BOLDEA COSTIN RADU

Sisteme de Gestiune a Bazelor de Date

Suport de curs

2010

CUPRINS

Capitolul 1. INTRODUCERE IN STUDIUL LIMBAJELOR DE PROGRAMARE…….……………………………………………………………………..31.1. Noţiuni generale privind limbajele de programare1.2. Clasificarea limbajelor de programare1.3. Structurarea şi organizarea datelor. Tipuri de date utilizate în limbajele de programare1.4. Caracterizarea principalelor limbaje de programare 1.5. Criterii de selecţie a limbajelor de programare

CAPITOLUL 2 BAZE DE DATE ŞI SISTEME DE GESTIUNE A BAZELOR DE DATE…………….…………………………………………………………………………172.1 Concepte utilizate în studiul bazelor de date şi al sistemelor de gestiune a bazelor de date2.2. Modele de structurare a datelor în baze de date2.3. Sisteme de gestiune a bazelor de date2.4. Arhitecturi multiutilizator pentru sisteme de gestiune a bazelor de date2.5. Protecţia şi securitatea bazelor de date 2.6. Administrarea datelor şi a bazelor de date

Capitolul 3. MODELUL RELAŢIONAL AL DATELOR………………………………523.1. Elementele modelului relaţional3.2. Algebra relaţională3.3. Studiul dependenţelor funcţionale 3.4. Normalizarea bazelor de date relaţionale

Capitolul 4. LIMBAJE DE INTEROGARE A BAZELOR DE DATE – SQL………….67 4.1. SQL - Evoluţie şi performanţe4.2. Comenzi pentru descrierea datelor;4.3. Comenzi pentru interogarea bazelor de date

2

Capitolul 1. INTRODUCERE IN STUDIUL LIMBAJELOR DE PROGRAMARE

1.1. Noţiuni generale privind limbajele de programare1.2. Clasificarea limbajelor de programare1.3. Structurarea şi organizarea datelor. Tipuri de date utilizate în limbajele de programare1.4. Caracterizarea principalelor limbaje de programare 1.5. Criterii de selecţie a limbajelor de programare

1.1. Noţiuni generale privind limbajele de programareOdată cu apariţia calculatoarelor electronice a apărut şi noţiunea de limbaj de

programare ca mijloc de dialog om-calculator. Limbajele de programare aparţin setului de limbaje artificiale create de om şi servesc

la exprimarea, sub formă de instrucţiuni executabile de către calculator, a algoritmului de rezolvare a unei probleme. Algoritmul indică modul de prelucrare a datelor iniţiale şi modificarea lor pas cu pas până la obţinerea rezultatelor finale. Natura datelor, organizarea lor şi relaţiile dintre ele trebuie precizate prin program. Limbajele de programare oferă facilităţi corespunzătoare de descriere.

Definiţia modernă consideră limbajul de programare un instrument de dialog om-calculator care are proprietatea că este înţeles de ambii participanţi 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 (instrucţiuni, comenzi, funcţii, variabile, constante). Ansamblul regulilor prin care se construiesc instrucţiunile constituie gramatica limbajului.

Exprimarea regulilor gramaticale din limbajul de programare se realizează cu ajutorul unui metalimbaj. Elementele de metalimbaj apar în documentaţiile care însoţesc produsele-program. Cele mai des utilizate elemente de metalimbaj sunt: cuvinte scrise cu majuscule reprezintă cuvinte rezervate şi trebuie folosite exact în aceeaşi

formă. De exemplu.: comenzi, clauze şi funcţii în Visual FoxPro - LIST, CREATE, FOR, IIF();

cuvinte utilizator - sunt scrise cu litere mici şi reprezintă construcţii care vor fi înlocuite de utilizator. De exemplu: codprod, um, cant, pretu;

[ ]- încadrează o construcţie opţională (programatorul decide dacă acestea vor fi sau nu folosite). De exemplu: LIST [FIELDS <lista_câmpuri>] etc.;

{ } sau | - sau exclusiv din elementele prezente se va alege unul singur. Exemplu: TO PRINT| TO FILE, ON|OFF, etc.;

În practică există şi încercări 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. Utilizând limbajul de programare, omul va întocmi un program care descrie problema de rezolvat în termeni inteligibili pentru calculator. Programul reprezintă un ansamblu de instrucţiuni şi/sau comenzi scrise cu ajutorul unui limbaj de programare care descriu prelucrările de date pe care trebuie să le execute calculatorul în scopul rezolvării unei probleme. Instrucţiunile şi/sau comenzile reprezintă informaţii codificate prin care se transmite calculatorului acţiunea ce urmează a fi executată. La rândul lor acestea pot fi structurate în două mari grupe:

de prelucrare prin care se realizează introducerea/extragerea datelor în/din sistem, efectuarea operaţiunilor de calcul, efectuarea transferului de date între diferite zone de memorie etc.;

3

de organizare (de structurare internă a programului) ce asigură codificarea structurilor de control şi de apelare sau de salt la alte programe.

Ansamblul activităţilor de concepere, dezvoltare şi întreţinere a programelor poartă denumirea de programare. Programul scris de om se numeşte program-sursă. Pentru a putea fi înţeles de calculator el trebuie adus în format executabil. Obţinerea formatului executabil se realizează prin traducere, cu ajutorul unor programe speciale, care pot fi interpretoare sau compilatoare.

Figura 1.1 ilustrează procesul de programare.

Figura 1.1. Procesul de programare Aşa cum rezultă din figura 1.1, în cazul problemelor simple, calea de la problema de

rezolvat la rezultate este relativ uşoară, putând fi sintetizată astfel: definirea şi analiza problemei, elaborarea algoritmului de rezolvare a problemei şi reprezentarea acestuia, codificarea algoritmului într-un program utilizând un limbaj de programare, transformarea programului sursă în program executabil (prin compilare sau interpretare), testarea şi documentarea, exploatarea şi întreţinerea.

În cazul problemelor complexe, activitatea de programare capătă caracteristicile activităţilor de tip industrial, presupunând implicarea mai multor categorii de specialişti, mai mult timp şi mai mulţi bani. În acest caz, rezultatul activitităţii de programare este produsul-program. Acesta ilustrează tocmai trecerea de la “artizanal” la “industrial” în programare. Prin produs-program se desemnează atât programul propriu-zis, cât şi documentaţia pentru elaborarea, implementarea şi întreţinerea sa. Documentaţia poate fi inclusă în program prin linii de documentare/linii comentariu, care nu influenţează modul de derulare a execuţiei programului, facilitând doar înţelegerea sa sau ataşată programului sub forma dosarului de programare care la rândul său cuprinde descrierea problemei şi a funcţiilor sale, descrierea structurii datelor (de intrare şi de ieşire), descrierea algoritmului de rezolvare a problemei, programul sursă, descrierea condiţiilor de implementare şi exploatare.

Produsele-program sunt realizate atât de către firme specializate, cât şi de firme care-şi dezvoltă propriile aplicaţii.

Industrializarea activităţii de programare a determinat apariţia, în 1968, a conceptului de ingineria programării (software engineering), un domeniu al informaticii care se ocupă cu identificarea celor mai adecvate soluţii, metode, procedee şi instrumente care să conducă, în condiţii optime de productivitate şi eficienţă, la elaborarea de produse-program

Programator

pe baza analizeiproblemei de rezolvat

instrucţiunipentru calculator

Scrieprogramul

Traducere automatăîn limbaj maşină

Reguli şi restricţii alelimbajelor de programare

Program

Calculator

Problema

(utilizator)executăprogramul

Rezultat

4

performante. De la ingineria programării s-a trecut apoi la ingineria programării asistate de calculator (CASE- Computer Aided Software Engineering). Altfel spus, calculatorul îşi face singur programele, numai că trebuie să-i furnizăm singuri intrările î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 operaţiunile de efectuat. Ulterior, evoluţia s-a orientat către medii de programare. Mediile de programare reprezintă pachete de programe care asigură integrarea următoarelor funcţii: introducerea şi editarea programului sursă, interpretarea sau compilarea, respectiv editarea de legături, încărcarea şi lansarea în execuţie, 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 încărcător de programe, un depanator de programe. În puls, oferă facilităţi de gestionare a fişierelor prin meniul FILE şi o informare completă şi rapidă prin sistemul HELP.

1.2. Clasificarea limbajelor de programareCea mai folosită clasificare este cea care grupează limbajele de programare pe

generaţii şi urmăreşte periodizarea evoluţiei calculatoarelor.Generaţiile de limbaje care pot fi identificate sunt:Generaţia I - limbajele în cod maşină, în care toate instrucţiunile sunt numerice (şiruri

de 0 şi 1), fiind redactate plecând de la un cod binar propriu fiecărei maşini (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 maşinǎ puteau fi executate numai pe calculatorul pentru care au fost elaborate (nu erau portabile). Principalele deficienţe ale acestor limbaje sunt legate de dificultăţile de corectare a programelor, aceste programe fiind mari, iar erorile greu de identificat.

Generaţia a II-a - limbajele de asamblare, care înlocuiesc codurile numerice cu cele mnemonice, adresele fiind alocate de sistem. Utilizarea acestor limbaje presupune existenţa unor programe speciale numite asambloare care să traducă instrucţiunile în limbaj cod maşină. Instrucţiunile se traduc 1 la 1, adică fiecărei instrucţiuni în limbaj de asamblare îi corespunde o instrucţiune în cod maşină. Operaţia poartă numele de asamblare, iar rezultatul se numeşte program obiect executabil. Pentru a reprezenta codurile de operaţii şi poziţiile din memorie se folosesc simboluri, motiv pentru care aceste limbaje se mai numesc şi limbaje simbolice.

Execuţia unui program sursă scris într-un limbaj de asamblare are loc pe parcursul a două etape: asamblarea şi execuţia propriu-zisă. Schematic se obţine următoarea reprezentare (figura nr. 1.2):

Fig. nr.1.2. Tratarea programelor în limbaje de asamblare

Limbajele de asamblare permit utilizarea de abrevieri alfabetice (mnemonice) care sunt mai uşor de memorat decât adresele scrise în binar ( Ex. ADD - adunare, DIV –

P.S.

Programexecutabil 1.Asamblare

2.Execuţie

Rezultatefinale

DateAsamblor

5

împărţire). Ele simplifică enorm programarea, deoarece elimină memorarea poziţiilor din memorie pentru date şi instrucţiuni. Totodată, limbajul de asamblare rămâne un limbaj orientat maşină deoarece instrucţiunile în limbaj de asamblare corespund instrucţiunilor în limbaj maşină conform modelului de calculator utilizat. O singură instrucţiune în limbaj de asamblare corespunde unei singure instrucţiuni în limbaj maşină şi deci este nevoie de acelaşi număr de instrucţiuni în ambele cazuri.

Aceste limbaje sunt utilizate pentru elaborarea software-ului de sistem, datorită vitezei de execuţie 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)/3LDA X - încarcă X în registrul AADD Y - adună Y la conţinutul registrului AADD Z -adună Z la conţinutul registrului ADIV 3 - împarte rezultatul la 3STA B - stochează rezultatul final în BLimbajele în cod maşină şi de asamblare sunt limbaje de nivel redus.Generaţia a III-a - limbajele de nivel înalt sau evoluate, care au dominat peste 30 de

ani piaţa informaticii. Reprezentative sunt: FORTRAN pentru ingineri şi matematicieni şi COBOL pentru mediul economic. Caracteristica lor principală este proceduralitatea (adică urmăresc pas cu pas procedura de rezolvare a unei probleme). Au fost create mii de astfel de limbaje, unele având destinaţii precise (FORTRAN şi ALGOL sunt destinate calculelor ştiinţifice, COBOL este destinat aplicaţiilor economice, SIMULA fiind un limbaj de simulare, etc.), iar altele având utilizare largă (BASIC, PASCAL, C). Şi instrucţiunile scrise în aceste limbaje trebuie traduse în cod maşină; 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 maşină (sunt utilizate pentru COBOL, FORTRAN);

interpretoare - sunt translatoare care citesc pe rând fiecare instrucţiune 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” desfăşurat pe trei faze:

compilarea /interpretarea; editarea de legături; execuţia propriu-zisă.

Schematic se obţine următoarea reprezentare (figura nr.1.3 ):

Fig.1.3. Tratarea programelor în limbaje evoluateAvantaje: sunt mai uşor de învăţat şi utilizat decât limbajele de asamblare; sunt

portabile (pot fi utilizate şi pe un alt calculator); pot fi oricând modificate şi actualizate.

P.S.

Rezultatefinale

Date

1. Compilare/interpretare

2. Editaredelegături

3. ExecuţieP.O. imaginememorieexecutabil

ProgramO.Compilator/interpretorEditor delegături

6

Câştigul de productivitate este remarcabil: o linie de program scris cu un limbaj de generaţia a III-a reprezintă mai mult de 100 de linii de instrucţiuni în cod-maşină. Dezavantaje: au reguli şi sintaxe rigide şi deloc uşor de învăţat pentru un utilizator nespecialist; solicită mult timp pentru translatare în cod maşină (descoperirea unei erori înseamnă nu numai corectarea ei, ci şi traducerea din nou în cod maşină).

Exemplu: Folosind limbaje din generaţia 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-ZAceste limbaje se caracterizează prin proceduralitate, adică evenimentele se succed

secvenţial, unul după altul. Există în literatura de specialitate o împărţire a LG3 în generaţii. Cu menţiunea că există şi excepţii, iată care sunt acestea:

generaţia I se încadrează în intervalul 1954 – 1958. Comenzile erau bazate pe expresii matematice. Reprezentanţi: FORTRAN I, ALGOL 58;

generaţia a II-a acoperă intervalul 1959 – 1961 (FORTRAN II, ALGOL 60, COBOL). Apar subrutinele programate, se definesc structurile de date şi lucrul cu fişierele de date;

generaţia 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 programării structurate. Realizarea unui program începe cu definirea principalilor paşi şi continuă în această manieră până când întregul program este dezvoltat. Ideea structurării a apărut datorită problemelor ce apăreau la dezvoltarea de aplicaţii complexe, cea mai relevantă fiind lipsa viziunii de ansamblu asupra programului. Deşi primele concepte ale programării structurate au apărut încă de la începutul anilor ’60, implementarea lor s-a făcut în timp, în sprijinul acesteia creându-se metodologiile care ofereau direcţiile de urmat în proiectarea de aplicaţii, pas-cu-pas.

după anii ’70 au apărut tot mai multe tipuri de LP, astfel ca încadrarea lor în generaţii a devenit tot mai dificilă. Programarea structurată s-a generalizat. În domeniul aplicaţiilor economice, COBOL deţinea 80% din totalul acestora.

Generaţia a IV-a (4GL) - limbajele de nivel foarte înalt, care au apărut în primul rând pentru utilizatorii nespecialişti, numiţi ş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 conversaţional, interactiv. Se bazează în mare măsură pe utilizarea meniurilor şi interfeţelor grafice, fiind uşor de învăţat (oferă facilităţi de tip HELP sau Wizard).

Evenimentul ce a perturbat evoluţia limbajelor procedurale a fost apariţia şi, mai ales, răspândirea PC-urilor. La mijlocul anilor ’80 a început declinul mainframe-urilor si al prelucrării centralizate a datelor. Managerii erau încântaţi de posibilităţile pe care le oferea PC-ul în a-şi rezolva singuri multe din probleme, mai ales odată cu apariţia interfeţelor grafice. Utilizatorii de PC-uri nu-şi propuneau să rezolve probleme complicate şi să dezvolte aplicaţii complexe, astfel că nu aveau nevoie de limbaje declarative. Ei cereau limbaje grafice, prietenoase, de aceea limbajele procedurale au evoluat altfel decât către declarativ. A IV-a generaţie de limbaje de programare a fost orientată către utilizatori, fiind numită şi generaţia utilizatorilor finali. Producătorii de software s-au orientat către crearea de instrumente şi medii de lucru prietenoase, iar accentul s-a mutat pe interfaţa cu utilizatorul. O interfaţă grafică, simplă, dar nu simplistă, care să ofere utilizatorului un mediu de lucru eficient şi prietenos în acelaşi timp a devenit cheia unui soft de succes.

Caracteristicile limbajelor de generaţia a IV-a pot fi rezumate astfel: neproceduralitate, interfaţă prietenoasă şi eficacitate.

Majoritatea specialiştilor grupează limbajele din generaţia a-4-a în următoarele clase de produse: limbaje (instrumente) de interogare; generatoare de rapoarte; generatoare de aplicaţii şi /sau proiecte;

7

generatoare de grafice; instrumente de sprijinire a deciziilor.

La ora actuală constructorii de software oferă produse care integrează toate aceste funcţiuni. De exemplu, programul de calcul tabelar EXCEL este un instrument de sprijinire a procesului decizional, dar care oferă şi o vastă gamă de alte facilităţi: generarea graficelor, obţinerea, actualizarea şi interogarea bazelor de date, generarea rapoartelor etc.

Limbajele de interogare la rândul lor pot fi de două tipuri: limbaje de interogare simplă care permit consultarea fişierelor şi bazelor de date pe un

singur tip de înregistrare logică utilizând un criteriu de selecţie mai puţin complex; limbaje de interogare complexă care permit consultarea mai multor tipuri de înregistrări

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 răspândire o cunoaşte 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 funcţii esenţiale: selecţia informaţiilor solicitate, ordonarea datelor după criterii prestabilite şi editarea rapoartelor într-o structură formalizată folosind un număr minim de instrucţiuni de programare.

În general, toate sistemele de gestiune a bazelor de date precum şi programele de calcul tabelar (spreadsheet-urile) au încorporate generatoare de rapoarte. Cele mai populare instrumente din această categorie sunt: Easytrieve Plus, Datatrieve, Mark V1.

Există şi generatoare de rapoarte care sunt proiectate pentru a fi utilizate de către specialişti – RPG III (Report Program Generator).

Generatoarele de aplicaţii şi/sau proiecte se adresează în special utilizatorilor cunoscători ai tehnicilor de programare. Ele permit ca pe baza unor descrieri externe a datelor şi a modului de organizare, prelucrare şi afişare a acestora să se accelereze generarea (codarea) programelor, folosind un limbaj specific sau chiar un limbaj de generaţia 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 aplicaţiilor.

O categorie aparte o reprezintă pachetele-aplicaţii specializate pentru aplicaţii economice generale (finanţe-contabilitate) sau chiar numai pentru procesări de texte, tehnoredactări (DeskTop Publishing).

Generatoarele de grafice sunt instrumente ce permit reprezentarea sub formă grafică (histograme, bare, linii, cercuri etc. bi sau tridimensionale, cu opţiuni de culoare, text, legendă), a rezultatelor prelucrării datelor. Ele sunt independente (Tell-al Graph, SAS, ADRS/B6) sau încorporate în spreadsheet-uri (LOTUS, QUATTRO, EXCEL) sau SGBD-uri (FoxGraph).

Instrumentele de sprijinire a deciziilor se adresează experţilor din diferite domenii de activitate (finanţe, management, contabilitate, marketing etc.) pentru elaborarea şi urmărirea bugetelor, analiza investiţiilor, studiul pieţei etc. permiţând realizarea simulării şi modelării matematice a fenomenelor economice. Intră în această clasă programele de calcul tabelar (QUATTRO, LOTUS, EXCEL ş.a.), pachetele program statistice (SPSS, SAS etc.).

Generaţia a V-a cuprinde limbajele care sunt sau vor fi îndreptate spre exploatarea bazelor de cunoştinţe, crearea sistemelor expert şi, mai general, spre rezolvarea problemelor legate de inteligenţa artificială.

După cum se observă limbajele au evoluat continuu, aşa cum rezultă din figura 1.4.

1 Oprea, D., Premisele şi consecinţele informatizării contabilităţii, Ed. Graphix, Iaşi, 1994, p. 96

8

Fig. nr. 14. Evoluţia limbajelor de programareAşa cum rezultă şi din figura 1.4, două sunt tendinţele care au marcat evoluţia

limbajelor de programare. Prima este trecerea de la programele specializate pe un tip de probleme, elaborate de programatori profesionişti la pachetele de software cu destinaţii diverse adaptate la nivelul utilizatorilor finali neinformaticieni. Această tendinţă s-a amplificat odată cu apariţia microcalculatoarelor. Tendinţa principală în prezent este către instrumente avansate de dezvoltare a aplicaţiilor orientate pe obiect. A doua tendinţă este îndepărtarea de limbajele de programare tehnice, foarte dificil de utilizat, specifice începuturilor programării (limbaje de generaţia I şi a II-a) şi de limbajele procedurale. Tendinţa este către limbajele neprocedurale şi limbajele naturale, apropiate de limbajul uman, tendinţă care s-a accentuat odată cu apariţia celei de-a IV-a generaţii de limbaje. Ea continuă prin îmbunătăţirea interfeţelor grafice şi dezvoltarea inteligenţei artificiale, care produce aşteptatele limbaje naturale. Este vorba de cea de-a V-a generaţie de limbaje de programare, reprezentată de pachete de programe asistate de experţi. Şi în pachetele de programe actuale sunt încorporate unele module de ajutor sau module de sprijin inteligente (wizard) care oferă utilizatorului asistenţă în rezolvarea unor probleme (realizarea unui grafic sau tabel).

O altă clasificare a limbajelor de programare a fost realizată de J.E. Sammet într-o lucrare publicată în 19692, el având în vedere următoarele 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 operaţiunile care se execută şi ordinea de execuţie a acestora. Ele răspund la întrebarea CUM?. Exemple: COBOL, FORTRAN, BASIC, ALGOL, PASCAL.

Limbajele neprocedurale (numite şi limbaje de nivel foarte înalt) oferă soluţia de rezolvare a unei probleme, dar fără a da detalii asupra modului concret de rezolvare. Ele răspund la întrebarea CE?. Exemplu: limbajele din SGBD, PROLOG, LISP.

Limbajele speciale descriu funcţii specifice ale produselor-program. De exemplu, procesorul Word are inclus un limbaj de scriere a macrourilor.

Limbajele orientate pe problemă deservesc domenii restrânse 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.

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

Generaţia I Generaţia II Generaţia III Generaţia IV Generaţia V

Tendinţa: către limbajele de programare conversaţionale, naturale

Evoluţielimbaje

limbaje încod maşină

limbaje deasamblare

limbaje de nivel inalt;primele sisteme deoperare

limbaje degen. a IV-a(4GL) orien-tate cătreutilizator

limbajenaturale;sistemeexpert

Tendinţa: către aplicaţii cu scop general, orientate spre utilizatorul nespecialist

Tendinţe majore în software

9

1.3. Structurarea şi organizarea datelor. Tipuri de date utilizate în limbajele de programare

Dezvoltarea rapidă şi complexă a societăţii a dus în mod inevitabil la o sporire însemnată a volumului de date, care tind să aglomereze şi să blocheze canalele informaţionale în aceeaşi măsură în care creşte continuu nevoia de informaţie.

Rezultă că orice organism economic se confruntă cu un volum mare de date, supus unor prelucrări relativ simple, dar cu un caracter repetitiv şi cu o frecvenţă mare. În acelaşi timp datele se caracterizează printr-o structură uniformă rezultată din structura documentelor primare specifice operaţiilor economice. Toate acestea reprezintă, de fapt, restricţii în activitatea de structurare şi organizare a datelor economice în sistemele informatice.

1.3.1 Concepte utilizate în organizarea datelorOrganizarea 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 cât mai redus. O colecţie de date pe care s-a definit o structură, căreia îi este specific un anumit mecanism de selecţie şi identificare a elementelor componente constituie o structură de date. Toate structurile de date care au aceeaşi organizare şi sunt supuse aceloraşi operaţii formează un anumit tip de structură de date. Pentru specificul activităţilor economice fiecare nivel de abstractizare implică: date elementare şi date structurate.

Noţiunea de dată elementară se referă la mulţimea ordonată şi finită de valori, de un anumit tip, asupra cărora se pot efectua operaţii. O dată care apare ca entitate indisolubilă atât în raport de informaţia pe care o reprezintă, cât şi în raport de procesorul care o prelucrează se numeşte dată elementară.

Cel mai des întâlnite tipuri de date elementare în limbajele de programare sunt: tipul numeric – se includ numerele întregi, reale şi complexe şi asupra cărora se pot

realiza operaţii de adunare, scădere, etc.; tipul logic (boolean) – este utilizat pentru precizarea stărilor de adevăr (TRUE, YES)

sau neadevăr (FALSE, NO) ale unui enunţ. Asupra acestora se pot efectua operaţii logice: AND, OR, NOT;

tipul caracter - conţine o mulţime de caractere alfanumerice, în cadrul acestora putându-se defini operaţii de concatenare, ordonare etc.;

tipul pointer - conţine adrese către 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 colecţii de date elementare care, într-un anumit sens, sunt în

relaţii unele cu altele. Natura relaţiei se stabileşte la crearea structurii şi poate diferi în funcţie de nivelurile de abstractizare.

Cele mai utilizate date structurate sunt: articolul; fişierul; tabloul.

Articolul este o structură de tip arborescent ale cărui câmpuri (câmpul reprezentând o mărime ce poate lua valori diferite dintr-o multitudine de valori posibile, face excepţie câmpul boolean care poate lua doar două valori) sunt descendenţii rădăcinii (nivelul 1), subcâmpurile sunt descendenţii câmpurilor (nivelul 2) ş.a.m.d. Câmpurile unui articol pot fi date elementare sau grupuri de date de diverse tipuri. În principiu fiecare câmp sau subcâmp se defineşte prin următoarele atribute:3 Cristea , V. , Dicţionar de informatică, Editura Ştiinţifică şi enciclopedică, Bucureşti , 1981, p. 240

10

nume - un cod unic de identificare; tip - natura datei; lungime - numărul total de caractere; partea zecimală – specificată numai pentru datele numerice.

De exemplu, articolul PRODUSE poate avea în structură următoarele câmpuri:Nume Tip Lungime Partea zecimalăCODPROD N 5 0DENUMIRE C 10PREŢ N 9 2STOC N 8 2Fişierul este o structură de date omogene din punct de vedere a semnificaţiilor şi a

cerinţelor de prelucrare, înregistrate pe un suport şi care pot fi exploatate individual.Într-un fişier trebuie să distingem articolul tip (structura articolului) care este o

modalitate de a descrie dacă un obiect aparţine sau nu la o clasă de obiecte, de realizările (articolele) care sunt elemente ale clasei de obiecte descrise.

Tabloul este o colecţie de date de acelaşi 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 cărui valori sunt folosite pentru referirea elementelor tabloului.

Ex. T (i1, i2...ik), unde k reprezintă numărul de dimensiuni, iar i1, i2....ik sunt elementele tabloului T.

De exemplu, pentru introducerea notelor obţinute de studenţi în cele 2 sesiuni, fiecare sesiune având câte 5 examene, definim variabila Nota(2,5). Vom obţine 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 defineşte vectorul VECT cu 3 elemente şi matricea MATR cu 5 linii şi 10 coloane.

Prelucrarea datelor presupune parcurgerea unei succesiuni ordonate de operaţii care acţionează asupra mărimilor. Ele se pot grupa în următoarele categorii: operaţiuni de atribuire; operaţiuni de calcul; operaţiuni de decizie; operaţiuni de intrare /ieşire; operaţiuni de transfer a controlului.

Operaţiuni de atribuire sunt acelea prin care unui câmp i se atribuie o anumită valoare predefinită sau rezultatul evaluării unei expresii.TOTVAL = 0SF = SID + RD – RC

Operaţii de calcul se definesc pe mulţimea numerelor reale. Dintre acestea fac parte operaţia de adunare, scădere, înmulţire, împărţire, ridicare la putere, calculul unor expresii numerice etc.

Ca operatori se utilizează:+ pentru adunare;- pentru scădere;* pentru înmulţire;/ pentru împărţire;** pentru ridicare la putere.

11

De asemenea, în cadrul expresiilor se pot utiliza şi parantezele, evaluarea acestora făcându-se după regulile din algebră.

Exemplu: SALAR NET = ((NRORLUCR * TO) + SPORV) - IMPOZa = (b * c)**2 + 650Operaţiunile de decizie sunt utilizate pentru a delimita valoarea logică a unei

propoziţii: adevărat sau fals. Ele condiţionează executarea unor operaţii sau grupuri de operaţiuni. Operatorii utilizaţi pentru scrierea condiţiilor pot fi operatori relaţionali (=, >, <, ≠) şi operatori logici (AND, OR şi NOT).

