UNIVERSITATEA GEORGE BACOVIA BACU

MEDII DE PROGRAMARE
SUPORT DE CURS

Conf. univ. dr. Andreia Melnic

Uz intern Bacu 2005

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. Caracterizarea principalelor limbaje de programare 1.5. Criterii de selecie a limbajelor de programare 1.6. Elaborarea produselor-program. Activiti specifice elaborrii produselorprogram Capitolul 2. PROGRAMELE DE CALCUL TABELAR I UTILIZAREA LOR N GESTIUNEA NTREPRINDERII23 2.1. Noiuni de baz privind programele de calcul tabelar (foaia de calcul, registrul de lucru, tipuri de date, formule, funcii, comenzi, macrocomenzi) 2.2. Principii de realizare a aplicaiilor informatice n programele de calcul tabelar 2.3. Categorii de funcii din programele de calcul tabelar i posibiliti de utilizare n simulri (sintaxa funciilor, categorii de funcii) 2.4. Faciliti grafice n programele de calcul tabelar 2.5. Simulri utiliznd programele de calcul tabelar 2.6. Baze de date Excel

CAPITOLUL 3 BAZE DE DATE I SISTEME DE GESTIUNE A BAZELOR DE DATE36 3.1 Concepte utilizate n studiul bazelor de date i al sistemelor de gestiune a bazelor de date 3.2. Modele de structurare a datelor n baze de date 3.3. Sisteme de gestiune a bazelor de date 3.4. Protecia i securitatea bazelor de date 3.5. Administrarea datelor i a bazelor de date Capitolul 4. MODELUL RELAIONAL AL DATELOR.67 4.1. Elementele modelului relaional 4.2. Algebra relaional 4.3. Studiul dependenelor funcionale 4.4. Normalizarea bazelor de date relaionale Capitolul 5. LIMBAJE DE INTEROGARE A BAZELOR DE DATE SQL.84 5.1. SQL - Evoluie i performane 5.2. Comenzi pentru descrierea datelor; 5.3. Comenzi pentru interogarea bazelor de date 5.4. Comenzi pentru actualizarea bazelor de date Bibliografie ...104

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.6. Elaborarea produselor-program. Activiti specifice elaborrii produselorprogram 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 om-calculator 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 produsele-program. 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 produsul-program. 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
4

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 care-i 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. Asamblare 2. Execuie Rezultate finale

Asamblor 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.

Progra m O. P.O. ima gine memorie executa bil

1. Compilare/ interpretare 2. Editare de 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 codmain. 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 mainframeurilor 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 ntr-o 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 V 1. 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. 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 (Tellal 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.

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

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 1969 2, 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. 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.

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

10

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. 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.
3

Cristea , V. , Dicionar de informatic, Editura tiinific i enciclopedic, Bucureti , 1981, p. 240

11

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.

12

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. 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):

13

Zon de intra re Zon de lucru Zon de 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 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. Caracterizarea principalelor limbaje de programare Din multitudinea limbajelor de programare practica a consacrat att limbaje de tip universal, ct i limbaje specializate pe domenii de activitate. n continuare, fr pretenia de a fi exhaustivi, prezentm limbajele care s-au impus n domeniul economic i n cel tehnico-tiinific.

14

FORTRAN (FORmula TRANslation) este un limbaj cu orientare matematic, fiind utilizat cu precdere n aplicaii tehnice (ecuaii, operaii cu matrici, programare liniar, simulare). Este primul limbaj de nivel nalt. Prima versiune a aprut n 1954, fiind realizat de o echip de la IBM i urmat de alte versiuni perfecionate. 1964 este anul n care FORTRAN a fost standardizat n SUA. A fost foarte criticat n anii 70, conferindui-se atributele greoi, dezordonat, infantil i fr speran de a deveni adecvat. Totui, ultimele versiuni FORTRAN au fost aduse n concordan cu noile standarde ale programrii structurate. Cu toate acestea, este destul de puin utilizat astzi. Cele mai utilizate versiuni au fost: FORTRAN IV, FORTRAN IV PLUS, FORTRAN 77 pentru minicalculatoare, specializat pentru prelucrri n timp real, FORTRAN 90 variant mbuntit cu atributele programrii orientate obiect. COBOL (COmmon Business Oriented Language) a fost primul limbaj orientat exclusiv ctre rezolvarea problemelor economice, cum reiese i din numele su. Dintre limbajele din generaia a 3-a este cel mai rspndit, dup FORTRAN. Se utilizeaz pentru exploatarea unui volum mare de date cu structuri diverse (arbori, tablouri, fiiere etc.). COBOL a fost lansat n 1964, fiind dezvoltat de o echip de specialiti, condus de o femeie (cpt. Grace Hooper) de la Departamentul Aprrii SUA. A fost standardizat prima oar n 1968. Succesul lansrii i utilizrii n urmtorii ani (la sfritul anilor 80, ntre 60 i 75% din aplicaiile economice erau scrise n COBOL) a fost nsoit de mai multe controverse. Avantaje: posibilitatea manipulrii unor volume mari de date, descrierea complet a structurilor de date, rapiditate n execuie (datorit compilrii). Cea mai important productoare de compilatoare COBOL (firma britanic Micro FOCUS) a lansat n 1994 COBOL orientat pe obiecte pentru microcalculatoare. La ora actual, pentru microcalculatoare, firma Micro Focus ofer compilatoare COBOL care permit: dezvoltarea de aplicaii (inclusiv cu faciliti grafice) pentru lucrul n reelele de calculatoare; dezvoltarea de aplicaii cross-platform destinate unei game largi de echipamente i sisteme de operare; asigurarea portabilitii la nivel de programe surs. COBOL reprezint un software complex cu un nalt grad de generalizare i care asigur independena programelor fa de componentele hardware. BASIC (Begginners All Purpose Instruction Code) este unul din cele mai utilizate limbaje de generaia a III-a, poate i pentru faptul c a fost livrat odat cu sistemul de operare MS-DOS, fiind inclus ntre aplicaiile acestuia (universalitatea i simplitatea limbajului a determinat includerea sa n sistemele de operare). Totul a nceput n 1963, cnd profesorii Kurtz i Kemeny de la colegiul Darmouth, SUA ncep lucrul la un nou limbaj, care s nlocuiasc Fortran i lucrul cu cartele perforate. n 1964 este lansat prima versiune, sub numele BASIC care avea 12 instruciuni. Prima versiune pentru microcalculatoare a fost lansat n 1972. n 1975, Bill Gates i Paul Allen au scris primul interpreter BASIC pentru microcalculatoare care ocupa doar 7 KB de memorie, compania Microsoft care a aprut apoi susinnd BASIC-ul prin includerea lui n pachetul sistemului de operare MS-DOS (ncepnd de la versiunea 5.0). Au aprut apoi zeci de versiuni de BASIC, cu diferii autori, multe dintre ele incompatibile, ajungnd s fie denumit de unii limbajul programatorilor neprofesioniti. De aceea, n 1983 ANSI hotrte elaborarea unui standard pentru limbajul BASIC. Acest limbaj a cunoscut diverse variante, cele mai rspndite fiind BASICA, GWBASIC, QBASIC, Turbo Basic i, nu n ultimul rnd, Visual Basic.

15

PASCAL este un limbaj popular n mediul universitar (mai ales n facultile de informatic i matematic). A aprut n 1968 i a fost denumit dup matematicianul francez Blaise Pascal. Este un limbaj universal, caracterizat prin simplitate, eficien, accesibilitate (chiar i pentru nceptori) i care prezint (nc de la prima versiune) toate elementele specifice programrii structurate. Sunt preri care apreciaz c nvarea limbajului PASCAL este indispensabil pentru formarea unor informaticieni. Dezavantaje: slaba gestionare a datelor organizate n fiiere i incapacitatea de a manipula volume mari de date. Limbajul a cunoscut mai multe versiuni adaptate diverselor metode de prelucrare (Pascal secvenial, Pascal concurent, Pascal obiectual). Pascal a stat la baza elaborrii de noi limbaje precum MODULA-1, MODULA-2, ADA. Ultimele versiuni, produse de firma Borland, au aprut sub numele Turbo PASCAL, cu un succes remarcabil pe pia. ADA, (Automatic Data Acquisition i totodat numele contesei de Lovelace Augusta Ada Byron, considerat a fi primul programator din lume), elaborat la Departamentul Aprrii SUA pentru aplicaii tehnico-tiinifice n 1979. Are multe din elementele limbajului PASCAL, dar este mult mai complex, fiind considerat unul din cele mai dificile limbaje. Folosit iniial n domeniul militar, la ora actual, datorit ]facilitilor oferite este larg utilizat i n aplicaiile economice. C a fost produs de Bell Laboratories la nceputul anilor 70 (dezvolt limbajul B elaborat de laboratoarele Bell). Este un limbaj orientat spre asigurarea fluxurilor de instruciuni, conducnd la elaborarea de programe compacte, bine structurate. Destinat iniial programatorilor de sistem, i-a lrgit aria de utilizatori odat cu extinderea sistemului de operare UNIX. Este limbajul de programare cu cea mai impresionant evoluie i extindere n anii 90. C-ul preia de la limbajele de tip PASCAL gradul ridicat de portabilitate, iar de la limbajele de asamblare rapiditatea n execuia i gestionarea eficient a memoriei. Rmne totui un limbaj pentru profesioniti, multe aplicaii (procesoare de texte, spreadsheet-uri sau SGBD-uri) fiind scrise cu ajutorul limbajului C. n plus, ultimele versiuni ale acestui limbaj au transformat C ntr-un limbaj orientat pe obiect (C++). Principalii productori sunt Borland (C++), Microsoft (Quick C, Visual C), Symantec. RPG (Report Program Generator) este un limbaj dezvoltat de ctre firma IBM la mijlocul anilor 60 odat cu lansarea unei noi linii de minicalculatoare proiectate pentru afacerile mici i mijlocii. Limbajul permite ca pe baza unor specificaii ale utilizatorului, s se genereze codul unui program care lansat n execuie va conduce la obinerea rapid i cu un cost relativ redus, a rapoartelor dorite. PL/1 (Programming Language 1) este un limbaj lansat de ctre firma IBM la nceputul anilor 60, mbinnd facilitile din FORTRAN pentru aplicaii tiinifice cu cele din COBOL pentru aplicaiile economice. La ora actual acesta nu este foarte popular, utilizarea lui fiind limitat datorit faptului c este complex i greu de nvat LISP (LISt Processing) este un limbaj adecvat inteligenei artificiale, utilizat mai ales n cercetare i n domeniul inteligenei artificiale. A aprut n 1958 la Institutul Tehnologiei din Massachussets, dar a fost considerat prea avansat pentru tehnologia vremii. Spre deosebire de celelalte limbaje prezentate, care sunt imperative, LISP este un limbaj funcional. LISP nu face deosebirea ntre date i prelucrri, acestea fiind considerate obiecte i tratate la fel. Se pot declara dou tipuri de obiecte: atomi i liste. PROLOG (PROgramming in LOGic) a fost fundamentat n 1972 la Universitatea din Marsilia pentru aplicaii de inteligen artificial i face parte din familia limbajelor declarative (nu algoritmice). A fost orientat spre demonstrarea de teoreme i nelegerea limbajului natural. Permite reprezentarea i utilizarea

