Sunteți pe pagina 1din 84

UNIVERSITATEA GEORGE BACOVIA BACU

BAZE DE DATE SUPORT DE CURS

Conf. univ. dr. Andreia Melnic

Uz intern Bacu 2008

CUPRINS Capitolul 1. INTRODUCERE IN STUDIUL LIMBAJELOR DE PROGRAMARE. ..3 1.1. Noiuni generale privind limbajele de programare 1.2. Clasificarea limbajelor de programare 1.3. Structurarea i organizarea datelor. Tipuri de date utilizate n limbajele de programare 1.4. Criterii de selecie a limbajelor de programare CAPITOLUL 2 BAZE DE DATE I SISTEME DE GESTIUNE A BAZELOR DE DATE.15 2.1 Concepte utilizate n studiul bazelor de date i al sistemelor de gestiune a bazelor de date 2.2. Modele de structurare a datelor n baze de date 2.3. Sisteme de gestiune a bazelor de date 2.4. Arhitecturi multiutilizator pentru sisteme de gestiune a bazelor de date 2.5. Protecia i securitatea bazelor de date 2.6. Administrarea datelor i a bazelor de date Capitolul 3. MODELUL RELAIONAL AL DATELOR50 3.1. Elementele modelului relaional 3.2. Algebra relaional 3.3. Studiul dependenelor funcionale 3.4. Normalizarea bazelor de date relaionale Capitolul 4. LIMBAJE DE INTEROGARE A BAZELOR DE DATE SQL.65 4.1. SQL - Evoluie i performane 4.2. Comenzi pentru descrierea datelor; 4.3. Comenzi pentru interogarea bazelor de date