Exemplu:IF STOCSIGUR < 10000 THEN PRINT "ATENŢIE! E NECESARĂ REAPROVIZIONAREA"ENDIFsauFOR MEDIA > 9.50 .AND. DOMICILIU ='NON IAŞI' PRINT 'DREPT DE

CAZARE'Operaţiunile de intrare/ieşire vizează realizarea transferului de date între memoria

externă şi cea internă şi invers. Pentru optimizarea operaţiei de intrare/ieşire se interpun zone tampon (buffere), atât pentru intrare, cât şi pentru ieşire conform schemei următoare (figura nr. 1.5):

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

Cele mai utilizate operaţii de I/E sunt cele de deschidere şi închidere a fişierelor şi de citire şi scriere date.

Operaţiunile de transfer a controlului sunt operaţii de salt şi de apelare. Cele de salt au rolul de a preda controlul unei alte operaţiuni decât cea imediat următoare, iar cele de apel, determină lansarea în execuţie a unor proceduri (grupuri de operaţiuni), evitându-se descrierea lor, de mai multe ori, în cadrul algoritmului.

Schematic derularea unei secvenţe de operaţiuni de apel se prezintă astfel (figura nr. 1.6.):

Zonatampon

Zonatampon

DEN

DEN

COD

COD

UM

UM

CANT

CANT

PREº

PREº

Z.ARTICOL

VALOARE

VALOARE

X

Z.ARTICOL

Zonådeintrare

Zonådelucru

Zonådeie¿ire

12

Fig. 1.6. Derularea operaţiunilor de apel

1.4. Caracterizarea principalelor limbaje de programare

Din multitudinea limbajelor de programare practica a consacrat atât limbaje de tip universal, cât şi limbaje specializate pe domenii de activitate. În continuare, fără pretenţia de a fi exhaustivi, prezentăm limbajele care s-au impus în domeniul economic şi în cel tehnico-ştiinţific.

FORTRAN (FORmula TRANslation) este un limbaj cu orientare matematică, fiind utilizat cu precădere în aplicaţii tehnice (ecuaţii, operaţii cu matrici, programare liniară, simulare). Este primul limbaj de nivel înalt. Prima versiune a apărut în 1954, fiind realizată de o echipă de la IBM şi urmată de alte versiuni perfecţionate. 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 fără speranţă de a deveni adecvat. Totuşi, ultimele versiuni FORTRAN au fost aduse în concordanţă cu noile standarde ale programării structurate. Cu toate acestea, este destul de puţin utilizat astăzi. Cele mai utilizate versiuni au fost: FORTRAN IV, FORTRAN IV PLUS, FORTRAN 77 – pentru minicalculatoare, specializat pentru prelucrări în timp real, FORTRAN 90 – variantă îmbunătăţită cu atributele programării orientate obiect.

COBOL (COmmon Business Oriented Language) a fost primul limbaj orientat exclusiv către rezolvarea problemelor economice, cum reiese şi din numele său. Dintre limbajele din generaţia a 3-a este cel mai rǎspândit, după FORTRAN. Se utilizează pentru exploatarea unui volum mare de date cu structuri diverse (arbori, tablouri, fişiere etc.). COBOL a fost lansat în 1964, fiind dezvoltat de o echipă de specialişti, condusă de o femeie (cpt. Grace Hooper) de la Departamentul Apărării SUA. A fost standardizat prima oară în 1968. Succesul lansării şi utilizării în următorii ani (la sfârşitul anilor ’80, între 60 şi 75% din aplicaţiile economice erau scrise în COBOL) a fost însoţit de mai multe controverse. Avantaje: posibilitatea manipulării unor volume mari de date, descrierea completă a structurilor de date, rapiditate în execuţie (datorită compilării).

Cea mai importantă producătoare 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 aplicaţii (inclusiv cu facilităţi grafice) pentru lucrul în reţelele de

calculatoare; dezvoltarea de aplicaţii cross-platform destinate unei game largi de echipamente şi

sisteme de operare; asigurarea portabilităţii la nivel de programe sursă.

COBOL reprezintă un software complex cu un înalt grad de generalizare şi care asigură independenţa programelor faţă de componentele hardware.

13

BASIC (Begginner’s All Purpose Instruction Code) este unul din cele mai utilizate limbaje de generaţia a III-a, poate şi pentru faptul că a fost livrat odată cu sistemul de operare MS-DOS, fiind inclus între aplicaţiile acestuia (universalitatea şi simplitatea limbajului a determinat includerea sa în sistemele de operare). Totul a început în 1963, când 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 instrucţiuni. 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 apărut apoi susţinând BASIC-ul prin includerea lui în pachetul sistemului de operare MS-DOS (începând de la versiunea 5.0). Au apărut apoi zeci de versiuni de BASIC, cu diferiţi autori, multe dintre ele incompatibile, ajungând să fie denumit de unii “limbajul programatorilor neprofesionişti”. De aceea, în 1983 ANSI hotărăşte elaborarea unui standard pentru limbajul BASIC. Acest limbaj a cunoscut diverse variante, cele mai răspândite fiind BASICA, GWBASIC, QBASIC, Turbo Basic şi, nu în ultimul rând, Visual Basic.

PASCAL este un limbaj popular în mediul universitar (mai ales în facultăţile de informatică şi matematică). A apărut în 1968 şi a fost denumit după matematicianul francez Blaise Pascal. Este un limbaj universal, caracterizat prin simplitate, eficienţă, accesibilitate (chiar şi pentru începători) şi care prezintă (încă de la prima versiune) toate elementele specifice programării structurate. Sunt păreri care apreciază că învăţarea limbajului PASCAL este indispensabilă pentru formarea unor informaticieni. Dezavantaje: slaba gestionare a datelor organizate în fişiere şi incapacitatea de a manipula volume mari de date. Limbajul a cunoscut mai multe versiuni adaptate diverselor metode de prelucrare (Pascal secvenţial, Pascal concurent, Pascal obiectual). Pascal a stat la baza elaborării de noi limbaje precum MODULA-1, MODULA-2, ADA. Ultimele versiuni, produse de firma Borland, au apărut 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 Apărării SUA pentru aplicaţii tehnico-ştiinţifice în 1979. Are multe din elementele limbajului PASCAL, dar este mult mai complex, fiind considerat unul din cele mai dificile limbaje. Folosit iniţial în domeniul militar, la ora actuală, datorită ]facilităţilor oferite este larg utilizat şi în aplicaţiile 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 instrucţiuni, conducând la elaborarea de programe compacte, bine structurate. Destinat iniţial programatorilor de sistem, şi-a lărgit aria de utilizatori odată cu extinderea sistemului de operare UNIX. Este limbajul de programare cu cea mai impresionantă evoluţie ş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 execuţia şi gestionarea eficientă a memoriei. Rămâne totuşi un limbaj pentru profesionişti, multe aplicaţii (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 producători sunt Borland (C++), Microsoft (Quick C, Visual C), Symantec.

RPG (Report Program Generator) este un limbaj dezvoltat de către 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 specificaţii ale utilizatorului, să se genereze codul unui program care lansat în execuţie va conduce la obţinerea rapidă şi cu un cost relativ redus, a rapoartelor dorite. PL/1 (Programming Language 1) este un limbaj lansat de către firma IBM la începutul anilor ’60, îmbinând facilităţile din FORTRAN pentru aplicaţii ştiinţifice cu cele din COBOL pentru aplicaţiile economice. La ora actuală acesta nu este foarte popular, utilizarea lui fiind limitată datorită faptului că este complex şi greu de învăţat

LISP (LISt Processing) este un limbaj adecvat inteligenţei artificiale, utilizat mai ales în cercetare şi în domeniul inteligenţei artificiale. A apărut în 1958 la Institutul Tehnologiei din Massachussets, dar a fost considerat prea avansat pentru tehnologia vremii. Spre deosebire

14

de celelalte limbaje prezentate, care sunt imperative, LISP este un limbaj funcţional. LISP nu face deosebirea între date şi prelucrări, 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 aplicaţii de inteligenţă artificială şi face parte din familia limbajelor declarative (nu algoritmice). A fost orientat spre demonstrarea de teoreme şi înţelegerea limbajului natural. Permite reprezentarea şi utilizarea cunoştinţelor, fiind utilizat în crearea de sisteme expert. PROLOG este considerat o răzvratire împotriva modului de programare impus de modelul Von Neumann, iar în 1982 proiectul japonez de realizare a calculatoarelor de generaţia a V-a prevede folosirea ca limbaj de bază a limbajului PROLOG.

Smalltalk a fost dezvoltat la mijlocul anilor ’70 de către firma Xerox Corporation şi a fost primul limbaj specific programării orientată pe obiecte. Acest limbaj nu este greu de învăţat şi utilizat dar reclamă schimbarea în întregime a modului de gândire a unui program. Se prevede ca în viitor Smalltalk alături 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 comunicării între echipamente eterogene şi distribuirea formatului executabil al programelor în reţea, fiind limbajul cel mai utilizat în reţeaua INTERNET. Acest limbaj operează cu tipuri obişnuite de date, dispune de instrucţiuni speciale de protecţie şi oferă facilităţi de programare de tip animaţie, orientare obiect, distribuţie. Codul Java este portabil, acelaşi program putând fi rulat pe orice platformă care deţine acest mediu de execuţie.

O parte din limbajele de programare, prin diversele lor versiuni, nu pot fi încadrate strict într-o anume generaţie. Fiind supuse continuu perfecţionării, ele tind spre generaţia superioară celei în care au fost proiectate iniţial.

1.5. Criterii de selecţie a limbajelor de programareLa alegerea unui limbaj de programare trebuie avute în vedere o serie de aspecte care

să asigure eficienţă, siguranţă şi flexibilitate în rezolvarea aplicaţiilor utilizator. Criteriile care stau la baza opţiunii de selectare a limbajului privesc următorii factori:4

1. tipul problemei ce urmează a fi rezolvată şi cunoştinţele utilizatorului (măsura în care limbajul de programare este convenabil atât la clasa de probleme, cât şi pentru utilizator)

2. tipul echipamentelor disponibile utilizatorului3. gradul de dependenţă faţă de echipamentul folosit şi sistemul de operare4. evaluarea rezultatelor obţinute prin folosirea anterioară de către alţi utilizatori5. eficienţa scontată prin exploatare 6. caracteristicile tehnice şi funcţionale generale7. cerinţe de ordin economic Tipul problemei ce urmează a fi rezolvată şi cunoştinţele utilizatoruluiAcest criteriu are în vedere selectarea acelui limbaj care să răspundă cel mai bine tipului /tipurilor de aplicaţii utilizator, să asigure concomitent uşurinţă în utilizare, un timp minim pentru prelucrarea datelor confidenţialitatea ş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 achiziţionate. Această analiză trebuie să stabilească dacă sunt asigurate resursele minime pentru dezvoltarea şi exploatarea aplicaţiilor. În felul acesta se urmăreşte utilizarea eficientă a limbajului pe echipamentele din dotare. Gradul de dependenţa faţă de echipamentul folosit şi sistemul de operareConform acestui criteriu trebuie ales un limbaj de programare care să poată fi folosit fără probleme sub sistemul de operare sub care lucrează echipamentele din dotare. În plus, trebuie asigurată portabilitatea programelor în cazul în care se vor achiziţiona noi resurse informatice. Trebuie asigurată creşterea gradului de portabilitate cel puţin la nivel de program sursă. Evaluarea rezultatelor obţinute prin folosirea anterioară de către alţi utilizator

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

15

Acest criteriu cere realizarea unei documentări prealabile privind problemele cu care s-au confruntat alţi utilizatori ai limbajului (existenţa /inexistenţa unei documentaţii de învăţare şi utilizare, posibilităţile/facilităţile de rezolvare a problemelor practice etc.). Eficienţa 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 atât eficienţa execuţiei programului, mai ales la programele des utilizate cât şi eficienţa globală care ia în considerare toate fazele de elaborare şi utilizare (scriere, testare, exploatare şi întreţinere). În acest context performanţa limbajului poate deveni o problemă mai puţin importantă. Caracteristicile tehnice şi funcţionale 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, naturaleţea, consistenţa şi conciziunea în exprimare. Cerinţe de ordin economic Aceste cerinţe ţin seama de resursele financiare de care dispune utilizatorul , resurse care trebuie să acopere atât achiziţionarea şi exploatarea propriu-zisă a limbajului, cât şi organizarea şi pregătirea prealabilă a personalului.

Având în vedere cele de mai sus rezultă că alegerea unui limbaj este o decizie care trebuie susţinută printr-o serie de analize de ordin tehnic, funcţional şi economic.

16

CAPITOLUL 2. BAZE DE DATE ŞI SISTEME DE GESTIUNE A BAZELOR DE DATE

2.1 Concepte utilizate în studiul bazelor de date şi al sistemelor de gestiune a bazelor de date2.2. Modele de structurare a datelor în baze de date2.3. Sisteme de gestiune a bazelor de date2.4. Protecţia şi securitatea bazelor de date 2.5. Administrarea datelor şi a bazelor de date

Sistemele de baze de date reprezintă cea mai importantă dezvoltare în domeniul ingineriei programării, ele devenind din ce în ce mai accesibile penru o largă varietate de utilizatori.

2.1. Concepte utilizate în studiul bazelor de date şi al sistemelor de gestiune a bazelor de date

2.1.1. Metoda prelucrării prin fişiere independenteSistemul bazat pe fişiere reprezintă sistemul anterior bazelor de date. Modul de lucru

bazat pe fişiere independente, demodat astăzi, are o serie de neajunsuri care limitează eficienţa şi eficacitatea aplicaţiilor utilizator5.

Specific metodei prelucrării prin fişiere, ilustrată în fig. nr. 2.1.6, este faptul că fiecare dată (Data1, Data2, ..., Datan) este descrisă în toate fişierele în care apare, iar fiecare fişier trebuie descris în toate programele în care este utilizat. Nu există nici o posibilitate de a stabili în mod explicit o relaţie între două fişiere de date.

Fig. nr. 2.1.Organizarea datelor în fişiere

De asemenea, dacă spre exemplu, Data2 din Fişier1 este modificată, modificarea nu se face automat şi în Fişier2, ceea ce determină inconsistenţa datelor.Dezavantajele organizării datelor în fişiere pot fi sistematizate astfel:

1. Redundanţa şi inconsistenţa datelor, datorită prezenţei aceleiaşi date în mai multe fişiere independente;

Aceleaşi date sunt înregistrate şi stocate în mai multe fişiere, ceea ce reclamă programe distincte pentru actualizarea fiecărui fişier. În plus, duplicarea datelor conduce la un consum mare de memorie şi incoerenţă la trecerea datelor stocate dintr-un fişier în altul. Aceasta duce la alterarea integrităţii datelor (datele nu mai concordă), gestionarea complexă şi actualizarea greoaie a acestora, precum şi la o monopolizare inutilă a spaţiului de memorie.

2. Complexitatea actualizărilor (adăugarea, ştergerea sau modificarea datelor);3. Dificultatea obţinerii de informaţii neplanificate (spontane sau ad-hoc), chiar şi

pentru o simplă interogare fiind necesară scrierea unui program;Dispersia datelor în diverse fişiere independente complică accesul utilizatorilor la

informaţiile cerute ad-hoc, necesitând crearea de programe particulare pentru extragerea

5 O’Brian, Op. cit., pp. 244-2466 Fotache, M., Baze de date relaţionale, Organizare, interogare şi normalizare, Ediţia a II-a, Editura Junimea, Iaşi, 1997, p. 25

17

datelor solicitate. În lipsa acestor programe, pentru obţinerea informaţiilor dorite utilizatorul procedează la extragerea manuală.

4. Costul ridicat de exploatare ca urmare a dublării datelor;Exploatarea fişierelor independente presupune un cost ridicat, atât în ceea ce priveşte

resursele informatice (hardware şi software), cât şi cele legate de personalul utilizat.5. Separarea şi izolarea datelor;Atunci când datele sunt izolate în fişiere separate, programatorul de aplicaţii trebuie să se

asigure că sunt extrase datele corecte, fiind astfel necesară sincronizarea prelucrării datelor din fişiere diferite, această operaţiune fiind dificilă când sunt solicitate date din mai mult de două fişiere.

6. Formate de fişiere incompatibile, ceea ce face dificilă prelucrarea lor simultanăDeoarece structura fişierelor este încorporată în programele de aplicaţii, ea este

dependentă de limbajul de programare în care sunt scrise acestea. De exemplu, structura unui fişier 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 fişierelor într-un format comun.

7. Dependenţa datelor faţă de programele de aplicaţiiOrganizarea fişierelor, adresa lor fizică în memorie şi programele de aplicaţii folosite

pentru accesarea fişierelor sunt interdependente. Astfel, schimbările legate de dispunerea pe suportul de memorie, de structura datelor şi modificarea înregistrărilor unui fişier presupun modificări în toate programele în care este referit fişierul respectiv. Întreţinerea acestor programe este dificilă putând genera incoerenţe în fişierele de date. Incoerenţa şi lipsa de integritate sunt extrem de dificil de corectat deoarece nu există un dicţionar central pentru urmărirea definirii datelor.Toate aceste probleme care apar în sistemul ce prelucrează fişiere îşi găsesc rezolvarea prin folosirea bazelor de date şi a sistemelor de gestiune a bazelor de date. Datele stocate în baze sunt independente atât faţă de programele de aplicaţii care le folosesc, cât şi faţă de tipul de memorie utilizat.

2.1.2. Baze de datePe măsura evoluţiei sistemelor de prelucrare automată a datelor şi, în mod special, a

componentei hardware şi software, dar şi ca urmare a creşterii volumului datelor de prelucrat s-a dezvoltat un nou concept, cel al bazelor de date. El îşi face apariţia în a doua parte a anilor ’60, aducând un element de noutate, respectiv existenţa unui fişier de descriere globală a datelor, ceea ce asigură independenţa datelor de programe şi invers, fişier denumit dicţionar de date (vezi fig. nr. 3.2). La momentul respectiv, în cadrul sistemelor informatice implementate în întreprinderi, informaţiile erau organizate în fişiere de date (secvenţiale, indexate etc.) create cu ajutorul unor programe scrise în limbaje din generaţia a III-a: COBOL, FORTRAN etc.

Principiul fundamental al bazelor de date îl constituie unicitatea informaţiilor, adică orice informaţie este înregistrată o singură dată şi poate fi utilizată ori de câte ori este nevoie, de către diferiţi utilizatori şi în diferite momente.

Baza de date reprezintă un ansamblu integrat de înregistrări sau de fişiere reunite şi structurate în mod logic. În felul acesta datele stocate anterior în fişiere independente/distincte sunt concentrate într-un fond comun de înregistrări cu posibilitatea utilizării lor în numeroase aplicaţii.

Baza de date este o colecţie partajată de date între care există relaţii logice şi o descriere a acestor date, proiectată pentru a satisface necesităţile informaţionale ale unei organizaţii. Ea reprezintă un depozit de date unic care este definit o singură dată şi este utilizat simultan de către mai multe departamente şi utilizatori. În loc de a mai exista fişiere separate cu date redundante, toate datele sunt integrate, cu o dublare minimă. Baza de date nu mai este deţinută de un singur departament, ci constituie acum o resursă comună, partajată. Ea conţine nu numai datele operaţionale ale organizaţiei, ci şi o descriere a acestora. De aceea ea este definită şi ca o colecţie autodescrisă de înregistrări integrate. Această descriere a datelor este cunoscută sub denumirea de catalog de sistem sau dicţionar de date sau meta-date (date

18

despre date). Natura autodescriptivă a bazelor de date este cea care determină independenţa program-date.

Fig. nr .2.2. Structura unei baze de date

Conceptul de bază de date a apărut în 1964 în cadrul primului raport CODASYL7

prezentat la lucrările unei Conferinţe pe probleme de limbaje de gestiune a datelor “Development and Management of Computer – centered date-base”. La această conferinţă a fost lansată ideea organizării datelor prin intermediul unui fişier de descriere globală, numit dicţionar de date care are menirea de a asigura independenţa programelor faţă de date şi a datelor faţă de programe8.

Atunci când se analizează necesităţile informaţionale ale unei organizaţii se urmăreşte identificarea entităţilor, a atributelor şi a relaţiilor dintre entităţi. De aceea, abordarea bazelor de date presupune şi tratarea următoarelor elemente: entitate (articol, înregistrare logică), atribut (caracteristică, câmp) şi valoare/realizare9.

Prin entitate se înţelege un obiect concret sau abstract (operaţie economică, mijloc economic etc.) reprezentat prin proprietăţile sau însuşirile sale. Orice proprietate poate fi exprimată printr-o pereche atribut-valoare sau caracteristică-realizare. O entitate este identificată printr-un nume şi cuprinde, în general, mai multe valori sau realizări.

Atributul are rolul de a descrie însuşirile sau proprietăţile obiectului, stabilind natura valorilor pe care acesta le poate lua.

Valoarea reprezintă mărimea ce se atribuie fiecărei caracteristici din cadrul unei entităţi.

Relaţia reprezintă o asociaţie între mai multe entităţi.Aceste elemente sunt prezentate în tabelul nr. 2.1:

Tabelul nr. 2.1. Elemente specifice bazelor de dateEntitate Caracteristici (atribute) Realizări (valori)

Produs

Cod_produsDenumire_produsUnit_măsPreţ_ unitarCantitateNr._factură Data_recepţiei

152PantofiPereche

1151002452

24-10-2007

7 COnference on DAta SYstems Languages – Conferinţa despre Limbajele Sistemelor de Date8Lungu, I., ş.a., Baze de date, Organizare, proiectare şi implementare, Editura All, Bucureşti, 1995, p.139 Aceste elemente sunt numite diferit în literatura de specialitate. Vezi Roşca, I., ş.a. Baze de date şi SGBD, Bucureşti, 1986; Lungu, I., ş.a., Op., cit.,; Fotache, M., Baze de date relaţionale, Editura Junimea, 1997

19

O bază de date trebuie să satisfacă cinci condiţii esenţiale10: O bună reprezentare a realităţii înconjurătoare, adică baza de date trebuie să

ofere întotdeauna o imagine fidelă a realităţii prin informaţii fiabile şi actualizate; O non-redundanţă a informaţiei, informaţia conţinută în baza de date trebuind să

fie unică din punct de vedere semantic şi fizic; O independenţă a datelor faţă de prelucrări; datele constituie imaginea fidelă a

lumii reale, programele de aplicaţii trebuind să fie concepute în raport cu această structură a datelor;

Securitatea şi confidenţialitatea datelor; securitatea datelor trebuie asigurată prin proceduri fizice, iar confidenţialitatea prin proceduri care să împiedice accesul utilizatorilor neautorizaţi;

Performanţe în exploatare, orice cerere de prelucrare trebuind să fie satisfăcută într-un timp convenabil utilizatorului, ceea ce presupune folosirea unor tehnici de optimizare pentru reducerea timpului de prelucrare.

Dicţionarele de date Accesul utilizatorilor la informaţiile despre structura unei baze de date se realizează prin

intermediul dicţionarului de date. În principal, un dicţionar îndeplineşte următoarele funcţii:

definirea şi gestionarea datelor elementare ale întreprinderii (cod, etichetă, atribute, reprezentare etc.);

definirea şi gestionarea ansamblurilor de date; definirea şi gestionarea relaţiilor, de dependenţă sau ierarhice, dintre date; descrierea din trei puncte de vedere a utilizării datelor:

administrativ: care sunt posturile de lucru ce vor apela datele şi care va fi utilizarea acestor date?

logic: care sunt fişierele sau bazele de date în care intră elementele descrise?; organic: în care unităţi de prelucrare vor fi utilizate elementele descrise?În plus dicţionarele de date permit automatizarea operaţiilor de scriere, de descriere a

fişierelor sau ecranelor, de control etc. utile pentru întreţinerea şi dezvoltarea dosarelor de programe.

Bazele de date sunt concepute pentru a prelucra un volum mare de informaţii. Gestiunea acestora impune nu numai o structurare riguroasă a datelor, dar şi o raţionalizare a procedurilor de acces şi prelucrare. Pentru a putea fi exploatată de către 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 raţională a datelor conţinute. Obiectivul esenţial al unui sistem de gestiune a bazelor de date este, deci, furnizarea unui mediu eficient, adaptat utilizatorilor care doresc să consulte sau să actualizeze informaţiile conţinute î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 conţinute într-o bază de date. El trebuie, de asemenea, să asigure securitatea şi confidenţialitatea datelor într-un mediu multi-utilizator.

Principalele beneficii ale bazelor de date constau în: integrarea în aceeaşi structură a tuturor datelor pertinente ale unui sistem; gestionarea acestor date printr-un software specializat (SGBD); oferirea unei vederi parţiale asupra ansamblului de date necesare fiecărui

utilizator; asigurarea partajării datelor între diferiţi utilizatori.

Niveluri de abstractizare a datelor în bazele de date

10Moréjon, J., Principes et conception d’une base de données relationnelle, Les Editions d’organisation, Paris, 1992, p. 20

20

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 organizările fişierelor utilizate pentru stocarea datelor pe dispozitivele de stocare. El tratează probleme cum ar fi: alocarea spaţiului de stocare pentru date şi indexuri, descrierile înregistrărilor pentru stocare, cu dimensiunile de stocare pentru articolele de date, plasarea înregistrărilor, tehnicile de comprimare şi de codificare a datelor. Nivelul intern interacţionează cu metodele de acces al sistemului de operare (tehnici de administrare a fişierelor, pentru stocarea şi regăsirea înregistrărilor de date) pentru a plasa datele pe suporturile de stocare, a regăsi 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 relaţiile dintre acestea. La acest nivel structura bazei de date se concretizează în schema conceptuală. Nivelul conceptual asigură atât transpunerea, cât şi independenţa dorită dintre nivelul extern şi cel intern.Nivelul conceptual reprezintă toate entităţile, atributele şi relaţiile dintre ele, contrângerile asupra datelor, informaţii semantice despre date, informaţii privind securitatea şi integritatea.

Nivelul extern reprezintă vederea utilizatorului asupra bazei de date ce descrie acea parte a bazei de date relevantă pentru fiecare utilizator. Recurgerea la acest nivel de abstractizare se face pentru simplificarea interacţiunii 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 entităţi, atribute şi relaţii din lumea reală de care este interesat utilizatorul. Se urmăreşte satisfacarea cerinţelor tuturor utilizatorilor în condiţiile unei redundanţe minime şi controlate a datelor.

Văzută prin prisma celor trei niveluri, baza de date poate fi reprezentată ca în figura nr.2.3.11

Fig. nr.2.3. Nivele de abstractizare a datelor în bazele de dateIncluderea în baza de date a descrierii structurii acesteia o deosebeşte calitativ de

fişierele de date, deoarece prin aceasta se asigură independenţa datelor din bază faţă de programele de aplicaţii şi invers. Posibilitatea modificării structurii la un nivel, fără a afecta structura celorlalte niveluri este întâlnită sub numele de independenţa datelor, prezentă sub două forme:11 Fotache, M., Baze de date relaţionale. Organizare, interogare şi normalizare, Editua Junimea, Iaşi, 1997, p.32

21

independenţa fizică de date, adică posibilitatea modificării structurii bazei de date la nivel intern (cum ar fi utilizarea unor organizări ale fişierelor sau structuri de stocare diferite, a unor dispozitive diferite de stocare, modificarea de indexuri sau de algoritmi hash), fără a fi necesară schimbarea structurii conceptuale şi rescrierea programelor de prelucrare a datelor. Asemenea modificări sunt necesare pentru ameliorarea performanţelor de lucru (viteză de acces, mărimea fişierelor etc.). Autonomia fizică este cea care asigură şi portabilitatea bazei de date de pe un sistem de calcul pe altul fără modificarea schemei conceptuale şi a programelor;

independenţa logică de date se referă la faptul că modificarea schemei conceptuale a bazei de date (cum ar fi adăugarea sau eliminarea unor entităţi, atribute sau relaţii) nu necesită şi modificarea schemei externe sau rescrierea programelor de aplicaţii.

Este important să se facă distincţie între descrierea bazei de date şi baza de date însăşi. Descrierea bazei de date constituie schema bazei de date. Ea este specificată în timpul procesului de proiectare a bazei de date şi este schimbată rareori. Setul de date din baza de date se numeşte instanţa bazei de date. Mai multe instanţe ale bazei de date pot corespunde aceleiaşi scheme a bazei de date.

2.1.3. Bănci de dateÎn accepţiunea cea mai largă, banca de date reprezintă un set de informaţii gestionate

şi accesate prin intermediul unor programe speciale. Informaţiile, î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 colecţii de date aflate în interdependenţă, împreună cu descrierea datelor şi a relaţiilor dintre ele şi cu sistemul de programe pentru gestiunea datelor care asigură independenţa programelor aplicative faţă de modul de structurare a datelor, o redundanţă minimă şi controlată în memorarea lor, precum şi un timp minim de răspuns la solicitările utilizatorilor.12

Ea reprezintă un ansamblu de informaţii organizate, înregistrate pe suporturi magnetice sau optice care pot fi consultate local sau la distanţă prin intermediul calculatoarelor şi a reţelelor de comunicaţie. Deoarece permit accesul unui mare număr de utilizatori la datele stocate, băncile de date sunt considerate sisteme de documentare.

Se pot organiza bănci de date în toate sferele de activitate: bănci de date bibliografice, de documentare statistică, pentru evidenţe financiar-contabile şi bancare, diagnosticare şi informare medicală, pentru rezervarea tichetelor de călătorie şi a locurilor în staţiunile turistice etc.

În unele lucrări, banca de date este redusă la două componente: baza de date şi SGBD-ul asociat. Alţi autori extind noţiunea de bancă de date, ea înglobând baza de date, sistemul de gestiune a bazei de date, sistemul electronic de calcul, echipamentele de teleprelucrare, programele de aplicaţii, sistemul de operare, utilizatorii. Schematic structura unei bănci de date poate fi prezentată ca în figura nr. 2.4.

12 Pescaru, V., ş.a., Fişiere, baze de date şi bănci de date, Editura Tehnică, Bucureşti, 1976, p. 13

22

Colec¡iide date

Colec¡iide date

Colec¡iide date

Colec¡iide date

Fig.2.4. Structura unei bănci de date

Dacă în anii ‘70 şi la începutul anilor ’80, noţiunea cvasi-utilizată era cea de bancă de date, în lucrările din ultimii ani, termenul devine din ce în ce mai puţin invocat, majoritatea lucrărilor de profil, ca şi toţi marii furnizori de software fac trimitere, aproape exclusiv, la noţiunile de bază de date şi SGBD.

2.1.4. Depozite de dateConceptul de depozit de date a apărut la sfârşitul deceniului 8, dar s-a conturat şi

dezvoltat în anii ‘90. Conceptul datawarehouse (depozit de date) este definit de William Inmon (vicepreşedintele firmei Prism Solution) ca fiind o “colecţie de date destinate fundamentării deciziei manageriale, colecţie care este tematică, integrată, plasată într-un context temporal şi permanentă”.

Depozitul de date reprezintă o altă direcţie de dezvoltare şi evoluţie 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 următoarele: scopul pe care îl au datele stocate - acestea nu sunt utilizate în scop operaţional, ci pentru sarcini analitice, de la identificarea unui nou segment de piaţă până la brainstorming; dacă o bază de date este utilizată pentru prelucrarea tranzacţiilor on-line, depozitele de date se bazează pe prelucrarea analitică on-line, o nouă aplicaţie strategică; dacă o bază de date înregistrază şi raportează ce s-a întâmplat, un depozit de date arată şi de ce.Patru elemente determinante caracterizează depozitul de date: datele stocate privesc o funcţiune sau un proces din întreprindere (sunt orientate pe subiect); datele sunt integrate şi redefinite penteu a putea fi exploatate; informaţiile sunt conservate mai mulţi ani, acesta reprezentând 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 operaţional, din datele de arhivă (în perioada de constituire a depozitului), precum din surse externe (baze de date publice, date din recensăminte, 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 aplicaţiile de birotică (programe de calcul tabelar, procesoare de texte, programe de prezentare etc.), dar mai ales pentru a putea fi utilizate în aplicaţii specializate de analiză.Componentele unui depozit de date sunt următoarele:13

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

23

1. instrumente pentru modelarea datelor, asociate adesea cu instrumente de tip CASE;2. o enciclopedie a metadatelor care păstrează informaţiile relevante despre fiecare

dată a depozitului de date (ce reprezintă, tipul său, unde se găseşte, cum poate fi accesată, formatul său, etc.);

3. baza de date - nucleu care este centrul depozitului şi ia forma bazelor de date (foarte rar a fişierelor independente);

4. instrumente pentru transpotul datelor, proiectate pentru a muta copii ale datelor din sistemul operaţional în baza de date;

5. instrumentele pentru extragerea, rafinarea şi standardizarea datelor, sarcini foarte dificile în condiţiile în care informaţiile sunt foarte complexe, iar instrumentele de lucru eterogene;

6. middleware care asigură conectivitatea în cadrul reţelelor de calculatoare atunci când datele sunt preluate din mai multe baze de date sau o bază de date este distribuită pe mai multe noduri ale unei reţele;

7. instrumente pentru accesul utilizatorilor la date şi furnizarea informaţiilor care cuprind instrumente de tipul interfaţă grafică utilizator (GUI) sau navigatoare (browsere) Web ce permit utilizatorilor să acceseze şi analizeze informaţiile din depozitul de date.

Una din preocuparea actuală a producătorilor de instrumente de construire a depozitelor de date este integrarea celor şapte categorii de instrumente prezentate mai sus într-un produs atotcuprinzător, ceea ce unii au reuşit într-o oarecare măsură.14

Din punct de vedere al ariei de întindere, se întâlnesc trei modele de depozite de date: depozite de întreprindere, data marts şi depozite virtuale.

Un depozit de întreprindere colectează toate informaţiile despre subiecte care privesc întreaga organizaţie. El necesită cheltuieli mai mari pentru modelare şi ani de zile pentru proiectare şi realizare. El conţine de regulă date detaliate, dar şi date agregate, iar ca ordin de mărime porneşte de la câţiva gigabytes până la sute de gigabytes, terabytes sau mai mult.

Un data marts poate fi considerat un subansamblu al unui depozit de date, mai uşor de construit şi întreţinut şi mai puiţin scump. El conţine un subset al volumului de date din organizaţie, specific unui grup de utilizatori. Domeniul este limitat la subiecte specifice. De exemplu, un data mats pentru marketing limitează subiectele la clienţi, articole, vânzări. Un depozit virtual este un set de viziuni (views) asupra bazelor de date operaţionale. Este uşor de construit, dar necesită capacităţi suplimentare pe serverele de baze de date. Pentru eficienţa procesării interogărilor, numai unele din viziunile de agregare pot fi materializate.

Baza de date reprezintă "inima" depozitului. În practică, baza de date nucleu se poate regăsi sub forma fişierelor independente de date (mai rar), poate fi o bază de date relaţională 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 simulările sau predicţiile), adaptându-se astfel foarte bine în contexul depozitelor de date.

În ceea ce priveşte instrumentele de analiză şi acces la informaţii, două categorii, instrumentele de interogare şi cele OLAP se regăsesc pentru a combina accesul liber la informaţii şi funcţiile de analiză, fiind concepute pentru a răspunde nevoilor foarte diverse ale utilizatorilor finali. Astfel, anumiţi utilizatori sunt autonomi şi doresc un acces liber la informaţii fără a se îngriji de căile de acces la date. Instrumentele de tip interogare răspund nevoilor lor. Aceste instrumente favorizează formularea de interogări bazându-se pe logica asamblistă a bazelor de date relaţionale. Ele permit, de exemplu, obţinerea listei cu numele şi prenumele clienţilor care au cumpărat un anumit produs în cursul ultimelor trei luni. Alţi utilizatori exprimă cerinţe de analiză, ceea ce necesită o informaţie bine pregătită şi foarte organizată. Instrumentele de tip OLAP (On-Line Analytical Processing) sunt mai bine adaptate exigenţelor lor. Prelucrarea analitică on-line este un nou instrument la dispoziţia managerilor şi analiştilor pentru examinarea interactivă şi manipularea unui volum mare de

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

24

date analitice sau agregate sub diverse forme. OLAP înseamnă analiza relaţiilor complexe între mii şi chiar milioane de date pentru a descoperi tendinţe, modele şi excepţii. Operaţiile 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ă, implicând date aflate în legătură. Forajul este operaţiunea inversă şi se referă la afişarea datelor detaliate, pornind de la cele consolidate. Disecarea porneşte 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 tendinţele şi a descoperi modele de evoluţie.

Alţi utilizatori au nevoie de instrumente de data mining care permit structurarea informaţiei fără preocuparea pentru modul în care datele sunt puse în corelaţie, prin punerea în funcţiune a unor mecanisme de inducţie.

Prelucrarea analitică on-line, referită de regulă ca OLAP (On Line Analytical Processing) răspunde la întrebări pe care managerii şi le pun la modul concret. Singura trăsătură comună a acestor întrebări este caracterul lor multidimensional. Există totuşi câteva tipuri uzuale de întrebări, care pot arunca o lumină asupra complexităţii instrumentelor care trebuie să furnizeze răspunsuri: Raporturi multidimensionale. De exemplu: Care este contribuţia la vânzările săptămânale totale a produselor informatice vândute prin magazinele situate în regiunea Moldova între 10 şi 20 septembrie? Comparaţii. De exemplu: Care este media abaterii procentuale de la planul de vânzări în lunile acestui an comparativ cu anul trecut? Clasificări şi profiluri statistice. De exemplu: Care este volumul vânzărilor şi media profitului pentru primii 20% dintre distribuitori şi care este contribuţia acestora la totalul vânzărilor pe trimestrul trecut? Agregări libere. De exemplu: Care sunt veniturile realizate în ultimele patru trimestre de filialele judeţene din regiunea Moldova? Evaluări What-If. De exemplu: În ce măsură ar influenţa profitul total o creştere cu 10 procente a vânzărilor în judeţele din Moldova?

Instrumentele de data mining explorează bazele de date şi extrag din acestea o multitudine de informaţii asupra tendinţelor şi previziunilor. Câmpul de acţiune al data mining cuprinde nu numai analiza datelor, ci şi a textelor.

Depozitele de date nu înseamnă totuşi numai avantaje, ci ele ridică o serie de probleme înre care menţionăm:

dimensiunile extrem de mari la care pot ajunge, de ordinul gigaocteţilor, 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 integrării diferitelor platforme hardware şi software existente în cadrul

întreprinderii.

2.1.5. Proiectarea bazelor de dateRealizarea unei baze de date presupune parcurgerea următoarelor etape:

analiza sistemului (domeniului) pentru care se realizează baza de date, precum şi a cerinţelor informaţionale asociate;

proiectarea structurii bazei de date (schema conceptuală, internă şi externă); încărcarea datelor în baza de date ; exploatarea şi întreţinerea bazei de date15.

Activităţile desfăşurate în etapa de proiectare depind în mare măsură de specificul activităţii pentru care se doreşte realizarea unei baze de date, dar există şi o serie de elemente cu caracter general.

15 vezi Lungu, I. şi colab. ,Baze de date. Organizare, proiectare şi implementare, Editura ALL, Bucureşti, 1995, p. 26.

25

În literatura de specialitate se întâlneşte şi concepţia potrivit căreia proiectarea unei baze de date este un proces în doi paşi16:

etapa proiectării conceptuale (independentă de SGBD) - ar consta în analiza sistemului;

etapa proiectării fizice (în funcţie de un anumit SGBD) - grupează activităţile de proiectare a structurii, încărcare, exploatare şi întreţinere a bazei de date.

Obiectivele proiectării bazei de date pot fi grupate în două categorii:1. cerinţe funcţionale:

rapoartele (situaţiile de ieşire) necesare; cererile, interogările care pot apărea; alte ieşiri care ar putea fi trimise altor sisteme de prelucrare a datelor; toate actualizările necesare; toate calculele necesare; toate restricţiile sistemului (de exemplu, restricţii funcţionale sau restricţii de

comportament); toate sinonimele utilizate pentru un atribut dat;

2. restricţiile fizice (volumul prelucrărilor şi evaluarea performanţelor): numărul, dimensiunile şi frecvenţa rapoartelor; timpul de răspuns pentru fiecare interogare; timpul de răspuns pentru fiecare actualizare; măsurile de securitate prin restricţionarea accesului.

Analiza preliminară şi identificarea cerinţelor informaţionaleActivitatea de analiză cuprinde trei laturi importante:

analiza componentelor sistemului şi a legăturilor dintre acestea (analiza structurală sau statică)modelul structural sau static al sistemului;

analiza stărilor sistemului şi a tranziţiilor posibile între aceste stări (analiza comportamentală sau temporală)modelul dinamic (temporal) al sistemului;

analiza cerinţelor informaţionale, respectiv a transformărilor de date din cadrul sistemului prin care sunt satisfăcute necesităţile de informare ale organismului studiatmodelul funcţional al sistemului;

integrarea celor trei modele în scopul completării şi corelării lor.În urma acestei analize se trece la definirea structurii bazei de date. Importanţa analizei preliminare pentru definirea structurii diferă după modelul de organizare a bazei de date. Astfel, pentru modelele ierarhic şi reţea analiza structurală sau statică este foarte importantă, pentru modelul relaţional toate etapele au cam aceeaşi importanţă, iar pentru modelul OO trebuie acordat maximum de atenţie analizei temporale şi celei funcţionale.

Analiza structurală sau staticăAceastă etapă are rolul evidenţierii componentelor (obiectelor) din cadrul sistemului pentru care se proiectează baza de date, precum şi a legăturilor dintre aceste componente.Se cunosc în acest sens mai multe tehnici de analiză:

modelul canonic (James Martin) modelul Entitate-Asociere (Peter Chen); tehnica SDM - Semantic Data Model (Michael Hammer, Dennis McLeod) ş.a.Analiza dinamică (de comportament)

Are drept scop explicarea comportamentului elementelor sistemului analizat. Construirea modelului dinamic presupune:

identificarea stărilor î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 stărilor de tranziţie, a fluxului de evenimente).