16

cunotinelor, fiind utilizat n crearea de sisteme expert. PROLOG este considerat o rzvratire mpotriva modului de programare impus de modelul Von Neumann, iar n 1982 proiectul japonez de realizare a calculatoarelor de generaia a V-a prevede folosirea ca limbaj de baz a limbajului PROLOG. Smalltalk a fost dezvoltat la mijlocul anilor 70 de ctre firma Xerox Corporation i a fost primul limbaj specific programrii orientat pe obiecte. Acest limbaj nu este greu de nvat i utilizat dar reclam schimbarea n ntregime a modului de gndire a unui program. Se prevede ca n viitor Smalltalk alturi de celelalte limbaje orientate pe obiect s cunoasc o dezvoltare i utilizare deosebit. JAVA este un limbaj orientat pe obiecte dezvoltat de firma Sun Microsystems. Are ca scop asigurarea comunicrii ntre echipamente eterogene i distribuirea formatului executabil al programelor n reea, fiind limbajul cel mai utilizat n reeaua INTERNET. Acest limbaj opereaz cu tipuri obinuite de date, dispune de instruciuni speciale de protecie i ofer faciliti de programare de tip animaie, orientare obiect, distribuie. Codul Java este portabil, acelai program putnd fi rulat pe orice platform care deine acest mediu de execuie. O parte din limbajele de programare, prin diversele lor versiuni, nu pot fi ncadrate strict ntr-o anume generaie. Fiind supuse continuu perfecionrii, ele tind spre generaia superioar celei n care au fost proiectate iniial. 1.5. 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

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

17

noi resurse informatice. Trebuie asigurat creterea gradului de portabilitate cel puin la nivel de program surs. 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. 1.6. Elaborarea produselor-program. Activiti specifice elaborrii produselorprogram Elaborarea unui produs-program constituie o activitate deosebit de complex care necesit utilizarea unei metodologii clare i unitare. De regul, o asemenea activitate se desfoar n echipe de lucru complexe n care sunt inclui analiti, specialiti ai domeniului pentru care se dezvolt produsul-program, programatori, specialiti n testarea i implementarea produselor-program, utilizatori etc. Literatura de specialitate pune n discuie o multitudine de probleme legate de metodologia elaborrii produselor-program i subliniaz n mod deosebit necesitatea existenei unei metodologii unitare. Totui, se poate afirma c n forma sa final orice produs-program poate fi privit ca un sistem cu funcii i componente proprii, cu intrri, ieiri, prelucrri i bucle de autoreglare i cu un scop bine stabilit. Din punct de vedere practic, elaborarea unui produs-program presupune parcurgerea unui anumit numr de activiti specifice obinerii acestuia. Exist un numr nsemnat de modele pentru elaborarea unui produs-program dintre care cele mai importante sunt: modelul n cascad, modelul n V, modelul evolutiv, modelul spiral, modelul liniar, modelul incremental, modelul RAD.

18

Modelul n cascad Dintre toate modelele enumerate, modelul n cascad este cel mai des utilizat n practic. Activitile avute n vedere la elaborarea produselor-program n cazul modelului n cascad sunt urmtoarele: Definirea cerinelor (problemei); Analiza; Proiectarea; Dezvoltarea; Testarea; Implementarea;

Exploatarea i ntreinerea. Acest model a fost lansat de W.W. Royce la nceputul anilor 1970 5 i este cel mai familiar programatorilor. Caracteristica fiecrei etape const n aceea c se finalizeaz cu o verificare i o validare n scopul eliminrii eventualelor anomalii care ar putea s apar n cadrul acesteia. Dac se constat anomalii, atunci se va reveni la etapa precedent pn cnd acestea vor fi eliminate. Astfel se realizeaz o minimizare a costului pentru produsul-program dezvoltat. n acelai timp, trecerea de la o faz la alta, n sus i n jos ofer modelului un caracter iterativ i incremental.
Definirea cerinelor Analiza Proiectarea

Dezvoltarea

Testarea

Implementarea

Exploatarea i ntreinerea

Fig. nr. 1.7. Modelul n cascad

Royce, W.W., Management the Development of Large Software systems, Proceedings of WESTCON, CA, USA, 1970 19

