SUPo RT CURSBAZEDEDATE2007

UNIVERSITATEA “GEORGE BACOVIA” BACĂU
BAZE DE DATE
SUPORT DE CURS
Conf. univ. dr. Andreia Melnic
Uz intern
Bacău
2007
CUPRINS
Capitolul 1. INTRODUCERE IN STUDIUL LIMBAJELOR DE PROGRAMARE…….

……………………………………………………………………..3
1.1. Noţiuni generale privind limbajele de programare
1.2. Clasificarea limbajelor de programare
1.3. Structurarea şi organizarea datelor. Tipuri de date utilizate în limbajele de programare
1.4. Caracterizarea principalelor limbaje de programare
1.5. Criterii de selecţie a limbajelor de programare
CAPITOLUL 2 BAZE DE DATE ŞI SISTEME DE GESTIUNE A BAZELOR DE

DATE…………….…………………………………………………………………………17
2.1 Concepte utilizate în studiul bazelor de date şi al sistemelor de gestiune a bazelor de date
2.2. Modele de structurare a datelor în baze de date
2.3. Sisteme de gestiune a bazelor de date
2.4. Arhitecturi multiutilizator pentru sisteme de gestiune a bazelor de date
2.5. Protecţia şi securitatea bazelor de date
2.6. Administrarea datelor şi a bazelor de date
Capitolul 3. MODELUL RELAŢIONAL AL DATELOR………………………………52

3.1. Elementele modelului relaţional
3.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ţe
4.2. Comenzi pentru descrierea datelor;
4.3. Comenzi pentru interogarea bazelor de date
2
Capitolul 1. INTRODUCERE IN STUDIUL LIMBAJELOR DE PROGRAMARE

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

Odată 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:
3
 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.;
 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.
Problema
Programator execută
Calculator
(utilizator) programul
pe baza analizei instrucţiuni Rezultat

problemei de rezolvat pentru calculator
Scrie Program Traducere automată

programul în limbaj maşină
Reguli şi restricţii ale

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

Cea 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):
P.S.
Program
executabil 1. Asamblare Asamblor
2. Execuţie Date
Rezultate
finale
5
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 –
î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)/3
LDA X - încarcă X în registrul A
ADD Y - adună Y la conţinutul registrului A
ADD Z -adună Z la conţinutul registrului A
DIV 3 - împarte rezultatul la 3
STA B - stochează rezultatul final în B
Limbajele î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 ):
6
P.S.
1. Compilare/ Compilator/
ProgramO. interpretare interpretor
2. Editarede Editor de
P.O. imagine legături legături
memorie
3. Execuţie Date
executabil
Rezultate
finale
Fig.1.3. Tratarea programelor în limbaje evoluate

Avantaje: 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.
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-Z
Aceste 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).
7
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;
 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.
1
Oprea, D., Premisele şi consecinţele informatizării contabilităţii, Ed. Graphix, Iaşi,
1994, p. 96
8
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.
Tendinţe majore în software
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
limbaje în limbaje de limbaje de limbaje de limbaje

Evoluţie cod maşină asamblare nivel inalt; gen. a IV-a naturale;
limbaje primele (4GL) orien- sisteme
sisteme de tate către expert
operare utilizator
Tendinţa: către aplicaţii cu scop general, orientate spre utilizatorul nespecialist
Fig. nr. 14. Evoluţia limbajelor de programare
Aş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.
2
Sammet, J.,E., Programming Languages: History and Fundamentals, N.J. Prentice-Hall, 1969
9
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.
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 datelor

Organizarea datelor reprezintă procesul de identificare, definire, structurare şi
memorare a datelor.3
O bună organizare a datelor impune folosirea unor structuri care să permită o
prelucrare cu un cost 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.
3
Cristea , V. , Dicţionar de informatică, Editura Ştiinţifică şi enciclopedică,
Bucureşti , 1981, p. 240
10
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:
• 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 0
DENUMIRE C 10
PREŢ N 9 2
STOC N 8 2
Fiş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.
11
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 = 0
SF = 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.
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) - IMPOZ
a = (b * c)**2 + 650
Operaţ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"
ENDIF
sau
FOR 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):
Zonatampon
Zonåde
intrare Z. ARTICOL COD DEN UM CANT PREº
X
Zonåde VALOARE
lucru
Z. ARTICOL COD DEN UM CANT PREº VALOARE

Zonåde
ie¿ire
Zonatampon
Fig. 1.5. Transferul de date între memoria internă şi cea externă
12
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.):
Fig. 1.6. Derularea operaţiunilor de apel
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).
13
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.
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.
14
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
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.

La 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 utilizatorului
3. gradul de dependenţă faţă de echipamentul folosit şi sistemul de operare
4. evaluarea rezultatelor obţinute prin folosirea anterioară de către alţi utilizatori
5. eficienţa scontată prin exploatare
6. caracteristicile tehnice şi funcţionale generale
7. cerinţe de ordin economic
 Tipul problemei ce urmează a fi rezolvată şi cunoştinţele utilizatorului
Acest 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.
4
Sammet, J.,E., Programming Languages: History and Fundamentals, N.J. Prentice-Hall, 1969
15
 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 operare
Conform 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
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
date
2.2. Modele de structurare a datelor în baze de date
2.3. Sisteme de gestiune 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 independente

Sistemul 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

Data1
Data2 Raport
FIŞIER 1 Prelucrare 1 1
Data3 ...
Raport
Data2 FI ŞIER 2 Prelucrare 2 2
Data4 Raport
... 3
Data3
FIŞIER 3 Prelucrare 3 Raport
Data1 4
Data2 Data5 ...
DATE FI ŞIERE PRELUCR ĂRI IEŞIRI
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-246
6
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ţii
Organizarea 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 date

Pe 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.
BAZA DE DATE
Fişier de date 1
Fişier de date 2 Dicţionar