16 Pratt, P.J., Adamski, J.J., Database Systems. Management and Design, Boyd&Fraser, Boston, 1991, p. 285

26

Analiza cerinţelor informaţionale (analiza funcţională)Urmăreşte determinarea transformărilor pe care le suportă datele în sistemul studiat,

în scopul satisfacerii cerinţelor informaţionale aferente acestui sistem. Transformările de date se prezintă sub forma unui flux al prelucrărilor, in care nodurile reflectă procesele şi arcele fluxurile informaţionale.

Construirea modelului funcţional implică o serie de etape: identificarea datelor de ieşire şi a celor de intrare; construirea de diagrame de flux; identificarea restricţiilor pentru anumite date; precizarea unor criterii de optimizare a prelucrărilor.Integrarea modelelor sistemului

În etapa de proiectare, modelele static şi dinamic sunt complet independente de SGBD (aplicaţiile) ce urmează a se folosi, pe când modelul funcţional este orientat preponderent spre acestea.

Rezultatele cercetării din etapele anterioare sunt supuse unui proces de integrare, în urma căruia se obţine o viziune de ansamblu a sistemului studiat. Cu această ocazie se testează completitudinea şi consistenţa modelelor static şi dinamic, anume dacă informaţiile dispun de coerenţă şi dacă nu au fost omise la analiză unele elemente informaţionale. În caz de necesitate, în această etapă se pot aduce completări modelului.Ca urmare a integrării, dispare independenţa faţă de aplicaţii a modelelor static şi dinamic, ca şi orientarea spre aplicaţii a modelului funcţional. Este un avantaj, deoarece pe de o parte orientarea excesivă spre aplicaţii complică în mod inutil modelul şi-i scad adaptabilitatea, iar pe de altă parte efectuarea unei analize complet independente de aplicaţii presupune un mare consum de resurse de toate tipurile.

Proiectarea structurii bazei de dateÎn urma analizei sistemului, se obţin aşa-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 schimbării SGBD ar fi nevoie de reproiectarea BD; caracteristicile unui anume SGBD pot limita activitatea de analiză, făcând modelul

foarte puţin flexibil; dacă utilizatorul final nu cunoaşte nimic despre un anume SGBD, este imposibil să-şi

formuleze cerinţele de informare în mod adecvat.Spre deosebire de analiza preliminară, proiectarea structurii bazei de date impune

focalizarea atenţiei asupra unui SGBD. Astfel, modelul conceptual este transpus într-un model al datelor care are caracteristicile proprii SGBD-ului ales de proiectant.Proiectarea structurii bazei de date implică următoarele activităţi17:

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. cerinţele utilizatorilor, sub aspectul:

tipurilor de aplicaţii; timpului de răspuns; confidenţialităţii şi securităţii datelor; uşurinţei în utilizare;

2. cerinţele de ordin tehnic: portabilitatea SGBD; portabilitatea datelor şi programelor de aplicaţii; condiţiile de încărcare, exploatare şi întreţinere a BD;

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

27

3. cerinţe de ordin economic: încadrarea în bugetul destinat acestui scop; timpul necesar pentru implementarea sistemului (inclusiv pregătirea

utilizatorilor).În urma analizei acestor cerinţe, ca şi a SGBD-urilor disponibile şi a modului cum ele oferă răspuns la cerinţele utilizatorilor, se decide care va fi SGBD utilizat.

Proiectarea schemei conceptualeÎn accepţiunea cea mai simplă, schema conceptuală semnifică descrierea datelor şi a

relaţiilor dintre acestea. Elaborarea schemei conceptuale presupune: stabilirea colecţiilor de date şi a conţinutului acestora; determinarea legăturilor dintre colecţiile de date; testarea şi revizuirea eventuală a schemei obţinute; descrierea schemei conceptuale în maniera proprie SGBD ales.

În stabilirea colecţiilor de date şi a legăturilor dintre acestea se porneşte de la entităţile identificate în etapa de analiză. Astfel, în cazul unui proces economic oarecare, aceste entităţi vor fi participanţii la procesul în cauză. Spre exemplu, în cazul unei activităţi comerciale, putem identifica la prima vedere câteva entităţi: cumpărător, vânzător, marfă etc.

Pentru aceste entităţi se vor preciza atributele sau proprietăţile care prezintă interes pentru utilizatorii informaţiei, eventual şi o serie de atribute auxiliare, utilizate pentru a exprima legături între entităţi.

Aceste entităţi alcătuiesc modelul semantic. Nu este obligatoriu ca fiecare componentă a acestui model să atragă constituirea unei colecţii de date distincte. Ąn practică, pentru îmbunătăţirea performanţelor aplicaţiilor (în special optimizarea timpului de acces la date), poate opera o sporire, dar şi o reducere a numărului de colecţii de date proiectate iniţial.

În realizarea colecţiilor de date se poate porni şi de la documentele de ieşire (cele care conţin informaţiile de care are nevoie utilizatorul), caz în care toate atributele identificate concură la alcătuirea unui dicţionar de date şi urmează a fi grupate în funcţie de anumite legături identificabile între atribute.

Modul de reprezentare a legăturilor dintre colecţiile de date identificate diferă în funcţie de modelul datelor pe care-l implică SGBD utilizat. Spre exemplu, pentru modelele ierarhic şi reţea se utilizează pointeri, iar pentru modelul relaţional, chei externe (străine).

Testarea schemei conceptuale presupune verificarea corectitudinii (a modului în care aceasta ilustrează cerinţele utilizatorilor) şi consistenţei acesteia (a corespondenţei dintre legăturile determinate şi lumea reală). De asemenea, trebuie ca redundanţa 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 priveşte descrierea schemei conceptuale, aceasta comportă transpunerea schemei în limbajul de manipulare a datelor specific SGBD ales. Rezultatul acestui proces îl constituie schema (în accepţiune CODASYL18) bazei de date.

Proiectarea schemei externePrin schemă externă se înţelege forma sub care un utilizator oarecare percepe schema

conceptuală. Prin programele de aplicaţii se oferă fiecărui utilizator o viziune oarecum "compartimentată" a BD, în funcţie de necesităţile sale specifice (există aici şi puternice raţiuni de securitate şi confidenţialitate a datelor). Acest mod de acces restrictiv la baza de date se materializează prin aşa-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ă. Totuşi, accepţiunea CODASYL defineşte schema externă (subschema) ca pe o parte componentă a schemei conceptuale, dar care poate înregistra diferenţe în ceea ce priveşte alcătuirea, faţă de schema conceptuală.

18 abreviere de la "Conference on Data Systems Languages"

28

Proiectarea schemei interneSchema internă, numită de unii autori şi schemă de memorare, se referă explicit la

modul de memorare a datelor pe suport (purtătorul de informaţie). Acest mod de memorare este specific SGBD utilizat. Din punctul de vedere al utilizatorului, această schemă nu trebuie să fie vizibilă.

Încărcarea datelor în baza de dateAceasta este o etapă inerentă proiectării bazei de date, şi constă în specificarea

conţinutului acesteia (a datelor pe care le va memora). Deşi activitatea nu este pretenţioasă, ea este destul de delicată, dat fiind volumul mare de date care trebuie vehiculate.

Un detaliu important este acela al încărcării BD numai cu date corecte, scop în care sunt necesare proceduri de validare şi corectare a datelor.

Sursele de date pot consta îndocumente primare,colecţii de date aflate deja pe suporturi (de exemplu, sisteme de fişiere), date preluate direct, fără intervenţia documentelor (prin schimb electronic de date).

Nu trebuie să se exagereze în direcţia procedurilor de validare utilizate, deoarece productivitatea introducerii datelor poate scădea în mod drastic.

Exploatarea şi întreţinerea bazei de dateExploatarea bazei de date este de resortul utilizatorilor finali şi implică utilizarea de

către aceştia a datelor din baza de date, în scopul satisfacerii cerinţelor informaţionale. Pentru aceasta, SGBD-urile dispun de limbaje de manipulare a datelor, ca şi de alte instrumente specializate (mai ales cele din categoria generatoarelor).

Întreţinerea bazei de date implică pe de o parte operaţii de actualizare (modificare a conţinutului), dar şi de reproiectare a structurii (aceasta din urmă fiind rezervată administratorului bazei de date).

Ca oricare alt sistem informatic, o bază de date poate ajunge într-o fază de declin, când întreţinerea sa devine nerentabilă. În acest caz se poate decide proiectarea unei noi baze de date.

2.2 MODELE CONCEPTUALE DE STRUCTURARE ŞI ORGANIZARE A DATELOR ÎN BAZE DE DATE

Pentru descrierea structurii datelor unei baze de date şi a relaţiilor dintre acestea sunt folosite procedee formale, concretizate în modele conceptuale. Acestea se particularizează prin terminologia utilizată şi prin relaţiile dintre date.

Tipuri de relaţii şi structuri de reprezentare a relaţiilor în cadrul unei baze de dateEntităţile aceluiaşi sistem informaţional sunt rareori izolate unele de altele, ele

antrenând, cel mai adesea, legături sau relaţii. Între datele diverselor tipuri de entităţi pot exista două categorii de legături sau relaţii. Prima priveşte relaţiile dintre datele aparţinătoare aceleiaşi entităţi, iar a doua se referă la relaţiile dintre mai multe entităţi care pot fi şi de tipuri diferite.

La rândul lor relaţiile pot fi binare şi n-are. Relaţiile binare presupun existenţa unui domeniu, a unui codomeniu şi a unei

corespondenţe între entităţile acestora. În practica bazelor de date se utilizează patru tipuri de relaţii binare:

1-1 (una-la-una) în care unei realizări din domeniu îi corespunde o realizare şi numai una din codomeniu. (Figura nr.2.5 )

29

X 1

X

X

2

.

.

n

YY

Y

1

2

.

.

n

Domeniu CodomeniuFig. 2.5 Relaţia de tip 1-1

1-n (una la mai multe) în care unei realizări din domeniu îi corespunde 0, una sau mai multe realizări din codomeniu. (figura nr. 2.6)

X 1

X 2

YYYYY

1

2

. 3.

4

5

Domeniu CodomeniuFig. 2.6 Relaţii de tip 1-n

n-1 (mai-multe-la-una) în care mai multe înregistrări din domeniu corespund unei realizări din codomeniu. (Figura nr.2.7)

X 1

X

X

2

3

Y

Domeniu CodomeniuFig. 2.7. Relaţia n-1

n-m (mai-multe-la-mai-multe) în care unei realizări din domeniu îi corespund 0, una sau mai multe realizări din codomeniu, iar unei realizări din codomeniu îi corespund 0, una sau mai multe realizări din domeniu (figura nr. 2.8):

X 1

X 2

YYYY

1

2

. 3.

4

Domeniu CodomeniuFig. 2.8.Relaţia n-m

Relaţiile n-are presupun existenţa unei interdependenţe logice între realizările unei mulţimi de caracteristici definită pe o mulţime de tupluri.

Mecanismul de selecţie şi de identificare a componentelor unei baze de date presupune existenţa unei structuri de date. Concret o structură de date reprezintă o colecţie de date între care s-au stabilit anumite relaţii. Structurile de date care au aceeaşi organizare şi sunt supuse prelucrărilor cu un grup de operatori de bază cu o semantică predefinită formează un anumit tip de structură.

30

Principalele tipuri de structuri sunt19: punctuală, liniară, arborescentă, reţea, relaţională. Dintre acestea sunt considerate de bază structurile liniară şi arborescentă. Prin combinarea lor în funcţie de opţiunile utilizatorilor, pot fi construite şi alte structuri cu grade diferite de complexitate.

2.2.2 Modele de organizare a datelor în bazele de dateUn model de date este un ansamblu de instrumente conceptuale care permit

descrierea datelor, a relaţiilor dintre ele, a semanticii lor, ca şi a restricţiilor 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 restricţiilor pe care trebuie să le respecte acestea. Cele mai cunoscute sunt: modelul entităţi-asociaţii, modelul semantic, modelul funcţional şi modelul orientat pe obiecte.

Modelul entităţi-asociaţii are la bază percepţia lumii reale sub forma unei colecţii de obiecte, denumite entităţi, unite prin intermediul unor asociaţii. O entitate este un obiect care poate fi diferenţiat de alte obiecte printr-un ansamblu de atribute care permit descrierea precisă a acestuia. O asociaţie reuneşte două sau mai multe entităţi. De exemplu, atributele Număr şi Disponibil descriu entitatea Cont la bancă. Atributele Nume, Adresă, etc. descriu entitatea Client. Există o asociaţie care leagă un client de fiecare din conturile pe care le are deschise la banca respectivă. Ansamblul entităţilor de acelaşi tip formează o clasă de entităţi, iar ansamblul asociaţiilor de acelaşi gen reprezintă o clasă de asociaţii.

În reprezentarea unei structuri de baze de date cu ajutorul modelului E-R se realizează o diagramă, care utilizează simbolurile:

 dreptunghi, pentru clase de entităţi,  elipse, pentru atribute, romburi, pentru clase de asociaţii, linii, pentru a lega atribute de clase de entităţi şi clasele de entităţi de clasele

de asociaţii.Exemplu

FurnizorAdresa

Localitate

FURNIZORI Cumparare FACTURI-PRIMITE

NumarData

Valoare

Fig. nr. 2.10. Modelul Entitate-Asociaţie

Modelul de date orientat spre obiecte extinde definiţia unei entităţi pentru a include nu numai atributele care descriu starea obiectului, ci şi acţiunile asociate acestuia, respectiv comportamentul. Se spune că obiectul încapsulează atât starea, cât şi comportamentul.

Modelul de date orientat pe obiecte reprezintă un model logic de date care conţine semantica obiectelor, acceptată în programarea orientată pe obiecte.

Modelarea orientată obiect devine din ce în ce mai populară datorită abilităţii de a reprezenta relaţii complexe ca şi de a reprezenta datele şi procesarea acestora cu ajutorul unor notaţii consistente.

Un model al datelor este o abstractizare a lumii reale ce permite "tratarea" complexităţii inerente în cazul problemelor din lumea reală prin concentrarea atenţiei asupra caracteristicilor esenţiale şi interesante ale datelor de care are nevoie o organizaţie. Un model orientat obiect este construit în jurul "obiectelor" tot aşa cum modelul E-A are la bază entităţile. Totuşi un obiect încapsulează atât datele cât şi comportamentul, ceea ce permite 19 Lungu, I., Op. cit., p. 6

31

utilizarea unei abordări orientate obiect nu doar pentru modelarea datelor, ci şi pentru modelarea proceselor. Pentru a modela cu stricteţe o aplicaţie din lumea reală trebuie să se modeleze atât datele, cât şi procesele ce acţionează asupra datelor. Modelarea orientată obiect asigură un mediu puternic pentru dezvoltarea unor sisteme complexe, datorită posibilităţii de captare a datelor şi a proceselor şi datorită mai ales, moştenirii şi reutilizării codului.