Activiti specifice elaborrii produselor-program ntruct cel mai des utilizat model pentru elaborarea produselor program este modelul n cascad, vom prezenta n continuare activitile specifice de elaborare a produselor-program utiliznd acest model: 1. Definirea problemei n activitatea de elaborare a unui produs-program este foarte important de a ti i de a nelege esena sarcinii de ndeplinit nc nainte de nceperea lucrului efectiv. Scopul activitii de definire a problemei este, deci, de a formula pe nelesul echipei de lucru problema de rezolvat i de a descrie o strategie de rezolvare a problemei. n aceast etap se poart discuii cu specialiti ai domeniului i cu potenialii utilizatori ai viitorului produs-program. Astfel, se urmrete extragerea de informaii cu privire la cerinele, restriciile i obiectivele avute n vedere pentru asigurarea funcionalitii produselor-program. Metoda cea mai des utilizat este interviul, la care se pot aduga informaii extrase din diverse surse, precum: studii comparative realizate pentru produse-program similare, studii de fezabilitate, informri. Din aceast activitate trebuie s rezulte clar urmtoarele categorii de cerine: - cerine funcionale pentru utilizri simple i avansate - cerine tehnice (resursele tehnice minime necesare pentru utilizarea produselor-program - cerine cu privire la livrare. Verificarea i validarea au loc pe tot parcursul acestei activiti, prin faptul c att utilizatorii, ct i echipa de lucru colaboreaz foarte strns la obinerea informaiilor necesare. 2. Analiza Dup obinerea unei definiii clare a problemei de rezolvat, se procedeaz la analizarea problemei. Scopul analizei este de a determina cu exactitate ce trebuie fcut pentru rezolvarea problemei. De regul, elementele logice ale sistemului (limitele, procesele i datele sale) sunt definite n cursul analizei, avnd n vedere cerinele formulate n etapa precedent. Rezultatul obinut de ctre membrii echipei de lucru este supus verificrii corespondenelor cu cerinele din etapa precedent. Validarea se realizeaz de ctre beneficiar ntr-o ntlnire n care i se poate prezenta sub forma unei informri rezultatul analizei echipei de lucru. Dac la aceast ntlnire se constat c trebuie fcute completri informaionale legate de natura problemei de rezolvat, atunci se poate reveni la etapa de definire a problemei i reluarea/completarea analizei. Dac se constat c nu exist aspecte suplimentare de clarificat, atunci are loc validarea din partea beneficiarului a activitii de analiz i se poate trece la activitatea urmtoare. 3. Proiectarea Proiectarea produsului-program este procesul prin care se reprezint funciile fiecrei componente n maniera n care se relev concret una sau mai multe uniti funcionale, module etc. Scopul activitii de proiectare const n a determina modul n care va fi rezolvat problema. n timpul proiectrii, atenia analistului se va deplasa de la latura logic la cea fizic. Procesele sunt convertite n proceduri manuale sau programe de calculator. Elementele datelor sunt grupate pentru a forma structuri de date fizice, machete, rapoarte, fiiere i baze de date. Sunt definite componentele hardware care susin programele i datele.

20

Proiectarea produsului-program parcurge urmtoarele faze: - proiectarea architectural - specificaia produsului-program - proiectarea de ansamblu - proiectarea de detaliu n faza proiectrii arhitecturale se stabilete arhitectura general a viitorului produs-program n corelaie cu fazele precedente. Specificaia produsului-program const ntr-o documentaie care va fi obiectul unui contract ncheiat ntre beneficiar i dezvoltator. n aceast documentaie se va avea n vedere stabilirea funciilor de informatizat i cuprinderea condiiilor de lucru efectiv. n faza proiectrii de ansamblu se stabilete structura modular a produsuluiprogram, pornind de la specificaia i arhitectura stabilit anterior. Elementul de baz al structurii l constituie modulul. n faza proiectrii detaliate se procedeaz la stabilirea algoritmului de lucru pentru fiecare modul i se ine cont de toate detaliile funcionale ale acestuia. Prin parcurgerea acestor faze se va obine un proiect cu dou categorii de informaii, de ansamblu i de detaliu. Parcurgerea unor faze din cele prezentate se poate repeta prin aa-numitul proces de rafinare prin care se verific rezultatul obinut dup proiectarea de detaliu cu proiectarea arhitectural i specificaiile produsului-program. Verificarea are loc permanent prin raportare att la cerinele stabilite n prima activitate, ct i la arhitectura general stabilit la nceputul acestei activiti. Validarea se pune n eviden prin acceptarea produsului-program de ctre beneficiar. 4. Dezvoltarea Crearea propriu-zis a produsului-program are loc n cadrul activitii de dezvoltare. n cadrul acesteia au loc urmtoarele sub-activiti: - codificarea algoritmilor de lucru pentru fiecare modul al arhitecturii produsului-program; - documentarea i testarea fiecrei componente arhitecturale ; - pregtirea documentaiei pentru utilizatorul final ; - iniializarea bazelor de date i a fiierelor; - instruirea utilizatorilor. Procesul dezvoltrii produselor-program de la stadiu de proiect la stadiu de aplicaie se poate realiza pe dou ci: - dezvoltarea top-down (descendent); - dezvoltarea bottom-up (ascendent). Alegerea unei modaliti de dezvoltare a produselor-program depinde de metoda de proiectare i de obinuina echipei de lucru. n cazul dezvoltrii descendente, produsul-program este considerat a fi o ierarhie de componente i presupune nceperea activitilor specifice de la vrf ctre componente, n timp ce n cazul dezvoltrii ascendente se pornete de la componente ctre vrf. 1. Dezvoltarea descendent n acest caz activitatea de programare ncepe cu modulul director, adic modulul aflat pe nivelul cel mai nalt al ierarhiei, dup care sunt tratate modulele de pe nivelul urmtor, pn cnd se codific toate modulele de pe toate nivelurile de descompunere. Pe msura definitivrii codificrii componentelor de la un nivel se

21

trece la cele de pe nivelul urmtor. Prin aceast tehnic de dezvoltare se obin programe mai lizibile i mai fiabile, cu posibilitatea ntreinerii foarte uoare. 2. Dezvoltarea ascendent n cazul dezvoltrii ascendente activitatea de codificare ncepe cu modulele de la cel mai mic nivel i se trece treptat la modulele de pe nivelul superior. Aceast dezvoltare este mai potrivit pentru optimizri cu caracter local n costul i n calitatea produselor program. Se recomand n cazul produselor-program complexe cnd, la rndul lor, modulele se constituie n aplicaii de sine-stttoare, iar gradul de interconectare este mare. n practic, de cele mai multe ori, se accept o combinaie a celor dou tehnici de dezvoltare pentru a se ctiga timp i bani. n activitatea de dezvoltare, verificarea are loc prin compararea fiecrui modul cu cerinele iniiale i specificaia produsului-program, precum i cu ocazia testrii funcionalitii fiecrui modul codificat chiar de ctre echipa de programatori. Verificarea se realizeaz n colaborare cu specialitii i utilizatorii desemani de ctre beneficiar. 5. Testarea Integrarea i testarea produsului-program este faza n care unitile de program, testate anterior separat, sunt integrate i testate ca un sistem pentru ca echipa de proiectare s se conving mpreun cu beneficiarii de asigurarea funcionalitii produsului-program n ansamblu. Aceast etap presupune i validarea funcionalitii produsului-program cu date de test stabilite de viitorul beneficiar. 6. Implementarea Dup ce programul trece i ultimul test i sunt corectate eventualele probleme aprute, sistemul poate fi implementat direct la beneficiar. Aceast activitate se constituie din urmtoarele aciuni: instalare, parametrizare, iniializare cu datele beneficiarului. De cele mai multe ori, dezvoltatorul se implic i n aciuni de formare a personalului ce va utiliza produsul-program. Eventualele anomalii constatate la implementare pot atrage reluarea unor activiti precedente. 7. Exploatarea i ntreinerea Utilizarea i ntreinerea este faza cea mai ndelungat a ciclului de via a unui produs-program. Produsul-program este instalat i pus n funciune la utilizator. Aceast activitate implic descoperirea i eliminarea tuturor eventualelor erori care nu au putut fi descoperite n fazele precedente, mbuntirea implementrii unor uniti de program astfel nct s ncorporeze noi funcii cerute de beneficiari. Dup trimiterea sistemului, ncep lucrrile de ntreinere. Obiectivul ntreinerii este meninerea funcionrii sistemului la un nivel acceptabil. Pentru inerea sub control a activitilor specifice fiecrei faze este necesar elaborarea unei documentaii specfice care se va utilize cu precdere ca suport de lucru n etapele urmtoare. Avnd n vedere multitudinea de etape i numrul mare de specificaii necesare derulrii fiecrei etape, acest model nu este folosit n practic pentru aplicaii mici, dezvoltate n logica utilizatorului final.

22

Capitolul 2. PROGRAMELE DE CALCUL TABELAR I UTILIZAREA LOR N GESTIUNEA NTREPRINDERII 2.1. Noiuni de baz privind programele de calcul tabelar (foaia de calcul, registrul de lucru, tipuri de date, formule, funcii, comenzi, macrocomenzi) 2.2. Principii de realizare a aplicaiilor informatice n programele de calcul tabelar 2.3. Categorii de funcii din programele de calcul tabelar i posibiliti de utilizare n simulri (sintaxa funciilor, categorii de funcii) 2.4. Faciliti grafice n programele de calcul tabelar (principalele tipuri de grafice, procedura general de creare a graficelor, previziuni i simulri pe baza graficelor EXCEL) 2.5. Simulri utiliznnd programele de calcul tabelar 2.6. Baze de date Excel Programele de calcul tabelar reprezint instrumente orientate ctre utilizatorul final, oferind modele i tehnici de lucru apropiate de modalitile curente de rezolvare a problemelor. Principala calitate din care decurge i succesul programelor de calcul tabelar o reprezint simplitatea n utilizare. Organizarea lor sub forma celulelor unei foi de calcul sau registru de lucru, puterea de formalizare, de calcul i de memorare au determinat transformarea acestora n instrumente utile i capabile de a traduce experiena utilizatorilor. 2.1 Noiuni de baz privind programele de calcul tabelar Foaia de calcul electronic este documentul principal al programelor de calcul tabelar. ntlnit n literatura de specialitate din ara noastr i sub denumirea de centralizator electronic, tabel electronic sau chiar "spreadsheet", dup denumirea din limba englez, foaia de calcul electronic reprezint un tabel de dimensiuni foarte mari, structurat n linii i coloane, n care se pot defini cu uurin modelele de rezolvare a problemelor. Ea ofer posibiliti de introducere a datelor i definire a modelelor, posibiliti de calcul, de vizualizare, de exprimare grafic, de simulare etc. (vezi fig. nr. 2.1). Fiecare csu (celul) a foii de calcul este independent de celelalte, putnd fi referit printr-o adres care indic linia i coloana la ntretierea crora se afl. Pentru specificarea adreselor sunt practicate dou stiluri: stilul consacrat de LOTUS (A1, A2, F5, ;IV65536) i stilul consacrat de MULTIPLAN (R1C1, R2C2, R5C6, ,R16384C256). Programele de calcul tabelar lucreaz, n general, cu dou tipuri de date: date numerice i date de tip ir de caractere. Sistemul detecteaz tipul datei dup natura primului caracter introdus sau dup coninut. Dac primul caracter este o liter, data este considerat de tip ir de caractere, dac ncepe cu o cifr, data este considerat de tip numeric. Programele de calcul tabelar gestioneaz i date calendaristice: intern ele sunt reprezentate ca un numr ([1,2958465] n Excel), iar afiarea se poate face n diferite formate. De exemplu, pentru ca o celul s conin data calendaristic de 01Oct-2000, trebuie s introducei n celula respectiv numrul 36800 i s solicitai apoi, prin comanda FORMAT (n Excel, de exemplu, se utilizeaz din meniul Format comanda Cells, apoi se selecteaz Number i categoria Date) afiarea ca dat calendaristic.

23

Coninutul unei celule poate fi i o formul sau o funcie. Formulele i funciile ncep printr-un caracter special: =; +; -; @; etc, prin intermediul lor putnduse exprima o mare diversitate de calcule. De fapt, formulele i funciile sunt elementele eseniale ale foii de calcul electronice din care rezult performanele i capacitile de simulare ale acesteia. Printr-o formul se definete coninutul unei celule n funcie de coninutul altor celule. Relaia rmne adevrat pentru orice coninut al celulelor folosite ca argumente n formule. Dac se schimb coninutul celulelor folosite ca argumente, instantaneu se modific i coninutul celulei care conine formula. Modelul prezentat n fig. nr. 2.2. poate fi utilizat de ctre administratorul unui spaiu comercial care nchiriaz spaiul mai multor firme i dorete s gestioneze cu ajutorul unui program de calcul tabelar ncasrile realizate prin nchiriere. Este suficient s introducei datele de intrare, iar pe baza formulelor i a funciilor existente se obin imediat rezultatele. ntruct graficul din fig. nr. 2.1. este construit pe baza datelor din zona G4:G19, de fiecare dat cnd se modific datele din zona specificat, se va modifica i graficul. Dac sunt mai multe societi vor fi inserate noi linii, dup care se vor copia formulele i funciile deja introduse.

Fig. nr. 2.1. Model realizat n Excel pentru determinarea ncasrilor realizate prin nchirierea unui spaiu comercial La copierea sau mutarea unei formule sau funcii are loc i actualizarea adreselor. Dac fomula =H4-J4 din K4 este copiat n K5 ea devine =H5-J5. n schimb, dac se copie formula =C26*$D$33 din D26 n D27 aceasta devine =C27*$D$33 i nu =C27*D34. Adresele care sunt actualizate la copiere sau mutare se numesc adrese relative (de exemplu, H4, J4), adresele care rmn neschimbate la copiere sau mutare se numesc adrese absolute (de exemplu, $D$33). Corectarea formulelor introduse, tergerea coninutului unor celule sau grupuri de celule se poate face la fel de simplu i rapid ca n procesoarele de texte.

24

De asemenea, exist posibilitatea atribuirii de nume unor celule sau grupuri de celule, scrierea formulelor devenind mai simpl i mai rapid. De exemplu, =SUM(Suprafaa), =SUM(Datorat), =SUM(TVA) sunt mult mai sugestive din punct de vedere al logicii problemei de rezolvat dect =SUM(G4:G19); =SUM(H4:H19); =SUM(I4:I19) (vezi fig. nr. 2.2). n acest scop grupului G4:G19 i se atribuie numele Suprafaa, grupului H4:H19 i se atribuie numele Datorat, iar grupului I4:I19 i se atribuie numele TVA. n Excel, de exemplu, atribuirea de nume unor grupuri de celule se realizeaz utiliznd din meniul Insert comanda Define i apoi Name.

Fig. nr.2.2. Formule i funcii utilizate n modelul de rezolvare EXCEL Funciile reprezint formule predefinite n sistem. Utilizatorul trebuie doar s specifice numele funciei i argumentele, respectnd regulile de sintax. Numrul i natura argumentelor depind de tipul funciei: matematice, logice, financiare, speciale, statistice, pentru baze de date, pentru date calendaristice etc. n fig. nr. 2.2. s-a exemplificat utilizarea funciei statistice SUM, a funciei de cutare VLOOKUP i a funciei pentru date calendaristice DATE. La fel ca limbajele de programare din generaiile anterioare, programele de calcul tabelar dispun de comenzi i macro-comenzi prin care se pot defini i declana anumite operaiuni sau parametri (inserarea de linii, coloane, celule etc., stabilirea parametrilor de format, gestionarea ferestrelor de afiare etc.). Comenzile permit declanarea unor operaiuni n foaia de calcul i sunt desemnate prin cuvinte cheie. Comenzile sunt grupate n meniuri i submeniuri cu mai multe niveluri. n versiunile sub MS-DOS se utilizau, de obicei, meniuri tip linie. n versiunile sub WINDOWS se utilizeaz meniuri derulante (vezi fig. nr. 2.3.). Concomitent se asigur posibilitatea folosirii rapide a comenzilor mai des ntlnite prin intermediul pictogramelor din liniile de instrumente afiate n partea superioar a ecranului. De asemenea, exist i posibilitatea definirii i utilizrii de linii de instrumente personalizate.
25

Macro-comenzile (macro-urile) sunt similare instruciunilor i comenzilor din limbajele de programare clasice i permit descrierea unor grupuri de operaiuni repetitive. Astfel nu mai este necesar repetarea comenzilor, ci doar apelarea modulelor de program realizate. Primele versiuni ale programelor de calcul tabelar utilizau un limbaj de macro-comenzi asemntor limbajelor de asamblare, ele bazndu-se pe mnemonice obinute din iniialele comenzilor. Versiunile recente folosesc ca limbaj de macro-comenzi un limbaj evoluat (de exemplu, EXCEL folosete limbajul Visual Basic). n plus este oferit i posibilitatea nregistrrii automate a macro-comenzilor. n tabelul 2.1 este prezentat un modul de program pentru inserarea datei calendaristice n EXCEL. Iniial programele de calcul tabelar se bazau doar pe utilizarea facilitailor oferite de foile electronice de calcul. Pe msura evoluiei, ele au devenit instrumente software integrate, orice program de calcul tabelar incluznd mai multe module: modul pentru lucrul cu foile de calcul electronice; modul pentru reprezentarea grafic a datelor din modelele definite; modul pentru lucrul cu obiecte grafice (Drawing toolbar); modul pentru baze de date; modul pentru definirea de programe, utiliznd tehnica macro-comenzilor; modul de instruire sau faciliti de tip Help; modul de import/export de date de la/ctre alte programe de calcul tabelar sau sisteme de gestiune a bazelor de date.

Fig.nr. 2.3. Secven din sistemul de comenzi EXCEL Tabel nr. 2.1. EXCEL versiunea 7.0 ' Macro1 Macro ' Macro recorded 01-11-02 by Andreia
26

Melnic ' Sub Macro1() ActiveCell.FormulaR1C1 = "=NOW()" Selection.NumberFormat = "d-mmmyy" Selection.Columns.AutoFit End Sub Larga rspndire a programelor de calcul tabelar este determinat de urmtoarele faciliti: a) recalcularea automat a rezultatelor formulelor i funciilor; b) simulri; c) rearanjarea automat a liniilor/coloanelor dup actualizare; d) posibiliti de afiare a datelor n diferite formate; e) implementarea de funcii financiare, statistice, speciale etc.; f) posibiliti de automatizare a unor operaiuni; g) instrumente de lucru orientate ctre utilizatorul final; h) personalizarea modelelor definite. a) Recalcularea automat a rezultatelor formulelor i funciilor ofer posibilitatea vizualizrii rapide a influenei modificrii coninutului celulelor referite. Efectul recalculrii este vizibil numai dac la scrierea formulelor i funciilor nu s-au folosit constante. Formulele i funciile pot fi orict de complexe, ele pot face referin la celule care la rndul lor conin alte formule sau funcii. De asemenea, funciile pot avea ca argumente alte funcii. Recalcularea automat determin ca atunci cnd se modific valoarea unei celule care este referit n anumite formule sau funcii, imediat s se modifice i rezultatul dat de aceste formule sau funcii. b) Simulrile Simulrile au ca punct de plecare facilitatea programului tabelar de recalculare automat. Programele de calcul tabelar sunt considerate sisteme suport pentru decizii de nivel elementar, instrumente de analiz i previziune la ndemna oricrui manager. Orice formul sau funcie permite obinerea de rspunsuri rapide la ntrebri de tipul: Ce-ar fi dac? (What if?). Folosind datele din fig. nr. 2.1. s ne punem ntrebarea: "Care ar fi preul n lei pentru categoria de suprafa 1a dac preul n dolari ar fi 20?" Dar dac preul ar fi de 25$? Rspunsul l obinem n celula D26 dac n celula C26 introducem pe rnd valorile 20 i 25. Exist i posibilitatea construirii de modele de simulare mai complexe prin tehnici cum sunt: tabele de simulare cu una sau mai multe variabile i formule, cutare rezultat final (Goal Seek), utilizarea funciei de rezolvare (Solver), gestiunea scenariilor, simulri pe baz de grafice etc. c) Rearanjarea automat a liniilor/coloanelor dup actualizare Dup operaiunile de inserare sau tergere de linii i/sau coloane, sistemul face automat renumerotarea acestora i actualizeaz adresele celulelor utilizate n formule i funcii. Astfel, utilizatorul nu mai trebuie s verifice modelul actualizat. d) Afiarea datelor n diferite formate Programele de calcul tabelar lucreaz cu dou tipuri de date: numerice i de tip ir de caractere. Sistemul recunoate tipul datei dup primul caracter introdus de utilizator sau dup coninut (de exemplu, o liter sau un spaiu arat o dat ir de caractere, o cifr sau semnul - arat o dat numeric, @ sau = desemneaz o funcie; +, = sau ( indic o formul).

27

Datele de tip ir de caractere pot fi aliniate la stnga, la dreapta sau la centrul celulei. Versiunile noi permit formatarea datelor ca n procesoarele de texte (utilizarea fonturilor disponibile n mediul WINDOWS, asocierea de atribute - bold, italic, underline etc., modificarea mrimii fonturilor, scrierea textului pe mai multe rnduri n aceeai celul sau nclinat sub un anumit unghi, definirea i utilizarea stilurilor etc.). Datele numerice au implicit un format general, dar acesta poate fi modificat cu uurin de ctre utilizator (vezi fig.nr.2.4.).

Fig.nr. 2.4. Exemple de formate din EXCEL e) Implementarea de funcii financiare i statistice este un alt atu al programelor de calcul tabelar. Numrul de funcii variaz n funcie de versiune. Toate programele de calcul tabelar au implementate cele apte funcii statistice standard (AVERAGE medie aritmetic; COUNT - numrare; MAX - determinare maxim; MIN determinare minim; STD - abatere medie ptratic; SUM - nsumare; VAR dispersie). n plus, exist funcii statistice pentru baze de date, foarte utile n analize economice. Funciile financiare pot fi mprite n: funcii pentru analize economicofinanciare, funcii pentru calculul amortizrii, funcii pentru calculul anuitilor, alte funcii financiare. Versiunile mai recente dispun i de asisteni pentru funcii (Function Wizard) care ncorporeaz paii de parcurs n utilizarea acestora. f) Posibilitile de automatizare a operaiilor se concretizeaz n crearea i utilizarea de module de program prin intermediul macro-comenzilor. Astfel, prelucrrile repetitive pot fi aplicate rapid i eficient, fiind necesar definirea lor o singur dat. Limbajul de macro-comenzi este uor de utilizat i constituie un instrument util la dispoziia utilizatorilor. n versiunile mai recente ale programelor de calcul tabelar exist i posibilitatea nregistrrii automate a macro-comenzilor. g) Instrumentele de lucru orientate ctre utilizatorul final se ntlnesc la toate programele de calcul tabelar. Sunt oferite de cele trei module de baz: foaia de calcul, baza de date i modulul grafic, utilizatorul putnd lucra n acelai timp cu toate cele trei module. Graficele sunt uor de realizat. Astfel, dup introducerea datelor n foaia de calcul, cu ajutorul meniului corespunztor, utilizatorul definete graficul n forma dorit (liniar, histogram, histogram cumulat, diagram de structur sau combinaii ale acestora). Orice modificare a datelor n foaia de calcul este reflectat imediat de modificarea graficului (n Excel este posibil i modificarea invers). Noile versiuni de programe de calcul tabelar ofer peste 100 de tipuri de grafice care reprezint