... de
date
Fişier de date n
Aplicaţia 1 Aplicaţia 2 ... Aplicaţia m
Fig. nr .2.2. Structura unei baze de date
Conceptul de bază de date a apărut în 1964 în cadrul primului raport CODASYL 7

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 date
Entitate Caracteristici (atribute) Realizări (valori)
Cod_produs 152
Denumire_produs Pantofi
Unit_măs Pereche
Produs Preţ_ unitar 115
Cantitate 100
Nr._factură 2452
Data_recepţiei 24-10-2007
7
COnference on DAta SYstems Languages – Conferinţa despre Limbajele Sistemelor de Date
8
Lungu, I., ş.a., Baze de date, Organizare, proiectare şi implementare, Editura All, Bucureşti, 1995,
p.13
9
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.
Moréjon, J., Principes et conception d’une base de données relationnelle, Les Editions d’organisation,
10
Paris, 1992, p. 20
20
Niveluri de abstractizare a datelor în bazele de date
Abordarea datelor în contextul bazelor de date se face pe trei niveluri, considerate
niveluri de abstractizare:
Nivelul intern este nivelul elementar la care pot fi considerate datele şi se referă la
modul în care sunt stocate datele pe suporturi - disc magnetic, bandă magnetică, disc optic etc.
La acest nivel structura datelor este foarte detaliată. Nivelul intern cuprinde structurile de date
şi 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
Utilizator A1 Utilizator A2 Utilizator B1 Utilizator B2 ...
Aplicaţie Comenzi Comenzi ….

autonome Aplicaţie
autonome
Schema Imagine A Schema

externă A externă B Imagine B ….
(nivel extern) (nivel exter n)
INTERFAŢA A INTERFAŢA B
Schema conceptuală Imagine globală Sistem de

(globală) (nivel global) gestiune a
bazei de date
INTERFAŢA
Schema internă
BAZA DE DATE MEMORATĂ PE DISC
Fig. nr.2.3. Nivele de abstractizare a datelor în bazele de date

Includerea în baza de date a descrierii structurii acesteia o deosebeşte calitativ de
fişierele de date, deoarece prin aceasta se asigură independenţa datelor din bază faţă de
11
Fotache, M., Baze de date relaţionale. Organizare, interogare şi normalizare, Editua Junimea, Iaşi,
1997, p.32
21
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:
• 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
C o l e c ¡i i
d e d a te
C o l e c ¡i i C o l e c ¡i i
d e d a te d e d a te
C o l e c ¡i i
d e d a te
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 date

Conceptul 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ă.
23
Componentele unui depozit de date sunt următoarele:13
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
13
Fotache, M., Op. cit., p. 56
14
Fotache, M., Depozitul de date, în Tribuna economică nr.36 /1998, p.49
24
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
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 date

Realizarea 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ţionale

Activitatea 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
studiat→modelul 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;
16
Pratt, P.J., Adamski, J.J., Database Systems. Management and Design, Boyd&Fraser, Boston, 1991,
p. 285
26
• stabilirea succesiunii evenimentelor şi construirea unei diagrame care să descrie
fluxul acestora (diagramă a stărilor de tranziţie, a fluxului de evenimente).
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:
17
Lungu, I. şi colab., Op. cit., p. 53
27
• portabilitatea SGBD;
• portabilitatea datelor şi programelor de aplicaţii;
• condiţiile de încărcare, exploatare şi întreţinere a BD;
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 externe

Prin 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ă
18
abreviere de la "Conference on Data Systems Languages"
28
(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ă.
Proiectarea schemei interne

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

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

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

Entităţ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
Y 1
X 2
Y 2
.
.
.
.
X n
Y n
D o m en iu C o d o m en iu
Fig. 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
Y 1
Y 2
.Y 3.
Y 4
X 2 Y 5
Fig. 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 2 Y
X 3
Fig. 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
Y 1
Y 2
.Y 3.
X 2
Y 4
Fig. 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
30
sunt supuse prelucrărilor cu un grup de operatori de bază cu o semantică predefinită formează
un anumit tip de structură.
Principalele tipuri de structuri sunt19: punctuală, liniară, arborescentă, 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 date

Un 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
Adresa Data
Furnizor Localitate Numar Valoare
FURNIZORI Cumparare FACTURI-PRIMITE
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
19
Lungu, I., Op. cit., p. 6
31
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
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,
20
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., Object-Oriented Modelling and
Design, Pretice-Hall, 1991
32
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ţă,
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ă).
33
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 -
FURNIZORI FACTURI-PRIMITE
Furnizor Adresa Localitate Furnizor Număr Data Valoare
Alfa Unirii 2 Iaşi Alfa SRL 12540 12/02/07 1259.8
SRL
Beta SA Apelor 5 Bacău Beta SA 14870 14/02/07 3265
Gama Viilor 56 Iaşi Alfa SRL 24550 22/02/07 2987.5
SA
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:
FACTURI-
EMISE
Factura 1 Factura 2 Factura 3

Produs B Produs
Produs
Produs AA Produs D Produs A Produs E Produs F
Produs B
C
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.
34
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 A Produs B Produs C Produs D Produs E Produs F

Fig. 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ŢII

Definirea 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.
35
2546 13/02/07 2365
Alfa SRL Unirii 2 Iaşi R12548171
3560 15/02/07 1879
Beta SA Ploii 21 Bacău R19857144 2478 18/02/07 3654
1266 20/02/07 1458.7

Gama SA Viilor 50 Iaşi R19874001
1687 21/02/07 1897.1
Fig. 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.
FURNIZORI FACTURI
Nume Număr
Adresă întocmeşte este Dată
CUMPĂRARE
Localitate întocmită Valoare
Cod_fiscal
Fig. nr. 2.14. Diagrama entitate-asociaţii
Metoda MERISE de proiectare a bazelor de date propune reprezentarea grafică din