Ciclul de viaţă al proiectării orientate obiect constă din reprezentarea progresivă a obiectelor în cadrul a trei faze: analiză, proiectare şi implementare. Acest ciclu de viaţă este similar cu cel al dezvoltării sistemelor. În primele etape, modelul pe care îl creăm este abstract, concentrându-se asupra calităţii externe a sistemului. Pe măsură ce modelul evoluează, acesta devine din ce în ce mai detaliat, atenţia deplasându-se spre cum va fi construit sistemul şi mai ales, cum va funcţiona. Accentul în modelare trebuie pus pe analiză şi proiectare, în special pe problemele conceptuale front-end, faţă de problemele de implementare back-end ce restricţionează opţiunile de proiectare20.

În etapa de analiză este dezvoltat un model al aplicaţiei din lumea reală ce reprezintă proprietăţile sale importante. Modelul abstractizează concepte din domeniul aplicaţiei şi descrie ce anume trebuie să realizeze sistemul mai degrabă decât cum va fi realizat acest lucru. Modelul specifică în special comportamentul funcţional al sistemului, independent de problemele legate de mediul în care va fi implementat în final. Trebuie să se aloce suficient timp pentru înţelegerea clară a tuturor cerinţelor problemei în discuţie. Modelul de analiză captează aceste cerinţe în mod precis, concis şi cu acurateţe.

În faza de proiectare orientată obiect se defineşte cum va fi realizat modelul de analiză orientată obiect în cadrul mediului de implementare. Există trei motive pentru utilizarea proiectării orientate obiect:1. Modelul de analiză nu este suficient de formal pentru a fi implementat direct într-un

limbaj de programare. Pentru a ne deplasa către codul sursă trebuie să rafinăm mai întâi obiectele prin adoptarea unei decizii privind operatorii ce vor fi asiguraţi de un obiect, cum ar trebui să arate comunicaţia între obiecte, ce mesaje vor fi transmise etc.

2. Sistemul actual trebuie să fie adaptat mediului în care sistemul va fi implementat. Pentru a realiza acest lucru, modelul de analiză trebuie să fie transformat într-un model conceptual de proiectare, luând în considerare diferiţi factori cum ar fi: cerinţele de performanţă, cerinţele de timp real şi concurenţă, hardware-ul şi software-ul implicat, SGBD-ul şi limbajele de programare ce vor fi adoptate etc.

3. Rezultatele etapei de analiză pot fi validate cu ajutorul proiectării orientate obiect. În acestă etapă putem verifica dacă rezultatele furnizate de analiză sunt adecvate pentru construirea sistemului şi dacă este necesar să se efectueze modificări asupra modelului de analiză.

Pentru dezvoltarea modelului de proiectare trebuie să fie identificate şi investigate consecinţele pe care le va avea mediul de implementare asupra proiectării. Toate deciziile de proiectare strategice (cum va fi implementat SGBD-ul, cum vor fi asigurate comunicaţiile între procese şi tratarea erorilor, care componente vor fi reutilizate) vor fi adoptate şi vor fi apoi încorporate într-un prim model de proiectare adaptat mediului de dezvoltare. În final, modelul este formalizat pentru a descrie modul în care obiectele interacţionează unele cu altele pentru fiecare scenariu sau caz.

Rumbaugh separă activitatea de proiectare în două etape: proiectarea sistemului şi proiectarea obiectelor.

La proiectarea sistemulul trebuie propusă o arhitectură globală a sistemului care îl organizează în componente, numite subsisteme şi asigură contextul necesar adoptării deciziilor cum ar fi identificarea concurenţei, alocarea subsistemelor pe procesoare şi task-uri, asigurarea accesului la resursele globale, selectarea modalităţilor de implementare a controlului software etc.

În etapa de proiectare a obiectelor va fi construit un model de proiectare prin adăugarea unor detalii de implementare cum ar fi: restructurarea claselor pentru eficienţă,

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

32

structurile interne de date şi algoritmii pentru implementarea fiecărei clase, implementarea controlului şi a asociaţiilor (legăturilor), precum şi împărţirea în module fizice în concordanţă cu strategia adoptată în timpul proiectării sistemului. Clasele de obiecte specifice domeniului aplicaţiei din cadrul modelului de analiză vor fi îmbogăţite cu o serie de elemente specifice procedurilor de calcul în scopul optimizării performanţelor.

Etapa de proiectare este urmată de o etapă de implementare. În această fază, proiectul este implementat cu ajutorul unui limbaj de programare sau a unui SGBD. Translatarea proiectului în cod sursă este un proces relativ uşor datorită faptului că modelul de proiectare încorporează deja o serie de aspecte ale limbajului de programare şi SGBD-ului ales.

Unele din avantajele des citate în favoarea orientării spre obiecte sunt: Definiţia unui sistem prin intermediul obiectelor facilitează construcţia de

componente software care seamănă îndeaproape cu domeniul de aplicaţie, contribuind astfel la proiectarea şi înţelegerea sistemelor;

Datorită încapsulării şi ascunderii informaţiilor, întrebuinţarea obiectelor şi mesajelor încurajează proiectarea modulară;

Implementarea unui obiect nu depinde de structura internă a acestuia, ci de modul cum acesta răspunde la mesaje;

Întrebuinţarea claselor şi a moştenirii promovează dezvoltarea de componente reutilizabile şi extensibile în contrucţia de noi sisteme sau pentru actualizarea celor existente.O bază de date orientată spre obiecte este o colecţie de obiecte persistente şi

partajabile care sunt definite de un model de date orientat pe obiecte. Un sistem SGBD orientat pe obiecte este administratorul unei baze de date orientată pe obiecte.

Aspecte structurale ale modelului de date orientat pe obiecte: Obiectele sunt entităţi de bază care încorporează structuri de date şi operaţii; Fiecare obiect are un identificator unic, atribuit de sistem; Clasele descriu tipuri generice de obiecte; Conceptul de clasă este strâns legat de conceptul de moştenire; Clasele formează ierarhii de clase; Definirea unei clase este mecanismul de specificare a schemei bazei de date; Schema bazei de date se poate extinde prin definirea de noi clase; Definirea unei clase poate include atribute de tipuri definite de utilizator (imagine,

sunet); Se admit referiri recursive.

Operaţii ale modelului de date orientat pe obiecte: Obiectele comunică prin mesaje; Un mesaj poate fi trimis instanţelor din mai multe clase; Metodele pot fi definite, şterse sau modificate; Clasele pot fi definite, şterse sau modificate; Instanţa unei clase poate fi actualizată prin metode ce modifică valorile variabilelor

propriei instanţe.Reguli de integritate ale modelului de date orientat pe obiecte:

Obiectele trebuie să respecte caracteristicile clasei din care fac parte; Obiectele sunt încapsulate; Un obiect nu există fără să aibă un identificator; dacă obiectul este şters, se şterge şi

identificatorul; Restricţia de integritate cunoscută de la modelul relaţional nu este implementată (nu

există posibilitatea de ştergere în cascadă).

Modelele orientate pe înregistrare sunt utilizate pentru reprezentarea atât a structurii logice a bazei de date, cât şi a conţinutului acesteia. Un dezavantaj principal este absenţa instrumentelor prin care să se specifice restricţiile datelor. Cele mai utilizate sunt: modelul relaţional, modelul ierarhic şi modelul reţea.

Modelul relaţional reprezintă datele şi legăturile dintre ele sub forma unor tabele, în care liniile şi coloanele reprezintă un element distinct al bazei de date. Exemplu -

33

FURNIZORI FACTURI-PRIMITEFurnizor Adresa Localitate Furnizor Număr Data ValoareAlfa SRL

Unirii 2 Iaşi Alfa SRL 12540 12/02/07 1259.8

Beta SA Apelor 5 Bacău Beta SA 14870 14/02/07 3265Gama SA

Viilor 56 Iaşi Alfa SRL 24550 22/02/07 2987.5

Gama SA 18960 28/02/07 5420

Modelul ierarhic reprezintă structura datelor sub forma unui arbore, alcătuit din mai multe noduri; unele sunt noduri-părinte, altele sunt noduri-copil. Partea superioară este rădăcina. Un fiu nu poate exista independent de tatăl său, iar orice fiu poate fi la rândul său tată, deci poate avea unul sau mai mulţi fii.

Primul model utilizat pentru organizarea datelor în baze de date, modelul ierarhic se bazează deci pe structura arborescentă şi pe relaţiile 1-1 şi 1-n, prezentându-se sub forma unui arbore, în care se regăsesc pe un prim nivel – rădăcina (nodul-părinte), iar pe nivele următoare diferite elemente subordonate (noduri-copil). Nodul-părinte poate avea subordonate mai multe noduri-copil în timp ce un nod-copil poate avea un singur părinte. Rezultă că relaţia părinte-copil poate fi de tip 1-n, iar relaţia copil părinte poate fi doar de tip 1-1.

Acest model asigură organizarea datelor pe orice tip de suport magnetic şi reducerea timpului de acces la înregistrări. El are însă o serie de limite în special în operaţiile de actualizare când adăugarea de noi înregistrări, cu excepţia celor din colecţia de date rădăcină, se poate efectua numai cu specificarea colecţiilor de date superioare, iar ştergerea unei înregistrări duce la eliminarea fizică a tuturor înregistrărilor subordonate.

În figura nr.2.11 este prezentat un exemplu de model ierarhic:

Fig. nr.2.11. Modelul ierarhic

Modelul reţea este o dezvoltare a modelului ierarhic. Înregistrările sunt privite în baza de date ca o colecţie de grafuri.

Modelul reţea elimină redundanţele specifice modelului ierarhic şi se bazează pe structurile reţea şi pe relaţiile de tip 1-1, 1-n şi n-m. Caracteristica principală a acestui model este că acceptă ca orice colecţie de date să se situeze pe nivelul 1, astfel fiind permis accesul direct la realizările colecţiilor superioare (operaţie imposibilă în modelul ierarhic).

În plus, prin acest model este permisă reprezentarea unică a realizărilor în baza de date.

Legăturile fizice pe suport sunt asigurate prin intermediul unor caracteristici care exprimă pointer-ul (adresa de pe suport) a realizării superioare sau a realizării subordonate. Astfel reţeaua este un graf orientat alcătuit din noduri conectate prin arce. Nodurile corespund tipurilor de înregistrare, iar arcele pointerilor. În felul acesta este permisă introducerea înregistrărilor artificiale pentru a reprezenta legăturile n-are (n>2)

FACTURI-EMISE

Factura 1 Factura 2 Factura 3

Produs B

Produs B

Produs CProdus D Produs A Produs E Produs F

Produs AProdus A

34

FACTURI-EMISE

Factura 1 Factura 2 Factura 3

Produs A Produs B Produs C Produs D Produs E Produs FFig. nr. 2.12. Modelul reţea

După cum se observă din figura nr. 2.12, modelul admite relaţii de tip n-m, ceea ce are ca efect reducerea redundanţei datelor.

Modelele ierarhic şi reţea nu permit realizarea unei independenţe logice satisfăcătoare între date şi programe, deoarece relaţiile dintre date există şi sunt referite în programele de aplicaţii.

Modelul ENTITĂŢI – ASOCIAŢIIDefinirea entităţii este în acelaşi timp uşoară şi dificilă, existând 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 organizaţie, o entitate reprezintă un obiect al sistemului informaţional, care are existenţă proprie, prezintă importanţă pentru gestiunea organizaţiei şi este înzestrat cu o serie de proprietăţi. O entitate se caracterizează prin:

existenţă proprie; poate fi abstractă sau concretă; aparţine unei familii de obiecte de aceiaşi natură, numită clasă de entităţi; fiecare entitate este identificabilă şi caracterizată fără ambiguitate.Clasa de entităţi este deci un ansamblu de entităţi care au proprietăţi comune. De

exemplu, firma RTC este furnizor de hârtie pentru tipografia Polirom, deci RTC va fi un membru al clasei de entităţi FURNIZORI pentru firma Polirom.

Gruparea entităţilor î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 entităţi. 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 entităţi CLIENŢI pentru firma Polirom.

Orice entitate poate fi caracterizată printr-un ansamblu de atribute. Un atribut este o proprietate comună tuturor entităţilor 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 entităţi dintr-o altă clasă prin intermediul unei asociaţii. O asociaţie este o relaţie stabilită între două sau mai multe entităţi care, deşi nu are o existenţă proprie, poate fi purtătoarea unor proprietăţi. Mai multe asociaţii cu aceleaşi proprietăţi se reunesc în clase de asociaţii. O clasă de asociaţii este o relaţie definită pe una sau mai multe clase de entităţi. Pentru denumirea unei clase de asociaţii se alege un substantiv care reflectă logica legăturii dintre cele două clase de entităţi.

EXEMPLU: considerăm clasa FURNIZORI (cu atributele nume, localitate, cod fiscal) şi clasa FACTURI-PRIMITE care reuneşte toate facturile primite de la furnizori, cu următoarele atribute: număr factură, data, valoare factură. Definim clasa de asociaţii CUMPĂRARE pentru a lega furnizorii de facturile pe care le-au întocmit. Ansamblul legăturilor dintre cele 2 clase de entităţi este ilustrat în figura 2.13.

2546 13/02/07 2365Alfa SRL Unirii 2 Iaşi R12548171

35

3560 15/02/07 1879

Beta SA Ploii 21 Bacău R19857144 2478 18/02/07 3654

1266 20/02/07 1458.7Gama SA Viilor 50 Iaşi R19874001

1687 21/02/07 1897.1Fig. nr. 2.13. Modelul entitate-asociaţii

Funcţia care atrage o entitate într-o asociaţie se numeşte rol. Clarificarea rolului fiecărei clase de entităţi este esenţială în proiectarea bazei de date. De exemplu, pentru clasa de asociaţii CUMPĂRARE, rolul fiecărei entităţi din clasa FURNIZORI este întocmeşte, iar rolul fiecărei entităţi din clasa FACTURI-PRIMITE este-întocmită. Formularea rolului pemite identificarea unui cuplu entităţi-asociaţii. Pentru reprezentarea grafică a unei diagrame entităţi-asociaţii, în literatura de specialitate au fost propuse mai multe soluţii. Una din cele mai utilizate este prezentată mai în figura nr. 2.14.

Fig. nr. 2.14. Diagrama entitate-asociaţii

Metoda MERISE de proiectare a bazelor de date propune reprezentarea grafică din fig. nr. 2.15.

Fig. nr. 2.15. Reprezentare grafică prin metoda Merise

În caracterizarea oricărei clase de asociaţii se au în vedere trei elemente: dimensiunea, cardinalitatea şi caracterul obligatoriu sau facultativ al asociaţiei.

Dimensiunea (sau ordinul) unei asociaţii reprezintă numărul claselor de entităţi implicate într-o clasă de asociaţii. Din acest punct de vedere, există:

asociaţii unare, care se stabilesc între entităţile aceleiaşi clase;  asociaţii binare, prin care se stabilesc legături între entităţi din două clase

diferite; asociaţii ternare, în care apar 3 clase de entităţi;  asociaţii de ordinul n, care stabilesc relaţii între n clase de entităţi.Cele mai simple, dar şi cele mai utilizate sunt asociaţii binare. În practică apar deseori

şi asociaţii ternare.

FURNIZORINumeAdresăLocalitateCod_fiscal

CUMPĂRARE

FACTURINumărDatăValoare

întocmeşte esteîntocmită

FURNIZORINumeAdresăLocalitateCod_fiscal

CUMPĂRARE

FACTURINumărDatăValoare

36

Cardinalitatea defineşte numărul de entităţi dintr-o clasă de care poate fi legată o entitate dată prin intermediul unei asociaţii. Considerând cazul unei asociaţii binare, există patru cardinalităţi posibile (vezi fig nr. 2.16 şi 2.18):

x1

x2

x3

x4

y1

y2

y3

y4

TIP 1 la 1

x1

x2

x3

y1

y2

y3

y4

TIP 1 la nFig. nr.2.16

- cardinalitatea de tip 1 la 1, în care unei entităţi din clasa X îi este asociată o singură entitate din clasa Y şi reciproc. Pentru exemplul clasei de asociaţii CUMPĂRARE, ar avea o astfel de cardinalitate dacă fiecare factură ar fi întocmită de un singur furnizor (perfect adevărat) ş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 entităţi din clasa Y, în timp ce fiecare entitate din clasa Y poate fi asociată unei singure entităţi din clasa X. Clasa de asociaţii VÂNZARE are o astfel de cardinalitate, pentru că pentru fiecare client se pot întocmi mai multe facturi, dar o factură are un singur client (figura 2.17).Observaţie: Într-o diagramă entităţi-asociaţii, cardinalitatea este reprezentată prin indicarea, în dreptul clasei de entităţi a numărului maxim de asociaţii 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ă cardinalităţii se face invers faţă de modul de citire al acesteia.

CLIENTINumeAdresaLocalitateCod_fiscal

VANZARE

FACTURINumarDataValoare

n 1

Fig. nr. 2.17- cardinalitatea de tip n la 1, în care o entitate din clasa X este asociată unei singure entităţi din clasa Y, iar orice entitate din Y poate fi asociată la n entităţi din X. Este inversa cardinalităţii de tip 1 la n.- cardinalitatea de tip n la n, în care orice entitate din X poate fi asociată mai multor entităţi din Y, iar o entitate din Y este asociabilă mai multor entităţi din X.

37

x1

x2

x3

x4

y1

y2

y3

TIP n la 1

x5

x1

x2

x3

x4

y1

y2

y3

TIP n la nFig nr .2.18

Caracterul obligatoriu sau facultativ este legat de conceptul de restricţie de dependenţă. Dacă existenţa entităţii A din clasa X depinde de existenţa entităţii B din clasa Y se spune că A este dependentă de B. În acest caz, ştergerea entităţii B din BD atrage după sine ştergerea şi a entităţii A. Entitatea B este numită entitate dominantă. În clasa de asociaţii VÂNZARE, clasa de entităţi FACTURI este dependentă de clasa de entităţi CLIENŢI, deci CLIENŢI este o clasă dominantă.

În lucrările de specialitate, restricţia de dependenţă dintre două clase de entităţi se exprimă prin sintagma “clase de asociaţii obligatorii sau faculative”. Astfel, clasa de asociaţii VÂNZARE este obligatorie pentru FACTURI (nu poate apare o factură emisă în absenţa unei vânzări) şi facultativă pentru clasa de entităţi CLIENŢI. Se spune că numărul minim de asociaţii din VÂNZARE în care poate apare o entitate din FACTURI este 1, iar numărul minim de asociaţii în care poate apare un client este 0. În diagramele E-A, în dreptul fiecărei clase de entităţi apare o pereche de valori: prima arată cardinalitatea minimă, care este legată de caracterul obligatoriu/facultativ al clasei de asociaţii pentru clasa de entităţi respectivă, iar a doua valoare reprezintă cardinalitatea maximă (ceea ce s-a prezentat mai sus) (vezi figura nr. 2.19).

CLIENTINumeAdresaLocalitateCod_fiscal

VANZARE

FACTURINumarDataValoare

0,n 1,1

Fig. nr. 2.19

Diagrama din figura 2.19 poate fi interpretată astfel: fiecare entitate din clasa CLIENŢI poate apare în maxim n asociaţii din clasa VÂNZARE şi minim în 0 (nici una), iar fiecare entitate din clasa FACTURI poate apare în maxim 1 asociaţiidin clasa VÂNZARE şi minim 1 asociaţie din această clasă.

2.3 SISTEME DE GESTIUNE A BAZELOR DE DATE

SGBD-urile reprezintă un software complex care realizează/asigură independenţa, relaţiile logice între date şi o redundanţă minimă a acestora. Ele trebuie să permită dezvoltarea rapidă şi la un cost avantajos a programelor de aplicaţii pentru exploatarea datelor dintr-o structură complexă, precum şi accesul rapid la date şi asigurarea securităţii lor.

SGBD-ul reprezintă un sistem de programe care permite utilizatorului definirea, crearea şi întreţinerea bazei de date şi accesul controlat la aceasta.

Sistemul SGBD constă în elemente de software care interacţionează cu programele aplicaţie ale utilizatorului şi cu baza de date. De obicei, un SGBD oferă următoarele facilităţi1. 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 constrângerile asupra datelor sunt stocate în baza de date

38

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. Existenţa unui limbaj de interogare elimină dificultăţile sistemelor bazate pe fişiere unde utilizatorul este constrâns să lucreze cu un set fix de interogări 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 funcţie de operaţiile de extragere. De obicei, cele procedurale tratează baza de date înregistrare cu înregistrare, în timp ce cele neprocedurale operează asupra unor seturi de înregistrări. În consecinţă, limbajele procedurale specifică cum se obţine rezultatul unei instrucţiuni DML, iar cele neprocedurale descriu numai ce date vor fi obţinute. Cel mai obişnuit tip de limbaj neprocedural este limbajul structurat de interogare (SQL) care reprezintă acum atât limbajul standard, cât şi cel de facto pentru SGBD relaţionale.

3. Oferă accesul controlat la baza de date. De exemplu, poate furniza- un sistem de securitate care previne accesarea bazei de date de către utilizatori

neautorizaţi- un sistem de integritate care menţine concordanţa datelor stocate- un sistem de control al concurenţei 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 defecţiuni în hardware sau software- un catalog accesibil utilizatorilor care conţine descrieri ale datelor din baza de date

SGBD-ul prezintă şi o facilitate cunoscută sub denumirea de mecanism de vizualizare care permite fiecărui 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 redundanţei datelor- coerenţa datelor- mai multe informaţii de la aceeaşi cantitate de date- partajarea datelor- integritatea crescută a datelor- securitatea crescută- aplicarea standardelor- economia de scală- echilibru între cerinţe aflate în conflict- îmbunătăţirea accesibilităţii datelor şi capacităţii de răspuns- productivitatea crescută- capacitatea de întreţinere îmbunătăţită, prin independenţa de date- concurenţa îmbunătăţită- îmbunătăţirea serviciilor de salvare de siguranţă şi refacere

2.3.1 Arhitectura sistemelor de gestiune a bazelor de dateTeoria şi practica SGBD-urilor oferă diferite arhitecturi diferenţiate în funcţie de

componentele, limbajele utilizate şi posibilităţile de prelucrare a datelor, existând totuşi preocupări de standardizare a cestora.

În general, intră în arhitectura unui SGBD cel puţin 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 întreţinere a bazei de date; componente de control a programelor de aplicaţii.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 aplicaţii sau interactiv prin intermediul ecranului.

39