28

combinaii ale celor patru tipuri de baz. n plus ofer i un asistent (Chart Wizard) care ghideaz utilizatorul, pas cu pas, n realizarea graficelor. h) Personalizarea modelelor definite se realizeaz prin definirea unor module de dialog, a unor linii de instrumente proprii, prin inserarea unor elemente grafice proprii sau importate etc. 2.3. Principii de realizare a aplicaiilor informatice n programele de calcul tabelar La proiectarea unei aplicaii utiliznd programele de calcul tabelar este bine s se aib n vedere respectarea anumitor principii i reguli pentru a avea sigurana c aplicaia realizat va putea fi folosit, n condiii normale, i de alte persoane dect proiectantul ei. 2.3.1. Reguli de respectat n proiectarea i utilizarea aplicaiilor n programele de calcul tabelar Proiectarea aplicaiilor utiliznd programele de calcul tabelar este realizat de cele mai multe ori de ctre utilizatorii nii. De aceea, obinerea unor aplicaii eficiente solicit respectarea urmtoarelor reguli 6: 1. n formule i funcii se recomand s nu se foloseasc ca argumente constantele. n general, orice formul sau funcie reprezint un potenial model de simulare. Utilizarea constantelor ca argumente elimin acest potenial. Reutilizarea modelului va solicita de fiecare dat rescrierea formulelor sau funciilor. Dac modelul de rezolvare presupune utilizarea unor constante, acestea vor fi plasate n celule distincte i vor fi apelate prin referine absolute. 2. Dimensionarea mrimii liniilor i coloanelor se face n funcie de datele cele mai semnificative i nu de construciile cu rol explicativ din antetul de linie sau coloan. Se recomand ca aceast operaiune s fie efectuat la terminarea construirii modelului n foaia de calcul. n mediul WINDOWS dimensionarea mrimii liniilor i coloanelor se poate realiza rapid cu ajutorul mouse-ului sau prin comenzi de tip Format/Row/AutoFit sau Format/Column/AutoFit. 3. Pentru lucrrile frecvente (facturi, ordine de plat, state de salarii etc.) se recomand utilizarea "abloanelor" oferite de sistem (Spreadsheet Solutions) sau definite de utilizatori n fiiere de tip Template (cu extensia .xlt n Excel). 4. Deplasarea n foaia de calcul, din raiuni de eficien, nu se va realiza doar prin utilizarea tastelor de tip sgeat (;;;), ci se pot utiliza taste care permit deplasarea mai rapid (PgUp, PgDown, Home), combinaii de taste (CTRL+ sau ;;, END+ sau ;;), butoanele de deplasare, respectiv liniile de deplasare vertical sau orizontal din fereastra de vizualizare a foii de calcul, se pot insera butoane suplimentare pentru deplasarea rapid de la o zon la alta din foaia de calcul sau se pot utiliza comenzile de tip GOTO sau GOTO Special, combinate cu atribuirea de nume diferitelor zone din modelul de rezolvare. 5. Cnd se lucreaz cu registre de calcul se recomand atribuirea de nume semnificative fiecrei foi ale acestora, n funcie de componentele modelului de rezolvare (de exemplu, n loc de Sheet1, Sheet2, Sheet3, , Sheetn se vor folosi denumiri, cum ar fi: Meniu, Preluare date, Centralizare, Tiprire, Help etc. ). 6. nainte de a trece la utilizarea modelului realizai salvarea acestuia, prin comenzi de tip SAVE, ntr-un fiier cu nume adecvat lucrrii (Facturi, Stat de plat salarii, Casa, Balan de verificare, Bilan etc.). Altfel, riscai s pierdei tot ce ai
6

Oprea, D., Airinei, D., Meni, G., Dumitriu, F., Aplicaii cu macro-uri LOTUS 1-2-3, Editura Policromia, Piatra Neam, 1995, pp. 36-39 29