fig. nr. 2.15.
FURNIZORI FACTURI
Nume Număr
Adresă CUMPĂRARE Dată
Localitate Valoare
Cod_fiscal
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.
36
Cele mai simple, dar şi cele mai utilizate sunt asociaţii binare. În practică apar deseori
şi asociaţii ternare.
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 y1 x1 y1
x2 y2 x2 y2
x3 y3 x3 y3
x4 y4 y4
TIP 1 la 1 TIP 1 la n
Fig. 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.
CLIENTI FACTURI
Nume n 1 Numar
Adresa VANZARE Data
Localitate Valoare
Cod_fiscal
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 y1 x1 y1
x2 y2 x2 y2
x3 y3 x3 y3
x4 x4
x5
TIPnla 1 TIPnla n
Fig 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).
CLIENTI FACTURI
Nume 0,n 1,1 Numar
Adresa VANZARE Data
Localitate Valoare
Cod_fiscal
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ăţi
38
1. Permite utilizatorilor să definească baza de date, de obicei printr-un limbaj de definire a
datelor (DDL). Limbajul DDL permite utilizatorilor specificarea tipurilor de date şi a
structurilor, în timp ce constrângerile asupra datelor sunt stocate în baza de date
2. Permite utilizatorilor să insereze, să reactualizeze, să şteargă şi să extragă date din baza de
date, de obicei printr-un limbaj de manipulare a datelor (DML). Faptul că există un
depozit central al tuturor datelor şi descrierilor acestora permite limbajului DML să ofere
o facilitate de interogare generală a acestor date, denumită limbaj de interogare. 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 date

Teoria ş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);
39
• 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.
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 date
Un 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 control
Acestea 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;
21
Saleh, I., Op. cit., p. 13
22
Ginguay, M., Lauret, A., Dictionnaire d’informatique, Ed. Masson, Paris, 1990, p. 215
40
• î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:
A d m i n i s tr a to r u l
U ti l i z a to r i
BD
P ro g ram e d e
S tr u c tu r a B D a p l i c a ¡i i
LDD LM D
PG BD
U t. î n tr e ¡i n e r e C o m p . c o n tr o l
SG B D
B aza
de
d a te
Fig. 2.20. Structura generală a unui SGBD
2.3.2 Funcţiile unui SGBD

Orice 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;
23
Fotache, M., Op. cit., p. 37
41
• 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.
Î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).
Program de
aplicaţie 1
Utilizator 1 Sistem
operare Sistem
(control operare
Program de SGBD (date)
Utilizator 2 comunicaţii)
aplicaţie 2
Baza de
Program de date
Utilizator n aplicaţie 3
Figura nr.2.21. Sistem cu teleprelucrare
24
Lungu, I., ş.a. Op. cit., p. 19
25
Sabău, Ghe., Op. cit., p. 18
42
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
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.
Program
aplicaţii 1
Utilizator 1 Sistem de
SGBD operare LAN
Program (reţea)
aplicaţii 2
Client 1
Program Sistem de Sistem de Sistem de

Utilizator 2 aplicaţii 2 SGBD operare operare operare BD
(reţea) (reţea) (date)
Client 2
.
. Server de fişiere
.
Program Sistem de
aplicaţii 2
operare
Utilizator N SGBD (reţea)
Program
aplicaţii 3
Client N
Figura nr. 2.22. Arhitectura fişier-server
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.
Program
aplicaţii 1 Sistem de
Utilizator 1 operare
(reţea)
Program
aplicaţii 2 LAN
Client 1
Sistem de
Program operare Sistem de Sistem de
Utilizator 2 aplicaţii 2 (reţea) operare SGBD operare
(reţea) BD
(date)
Client 2
.
.
.
Server de BD
Program
aplicaţii 2 Sistem de
Utilizator N operare
(reţea)
Program
aplicaţii 3
Client N
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;
45
• 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.
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ă:
46
• 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
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.

Prin 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);
26
Băduţ, M., O perspectivă asupra bazelor de date, PC Report nr.12/1998
47
• 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
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 date
Aceste 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).
48
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

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

Î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
49
- 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
- menţinerea contactului cu utilzatorii pentru a determina noile cerinţe şi a rezolva
dificultăţile privind accesul la date sau performanţele
Administratorul bazei de date este implicat în proiectarea fizică a bazei de date şi în
implementarea efectivă a acesteia pe suporturile fizice de memorare, în impunerea
standardelor de securitate şi 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
50
- 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
- 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


Modelul 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;
52
− mulţimea numelor atributelor unei relaţii (coloanelor unei tabele) împreună cu numele
relaţiei reprezintă o schemă a unei relaţii.
nume relatie
atribut
Obiecte-inventar
schema
relatiei
Cod-Furnizor Cod-ob-inv Den-ob-inv. UM PU Cantitate
211 311 Etajere buc 35 12