Limbajul de descriere a datelor (LDD) permite traducerea (compilare sau interpretare, după caz) şi descrierea naturii datelor şi a legăturilor lor logice fie la nivelul global (sub forma schemei conceptuale), fie la nivelul specific fiecărei aplicaţii (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 întreţinere a bazei de dateUn SGBD trebuie să ofere o gamă variată de programe utilitare care să permită

gestionarea de către un operator a bazei de date. Utilitarele variază de la un sistem la altul şi depind de complexitatea SGBD-ului. Acestea pot efectua următoarele operaţii21:

crearea versiunii iniţiale a bazei de date şi încărcarea acesteia folosindu-se fie o copie creată anterior, fie date neorganizate;

crearea şi actualizarea jurnalelor tranzacţiilor realizate asupra bazelor de date. Acest utilitar controlează fiecare tranzacţie reţinând în jurnal următoarele informaţii:

identificatorii de program, de utilizator şi terminalul folosit; determinarea “timpului-maşină”; structura şi conţinutul bazei înainte şi după tranzacţie; natura tranzacţiei (sistem sau aplicaţie); înscrierea datelor transmise tampoanelor SGBD-ului în jurnalul

sistemului; reorganizarea bazei de date pentru recuperarea spaţiului vid; reorganizarea structurii fizice şi logice după tranzacţie; restructurarea bazei de date după un incident logic sau fizic, cu refacerea stării

existente anterior acestuia. Restaurarea este determinată de existenta în cadrul SGBD-urilor a aşa-numitelor puncte-de-reluare (Checkpoint)22 în cazul unor întreruperi în exploatarea unei baze de date, reluarea exploatării se va face nu de la începutul bazei de date, ci de la Checkpointul precedent;

diverse statistici ce permit cunoaşterea activităţii şi utilizării bazei de date; actualizarea schemei şi sub-schemei fără rescrierea şi compilarea lor; detectarea “spărgătorilor” regulilor de integritate definite, fără a fi necesară

intrarea în baza de date; realizarea unei copii permanente a bazei de date în scopuri de securitate.Componentele de controlAcestea constituie mijloace de prevenire şi corectare a anumitor erori ce pot să apară

în condiţii “multi-utilizator”.Integritatea bazei de date poate fi privită din mai multe puncte de vedere: dacă datele trebuie să fie modificate printr-o aplicaţie, atunci secvenţa completă a

acestei operaţii trebuie protejată de orice propagare sau interferenţă cu alte aplicaţii;

dacă o aplicaţie efectuează doar o citire a datelor, atunci execuţia acesteia trebuie să interzică modificarea datelor astfel încât să se evite riscul invalidării datelor citite în prealabil. Se asigură astfel blocarea actualizării în timpul operaţiei de citire;

în cazul în care cel puţin două aplicaţii accesează concurent aceeaşi dată în cadrul unei operaţii de actualizare, atunci integritatea bazei de date este “ameninţată”.

Schematic structura unui SGBD pate fi prezentată ca în figura 2.20:

21 Saleh, I., Op. cit., p. 1322 Ginguay, M., Lauret, A., Dictionnaire d’informatique, Ed. Masson, Paris, 1990, p. 215

40

Structura BD

L DD

PGBD

L M D

Programe deaplica¡ii

Comp. controlUt. între¡inere

Bazade

date

SGBD

A dministratorulBD Utilizatori

Fig. 2.20. Structura generală a unui SGBD

2.3.2 Funcţiile unui SGBDOrice SGBD trebuie să îndeplinească următoarele funcţii: de descriere, de

manipulare, utilizare.Funcţia 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 confidenţialităţii şi integrităţii datelor. Toate aceste elemente se regăsesc în ceea ce se numeşte schema bazei de date. Execuţia definiţiilor limbajului se materializează într-un ansamblu de tabele, memorate într-un fişier special denumit dicţionar de date (repertoar de date)23.

Funcţia de manipulare asigură prin intermediul limbajului special LMD derularea următoarelor activităţi: încărcarea bazei de date, adăugarea de noi înregistrări, ştergerea unor înregistrări, editarea totală sau parţială a unor înregistrări, ordonarea înregistrărilor, căutarea logică sau fizică a înregistrărilor etc.

Funcţia de utilizare permite comunicarea între utilizatori şi baza de date prin intermediul unor interfeţe, creându-se astfel un mediu favorabil utilizatorului care la ora actuală beneficiază de prelucrarea în timp real, arhitecturile client-server, servicii Internet etc.

În cadrul realizării acestei funcţii interacţionează diverşi utilizatori, literatura de specialitate oferind mai multe clasificări sau grupări. Dintre acestea am selectat doar câteva astfel de grupări. 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 defineşte schema conceptuală a bazei de date. Această schemă furnizează o viziune pe termen lung şi este baza pentru declaraţiile 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 întreţinerii acesteia. În acelaşi raport sunt prezentate trei categorii de administratori:

administratorul întreprinderii care asigură gestionarea globală a aplicaţiilor curente şi identificarea celor viitoare;

administratorul aplicaţiilor care are rolul de a dezvolta schemele externe (sub-schemele) pentru aplicaţiile utilizator;

administratorul de date care operează la nivelul schemei de date precizând necesarul şi disponibilitatea datelor;

programatorii de aplicaţii şi utilizatorii finali care comunică cu SGBD-ul prin intermediul limbajului de manipulare sau a limbajului de interogare.

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

41

Într-o altă viziune utilizatorii pot fi structuraţi astfel24:1. utilizatorii liberi sau conversaţionali, reprezintă beneficiarii (utilizatorii neinformaticieni)

a informaţiilor care nu dispun de cunoştinţe despre structura bazei de date şi nici despre sistemul de calcul pe care este implementată baza de date. În schimb au la dispoziţie limbaje de interogare a bazei de date într-o formă simplistă;

2. utilizatori programatori care utilizează limbaje de manipulare realizând proceduri complexe de exploatare a bazei de date. Aceşti utilizatori cunosc atât structura bazei de date cât şi particularităţile sistemului de operare, ceea ce le dă posibilitatea să exploateze toate facilităţile oferite de baza de date;

3. administratorul bazei de date care are cel mai important rol în funcţionarea şi exploatarea optimă a întregului sistem, asigurând realizarea obiectivelor şi funcţiilor SGBD-ului.

O ultimă clasificare asupra căreia ne-am oprit grupează utilizatorii în trei mari categorii25:utilizatori finali – care interacţionează cu baza de date prin intermediul unui limbaj de

interogare sau care apelează programe scrise de programatorii de aplicaţii;programatorii de aplicaţii care au rolul de a crea programele de aplicaţii ale bazei de date,

utilizând 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 lângă aceste categorii de utilizatori, bazele de date pot fi accesate fraudulos de

persoane cu cunoştinţe de specialitate care încearcă să sustragă sau să distrugă informaţii, provocând daune proprietarilor băncilor de date. Aceşti utilizatori sunt cunoscuţi sub numele de hacker-i.

2.4. Arhitecturi multiutilizator pentru sisteme de gestiune a bazelor de date

Arhitecturile uzuale utilizate pentru implementarea sistemelor de gestiune a bazelor de date multiutilizator sunt teleprelucrarea, arhitectura fişier-server şi client – server.

2.4.1. Teleprelucrarea

Prima metodă de realizare a unei baze de date multiutilizator a fost teleprelucrarea la care există un calculator cu o singură unitate centrală de prelucrare şi un număr de terminale (figura nr. 2.21).

Figura nr.2.21. Sistem cu teleprelucrare

Toată procesarea este efectuată pe acelaşi calculator. Terminalele utilizatorilor sunt incapabile să funcţioneze singure, ele fiind legate la calculatorul central. Utilizatorii transmit mesaje şi date de la terminale către calculatorul central. Subsistemul de control al comunicaţiilor din cadrul sistemului de operare primeşte mesajele şi datele şi le transmite

24 Lungu, I., ş.a. Op. cit., p. 1925 Sabău, Ghe., Op. cit., p. 18

Utilizator 1

Utilizator 2

Utilizator n

Sistem operare (control comunicaţii) SGBD

Sistem operare (date)

Program de aplicaţie 1

Program de aplicaţie 2

Program de aplicaţie 3

Baza de

date

42

programului de aplicaţii al utilizatorului corespunzător, acesta apelând la serviciile SGBD-ului. În acelaşi mod, mesajele sunt transmise înapoi la terminalul utilizatorului.

SGBD-ul utilizează partea de management a datelor din cadrul sistemului de operare pentru a procesa datele din baza de date. Toate comenzile din cadrul unui astfel de sistem sunt generate de calculatorul central şi transmise pe canale de comunicaţie, sistemul numindu-se “cu teleprelucrare” (tele=distanţă).

Pe lângă sarcina rulării programelor aplicaţie şi a sistemului SGBD, calculatorul central trebuie să preia şi o cantitate semnificativă de muncă din partea terminalelor (de exemplu, formatarea datelor pentru afişarea pe ecran).

Pe măsură ce raportul preţ/performanţă al calculatoarelor a crescut, tendinţa a fost de utilizare a altor alternative ce implică mai multe calculatoare: arhitecturile fişier - server şi client - server.

2.4.2. Arhitectura fişier-server

Într-un mediu fişier-server, procesarea este distribuită în reţea - de obicei o reţea LAN. Arhitectura fişier-server cuprinde fişierele cerute de aplicaţii şi sistemul SGBD. Aplicaţiile şi sistemul de gestiune sunt executate pe fiecare staţie de lucru, solicitând când este necesar fişiere de la serverul de fişiere. Astfel, serverul de fişiere acţionează ca o unitate de hard-disc partajată. SGBD-ul local de pe fiecare staţie de lucru trebuie să ceară serverului de fişiere să-i transmită toate tabelele de care are nevoie pentru a efectua interogările.

Această arhitectură are următoarele dezavantaje:1. Există un trafic intens pe reţea;2. Este necesară o copie completă a sistemului SGBD pe fiecare staţie de lucru;3. Controlul simultaneităţii, reconstituirii şi integrităţii este mult mai complex deoarece

acelaşi fişier poate fi accesat de mai multe sisteme SGBD.

Figura nr. 2.22. Arhitectura fişier-server

Utilizator 1

Utilizator 2

Utilizator N

Client N

Client 2

Client 1

SGBD

SGBD

SGBD

BD

Server de fişiere

Sistem de operare (reţea)

Sistem de operare (date)

Sistem de operare (reţea)

Sistem de operare (reţea)

Sistem de operare (reţea)

Programaplicaţii 1

Programaplicaţii 2

Programaplicaţii 2

Programaplicaţii 2

Programaplicaţii 3

LAN

.

.

.

43

2.4.3. Arhitectura client/server

Toate organizaţiile din ziua de azi (guvernamentale, economice) şi majoritatea întreprinderilor mari şi mici recunosc rolul central pe care aplicaţiile software îl au în cadrul lor, aplicaţiile având rolul reducerii costurilor şi îmbunătăţirii serviciilor faţă de competiţie.

Această dezvoltare şi necesitatea utilizării pe o arie mare a unor date de interes comun a dus la apariţia, utilizarea şi proiectarea modelului client/server, care oferă date distribuite, portabilitate între platforme şi un acces standardizat la resurse.

Termenul de client/server provine de la metoda tradiţională de accesare a unui computer central numit server de către computere aflate la distanţă sau clienţi într-o infrastructură de reţea..

Modelul client/server (figura nr. 2.23) implică o entitate software (clientul) care efectuează cereri, acestea fiind îndeplinite de o altă entitate software (serverul). Clientul este cel ce transmite o cerere server-ului, acesta o interpretează şi apoi o efectuează. Pentru a putea îndeplini cererea, serverul poate referi o sursă de informaţie (baze de date), poate să efectueze procesări asupra datelor, să controleze periferice sau să efectueze cereri adiţionale altor servere. În foarte multe arhitecturi, un client poate face cereri la multiple servere şi un server poate deservi mai mulţi clienţi.

Relaţia între client şi server este una de comandă/control, clientul iniţiază cererea şi serverul este cel care o îndeplineşte, transmiţând rezultatul clientului, aplicaţia fiind procesată prin divizarea ei între cele două entităţi, iar transferul de date este bidirecţional. Un server nu iniţializează niciodată un dialog cu clienţii. Clientul poate funcţiona pe un server hardware şi să efectueze cereri de la un server care rulează pe un alt server hardware sau pe un PC sau clientul şi serverul pot funcţiona pe acelaşi computer.

Spre deosebire de un sistem file/server în care datele sunt aduse de pe file server pentru a fi procesate pe o maşină locală, în acest sistem comenzile sunt transmise asupra bazelor de date localizate pe server, rezultatul fiind transmis înapoi clientului pentru a fi vizualizat.

Arhitectura afectează toate aspectele software, ea trebuie să ia în considerare complexitatea aplicaţiei, nivelul de integrare şi interfaţare cerut, numărul utilizatorilor, răspândirea lor geografică, natura reţelelor şi toate tipurile de tranzacţii necesare. De asemenea, alegerea arhitecturii afectează timpul de dezvoltare, flexibilitatea, precum şi întreţinerea aplicaţiei. La majoritatea aplicaţiilor end user se urmăreşte: prezentare, procesare şi date. Arhitecturile client/server definesc cum aceste trei componente sunt împărţite între entităţile software şi distribuite în reţea, există o varietate de moduri în care pot fi divizate şi implementate, utilizarea unor astfel de arhitecturi putând aduce multe beneficii firmelor, permiţând adaptarea la diferite standarde şi tehnologii.

O arhitectură client/server descrie un model de calcul pentru dezvoltarea unor sisteme automate, model ce se bazează pe distribuirea funcţiilor între două tipuri independente şi autonome de procese, respectiv procese server şi procese client.

Un client este un proces oarecare care solicită servicii specifice de la procese server, în timp ce un server este procesul care furnizează serviciile cerute de către clienţi.

Atât procesele client, cât şi cele server pot fi amplasate pe acelaşi calculator sau pe calculatoare diferite din cadrul unei reţele, reţeaua legând serverele şi clienţii şi asigurându-le mediul de comunicaţie. Teoretic, calculatoarele implicate pot fi mainframe-uri, minicalculatoare sau microcalculatoare. Datorită costurilor, cel mai adesea în cadrul unei arhitecturi client-server sunt implicate microcalculatoare.

Cele trei componente fundamentale ale unei arhitecturi client/server sunt: Clientul, cunoscut şi sub denumirea de "aplicaţie front-end", datorită faptului că

utilizatorii finali interacţionează cu procesele client; Serverul, cunoscut şi sub denumirea de "aplicaţie back-end", datorită faptului că

procesele server furnizează serviciile de bază sau elementare pentru procesele client; Componenta comunicaţie (communication middleware) care reprezintă mulţimea

proceselor de comunicaţie între procesele server şi procesele client, având rolul de supervizare a transmisiei datelor şi informaţiilor de control între servere şi clienţi.

44

Componenta de comunicaţie este asociată întotdeauna cu o reţea de comunicaţie ce asigură suportul pentru circulaţia sub formă de mesaje a tuturor cererilor clienţilor şi a răspunsurilor serverelor.

În cadrul arhitecturii client/server, clienţii au următorul rol: Asigură interfaţa bazei de date cu utilizatorul; Acceptă şi verifică sintaxa intrărilor (datelor) utilizatorilor; Generează cererile utilizatorilor pentru baza de date şi le transmite serverului; Recepţionează rezultatele de la server; Formatează rezultatele.

Serverul are următorele funcţii: Primeşte şi procesează cererile clienţilor pentru baza de date; Verifică autorizarea; Garantează că nu sunt încălcate contrângerile de integritate; Efectuează procesarea interogare/reactualizare şi trimite clientului răspunsul; Întreţine catalogul de sistem care descrie datele; Oferă acces simultan la baza de date; Asigură restaurarea şi refacerea bazei de date; Optimizează interogarea bazei de date.

Procesele client sunt procese proactive, iniţiind comunicaţia cu procesele server, în timp ce procesele server sunt reactive, aşteptând cererile proceselor client.

Figura nr. 2.23. Arhitectura client-server

Un proces server poate asigura următoarele categorii de servicii: Servicii de fişiere pentru o reţea locală de calculatoare în care fiecare calculator

client accesează discul dur al calculatorului server ca şi cum ar fi un disc dur local; Servicii de imprimare în cadrul unei reţele în care fiecare calculator client accesează

imprimanta sau imprimantele calculatorului server ca şi cum ar fi locale; Servicii de fax, calculatorul server fiind echipat cu o placă de fax/modem şi

gestionând toate problemele legate de transmisia datelor; Servicii de baze de date - calculatorul server stochează datele propriu-zise şi motorul

sistemului de gestiune a bazelor de date, în timp ce pe calculatoarele client se găseşte aplicaţia front-end pentru accesarea datelor;

Servicii de tranzacţii oferite de către un server de tranzacţii conectat la un server de baze de date;

Alte servicii, incluzând servicii audio, video, CD-ROM, backup etc.

Utilizator 1

Utilizator 2

Utilizator N

Client N

Client 2

Client 1

BD

Server de BD

Sistem de operare (reţea)

Sistem de operare (date)

Sistem de operare (reţea)

Programaplicaţii 1

Programaplicaţii 2

Programaplicaţii 2

Programaplicaţii 2

Programaplicaţii 3

LAN

Sistem de operare (reţea)

Sistem de operare (reţea)

SGBD

.

.

.

45

Componenta comunicaţie se referă la un software cu rol special care: Este amplasat logic între procesele client şi server; Asigură servicii specializate pentru a "ascunde" clienţilor detaliile protocoalelor de

comunicaţie în reţea şi a protocoalelor propriu-zise ale serverului.Pentru a-şi îndeplini funcţiile, software-ul de comunicaţie posedă următoarele două

nivele: Nivelul fizic se referă la modul în care calculatoarele client şi server sunt conectate

fizic; Nivelul logic se ocupă de comunicaţia dintre procesele client şi server, fiind nivelul

protocoalelor de comunicaţie interprocese care asigură "conversaţia". Componentele unei arhitecturi client-server trebuie să se conformeze următoarelor

principii fundamentale pentru a interacţiona corect:- Independenţa hardware care impune ca procesele server, client şi de comunicaţie să

funcţioneze pe diferite platforme hardware fără diferenţe funcţionale.- Independenţa software faţă de sistemele de operare, faţă de sistemele de operare în

reţea, faţă de aplicaţii care impune ca procesele server, client şi de comunicaţie să funcţioneze în condiţiile existenţei unor diferite sisteme de operare, protocoale software şi aplicaţii, fără diferenţe funcţionale.

- Accesul liber la serviciile oferite de servere trebuie asigurat tuturor clienţilor unui sistem. Aceste servicii nu trebuie să depindă de locaţiile clienţilor sau serverelor. Un alt factor cheie este acela că serviciile sunt furnizate doar la cerere.

- Distribuirea proceselor impune respectarea următoarelor reguli: Procesele client şi server trebuie să fie entităţi autonome cu funcţiuni bine definite,

conducând astfel la creşterea modularităţii şi flexibilităţii întregului sistem. Maximizarea utilizării locale a resurselor, atât la nivelul clienţilor, cât şi la nivelul

serverelor Asigurarea scalabilităţii, în sensul existenţei posibilităţii de extensie rapidă a sistemului Asigurarea interoperabilităţii şi integrării. - Standardele trebuie să guverneze interfaţa cu utilizatorii, accesul la date, protocoalele de reţea, comunicaţia interprocese. În prezent, din multitudinea de procese se remarcă două, pentru accesul la date şi anume ODBC (Open Data Base Connectivity) şi IDAPI (Integrated Database Application Programming Interface).

Există multe avantaje ale arhitecturii client/server: Permite un acces mai larg la bazele de date existente; Are performanţe crescute - dacă clienţii şi serverul se află pe calculatoare diferite,

atunci diferite unităţi centrale de prelucrare pot procesa aplicaţii în paralel; reglarea serverului este mai uşor de efectuat dacă singura sa sarcină este de a efectua prelucrarea bazei de date;

Reduce costurilor dispozitivelor hardware - numai serverul necesită o capacitate de stocare şi o putere de prelucrare suficiente pentru a stoca şi gestiona baza de date;

Reduce costurile comunicaţiilor - aplicaţiile execută o parte din operaţii la client care trimite prin reţea numai cererea de acces la baza de date, ceea ce face ca pe reţea să circule mai puţine date;

Măreşte coerenţa - serverul poate trata verificările de integritate astfel încât constrângerile trebuie definite şi validate într-un singur loc, fără a fi necesar ca fiecare program aplicaţie să execute propriile verificări.Principalul dezavantaj al arhitecturii client/server este cel legat de control.

Calculatoarele client operează simultan şi din acest motiv procesează aplicaţiile în paralel, ceea ce determină posibilitatea apariţiei unor pierderi de date la actualizări.

În contextul bazelor de date, arhitectura client/server înseamnă: Clientul administrază interfaţa cu utilizatorul şi logica aplicaţiei, acţionând ca o staţie

de lucru sofisticată pe care sunt executate aplicaţiile bazei de date. Clientul preia cererea utilizatorului, verifică sintaxa şi generează cererea pentru baza

de date în limbajul SQL sau în alt limbaj de baze de date, adecvat logicii aplicaţiei. Pe

46

urmă transmite mesajul serverului, aşteaptă un răspuns şi îl formatează pentru utilizatorul final.

Serverul acceptă şi procesează cererea pentru baza de date după care transmite rezultatul clientului. Procesarea implică verificarea autorizării, asigurarea integrităţii, întreţinerea catalogului de sistem şi procese de interogare şi reactualizare. În plus, se asigură controlul simultaneităţii şi reconstrucţiei. Nu putem încheia abordarea privind bazele de date în arhitectura client/server fără să

amintim de adaptabilitatea organică pentru Internet. Majoritatea serviciilor Internetului se desfăşoară în regim client/server (banala navigare înseamnă un utilizator accesând datele dintr-un site-server prin intermediul unei aplicaţii client care este browserul de Web), astfel că devine naturală implicarea SGBDR-urilor în aplicaţii Internet de genul e-business sau e-commerce26.

2.5. Protecţia şi securitatea bazelor de datePrin protecţia bazei de date se înţelege un ansamblu de activităţi umane şi de facilităti

oferite de SGBD prin care se urmăreşte asigurarea integrităţii datelor (corectitudinii datelor memorate în baza de date) şi securităţii datelor (restricţionarea accesului la date). Cu cât aria de cuprindere a SGBD este mai vastă, cu atât aceste două obiective sunt mai importante şi mai dificil de realizat.Cu privire la integritatea datelor, pot să apară trei situaţii practice:

1. Asigurarea integrităţii semantice a datelor. Obiectivul impune de fapt evitarea introducerii de date incorecte sau efectuarea unor prelucrări incorecte. Erorile trebuie sesizate la un interval de timp cât mai scurt după apariţia lor.

2. Controlul accesului concurent la date. Acesta implică evitarea obţinerii de rezultate neverosimile ale prelucrărilor ca urmare a execuţiei concurente a mai multor prelucrări în regim multiutilizator.

3. Salvarea şi restaurarea bazei de date. În cazul funcţionării anormale a sistemului, bazele de date trebuie să poată fi readuse la starea avută înainte ca defecţiunea să survină.

Integritatea semantică se poate asigura atât prin proceduri de validare incluse în programele de aplicaţii, cât şi prin instituirea unor reguli de integritate asupra bazei de date. Există restricţii de integritate implicite şi explicite (acestea din urmă se mai numesc şi restricţii de comportament). Ca restricţii implicite, la modelul relaţional avem integritatea entităţii (se referă la valori nenule ale cheii) şi integritatea referenţială. Restricţiile explicite de integritate (ex: nici un salariu să nu fie mai mare de 10000000 lei) pot fi definite în programele de aplicaţii sau, dacă SGBD o permite, pot fi memorate în dicţionarul de date, sub formă de proceduri stocate, declanşatori 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 "execuţie întreţesută"). Întreruperea accesului unui program la baza de date pentru a permite accesul altuia poate avea consecinţe grave asupra operaţiunii în curs, alterând datele.Pentru controlul accesului concurent, SGBD multiutilizator operează cu mecanismul tranzacţiilor. Tranzacţia este o secvenţă de operatii care din punctul de vedere al SGBD se constituie ca un tot unitar, acceptându-se fie derularea ei completă, fie anularea tuturor modificărilor aduse bazei de date (derularea inversă). Orice tranzacţie are un punct de început şi unul de sfârşit. Tranzacţiile sunt de două tipuri:

implicite, care au puncte de început şi de sfârşit automat definite (de ex., comenzile INSERT, UPDATE, DELETE din SQL);

explicite, adică acelea care prezintă clauze pentru stabilirea punctelor de început şi de sfârşit (BEGIN TRANSACTION, COMMIT/END TRANSACTION, ROLLBACK).

Tranzacţiile nu produc anomalii dacă au loc de o manieră succesivă (execuţie serială). Cum din motive de performanţă execuţia seriala nu este posibilă pe sisteme multiutilizator, se

26 Băduţ, M., O perspectivă asupra bazelor de date, PC Report nr.12/1998

47

apelează la tehnica blocării pentru a asigura o execuţie serializabilă a tranzacţiilor. În cea mai simplă formă, blocarea constă în interzicerea accesului altor procese la datele implicate într-o tranzacţie, până ce aceasta nu se finalizează. Blocarea poate avea loc la nivel de bază de date, fişier, grup de înregistrări, înregistrare sau chiar câmp. Totuşi, blocarea nu este atât de restrictivă, în sensul că:

se permite citirea de către un utilizator a datelor accesate spre citire de alt utilizator (blocare partajabilă);

nu se permite citirea de către alţi utilizatori a datelor accesate în scopul actualizării de alt utilizator (blocare exclusivă).

Blocarea se realizează prin emiterea de către o tranzacţii a unei cereri explicite de blocare.

Accesul concurent şi complexitatea mecanismului de blocare sunt influenţate de granularitatea blocării. Se intuieşte uşor faptul că blocarea întregii baze de date este mai neeconomicoasă decât alte tipuri de blocare, dar blocarea unui singur câmp complică foarte mult mecanismul de blocare. În practică, SGBD execută blocarea la nivel de înregistrare, grup de înregistrări sau fişier.O problemă specială o constituie interblocarea (deadlock), care constă în blocarea de către două tranzacţii a anumitor resurse, apoi fiecare solicită resursele blocate de cealaltă. Există două strategii de rezolvare a interblocării:

prevenirea interblocării: fiecare tranzacţie blochează de la început toate resursele de care are nevoie, astfel că alte tranzacţii nu le vor putea accesa; cum este imposibil de cunoscut dinainte ce resurse sunt necesare, metoda are o slabă aplicabilitate practică;

soluţionarea interblocării: se blochează resursele pe măsura ce tranzacţia le solicită, deci interblocarea poate surveni, dar apoi se folosesc metode pentru detectarea şi eliminarea sa. Pentru aceasta, sistemul poate să ţină evidenţa tranzacţiilor în curs, deci a înregistrărilor accesate. Dacă survine interblocarea, una dintre părţi va fi victima, adică tranzacţia sa va fi abandonată. Toate resursele vor fi deblocate iar utilizatorul va fi anunţat 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 execuţie; cel care nu a realizat încă actualizarea BD etc.Aceste precizări sunt valabile pentru calculatoarele mari, SGBD micro având facilităţi mult mai modeste de control al tranzacţiilor concurente.

Salvarea şi restaurarea bazei de dateAceste operaţii au ca scop readucerea bazei de date în starea consistentă în care se

afla înainte de unele evenimente care au alterat consistenţa datelor, precum: funcţionare anormală a SGBD-ului sau sistemului de operare, defecţiune a suportului fizic pe care este memorată baza de date.

O stare consistentă este una în care sunt reflectate rezultatele finale ale execuţiei unor tranzacţii, nici o tranzacţie nu este în curs de execuţie şi sunt satisfăcute restricţiile semantice necesare.

Există mai multe tehnici de restaurare. Una dintre ele constă în terminarea tranzacţiilor active la momentul defecţiunii. Informaţiile necesare restaurării pot îmbrăca forma unor copii de siguranţă, jurnale ale tranzacţiilor (succesiunea cronologică a prelucrărilor), puncte de control (checkpoints) şi jurnale ale imaginilor (rezultatele prelucrărilor succesive). Restaurarea se poate face automat sau manual.Securitatea bazei de date

Interzicerea accesului neautorizat la date îmbracă forma unui set de măsuri de protecţie umane, hardware şi software.

Prima şi cea mai simplă măsură este izolarea fizică a sistemului de calcul de persoanele neautorizate (acolo unde este posibil).

Accesul la resursele sistemului poate avea loc prin facilităţi ca parole, profile utilizator sau matrici ale drepturilor de acces (privilegii, reguli de autorizare).

Utilizator Obiect Acţiune Restricţie

48

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), reprezentând 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 cărora este definit.

De asemenea, datele pot fi memorate pe suportul extern în formă criptată, astfel încât citirea lor fără aplicaţia proprietară (de exemplu cu ajutorul comenzilor sistemului de operare) să fie imposibilă. Criptarea presupune folosirea componentelor următoare:

cheie de criptare; algoritm de criptare; cheie de decriptare; algoritm de decriptare.

Mai cunoscute sunt metodele de criptare DES (cheie privată pe 64 de biţi), RSA, PGP (cheie publică şi cheie privată).

2.6. Administrarea datelor şi a bazelor de dateÎn prezent este larg recunoscută importanţa critică a gestiunii datelor în cadrul unei

organizaţii economice. Datele şi informaţiile asociate reprezintă o resursă mult prea valoroasă pentru a nu beneficia de o atenţie sporită în ceea ce priveşte activitatea de administrare a lor.

Administrarea ineficientă a datelor duce la o slabă valorificare a acestora şi se poate caracteriza prin:- definiţii multiple ale aceleiaşi entităţi de date şi/sau reprezentări inconsistente ale unor

aceleaşi elemente de date în baze de date diferite, conducând la imposibilitatea integrării datelor

- lipsa unor elemente cheie ale datelor, fapt ce determină pierderea valorii datelor pentru organizaţie

- nivele scăzute ale calităţii datelor datorate unor surse inadecvate de date sau timpilor prohibitivi de transfer de la un sistem la altul

- lipsa unei familiarizări cu datele existente la dispoziţie, inclusiv lipsa cunoaşterii locaţiilor şi semnificaţiilor datelor în procesele de adoptare a deciziilor strategice sau de planificare.

Având în vedere aceste aspecte negative, majoritatea organizaţiilor au creat două funcţii speciale: pentru administrarea datelor, respectiv pentru administrarea bazei de date.

Administratorul datelor este custodele datelor organizaţiei, fiind direct răspunzător de controlarea utilizării şi de protejarea resurselor de date. De asemenea, administratorul datelor are ca sarcini:- determinarea cerinţelor organizaţiei privind datele, estimarea volumului de date şi a

creşterii probabile a acestuia- dezvoltarea unui model de date general- realizarea proiectării conceptuale şi logice a bazei de date- gestionarea dicţionarului de date- soluţionarea conflictelor cauzate de accesul concurent la o aceeaşi resursă de date

(partajarea unei resurse de date)- adoptarea deciziilor privitoare la memorarea datelor- impunerea şi menţinerea unor definiţii ale datelor şi a unor standarde- îmbunătăţirea performanţelor bazei de date- asigurarea mijloacelor de instruire a utilizatorilor- implicarea într-o gamă largă de activităţi ca planificarea, analiza, proiectarea,

implementarea şi asigurarea securităţii bazei de date- asigurarea unei documentaţii complete care să includă modelul întreprinderii, standardele,

politicile, procedurile, utilizarea dicţionarului de date şi controlul asupra utilizatorilor finali

49

- menţinerea contactului cu utilzatorii pentru a determina noile cerinţe şi a rezolva dificultăţile privind accesul la date sau performanţeleAdministratorul 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 protecţie, precum şi în activităţile de salvare şi restaurare a bazei de date.

Funcţiile generale ale administrării datelor şi bazelor de date sunt următoarele:- stabilirea politicilor, procedurilor şi standardelor organizaţiei în materie de date, ca

măsuri de protecţie a datelor şi a bazei de date- politicile datelor sunt reprezentate de o serie de specificaţii care explicitează