lucrat dac la execuie sistemul se blocheaz sau intervine un incident neprevzut. Pentru mai mult siguran, putei realiza chiar salvri periodice. Dac lucrai pe un calculator utilizat de mai multe persoane, atunci e recomandat s avei un subdirector propriu n care s pstrai toate lucrrile. 7. Pentru aplicaiile mai complexe este de preferat s se utilizeze mai multe foi de calcul, dect s se ncerce proiectarea tuturor elementelor ntr-un singur centralizator. Astfel, se evit alterarea componentelor modelului de rezolvare la actualizarea prin inserarea de linii sau coloane. 8. ntr-un model definit ntr-un registru de calcul se protejeaz toate zonele definite, n afara zonelor rezervate datelor de intrare. Dac zonele sunt protejate nu se mai pot face nici un fel de modificri asupra coninutului. Se reduce, astfel, riscul deteriorrii voluntare sau involuntare a modelului de rezolvare. n Excel, de exemplu, protecia datelor se realizeaz n dou etape: a) se deprotejeaz zona ocupat de datele de intrare, folosind Format/Cells/Protection/Locked b) se protejeaz foaia de calcul sau registrul de lucru utiliznd comanda Protection din meniul Tools. Confidenialitatea datelor poate fi asigurat i prin folosirea parolelor i a tehnicii ascunderii de linii sau coloane. (n Excel, de exemplu, acunderea de linii i coloane se realizeaz selectnd din meniul Format comenzile Row/Hide sau Column/Hide, iar stabilirea de parole se poate realiza la salvarea documentului). 9. Pentru lucrrile mai complexe se recomand utilizarea macro-comenzilor prin limbajul de macro-comenzi disponibil. Prelucrrile repetitive sunt astfel ncorporate n programe ce se apeleaz ori de cte ori este necesar. Majoritatea versiunilor din programele de calcul tabelar ofer faciliti de nregistrare automat a macrocomenzilor. 10. Foarte multe din problemele economice sunt deja rezolvate n programele de calcul tabelar, utilizatorul trebuind doar s furnizeze corect argumentele unor funcii sau s apeleze la modulele de asisten (de tip Wizard) (de exemplu, calculul dispersiei, calculul mediei aritmetice, determinarea trendului unui fenomen, determinarea ratei interne de rentabilitate etc.) 2.3.2. Etapele proiectrii aplicaiilor n programele de calcul tabelar Programele de calcul tabelar au determinat orientarea majoritii aplicaiilor informatice ctre utilizatorul final. Chiar dac programele de calcul tabelar ofer soluii rapide de rezolvare a problemelor nu trebuie neglijate aspectele de conceptualizare, de definire a unui model de rezolvare valabil pentru mai multe situaii concrete. De aceea, realizarea de aplicaii eficiente presupune parcurgerea urmtoarelor etape (vezi fig. nr. 2.5): 1. analiza problemei i conceperea modelului foii de calcul; 2. construirea modelului de foaie de calcul; 3. utilizarea (testarea) modelului; 4. generalizarea modelului cu macroprograme. 1. Conceperea modelului foii de calcul este o etap manual ce se concretizeaz n obinerea pe hrtie a modelului foii de calcul. Conceperea modelului are n vedere identificarea datelor primare i a datelor calculate, definirea relaiilor de calcul, realizarea machetei pentru foaia de calcul, definirea relaiilor ntre liniile i coloanele tabelei (subtotaluri, totaluri, alte rezultate). Sunt delimitate toate zonele pentru datele de intrare, pentru datele calculate, blocurile folosite pentru realizarea graficelor necesare.

30

2. Etapa de construire a modelului are la baz modelul conceput n prealabil. Operaiile care se execut n cadrul acestei etape sunt: ncrcarea produsului program de calcul tabelar; definirea mrimii coloanelor, demarcarea liniilor, formatarea celulelor; introducerea antetului pentru fiecare linie i coloan; introducerea formulelor de calcul i a funciilor pentru fiecare celul n care intervin calcule; personalizarea modelului; protejarea componentelor modelului (cu excepia zonelor rezervate datelor de intrare); salvarea modelului pe suport magnetic (dischet sau disc dur). 3. Utilizarea (testarea) modelului se realizeaz parcurgnd urmtoarele operaii: ncrcarea produsului - program de calcul tabelar; ncrcarea modelului; introducerea datelor; analiza rezultatelor i realizarea eventualelor corecii; realizarea copiilor de siguran; tiprirea la imprimant a rezultatelor. 4. Generalizarea modelului cu macroprograme Dup testarea modelului i corectarea eventualelor erori se realizeaz o automatizare a execuiei operaiilor repetitive prin elaborarea i testarea unor macroprograme n conformitate cu specificaiile aplicaiei.

Fig nr. 2.5 Etapele de rezolvare a unei probleme utiliznd programele de calcul tabelar

31

2.3. Categorii de funcii n programele de calcul tabelar Funciile din programele de calcul tabelar reprezint formule des utilizate, prin care se poate executa o mare varietate de calcule, n mod rapid i comod. Se pot efectua calcule financiare, matematice, statistice, cu iruri de caractere, cu date calendaristice etc. De asemenea, funciile se pot folosi pentru crearea de expresii condiionale sau pentru efectuarea de cutri n tabele. Alturi de formule i macrocomenzi, funciile asigur performane sporite programelor de calcul tabelar, mai ales n simulri. Deoarece fiecare program de calcul tabelar, respectiv fiecare versiune, are anumite particulariti ne vom opri la o prezentare de principiu a principalelor categorii de funcii din EXCEL. n EXCEL funciile sunt precedate de semnul =. Fiecare funcie are o anumit sintax. Dac sintaxa funciei nu este respectat, sistemul nu o poate interpreta. Funciile din EXCEL au urmtorul format general =FUNCIE() sau =FUNCIE(argument_1,argument_2,...,argument_n) unde FUNCIE reprezint numele funciei argument_1, argument_2,..., argument_n reprezint datele pe care funcia le va utiliza n calcule. Dac funcia are n sintax argumente, acestea trebuie s fie incluse ntre paranteze rotunde. Argumentul este o valoare utilizat de o funcie pentru a executa operaii i calculaii. Tipul de argument utilizat de o funcie este specific funciei respective. Argumentele precizeaz obiectul funciilor. De exemplu, n funcia =SUM(C10:C15), argumentul C10:C15 precizeaz c se vor aduna valorile ntlnite n grupul de csue C10:C15. Argumentele pot fi valori numerice, iruri de caractere, referine de csue i condiii. Cnd argumentul este o valoare numeric se poate utiliza un numr, o formul (expresie) de tip numeric, un nume de grup sau adresa unei csue care conine un numr sau o formul de tip numeric. Cnd argumentul este de tip ir de caractere se poate utiliza o constant tip ir de caractere (orice secven de litere, cifre sau alte caractere, delimitat Ia stnga i la dreapta de caracterul (ghilimele)), o formul de tip ir, un nume de grup sau adresa unei csue care conine un ir sau o formul de tip ir. Cnd argumentul este o referin de csu, se poate utiliza un nume de grup sau o adres. Cnd argumentul este o condiie se folosete o expresie logic (o formul n care se utilizeaz un operator de comparaie, adic >, <, =, , >=, <=, <>) sau un nume de grup ori o adres de csu care conine o expresie logic. La introducerea funciilor trebuie s inem cont de urmtoarele recomandri: 1) Numele funciei trebuie s fie precedat de simbolul =. 2) Indiferent de tipul literelor folosite la tastarea numelui funciei, mici sau mari, sistemul le va afia cu majuscule. 3) Nu se las spaii ntre numele funciei i argumente i nici ntre argumente. 4) ntotdeauna includei argumentele funciilor ntre paranteze rotunde. 5) O funcie poate include ca argument o alt funcie. 6) Cnd o funcie devine argument al altei funcii fiecare dintre ele trebuie s aib argumentele cuprinse ntre paranteze.Exemplu: =IF(SUM(A1:A5)>0,B1,B2). 7) Dac sunt mai multe argumente, acestea se separ prin , (virgul) sau ; (punct i virgul), corespunztor delimitatorului stabilit. 8) Sistemul atribuie valoarea zero tuturor csuelor libere ale cror adrese sunt folosite ca argumente n funciile financiare, logice sau matematice. Funciile pot fi folosite ca argumente pentru alte funcii. Cnd o funcie este folosit ca un argument sau este imbricat, trebuie s ntoarc acelai tip de valoare ca i cel pe care l folosete argumentul. Dac o funcie imbricat nu ntoarce tipul corect de

32

valoare, Microsoft Excel va afia o valoare de eroare #VALUE!. De exemplu, formula urmtoare utilizeaz o funcie AVERAGE imbricat i o compar cu valoarea 200. Comparaia trebuie s ntoarc TRUE sau FALSE, pentru c acesta este tipul de valoare cerut pentru primul argument dintr-o funcie IF. = IF(AVERAGE(A2:A5)>200, SUM(B2:B5),0) O formul poate conine pn la apte nivele de funcii imbricate. Cnd Funcia B este folosit ca un argument n Funcia A, Funcia B este o funcie de nivel doi. Dac Funcia B conine Funcia C ca un argument, Funcia C va fi o funcie de nivel trei. Putei folosi Past function din linia de instrumente standard pentru a imbrica funcii ca argumente. De exemplu, putei insera Funcia B ca un argument al Funciei A dac facei clic pe sgeata vertical din bara de formule. Dac dorii s continuai introducerea de argumente pentru Funcia A, facei clic pe numele Funciei A n bara de formule. n Excel, funciile se pot grupa n urmtoarele categorii: 1) Funcii statistice (Statistical) execut calcule statistice asupra unor serii de date; 2) Funcii financiare (Financial) calculeaz mprumuturi, anuiti sau fluxuri financiare; 3) Funcii logice (Logical) calculeaz rezultatul unei expresii condiionale; 4) Funcii matematice i trigonometrice (Math & Trig) execut o mare varietate de calcule cu valori numerice; 5) Funcii speciale (execut diverse operaii, cum ar fi: cutarea unei valori ntrun tabel sau oferirea de informaii despre o anumit csu) (Lookup & Reference, Information); 6) Funcii pentru date calendaristice i timp (Date & Time) calculeaz valorile ce reprezint data calendaristic i timpul. 7) Funcii pentru baze de date (Database) efectueaz calcule statistice i interogri asupra bazelor de date EXCEL 8) Funii tip ir de caractere (Text) lucreaz cu iruri (texte, expresii tip ir) sau constante tip ir. 2.4. FACILITI GRAFICE N PROGRAMELE DE CALCUL TABELAR Un alt atu al programelor de calcul tabelar este facilitatea de generare automat de reprezentri grafice pe baza datelor din foaia de calcul. Se pot crea diagrame ca obiecte grafice ncapsulate ntr-o foaie de calcul sau se poate lucra cu o diagram ntr-o foaie separat a agendei de lucru (foaie de tip Chart). Putei utiliza asistentul Chart Wizard pentru a v ghida pas cu pas prin procesul de creare a unei diagrame. Pentru a desena o diagram, programul utilizeaz reguli precise bazate pe modul n care sunt configurate datele. Orientarea datelor determin care celule sunt utilizate pentru marcarea axei categoriilor i a axei valorilor i care celule sunt folosite pentru etichetele legend. n majoritatea cazurilor, regulile corespund aezrii standard n pagin a datelor, astfel nct diagramele EXCEL se traseaz corect, fr orice alt intervenie. Sub mediul de lucru Windows se ntlnesc mai multe tipuri de grafice, att 2D, ct i 3D. n fig. nr. 2.6 sunt prezentate principalele tipuri de grafice ntlnite n EXCEL 7, fiecrui tip corespunzndu-i mai multe subtipuri de grafice.
Formatul prestabilit pentru diagrame este acela de diagram cu coloane i legend. Dac nu selectai un anumit tip de diagram, Excel va aplica acest format noii diagrame. 33
7