202 291 Scaune buc 95 10
211 321 Cuiere buc 47 5 tuplu
237 312 Dulapuri buc 450 4 n-tupluri
192 357 Salopete buc 50 14
213 345 Manusi buc 25 12
1
192 314 Ochelari buc 20 10
1
211 291 Birouri buc 1500 3
domeniu
valoarea
din domeniu
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.1
Formal Uzual Fizic
relaţie tabel (tabelă) Fişier
tuplu rând (linie) înregistrare
atribut coloană câ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
53
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.
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 unice
Regula 2: integritatea entităţii - atributul/atributele ce compun cheia primară trebuie
să aibă valori diferite de Null
Regula 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ŢI
Cod_client Nume_client Localitate Cod_fiscal
FACTURI_EMISE
Numă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
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
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ă).
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 La nivelul logic, toate informaţiile dintr-o bază de date
informaţiei relaţională sunt reprezentate explicit ca valori în tabele
R2 Regula accesului garantat Orice valoare a oricărui atribut din cadrul oricărei
la date 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 SGBD-ul asigură un suport sistematic pentru
informaţiei necunoscute tratamentul valorilor nule (date necunoscute sau
neaplicabile), diferit de valorile prestabilite şi
independent de orice domeniu
R4 Regula catalogului dinamic Descrierea bazei de date şi a componentelor sale este
on-line realizată la nivel logic sub formă de tabele, putând fi
interogată în timp real prin intermediul limbajului de
manipulare a bazei de date.
R5 Regula limbajului de Este obligatorie existenţa unui limbaj de manipulare a
interogare 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 Este obligatorie existenţa unui mecanism de
vederilor determinare a posibilităţii de actualizare sau nu a unei
tabele virtuale (vederi).
R7 Regula limbajului de nivel Limbajul de manipulare a datelor nu trebuie să
înalt conducă utilizatorul la explorarea relaţiilor tuplu cu
tuplu, pentru a regăsi datele dorite.
R8 Regula independenţei fizice Este necesar ca aspectele fizice ale stocării sau
a datelor accesului la date să fie separate de aspectele logice (de
organizare) ale datelor.
R9 Regula independenţei logice Este necesar ca modificările asupra datelor să nu
a datelor afecteze în nici un mod funcţionarea programelor de
aplicaţie şi nici operaţiile de manipulare a datelor.
R10 Regula independenţei Regulile de integritate a datelor trebuie să fie definite
datelor din punctul de în catalogul de sistem, independent de programele de
vedere al integrităţii aplicaţie.
R11 Regula independenţei Distribuirea datelor pe mai multe calculatoare din
datelor din punctul de cadrul unei reţele nu trebuie să afecteze programele de
vedere al distribuirii 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;
55
• 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;
• 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.

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şti
Relaţ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.
Reuniunea
Reuniunea 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 ∪ R2
Exemplu: Considerăm tebelele CLIENŢI1 şi CLIENŢI2.
Tabela CLIENŢI1
Nume_client Localitate Cod_fiscal
Alfa SRL Iaşi R19548710
Anca SRL Iaşi R19852553
Omega SA Roman R17466540
Star SRL Bacău R12586330
Amigo Srl Bacău R17256007
Select SRL Leţcani R17885330
Tabela CLIENŢI2
Gama SA Iaşi R19852201
Delta SRL Bacău R17256007
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:
56
Tabela CLIENŢI_NOI
Amigo SRL Bacău R17256007
Gama SA Iaşi R19852201
Delta SRL Bacău R17256007
Deci, CLIENŢI_NOI ← CLIENŢI1 ∪ CLIENŢI2
Din tabela CLIENŢI2 s-au preluat două tupluri, deoarece celelalte există deja în
tabela CLIENŢI1. Se elimină, deci, dublurile.
Intersecţia
Intersecţ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 ∩ R2
Exemplu: 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_COMUNI
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ţa
Diferenţ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 – R2
Exemplu: 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ŢI1
Amigo SRL Bacău R17256007
NUMAI_CLIENŢI1 ← CLIENŢI1 – CLIENŢI2
Diferenţ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 cartezian
Produsul 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.
57
Se notează R3 ← R1 x R2
Exemplu: Considerăm tabela CLIENŢI2 de mai sus şi tabela FACTURI.
Tabela FACTURI
Nr_factură Data Nume_client Val_factură
12540 12/02/07 Delta SRL 2300.08
15780 15/02/07 Gama SA 2564
47100 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ŢI
Clienţi2. Clienţi2 Clienţi2. Facturi. Facturi. Facturi. Facturi.
Nume_client Localitate Cod_fiscal Nr_factură Data Nume_client Val_factură
Alfa SRL Iaşi R19548710 12540 12/02/07 Delta SRL 2300.08
Alfa SRL Iaşi R19548710 15780 15/02/07 Gama SA 2564
Alfa SRL Iaşi R19548710 47100 17/02/07 Delta SRL 8790
Gama SA Iaşi R19852201 12540 12/02/07 Delta SRL 2300.08
Gama SA Iaşi R19852201 15780 15/02/07 Gama SA 2564
Gama SA Iaşi R19852201 47100 17/02/07 Delta SA 8790
Delta SRL Bacău R17256007 12540 12/02/07 Delta SRL 2300.08
Delta SRL Bacău R17256007 15780 15/02/07 Gama SA 2564
Delta SRL Bacău R17256007 47100 17/02/07 Delta SRL 8790
Omega SA Roman R17466540 12540 12/02/07 Delta SRL 2300.08
Omega SA Roman R17466540 15780 15/02/07 Gama SA 2564
Omega 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ţionali
Operatorii relaţionali se împart în:
 operatori unari de restricţie (selecţia şi proiecţia);
 operatori binari de extensie (joncţiunea şi diviziunea).
Selecţia
Selecţ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”)
58
Tabela R2 va arăta astfel:

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ţia
Proiecţ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
Localitate
Iaşi
Roman
Bacău
Leţcani
În tabela RR1 au fost eliminate valorile identice ale atributului Localitate.
RR2
Nume_client
Alfa SRL
Anca SRL
Omega SRL
Star SRL
Amigo SRL
Select SRL
În tabela RR2 numărul de linii este identic cu cel al tabelei CLIENŢI.
Joncţiunea
Joncţ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: < .> . > = . < = . ≠ .
59
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) R2
este 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.
Î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ŢI
Cod_client Nume_client Localitate
1000 Alfa SRL Iaşi
1001 Gama SA Iaşi
1002 Delta SRL Bacău
1003 Omega SA Roman
Tabela FACTURI
Nr_factură Data_factură Cod_client Valoare_factură
12540 12/02/07 1001 2300.08
15780 15/02/07 1001 2564
21630 10/02/07 1002 1256
47100 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. Clienţi Clienţi. Facturi. Facturi. Facturi. Facturi.
Cod_client Nume_client Localitate Nr_factur Data_factură Cod_client Valoare_factură
ă
1000 Alfa SRL Iaşi 47100 17/02/07 1000 8790
1001 Gama SA Iaşi 12540 12/02/07 1001 2300.08
1001 Gama Sa Iaşi 15780 15/02/07 1001 2564
1002 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)
Diviziunea
Este 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.
60
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 i ∈ Y ∈ R2 → ∃ (xi, yi) ∈ R1
Se notează R3 ← R1 ÷ R2
Tabela 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.
R1
X Y
X1 y1
X3 y1
X5 y1
X1 y2
X2 y2
X3 y2
X4 y2
X1 y3
X5 y3
X3 y3
X2 y3
X4 y3
R2
Y
Y1
Y2
Y3
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:
R3
X
X1
X3
Diviziunea nu este un operator fundamental, funcţionalitatea sa este obţinută prin
combinarea operatorilor produs cartezian, diferenţă şi proiecţie.