scopurile administrării datelor (de exemlu, "fiecare utilizator trebuie să posede o parolă"

- procedurile asociate datelor sunt exprimări ale unor acţiuni ce trebuie întreprinse pentru efectuarea unor anumite activităţi; de exemplu, procedurile de salvare şi restaurare a datelor ce trebuie cunoscute de către toţi utilizatorii

- standardele asociate datelor sunt convenţii explicite ce trebuie urmate pentru a facilita cunatificarea nivelului de calitate a datelor şi a bazei de date; de exemplu, convenţiile de notaţie pentru obiectele componente ale unei baze de date trebuie standardizate, urmând a fi respectate întocmai de către toţi programatorii de aplicaţii.

- planificarea ce presupune administrarea eficientă a datelor şi a bazei de date implică atât înţelegerea cu exactitate a nevoilor reale ale organizaţiei, cât şi abilitatea de a contribui la dezvoltarea unei arhitecturi informaţionale care să satisfacă nevoile organizaţiei

- 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 organizaţiei. Î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 cărui conţinut este reprezentat de metadatele ce descriu datele şi resursele de procesare a datelor unei organizaţii. În prezent depozitele de date înlocuiesc dicţionarele de date în majoritatea organizaţiilor, constituind instrumente esenţiale de sprijinire a activităţilor 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 organizaţii, aspectul cel mai important fiind cel al asigurării permanente a unei compatibilităţi depline între componentele hardware şi cele software

- gestionarea aspectelor privind securitatea şi confidenţialitatea datelor. Scopul asigurării protecţiei şi securităţii datelor este de a preveni apariţia unor ameninţări intenţionate sau accidentale la adresa integrităţii datelor şi a accesului la date. Asigurarea protecţiei datelor se concretizează în elaborarea şi implementarea unor planuri detaliate de securitate a datelor ce includ:

- politici şi proceduri administrative- protecţii ale datelor la nivel fizic- protecţii ale sistemului de gestiune a bazei de date, ce includ:

- perspective sau subscheme care restricţionează accesul utilizatorilor- reguli de autorizare care identifică utilizatorii şi restricţionează acţiunile pe

care aceştia le pot efectua asupra bazei de date- proceduri definite de utilizatori ce impun restricţii şi limitări adiţionale

asupra utilizării bazei de date- proceduri de criptare ce conduc la criptarea datelor din baza de date într-un

format neinteligibil- scheme de autentificare ce identifică fără ambiguitate persoanele ce

intenţionează să acceseze baza de date

50

- facilităţi suplimentare de salvare, monitorizare şi verificare care conduc la uşurarea activităţii de restaurare.

- asigurarea procedurilor specifice de salvare şi restaurare

51

Capitolul 3. MODELUL RELAŢIONAL AL DATELOR

3.1. Elementele modelului relaţional3.2. Algebra relaţională3.3. Studiul dependenţelor funcţionale 3.4. Normalizarea bazelor de date relaţionale

3.1. Elementele modelului relaţionalModelul relaţional a fost introdus de către E.F. Codd (1970), fiind un model formal

de organizare conceptuală a datelor, destinat reprezentări legăturilor dintre date cu ajutorul teoriei matematice a relaţiilor.

Principalul obiectiv al modelului relaţional a fost acela de a realiza o distincţie clară între aspectele fizice şi logice ale unei baze de date, cu alte cuvinte, de a asigura independenţa fizică a datelor. Spre deosebire de modelele anterioare de organizare a datelor (modelul ierarhic, modelul reţea) care erau orientate spre fişiere şi care necesitau programe specializate pentru accesarea bazei de date înregistrare cu înregistrare, la nivel fizic, modelul relaţional este orientat spre mulţimi de date, reprezentate conceptual cu ajutorul relaţiilor, permiţând introducerea unor limbaje neprocedurale de manipulare a datelor.

Modelul relaţional al datelor este independent de sistemul de calcul implicat în organizarea, stocarea şi regăsirea datelor, “ascunzând” faţă de utilizator structurile, regulile şi operaţiile referitoare la implementarea fizică a bazei de date.

Avantajele modelului relaţional au condus la larga sa acceptare de către comunitatea proiectanţilor şi programatorilor sistemelor de baze de date, fiind riguros din punct de vedere matematic şi oferind un instrument performant de studiu a proprietăţilor şi aspectelor logice ale unei aplicaţii cu baze de date.

Rezultatul modelării relaţionale a datelor este o schemă relaţională a unei baze de date, ce este constituită dintr-un set de scheme ale relaţiilor împreună cu un set de restricţii de integritate asociate. Aşadar, modelul relaţional prezintă următoarele caracteristici:

o relaţie este o structură bidimensională de date, compusă din rânduri şi coloane; denumirea uzuală a unei relaţii este aceea de tabel sau tabelă, termenul de relaţie constituind fundamentul teoriei matematice a seturilor, fără a face referire la legăturile dintre structuri şi date;

o relaţie stochează informaţii despre entităţile aparţinând unei clase de entităţi; fiecare rând al unei tabele poartă denumirea de tuplu şi face referire la o entitate

particulară din cadrul clasei de entităţi; fiecare coloană reprezintă un atribut, având un nume distinct; numele atributului

exprimă, de regulă, semnificaţia valorilor din cadrul coloanei respective, numărul atributelor defineşte gradul relaţiei;

numărul tuplurilor dintr-o relaţie reprezintă cardinalitatea relaţiei; la intersecţia fiecărui rând cu fiecare coloană se găseşte o singură dată (o valoare

atomică); fiecare tabelă posedă o cheie primară ce identifică în mod unic fiecare rând (tuplu); valorile unui atribut (coloane) se încadrează într-o gamă de valori cunoscută sub

denumirea de domeniu al atributului respectiv; un domeniu este o mulţime de valori ce se poate defini fie enumerând elementele componente ale mulţimii (de exemplu, mulţimea culorilor), fie definind o proprietate distinctă a valorilor (de exemplu, toate valorile sunt numere întregi);

în cadrul modelului relaţional există posibilitatea de a lucra şi cu valori necunoscute, nedefinite sau neaplicabile, pentru aceasta introducându-se valoarea specială Null;

ordinea rândurilor şi coloanelor nu prezintă importanţă pentru sistemul de gestiune a bazelor de date;

mulţimea numelor atributelor unei relaţii (coloanelor unei tabele) împreună cu numele relaţiei reprezintă o schemă a unei relaţii.

52

Fig. nr.3.1 Elementele modelului relaţional

Elementele de bază ale organizării datelor sunt prezentate comparativ, formal, uzual sau fizic în Tabelul nr. 3.1.

Tabelul 3.1Formal Uzual Fizicrelaţie tupluatribut

tabel (tabelă)rând (linie)coloană

Fişierînregistrarecâmp

Restricţiile minimale de integritate (a entităţii, a cheii şi a referinţei) sunt definite în raport cu noţiunea de cheie a unei relaţii.

Prin supercheie se desemnează un atribut (sau o combinaţie de atribute) ce identifică în mod unic un tuplu din cadrul unei relaţii. O cheie candidată este o supercheie minimală, cu alte cuvinte, o supercheie ce nu conţine un subset de atribute cu proprietatea de a fi el însuşi supercheie a relaţiei respective.

Cheia primară a unei relaţii este una dintre cheile candidate, selectată de către proiectantul sau administratorul bazei de date, pentru a identifica în mod unic toate valorile celorlalte atribute ce compun un tuplu. Cheia primară nu poate conţine valori Null. Atunci când 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 restricţii: unicitatea – o cheie identifică un singur tuplu (linie) al relaţiei; compoziţia minimală – atunci când cheia primară este compusă, nici un atribut din

cheie nu poate fi eliminat fără distrugerea unicităţii tuplului în cadrul relaţiei (în cazuri limită o cheie poate fi alcătuită din toate atributele relaţiei);

valorile non-nule – valorile atributului sau ale ansamblului de atribute ce desemnează cheia primară sunt întotdeauna specificate, deci ne-nule; nici un atribut din compoziţia cheii primare nu poate avea valori nule.

Legătura între tuplurile din relaţii diferite se realizează prin atribute sau combinaţii de atribute, numite chei străine (externe). Cheia străină a unei relaţii este un atribut /combinaţie de atribute, ale cărui valori sunt fie Null, fie se regăsesc în mulţimea valorilor cheii primare ale altei relaţii.

Fie, de exemplu, relaţiile R1 (A, B, C, ...) şi R2 (M, N, O, ..., A) în care atributele A, respectiv M, sunt cheile primare. Atributul A este cheia străină a relaţiei R2.

211202211237192213192211

311291321312357345314291

bucbucbucbucbucbucbucbuc

Cod-Furnizor Cod-ob-inv Den-ob-inv. UM PU Cantitate

EtajereScauneCuiereDulapuriSalopeteManusiOchelariBirouri

359547450

50 1

2520

10

150

1210

54

141210

3

Obiecte-inventar

nume relatie

atribut

schemarelatiei

tuplu

n-tupluri

valoareadin domeniu

domeniu

53

Regulile de integritate ale modelului relaţional sunt următoarele:Regula 1: unicitatea cheii primare- cheia primară trebuie să fie minimală şi să aibă

valori uniceRegula 2: integritatea entităţii - atributul/atributele ce compun cheia primară trebuie să aibă valori diferite de NullRegula 3: integritatea referenţială- valorile atributului /atributelor cheii străine

trebuie să fie sau Null sau să fie prezente în cadrul valorilor cheii primare asociate.Descrierea unei baze de date relaţionale presupune să se aibă în vedere două aspecte

ale acesteia: structura (sau schema) şi conţinutul (sau instanţierea).Conţinutul unei relaţii este ansamblul tuplurilor ce o alcătuiesc la un moment dat. Se

modifică în timp.Schema poate fi definită ca un ansamblu de relaţii asociate semantic prin domeniul

lor de definiţie şi prin restricţii de integritate. Este independentă de timp şi este componenta permanentă a unei relaţii.

După C.J. Date, schema baza de date cuprinde: numele relaţiilor şi ale atributelor fiecărei relaţii; restricţiile de integritate, care sunt de trei feluri:

- restricţiile cheilor primare;- restricţii referenţiale care decurg din existenţa cheilor străine;- alte restricţii (cum sunt cele de comportament27).

Schema simplificată a unei baze de date relaţionale cuprinde numele tabelelor şi enumerarea atributelor acestora, atributele-cheie fiind subliniate.

EX: Baza de date DESFACERE, alcătuită din tabelele CLIENŢI şi FACTURI-EMISE

CLIENŢI(Cod_client, Nume_client, Localitate, Cod_fiscal)FACTURI-EMISE(Număr_factură, Data_factură, Valoare, Cod_client)Prezentarea grafică a unei baze de date respectă următoarele 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 alcătuiesc cheia primară se subliniază;  o restricţie referenţială este reprezentată printr-o săgeată care pleacă de la

numele coloanei de referinţă şi are vârful la atributul corespunzător din tabela cu care intră în legătură.

CLIENŢICod_client Nume_client Localitate Cod_fiscal

FACTURI_EMISENumăr_factură Data_factură Valoare Cod_client

Practic, ansamblul informaţiilor existente în baza de date la un moment dat reprezintă conţinutul sau instanţierea sau realizarea acesteia. Organizarea bazei de date se reflectă în schema sau structura sa, aceasta fiind un ansamblu de instrumente pentru descrierea datelor, a relaţiilor dintre acestea, a semanticii lor şi a restricţiilor la care sunt supuse. În timp se pot modifica atât structura, cât şi conţinutul bazei de date, dar de regulă, structura bazei de date este relativ constantă pe tot parcursul utilizării 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 relaţional, apreciindu-se, de fapt, măsura în care sistemul este relaţional (numărul regulilor pe care le respectă).27 Restricţiile 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 actualizării să fie altele decât cele anterioare actualizării.

54

R0 Regula fundamentală Un sistem de gestiune a bazelor de date relaţionale trebuie să fie capabil să gestioneze o bază de date cu ajutorul facilităţilor sale relaţionale.

R1 Regula reprezentării informaţiei

La nivelul logic, toate informaţiile dintr-o bază de date relaţională sunt reprezentate explicit ca valori în tabele

R2 Regula accesului garantat la date

Orice valoare a oricărui atribut din cadrul oricărei relaţii trebuie să poată fi regăsită prin specificarea numelui relaţiei, a numelui atributului şi a valorii cheii primare.

R3 Regula reprezentării informaţiei necunoscute

SGBD-ul asigură un suport sistematic pentru tratamentul valorilor nule (date necunoscute sau neaplicabile), diferit de valorile prestabilite şi independent de orice domeniu

R4 Regula catalogului dinamic on-line

Descrierea bazei de date şi a componentelor sale este realizată la nivel logic sub formă de tabele, putând fi interogată în timp real prin intermediul limbajului de manipulare a bazei de date.

R5 Regula limbajului de interogare

Este obligatorie existenţa unui limbaj de manipulare a datelor cu ajutorul căruia să se poată crea relaţii şi vederi (perspective asupra bazei de date), să se poată actualiza şi regăsi date etc.

R6 Regula actualizării vederilor

Este obligatorie existenţa unui mecanism de determinare a posibilităţii de actualizare sau nu a unei tabele virtuale (vederi).

R7 Regula limbajului de nivel înalt

Limbajul de manipulare a datelor nu trebuie să conducă utilizatorul la explorarea relaţiilor tuplu cu tuplu, pentru a regăsi datele dorite.

R8 Regula independenţei fizice a datelor

Este necesar ca aspectele fizice ale stocării sau accesului la date să fie separate de aspectele logice (de organizare) ale datelor.

R9 Regula independenţei logice a datelor

Este necesar ca modificările asupra datelor să nu afecteze în nici un mod funcţionarea programelor de aplicaţie şi nici operaţiile de manipulare a datelor.

R10 Regula independenţei datelor din punctul de vedere al integrităţii

Regulile de integritate a datelor trebuie să fie definite în catalogul de sistem, independent de programele de aplicaţie.

R11 Regula independenţei datelor din punctul de vedere al distribuirii

Distribuirea datelor pe mai multe calculatoare din cadrul unei reţele nu trebuie să afecteze programele de aplicaţie.

R12 Regula de nonsubversiune Atunci când SGBD posedă un limbaj de nivel inferior (cod-maşină sau de asamblare), acesta nu poate încălca regulile de integritate definite prin limbajul relaţional al bazei de date

În literatura de specialitate se obişnuieşte ca, în funcţie de tipul cerinţelor 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 independenţa datelor R8, R9, R11.

Avantajele modelului relaţional în comparaţie cu celelalte tipuri de modele sunt: independenţa sporită a programelor de aplicaţii faţă de modul de reprezentare

internă a datelor şi metodele de acces la date;

55

definirea unei structuri conceptuale, optime minimizând redundanţa datelor şi anomaliile la actualizare (prin tehnica de normalizare);

utilizarea unor limbaje procedurale, bazate pe algebra relaţională, şi a unor limbaje neprocedurale care contribuie la îmbunătăţirea comunicării dintre sistem şi utilizatorii neinformaticieni;

integritatea şi confidenţialitatea datelor, prin folosirea unor mecanisme proprii; utilizarea paralelismului în prelucrarea datelor, deoarece manipularea datelor se

realizează numai la nivel de relaţie.

3.2. Algebra relaţionalăE.F.Codd fundamentează modelul relaţional pe baza teoriei matematice a relaţiilor şi

a calculului relaţional. Teoria matematică a relaţiilor este cunoscută sub numele de algebră relaţională. Aceasta poate fi considerată ca fiind o colecţie de operaţii pe relaţii definite într-o manieră formală, producând ca rezultat alte relaţii.

Algebra relaţională lucrează cu două tipuri de operatori: ansamblişti (reuniune, intersecţie, diferenţă şi produs cartezian); relaţionali (selecţie, proiecţie, joncţiune şi diviziune).

Operatori ansambliştiRelaţiile utilizate sunt R1 şi R2. R1(A1, A2, ... An) şi R2 (B1, B2, ... Bm).

Prima relaţie are n atribute, a doua are m atribute.Reuniunea, intersecţia şi diferenţa se pot aplica numai relaţiilor unicompatibile.

Relaţiile R1 şi R2 sunt unicompatibile dacă: n = m (au acelaşi număr de atribute); cele n atribute ale fiecărei relaţii sunt de acelaşi tip sintactic.

ReuniuneaReuniunea este operaţia între două relaţii R1 şi R2 având aceeaşi schemă deci, care

sunt unicompatibile. Rezultatul va fi relaţia R3 care conţine ansamblul tuplurilor constituit prin reuniunea tuplurilor din relaţiile R1 şi R2, duplicatele fiind eliminate.

Matematic, reuniunea se poate scrie R3 R1 R2Exemplu: Considerăm tebelele CLIENŢI1 şi CLIENŢI2.Tabela CLIENŢI1

Nume_client Localitate Cod_fiscalAlfa SRL Iaşi R19548710Anca SRL Iaşi R19852553Omega SA Roman R17466540Star SRL Bacău R12586330

Amigo Srl Bacău R17256007Select SRL Leţcani R17885330

Tabela CLIENŢI2Nume_client Localitate Cod_fiscal

Alfa SRL Iaşi R19548710Gama SA Iaşi R19852201Delta SRL Bacău R17256007Omega SA Roman R17466540

Presupunem că două firme fuzionează. Ambele folosesc acelaşi SGBD, iar structurile tabelelor au fost transformate, devenind identice. Care vor fi clienţii firmei rezultate după fuzionare? Prin reuniunea tabelelor CLIENŢI1 şi CLIENŢI2 se obţine tabela CLIENŢI_NOI:

Tabela CLIENŢI_NOINume_client Localitate Cod_fiscal

Alfa SRL Iaşi R19548710

56

Anca SRL Iaşi R19852553Omega SA Roman R17466540Star SRL Bacău R12586330

Amigo SRL Bacău R17256007Select SRL Leţcani R17885330Gama SA Iaşi R19852201Delta SRL Bacău R17256007

Deci, CLIENŢI_NOI CLIENŢI1 CLIENŢI2Din tabela CLIENŢI2 s-au preluat două tupluri, deoarece celelalte există deja în

tabela CLIENŢI1. Se elimină, deci, dublurile.

IntersecţiaIntersecţia reprezintă operaţia între două relaţii R1 şi R2 unicompatibile, rezultatul

fiind o relaţie R3 cu aceeaşi schemă şi care conţine tuplurile comune relaţiilor R1 şi R2.Se scrie R3 R1 R2Exemplu: Pornind de la aceleaşi tabele trebuie să răspundem la întrebarea: Care sunt

clienţii comuni celor două firme? Răspunsul îl constituie tabela CLIENŢI_COMUNI care va arăta astfel:

Tabela CLIENŢI_COMUNINume_client Localitate Cod_fiscal

Alfa SRL Iaşi R19548710Omega SA Roman R17466540

Deci, CLIENŢI_COMUNI CLIENŢI1 CLIENŢI2.O tabelă rezultată prin intersecţia a două tabele va conţine numai acele tupluri care

prezintă valori identice pentru toate atributele.

DiferenţaDiferenţa este operaţia între două relaţii R1 şi R2 unicompatibile (care au aceeaşi

schemă), obţinându-se relaţia R3 cu aceeaşi schemă şi care conţine ansamblul realizărilor constituit din tuplurile relaţiei R1 care diferă de cele existente în relaţia R2.

Se scrie R3 R1 – R2Exemplu: Care sunt clienţii pe care îi are numai prima firmă? Răspunsul va fi tabela

NUMAI_CLIENŢI1, obţinută prin diferenţa între cele două tabele, astfel:

Tabela NUMAI_CLIENŢI1Nume_client Localitate Cod_fiscalAnca SRL Iaşi R19852553Star SRL Bacău R12586330

Amigo SRL Bacău R17256007Select SRL Leţcani R17885330

NUMAI_CLIENŢI1 CLIENŢI1 – CLIENŢI2Diferenţa presupune deci eliminarea tuplurilor comune celor două relaţii, tabela

rezultat reţinând doar tuplurile primei relaţii, care nu sunt şi în relaţia a doua.

Produsul cartezianProdusul cartezian este operaţia între două relaţii R1 şi R2 ce are ca rezultat o relaţie

R3 a cărei schemă se obţine prin juxtapunerea schemelor relaţiilor R1 şi R2. Relaţia R3 cuprinde toate combinaţiile n-uplurilor din relaţiile R1 şi R2.

Se notează R3 R1 x R2Exemplu: Considerăm tabela CLIENŢI2 de mai sus şi tabela FACTURI.

Tabela FACTURINr_factură Data Nume_client Val_factură12540 12/02/07 Delta SRL 2300.08

57

15780 15/02/07 Gama SA 256447100 17/02/07 Delta SRL 8790

Produsul cartezian al celor două tabele va avea ca rezultat tabela Facturi_Clienţi, care va arăta astfel:

FACTURI_CLIENŢI CLIENŢI2 x FACTURI

Tabela FACTURI_CLIENŢIClienţi2.Nume_client

Clienţi2Localitate

Clienţi2.Cod_fiscal

Facturi.Nr_factură

Facturi.Data

Facturi.Nume_client

Facturi.Val_factură

Alfa SRL Iaşi R19548710 12540 12/02/07 Delta SRL 2300.08Alfa SRL Iaşi R19548710 15780 15/02/07 Gama SA 2564Alfa SRL Iaşi R19548710 47100 17/02/07 Delta SRL 8790Gama SA Iaşi R19852201 12540 12/02/07 Delta SRL 2300.08Gama SA Iaşi R19852201 15780 15/02/07 Gama SA 2564Gama SA Iaşi R19852201 47100 17/02/07 Delta SA 8790Delta SRL Bacău R17256007 12540 12/02/07 Delta SRL 2300.08Delta SRL Bacău R17256007 15780 15/02/07 Gama SA 2564Delta SRL Bacău R17256007 47100 17/02/07 Delta SRL 8790Omega SA Roman R17466540 12540 12/02/07 Delta SRL 2300.08Omega SA Roman R17466540 15780 15/02/07 Gama SA 2564Omega SA Roman R17466540 47100 17/02/07 Delta SRL 8790

După cum se observă, prima linie a tabelei rezultat este combinaţia (concatenarea) între prima linie a tabelei CLIENŢI2 şi prima linie a tabelei FACTURI, a doua este combinaţia între prima linie din CLIENŢI2 cu a doua din FACTURI ş.a.m.d.

Cum tabela Clienţi2 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 utilităţii acestei operaţii. Practic, produsul cartezian nu este utilizat niciodată direct, există însă operatori algebrici care derivă sau se bazează pe acesta.

Operatori relaţionaliOperatorii relaţionali se împart în:

operatori unari de restricţie (selecţia şi proiecţia); operatori binari de extensie (joncţiunea şi diviziunea).

SelecţiaSelecţia (restricţia) este operaţia pe o relaţie R1 care produce o nouă relaţie R2 cu

aceeaşi schemă şi în care tuplurile verifică o condiţie exprimată explicit. Practic prin selecţie se elimină/suprimă realizările (liniile) care nu satisfac condiţia impusă. Prin urmare cardinalitatea noii relaţii R2 va fi mai mică sau cel mult egală cu cardinalitatea relaţiei R1.

Se notează R2 Selecţie (R1, expresie - logică)R2 este tabela rezultat care va ave aceeaşi schemă ca şi R1.Exemplu: Considerăm tabelele CLIENŢI1 şi FACTURI.1. Care sunt clienţii cu sediul în Iaşi? Răspunsul se obţine prin aplicarea

operatorului SELECŢIE asupra relaţiei CLIENŢI. Tabela rezultat va conţine doar tuplurile care prezintă valoarea atributului Localitate egală cu şirul de caractere „Iaşi”

Se scrie R2 SELECŢIE(CLIENŢI, Localitate = „Iaşi”)Tabela R2 va arăta astfel:

Nume_client Localitate Cod_fiscalAlfa SRL Iaşi R19548710Anca SRL Iaşi R19852553

58

2. Care sunt facturile cu valoare mai mare de 50000000 lei? Răspunsul se obţine prin aplicarea operatorului SELECŢIE asupra relaţiei FACTURI. Tabela rezultat va conţine doar tuplurile care au valoarea atributului Val_factură este mai mare de 50000000.

Se scrie R2 SELECŢIE (FACTURI, Val_factură 50000000)Tabela R2 va arăta astfel:Nr_factură Data Nume_client Val_factură47100 17/02/06 Delta SRL 87900000

ProiecţiaProiecţia (decupajul vertical) reprezintă o operaţie pe o singură relaţie R1 şi are ca

rezultat o relaţie R2 redusă la atributele menţionate explicit în operanzi. Tuplurile din relaţia R2 sunt unice.

Prin proiecţie se trece la o relaţie de grad inferior relaţiei R1. Se notează R2 Proiecţie (R1; Atribut1, Atribut2, ..., Atributn) sau R2 R1

(Atribut1, Atribut2,...)R2 este tabela rezultat, a cărei schemă va fi diferită de a tabelei R1, fiind formată

doar din atributele specificate. Dacă nu există tupluri identice, ea va avea acelaşi număr de linii ca şi tabela R1.

Exemplu:1) Care sunt localităţile în care firma are clienţi?

RR1 PROIECŢIE (CLIENŢI, Localitate)2) Care sunt numele clienţilor firmei?

RR2 CLIENŢI (Nume_client)RR1

LocalitateIaşi

RomanBacăuLeţcani

În tabela RR1 au fost eliminate valorile identice ale atributului Localitate.RR2

Nume_clientAlfa SRLAnca SRL

Omega SRLStar SRL

Amigo SRLSelect SRL

În tabela RR2 numărul de linii este identic cu cel al tabelei CLIENŢI.

JoncţiuneaJoncţiunea (Join sau Theta-joncţiune) reprezintă o operaţie între două relaţii R1 şi R2

care are ca rezultat o relaţie R3 cu o schemă obţinută prin concatenarea schemelor primelor două. Conţinutul relaţiei îl reprezintă ansamblul tuplurilor obţinute prin concatenarea tuplurilor din R1 şi R2 care verifică o condiţie stabilită între atributele celor două relaţii. Condiţia se construieşte cu ajutorul operatorilor: . . . . .

Considerăm relaţiile R1 (A1, A2, ... , An) şi R2 B1, B2, ..., Bm). Ai şi Bj sunt două atribute definite pe acelaşi domeniu şi mulţimea operatorilor pentru comparaţii ce pot fi aplicaţi celor două atribute. Joncţiunea relaţiei R1, prin Ai cu relaţia R2, prin Bj, notată:

R1 (Ai Bj) R2este relaţia R3 ale cărei tupluri sunt obţinute prin concatenarea fiecărui tuplu al relaţiei R1 cu tuplurile relaţiei R2 pentru care este adevărată condiţia instituită între Ai şi Bj.

Joncţiunea este echivalenta unui produs cartezian urmat de o selecţie.

59

În lucrul cu bazele de date relaţionale se utilizează cu precădere echijoncţiunea, care este un caz particular al theta-joncţiunii, în care se utilizează operatorul de egalitate. Echi-joncţiunea se reprezintă astfel: R3 ECHIJONCŢIUNE (R1, R2, Ai = Bj)Exemplu: Considerăm tabelele CLIENŢI şi FACTURI. Proprietatea comună a celor două relaţii este Cod_client, care este cheie primară în tabela CLIENŢI şi cheie străină în tabela FACTURI.

Tabela CLIENŢICod_client Nume_client Localitate

1000 Alfa SRL Iaşi1001 Gama SA Iaşi1002 Delta SRL Bacău1003 Omega SA Roman

Tabela FACTURINr_factură Data_factură Cod_client Valoare_factură

12540 12/02/07 1001 2300.0815780 15/02/07 1001 256421630 10/02/07 1002 125647100 17/02/07 1000 8790

Echijoncţiunea este reprezentată astfel:R3 ECHI-JONCŢIUNE (CLIENŢI, FACTURI; CLIENŢI.Cod_client =

FACTURI. Cod_client)La execuţia joncţiunii, în prima etapă se

calculează produsul cartezian al tabelelor CLIENŢI şi FACTURI, iar în pasul al doilea se operează selecţia, care elimină tuplurile care nu îndeplinesc condiţia de selecţie (sunt reţinuţi doar clienţii care au emis facturi). Rezultatul joncţiunii este prezentat în tabela de mai jos.Clienţi.Cod_client

ClienţiNume_client

Clienţi.Localitate

Facturi.Nr_factură

Facturi.Data_factură

Facturi.Cod_client

Facturi.Valoare_factură

1000 Alfa SRL Iaşi 47100 17/02/07 1000 87901001 Gama SA Iaşi 12540 12/02/07 1001 2300.081001 Gama Sa Iaşi 15780 15/02/07 1001 25641002 Delta SRL Bacău 21 630 10/02/07 1002 1256

Adesea numele atributului comun este identic în ambele tabele astfel că se impune specificarea numelui tabelei (nume tabelă nume atribut). Această joncţiune, în care numele atributelor sunt identice în ambele tabele se numeşte joncţiune naturală. Este cea mai utilizată şi o vom nota astfel:R3 JONCŢIUNE (CLIENŢI, FACTURI, Cod_client)

DiviziuneaEste cel mai complex dintre operatorii algebrei relaţionale. În definire se porneşte de

la două relaţii: 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 acelaşi domeniu ca şi în R1.

Diviziunea relaţională R1 R2 are ca rezultat o relaţie 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ă Y R2 (xi, yi) R1

60

Se notează R3 R1 R2Tabela R1 se numeşte deîmpărţit,iar tabela R2 se numeşte divizor.Pentru exemplificare vom considera X şi Y atribute şi nu grupe de atribute.

R1X YX1 y1X3 y1X5 y1X1 y2X2 y2X3 y2X4 y2X1 y3X5 y3X3 y3X2 y3X4 y3

R2YY1Y2Y3

Determinarea relaţiei 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 rând 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:

R3XX1X3

Diviziunea nu este un operator fundamental, funcţionalitatea sa este obţinută prin combinarea operatorilor produs cartezian, diferenţă şi proiecţie.

3.3. Studiul dependenţelor funcţionale

Dependenţele dintre atributeNormalizarea se bazează pe conceptul de dependenţă dintre atributele bazei de date.

Există trei tipuri de dependenţe: funcţională, multivaloare şi de joncţiune.Dependenţa funcţională reprezintă o generalizare a conceptului de cheie primară.

Considerăm două atribute sau grupe de atribute ale unei relaţii: Data1 şi Data2. Se spune că Data2 este în dependenţă funcţională cu Data1 atunci când cunoaşterea unei valori pentru Data1 permite cunoaşterea a maximum o valoare pentru Data2. Data1 se numeşte sursa dependenţei funcţionale, iar Data2 este destinaţia dependenţei funcţionale. Se notează Data1 Data2.