Capitolul 1. INTRODUCERE IN STUDIUL LIMBAJELOR DE PROGRAMARE 1.1. Noiuni generale privind limbajele de programare 1.2. Clasificarea limbajelor de programare 1.3. Structurarea i organizarea datelor. Tipuri de date utilizate n limbajele de programare 1.4. Caracterizarea principalelor limbaje de programare 1.5. Criterii de selecie a limbajelor de programare 1.1. Noiuni generale privind limbajele de programare Odat cu apariia calculatoarelor electronice a aprut i noiunea de limbaj de programare ca mijloc de dialog om-calculator. Limbajele de programare aparin setului de limbaje artificiale create de om i servesc la exprimarea, sub form de instruciuni executabile de ctre calculator, a algoritmului de rezolvare a unei probleme. Algoritmul indic modul de prelucrare a datelor iniiale i modificarea lor pas cu pas pn la obinerea rezultatelor finale. Natura datelor, organizarea lor i relaiile dintre ele trebuie precizate prin program. Limbajele de programare ofer faciliti corespunztoare de descriere. Definiia modern consider limbajul de programare un instrument de dialog omcalculator care are proprietatea c este neles de ambii participani la dialog. Toate limbajele de programare se bazeaz pe un set de simboluri elementare (de obicei, literele mari i mici ale alfabetului latin, cifrele sistemului zecimal, caractere speciale (+ - * /, %...), numit alfabetul limbajului. Aceste simboluri sunt asamblate n cuvinte-cheie sau expresii care formeaz vocabularul limbajului (instruciuni, comenzi, funcii, variabile, constante). Ansamblul regulilor prin care se construiesc instruciunile constituie gramatica limbajului. Exprimarea regulilor gramaticale din limbajul de programare se realizeaz cu ajutorul unui metalimbaj. Elementele de metalimbaj apar n documentaiile care nsoesc produseleprogram. Cele mai des utilizate elemente de metalimbaj sunt: cuvinte scrise cu majuscule reprezint cuvinte rezervate i trebuie folosite exact n aceeai form. De exemplu.: comenzi, clauze i funcii n Visual FoxPro - LIST, CREATE, FOR, IIF(); cuvinte utilizator - sunt scrise cu litere mici i reprezint construcii care vor fi nlocuite de utilizator. De exemplu: codprod, um, cant, pretu; [ ]- ncadreaz o construcie opional (programatorul decide dac acestea vor fi sau nu folosite). De exemplu: LIST [FIELDS <lista_cmpuri>] etc.; { } sau | - sau exclusiv din elementele prezente se va alege unul singur. Exemplu: TO PRINT| TO FILE, ON|OFF, etc.; n practic exist i ncercri de standardizare a metalimbajelor, cele mai cunoscute fiind BNF (Backus Naur Form) i EBNF(Extended BNF). Limbajele de programare servesc la transformarea ntr-un format accesibil calculatorului a modului de rezolvare a unei probleme. Utiliznd limbajul de programare, omul va ntocmi un program care descrie problema de rezolvat n termeni inteligibili pentru calculator. Programul reprezint un ansamblu de instruciuni i/sau comenzi scrise cu ajutorul unui limbaj de programare care descriu prelucrrile de date pe care trebuie s le execute calculatorul n scopul rezolvrii unei probleme. Instruciunile i/sau comenzile reprezint informaii codificate prin care se transmite calculatorului aciunea ce urmeaz a fi executat. La rndul lor acestea pot fi structurate n dou mari grupe:

de prelucrare prin care se realizeaz introducerea/extragerea datelor n/din


sistem, efectuarea operaiunilor de calcul, efectuarea transferului de date ntre diferite zone de memorie etc.; de organizare (de structurare intern a programului) ce asigur codificarea structurilor de control i de apelare sau de salt la alte programe. Ansamblul activitilor de concepere, dezvoltare i ntreinere a programelor poart denumirea de programare. Programul scris de om se numete program-surs. Pentru a putea fi neles de calculator el trebuie adus n format executabil. Obinerea formatului executabil se realizeaz prin traducere, cu ajutorul unor programe speciale, care pot fi interpretoare sau compilatoare. Figura 1.1 ilustreaz procesul de programare.

Problema Programator (utilizator) pe baza analizei problemei de rezolvat Scrie programul Program Calculator instruciuni pentru calculator Traducere automat n limbaj main execut programul Rezultat

Reguli i restricii ale limbajelor de programare


Figura 1.1. Procesul de programare Aa cum rezult din figura 1.1, n cazul problemelor simple, calea de la problema de rezolvat la rezultate este relativ uoar, putnd fi sintetizat astfel: definirea i analiza problemei, elaborarea algoritmului de rezolvare a problemei i reprezentarea acestuia, codificarea algoritmului ntr-un program utiliznd un limbaj de programare, transformarea programului surs n program executabil (prin compilare sau interpretare), testarea i documentarea, exploatarea i ntreinerea. n cazul problemelor complexe, activitatea de programare capt caracteristicile activitilor de tip industrial, presupunnd implicarea mai multor categorii de specialiti, mai mult timp i mai muli bani. n acest caz, rezultatul activititii de programare este produsulprogram. Acesta ilustreaz tocmai trecerea de la artizanal la industrial n programare. Prin produs-program se desemneaz att programul propriu-zis, ct i documentaia pentru elaborarea, implementarea i ntreinerea sa. Documentaia poate fi inclus n program prin linii de documentare/linii comentariu, care nu influeneaz modul de derulare a execuiei programului, facilitnd doar nelegerea sa sau ataat programului sub forma dosarului de programare care la rndul su cuprinde descrierea problemei i a funciilor sale, descrierea structurii datelor (de intrare i de ieire), descrierea algoritmului de rezolvare a problemei, programul surs, descrierea condiiilor de implementare i exploatare. Produsele-program sunt realizate att de ctre firme specializate, ct i de firme carei dezvolt propriile aplicaii.

Industrializarea activitii de programare a determinat apariia, n 1968, a conceptului de ingineria programrii (software engineering), un domeniu al informaticii care se ocup cu identificarea celor mai adecvate soluii, metode, procedee i instrumente care s conduc, n condiii optime de productivitate i eficien, la elaborarea de produse-program performante. De la ingineria programrii s-a trecut apoi la ingineria programrii asistate de calculator (CASE- Computer Aided Software Engineering). Altfel spus, calculatorul i face singur programele, numai c trebuie s-i furnizm singuri intrrile ntr-un mod ordonat, dup anumite reguli. La primele limbaje de programare trecerea de la programele surs la programele executabile se realiza prin comenzi distincte n care se specificau explicit operaiunile de efectuat. Ulterior, evoluia s-a orientat ctre medii de programare. Mediile de programare reprezint pachete de programe care asigur integrarea urmtoarelor funcii: introducerea i editarea programului surs, interpretarea sau compilarea, respectiv editarea de legturi, ncrcarea i lansarea n execuie, depanarea programului. Actualmente majoritatea limbajelor de programare sunt integrate n medii de programare. Spre exemplu, Visual Basic se poate considera c reprezint un mediu de programare care ofer un editor de texte, un interpretor, un ncrctor de programe, un depanator de programe. n puls, ofer faciliti de gestionare a fiierelor prin meniul FILE i o informare complet i rapid prin sistemul HELP. 1.2. Clasificarea limbajelor de programare Cea mai folosit clasificare este cea care grupeaz limbajele de programare pe generaii i urmrete periodizarea evoluiei calculatoarelor. Generaiile de limbaje care pot fi identificate sunt: Generaia I - limbajele n cod main, n care toate instruciunile sunt numerice (iruri de 0 i 1), fiind redactate plecnd de la un cod binar propriu fiecrei maini (calculator). Utilizatorul trebuia s in minte toate codurile numerice, ceea ce la calculatoarele moderne ar nsemna mii de coduri i adresele de memorie utilizate, astfel c productivitatea este foarte redus. Programele scrise n limbaj main puteau fi executate numai pe calculatorul pentru care au fost elaborate (nu erau portabile). Principalele deficiene ale acestor limbaje sunt legate de dificultile de corectare a programelor, aceste programe fiind mari, iar erorile greu de identificat. Generaia a II-a - limbajele de asamblare, care nlocuiesc codurile numerice cu cele mnemonice, adresele fiind alocate de sistem. Utilizarea acestor limbaje presupune existena unor programe speciale numite asambloare care s traduc instruciunile n limbaj cod main. Instruciunile se traduc 1 la 1, adic fiecrei instruciuni n limbaj de asamblare i corespunde o instruciune n cod main. Operaia poart numele de asamblare, iar rezultatul se numete program obiect executabil. Pentru a reprezenta codurile de operaii i poziiile din memorie se folosesc simboluri, motiv pentru care aceste limbaje se mai numesc i limbaje simbolice. Execuia unui program surs scris ntr-un limbaj de asamblare are loc pe parcursul a dou etape: asamblarea i execuia propriu-zis. Schematic se obine urmtoarea reprezentare (figura nr. 1.2): P.S. Program executabil

1. Asam blare 2. Execuie Rezultate finale

Asam blor Date

Fig. nr.1.2. Tratarea programelor n limbaje de asamblare Limbajele de asamblare permit utilizarea de abrevieri alfabetice (mnemonice) care sunt mai uor de memorat dect adresele scrise n binar ( Ex. ADD - adunare, DIV mprire). Ele simplific enorm programarea, deoarece elimin memorarea poziiilor din memorie pentru date i instruciuni. Totodat, limbajul de asamblare rmne un limbaj orientat main deoarece instruciunile n limbaj de asamblare corespund instruciunilor n limbaj main conform modelului de calculator utilizat. O singur instruciune n limbaj de asamblare corespunde unei singure instruciuni n limbaj main i deci este nevoie de acelai numr de instruciuni n ambele cazuri. Aceste limbaje sunt utilizate pentru elaborarea software-ului de sistem, datorit vitezei de execuie ridicate, chiar dac limbajele evoluate solicit un efort de programare mai mic. Exemplu: S se calculeze media aritmetic a trei numere M=(X+Y+Z)/3 LDA X - ncarc X n registrul A ADD Y - adun Y la coninutul registrului A ADD Z -adun Z la coninutul registrului A DIV 3 - mparte rezultatul la 3 STA B - stocheaz rezultatul final n B Limbajele n cod main i de asamblare sunt limbaje de nivel redus. Generaia a III-a - limbajele de nivel nalt sau evoluate, care au dominat peste 30 de ani piaa informaticii. Reprezentative sunt: FORTRAN pentru ingineri i matematicieni i COBOL pentru mediul economic. Caracteristica lor principal este proceduralitatea (adic urmresc pas cu pas procedura de rezolvare a unei probleme). Au fost create mii de astfel de limbaje, unele avnd destinaii precise (FORTRAN i ALGOL sunt destinate calculelor tiinifice, COBOL este destinat aplicaiilor economice, SIMULA fiind un limbaj de simulare, etc.), iar altele avnd utilizare larg (BASIC, PASCAL, C). i instruciunile scrise n aceste limbaje trebuie traduse n cod main; pentru aceasta se utilizeaz dou categorii de translatoare: compilatoare - sunt translatoare care citesc tot programul n limbajul n care este scris (n cod surs) i apoi l traduc n cod main (sunt utilizate pentru COBOL, FORTRAN); interpretoare - sunt translatoare care citesc pe rnd fiecare instruciune din programul surs, o traduc i o execut (sunt utilizate pentru BASIC, PASCAL). Prin urmare programele surs redactate n limbaje evoluate sunt supuse unui proces de tratare desfurat pe trei faze: compilarea /interpretarea; editarea de legturi; execuia propriu-zis. Schematic se obine urmtoarea reprezentare (figura nr.1.3 ):

P.S.

ProgramO. P.O. imagine memorie executabil

1. Compilare/ interpretare 2. Editarede legturi 3. Execuie Rezultate finale

Compilator/ interpretor Editor de legturi Date

Fig.1.3. Tratarea programelor n limbaje evoluate Avantaje: sunt mai uor de nvat i utilizat dect limbajele de asamblare; sunt portabile (pot fi utilizate i pe un alt calculator); pot fi oricnd modificate i actualizate. Ctigul de productivitate este remarcabil: o linie de program scris cu un limbaj de generaia a III-a reprezint mai mult de 100 de linii de instruciuni n cod-main. Dezavantaje: au reguli i sintaxe rigide i deloc uor de nvat pentru un utilizator nespecialist; solicit mult timp pentru translatare n cod main (descoperirea unei erori nseamn nu numai corectarea ei, ci i traducerea din nou n cod main). Exemplu: Folosind limbaje din generaia a 3-a s se codifice X = Y Z n COBOL SUBSTRACT Z FROM Y GIVING X n BASIC LET X = Y - Z N PASCAL X : = Y-Z Aceste limbaje se caracterizeaz prin proceduralitate, adic evenimentele se succed secvenial, unul dup altul. Exist n literatura de specialitate o mprire a LG3 n generaii. Cu meniunea c exist i excepii, iat care sunt acestea: generaia I se ncadreaz n intervalul 1954 1958. Comenzile erau bazate pe expresii matematice. Reprezentani: FORTRAN I, ALGOL 58; generaia a II-a acoper intervalul 1959 1961 (FORTRAN II, ALGOL 60, COBOL). Apar subrutinele programate, se definesc structurile de date i lucrul cu fiierele de date; generaia a III-a cuprinde intervalul 1962 - 1970 i este reprezentat de limbaje de programare structurate (ALGOL 68, PL/1, PASCAL, BASIC, COBOL strucutrat). Se impun principiile programrii structurate. Realizarea unui program ncepe cu definirea principalilor pai i continu n aceast manier pn cnd ntregul program este dezvoltat. Ideea structurrii a aprut datorit problemelor ce apreau la dezvoltarea de aplicaii complexe, cea mai relevant fiind lipsa viziunii de ansamblu asupra programului. Dei primele concepte ale programrii structurate au aprut nc de la nceputul anilor 60, implementarea lor s-a fcut n timp, n sprijinul acesteia crendu-se metodologiile care ofereau direciile de urmat n proiectarea de aplicaii, pas-cu-pas. dup anii 70 au aprut tot mai multe tipuri de LP, astfel ca ncadrarea lor n generaii a devenit tot mai dificil. Programarea structurat s-a generalizat. n domeniul aplicaiilor economice, COBOL deinea 80% din totalul acestora. Generaia a IV-a (4GL) - limbajele de nivel foarte nalt, care au aprut n primul rnd pentru utilizatorii nespecialiti, numii i utilizatori finali. Se caracterizeaz prin neproceduralitate (utilizatorul trebuie s-i spun calculatorului CE S FAC, i nu CUM S FAC) i este un limbaj conversaional, interactiv. Se bazeaz n mare msur pe utilizarea meniurilor i interfeelor grafice, fiind uor de nvat (ofer faciliti de tip HELP sau Wizard).

Evenimentul ce a perturbat evoluia limbajelor procedurale a fost apariia i, mai ales, rspndirea PC-urilor. La mijlocul anilor 80 a nceput declinul mainframe-urilor si al prelucrrii centralizate a datelor. Managerii erau ncntai de posibilitile pe care le oferea PC-ul n a-i rezolva singuri multe din probleme, mai ales odat cu apariia interfeelor grafice. Utilizatorii de PC-uri nu-i propuneau s rezolve probleme complicate i s dezvolte aplicaii complexe, astfel c nu aveau nevoie de limbaje declarative. Ei cereau limbaje grafice, prietenoase, de aceea limbajele procedurale au evoluat altfel dect ctre declarativ. A IV-a generaie de limbaje de programare a fost orientat ctre utilizatori, fiind numit i generaia utilizatorilor finali. Productorii de software s-au orientat ctre crearea de instrumente i medii de lucru prietenoase, iar accentul s-a mutat pe interfaa cu utilizatorul. O interfa grafic, simpl, dar nu simplist, care s ofere utilizatorului un mediu de lucru eficient i prietenos n acelai timp a devenit cheia unui soft de succes. Caracteristicile limbajelor de generaia a IV-a pot fi rezumate astfel: neproceduralitate, interfa prietenoas i eficacitate. Majoritatea specialitilor grupeaz limbajele din generaia a-4-a n urmtoarele clase de produse: limbaje (instrumente) de interogare; generatoare de rapoarte; generatoare de aplicaii i /sau proiecte; generatoare de grafice; instrumente de sprijinire a deciziilor. La ora actual constructorii de software ofer produse care integreaz toate aceste funciuni. De exemplu, programul de calcul tabelar EXCEL este un instrument de sprijinire a procesului decizional, dar care ofer i o vast gam de alte faciliti: generarea graficelor, obinerea, actualizarea i interogarea bazelor de date, generarea rapoartelor etc. Limbajele de interogare la rndul lor pot fi de dou tipuri: limbaje de interogare simpl care permit consultarea fiierelor i bazelor de date pe un singur tip de nregistrare logic utiliznd un criteriu de selecie mai puin complex; limbaje de interogare complex care permit consultarea mai multor tipuri de nregistrri logice din una sau mai multe baze de date devenind posibil asocierea unor structuri foarte diferite. n cea de a doua subgrup intr SQL (Structure Query Language), QBE (Query By Example), Hiper Talk, INTTELECT, etc. Cea mai mare rspndire o cunoate SQL, un nucleu SQL fiind prezent n orice sistem de gestiune a bazelor de date (Acces, FoxPro, Oracle). Generatoarele de rapoarte ndeplinesc, n principal, trei funcii eseniale: selecia informaiilor solicitate, ordonarea datelor dup criterii prestabilite i editarea rapoartelor ntro structur formalizat folosind un numr minim de instruciuni de programare. n general, toate sistemele de gestiune a bazelor de date precum i programele de calcul tabelar (spreadsheet-urile) au ncorporate generatoare de rapoarte. Cele mai populare instrumente din aceast categorie sunt: Easytrieve Plus, Datatrieve, Mark V1. Exist i generatoare de rapoarte care sunt proiectate pentru a fi utilizate de ctre specialiti RPG III (Report Program Generator). Generatoarele de aplicaii i/sau proiecte se adreseaz n special utilizatorilor cunosctori ai tehnicilor de programare. Ele permit ca pe baza unor descrieri externe a datelor i a modului de organizare, prelucrare i afiare a acestora s se accelereze generarea (codarea) programelor, folosind un limbaj specific sau chiar un limbaj de generaia a-3-a (COBOL). Intr n aceast clas de generatoare CSP (Cross System Product), FOCUS, Mantis, Natural, NOMAD2, RAMIS 1, IDEAL MAPPER, modulele de tip RAD pentru dezvoltarea rapid a aplicaiilor.

Oprea, D., Premisele i consecinele informatizrii contabilitii, Ed. Graphix, Iai, 1994, p. 96
1

O categorie aparte o reprezint pachetele-aplicaii specializate pentru aplicaii economice generale (finane-contabilitate) sau chiar numai pentru procesri de texte, tehnoredactri (DeskTop Publishing). Generatoarele de grafice sunt instrumente ce permit reprezentarea sub form grafic (histograme, bare, linii, cercuri etc. bi sau tridimensionale, cu opiuni de culoare, text, legend), a rezultatelor prelucrrii datelor. Ele sunt independente (Tell-al Graph, SAS, ADRS/B6) sau ncorporate n spreadsheet-uri (LOTUS, QUATTRO, EXCEL) sau SGBD-uri (FoxGraph). Instrumentele de sprijinire a deciziilor se adreseaz experilor din diferite domenii de activitate (finane, management, contabilitate, marketing etc.) pentru elaborarea i urmrirea bugetelor, analiza investiiilor, studiul pieei etc. permind realizarea simulrii i modelrii matematice a fenomenelor economice. Intr n aceast clas programele de calcul tabelar (QUATTRO, LOTUS, EXCEL .a.), pachetele program statistice (SPSS, SAS etc.). Generaia a V-a cuprinde limbajele care sunt sau vor fi ndreptate spre exploatarea bazelor de cunotine, crearea sistemelor expert i, mai general, spre rezolvarea problemelor legate de inteligena artificial. Dup cum se observ limbajele au evoluat continuu, aa cum rezult din figura 1.4.

Tendine majore n software


Generaia I Generaia II Generaia III Generaia IV Generaia V Tendina: ctre limbajele de programare conversaionale, naturale Evoluie limbaje limbaje n limbaje de cod main asamblare limbaje de nivel inalt; primele sisteme de operare limbaje de gen. a IV-a (4GL) orientate ctre utilizator limbaje naturale; sisteme expert

Tendina: ctre aplicaii cu scop general, orientate spre utilizatorul nespecialist


Fig. nr. 14. Evoluia limbajelor de programare Aa cum rezult i din figura 1.4, dou sunt tendinele care au marcat evoluia limbajelor de programare. Prima este trecerea de la programele specializate pe un tip de probleme, elaborate de programatori profesioniti la pachetele de software cu destinaii diverse adaptate la nivelul utilizatorilor finali neinformaticieni. Aceast tendin s-a amplificat odat cu apariia microcalculatoarelor. Tendina principal n prezent este ctre instrumente avansate de dezvoltare a aplicaiilor orientate pe obiect. A doua tendin este ndeprtarea de limbajele de programare tehnice, foarte dificil de utilizat, specifice nceputurilor programrii (limbaje de generaia I i a II-a) i de limbajele procedurale. Tendina este ctre limbajele neprocedurale i limbajele naturale, apropiate de limbajul uman, tendin care s-a accentuat odat cu apariia celei de-a IV-a generaii de limbaje. Ea continu prin mbuntirea interfeelor grafice i dezvoltarea inteligenei artificiale, care produce ateptatele limbaje naturale. Este vorba de cea de-a V-a generaie de limbaje de programare, reprezentat de pachete de programe asistate de experi. i n pachetele de programe actuale sunt ncorporate unele module de ajutor sau module de sprijin inteligente (wizard) care ofer utilizatorului asisten n rezolvarea unor probleme (realizarea unui grafic sau tabel). O alt clasificare a limbajelor de programare a fost realizat de J.E. Sammet ntr-o lucrare publicat n 19692, el avnd n vedere urmtoarele clase de limbaje: procedurale, neprocedurale, orientate pe problem i speciale. ncadrarea unui limbaj de programare anume ntr-o clas este uneori dificil de realizat.
2

Sammet, J.,E., Programming Languages: History and Fundamentals, N.J. Prentice-Hall, 1969

Limbajele procedurale (numite i limbaje de nivel nalt) sunt utilizate pentru a descrie un algoritm de rezolvare a unei probleme. Se descriu complet operaiunile care se execut i ordinea de execuie a acestora. Ele rspund la ntrebarea CUM?. Exemple: COBOL, FORTRAN, BASIC, ALGOL, PASCAL. Limbajele neprocedurale (numite i limbaje de nivel foarte nalt) ofer soluia de rezolvare a unei probleme, dar fr a da detalii asupra modului concret de rezolvare. Ele rspund la ntrebarea CE?. Exemplu: limbajele din SGBD, PROLOG, LISP. Limbajele speciale descriu funcii specifice ale produselor-program. De exemplu, procesorul Word are inclus un limbaj de scriere a macrourilor. Limbajele orientate pe problem deservesc domenii restrnse de activitate. Astfel de limbaje sunt limbajele de simulare, ca, de exemplu, GPSS (General Purpose System Simulation) care este conceput pentru descrierea i rezolvarea problemelor de simulare. 1.3. Structurarea i organizarea datelor. Tipuri de date utilizate n limbajele de programare Dezvoltarea rapid i complex a societii a dus n mod inevitabil la o sporire nsemnat a volumului de date, care tind s aglomereze i s blocheze canalele informaionale n aceeai msur n care crete continuu nevoia de informaie. Rezult c orice organism economic se confrunt cu un volum mare de date, supus unor prelucrri relativ simple, dar cu un caracter repetitiv i cu o frecven mare. n acelai timp datele se caracterizeaz printr-o structur uniform rezultat din structura documentelor primare specifice operaiilor economice. Toate acestea reprezint, de fapt, restricii n activitatea de structurare i organizare a datelor economice n sistemele informatice. 1.3.1 Concepte utilizate n organizarea datelor Organizarea datelor reprezint procesul de identificare, definire, structurare i memorare a datelor.3 O bun organizare a datelor impune folosirea unor structuri care s permit o prelucrare cu un cost ct mai redus. O colecie de date pe care s-a definit o structur, creia i este specific un anumit mecanism de selecie i identificare a elementelor componente constituie o structur de date. Toate structurile de date care au aceeai organizare i sunt supuse acelorai operaii formeaz un anumit tip de structur de date. Pentru specificul activitilor economice fiecare nivel de abstractizare implic: date elementare i date structurate. Noiunea de dat elementar se refer la mulimea ordonat i finit de valori, de un anumit tip, asupra crora se pot efectua operaii. O dat care apare ca entitate indisolubil att n raport de informaia pe care o reprezint, ct i n raport de procesorul care o prelucreaz se numete dat elementar. Cel mai des ntlnite tipuri de date elementare n limbajele de programare sunt: tipul numeric se includ numerele ntregi, reale i complexe i asupra crora se pot realiza operaii de adunare, scdere, etc.; tipul logic (boolean) este utilizat pentru precizarea strilor de adevr (TRUE, YES) sau neadevr (FALSE, NO) ale unui enun. Asupra acestora se pot efectua operaii logice: AND, OR, NOT; tipul caracter - conine o mulime de caractere alfanumerice, n cadrul acestora putndu-se defini operaii de concatenare, ordonare etc.; tipul pointer - conine adrese ctre alte date elementare. Aceste tipuri de date sunt elemente invizibile ale limbajelor de programare, iar structura lor intern nu este accesibil programatorului.
Cristea , V. , Dicionar de informatic, Editura tiinific i enciclopedic, Bucureti , 1981, p. 240
3

10

Datele structurate sunt colecii de date elementare care, ntr-un anumit sens, sunt n relaii unele cu altele. Natura relaiei se stabilete la crearea structurii i poate diferi n funcie de nivelurile de abstractizare. Cele mai utilizate date structurate sunt: articolul; fiierul; tabloul. Articolul este o structur de tip arborescent ale crui cmpuri (cmpul reprezentnd o mrime ce poate lua valori diferite dintr-o multitudine de valori posibile, face excepie cmpul boolean care poate lua doar dou valori) sunt descendenii rdcinii (nivelul 1), subcmpurile sunt descendenii cmpurilor (nivelul 2) .a.m.d. Cmpurile unui articol pot fi date elementare sau grupuri de date de diverse tipuri. n principiu fiecare cmp sau subcmp se definete prin urmtoarele atribute: nume - un cod unic de identificare; tip - natura datei; lungime - numrul total de caractere; partea zecimal specificat numai pentru datele numerice. De exemplu, articolul PRODUSE poate avea n structur urmtoarele cmpuri: Nume Tip Lungime Partea zecimal CODPROD N 5 0 DENUMIRE C 10 PRE N 9 2 STOC N 8 2 Fiierul este o structur de date omogene din punct de vedere a semnificaiilor i a cerinelor de prelucrare, nregistrate pe un suport i care pot fi exploatate individual. ntr-un fiier trebuie s distingem articolul tip (structura articolului) care este o modalitate de a descrie dac un obiect aparine sau nu la o clas de obiecte, de realizrile (articolele) care sunt elemente ale clasei de obiecte descrise. Tabloul este o colecie de date de acelai tip, aranjate ntr-o structur rectangular, cu una sau mai multe dimensiuni. Tablourile cu o dimensiune se numesc vectori, iar cele cu mai multe dimensiuni se numesc matrici sau masive. Pentru fiecare dimensiune se asociaz un indice ale crui valori sunt folosite pentru referirea elementelor tabloului. Ex. T (i1, i2...ik), unde k reprezint numrul de dimensiuni, iar i1, i2....ik sunt elementele tabloului T. De exemplu, pentru introducerea notelor obinute de studeni n cele 2 sesiuni, fiecare sesiune avnd cte 5 examene, definim variabila Nota(2,5). Vom obine un tablou de variabile astfel: Nota(1,1), Nota(1,2), Nota(1,3), Nota(1,4), Nota(1,5), Nota(2,1), etc. n Visual FoxPro, de exemplu, declararea unui tablou poate fi realizat cu comanda DIMENSION: DIMENSION VECT(3), MATR(5,10) NOTE se definete vectorul VECT cu 3 elemente i matricea MATR cu 5 linii i 10 coloane. Prelucrarea datelor presupune parcurgerea unei succesiuni ordonate de operaii care acioneaz asupra mrimilor. Ele se pot grupa n urmtoarele categorii: operaiuni de atribuire; operaiuni de calcul; operaiuni de decizie; operaiuni de intrare /ieire; operaiuni de transfer a controlului.

11

Operaiuni de atribuire sunt acelea prin care unui cmp i se atribuie o anumit valoare predefinit sau rezultatul evalurii unei expresii. TOTVAL = 0 SF = SID + RD RC Operaii de calcul se definesc pe mulimea numerelor reale. Dintre acestea fac parte operaia de adunare, scdere, nmulire, mprire, ridicare la putere, calculul unor expresii numerice etc. Ca operatori se utilizeaz: + pentru adunare; - pentru scdere; * pentru nmulire; / pentru mprire; ** pentru ridicare la putere. De asemenea, n cadrul expresiilor se pot utiliza i parantezele, evaluarea acestora fcndu-se dup regulile din algebr. Exemplu: SALAR NET = ((NRORLUCR * TO) + SPORV) - IMPOZ a = (b * c)**2 + 650 Operaiunile de decizie sunt utilizate pentru a delimita valoarea logic a unei propoziii: adevrat sau fals. Ele condiioneaz executarea unor operaii sau grupuri de operaiuni. Operatorii utilizai pentru scrierea condiiilor pot fi operatori relaionali (=, >, <, ) i operatori logici (AND, OR i NOT). Exemplu: IF STOCSIGUR < 10000 THEN PRINT "ATENIE! E NECESAR REAPROVIZIONAREA" ENDIF sau FOR MEDIA > 9.50 .AND. DOMICILIU ='NON IAI' PRINT 'DREPT DE CAZARE' Operaiunile de intrare/ieire vizeaz realizarea transferului de date ntre memoria extern i cea intern i invers. Pentru optimizarea operaiei de intrare/ieire se interpun zone tampon (buffere), att pentru intrare, ct i pentru ieire conform schemei urmtoare (figura nr. 1.5):

Zonde intrare Zonde lucru Zonde ieire

Zona tampon
Z. ARTICOL COD DEN UM CANT PRE
X

VALOARE

Z. ARTICOL

COD

DEN

UM

CANT

PRE

VALOARE

Zona tampon

Fig. 1.5. Transferul de date ntre memoria intern i cea extern

12

Cele mai utilizate operaii de I/E sunt cele de deschidere i nchidere a fiierelor i de citire i scriere date. Operaiunile de transfer a controlului sunt operaii de salt i de apelare. Cele de salt au rolul de a preda controlul unei alte operaiuni dect cea imediat urmtoare, iar cele de apel, determin lansarea n execuie a unor proceduri (grupuri de operaiuni), evitndu-se descrierea lor, de mai multe ori, n cadrul algoritmului. Schematic derularea unei secvene de operaiuni de apel se prezint astfel (figura nr. 1.6.):

Fig. 1.6. Derularea operaiunilor de apel

1.4. Criterii de selecie a limbajelor de programare La alegerea unui limbaj de programare trebuie avute n vedere o serie de aspecte care s asigure eficien, siguran i flexibilitate n rezolvarea aplicaiilor utilizator. Criteriile care stau la baza opiunii de selectare a limbajului privesc urmtorii factori:4 1. tipul problemei ce urmeaz a fi rezolvat i cunotinele utilizatorului (msura n care limbajul de programare este convenabil att la clasa de probleme, ct i pentru utilizator) 2. tipul echipamentelor disponibile utilizatorului 3. gradul de dependen fa de echipamentul folosit i sistemul de operare 4. evaluarea rezultatelor obinute prin folosirea anterioar de ctre ali utilizatori 5. eficiena scontat prin exploatare 6. caracteristicile tehnice i funcionale generale 7. cerine de ordin economic Tipul problemei ce urmeaz a fi rezolvat i cunotinele utilizatorului Acest criteriu are n vedere selectarea acelui limbaj care s rspund cel mai bine tipului /tipurilor de aplicaii utilizator, s asigure concomitent uurin n utilizare, un timp minim pentru prelucrarea datelor confidenialitatea i securitatea acestora. Tipul echipamentelor hardware disponibile utilizatorului naintea alegerii limbajului trebuie efectuat o analiz a resurselor fizice existente i a celor care urmeaz s fie achiziionate. Aceast analiz trebuie s stabileasc dac sunt asigurate resursele minime pentru dezvoltarea i exploatarea aplicaiilor. n felul acesta se urmrete utilizarea eficient a limbajului pe echipamentele din dotare. Gradul de dependena fa de echipamentul folosit i sistemul de operare Conform acestui criteriu trebuie ales un limbaj de programare care s poat fi folosit fr probleme sub sistemul de operare sub care lucreaz echipamentele din dotare. n plus, trebuie asigurat portabilitatea programelor n cazul n care se vor achiziiona noi resurse informatice. Trebuie asigurat creterea gradului de portabilitate cel puin la nivel de program surs.
4

Sammet, J.,E., Programming Languages: History and Fundamentals, N.J. Prentice-Hall, 1969

13

Evaluarea rezultatelor obinute prin folosirea anterioar de ctre ali utilizator Acest criteriu cere realizarea unei documentri prealabile privind problemele cu care s-au confruntat ali utilizatori ai limbajului (existena /inexistena unei documentaii de nvare i utilizare, posibilitile/facilitile de rezolvare a problemelor practice etc.). Eficiena scontat prin exploatare. Aceast eficien implic stabilirea parametrilor de exploatare pe fiecare etap de realizare a programelor /produselor-program(scriere, testare, implementare, utilizare). Se are n vedere att eficiena execuiei programului, mai ales la programele des utilizate ct i eficiena global care ia n considerare toate fazele de elaborare i utilizare (scriere, testare, exploatare i ntreinere). n acest context performana limbajului poate deveni o problem mai puin important. Caracteristicile tehnice i funcionale generale. Alegerea unui limbaj trebuie sa in seama i de gradul de standardizare a acestuia, tiut fiind c, n general, la standardizarea unui produs informatic se au n vedere parametrii ce privesc simplitatea n exploatare, generalitatea n aplicare, naturaleea, consistena i conciziunea n exprimare. Cerine de ordin economic Aceste cerine in seama de resursele financiare de care dispune utilizatorul , resurse care trebuie s acopere att achiziionarea i exploatarea propriu-zis a limbajului, ct i organizarea i pregtirea prealabil a personalului. Avnd n vedere cele de mai sus rezult c alegerea unui limbaj este o decizie care trebuie susinut printr-o serie de analize de ordin tehnic, funcional i economic.

14

CAPITOLUL 2. BAZE DE DATE I SISTEME DE GESTIUNE A BAZELOR DE DATE 2.1 Concepte utilizate n studiul bazelor de date i al sistemelor de gestiune a bazelor de date 2.2. Modele de structurare a datelor n baze de date 2.3. Sisteme de gestiune a bazelor de date 2.4. Protecia i securitatea bazelor de date 2.5. Administrarea datelor i a bazelor de date Sistemele de baze de date reprezint cea mai important dezvoltare n domeniul ingineriei programrii, ele devenind din ce n ce mai accesibile penru o larg varietate de utilizatori. 2.1. Concepte utilizate n studiul bazelor de date i al sistemelor de gestiune a bazelor de date 2.1.1. Metoda prelucrrii prin fiiere independente Sistemul bazat pe fiiere reprezint sistemul anterior bazelor de date. Modul de lucru bazat pe fiiere independente, demodat astzi, are o serie de neajunsuri care limiteaz eficiena i eficacitatea aplicaiilor utilizator5. Specific metodei prelucrrii prin fiiere, ilustrat n fig. nr. 2.1.6, este faptul c fiecare dat (Data1, Data2, ..., Datan) este descris n toate fiierele n care apare, iar fiecare fiier trebuie descris n toate programele n care este utilizat. Nu exist nici o posibilitate de a stabili n mod explicit o relaie ntre dou fiiere de date. Fig. nr. 2.1.Organizarea datelor n fiiere
Data1 Data2 Data3 Data2 Data4 Data3 Data1 Data2 DATE ... FIIER 3 Data5 ... FI IERE Prelucrare 3 ... FI IER 2 Prelucrare 2 FIIER 1 Prelucrare 1 Raport 1 Raport 2 Raport 3 Raport 4 IEIRI

PRELUCR RI

De asemenea, dac spre exemplu, Data2 din Fiier1 este modificat, modificarea nu se face automat i n Fiier2, ceea ce determin inconsistena datelor. Dezavantajele organizrii datelor n fiiere pot fi sistematizate astfel: 1. Redundana i inconsistena datelor, datorit prezenei aceleiai date n mai multe fiiere independente; Aceleai date sunt nregistrate i stocate n mai multe fiiere, ceea ce reclam programe distincte pentru actualizarea fiecrui fiier. n plus, duplicarea datelor conduce la un consum mare de memorie i incoeren la trecerea datelor stocate dintr-un fiier n altul. Aceasta duce la alterarea integritii datelor (datele nu mai concord), gestionarea complex i actualizarea greoaie a acestora, precum i la o monopolizare inutil a spaiului de memorie. 2. Complexitatea actualizrilor (adugarea, tergerea sau modificarea datelor); 3. Dificultatea obinerii de informaii neplanificate (spontane sau ad-hoc), chiar i pentru o simpl interogare fiind necesar scrierea unui program; Dispersia datelor n diverse fiiere independente complic accesul utilizatorilor la informaiile cerute ad-hoc, necesitnd crearea de programe particulare pentru extragerea
OBrian, Op. cit., pp. 244-246 Fotache, M., Baze de date relaionale, Organizare, interogare i normalizare, Ediia a II-a, Editura Junimea, Iai, 1997, p. 25
5 6

15

datelor solicitate. n lipsa acestor programe, pentru obinerea informaiilor dorite utilizatorul procedeaz la extragerea manual. 4. Costul ridicat de exploatare ca urmare a dublrii datelor; Exploatarea fiierelor independente presupune un cost ridicat, att n ceea ce privete resursele informatice (hardware i software), ct i cele legate de personalul utilizat. 5. Separarea i izolarea datelor; Atunci cnd datele sunt izolate n fiiere separate, programatorul de aplicaii trebuie s se asigure c sunt extrase datele corecte, fiind astfel necesar sincronizarea prelucrrii datelor din fiiere diferite, aceast operaiune fiind dificil cnd sunt solicitate date din mai mult de dou fiiere. 6. Formate de fiiere incompatibile, ceea ce face dificil prelucrarea lor simultan Deoarece structura fiierelor este ncorporat n programele de aplicaii, ea este dependent de limbajul de programare n care sunt scrise acestea. De exemplu, structura unui fiier generat de un program scris cu limbajul COBOL poate s fie diferit de cea a unuia generat cu un program n limbajul C. De aceea sunt necesare programe de transformare a fiierelor ntr-un format comun. 7. Dependena datelor fa de programele de aplicaii Organizarea fiierelor, adresa lor fizic n memorie i programele de aplicaii folosite pentru accesarea fiierelor sunt interdependente. Astfel, schimbrile legate de dispunerea pe suportul de memorie, de structura datelor i modificarea nregistrrilor unui fiier presupun modificri n toate programele n care este referit fiierul respectiv. ntreinerea acestor programe este dificil putnd genera incoerene n fiierele de date. Incoerena i lipsa de integritate sunt extrem de dificil de corectat deoarece nu exist un dicionar central pentru urmrirea definirii datelor. Toate aceste probleme care apar n sistemul ce prelucreaz fiiere i gsesc rezolvarea prin folosirea bazelor de date i a sistemelor de gestiune a bazelor de date. Datele stocate n baze sunt independente att fa de programele de aplicaii care le folosesc, ct i fa de tipul de memorie utilizat. 2.1.2. Baze de date Pe msura evoluiei sistemelor de prelucrare automat a datelor i, n mod special, a componentei hardware i software, dar i ca urmare a creterii volumului datelor de prelucrat s-a dezvoltat un nou concept, cel al bazelor de date. El i face apariia n a doua parte a anilor 60, aducnd un element de noutate, respectiv existena unui fiier de descriere global a datelor, ceea ce asigur independena datelor de programe i invers, fiier denumit dicionar de date (vezi fig. nr. 3.2). La momentul respectiv, n cadrul sistemelor informatice implementate n ntreprinderi, informaiile erau organizate n fiiere de date (secveniale, indexate etc.) create cu ajutorul unor programe scrise n limbaje din generaia a III-a: COBOL, FORTRAN etc. Principiul fundamental al bazelor de date l constituie unicitatea informaiilor, adic orice informaie este nregistrat o singur dat i poate fi utilizat ori de cte ori este nevoie, de ctre diferii utilizatori i n diferite momente. Baza de date reprezint un ansamblu integrat de nregistrri sau de fiiere reunite i structurate n mod logic. n felul acesta datele stocate anterior n fiiere independente/distincte sunt concentrate ntr-un fond comun de nregistrri cu posibilitatea utilizrii lor n numeroase aplicaii. Baza de date este o colecie partajat de date ntre care exist relaii logice i o descriere a acestor date, proiectat pentru a satisface necesitile informaionale ale unei organizaii. Ea reprezint un depozit de date unic care este definit o singur dat i este utilizat simultan de ctre mai multe departamente i utilizatori. n loc de a mai exista fiiere separate cu date redundante, toate datele sunt integrate, cu o dublare minim. Baza de date nu mai este deinut de un singur departament, ci constituie acum o resurs comun, partajat. Ea conine nu numai datele operaionale ale organizaiei, ci i o descriere a acestora. De aceea ea este definit i ca o colecie autodescris de nregistrri integrate. Aceast descriere a datelor este cunoscut sub denumirea de catalog de sistem sau dicionar de date sau meta-date (date
16

despre date). Natura autodescriptiv a bazelor de date este cea care determin independena program-date.
BAZA DE DATE

Fiier de date 1 Fiier de date 2 ... Fiier de date n Dicionar de date

Aplicaia 1

Aplicaia 2

...

Aplicaia m

Fig. nr .2.2. Structura unei baze de date Conceptul de baz de date a aprut n 1964 n cadrul primului raport CODASYL 7 prezentat la lucrrile unei Conferine pe probleme de limbaje de gestiune a datelor Development and Management of Computer centered date-base. La aceast conferin a fost lansat ideea organizrii datelor prin intermediul unui fiier de descriere global, numit dicionar de date care are menirea de a asigura independena programelor fa de date i a datelor fa de programe8. Atunci cnd se analizeaz necesitile informaionale ale unei organizaii se urmrete identificarea entitilor, a atributelor i a relaiilor dintre entiti. De aceea, abordarea bazelor de date presupune i tratarea urmtoarelor elemente: entitate (articol, nregistrare logic), atribut (caracteristic, cmp) i valoare/realizare9. Prin entitate se nelege un obiect concret sau abstract (operaie economic, mijloc economic etc.) reprezentat prin proprietile sau nsuirile sale. Orice proprietate poate fi exprimat printr-o pereche atribut-valoare sau caracteristic-realizare. O entitate este identificat printr-un nume i cuprinde, n general, mai multe valori sau realizri. Atributul are rolul de a descrie nsuirile sau proprietile obiectului, stabilind natura valorilor pe care acesta le poate lua. Valoarea reprezint mrimea ce se atribuie fiecrei caracteristici din cadrul unei entiti. Relaia reprezint o asociaie ntre mai multe entiti. Aceste elemente sunt prezentate n tabelul nr. 2.1: Tabelul nr. 2.1. Elemente specifice bazelor de date Entitate Caracteristici (atribute) Realizri (valori) Cod_produs 152 Denumire_produs Pantofi Unit_ms Pereche Produs Pre_ unitar 115 Cantitate 100 Nr._factur 2452 Data_recepiei 24-10-2007
COnference on DAta SYstems Languages Conferina despre Limbajele Sistemelor de Date Lungu, I., .a., Baze de date, Organizare, proiectare i implementare, Editura All, Bucureti, 1995, p.13 9 Aceste elemente sunt numite diferit n literatura de specialitate. Vezi Roca, I., .a. Baze de date i SGBD, Bucureti, 1986; Lungu, I., .a., Op., cit.,; Fotache, M., Baze de date relaionale, Editura Junimea, 1997
7 8

17

O baz de date trebuie s satisfac cinci condiii eseniale10:

O bun reprezentare a realitii nconjurtoare, adic baza de date trebuie s ofere ntotdeauna o imagine fidel a realitii prin informaii fiabile i actualizate; O non-redundan a informaiei, informaia coninut n baza de date trebuind s fie unic din punct de vedere semantic i fizic; O independen a datelor fa de prelucrri; datele constituie imaginea fidel a lumii reale, programele de aplicaii trebuind s fie concepute n raport cu aceast structur a datelor; Securitatea i confidenialitatea datelor; securitatea datelor trebuie asigurat prin proceduri fizice, iar confidenialitatea prin proceduri care s mpiedice accesul utilizatorilor neautorizai; Performane n exploatare, orice cerere de prelucrare trebuind s fie satisfcut ntr-un timp convenabil utilizatorului, ceea ce presupune folosirea unor tehnici de optimizare pentru reducerea timpului de prelucrare.

Dicionarele de date Accesul utilizatorilor la informaiile despre structura unei baze de date se realizeaz prin intermediul dicionarului de date. n principal, un dicionar ndeplinete urmtoarele funcii: definirea i gestionarea datelor elementare ale ntreprinderii (cod, etichet, atribute, reprezentare etc.); definirea i gestionarea ansamblurilor de date; definirea i gestionarea relaiilor, de dependen sau ierarhice, dintre date; descrierea din trei puncte de vedere a utilizrii datelor: administrativ: care sunt posturile de lucru ce vor apela datele i care va fi utilizarea acestor date? logic: care sunt fiierele sau bazele de date n care intr elementele descrise?;

organic: n care uniti de prelucrare vor fi utilizate elementele descrise? n plus dicionarele de date permit automatizarea operaiilor de scriere, de descriere a fiierelor sau ecranelor, de control etc. utile pentru ntreinerea i dezvoltarea dosarelor de programe. Bazele de date sunt concepute pentru a prelucra un volum mare de informaii. Gestiunea acestora impune nu numai o structurare riguroas a datelor, dar i o raionalizare a procedurilor de acces i prelucrare. Pentru a putea fi exploatat de ctre utilizatori o baz de date trebuie s aib asociat un set de programe, numit generic sistem de gestiune a bazelor de date care s permit exploatarea raional a datelor coninute. Obiectivul esenial al unui sistem de gestiune a bazelor de date este, deci, furnizarea unui mediu eficient, adaptat utilizatorilor care doresc s consulte sau s actualizeze informaiile coninute n baza de date. Sistemul de gestiune a bazelor de date reprezint un ansamblu coordonat de programe care permite descrierea, memorarea, manipularea, interogarea i tratarea datelor coninute ntr-o baz de date. El trebuie, de asemenea, s asigure securitatea i confidenialitatea datelor ntr-un mediu multi-utilizator. Principalele beneficii ale bazelor de date constau n: integrarea n aceeai structur a tuturor datelor pertinente ale unui sistem; gestionarea acestor date printr-un software specializat (SGBD); oferirea unei vederi pariale asupra ansamblului de date necesare fiecrui utilizator; asigurarea partajrii datelor ntre diferii utilizatori.
Morjon, J., Principes et conception dune base de donnes relationnelle, Les Editions dorganisation, Paris, 1992, p. 20
10

18

Niveluri de abstractizare a datelor n bazele de date Abordarea datelor n contextul bazelor de date se face pe trei niveluri, considerate niveluri de abstractizare: Nivelul intern este nivelul elementar la care pot fi considerate datele i se refer la modul n care sunt stocate datele pe suporturi - disc magnetic, band magnetic, disc optic etc. La acest nivel structura datelor este foarte detaliat. Nivelul intern cuprinde structurile de date i organizrile fiierelor utilizate pentru stocarea datelor pe dispozitivele de stocare. El trateaz probleme cum ar fi: alocarea spaiului de stocare pentru date i indexuri, descrierile nregistrrilor pentru stocare, cu dimensiunile de stocare pentru articolele de date, plasarea nregistrrilor, tehnicile de comprimare i de codificare a datelor. Nivelul intern interacioneaz cu metodele de acces al sistemului de operare (tehnici de administrare a fiierelor, pentru stocarea i regsirea nregistrrilor de date) pentru a plasa datele pe suporturile de stocare, a regsi datele, a realiza indexurile. Nivelul conceptual corespunde administratorului bazei de date care proiecteaz structura logic a bazei de date. Asigur o viziune global. a bazei de date, descriind ce date sunt stocate n baza de date i relaiile dintre acestea. La acest nivel structura bazei de date se concretizeaz n schema conceptual. Nivelul conceptual asigur att transpunerea, ct i independena dorit dintre nivelul extern i cel intern. Nivelul conceptual reprezint toate entitile, atributele i relaiile dintre ele, contrngerile asupra datelor, informaii semantice despre date, informaii privind securitatea i integritatea. Nivelul extern reprezint vederea utilizatorului asupra bazei de date ce descrie acea parte a bazei de date relevant pentru fiecare utilizator. Recurgerea la acest nivel de abstractizare se face pentru simplificarea interaciunii utilizator-baz de date. Acest nivel corespunde utilizatorilor care pot avea viziuni diferite asupra bazei de date pe baza unor subscheme proprii. Vederea extern include numai acele entiti, atribute i relaii din lumea real de care este interesat utilizatorul. Se urmrete satisfacarea cerinelor tuturor utilizatorilor n condiiile unei redundane minime i controlate a datelor. Vzut prin prisma celor trei niveluri, baza de date poate fi reprezentat ca n figura nr.2.3.11
Utilizator A1 Aplicaie Utilizator A2 Comenzi autonome Imagine A (nivel extern) INTERFAA A Schema conceptual (global) Schema extern B Utilizator B1 Aplicaie Utilizator B2 Comenzi autonome . ... .

Schema extern A

Imagine B (nivel exter n)

INTERFAA B Sistem de gestiune a bazei de date

Imagine global (nivel global) INTERFAA

Schema intern

BAZA DE DATE MEMORAT PE DISC

Fig. nr.2.3. Nivele de abstractizare a datelor n bazele de date Includerea n baza de date a descrierii structurii acesteia o deosebete calitativ de fiierele de date, deoarece prin aceasta se asigur independena datelor din baz fa de
Fotache, M., Baze de date relaionale. Organizare, interogare i normalizare, Editua Junimea, Iai, 1997, p.32
11

19

programele de aplicaii i invers. Posibilitatea modificrii structurii la un nivel, fr a afecta structura celorlalte niveluri este ntlnit sub numele de independena datelor, prezent sub dou forme:

independena fizic de date, adic posibilitatea modificrii structurii bazei de date la nivel intern (cum ar fi utilizarea unor organizri ale fiierelor sau structuri de stocare diferite, a unor dispozitive diferite de stocare, modificarea de indexuri sau de algoritmi hash), fr a fi necesar schimbarea structurii conceptuale i rescrierea programelor de prelucrare a datelor. Asemenea modificri sunt necesare pentru ameliorarea performanelor de lucru (vitez de acces, mrimea fiierelor etc.). Autonomia fizic este cea care asigur i portabilitatea bazei de date de pe un sistem de calcul pe altul fr modificarea schemei conceptuale i a programelor;

independena logic de date se refer la faptul c modificarea schemei conceptuale a bazei de date (cum ar fi adugarea sau eliminarea unor entiti, atribute sau relaii) nu necesit i modificarea schemei externe sau rescrierea programelor de aplicaii. Este important s se fac distincie ntre descrierea bazei de date i baza de date nsi. Descrierea bazei de date constituie schema bazei de date. Ea este specificat n timpul procesului de proiectare a bazei de date i este schimbat rareori. Setul de date din baza de date se numete instana bazei de date. Mai multe instane ale bazei de date pot corespunde aceleiai scheme a bazei de date. 2.1.3. Bnci de date n accepiunea cea mai larg, banca de date reprezint un set de informaii gestionate i accesate prin intermediul unor programe speciale. Informaiile, n ansamblul lor reprezint ceea ce este consacrat sub numele de baz de date, iar programele speciale constituie sistemul de gestiune a bazei de date. Banca de date reprezint un sistem de colecii de date aflate n interdependen, mpreun cu descrierea datelor i a relaiilor dintre ele i cu sistemul de programe pentru gestiunea datelor care asigur independena programelor aplicative fa de modul de structurare a datelor, o redundan minim i controlat n memorarea lor, precum i un timp minim de rspuns la solicitrile utilizatorilor.12 Ea reprezint un ansamblu de informaii organizate, nregistrate pe suporturi magnetice sau optice care pot fi consultate local sau la distan prin intermediul calculatoarelor i a reelelor de comunicaie. Deoarece permit accesul unui mare numr de utilizatori la datele stocate, bncile de date sunt considerate sisteme de documentare. Se pot organiza bnci de date n toate sferele de activitate: bnci de date bibliografice, de documentare statistic, pentru evidene financiar-contabile i bancare, diagnosticare i informare medical, pentru rezervarea tichetelor de cltorie i a locurilor n staiunile turistice etc. n unele lucrri, banca de date este redus la dou componente: baza de date i SGBD-ul asociat. Ali autori extind noiunea de banc de date, ea nglobnd baza de date, sistemul de gestiune a bazei de date, sistemul electronic de calcul, echipamentele de teleprelucrare, programele de aplicaii, sistemul de operare, utilizatorii. Schematic structura unei bnci de date poate fi prezentat ca n figura nr. 2.4.

12

Pescaru, V., .a., Fiiere, baze de date i bnci de date, Editura Tehnic, Bucureti, 1976, p. 13

20

C o l e c i i d e d a te C o l e c i i d e d a te C o l e c i i d e d a te C o l e c i i d e d a te

Fig.2.4. Structura unei bnci de date Dac n anii 70 i la nceputul anilor 80, noiunea cvasi-utilizat era cea de banc de date, n lucrrile din ultimii ani, termenul devine din ce n ce mai puin invocat, majoritatea lucrrilor de profil, ca i toi marii furnizori de software fac trimitere, aproape exclusiv, la noiunile de baz de date i SGBD. 2.1.4. Depozite de date Conceptul de depozit de date a aprut la sfritul deceniului 8, dar s-a conturat i dezvoltat n anii 90. Conceptul datawarehouse (depozit de date) este definit de William Inmon (vicepreedintele firmei Prism Solution) ca fiind o colecie de date destinate fundamentrii deciziei manageriale, colecie care este tematic, integrat, plasat ntr-un context temporal i permanent. Depozitul de date reprezint o alt direcie de dezvoltare i evoluie a bazelor de date. El desemneaz o baz de date special conceput pentru analiza datelor i suportul deciziilor, prin consolidarea tuturor datelor ntreprinderii. Deosebirile fa de o baz de date sunt urmtoarele: scopul pe care l au datele stocate - acestea nu sunt utilizate n scop operaional, ci pentru sarcini analitice, de la identificarea unui nou segment de pia pn la brainstorming; dac o baz de date este utilizat pentru prelucrarea tranzaciilor on-line, depozitele de date se bazeaz pe prelucrarea analitic on-line, o nou aplicaie strategic; dac o baz de date nregistraz i raporteaz ce s-a ntmplat, un depozit de date arat i de ce. Patru elemente determinante caracterizeaz depozitul de date: datele stocate privesc o funciune sau un proces din ntreprindere (sunt orientate pe subiect); datele sunt integrate i redefinite penteu a putea fi exploatate; informaiile sunt conservate mai muli ani, acesta reprezentnd un atu al depozitelor de date (se asigur continuitatea i comparabilitatea); datele nu pot fi modificate sau terse. Datele organizate n depozite provin din datele preluate din sistemul operaional, din datele de arhiv (n perioada de constituire a depozitului), precum din surse externe (baze de date publice, date din recensminte, date de prognoz economic etc.). Utilizarea depozitelor de date se concretizeaz n extragerea unor rapoarte (la cerere sau pe baza unui abonament cu o anumit periodicitate), extragerea unor date pentru a putea fi utilizate de aplicaiile de birotic (programe de calcul tabelar, procesoare de texte, programe de prezentare etc.), dar mai ales pentru a putea fi utilizate n aplicaii specializate de analiz.

21

Componentele unui depozit de date sunt urmtoarele:13 1. instrumente pentru modelarea datelor, asociate adesea cu instrumente de tip CASE; 2. o enciclopedie a metadatelor care pstreaz informaiile relevante despre fiecare dat a depozitului de date (ce reprezint, tipul su, unde se gsete, cum poate fi accesat, formatul su, etc.); 3. baza de date - nucleu care este centrul depozitului i ia forma bazelor de date (foarte rar a fiierelor independente); 4. instrumente pentru transpotul datelor, proiectate pentru a muta copii ale datelor din sistemul operaional n baza de date; 5. instrumentele pentru extragerea, rafinarea i standardizarea datelor, sarcini foarte dificile n condiiile n care informaiile sunt foarte complexe, iar instrumentele de lucru eterogene; 6. middleware care asigur conectivitatea n cadrul reelelor de calculatoare atunci cnd datele sunt preluate din mai multe baze de date sau o baz de date este distribuit pe mai multe noduri ale unei reele; 7. instrumente pentru accesul utilizatorilor la date i furnizarea informaiilor care cuprind instrumente de tipul interfa grafic utilizator (GUI) sau navigatoare (browsere) Web ce permit utilizatorilor s acceseze i analizeze informaiile din depozitul de date. Una din preocuparea actual a productorilor de instrumente de construire a depozitelor de date este integrarea celor apte categorii de instrumente prezentate mai sus ntrun produs atotcuprinztor, ceea ce unii au reuit ntr-o oarecare msur.14 Din punct de vedere al ariei de ntindere, se ntlnesc trei modele de depozite de date: depozite de ntreprindere, data marts i depozite virtuale. Un depozit de ntreprindere colecteaz toate informaiile despre subiecte care privesc ntreaga organizaie. El necesit cheltuieli mai mari pentru modelare i ani de zile pentru proiectare i realizare. El conine de regul date detaliate, dar i date agregate, iar ca ordin de mrime pornete de la civa gigabytes pn la sute de gigabytes, terabytes sau mai mult. Un data marts poate fi considerat un subansamblu al unui depozit de date, mai uor de construit i ntreinut i mai puiin scump. El conine un subset al volumului de date din organizaie, specific unui grup de utilizatori. Domeniul este limitat la subiecte specifice. De exemplu, un data mats pentru marketing limiteaz subiectele la clieni, articole, vnzri. Un depozit virtual este un set de viziuni (views) asupra bazelor de date operaionale. Este uor de construit, dar necesit capaciti suplimentare pe serverele de baze de date. Pentru eficiena procesrii interogrilor, numai unele din viziunile de agregare pot fi materializate. Baza de date reprezint "inima" depozitului. n practic, baza de date nucleu se poate regsi sub forma fiierelor independente de date (mai rar), poate fi o baz de date relaional sau multidimensional. n prezent se pune tot mai mult accent pe bazele de date multidimensionale care sunt concepute pentru optimizarea analizei indicatorilor (cifr de afaceri, marj) n raport cu dimensiunile care le sunt asociate (timp, produs, regiune). Ele simplific gestiunea volumelor mici sau mijlocii de date, sunt adaptate la rezolvarea unor probleme concrete (fiind utilizate mai ales pentru analize sofisticate cum ar fi simulrile sau prediciile), adaptndu-se astfel foarte bine n contexul depozitelor de date. n ceea ce privete instrumentele de analiz i acces la informaii, dou categorii, instrumentele de interogare i cele OLAP se regsesc pentru a combina accesul liber la informaii i funciile de analiz, fiind concepute pentru a rspunde nevoilor foarte diverse ale utilizatorilor finali. Astfel, anumii utilizatori sunt autonomi i doresc un acces liber la informaii fr a se ngriji de cile de acces la date. Instrumentele de tip interogare rspund nevoilor lor. Aceste instrumente favorizeaz formularea de interogri bazndu-se pe logica asamblist a bazelor de date relaionale. Ele permit, de exemplu, obinerea listei cu numele i prenumele clienilor care au cumprat un anumit produs n cursul ultimelor trei luni. Ali utilizatori exprim cerine de analiz, ceea ce necesit o informaie bine pregtit i foarte organizat. Instrumentele de tip OLAP (On-Line Analytical Processing) sunt mai bine
13 14

Fotache, M., Op. cit., p. 56 Fotache, M., Depozitul de date, n Tribuna economic nr.36 /1998, p.49

22

adaptate exigenelor lor. Prelucrarea analitic on-line este un nou instrument la dispoziia managerilor i analitilor pentru examinarea interactiv i manipularea unui volum mare de date analitice sau agregate sub diverse forme. OLAP nseamn analiza relaiilor complexe ntre mii i chiar milioane de date pentru a descoperi tendine, modele i excepii. Operaiile fundamentale n OLAP sunt consolidarea, forajul (drill down) i disecarea (slice and dice). Consolidarea nseamn agregarea datelor ce poate fi o simpl sumarizare sau o grupare complex, implicnd date aflate n legtur. Forajul este operaiunea invers i se refer la afiarea datelor detaliate, pornind de la cele consolidate. Disecarea pornete de la capacitatea OLAP de a privi o baz de date din mai multe perspective. Ea se realizeaz cel mai adesea dea lungul unei axe de timp pentru a analiza tendinele i a descoperi modele de evoluie. Ali utilizatori au nevoie de instrumente de data mining care permit structurarea informaiei fr preocuparea pentru modul n care datele sunt puse n corelaie, prin punerea n funciune a unor mecanisme de inducie. Prelucrarea analitic on-line, referit de regul ca OLAP (On Line Analytical Processing) rspunde la ntrebri pe care managerii i le pun la modul concret. Singura trstur comun a acestor ntrebri este caracterul lor multidimensional. Exist totui cteva tipuri uzuale de ntrebri, care pot arunca o lumin asupra complexitii instrumentelor care trebuie s furnizeze rspunsuri: Raporturi multidimensionale. De exemplu: Care este contribuia la vnzrile sptmnale totale a produselor informatice vndute prin magazinele situate n regiunea Moldova ntre 10 i 20 septembrie? Comparaii. De exemplu: Care este media abaterii procentuale de la planul de vnzri n lunile acestui an comparativ cu anul trecut? Clasificri i profiluri statistice. De exemplu: Care este volumul vnzrilor i media profitului pentru primii 20% dintre distribuitori i care este contribuia acestora la totalul vnzrilor pe trimestrul trecut? Agregri libere. De exemplu: Care sunt veniturile realizate n ultimele patru trimestre de filialele judeene din regiunea Moldova? Evaluri What-If. De exemplu: n ce msur ar influena profitul total o cretere cu 10 procente a vnzrilor n judeele din Moldova? Instrumentele de data mining exploreaz bazele de date i extrag din acestea o multitudine de informaii asupra tendinelor i previziunilor. Cmpul de aciune al data mining cuprinde nu numai analiza datelor, ci i a textelor. Depozitele de date nu nseamn totui numai avantaje, ci ele ridic o serie de probleme nre care menionm: dimensiunile extrem de mari la care pot ajunge, de ordinul gigaocteilor, ceea ce ridic problema suporturilor de stocare, ca i asigurarea unei viteze rezonabile de acces la date; costuri de dezvoltare foarte mari i timp ndelungat necesar pentru construirea lor; dificultatea integrrii diferitelor platforme hardware i software existente n cadrul ntreprinderii. 2.1.5. Proiectarea bazelor de date Realizarea unei baze de date presupune parcurgerea urmtoarelor etape: analiza sistemului (domeniului) pentru care se realizeaz baza de date, precum i a cerinelor informaionale asociate; proiectarea structurii bazei de date (schema conceptual, intern i extern); ncrcarea datelor n baza de date ; exploatarea i ntreinerea bazei de date15. Activitile desfurate n etapa de proiectare depind n mare msur de specificul activitii pentru care se dorete realizarea unei baze de date, dar exist i o serie de elemente cu caracter general.
vezi Lungu, I. i colab. ,Baze de date. Organizare, proiectare i implementare, Editura ALL, Bucureti, 1995, p. 26.
15

23

n literatura de specialitate se ntlnete i concepia potrivit creia proiectarea unei baze de date este un proces n doi pai16: etapa proiectrii conceptuale (independent de SGBD) - ar consta n analiza sistemului; etapa proiectrii fizice (n funcie de un anumit SGBD) - grupeaz activitile de proiectare a structurii, ncrcare, exploatare i ntreinere a bazei de date. Obiectivele proiectrii bazei de date pot fi grupate n dou categorii: 1. cerine funcionale: rapoartele (situaiile de ieire) necesare; cererile, interogrile care pot aprea; alte ieiri care ar putea fi trimise altor sisteme de prelucrare a datelor; toate actualizrile necesare; toate calculele necesare; toate restriciile sistemului (de exemplu, restricii funcionale sau restricii de comportament); toate sinonimele utilizate pentru un atribut dat; 2. restriciile fizice (volumul prelucrrilor i evaluarea performanelor): numrul, dimensiunile i frecvena rapoartelor; timpul de rspuns pentru fiecare interogare; timpul de rspuns pentru fiecare actualizare; msurile de securitate prin restricionarea accesului. Analiza preliminar i identificarea cerinelor informaionale Activitatea de analiz cuprinde trei laturi importante: analiza componentelor sistemului i a legturilor dintre acestea (analiza structural sau static)modelul structural sau static al sistemului; analiza strilor sistemului i a tranziiilor posibile ntre aceste stri (analiza comportamental sau temporal)modelul dinamic (temporal) al sistemului; analiza cerinelor informaionale, respectiv a transformrilor de date din cadrul sistemului prin care sunt satisfcute necesitile de informare ale organismului studiatmodelul funcional al sistemului; integrarea celor trei modele n scopul completrii i corelrii lor. n urma acestei analize se trece la definirea structurii bazei de date. Importana analizei preliminare pentru definirea structurii difer dup modelul de organizare a bazei de date. Astfel, pentru modelele ierarhic i reea analiza structural sau static este foarte important, pentru modelul relaional toate etapele au cam aceeai importan, iar pentru modelul OO trebuie acordat maximum de atenie analizei temporale i celei funcionale. Analiza structural sau static Aceast etap are rolul evidenierii componentelor (obiectelor) din cadrul sistemului pentru care se proiecteaz baza de date, precum i a legturilor dintre aceste componente. Se cunosc n acest sens mai multe tehnici de analiz: modelul canonic (James Martin) modelul Entitate-Asociere (Peter Chen); tehnica SDM - Semantic Data Model (Michael Hammer, Dennis McLeod) .a. Analiza dinamic (de comportament) Are drept scop explicarea comportamentului elementelor sistemului analizat. Construirea modelului dinamic presupune: identificarea strilor n care se afl componentele sistemului; identificarea evenimentelor care determin trecerea unei componente dintr-o stare n alta;
Pratt, P.J., Adamski, J.J., Database Systems. Management and Design, Boyd&Fraser, Boston, 1991, p. 285
16

24

stabilirea succesiunii evenimentelor i construirea unei diagrame care s descrie fluxul acestora (diagram a strilor de tranziie, a fluxului de evenimente). Analiza cerinelor informaionale (analiza funcional) Urmrete determinarea transformrilor pe care le suport datele n sistemul studiat, n scopul satisfacerii cerinelor informaionale aferente acestui sistem. Transformrile de date se prezint sub forma unui flux al prelucrrilor, in care nodurile reflect procesele i arcele fluxurile informaionale. Construirea modelului funcional implic o serie de etape: identificarea datelor de ieire i a celor de intrare; construirea de diagrame de flux; identificarea restriciilor pentru anumite date; precizarea unor criterii de optimizare a prelucrrilor. Integrarea modelelor sistemului n etapa de proiectare, modelele static i dinamic sunt complet independente de SGBD (aplicaiile) ce urmeaz a se folosi, pe cnd modelul funcional este orientat preponderent spre acestea. Rezultatele cercetrii din etapele anterioare sunt supuse unui proces de integrare, n urma cruia se obine o viziune de ansamblu a sistemului studiat. Cu aceast ocazie se testeaz completitudinea i consistena modelelor static i dinamic, anume dac informaiile dispun de coeren i dac nu au fost omise la analiz unele elemente informaionale. n caz de necesitate, n aceast etap se pot aduce completri modelului. Ca urmare a integrrii, dispare independena fa de aplicaii a modelelor static i dinamic, ca i orientarea spre aplicaii a modelului funcional. Este un avantaj, deoarece pe de o parte orientarea excesiv spre aplicaii complic n mod inutil modelul i-i scad adaptabilitatea, iar pe de alt parte efectuarea unei analize complet independente de aplicaii presupune un mare consum de resurse de toate tipurile.

Proiectarea structurii bazei de date n urma analizei sistemului, se obin aa-numitele modele semantice sau conceptuale, care sunt independente de instrumentul care le va pune n aplicare. Este foarte important ca analiza s nu fie tributar vreunui SGBD, deoarece: n cazul schimbrii SGBD ar fi nevoie de reproiectarea BD; caracteristicile unui anume SGBD pot limita activitatea de analiz, fcnd modelul foarte puin flexibil; dac utilizatorul final nu cunoate nimic despre un anume SGBD, este imposibil s-i formuleze cerinele de informare n mod adecvat. Spre deosebire de analiza preliminar, proiectarea structurii bazei de date impune focalizarea ateniei asupra unui SGBD. Astfel, modelul conceptual este transpus ntr-un model al datelor care are caracteristicile proprii SGBD-ului ales de proiectant. Proiectarea structurii bazei de date implic urmtoarele activiti17: alegerea SGBD utilizat pentru implementarea i exploatarea BD; proiectarea schemei conceptuale a BD; proiectarea schemei externe (subschemei) BD; proiectarea schemei interne (de memorare) a BD. Alegerea sistemului de gestiune a bazei de date n alegerea unui SGBD, se au n vedere mai multe aspecte: 1. cerinele utilizatorilor, sub aspectul: tipurilor de aplicaii; timpului de rspuns; confidenialitii i securitii datelor; uurinei n utilizare; 2. cerinele de ordin tehnic:
17

Lungu, I. i colab., Op. cit., p. 53

25

portabilitatea SGBD; portabilitatea datelor i programelor de aplicaii; condiiile de ncrcare, exploatare i ntreinere a BD; 3. cerine de ordin economic: ncadrarea n bugetul destinat acestui scop; timpul necesar pentru implementarea sistemului (inclusiv pregtirea utilizatorilor). n urma analizei acestor cerine, ca i a SGBD-urilor disponibile i a modului cum ele ofer rspuns la cerinele utilizatorilor, se decide care va fi SGBD utilizat. Proiectarea schemei conceptuale n accepiunea cea mai simpl, schema conceptual semnific descrierea datelor i a relaiilor dintre acestea. Elaborarea schemei conceptuale presupune: stabilirea coleciilor de date i a coninutului acestora; determinarea legturilor dintre coleciile de date; testarea i revizuirea eventual a schemei obinute; descrierea schemei conceptuale n maniera proprie SGBD ales. n stabilirea coleciilor de date i a legturilor dintre acestea se pornete de la entitile identificate n etapa de analiz. Astfel, n cazul unui proces economic oarecare, aceste entiti vor fi participanii la procesul n cauz. Spre exemplu, n cazul unei activiti comerciale, putem identifica la prima vedere cteva entiti: cumprtor, vnztor, marf etc. Pentru aceste entiti se vor preciza atributele sau proprietile care prezint interes pentru utilizatorii informaiei, eventual i o serie de atribute auxiliare, utilizate pentru a exprima legturi ntre entiti. Aceste entiti alctuiesc modelul semantic. Nu este obligatoriu ca fiecare component a acestui model s atrag constituirea unei colecii de date distincte. n practic, pentru mbuntirea performanelor aplicaiilor (n special optimizarea timpului de acces la date), poate opera o sporire, dar i o reducere a numrului de colecii de date proiectate iniial. n realizarea coleciilor de date se poate porni i de la documentele de ieire (cele care conin informaiile de care are nevoie utilizatorul), caz n care toate atributele identificate concur la alctuirea unui dicionar de date i urmeaz a fi grupate n funcie de anumite legturi identificabile ntre atribute. Modul de reprezentare a legturilor dintre coleciile de date identificate difer n funcie de modelul datelor pe care-l implic SGBD utilizat. Spre exemplu, pentru modelele ierarhic i reea se utilizeaz pointeri, iar pentru modelul relaional, chei externe (strine). Testarea schemei conceptuale presupune verificarea corectitudinii (a modului n care aceasta ilustreaz cerinele utilizatorilor) i consistenei acesteia (a corespondenei dintre legturile determinate i lumea real). De asemenea, trebuie ca redundana datelor s se situeze la un nivel minim. Dac n aceast etap se identific erori, se poate reveni la etapa de proiectare i uneori chiar la cea de analiz a sistemului. n ceea ce privete descrierea schemei conceptuale, aceasta comport transpunerea schemei n limbajul de manipulare a datelor specific SGBD ales. Rezultatul acestui proces l constituie schema (n accepiune CODASYL18) bazei de date. Proiectarea schemei externe Prin schem extern se nelege forma sub care un utilizator oarecare percepe schema conceptual. Prin programele de aplicaii se ofer fiecrui utilizator o viziune oarecum "compartimentat" a BD, n funcie de necesitile sale specifice (exist aici i puternice raiuni de securitate i confidenialitate a datelor). Acest mod de acces restrictiv la baza de date se materializeaz prin aa-numitele view-uri, ca i prin drepturi de acces, acolo unde SGBD-ul face posibil acest lucru. n general, elementele care compun schema extern sunt similare elementelor care compun schema conceptual. Totui, accepiunea CODASYL definete schema extern
18

abreviere de la "Conference on Data Systems Languages"

26

(subschema) ca pe o parte component a schemei conceptuale, dar care poate nregistra diferene n ceea ce privete alctuirea, fa de schema conceptual. Proiectarea schemei interne Schema intern, numit de unii autori i schem de memorare, se refer explicit la modul de memorare a datelor pe suport (purttorul de informaie). Acest mod de memorare este specific SGBD utilizat. Din punctul de vedere al utilizatorului, aceast schem nu trebuie s fie vizibil. ncrcarea datelor n baza de date Aceasta este o etap inerent proiectrii bazei de date, i const n specificarea coninutului acesteia (a datelor pe care le va memora). Dei activitatea nu este pretenioas, ea este destul de delicat, dat fiind volumul mare de date care trebuie vehiculate. Un detaliu important este acela al ncrcrii BD numai cu date corecte, scop n care sunt necesare proceduri de validare i corectare a datelor. Sursele de date pot consta ndocumente primare,colecii de date aflate deja pe suporturi (de exemplu, sisteme de fiiere), date preluate direct, fr intervenia documentelor (prin schimb electronic de date). Nu trebuie s se exagereze n direcia procedurilor de validare utilizate, deoarece productivitatea introducerii datelor poate scdea n mod drastic. Exploatarea i ntreinerea bazei de date Exploatarea bazei de date este de resortul utilizatorilor finali i implic utilizarea de ctre acetia a datelor din baza de date, n scopul satisfacerii cerinelor informaionale. Pentru aceasta, SGBD-urile dispun de limbaje de manipulare a datelor, ca i de alte instrumente specializate (mai ales cele din categoria generatoarelor). ntreinerea bazei de date implic pe de o parte operaii de actualizare (modificare a coninutului), dar i de reproiectare a structurii (aceasta din urm fiind rezervat administratorului bazei de date). Ca oricare alt sistem informatic, o baz de date poate ajunge ntr-o faz de declin, cnd ntreinerea sa devine nerentabil. n acest caz se poate decide proiectarea unei noi baze de date. 2.2 MODELE CONCEPTUALE DE STRUCTURARE I ORGANIZARE A DATELOR N BAZE DE DATE Pentru descrierea structurii datelor unei baze de date i a relaiilor dintre acestea sunt folosite procedee formale, concretizate n modele conceptuale. Acestea se particularizeaz prin terminologia utilizat i prin relaiile dintre date. Tipuri de relaii i structuri de reprezentare a relaiilor n cadrul unei baze de date Entitile aceluiai sistem informaional sunt rareori izolate unele de altele, ele antrennd, cel mai adesea, legturi sau relaii. ntre datele diverselor tipuri de entiti pot exista dou categorii de legturi sau relaii. Prima privete relaiile dintre datele aparintoare aceleiai entiti, iar a doua se refer la relaiile dintre mai multe entiti care pot fi i de tipuri diferite. La rndul lor relaiile pot fi binare i n-are. Relaiile binare presupun existena unui domeniu, a unui codomeniu i a unei corespondene ntre entitile acestora. n practica bazelor de date se utilizeaz patru tipuri de relaii binare:

1-1 (una-la-una) n care unei realizri din domeniu i corespunde o realizare i numai una din codomeniu. (Figura nr.2.5 )

27

X X
. .

1 2

Y Y
. .

1 2

D o m en iu

C o d o m en iu

Fig. 2.5 Relaia de tip 1-1

1-n (una la mai multe) n care unei realizri din domeniu i corespunde 0, una sau mai multe realizri din codomeniu. (figura nr. 2.6)
X
1

Y Y .Y Y Y

1 2 3. 4 5

D o m en iu

C o d o m en iu

Fig. 2.6 Relaii de tip 1-n

n-1 (mai-multe-la-una) n care mai multe nregistrri din domeniu corespund unei realizri din codomeniu. (Figura nr.2.7)
X X X
1

D o m en iu

C o d o m en iu

Fig. 2.7. Relaia n-1

n-m (mai-multe-la-mai-multe) n care unei realizri din domeniu i corespund 0, una sau mai multe realizri din codomeniu, iar unei realizri din codomeniu i corespund 0, una sau mai multe realizri din domeniu (figura nr. 2.8):
X
1

Y Y .Y Y

1 2 3. 4

D o m en iu

C o d o m en iu

Fig. 2.8.Relaia n-m Relaiile n-are presupun existena unei interdependene logice ntre realizrile unei mulimi de caracteristici definit pe o mulime de tupluri. Mecanismul de selecie i de identificare a componentelor unei baze de date presupune existena unei structuri de date. Concret o structur de date reprezint o colecie de date ntre care s-au stabilit anumite relaii. Structurile de date care au aceeai organizare i

28

sunt supuse prelucrrilor cu un grup de operatori de baz cu o semantic predefinit formeaz un anumit tip de structur. Principalele tipuri de structuri sunt19: punctual, liniar, arborescent, reea, relaional. Dintre acestea sunt considerate de baz structurile liniar i arborescent. Prin combinarea lor n funcie de opiunile utilizatorilor, pot fi construite i alte structuri cu grade diferite de complexitate. 2.2.2 Modele de organizare a datelor n bazele de date Un model de date este un ansamblu de instrumente conceptuale care permit descrierea datelor, a relaiilor dintre ele, a semanticii lor, ca i a restriciilor la care sunt supuse acestea. Se pot clasifica n: modele orientate pe obiect, modele orientate pe nregistrare i modele fizice. Cum ne vom ocupa doar de descrierea nivelurilor conceptual i extern, vom trata primele dou categorii de modele. Modelele orientate pe obiect se caracterizeaz prin flexibilitate i explicitate n reprezentarea structurilor de date i a restriciilor pe care trebuie s le respecte acestea. Cele mai cunoscute sunt: modelul entiti-asociaii, modelul semantic, modelul funcional i modelul orientat pe obiecte. Modelul entiti-asociaii are la baz percepia lumii reale sub forma unei colecii de obiecte, denumite entiti, unite prin intermediul unor asociaii. O entitate este un obiect care poate fi difereniat de alte obiecte printr-un ansamblu de atribute care permit descrierea precis a acestuia. O asociaie reunete dou sau mai multe entiti. De exemplu, atributele Numr i Disponibil descriu entitatea Cont la banc. Atributele Nume, Adres, etc. descriu entitatea Client. Exist o asociaie care leag un client de fiecare din conturile pe care le are deschise la banca respectiv. Ansamblul entitilor de acelai tip formeaz o clas de entiti, iar ansamblul asociaiilor de acelai gen reprezint o clas de asociaii. n reprezentarea unei structuri de baze de date cu ajutorul modelului E-R se realizeaz o diagram, care utilizeaz simbolurile: dreptunghi, pentru clase de entiti, elipse, pentru atribute, romburi, pentru clase de asociaii, linii, pentru a lega atribute de clase de entiti i clasele de entiti de clasele de asociaii. Exemplu

Adresa Furnizor Localitate Cumparare Numar

Data Valoare

FURNIZORI

FACTURI-PRIMITE

Fig. nr. 2.10. Modelul Entitate-Asociaie Modelul de date orientat spre obiecte extinde definiia unei entiti pentru a include nu numai atributele care descriu starea obiectului, ci i aciunile asociate acestuia, respectiv comportamentul. Se spune c obiectul ncapsuleaz att starea, ct i comportamentul. Modelul de date orientat pe obiecte reprezint un model logic de date care conine semantica obiectelor, acceptat n programarea orientat pe obiecte. Modelarea orientat obiect devine din ce n ce mai popular datorit abilitii de a reprezenta relaii complexe ca i de a reprezenta datele i procesarea acestora cu ajutorul unor notaii consistente. Un model al datelor este o abstractizare a lumii reale ce permite "tratarea" complexitii inerente n cazul problemelor din lumea real prin concentrarea ateniei asupra
19

Lungu, I., Op. cit., p. 6

29

caracteristicilor eseniale i interesante ale datelor de care are nevoie o organizaie. Un model orientat obiect este construit n jurul "obiectelor" tot aa cum modelul E-A are la baz entitile. Totui un obiect ncapsuleaz att datele ct i comportamentul, ceea ce permite utilizarea unei abordri orientate obiect nu doar pentru modelarea datelor, ci i pentru modelarea proceselor. Pentru a modela cu strictee o aplicaie din lumea real trebuie s se modeleze att datele, ct i procesele ce acioneaz asupra datelor. Modelarea orientat obiect asigur un mediu puternic pentru dezvoltarea unor sisteme complexe, datorit posibilitii de captare a datelor i a proceselor i datorit mai ales, motenirii i reutilizrii codului. Ciclul de via al proiectrii orientate obiect const din reprezentarea progresiv a obiectelor n cadrul a trei faze: analiz, proiectare i implementare. Acest ciclu de via este similar cu cel al dezvoltrii sistemelor. n primele etape, modelul pe care l crem este abstract, concentrndu-se asupra calitii externe a sistemului. Pe msur ce modelul evolueaz, acesta devine din ce n ce mai detaliat, atenia deplasndu-se spre cum va fi construit sistemul i mai ales, cum va funciona. Accentul n modelare trebuie pus pe analiz i proiectare, n special pe problemele conceptuale front-end, fa de problemele de implementare back-end ce restricioneaz opiunile de proiectare20. n etapa de analiz este dezvoltat un model al aplicaiei din lumea real ce reprezint proprietile sale importante. Modelul abstractizeaz concepte din domeniul aplicaiei i descrie ce anume trebuie s realizeze sistemul mai degrab dect cum va fi realizat acest lucru. Modelul specific n special comportamentul funcional al sistemului, independent de problemele legate de mediul n care va fi implementat n final. Trebuie s se aloce suficient timp pentru nelegerea clar a tuturor cerinelor problemei n discuie. Modelul de analiz capteaz aceste cerine n mod precis, concis i cu acuratee. n faza de proiectare orientat obiect se definete cum va fi realizat modelul de analiz orientat obiect n cadrul mediului de implementare. Exist trei motive pentru utilizarea proiectrii orientate obiect: 1. Modelul de analiz nu este suficient de formal pentru a fi implementat direct ntr-un limbaj de programare. Pentru a ne deplasa ctre codul surs trebuie s rafinm mai nti obiectele prin adoptarea unei decizii privind operatorii ce vor fi asigurai de un obiect, cum ar trebui s arate comunicaia ntre obiecte, ce mesaje vor fi transmise etc. 2. Sistemul actual trebuie s fie adaptat mediului n care sistemul va fi implementat. Pentru a realiza acest lucru, modelul de analiz trebuie s fie transformat ntr-un model conceptual de proiectare, lund n considerare diferii factori cum ar fi: cerinele de performan, cerinele de timp real i concuren, hardware-ul i software-ul implicat, SGBD-ul i limbajele de programare ce vor fi adoptate etc. 3. Rezultatele etapei de analiz pot fi validate cu ajutorul proiectrii orientate obiect. n acest etap putem verifica dac rezultatele furnizate de analiz sunt adecvate pentru construirea sistemului i dac este necesar s se efectueze modificri asupra modelului de analiz. Pentru dezvoltarea modelului de proiectare trebuie s fie identificate i investigate consecinele pe care le va avea mediul de implementare asupra proiectrii. Toate deciziile de proiectare strategice (cum va fi implementat SGBD-ul, cum vor fi asigurate comunicaiile ntre procese i tratarea erorilor, care componente vor fi reutilizate) vor fi adoptate i vor fi apoi ncorporate ntr-un prim model de proiectare adaptat mediului de dezvoltare. n final, modelul este formalizat pentru a descrie modul n care obiectele interacioneaz unele cu altele pentru fiecare scenariu sau caz. Rumbaugh separ activitatea de proiectare n dou etape: proiectarea sistemului i proiectarea obiectelor. La proiectarea sistemulul trebuie propus o arhitectur global a sistemului care l organizeaz n componente, numite subsisteme i asigur contextul necesar adoptrii deciziilor cum ar fi identificarea concurenei, alocarea subsistemelor pe procesoare i task-uri,

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., Object-Oriented Modelling and Design, Pretice-Hall, 1991
20

30

asigurarea accesului la resursele globale, selectarea modalitilor de implementare a controlului software etc. n etapa de proiectare a obiectelor va fi construit un model de proiectare prin adugarea unor detalii de implementare cum ar fi: restructurarea claselor pentru eficien, structurile interne de date i algoritmii pentru implementarea fiecrei clase, implementarea controlului i a asociaiilor (legturilor), precum i mprirea n module fizice n concordan cu strategia adoptat n timpul proiectrii sistemului. Clasele de obiecte specifice domeniului aplicaiei din cadrul modelului de analiz vor fi mbogite cu o serie de elemente specifice procedurilor de calcul n scopul optimizrii performanelor. Etapa de proiectare este urmat de o etap de implementare. n aceast faz, proiectul este implementat cu ajutorul unui limbaj de programare sau a unui SGBD. Translatarea proiectului n cod surs este un proces relativ uor datorit faptului c modelul de proiectare ncorporeaz deja o serie de aspecte ale limbajului de programare i SGBD-ului ales. Unele din avantajele des citate n favoarea orientrii spre obiecte sunt: Definiia unui sistem prin intermediul obiectelor faciliteaz construcia de componente software care seamn ndeaproape cu domeniul de aplicaie, contribuind astfel la proiectarea i nelegerea sistemelor; Datorit ncapsulrii i ascunderii informaiilor, ntrebuinarea obiectelor i mesajelor ncurajeaz proiectarea modular; Implementarea unui obiect nu depinde de structura intern a acestuia, ci de modul cum acesta rspunde la mesaje; ntrebuinarea claselor i a motenirii promoveaz dezvoltarea de componente reutilizabile i extensibile n contrucia de noi sisteme sau pentru actualizarea celor existente. O baz de date orientat spre obiecte este o colecie de obiecte persistente i partajabile care sunt definite de un model de date orientat pe obiecte. Un sistem SGBD orientat pe obiecte este administratorul unei baze de date orientat pe obiecte. Aspecte structurale ale modelului de date orientat pe obiecte: Obiectele sunt entiti de baz care ncorporeaz structuri de date i operaii; Fiecare obiect are un identificator unic, atribuit de sistem; Clasele descriu tipuri generice de obiecte; Conceptul de clas este strns legat de conceptul de motenire; Clasele formeaz ierarhii de clase; Definirea unei clase este mecanismul de specificare a schemei bazei de date; Schema bazei de date se poate extinde prin definirea de noi clase; Definirea unei clase poate include atribute de tipuri definite de utilizator (imagine, sunet); Se admit referiri recursive. Operaii ale modelului de date orientat pe obiecte: Obiectele comunic prin mesaje; Un mesaj poate fi trimis instanelor din mai multe clase; Metodele pot fi definite, terse sau modificate; Clasele pot fi definite, terse sau modificate; Instana unei clase poate fi actualizat prin metode ce modific valorile variabilelor propriei instane. Reguli de integritate ale modelului de date orientat pe obiecte: Obiectele trebuie s respecte caracteristicile clasei din care fac parte; Obiectele sunt ncapsulate; Un obiect nu exist fr s aib un identificator; dac obiectul este ters, se terge i identificatorul; Restricia de integritate cunoscut de la modelul relaional nu este implementat (nu exist posibilitatea de tergere n cascad).

31

Modelele orientate pe nregistrare sunt utilizate pentru reprezentarea att a structurii logice a bazei de date, ct i a coninutului acesteia. Un dezavantaj principal este absena instrumentelor prin care s se specifice restriciile datelor. Cele mai utilizate sunt: modelul relaional, modelul ierarhic i modelul reea. Modelul relaional reprezint datele i legturile dintre ele sub forma unor tabele, n care liniile i coloanele reprezint un element distinct al bazei de date. Exemplu FURNIZORI FACTURI-PRIMITE Furnizor Adresa Localitate Furnizor Numr Data Valoare Alfa Unirii 2 Iai Alfa SRL 12540 12/02/08 1259.8 SRL Beta SA Apelor 5 Bacu Beta SA 14870 14/02/08 3265 Gama Viilor 56 Iai Alfa SRL 24550 22/02/07 2987.5 SA Gama SA 18960 28/02/08 5420 Modelul ierarhic reprezint structura datelor sub forma unui arbore, alctuit din mai multe noduri; unele sunt noduri-printe, altele sunt noduri-copil. Partea superioar este rdcina. Un fiu nu poate exista independent de tatl su, iar orice fiu poate fi la rndul su tat, deci poate avea unul sau mai muli fii. Primul model utilizat pentru organizarea datelor n baze de date, modelul ierarhic se bazeaz deci pe structura arborescent i pe relaiile 1-1 i 1-n, prezentndu-se sub forma unui arbore, n care se regsesc pe un prim nivel rdcina (nodul-printe), iar pe nivele urmtoare diferite elemente subordonate (noduri-copil). Nodul-printe poate avea subordonate mai multe noduri-copil n timp ce un nod-copil poate avea un singur printe. Rezult c relaia printecopil poate fi de tip 1-n, iar relaia copil printe poate fi doar de tip 1-1. Acest model asigur organizarea datelor pe orice tip de suport magnetic i reducerea timpului de acces la nregistrri. El are ns o serie de limite n special n operaiile de actualizare cnd adugarea de noi nregistrri, cu excepia celor din colecia de date rdcin, se poate efectua numai cu specificarea coleciilor de date superioare, iar tergerea unei nregistrri duce la eliminarea fizic a tuturor nregistrrilor subordonate. n figura nr.2.11 este prezentat un exemplu de model ierarhic:

FACTURIEMISE Factura 1
Produs Produs A A Produs B

Factura 2
Produs B Produs C Produs D

Factura 3
Produs A Produs E Produs F

Fig. nr.2.11. Modelul ierarhic Modelul reea este o dezvoltare a modelului ierarhic. nregistrrile sunt privite n baza de date ca o colecie de grafuri. Modelul reea elimin redundanele specifice modelului ierarhic i se bazeaz pe structurile reea i pe relaiile de tip 1-1, 1-n i n-m. Caracteristica principal a acestui model este c accept ca orice colecie de date s se situeze pe nivelul 1, astfel fiind permis accesul direct la realizrile coleciilor superioare (operaie imposibil n modelul ierarhic). n plus, prin acest model este permis reprezentarea unic a realizrilor n baza de date. Legturile fizice pe suport sunt asigurate prin intermediul unor caracteristici care exprim pointer-ul (adresa de pe suport) a realizrii superioare sau a realizrii subordonate.

32

Astfel reeaua este un graf orientat alctuit din noduri conectate prin arce. Nodurile corespund tipurilor de nregistrare, iar arcele pointerilor. n felul acesta este permis introducerea nregistrrilor artificiale pentru a reprezenta legturile n-are (n>2)

FACTURI-EMISE Factura 1
Produs A Produs B

Factura 2
Produs C Produs D

Factura 3
Produs E Produs F

Fig. nr. 2.12. Modelul reea Dup cum se observ din figura nr. 2.12, modelul admite relaii de tip n-m, ceea ce are ca efect reducerea redundanei datelor. Modelele ierarhic i reea nu permit realizarea unei independene logice satisfctoare ntre date i programe, deoarece relaiile dintre date exist i sunt referite n programele de aplicaii. Modelul ENTITI ASOCIAII Definirea entitii este n acelai timp uoar i dificil, existnd o multitudine de opinii. Cel mai simplu, o entitate este un obiect care poate fi delimitat clar de alte obiecte. Sau: ceva ce are o existen distinct, concret sau imaginar. Pentru o organizaie, o entitate reprezint un obiect al sistemului informaional, care are existen proprie, prezint importan pentru gestiunea organizaiei i este nzestrat cu o serie de proprieti. O entitate se caracterizeaz prin: existen proprie; poate fi abstract sau concret; aparine unei familii de obiecte de aceiai natur, numit clas de entiti; fiecare entitate este identificabil i caracterizat fr ambiguitate. Clasa de entiti este deci un ansamblu de entiti care au proprieti comune. De exemplu, firma RTC este furnizor de hrtie pentru tipografia Polirom, deci RTC va fi un membru al clasei de entiti FURNIZORI pentru firma Polirom. Gruparea entitilor n clase este arbitrar, iar clasele nu sunt ntotdeauna disjuncte, ceea ce nseamn c este posibil ca o entitate care este ncadrat ntr-o clas s poat face parte simultan i din alt clas de entiti. De exemplu: dac firma RTC comand la tipografia Polirom 5000 de calendare de birou devine client al acesteia, deci RTC va fi i membru al clasei de entiti CLIENI pentru firma Polirom. Orice entitate poate fi caracterizat printr-un ansamblu de atribute. Un atribut este o proprietate comun tuturor entitilor dintr-o anumit clas. De exemplu atributele clasei FURNIZORI sunt: nume, adres, localitate, telefon, cod fiscal, etc. O entitate este legat cu una sau mai multe entiti dintr-o alt clas prin intermediul unei asociaii. O asociaie este o relaie stabilit ntre dou sau mai multe entiti care, dei nu are o existen proprie, poate fi purttoarea unor proprieti. Mai multe asociaii cu aceleai proprieti se reunesc n clase de asociaii. O clas de asociaii este o relaie definit pe una sau mai multe clase de entiti. Pentru denumirea unei clase de asociaii se alege un substantiv care reflect logica legturii dintre cele dou clase de entiti. EXEMPLU: considerm clasa FURNIZORI (cu atributele nume, localitate, cod fiscal) i clasa FACTURI-PRIMITE care reunete toate facturile primite de la furnizori, cu urmtoarele atribute: numr factur, data, valoare factur. Definim clasa de asociaii CUMPRARE pentru a lega furnizorii de facturile pe care le-au ntocmit. Ansamblul legturilor dintre cele 2 clase de entiti este ilustrat n figura 2.13.

33

2546 Alfa SRL Unirii 2 Iai R12548171 3560 Beta SA Ploii 21 Bacu R19857144 2478 1266 Gama SA Viilor 50 Iai R19874001

13/02/08 15/02/08 18/02/08 20/02/08

2365 1879 3654 1458.7 1897.1

1687 21/02/08 Fig. nr. 2.13. Modelul entitate-asociaii

Funcia care atrage o entitate ntr-o asociaie se numete rol. Clarificarea rolului fiecrei clase de entiti este esenial n proiectarea bazei de date. De exemplu, pentru clasa de asociaii CUMPRARE, rolul fiecrei entiti din clasa FURNIZORI este ntocmete, iar rolul fiecrei entiti din clasa FACTURI-PRIMITE este-ntocmit. Formularea rolului pemite identificarea unui cuplu entiti-asociaii. Pentru reprezentarea grafic a unei diagrame entiti-asociaii, n literatura de specialitate au fost propuse mai multe soluii. Una din cele mai utilizate este prezentat mai n figura nr. 2.14.

FURNIZORI Nume ntocmete Adres Localitate Cod_fiscal

CUMPRARE

FACTURI Numr este Dat ntocmit Valoare

Fig. nr. 2.14. Diagrama entitate-asociaii Metoda MERISE de proiectare a bazelor de date propune reprezentarea grafic din fig. nr. 2.15.

FURNIZORI Nume Adres Localitate Cod_fiscal

CUMPRARE

FACTURI Numr Dat Valoare

Fig. nr. 2.15. Reprezentare grafic prin metoda Merise n caracterizarea oricrei clase de asociaii se au n vedere trei elemente: dimensiunea, cardinalitatea i caracterul obligatoriu sau facultativ al asociaiei. Dimensiunea (sau ordinul) unei asociaii reprezint numrul claselor de entiti implicate ntr-o clas de asociaii. Din acest punct de vedere, exist: asociaii unare, care se stabilesc ntre entitile aceleiai clase; asociaii binare, prin care se stabilesc legturi ntre entiti din dou clase diferite; asociaii ternare, n care apar 3 clase de entiti; asociaii de ordinul n, care stabilesc relaii ntre n clase de entiti.

34

Cele mai simple, dar i cele mai utilizate sunt asociaii binare. n practic apar deseori i asociaii ternare. Cardinalitatea definete numrul de entiti dintr-o clas de care poate fi legat o entitate dat prin intermediul unei asociaii. Considernd cazul unei asociaii binare, exist patru cardinaliti posibile (vezi fig nr. 2.16 i 2.18):

x1 x2 x3 x4 TIP 1 la 1

y1 y2 y3 y4

x1 x2 x3

y1 y2 y3 y4

TIP 1 la n

Fig. nr.2.16 - cardinalitatea de tip 1 la 1, n care unei entiti din clasa X i este asociat o singur entitate din clasa Y i reciproc. Pentru exemplul clasei de asociaii CUMPRARE, ar avea o astfel de cardinalitate dac fiecare factur ar fi ntocmit de un singur furnizor (perfect adevrat) i fiecare furnizor ar ntocmi o singur factur (nerealist). - cardinalitatea de tip 1 la n, n care o entitate din clasa X poate fi asociat la n entiti din clasa Y, n timp ce fiecare entitate din clasa Y poate fi asociat unei singure entiti din clasa X. Clasa de asociaii VNZARE are o astfel de cardinalitate, pentru c pentru fiecare client se pot ntocmi mai multe facturi, dar o factur are un singur client (figura 2.17). Observaie: ntr-o diagram entiti-asociaii, cardinalitatea este reprezentat prin indicarea, n dreptul clasei de entiti a numrului maxim de asociaii la care poate participa o entitate din clasa respectiv. Un client poate fi asociat la n facturi emise, dar o factur poate fi asociat unui singur client. De remarcat c reprezentarea grafic cardinalitii se face invers fa de modul de citire al acesteia.

CLIENTI Nume Adresa Localitate Cod_fiscal

FACTURI

VANZARE

Numar Data Valoare

Fig. nr. 2.17 - cardinalitatea de tip n la 1, n care o entitate din clasa X este asociat unei singure entiti din clasa Y, iar orice entitate din Y poate fi asociat la n entiti din X. Este inversa cardinalitii de tip 1 la n. - cardinalitatea de tip n la n, n care orice entitate din X poate fi asociat mai multor entiti din Y, iar o entitate din Y este asociabil mai multor entiti din X.

35

x1 x2 x3 x4 x5 T nla 1 IP

y1 y2 y3

x1 x2 x3 x4

y1 y2 y3

T nla n IP

Fig nr .2.18 Caracterul obligatoriu sau facultativ este legat de conceptul de restricie de dependen. Dac existena entitii A din clasa X depinde de existena entitii B din clasa Y se spune c A este dependent de B. n acest caz, tergerea entitii B din BD atrage dup sine tergerea i a entitii A. Entitatea B este numit entitate dominant. n clasa de asociaii VNZARE, clasa de entiti FACTURI este dependent de clasa de entiti CLIENI, deci CLIENI este o clas dominant. n lucrrile de specialitate, restricia de dependen dintre dou clase de entiti se exprim prin sintagma clase de asociaii obligatorii sau faculative. Astfel, clasa de asociaii VNZARE este obligatorie pentru FACTURI (nu poate apare o factur emis n absena unei vnzri) i facultativ pentru clasa de entiti CLIENI. Se spune c numrul minim de asociaii din VNZARE n care poate apare o entitate din FACTURI este 1, iar numrul minim de asociaii n care poate apare un client este 0. n diagramele E-A, n dreptul fiecrei clase de entiti apare o pereche de valori: prima arat cardinalitatea minim, care este legat de caracterul obligatoriu/facultativ al clasei de asociaii pentru clasa de entiti respectiv, iar a doua valoare reprezint cardinalitatea maxim (ceea ce s-a prezentat mai sus) (vezi figura nr. 2.19).

CLIENTI Nume Adresa Localitate Cod_fiscal

FACTURI

0,n

VANZARE
Fig. nr. 2.19

1,1 Numar

Data Valoare

Diagrama din figura 2.19 poate fi interpretat astfel: fiecare entitate din clasa CLIENI poate apare n maxim n asociaii din clasa VNZARE i minim n 0 (nici una), iar fiecare entitate din clasa FACTURI poate apare n maxim 1 asociaiidin clasa VNZARE i minim 1 asociaie din aceast clas. 2.3 SISTEME DE GESTIUNE A BAZELOR DE DATE SGBD-urile reprezint un software complex care realizeaz/asigur independena, relaiile logice ntre date i o redundan minim a acestora. Ele trebuie s permit dezvoltarea rapid i la un cost avantajos a programelor de aplicaii pentru exploatarea datelor dintr-o structur complex, precum i accesul rapid la date i asigurarea securitii lor. SGBD-ul reprezint un sistem de programe care permite utilizatorului definirea, crearea i ntreinerea bazei de date i accesul controlat la aceasta. Sistemul SGBD const n elemente de software care interacioneaz cu programele aplicaie ale utilizatorului i cu baza de date. De obicei, un SGBD ofer urmtoarele faciliti

36

1. Permite utilizatorilor s defineasc baza de date, de obicei printr-un limbaj de definire

a datelor (DDL). Limbajul DDL permite utilizatorilor specificarea tipurilor de date i a structurilor, n timp ce constrngerile asupra datelor sunt stocate n baza de date 2. Permite utilizatorilor s insereze, s reactualizeze, s tearg i s extrag date din baza de date, de obicei printr-un limbaj de manipulare a datelor (DML). Faptul c exist un depozit central al tuturor datelor i descrierilor acestora permite limbajului DML s ofere o facilitate de interogare general a acestor date, denumit limbaj de interogare. Existena unui limbaj de interogare elimin dificultile sistemelor bazate pe fiiere unde utilizatorul este constrns s lucreze cu un set fix de interogri pentru a evita proliferarea de programe care creeaz probleme majore privind gestionarea acestora. Exist dou tipuri de limbaje DML - procedurale i neprocedurale care se deosebesc n funcie de operaiile de extragere. De obicei, cele procedurale trateaz baza de date nregistrare cu nregistrare, n timp ce cele neprocedurale opereaz asupra unor seturi de nregistrri. n consecin, limbajele procedurale specific cum se obine rezultatul unei instruciuni DML, iar cele neprocedurale descriu numai ce date vor fi obinute. Cel mai obinuit tip de limbaj neprocedural este limbajul structurat de interogare (SQL) care reprezint acum att limbajul standard, ct i cel de facto pentru SGBD relaionale. 3. Ofer accesul controlat la baza de date. De exemplu, poate furniza - un sistem de securitate care previne accesarea bazei de date de ctre utilizatori neautorizai - un sistem de integritate care menine concordana datelor stocate - un sistem de control al concurenei care permite accesul partajat la baza de date - un sistem de control al refacerii care restaureaz baza de date ntr-o stare precedent concordant ca urmare a unei defeciuni n hardware sau software - un catalog accesibil utilizatorilor care conine descrieri ale datelor din baza de date SGBD-ul prezint i o facilitate cunoscut sub denumirea de mecanism de vizualizare care permite fiecrui utilizator s-i defineasc propriul mod de vizualizare a bazei de date. Limbajul DML permite definirea de moduri de vizualizare n care acestea reprezint un subset al bazei de date. Avantajele SGBD - controlul redundanei datelor - coerena datelor - mai multe informaii de la aceeai cantitate de date - partajarea datelor - integritatea crescut a datelor - securitatea crescut

aplicarea standardelor economia de scal echilibru ntre cerine aflate n conflict mbuntirea accesibilitii datelor i capacitii de rspuns productivitatea crescut capacitatea de ntreinere mbuntit, prin independena de date concurena mbuntit mbuntirea serviciilor de salvare de siguran i refacere

2.3.1 Arhitectura sistemelor de gestiune a bazelor de date Teoria i practica SGBD-urilor ofer diferite arhitecturi difereniate n funcie de componentele, limbajele utilizate i posibilitile de prelucrare a datelor, existnd totui preocupri de standardizare a cestora. n general, intr n arhitectura unui SGBD cel puin 5 clase de module: programe de gestiune a bazei de date; limbajul de definire/descriere a datelor (LDD);

37

limbajul de manipulare a datelor (LMD); utilitare de ntreinere a bazei de date; componente de control a programelor de aplicaii. Programele de gestiune a bazelor de date (PGBD) Aceast clas de module realizeaz accesul fizic la date ca urmare a unei comenzi primite printr-un program de aplicaii sau interactiv prin intermediul ecranului. Limbajul de descriere a datelor (LDD) permite traducerea (compilare sau interpretare, dup caz) i descrierea naturii datelor i a legturilor lor logice fie la nivelul global (sub forma schemei conceptuale), fie la nivelul specific fiecrei aplicaii (sub forma schemei externe sau sub-schem). Limbajul de manipulare a datelor (LMD) permite gestionarea i actualizarea datelor dintr-o baz de date. Utilitare de ntreinere a bazei de date Un SGBD trebuie s ofere o gam variat de programe utilitare care s permit gestionarea de ctre un operator a bazei de date. Utilitarele variaz de la un sistem la altul i depind de complexitatea SGBD-ului. Acestea pot efectua urmtoarele operaii21: crearea versiunii iniiale a bazei de date i ncrcarea acesteia folosindu-se fie o copie creat anterior, fie date neorganizate; crearea i actualizarea jurnalelor tranzaciilor realizate asupra bazelor de date. Acest utilitar controleaz fiecare tranzacie reinnd n jurnal urmtoarele informaii: identificatorii de program, de utilizator i terminalul folosit; determinarea timpului-main; structura i coninutul bazei nainte i dup tranzacie; natura tranzaciei (sistem sau aplicaie); nscrierea datelor transmise tampoanelor SGBD-ului n jurnalul sistemului; reorganizarea bazei de date pentru recuperarea spaiului vid; reorganizarea structurii fizice i logice dup tranzacie;

restructurarea bazei de date dup un incident logic sau fizic, cu refacerea strii existente anterior acestuia. Restaurarea este determinat de existenta n cadrul SGBD-urilor a aa-numitelor puncte-de-reluare (Checkpoint)22 n cazul unor ntreruperi n exploatarea unei baze de date, reluarea exploatrii se va face nu de la nceputul bazei de date, ci de la Checkpointul precedent; diverse statistici ce permit cunoaterea activitii i utilizrii bazei de date; actualizarea schemei i sub-schemei fr rescrierea i compilarea lor; detectarea sprgtorilor regulilor de integritate definite, fr a fi necesar intrarea n baza de date; realizarea unei copii permanente a bazei de date n scopuri de securitate. Componentele de control Acestea constituie mijloace de prevenire i corectare a anumitor erori ce pot s apar n condiii multi-utilizator. Integritatea bazei de date poate fi privit din mai multe puncte de vedere: dac datele trebuie s fie modificate printr-o aplicaie, atunci secvena complet a acestei operaii trebuie protejat de orice propagare sau interferen cu alte aplicaii; dac o aplicaie efectueaz doar o citire a datelor, atunci execuia acesteia trebuie s interzic modificarea datelor astfel nct s se evite riscul invalidrii datelor citite n prealabil. Se asigur astfel blocarea actualizrii n timpul operaiei de citire;
21 22

Saleh, I., Op. cit., p. 13 Ginguay, M., Lauret, A., Dictionnaire dinformatique, Ed. Masson, Paris, 1990, p. 215

38

n cazul n care cel puin dou aplicaii acceseaz concurent aceeai dat n cadrul unei operaii de actualizare, atunci integritatea bazei de date este ameninat. Schematic structura unui SGBD pate fi prezentat ca n figura 2.20:
A d m i n i s tr a to r u l BD S tr u c tu r a B D U ti l i z a to r i P ro g ram e d e a p l i c a i i

LDD PG BD

LM D

U t. n tr e i n e r e

C o m p . c o n tr o l SG B D

B aza de d a te

Fig. 2.20. Structura general a unui SGBD 2.3.2 Funciile unui SGBD Orice SGBD trebuie s ndeplineasc urmtoarele funcii: de descriere, de manipulare, utilizare. Funcia de descriere permite definirea structurii bazei cu ajutorul limbajului special LDD, stabilind criterii de validare a datelor, metode de acces la date i de asigurare a confidenialitii i integritii datelor. Toate aceste elemente se regsesc n ceea ce se numete schema bazei de date. Execuia definiiilor limbajului se materializeaz ntr-un ansamblu de tabele, memorate ntr-un fiier special denumit dicionar de date (repertoar de date)23. Funcia de manipulare asigur prin intermediul limbajului special LMD derularea urmtoarelor activiti: ncrcarea bazei de date, adugarea de noi nregistrri, tergerea unor nregistrri, editarea total sau parial a unor nregistrri, ordonarea nregistrrilor, cutarea logic sau fizic a nregistrrilor etc. Funcia de utilizare permite comunicarea ntre utilizatori i baza de date prin intermediul unor interfee, crendu-se astfel un mediu favorabil utilizatorului care la ora actual beneficiaz de prelucrarea n timp real, arhitecturile client-server, servicii Internet etc. n cadrul realizrii acestei funcii interacioneaz diveri utilizatori, literatura de specialitate oferind mai multe clasificri sau grupri. Dintre acestea am selectat doar cteva astfel de grupri. Raportul ANSI/SPARC 1975 prezint trei categorii de utilizatori (roluri umane) ce definesc schemele dintr-o arhitectur de sistem bazat pe SGBD. persoana sau grupul de persoane care definete schema conceptual a bazei de date. Aceast schem furnizeaz o viziune pe termen lung i este baza pentru declaraiile de securitate-integritate i standardizare impuse celorlalte tipuri de utilizatori; administratorul bazei de date care are responsabilitatea definirii schemei interne a bazei de date i a ntreinerii acesteia. n acelai raport sunt prezentate trei categorii de administratori: administratorul ntreprinderii care asigur gestionarea global a aplicaiilor curente i identificarea celor viitoare; administratorul aplicaiilor care are rolul de a dezvolta schemele externe (subschemele) pentru aplicaiile utilizator;

23

Fotache, M., Op. cit., p. 37

39

administratorul de date care opereaz la nivelul schemei de date preciznd necesarul i disponibilitatea datelor; programatorii de aplicaii i utilizatorii finali care comunic cu SGBD-ul prin intermediul limbajului de manipulare sau a limbajului de interogare. ntr-o alt viziune utilizatorii pot fi structurai astfel24: 1. utilizatorii liberi sau conversaionali, reprezint beneficiarii (utilizatorii neinformaticieni) a informaiilor care nu dispun de cunotine despre structura bazei de date i nici despre sistemul de calcul pe care este implementat baza de date. n schimb au la dispoziie limbaje de interogare a bazei de date ntr-o form simplist; 2. utilizatori programatori care utilizeaz limbaje de manipulare realiznd proceduri complexe de exploatare a bazei de date. Aceti utilizatori cunosc att structura bazei de date ct i particularitile sistemului de operare, ceea ce le d posibilitatea s exploateze toate facilitile oferite de baza de date; 3. administratorul bazei de date care are cel mai important rol n funcionarea i exploatarea optim a ntregului sistem, asigurnd realizarea obiectivelor i funciilor SGBD-ului. O ultim clasificare asupra creia ne-am oprit grupeaz utilizatorii n trei mari categorii25: utilizatori finali care interacioneaz cu baza de date prin intermediul unui limbaj de interogare sau care apeleaz programe scrise de programatorii de aplicaii; programatorii de aplicaii care au rolul de a crea programele de aplicaii ale bazei de date, utiliznd limbajul de manipulare a datelor; administratorul bazei de date care este o persoan sau un grup de persoane responsabil cu controlul general al sistemului. Pe lng aceste categorii de utilizatori, bazele de date pot fi accesate fraudulos de persoane cu cunotine de specialitate care ncearc s sustrag sau s distrug informaii, provocnd daune proprietarilor bncilor de date. Aceti utilizatori sunt cunoscui sub numele de hacker-i. 2.4. Arhitecturi multiutilizator pentru sisteme de gestiune a bazelor de date Arhitecturile uzuale utilizate pentru implementarea sistemelor de gestiune a bazelor de date multiutilizator sunt teleprelucrarea, arhitectura fiier-server i client server. 2.4.1. Teleprelucrarea Prima metod de realizare a unei baze de date multiutilizator a fost teleprelucrarea la care exist un calculator cu o singur unitate central de prelucrare i un numr de terminale (figura nr. 2.21).
Program de aplicaie 1 Sistem operare (date) Baza de date

Utilizator 1 Utilizator 2

Sistem operare (control Program de comunicaii) aplicaie 2 Program de aplicaie 3

SGBD

Utilizator n

Figura nr.2.21. Sistem cu teleprelucrare

24 25

Lungu, I., .a. Op. cit., p. 19 Sabu, Ghe., Op. cit., p. 18

40

Toat procesarea este efectuat pe acelai calculator. Terminalele utilizatorilor sunt incapabile s funcioneze singure, ele fiind legate la calculatorul central. Utilizatorii transmit mesaje i date de la terminale ctre calculatorul central. Subsistemul de control al comunicaiilor din cadrul sistemului de operare primete mesajele i datele i le transmite programului de aplicaii al utilizatorului corespunztor, acesta apelnd la serviciile SGBDului. n acelai mod, mesajele sunt transmise napoi la terminalul utilizatorului. SGBD-ul utilizeaz partea de management a datelor din cadrul sistemului de operare pentru a procesa datele din baza de date. Toate comenzile din cadrul unui astfel de sistem sunt generate de calculatorul central i transmise pe canale de comunicaie, sistemul numindu-se cu teleprelucrare (tele=distan). Pe lng sarcina rulrii programelor aplicaie i a sistemului SGBD, calculatorul central trebuie s preia i o cantitate semnificativ de munc din partea terminalelor (de exemplu, formatarea datelor pentru afiarea pe ecran). Pe msur ce raportul pre/performan al calculatoarelor a crescut, tendina a fost de utilizare a altor alternative ce implic mai multe calculatoare: arhitecturile fiier - server i client - server. 2.4.2. Arhitectura fiier-server ntr-un mediu fiier-server, procesarea este distribuit n reea - de obicei o reea LAN. Arhitectura fiier-server cuprinde fiierele cerute de aplicaii i sistemul SGBD. Aplicaiile i sistemul de gestiune sunt executate pe fiecare staie de lucru, solicitnd cnd este necesar fiiere de la serverul de fiiere. Astfel, serverul de fiiere acioneaz ca o unitate de hard-disc partajat. SGBD-ul local de pe fiecare staie de lucru trebuie s cear serverului de fiiere s-i transmit toate tabelele de care are nevoie pentru a efectua interogrile. Aceast arhitectur are urmtoarele dezavantaje: 1. Exist un trafic intens pe reea; 2. Este necesar o copie complet a sistemului SGBD pe fiecare staie de lucru; 3. Controlul simultaneitii, reconstituirii i integritii este mult mai complex deoarece acelai fiier poate fi accesat de mai multe sisteme SGBD.
Utilizator 1
Program aplicaii 1

Program aplicaii 2

SGBD
Client 1

Sistem de operare (reea)

LAN

Utilizator 2

Program aplicaii 2

SGBD

Sistem de operare (reea)

Sistem de operare (reea)

Sistem de operare (date)

BD

Client 2

. . .

Server de fiiere

Program aplicaii 2

Utilizator N
Program aplicaii 3

Sistem de operare SGBD (reea)

Client N

Figura nr. 2.22. Arhitectura fiier-server

41

2.4.3. Arhitectura client/server Toate organizaiile din ziua de azi (guvernamentale, economice) i majoritatea ntreprinderilor mari i mici recunosc rolul central pe care aplicaiile software l au n cadrul lor, aplicaiile avnd rolul reducerii costurilor i mbuntirii serviciilor fa de competiie. Aceast dezvoltare i necesitatea utilizrii pe o arie mare a unor date de interes comun a dus la apariia, utilizarea i proiectarea modelului client/server, care ofer date distribuite, portabilitate ntre platforme i un acces standardizat la resurse. Termenul de client/server provine de la metoda tradiional de accesare a unui computer central numit server de ctre computere aflate la distan sau clieni ntr-o infrastructur de reea.. Modelul client/server (figura nr. 2.23) implic o entitate software (clientul) care efectueaz cereri, acestea fiind ndeplinite de o alt entitate software (serverul). Clientul este cel ce transmite o cerere server-ului, acesta o interpreteaz i apoi o efectueaz. Pentru a putea ndeplini cererea, serverul poate referi o surs de informaie (baze de date), poate s efectueze procesri asupra datelor, s controleze periferice sau s efectueze cereri adiionale altor servere. n foarte multe arhitecturi, un client poate face cereri la multiple servere i un server poate deservi mai muli clieni. Relaia ntre client i server este una de comand/control, clientul iniiaz cererea i serverul este cel care o ndeplinete, transmind rezultatul clientului, aplicaia fiind procesat prin divizarea ei ntre cele dou entiti, iar transferul de date este bidirecional. Un server nu iniializeaz niciodat un dialog cu clienii. Clientul poate funciona pe un server hardware i s efectueze cereri de la un server care ruleaz pe un alt server hardware sau pe un PC sau clientul i serverul pot funciona pe acelai computer. Spre deosebire de un sistem file/server n care datele sunt aduse de pe file server pentru a fi procesate pe o main local, n acest sistem comenzile sunt transmise asupra bazelor de date localizate pe server, rezultatul fiind transmis napoi clientului pentru a fi vizualizat. Arhitectura afecteaz toate aspectele software, ea trebuie s ia n considerare complexitatea aplicaiei, nivelul de integrare i interfaare cerut, numrul utilizatorilor, rspndirea lor geografic, natura reelelor i toate tipurile de tranzacii necesare. De asemenea, alegerea arhitecturii afecteaz timpul de dezvoltare, flexibilitatea, precum i ntreinerea aplicaiei. La majoritatea aplicaiilor end user se urmrete: prezentare, procesare i date. Arhitecturile client/server definesc cum aceste trei componente sunt mprite ntre entitile software i distribuite n reea, exist o varietate de moduri n care pot fi divizate i implementate, utilizarea unor astfel de arhitecturi putnd aduce multe beneficii firmelor, permind adaptarea la diferite standarde i tehnologii. O arhitectur client/server descrie un model de calcul pentru dezvoltarea unor sisteme automate, model ce se bazeaz pe distribuirea funciilor ntre dou tipuri independente i autonome de procese, respectiv procese server i procese client. Un client este un proces oarecare care solicit servicii specifice de la procese server, n timp ce un server este procesul care furnizeaz serviciile cerute de ctre clieni. Att procesele client, ct i cele server pot fi amplasate pe acelai calculator sau pe calculatoare diferite din cadrul unei reele, reeaua legnd serverele i clienii i asigurndu-le mediul de comunicaie. Teoretic, calculatoarele implicate pot fi mainframe-uri, minicalculatoare sau microcalculatoare. Datorit costurilor, cel mai adesea n cadrul unei arhitecturi client-server sunt implicate microcalculatoare. Cele trei componente fundamentale ale unei arhitecturi client/server sunt: Clientul, cunoscut i sub denumirea de "aplicaie front-end", datorit faptului c utilizatorii finali interacioneaz cu procesele client; Serverul, cunoscut i sub denumirea de "aplicaie back-end", datorit faptului c procesele server furnizeaz serviciile de baz sau elementare pentru procesele client; Componenta comunicaie (communication middleware) care reprezint mulimea proceselor de comunicaie ntre procesele server i procesele client, avnd rolul de supervizare a transmisiei datelor i informaiilor de control ntre servere i clieni.
42

Componenta de comunicaie este asociat ntotdeauna cu o reea de comunicaie ce asigur suportul pentru circulaia sub form de mesaje a tuturor cererilor clienilor i a rspunsurilor serverelor. n cadrul arhitecturii client/server, clienii au urmtorul rol: Asigur interfaa bazei de date cu utilizatorul; Accept i verific sintaxa intrrilor (datelor) utilizatorilor; Genereaz cererile utilizatorilor pentru baza de date i le transmite serverului; Recepioneaz rezultatele de la server; Formateaz rezultatele. Serverul are urmtorele funcii: Primete i proceseaz cererile clienilor pentru baza de date; Verific autorizarea; Garanteaz c nu sunt nclcate contrngerile de integritate; Efectueaz procesarea interogare/reactualizare i trimite clientului rspunsul; ntreine catalogul de sistem care descrie datele; Ofer acces simultan la baza de date; Asigur restaurarea i refacerea bazei de date; Optimizeaz interogarea bazei de date. Procesele client sunt procese proactive, iniiind comunicaia cu procesele server, n timp ce procesele server sunt reactive, ateptnd cererile proceselor client.
Utilizator 1
Program aplicaii 1 Sistem de

operare (reea)

Program aplicaii 2

LAN

Client 1 Sistem de operare (reea)

Utilizator 2

Program aplicaii 2

Sistem de operare (reea)

SGBD

Sistem de operare (date)

BD

Client 2 . . .

Server de BD

Program aplicaii 2

Utilizator N
Program aplicaii 3

Sistem de operare (reea)

Client N

Figura nr. 2.23. Arhitectura client-server


Un proces server poate asigura urmtoarele categorii de servicii: Servicii de fiiere pentru o reea local de calculatoare n care fiecare calculator client acceseaz discul dur al calculatorului server ca i cum ar fi un disc dur local; Servicii de imprimare n cadrul unei reele n care fiecare calculator client acceseaz imprimanta sau imprimantele calculatorului server ca i cum ar fi locale; Servicii de fax, calculatorul server fiind echipat cu o plac de fax/modem i gestionnd toate problemele legate de transmisia datelor; Servicii de baze de date - calculatorul server stocheaz datele propriu-zise i motorul sistemului de gestiune a bazelor de date, n timp ce pe calculatoarele client se gsete aplicaia front-end pentru accesarea datelor;

43

Servicii de tranzacii oferite de ctre un server de tranzacii conectat la un server de baze de date; Alte servicii, incluznd servicii audio, video, CD-ROM, backup etc. Componenta comunicaie se refer la un software cu rol special care: Este amplasat logic ntre procesele client i server; Asigur servicii specializate pentru a "ascunde" clienilor detaliile protocoalelor de comunicaie n reea i a protocoalelor propriu-zise ale serverului. Pentru a-i ndeplini funciile, software-ul de comunicaie posed urmtoarele dou

nivele: Nivelul fizic se refer la modul n care calculatoarele client i server sunt conectate fizic; Nivelul logic se ocup de comunicaia dintre procesele client i server, fiind nivelul protocoalelor de comunicaie interprocese care asigur "conversaia". Componentele unei arhitecturi client-server trebuie s se conformeze urmtoarelor principii fundamentale pentru a interaciona corect: - Independena hardware care impune ca procesele server, client i de comunicaie s funcioneze pe diferite platforme hardware fr diferene funcionale. - Independena software fa de sistemele de operare, fa de sistemele de operare n reea, fa de aplicaii care impune ca procesele server, client i de comunicaie s funcioneze n condiiile existenei unor diferite sisteme de operare, protocoale software i aplicaii, fr diferene funcionale. - Accesul liber la serviciile oferite de servere trebuie asigurat tuturor clienilor unui sistem. Aceste servicii nu trebuie s depind de locaiile clienilor sau serverelor. Un alt factor cheie este acela c serviciile sunt furnizate doar la cerere. - Distribuirea proceselor impune respectarea urmtoarelor reguli: Procesele client i server trebuie s fie entiti autonome cu funciuni bine definite, conducnd astfel la creterea modularitii i flexibilitii ntregului sistem. Maximizarea utilizrii locale a resurselor, att la nivelul clienilor, ct i la nivelul serverelor Asigurarea scalabilitii, n sensul existenei posibilitii de extensie rapid a sistemului Asigurarea interoperabilitii i integrrii. - Standardele trebuie s guverneze interfaa cu utilizatorii, accesul la date, protocoalele de reea, comunicaia interprocese. n prezent, din multitudinea de procese se remarc dou, pentru accesul la date i anume ODBC (Open Data Base Connectivity) i IDAPI (Integrated Database Application Programming Interface). Exist multe avantaje ale arhitecturii client/server: Permite un acces mai larg la bazele de date existente; Are performane crescute - dac clienii i serverul se afl pe calculatoare diferite, atunci diferite uniti centrale de prelucrare pot procesa aplicaii n paralel; reglarea serverului este mai uor de efectuat dac singura sa sarcin este de a efectua prelucrarea bazei de date; Reduce costurilor dispozitivelor hardware - numai serverul necesit o capacitate de stocare i o putere de prelucrare suficiente pentru a stoca i gestiona baza de date; Reduce costurile comunicaiilor - aplicaiile execut o parte din operaii la client care trimite prin reea numai cererea de acces la baza de date, ceea ce face ca pe reea s circule mai puine date; Mrete coerena - serverul poate trata verificrile de integritate astfel nct constrngerile trebuie definite i validate ntr-un singur loc, fr a fi necesar ca fiecare program aplicaie s execute propriile verificri. Principalul dezavantaj al arhitecturii client/server este cel legat de control. Calculatoarele client opereaz simultan i din acest motiv proceseaz aplicaiile n paralel, ceea ce determin posibilitatea apariiei unor pierderi de date la actualizri. n contextul bazelor de date, arhitectura client/server nseamn:

44

Clientul administraz interfaa cu utilizatorul i logica aplicaiei, acionnd ca o staie de lucru sofisticat pe care sunt executate aplicaiile bazei de date. Clientul preia cererea utilizatorului, verific sintaxa i genereaz cererea pentru baza de date n limbajul SQL sau n alt limbaj de baze de date, adecvat logicii aplicaiei. Pe urm transmite mesajul serverului, ateapt un rspuns i l formateaz pentru utilizatorul final. Serverul accept i proceseaz cererea pentru baza de date dup care transmite rezultatul clientului. Procesarea implic verificarea autorizrii, asigurarea integritii, ntreinerea catalogului de sistem i procese de interogare i reactualizare. n plus, se asigur controlul simultaneitii i reconstruciei. Nu putem ncheia abordarea privind bazele de date n arhitectura client/server fr s amintim de adaptabilitatea organic pentru Internet. Majoritatea serviciilor Internetului se desfoar n regim client/server (banala navigare nseamn un utilizator accesnd datele dintr-un site-server prin intermediul unei aplicaii client care este browserul de Web), astfel c devine natural implicarea SGBDR-urilor n aplicaii Internet de genul e-business sau ecommerce26. 2.5. Protecia i securitatea bazelor de date Prin protecia bazei de date se nelege un ansamblu de activiti umane i de facilitti oferite de SGBD prin care se urmrete asigurarea integritii datelor (corectitudinii datelor memorate n baza de date) i securitii datelor (restricionarea accesului la date). Cu ct aria de cuprindere a SGBD este mai vast, cu att aceste dou obiective sunt mai importante i mai dificil de realizat. Cu privire la integritatea datelor, pot s apar trei situaii practice: 1.Asigurarea integritii semantice a datelor. Obiectivul impune de fapt evitarea introducerii de date incorecte sau efectuarea unor prelucrri incorecte. Erorile trebuie sesizate la un interval de timp ct mai scurt dup apariia lor. 2.Controlul accesului concurent la date. Acesta implic evitarea obinerii de rezultate neverosimile ale prelucrrilor ca urmare a execuiei concurente a mai multor prelucrri n regim multiutilizator. 3. Salvarea i restaurarea bazei de date. n cazul funcionrii anormale a sistemului, bazele de date trebuie s poat fi readuse la starea avut nainte ca defeciunea s survin. Integritatea semantic se poate asigura att prin proceduri de validare incluse n programele de aplicaii, ct i prin instituirea unor reguli de integritate asupra bazei de date. Exist restricii de integritate implicite i explicite (acestea din urm se mai numesc i restricii de comportament). Ca restricii implicite, la modelul relaional avem integritatea entitii (se refer la valori nenule ale cheii) i integritatea referenial. Restriciile explicite de integritate (ex: nici un salariu s nu fie mai mare de 10000000 lei) pot fi definite n programele de aplicaii sau, dac SGBD o permite, pot fi memorate n dicionarul de date, sub form de proceduri stocate, declanatori etc. (avantaj considerabil). Controlul accesului concurent la baza de date n sistemele multiutilizator, sistemul de operare asigur accesul programelor la resurse dup o disciplin intern (uneori "execuie ntreesut"). ntreruperea accesului unui program la baza de date pentru a permite accesul altuia poate avea consecine grave asupra operaiunii n curs, alternd datele. Pentru controlul accesului concurent, SGBD multiutilizator opereaz cu mecanismul tranzaciilor. Tranzacia este o secven de operatii care din punctul de vedere al SGBD se constituie ca un tot unitar, acceptndu-se fie derularea ei complet, fie anularea tuturor modificrilor aduse bazei de date (derularea invers). Orice tranzacie are un punct de nceput i unul de sfrit. Tranzaciile sunt de dou tipuri: implicite, care au puncte de nceput i de sfrit automat definite (de ex., comenzile INSERT, UPDATE, DELETE din SQL);
26

Bdu, M., O perspectiv asupra bazelor de date, PC Report nr.12/1998

45

explicite, adic acelea care prezint clauze pentru stabilirea punctelor de nceput i de sfrit (BEGIN TRANSACTION, COMMIT/END TRANSACTION, ROLLBACK). Tranzaciile nu produc anomalii dac au loc de o manier succesiv (execuie serial). Cum din motive de performan execuia seriala nu este posibil pe sisteme multiutilizator, se apeleaz la tehnica blocrii pentru a asigura o execuie serializabil a tranzaciilor. n cea mai simpl form, blocarea const n interzicerea accesului altor procese la datele implicate ntr-o tranzacie, pn ce aceasta nu se finalizeaz. Blocarea poate avea loc la nivel de baz de date, fiier, grup de nregistrri, nregistrare sau chiar cmp. Totui, blocarea nu este att de restrictiv, n sensul c: se permite citirea de ctre un utilizator a datelor accesate spre citire de alt utilizator (blocare partajabil); nu se permite citirea de ctre ali utilizatori a datelor accesate n scopul actualizrii de alt utilizator (blocare exclusiv). Blocarea se realizeaz prin emiterea de ctre o tranzacii a unei cereri explicite de blocare. Accesul concurent i complexitatea mecanismului de blocare sunt influenate de granularitatea blocrii. Se intuiete uor faptul c blocarea ntregii baze de date este mai neeconomicoas dect alte tipuri de blocare, dar blocarea unui singur cmp complic foarte mult mecanismul de blocare. n practic, SGBD execut blocarea la nivel de nregistrare, grup de nregistrri sau fiier. O problem special o constituie interblocarea (deadlock), care const n blocarea de ctre dou tranzacii a anumitor resurse, apoi fiecare solicit resursele blocate de cealalt. Exist dou strategii de rezolvare a interblocrii: prevenirea interblocrii: fiecare tranzacie blocheaz de la nceput toate resursele de care are nevoie, astfel c alte tranzacii nu le vor putea accesa; cum este imposibil de cunoscut dinainte ce resurse sunt necesare, metoda are o slab aplicabilitate practic; soluionarea interblocrii: se blocheaz resursele pe msura ce tranzacia le solicit, deci interblocarea poate surveni, dar apoi se folosesc metode pentru detectarea i eliminarea sa. Pentru aceasta, sistemul poate s in evidena tranzaciilor n curs, deci a nregistrrilor accesate. Dac survine interblocarea, una dintre pri va fi victima, adic tranzacia sa va fi abandonat. Toate resursele vor fi deblocate iar utilizatorul va fi anunat despre acest lucru. Procesul ntrerupt poate fi: cel cu cele mai multe resurse blocate; cel cu cele mai putine resurse blocate; cel mai vechi; cel mai recent; cel cu cea mai mic prioritate la execuie; cel care nu a realizat nc actualizarea BD etc. Aceste precizri sunt valabile pentru calculatoarele mari, SGBD micro avnd faciliti mult mai modeste de control al tranzaciilor concurente. Salvarea i restaurarea bazei de date Aceste operaii au ca scop readucerea bazei de date n starea consistent n care se afla nainte de unele evenimente care au alterat consistena datelor, precum: funcionare anormal a SGBD-ului sau sistemului de operare, defeciune a suportului fizic pe care este memorat baza de date. O stare consistent este una n care sunt reflectate rezultatele finale ale execuiei unor tranzacii, nici o tranzacie nu este n curs de execuie i sunt satisfcute restriciile semantice necesare. Exist mai multe tehnici de restaurare. Una dintre ele const n terminarea tranzaciilor active la momentul defeciunii. Informaiile necesare restaurrii pot mbrca forma unor copii de siguran, jurnale ale tranzaciilor (succesiunea cronologic a prelucrrilor), puncte de control (checkpoints) i jurnale ale imaginilor (rezultatele prelucrrilor succesive). Restaurarea se poate face automat sau manual. Securitatea bazei de date Interzicerea accesului neautorizat la date mbrac forma unui set de msuri de protecie umane, hardware i software. Prima i cea mai simpl msur este izolarea fizic a sistemului de calcul de persoanele neautorizate (acolo unde este posibil).

46

Accesul la resursele sistemului poate avea loc prin faciliti ca parole, profile utilizator sau matrici ale drepturilor de acces (privilegii, reguli de autorizare). Utilizator Obiect Aciune Restricie U1 salariati.dbf citire sector="Personal" U2 furnizori.dbf citire, modificare, stergere U3 salariati.dbf citire sector#"TESA" Un alt mecanism este cel al schemelor externe (referite in literatura de specialitate i ca view-uri), reprezentnd acea parte a bazei de date care poate fi accesat de un anumit utilizator. De obicei, privilegiile pentru un view sunt precizate independent de cele pentru obiectele pe baza crora este definit. De asemenea, datele pot fi memorate pe suportul extern n form criptat, astfel nct citirea lor fr aplicaia proprietar (de exemplu cu ajutorul comenzilor sistemului de operare) s fie imposibil. Criptarea presupune folosirea componentelor urmtoare: cheie de criptare; algoritm de criptare; cheie de decriptare; algoritm de decriptare. Mai cunoscute sunt metodele de criptare DES (cheie privat pe 64 de bii), RSA, PGP (cheie public i cheie privat). 2.6. Administrarea datelor i a bazelor de date n prezent este larg recunoscut importana critic a gestiunii datelor n cadrul unei organizaii economice. Datele i informaiile asociate reprezint o resurs mult prea valoroas pentru a nu beneficia de o atenie sporit n ceea ce privete activitatea de administrare a lor. Administrarea ineficient a datelor duce la o slab valorificare a acestora i se poate caracteriza prin: - definiii multiple ale aceleiai entiti de date i/sau reprezentri inconsistente ale unor aceleai elemente de date n baze de date diferite, conducnd la imposibilitatea integrrii datelor - lipsa unor elemente cheie ale datelor, fapt ce determin pierderea valorii datelor pentru organizaie - nivele sczute ale calitii datelor datorate unor surse inadecvate de date sau timpilor prohibitivi de transfer de la un sistem la altul - lipsa unei familiarizri cu datele existente la dispoziie, inclusiv lipsa cunoaterii locaiilor i semnificaiilor datelor n procesele de adoptare a deciziilor strategice sau de planificare. Avnd n vedere aceste aspecte negative, majoritatea organizaiilor au creat dou funcii speciale: pentru administrarea datelor, respectiv pentru administrarea bazei de date. Administratorul datelor este custodele datelor organizaiei, fiind direct rspunztor de controlarea utilizrii i de protejarea resurselor de date. De asemenea, administratorul datelor are ca sarcini: - determinarea cerinelor organizaiei privind datele, estimarea volumului de date i a creterii probabile a acestuia - dezvoltarea unui model de date general - realizarea proiectrii conceptuale i logice a bazei de date - gestionarea dicionarului de date - soluionarea conflictelor cauzate de accesul concurent la o aceeai resurs de date (partajarea unei resurse de date) - adoptarea deciziilor privitoare la memorarea datelor - impunerea i meninerea unor definiii ale datelor i a unor standarde - mbuntirea performanelor bazei de date - asigurarea mijloacelor de instruire a utilizatorilor

47

implicarea ntr-o gam larg de activiti ca planificarea, analiza, proiectarea, implementarea i asigurarea securitii bazei de date - asigurarea unei documentaii complete care s includ modelul ntreprinderii, standardele, politicile, procedurile, utilizarea dicionarului de date i controlul asupra utilizatorilor finali - meninerea contactului cu utilzatorii pentru a determina noile cerine i a rezolva dificultile privind accesul la date sau performanele Administratorul bazei de date este implicat n proiectarea fizic a bazei de date i n implementarea efectiv a acesteia pe suporturile fizice de memorare, n impunerea standardelor de securitate i protecie, precum i n activitile de salvare i restaurare a bazei de date. Funciile generale ale administrrii datelor i bazelor de date sunt urmtoarele: - stabilirea politicilor, procedurilor i standardelor organizaiei n materie de date, ca msuri de protecie a datelor i a bazei de date - politicile datelor sunt reprezentate de o serie de specificaii care expliciteaz scopurile administrrii datelor (de exemlu, "fiecare utilizator trebuie s posede o parol" - procedurile asociate datelor sunt exprimri ale unor aciuni ce trebuie ntreprinse pentru efectuarea unor anumite activiti; de exemplu, procedurile de salvare i restaurare a datelor ce trebuie cunoscute de ctre toi utilizatorii - standardele asociate datelor sunt convenii explicite ce trebuie urmate pentru a facilita cunatificarea nivelului de calitate a datelor i a bazei de date; de exemplu, conveniile de notaie pentru obiectele componente ale unei baze de date trebuie standardizate, urmnd a fi respectate ntocmai de ctre toi programatorii de aplicaii. - planificarea ce presupune administrarea eficient a datelor i a bazei de date implic att nelegerea cu exactitate a nevoilor reale ale organizaiei, ct i abilitatea de a contribui la dezvoltarea unei arhitecturi informaionale care s satisfac nevoile organizaiei - rezolvarea conflictelor de date. Bazele de date sunt utilizate cu scopul de a fi partajate; mai mult, de regul, bazele de date implic date ce provin de la mai multe departamente din cadrul organizaiei. n acest context, administratorilor datelor i a bazelor de date le revine misiunea de a media conflictele generate de asumarea dreptului de proprietate asupra datelor din partea unor utilizatori - gestionarea depozitului intern de date al crui coninut este reprezentat de metadatele ce descriu datele i resursele de procesare a datelor unei organizaii. n prezent depozitele de date nlocuiesc dicionarele de date n majoritatea organizaiilor, constituind instrumente eseniale de sprijinire a activitilor de administrare a datelor i a bazelor de date - selectarea componentelor hadware i software. Evaluarea i selectarea componentelor hardware i software este un factor cheie n administrarea eficient a datelor unei organizaii, aspectul cel mai important fiind cel al asigurrii permanente a unei compatibiliti depline ntre componentele hardware i cele software - gestionarea aspectelor privind securitatea i confidenialitatea datelor. Scopul asigurrii proteciei i securitii datelor este de a preveni apariia unor ameninri intenionate sau accidentale la adresa integritii datelor i a accesului la date. Asigurarea proteciei datelor se concretizeaz n elaborarea i implementarea unor planuri detaliate de securitate a datelor ce includ: - politici i proceduri administrative - protecii ale datelor la nivel fizic - protecii ale sistemului de gestiune a bazei de date, ce includ: - perspective sau subscheme care restricioneaz accesul utilizatorilor reguli de autorizare care identific utilizatorii i restricioneaz aciunile pe care acetia le pot efectua asupra bazei de date -

48

proceduri definite de utilizatori ce impun restricii i limitri adiionale asupra utilizrii bazei de date proceduri de criptare ce conduc la criptarea datelor din baza de date ntr-un format neinteligibil scheme de autentificare ce identific fr ambiguitate persoanele ce intenioneaz s acceseze baza de date faciliti suplimentare de salvare, monitorizare i verificare care conduc la uurarea activitii de restaurare. asigurarea procedurilor specifice de salvare i restaurare

49

Capitolul 3. MODELUL RELAIONAL AL DATELOR 3.1. Elementele modelului relaional 3.2. Algebra relaional 3.3. Studiul dependenelor funcionale 3.4. Normalizarea bazelor de date relaionale 3.1. Elementele modelului relaional Modelul relaional a fost introdus de ctre E.F. Codd (1970), fiind un model formal de organizare conceptual a datelor, destinat reprezentri legturilor dintre date cu ajutorul teoriei matematice a relaiilor. Principalul obiectiv al modelului relaional a fost acela de a realiza o distincie clar ntre aspectele fizice i logice ale unei baze de date, cu alte cuvinte, de a asigura independena fizic a datelor. Spre deosebire de modelele anterioare de organizare a datelor (modelul ierarhic, modelul reea) care erau orientate spre fiiere i care necesitau programe specializate pentru accesarea bazei de date nregistrare cu nregistrare, la nivel fizic, modelul relaional este orientat spre mulimi de date, reprezentate conceptual cu ajutorul relaiilor, permind introducerea unor limbaje neprocedurale de manipulare a datelor. Modelul relaional al datelor este independent de sistemul de calcul implicat n organizarea, stocarea i regsirea datelor, ascunznd fa de utilizator structurile, regulile i operaiile referitoare la implementarea fizic a bazei de date. Avantajele modelului relaional au condus la larga sa acceptare de ctre comunitatea proiectanilor i programatorilor sistemelor de baze de date, fiind riguros din punct de vedere matematic i oferind un instrument performant de studiu a proprietilor i aspectelor logice ale unei aplicaii cu baze de date. Rezultatul modelrii relaionale a datelor este o schem relaional a unei baze de date, ce este constituit dintr-un set de scheme ale relaiilor mpreun cu un set de restricii de integritate asociate. Aadar, modelul relaional prezint urmtoarele caracteristici:

o relaie este o structur bidimensional de date, compus din rnduri i coloane; denumirea uzual a unei relaii este aceea de tabel sau tabel, termenul de relaie constituind fundamentul teoriei matematice a seturilor, fr a face referire la legturile dintre structuri i date; o relaie stocheaz informaii despre entitile aparinnd unei clase de entiti;

fiecare rnd al unei tabele poart denumirea de tuplu i face referire la o entitate particular din cadrul clasei de entiti;
fiecare coloan reprezint un atribut, avnd un nume distinct; numele atributului exprim, de regul, semnificaia valorilor din cadrul coloanei respective, numrul atributelor definete gradul relaiei; numrul tuplurilor dintr-o relaie reprezint cardinalitatea relaiei; la intersecia fiecrui rnd cu fiecare coloan se gsete o singur dat (o valoare atomic); fiecare tabel posed o cheie primar ce identific n mod unic fiecare rnd (tuplu); valorile unui atribut (coloane) se ncadreaz ntr-o gam de valori cunoscut sub denumirea de domeniu al atributului respectiv; un domeniu este o mulime de valori ce se poate defini fie enumernd elementele componente ale mulimii (de exemplu, mulimea culorilor), fie definind o proprietate distinct a valorilor (de exemplu, toate valorile sunt numere ntregi); n cadrul modelului relaional exist posibilitatea de a lucra i cu valori necunoscute, nedefinite sau neaplicabile, pentru aceasta introducndu-se valoarea special Null; ordinea rndurilor i coloanelor nu prezint importan pentru sistemul de gestiune a bazelor de date;

50

mulimea numelor atributelor unei relaii (coloanelor unei tabele) mpreun cu numele relaiei reprezint o schem a unei relaii.
nume relatie atribut

Obiecte-inventar Den-ob-inv. UM Etajere Scaune Cuiere Dulapuri Salopete Manusi Ochelari Birouri buc buc buc buc buc buc buc buc PU 35 95 47 450 50 1 Cantitate 12 10 5 4 14 12 10 3
schema relatiei

Cod-Furnizor Cod-ob-inv 211 202 211 237 192 213 192 211
domeniu

311 291 321 312 357 345 314 291


valoarea din domeniu

tuplu n-tupluri

1 1500

25 20

Fig. nr.3.1 Elementele modelului relaional Elementele de baz ale organizrii datelor sunt prezentate comparativ, formal, uzual sau fizic n Tabelul nr. 3.1. Tabelul 3.1 Formal Uzual Fizic relaie tabel (tabel) Fiier tuplu rnd (linie) nregistrare atribut coloan cmp Restriciile minimale de integritate (a entitii, a cheii i a referinei) sunt definite n raport cu noiunea de cheie a unei relaii. Prin supercheie se desemneaz un atribut (sau o combinaie de atribute) ce identific n mod unic un tuplu din cadrul unei relaii. O cheie candidat este o supercheie minimal, cu alte cuvinte, o supercheie ce nu conine un subset de atribute cu proprietatea de a fi el nsui supercheie a relaiei respective. Cheia primar a unei relaii este una dintre cheile candidate, selectat de ctre proiectantul sau administratorul bazei de date, pentru a identifica n mod unic toate valorile celorlalte atribute ce compun un tuplu. Cheia primar nu poate conine valori Null. Atunci cnd o cheie candidat nu este cheie primar este considerat cheie alternativ (secundar). O cheie secundar este utilizat ca index pentru a accesa tupluri. Deci, cheia primar trebuie s verifice trei restricii: unicitatea o cheie identific un singur tuplu (linie) al relaiei; compoziia minimal atunci cnd cheia primar este compus, nici un atribut din cheie nu poate fi eliminat fr distrugerea unicitii tuplului n cadrul relaiei (n cazuri limit o cheie poate fi alctuit din toate atributele relaiei); cheia primar sunt ntotdeauna specificate, deci ne-nule; nici un atribut din compoziia cheii primare nu poate avea valori nule. Legtura ntre tuplurile din relaii diferite se realizeaz prin atribute sau combinaii de atribute, numite chei strine (externe). Cheia strin a unei relaii este un atribut /combinaie

valorile non-nule valorile atributului sau ale ansamblului de atribute ce desemneaz

51

de atribute, ale crui valori sunt fie Null, fie se regsesc n mulimea valorilor cheii primare ale altei relaii. Fie, de exemplu, relaiile R1 (A, B, C, ...) i R2 (M, N, O, ..., A) n care atributele A, respectiv M, sunt cheile primare. Atributul A este cheia strin a relaiei R2. Regulile de integritate ale modelului relaional sunt urmtoarele: Regula 1: unicitatea cheii primare- cheia primar trebuie s fie minimal i s aib valori unice Regula 2: integritatea entitii - atributul/atributele ce compun cheia primar trebuie s aib valori diferite de Null Regula 3: integritatea referenial- valorile atributului /atributelor cheii strine trebuie s fie sau Null sau s fie prezente n cadrul valorilor cheii primare asociate. Descrierea unei baze de date relaionale presupune s se aib n vedere dou aspecte ale acesteia: structura (sau schema) i coninutul (sau instanierea). Coninutul unei relaii este ansamblul tuplurilor ce o alctuiesc la un moment dat. Se modific n timp. Schema poate fi definit ca un ansamblu de relaii asociate semantic prin domeniul lor de definiie i prin restricii de integritate. Este independent de timp i este componenta permanent a unei relaii. Dup C.J. Date, schema baza de date cuprinde: numele relaiilor i ale atributelor fiecrei relaii; restriciile de integritate, care sunt de trei feluri: - restriciile cheilor primare; - restricii refereniale care decurg din existena cheilor strine; - alte restricii (cum sunt cele de comportament27). Schema simplificat a unei baze de date relaionale cuprinde numele tabelelor i enumerarea atributelor acestora, atributele-cheie fiind subliniate. EX: Baza de date DESFACERE, alctuit din tabelele CLIENI i FACTURIEMISE CLIENI(Cod_client, Nume_client, Localitate, Cod_fiscal) FACTURI-EMISE(Numr_factur, Data_factur, Valoare, Cod_client) Prezentarea grafic a unei baze de date respect urmtoarele reguli: o tabel se reprezint pe dou linii, pe prima fiind scris numele tabelei, iar pe a doua numele atributelor; cheia primar este plasat prima; numele coloanelor cu atribute ce alctuiesc cheia primar se subliniaz; o restricie referenial este reprezentat printr-o sgeat care pleac de la numele coloanei de referin i are vrful la atributul corespunztor din tabela cu care intr n legtur. CLIENI Cod_client Nume_client Localitate Cod_fiscal

Numr_factur

FACTURI_EMISE Data_factur Valoare

Cod_client

Practic, ansamblul informaiilor existente n baza de date la un moment dat reprezint coninutul sau instanierea sau realizarea acesteia. Organizarea bazei de date se reflect n schema sau structura sa, aceasta fiind un ansamblu de instrumente pentru descrierea datelor, a relaiilor dintre acestea, a semanticii lor i a restriciilor la care sunt supuse. n timp se pot
Restriciile de comportament pot fi, cel mai adesea, de domeniu i temporale. Cele de domeniu impun ca valorile unui atribut s se ncadreze ntre anumite limite. Cele temporale impun ca valorile rezultate n urma actualizrii s fie altele dect cele anterioare actualizrii.
27

52

modifica att structura, ct i coninutul bazei de date, dar de regul, structura bazei de date este relativ constant pe tot parcursul utilizrii acesteia. Codd a formulat, n 1985, setul celor 13 reguli n raport cu care un sistem de gestiune a bazelor de date poate fi considerat sistem relaional, apreciindu-se, de fapt, msura n care sistemul este relaional (numrul regulilor pe care le respect). R0 Regula fundamental Un sistem de gestiune a bazelor de date relaionale trebuie s fie capabil s gestioneze o baz de date cu ajutorul facilitilor sale relaionale. R1 Regula reprezentrii La nivelul logic, toate informaiile dintr-o baz de date informaiei relaional sunt reprezentate explicit ca valori n tabele R2 Regula accesului garantat Orice valoare a oricrui atribut din cadrul oricrei la date relaii trebuie s poat fi regsit prin specificarea numelui relaiei, a numelui atributului i a valorii cheii primare. R3 Regula reprezentrii SGBD-ul asigur un suport sistematic pentru informaiei necunoscute tratamentul valorilor nule (date necunoscute sau neaplicabile), diferit de valorile prestabilite i independent de orice domeniu R4 Regula catalogului dinamic Descrierea bazei de date i a componentelor sale este on-line realizat la nivel logic sub form de tabele, putnd fi interogat n timp real prin intermediul limbajului de manipulare a bazei de date. R5 Regula limbajului de Este obligatorie existena unui limbaj de manipulare a interogare datelor cu ajutorul cruia s se poat crea relaii i vederi (perspective asupra bazei de date), s se poat actualiza i regsi date etc. R6 Regula actualizrii Este obligatorie existena unui mecanism de vederilor determinare a posibilitii de actualizare sau nu a unei tabele virtuale (vederi). R7 Regula limbajului de nivel Limbajul de manipulare a datelor nu trebuie s nalt conduc utilizatorul la explorarea relaiilor tuplu cu tuplu, pentru a regsi datele dorite. R8 Regula independenei fizice Este necesar ca aspectele fizice ale stocrii sau a datelor accesului la date s fie separate de aspectele logice (de organizare) ale datelor. R9 Regula independenei logice Este necesar ca modificrile asupra datelor s nu a datelor afecteze n nici un mod funcionarea programelor de aplicaie i nici operaiile de manipulare a datelor. R10 Regula independenei Regulile de integritate a datelor trebuie s fie definite datelor din punctul de n catalogul de sistem, independent de programele de vedere al integritii aplicaie. R11 Regula independenei Distribuirea datelor pe mai multe calculatoare din datelor din punctul de cadrul unei reele nu trebuie s afecteze programele de vedere al distribuirii aplicaie. R12 Regula de nonsubversiune Atunci cnd SGBD posed un limbaj de nivel inferior (cod-main sau de asamblare), acesta nu poate nclca regulile de integritate definite prin limbajul relaional al bazei de date n literatura de specialitate se obinuiete ca, n funcie de tipul cerinelor exprimate, regulile s fie grupate n 5 categorii: reguli de baz (fundamentale) R0 i R12; reguli structurale R1 i R6; reguli privind integritatea datelor R3 i R10; reguli privind manipularea datelor R2, R4, R5, R7;

53

reguli privind independena datelor R8, R9, R11. Avantajele modelului relaional n comparaie cu celelalte tipuri de modele sunt: independena sporit a programelor de aplicaii fa de modul de reprezentare intern a datelor i metodele de acces la date; definirea unei structuri conceptuale, optime minimiznd redundana datelor i anomaliile la actualizare (prin tehnica de normalizare); utilizarea unor limbaje procedurale, bazate pe algebra relaional, i a unor limbaje neprocedurale care contribuie la mbuntirea comunicrii dintre sistem i utilizatorii neinformaticieni; integritatea i confidenialitatea datelor, prin folosirea unor mecanisme proprii; utilizarea paralelismului n prelucrarea datelor, deoarece manipularea datelor se realizeaz numai la nivel de relaie. 3.2. Algebra relaional E.F.Codd fundamenteaz modelul relaional pe baza teoriei matematice a relaiilor i a calculului relaional. Teoria matematic a relaiilor este cunoscut sub numele de algebr relaional. Aceasta poate fi considerat ca fiind o colecie de operaii pe relaii definite ntr-o manier formal, producnd ca rezultat alte relaii. Algebra relaional lucreaz cu dou tipuri de operatori: ansambliti (reuniune, intersecie, diferen i produs cartezian); relaionali (selecie, proiecie, jonciune i diviziune). Operatori ansambliti Relaiile utilizate sunt R1 i R2. R1(A1, A2, ... An) i R2 (B1, B2, ... Bm). Prima relaie are n atribute, a doua are m atribute. Reuniunea, intersecia i diferena se pot aplica numai relaiilor unicompatibile. Relaiile R1 i R2 sunt unicompatibile dac: n = m (au acelai numr de atribute); cele n atribute ale fiecrei relaii sunt de acelai tip sintactic. Reuniunea Reuniunea este operaia ntre dou relaii R1 i R2 avnd aceeai schem deci, care sunt unicompatibile. Rezultatul va fi relaia R3 care conine ansamblul tuplurilor constituit prin reuniunea tuplurilor din relaiile R1 i R2, duplicatele fiind eliminate. Matematic, reuniunea se poate scrie R3 R1 R2 Exemplu: Considerm tebelele CLIENI1 i CLIENI2. Tabela CLIENI1 Nume_client Localitate Cod_fiscal Alfa SRL Iai R19548710 Anca SRL Iai R19852553 Omega SA Roman R17466540 Star SRL Bacu R12586330 Amigo Srl Bacu R17256007 Select SRL Lecani R17885330 Tabela CLIENI2 Nume_client Localitate Cod_fiscal Alfa SRL Iai R19548710 Gama SA Iai R19852201 Delta SRL Bacu R17256007 Omega SA Roman R17466540 Presupunem c dou firme fuzioneaz. Ambele folosesc acelai SGBD, iar structurile tabelelor au fost transformate, devenind identice. Care vor fi clienii firmei rezultate dup fuzionare? Prin reuniunea tabelelor CLIENI1 i CLIENI2 se obine tabela CLIENI_NOI:

54

Tabela CLIENI_NOI Nume_client Localitate Cod_fiscal Alfa SRL Iai R19548710 Anca SRL Iai R19852553 Omega SA Roman R17466540 Star SRL Bacu R12586330 Amigo SRL Bacu R17256007 Select SRL Lecani R17885330 Gama SA Iai R19852201 Delta SRL Bacu R17256007 Deci, CLIENI_NOI CLIENI1 CLIENI2 Din tabela CLIENI2 s-au preluat dou tupluri, deoarece celelalte exist deja n tabela CLIENI1. Se elimin, deci, dublurile. Intersecia Intersecia reprezint operaia ntre dou relaii R1 i R2 unicompatibile, rezultatul fiind o relaie R3 cu aceeai schem i care conine tuplurile comune relaiilor R1 i R2. Se scrie R3 R1 R2 Exemplu: Pornind de la aceleai tabele trebuie s rspundem la ntrebarea: Care sunt clienii comuni celor dou firme? Rspunsul l constituie tabela CLIENI_COMUNI care va arta astfel: Tabela CLIENI_COMUNI Nume_client Localitate Cod_fiscal Alfa SRL Iai R19548710 Omega SA Roman R17466540 Deci, CLIENI_COMUNI CLIENI1 CLIENI2. O tabel rezultat prin intersecia a dou tabele va conine numai acele tupluri care prezint valori identice pentru toate atributele. Diferena Diferena este operaia ntre dou relaii R1 i R2 unicompatibile (care au aceeai schem), obinndu-se relaia R3 cu aceeai schem i care conine ansamblul realizrilor constituit din tuplurile relaiei R1 care difer de cele existente n relaia R2. Se scrie R3 R1 R2 Exemplu: Care sunt clienii pe care i are numai prima firm? Rspunsul va fi tabela NUMAI_CLIENI1, obinut prin diferena ntre cele dou tabele, astfel: Tabela NUMAI_CLIENI1 Nume_client Localitate Cod_fiscal Anca SRL Iai R19852553 Star SRL Bacu R12586330 Amigo SRL Bacu R17256007 Select SRL Lecani R17885330 NUMAI_CLIENI1 CLIENI1 CLIENI2 Diferena presupune deci eliminarea tuplurilor comune celor dou relaii, tabela rezultat reinnd doar tuplurile primei relaii, care nu sunt i n relaia a doua. Produsul cartezian Produsul cartezian este operaia ntre dou relaii R1 i R2 ce are ca rezultat o relaie R3 a crei schem se obine prin juxtapunerea schemelor relaiilor R1 i R2. Relaia R3 cuprinde toate combinaiile n-uplurilor din relaiile R1 i R2.

55

Se noteaz R3 R1 x R2 Exemplu: Considerm tabela CLIENI2 de mai sus i tabela FACTURI. Tabela FACTURI Nr_factur Data Nume_client Val_factur 12540 12/02/08 Delta SRL 2300.08 15780 15/02/08 Gama SA 2564 47100 17/02/08 Delta SRL 8790 Produsul cartezian al celor dou tabele va avea ca rezultat tabela Facturi_Clieni, care va arta astfel: FACTURI_CLIENI CLIENI2 x FACTURI Tabela FACTURI_CLIENI Clieni2. Clieni2 Clieni2. Facturi. Facturi. Facturi. Facturi. Nume_client Localitate Cod_fiscal Nr_factur Data Nume_client Val_factur Alfa SRL Iai R19548710 12540 12/02/08 Delta SRL 2300.08 Alfa SRL Iai R19548710 15780 15/02/08 Gama SA 2564 Alfa SRL Iai R19548710 47100 17/02/08 Delta SRL 8790 Gama SA Iai R19852201 12540 12/02/08 Delta SRL 2300.08 Gama SA Iai R19852201 15780 15/02/08 Gama SA 2564 Gama SA Iai R19852201 47100 17/02/08 Delta SA 8790 Delta SRL Bacu R17256007 12540 12/02/08 Delta SRL 2300.08 Delta SRL Bacu R17256007 15780 15/02/08 Gama SA 2564 Delta SRL Bacu R17256007 47100 17/02/08 Delta SRL 8790 Omega SA Roman R17466540 12540 12/02/08 Delta SRL 2300.08 Omega SA Roman R17466540 15780 15/02/08 Gama SA 2564 Omega SA Roman R17466540 47100 17/02/08 Delta SRL 8790 Dup cum se observ, prima linie a tabelei rezultat este combinaia (concatenarea) ntre prima linie a tabelei CLIENI2 i prima linie a tabelei FACTURI, a doua este combinaia ntre prima linie din CLIENI2 cu a doua din FACTURI .a.m.d. Cum tabela Clieni2 are patru linii, iar tabela Facturi are trei linii, tabela rezultat prin produsul cartezian va avea 4 x 3, adic 12 linii. Firesc, se ridic problema utilitii acestei operaii. Practic, produsul cartezian nu este utilizat niciodat direct, exist ns operatori algebrici care deriv sau se bazeaz pe acesta. Operatori relaionali Operatorii relaionali se mpart n: operatori unari de restricie (selecia i proiecia); operatori binari de extensie (jonciunea i diviziunea).

Selecia Selecia (restricia) este operaia pe o relaie R1 care produce o nou relaie R2 cu aceeai schem i n care tuplurile verific o condiie exprimat explicit. Practic prin selecie se elimin/suprim realizrile (liniile) care nu satisfac condiia impus. Prin urmare cardinalitatea noii relaii R2 va fi mai mic sau cel mult egal cu cardinalitatea relaiei R1. Se noteaz R2 Selecie (R1, <expresie - logic>) R2 este tabela rezultat care va ave aceeai schem ca i R1. Exemplu: Considerm tabelele CLIENI1 i FACTURI. 1. Care sunt clienii cu sediul n Iai? Rspunsul se obine prin aplicarea operatorului SELECIE asupra relaiei CLIENI. Tabela rezultat va conine doar tuplurile care prezint valoarea atributului Localitate egal cu irul de caractere Iai Se scrie R2 SELECIE(CLIENI, Localitate = Iai)

56

Tabela R2 va arta astfel: Nume_client Localitate Cod_fiscal

Alfa SRL Iai R19548710 Anca SRL Iai R19852553 2. Care sunt facturile cu valoare mai mare de 50000000 lei? Rspunsul se obine prin aplicarea operatorului SELECIE asupra relaiei FACTURI. Tabela rezultat va conine doar tuplurile care au valoarea atributului Val_factur este mai mare de 50000000. Se scrie R2 SELECIE (FACTURI, Val_factur > 50000000) Tabela R2 va arta astfel: Nr_factur Data Nume_client Val_factur 47100 17/02/08 Delta SRL 87900000 Proiecia Proiecia (decupajul vertical) reprezint o operaie pe o singur relaie R1 i are ca rezultat o relaie R2 redus la atributele menionate explicit n operanzi. Tuplurile din relaia R2 sunt unice. Prin proiecie se trece la o relaie de grad inferior relaiei R1. Se noteaz R2 Proiecie (R1; Atribut1, Atribut2, ..., Atributn) sau R2 R1 (Atribut1, Atribut2,...) R2 este tabela rezultat, a crei schem va fi diferit de a tabelei R1, fiind format doar din atributele specificate. Dac nu exist tupluri identice, ea va avea acelai numr de linii ca i tabela R1. Exemplu: 1) Care sunt localitile n care firma are clieni? RR1 PROIECIE (CLIENI, Localitate) 2) Care sunt numele clienilor firmei? RR2 CLIENI (Nume_client) RR1 Localitate Iai Roman Bacu Lecani n tabela RR1 au fost eliminate valorile identice ale atributului Localitate. RR2 Nume_client Alfa SRL Anca SRL Omega SRL Star SRL Amigo SRL Select SRL n tabela RR2 numrul de linii este identic cu cel al tabelei CLIENI. Jonciunea Jonciunea (Join sau Theta-jonciune) reprezint o operaie ntre dou relaii R1 i R2 care are ca rezultat o relaie R3 cu o schem obinut prin concatenarea schemelor primelor dou. Coninutul relaiei l reprezint ansamblul tuplurilor obinute prin concatenarea tuplurilor din R1 i R2 care verific o condiie stabilit ntre atributele celor dou relaii. Condiia se construiete cu ajutorul operatorilor: < .> . > = . < = . .