Dependenţele dintre atribute
Normalizarea 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.
61
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ă:
• 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 →Y
Se consideră tabela FACTURI.
FACTURI
Numă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_client
Număr_factură → Val_factură
Implicit, în orice relaţie R există dependenţele funcţionale:
cheia primară a lui R → celelalte atribute ale lui R
Dependenţ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ţiale

Dependenţ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) → Valoare
care este o dependenţă funcţională elementară.
Dependenţele:
(Număr_factură, Cod_cl) → Nume_cl
(Număr_factură, Cod_cl) → Localitate
nu 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→ Localitate
Dependenţa funcţională elementară se mai numeşte totală sau deplină.
Dependenţe funcţionale directe şi tranzitive

O 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.
62
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.
Considerăm o relaţie R{A1, A2, ..., Ai} şi N subansamble de atribute X 1, 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.

Necesitatea normalizării
Normalizarea 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_factura

10540 10/02/07 Delta SRL Iaşi R19548710 2300.08
10541 10/02/07 Gama SA Iaşi R19848451 2564
10542 11/02/07 Delta SRL Iaşi R19548710 8790
10543 12/02/07 Alfa SRL Vaslui R19852201 4356.08
10544 12/02/07 Diana SRL Paşcani R19674531 3564
10545 12/02/07 Popa SNC Iaşi R12323432 1790
10546 12/02/07 Omega SRL Bacău R17256007 1300.08
28
Filip, M., Grama, A., Medii de programare. Abordări teoretice, Ed. Fides, Iaşi, 1998, p.204
63
10547 13/02/07 Iulius SRL Iaşi R19456700 3564
10548 14/02/07 Toni SRL Bacău R18790654 3650
10549 14/02/07 Anca SRL Roman R17466540 4100.080
10550 15/02/07 Select SA Bacău R13666589 3864
10551 15/02/07 Anca SRL Roman R17466540 3290
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ţionale

Teoria 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.
1F N
2F N DF
3F N
BCNF
4F N DM V
5F N DJ
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).
29
Codd, E.F., Further normalization of the database relational model, DataBase Systems, Courant
Computer Science Symposia Series, Vol.6, Englewood Cliffs, N.J.,Prentice-Hall, 1972
30
Filip, M., Grama, A., Op. cit., p.205
64
Î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.
Î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 X→Y şi X→Z, 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:
FACT
Nr_fact Data Cod_cl Val
CL
Cod_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.
65
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ă
Cod_post → Localitate
Cod_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:
CLIENTI
Cod_cl Nume_client Cod_post
CODP
Cod_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ţe
4.2. Comenzi pentru descrierea datelor;
4.3. Comenzi pentru interogarea bazelor de date
4.4. Comenyi pentru actualizarea bazei de date
4.1. Evoluţie şi performanţe

SQL 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ă;
68
• Furnizează răspunsuri la numeroase interogări simple, ad-hoc, neprevăzute
iniţial;
• 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
69
• 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:
Tabelul nr. 4.1. Clase de comenzi SQL

Comandă Scop
Pentru manipularea datelor
SELECT Extragerea datelor din baza de date
INSERT Adăugarea de noi linii într-o tabelă
DELETE Ştegerea de linii dintr-o tabelă
UPDATE Modificarea valorilor unor atribute
Pentru definirea bazei de date
CREATE TABLE Adăugarea unei noi tabele în baza de date
DROP TABLE Ştergerea unei tabele din bază
ALTER TABLE Modificarea structurii unei tabele
CREATE VIEW Crearea unei tabele virtuale
DROP VIEW Ştergerea unei tabele virtuale
Pentru controlul accesului la BD

GRANT Acordarea unor drepturi pentru utilizatori
REVOKE Revocarea unor drepturi pentru utilizatori
Pentru controlul tranzacţiilor
COMMIT Marchează sfârşitul unei tranzacţii
ROLLBACK Abandonează tranzacţia în curs
4.2. Comenzi pentru descrierea datelor

Comanda SQL utilizată pentru crearea unei tabele este CREATE TABLE. Aceasta
creează o tabelă vidă (fără linii), cu o anumită structură.
CLIENŢI
CodClient NumeClient Adresa Localitate
1001 TEXTILA SA Bld. Copou, 87 Iaşi
1002 MODERN SRL Bld. Gării, 22 Focşani
1003 OCCO SRL NULL Iaşi
1004 FILATURA SA Bld. Unirii, 145 Focşani
1005 INTEGRATA SA I.V.Viteazu, 115 Paşcani
1006 AMI SRL Galaţiului, 72 Bacău
1007 AXON SRL Silvestru, 2 Iaşi
1008 ALFA SRL Prosperităţii, 15 Paşcani
FACTURIEMISE
NrFactură CodClient DataFactură ValoareTotală TVAColectată
111111 1003 17.06. 2007 1700 271.42
111112 1001 17.06.2007 285 45.5
111113 1004 18.06.2007 585 93.4
111114 1003 18.06.2007 2850 455.04
111115 1008 18.06.2007 3570 570
111116 1008 19.06.2007 870 138.9
70
111117 1006 20.06.2007 1100 175.63
111118 1007 23.06.2007 1500 239.49
111119 1005 24.06.2007 4725 754.41
111120 1003 24.06.2007 300 47.89
111121 1001 24.06.2007 425 67.85
111122 1007 24.06.2007 875 139.7
111123 1006 25.06.2007 660 105.3
111124 1004 25.06.2007 3850 614.7
111125 1003 30.06.2007 1280 204.37
111126 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ŢI
ADD 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)
71
Ş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
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, ..., Cn
FROM R1, R2, ..., Rm
WHERE 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ţie
WHERE…
Î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, ..., Cn
FROM R1, R2, ..., Rm
WHERE P
În concluzie, o frază SELECT, în forma în care a fost prezentată, corespunde:
• unei selecţii algebrice (clauza WHERE - P)
72
• 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
• 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 ValoareFaraTVA
FROM 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.58
111112 239.50
111113 491.6
111114 2394.96
111115 3000
111116 731.1
111117 924.37
111118 1260.51
111119 3970.59
111120 252.11
111121 357.15
111122 735.3
111123 554.7
111124 3235.3
111125 1075.63
111126 4558.83
Fig. nr. 4.2. Exemplu de câmp calculat (ValoareFaraTVA)
Interogări care utilizează operatorii asamblişti din algebra relaţională