Formal, considerăm relaţia R{A1, A2, ..., An} şi două grupe de atribute X şi Y. Se spune că există o dependenţă funcţională între X şi Y, dacă:

61

fiecare valoare a lui X poate fi asociată unei singure valori a lui Y; două valori identice ale lui X nu pot fi asociate decât aceleiaşi valori a lui Y.

Se notează: X YSe consideră tabela FACTURI.

FACTURINumăr_factură Data_ factură Cod_client Val_factură

În tabela FACTURI, elementul cheie este Număr_factură. Dacă este cunoscut, atunci vom afla şi data facturii, clientul pentru care s-a întocmit şi valoarea ei. Deci,

Număr_factură Data_facturăNumăr_factură Cod_clientNumăr_factură Val_facturăImplicit, în orice relaţie R există dependenţele funcţionale:cheia primară a lui R celelalte atribute ale lui RDependenţele funcţionale care prezintă la sursă două sau mai multe atribute

sunt dependenţe funcţionale cu sursă compusă.

Dependenţe funcţionale elementare (totale) şi parţialeDependenţa funcţională Data1 Data2 este elementară dacă nu există nici un

subansamblu al lui Data1 (Data3) care să verifice dependenţa funcţională Data3 Data2.Implicit, toate dependenţele în care sursa este simplă (formată dintr-un atribut) sunt

dependenţe funcţionale elementare. Considerăm următoarea relaţie (FACT_CL):

Nr_fact Data Cod_cl Nume_cl Strada Localitate Judeţ Cod_post Valoare

În tabela FACT_CL, dependenţă funcţională elementară este:Cod_post Strada

Problema apare la dependenţele funcţionale cu sursa compusă. În tabela FACT_CL avem:(Număr_factură, Cod_cl) Valoarecare este o dependenţă funcţională elementară.Dependenţele:(Număr_factură, Cod_cl) Nume_cl(Număr_factură, Cod_cl) Localitatenu sunt elementare pentru că o parte a sursei este la rândul său sursă pentru alte dependenţe funcţionale: Cod_cl Nume_cl

Cod_cl LocalitateDependenţa funcţională elementară se mai numeşte totală sau deplină.

Dependenţe funcţionale directe şi tranzitiveO dependenţă funcţională Data1 Data2 este directă atunci când nu există Data3

care angajează o dependenţă funcţională tranzitivă de genul Data1 Data3 Data2.În relaţia FACT_CL, avem dependenţa funcţională Cod_post Strada. Codul poştal

este unic pentru fiecare stradă, deci dependenţa de mai sus este funcţională şi directă.Dependenţa Cod_cl Strada este funcţională, dar nu este directă, ci tranzitivă

datorită dependenţei funcţionale de mai sus. Avem: Cod_cl Cod_post Strada.Dependenţele multivaloare şi de joncţiune sunt mai dificil de explicat şi identificat

decât cele funcţionale. Multe lucrări nu le prezintă, considerând că primele trei forme normale şi forma Boyce Codd, care se bazează pe dependenţele funcţionale elementare şi directe sunt suficiente pentru majoritatea cazurilor practice.

Fie relaţia 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 relaţiei R dacă şi numai dacă:

la fiecare valoare a lui X poate fi asociată una sau mai multe valori ale lui Y; această asociaţie nu depinde de valorile lui Z.

62

Considerăm o relaţie R{A1, A2, ..., Ai} şi N subansamble de atribute X1, X2, ..., XN. Se spune că există o dependenţă de joncţiune de ordinul N între X1, X2, ..., XN dacă şi numai dacă R este joncţiunea proiecţiilor sale pe X1, X2, ..., XN. Dacă N=2, avem de-a face cu o dependenţă multivaloare.

3.4. Normalizarea bazelor de date relaţionale

Necesitatea normalizăriiNormalizarea unei relaţii constă în reprezentarea acesteia sub o formă canonică,

respectând anumite criterii de definire semantică a structurii bazei de date, precum şi integritatea datelor28.

Uzual, prin normalizare se desemnează procesul de stabilire a structurii tabelelor unei baze de date relaţionale, a cheilor primare, a cheilor străine şi a altor restricţii. Prin normalizare se ajunge la o optimizare a bazei de date, urmărindu-se:

Eliminarea anomaliilor de actualizare; Diminuarea nevoii de reorganizare periodică a modelului; Reprezentarea diverselor conexiuni dintre atributele bazei; Utilizarea unor algoritmi eficienţi privind căutarea tuplurilor care îndeplinesc anumite

condiţii specificate (interogarea bazei de date).Înscrisă de obicei în activităţile 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, importanţa normalizării nu trebuie absolutizată. Fragmentarea tabelelor în altele mai simple are în vedere şi optimizarea vitezei de acces, reducerea traficului pe reţea etc. În plus, preocupări de dată mai recentă vizează înglobarea, în normalizare, a unor concepte privind gestiunea domeniilor atributelor şi extinderea sa către tehnologia obiectuală.

Prin normalizare, o relaţie este descompusă reversibil, obţinându-se o schemă relaţională optimă. Există două tipuri de algoritmi pentru obţinerea relaţiilor normalizate:

descompunerea - este un procedeu pas cu pas, de trecere dintr-o formă normalizată în alta;

sinteza - operează cu un graf complet de dependenţe funcţionale.Normalizarea are ca scop asigurarea echilibrului între obţinerea unui volum maxim de

informaţii într-un timp cât 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ă (aşa-numita relaţie universală) atrage serioase probleme privind redundanţa datelor şi anomalii la adăugarea, modificarea şi ştergerea unor linii.

Nr_factura Data Nume_client Localitate Cod_fiscal Val_factura10540 10/02/07 Delta SRL Iaşi R19548710 2300.0810541 10/02/07 Gama SA Iaşi R19848451 256410542 11/02/07 Delta SRL Iaşi R19548710 879010543 12/02/07 Alfa SRL Vaslui R19852201 4356.0810544 12/02/07 Diana SRL Paşcani R19674531 356410545 12/02/07 Popa SNC Iaşi R12323432 179010546 12/02/07 Omega SRL Bacău R17256007 1300.0810547 13/02/07 Iulius SRL Iaşi R19456700 356410548 14/02/07 Toni SRL Bacău R18790654 365010549 14/02/07 Anca SRL Roman R17466540 4100.08010550 15/02/07 Select SA Bacău R13666589 386410551 15/02/07 Anca SRL Roman R17466540 3290

28 Filip, M., Grama, A., Medii de programare. Abordări teoretice, Ed. Fides, Iaşi, 1998, p.204

63

Acest lucru se observă din exemplul de mai sus - este aşa-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ă modificăm 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 restricţii de integritate referenţială. Este important modul în care se realizează acest lucru, pentru a nu se pierde informaţii, pe de o parte, iar pe de altă parte dacă va rezulta un număr mare de tabele, acestea vor fi dificil de controlat, în ceea ce priveşte respectarea restricţiilor.

Deci, obiectivul normalizării poate fi formulat astfel: minimizarea redundanţei, eliminarea pierderilor de informaţii şi asigurarea unei viteze optime de acces la date.

Formele normale ale unei baze de date relaţionaleTeoria clasică a normalizării este construită în jurul a cinci forme normalizate. Codd,

părintele modelului relaţional de organizare a datelor, a definit iniţial trei forme normalizate 29, notate cu 1FN, 2FN şi 3FN. Întrucât, într-o primă formulare, definiţia 3FN ridica ceva probleme, Codd şi Boyce au elaborat o nouă variantă, cunoscută sub numele Boyce-Codd Normal Form (BCNF). Deşi este vorba, în principiu, de o formulare mai riguroasă a aceleiaşi 3FN, BCNF este prezentată, în majoritatea lucrărilor, separat. Formele 4 şi 5, care sunt legate de numele lui Fagin, sunt tratate mai cu reţinere în literatura consacrată analizei bazelor de date relaţionale. Ba chiar unele lucrări, cu tentă mai pragmatică, se opresc, declarat, la 3FN pe care o consideră suficientă în rezolvarea majorităţii cazurilor practice.

Fundamentul normalizării bazelor de date relaţionale îl constituie dependenţele dintre atribute. Primele trei forme normalizate pot fi determinate pe baza dependenţelor funcţionale elementare (totale) şi tranzitive. Forma a patra (4FN) se bazează pe dependenţele multiva-loare, în timp ce a cincea formă normalizată (5FN) pe dependenţele de joncţiune. În practică, dependenţa multivaloare, dar mai ales cea de joncţiune sunt rare şi dificil de identificat. Ierarhia dintre formele normale şi legătura cu dependenţele dintre atribute este prezentată în fig. nr. 3.2.30.

1FN2FN

3FNBCNF

4FN

5FN

DM V

DJ

DF

Fig. nr. 3.2. Ierarhia formelor normale

Prima formă normală (1FN)O relaţie se află în 1FN dacă fiecare atribut al său conţine o valoare atomică (sau

atributele sunt nedecompozabile).În relaţia FACT_CL prezentată anterior toate atributele sunt atomice. Deci, relaţia FACT_CL este în 1FN.

A doua formă normală (2FN)Începând din a doua formă normală, relaţiile pot fi decupate în sub-relaţii în scopul

diminuării problemelor legate de stocare şi actualizare.

29Codd, E.F., Further normalization of the database relational model, DataBase Systems, Courant Computer Science Symposia Series, Vol.6, Englewood Cliffs, N.J.,Prentice-Hall, 197230Filip, M., Grama, A., Op. cit., p.205

64

În 1971, Heath a demonstrat că orice relaţie care are cel puţin trei atribute, notată R(X, Y, Z), în care există dependenţele funcţionale XY şi XZ, poate fi descompusă în două relaţii R1(X, Y) şi R2(X, Z). R1 şi R2 reprezintă proiecţiile relaţiei R pe atributele X, Y şi, respectiv, X, Z. Descompunerea se face fără pierderi de informaţii, adică R poate fi recompusă prin joncţiunea tabelelor R1 şi R2.

O relaţie se află în 2FN dacă: se află în 1FN; toate dependenţele funcţionale care leagă cheia primară de celelalte atribute

sunt dependenţe funcţionale elementare.Deci, normalizarea relaţiilor 1FN la forma 2FN presupune eliminarea dependenţelor

parţiale.În exemplul de mai sus, cheia primară a relaţiei FACT_CL este perechea (Nr_fact,

Cod_cl). Există următoarele dependenţe funcţionale:(1) (Nr_fact, Cod_cl) Data(2) (Nr_fact, Cod_cl) Nume_client(3) (Nr_fact, Cod_cl) Localitate(4) (Nr_fact, Cod_cl) Strada(5) (Nr_fact, Cod_cl) Judeţ(6) (Nr_fact, Cod_cl) Cod_post(7) (Nr_fact, Cod_cl) Valoare

Dependenţele funcţionale (2), (3), (4) (5) şi (6) nu sunt elementare datorită existenţei dependenţelor:(8) Cod_cl Nume_client(9) Cod_cl Localitate(10) Cod_cl Strada(11) Cod_cl Judet(12) Cod_cl Cod_post

Aducerea relaţiei în 2FN presupune parcurgerea a trei paşi: identificarea dependenţelor elementare, inclusiv cele tranzitive - cele de la (1) la (7); identificarea dependenţelor care au ca sursă un atribut din cheia primară - (8) la (12); pentru fiecare atribut al cheii (precizat în pasul 2) se creează o relaţie care va avea drept

identificator primar atributul respectiv, iar celelalte atribute vor fi cele care apar ca destinaţii în dependenţele de la pasul 2. În cazul nostru, relaţia FACT_CL se fragmentează în două tabele - FACT şi CL:

FACTNr_fact Data Cod_cl Val

CLCod_cl Nume_client Localitate Strada Judeţ Cod_post

A treia formă normală (3FN)O relaţie se află în 3FN dacă: se găseşte în 2FN; toate atributele care nu aparţin cheii primare nu depind funcţional de un alt atribut care nu

face parte din cheie.

Pentru trecerea în 3FN se parcurg următorii paşi: se identifică toate atributele ne-cheie şi care sunt surse ale unor dependenţe funcţionale; pentru fiecare atribut ne-cheie care este sursă de dependenţe funcţionale se constituie câte

o relaţie în care cheie primară va fi atributul respectiv, iar celelalte atribute vor fi destinaţiile din dependenţele funcţionale.

Relaţia FACT este în 3FN pentru că nu este nici o dependenţă funcţională între un atribut ne-cheie şi celelalte atribute. În relaţia CL, există dependenţele funcţionale:Cod_post Stradă

65

Cod_post LocalitateCod_post Judeţ

Cod_post este un atribut ne-cheie, sursă în dependenţe funcţionale cu Strada, Localitate şi Judeţ. Tabela CL se descompune în tabelele CLIENŢI şi CODP, astfel:

CLIENTICod_cl Nume_client Cod_post

CODPCod_post Strada Localitate Judeţ

În 3FN, relaţia FACT_CL de la care am pornit se prezintă sub forma a trei relaţii: FACT, CLIENTI, CODP

Forma normală Boyce-CoddÎn practică pot apare cazuri în care 3FN să nu fie suficientă.O relaţie este în BCFN dacă: se află în 3FN; nu există nici o dependenţă funcţională a cărei sursă să fie un atribut ne-

cheie, iar destinaţia un atribut din cheie.Într-o altă formulare, o relaţie este în BCFN dacă şi numai dacă orice determinant

este o cheie-candidat (atunci când într-o relaţie există mai multe combinaţii de atribute care identifică tuplul în mod unic, acestea se numesc chei candidate). Un determinant este orice atribut de care depinde funcţional un alt atribut al relaţiei. Un determinant este deci o sursă de dependenţe funcţionale.

A patra formă normală (4FN)O relaţie este în 4FN dacă: este în BCFN; nu există dependenţe multivaloare în cadrul relaţiei.Altfel spus, o relaţie este în 4 FN dacă este în BCFN şi toate dependenţele care se

manifestă în cadrul său sunt funcţionale.

A cincea formă normală (5FN)O relaţie este în 5FN dacă şi numai dacă toate dependenţele de joncţiune sunt între

cheile candidate ale lui R.5FN este o generalizare a lui 4FN, care este o generalizare a lui BCFN.

66

Capitolul 4. LIMBAJE DE INTEROGARE A BAZELOR DE DATE – SQL 4.1. SQL - Evoluţie şi performanţe4.2. Comenzi pentru descrierea datelor;4.3. Comenzi pentru interogarea bazelor de date 4.4. Comenzi pentru actualizarea bazei de date

4.1. Evoluţie şi performanţeSQL reprezintă cel mai important limbaj actual în domeniul bazelor de date prin

gama comenzilor şi opţiunilor de care dispune, dar mai ales datorită faptului că s-a reuşit 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 relaţional 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ă mulţi autori, momentul decisiv în naşterea SQL ca limbaj îl constituie lansarea proiectului System/R de către 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, asemănător 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 relaţional.

Î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 astăzi mulţi specialişti pronunţă SQL ca pe predecesorul său.

Anii următori au înregistrat apariţia a o serie întreagă de lucrări dedicate SQL care l-au perfecţionat şi consacrat ca pe cel mai răspândit limbaj de interogare a bazelor de date relaţionale, fiind prezent în numeroase "dialecte" specifice tuturor SGBDR-urilor actuale, de la DB2 la Microsoft SQL Server, de la Oracle la FoxPro şi Access.

Încercând să răspundă solicitărilor pentru standardizarea unui limbaj de lucru cu bazele de date, Institutul Naţional American pentru Standarde (American National Standard Institute - ANSI) a început să realizeze în 1982 un limbaj relaţional 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 măsură, pe "dialectul" SQL al produsului DB2 de la IBM. Organizaţia Internaţională 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 defineşte comenzile de bază ale SQL, inclusiv pentru crearea de tabele şi tabele virtuale (CREATE TABLE, CREATE VIEW), însă nu conţine opţiuni 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, "născându-se" SQL-89, care mai este denumit şi SQL-1.

Deşi recunoscut ca bază a multor SGBDR-uri comerciale, SQL-1 şi-a atras numeroase critici. În plus, variantele comercializate de diferiţii producători, deşi asemănătoare î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, specificaţiile 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 facilităţi aduse de SQL-92 amintim: joncţiunea externă (OUTER JOIN), atribute zi-oră şi de alte tipuri, raportare

67

standardizată a erorilor, modificarea schemei bazei de date (DROP, ALTER, REVOKE, GRANT), SQL dinamic, modificări şi ştergeri referenţiale în cascadă, amânarea verificării restricţiilor, niveluri de consistenţă a tranzacţiilor etc.

Pe lângă ANSI, ale cărui 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 aplicaţii portabile, grefat pe sistemul de operare UNIX.

IBM a avut un aport incontestabil la apariţia şi maturizarea SQL, fiind un producător cu mare influenţă în lumea SGBD-urilor, iar produsul său, DB2, este unul din standardele de facto ale SQL.

În 1989 un grup de producători de instrumente dedicate bazelor de date au format SQL Access Group, în vederea realizării conexiunilor dintre SGBDR-urile fiecăruia, pe baza unor specificaţii comune, din care un prim set a fost publicat în 1991 sub titulatura RDA (Remote Database Access). Specificaţiile RDA n-au reuşit să se impună pe piaţa SGBD-urilor.

La insistenţele firmei Microsoft, SQL Access Group şi-a concentrat eforturile pentru elaborarea unei interfeţe-standard pentru SQL. Pe baza unui set de propuneri înaintat de Microsoft, în 1992 au rezultat specificaţiile CLI (Call Level Interface). Acestea reprezintă un ansamblu de funcţii şi proceduri pentru conectarea bazelor de date prin SQL în medii multi-utilizator şi multi-platformă. Având drept reper CLI, Microsoft elaborează şi implementează în acelaşi an un set propriu, ODBC (Open DataBase Conectivity), care a devenit standard în materie de interfaţă SQL pentru microcalculatoare compatibile IBM PC în vederea accesării bazelor de date relaţionale.

Standardul SQL:1999, denumit iniţial SQL3, are ca principale orientări: transformarea acestuia într-un limbaj complet, în vederea definirii şi gestionării obiectelor complexe şi persistente. Aceasta include: generalizare şi specializare, moşteniri multiple, polimorfism, încapsulare, tipuri de date definite de utilizator, triggere şi proceduri stocate, suport pentru sisteme bazate pe gestiunea cunoştinţelor, expresii privind interogări recursive şi instrumente adecvate de administrare a datelor.

Standardul SQL:2003 are drept caracteristici majore: caracteristici legate de XML, funcţii window, secvenţe standardizate şi coloane cu valori auto-generate (incluzând coloane-identitate).

Standardul SQL:2006 defineşte căi prin care SQL poate fi utilizat împreună cu XML, căi de a importa şi stoca date XML într-o bază de date SQL, de a le manipula în cadrul acelei baze de date şi de a le publica.

Din punctul de vedere al utilizatorului final, obiectivul principal al SQL constă în a oferi utilizatorului mijloacele necesare formulării unei consultări numai prin descrierea rezultatului dorit, cu ajutorul unei expresii logice, fără a fi necesară şi explicitarea modului efectiv în care se face căutarea în baza de date. Altfel spus, utilizatorul specifică rezultatul, iar sistemul se ocupă de procedura de căutare.

Deşi este considerat, în primul rând, un limbaj de interogare, SQL este mult mai mult decât un instrument de consultare a bazelor de date, deoarece permite, în egală măsură:

definirea datelor; consultarea bazei de date; manipularea datelor din bază; controlul accesului; partajarea bazei între mai mulţi utilizatori ai acesteia; menţinerea integrităţii bazei de date.

După Groff şi Weinberg, principalele atuuri ale SQL sunt: Independenţa de producător, nefiind o tehnologie proprietară; Portabilitate între diferite sisteme de operare; Este standardizat; "Filosofia" sa se bazează pe modelul relaţional de organizare a datelor; Este un limbaj de nivel înalt, cu o structură care se apropie de limba engleză; Furnizează răspunsuri la numeroase interogări simple, ad-hoc, neprevăzute iniţial;

68

Constituie suportul programatic pentru accesul la baza de date; Permite multiple imagini asupra datelor bazei; Este un limbaj relaţional complet; Permite definirea dinamică a datelor, în sensul modificării structurii bazei chiar în

timp ce o parte din utilizatori sunt conectaţi la baza de date; Constituie un excelent suport pentru implementarea arhitecturilor client-server.

Limbajul SQL constituie un exemplu de limbaj orientat spre tansformări sau limbaj proiectat să utilizeze relaţiile pentru a transforma intrările în ieşirile 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 regăsirea şi reactualizarea datelor.Limbajul SQL conţine numai comenzi de definire şi manipulare şi nu conţine comenzi de

flux de control. Cu alte cuvinte nu există comenzi IF…THEN…ELSE, GO TO, DO…WHILE sau alte comenzi care să ofere un flux de control. Acestea trebuie implementate prin utilizarea unui limbaj de programare sau de control al lucrărilor 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 instrucţiunilor de la un terminal. A doua este de a integra instrucţiunile SQL într-un limbaj procedural. SQL este un limbaj relativ uşor de învăţat: Este un limbaj neprocedural - se specifică ce informaţii sunt cerute şi nu cum sunt