57

Considerm relaiile R1 (A1, A2, ... , An) i R2 B1, B2, ..., Bm). Ai i Bj sunt dou atribute definite pe acelai domeniu i mulimea operatorilor pentru comparaii ce pot fi aplicai celor dou atribute. Jonciunea relaiei R1, prin Ai cu relaia R2, prin Bj, notat: R1 (Ai Bj) R2 este relaia R3 ale crei tupluri sunt obinute prin concatenarea fiecrui tuplu al relaiei R1 cu tuplurile relaiei R2 pentru care este adevrat condiia instituit ntre Ai i Bj. Jonciunea este echivalenta unui produs cartezian urmat de o selecie. n lucrul cu bazele de date relaionale se utilizeaz cu precdere echijonciunea, care este un caz particular al theta-jonciunii, n care se utilizeaz operatorul de egalitate. Echijonciunea se reprezint astfel: R3 ECHIJONCIUNE (R1, R2, Ai = Bj) Exemplu: Considerm tabelele CLIENI i FACTURI. Proprietatea comun a celor dou relaii este Cod_client, care este cheie primar n tabela CLIENI i cheie strin n tabela FACTURI. Tabela CLIENI Cod_client 1000 1001 1002 1003 Nume_client Alfa SRL Gama SA Delta SRL Omega SA Localitate Iai Iai Bacu Roman Cod_client 1001 1001 1002 1000 Valoare_factur 2300.08 2564 1256 8790