Reuniunea
SELECT *
FROM R1
UNION
SELECT *
FROM R2
Operatorul pentru reuniune este deci UNION. De remarcat că, la reuniune, SQL elimină
automat dublurile, deci nu este necesară utilizarea clauzei DISTINCT. Operatorul UNION
este prezent în toate SGBD-urile importante.
Intersecţia
Pentru realizarea intersecţiei a două tabele, R1 şi R2 se utilizează operatorul
INTERSECT:
SELECT *
73
FROM R1
INTERSECT
SELECT *
FROM R2
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 R1
MINUS
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 FACTURIEMISE
WHERE DataFactură > {23.06.2007} AND ValoareTotala > 3000
Rezultat:
111119 1005 24.06.2007 4725 754.41
111124 1004 25.06.2007 3850 614.7
111126 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 BETWEEN
Acest 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 2
Care 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:
74
SELECT *
FROM FACTURIEMISE
WHERE DataFactură > {23.06.2007} AND
ValoareTotala >= 3000 AND ValoareTotala <= 4000
Utilizând operatorul BETWEEN se poate scrie:
SELECT *
FROM FACTURIEMISE
WHERE DataFactură > {23.06.2007} AND ValoareTotala BETWEEN
3000 AND 4000
Operatorul LIKE
Acest 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 3
Care 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ŢI
WHERE NumeClient LIKE "A__ SRL"
Rezultat:
CodClien NumeClient Adresa Localitate
t
Exemplul 4
Dacă în exemplu 3 s-ar fi utilizat simbolul "%":
SELECT *
FROM CLIENŢI
WHERE NumeClient LIKE "A%SRL",
am fi obţinut:
Rezultat:
1008 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, ...)
75
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 5
Care sunt clienţii din Iaşi şi Bacău ?
Fără utilizarea operatorului IN se scrie:
SELECT *
FROM CLIENTI
WHERE Localitate= "Iaşi" OR Localitate= "Bacău”
Utilizând operatorul IN:
SELECT *
FROM CLIENTI
WHERE Localitate IN ("Iaşi", "Bacău)
Rezultat
1001 TEXTILA SA Bld. Copou, 87 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 6
Dacă se doreşte aflarea clienţilor pentru care nu s-a introdus adresa, se poate scrie:
SELECT *
FROM CLIENTI
WHERE Adresa IS NULL
Rezultat:
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 BY

Coloanele 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 ?
76
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 Localitate
FROM CLIENTI
Rezultat:
Localitate
Iaşi
Focşani
Bacău
Paşcani
Prezentarea localităţilor în ordinea alfabetică a numelui acestora este posibilă apelând la

clauza ORDER BY.
SELECT Localitate
FROM CLIENTI
ORDER 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ţiunea
SQL 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, Localitate
FROM FACTURIEMISE, CLIENŢI
WHERE FACTURIEMISE.CodClient = CLIENŢI.CodClient
AND Localitate=”Iaşi”
sau
SELECT NrFactura, NumeClient, Localitate
FROM FACTURIEMISE INNER JOIN CLIENŢI
ON WHERE FACTURIEMISE.CodClient = CLIENŢI.CodClient
WHERE Localitate=”Iaşi”
Rezultat:
NrFactură NumeClient Localitate
111111 OCCO SRL Iaşi
111112 TEXTILA SA Iaşi
111118 AXON SRL Iaşi
111121 TEXTILA SA Iaşi
77
111122 AXON SRL Iaşi
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 1
Care sunt facturile emise în aceeaşi zi în care a fost întocmită factura 111114 ?
SELECT *
FROM FACTURIEMISE
WHERE DataFactură IN
(SELECT DataFactură
FROM FACTURIEMISE
WHERE NrFactură=111114)
Observaţie
Sub-consultarea
SELECT DataFactură
FROM FACTURIEMISE
WHERE 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:
111113 1004 18.06.2007 585 93.4
111114 1003 18.06.2007 2850 455.04
111115 1008 18.06.2007 3570 570
Exemplul 2
Care sunt facturile emise în alte zile decât cea în care a fost întocmită factura 111114 ?
SELECT *
FROM FACTURIEMISE
WHERE DataFactură NOT IN
FROM FACTURIEMISE
S-a utilizat negaţia, testându-se non-apartenenţa la o relaţie creată printr-o sub-frază
SELECT.
Exemplul 3
Care sunt clienţii cărora li s-au trimis facturi întocmite în aceeaşi zi cu factura 111114 ?
SELECT DISTINCT NumeClient
78
FROM CLIENŢI
WHERE CodClient IN
(SELECT CodClient
FROM FACTURIEMISE
WHERE DataFactură IN
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 NumeClient

FROM CLIENŢI, FACTURIEMISE
WHERE CLIENŢI.CodClient=FACTURIEMISE.CodClient
AND DataFactură IN
FROM FACTURIEMISE
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ăN
FROM listă-tabele
WHERE 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_Clienti
FROM 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 CLIENTI
WHERE CodClient IN
(SELECT CodClient
79
FROM FACTURIEMISE)
Rezultatul corect poate fi însă obţinut şi prin utilizarea clauzei DISTINCT astfel:
SELECT COUNT (DISTINCT CodClient)
FROM FACTURIEMISE
Funcţia SUM calculează suma valorilor unei coloane.
Exemplul 3
Care este valoarea totală a facturilor emise ?
SELECT SUM (ValoareTotala) AS Total_FE
FROM FACTURIEMISE
Rezultat:
Total_FE
30000
Exemplul 4
Care este totalul valorii facturilor trimise clientului AXON SRL ?
SELECT SUM (ValoareTotala) AS Total_FE_AXON
FROM FACTURIEMISE, CLIENTI
WHERE FACTURIEMISE.CodClient = CLIENTI.CodClient
AND NumeClient = "AXON SRL"
Funcţiile MAX şi MIN determină valorile maxime, respectiv minime ale unei coloane
în cadrul unei tabele.
Exemplul 5
Care este cea mai mică valoare a unei facturi emise ?
SELECT MIN(ValoareTotala) AS ValMinima
FROM FACTURIEMISE
Rezultat
ValMinima
285
Exemplul 6
Care este factura emisă ce are cea mai mare valoare ?
SELECT NrFactură, ValoareTotala
FROM FACTURIEMISE
WHERE ValoareTotala = (SELECT MAX (ValoareTotala)
FROM FACTURIEMISE)
Rezultat:
NrFactura ValoareTotala
111126 5425
Gruparea tuplurilor. Clauzele GROUP BY şi HAVING

SQL 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.
80
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
FROM tabelă
GROUP BY coloană-de-regrupare
Exemplu 1
Care este totalul zilnic al valorii facturilor emise ?
SELECT DataFactură, SUM (ValoareTotala)
FROM FACTURIEMISE
GROUP BY DataFactură
În acest caz tabela-rezultat va avea un 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 TVAColectata

111111 1003 17.06.2007 1700 271.42
111112 1001 17.06.2007 285 45.5
111113 1004 18.06.2007 585 93.4
111114 1003 18.06.2007 2850 455.04
111115 1008 18.06.2007 3570 570
111116 1008 19.06.2007 870 138.9
111117 1006 20.06.2007 1100 175.63
111118 1007 23.06.2007 1500 239.49
111119 1005 24.06.2007 4725 754.41
111120 1003 24.06.2007 300 47.89
111121 1001 24.06.2007 425 67.85
111122 1007 24.06.2007 875 139.7
111123 1006 25.06.2007 660 105.37
111124 1004 25.06.2007 3850 614.7
111125 1003 30.06.2007 1280 204.36
111126 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 TVAColectata
111111 1003 17.06.2007 1700 271.42
111112 1001 17.06.2007 285 45.5
111113 1004 18.06.2007 585 93.4
111114 1003 18.06.2007 2850 455.04
111115 1008 18.06.2007 3570 570
111116 1008 19.06.2007 870 138.9
111117 1006 20.06.2007 1100 175.63
111118 1007 23.06.2007 1500 239.49
111119 1005 24.06.2007 4725 754.41
111120 1003 24.06.2007 300 47.89
111121 1001 24.06.2007 425 67.85
81
111122 1007 24.06.2007 875 139.7
111123 1006 25.06.2007 660 105.37
111124 1004 25.06.2007 3850 614.7
111125 1003 30.06.2007 1280 204.36
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 1985
18.06.2007 7005
19.06.2007 870
20.06.2007 1100
23.06.2007 1500
24.06.2007 6325
25.06.2007 4510
30.06.2007 1280
01.07.2007 5425
Exemplul 2
Care este numărul facturilor emise pentru fiecare client ?
SELECT NumeClient, COUNT(NrFactură)
FROM FACTURIEMISE, CLIENTI
WHERE FACTURIEMISE.CodClient=CLIENTI.CodClient
GROUP BY FACTURIEMISE.CodClient
Observaţie
Pâ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ă m
FROM tabelă
GROUP BY coloană-de-regrupare
HAVING caracteristică-de-grup
Exemplul 3
Pentru 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 FACTURIEMISE
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)
82
18.06.2007 7005
24.06.2007 6325
01.07.2007 5425
Exemplul 4
Să se afişeze ziua în care s-au întocmit cele mai multe facturi.
SELECT DataFactură
FROM FACTURIEMISE
HAVING COUNT(*) >= ALL
(SELECT COUNT(*)
FROM FACTURIEMISE
GROUP BY DataFactură)
Exemplul 5
Care sunt clienţii pentru care s-au întocmit numai două facturi?
SELECT NumeClient
FROM CLIENTI INNER JOIN FACTURIEMISE
ON CLIENTI.CODCLIENT=FACTURIEMISE.CODCLIENT
GROUP BY NumeClient
HAVING COUNT(NrFactura)=2
sau
SELECT NumeClient
FROM CLIENTI
WHERE CodClient IN
(SELECT CodClient
FROM FACTURIEMISE
GROUP BY CodClient
HAVING COUNT(NrFactura)=2)
Exemplu 6
Care sunt zilele în care s-au întocmit cel puţin trei facturi?
SELECT DataFact , Count(*) as Nr
FROM FacturiEmise
GROUP BY DataFact
HAVING COUNT(*)>=3
5.4. Comenzi pentru actualizarea bazelor de date

SQL prezintă comenzi specifice pentru modificarea 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ări
Adă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 1
83
Să 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:
INSERT
INTO CLIENŢI
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:
INSERT
INTO 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:
INSERT
INTO CLIENŢI
VALUES (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ărilor
Operaţ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 2
Să se elimine din tabela CLIENŢI linia aferentă clientului MODERN SRL (cod 1002).
DELETE
FROM CLIENŢI
WHERE CodClient = 1002
Exemplu 3
Să se şteargă datele referitoare la facturile emise clienţilor din oraşul Focşani.
DELETE
FROM FACTURIEMISE
WHERE 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,
84
ValoareTotala decimal (15) not NULL,
TVAColectata decimal (14) ,
PRIMARY KEY (NrFactură),
FOREIGN KEY (CodClient) REFERENCES CLIENŢI
ON DELETE RESTRICT)
Modificarea valorilor unor atribute

Pentru modificarea valorilor unuia sau mai multor atribute dintr-o tabelă, comanda
utilizată este UPDATE care are formatul general:
UPDATE tabelă
SET atribut = expresie
WHERE predicat
Ca rezultat, vor fi modificate valorile atributului specificat, noile valori ale acestuia fiind
cele care rezultă în urma evaluării expresiei; modificarea se va produce pe toate liniile tabelei
care îndeplinesc condiţia specificată în predicat.
Exemplul 4
Noua adresă a clientului Modern SRL este “Bulevardul Victoriei nr. 21”. Să se opereze
modificarea în baza de date.
Se actualizează atributul Adresa din tabela Clienţi.
UPDATE CLIENŢI
SET Adresa=“Bulevardul Victoriei nr. 21”
WHERE NumeClient=”Modern SRL”
85
Bibliografie
1. Airinei, D., ş.a., Modele de aplicaţii practice în Microsoft Excel şi Visual FoxPro,
Editura Sedcom Libris, Iaşi, 2003
2. Bazian, Menachem, Totul despre Visual FoxPro 6.0, Editura Teora, Bucureşti,
2001
3. Bâscă, O., Baze de date, Editura All, Bucureşti, 1997
4. Bot, Ed, Leonhard, Woody, Microsoft Office XP, traducere de Simona şi Titi
Preda, Editura Teora, Bucureşti, 2003
5. Conolly, T., Begg, C., Strachan, A., Baze de date,. Proiectare, implementare,
gestionare, Editura Teora, Bucureşti, 2001
6. Florescu, V., ş.a., Baze de date, Editura Economica, Bucureşti, 1999
7. Forta, B., SQL în lecţii de 10 minute, traducere de Mihai Mănăstireanu, Editura
Teora, Bucureşti, 2007
8. Fotache, M., Baze de date relaţionale. Organizare, interogare şi normalizare,
Editura Junimea, Iaşi, 1997
9. Fotache, M., SQL. Dialecte DB2, Oracle, Visual FoxPro, Editura Polirom, Iaşi,
2001
10. Fotache, M., Proiectarea bazelor de date. Normalizare, postnormalizare, Editura
Polirom, Iaşi, 2005
11. Fotache, M., Brava, I., Strîmbei, C., Creţu, L., Visual FoxPro. Ghidul dezvoltării
aplicaţiilor profesioanle, Editura Polirom, Iaşi, 2002
12. Hernandez, M. J., Proiectarea bazelor de date, Editura Teora, Bucureşti, 2003
13. Lungu, I. şi colectiv, Baze de date. Organizare, proiectare şi implementare,
Editura ALL, Bucureşti, 1995
14. Melnic, A., Medii de programare, Editura TehnoPress, Iaşi, 2005
15. Miloşescu, M., Baze de date în Visual FoxPro, Editura Teora, Bucureşti, 2003
16. Năstase, P., Tehnologia bazelor de date, Access 2000, Editura Economică,
Bucureşti, 2000
17. Oppel, A., SQL fără mistere, traducere de Cristian Mocanu, Florin Moraru,
Editura Rosetti Educational, Bucureşti, 2006
18. *** Microsoft Office, Access 2003, traducere de Cristian
Mocanu, Editura Teora, Bucureşti, 2004
86

SUPo RT CURSBAZEDEDATE2007

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SUPo RT CURSBAZEDEDATE2007

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA “GEORGE BACOVIA” BACĂU

Conf. univ. dr. Andreia Melnic

Capitolul 1. INTRODUCERE IN STUDIUL LIMBAJELOR DE PROGRAMARE…….

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

Capitolul 3. MODELUL RELAŢIONAL AL DATELOR………………………………52

Capitolul 4. LIMBAJE DE INTEROGARE A BAZELOR DE DATE – SQL………….67

1.1. Noţiuni generale privind limbajele de programare

1.1. Noţiuni generale privind limbajele de programare

pe baza analizei instrucţiuni Rezultat

Scrie Program Traducere automată

Reguli şi restricţii ale

1.2. Clasificarea limbajelor de programare

Limbajele de asamblare permit utilizarea de abrevieri alfabetice (mnemonice) care

Fig.1.3. Tratarea programelor în limbaje evoluate

Tendinţe majore în software

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

limbaje în limbaje de limbaje de limbaje de limbaje

O altă clasificare a limbajelor de programare a fost realizată de J.E. Sammet într-o

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

1.3.1 Concepte utilizate în organizarea datelor

Z. ARTICOL COD DEN UM CANT PREº VALOARE

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

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

1.5. Criterii de selecţie a limbajelor de programare

Sistemele de baze de date reprezintă cea mai importantă dezvoltare în domeniul

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

2.1.1. Metoda prelucrării prin fişiere independente

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

2.1.2. Baze de date

Fişier de date 2 Dicţionar

Aplicaţia 1 Aplicaţia 2 ... Aplicaţia m

Fig. nr .2.2. Structura unei baze de date

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

Utilizator A1 Utilizator A2 Utilizator B1 Utilizator B2 ...

Aplicaţie Comenzi Comenzi ….

Schema Imagine A Schema

Schema conceptuală Imagine globală Sistem de

Fig. nr.2.3. Nivele de abstractizare a datelor în bazele de date

2.1.3. Bănci de date

Fig.2.4. Structura unei bănci de date

2.1.4. Depozite de date

2.1.5. Proiectarea bazelor de date

Analiza preliminară şi identificarea cerinţelor informaţionale

Proiectarea structurii bazei de date

Proiectarea schemei externe

Proiectarea schemei interne

Încărcarea datelor în baza de date

Exploatarea şi întreţinerea bazei de date

2.2 MODELE CONCEPTUALE DE STRUCTURARE ŞI ORGANIZARE A

Tipuri de relaţii şi structuri de reprezentare a relaţiilor în cadrul unei baze de date

Fig. 2.6 Relaţii de tip 1-n

Fig. 2.7. Relaţia n-1

• n-m (mai-multe-la-mai-multe) în care unei realizări din domeniu îi corespund 0,

2.2.2 Modele de organizare a datelor în bazele de date

FURNIZORI Cumparare FACTURI-PRIMITE

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

Factura 1 Factura 2 Factura 3

Fig. nr.2.11. Modelul ierarhic

Modelul reţea este o dezvoltare a modelului ierarhic. Înregistrările sunt privite în

Factura 1 Factura 2 Factura 3