Dup definirea datelor surs ale reprezentrii grafice, etapele realizrii de grafice, utilizate i de asistentul de grafice (Chart Wizard) sunt urmtoarele: 1. Alegerea tipului de grafic (vezi fig. nr. 2.7). Se pot utiliza tipurile standard (Standard Types) sau tipuri personalizate (Custom Types); 2. Alegerea subtipului de grafic (vezi fig. nr. 2.7). Se pot realiza diagrame bi sau tridimensionale; 3. Selecia zonei de celule care conine datele de exprimat grafic, utiliznd etichetele Data Range i Series de la pasul 2 al asistentului Chart Wizard; 4. Precizarea informaiilor despre dispunerea seriilor de date (pe linie, pe coloan). Se utilizeaz opiunea Series in de la pasul 2 al asistentului Chart Wizard; 5. Rafinarea graficului (specificarea titlului graficului i a titlului pentru axa X i Y, a reelei de linii, a legendei, stabilirea de etichete etc.); 6. Precizarea locului unde va fi dispus graficul: ntr-o foaie de calcul a agendei e lucru sau ntr-o foaie de tip Chart. 7. Executarea unui clic pe butonul Finish, graficul aprnd n forma sa final n foaia de calcul. Se pot crea dou feluri de diagrame utiliznd programul EXCEL: nglobate i care apar ntr-o foaie de diagrame. Diagramele nglobate sunt necesare atunci cnd se dorete s fie incluse unele lng altele o diagram i datele pe baza crora a fost realizat aceasta, ca de exemplu ntr-un raport. Diagramele reprezentate n foi de diagrame vor fi denumite Chart1, Chart2 .a.m.d. O diagram este un obiect creat i el poate fi plasat n alt poziie cu tehnica clic & drag, micorat, mrit sau eliminat din foaia de calcul. Activarea unui grafic n vederea efecturii unor modificri, ca de exemplu: schimbarea tipului de grafic, a titlului sau a altor elemente constitutive, se face cu un clic n interiorul chenarului ce ncadreaz graficul.

Fig. nr. 2.6.Tipuri de grafice EXCEL i subtipurile graficului de tip Column 2.5. Simulri utiliznd programele de calcul tabelar Programele de calcul tabelar pot fi interpretate ca sisteme de sprijinire a deciziilor elementare. Practic, ele preiau o parte din sarcinile decidentului, sarcini care pot fi mai mult sau mai puin structurate n funcie de nivelul la care se iau deciziile. Modelele analitice specifice unui sistem suport pentru decizii implementate ntr-un program de calcul tabelar sunt analiza de tipul "Ce se ntmpl dac?" i modelele de simulri. Simulrile reprezint o particularizare a analizei "Ce se ntmpl dac?"

34

(What if?). Simulrile au ca punct de plecare recalcularea automat, considerat cea mai simpl metod de simulare. Ce se ntmpl dac cheltuielile s-ar reduce cu 10% ct ar fi profitul i rata rentabilitii? Mai mult, exist posibilitatea construirii de modele de simulare mai complexe prin tehnici cum sunt: tabele de simulare cu una sau mai multe variabile sau formule, cutare rezultat final (Goal Seek), utilizarea funciei de rezolvare (Solver), gestiunea scenariilor. De asemenea, se pot realiza simulri pe baz de grafice (utilizatorul rectific reprezentarea grafic dup dorin, iar sistemul modific datele n mod corespunztor). 2.6. Baze de date Excel Excel este un program de calcul tabelar ce poate fi utilizat i pentru crearea i gestionarea bazelor de date (de exemplu, liste cu adresele clienilor, inventarul produselor etc.), capacitile oferite n acest domeniu fiind remarcabile. n Excel, o baz de date este o list creat pentru a organiza i gestiona grupuri de date ntr-o foaie de lucru. Coloanele din domeniul bazei de date sunt cunoscute sub denumirea de cmpuri, iar rndurile sub denumirea de nregistrri. Rndul de sus al bazei de date conine numele cmpurilor. Modulul pentru baze de date din programele de calcul tabelar asigur gestionarea bazelor de date, permind crearea, actualizarea i interogarea acestora, precum i efectuarea unei complexe game de operaiuni asupra structurii nregistrrilor. O baz de date este format dintr-un grup de date ntre care exist o legtur, grupul fiind organizat n rnduri i coloane ale unui tabel. Aceeai foaie de calcul poate s conin mai multe baze de date, fiecare dintre ele avnd nregistrri (rnduri) i cmpuri (coloane). De fapt, o nregistrare este o colecie de date despre un obiect, fenomen sau proces al bazei, iar un cmp este o caracteristic, un atribut al tuturor nregistrrilor bazei de date. Aadar, ntr-o baz de date fiecare linie este o nregistrare i fiecare coloan este un cmp, cu meniunea c prima linie a tabelului conine numele cmpurilor, cte unul pentru fiecare coloan. Prin nume se face referirea la cmpurile bazei. Crearea unei baze de date presupune doar introducerea numelor cmpurilor n prima linie ocupat de baza de date i apoi introducerea valorilor asociate n urmtoarele linii. Actualizarea bazei de date se realizeaz astfel: Adugarea de nregistrri presupune doar introducerea de noi valori dup ultima linie completat cu date. Inserarea n interior necesit utilizarea comenzii de inserare linie n poziia dorit, urmat de completarea cu date. tergerea de nregistrri nseamn de fapt tergerea de rnduri din foaia de calcul. Modificarea coninutului bazei de date utilizeaz facilitile de editare ale programului de calcul tabelar. Modificarea structurii bazei de date presupune adugarea de noi cmpuri, adic adugarea de noi coloane i tergerea cmpurilor, adic tergerea de coloane. n Microsoft Excel putei folosi cu uurin o list ca o baz de date. Cnd executai activiti specifice bazelor de date, ca de pild cutare, sortare sau subtotalizare date, Microsoft Excel recunoate automat lista ca o baz de date i folosete urmtoarele elemente ale listei pentru a organiza datele: Coloanele din list sunt cmpurile din baza de date. Etichetele coloanelor din list sunt numele cmpurilor n baza de date. Fiecare rnd din list este o nregistrare n baza de date.

35

CAPITOLUL 3 BAZE DE DATE I SISTEME DE GESTIUNE A BAZELOR DE DATE 3.1 Concepte utilizate n studiul bazelor de date i al sistemelor de gestiune a bazelor de date 3.2. Modele de structurare a datelor n baze de date 3.3. Sisteme de gestiune a bazelor de date 3.4. Protecia i securitatea bazelor de date 3.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. 3.1. Concepte utilizate n studiul bazelor de date i al sistemelor de gestiune a bazelor de date 3.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 utilizator 8. Specific metodei prelucrrii prin fiiere, ilustrat n fig. nr. 3.1. 9, 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.
D ata1 D ata2 D ata3 D ata2 D ata4 D ata3 D ata1 D ata2 DATE ... FI IE R 3 D ata5 ... F I IE R E Prelucrare 3 ... FI IE R 2 Prelucrare 2 FI IE R 1 Prelucrare 1 R aport 1 R aport 2 R aport 3 R aport 4 IE IR I

PRELUCRRI

Fig. nr. 3.1.Organizarea datelor n fiiere 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 dintrun 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.
8 9

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 36

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 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. 3.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.

37

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 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 .3.2. Structura unei baze de date Conceptul de baz de date a aprut n 1964 n cadrul primului raport CODASYL 10 prezentat la lucrrile unei Conferine pe probleme de limbaje de gestiune a datelor Development and Management of Computer centered datebase. 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 programe 11. 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/realizare 12. Prin entitate se nelege un obiect concret sau abstract (operaie economic, mijloc economic etc.) reprezentat prin proprietile sau nsuirile sale. Orice
10 11

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 12 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
38

proprietate poate fi exprimat printr-o pereche atribut-valoare sau caracteristicrealizare. 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. 3.1: Entitate Tabelul nr. 3.1. Elemente specifice bazelor de date Caracteristici (atribute) Realizri (valori) Cod_produs 152 Denumire_produs Pantofi Unit_ms Pereche Pre_ unitar 1150000 Cantitate 100 Nr._factur 2452 Data_recepiei 24-11-2004

Produs

O baz de date trebuie s satisfac cinci condiii eseniale 13: 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:
13

Morjon, J., Principes et conception dune base de donnes relationnelle, Les Editions dorganisation, Paris, 1992, p. 20 39

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. 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.

40

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.3.3. 14
Utilizator A1 Aplica ie Utilizator A2 Comenzi auto nome Im agine A (ni vel extern) IN TE R FA A A Schema conceptual (global ) Utilizator B1 Aplica ie Schema extern B Utilizator B2 Comenzi auto nome . ... .

Schema extern A

Im agine B (ni vel extern)

IN TE R F A A B Si stem de gesti une a bazei de d ate

Im agine global (ni vel glo bal) IN TE R FA A

Schema intern

B AZA D E D A TE M E M O R AT P E DIS C

Fig. nr.3.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 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
14

Fotache, M., Baze de date relaionale. Organizare, interogare i normalizare, Editua Junimea, Iai, 1997, p.32 41

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. 3.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. 15 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. 3.4.

Cole cii dedate Cole cii dedate Cole cii dedate Cole cii dedate

Fig.3.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.
15

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

3.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. Componentele unui depozit de date sunt urmtoarele: 16 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;

16

Fotache, M., Op. cit., p. 56 43

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 ntr-un produs atotcuprinztor, ceea ce unii au reuit ntr-o oarecare msur. 17 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 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
17

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

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 de-a 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. 3.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 ;

45

 exploatarea i ntreinerea bazei de date 18. 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. n literatura de specialitate se ntlnete i concepia potrivit creia proiectarea unei baze de date este un proces n doi pai 19: 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.
vezi Lungu, I. i colab. ,Baze de date. Organizare, proiectare i implementare, Editura ALL, Bucureti, 1995, p. 26. 19 Pratt, P.J., Adamski, J.J., Database Systems. Management and Design, Boyd&Fraser, Boston, 1991, p. 285 46
18

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; 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

47

transpus ntr-un model al datelor care are caracteristicile proprii SGBD-ului ales de proiectant. Proiectarea structurii bazei de date implic urmtoarele activiti 20: 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: 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

20

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

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 CODASYL 21) 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 (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.

21

abreviere de la "Conference on Data Systems Languages" 49

3.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.3.5 )
X1 X2
. .

Y1 Y2
. .

Xn Domeniu

Yn Codome niu

Fig. 3.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. 3.6)
X1 Y1 Y2 .Y3. Y4 Y5 Codome niu