Tabela FACTURI Nr_factur Data_factur 12540 12/02/08 15780 15/02/08 21630 10/02/08 47100 17/02/08

Echijonciunea este reprezentat astfel: R3 ECHI-JONCIUNE (CLIENI, FACTURI; CLIENI.Cod_client = FACTURI. Cod_client) La execuia jonciunii, n prima etap se calculeaz produsul cartezian al tabelelor CLIENI i FACTURI, iar n pasul al doilea se opereaz selecia, care elimin tuplurile care nu ndeplinesc condiia de selecie (sunt reinui doar clienii care au emis facturi). Rezultatul jonciunii este prezentat n tabela de mai jos. Clieni. Clieni Clieni. Facturi. Facturi. Facturi. Facturi. Cod_client Nume_client Localitate Nr_factur Data_factur Cod_client Valoare_factur 1000 Alfa SRL Iai 47100 17/02/08 1000 8790 1001 Gama SA Iai 12540 12/02/08 1001 2300.08 1001 Gama Sa Iai 15780 15/02/08 1001 2564 1002 Delta SRL Bacu 21 630 10/02/08 1002 1256 Adesea numele atributului comun este identic n ambele tabele astfel c se impune specificarea numelui tabelei (nume tabel nume atribut). Aceast jonciune, n care numele atributelor sunt identice n ambele tabele se numete jonciune natural. Este cea mai utilizat i o vom nota astfel: R3 JONCIUNE (CLIENI, FACTURI, Cod_client) Diviziunea Este cel mai complex dintre operatorii algebrei relaionale. n definire se pornete de la dou relaii: R1(X,Y) i R2(Y). R1 are dou atribute sau grupe de atribute, iar R2 are un singur atribut sau grup de atribute Y, definit pe acelai domeniu ca i n R1.