obţinute (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. Totuşi o comandă (sau un set de comenzi SQL) este mai lizibilă dacă se foloseşte indentarea şi alinierea. De exemplu:- fiecare clauză din cadrul unei comenzi trebuie să înceapă pe o linie nouă;- începutul fiecărei clauze trebuie să fie aliniat cu începutul celorlalte;- dacă o clauză are mai multe părţi, fiecare dintre ele trebuie să apară pe câte o linie

separată şi trebuie să fie indentată faţă de începutul clauzei pentru a indica relaţia. 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 aplicaţii şi alte tipuri de utilizatori.SQL este primul şi deocamdată singurul limbaj de baze de date standardizat care se

bucură de o acceptare largă.Cele mai multe "dialecte" SQL admit următoarele tipuri de date:

SMALLINT: întregi - scurte (4 poziţii, reprezentate pe 16 biţi), INTEGER sau INT: întregi - lungi (9 poziţii, 32 biţi), NUMERIC(m,n) sau DECIMAL(m,n) sau DEC(m,n) - reale, cu un total de m

poziţii, din care n la partea fracţionară, FLOAT: reale, virgulă mobilă (20 poziţii pentru mantisă), REAL : real, virgulă mobilă DOUBLE PRECISION: reale, virgulă mobilă, dublă precizie (30 poziţii 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 fracţiune zecimală dintr-o

secundă.Principalele comenzi ale SQL, care se regăsesc, într-o formă sau alta, în multe dintre

SGBDR-urile actuale sunt următoarele:

69

Tabelul nr. 4.1. Clase de comenzi SQLComandă ScopPentru manipularea datelorSELECT Extragerea datelor din baza de dateINSERT Adăugarea de noi linii într-o tabelăDELETE Ştegerea de linii dintr-o tabelăUPDATE Modificarea valorilor unor atributePentru definirea bazei de dateCREATE TABLE Adăugarea unei noi tabele în baza de dateDROP TABLE Ştergerea unei tabele din bazăALTER TABLE Modificarea structurii unei tabeleCREATE VIEW Crearea unei tabele virtualeDROP VIEW Ştergerea unei tabele virtuale

Pentru controlul accesului la BDGRANT Acordarea unor drepturi pentru utilizatoriREVOKE Revocarea unor drepturi pentru utilizatoriPentru controlul tranzacţiilorCOMMIT Marchează sfârşitul unei tranzacţiiROLLBACK Abandonează tranzacţia în curs

4.2. Comenzi pentru descrierea datelorComanda SQL utilizată pentru crearea unei tabele este CREATE TABLE. Aceasta

creează o tabelă vidă (fără linii), cu o anumită structură.

CLIENŢICodClient NumeClient Adresa Localitate1001 TEXTILA SA Bld. Copou, 87 Iaşi1002 MODERN SRL Bld. Gării, 22 Focşani1003 OCCO SRL NULL Iaşi1004 FILATURA SA Bld. Unirii, 145 Focşani1005 INTEGRATA SA I.V.Viteazu, 115 Paşcani1006 AMI SRL Galaţiului, 72 Bacău1007 AXON SRL Silvestru, 2 Iaşi1008 ALFA SRL Prosperităţii, 15 Paşcani

FACTURIEMISENrFactură CodClient DataFactură ValoareTotală TVAColectată111111 1003 17.06. 2007 1700 271.42111112 1001 17.06.2007 285 45.5111113 1004 18.06.2007 585 93.4111114 1003 18.06.2007 2850 455.04111115 1008 18.06.2007 3570 570111116 1008 19.06.2007 870 138.9111117 1006 20.06.2007 1100 175.63111118 1007 23.06.2007 1500 239.49111119 1005 24.06.2007 4725 754.41111120 1003 24.06.2007 300 47.89111121 1001 24.06.2007 425 67.85

70

111122 1007 24.06.2007 875 139.7111123 1006 25.06.2007 660 105.3111124 1004 25.06.2007 3850 614.7111125 1003 30.06.2007 1280 204.37111126 1002 01.07.2007 5425 866.17

Fig. nr. 4.1. Baza de date utilizată în exemple

De exemplu, pentru crearea tabelei CLIENŢI, comanda se scrie astfel:CREATE TABLE CLIENŢI

(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 poziţii. Celelalte atribute conţin şiruri de caractere. Valorile pentru CodClient şi NumeClient sunt diferite de NULL. Cheia primară a relaţiei este atributul CodClient.

Există posibilitatea adăugării ulterioare a unui nou atribut la cele existente, ştergerii unui atribut sau de modificare a tipului sau lungimii sale. Operaţiunea nu este atât de frecventă, fiind recomandabil să se desfăşoare cât mai rar; o bună analiză desfăşurată în faza de proiectare a bazei de date elimină, de obicei, acest gen de probleme.

Dacă în tabela CLIENŢI se doreşte păstrarea şi a codului fiscal al fiecărui furnizor, este necesară adăugarea atributului CodFiscal, care este un şir de caractere (un număr precedat de litera R, dacă clientul respectiv este plătitor de TVA) de lungime 10 caractere. Comanda utilizată este ALTER TABLE, astfel:

ALTER TABLE CLIENŢIADD CodFiscal char(10)SQL permite declararea cheilor primare, candidate şi a coloanelor de referinţă (chei

străine). Dacă stabilim că, pentru tabela CLIENŢI, cheia primară este atributul CodClient, iar atributul NumeClient este cheie candidată, comanda se poate scrie sub forma:

CREATE TABLE CLIENŢI(CodClient decimal (7) not NULL, NumeClient char(25) not NULL, Adresa char(30), Localitate char(25) , PRIMARY KEY (CodClient) UNIQUE (NumeClient))Cheile străine sunt declarate cu ajutorul opţiunii FOREIGN KEY. Pentru tabela

FACTURIEMISE, cheia primară este atributul NrFactură, în timp ce CodClient este cheie străină către tabela CLIENŢI:

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 CLIENŢI)Ştergerea unei tabele din baza de date este realizabilă cu ajutorul comenzii DROP

TABLE. De obicei, această comandă se utilizează atunci când pe parcursul lucrului s-au creat tabele intermediare, temporare. Ştergerea unei asemenea tabele, denumită de exemplu TEMP1, se declanşează prin comanda:

DROP TABLE TEMP1

71

4.3. Comenzi pentru interogarea bazelor de date. Fraza Select

În SQL o interogare se formulează printr-o frază SELECT. Aceasta prezintă trei clauze principale: SELECT, FROM şi WHERE. SELECT corespunde operatorului proiecţie din algebra relaţională, fiind utilizată pentru

desemnarea listei de atribute (coloanele) din tabela-rezultat; FROM este cea care permite enumerarea relaţiilor din care vor fi extrase informaţiile

aferente consultării; prin WHERE se desemnează predicatul selectiv al algebrei relaţionale, relativ la atribute

ale relaţiilor care apar în clauza FROM.La modul general (şi simplist) o consultare simplă în SQL poate fi prezentată astfel:

SELECT C1, C2, ..., CnFROM R1, R2, ..., RmWHERE P

Execuţia unei fraze SELECT se conc1retizează în obţinerea unei tabele (relaţii) 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 obţinută sub forma unei variabile-tablou.

Ci - reprezintă coloanele (care sunt atribute sau expresii de atribute) tabelei-rezultat;Rj - sunt relaţiile ce trebuie parcurse pentru obţinerea rezultatului;P - este predicatul (condiţia) simplu sau compus ce trebuie îndeplinit de tupluri

pentru a fi incluse în tabela-rezultat.Când clauza WHERE este omisă, se consideră implicit că predicatul P are valoarea

logică "adevărat". Dacă în locul coloanelor C1, C2, ... Cn apare simbolul "*", în tabela-rezultat vor fi

incluse toate coloanele (atributele) din toate relaţiile 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 opţiunea AS .

Rezultatul unei fraze SELECT îl vom considera ca fiind sub forma unei tabele oarecare. Trebuie avute în vedere, însă, că rezultatul interogării poate fi obţinut ş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 conţine şi clauza INTO.

SELECT …FROM …INTO destinaţieWHERE…

În destinaţie 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 interogării se obţine o tabelă temporară cu numele predeterminat (Query).

Uneori, tabela rezultat ("normală" sau temporară) "încalcă" poruncile modelului relaţional. Conform restricţiei de entitate, într-o relaţie nu pot exista două linii identice. Or, în SQL, tabela obţinută dintr-o consultare poate conţine două sau mai multe tupluri identice.

Spre deosebire de algebra relaţională, în SQL nu se elimină automat tuplurile identice (dublurile) din tabela-rezultat. Pentru aceasta este necesară utilizarea opţiunii DISTINCT:

SELECT DISTINCT C1, C2, ..., CnFROM R1, R2, ..., RmWHERE P

În concluzie, o frază SELECT, în forma în care a fost prezentată, corespunde: unei selecţii algebrice (clauza WHERE - P) unei proiecţii (SELECT - Ci) unui produs cartezian (FROM - R1 R2 ... Rm)şi conduce la obţinerea unei noi relaţii (tabele-rezultat) cu n coloane, fiecare coloană

fiind: un atribut din R1, R2, ..., Rm sau

72

o expresie calculată pe baza unor atribute din R1, R2, ..., Rm.

Exemplu

Care este, pentru fiecare factură emisă, valoarea fără TVA ?SELECT NrFactură, ValoareTotală - TVAColectata AS ValoareFaraTVAFROM FACTURIEMISE

Tabela rezultat din fig. nr. 4.2 va conţine două atribute: NrFactură şi ValoareFaraTVA. Ultimul este un câmp calculat.

Rezultat:NrFactură ValoareFaraTVA

111111 1428.58111112 239.50111113 491.6111114 2394.96111115 3000111116 731.1111117 924.37111118 1260.51111119 3970.59111120 252.11111121 357.15111122 735.3111123 554.7111124 3235.3111125 1075.63111126 4558.83

Fig. nr. 4.2. Exemplu de câmp calculat (ValoareFaraTVA)

Interogări care utilizează operatorii asamblişti din algebra relaţionalăReuniunea

SELECT *FROM R1UNION

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.

Intersecţia Pentru realizarea intersecţiei a două tabele, R1 şi R2 se utilizează operatorul

INTERSECT:SELECT *FROM R1INTERSECT

SELECT *FROM R2

73

Dacă în produsele profesionale, precum DB2 sau Oracle, operatorul este prezent, în altele, precum Visual FoxPro, INTERSECT rămâne un deziderat, funcţionalitatea sa realizându-se prin subconsultări (operatorii IN şi EXISTS) sau, uneori, prin joncţiune.

Diferenţa Diferenţa dintre tabelele R1 şi R2 se realizează utilizând operatorul MINUS sau

EXCEPT. Fraza SELECT următoare funcţionează în Oracle.

SELECT *FROM R1MINUS

SELECT *FROM R2

Produsul cartezian În SQL nu există operator explicit pentru efectuarea produsului cartezian. Dacă în clauza

FROM apar două relaţii, R1 şi R2, atunci, în lipsa unei condiţii de joncţiune formulată în clauza WHERE, tabela rezultat va conţine liniile obţinute din produsul cartezian R1 R2.

SELECT *FROM R1, R2

Interogări care utilizează operatorii relaţionali din algebra relaţionalăSelecţia

Exemplul 1 Care dintre facturile emise după 23.06.2007 prezintă valoarea mai mare de 3000 lei ?

SELECT *FROM FACTURIEMISEWHERE DataFactură > {23.06.2007} AND ValoareTotala > 3000

Rezultat:NrFactură CodClient DataFactură ValoareTotală TVAColectată

111119 1005 24.06.2007 4725 754.41111124 1004 25.06.2007 3850 614.7111126 1002 01.07.2007 5425 866.17

Operatorul AND a fost utilizat pentru a introduce un "ŞI" logic, după cum OR se utilizează pentru “SAU” logic. În SQL, pentru comparare, în afara "clasicilor": >, >=, <, <=, =, (<>), mai pot fi utilizaţi şi alţi 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 BETWEENAcest operator permite specificarea unui interval de valori în care trebuie să se încadreze

câmpul sau expresia testată. Intervalul se referă la valori numerice sau la date calendaristice.Exemplul 2Care sunt facturile emise după 23.06.2007 şi care au valoarea cuprinsă între 3000 şi

4000 lei ?Fără operatorul BETWEEN fraza SELECT se scrie:

SELECT *FROM FACTURIEMISEWHERE DataFactură > {23.06.2007} AND ValoareTotala >= 3000 AND ValoareTotala <= 4000

74

Utilizând operatorul BETWEEN se poate scrie:SELECT *FROM FACTURIEMISEWHERE DataFactură > {23.06.2007} AND ValoareTotala BETWEEN

3000 AND 4000

Operatorul LIKEAcest operator se foloseşte 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 doreşte obţinerea unei tabele-rezultat care să conţină numai clienţii ai căror 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 CLIENŢI 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 liniuţa de subliniere ("_"). Spre deosebire de "%", "_" substituie un singur caracter. Diferenţa dintre cei doi specificatori multipli este pusă în evidenţă în exemplele următoare.

Exemplul 3Care sunt clienţii ai căror nume este format din şapte caractere, începe cu litera A şi

sunt societăţi cu răspundere limitată (SRL-uri) ?SELECT *FROM CLIENŢIWHERE NumeClient LIKE "A__ SRL"

Rezultat:CodClien

tNumeClient Adresa Localitate

1006 AMI SRL Galaţiului, 72 Bacău

Exemplul 4Dacă în exemplu 3 s-ar fi utilizat simbolul "%":

SELECT *FROM CLIENŢIWHERE NumeClient LIKE "A%SRL",

am fi obţinut:Rezultat:

CodClient NumeClient Adresa Localitate1006 AMI SRL Galaţiului, 72 Bacău1007 AXON SRL Silvestru, 2 Iaşi1008 ALFA SRL Prosperităţii, 15 Paşcani

În concluzie, "_" înlocuieşte (substituie) un singur caracter, în timp ce "%" înlocuieşte un şir de caractere de lungime variabilă (între 0 şi n caractere). Cei doi specificatori multipli pot fi utilizaţi împreună.

Operatorul IN Format general:

expresie1 IN (expresie2, expresie3, ...)Rezultatul evaluării unui predicat ce conţine acest operator va fi "adevărat" dacă valoarea

expresiei1 este egală cu (cel puţin) una din valorile: expresie2, expresie3, ... Este util atunci când condiţiile de selecţie sunt mai complexe.

Exemplul 5Care sunt clienţii din Iaşi şi Bacău ?

75

Fără utilizarea operatorului IN se scrie:SELECT *FROM CLIENTIWHERE Localitate= "Iaşi" OR Localitate= "Bacău”

Utilizând operatorul IN:SELECT *FROM CLIENTIWHERE Localitate IN ("Iaşi", "Bacău)

RezultatCodClient NumeClient Adresa Localitate1001 TEXTILA SA Bld. Copou, 87 Iaşi1003 OCCO SRL NULL Iaşi1006 AMI SRL Galaţiului, 72 Bacău1007 AXON SRL Silvestru, 2 Iaşi

Operatorul IS NULL O valoare nulă este o valoare nedefinită. Este posibil ca la adăugarea unei linii într-o

tabelă valorile unor atribute să fie necunoscute. În aceste cazuri valoarea atributului pentru tuplul respectiv este nulă. Reamintim că, prin definiţie, nu se admit valori nule pentru grupul atributelor care constituie cheia primară a relaţiei.

Exemplul 6Dacă se doreşte aflarea clienţilor pentru care nu s-a introdus adresa, se poate scrie:

SELECT *FROM CLIENTIWHERE Adresa IS NULL

Rezultat:CodClient NumeClient Adresa Localitate

1003 OCCO SRL NULL Iaşi

Observaţii Valoarea NULL nu se confundă cu valoarea zero (pentru atributele numerice) sau cu

valoarea "spaţiu" (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 evaluării va fi întotdeauna fals, chiar dacă expresia nu este nulă.

Proiecţia. Opţiunea ORDER BYColoanele tabelei-rezultat al consultării sunt specificate în clauza SELECT, fiind

separate prin virgulă.

Exemplul 1 Care sunt localităţile în care firma are clienţi ?Este necesară parcurgerea relaţiei CLIENTI, singurul atribut care interesează fiind

Localitate. Deoarece SQL nu elimină dublurile automat, dacă se doreşte ca în tabela-rezultat o localitate să figureze o singură dată, se utilizează opţiunea DISTINCT:

SELECT DISTINCT LocalitateFROM CLIENTI

Rezultat:

76

LocalitateIaşiFocşaniBacăuPaşcani

Prezentarea localităţilor în ordinea alfabetică a numelui acestora este posibilă apelând la clauza ORDER BY.

SELECT LocalitateFROM CLIENTIORDER BY Localitate DESCENDING

Opţiunile ASCENDING (crescător) şi DESCENDING (descrescător) indică modul în care se face ordonarea tuplurilor tabelei-rezultat al interogării.

Prioritatea de ordonare este stabilită prin ordinea atributelor specificate în ORDER BY: ordonarea "principală" se face în funcţie de valorile primului atribut specificat; în cadrul grupelor de tupluri pentru care valoarea primului atribut este identică, ordinea se stabileşte după valoarea celui de-al doilea atribut specificat ş.a.m.d.

Dacă în ORDER BY lipsesc opţiunile ASCENDING/DESCENDING, ordonarea se face implicit crescător.

JoncţiuneaSQL nu prezintă clauze sau operatori speciali pentru realizarea theta-joncţiunii, echi-

joncţiunii sau joncţiunii naturale. Dar, aşa cum am văzut, o joncţiune este o combinaţie de produs cartezian şi selecţie.

Exemplu:Care sunt facurile emise clienţilor din municipiul Iaşi ?

SELECT NrFactura, NumeClient, LocalitateFROM FACTURIEMISE, CLIENŢIWHERE FACTURIEMISE.CodClient = CLIENŢI.CodClient

AND Localitate=”Iaşi”sauSELECT NrFactura, NumeClient, LocalitateFROM FACTURIEMISE INNER JOIN CLIENŢION WHERE FACTURIEMISE.CodClient = CLIENŢI.CodClient WHERE Localitate=”Iaşi”

Rezultat:NrFactură NumeClient Localitate

111111 OCCO SRL Iaşi111112 TEXTILA SA Iaşi111114 OCCO SRL Iaşi111118 AXON SRL Iaşi111120 OCCO SRL Iaşi111121 TEXTILA SA Iaşi111122 AXON SRL Iaşi111125 OCCO SRL Iaşi

77

Sub-consultări. Operatorul IN O altă facilitate deosebit de importantă a limbajului SQL o constituie posibilitatea

includerii (imbricării) a două sau mai multe fraze SELECT, astfel încât pot fi formulate interogări cu mare grad de complexitate.

Operatorul IN poate fi utilizat şi pentru includerea unei fraze SELECT într-o altă frază SELECT.

Exemplul 1Care sunt facturile emise în aceeaşi zi în care a fost întocmită factura 111114 ?

SELECT *FROM FACTURIEMISEWHERE DataFactură IN

(SELECT DataFactură FROM FACTURIEMISE WHERE NrFactură=111114)

ObservaţieSub-consultarea

SELECT DataFacturăFROM FACTURIEMISEWHERE NrFactură=111114

are ca rezultat o tabelă alcătuită dintr-o singură coloană (DataFactură) şi o singură linie ce conţine valoarea atributului DataFactură pentru factura 111114:

DataFactură18.06.2007

Clauza WHERE DataFactură IN determină căutarea î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 obţinută prin "sub-consultare". Cu alte cuvinte, în acest caz WHERE Data IN va selecta toate facturile pentru care data emiterii este 18.06.2007.

Rezultat:NrFactură CodClient DataFactură ValoareTotală TVAColectată

111113 1004 18.06.2007 585 93.4111114 1003 18.06.2007 2850 455.04111115 1008 18.06.2007 3570 570

Exemplul 2Care sunt facturile emise în alte zile decât cea în care a fost întocmită factura 111114 ?

SELECT *FROM FACTURIEMISEWHERE DataFactură NOT IN

(SELECT DataFactură FROM FACTURIEMISE WHERE NrFactură=111114)

S-a utilizat negaţia, testându-se non-apartenenţa la o relaţie creată printr-o sub-frază SELECT.

Exemplul 3Care sunt clienţii cărora li s-au trimis facturi întocmite în aceeaşi zi cu factura 111114 ?

SELECT DISTINCT NumeClientFROM CLIENŢIWHERE CodClient IN

(SELECT CodClient FROM FACTURIEMISE

78

WHERE DataFactură IN (SELECT DataFactură FROM FACTURIEMISE WHERE NrFactură=111114))

Am ilustrat modul în care pot fi imbricate (înlănţuite, incluse) trei fraze SELECT. O altă soluţie pentru rezolvarea aceleaşi probleme este şi:

SELECT DISTINCT NumeClientFROM CLIENŢI, FACTURIEMISEWHERE CLIENŢI.CodClient=FACTURIEMISE.CodClientAND DataFactură IN

(SELECT DataFactură FROM FACTURIEMISE WHERE NrFactură=111114)

Se poate reţine, ca regulă generală, că aproape orice consultare poate fi redactată în mai multe moduri, în funcţie de experienţa şi imaginaţia celui care o formulează.

Funcţii de agregare (statistice): COUNT, SUM, AVG, MAX, MIN Formatul general al unei fraze SELECT ce conţine funcţii predefinite este:

SELECT funcţia-predefinită1, ... , funcţia-predefinităNFROM listă-tabeleWHERE condiţii.

Rezultatul oricărei fraze SELECT este o nouă relaţie (tabelă). În lipsa opţiunii GROUP BY, dacă în clauza SELECT este prezentă o funcţie predefinită, tabela rezultat va conţine o singură linie.

Funcţia COUNT contorizează valorile unei coloane, altfel spus, numără, într-o relaţie, câte valori diferite de NULL are coloana specificată.

Exemplul 1 Câţi clienţi are firma ?

SELECT COUNT (CodClient) AS Nr_ClientiFROM CLIENTI

Rezultat:Nr_Clienti

8

În funcţia COUNT se poate utiliza ca argument, în locul numelui unei coloane, semnul *; în acest caz se va determina câte linii are tabela la care se aplică funcţia respectivă.

Exemplul 2 La câţi clienţi s-au trimis facturi ?

SELECT COUNT(*)FROM CLIENTIWHERE CodClient IN

(SELECT CodClient FROM FACTURIEMISE)

Rezultatul corect poate fi însă obţinut şi prin utilizarea clauzei DISTINCT astfel:SELECT COUNT (DISTINCT CodClient)FROM FACTURIEMISE

79

Funcţia SUM calculează suma valorilor unei coloane.

Exemplul 3 Care este valoarea totală a facturilor emise ?

SELECT SUM (ValoareTotala) AS Total_FEFROM FACTURIEMISE

Rezultat:Total_FE

30000

Exemplul 4 Care este totalul valorii facturilor trimise clientului AXON SRL ?

SELECT SUM (ValoareTotala) AS Total_FE_AXONFROM FACTURIEMISE, CLIENTIWHERE FACTURIEMISE.CodClient = CLIENTI.CodClient AND NumeClient = "AXON SRL"

Funcţiile MAX şi MIN determină valorile maxime, respectiv minime ale unei coloane în cadrul unei tabele.

Exemplul 5Care este cea mai mică valoare a unei facturi emise ?

SELECT MIN(ValoareTotala) AS ValMinimaFROM FACTURIEMISE

RezultatValMinima

285

Exemplul 6Care este factura emisă ce are cea mai mare valoare ?

SELECT NrFactură, ValoareTotalaFROM FACTURIEMISEWHERE ValoareTotala = (SELECT MAX (ValoareTotala)

FROM FACTURIEMISE)

Rezultat:NrFactura ValoareTotala

111126 5425

Gruparea tuplurilor. Clauzele GROUP BY şi HAVINGSQL permite utilizarea clauzei GROUP BY pentru a forma grupe (grupuri) de tupluri ale

unei relaţii, pe baza valorilor comune ale unei coloane. În frazele SELECT formulate până î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 conţine clauza GROUP BY este o tabelă care va fi obţinută prin regruparea tuturor liniilor din tabelele enumerate în FROM, care prezintă o aceeaşi valoare pentru o coloană sau un grup de coloane.

Formatul general este:SELECT coloană1, coloană2, ...., coloanăm

80

FROM tabelăGROUP BY coloană-de-regrupare

Exemplu 1Care este totalul zilnic al valorii facturilor emise ?

SELECT DataFactură, SUM (ValoareTotala)FROM FACTURIEMISEGROUP BY DataFactură

În acest caz tabela-rezultat va avea un număr de linii egal cu numărul de date calendaristice distincte din tabela FACTURIEMISE. Pentru toate facturile aferente unei zile se va calcula suma valorilor, datorită utilizării funcţiei SUM(ValoareTotala).

Succesiunea paşilor este următoarea:1. Se ordonează liniile tabelei FACTURIEMISE în funcţie de valoarea atributului

DataFactură:

NrFactură CodClient DataFactură ValoareTotala TVAColectata111111 1003 17.06.2007 1700 271.42111112 1001 17.06.2007 285 45.5111113 1004 18.06.2007 585 93.4111114 1003 18.06.2007 2850 455.04111115 1008 18.06.2007 3570 570111116 1008 19.06.2007 870 138.9111117 1006 20.06.2007 1100 175.63111118 1007 23.06.2007 1500 239.49111119 1005 24.06.2007 4725 754.41111120 1003 24.06.2007 300 47.89111121 1001 24.06.2007 425 67.85111122 1007 24.06.2007 875 139.7111123 1006 25.06.2007 660 105.37111124 1004 25.06.2007 3850 614.7111125 1003 30.06.2007 1280 204.36111126 1002 01.07.2007 5425 866.17

2. Se formează câte un grup pentru fiecare valoare distinctă a atributului DataFactură:

3.NrFactură CodClient DataFactură ValoareTotala TVAColectata111111 1003 17.06.2007 1700 271.42111112 1001 17.06.2007 285 45.5111113 1004 18.06.2007 585 93.4111114 1003 18.06.2007 2850 455.04111115 1008 18.06.2007 3570 570111116 1008 19.06.2007 870 138.9111117 1006 20.06.2007 1100 175.63111118 1007 23.06.2007 1500 239.49111119 1005 24.06.2007 4725 754.41111120 1003 24.06.2007 300 47.89111121 1001 24.06.2007 425 67.85111122 1007 24.06.2007 875 139.7111123 1006 25.06.2007 660 105.37111124 1004 25.06.2007 3850 614.7111125 1003 30.06.2007 1280 204.36

81

111126 1002 01.07.2007 5425 866.17

3. Pentru fiecare din cele nouă grupuri se calculează suma valorilor atributului ValoareTotala.

Tabela - rezultat final va avea nouă linii:DataFactură SUM(ValoareTotala)

17.06.2007 198518.06.2007 700519.06.2007 87020.06.2007 110023.06.2007 150024.06.2007 6325 25.06.2007 451030.06.2007 1280 01.07.2007 5425

Exemplul 2Care este numărul facturilor emise pentru fiecare client ?

SELECT NumeClient, COUNT(NrFactură)FROM FACTURIEMISE, CLIENTIWHERE FACTURIEMISE.CodClient=CLIENTI.CodClientGROUP BY FACTURIEMISE.CodClient

ObservaţiePână 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 restricţii care sunt aplicate grupurilor de tupluri, deci nu tuplurilor "individuale", aşa cum "face" clauza WHERE. Din tabela rezultat sunt eliminate toate grupurile care nu satisfac condiţia 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ă mFROM tabelăGROUP BY coloană-de-regrupareHAVING caracteristică-de-grup

Exemplul 3Pentru facturile emise interesează valoarea zilnică a acestora (în funcţie de data la care

au fost întocmite, dar numai dacă aceasta (valoarea zilnică) este de mai mare de cinci mii lei.SELECT DataFactură, SUM(ValoareTotala)FROM FACTURIEMISEGROUP BY DataFacturăHAVING SUM(ValoareTotala) > 5000

La execuţia acestei fraze, se parcurg cei trei paşi prezentaţi la exemplul 1, apoi, din cele nouă tupluri obţinute prin grupare, sunt extrase numai cele care îndeplinesc condiţia SUM(ValoareTotala) > 5000.

Rezultat:Data SUM(ValoareTotala)

18.06.2007 700524.06.2007 632501.07.2007 5425

82

Exemplul 4 Să se afişeze ziua în care s-au întocmit cele mai multe facturi.

SELECT DataFacturăFROM FACTURIEMISEGROUP BY DataFacturăHAVING COUNT(*) >= ALL

(SELECT COUNT(*)FROM FACTURIEMISEGROUP BY DataFactură)

Exemplul 5Care sunt clienţii pentru care s-au întocmit numai două facturi?

SELECT NumeClientFROM CLIENTI INNER JOIN FACTURIEMISE ON CLIENTI.CODCLIENT=FACTURIEMISE.CODCLIENTGROUP BY NumeClientHAVING COUNT(NrFactura)=2sauSELECT NumeClientFROM CLIENTI WHERE CodClient IN(SELECT CodClientFROM FACTURIEMISEGROUP BY CodClientHAVING COUNT(NrFactura)=2)

Exemplu 6Care sunt zilele în care s-au întocmit cel puţin trei facturi?

SELECT DataFact , Count(*) as NrFROM FacturiEmise

GROUP BY DataFactHAVING COUNT(*)>=3

5.4. Comenzi pentru actualizarea bazelor de dateSQL prezintă comenzi specifice pentru modificarea conţinutului unei tabele, înţelegând

prin aceasta trei acţiuni prin care se actualizează baza:a) adăugarea de noi linii la cele existente într-o tabelă,b) ştergerea unor linii,c) modificarea valorii unui atribut.

Adăugarea de înregistrăriAdăugarea de noi linii într-o tabelă se realizează cu comanda INSERT care are

următoarea sintaxă:Format: INSERT

INTO tabelă [(listă_câmpuri)]VALUES (listă_valori)

Exemplul 1Să presupunem că, la un moment dat, întreprinderea vinde produse şi firmei RODEX

SRL care are sediul pe strada Sapienţei, nr.44 bis, în localitatea Iaşi. Acest nou client trebuie "introdus" în baza de date, operaţiune care în SQL, se realizează prin comanda:

INSERTINTO CLIENŢI

83

VALUES (1009, "RODEX SRL", "Sapienţei, 44 bis", “Iaşi”)Fraza INSERT de mai sus poate fi scrisă şi sub forma:

INSERT INTO CLIENŢI (CodClient, NumeClient, Adresa, Localitate)VALUES (1009, "RODEX SRL", "Sapienţei 44 bis", "Iaşi").

După cum se observă, după numele tabelei (CLIENŢI) au fost enumerate toate atributele pentru care se introduc valori prin clauza VALUES.

Dacă nu s-ar fi cunoscut adresa clientului RODEX, atunci fraza INSERT ar fi avut forma:

INSERTINTO CLIENŢI (CodClient, NumeClient, Adresa, Localitate)VALUES (1009, "RODEX SRL", NULL, "Iaşi")

În noua linie a tabelei CLIENŢI valoarea atributului Adresa va fi NULL.Se putea folosi şi forma:

INSERTINTO CLIENŢIVALUES (1009, "RODEX SRL", " ", "Iaşi")

În urma execuţiei acestei comenzi, valoarea atributului Adresa va fi " " (un spaţiu), deci diferită de NULL.

Ştergerea înregistrărilorOperaţiunea de eliminare a uneia sau mai multor linii dintr-o tabelă se realizează prin

comanda DELETE care are următoarea sintaxă:DELETE FROM nume-tabelăWHERE predicat

Exemplul 2Să se elimine din tabela CLIENŢI linia aferentă clientului MODERN SRL (cod 1002).

DELETEFROM CLIENŢIWHERE CodClient = 1002

Exemplu 3Să se şteargă datele referitoare la facturile emise clienţilor din oraşul Focşani.

DELETEFROM FACTURIEMISEWHERE CodClient IN

(SELECT CodClient FROM CLIENŢI WHERE Localitate = "Focşani")

În general, ştergerea unor linii trebuie privită cu multă circumspecţie, deoarece atunci când linia de şters conţine valori ale unor atribute ce apar în alte tabele ca şi chei străine, există riscul pierderii integrităţii referenţiale.

Standardul SQL92 permite la crearea unei tabele descrierea acţiunii care se va derula la ştergerea unei linii părinte în cazul în care există linii copil. Spre exemplu, se poate refuza ştergerea de linii din tabela CLIENŢI, 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 CLIENŢI

ON DELETE RESTRICT)

84

Modificarea valorilor unor atributePentru modificarea valorilor unuia sau mai multor atribute dintr-o tabelă, comanda

utilizată este UPDATE care are formatul general:UPDATE tabelăSET atribut = expresieWHERE predicat

Ca rezultat, vor fi modificate valorile atributului specificat, noile valori ale acestuia fiind cele care rezultă în urma evaluării expresiei; modificarea se va produce pe toate liniile tabelei care îndeplinesc condiţia specificată în predicat.

Exemplul 4Noua adresă a clientului Modern SRL este “Bulevardul Victoriei nr. 21”. Să se opereze

modificarea în baza de date.Se actualizează atributul Adresa din tabela Clienţi.

UPDATE CLIENŢISET Adresa=“Bulevardul Victoriei nr. 21”WHERE NumeClient=”Modern SRL”

85

Bibliografie1. Airinei, D., ş.a., Modele de aplicaţii practice în Microsoft Excel şi Visual FoxPro,

Editura Sedcom Libris, Iaşi, 20032. Bazian, Menachem, Totul despre Visual FoxPro 6.0, Editura Teora, Bucureşti,

20013. Bâscă, O., Baze de date, Editura All, Bucureşti, 19974. Bot, Ed, Leonhard, Woody, Microsoft Office XP, traducere de Simona şi Titi

Preda, Editura Teora, Bucureşti, 20035. Conolly, T., Begg, C., Strachan, A., Baze de date,. Proiectare, implementare,

gestionare, Editura Teora, Bucureşti, 20016. Florescu, V., ş.a., Baze de date, Editura Economica, Bucureşti, 19997. Forta, B., SQL în lecţii de 10 minute, traducere de Mihai Mănăstireanu, Editura

Teora, Bucureşti, 20078. Fotache, M., Baze de date relaţionale. Organizare, interogare şi normalizare,

Editura Junimea, Iaşi, 19979. Fotache, M., SQL. Dialecte DB2, Oracle, Visual FoxPro, Editura Polirom, Iaşi,

200110. Fotache, M., Proiectarea bazelor de date. Normalizare, postnormalizare, Editura

Polirom, Iaşi, 200511. Fotache, M., Brava, I., Strîmbei, C., Creţu, L., Visual FoxPro. Ghidul dezvoltării

aplicaţiilor profesioanle, Editura Polirom, Iaşi, 200212. Hernandez, M. J., Proiectarea bazelor de date, Editura Teora, Bucureşti, 200313. Lungu, I. şi colectiv, Baze de date. Organizare, proiectare şi implementare,

Editura ALL, Bucureşti, 199514. Melnic, A., Medii de programare, Editura TehnoPress, Iaşi, 200515. Miloşescu, M., Baze de date în Visual FoxPro, Editura Teora, Bucureşti, 200316. Năstase, P., Tehnologia bazelor de date, Access 2000, Editura Economică,

Bucureşti, 200017. Oppel, A., SQL fără mistere, traducere de Cristian Mocanu, Florin Moraru,

Editura Rosetti Educational, Bucureşti, 200618. *** Microsoft Office, Access 2003, traducere de Cristian

Mocanu, Editura Teora, Bucureşti, 2004

86