X2 Dome niu

Fig. 3.7 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.3.8)
X1 X2 X3 Dome niu Codome niu Y

Fig. 3.8. Relaia n-1

50

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. 3.9):
X1 Y1 Y2 .Y3. Y4 Codome niu

X2 Dome niu

Fig.3.9.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 sunt supuse prelucrrilor cu un grup de operatori de baz cu o semantic predefinit formeaz un anumit tip de structur. Principalele tipuri de structuri sunt 22: 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. 3.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,
22

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

 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. 3.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. 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/05 1259800 SRL 0 Beta SA Apelor 5 Bacu Beta SA 14870 14/02/05 3265000 0 Gama Viilor Iai Alfa SRL 24550 22/02/05 2987500 SA 56 0 Gama SA 18960 28/02/05 5420000 0 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 printe-copil 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

52

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.3.11 este prezentat un exemplu de model ierarhic:

FACTURI-EMISE Factura 1
Produs B

Factura 2
Produs B Produs D Produs C

Factura 3
Produs A Produs E Produs F

Produs A

Fig. nr.3.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. 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. 3.12. Modelul reea Dup cum se observ din figura nr.3.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.

53

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, descris mai sus (vom reine doar 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 3.13. 2546 13/02/05 23650000 Alfa SRL Unirii 2 Iai R12548171 3560 15/02/05 18790000 Beta SA Ploii 21 Bacu R19857144 2478 1266 Gama SA Viilor 50 Iai R19874001 1687 21/02/05 Fig. nr. 3.13. Modelul entitate-asociaii 18971000 18/02/05 20/02/05 36540000 14587000

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
54

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 jos n figura

FURNIZORI Nume ntocmete Adres Localitate Cod_fiscal

CUMPRARE

FACTURI Numr este Dat ntocmit Valoare

Metoda MERISE de proiectare a bazelor de date propune urmtoarea reprezentare grafic

FURNIZORI Nume Adres Localitate Cod_fiscal

CUMPRARE

FACTURI Numr Dat Valoare

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. 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

55

binare,

exist

patru

cardinaliti

posibile

(vezi

fig

3.14

3.16):

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.3.14 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 3.15). 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. 3.15 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.

56

x1 x2 x3 x4 x5 T I P n la 1

y1 y2 y3

x1 x2 x3 x4

y1 y2 y3

T I P n la n

Fig nr .3.16 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.3.17).

CLIENTI Nume Adresa Localitate Cod_fiscal

FACTURI

0,n

VANZARE

1,1 Numar

Data Valoare

Fig. nr.3.17 Diagrama din figura 3.17 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. 3.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.

57

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 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

58

4.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); 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 operaii 23: 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) 24 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;
23 24

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

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; 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 poate fi prezentat ca n figura 3.18 :
Adminis tratorul BD S tructura BD Utilizatori P rogramede aplicaii

LDD

LMD

P GBD

Ut. ntre ine re

Comp. control S GBD

Baza de date

Fig. 3.18. Structura general a unui SGBD 3.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) 25. 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.
25

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

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 (sub-schemele) pentru aplicaiile utilizator; 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 astfel 26: 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 categorii 27: 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
26 27

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

informaii, provocnd daune proprietarilor bncilor de date. Aceti utilizatori sunt cunoscui sub numele de hacker-i. 3.4. 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); 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:

62

 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). Accesul la resursele sistemului poate avea loc prin faciliti ca parole, profile utilizator sau matrici ale drepturilor de acces (privilegii, reguli de autorizare).

63

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). 3.5. 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
64

impunerea i meninerea unor definiii ale datelor i a unor standarde mbuntirea performanelor bazei de date asigurarea mijloacelor de instruire a utilizatorilor 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

65

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 - 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

66

Capitolul 4. MODELUL RELAIONAL AL DATELOR 4.1. Elementele modelului relaional 4.2. Algebra relaional 4.3. Studiul dependenelor funcionale 4.4. Normalizarea bazelor de date relaionale 4.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

67

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; 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. Etajere Scaune Cuiere Dulapuri Salopete Manusi Ochelari Birouri UM buc buc buc buc buc buc buc buc PU
1 350000

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

Cantitate 12 10 5 4 14 12 10 3

schema relatiei

311 291 321 312 357 345 314 291

valoarea din domeniu

950000 470000 4500000 2 50000 180000 150000 1500000

tuplu n-tupluri

Fig. nr.4.1 Elementele modelului relaional Elementele de baz ale organizrii datelor sunt prezentate comparativ, formal, uzual sau fizic n Tabelul nr. 4.1. Tabelul 4.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;

68

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); valorile non-nule valorile atributului sau ale ansamblului de atribute ce desemneaz 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 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 comportament 28). 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;
28

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. 69

 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 Nume_client Localitate FACTURI_EMISE Data_factur Valoare

Cod_client

Cod_fiscal

Numr_factur

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 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 Un sistem de gestiune a bazelor de date Regula fundamental 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 relaional sunt reprezentate explicit ca informaiei valori n tabele R2 Regula accesului Orice valoare a oricrui atribut din cadrul oricrei relaii trebuie s poat fi regsit prin specificarea garantat la date numelui relaiei, a numelui atributului i a valorii cheii primare. R3 SGBD-ul asigur un suport sistematic pentru Regula reprezentrii tratamentul valorilor nule (date necunoscute sau informaiei necunoscute neaplicabile), diferit de valorile prestabilite i independent de orice domeniu R4 Regula catalogului Descrierea bazei de date i a componentelor sale este realizat la nivel logic sub form de tabele, dinamic on-line 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 datelor cu ajutorul cruia s se interogare poat crea relaii i vederi (perspective asupra bazei de date), s se poat actualiza i regsi date etc. R6 Este obligatorie existena unui mecanism de Regula actualizrii determinare a posibilitii de actualizare sau nu a vederilor unei tabele virtuale (vederi). R7 Regula limbajului de Limbajul de manipulare a datelor nu trebuie s

70

conduc utilizatorul la explorarea relaiilor tuplu cu tuplu, pentru a regsi datele dorite. R8 Regula independenei Este necesar ca aspectele fizice ale stocrii sau accesului la date s fie separate de aspectele fizice a datelor logice (de organizare) ale datelor. R9 Regula independenei Este necesar ca modificrile asupra datelor s nu afecteze n nici un mod funcionarea programelor logice a datelor de aplicaie i nici operaiile de manipulare a datelor. R10 Regula independenei Regulile de integritate a datelor trebuie s fie datelor din punctul de definite n catalogul de sistem, independent de programele de aplicaie. vedere al integritii R11 Regula independenei Distribuirea datelor pe mai multe calculatoare din datelor din punctul de cadrul unei reele nu trebuie s afecteze programele de aplicaie. vedere al distribuirii R12 Regula de Atunci cnd SGBD posed un limbaj de nivel inferior (cod-main sau de asamblare), acesta nu nonsubversiune 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; 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. nivel nalt 4.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).

71

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 CLIENI 2. 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: 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
72

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. 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/05 Delta SRL 23000800 15780 15/02/05 Gama SA 25640000 47100 17/02/05 Delta SRL 87900000 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

73

Clieni2. Clieni2 Clieni2. Facturi. Facturi. Facturi. Facturi. Nume_clie Localitate Cod_fiscal Nr_factur Data Nume_clien Val_factu nt t r Alfa SRL Iai R19548710 12540 12/02/05 Delta SRL 23000800 Alfa SRL Iai R19548710 15780 15/02/05 Gama SA 25640000 Alfa SRL Iai R19548710 47100 17/02/05 Delta SRL 87900000 Gama SA Iai R19852201 12540 12/02/05 Delta SRL 23000800 Gama SA Iai R19852201 15780 15/02/05 Gama SA 25640000 Gama SA Iai R19852201 47100 17/02/05 Delta SA 87900000 Delta SRL Bacu R17256007 12540 12/02/05 Delta SRL 23000800 Delta SRL Bacu R17256007 15780 15/02/05 Gama SA 25640000 Delta SRL Bacu R17256007 47100 17/02/05 Delta SRL 87900000 Omega SA Roman R17466540 12540 12/02/05 Delta SRL 23000800 Omega SA Roman R17466540 15780 15/02/05 Gama SA 25640000 Omega SA Roman R17466540 47100 17/02/05 Delta SRL 87900000 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) Tabela R2 va arta astfel: Nume_client Alfa SRL Anca SRL Localitate Iai Iai Cod_fiscal R19548710 R19852553

74

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/05 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: < .> .>=.<=..

75

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. Echi-jonciunea 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 23000800 25640000 12560000 87900000

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

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 47 100 17/02/00 1000 87900000 1001 Gama SA Iai 12540 12/02/00 1001 23000800 1001 Gama Sa Iai 15780 15/02/00 1001 25640000 1002 Delta SRL Bacu 21 630 10/02/00 1002 12560000 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:

76

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. 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.

77

4.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. 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: XY 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

78

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. 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. 4.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 datelor 29. 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
29

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

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 10547 10548 10549 10550 10551 Data 10/02/05 10/02/05 11/02/05 12/02/05 12/02/05 12/02/05 12/02/05 13/02/05 14/02/05 14/02/05 15/02/05 15/02/05 Nume_client Delta SRL Gama SA Delta SRL Alfa SRL Diana SRL Popa SNC Omega SRL Iulius SRL Toni SRL Anca SRL Select SA Anca SRL Localitate Iai Iai Iai Vaslui Pacani Iai Bacu Iai Bacu Roman Bacu Roman Cod_fiscal R19548710 R19848451 R19548710 R19852201 R19674531 R12323432 R17256007 R19456700 R18790654 R17466540 R13666589 R17466540 Val_factura 23000800 25640000 87900000 43560800 35640000 17900000 13000800 35640000 36500000 41000800 38640000 32900000

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 30, 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
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 80
30

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. 4.2. 31.
1FN 2FN 3FN BCNF 4FN 5FN DMV DJ DF

Fig. nr. 4.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). 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
31

Filip, M., Grama, A., Op. cit., p.205 81