58

Diviziunea relaional R1 R2 are ca rezultat o relaie R3(X), defnit ca ansamblul subtuplurilor R1(X) pentru care produsul lor cartezian cu R2(Y) este un ansamblu al R1(X,Y). xi R3 dac i numai dac yi Y R2 (xi, yi) R1 Se noteaz R3 R1 R2 Tabela R1 se numete demprit,iar tabela R2 se numete divizor. Pentru exemplificare vom considera X i Y atribute i nu grupe de atribute. R1 X X1 X3 X5 X1 X2 X3 X4 X1 X5 X3 X2 X4 Y y1 y1 y1 y2 y2 y2 y2 y3 y3 y3 y3 y3

R2 Y Y1 Y2 Y3 Determinarea relaiei R3 prin diviziune este sinonim cu rezolvarea problemei. Care dintre x1, x2, x3, x4, x5 apar n R1, n tupluri(linii) mpreun cu toate tuplurile din R2 (y1, y2, y3)? Se parcurg pe rnd valorile xi ale atributului X din tabela R1 i se constat c y1 i x3 apar n tupluri cu toate valorile atributului Y din R2, deci tabela R3 va fi: R3 X X1 X3 Diviziunea nu este un operator fundamental, funcionalitatea sa este obinut prin combinarea operatorilor produs cartezian, diferen i proiecie.

3.3. Studiul dependenelor funcionale Dependenele dintre atribute Normalizarea se bazeaz pe conceptul de dependen dintre atributele bazei de date. Exist trei tipuri de dependene: funcional, multivaloare i de jonciune. Dependena funcional reprezint o generalizare a conceptului de cheie primar. Considerm dou atribute sau grupe de atribute ale unei relaii: Data1 i Data2. Se spune c Data2 este n dependen funcional cu Data1 atunci cnd cunoaterea unei valori pentru Data1 permite cunoaterea a maximum o valoare pentru Data2. Data1 se numete sursa dependenei funcionale, iar Data2 este destinaia dependenei funcionale. Se noteaz Data1 Data2.

59

Formal, considerm relaia R{A1, A2, ..., An} i dou grupe de atribute X i Y. Se spune c exist o dependen funcional ntre X i Y, dac: fiecare valoare a lui X poate fi asociat unei singure valori a lui Y; dou valori identice ale lui X nu pot fi asociate dect aceleiai valori a lui Y. Se noteaz: X Y Se consider tabela FACTURI. FACTURI Numr_factur Data_ factur Cod_client Val_factur n tabela FACTURI, elementul cheie este Numr_factur. Dac este cunoscut, atunci vom afla i data facturii, clientul pentru care s-a ntocmit i valoarea ei. Deci, Numr_factur Data_factur Numr_factur Cod_client Numr_factur Val_factur Implicit, n orice relaie R exist dependenele funcionale: cheia primar a lui R celelalte atribute ale lui R Dependenele funcionale care prezint la surs dou sau mai multe atribute sunt dependene funcionale cu surs compus. Dependene funcionale elementare (totale) i pariale Dependena funcional Data1 Data2 este elementar dac nu exist nici un subansamblu al lui Data1 (Data3) care s verifice dependena funcional Data3 Data2. Implicit, toate dependenele n care sursa este simpl (format dintr-un atribut) sunt dependene funcionale elementare. Considerm urmtoarea relaie (FACT_CL): Nr_fact Data Cod_cl Nume_cl Strada Localitate Jude Cod_post Valoare n tabela FACT_CL, dependen funcional elementar este: Cod_post Strada Problema apare la dependenele funcionale cu sursa compus. n tabela FACT_CL avem: (Numr_factur, Cod_cl) Valoare care este o dependen funcional elementar. Dependenele: (Numr_factur, Cod_cl) Nume_cl (Numr_factur, Cod_cl) Localitate nu sunt elementare pentru c o parte a sursei este la rndul su surs pentru alte dependene funcionale: Cod_cl Nume_cl Cod_cl Localitate Dependena funcional elementar se mai numete total sau deplin. Dependene funcionale directe i tranzitive O dependen funcional Data1 Data2 este direct atunci cnd nu exist Data3 care angajeaz o dependen funcional tranzitiv de genul Data1 Data3 Data2. n relaia FACT_CL, avem dependena funcional Cod_post Strada. Codul potal este unic pentru fiecare strad, deci dependena de mai sus este funcional i direct. Dependena Cod_cl Strada este funcional, dar nu este direct, ci tranzitiv datorit dependenei funcionale de mai sus. Avem: Cod_cl Cod_post Strada. Dependenele multivaloare i de jonciune sunt mai dificil de explicat i identificat dect cele funcionale. Multe lucrri nu le prezint, considernd c primele trei forme normale i forma Boyce Codd, care se bazeaz pe dependenele funcionale elementare i directe sunt suficiente pentru majoritatea cazurilor practice.

60

Fie relaia R{A1, A2, ..., An} i X, Y i Z trei subansamble ale ansamblului {A1, A2, ..., An}. Exist o dependen multivaloare ntre grupurile de atribute X i Y ale relaiei R dac i numai dac: la fiecare valoare a lui X poate fi asociat una sau mai multe valori ale lui Y; aceast asociaie nu depinde de valorile lui Z. Considerm o relaie R{A1, A2, ..., Ai} i N subansamble de atribute X1, X2, ..., XN. Se spune c exist o dependen de jonciune de ordinul N ntre X1, X2, ..., XN dac i numai dac R este jonciunea proieciilor sale pe X1, X2, ..., XN. Dac N=2, avem de-a face cu o dependen multivaloare.