(Nr_fact, Cod_cl) Nume_client (Nr_fact, Cod_cl) Localitate (Nr_fact, Cod_cl) Strada (Nr_fact, Cod_cl) Jude (Nr_fact, Cod_cl) Cod_post (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 (2) (3) (4) (5) (6) (7) 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. 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 ne-cheie 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:

82

Cod_cl

CLIENTI Nume_client

Cod_post

Cod_post

CODP Strada 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.

83

Capitolul 5. LIMBAJE DE INTEROGARE A BAZELOR DE DATE SQL 5.1. SQL - Evoluie i performane 5.2. Comenzi pentru descrierea datelor; 5.3. Comenzi pentru interogarea bazelor de date 5.4. Comenzi pentru actualizarea bazei de date 5.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 sa 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 l-au 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" SQL89, care mai este denumit i SQL-1.

84

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 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 SGBD-urilor. 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 multi-utilizator 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 curent este SQL-99, denumit iniial SQL3. Principalele orientri ale SQL3 vizeaz 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. 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;
85

 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; 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 clientserver. 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, DOWHILE 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.

86

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 TIMESTAMP: an, lun, zi, ora, minutul, secunda, plus o fraciune zecimal dintr-o secund. Principalele comenzi ale SQL, care se regsesc, ntr-o form sau alta, n multe dintre SGBDR-urile actuale sunt urmtoarele: Tabelul nr. 5.1. Clase de comenzi SQL Comand Pentru manipularea datelor SELECT INSERT DELETE UPDATE Scop Extragerea datelor din baza de date Adugarea de noi linii ntr-o tabel tegerea de linii dintr-o tabel Modificarea valorilor unor atribute

Pentru definirea bazei de date Adugarea unei noi tabele n baza de date CREATE TABLE tergerea unei tabele din baz DROP TABLE Modificarea structurii unei tabele ALTER TABLE Crearea unei tabele virtuale CREATE VIEW tergerea unei tabele virtuale DROP VIEW Pentru controlul accesului la BD Acordarea unor drepturi pentru utilizatori GRANT Revocarea unor drepturi pentru utilizatori REVOKE Pentru controlul tranzaciilor Marcheaz sfritul unei tranzacii COMMIT Abandoneaz tranzacia n curs ROLLBACK 5.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.

87

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 CodClient DataFactur ValoareTotal TVAColectat NrFactur 111111 1003 17.06. 2004 17000000 2719286 111112 1001 17.06.2004 2850000 455042 111113 1004 18.06.2004 5850000 934034 111114 1003 18.06.2004 28500000 4550420 111115 1008 18.06.2004 35700000 5700000 111116 1008 19.06.2004 8700000 1389076 111117 1006 20.06.2004 11000000 1756303 111118 1007 23.06.2004 15000000 2394958 111119 1005 24.06.2004 47250000 7544118 111120 1003 24.06.2004 3000000 478992 111121 1001 24.06.2004 4250000 678571 111122 1007 24.06.2004 8750000 1397059 111123 1006 25.06.2004 6600000 1053782 111124 1004 25.06.2004 38500000 6171008 111125 1003 30.06.2004 12800000 2051761 111126 1002 01.07.2004 54250000 8661765 Fig. nr.5.1. Baza de date utilizat n exemple 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.

88

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) 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 sau creat tabele intermediare, temporare. tergerea unei asemenea tabele, denumit de exemplu TEMP1, se declaneaz prin comanda: DROP TABLE TEMP1 5.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

89

Execuia unei fraze SELECT se concretizeaz 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) tabeleirezultat; 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) unei proiecii (SELECT - Ci) unui produs cartezian (FROM - R1 R2 ... Rm) 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. Exemplu

90

Care este, pentru fiecare factur emis, valoarea fr TVA ? SELECT NrFactur, ValoareTotal TVAColectata AS ValoareFaraTVA FROM FACTURIEMISE Tabela rezultat din fig. nr. 5.2 va conine dou atribute: NrFactur i ValoareFaraTVA. Ultimul este un cmp calculat. Rezultat: NrFactur ValoareFaraTVA 111111 14285714 111112 2394958 111113 4915966 111114 23949580 111115 30000000 111116 7310924 111117 9243697 111118 12605042 111119 39705882 111120 2521008 111121 3571429 111122 7352941 111123 5546218 111124 32478992 111125 10798739 111126 45588235 Fig. nr. 5.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 * 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.

91

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 Visual FoxPro nu dispune nici de operatorul MINUS, nici de EXCEPT, funciunea lor fiind asigurat prin combinarea altor operatori, precum IN sau EXISTS. 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.2004 prezint valoarea mai mare de 30000000 lei ? SELECT * FROM FACTURIEMISE WHERE DataFactur > {23.06.2004} AND ValoareTotala > 30000000 Rezultat: DataFactur ValoareTotal TVAColectat NrFactur CodClient 111119 1005 24.06.2004 47250000 7544118 111124 1004 25.06.2004 38500000 6171008 111126 1002 01.07.2004 54250000 8661765 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.2004 i care au valoarea cuprins ntre 30000000 i 40000000 lei ?
92

Fr operatorul BETWEEN fraza SELECT se scrie: SELECT * FROM FACTURIEMISE WHERE DataFactur > {23.06.2004} AND ValoareTotala >= 30000000 AND ValoareTotala <= 40000000 Utiliznd operatorul BETWEEN se poate scrie: SELECT * FROM FACTURIEMISE WHERE DataFactur > {23.06.2004} AND ValoareTotala BETWEEN 30000000 AND 40000000 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:
CodClient NumeClient Adresa Localitate

1006

AMI SRL

Galaiului, 72

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.

93

Operatorul IN Format general: expresie1 IN (expresie2, expresie3, ...) 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 1001 1003 1006 1007 NumeClient TEXTILA SA OCCO SRL AMI SRL AXON SRL Adresa Bld. Copou, 87 NULL Galaiului, 72 Silvestru, 2 Localitate Iai Iai Bacu Iai

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: NumeClient CodClient 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.

94

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 ? 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, echi-jonciunii 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
95

ON WHERE FACTURIEMISE.CodClient = CLIENI.CodClient WHERE Localitate=Iai Rezultat: NrFactur 111111 111112 111114 111118 111120 111121 111122 111125 NumeClient OCCO SRL TEXTILA SA OCCO SRL AXON SRL OCCO SRL TEXTILA SA AXON SRL OCCO SRL Localitate Iai Iai Iai Iai Iai Iai 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.2004 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 "sub-consultare". Cu alte cuvinte, n acest caz WHERE Data IN va selecta toate facturile pentru care data emiterii este 18.06.2004. Rezultat: NrFactur CodClient DataFactur ValoareTotal TVAColectat 111113 1004 18.06.2004 5850000 934034 111114 1003 18.06.2004 28500000 4550420 111115 1008 18.06.2004 35700000 5700000

96

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 subfraz SELECT. Exemplul 3 Care sunt clienii crora li s-au trimis facturi ntocmite n aceeai zi cu factura 111114 ? SELECT DISTINCT NumeClient 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.

97

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 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 30000000 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

98

Rezultat ValMinima 2850000 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 ValoareTotala 111126 54250000 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. 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 CodClient DataFactur ValoareTotala TVAColectata

111111 111112 111113 111114 111115 111116 111117

1003 1001 1004 1003 1008 1008 1006

17.06.2004 17.06.2004 18.06.2004 18.06.2004 18.06.2004 19.06.2004 20.06.2004

17000000 2850000 5850000 28500000 35700000 8700000 11000000

2714286 455042 934034 4550420 5700000 1389076 1756303

99

111118 111119 111120 111121 111122 111123 111124 111125 111126

1007 1005 1003 1001 1007 1006 1004 1003 1002

23.06.2004 24.06.2004 24.06.2004 24.06.2004 24.06.2004 25.06.2004 25.06.2004 30.06.2004 01.07.2004

15000000 47250000 3000000 4250000 8750000 6600000 38500000 12800000 54250000

2394958 7544118 478992 678571 1397059 1053782 6171008 2051761 8661765

2. Se formeaz cte un grup pentru fiecare valoare distinct a atributului DataFactur .Pasul 2:
NrFactur CodClient DataFactur ValoareTotala TVAColectata

111111 111112 111113 111114 111115 111116 111117 111118 111119 111120 111121 111122 111123 111124 111125 111126

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

17.06.2004 17.06.2004 18.06.2004 18.06.2004 18.06.2004 19.06.2004 20.06.2004 23.06.2004 24.06.2004 24.06.2004 24.06.2004 24.06.2004 25.06.2004 25.06.2004 30.06.2004 01.07.2004

17000000 2850000 5850000 28500000 35700000 8700000 11000000 15000000 47250000 3000000 4250000 8750000 6600000 38500000 12800000 54250000

2714286 455042 934034 4550420 5700000 1389076 1756303 2394958 7544118 478992 678571 1397059 1053782 6171008 2051761 8661765

3. Pentru fiecare din cele nou grupuri se calculeaz suma valorilor atributului ValoareTotala. Tabela - rezultat final va avea nou linii: DataFactur 17.06.2004 18.06.2004 19.06.2004 20.06.2004 23.06.2004 24.06.2004 25.06.2004 30.06.2004 01.07.2004 SUM(ValoareTotala) 19850000 70050000 8700000 11000000 15000000 63250000 45100000 12800000 54250000

Exemplul 2 Care este numrul facturilor emise pentru fiecare client ?

100

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 cincizeci milioane lei. SELECT DataFactur, SUM(ValoareTotala) FROM FACTURIEMISE GROUP BY DataFactur HAVING SUM(ValoareTotala) > 50000000 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) > 50000000. Rezultat: Data 18.06.2004 24.06.2004 01.07.2004 SUM(ValoareTotala ) 70050000 63250000 54250000

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)

101

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 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.
102

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, ValoareTotala decimal (15) not NULL, TVAColectata decimal (14) , PRIMARY KEY (NrFactur), FOREIGN KEY (CodClient) REFERENCES CLIENI
103

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

Bibliografie 1. Airinei, D., .a., Modele de aplicaii practice n Microsoft Excel i Visual FoxPro, Editura Sedcom Libris, Iai, 2003 2. Bazian, Menachem, Totul despre Visual FoxPro 6.0, Editura Teora, Bucureti, 2001 3. Bsc, O., Baze de date, Editura All, Bucureti, 1997 4. Blattner, P., Excel 2002, Editura Teora, Bucureti, 2002 5. Conolly, T., Begg, C., Strachan, A., Baze de date,. Proiectare, implementare, gestionare, Editura Teora, Bucureti, 2001 6. Florescu, V., .a., Baze de date, Editura Economica, Bucureti, 1999 7. Fotache, M., Baze de date relaionale. Organizare, interogare i normalizare, Editura Junimea, Iai, 1997 8. Fotache, M., SQL. Dialecte DB2, Oracle, Visual FoxPro, Editura Polirom, Iai, 2001 9. Fotache, M., Brava, I., Strmbei, C., Creu, L., Visual FoxPro. Ghidul dezvoltrii aplicaiilor profesioanle, Editura Polirom, Iai, 2002 10. Hernandez, M. J., Proiectarea bazelor de date, Editura Teora, Bucureti, 2003 11. Lungu, I. i colectiv, Baze de date. Organizare, proiectare i implementare, Editura ALL, Bucureti, 1995 12. Melnic, A., Fotache, M., Blb, R., Informatic aplicat n economie. Programe de calcul tabelar, Editura Moldavia, Bacu, 2000 13. Miloescu, M., Baze de date n Visual FoxPro, Editura Teora, Bucureti, 2003 14. Pvloaia, W., .a.., Analiz economico-financiar i informatic de gestiune, Editura Moldavia, Bacu, 2000 15. Popescu, I., Modelarea bazelor de date, Editura Tehnic, Bucureti, 2001

104