3.4. Normalizarea bazelor de date relaionale Necesitatea normalizrii Normalizarea unei relaii const n reprezentarea acesteia sub o form canonic, respectnd anumite criterii de definire semantic a structurii bazei de date, precum i integritatea datelor28. Uzual, prin normalizare se desemneaz procesul de stabilire a structurii tabelelor unei baze de date relaionale, a cheilor primare, a cheilor strine i a altor restricii. Prin normalizare se ajunge la o optimizare a bazei de date, urmrindu-se: Eliminarea anomaliilor de actualizare; Diminuarea nevoii de reorganizare periodic a modelului; Reprezentarea diverselor conexiuni dintre atributele bazei; Utilizarea unor algoritmi eficieni privind cutarea tuplurilor care ndeplinesc anumite condiii specificate (interogarea bazei de date). nscris de obicei n activitile de analiz i proiectare ale bazelor de date, normalizarea a constituit obiectul a numeroase studii; nu se poate afirma c exist o unanimitate de idei i instrumente. Pe de alt parte, importana normalizrii nu trebuie absolutizat. Fragmentarea tabelelor n altele mai simple are n vedere i optimizarea vitezei de acces, reducerea traficului pe reea etc. n plus, preocupri de dat mai recent vizeaz nglobarea, n normalizare, a unor concepte privind gestiunea domeniilor atributelor i extinderea sa ctre tehnologia obiectual. Prin normalizare, o relaie este descompus reversibil, obinndu-se o schem relaional optim. Exist dou tipuri de algoritmi pentru obinerea relaiilor normalizate: descompunerea - este un procedeu pas cu pas, de trecere dintr-o form normalizat n alta; sinteza - opereaz cu un graf complet de dependene funcionale. Normalizarea are ca scop asigurarea echilibrului ntre obinerea unui volum maxim de informaii ntr-un timp ct mai scurt, pe de o parte i eliminarea anomaliilor de stocare i actualizare, pe de alt parte. Gruparea tuturor atributelor unei baze de date ntr-o singur tabel (aa-numita relaie universal) atrage serioase probleme privind redundana datelor i anomalii la adugarea, modificarea i tergerea unor linii. Nr_factura 10540 10541 10542 10543 10544 10545 10546
28

Data 10/02/08 10/02/08 11/02/08 12/02/08 12/02/08 12/02/08 12/02/08

Nume_client Delta SRL Gama SA Delta SRL Alfa SRL Diana SRL Popa SNC Omega SRL

Localitate Iai Iai Iai Vaslui Pacani Iai Bacu

Cod_fiscal R19548710 R19848451 R19548710 R19852201 R19674531 R12323432 R17256007

Val_factura 2300.08 2564 8790 4356.08 3564 1790 1300.08

Filip, M., Grama, A., Medii de programare. Abordri teoretice, Ed. Fides, Iai, 1998, p.204

61

10547 13/02/08 Iulius SRL Iai R19456700 3564 10548 14/02/08 Toni SRL Bacu R18790654 3650 10549 14/02/08 Anca SRL Roman R17466540 4100.080 10550 15/02/08 Select SA Bacu R13666589 3864 10551 15/02/08 Anca SRL Roman R17466540 3290 Acest lucru se observ din exemplul de mai sus - este aa-numita redundan logic. Anomaliile de stocare apar, de exemplu, n cazul n care un client i schimb codul fiscal sau sediul, caz n care trebuie s modificm toate liniile pe care apare clientul respectiv i nu o singur dat, cum ar fi logic. n consecin, este necesar fragmentarea bazei n mai multe tabele care vor fi legate prin restricii de integritate referenial. Este important modul n care se realizeaz acest lucru, pentru a nu se pierde informaii, pe de o parte, iar pe de alt parte dac va rezulta un numr mare de tabele, acestea vor fi dificil de controlat, n ceea ce privete respectarea restriciilor. Deci, obiectivul normalizrii poate fi formulat astfel: minimizarea redundanei, eliminarea pierderilor de informaii i asigurarea unei viteze optime de acces la date. Formele normale ale unei baze de date relaionale Teoria clasic a normalizrii este construit n jurul a cinci forme normalizate. Codd, printele modelului relaional de organizare a datelor, a definit iniial trei forme normalizate 29, notate cu 1FN, 2FN i 3FN. ntruct, ntr-o prim formulare, definiia 3FN ridica ceva probleme, Codd i Boyce au elaborat o nou variant, cunoscut sub numele Boyce-Codd Normal Form (BCNF). Dei este vorba, n principiu, de o formulare mai riguroas a aceleiai 3FN, BCNF este prezentat, n majoritatea lucrrilor, separat. Formele 4 i 5, care sunt legate de numele lui Fagin, sunt tratate mai cu reinere n literatura consacrat analizei bazelor de date relaionale. Ba chiar unele lucrri, cu tent mai pragmatic, se opresc, declarat, la 3FN pe care o consider suficient n rezolvarea majoritii cazurilor practice. Fundamentul normalizrii bazelor de date relaionale l constituie dependenele dintre atribute. Primele trei forme normalizate pot fi determinate pe baza dependenelor funcionale elementare (totale) i tranzitive. Forma a patra (4FN) se bazeaz pe dependenele multivaloare, n timp ce a cincea form normalizat (5FN) pe dependenele de jonciune. n practic, dependena multivaloare, dar mai ales cea de jonciune sunt rare i dificil de identificat. Ierarhia dintre formele normale i legtura cu dependenele dintre atribute este prezentat n fig. nr. 3.2.30.
1F N 2F N 3F N BCNF 4F N 5F N DM V DJ DF

Fig. nr. 3.2. Ierarhia formelor normale Prima form normal (1FN) O relaie se afl n 1FN dac fiecare atribut al su conine o valoare atomic (sau atributele sunt nedecompozabile).
Codd, E.F., Further normalization of the database relational model, DataBase Systems, Courant Computer Science Symposia Series, Vol.6, Englewood Cliffs, N.J.,Prentice-Hall, 1972 30 Filip, M., Grama, A., Op. cit., p.205
29

62

n relaia FACT_CL prezentat anterior toate atributele sunt atomice. Deci, relaia FACT_CL este n 1FN. A doua form normal (2FN) ncepnd din a doua form normal, relaiile pot fi decupate n sub-relaii n scopul diminurii problemelor legate de stocare i actualizare. n 1971, Heath a demonstrat c orice relaie care are cel puin trei atribute, notat R(X, Y, Z), n care exist dependenele funcionale XY i XZ, poate fi descompus n dou relaii R1(X, Y) i R2(X, Z). R1 i R2 reprezint proieciile relaiei R pe atributele X, Y i, respectiv, X, Z. Descompunerea se face fr pierderi de informaii, adic R poate fi recompus prin jonciunea tabelelor R1 i R2. O relaie se afl n 2FN dac: se afl n 1FN; toate dependenele funcionale care leag cheia primar de celelalte atribute sunt dependene funcionale elementare. Deci, normalizarea relaiilor 1FN la forma 2FN presupune eliminarea dependenelor pariale. n exemplul de mai sus, cheia primar a relaiei FACT_CL este perechea (Nr_fact, Cod_cl). Exist urmtoarele dependene funcionale: (1) (Nr_fact, Cod_cl) Data (2) (Nr_fact, Cod_cl) Nume_client (3) (Nr_fact, Cod_cl) Localitate (4) (Nr_fact, Cod_cl) Strada (5) (Nr_fact, Cod_cl) Jude (6) (Nr_fact, Cod_cl) Cod_post (7) (Nr_fact, Cod_cl) Valoare Dependenele funcionale (2), (3), (4) (5) i (6) nu sunt elementare datorit existenei dependenelor: (8) Cod_cl Nume_client (9) Cod_cl Localitate (10) Cod_cl Strada (11) Cod_cl Judet (12) Cod_cl Cod_post Aducerea relaiei n 2FN presupune parcurgerea a trei pai: identificarea dependenelor elementare, inclusiv cele tranzitive - cele de la (1) la (7); identificarea dependenelor care au ca surs un atribut din cheia primar - (8) la (12); pentru fiecare atribut al cheii (precizat n pasul 2) se creeaz o relaie care va avea drept identificator primar atributul respectiv, iar celelalte atribute vor fi cele care apar ca destinaii n dependenele de la pasul 2. n cazul nostru, relaia FACT_CL se fragmenteaz n dou tabele - FACT i CL: FACT Nr_fact Data Cod_cl Val CL Localitate

Cod_cl

Nume_client

Strada

Jude

Cod_post

A treia form normal (3FN) O relaie se afl n 3FN dac: se gsete n 2FN; toate atributele care nu aparin cheii primare nu depind funcional de un alt atribut care nu face parte din cheie.

63

Pentru trecerea n 3FN se parcurg urmtorii pai: se identific toate atributele ne-cheie i care sunt surse ale unor dependene funcionale; pentru fiecare atribut ne-cheie care este surs de dependene funcionale se constituie cte o relaie n care cheie primar va fi atributul respectiv, iar celelalte atribute vor fi destinaiile din dependenele funcionale. Relaia FACT este n 3FN pentru c nu este nici o dependen funcional ntre un atribut necheie i celelalte atribute. n relaia CL, exist dependenele funcionale: Cod_post Strad Cod_post Localitate Cod_post Jude Cod_post este un atribut ne-cheie, surs n dependene funcionale cu Strada, Localitate i Jude. Tabela CL se descompune n tabelele CLIENI i CODP, astfel: CLIENTI Nume_client

Cod_cl

Cod_post

Cod_post

Strada

CODP Localitate

Jude

n 3FN, relaia FACT_CL de la care am pornit se prezint sub forma a trei relaii: FACT, CLIENTI, CODP Forma normal Boyce-Codd n practic pot apare cazuri n care 3FN s nu fie suficient. O relaie este n BCFN dac: se afl n 3FN; nu exist nici o dependen funcional a crei surs s fie un atribut necheie, iar destinaia un atribut din cheie. ntr-o alt formulare, o relaie este n BCFN dac i numai dac orice determinant este o cheie-candidat (atunci cnd ntr-o relaie exist mai multe combinaii de atribute care identific tuplul n mod unic, acestea se numesc chei candidate). Un determinant este orice atribut de care depinde funcional un alt atribut al relaiei. Un determinant este deci o surs de dependene funcionale. A patra form normal (4FN) O relaie este n 4FN dac: este n BCFN; nu exist dependene multivaloare n cadrul relaiei. Altfel spus, o relaie este n 4 FN dac este n BCFN i toate dependenele care se manifest n cadrul su sunt funcionale. A cincea form normal (5FN) O relaie este n 5FN dac i numai dac toate dependenele de jonciune sunt ntre cheile candidate ale lui R. 5FN este o generalizare a lui 4FN, care este o generalizare a lui BCFN.

64

4.1. 4.2. 4.3. 4.4.

Capitolul 4. LIMBAJE DE INTEROGARE A BAZELOR DE DATE SQL SQL - Evoluie i performane Comenzi pentru descrierea datelor; Comenzi pentru interogarea bazelor de date Comenyi pentru actualizarea bazei de date

4.1. Evoluie i performane SQL reprezint cel mai important limbaj actual n domeniul bazelor de date prin gama comenzilor i opiunilor de care dispune, dar mai ales datorit faptului c s-a reuit standardizarea lui i portarea pe toate sistemele de gestiune a bazelor de date semnificative. nc din anul 1970, E.F.Codd a sugerat "adoptarea unui model relaional pentru organizarea datelor [...] care s permit punerea la punct a unui sub-limbaj universal pentru gestiunea acestora, sub-limbaj care s fie, n fapt, o form aplicat de calcul asupra predicatelor". Dup muli autori, momentul decisiv n naterea SQL ca limbaj l constituie lansarea proiectului System/R de ctre firma IBM, eveniment ce a avut loc n 1974. Tot n 1974 Chamberlin i Boyce au publicat un articol n care este prezentat un limbaj structurat de interogare, denumit SEQUEL (Structured English as QUEry Language). n 1975 Chamberlin, Boyce, King i Hammer redacteaz o lucrare dedicat sub-limbajului SQUARE, asemntor SEQUEL-ului, dar care utiliza expresii matematice i nu cuvinte din limba englez. Autorii celor dou studii au demonstrat c limbajele SEQUEL i SQUARE sunt complete din punct de vedere relaional. n 1976 un colectiv de autori condus de Chamberlin elaboreaz o nou lucrare n care se face referire la SEQUEL 2, acesta fiind declarat limbaj de interogare al SGBD-ului System/R al firmei IBM. n 1980 Chamberlin schimb denumirea SEQUEL n SQL - Structured Query Language (Limbaj Structurat de Interogare), din motive legale (s-a descoperit c acronimul SEQUEL fusese utilizat anterior de altcineva), dar i astzi muli specialiti pronun SQL ca pe predecesorul su. Anii urmtori au nregistrat apariia a o serie ntreag de lucrri dedicate SQL care lau perfecionat i consacrat ca pe cel mai rspndit limbaj de interogare a bazelor de date relaionale, fiind prezent n numeroase "dialecte" specifice tuturor SGBDR-urilor actuale, de la DB2 la Microsoft SQL Server, de la Oracle la FoxPro i Access. ncercnd s rspund solicitrilor pentru standardizarea unui limbaj de lucru cu bazele de date, Institutul Naional American pentru Standarde (American National Standard Institute - ANSI) a nceput s realizeze n 1982 un limbaj relaional pentru bazele de date, bazat pe un articol conceptual al firmei IBM. n 1986 ANSI public standardul SQL ANSI X3.135-1986, standard care se bazeaz, ntr-o mare msur, pe "dialectul" SQL al produsului DB2 de la IBM. Organizaia Internaional pentru Standarde (ISO) a adoptat propriul document, aproape identic cu ANSI SQL-86, pe care l-a publicat n 1987 ca ISO 9075-1987 Database Language SQL. SQL-86 definete comenzile de baz ale SQL, inclusiv pentru crearea de tabele i tabele virtuale (CREATE TABLE, CREATE VIEW), ns nu conine opiuni de modificare a structurii sau tergere (ALTER/DROP) i nici comenzi pentru acordare i revocare a drepturilor utilizatorilor. n 1989 are loc revizuirea i extinderea acestui standard, "nscndu-se" SQL-89, care mai este denumit i SQL-1. Dei recunoscut ca baz a multor SGBDR-uri comerciale, SQL-1 i-a atras numeroase critici. n plus, variantele comercializate de diferiii productori, dei asemntoare n esen, erau (i sunt) incompatibile la nivel de detaliu. Pentru a umple golurile SQL-1, ANSI i ISO au elaborat n 1992 versiunea SQL-2, specificaiile fiind prezentate la un nivel mult mai detaliat (dac SQL-1 se ntindea pe numai 100 de pagini, SQL-2 a fost publicat n aproape 600). Dintre numeroasele faciliti aduse de SQL-92 amintim: jonciunea extern (OUTER JOIN), atribute zi-or i de alte tipuri, raportare

65

standardizat a erorilor, modificarea schemei bazei de date (DROP, ALTER, REVOKE, GRANT), SQL dinamic, modificri i tergeri refereniale n cascad, amnarea verificrii restriciilor, niveluri de consisten a tranzaciilor etc. Pe lng ANSI, ale crui standarde au cea mai larg audien, mai exist i alte organisme de standardizare SQL. X/Open este un grup de firme vest-europene care a adoptat SQL ca nucleu al unei ntregi serii de standarde menite s asigure realizarea unui mediu general pentru aplicaii portabile, grefat pe sistemul de operare UNIX. IBM a avut un aport incontestabil la apariia i maturizarea SQL, fiind un productor cu mare influen n lumea SGBD-urilor, iar produsul su, DB2, este unul din standardele de facto ale SQL. n 1989 un grup de productori de instrumente dedicate bazelor de date au format SQL Access Group, n vederea realizrii conexiunilor dintre SGBDR-urile fiecruia, pe baza unor specificaii comune, din care un prim set a fost publicat n 1991 sub titulatura RDA (Remote Database Access). Specificaiile RDA n-au reuit s se impun pe piaa SGBDurilor. La insistenele firmei Microsoft, SQL Access Group i-a concentrat eforturile pentru elaborarea unei interfee-standard pentru SQL. Pe baza unui set de propuneri naintat de Microsoft, n 1992 au rezultat specificaiile CLI (Call Level Interface). Acestea reprezint un ansamblu de funcii i proceduri pentru conectarea bazelor de date prin SQL n medii multiutilizator i multi-platform. Avnd drept reper CLI, Microsoft elaboreaz i implementeaz n acelai an un set propriu, ODBC (Open DataBase Conectivity), care a devenit standard n materie de interfa SQL pentru microcalculatoare compatibile IBM PC n vederea accesrii bazelor de date relaionale. Standardul SQL:1999, denumit iniial SQL3, are ca principale orientri: transformarea acestuia ntr-un limbaj complet, n vederea definirii i gestionrii obiectelor complexe i persistente. Aceasta include: generalizare i specializare, moteniri multiple, polimorfism, ncapsulare, tipuri de date definite de utilizator, triggere i proceduri stocate, suport pentru sisteme bazate pe gestiunea cunotinelor, expresii privind interogri recursive i instrumente adecvate de administrare a datelor. Standardul SQL:2003 are drept caracteristici majore: caracteristici legate de XML, funcii window, secvene standardizate i coloane cu valori auto-generate (incluznd coloaneidentitate). Standardul SQL:2006 definete ci prin care SQL poate fi utilizat mpreun cu XML, ci de a importa i stoca date XML ntr-o baz de date SQL, de a le manipula n cadrul acelei baze de date i de a le publica. Din punctul de vedere al utilizatorului final, obiectivul principal al SQL const n a oferi utilizatorului mijloacele necesare formulrii unei consultri numai prin descrierea rezultatului dorit, cu ajutorul unei expresii logice, fr a fi necesar i explicitarea modului efectiv n care se face cutarea n baza de date. Altfel spus, utilizatorul specific rezultatul, iar sistemul se ocup de procedura de cutare. Dei este considerat, n primul rnd, un limbaj de interogare, SQL este mult mai mult dect un instrument de consultare a bazelor de date, deoarece permite, n egal msur: definirea datelor; consultarea bazei de date; manipularea datelor din baz; controlul accesului; partajarea bazei ntre mai muli utilizatori ai acesteia; meninerea integritii bazei de date. Dup Groff i Weinberg, principalele atuuri ale SQL sunt: Independena de productor, nefiind o tehnologie proprietar; Portabilitate ntre diferite sisteme de operare; Este standardizat; "Filosofia" sa se bazeaz pe modelul relaional de organizare a datelor; Este un limbaj de nivel nalt, cu o structur care se apropie de limba englez;
66

Furnizeaz rspunsuri la numeroase interogri simple, ad-hoc, neprevzute iniial; Constituie suportul programatic pentru accesul la baza de date; Permite multiple imagini asupra datelor bazei; Este un limbaj relaional complet; Permite definirea dinamic a datelor, n sensul modificrii structurii bazei chiar n timp ce o parte din utilizatori sunt conectai la baza de date; Constituie un excelent suport pentru implementarea arhitecturilor client-server. Limbajul SQL constituie un exemplu de limbaj orientat spre tansformri sau limbaj proiectat s utilizeze relaiile pentru a transforma intrrile n ieirile cerute. Ca limbaj, SQL are dou componente principale: - un limbaj de definire a datelor pentru definirea structurii bazei de date (DDL) - un limbaj de manipulare a datelor (DML) pentru regsirea i reactualizarea datelor. Limbajul SQL conine numai comenzi de definire i manipulare i nu conine comenzi de flux de control. Cu alte cuvinte nu exist comenzi IFTHENELSE, GO TO, DO WHILE sau alte comenzi care s ofere un flux de control. Acestea trebuie implementate prin utilizarea unui limbaj de programare sau de control al lucrrilor sau interactiv prin decizii ale utilizatorului. Datorit acestui fapt, limbajul SQL poate fi utilizat n dou moduri. Prima modalitate este de a folosi limbajul SQL interactiv, prin introducerea instruciunilor de la un terminal. A doua este de a integra instruciunile SQL ntr-un limbaj procedural. SQL este un limbaj relativ uor de nvat: Este un limbaj neprocedural - se specific ce informaii sunt cerute i nu cum sunt obinute (limbajul SQL nu necesit specificarea metodelor de acces la date). SQL este un limbaj modern, cu format liber, ceea ce nseamn c nu este necesar ca fragmentele de comenzi s fie scrise n anumite locuri de pe ecran. Totui o comand (sau un set de comenzi SQL) este mai lizibil dac se folosete indentarea i alinierea. De exemplu: - fiecare clauz din cadrul unei comenzi trebuie s nceap pe o linie nou; - nceputul fiecrei clauze trebuie s fie aliniat cu nceputul celorlalte; - dac o clauz are mai multe pri, fiecare dintre ele trebuie s apar pe cte o linie separat i trebuie s fie indentat fa de nceputul clauzei pentru a indica relaia. Structura comenzilor const n cuvinte standard din limba englez, cum ar fi CREATE TABLE, INSERT; SELECT. Limbajul SQL poate fi folosit de o gam larg de utilizatori, inclusiv administratorii de baze de date, programatorii de aplicaii i alte tipuri de utilizatori. SQL este primul i deocamdat singurul limbaj de baze de date standardizat care se bucur de o acceptare larg. Cele mai multe "dialecte" SQL admit urmtoarele tipuri de date: SMALLINT: ntregi - scurte (4 poziii, reprezentate pe 16 bii), INTEGER sau INT: ntregi - lungi (9 poziii, 32 bii), NUMERIC(m,n) sau DECIMAL(m,n) sau DEC(m,n) - reale, cu un total de m poziii, din care n la partea fracionar, FLOAT: reale, virgul mobil (20 poziii pentru mantis), REAL : real, virgul mobil DOUBLE PRECISION: reale, virgul mobil, dubl precizie (30 poziii pentru mantis), CHAR(n) sau CHARACTER(n): ir de caractere de lungime n (max. 240), VARCHAR(n) sau CHAR VARYING(n) sau CHARACTER VARYING(n): ir de caractere de lungime variabil (max. 254), DATE: dat calendaristic TIME: ora

67

dintr-o secund. Principalele comenzi ale SQL, care se regsesc, ntr-o form sau alta, n multe dintre SGBDR-urile actuale sunt urmtoarele:

TIMESTAMP: an, lun, zi, ora, minutul, secunda, plus o fraciune zecimal

Tabelul nr. 4.1. Clase de comenzi SQL Comand Pentru manipularea datelor SELECT INSERT DELETE UPDATE Pentru definirea bazei de date CREATE TABLE DROP TABLE ALTER TABLE CREATE VIEW DROP VIEW Scop Extragerea datelor din baza de date Adugarea de noi linii ntr-o tabel tegerea de linii dintr-o tabel Modificarea valorilor unor atribute Adugarea unei noi tabele n baza de date tergerea unei tabele din baz Modificarea structurii unei tabele Crearea unei tabele virtuale tergerea unei tabele virtuale

Pentru controlul accesului la BD GRANT Acordarea unor drepturi pentru utilizatori Revocarea unor drepturi pentru utilizatori REVOKE Pentru controlul tranzaciilor Marcheaz sfritul unei tranzacii COMMIT ROLLBACK Abandoneaz tranzacia n curs

4.2. Comenzi pentru descrierea datelor Comanda SQL utilizat pentru crearea unei tabele este CREATE TABLE. Aceasta creeaz o tabel vid (fr linii), cu o anumit structur. CLIENI CodClient 1001 1002 1003 1004 1005 1006 1007 1008 NumeClient TEXTILA SA MODERN SRL OCCO SRL FILATURA SA INTEGRATA SA AMI SRL AXON SRL ALFA SRL Adresa Bld. Copou, 87 Bld. Grii, 22 NULL Bld. Unirii, 145 I.V.Viteazu, 115 Galaiului, 72 Silvestru, 2 Prosperitii, 15 Localitate Iai Focani Iai Focani Pacani Bacu Iai Pacani

FACTURIEMISE NrFactur CodClient 111111 1003 111112 1001 111113 1004 111114 1003 111115 1008 111116 1008

DataFactur 17.06. 2008 17.06.2008 18.06.2008 18.06.2008 18.06.2008 19.06.2008

ValoareTotal TVAColectat 1700 271.42 285 45.5 585 93.4 2850 455.04 3570 570 870 138.9

68

111117 111118 111119 111120 111121 111122 111123 111124 111125 111126

1006 1007 1005 1003 1001 1007 1006 1004 1003 1002

20.06.2008 1100 23.06.2008 1500 24.06.2008 4725 24.06.2008 300 24.06.2008 425 24.06.2008 875 25.06.2008 660 25.06.2008 3850 30.06.2008 1280 01.07.2008 5425 Fig. nr. 4.1. Baza de date utilizat n exemple

175.63 239.49 754.41 47.89 67.85 139.7 105.3 614.7 204.37 866.17

De exemplu, pentru crearea tabelei CLIENI, comanda se scrie astfel: CREATE TABLE CLIENI (CodClient decimal (7) not NULL, NumeClient char(25) not NULL, Adresa char(30), Localitate char(25), PRIMARY KEY (CodClient)) Atributul CodClient este de tip numeric, valoarea sa fiind reprezentat pe apte poziii. Celelalte atribute conin iruri de caractere. Valorile pentru CodClient i NumeClient sunt diferite de NULL. Cheia primar a relaiei este atributul CodClient. Exist posibilitatea adugrii ulterioare a unui nou atribut la cele existente, tergerii unui atribut sau de modificare a tipului sau lungimii sale. Operaiunea nu este att de frecvent, fiind recomandabil s se desfoare ct mai rar; o bun analiz desfurat n faza de proiectare a bazei de date elimin, de obicei, acest gen de probleme. Dac n tabela CLIENI se dorete pstrarea i a codului fiscal al fiecrui furnizor, este necesar adugarea atributului CodFiscal, care este un ir de caractere (un numr precedat de litera R, dac clientul respectiv este pltitor de TVA) de lungime 10 caractere. Comanda utilizat este ALTER TABLE, astfel: ALTER TABLE CLIENI ADD CodFiscal char(10) SQL permite declararea cheilor primare, candidate i a coloanelor de referin (chei strine). Dac stabilim c, pentru tabela CLIENI, cheia primar este atributul CodClient, iar atributul NumeClient este cheie candidat, comanda se poate scrie sub forma: CREATE TABLE CLIENI (CodClient decimal (7) not NULL, NumeClient char(25) not NULL, Adresa char(30), Localitate char(25) , PRIMARY KEY (CodClient) UNIQUE (NumeClient)) Cheile strine sunt declarate cu ajutorul opiunii FOREIGN KEY. Pentru tabela FACTURIEMISE, cheia primar este atributul NrFactur, n timp ce CodClient este cheie strin ctre tabela CLIENI: CREATE TABLE FACTURIEMISE (NrFactur decimal (8) not NULL, DataFactur date, CodClient decimal (7) not NULL, ValoareTotala decimal (15) not NULL, TVAColectata decimal (14) , PRIMARY KEY (NrFactur), FOREIGN KEY (CodClient) REFERENCES CLIENI)

69

tergerea unei tabele din baza de date este realizabil cu ajutorul comenzii DROP TABLE. De obicei, aceast comand se utilizeaz atunci cnd pe parcursul lucrului s-au creat tabele intermediare, temporare. tergerea unei asemenea tabele, denumit de exemplu TEMP1, se declaneaz prin comanda: DROP TABLE TEMP1 4.3. Comenzi pentru interogarea bazelor de date. Fraza Select n SQL o interogare se formuleaz printr-o fraz SELECT. Aceasta prezint trei clauze principale: SELECT, FROM i WHERE. SELECT corespunde operatorului proiecie din algebra relaional, fiind utilizat pentru desemnarea listei de atribute (coloanele) din tabela-rezultat; FROM este cea care permite enumerarea relaiilor din care vor fi extrase informaiile aferente consultrii; prin WHERE se desemneaz predicatul selectiv al algebrei relaionale, relativ la atribute ale relaiilor care apar n clauza FROM. La modul general (i simplist) o consultare simpl n SQL poate fi prezentat astfel: SELECT C1, C2, ..., Cn FROM R1, R2, ..., Rm WHERE P Execuia unei fraze SELECT se conc1retizeaz n obinerea unei tabele (relaii) rezultat. Acest poate fi o tabel propriu-zis sau o tabel temporar (care, de obicei, nu poate fi actualizat), dar i o tabel derivat (imagine). Uneori tabela rezultat poate fi obinut sub forma unei variabile-tablou. Ci - reprezint coloanele (care sunt atribute sau expresii de atribute) tabelei-rezultat; Rj - sunt relaiile ce trebuie parcurse pentru obinerea rezultatului; P - este predicatul (condiia) simplu sau compus ce trebuie ndeplinit de tupluri pentru a fi incluse n tabela-rezultat. Cnd clauza WHERE este omis, se consider implicit c predicatul P are valoarea logic "adevrat". Dac n locul coloanelor C1, C2, ... Cn apare simbolul "*", n tabela-rezultat vor fi incluse toate coloanele (atributele) din toate relaiile specificate n clauza FROM. De asemenea, n tabela-rezultat, nu este obligatoriu ca atributele s prezinte nume identic cu cel din tabela enumerat n clauza FROM. Schimbarea numelui se realizeaz prin opiunea AS . Rezultatul unei fraze SELECT l vom considera ca fiind sub forma unei tabele oarecare. Trebuie avute n vedere, ns, c rezultatul interogrii poate fi obinut i sub forma unei tabele temporare sau chiar a unei variabile-tablou (matrice). n unele SGBD-uri, cum ar fi FoxPro, formatul general al frazei SELECT conine i clauza INTO. SELECT FROM INTO destinaie WHERE n destinaie poate fi specificat o tabel "normal", o tabel temporar (tabel care se terge automat la nchiderea sa) sau o variabil-tablou. Dac clauza INTO nu este utilizat, atunci n urma interogrii se obine o tabel temporar cu numele predeterminat (Query). Uneori, tabela rezultat ("normal" sau temporar) "ncalc" poruncile modelului relaional. Conform restriciei de entitate, ntr-o relaie nu pot exista dou linii identice. Or, n SQL, tabela obinut dintr-o consultare poate conine dou sau mai multe tupluri identice. Spre deosebire de algebra relaional, n SQL nu se elimin automat tuplurile identice (dublurile) din tabela-rezultat. Pentru aceasta este necesar utilizarea opiunii DISTINCT: SELECT DISTINCT C1, C2, ..., Cn FROM R1, R2, ..., Rm WHERE P n concluzie, o fraz SELECT, n forma n care a fost prezentat, corespunde: unei selecii algebrice (clauza WHERE - P)
70

i conduce la obinerea unei noi relaii (tabele-rezultat) cu n coloane, fiecare coloan fiind: un atribut din R1, R2, ..., Rm sau o expresie calculat pe baza unor atribute din R1, R2, ..., Rm.

unei proiecii (SELECT - Ci) unui produs cartezian (FROM - R1 R2 ... Rm)

Exemplu Care este, pentru fiecare factur emis, valoarea fr TVA ? SELECT NrFactur, ValoareTotal - TVAColectata AS ValoareFaraTVA FROM FACTURIEMISE Tabela rezultat din fig. nr. 4.2 va conine dou atribute: NrFactur i ValoareFaraTVA. Ultimul este un cmp calculat. Rezultat: NrFactur ValoareFaraTVA 111111 1428.58 111112 239.50 111113 491.6 111114 2394.96 111115 3000 111116 731.1 111117 924.37 111118 1260.51 111119 3970.59 111120 252.11 111121 357.15 111122 735.3 111123 554.7 111124 3235.3 111125 1075.63 111126 4558.83 Fig. nr. 4.2. Exemplu de cmp calculat (ValoareFaraTVA) Interogri care utilizeaz operatorii asambliti din algebra relaional Reuniunea SELECT * FROM R1 UNION SELECT * FROM R2 Operatorul pentru reuniune este deci UNION. De remarcat c, la reuniune, SQL elimin automat dublurile, deci nu este necesar utilizarea clauzei DISTINCT. Operatorul UNION este prezent n toate SGBD-urile importante. Intersecia Pentru realizarea interseciei a dou tabele, R1 i R2 se utilizeaz operatorul INTERSECT: SELECT *

71

FROM R1 INTERSECT SELECT * FROM R2 Dac n produsele profesionale, precum DB2 sau Oracle, operatorul este prezent, n altele, precum Visual FoxPro, INTERSECT rmne un deziderat, funcionalitatea sa realizndu-se prin subconsultri (operatorii IN i EXISTS) sau, uneori, prin jonciune. Diferena Diferena dintre tabelele R1 i R2 se realizeaz utiliznd operatorul MINUS sau EXCEPT. Fraza SELECT urmtoare funcioneaz n Oracle. SELECT * FROM R1 MINUS SELECT * FROM R2 Produsul cartezian n SQL nu exist operator explicit pentru efectuarea produsului cartezian. Dac n clauza FROM apar dou relaii, R1 i R2, atunci, n lipsa unei condiii de jonciune formulat n clauza WHERE, tabela rezultat va conine liniile obinute din produsul cartezian R1 R2. SELECT * FROM R1, R2 Interogri care utilizeaz operatorii relaionali din algebra relaional Selecia Exemplul 1 Care dintre facturile emise dup 23.06.2008 prezint valoarea mai mare de 3000 lei ? SELECT * FROM FACTURIEMISE WHERE DataFactur > {23.06.2008} AND ValoareTotala > 3000 Rezultat: NrFactur CodClient DataFactur ValoareTotal TVAColectat 111119 1005 24.06.2008 4725 754.41 111124 1004 25.06.2008 3850 614.7 111126 1002 01.07.2008 5425 866.17 Operatorul AND a fost utilizat pentru a introduce un "I" logic, dup cum OR se utilizeaz pentru SAU logic. n SQL, pentru comparare, n afara "clasicilor": >, >=, <, <=, =, (<>), mai pot fi utilizai i ali operatori, dintre care n acest paragraf ne vom opri la: BETWEEN (ntre, cuprins ntre), LIKE (ca i, la fel ca), IN (n) i IS NULL. Operatorul BETWEEN Acest operator permite specificarea unui interval de valori n care trebuie s se ncadreze cmpul sau expresia testat. Intervalul se refer la valori numerice sau la date calendaristice. Exemplul 2 Care sunt facturile emise dup 23.06.2008 i care au valoarea cuprins ntre 3000 i 4000 lei ? Fr operatorul BETWEEN fraza SELECT se scrie:

72

SELECT * FROM FACTURIEMISE WHERE DataFactur > {23.06.2008} AND ValoareTotala >= 3000 AND ValoareTotala <= 4000 Utiliznd operatorul BETWEEN se poate scrie: SELECT * FROM FACTURIEMISE WHERE DataFactur > {23.06.2008} AND ValoareTotala BETWEEN 3000 AND 4000 Operatorul LIKE Acest operator se folosete pentru a compara un atribut de tip ir de caractere (de exemplu NumeClient, Adresa, Localitate) cu un literal (constant de tip ir de caractere). Astfel, dac se dorete obinerea unei tabele-rezultat care s conin numai clienii ai cror nume ncepe cu litera M, putem scrie predicatul din clauza WHERE sub forma: NumeClient LIKE "M%". Deoarece dup litera M apare semnul "%", se vor extrage din tabela CLIENI toate tuplurile pentru care valoarea atributului NumeClient ncepe cu litera M, indiferent de lungimea acestuia (ex. MELCRET, MIGAS, MITA, MATSUSHITA etc.). Despre semnul "%" se spune c este un specificator multiplu, joker sau masc. Un alt specificator multiplu utilizat n multe versiuni SQL este liniua de subliniere ("_"). Spre deosebire de "%", "_" substituie un singur caracter. Diferena dintre cei doi specificatori multipli este pus n eviden n exemplele urmtoare. Exemplul 3 Care sunt clienii ai cror nume este format din apte caractere, ncepe cu litera A i sunt societi cu rspundere limitat (SRL-uri) ? SELECT * FROM CLIENI WHERE NumeClient LIKE "A__ SRL" Rezultat: CodClien NumeClient t 1006 AMI SRL Adresa Galaiului, 72 Localitate Bacu

Exemplul 4 Dac n exemplu 3 s-ar fi utilizat simbolul "%": SELECT * FROM CLIENI WHERE NumeClient LIKE "A%SRL", am fi obinut: Rezultat: CodClient NumeClient Adresa Localitate 1006 AMI SRL Galaiului, 72 Bacu 1007 AXON SRL Silvestru, 2 Iai 1008 ALFA SRL Prosperitii, 15 Pacani n concluzie, "_" nlocuiete (substituie) un singur caracter, n timp ce "%" nlocuiete un ir de caractere de lungime variabil (ntre 0 i n caractere). Cei doi specificatori multipli pot fi utilizai mpreun. Operatorul IN Format general: expresie1 IN (expresie2, expresie3, ...)

73

Rezultatul evalurii unui predicat ce conine acest operator va fi "adevrat" dac valoarea expresiei1 este egal cu (cel puin) una din valorile: expresie2, expresie3, ... Este util atunci cnd condiiile de selecie sunt mai complexe. Exemplul 5 Care sunt clienii din Iai i Bacu ? Fr utilizarea operatorului IN se scrie: SELECT * FROM CLIENTI WHERE Localitate= "Iai" OR Localitate= "Bacu Utiliznd operatorul IN: SELECT * FROM CLIENTI WHERE Localitate IN ("Iai", "Bacu) Rezultat CodClient NumeClient Adresa 1001 TEXTILA SA Bld. Copou, 87 Iai 1003 OCCO SRL NULL Iai 1006 AMI SRL Galaiului, 72 Bacu 1007 AXON SRL Silvestru, 2 Iai

Localitate

Operatorul IS NULL O valoare nul este o valoare nedefinit. Este posibil ca la adugarea unei linii ntr-o tabel valorile unor atribute s fie necunoscute. n aceste cazuri valoarea atributului pentru tuplul respectiv este nul. Reamintim c, prin definiie, nu se admit valori nule pentru grupul atributelor care constituie cheia primar a relaiei. Exemplul 6 Dac se dorete aflarea clienilor pentru care nu s-a introdus adresa, se poate scrie: SELECT * FROM CLIENTI WHERE Adresa IS NULL Rezultat: CodClient NumeClient 1003 OCCO SRL

Adresa NULL Iai

Localitate

Observaii Valoarea NULL nu se confund cu valoarea zero (pentru atributele numerice) sau cu valoarea "spaiu" (pentru atributele de tip ir de caractere) Operatorul NULL se utilizeaz cu IS i nu cu semnul "=". Dac s-ar utiliza forma expresie = NULL i nu expresie IS NULL, rezultatul evalurii va fi ntotdeauna fals, chiar dac expresia nu este nul.

Proiecia. Opiunea ORDER BY Coloanele tabelei-rezultat al consultrii sunt specificate n clauza SELECT, fiind separate prin virgul. Exemplul 1 Care sunt localitile n care firma are clieni ?

74

Este necesar parcurgerea relaiei CLIENTI, singurul atribut care intereseaz fiind Localitate. Deoarece SQL nu elimin dublurile automat, dac se dorete ca n tabela-rezultat o localitate s figureze o singur dat, se utilizeaz opiunea DISTINCT: SELECT DISTINCT Localitate FROM CLIENTI Rezultat: Localitate Iai Focani Bacu Pacani Prezentarea localitilor n ordinea alfabetic a numelui acestora este posibil apelnd la clauza ORDER BY. SELECT Localitate FROM CLIENTI ORDER BY Localitate DESCENDING Opiunile ASCENDING (cresctor) i DESCENDING (descresctor) indic modul n care se face ordonarea tuplurilor tabelei-rezultat al interogrii. Prioritatea de ordonare este stabilit prin ordinea atributelor specificate n ORDER BY: ordonarea "principal" se face n funcie de valorile primului atribut specificat; n cadrul grupelor de tupluri pentru care valoarea primului atribut este identic, ordinea se stabilete dup valoarea celui de-al doilea atribut specificat .a.m.d. Dac n ORDER BY lipsesc opiunile ASCENDING/DESCENDING, ordonarea se face implicit cresctor.

Jonciunea SQL nu prezint clauze sau operatori speciali pentru realizarea theta-jonciunii, echijonciunii sau jonciunii naturale. Dar, aa cum am vzut, o jonciune este o combinaie de produs cartezian i selecie. Exemplu: Care sunt facurile emise clienilor din municipiul Iai ? SELECT NrFactura, NumeClient, Localitate FROM FACTURIEMISE, CLIENI WHERE FACTURIEMISE.CodClient = CLIENI.CodClient AND Localitate=Iai sau SELECT NrFactura, NumeClient, Localitate FROM FACTURIEMISE INNER JOIN CLIENI ON WHERE FACTURIEMISE.CodClient = CLIENI.CodClient WHERE Localitate=Iai Rezultat: NrFactur 111111 111112 111114 111118 111120 111121 NumeClient OCCO SRL TEXTILA SA OCCO SRL AXON SRL OCCO SRL TEXTILA SA Localitate Iai Iai Iai Iai Iai Iai

75

111122 111125

AXON SRL OCCO SRL

Iai Iai

Sub-consultri. Operatorul IN O alt facilitate deosebit de important a limbajului SQL o constituie posibilitatea includerii (imbricrii) a dou sau mai multe fraze SELECT, astfel nct pot fi formulate interogri cu mare grad de complexitate. Operatorul IN poate fi utilizat i pentru includerea unei fraze SELECT ntr-o alt fraz SELECT. Exemplul 1 Care sunt facturile emise n aceeai zi n care a fost ntocmit factura 111114 ? SELECT * FROM FACTURIEMISE WHERE DataFactur IN (SELECT DataFactur FROM FACTURIEMISE WHERE NrFactur=111114) Observaie Sub-consultarea SELECT DataFactur FROM FACTURIEMISE WHERE NrFactur=111114 are ca rezultat o tabel alctuit dintr-o singur coloan (DataFactur) i o singur linie ce conine valoarea atributului DataFactur pentru factura 111114: DataFactur 18.06.2007 Clauza WHERE DataFactur IN determin cutarea n tabela FACTURIEMISE a tuturor tuplurilor (liniilor) care au valoarea atributului DataFactur egal cu una din valorile tuplurilor (n cazul nostru, egal cu valoarea tuplului) din tabela obinut prin "subconsultare". Cu alte cuvinte, n acest caz WHERE Data IN va selecta toate facturile pentru care data emiterii este 18.06.2007. Rezultat: NrFactur CodClient DataFactur ValoareTotal TVAColectat 111113 1004 18.06.2008 585 93.4 111114 1003 18.06.2008 2850 455.04 111115 1008 18.06.2008 3570 570 Exemplul 2 Care sunt facturile emise n alte zile dect cea n care a fost ntocmit factura 111114 ? SELECT * FROM FACTURIEMISE WHERE DataFactur NOT IN (SELECT DataFactur FROM FACTURIEMISE WHERE NrFactur=111114) S-a utilizat negaia, testndu-se non-apartenena la o relaie creat printr-o sub-fraz SELECT. Exemplul 3 Care sunt clienii crora li s-au trimis facturi ntocmite n aceeai zi cu factura 111114 ? SELECT DISTINCT NumeClient

76

FROM CLIENI WHERE CodClient IN (SELECT CodClient FROM FACTURIEMISE WHERE DataFactur IN (SELECT DataFactur FROM FACTURIEMISE WHERE NrFactur=111114)) Am ilustrat modul n care pot fi imbricate (nlnuite, incluse) trei fraze SELECT. O alt soluie pentru rezolvarea aceleai probleme este i: SELECT DISTINCT NumeClient FROM CLIENI, FACTURIEMISE WHERE CLIENI.CodClient=FACTURIEMISE.CodClient AND DataFactur IN (SELECT DataFactur FROM FACTURIEMISE WHERE NrFactur=111114) Se poate reine, ca regul general, c aproape orice consultare poate fi redactat n mai multe moduri, n funcie de experiena i imaginaia celui care o formuleaz.

Funcii de agregare (statistice): COUNT, SUM, AVG, MAX, MIN Formatul general al unei fraze SELECT ce conine funcii predefinite este: SELECT funcia-predefinit1, ... , funcia-predefinitN FROM list-tabele WHERE condiii. Rezultatul oricrei fraze SELECT este o nou relaie (tabel). n lipsa opiunii GROUP BY, dac n clauza SELECT este prezent o funcie predefinit, tabela rezultat va conine o singur linie. Funcia COUNT contorizeaz valorile unei coloane, altfel spus, numr, ntr-o relaie, cte valori diferite de NULL are coloana specificat. Exemplul 1 Ci clieni are firma ? SELECT COUNT (CodClient) AS Nr_Clienti FROM CLIENTI Rezultat: Nr_Clienti 8 n funcia COUNT se poate utiliza ca argument, n locul numelui unei coloane, semnul *; n acest caz se va determina cte linii are tabela la care se aplic funcia respectiv. Exemplul 2 La ci clieni s-au trimis facturi ? SELECT COUNT(*) FROM CLIENTI WHERE CodClient IN (SELECT CodClient
77

FROM FACTURIEMISE) Rezultatul corect poate fi ns obinut i prin utilizarea clauzei DISTINCT astfel: SELECT COUNT (DISTINCT CodClient) FROM FACTURIEMISE Funcia SUM calculeaz suma valorilor unei coloane. Exemplul 3 Care este valoarea total a facturilor emise ? SELECT SUM (ValoareTotala) AS Total_FE FROM FACTURIEMISE Rezultat: Total_FE 30000 Exemplul 4 Care este totalul valorii facturilor trimise clientului AXON SRL ? SELECT SUM (ValoareTotala) AS Total_FE_AXON FROM FACTURIEMISE, CLIENTI WHERE FACTURIEMISE.CodClient = CLIENTI.CodClient AND NumeClient = "AXON SRL" Funciile MAX i MIN determin valorile maxime, respectiv minime ale unei coloane n cadrul unei tabele. Exemplul 5 Care este cea mai mic valoare a unei facturi emise ? SELECT MIN(ValoareTotala) AS ValMinima FROM FACTURIEMISE Rezultat ValMinima 285 Exemplul 6 Care este factura emis ce are cea mai mare valoare ? SELECT NrFactur, ValoareTotala FROM FACTURIEMISE WHERE ValoareTotala = (SELECT MAX (ValoareTotala) FROM FACTURIEMISE) Rezultat: NrFactura 111126 ValoareTotala 5425

Gruparea tuplurilor. Clauzele GROUP BY i HAVING SQL permite utilizarea clauzei GROUP BY pentru a forma grupe (grupuri) de tupluri ale unei relaii, pe baza valorilor comune ale unei coloane. n frazele SELECT formulate pn n acest paragraf, prin intermediul clauzei WHERE au fost selectate tupluri din diferite tabele. Prin asocierea unei clauze HAVING la o clauz GROUP BY este posibil selectarea anumitor grupe de tupluri ce ndeplinesc un criteriu.

78

Rezultatul unei fraze SELECT ce conine clauza GROUP BY este o tabel care va fi obinut prin regruparea tuturor liniilor din tabelele enumerate n FROM, care prezint o aceeai valoare pentru o coloan sau un grup de coloane. Formatul general este: SELECT coloan1, coloan2, ...., coloanm FROM tabel GROUP BY coloan-de-regrupare Exemplu 1 Care este totalul zilnic al valorii facturilor emise ? SELECT DataFactur, SUM (ValoareTotala) FROM FACTURIEMISE GROUP BY DataFactur n acest caz tabela-rezultat va avea un numr de linii egal cu numrul de date calendaristice distincte din tabela FACTURIEMISE. Pentru toate facturile aferente unei zile se va calcula suma valorilor, datorit utilizrii funciei SUM(ValoareTotala). Succesiunea pailor este urmtoarea: 1. Se ordoneaz liniile tabelei FACTURIEMISE n funcie de valoarea atributului DataFactur: NrFactur 111111 111112 111113 111114 111115 111116 111117 111118 111119 111120 111121 111122 111123 111124 111125 111126
2.

CodClient 1003 1001 1004 1003 1008 1008 1006 1007 1005 1003 1001 1007 1006 1004 1003 1002

DataFactur 17.06.2008 17.06.2008 18.06.2008 18.06.2008 18.06.2008 19.06.2008 20.06.2008 23.06.2008 24.06.2008 24.06.2008 24.06.2008 24.06.2008 25.06.2008 25.06.2008 30.06.2008 01.07.2008

ValoareTotala 1700 285 585 2850 3570 870 1100 1500 4725 300 425 875 660 3850 1280 5425

TVAColectata 271.42 45.5 93.4 455.04 570 138.9 175.63 239.49 754.41 47.89 67.85 139.7 105.37 614.7 204.36 866.17

Se formeaz cte un grup pentru fiecare valoare distinct a atributului DataFactur: CodClient 1003 1001 1004 1003 1008 1008 1006 1007 1005 1003 1001 DataFactur 17.06.2008 17.06.2008 18.06.2008 18.06.2008 18.06.2008 19.06.2008 20.06.2008 23.06.2008 24.06.2008 24.06.2008 24.06.2008 ValoareTotala 1700 285 585 2850 3570 870 1100 1500 4725 300 425 TVAColectata 271.42 45.5 93.4 455.04 570 138.9 175.63 239.49 754.41 47.89 67.85

3. NrFactur 111111 111112 111113 111114 111115 111116 111117 111118 111119 111120 111121

79

111122 111123 111124 111125 111126

1007 1006 1004 1003 1002

24.06.2008 25.06.2008 25.06.2008 30.06.2008 01.07.2008

875 660 3850 1280 5425

139.7 105.37 614.7 204.36 866.17

3. Pentru fiecare din cele nou grupuri se calculeaz suma valorilor atributului ValoareTotala. Tabela - rezultat final va avea nou linii: DataFactur SUM(ValoareTotala) 17.06.2008 1985 18.06.2008 7005 19.06.2008 870 20.06.2008 1100 23.06.2008 1500 24.06.2008 6325 25.06.2008 4510 30.06.2008 1280 01.07.2008 5425 Exemplul 2 Care este numrul facturilor emise pentru fiecare client ? SELECT NumeClient, COUNT(NrFactur) FROM FACTURIEMISE, CLIENTI WHERE FACTURIEMISE.CodClient=CLIENTI.CodClient GROUP BY FACTURIEMISE.CodClient Observaie Pn la standardul SQL99 i publicarea Amendamentului OLAP la acest standard, n SQL nu puteau fi calculate, prin GROUP BY, subtotaluri pe mai multe niveluri, pentru aceasta fiind necesar scrierea de programe n SGBD-ul respectiv. Clauza HAVING permite introducerea unor restricii care sunt aplicate grupurilor de tupluri, deci nu tuplurilor "individuale", aa cum "face" clauza WHERE. Din tabela rezultat sunt eliminate toate grupurile care nu satisfac condiia specificat. Clauza HAVING "lucreaz" mpreun cu o clauz GROUP BY, fiind practic o clauz WHERE aplicat acesteia. Formatul general este: SELECT coloan 1, coloan 2, .... , coloan m FROM tabel GROUP BY coloan-de-regrupare HAVING caracteristic-de-grup Exemplul 3 Pentru facturile emise intereseaz valoarea zilnic a acestora (n funcie de data la care au fost ntocmite, dar numai dac aceasta (valoarea zilnic) este de mai mare de cinci mii lei. SELECT DataFactur, SUM(ValoareTotala) FROM FACTURIEMISE GROUP BY DataFactur HAVING SUM(ValoareTotala) > 5000 La execuia acestei fraze, se parcurg cei trei pai prezentai la exemplul 1, apoi, din cele nou tupluri obinute prin grupare, sunt extrase numai cele care ndeplinesc condiia SUM(ValoareTotala) > 5000. Rezultat: Data SUM(ValoareTotala)
80

18.06.2008 24.06.2008 01.07.2008

7005 6325 5425

Exemplul 4 S se afieze ziua n care s-au ntocmit cele mai multe facturi. SELECT DataFactur FROM FACTURIEMISE GROUP BY DataFactur HAVING COUNT(*) >= ALL (SELECT COUNT(*) FROM FACTURIEMISE GROUP BY DataFactur) Exemplul 5 Care sunt clienii pentru care s-au ntocmit numai dou facturi? SELECT NumeClient FROM CLIENTI INNER JOIN FACTURIEMISE ON CLIENTI.CODCLIENT=FACTURIEMISE.CODCLIENT GROUP BY NumeClient HAVING COUNT(NrFactura)=2 sau SELECT NumeClient FROM CLIENTI WHERE CodClient IN (SELECT CodClient FROM FACTURIEMISE GROUP BY CodClient HAVING COUNT(NrFactura)=2) Exemplu 6 Care sunt zilele n care s-au ntocmit cel puin trei facturi? SELECT DataFact , Count(*) as Nr FROM FacturiEmise GROUP BY DataFact HAVING COUNT(*)>=3 5.4. Comenzi pentru actualizarea bazelor de date SQL prezint comenzi specifice pentru modificarea coninutului unei tabele, nelegnd prin aceasta trei aciuni prin care se actualizeaz baza: a) adugarea de noi linii la cele existente ntr-o tabel, b) tergerea unor linii, c) modificarea valorii unui atribut.

Adugarea de nregistrri Adugarea de noi linii ntr-o tabel se realizeaz cu comanda INSERT care are urmtoarea sintax: Format: INSERT INTO tabel [(list_cmpuri)] VALUES (list_valori) Exemplul 1

81

S presupunem c, la un moment dat, ntreprinderea vinde produse i firmei RODEX SRL care are sediul pe strada Sapienei, nr.44 bis, n localitatea Iai. Acest nou client trebuie "introdus" n baza de date, operaiune care n SQL, se realizeaz prin comanda: INSERT INTO CLIENI VALUES (1009, "RODEX SRL", "Sapienei, 44 bis", Iai) Fraza INSERT de mai sus poate fi scris i sub forma: INSERT INTO CLIENI (CodClient, NumeClient, Adresa, Localitate) VALUES (1009, "RODEX SRL", "Sapienei 44 bis", "Iai"). Dup cum se observ, dup numele tabelei (CLIENI) au fost enumerate toate atributele pentru care se introduc valori prin clauza VALUES. Dac nu s-ar fi cunoscut adresa clientului RODEX, atunci fraza INSERT ar fi avut forma: INSERT INTO CLIENI (CodClient, NumeClient, Adresa, Localitate) VALUES (1009, "RODEX SRL", NULL, "Iai") n noua linie a tabelei CLIENI valoarea atributului Adresa va fi NULL. Se putea folosi i forma: INSERT INTO CLIENI VALUES (1009, "RODEX SRL", " ", "Iai") n urma execuiei acestei comenzi, valoarea atributului Adresa va fi " " (un spaiu), deci diferit de NULL. tergerea nregistrrilor Operaiunea de eliminare a uneia sau mai multor linii dintr-o tabel se realizeaz prin comanda DELETE care are urmtoarea sintax: DELETE FROM nume-tabel WHERE predicat Exemplul 2 S se elimine din tabela CLIENI linia aferent clientului MODERN SRL (cod 1002). DELETE FROM CLIENI WHERE CodClient = 1002 Exemplu 3 S se tearg datele referitoare la facturile emise clienilor din oraul Focani. DELETE FROM FACTURIEMISE WHERE CodClient IN (SELECT CodClient FROM CLIENI WHERE Localitate = "Focani") n general, tergerea unor linii trebuie privit cu mult circumspecie, deoarece atunci cnd linia de ters conine valori ale unor atribute ce apar n alte tabele ca i chei strine, exist riscul pierderii integritii refereniale. Standardul SQL92 permite la crearea unei tabele descrierea aciunii care se va derula la tergerea unei linii printe n cazul n care exist linii copil. Spre exemplu, se poate refuza tergerea de linii din tabela CLIENI, dac la crearea tabelei FACTURIEMISE se specific: CREATE TABLE FACTURIEMISE (NrFactur decimal (8) not NULL, DataFactur date, CodClient decimal (7) not NULL,

82

ValoareTotala decimal (15) not NULL, TVAColectata decimal (14) , PRIMARY KEY (NrFactur), FOREIGN KEY (CodClient) REFERENCES CLIENI ON DELETE RESTRICT) Modificarea valorilor unor atribute Pentru modificarea valorilor unuia sau mai multor atribute dintr-o tabel, comanda utilizat este UPDATE care are formatul general: UPDATE tabel SET atribut = expresie WHERE predicat Ca rezultat, vor fi modificate valorile atributului specificat, noile valori ale acestuia fiind cele care rezult n urma evalurii expresiei; modificarea se va produce pe toate liniile tabelei care ndeplinesc condiia specificat n predicat. Exemplul 4 Noua adres a clientului Modern SRL este Bulevardul Victoriei nr. 21. S se opereze modificarea n baza de date. Se actualizeaz atributul Adresa din tabela Clieni. UPDATE CLIENI SET Adresa=Bulevardul Victoriei nr. 21 WHERE NumeClient=Modern SRL

83

Bibliografie

1. Airinei, D., .a., Instrumente software pentru afaceri, Editura Sedcom Libris, Iai, 2007 2. Airinei, D., .a., Modele de aplicaii practice n Microsoft Excel i Microsoft Access, Editura Sedcom Libris, Iai, 2007 3. Conolly, T., Begg, C., Strachan, A., Baze de date, Proiectare, implementare, gestionare, Editura Teora, Bucureti, 2001 4. Date, C.J., Baze de date, ediia a opta, Editura Plus, 2007 5. Florescu, V., .a., Baze de date, Editura Economic, Bucureti, 1999 6. Fotache, M., Baze de date relaionale. Organizare, interogare i normalizare, Editura Junimea, Iai, 1997 Fotache, M., SQL. Dialecte DB2, Oracle, Visual FoxPro, Editura Polirom, Iai, 2001 8.Fotache, M., Proiectarea bazelor de date. Normalizare,postnormalizare, Editura Polirom, Iai, 2005 9. Habraken, J., Microsoft Office 2003, 6 n 1, Editura Teora, 2008 10. Melnic, A., Medii de programare, Editura Tehnopress, Iai, 2005 11. Hernandez, M. J., Proiectarea bazelor de date, Editura Teora, Bucureti, 2003 12. Nstase, P., .a., Tehnologia bazelor de date Access 2000, Editura Economic, Bucureti, 2000 13. Popescu, I., Modelarea bazelor de date, Editura Tehnic, Bucureti, 2001

84