ROMÂNIA

MINISTERUL EDUCAŢIEI, CERCETĂRII ŞI

TINERETULUI
UNIVERSITATEA din BACĂU
FACULTATEA DE ŞTIINŢE
Str. Spiru Haret, nr. 8, Bacău, 600114
Tel. ++40-234-542411, tel./ fax ++40-234-516345
www.ub.ro; e-mail: stiinte@ub.ro

BAZE DE DATE   
Conf. univ.dr. ELENA NECHITA
Lector univ. dr. GLORIA-CERASELA CRIŞAN

2008
 Prezentarea cursului

Informaţiile din lumea ce ne înconjoară sunt structurate în diverse moduri.

Adesea structura o impunem sau o chiar inventăm noi în procesul de memorare, în
încercarea de a transforma informaţiile cu care suntem bombardaţi în cunoştinţe.
Sistemul de structurare a datelor care intervine cel mai frecvent este tabelul, iar în
cazul volumelor mari vorbim despre baze de date.
Procesul de instruire în societatea noastră tot mai informatizată, în aşa numita
Societate Informaţională, impune tot mai mult structurarea cunoştinţelor acumulate,
capacitatea de a le organiza, clasifica, regăsi şi mai ales completa. Vorbim despre
managementul cunoştinţelor, un capitol important atât al ontologiei, cât şi al
informaticii. Putem spune că disciplina "Baze de Date" se ocupă cu câteva din
mecanismele de gestiune a informaţiilor şi a cunoştinţelor.
Căutările pe World Wide Web, modul în care apelăm la motoarele de căutare
şi modul în care acestea lucrează şi au fost concepute, toate au de a face cu
conceptele şi procedeele de lucru cu Baze de Date. Motoarele de căutare sunt, în
fond, nişte instrumente de căutare a informaţiilor într-o imensă bază de date, care
este actualizată continuu, pe măsură ce apar noi pagini Web. Marile motoare de
căutare, Google sau Yahoo, folosesc adevărate "ferme" de servere pe care menţin
aceste imense baze de date, astfel încât noi să obţinem răspunsul în câteva clipe.
Acest curs are drept scop prezentarea elementelor fundamentale despre
baze de date, a conceptelor cu care se lucrează în acest domeniu şi a modalităţilor
de prelucrare a datelor organizate în baze de date.

4
 Obiectivele cursului

Principalele obiective ale cursului sunt:

1. Însuşirea cunoştinţelor de bază referitoare la modul de proiectare şi de
programare a bazelor de date.
2. Familiarizarea cu modelul Entitate/Asociere şi cu modelul relaţional.
3. Studiul algebrei relaţionale, ca suport pentru prelucările realizate în baze de date
relaţionale.
4. Studiul dependenţelor funcţionale şi al formelor normale, în scopul optimizării
stocării datelor în bazele de date.
5. Prezentarea unor noţiuni referitoare la limbajele utilizate în domeniul bazelor de
date.
Sunt necesare cunoştinţe anterioare de matematică, programarea calculatoarelor,
structuri de date şi algoritmi, limbaje de programare (C, C++).

Cerinţe de examinare
Pentru evaluare se vor realiza următoarele activităţi:

1. Însuşirea cunoştinţelor teoretice din suportul de curs.

2. Participarea la orele de laborator. Se vor da două teste, în săptămânile a 7-a şi
a 13-a. Este necesar ca la fiecare să se obţină cel puţin nota 5.
3. Se va realiza un proiect, individual sau în echipă.
4. Examenul va consta într-un test de verificare a cunoştinţelor teoretice.
5. Nota acordată va fi media notelor obţinute la teste, la proiect şi la test.

5
 CUPRINS

Prezentarea cursului 3
Obiectivele cursului. Cerinţe de examinare 4

1. Introducere în domeniul bazelor de date 7

1.1 Informaţii. Date. Colecţii de date 7
1.2 Organizări ale datelor 9
1.2.1 Organizarea datelor în fişiere 9
1.2.2 Organizarea datelor în baze de date 11
1.3 Conceptul de bază de date 11
1.4 Sisteme de gestiune a bazelor de date 12

2. Niveluri de reprezentare a unei baze de date 14

2.1 Modelarea conceptuală 14
2.1.1 Modelul Entitate - Asociere 14
2.1.2 Diagrama Entitate - Asociere 16
2.2. Modele de date 16
2.2.1 Modelul ierarhic 16
2.2.2 Modelul reţea 17

3. Modelul relaţional 19
3.1 Conceptele modelului relaţional 20
3.2 Sisteme de gestiune a bazelor de date relaţionale 21

4. Noi funcţionalităţi ale bazelor de date 22

4.1 Partajarea bazelor de date 22
4.2 Baze de date distribuite 22
4.3 Baze de date deductive 24
4.4 Baze de date multidimensionale 24
4.5 Baze de date orientate obiecte 24
4.6 Alte tipuri de baze de date 26
4.7 Sisteme Client / Server 26
4.8 Bazele de date şi sistemele informaţionale din organizaţii 27

5. Forme normale. Normalizare 29

5.1 Dependenţe funcţionale 29
5.1.1 Descompunerea 29
5.1.2 Asocierile şi proiectarea schemelor 30
5.2 Dependenţe multivaloare 30
5.3 Forme normale ale bazelor de date 31
5.3.1. Date ne-normalizate 31
5.3.2 Prima formă normală (FN1) 32
5.3.3 A doua formă normală (FN2) 32
5.3.4 A treia formă normală (FN3) 33
5.3.5 Forma normală Boyce-Codd (FNBC) 34
5.3.6 A patra formă normală (FN4) 34
5.3.7 A cincea formă normală (FN5) 35
5.3.8. Procesul normalizării relaţiilor 36

6
6. Limbaje utilizate în lucrul cu baze de date 37
6.1 Limbajul de definire a datelor pentru modelul relaţional 37
6.2 Limbajul de manipulare a datelor pentru modelul relaţional 38
6.2.1 Algebra Relaţională 38
6.2.2 SQL 42
6.2.3 Calculul Relaţional orientat pe tupluri 42
6.2.4 Calculul Relaţional orientat pe domenii 43

7. Restricţiile de integritate ale modelului relaţional 44

7.1 Restricţii de integritate minimale 44
7.2 Alte restricţii de integritate 45
7.3 Aspecte privind integritatea 46

8. Depozite de date (Data warehouse) 47

8.1. Concepte de bază în data warehouse 47
8.2. Diferenţe înte bazele de date şi depozitele de date 48
8.3. Arhitectura depozitelor de date 49

9. Baze de cunoştinţe 54

10. Aplicaţii Access 56

10.1. Bază de date pentru activităţi şcolare 56
10.2. Bază de date pentru o activitate comercială 74
10.3. Bază de date pentru gestiunea unui parc auto 85
10.4. Bază de date pentru contabilitatea TVA 99

11. Teste 111

11.1 Testul 1 111
11.2 Testul 2 113
11.3 Testul 3 115
11.4 Testul 4 117
11.5 Testul 5 120
11.6 Testul 6 122
11.7 Testul 7 124

Bibliografie 125

7
 „Order is not sufficient.
What is required, is something
much more complex.
It is order entering upon novelty;
so that the massiveness of order
does not degenerate into mere repetition;
and so that the novelty
is always reflected
upon a background of system.''
(Alfred North Whitehead)

1. Introducere în domeniul bazelor de date

1.1 Informaţii. Date. Colecţii de date

Informaţiile şi cunoştinţele au o mare importanţă, atât pentru dezvoltarea

personalităţii umane, cât şi pentru evoluţia vieţii şi societăţii. Nici societatea şi nici indivizii ei
nu pot progresa satisfăcător în lipsă de informaţii. Prin intermediul informaţiilor se asigură
transferul cunoştinţelor de la o generaţie la alta, se asigură accesul la cele mai avansate
realizări ale omenirii.
Conceptul de informaţie reprezintă o noţiune de maximă generalitate care semnifică
o comunicare, o veste, o ştire, un mesaj, un semnal etc. despre evenimente, fapte, stări,
obiecte, despre forme de manifestare a realităţii care ne inconjoară. Informaţia reprezintă
cantitatea de noutate adusă de un mesaj din lumea reală.
Informaţia, energia şi materia sunt cei mai importanţi factori ai economiei moderne pe
lângă pământ, capital şi forţa de muncă. Faţă de materie, informaţia prezintă caracteristici
distincte:
• Se poate combina aproape nelimitat.
• Este puternic condensabilă.
• Se percepe ca o anumită măsură a ordinii, întrucât ea anihilează incertitudinea şi
nedeterminarea. O măsură a ordonării este entropia negativă, tremen care a luat
naştere prin analogie cu entropia, care este, în termodinamică, o măsură (exprimabilă
matematic) a neordonării.
• Calitatea unei informaţii constă în gradul de probabilitate cu care creează utilizatorului
certitudinea unei afirmaţii.
Oamenii ajung la informaţii direct, prin intermediul altor oameni sau prin purtători de
informaţie, precum ziare, cărţi, imagini, videocasete, CD-uri, discuri sau echipamente de
comunicaţie (radio, televizor, fax, telefon sau calculator).
Deci informaţia reprezintă o componentă esenţială a lumii reale, ce face posibilă
caracterizarea diferitelor elemente ale naturii (fiinţe, obiecte, stări, fenomene) şi permite
comunicarea.
Din punct de vedere conceptual, informaţia reprezintă o reflectare în planul gândirii
umane a legăturilor de cauzalitate, privind aspecte din realitatea ce ne înconjoară. Informaţia
are deci sens de noutate pentru cel căruia i se adresează, indiferent de forma pe care o ia
(ştire, semnal, comunicare). Putem spune deci că informaţia este un mesaj, dar cu precizarea
că nu orice mesaj este o informaţie. Dacă mesajul nu transmite o noutate şi nu are suport
real, atunci nu prezintă interes pentru receptor şi deci nu are caracter de informaţie.
Informaţia primeşte totdeauna atributul domeniului pe care îl reprezintă. De exemplu,
realităţile din domeniul economic se reflectă în informaţii economice.
Procesul de sesizare, înţelegere şi însuşire a informaţiilor dintr-un anumit domeniu
reprezintă un proces de informare. Informaţiile dobândite în urma unui proces de informare
într-un anumit domeniu formează cunoştinţele despre acel domeniu, iar mulţimea acestora
reprezintă baza de cunoştinţe.
Cunoştinţele reprezintă deci o însumare a tuturor informaţiilor dobândite într-un
anumit domeniu, sau care se referă la un anumit obiect. În sinteză, putem aprecia

8
cunoştinţele că sunt elemente abstracte şi individuale despre obiectele şi domeniile lumii
reale, însuşite şi/sau dobândite.
Aproape orice activitate are şi o latură informaţională. De exemplu, în paralel cu
procesul de producere de bunuri şi servicii se desfăşoară şi un proces informaţional,
constând din fluxuri de documente prin care se ţine evidenţa activităţii desfăşurate.
Atunci când informaţia este gestionată cu ajutorul tehnicii de calcul, ea devine dată.
Data este forma de reprezentare accesibilă a informaţiei prelucrate. Ea reprezintă
suportul formal al informaţiei, care se concretizează în: cifre, litere, simboluri, coduri şi alte
însemne. Există o corespondenţă determinată între informaţie, simbol şi dată astfel că, foarte
adesea, în practică, termenul de informaţie este utilizat pentru a desemna date, iar expresia
„prelucrarea informaţiilor” înlocuieşte expresia „prelucrarea datelor”. Putem considera că
datele prelucrate, în măsura în care afectează în sens pozitiv comportamentul receptorilor
(oameni sau maşini), au calitatea de informaţii.
În procesul prelucrării şi utilizării informaţiilor, acestea sunt privite din patru puncte de
vedere:
• Din punct de vedere sintactic, atunci când se urmăreşte aspectul admisibil al
acestora, în sensul că informaţiile trebuie să capete anumite forme de reprezentare, ce
respectă riguros anumite reguli.
• Din punct de vedere semantic, urmărindu-se semnificaţia, înţelesul informaţiei
(conţinutul real al informaţiei) ce derivă din datele prelucrate.
• Din punct de vedere pragmatic, urmărindu-se utilitatea pentru receptori, efectul
asupra acestora (măsura în care acestea satisfac cerinţele utilizatorului).
• Din punct de vedere sigmatic, se tratează raportul dintre semne şi obiecte, caz
în care se poate vorbi despre cunoştinţe obiective. În locuri publice, semnalizarea şi
direcţionarea cu ajutorul indicatoarelor trebuie să fie atât sugestivă, compactă, cât şi
independentă de limbă sau cultură. Pictogramele pentru indicarea cabinelor telefonice,
zonelor de fumători, ghişeelor de informaţii sau punctelor medicale reprezintă cunoştinţe
obiective.
Datele reprezintă aşadar informaţii care fac obiectul prelucrării pe sistemele de calcul
şi pot fi:
• Elementare (numite şi simple sau scalare) – atunci când sunt indivizibile în
raport cu prelucrările la care pot fi supuse.
• Compuse (numite şi complexe) – atunci când sunt alcătuite din mai multe
date elementare, deci sunt la rândul lor divizibile în date mai simple.
Exemplu. În cazul unei persoane: vârsta, înălţimea, greutatea, codul numeric personal sunt
date elementare. Domiciliul (format din oraş, stradă, număr) este o dată compusă.
Observaţie. O dată poate fi considerată elementară dintr-un punct de vedere şi compusă din
altul, aceasta în funcţie de prelucrările necesare.
Unei date i se atribuie un nume – identificatorul său, prin intermediul căreia ea se
distinge de celelalte şi prin care poate fi adresată. O caracteristică de bază a unei date este
tipul său. Acesta determină modul în care data respectivă va fi memorată pe suporturi de
memorare şi modul în care ea va fi prelucrată (adică operatorii şi funcţiile ce i se pot aplica).
În cadrul unui limbaj de programare, de exemplu, există o serie de tipuri de date de bază
(elementare), prestabilite de către proiectanţii limbajului şi, de cele mai multe ori, există
posibilitatea definirii de noi tipuri, prin combinarea celor elementare. Marea majoritate a
limbajelor permit manipularea datelor numerice (întregi şi reale), a caracterelor şi şirurilor de
caractere, a tablourilor uni- şi multi-dimensionale.
O colecţie de date reuneşte date despre o anume clasă de obiecte (reale sau
conceptuale).
Exemplu. Colecţia de date prezentată mai jos reuneşte date cu privire la clasa de obiecte
denumită CONTURI:

Cod_cont Denumire_cont
101 Capital social
104 Prime legate de capital
105 Diferenţe din reevaluare
106 Rezerve
…
933 Costul producţiei în curs de execuţie

9
 Fiecare obiect de acest tip are o existenţa proprie şi este bine definit de aceleaşi
caracteristici, respectiv codul contului şi denumirea contului. Contul cu codul 101 şi
denumirea Capital social constituie o realizare sau o instanţă a obiectului tip CONTURI,
pentru care caracteristicile Cod_cont, Denumire_cont iau valorile 101 şi respectiv Capital
social.

Alte exemple.
• Datele referitoare la materialele dintr-un depozit.
• Datele referitoare la cărţile dintr-o bibliotecă.
• Datele referitoare la pacienţii unui spital.
• Datele ce descriu situaţia contabilă a unei firme.
Omogenitatea datelor dintr-o colecţie de date trebuie înţeleasă în sens larg, sub
forma unei proprietăţi comune sau a unui obiectiv urmărit.

Noţiunile de informaţie şi dată sunt, prin urmare, diferite. Informaţiile sunt înţelese
de o persoană, în timp ce datele sunt modele stocate pe un mediu pasiv, ca de exemplu
discul hard al unui calculator. Scopul unui sistem care gestionează o colecţie de date este să
reducă distanţa între informaţii şi date – astfel, datele stocate în memoria sau pe discurile
unui calculator să fie convertite în informaţii utilizabile la momentul dorit.

1.2 Organizări ale datelor

Organizarea datelor în vederea prelucrării lor cu calculatorul este o activitate tot atât
de importantă ca şi cea de realizare a programelor. Datele şi programele se găsesc într-o
strânsă corelaţie. Un program, oricât de complex ar fi, nu va furniza rezultate satisfăcătoare
dacă structura datelor cu care lucrează nu este bine gândită. Invers, o structură de date bine
pusă la punct nu va fi suficientă, dacă programul care o prelucrează nu este corect conceput
şi realizat.
Din punct de vedere informatic ne putem referi la două tipuri de organizare a datelor:
• Organizarea in memoria internă a calculatorului şi
• Organizarea în memoria externă.
Organizarea în memoria externă a cunoscut, de-a lungul timpului, mai multe stadii:
• Fişiere şi
• Baze de date.

1.2.1 Organizarea datelor în fişiere

Un fişier este un ansamblu de înregistrări fizice, omogene din punct de vedere al

conţinutului şi al prelucrării. O înregistrare fizică este formată din una sau mai multe
înregistrări logice, o înregistrare logică fiind un ansamblu de câmpuri care conţin date
referitoare la un obiect, proces sau fenomen din lumea reală.

Exemplu. Fişierul de date STOCURI conţine date privind stocurile de produse. Pentru fiecare
produs se memorează: codul, denumirea, unitatea de măsură, preţul de referinţă şi cantitatea
aflată în stoc. Iată (schematic reprezentată) o înregistrare logică pentru un produs aflat în
stoc:

401 TV PANASONIC BUC 1000 20

Înregistrările privind produsele aflate în stoc sunt memorate pe suporturi tehnice şi

formează, împreună, fişierul STOCURI_PRODUSE.
Există două metode de organizare a datelor în fişiere:
• Organizare secvenţială – înregistrările sunt memorate pe suport tehnic în
ordinea introducerii datelor şi sunt accesate în ordinea în care ele sunt
memorate.
• Organizarea indexată – la memorarea înregistrărilor pe suport tehnic,
Sistemul de Gestiune a Fişierelor creează, separat, un tabel în care, pentru

10
 fiecare înregistrare de date, sunt memorate două elemente: cheia de
identificare a înregistrarii şi adresa la care înregistrarea este memorată pe
suport tehnic.

Exemplu.
Tabel cu Înregistrări de date
indecşi
350 A1 A2 401 TV PANASONIC BUC 1000 20
401 A2 A1 350 RADIO SAMSUNG BUC 100 30
420 A3 A3 420 VIDEO SAMSUNG BUC 900 10
… … … … … …

A1 reprezintă adresa (care face referire, în cazul HD, la cilindru, pistă şi sector) la care este
memorată înregistrarea cu valoarea din câmpul de indexare (aici codul produsului) cu
valoarea 350, ş.a.m.d.
Tabelul cu indecşi permite astfel localizarea rapidă a înregistrărilor pe suportul tehnic.
Această metodă presupune existenţa unui atribut ale cărui valori să permită identificarea
înregistrărilor. Acest atribut are rolul de cheie de identificare (indexare).
Deci, un fişier de date este bine definit când se precizează identificatorul de fişier,
structura înregistrării şi modul de organizare.

Exemplu.
Fişierul: STOCURI
Structura înregistrării:
CodMat, numeric
DenMat, Text
UM, Text
PretRef, Numeric
CantStoc, Numeric
Organizare: indexată
Cheie identificare: CodMat

Limite ale organizării datelor în fişiere

• Descrierea datelor se afce în fiecare program în care ele sunt utilizate; spunem că
datele sunt dependente de programe.
• Lipsa unui formalism riguros de definire şi validare a datelor.
• Performanţe scăzute pentru procesarea datelor, îndeosebi când este necesar să se
facă asocieri între date memorate în fişiere distincte.
• Menţinerea unei redundanţe ridicate în cadrul colecţiilor de date memorate pe
suporturi tehnice.

Deci abordarea tradiţională asocia fiecărei aplicaţii informatice propriile fişiere. În mod
evident, anumite date se regăseau în fişierele asociate mai multor aplicaţii. Schematic,
această metodă poate fi reprezentată astfel:

P1 P2 Pn
…

Această abordare ducea la memorarea repetată a unor date şi implicit la un volum

mare de memorie externă ocupată.
De exemplu, dacă într-o fabrică se folosesc materiale pentru realizarea unor produse,
atunci datele necesar a fi memorate pentru fiecare material sunt (cel puţin) cele menţinate în
cazul fişierului STOCURI:

11
 • Cod – un cod asociat fiecărui material, necesar identificării acestuia şi altfel decât prin
nume (de exemplu: 5289);
• Denumire – denumirea materialului (de exemplu: lemn de brad);
• Um – unitatea de măsură (de exemplu: mc, aici, metru cub);
• Preţ – este vorba de preţul unitar (preţul pentru un metru cub de lemn de brad);
• Cantitate – cantitatea existentă la un moment dat în fabrică.
Aceste date şi altele, specifice, vor fi prelucrate pentru diferite compartimente: aprovizionare
(pentru recepţia materialului), gestiune (păstrarea într-o magazie), producţie (consumul
materialului respectiv în procesul de producţie), contabilitate (pentru calculaţia costului
produselor finite). Deci cel puţin patru programe ar utiliza aceste date şi ar fi prin urmare
dezavantajoasă memorarea lor pe un suport fizic (în diferite fişiere) de tot atâtea ori.
Cu toate aceste limite, organizarea datelor în fişiere mai este utilizată şi astăzi,
îndeosebi pentru aplicaţii dezvoltate folosind limbajele clasice de programare.
Progresele în domeniul tehnologiilor informaţionale au marcat o creştere
considerabilă a capacităţii de memorare a suporturilor tehnice de date şi a vitezei de
procesare a datelor. La acestea se adaugă şi posibilitatea stocării şi procesării datelor
netradiţionale cum ar fi, de exemplu, imaginea şi sunetul (a se vedea [Tod04]).

1.2.2 Organizarea datelor în baze de date

Limitele organizării datelor în fişiere şi posibilităţile oferite de noile tehnologii

informaţionale au dus la promovarea metodei de organizare a datelor în baze de date. Ideea
a fost de a colecta toate datele, a le organiza într-un mod convenabil (specific realităţii pe
care acele date le modelează) şi a proiecta programe care să consulte şi să actualizeze
această colecţie de date. Schematic, această abordare se poate reprezenta astfel:

P2
Bază de date

P1 Pn

Prin urmare, o bază de date se defineşte ca fiind un ansamblu de date elementare

sau structurate, accesibile unei comunităţi de utilizatori. O definiţie mai apropiată de
reprezentarea fizică ar fi cea conform căreia o bază de date este un ansamblu de fişiere
intercorelate, care conţin nucleul de date necesare unei aplicaţii informatice complexe.
Astfel, în figura precedentă, legăturile desenate între fişiere reprezintă aceste
intercorelări (adică, fişierele corelate modelează o legătură logică între datele pe care le
conţin) iar aplicaţiile ce accesează datele pot fi privite ca aparţinând la diferiţi utilizatori sau
grupuri de utilizatori, care „văd” baza de date într-un mod propriu (cu alte cuvinte, accesează
din toată colecţia de date ceea ce le este necesar).

1.3 Conceptul de bază de date

În lucrarea Bases de données et systèmes relationnels, Dunod Informatique, Paris,
1982, C. Delobel şi M. Adiba definesc baza de date astfel:

Baza de date este un ansamblu structurat de date înregistrate pe

suporturi accesibile de către calculator pentru a satisface, chiar
simultan, mai mulţi utilizatori, de o manieră selectivă şi în timp oportun.

12
 Într-o bază de date sunt înregistrate date despre obiecte reale sau abstracte, dar şi
asocierile (relaţiile) care se pot stabili între acestea. Spunem că între datele unei baze de
date există o interdependenţă logică. Considerarea interdependenţelor ce se pot stabili între
colecţiile de date memorate într-o bază de date contribuie la asigurarea integrităţii funcţionale
a bazei de date.
O bază de date este un model al unui sistem real. Conţinutul unei baze de date
(numit uneori şi extensie) reprezintă, la un moment dat, o stare a sistemului care se
modelează. Schimbările în baza de date reprezintă evenimente care au loc în mediu şi care
schimbă starea sistemului modelat. Este evident că este de dorit să structurăm o bază de
date astfel încât aceasta să oglindească sistemul care se doreşte modelat.

Obiective fundamentale ale unei baze de date

• Centralizarea datelor. Permite controlul centralizat al datelor şi eliminarea repetărilor
(numite redundanţe). O eliminare totală a redundanţelor nu este posibilă, dar controlul
asupra lor duce la o utilizare eficientă a spaţiului de memorie externă.
• Independenţa între date şi prelucrări. Baza de date, fiind un model al unei realităţi,
se schimbă mereu (de exemplu, într-o bancă au loc: numeroase tranzacţii financiare,
schimbări de personal, schimbări de parteneri de afaceri etc.). Acest lucru nu trebuie
să afecteze programele de prelucrare a datelor şi invers, dacă este necesară operarea
de schimbări în anumite programe, datele nu trebuie să fie afectate.
• Realizarea de legături între date. Datele ce reprezintă modelul unui sistem nu sunt
disparate, între ele există legături logice. Aceste legături vor fi surprinse în baza de
date.
• Integritatea datelor. Asigură fiabilitatea şi coerenţa bazei de date.
• Securitatea datelor. Baza de date trebuie să fie protejată împotriva distrugerilor
logice (greşeli la actualizare) şi/sau fizice (deteriorări ale suporţilor fizici, pierderi de
date datorate unor accidente naturale (calamităţi, incendii etc.).
• Confidenţialitatea datelor. Se referă la caracterul secret al datelor, ce pot fi accesate
doar de către cei autorizaţi.
• Partajarea datelor. Permite deservirea utilizatorilor care accesează simultan aceleaşi
date din bază.

1.4 Sisteme de gestiune a bazelor de date

Sistemul de programe care permite construirea unei baze de date, introducerea

informaţiilor în baza de date şi dezvoltarea de aplicaţii se numeşte sistem de gestiune a
bazei de date (pe scurt, SGBD). Un SGBD dă utilizatorului posibilitatea să aibă acces la date
folosind un limbaj de nivel înalt, adică apropiat de modul obişnuit de exprimare, pentru a
obţine informaţii. Nu este necesar ca utilizatorul să cunoască modul în care sunt selectate
datele pe care le doreşte, ori modul de memorare al lor. Spunem de aceea că SGBD-ul este
o interfaţă între utilizatori şi baza de date, un instrument de asamblare, codificare, aranjare,
protecţie şi regăsire a datelor în baza de date.

Principalele funcţii ale unui SGBD

• Memorarea datelor pe suportul extern (prin intermediul sistemului de gestiune a
fişierelor);
• Gestiunea datelor şi a legăturilor dintre acestea, în vederea unei regăsiri rapide
prin intermediul sistemului de acces;
• Introducerea şi extragerea datelor din/spre exterior, în forma cerută de utilizator.
SGBD-ul poate prelucra mai multe cereri, provenind de la mai multe programe de aplicaţii.
Totodată, majoritatea SGBD-urilor asigură şi controlul transmisiei datelor la şi de la terminale.
SGBD-ul pune la dispoziţia utilizatorilor limbaje distincte pentru:
• Descrierea bazei de date: Limbajul de Descriere a Datelor (LDD).
• Utilizarea (manipularea) bazei de date: Limbajul de Manipulare a Datelor (LMD).
Limbajele de manipulare (interogare) a bazelor de date pot fi:
• Declarative – permit utilizatorului să declare de CE informaţii are nevoie.
• Procedurale – care obligă utilizatorul să descrie CUM obţine informaţiile.

13
 Realizarea pe plan mondial a unor reţele de calculatoare care permit conectarea mai
multor baze de date a condus la apariţia bazelor de date distribuite şi, implicit, la apariţia
SGBD pentru astfel de baze. Bazele de date distribuite reprezintă un salt calitativ superior în
acest domeniu, oferind noi perspective pentru realizarea sistemelor informatice. Un sistem de
baze de date distribuite este o colecţie de baze de date locale, amplasate geografic în puncte
diferite şi legate logic prin relaţii funcţionale, astfel încât apar, la nivel global, ca o singură
bază de date.
În funcţie de modul în care exploatează baza de date, utilizatorii pot fi împărţiţi în
următoarele clase:
• Utilizatorii obişnuiţi, care pot să obţină informaţiile dorite fără să aibă cunoştinţe de
programare, prin comenzi cunoscute şi eventual răspunzând la diferitele opţiuni pe
care le indică sistemul la un moment dat.
• Programatorii de aplicaţii, care realizează programele ce vor fi memorate şi ulterior
lansate în execuţie de utilizatori prin invocarea numelui asociat lor.
• Administratorul bazei de date, care stabileşte structura iniţială a bazei de date şi
modul de memorare a datelor la nivel fizic, acordă utilizatorilor drepturi de acces la
bază sau la părţi ale ei, stabileşte condiţiile pentru asigurarea securităţii şi integrităţii
datelor, modifică structura bazei atunci când este nevoie, asigură întreţinerea bazei
făcând periodic copii şi reconstruind baza de date în cazul în care au apărut erori
datorate componentelor soft, hard sau utilizării şi răspunde, în general, de modul de
utilizare al bazei de date.
Cele mai multe SGBD-uri conţin şi o colecţie de utilitare folosite în diferite aplicaţii:
procesoare pentru limbaje de cereri, editoare de rapoarte, sisteme de reprezentări grafice,
posibilităţi de lucru cu tabele, programe statistice, de copiere, generatoare de aplicaţii şi alte
posibilităţi de dezvoltare a unor aplicaţii de tip CASE (computer-aided software engineering).
Pentru a facilita munca administratorului de sistem, un SGBD conţine o serie de
componente care permit: crearea unei versiuni iniţiale a bazei, salvarea şi reîncărcarea
(efectuarea de copii periodice şi posibilitatea refacerii bazei plecând de la aceste copii),
reorganizarea (rearanjarea datelor în scopul îmbunătăţirii unor performanţe), statistici şi
analize asupra exploatării bazei de date.
Evoluţia tehnologiilor informaţionale face ca în prezent majoritatea SGBD-urilor:
• Să gestioneze date tradiţionale, dar şi date netradiţionale (video, foto, sunet
etc.).
• Să permită lucrul în reţea de calculatoare.
• Sa pună la dispoziţia utilizatorului atât limbaje declarative, cât şi limbaje
procedurale.

Materiale introductive privind domeniul bazelor de date:

Cursuri generale de baze de date:

1. www.cs.washington.edu/education/courses/444/98wi
2. www.albany.edu/acc/courses/acc682.fall98/
3. www.cs.umbc.edu/461/461.shtml
4. www-db.stanford/edu/~ulmann/fcdb.html
5. www.developer.com/db/article.php/719041
6. www.servicearchitecture.com/database/articles

7. webmonkey.wired.com/webmonkey/backend/databases/tutorial/tutorial1.html
Despre alegerea sistemului potrivit de baze de date

8. [Bas97]
Tipuri de organizare a fişierelor şi metode de căutare în fişiere
Descrierea unor SGBD-uri de tipuri diferite

14
 2. Niveluri de reprezentare a unei baze de date

Bazele de date pot fi analizate pe diferite nivele:

ƒ Nivelul conceptual – ce corespunde modelelor semantice de date – este un model „de
nivel înalt”, specific omului şi nu sistemelor de calcul.
ƒ Nivelul aplicaţie – ce poate fi privit, la rândul său, din două puncte de vedere:
ƒ Logic – referitor la organizarea datelor, organizare prin care se implementează o
anumită cantitate de informaţie şi
ƒ Fizic – referitor la stocarea efectivă a informaţiei (grupare, partiţionare, indexare,
etc.)

2.1 Modelarea conceptuală

Nivelul conceptual ne permite să modelăm aplicaţiile în termeni independenţi de

orice model de date particular. Este un instrument convenabil care ne permite să structurăm o
bază de date astfel încât aceasta să evolueze în timp odată cu mediul modelat, cu
necesităţile utilizatorilor şi cu schimbările care apar privind cererile de informaţie. Modelele
conceptuale furnizează un mediu pentru dezvoltarea structurii unei baze de date într-o
manieră de sus în jos (top-down). Cel mai utilizat model conceptual este Modelul Entitate -
Asociere.

2.1.1 Modelul Entitate - Asociere

Modelul entitate-asociere este un instrument pentru analiza acelor aspecte semantice

ale unei aplicaţii, care sunt independente de evenimente. Modelul entitate-asociere reduce
redundanţa datelor. Aceasta abordare utilizează urmăytoarele notaţii grafice: dreptunghiuri
pentru entităţi, romburi pentru asocieri (relaţii) şi cercuri sau elipse pentru atribute. Pentru
situaţii complexe, o diagramă entitate-asociere parţială (care nu include detalii depre atribute)
poate fi utilizată pentru a prezenta o sinteză a entităţilor şi relaţiilor.
Diagrama entitate-asociere furnizează o metodă eficientă pentru vizualizarea
legăturilor între entităţi, pentru o aplicaţie dată. Aceast instrument s-a dovedit util pentru a
face tranziţia de la desrierea unei aplicaţii la o schemă formală a bazei de date. Modelul
entitate-asociere este astfel realizat fără a fi necesară atenţia asupra proiectării fizice a bazei
de date. Diagramele entitate-asociere sunt ulterior transformate într-o schemă conceptuală în
unul din modelele în care baza de date se va implementa efectiv.
În continuare sunt prezentate definiţiile unor termeni de bază utilizaţi pentru
descrierea conceptelor importante ale modelului entitate-asociere.

• Entitate - O entitate este un obiect concret sau abstract care poate fi clar delimitat în
mediu.
o Instanţă de entitate - O instanţă este o apariţie particulară a unei entităti.
De exemplu, fiecare persoană în parte poate fi o instanţă a unei entităţi
PERSOANE, fiecare maşină în parte poate fi o instanţă a unei entităţi
MAŞINI, etc.
o Tip de entitate – Un grup de entităţi similare poartă numele de clasă de
entităţi sau tip de entitate. O clasă de entităţi are proprietăţi comune.

• Atribute – Atributele descriu proprietăţile entităţilor şi relaţiilor şi pot fi:

o Simple (scalare) – sunt cele mai mici unităţi semantice de date, atomice
(fără structură internă), de exemplu: oraşul.
o Compuse – reprezintă grupuri de atribute privite unitar, de exemplu: adresa
(stradă, număr, oraş, cod poştal ).
o Multivaluate (liste) - reprezintă valori multiple, de exemplu: note, cursuri,
etc.

15
 » Domeniile – sunt mulţimile de definiţie ale atributelor:
• mulţimi precizate de valori scalare de acelaşi tip sau
• mulţimi de valori posibile.

• Relaţiile – O relaţie este o legătură între două clase de entitate.

De examplu, o relaţie între entităţile PERSOANE şi MAŞINI poate fi cea de
„proprietate” (automobilele sunt în proprietatea oamenilor).
o Gradul unei relaţii indică numărul de entităţi implicate în relaţie.
o Cardinalitatea unei relaţii indică numărul de instanţe din clasa de entităţi E1
care poate sau trebuie asociată cu instanţe din clasa de entităţi E2:
ƒ Relaţii 1-1 (One to One relationship) – Pentru fiecare entitate dintr-
o clasă există cel mult o entitate asociată în cealaltă clasă. De
exemplu, fiecare persoană are un card de identitate (şi există copii,
care încă nu au).
ƒ Relaţii 1-n (One to Many relationships) – O entitate din clasa E2
este asociată cu zero sau mai multe entităţi din clasa E1, dar fiecărei
entităţi din E1 i se asociază cel mult o entitate în E2. De exemplu, o
femeie poate avea mai mulţi copii dar orice copil are o singură
mamă.
ƒ Relaţii m-n (Many to Many relationships) – Nu există restricţii
asupra numărului de entităţi dintr-o clasă, ce pot fi asociate cu o
entitate din cealaltă clasă. De exemplu, relaţia între studenţi şi
cursuri. Fiecare student merge la mai multe cursuri şi fiecare curs are
mai mulţi studenţi.
ƒ Poate fi obligatorie, opţională sau fixată.
o Ierarhiile Isa („Is a”) – reprezintă un tip special de relaţie ce permite
moştenirea atributelor. De exemplu, a spune că un camion este un automobil
şi un automobil are un fabricant, un model şi un număr de serie implică faptul
că un camion are, de asemenea, un fabricant, un model şi un număr de
serie.

• Cheile – Cheile identifică în mod unic o entitate de alta, într-o clasă de entităţi.
o Cheia primară – Identificator utilizat pentru a identifica în mod unic o instanţă
particulară a unei entităţi.
ƒ Poate fi reprezentată de unul sau mai multe atribute.
ƒ Trebuie să fie unică în domeniul său (şi nu doar în setul de date
curent).
ƒ Valorile sale nu se schimbă în timp.
ƒ Trebuie să aibă totdeauna o valoare.
ƒ Poate fi creată când nu este evident nici un atribut. Fiecărei instanţe i
se asociază o valoare.
o Cheie candidată – Când există mai multe chei primare posibile, fiecare este
o cheie candidată.
o Cheie concatenată – Este o cheie realizată din componente care, atunci
când sunt considerate împreună, identifică în mod unic entitatea. Cheile
atribute multiple sunt chei concatenate.
o Atribute cheie împrumutate – dacă există o relaţie isa, cheia clasei mai
generale este, de asemenea, o cheie pentru subclasă. De exemplu, dacă
numărul de serie pentru automobile este cheie, va fi cheie şi pentru
camioane.
o Chei secundare – Referă un tabel aflat în relaţie, prin cheia primară a acelui
tabel.
» Restricţia de integritate referenţială – Pentru fiecare valoare a unei chei
secundare, există o cheie primară cu acea valoare în tabelul referit. De
exemplu, dacă un număr de cont se utilizează într-un tabel pentru intrări,
atunci numărul de cont trebuie să existe tabelul cu numerele de cont.

• Evenimente – Evenimentele schimbă entităţile şi/sau relaţiile.

16
 2.1.2 Diagrama Entitate - Asociere

Simbolurile utilizate în diagrama entitate – asociere includ:

• Dreptunghiuri – Reprezintă clasele (tipurile) de entitate.
• Cercuri – reprezintă atributele.
• Romburi – reprezintă relaţiile.
• Arce – Au rolul de a conecta entităţile prin relaţii şi, de asemenea, de a conecta
atributele la entităţi. Unele modele de diagramă entitate – asociere utilizează săgeţi
sau săgeţi duble pentru a indica diferitele tipuri de relaţii.
• Sublinierea – Atributele cheie ale entităţilor sunt subliniate.

Iată un fragment dintr-o diagramă entitate – asociere:

Tip de entitate Relaţie Tip de entitate

1 N
CLIENŢI FACTURI
Primesc

Cod Nume Adr. Codf Data Val.

2.2. Modele de date

Principalele clase de modele logice utilizate în gestiunea bazelor de date sunt
următoarele:
• Modelul ierarhic
• Modelul reţea
• Modelul relaţional.
Un alt model care trebuie menţionat este modelul punctual. O bază de date cu un
singur fişier (tabel) reprezintă o structură punctuală. O astfel de structură este utilă doar în
cazuri extrem de simple, pentru cele mai multe aplicaţii din domeniul economic fiind
insuficientă. Multe procesoare de tabele includ facilităţi de baze de date, cum ar fi sortarea,
numărarea sau filtrarea datelor care satisfac anumite criterii. Toate facilităţile de baze de date
incluse în procesoarele de tabele se referă la structura punctuală.
În cele ce urmează se vor prezenta pe scurt primele două modele, detaliind într-un
capitol separat modelul relaţional care este, în prezent, cel mai utilizat.

2.2.1 Modelul ierarhic

Modelul de date ierarhic este o colecţie de structuri arborescente, fiind fondat pe

reprezentarea arborescentă a schemei conceptuale a bazei de date, în care nodurile
reprezintă clasele de obiecte, iar arcele – legăturile între acestea. Modelul ierarhic este, prin
urmare, un “arbore” de înregistrări în care fiecare înregistrare conţine două elemente
• rădăcină sau un câmp master (o cheie), care identifică tipul, locaţia sau ordinea
înregistrărilor
• câmpurile subordonate, ce reprezintă restul datelor dintr-o înregistrare
Toate câmpurile au numai un nod părinte, fiecare nod părinte putând avea mai mulţi fii.
Operaţiile din bazele de date de tip ierarhic se traduc în procese de parcurgere a arborilor.
Avantaje: viteză şi eficienţă pentru anumite tipuri de aplicaţii. Modelul ierarhic este o
alegere bună atunci când datele au o structură naturală de arbore. Astfel de aplicaţii pot fi, de
exemplu, inventarele, sistemele de documentare bibliografice, unele sisteme de luare a

17
deciziilor şi de gestionare de tip ierarhic, sistemele de informare şi operare bazate pe lucrul
cu meniuri şi altele asemănătoare.
Probleme: modul de definire a datelor este predefinit; fiecare asociere trebuie să fie
definită explicit, la crearea bazei de date.
Modelul ierarhic este un caz special al modelului reţea. Cel mai cunoscut SGBD de
tip ierarhic este IMS (Information Management System) de la IBM. A fost construit în 1968 în
scopul prelucrării datelor din industria aerospaţială. Iniţial a fost un sistem pur ierarhic, dar a
căpătat unele trăsături non-ierarhice, ca rezultat al necesităţilor practice.

Exemplu.
Structura arborescentă prezentată în continuare se referă la o bază de date a unei
agenţii de vânzări de locuinţe:

JUDETE (NUMER)
OFICII (ORAS, ADROF)
AGENTI (NUMEA, VANZARI)
ANGAJAT (NR_AN, NUMEAN, ADRAN, SALARIU)
OFERTE (ADROF, PRET)
CLIENTI (NUMEC, ADRC)

şi poate fi descrisă prin următoarea succesiune de instrucţiuni în SGBD IMS:

TREE AGENTIE
RECORD JUDETE ROOT
NUMER CHAR(20)
RECORD OFICII PARENT=JUDETE
ORAS CHAR(20)
ADROF CHAR(30)
RECORD AGENTI PARENT=OFICII
NUMEA CHAR(20)
VANZARI INTEGER
RECORD ANGAJAT PARENT=OFICII
NR_AN INTEGER
NUMEAN CHAR(20)
ADRAN CHAR(30)
SALARIU INTEGER
RECORD OFERTE PARENT=OFICII
ADROF CHAR(30)
PRET INTEGER
RECORD CLIENTI PARENT=AGENTI
NUMEC CHAR(20)
ADRC CHAR(30)

2.2.2 Modelul reţea

Modelul de date reţea este cel mai apropiat de forma de reprezentare a bazelor de
date sub forma diagramelor entitate-asociere. Deosebirea constă doar în faptul că toate
relaţiile ce apar pot fi numai binare şi de tipul 1-1 sau 1-n. Această restricţie permite
reprezentarea grafică a unei baze de tip reţea sub forma unui orientat numit reţea. În acest
graf, nodurile corespund entităţilor iar relaţiile sunt reprezentate prin săgeţi de la tată la fiu şi
anume: săgeţi simple dacă relaţia este de tip 1-1 şi săgeţi duble dacă relaţia este de tip 1-n.
Iată câteva caracteristici ale modelului reţea:
• Crează asocieri între date printr-o listă de legături în care înregistrările
subordonate (membre) pot fi legate la mai mult de un element (proprietar). Un
element poate fi parte a mai multor asocieri.
• Pointer – legătură explicită, păstrând adrese ce conţin locaţia înregistrării
asociate.
• Complexitate – pentru fiecare mulţime de elemente asociate trebuie păstrată o
pereche de pointeri. Utilizănd acest model, este dificil să se structureze, din
punct de vedere conceptual, structuri de date complexe.

18
 • Viteză – legăturile directe conduc la viteze de lucru mari ale sistemelor care
implementează modelul reţea.

Exemplu.
SGBD SOCRATE este de tip reţea, fiind totodată şi unul din primele sisteme de
gestiune a bazelor de date. A fost realizat de firma CII în colaborare cu ECA-Automation
pentru sisteme de tip IRIS, fiind folosit şi în ţara noastră pe vechile sisteme de tip Felix.
Sistemul conţine un limbaj de descriere pentru date (identificarea datelor, a proprietăţilor lor şi
eventual a criteriilor de validare), un limbaj de cereri, un macrogenerator (pentru generarea
unor macrocomenzi care permit utilizarea produsului şi de către nespecialişti), un modul de
metode de acces (care permite utilizarea unor programe de accesare a datelor scrise în
diverse limbaje de programare), un editor de texte (pentru gestionarea textelor programelor şi
a celor din baza de date), componente pentru asigurarea securităţii şi confidenţialităţii datelor
din bază, pentru reorganizarea bazei şi alte programe utilitare. Poate lucra atât autonom,
conţinând toate elementele necesare funcţionării sale, cât şi ca metodă de acces, fiind
deschis prin interfeţe pentru a putea funcţiona împreună cu alte programe. Poate opera atât
programabil cât şi conversaţional. În al doilea caz, poate lucra în regim multiutilizator.

Materiale privind modelarea:

1. http://www.utexas.edu/its/windows/database/datamodeling/rm/rm7.html
Curs de iniţiere in modelarea datelor la University of Texas at Austin

Despre modelele ierarhic şi reţea:

2. http://unixspace.com/context/databases.html
3. www.ittia.com/dbstar/whitepapers/technicalmodel.pdf
4. www.staff.brad.ac.uk/ckarazai/Lecture3.pdf

Despre modelul entitate-asociere:

5. www.campus.ncl.ac.uk/databases/design/design.html
6. http://databases.about.com/od/Specificproducts
7. http://ycmi.med.yale.edu/nadkarni/IntroductiontoEAVSystems.htm
8. http://wofford.org/ecs/DataAudVisualization/ermodel/material.htm

19
 3. Modelul relaţional

În modelul relaţional, baza de date este reprezentată de un grup de tabele corelate.

Modelul relaţional a fost propus în 1970 de către cercetătorul american E.F. Codd, în lucrarea
„A relational model of large shared data banks” şi este, în prezent, cel mai popular model.
Simplitatea matematică şi uşurinţa vizualizării modelului relaţional au contribuit la succesul
acestuia. În plus, modelul relaţional de date nu este legat de un tip anume de structură de
date (cum este, de exemplu, modelul ierarhic).
Modelul relaţional se bazează pe teoria matematică a relaţiilor.
Formal, o relaţie n-ară R pe domeniile X1, X2, …,Xn este o submulţime a produsului
cartezian X1xX2x … xXn şi se notează
R(X1,X2, …,Xn).
X1, X2, …,Xn se mai numesc constituenţi.

Exemplu. Fie o întreprindere şi clasa de obiecte „autoturisme fabricate în întreprindere”.

Fiecare produs are ca atribute: codul produsului, denumirea produsului şi preţul de referinţă.
Să considerăm datele ce caracterizează împreună un anume produs:
1555, OPEL VECTRA, 15000
1555 reprezintă codul, OPEL VECTRA reprezintă numele iar 15000, preţul. Datele reprezintă
valori ale atributelor, valori ce se plasează într-un domeniu de definiţie corespunzător.
Domeniul de definiţie se poate preciza implicit sau explicit. În acest caz, atributului „preţ de
referinţă” i se atribuie valori în mulţimea numerelor întregi. Dacă preţurile autoturismelor
fabricate au valori cuprinse între 10000 şi 30000, atunci domeniul de definiţie se poate
preciza ca fiind secvenţa numerelor între 10000 şi 30000.

Este important ca pentru fiecare atribut să se cunoască domeniul de definiţie,

deoarece la introducerea datelor în baza de date nu vor fi acceptate decât datele care
reprezintă valori plasate în domeniile de definiţie ale atributelor. Validarea datelor la
introducere poate fi foarte complexă, având ca obiectiv asigurarea integrităţii datelor.
Ansamblul valorilor afectate atributelor pentru un obiect real sau abstract din
domeniul supus studiului formează un tuplu (sau o realizare, sau o înregistrare de date).
Tuplurile unei relaţii trebuie să fie unice. Se observă că datele pot fi organizate, în mod
eficient, într-un tabel. Dealtfel, organizarea tabelară este foarte mult folosită în practică.
Tuplurile vor fi liniile tabelului, în timp ce atributele sunt regăsite pe coloane. Ordinea liniilor şi
coloanelor nu prezintă nici o importanţă.
Validarea datelor la nivelul realizării unei relaţii înseamnă, în plus, respectarea
regulilor de integritate stabilite la nivel de relaţie.

Exemplu. Pentru relaţia SALARIAT, cu atributele: Maca, Nume, Data_nasterii,

Data_angajarii. La nivelul acestei relaţii se poate stabili regula de integritate:

An(Data_angajarii)>=An(Data_nasterii)+18.

Regulile pentru asigurarea integrităţii datelor pot viza şi asocieri ce se stabilesc între
realizări ale relaţiilor din baza de date.

Exemplu. O relizare a relaţiei „facturi de la furnizori” se asociază cu o realizare a relaţiei

„furnizori”. Nu se pot înregistra datele dintr-o factură, dacă anterior nu s-a inregistrat, în baza
de date, furnizorul. Acesta este un exemplu de regulă de integritate referenţială a bazei de
date.

Dintre cele trei modele de baze de date prezentate, modelul relaţional se impune prin:
simplitate, structuri de date simple, operatori simpli (fără mari diferenţe între sisteme),
mecanismul vederilor, o bază teoretică solidă, un număr mic de concepte, aplicarea
principiului dualităţii accesului (prin program şi interactiv), independenţa fizică a datelor,
independenţa logică a datelor, uşurinţa dezvoltării aplicaţiilor, a instalării şi operării,
simplificarea proiectării bazelor de date, integrarea dicţionarelor, posibilitatea dezvoltării
bazelor de date distribuite, performanţe şi posibilităţi de extindere.

20
 3.1 Conceptele modelului relaţional
Conceptele modelului relaţional sunt prezentate în următoarea sinteză:

• Relaţie - Un tabel (bidimensional). Relaţia însăşi corespunde noţiunii noastre

obişnuite de tabel. O relaţie este deci o colecţie de tuple (termenul vine de la „t-
uplu”, notaţie folosită şi în matematică, adică o succesiune de t elemente), fiecare
conţinând valori ale unui număr fix de atribute. Relaţiile mai sunt uneori referite şi ca
fişiere, din cauza asemanării lor cu o secvenţă nestructurată de articole. Fiecare tuplu
al unei relaţii trebuie să fie unic (deci, nu există duplicate).
• Atribut – Este o coloană a tabelului. Alţi termeni utilizaţi în mod obişnuit pentru
atribut sunt proprietate şi câmp. Mulţimea valorilor permise pentru fiecare atribut se
numeşte domeniul acelui atribut.
• Tuplu – Este un rând al tabelului. Un tuplu este o instanţă a unei entităţi sau asocieri.
• Cheie – Un singur atribut sau o combinaţie de atribute ale căror valori identifică în
mod unic tuplurile relaţiei. Deci, fiecare rând are o valoare diferită pentru atributul
cheie. Modelul relaţional cere ca fiecare relaţie să aibă o cheie astfel încât:

o Oricare două tupluri nu pot avea aceiaşi valoare a cheii

o Fiecare tuplu trebuie să aibă o valoare pentru atributul cheie (câmpurile cheie
nu pot avea valori nenule).

Există două restricţii ale modelului relaţional care, în practică, sunt uneori nerespectate:
1. Nu sunt permise tupluri duplicate. Dacă sunt introduse două tuple cu aceeaşi
valoare pentru fiecare din atribute, ele de fapt sunt considerate a fi acelaşi tuplu.
Această restricţie este uneori rezolvată prin asignarea unui număr de linie (sau de
tuplu) unic pentru fiecare intrare, ceea ce asigură unicitatea.
2. Nu se presupune nici o ordine a tuplurilor în cadrul relaţiei. În practică, totuşi, se
foloseşte desori o metodă de ordonare a tuplurilor.

Exemplu de extensie a unei relaţii:

Atribut sau
câmp sau
coloană
Numele atributelor
sunt parte a
COD_CLIENT NUME ADRESĂ CREDIT_LIMITĂ
schemei
19283 ELBAC S.A. Şos. Oituz 34 300000000

Tuplu sau 35231 SUBEX S.A. Şos. Iaşului 12 500000000

Înregistrare sau
rând
34567 MICROSISTEM Şos. Alba 23 250000000
S.A.

Există următoarea distincţie între schema unei relaţii şi extensia unei relaţii.
Schema este „cadrul” pentru relaţie. Ea defineşte relaţia, adică:
• Numărul atributelor
• Numele atributelor şi domeniile acestora
• Atributul cheie primară
Extensia relaţiei este conţinutul relaţiei, adică mulţimea tuplurilor care formează
relaţia. Extensia unei relaţii poate varia foarte mult în timp, dar schema este stabilă. Antetele
coloanelor din figura de mai sus pot fi privite ca o parte a schemei, iar tuplurile de sub antete,
ca fiind extensia.

21
 În termeni conceptuali, o relaţie este o structură care păstrează valori ale atributelor
unei clase particulare de entităţi, sau ale unei clase particulare de asocieri. Exemplul
reprezintă o relaţie ce descrie membrii unei clase de entitate numită CLIENŢI. Relaţiile pot, de
asemenea, să descrie asocieri.
Observaţie. A nu se confunda, din cauza omonimiei, relaţia, care este o construcţie
la nivel de date a modelului relaţional, cu asocierea (pentru care se foloseşte şi termenul de
relaţie), care este o noţiune la nivel conceptual.
În relaţia CLIENŢI, cheia pentru fiecare realizare de entitate este păstrată în atributul
COD_CLIENT. Cheile compuse sunt folosite, de obicei, în cazul asocierilor. De exemplu,
dacă am crea o relaţie care să reprezinte asocierea dintre studenţi şi cursuri am avea nevoie
de o cheie, care ar putea fi combinaţia dintre cheia pentru studenţi şi cheia pentru cursuri.

Următoarele reguli permit (în cele mai multe cazuri) conversia unei diagrame entitate-
asociere într-o schemă relaţională:
• Este necesară câte o relaţie (tabel) pentru fiecare clasă de entităţi şi fiecare
relaţie de tip m-n;
• Nu sunt necesare relaţii pentru a reprezenta relataţiile de tip 1-1 sau 1-n;
• Când se construieşte o relaţie (tabel) pentru reprezentarea unei asocieri m-n,
cheia trebuie să conţină toate atributele cheie ale relaţiilor implicate.

Exemplul din 10.1 reprezintă un model relaţional.

3.2 Sisteme de gestiune a bazelor de date relaţionale

Bazele de date la organizarea cărora se utilizează modelul relaţional se numesc baze
de date relaţionale (BDR). SGBD-urile care permit gestiune bazelor de date relaţionale se
numesc sisteme de gestiune a bazelor de date relaţionale (SGBDR).
Dintre sistemele de gestiune a bazelor de date relaţionale menţionăm: Visual Fox,
Access, Db2, Oracle, Informix. Unele dintre aceste SGBDR-uri au interfeţe proprii pentru
interogarea bazelor de date relaţionale, toate implementând limbajul standard SQL. Multe
SGBDR-uri fac obiectul unor extinderi, pentru a fi adaptate noilor cerinţe, cum ar fi: orientarea
obiect, analiza multidimensională, sisteme expert, sisteme multimedia, sisteme client-server.
Pentru gestiunea bazelor de date de dimensiuni mari (cu înregistrări ce depăşesc
ordinul sutelor de mii) se recomandă utilizarea unor sisteme de gestiune a bazelor de date
performante, cum ar fi Oracle, SQL Server şi Informix. Având in vedere performanţele oferite
pentru gestiunea bazelor de date relaţionale dar şi necesităţile didactice, în cadrul acestui
curs vom prezenta aplicaţii realizate în Access.

Materiale privind modelul relaţional:

1. [Fel96]
Despre bazele de date relaţionale

2. http://databases.about.com/compute/databases/mbody.htm
Despre baze de date în general, cu informaţii despre modelul relaţional

3. http://www.sqlmag.com/Articles/Index.cfm?ArticleID=5113
SQL. Despre alegerea cheii primare

4. http://www.acm.org/classics/nov95/
Extrase din lucrarea lui Codd privind modelul relaţional

22
 4. Noi funcţionalităţi ale bazelor de date

4.1 Partajarea bazelor de date

În condiţiile lucrului în reţea, este posibil să se stocheze baza de date pe un

calculator ce are rol de server. Toţi utilizatorii de la posturile de lucru pot accede simultan la
baza de date; ei partajează baza de date.
Lucrul în sistem multiutilizator impune rezolvarea unor probleme care vizează:
• asigurarea integrităţii datelor (îndeosebi în cazul în care doi sau mai mulţi utilizatori
vor să realizeze în acelaşi timp operaţii de actualizare a bazei de date);
• asigurarea confidenţialităţii datelor;
• prevederea unor mecanisme de protecţie împotriva unor operaţii neautorizate, care
vizează îndeosebi modificarea structurii unor componente ale bazei de date;
Administratorul bazei de date are sarcini privind:
• modelarea datelor
• implementarea bazei de date
• definirea utilizatorilor şi a drepturilor de acces
• întreţinerea bazei de date.
Drepturile de acces la nivel de utilizator vizează operaţiile pe care aceştia le pot realiza. Se
poate merge până la detalii, precizând chiar tabelele la care un anume utilizator va avea
acces.
În practica dezvoltării sistemelor cu baze de date se poate opta pentru dezvoltarea
unor interfeţe de acces la baze de date partajate la nivel de utilizator / grup de utilizatori
(fiecare interfaţă utilizează, de regulă, numai tabele ale bazei de date ce este stocată pe
server).

4.2 Baze de date distribuite

În numeroase situaţii bazele de date sunt dispersate geografic – se spune că sunt
distribuite (BDD). O bază de date distribuită permite ca o colecţie arbitrară de relaţii, dintr-o
colecţie arbitrară de baze de date, , aflate pe o mare varietate de maşini ce lucrează sub
diverse sisteme de operare şi sunt legate prin diferite reţele de comunicaţie, să poată fi
utilizate ca şi cum ar fi o singură bază de date pe o singură maşină.
Principalele cerinţe pe care trebuie să le asigure un sistem de baze distribuite sunt:
autonomia locală în organizarea şi prelucrarea datelor, posibilitatea de lucru continuu al
nodurilor, independent de schimbările în configuraţiile de lucru (adăugări sau eliminări de
noduri), independenţa localizării şi fragmentării datelor (transparenţa fizică), posibilităţi de
replicare (copiere) şi independenţa copiilor, prelucrarea distribuită a cererilor, administrarea
distribuită a tranzacţiilor, independenţa de hardware, de sistem de operare, de reţea şi de
SGBD.

Exemplu. Considerăm o bancă ce are filiale în 20 de localităţi. Fiecare agenţie posedă un

sistem de calcul propriu şi propria bază de date (bază de date locală). Banca centrală
posedă, de asemenea, un sistem de calcul pentru prelucrarea ansamblului datelor de la toate
filialele. Tranzacţiile efectuate in conturi pot fi locale sau globale. Să presupunem că de la
filiala din Constanţaa băncii se face o depunere de 20 000 lei în contul cu numărul 456 al
persoanei X. Dacă persoana X a deschis contul la filiala din Constanţa, tranzacţia este locală.
Dacă persoana X are contul deschis la filiala din Bucureşti, tranzacţia este considerată
globală. Fiecare filială are acces la baza de date a unei alte filiale pentru realizarea unui set
finit de operaţii.

Lucrul în reţele de calculatoare permite distribuirea unei baze de date, din punct de
vedere fizic, pe mai multe site-uri. Fiecare site găzduieşte un sistem local de gestiune a
bazelor de date. Utilizatorii unui site au acces la baza de date locală şi, în plus, la bazele de
date distribuite în celelalte site-uri. Conexiunile între site-uri pot fi stabilite în diverse maniere.

23
 Topologiile de racordare (stea, inel, combinate) se prezintă sub formă de grafuri, ale
căror noduri corespund site-urilor. Un utilizator particular va folosi baza de date fără să facă
referiri concrete şi fără să se preocupe de locul unde aceasta este memorată fizic.

Figura următoare prezintă o posibilă arhitectură pentru baza de date distribuită a unei bănci:

Centru regional Centru regional Centru regional

1 2 … N

Centre regionale
cu Mainframe

LAN LAN LAN

Agenţia 1 Agenţia 2 Agenţia M

În cazul unei întreprinderi s-ar putea opta pentru soluţia unei baze de date distribuite pe
funcţii, ca în figura următoare:

Gestiunea
Gestiunea resurselor umane
resurselor materiale şi a salariilor
Infrastructură
pentru
comunicaţie

Gestiunea Contabilitate
producţiei şi control de gestiune

Există mai multe arhitecturi pentru baze de date distribuite:

• Cu replicare – diversele site-uri stochează o copie a bazei de date.
• Cu fragmentare – baza de date este fragmentată, iar fiecare fragment este găzduit de
către un site. Fragmentarea poate fi: orizontală, verticală sau mixtă.
• Cu replicare şi fragmentare.

Sistemele cu baze de date distribuite comportă două subsisteme:

• Gestionarul de tranzacţii - a cărui funcţie este de a gestiona tranzacţiile relative la
datele site-ului; fiecare tranzacţie poate fi locală (executabilă integral în cadrul site-
ului) sau poate să facă parte dintr-o tranzacţie globală (interesând mai multe site-uri);
• Coordonatorul tranzacţiilor – al cărui rol este de a coordona executarea diverselor
tranzacţii (locale sau globale); el trebuie să execute un protocol da validare a
tranzacţiei.

Avantaje. Avantajele repartizării bazelor de date sunt:

• partajarea datelor şi gestiunea distribuită a acestora;
• fiabilitatea şi disponibilitatea;
• prelucrarea accelerată a cererilor.

Principala dificultate în dezvoltarea sistemelor cu baze de date distributive provine din

necesitatea de a coordona ansamblul site-urilor. Un sistem cu baza de date distribuită ridică
problemele specifice sistemelor multiutilizator, la care se adaugă cele ale distribuirii bazelor
de date.

24
 4.3 Baze de date deductive
Bazele de date deductive se fundamentează pe cuplarea unei baze de date
relaţionale cu un procesor din clasa sistemelor expert. În figura următoare se prezintă o
arhitectură simplificată a unei baze de date deductive.

INTERFAŢA

Interpretor SGBDR
PROLOG

Se vor prezenta detalii în capitolul 9.

4.4 Baze de date multidimensionale

Bazele de date multidimensionale au apărut ca urmare a necesităţilor crescânde de

procesare multidimensională a datelor. Aplicaţiile care se bazează pe analiza
multidimensională a datelor sunt cunoscute sub numele de OLAP (On Line Analytical
Processing). Se face astfel distincţie între:
• OLTP (On Line Transactional Processing) - care privilegiază: integritatea şi
securitatea datelor şi tratarea cererilor informaţionale simple de către servicii
operaţionale (producţie, comercial, resurse umane etc.) şi
• OLAP – care privilegiază: analiza şi manipularea datelor folosind cereri complexe, în
vederea elaborării strategiei şi sunt destinate îndeosebi conducerii şi controlului de
gestiune.
Conceptul de bază este cel de hipercub, ilustrat în figura următoare:

Datele se regăsesc la intersecţia liniilor marcate pe hipercub şi au pentru coordonate

atributele ce definesc dimensiunile hipercubului. Hipercubul din figura de mai sus poate fi
utilizat, de exemplu, pentru a reprezenta date despre vânzări pe trei dimensiuni:
• dimensiunea localitate;
• dimensiunea produs;
• dimensiunea timp (lunile anului).

4.5 Baze de date orientate obiecte

Deşi succesul SGBDR-urilor în dezvoltarea aplicaţiilor economice este încă destul de
mare, ele prezintă şi anumite limite.
Este vorba, în primul rând, de faptul că pentru orice aplicaţie informatică se
delimitează net trei domenii:
• interfaţa;
• datele;
• prelucrările.

25
 Tehnologia orientată „pe obiecte” reduce cele trei formalisme la unul singur: obiectul.
Aplicarea tehnologiei orientate obiect în domeniul bazelor de date a determinat apariţia
bazelor de date orientate pe obiecte. Primele baze de date orientate pe obiecte au apărut la
sfârşitul anilor '80, dar nu au atins un nivel de dezvoltare prea ridicat, datorită:
• lipsei produselor CASE, care să permită o proiectare corectă;
• limbajelor de interogare, care erau deficitare;
• faptului că nu existau standarde acceptate.
O bază de date orientată pe obiecte trebuie să îndeplinească două cerinţe fundamentale:
• să îndeplinească cerinţele unei baze de date;
• să fie un sistem care să aibă la bază tehnologia orientată obiect.

Un obiect poate fi definit ca reuniune „într-o aceeaşi capsulă” a unui ansamblu de

date şi a prelucrărilor (standard) asociate (următoarea figură). Încapsularea este reuniunea
definiţiei statice a unui obiect prin atributele sale şi definirea dinamică a acestui obiect (cu
ajutorul regulilor de comportament). Aceste reguli sunt traduse cu ajutorul metodelor, care
reprezintă prelucrările asociate obiectelor. Obiectele sunt caracterizate printr-o structură şi o
interfaţă. Structura obiectului este reperată printr-un identificator intern unic şi posedă o stare
care regrupează în general atribute cu datele de tratat. Interfaţa unui obiect este compusă din
selectorul de metode (partea vizibilă a obiectului). Structura este cunoscută numai de către
obiect. Un obiect nu poate fi manipulat decât via metodele asociate.

Obiect

Descrierea dinamică
(modele de prelucrare)
Date
Descrierea statică
(modele de date)

Multe dintre obiectele manipulate posedă în comun aceeaşi structură şi acelaşi

comportament. O clasă descrie obiectele care au caracteristici statice şi dinamice comune.

Exemple.

Super-Clasa Persoana
Atribute
Nume
Adresa
DataNasterii
Metode
Nume
Returneaza(Self.Nume)
Adresa
Returneaza(Self.Adresa)
DataNasterii
Returneaza(Self.DataNasterii)

Clasa Salariat
Atribute
SalariuIncadrare
LocMunca
Responsabil
Metode
SalariuIncadrare
Returneaza(Self.SalariuIncadrare)
NumeResponsabil
Returneaza(Self.NumeResponsabil)

26
 O clasă (clasă derivată) poate moşteni de la o altă clasă (clasa de bază) atribute şi
metode. În exemplul de mai sus, clasa Salariat moşteneşte atributele şi metodele clasei
Persoana.
Tehnica moştenirii permite împărţirea eficace a anumitor cunoştinţe despre obiecte
pentru a obţine o reprezentare mai bogată în semantică. Datele cele mai generale se
grupează în clase care sunt în continuare specializate în subclase ce comportă atribute şi
comportamente din ce în ce mai particulare. La nivelul cel mai înalt va exista o superclasă
obiect de la care toate celelalte moştenesc (atribute, metode).
Clasa Salariat moşteneşte atributele, selectorii şi metodele superclasei Persoana. Ea
posedă în plus atribute şi metode proprii. Realizările clasei Salariat pot fi utilizate ca realizări
ale clasei Persoana şi pot poseda proprietăţi suplimentare.
Obiectele definite se integrează în sistem şi prezintă conexiuni cu alte obiecte. Aceste
conexiuni sunt materializate prin mesaje pe care obiectele le schimbă între ele. Aplicarea unei
metode la un obiect corespunde cu trimiterea unui mesaj. Receptorul mesajului se numeşte
Self.
Bazele de date orientate pe obiecte (BDOO) sunt gestionate folosind sisteme de
gestiune orientate pe obiecte (SGOO).
Principala caracteristică a BDOO este viteza de acces la date (în comparaţie cu
celelalte tipuri de Baze de date). Acest acces este asigurat prin intermediul unei hărţi a
ierarhiilor şi relaţiilor claselor de obiecte, pe care BDOO o stochează. De asemenea, permit
gruparea sau partiţionarea fizică a datelor, tehnică numită clustering. BDOO asigură
accesarea eficientă a obiectelor necesare la un moment dat unei cereri utilizator, minimizând
traficul prin reţea.
Domeniile în care este eficientă utilizarea BDOO sunt:
- simularea si modelarea diferitelor fenomene şi procese
- administrarea documentelor
- proiectele CASE (Computer Aided Software Engineering), CAD (Computer Aided
Design), CAM (Computer Aided Manufacturing), CAE (Computer Aided Engineering)
- multimedia
- ingineria cunoaşterii.

4.6 Alte tipuri de baze de date

Bazele de date textuale gestionează documente electronice. Principalele operaţii

asigurate sunt: stocarea, căutarea, modificarea şi asamblarea de documente şi alte informaţii
stocate cu titlu de date textuale în aceste baze de date.
Bazele de date multimedia extind aria de gestiune incluzând îndeosebi imagini,
sunete, etc.

4.7 Sisteme Client / Server

Sistemele Client/Server se fondează pe partajarea sarcinilor între două entităţi: server

şi client. Tehnologia client/server presupune două aplicaţii (următoarea figură):
• serverul, care furnizează diverse servicii;
• clientul, care este beneficiarul serviciilor oferite de server.

Cerere
Aplicaţie client Aplicaţie server

Răspuns

Cele mai răspândite aplicaţii client/server sunt cele cu baze de date; soft-ul pentru baza de
date este executat pe calculatorul server, iar programul care accesează baza de date pe un
calculator client.

27
 4.8 Bazele de date şi sistemele informaţionale din organizaţii
Bazele de date constituie componenta centrală a sistemelor informaţionale din
întreprinderi, în cadrul reprezentat în figura următoare:

SISE
SLIC

B
D SIM
SIAD
SIT
SIR

SIIO

unde notaţiile reprezintă:

• SIT – sisteme informaţionale tranzacţionale (sisteme informaţionale operaţionale);
• SLIC - sisteme de lucru bazate pe informaţie şi cunştinţe;
• SIIO - sisteme informaţionale interorganizaţionale (multe dintre aceste sisteme sunt
de tip tranzacţional);
• SISE - sisteme informaţionale suport pentru executiv
• SIM - sisteme informaţionale pentru management, care includ:
o SIAD - sisteme informaţionale de asistare a deciziei şi
o SIR sistemele imformaţionale de raportare.

Bazele de date sunt alimentate în principal de sistemele operaţionale şi sistemele

interorganizaţionale (sisteme de comerţ electronic, sisteme de plăţi electronice etc.) şi sunt
accesate de sistemele de management şi de sistemele suport pentru executiv. Ele pot fi, de
asemenea, accesate de sistemele de lucru bazate pe informaţie şi cunoştinţe (cum ar fi, spre
exemplu, sistemele expert). Structurile funcţionale şi de conducere din întreprinderi impun
organizarea de sisteme de baze de date care „comunică” între ele.

În figura următoare prezentăm o viziune (conform J. O’Brien, Les systèmes

d’information de gestion, 1995) a principalelor tipuri de baze de date utilizate de către
organizaţii şi utilizatori.

Post de lucru al
BD utilizatorului Server BD
distribuită de Baze de externe
date

BD
BD operaţionale
individuală
Depozite de
date

28
 Materiale privind funcţionalităţile moderne ale bazelor de date:
1. www.extropia.com/tutorials/sql/toc.html
Introducere în domeniul bazelor de date, pentru dezvoltatorii de web

2. http://www.service-architecture.com/object-oriented-databases/
Articole despre bazele de date orientate obiect şi produse pentru acestea

Despre baze de date multimedia

3. http://sunsite.berkeley.edu/Imaging/Databases/
4. [Tod04]

29
 5. Forme normale. Normalizare

5.1 Dependenţe funcţionale

Atributul Y este dependent funcţional de atributul X dacă şi numai dacă fiecare
valoare a atributului X este asociată cu exact o valoare a atributului Y. Se spune că X este
determinant al lui Y, sau că X determină pe Y şi se notează X→Y.

• Asocierile 1-1 prezintă două dependenţe funcţionale. De exemplu, între numele unei
persoane şi codul său numeric personal există o dependenţă 1-1, cele două atribute
determinându-se reciproc.
• Asocierile 1-n prezintă o dependenţă funcţională. De exemplu, între numele unui
student şi numărul său matricol: un număr matricol se asociază exact unui student;
dar mai mulţi studenţi pot avea acelaşi nume, astfel că un nume poate avea mai
multe numere matricole asociate.
• Asocierile m-n nu prezintă dependenţe funcţionale. De exemplu, între studenţi şi
cursuri există o corespondenţă de acest tip: fiecare student poate urma mai multe
cursuri şi fiecare curs poate avea mai multi studenţi, fără a se observa vreo corelaţie
între valori, în sensul definiţiei dependenţei funcţionale.

Utilizatorul care proiectează o aplicaţie determină dependenţele funcţionale

examinând mediul real. Deseori dependenţele înglobează anumite restricţii referitoare la
aplicaţia respectivă. Este o problemă de convenţie, de exemplu, ca un student să poată urma
mai multe cursuri, dar nu dintre cele care au loc în acelaşi interval de timp. Sau, ca un student
să aibă un singur număr matricol şi ca un număr matricol să poată fi asociat unui singur
student.

5.1.1 Descompunerea

Termenul descompunere se referă la faptul că informaţia inclusă într-o relaţie poate

fi splitată în două sau mai multe relaţii separate, fiecare dintre acestea având mai puţine
atribute decât relaţia originală. Cu alte cuvinte, atributele sunt plasate în tabele diferite.
Tuplele din noile relaţii vor fi determinate de atributele incluse. Scopurile descompunerii unei
relaţii sunt:
• Să reducă redundanţa datelor.
• Să păstreze capacitatea de a recrea relaţia originală, fără a pierde tupluri sau a
adăuga noi tupluri.

Procesul recreării tabelului original se numeşte uniune sau joncţiune (join). A se vedea
6.2.1.

Exemplu. În exemplul de mai jos sunt prezentate tabelele iniţiale, precum şi rezultatul
operaţiei join pe atributul Profesie.

Persoane Calităţi Rezultatul operaţiei join

Nume Profesie Profesie Calitate Nume Profesie Calitate
Andrei inginer inginer pragmatism Andrei inginer pragmatism
Carmen profesor profesor tact Carmen profesor tact
Silvia inginer pilot curaj Silvia inginer pragmatism
Traian pilot Traian pilot curaj

Este important ca descompunerile ce se realizează într-o bază de date să aibă loc fără
pierderi de informaţie, căci în caz contrar, informaţia trebuie restaurată.

30
 5.1.2 Asocierile şi proiectarea schemelor

Eleganţa matematică a modelului relaţional suportă o teorie a proiectării schemelor.

Teoria indică, într-o anumită măsură, ce structuri au probleme potenţiale şi ar trebui evitate.
Teoria normalizării oferă multe elemente foarte utile în procesul de proiectare a bazelor de
date.
După cum am observat deja, asocierile între datele aparţinând la două domenii, fie
acestea A şi B, se pot clasifica în trei categorii:
• asocieri 1-1
• asocieri n-1
• asocieri n-m
Vom ilustra fiecare tip de asociere în contextul unui exemplu.

Asocierile 1-1 sunt acelea în care fiecărui element din A i se pune în corespondenţă
un unic element din B şi reciproc. De exemplu, fiecare student are un număr matricol şi
fiecare număr matricol se asignează unui singur student. Tabelul următor prezintă o astfel de
asociere:

Număr matricol Nume student

21350 Ionescu Alina
21351 Mircea Diana
21576 Traian Alexandru
21577 Miron Vladimir
… …

Vom nota sintetic: Număr matricol (1-1) Nume student

Într-o asociere n-1, fiecărui element din B i se asociază un unic element din A, dar
fiecărui element din A i se pot asocia mai multe elemente din B. De exemplu, dacă plecăm de
la ipoteza că un student nu poate urma decât o specializare, atunci: un student urmează o
specializare, dar o specializare are mai mulţi studenţi. Aceasta este o relaţie n-1 între studenţi
şi specializări (sau 1-n între specializări şi studenţi). Tabelul următor prezintă o astfel de
asociere:

Număr matricol Specializare

21350 Informatică
21351 Informatică
21576 Biologie
21577 Biologie
… …

Vom nota sintetic: Număr matricol (n-1) Specializare

Asocierile n-m sunt acelea în care nici unui element nu i se asociază un singur
partener. O astfel de relaţie este cea între studenţi şi cursuri. Fiecare student urmează mai
multe cursuri, iar fiecare curs are mai mulţi studenţi. Nu există limite în ceea ce priveşte
numărul partenerilor de asociere.

Vom nota sintetic: Număr matricol (n-m) Cursuri

5.2 Dependenţe multivaloare

Fie R o schemă relaţională, X şi Y submulţimi ale lui R. Spunem că există o
dependenţă multivaloare a lui Y de X sau că X determină multivaloare pe Y şi notăm X→→Y
dacă, pentru orice valoare a atributelor lui X sunt asociate valori pentru atributele lui Y care nu
sunt corelate în nici un fel cu atributele din R-X-Y.

31
Exemplu. Fie relaţia

ORAR
CURS PROFESOR ORA LOCATIE STUDENT AN-STUDIU
Algebră Ionescu T. 10 A45 Miron Călin 1
Algebră Ionescu T. 10 A45 Matei Ruxandra 1
Programare Dinu A. 8 C9 Gruia Alina 2
Programare Dinu A. 8 C9 Traian Maria 2
Engleză Bontaş E. 16 C22 Miron Călin 1
Engleză Bontaş E. 16 C22 Matei Ruxandra 1
Engleză Bontaş E. 18 C22 Horia Anca 3

Se manifestă următoarele dependenţe funcţionale:

• CURS → PROFESOR (fiecare curs are un singur profesor)
• ORA, LOCATIE → CURS (la o oră dată, într-o anumită sală se poate ţine un singur curs)
• ORA, PROFESOR → LOCATIE (la o anumită oră, un profesor se poate afla în cel mult o
sală)
• CURS, STUDENT → AN-STUDIU (fiecare student urmează un curs într-un anumit an de
studiu)
• ORA, STUDENT → LOCATIE (fiecare student se poate afla în cel mult o sală, la un
moment dat).
Au loc dependenţele multivaloare
• CURS →→ ORA, LOCATIE
care semnifică faptul că fiecărui curs i se asociază o mulţime de perechi de ore şi săli care nu
depind în nici un fel de celelalte informaţii. În schimb nu au loc, în general, dependenţele
multivaloare CURS → ORA sau CURS → LOCATIE.

5.3 Forme normale ale bazelor de date

O formă normală se referă la o clasă de scheme relaţionale care se supun unui set
de reguli. O schemă care satisface regulile corespunzătoare unui set se spune că este în
forma normală respectivă. De obicei, proiectantul unei baze doreşte ca relaţiile să se afle în
cât mai multe forme normale posibil.

5.3.1. Date ne-normalizate

Următorul tabel conţine date ne-normalizate. Coloanele 2, 3 şi 4 conţin liste de valori,

iar coloana 5 conţine un atribut compus.

Listă Listă Listă Valori

compuse
Legitimaţie Cod Categorie Profil Nume Vârstă Birou Oraş Superior
Calificări Calificări nr.
21 113 Sisteme 3 Mareş 29 1 Iaşi Ion
Ana
35 113 Sisteme 5 Ionescu 33 2 Bucureşti Damian
170 Taxe 7 Dan
200 Audit 4
50 170 Taxe 3 Mircea 35 2 Bucureşti Damian
Călin
77 150 Consultanţă 5 Traian 28 1 Iaşi Ion
200 Audit 8 Raluca

32
 5.3.2 Prima formă normală (FN1)

O relaţie se prezintă în FN1 dacă valorile fiecărui câmp sunt ne-decompozabile

(atomice) şi fiecare tuplu este unic. Atributele care se pot partiţiona în sub-atribute sau
grupurile repetitive, care sunt foarte comune în bazele de date, nu sunt permise.
De exemplu, o persoană poate avea mai multe calificări. Dacă acestea sunt listate în
acelaşi câmp (ca în tableul de mai sus), atunci relaţia nu se află în prima formă normală. La
fel, dacă un câmp este comus, în genul unei adrese, formate din oraş, stradă, număr, cod
poştal. Dacă un câmp este considerat structurat sau nu, aceasta depinde în mare măsură de
aplicaţie. Dacă prelucrările nu necesită acces după oraş, sau stradă, sau cod poştal atunci
este potrivit sa păstrăm aceste date într-un singur câmp, dar dacă este necesar să sortăm
după unul din aceste elemente, de exemplu după cod poştal, atunci această abordare nu mai
este potrivită.
Utilitatea FN1 este evidentă. Grupurile repetitive „strică” natura tabelară a relatie.
Este dificil să se refere un element anume din grupul repetitiv, căci ar trebui specificată o
informatie cu privire la poziţia sa în grup. Mai mult, diferite părţi ale atributului se pot comporta
foarte diferit din punct de vedere al dependenţelor. Regula FN1 surprinde cerinţa naturală ca
fiecare atribut să aibă propriul său nume. Următorul tabel prezintă datele tabelului anterior,
structurate în FN1. În toate relaţiile ce vor fi prezentate, cheia primară este subliniată.

Cod Bi
Legiti Categorie Pro Prenu Vâr
Califi Nume rou Oraş Superior
maţie Calificări fil me stă
cări nr.
21 113 Sisteme 3 Mareş Ana 29 1 Iaşi Ion
35 113 Sisteme 5 Ionescu Dan 33 2 Bucureşti Damian
35 170 Taxe 7 Ionescu Dan 33 2 Bucureşti Damian
35 200 Audit 4 Ionescu Dan 33 2 Bucureşti Damian
50 170 Taxe 3 Mircea Călin 35 2 Bucureşti Damian
77 150 Consultanţa 5 Traian Raluca 28 1 Iaşi Ion
77 200 Audit 8 Traian Raluca 28 1 Iaşi Ion

Informaţiile aflate doar în FN1 prezintă un înalt grad de redundanţă. Pentru a reduce
redundanţa vom converti datele la a doua formă normală.
Formele normale mai mari decât FN1 au fost motivate de descoperirea anomaliilor,
deci a operaţiilor pe relaţii din care rezultă inconsistenţe sau pierderi nedorite ale adtelor.
Înlăturarea anomaliilor necesită trecerea progresivă prin diferite nivele ale formelor normale.
Această transformare urmăreşte un ideal: fiecare informaţie care presupune asocieri între
date să apară o singură dată în bază şi să nu depindă de prezenţa altor asocieri.

5.3.3 A doua formă normală (FN2)

O relaţie este în FN2 dacă este în FN1 şi toate atributele sale sunt dependente de
întreaga cheie (adică, nici unul din atributele non-cheie nu este relaţionat doar cu o parte a
cheii). Tehnica de descompunere pentru obţinerea FN2 este foarte simplă: presupune
construirea unei relaţii separate care sa inglobeze dependenţele parţiale şi să înlăture
atributele dependente din relaţia originală.
Pentru exemplul considerat, în urma eliminării dependenţelor parţiale s-au obţinut
următoarele trei relaţii.

Relaţia CADRE:
Bi
Legiti Prenu Vâr
Nume rou Oraş Superior
maţie me stă
nr.
21 Mareş Ana 29 1 Iaşi Ion
35 Ionescu Dan 33 2 Bucureşti Damian
50 Mircea Călin 35 2 Bucureşti Damian
77 Traian Raluca 28 1 Iaşi Ion

33
Se observă că numele şi prenumele, vârsta şi informaţiile referitoare la grupul din care
persona face parte (numărul biroului, orasul, şeful direct) sunt corelate direct cu numărul de
legitimaţie (am putea spune că „depind de” numărul de legitimaţie) şi nu depind de calificare.

Relaţia CALIFICĂRI:
Cod Categorie
Calificări Calificări
113 Sisteme
170 Taxe
200 Audit
150 Consultanţa

În acest caz, categoria calificării este determinată de codul calificării şi nu depinde de

numerele de legitimaţie ale cadrelor.

Relaţia COMPETENŢE:
Legiti Cod
Competenţe
matie Calificări
21 113 3
35 113 5
35 170 7
35 200 4
50 170 3
77 150 5
77 170 8

În acest caz, competenţa este determinată de combinaţia celor două chei (legitimaţie şi cod
calificare).

5.3.4 A treia formă normală (FN3)

O relaţie este în FN3 dacă este în FN2 şi nu există nici un fel de dependenţe
tranzitive (adică, nici unul din atributele non-cheie nu este dependent de alt atribut, care la
rândul său este dependent de cheia relaţiei).
Aceasta înseamnă că nu există nici o pereche (sau o pereche de mulţimi de atribute) X şi Y
pentru care să apară succesiunea:
Cheie X X Y
unde X este o cheie non-candidată.
O altă modalitate de a privi a treia formă normală este dată de faptul că ea rezultă din
relaţii ce reprezintă entităţi şi relaţii ce reprezintă asocieri între entităţi. O descompunere
corespunzătoare, prin care o schemă se poate converti la a treia formă normală, este aceea
prin care acele atribute care nu sunt direct (sau, sunt doar tranzitiv) dependente de cheie sunt
plasate într-o relaţie separată. Această descompunere prezintă două caracteristici importante:
• Fiecare dependenţă este concretizată printr-o relaţie (deci descompunerea păstrează
dependenţele).
• Dacă o extensie a relaţiei originale este descompusă, ea poate fi reconstruită prin
intermediul unui JOIN, din componente (fără pierderi).
În general, orice schemă poate fi adusă la a treia formă normală, cu păstrarea dependenţelor
şi cu operaţii join fără pierderi de date. Pentru exemplul considerat, datele în FN3 se prezintă
după cum urmează.

Relaţia CADRE:
Bi
Legiti Prenu Vâr
Nume rou Oraş Superior
maţie me stă
nr.
21 Mareş Ana 29 1 Iaşi Ion
35 Ionescu Dan 33 2 Bucureşti Damian
50 Mircea Călin 35 2 Bucureşti Damian
77 Traian Raluca 28 1 Iaşi Ion

34
Relaţia BIROURI:
Bi
rou Oraş Superior
nr.
1 Iaşi Ion
2 Bucureşti Damian

Relaţia CALIFICĂRI:
Cod
Categorie
Califi
Calificări
cări
113 Sisteme
170 Taxe
200 Audit
150 Consultanţa

Relaţia COMPETENŢE:
Legiti Cod
Competenţe
matie Calificări
21 113 3
35 113 5
35 170 7
35 200 4
50 170 3
77 150 5
77 170 8

5.3.5 Forma normală Boyce-Codd (FNBC)

Spunem că o relaţie R cu dependenţele F se află în forma normală Boyce-Codd

(FNBC) dacă, oricare ar fi dependenţa X→A cu A atribut neconţinut în X, există o cheie a lui
R conţinută în X.
Orice relaţie în forma normală Boyce-Codd este în FN3, dar reciproca nu este
adevărată.
Exemplu. Relaţia R cu schema R(A, B, C), cu cheile AC şi BC şi cu dependenţele
funcţionale F={AB→C, C→A}. R este în a treia formă normală, dar nu este în forma normală
Boyce-Codd deoarece cheile acestei relaţii sunt AC şi BC, iar pentru dependenţa C→A
partea stângă nu conţine nici una din cele două chei.
Pentru problema de a determina dacă o relaţie este în FNBC nu există (în general)
algoritmi eficienţi de rezolvare.

5.3.6 A patra formă normală (FN4)

Fie R o schemă relaţională şi D o mulţime de dependenţe funcţionale şi multivaloare

pe R. Spunem că R este în FN4 dacă, pentru orice dependenţă multivaloare X→→Y cu Y
neinclusă în X şi XY inclusă în R, există cheie a lui R inclusă în X.
Cu alte cuvinte, o relaţie R este în FN4 dacă este în FNBC şi orice dependenţă
multivaloare este, de fapt, o dependenţă funcţională.
Dacă D conţine numai dependenţe funcţionale şi R este în FN4, atunci R este în
FNBC.

Exemplu. Fie relaţia ORAR prezentată în 5.2. Singura cheie a relaţiei este formată din
atributele STUDENT şi ORA. Dependenţa CURS →→ ORA, LOCATIE nu respectă condiţia
din FN4 deoarece CURS nu conţine o cheie. Vom descompune relaţia în:

35
CURSURI
CURS ORA LOCATIE
Algebră 10 A45
Programare 8 C9
Engleză 16 C22

care are cheia ORA, LOCATIE şi este în FN4 şi

ORAR1
CURS PROFESOR STUDENT AN-STUDIU
Algebră Ionescu T. Miron Călin 1
Algebră Ionescu T. Matei Ruxandra 1
Programare Dinu A. Gruia Alina 2
Programare Dinu A. Traian Maria 2
Engleză Bontaş E. Miron Călin 1
Engleză Bontaş E. Matei Ruxandra 1
Engleză Bontaş E. Horia Anca 3

care are cheia CURS, STUDENT dar nu este în FN4 deoarece prezintă dependenţa
CURS →→ PROFESOR care rezultă din CURS → PROFESOR şi CURS nu conţine o cheie.
Descompunem ORAR1 în:

PROFESORI
CURS PROFESOR
Algebră Ionescu T.
Programare Dinu A.
Engleză Bontaş E.

şi

STUDENTI
CURS STUDENT AN-STUDIU
Algebră Miron Călin 1
Algebră Matei Ruxandra 1
Programare Gruia Alina 2
Programare Traian Maria 2
Engleză Miron Călin 1
Engleză Matei Ruxandra 1
Engleză Horia Anca 3

care sunt ambele în FN4.

Deci, descompunerea relaţiei ORAR în {CURSURI, PROFESORI, STUDENTI} se află
în FN4 şi este fără pierderi la uniune.

5.3.7 A cincea formă normală (FN5)

Se spune că o relaţie R satisface dependenţa de uniune (join dependency) şi se

notează cu
*(X,Y,…,Z)
dacă şi numai dacă R este egală cu uniunea proiecţiilor lui R pe X,Y,…,Z, acestea fiind
submulţimi ale lui R.
O relaţie R este în FN5 (numită şi forma normală proiecţie-uniune) dacă şi numai
dacă orice dependenţă de uniune a lui R este o consecinţă a unei chei candidat a lui R.
Orice relaţie care este în FN5 este şi în FN4, deoarece fiecare dependenţă
multivaloare poate fi privită ca un caz particular de dependenţă de uniune. Orice relaţie poate
fi descompusă fără pierderi la uniune într-o mulţime de relaţii care sunt în FN5.
Pentru a preciza dacă o relaţie este în FN5, este suficient să cunoaştem cheile
candidate şi toate dependenţele de uniune din R.

36
 5.3.8. Procesul normalizării relaţiilor

Procesul de normalizare a relaţiilor se poate descrie în felul următor:

1. Se proiectează relaţia iniţială, aflată în FN1, pe alte relaţii, pentru a elimina dependenţele
funcţionale care nu sunt complete. Se obţine o mulţime de relaţii în FN2.
2. Se proiectează relaţiiile obţinute în pasul 1 pe alte relaţii, pentru a elimina dependenţele
funcţionale tranzitive. Se obţine o mulţime de relaţii în FN3.
3. Se proiectează relaţiiile obţinute în pasul 2 pe alte relaţii, pentru a elimina dependenţele
în care partea din stânga nu este o supracheie. Se obţine o mulţime de relaţii în FNBC.
4. Se proiectează relaţiiile obţinute în pasul 3 pe alte relaţii, pentru a elimina toate
dependenţele multivaloare care nu sunt şi dependenţe funcţionale. Se obţine o mulţime
de relaţii în FN4.
5. Se proiectează relaţiiile obţinute în pasul 4 pe alte relaţii, pentru a elimina orice
dependenţă de uniune care nu este implicată de o cheie. Se obţine o mulţime de relaţii în
FN5.

De obieci, forma normală FN3 este suficientă, iar alteori chiar FN2 este suficientă.

Materiale privind normalizarea:

1. [Fel96]
Dependenţe între date

2. [Bas97]
Forme normale şi normalizare

3. http://databases.about.com/od/ specificproducts/a/normalization.htm
Despre normalizare

4. http://en.wikipedia.org/wiki/Database_normalization
Definiţia normalizării în enciclopedia wikipedia

5. http://www.datamodel.org/NormalizationRules.html
5 reguli pentru normalizarea datelor

6. http://www.fmsinc.com/tpapers/datanorm/
Fundamente ale normalizării datelor

37
 6. Limbaje utilizate în lucrul cu baze de date

6.1 Limbajul de definire a datelor pentru modelul relaţional

Schema unei baze de date relaţionale este declarată utilizând un limbaj de definire
a datelor (LDD). Un LDD relaţional este simplu. Fiecare relaţie trebuie să fie declarată:
atributele sale să fie definite, trebuie să fie specificat un domeniu pentru fiecare atribut şi
trebuie aleasă o cheie.
O abordare simplă, valabilă pentru multe baze de date relaţionale, este aceea prin
care fiecărei relaţii i se asociază un fişier. Sunt posibile şi alte abordări, dar necesită
implementări mult mai complexe. Imaginile următoare prezintă modalitatea de definire a
atributelor unei noi relaţii în ACCESS, precum şi adăugarea relaţiei la bază.

38
 6.2 Limbajul de manipulare a datelor pentru modelul relaţional
Se cunosc foarte multe abordări în ceea ce priveşte limbajele de manipulare a
datelor (LMD) organizate relaţional. Cele mai multe dintre acestea sunt interactive, proiectate
pentru folosirea conversaţională de către un utilizator care aşteaptă un răspuns imediat.
Există patru sarcini de bază pe care trebuie să le realizeze un limbaj de manipulare a
datelor:
• Inserarea datelor noi.
• Ştergerea datelor vechi.
• Actualizarea datelor.
• Consultarea datelor.
Aceste funcţii se regăsesc – într-o formă sau alta – în orice limbaj de manipulare a datelor.
Complexitatea cea mai mare a operaţiilor unui limbaj de manipulare a datelor se
referă la ultima categorie de prelucrări: consultarea datelor. Inserarea, ştergerea şi
actualizarea sunt, de obicei, operaţii clare şi sunt realizate de un utilizator experimentat (sau
de un program de aplicaţie), cunoscându-se exact ce trebuie modificat şi unde. Operaţiile de
consultare sau cerere de date (query), pe de altă parte, sunt deseori realizate de utilizatori
care fie nu ştiu de la început ce caută, fie îşi exprimă cerinţele într-un mod foarte complicat.
Din această cauză, limbajele de manipulare a datelor sunt uneori numite limbaje de cereri
(query languages).
În cele ce urmează vom prezenta, prin intermediul unor exemple, trei abordări ale
limbajului de cereri în modelul relaţional:
• Algebra relaţională.
• Calculul pe tupluri.
• Calculul pe domenii.
Aceste trei limbaje s-au dovedit a fi echivalente, în sensul că orice cerere ce poate fi
exprimată în unul din limbaje poate fi exprimată şi în celelalte două. Diferenţa constă în
facilitatea scrierii cererii respective.

6.2.1 Algebra Relaţională

Algebra Relaţională furnizează instrumente pentru exprimarea procedurală a cererilor

de date. Constă dintr-o colecţie de operaţii pe relaţii, fiecare operaţie având drept operanzi
una sau mai multe relaţii şi producând ca rezultat o altă relaţie.
E.F. Codd a introdus Algebra Relaţională Standard, constituită din:
• 5 operaţii de bază:
o Reuniunea
o Diferenţa
o Produsul cartezian
o Proiecţia
o Selecţia
• 3 operaţii derivate:
o Joncţiunea
o Intersecţia
o Diviziunea.
Ulterior, la Algebra Relaţională Standard au fost adăugate şi alte operaţii, aşa-numitele
operaţii adiţionale sau extensii ale Algebrei Relaţionale Standard, cum ar fi:
o Complementara
o Splitarea
o Închiderea tranzitivă.

În cele ce urmează presupunem că relaţia R are gradul r iar S are gradul s.

• Reuniunea. Pentru două relaţii R şi S se poate nota: RUS, UNION(R,S), ADD(R,S).
Reuniunea relaţiilor R şi S este mulţimea tuplurilor care se găsesc în cel puţin una din
relaţiile R sau S. Această operaţie se poate aplica numai în cazul în care R şi S au
aceeaşi schemă. Dacă atributele au nume se cere ca, în plus, cele două liste de
nume să coincidă şi rezultatul va avea aceeaşi listă de nume pentru atribute.

39
• Diferenţa. Pentru două relaţii R şi S se poate nota: R-S, MINUS(R,S), REMOVE(R,S).
Diferenţa relaţiilor R şi S este mulţimea tuplurilor din R care nu sunt în S. Este
necesar să fie îndeplinite aceleaşi condiţii ca pentru reuniune.
• Produsul cartezian. Pentru două relaţii R şi S se poate nota: R×S, PRODUCT(R,S),
TIMES(R,S). Produsul cartezian al relaţiilor R şi S este mulţimea tuplurilor cu r+s
componente, în care primele r componente reprezintă un tuplu în R iar ultimele s
componente reprezintă un tuplu în S. Dacă atributele au nume, lista numelor
atributelor din rezultat este reuniunea disjunctă a celor două liste (folosind calificări
sau redenumiri pentru atributele cu aceleaşi nume în cele două relaţii).
• Proiecţia. Fie relaţia R de grad r. Proiecţia relaţiei R după atributele c1, c2,…, ck (k<=r) se
notează πc1, c2,…, ck(R), PROJECT(R; c1, c2,…, ck) şi este mulţimea tuplurilor de aritate
k în care se păstrează doar valorile corespunzătoare atributelor menţionate explicit în
proiecţie. Dacă relaţia R are asociate nume pentru atribute, acestea se pot păstra în
relaţia rezultată. Se observă că acesastă operaţie corespunde unor „tăieturi verticale”
în R.
• Selecţia. Fie F o formulă logică formată din operanzi care sunt constante sau nume de
componente în tupluri şi operatori aritmetici şi/sau logici. Selecţia relaţiei R în raport
cu formula F se notează σF(R), SELECT(R; F) şi reprezintă mulţimea tuplurilor din R
pentru care formula F devine adevărată. Relaţia rezultat are pentru atribute aceleaşi
nume ca şi relaţia R. Toate constantele care apar în F sunt incluse între apostrofuri.

Operaţiile derivate se pot exprima în funcţie de operaţiile de bază. Utilizarea acestora

permite o exprimare mai simplă a cererilor şi, dacă sunt bine implementate, obţinerea unui
răspuns mai rapid.

• Joncţiunea. Este numită şi uniune sau join. O θ-uniune a relaţiilor R şi S după

coloanele i şi j, unde θ este un operator de comparaţie este notată UNION(R,S; iθj),
JOIN(R,S; iθj) sau R Xiθj S este constituită din mulţimea tuplurilor produsului cartezian
dintre R şi S, pentru care a i-a componentă a lui R se află în relaţia θ cu a j-a
componentă a lui S. Dacă R şi S au nume pentru atribute, în loc de i şi j se pot folosi
numele atributelor corespunzătoare. Joncţiunea este o operaţie derivată deoarece se
poate exprima cu ajutorul operaţiilor de bază prin formula: R Xiθj S= σiθ(r+j) (R×S).
Dacă θ este operatorul =, operaţia se numeşte echiuniune sau echijoin.
Un caz particular de joncţiune este joncţiunea naturală. Uniunea naturală a relaţiilor
R şi S, notată R X S, se aplică dacă cele două relaţii au nume asociate atributelor şi,
în acest caz, se selectează din produsul cartezian al relaţiilor R şi S acele tupluri ce
conţin valori comune pentru câmpurile cu aceleaşi nume din cele două relaţii şi apoi
se elimină valorile din câmpurile lui S comune cu cele din R.
• Intersecţia. Intersecţia relaţiilor R şi S, notată R∩S, INTERSECT(R,S), AND(R,S), este
constituită din mulţimea tuplurilor care se găsesc în ambele relaţii. Se aplică în
condiţiile specificate la reuniune. Intersecţia se poate exprima prin operaţiile de bază
cu formula: R∩S=R-(R-S).
• Diviziunea. Fie relaţiile R de aritate r şi S de aritate s, cu r >s şi S≠Φ. Diviziunea sau
câtul lui R prin S, notat R÷S, este mulţimea tuplurilor a de aritate r-s astfel încât,
pentru orice tuplu b al lui S, tuplul ab este în R. Dacă atributele celor două relaţii au
nume, atunci lista atributelor lui S trebuie să fie o submulţime a listei atributelor lui R
iar rezultatul are ca listă de atribute diferenţa celor două liste. Câtul se poate exprima
prin operaţiile de bază cu formula: R÷S= π1, 2,…, r-s(R)- π1, 2,…, r-s(π1, 2,…, r-s(R)×S)-R).

Exemplul 1. Fie relaţiile R şi S, cu schemele şi extensiile prezentate mai jos:

R S
A B C D E F
a b c b g a
d a f d a f
c b d

40
În acest caz, rezultatele aplicării operatorilor: reuniune, diferenţă, produs cartezian, proiecţie,
selecţie şi intersecţie asupra relaţiilor R şi S (cu precizările indicate pentru proiecţie şi
selecţie) sunt:

RUS R-S
a b c a b c
d a f c b d
c b d
b g a

R×S πA,C(R),
a b c b g a a c
a b c d a f d f
d a f b g a c d
d a f d a f
c b d b g a
c b d d a f
σ B=”b” (R), R ∩S
a b c d a f
c b d

Exemplul 2. Fie relaţiile R şi S, cu schemele şi extensiile următoare:

R S
A B C D E F
a b c d c d
a b e f e f
b c e f
e d c d
e d e f
a b d e

În acest caz, câtul lui R prin S este:

R÷S
a b
e d

Exemplul 3. Fie relaţiile R şi S, cu schemele şi extensiile de mai jos:

R S
A B C D E
1 2 3 3 1
4 5 6 6 2
7 8 9
În acest caz, joncţiunea lui R cu S cu B<D este:

R XB<D S
A B C D E
1 2 3 3 1
1 2 3 6 2
4 5 6 6 2

41
Exemplul 4. Fie relaţiile R şi S, cu schemele şi extensiile actuale:

R S
A B C B C D
a b c b c d
d b c b c e
b b f a d b
c a d

În acest caz, joncţiunea naturală a lui R cu S este:

R XS
A B C D
a b c d
a b c e
d b c d
d b c e
c a d b

Exemplul 5. Fie următoarea schemă:

Relaţia ANGAJATI
Nume câmp Tip Cheie
Marca Număr Da
Nume Text 20
Prenume Text 20
Initiala_tatalui Text 1
Data_angajarii Dată

Relaţia CHITANTE
Nume câmp Tip Cheie
Numar_chitanta Număr Da
Data Dată
Total Număr
Avans Număr
Numar_cont Text 9
Credit_card Număr
Tip_card Text 2
Marca Număr

Să se scrie o cerere prin care să se obţină un tabel cu următoarele date:

Numar_chitanta, Data, Total, Marca, Nume, Prenume
pentru toate chitanţele exprimând plăţi salariale efectuate înainte de luna martie 2005.

În cazul acestei cereri, sunt necesari operatorii: Selecţie, Proiecţie şi Joncţiune. Cererea
formulată se poate exprima, în limbajul algebrei relaţionale, prin secvenţa:

LIST JOIN(CHITANTE, ANGAJATI )

SELECT(Date&<3/1/05)
PROJECT(Numar_chitanta, Data, Total_chitanta, Marca, Nume, Prenume)

Materiale privind Algebra Relaţională:

1. www.cs.rochester.edu/users/faculty/nelson/courses/csc_173/relations/algebra.html
2. www.cs.sfu.ca/CC/354/zaiane/material/notes/Chapter3/node7.html
3. http://cs.wwc.edu/~aabyan/415/RelAlg.html

42
 6.2.2 SQL

Unul dintre cele mai puternice limbaje structurate pentru interogarea bazelor de date
relaţionale îl constituie SQL (Structured Query Language). Pe lângă manipularea şi regăsirea
datelor, limbajul permite efectuarea de operaţii complexe privind actualizarea şi administrarea
bazelor de date.
SQL este un limbaj neprocedural sau declarativ, deoarece utilizatorul lui descrie
numai informaţiile pe care vrea să le obţină în urma interogării, fără a fi nevoie să stabilească
modalităţile de a ajunge la rezultatele dorite. În acelaşi timp, SQL nu poate fi considerat un
limbaj de programare sau unul de sistem ci, mai curând, face parte din categoria limbajelor de
aplicaţii, fiind orientat pe mulţimi. Foarte frecvent, limbajul SQL este utilizat în administrarea
bazelor de date client/server, aplicaţia client fiind aceea care generează instrucţiunile SQL.
Există un anumit grad de standardizare a limbajului SQL, mai multe sisteme de
gestiune a bazelor de date recunoscând principalele instrucţiuni ale acestuia (de exemplu:
Oracle, Access, Sybase etc.). Pe plan mondial, standardul în domeniu este considerat ANSI
(American National Standards Institute) SQL care are în vedere atât aspectele de definire,
interogare, manipulare a datelor, procesare a tranzacţiilor, cât şi caracteristicile complexe
privind integritatea informaţiilor. Mulţi producători de sisteme de gestiune a bazelor de date
furnizează propriile extensii ale limbajului SQL, asigurându-şi astfel exclusivitatea.
Se cunosc în literatura de specialitate trei metode de bază privind implementarea
limbajului SQL şi anume:
• cea prin apelare directă (Direct Invocation) - constă în introducerea instrucţiunilor
SQL de la prompter;
• cea modulară (Modul Language) - foloseşte anumite proceduri apelate de programele
aplicaţiei;
• cea de tip încapsulat (Embedded SQL) - are în vedere instrucţiunile încapsulate în
codul de program, fiind de tip static şi dinamic.

În cazul exemplului 5 considerat mai sus, cererea SQL are forma:

SELECT
Numar_chitanta, Data, Total_chitanta, CHITANTE.Marca, Nume, Prenume
FROM
CHITANTE, ANGAJATI
WHERE
Date&<3/1/05 AND CHITANTE.Marca# ="ANGAJATI.Marca#"

În Access, cererea SQL are forma:

6.2.3 Calculul Relaţional orientat pe tupluri

O expresie de calcul pe tupluri este, în esenţă, o definiţie non-procedurală a unei

relaţii, în termenii unei mulţimi de relaţii date. O astfel de expresie este constituită din variabile
tuplu, condiţii şi formule bine formate.

În cazul exemplului 5:
Cererea în QUEL, limbajul de cereri al SGBD INGRES, are forma:

range of c is CHITANTE range of a is ANGAJATI

retrieve
(c.Numar_chitanta, c.Data, c.Total, c.Marca, a.Nume, a.Prenume)

43
 where
c.Data < 3/1/05 and c.Marca=”a.Marca”

Cererea în Access are forma:

6.2.4 Calculul Relaţional orientat pe domenii

Calculul pe domenii diferă de calculul pe tupluri prin aceea că variabilele sunt, în

acest caz, comenii şi nu relaţii. Şi aici, o expresie de calcul orientată pe domenii este alcătuită
din variabile domeniu, condiţii şi formule bine formate.

În cazul exemplului 5, cererea în Borland Paradox are forma:

CHITANTE
Numar_chitanta Data Total Avans Numar_cont Credit_card Tip_card Marca
3 3=3/1/05 3pers

ANGAJATI
Marca Nume Prenume Initiala_tatalui Data_angajarii
3pers 3 3

Materiale privind limbajele pentru baze de date:

1. www.freewebmasterhelp.com/tutorials/phpmysql/1
Tutorial PHP şi MySQL
2. www.w3schools.com/sql/default.asp
Tutorial SQL
3. www.w3schools.com/sql/default.asp
Tutorial XML
4. [Nas00]
Limbajul Visual Basic pentru Access 2000

44
 7. Restricţiile de integritate ale modelului relaţional
Integritatea bazelor de date este dată, în principiu, de corectitudinea informaţiilor
conţinute în acestea şi presupune detectarea, corectarea şi prevenirea diferitelor erori
neintenţionate privind informaţiile introduse în bazele de date.
Restricţiile de integritate (RI), denumite şi reguli de integritate, definesc cerinţele pe
care trebuie să le satisfacă datele din cadrul bazei de date relaţionale pentru a putea fi
considerate corecte şi coerente în raport cu sistemul real pe care îl reflectă.
În bazele de date relaţionale, relaţiile sunt toate la acelaşi nivel iar setul de operatori
este relativ restrâns, neputând exprima semantica operaţională a obiectelor complexe. Acest
aspect ramâne în sarcina programatorilor de aplicaţie. Totuşi, sistemele relaţionale deţin o
serie de mecanisme pentru tratatrea aspectelor de ordin semantic.
Restricţiile de integritate ale modelului relaţional sunt de două tipuri:

• RI structurale, care se definesc prinegalitatea sau inegalitatea unor valori din cadrul
relaţiilor. Din această cattegorie fac parte:
o Restriţiile de unicitate a cheii
o Restricţia referenţială
o Restricţia entităţii
o Dependenţa între date.

• RI de comportament, proprii unei anumite baze de date relaţionale, ce ţin cont de

semnificaţia valorilor din cadrul bazei respective. Se pot defini RI de comportament foarte
diverse: temporale, de domeniu, etc. De exemplu, faptul că vărsta unei persoane trebuie
să se plaseze între anumite limite constituie o restricţie de domeniu.

Utilizarea modelului relaţional nu impune definirea şi verificarea tuturor acestor tipuri de

restricţii. Din acest punct de vedere, putem considera că există:
• RI minimale – obligatoriu de definit şi de respectat. Din această categorie fac parte
restricţia de integritate a cheii, restricţia referenţială, restricţia entităţii.
• Alte RI – categorie din care fac parte dependenţele între date, restricţiile de
comportament.

7.1 Restricţii de integritate minimale

Cheia unei relaţii R reprezintă un ansamblu minimal de atribute prin care se poate
identifica în mod unic orice tuplu din R. Orice relaţie posedă cel puţin o cheie. La limită, cheia
este constituită fie dintr-un singur atribut, fie din totalitatea atributelor din schema relaţiei
respective.
Când cheia este constiituită dintr-un singur atribut ea poartă numele de cheie simplă
iar când este formată din mai multe atribute este denumită cheie compusă.

Exemplu. În relaţia R1 atributul A este cheie, în timp ce în relaţia R2 cheia trebuie formată
din atributele A şi B:
R1: R2:
A B A B
a1 b1 a1 b1
a2 b3 a1 b2
a3 b2 a2 b3
a4 b3 a3 b2

Într-o relaţie pot exista mai multe combinaţii de atribute cu proprietatea de identificare
unică a tuplurilor. Se spune în acest caz caz că relaţia posedă mai multe chei candidate. În
această situaţie, administratorul bazei va alege dintre cheile candidate una care să servească
efectiv la identificarea tuplurilor şi care se va numi cheie primară. Restul cheilor candidate se
vor numi chei alternate.

45
 Cheia unei relaţii trebuie sa fie minimală, în sensul că nici o parte a sa nu trebuie să
posede proprietatea de identificare unică a tuplurilor relaţie.
O cheie externă reprezintă un atribut sau un grup de atribute dintr-o relaţie R1 ale
cărui/căror valori sunt deinite pe acelaşi/aceleaşi domeniu/domenii ca şi cheia primară a unei
alte relaţii R2 şi care are rolul de a modela asocierea între entităţile reprezentate prin relaţiile
R1 şi R2. În acest context, R1 este numită relaţie care referă, în timp ce R2 poartă numele de
relaţie referită.
Exemplu. În relaţia ANGAJATI atributul Marca este cheie primară, în timp ce atributul
Cod_departament este cheie externă, servind la modelarea asocierii între angajaţi şi
departamente. În relaţia DEPARTAMENTE, cheia Departament este cheie primară.

ANGAJATI: DEPARTAMENTE:
Marca Nume Cod_departament Departament Denumire
11 N1 1 1 Tehnic
22 N2 2 2 Personal
33 N3 1 3 Administrativ
44 N4 3
55 N5 3
66 N6 2
77 N7 1

Modelul relaţional prezintă următoarele restricţii de integritate minimale:

• Restricţia de unicitate a cheii. Reprezintă restricţia care impune ca într-o relaţie R cu
cheia K, oricare ar fi tuplurile t1 şio t2 să fie satisfăcută inegalitatea t1(K) ≠ t2(K).

• Restricţia referenţială (integritatea referirii). Reprezintă restricţia care impune ca într-o

relaţie R1 care referă o relaţie R2, valorile cheii externe să figureze printre valorile
cheii primare din relaţia R2 sau să fie valori null (nedefinite). R1 şi R2 nu trebuie să
fie neapărat distincte. Semnificaţia restricţiei de integritate a referirii este următoarea:
o asociere nu poate exista decât între parteneri cunoscuţi, adică deja definiţi. Atunci
când, într-o anumită situaţie, asocierea nu este aplicabilă, unul dintre parteneri va fi
desemnat prin valoarea null, cu semnificaţia de „partener inexistent”. Exemplul
anterior respectă restricţia de integritate a referirii.

• Restricţia entităţii (integritatea entităţii). Reprezintă restricţia care impune ca într-o

relaţie atributele cheii primare să fie nenule. Unicitatea cheii impune ca, la încărcarea
unui tuplu, valoarea cheii să fie cunoscută, pentru a se putea verifica faptul că
această valoare nu este deja încărcată. Cu valori de null, cheia îşi pierde rolul de
identificator de tuplu.

Restricţia de integritatea a entităţii nu se aplică cheilor externe, ceea ce conferă o anumită

supleţe modelului relaţional. Uneori, se consideră drept restricţii de integritate minimale numai
ultimele două, restricţia de unicitate a cheii fiind considerată implicită.

7.2 Alte restricţii de integritate

În această categorie intră constrângerile de domeniu. Aceste constrângeri se pot
referi la tipul de date al unui atribut, la o listă de valori posibile, la un ordin de mărime, la un
format sau o formă, la o condiţie exprimată cu o formulă logică sau la o procedură care este
apelată ori de câte ori are loc o modificare pentru domeniul specificat.

Exemple. Pentru relaţia CUMPARATORI (Cod, Nume, Adresa, Debit) se poate impune
condiţia ca nici un cumpărător să nu aibă mai mult de 100.000.000 lei datorii. Pentru relaţia
MAGAZINE (Numemag, Adresamag, Codmarfa, Marfa, Pret) se poate impune ca noile preţuri
să nu crească cu mai mult de 20% faţa de preţurile vechi.

46
 7.3 Aspecte privind integritatea
De integritatea datelor este legată şi protecţia datelor împotriva diferitelor evenimente
de avarie cum ar fi: căderea sistemului, cauzată de defectarea unor componente hardware
sau software, executarea incompletă a unor programe din cauza apariţiei unor erori sau din
necesitatea de întrerupere a lor în urma unor interblocări sau prin intervenţia utilizatorilor,
programarea eronată a unor activităţi prin strategiile folosite de sistem şi altele.
Pentru reconstituirea bazelor de date în eventualitatea apariţiei unor inconsistenţe în
general, majoritatea bazelor de date se copiază periodic pe medii magnetice ce se păstrează
în locuri sigure. De asemenea, se ţine o evidenţă a tuturor transformărilor efectuate în baza
de date de când s-a efectuat ultima copie. Fişierul care conţine aceste modificări se numeşte
jurnal. Fiecare înregistrare din jurnal conţine un identificator al programului care a făcut
modificarea, fosta valoare şi noua valoare introdusă pentru un element. Tot în jurnal se mai
păstrează diferite momente importante din desfăşurarea programelor (început, sfârşit,
terminarea unor operaţii).
Se spune despre o tranzacţie că este comisă dacă au fost terminate toate calculele
produse de ea în aria de lucru şi s-a realizat o copie a rezultatelor ei în jurnal. Apariţia unor
căderi după ce o tranzacţie a fost comisă nu afectează conţinutul bazei de date, deoarece
acestea se pot reconstitui cu ajutorul ultimei copii şi a jurnalului în care se găsesc toate
rezultatele tranzacţiilor comise. Modificările tranzacţiilor abandonate sau necomise nu sunt
luate în considerare la parcurgerea jurnalului pentru restaurarea bazei de date.
Se defineşte strategia de comitere în două faze astfel: o tranzacţie poate să scrie
într-o bază de date numai după ce a fost comisă şi o tranzacţie poate fi comisă numai după
ce a înregistrat în jurnal toate schimbările de elemente produse de ea.

Materiale privind dependenţele datelor, integritatea şi securitatea

bazelor de date:

1. [Fel96]
Despre dependenţe între date

Despre securitatea sistemelor informaţionale, în general

2. www.boran.com/security/IT1x-4.html
3. www.computerworld.ro/index.cfm?t=articol&idcwd=2647
4. www.pcmagazine.ro/pcmag4-8/internet_business.shtml

47
 8. Depozite de date (Data warehouse)

Depozitele de date au devenit, la sfârşitul anilor ' 90, una dintre cele mai importante
dezvoltări în domeniul sistemelor informaţionale. Industria de data warehouse s-a dezvoltat
continuu în termeni de investiţii, produse disponibile şi proiecte elaborate. Se apreciază că
aproximativ 90% dintre companiile multinaţionale au implementate depozite de date sau
lucrează la dezvoltarea unor astfel de proiecte.
Depozitele de date sunt produsul mediului economic şi al tehnologiilor avansate. Pe
de o parte, mediule conomic este tot mai competitiv, global şi complex şi solicită informaţii
elaborate pentru sprijinirea deciziilor strategice iar, pe de altă parte, evoluţia tehnologiilor
informaţionale oferă soluţii eficiente de gestionare a unor volume mari de date integrate (de
ordinul Tera bytes) asigurând niveluri de sinteză / detaliere adecvate. Astfel, evoluţiile
hardware performante precum şi sistemele de procesări paralele masive, sistemele de
multiprocesare simetrică, sistemele tip baze de date paralele fac posibile încărcarea,
întreţinerea şi accesul la baze de date de dimensiuni uriaşe. Aplicaţiile data warehouse sunt
în măsură să asigure şi un timp mediu de răspuns extrem de scurt pentru categorii extinse de
utilizatori.
Primele domenii care au adoptat tehnologia depozitelor de date au fost
telecomunicaţiile, băncile şi comerţul cu amănuntul. Ulterior, depozitele de date au pătruns şi
în alte domenii cum ar fi industria farmaceutică, sistemul sanitar, asigurările, transporturile.
Studiile statistice arată că telecomunicaţiile şi sistemul bancar se menţin în top întrucât alocă
cel puţin 15% din bugetul lor IT pentru proiecte referitoare la depozite de date.
Un proiect de data warehouse reprezintă o investiţie majoră. Costurile tipice pentru
dezvoltarea unui depozit de date într-un interval de 3-6 luni se situează între 0,8 şi 2 milioane
USD. Ponderea echipamentelor se situează între 1/2 şi 2/3 din costul total. Uneori, investiţiile
în depozite de date nu se finalizează cu succes (politici organizaţionale defectuoase,
insuficiente fonduri sau insuficientă susţinere din partea conducerii.

8.1. Concepte de bază în data warehouse

Depozitele de date au fost definite în foarte multe moduri, astfel încât o definiţie
riguroasă este greu de formulat.
În sens larg, un depozit de date (data warehouse) reprezintă un sistem de baze de
date:
• ce acoperă un orizont temporal mai mare (fundamentală este perspectiva pe termen lung);
• ce conţine date interne şi externe;
• optimizat pentru a răspunde interogărilor complexe.
Datele din sistemele sursă sunt extrase, curăţate, transformate şi stocate în depozite
speciale în scopul sprijinirii proceselor decizionale, furnizând o platformă solidă de
consolidare a datelor istorice pentru analiză.
Caracteristicile majore ale depozitelor de date sunt următoarele:
• Orientarea pe subiecte. Un depozit de date este organizat în sensul unor subiecte
majore cum ar fi: clienţi, furnizori, producţie, vânzări. Mai curând decât a concentra
procesarea operaţiilor şi tranzacţiilor tipice într-o organizaţie, un depozit de date se
focalizează pe modelarea şi analiza datelor pentru luarea deciziilor. Se oferă o viziune simplă
şi concisă relativă la un subiect particular, excluzând datele care nu sunt utile în procesul de
decizie.
• Integrarea. Un depozit de date este, în mod uzual, construit prin integrarea a
multiple surse eterogene: baze de date relaţionale, fişiere, înregistrări privind tranzacţii online.
Tehnicile de curăţare (data cleaning) şi de integrare sunt aplicate pentru a asigura
concordanţa în convenţiile de atribuire a numelor, de codificare a structurilor şi atribuire a
valorilor.
• Caracterul istoric. Datele sunt stocate pentru a furniza informaţii în perspectivă
istorică (de la 5 până la 10 ani în urmă). Astfel, decidenţii pot consulta valorile succesive ale
aceloraşi date, pentru a determina evoluţia în timp şi a calcula tendinţele anumitor indicatori.
• Persistenţa datelor. Datele dintr-un depozit sunt permanente şi nu pot fi modificate.
O actualizare a depozitului de date, ca urmare a modificărilor efectuate în datele sursă,
înseamnă adăugare de date noi, fără a modifica sau şterge datele existente. Un depozit de

48
date este întotdeauna memorat separat, din punct de vedere fizic, de datele transformate din
alte aplicaţii. Datorită acestei separări, un depozit de date nu necesită mecanisme de
procesare a concurenţei. În mod uzual, solicită numai două operaţiuni: încărcarea iniţială a
datelor şi accesul la date.
Sintagma data warehousing desemnează procesul de construire şi utilizare a
depozitelor de date (data warehouse). Construirea necesită integrarea, curăţarea şi
consolidarea datelor. Utilizarea necesită o colecţie de tehnologii de asistare a deciziilor.
Acestea permit specialiştilor (manageri, analişti, executivi) să obţină rapid şi convenabil datele
necesare şi să ia decizii bazate pe informaţiile din depozit.

8.2. Diferenţe înte bazele de date şi depozitele de date

Atât bazele de date cât şi depozitele de date conţin mari cantităţi de date structurate
care pot fi accesate rapid datorită structurilor de acces optimizate şi se bazează, în
majoritatea cazurilor, pe tehnologii relaţioanle. Totuşi ele nu au fost proiectate pornind de la
aceleaşi obiective şi se diferenţiază prin numeroase aspecte.
Sistemele de gestiune ale bazelor de adte sunt adecavte aplicaţiilor curente de
gestiune şi servesc la crearea şi întreţinerea sistemelor de date operaţionale. Aceste sisteme
sunt cunoscute sub denumirea de sisteme OLTP (OnLine Transaction Processing) şi au ca
obiectiv execuţia online a tranzacţiilor şi proceselor de interogare. Ele încorporează toate
operaţiile zilnice dintr-o organizaţie, cum ar fi: aprovizionări, stocuri, producţie, decontări, plăţi,
contabilitate.
Sistemele depozite de date, pe de altă parte, servesc specialiştii în domeniul analizei
datelor şi luării deciziilor şi sunt cunoscute sub numele de sisteme OLAP (OnLine Analytical
Processing).
Deosebirile majore între OLTP şi OLAP sunt sintetizate în tabelul următor şi iau în
considerare următoarele trăsături: utilizatorii şi orientarea sistemului, caracterul datelor
conţinute, nivelul de sinteză, unitatea de lucru, schemele de acces, numărul de înregistrări
accesate, mărimea bazelor de adte, sistemul de evaluare.

Nr.
Trăsături OLTP OLAP
Crt.
1 Destinaţia Procese operaţionale Procese informaţionale
2 Orientarea sistemului Tranzacţii Analize
3 Utilizatori Funcţionari, administratori
BD, profesionişti în BD
4 Funcţii Operaţii zilnice Cerinţe informaţionale pe
termen lung, asistarea
deciziei
5 Instrumente folosite în Diagrame E-A Star / snowflake
proiectare
6 Caracterul datelor Curente, noutate garantată Istorice, precizie
menţinută în timp
7 Nivelul de sinteză Primitive, detaliere ridicată Sintetizare, consolidare
8 Unitatea de lucru Scurtă, tranzacţii simple Interogări complexe
9 Scheme de acces Read, Write Aproape totdeauna Read
10 Focalizare Culegere date Furnizare informaţii
11 Număr de înregistrări Zeci Milioane
accesate
12 Număr de utilizatori Mii Sute
13 Mărimea bazelor de date 100 MB - GB 100 Gb - TB
14 Priorităţi Performanţe ridicate, Flexibilitate ridicată,
disponibilitatea ridicată autonomie utilizatori finali
15 Sistem de evaluare Tranzacţii culese Interogări culese, timp de
răspuns

49
 Un sistem OLTP este orientat pe client (customer oriented) şi este utilizat pentru
procesarea tranzacţiilor şi a interogărilor. Un sistem OLAP este orientat spre piaţă (market
oriented) şi este utilizat de manageri, analişti şi specialişti.
Există şi conceptul de magazine de date (Operational Data Stores – ODS), care se
referă la o colecţie de date proiectate pentru sprijinirea controlului operaţional. La prim
avedere nu par deosebite de depozitele de date, dar – deşi ambele tehnologii sprijină
decidenţii – sunt diferite deoarece au scopul de a acoperi anumite tipuri de cerinţe
informaţionale. Magazinele de date conţin date orientate pe subiecte din întreprinderile mari
şi, spre deosebire de depozitele de date, conţin date volatile şi detaliate.

8.3. Arhitectura depozitelor de date

Arhitectura simplificată a unui depozit de date este prezentată în figura următoare.

Baze de date
operaţionale
Instrumente
pentru
Accesare
şi
Utilizare

ŞTERGERE
Achiziţie DEPOZIT DE DATE
(extragere) (DATE AGREGATE ARHIVARE
+
METADATE) AGREGARE

Prelucrare
(data mining)

În depozitul de date întâlnim mai multe tipuri de date care corespund diferitelor
cerinţe informaţionale ale utilizatorilor:
• Date detaliate
• Date uşor agregate
• Date puternic agregate
• Metadate.
Metadatele descriu datele conţinute în depozitul de date şi modul în care ele sunt
obţinute şi stocate. Prin metadate se precizeză structura datelor, provenienţa lor, regulile de
transformare, de agregare şi de calcul. Metadatele joacă un rol esenţial în alimentarea
depozitului cu date. Ele sunt utilizate în toate etapele de încărcare adatelor şi sunt consultate
şi actualizate pe parcursul întregului ciclu de viaţă ale depozitului.
Agregarea datelor se referă la realizarea de: totaluri precalculate, subtotaluri, valori
medii, etc., ce se preconizează că vor fi cerute şi folosite de către utilizatori. Aceste agregări,
deşi determină o creştere a redundanţei datelor, sunt necesare deoarece în acest fel se poate
asigura un timp de răspuns cât mai redus. Sunt stocate în depozitul de date împreună cu
datele importante din surse interne şi externe.
Data Mining reprezintă un proces de prelucrare bazat pe modele performante de
selectare şi agregare a datelor din depozitele de date. Cele două scopuri principale ale
procesului de data mining sunt, din punct de vedere practic:
• Predicţia – implică utilizarea unor câmputi sau variabile din baza de date, în
scopul estimării unor valori viitoare sau necunoscute, pentru alte variabile de
interes şi

50
 • Descrierea – se orientează către găsirea unor modele ce descriu datele,
interpretabile din perspectiva utilizatorului.

Procesul, numit şi Knowledge Data Discovery (KDD), este realizat prin intermediul
următoarelor sarcini:
• Clasificarea – este vorba de o funcţie care mapează (clasifică) un element de dată în
una sau mai multe clase predefinite.
• Regresia – o funcţie asociază un element de dată unei variabile cu rol de predicţie.
• Partiţionarea (clustering) – este o funcţie descriptivă prin care se urmăreşte
identificarea unui număr (finit) de categorii sau mulţimi care descriu datele. Strâns
legată de această funcţie este funcţia de estimare a densităţilor de probabilitate ale
variabilelor aleatoare constituite de câmpurile de date.
• Sumarizarea – implică metode pentru găsirea unei descrieri compacte a unei
submulţimi de date.
• Modelarea dependenţelor – constă din găsirea unor modele care descriu în mod
compact diferite dependenţe între subseturi de date. Modelele de dependenţă există
la două nivele: structural (ce variabile sunt dependente unele de altele) şi cantitativ
(specifică măsuri ale acestor dependenţe utilizând o scară numerică).
• Detectarea schimbărilor şi deviaţiilor – se focalizează pe descoperirea celor mai
semnificative schimbări ale datelor, utilizând valori anterior măsurate.

Cele mai populare metode de data-mining utilizează:

o Reguli şi arbori de decizie
o Regresie neliniară şi metode de clasificare
o Metode bazate pe exemple
o Modele Probabilistice de dependenţă
o Modele de învăţare relaţională

Există două metode de data mining:

• Data mining direct, care presupune:
o O abordare top-down
o Să ştim (cu aproximaţie) ce căutăm sau ce vrem să prezicem
o Un model predictiv, care să permită evaluarea alternativelor
o Modelul este văzut ca o cutie neagră, căci ne interesează numai predicţia şi nu
cum se realizaeză aceasta
o Scopul construirii unui model predictiv este de a aplica cunoştinţele dobândite în
trecut, pentru viitor.
o Exemplu: Să se găsească răspunsul la întrebarea: „Ce clienţi se presupune că
vor cumpăra un anumit tip de maşină?”
• Data mining indirect, care presupune:
o O abordare bottom-up
o Să găsim modele în colecţiile de date şi să lăsăm utilizatorii să determine dacă
acestea sunt sau nu importante
o Vrem să ştim cum lucrează un model şi cum oferă răspunsul
o Este necesară interacţiunea umană pentru că numai oamenii pot determina ce
semnificaţie (dacă există una) au modelele
o Este utilizat deseori în procesul de explorare a datelor

Literatura de specialitate face referire la trei soluţii practice de organizare a

depozitelor de date:
• Depozit la nivelul întreprinderii - Enterprise Warehouse. Colectează toate
informaţiile despre subiecte care privesc întreaga organizaţie şi furnizează un volum
extins de date.
• Depozite la nivelul unei unităţi de gestiune (filială, departament, serviciu), cunoscute
sub numele de data marts. Un data mart 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 mart pentru marketing limitează subiectele la clienţi,
articole, vânzări. Datele implementate în data mart sunt, de obicei, agregate. Un data
mart poate fi considerat un subansamblu al unui depozit de date, mai uşor de
construit şi mai puţin scump.

51
 • Depozite virtuale – Virtual Warehouse. Un depozit virtual este un set de viziuni
asupra bazelor de date operaţionale. Este uşor de construit dar necesită capacităţi
suplimentare pe serverele de baze de date.

Din punct de vedere al modelelor de date specifice data warehouse, cele mai
populare sunt:

• Reprezentarea stea (Star Schema). Este cel mai comun model de date, în care
depozitul conţine un tabel central voluminos (tabel de fapte) care cuprinde cea mai mare parte
a datelor fără redundanţe şi un set de tabele însoţitoare (tabele-dimensiune) pentru fiecare
dimensiune. Graful asociat seamănă cu o stea în care tabelele-dimensiune apar radial, în jurul
tabelului de fapte central, ca în figura următoare.

Timp
Tabel-dimensiune 1
Cheie-timp Articol
Zi Tabel-dimensiune 3
Zi-din-săptămână Cheie-articol
Lună Nume-articol
Trimestru Marca
An Tip
Tip-furnizor

Vânzări
Tabel de fapte
Cheie-timp
Cheie-articol Zonă
Cheie-ramură Tabel-dimensiune 4
Cheie-zonă Cheie-zonă
Vânzări-lei Stradă
Ramură Cantitate-vândută Localitate
Tabel-dimensiune 2 Judeţ
Cheie-ramură Cod-poştal
Nume-ramură Ţara
Tip-ramură

În acest exemplu, vânzările sunt considerate cu patru dimensiuni: timp, articol, ramură şi
zonă.

• Schema fulg de zăpadă (Snowflake). Este o variantă a modelului stea, unde

anumite tabele sunt normalizate, astfel încăt apar tabele suplimentare. Rezultă o schemă de o
formă grafică similară unui fulg de zăpadă. Diferenţa majoră între stea şi fulg de zăpadă este
că tabelele dimensiune din acest ultim model pot fi păstrate în formă normalizată, ceea ce
determină o redundanţă redusă. Asemenea tabele sunt uşor de întreţinut şi se economiseşte
spaţiu de stocare, deoarece dimensiunile unui tabel mare pot creşte foarte mult. Un exemplu
este schema anterioară, unde tabelele-dimensiune 3 şi 4 se modifică astfel:

Articol
Tabel-dimensiune 3 Furnizor
Cheie-articol Tabel-dimensiune 3-1
Nume-articol Cheie-furnizor
Marca Tip-furnizor
Tip
Cheie-furnizor

52
 Zonă
Tabel-dimensiune 4 Oraş
Cheie-zonă Tabel-dimensiune 4-1
Stardă Cheie-oraş
Cheie-oraş Oraş
Judeţ
Regiune

• Constelaţie de fapte – aplicaţiile complexe pot solicita tabele multiple de fapte, care
partajează tabelele-dimensiune. Acest gen de schemă poate fi văzut ca o colecţie de stele,
de unde denumirea de constelaţie de fapte (fact constellation).

Când se justifică un proiect de data warehouse? Există mai multe situaţii în care
un depozit de date este oportun pentru rezolvarea unor probleme:
• Insuficienta partajare a informaţiilor (de exemplu, când servicii sau departamente cu
aceiaşi clienţi nu comunică între ele).
• Grupuri diferite produc rapoarte contradictorii (datorită folosirii inconsistente a unor
termeni).
• Procesul de creare a rapoartelor este foarte anevoios (necesită mult timp pentru a fi
produse şi nu rămâne timp pentru analiza efectivă a datelor).
• Rapoartele nu sunt dinamice şi nu favorizează stilul de interogare ad-hoc (nu se pot
obţine rapoarte concludente în situaţii speciale).
• Rapoartele care necesită date istorice sunt dificil de realizat (astfel de date nu sunt
stocate în sistemele operaţionale, iar încorporarea datelor vechi în rapoarte poate fi
dificilă din cauza nepotrivirii structurilor).

Majoritatea firmelor producătoare de software pentru baze de date s-au orientat către
implementarea unui modul specific depozitelor de date. În topul preferinţelor se află: SQL
Analysis Manager produs de Microsoft Corporation şi Oracle Warehouse Builder produs de
Oracle. Aceste două instrumente beneficiază de experienţa şi puterea finaciară a companiilor
producătoare şi au reuşit să se impună pe piaţă ca soluţii viabile. Industria depozitelor de date
este însă în continuă expansiune.
Instrumentele data-mining vor continua să se maturizeze şi din ce în ce mai multe
organizaţii vor adopta acest gen de tehnologie. Iniţiativele data mining provin cel ami adesea
din zona departamentelor de marketing şi de vânzări cu amănuntul şi se pretează foarte bine
în organizaţiile care deţin baze de date cu volume foarte mari. Datorită faptului că aceste
instrumente dau cele mai bune rezultate cu date la un nivel ridicat de detaliere, evoluţia
instrumentelor data mining va coincide de fapt cu dezvoltarea depozitelor de date cu
dimensiuni de ordinul TB. Proiectele de data mining vor accentua şi ami mult importanţa
calităţii datelor din depozitele de date.
Tehnologiile data warehouse continuă să fie influenţate de poularitatea soluţiilor
bazate pe Intranet şi Internet. Ca urmare, din ce în ce mai multe instrumente de acces la date
vor putea suporta facilităţile oferite de web. Unele organizaţii au început deja să folosească
infrastructura Internetului pentru a oferi utilizatorilor posibilitatea de a utiliza depozitul de adte
de la distanţă, însă în acest caz este trebuie avută în vedere problema securităţii acestui
mediu.

Exemplul 1. NAWQA – Water Quality Data Warehouse este un depozit unde se colectează
date despre calităţile chimice, biologice şi fizice ale apei din 42 de bazine din SUA. Se
măsoară zilnic: concentraţiile în apă, sedimente şi ţesuturi organice pentru aproximativ 600
de constituenţi chimici. De asemenea, se păstrează date privind nivelul apelor în aceste
bazine hidrografice.

Exemplul 2. Departamentul SUA pentru Sănătate şi Servicii Umane a dezvoltat depozitul de

date geospaţiale HRSA (Health Resources and Services Administration). Acest depozit şi
aplicaţiile sale asociate furnizează informaţii despre programele HRSA, resurse despre
sănătate şi date demografice foarte utile pentru planificare şi domeniului politic. Acest depozit
conţine date despre granturi, burse şi împrumuturi, destinate serviciilor subsumate, precum şi
programe demonstrative. Fiind sursa centrală de informaţii utilizată pentru raportările

53
activităţilor HRSA, oferă un instrument de raportare pentru generarea şi utilizarea tabelelor.
Un instrument de tip hartă este disponibil pentru cei ce vor să plaseze date într-un context
geografic. Datele depozitului sunt actualizate cu regularitate şi se adugă noi surse de
informaţii. În continuare este prezentată secţiune de arii ale site-ului
(http://datawarehouse.hrsa.gov/).

What's New Data Dictionary

Data Refresh Dates Spatial Metadata
Program Information Data Access
Grants Information PCSA
Help Resources
Health Systems
Technical Support
Interactive Maps
Map Tool Help
Map Tool
Report Tool Help
Reporting
Grant Activity Listing
Report Tool
List of Data Sources
Metadata
Resources
Data Sources

Materiale privind depozitele de date şi data mining:

1. www.dwinfocenter.org
The Datawarehousing Information Center: acest site este o colecţie de eseuri ale
practicienilor depozitelor de date. Prezintă definiţii, argumente pro şi contra dezvoltării
depozitelor de date, evaluări ale unor instrumente software pentru depozite de date, informaţii
despre afaceri inteligente, politici pentru decizie şi ale domeniului depozitelor de date.

2. datawarehouse.ittoolbox.com
Instrumente pentru lucrul cu depozite de date.

3. freedatawarehouse.com
Concepte şi elemente practice.

4. www.infogoal.com/dmc/dmcdwh.htm
Informaţii despre: Data Warehouse, Data Mart, Data Mining, Decision Support
Resources.

5. www.datawarehousingonline.com
Resurse, tehnologii şi soluţii.

6. http://dbvis.inf-uni-konstanz.de/~keim/PDF/Vis04Tutorial.pdf
Articolul Information Visualization and Visual Data Mining, autori: Grinstein G.,
Keim D.A., Ward M., 2004. Prezintă istoria domeniilor vizualizare de date şi data mining,
tehnici şi sisteme de vizualizare, exemple de aplicabilitate în chimie.

7. www.nag.co.uk
The Numerical algorithms Group Ltd, Oxford. Oferă componente şi tehnologii data
mining şi vizualizare, pentru mai mult de 10000 de organizaţii din întreaga lume. Software şi
servicii de dezvoltare de aplicaţii (în bio-informatică, e-business, detecţia fraudelor, analiză
web).

54
 9. Baze de cunoştinţe

Bazele de cunoştinţe sunt întâlnite în literatura de specialitate sub diferite denumiri

cum ar fi: baze de date logice, baze de date inferenţiale, sisteme expert, sisteme deductive,
prelucrare recurentă, baze de date inteligente. Prin aceste sisteme se încearcă o cât mai
apropiată funcţionare a bazelor de date de sistemul obişnuit de operare cu date.
Astfel, în aceste sisteme diferitele tupluri ale relaţiilor sunt interpretate ca axiome iar
cererile sunt interpretate ca teoreme, răspunsul la cerere fiind interpretat ca o demonstraţie.
Această interpretare permite:
• uniformitate de reprezentare - bazele de date, axiomele, cererile şi constrângerile de
identitate sunt reprezentate toate la fel;
• uniformitate de operare – răspunsul la cereri optimizaea cererilor, proiectarea bazelor
de date, demonstrarea corectitudinii programelor sunt privite la fel;
• modelare semantică – prin evenimente, tipuri de ierarhii şi combinaţii de entităţi;
• aplicaţii extinse.
Bazele de cunoştinţe permit interpretarea unor cereri formulate în limbaj natural.
Printre altele, conţin copii ale unor tabele din catalogul bazei de date, tabele ce conţin valorile
datelor utilizate frecvent, o mulţime de reguli de transformare a frazelor (unele permiţând
substituirea automată a unor sub-expresii) şi un lexicon conţinând un tabel care defineşte
cuvinte din limba naturală ce pot fi utilizate în cereri sau cuvinte generale.
Baza de cunoştinţe este iniţiată prin construirea lexiconului şi a altor părţi
componente şi se completează în timp cu noi cunoştinţe sau elemente, de către utilizatori sau
automat, pe baza informaţiilor obţinute în exploatare.
În bazele de cunoştinţe sunt aplicate rezultatele din calculul propoziţiilor şi calculul
predicatelor. Pe baza transformărilor logice se urmăreşte demonstrarea unor aserţiuni ţinând
seama de axiomele logicii matematice şi de informaţiile conţinute în sistem.
Prin axiomă deductivă sau regulă de inferenţă se înţelege o regulă care permite
deducerea unor fapte plecând de la o mulţime de fapte date. Pentru a demonstra o aserţiune
de forma:
f1, f2, …,fn├ g
unde f1, f2, …,fn sunt premisele iar g este concluzia, de obicei se foloseşte metoda reducerii la
absurd, demostrând că formula:
f1 & f2 & …& fn & not g
este falsă. Pentru aceasta se transformă formula precedentă într-o formulă echivalentă
normal conjunctivă, de forma:
u1 & u2 & …& um
în care fiecare ui, i=1,…,m este o disjuncţie de atomi, eventual precedaţi de negaţie. Se
derivează în continuare alţi termeni, aplicând legea rezoluţiei în forma:
╞ ((f ∨ g) & (not g ∨ h) ⇒ (f ∨ h)
Dacă printre termenii derivaţi apare mulţimea vidă (înţeleasă ca fals şi notată []) atunci
aserţiunea iniţială este adevărată, altfel (când nu mai pot fi generaţi alţi termeni) aserţiunea
este considerată falsă.

Exemplu. Pentru a demonstra aserţiunea:

A ⇒ (B ⇒ C), NOT D OR A, B ├ D ⇒ C
Unde A, B, C şi D sunt formule, se pleacă de la formulele:
A ⇒ (B ⇒ C)
NOT D OR A
B
NOT(D ⇒ C)
care, aduse la forma normală conjunctivă, conduc la:
(1) NOT A OR NOT B OR C
(2) NOT D OR A
(3) B
(4) D
(5) NOT C
Aplicând rezoluţia pentru formulele (1) şi (2) în raport cu A se obţine
(6) NOT D OR NOT B OR C
Aplicând din nou rezoluţia pentru formulele (6) şi (3) în raport cu B se obţine

55
 (7) NOT D OR C
Aplicând din nou rezoluţia pentru formulele (7) şi (4) în raport cu D se obţine
(8) C
şi din (8) şi (5) unde rezoluţia se aplică în raport cu C se obţine clauza vidă, ceea ce
demonstrează că aserţiunea iniţială este adevărată.

Cererile pentru baza de cunoştinţe pot fi exprimate sub următoarea formă generală:
A1 AND A2 AND …AND Am ⇒ B1 OR B2 OR …OR Bn (*)
unde A1, A2, …, Am şi B1, B2, …, Bn sunt de forma r(x1, x2, …,xt) cu r predicat având
argumentele x1, x2, …,xt.
Dacă toate argumentele sunt constante, predicatul reprezintă o axiomă de bază şi
este o propoziţie adevărată. În termenii bazelor de date, (x1, x2, …,xt) este unul din tuplurile
existente în baza de date. În acest sens, predicatul r afirmă ceva în concordanţă cu înţelesul
pe care îl are relaţia R.
Pentru m>0 şi n=1, (*) devine clauza:
A1 AND A2 AND …AND Am ⇒ B
care poate fi privită ca o axiomă deductivă. Această axiomă deductivă dă o definiţie parţială
a predicatului din partea dreaptă a implicaţiei, în funcţie de predicatele din partea stângă.
Poate fi privită şi ca o constrângere de integritate.
Vederile unei baze de date pot fi privite ca modele teoretice. În aceste modele,
domeniile de bază conţin valori sau constante ce pot să descrie anumite obiecte ale lumii
reale, acestea formând contextul (ce poate fi privit ca un „univers”). Relaţiile de bază
reprezintă o mulţime de predicate sau formule deschise (cu variabile) ce urmează să fie
interpretate în acel context. Fiecare tuplu al unei relaţii reprezintă o particularizare a
predicatului corespunzător (adică o formulă închisă, fără variabile) care are valoarea adevărat
pentru universul respectiv. Constrângerile (restricţiile) de integritate sunt tot formule închise,
interpretabile în contextul respectiv. Prin urmare, tuplurile şi constrângerile de integritate pot fi
privite ca formând mulţimea axiomelor ce definesc o anumită teorie logică. Baza de date
poate fi privită ca mulţimea tuturor teoremelor ce se pot demonstra pornind de la axiome.
Evaluarea cererilor se face analog cu demonstrarea teoremelor.
Ca axiome ale unei baze de date pot fi considerate următoarele:
1. Axiomele de bază – corespund tuplurilor relaţiilor de bază, ele definind aşa-numita
bază de date extinsă (extensional database).
2. Câte o axiomă de completitudine pentru fiecare relaţie, prin care se afirmă că nu
există alte tupluri decât cele care apar efectiv în relaţia respectivă. Aceasta se mai
numeşte presupunerea de închidere (Closed World Assumption), prin care se
consideră false aserţiunile pentru tuplurile ce nu apar în relaţie.
3. Axioma numelui unic – prin care se afirmă că fiecare constantă se distinge de toate
celelalte constante (are nume unic).
4. Axioma închiderii domeniului – prin care se afirmă că nu există alte constante în
afară de cele existente în domeniul bazei de date.
5. O mulţime de axiome standard, prin care se defineşte predicatul „=”.
Un sistem deductiv de baze de date este un SGBD care permite construirea
vederilor cu demonstrare teoretică şi care este capabil, în particular, să deducă fapte
suplimentare din baza de date existentă aplicând axiome deductive sau reguli de inferenţă.
Axiomele deductive împreună cu constrângerile de integritate formează ceea ce se numeşte
conţinutul intern al bazei de date (intensional database) şi aceasta, împreună cu extinderea
bazei de date (care conţine informaţiile) formează baza de date deductivă (deductive
database).

Materiale privind bazele de cunoştinţe:

1. [Fel96]
2. http://www.kddresearch.org/Groups/Data-Mining/
Despre descoperirea cunoştinţelor şi Data Mining, la Departmentul de Calculatoare şi
Ştiinţele Informaţiei, Kansas State University, Laboratorul Knowledge Discovery in
DataBases
3. http://www.kmining.com
Despre inteligenţă în afaceri, Knowledge Discovery şi Data Mining

56
 10. Aplicaţii Access
Acest capitol conţine patru aplicaţii Access comentate, în scopul prezentării celor mai
utile informaţii privind realizarea bazelor de date relaţionale.

10.1. Bază de date pentru activităţi şcolare

Să presupunem că, într-un oraş, activităţile facultative ale elevilor se desfăşoară
într-un sediu special organizat, după un orar care se stabileşte la începutul fiecărui an şcolar.
Se doreşte crearea unei baze de date pentru gestionarea informaţiilor relative la această
activitate: elevi, profesori, orar. Pentru simplificarea aplicaţiei, vom considera că două cursuri
cu acelaşi obiect (de exemplu, două cursuri de pictură) susţinute la momente temporare
distincte (de acelaşi profesor sau de profesori diferiţi) sunt de fapt cursuri distincte, motiv
pentru care cursurile vor fi identificate printr-un cod.
Analiza problemei conduce la identificarea imediată a entităţilor: ELEVI, CURSURI,
PROFESORI. Cunoscând elementele ce trebuie memorate pentru fiecare entitate în parte şi
constatând relaţiile între entităţi, construim modelul conceptual al bazei de date, care se
poate reprezenta astfel:

ELEVI
nr matricol
nume si prenume
clasa
scoala

CURSURI
URMEAZĂ cod curs
denumire curs
ziua
ora inceperii
SUSŢIN evenimente

PROFESORI
cod profesor
specializarea
norma de baza

Cu specificaţia anterioară relativă la cursuri, observăm că relaţia dintre entităţile

PROFESORI şi CURSURI este de tip 1-n ("unu la mai mulţi") (un profesor poate susţine mai
multe cursuri dar un curs este realizat de un singur profesor), în timp ce relaţia între entităţile
ELEVI şi PROFESORI este de tip m-n ("mai mulţi la mai mulţi"). Într-adevăr, un elev poate
urma mai multe cursuri iar un curs are, desigur, mai mulţi elevi. Acest tip de relaţie se
transformă, pentru a putea fi modelată logic, în două relaţii de tip 1-n. Vom realiza aceasta
prin introducerea unei entităţi suplimentare, numită REPARTIŢII, care va permite şi notarea
fiecărui elev, la sfârşitul anului şcolar, la toate cursurile la care acesta participă. Ideea acestei
modelări este de a surprinde interacţiunea elev – curs şi elementele ei specifice. Fiecare elev
(identificat prin numărul său matricol, stocat în nr matricol) urmează un curs (identificat printr-
un cod păstrat în cod curs) şi primeşte o notă (stocată în câmpul apreciere). Astfel, modelul
logic (relaţional) al datelor este reprezentat de următoarea colecţie de tabele:

• ELEVI (nr matricol, nume şi prenume, clasa, şcoala)

• CURSURI (cod curs, denumire curs, ziua, ora începerii, evenimente)
• PROFESORI (cod profesor, specializarea, norma de bază, cod curs)
• REPARTIŢIE (cod, nr matricol, cod curs, apreciere).

57
 În reprezentarea de mai sus, atributele subliniate cu linie continuă caracterizează în
mod unic realizările de entitate (un număr matricol este specific unui elev şi numai unuia,
aceeaşi proprietate este valabilă pentru codul unui profesor, fiecare curs are un cod unic iar
fiecare linie a tabelului repartiţie este identificată printr-un număr, păstrat în câmpul cod). Un
atribut cu această proprietate (de identificare a realizărilor unei entităţi) se numeşte cheie
primară. De exemplu, atributul cod curs realizează diferenţierea a două cursuri (în baza
noastră de date, două cursuri cu aceeaşi denumire – Pictură – sunt susţinute de profesori
diferiţi, în zile diferite din săptămână; este evident că nu ar putea fi identificate prin denumire).
Câmpurile subliniate cu linie punctată au un rol de legătură, şi anume, modelează
relaţiile între entităţile identificate în faza de analiză. Aceste câmpuri se numesc chei
secundare sau externe (cod curs pentru tabela profesori, nr matricol şi cod curs pentru
tabela repartiţie). În timp ce cheile primare au valori unice, cheile secundare pot avea valori
duplicate (se va observa, studiind baza de date oferită ca exemplu, că numărul matricol 101
apare în trei linii ale tabelei repartiţie, iar cursul cu codul 3 în patru linii).
Vom studia în continuare procedeele prin care transpunem acest model într-o bază
de date Access şi cum putem folosi această bază de date.

În fereastra Microsoft Access optăm pentru crearea unei baze de date goale (Blank
Access database) şi tastăm OK. Apare caseta File New Database, în care introducem numele
dorit (în cazul nostru, instruire). În zona de lucru a aplicaţiei apare fereastra Database,
aceasta fiind fereastra principală a noii baze de date, prin intermediul căreia putem accesa
toate obiectele ei. Se observă că în zona din stânga ferestrei obiectele sunt grupate pe tipuri
(tablouri, cereri, etc.), iar în zona din dreapta se regăsesc instrumente de lucru şi obiectele de
tipul curent. Astfel, în imaginea de mai jos nu figurează tabele (acestea vor fi primele obiecte
create), dar se pot observa instrumentele prin intermediul cărora putem accesa diferitele
modalităţi de creare a tabelelor. Se observă că eticheta fiecărui grup de obiecte este
precedată de o imagine semnificativă. Imediat sub bara de titlu a ferestrei se pot observa
butoane de manevră a obiectelor de tipul curent (de exemplu, pentru tabele, Open, Design,
New şi Delete permit deschiderea în mod tabel, deschiderea în mod proiectare, crearea unui
tabel nou şi respectiv ştergerea unui tabel) şi butoanele pentru diferite afişări ale
pictogramelor obiectelor (Large Icons, Small, List şi Detail).

58
Crearea tabelelor
Prin realizarea unui dublu clic pe opţiunea Create table in design view se deschide
fereastra Table, în cadrul căreia se definesc:
• numele câmpului (Field Name), ce poate fi format din mai multe cuvinte, trebuie să fie
sugestiv (să sugereze conţinutul câmpului pe care îl numeşte). De exemplu, "nr
matricol" este numele câmpului care va conţine numărul matricol al unui elev.
• tipul câmpului (Data Type). Un tip de dată defineşte atât mulţimea valorilor pe care le
poate lua data respectivă, cât şi tipul operaţiilor ce se pot aplica asupra ei. Un clic pe
săgeata derulantă deschide lista opţiunilor (Text, Memo, Number, Date/Time, etc.).
• descrierea (Description), acest element fiind opţional (o descriere a câmpului
respectiv, de exemplu pentru "nr matricol" s-a precizat că reprezintă un cod intern,
necesar identificării elevilor în cadrul activităţii de instruire suplimentară).

Crearea relaţiilor între tabele

Există două tipuri de relaţii între tabelele unei baze de date:
• relaţii permanente, ce se stabilesc după definirea tabelelor. Aceste relaţii fac parte din
structura bazei de date (deci se memorează în ea) şi se realizează prin
corespondenţele chei primare – chei secundare.
• relaţii temporare, ce se stabilesc între tabele atunci când se realizează anumite
interogări; acestea nu se păstrează în bază.
Am observat deja care este tipul relaţiilor între tabelele PROFESORI şi CURSURI (1-
n), iar relaţia de tip m-n între tabelele ELEVI şi CURSURI a fost descompusă în două relaţii
de tip 1-n, cu ajutorul tabelei REPARTIŢIE: Relaţia ELEVI – REPARTIŢIE este de tip 1-n (un
elev participă la mai multe cursuri şi va primi o notă pentru fiecare) şi la fel este relaţia
CURSURI – REPARTIŢIE (un curs se regăseşte în tabela REPARTIŢIE de un număr de ori
egal cu numărul elevilor care-l urmează). În afara acestor tipuri de relaţii, în Access se mai
pot modela relaţiile de tip 1-1 ("unu la unu"), de exemplu între persoane şi mulţimea codurilor
numerice personale.

Un clic pe butonul Relationships: de pe bara de instrumente Database deschide

fereastra Relationships şi caseta Show Table, de unde utilizatorul aduce în fereastră tabelele
bazei de date (după care o închide). O relaţie între două tabele se realizează prin punctarea
cheii principale a tabelei ce constituie partea stângă a relaţiei) şi tragere până la cheia
secundară (externă) a tabelei ce constituie partea dreaptă a relaţiei. Această manevră
deschide fereastra de dialog Editare Relaţii:

59
 Se observă în această fereastră (în cazul de faţă, pentru editarea relaţiei ELEVI –
REPARTIŢIE) cele două tabele relaţionate, cheile primară şi secundară. Bifarea proprietăţii
Enforce Referential Integrity) activează un mecanism al sistemului de gestiune Access, prin
care nu este permisă introducerea datelor în tabele REPARTIŢIE, înaintea celor din tabela
ELEVI. Cu alte cuvinte, un elev cu numărul matricol 300 nu poate figura în tabela
REPARTIŢIE, înainte de a fi fost introdus în ELEVI. Această ordine de introducere este
naturală, nu putem repartiza elevii la cursuri înainte de a-i "înscrie". Situaţia se prezintă la fel
şi în cazul relaţiei CURSURI – REPARTIŢIE: trebuie să memorăm mai întâi datele despre un
curs şi apoi să repartizăm elevi la acest curs. Se observă că acest mecanism este unul de
păstrare a integrităţii referenţiale a bazei (după cum indică şi numele proprietăţii), astfel este
prevenită introducerea greşită a datelor şi sunt eliminate multe incoerenţe.
Iată fereastra Relaţii pentru baza de date instruire:

Introducerea datelor în tabele

Se poate realiza în mai multe moduri, dar pentru început putem realiza următorii paşi:
în fereastra Database selectăm fişierul dorit, activăm butonul Open şi în fereastra care apare
(gen foaie de date, ca în Excel) introducem datele. De fapt, această modalitate permite şi
vizualizarea şi modificarea datelor, la orice moment în exploatarea bazei de date. În fereastra
de mai jos se pot observa: articolul curent, indicat prin săgeata neagră şi în bara de stare,
butoanele de deplasare printre liniile tabelului (un articol înaintea celui curent: , articolul
următor: , primul articol: , ultimul articol: , articolul gol: , care apare totdeauna
marcat cu *) şi cursorul de defilare, pentru cazul în care sunt multe câmpuri şi este necesară

60
deplasarea stânga-dreapta (evident, ar apărea şi un cursor vertical dacă fereastra nu ar
conţine decât o parte din liniile tabelului).

Formulare
În cadrul aplicaţiei noastre, este creat un formular cu numele CURSURI, pentru
introducerea datelor în altă formă decât cea tabelară. Avantajul este o interfaţă deosebită,
care permite posibilitatea afişării unor indicaţii pentru cel care introduce datele (această
activitate fiind semnificativă, în cazul bazelor de date mari).

Antet

Zonă
de
detaliu

Subsol

În acest formular, se observă trei zone:

• antetul;
• zona de detaliu – care conţine numele câmpurilor şi datele;
• subsolul.
Atât antetul cât şi subsolul nu se modifică pe măsură ce introducem sau edităm înregistrări,
conţinând, de regulă, informaţii explicative cu privire la scopul formularului şi la datele pe care
acesta le prezintă.

61
Crearea formularului CURSURI
Efectuăm clic pe Formulare în fereastra Bază de date şi selectăm opţiunea Creare
formular utilizând Expertul. În continuare se selectează tabela cursuri şi acţionăm butonul
OK:

Urmează acum selectarea câmpurilor pe care le dorim în formular. Pentru selectarea tuturor
câmpurilor (situaţia cea mai comună), realizăm clic pe butonul .

La pasul următor se selectează modul de aşezare a datelor în formular. Posibilităţile

sunt: Columnar (datele unei înregistrări sunt prezentate pe coloane), Tabular ( câmpurile sunt
ordonate ca în figura de mai jos şi în formular apar mai multe linii din tabel), Datasheet (ca în
Excel), Justified (o aşezare a câmpurilor unei înregistrări între marginile formularului)
PivotTable (vizualizarea datelor detaliate sau rezumate prin aranjarea câmpurilor în filtru,

62
rând, coloană şi arii detaliu) şi PivotChart (afişarea date vizuală prin selectarea unui tip de
diagramă şi aranjarea câmpurilor în filtru, serie, categorie şi arii date). Un formular PivotTable
efectuează calculele alese, ca sume (implicit pentru câmpurile numerice) şi numărări (implicit
pentru câmpuri text), bazat pe modul în care sunt aranjate datele. De exemplu, un formular
PivotTable poate afişa valorile unui câmp orizontal sau vertical şi apoi calculează totalul
rândului sau coloanei. De asemenea, un formular PivotTable poate folosi valorile unui câmp
drept titluri de rând sau de coloane, calculând cantităţile individuale la intersecţia titlului
fiecărui rând cu fiecare coloană, iar apoi calculând subtotaluri şi totaluri generale. De
exemplu, pentru a analiza produsele vândute de fiecare angajat: se pot lista numele
angajaţilor ca titlurile coloanelor în partea superioară a formularului PivotTable, produsele ca
titlurile rândurilor în partea de jos a formularului PivotTable, iar suma vânzărilor calculată
după produse pentru fiecare angajat la intersecţia fiecărui rând cu fiecare coloană. Formularul
PivotChart permite reprezentarea grafică a datelor, folosind tipurile oferite de Excel: coloană,
bară, structură inelară, radială, etc.

În următoarea fereastră se selectează stilul formularului (stilul implică un fundal, un tip de font
pentru date, culori, aşezare etc.):

63
 Ultimul pas se referă la alegerea unui nume pentru formular şi dialogul se încheie cu
clic pe Finish.

Un alt formular (cu numele elevi) este proiectat asemănător; la activarea sa (de
exemplu, cu dublu clic) va afişa, în forma proiectată, conţinutul curent al tabelei ELEVI. Iată
cum se reflectă corecţia efectuată în câmpul şcoala, pentru elevul cu numărul matricol 303
(schimbarea valorii câmpului din 26 în 28):

Vom observa în continuare cum arată acest formular în mod proiectare (această vedere se
poate obţine selectând formularul în fereastra Database şi apoi realizând clic pe butonul
Proiect):

64
Fiecare componentă a formularului (Antet, Detaliere, Subsol) are proprietăţi care se pot seta
prin deschiderea meniului contextual aferent (clic dreapta pe şi selectarea
opţiunii Proprietăţi, care deschide meniul prezentat în continuare).

Cu ajutorul instrumentelor barei Toolbox, care se afişează automat în mod proiectare,

formularului i se pot adăuga elemente grafice, numite controale:

Acestea au funcţii numeroase şi complexe, dar eticheta este controlul cel mai simplu
de utilizat. Etichetele afişează textul indicat – astfel au fost create antetul şi subsolul
formularului cursuri.
Să realizăm un subsol şi pentru formularul elevi. Pentru aceasta, urmăm etapele de
mai jos:
• modificăm zona Subsol Formular, plasând cursorul pe linia inferioară, până când
devine de forma: apoi tragem până mărim zona după dorinţă;

65
 • acţionăm butonul Label (al treilea de pe bara de mai sus) şi ducem cursorul în zona
creată. Forma cursorului se schimbă, devenind un simbol A precedat de o cruce.
Punctul unde plasăm mijlocul crucii devine colţul din stânga sus al zonei destinate
etichetei;
• mişcăm cursorul spre dreapta şi în jos, până obţinem dimensiunea dorită a etichetei
şi eliberăm butonul mouse-ului;
• în interiorul zonei etichetei edităm textul dorit şi, dacă dorim, putem modifica
proprietăţile etichetei (culoare de fond, mărimea caracterelor etc.) selectând din
meniul rapid (obţinut cu clic dreapta) eticheta Proprietăţi, ca în imaginea următoare:

Aici, pentru eticheta adăugată în formular s-a modificat culoarea de fundal.

Interogarea bazei de date

Scopul principal al unei baze de date este acela de a furniza utilizatorilor ei
informaţiile de care aceştia au nevoie. Interogarea bazei (în engleză, termenul "query"
desemnează interogarea, cererea, chestionarea) înseamnă adresarea unei solicitări de
informaţie, pe care sistemul de gestiune a bazei de date trebuie să o rezolve şi să returneze
utilizatorului răspunsul dorit. În Access, interogările pot fi:
• simple – pot fi formulate pentru o singură tabelă şi se realizează:
ƒ prin vizualizarea datelor conţinute în tabele (de exemplu, dorim să vedem oferta
de cursuri suplimentare şi studiem tabelul CURSURI);
ƒ prin vizualizarea (parţială sau integrală) a conţinutului tabelelor, cu ajutorul
formularelor sau rapoartelor (de exemplu, dorim să cunoaştem care sunt elevii
din clasele a 8-a, participanţi la cursuri suplimentare);
• complexe – comportă în general mai multe tabele şi/sau cereri, ale căror date sunt
extrase prin precizarea unor criterii.
Ca în orice soft complex, aşa cum este şi SGBD-ul Access, o anumită sarcină se poate
rezolva în mai multe moduri. Şi pentru realizarea cererilor de interogare există mai multe
modalităţi, dar vom prezenta în continuare proiectarea în modul Vizualizare Proiect.

66
 • în fereastra Database, clic pe Interogări şi apoi pe Creare interogare în modul
Vizualizare proiect;
• pe ecran apar fereastra Interogare de selectare şi caseta de dialog Afişare Tabel:
o din caseta Afişare Tabel se selectează tabelele şi/sau cererile din care dorim să
extragem date, după care închidem caseta;
o fereastra Interogare de selectare are două zone: cea superioară, în care vedem
tabelele şi/sau cererile selectate, împreună cu legăturile dintre ele şi cea
inferioară, numită grilă de proiectare sau grilă QBE (Query By Example – cerere
prin exemplificare), în care se va proiecta efectiv cererea.

Câmpurile din structura unei cereri sunt de două feluri:

• Preluate. Trecerea unui câmp din tabel/cerere în linia Câmp a grilei QBE se face prin
tragere de mouse. Trecerea tuturor câmpurilor în grilă se realizează fie cu dublu clic
în bara de titlu a listei de câmpuri, clic în lista de câmpuri (pe oricare din ele) şi apoi
deplasarea în grila de proiectare, fie prin deplasarea caracterului * (aflat în capul listei
de câmpuri) în grilă. Această ultimă modalitate permite definirea ulterioară a unor
criterii de selecţie sau de sortare.
• Calculate. Pentru crearea unui câmp calculat, se selectează coloana în care dorim să
apară valoarea calculată şi din meniul View se alege opţiunea Totals, care va
introduce în grila QBE linia Total; se selectează (în celula aflată la intersecţia liniei
Total cu coloana aleasă) Expresie din lista derulantă şi în prima linie (Câmp) se
introduce formula de calcul. De exemplu, pentru a calcula un punctaj egal cu de zece
ori nota obţinută la curs, formula va fi următoarea:
punctaj:[apreciere]*10

67
 Iată şi rezultatul execuţiei cererii (se execută prin dublu clic pe pictograma sa), aşa
cum a fost proiectată până în momentul de faţă:

Sortarea datelor
Ordonarea datelor într-o cerere se poate realiza crescător sau descrescător, după
mai multe câmpuri numite chei de sortare. Se realizează clic în celula din grilă aflată la
intersecţia coloanei câmpului de sortare cu linia Sort şi se alege între Ascending (crescător) şi
Descending (descrescător). Iată grila QBE a unei cereri de interogare prin care se
vizualizează elevii înscrişi la cursurile facultative, în ordinea claselor. În cadrul unei clase,
elevii apar în ordine alfabetică. Prima cheie este de tip numeric iar a doua de tip text.

Rezultatul execuţiei cererii este următorul:

68
 Se observă că ordinea câmpurilor de sortare (în cazul în care sunt mai multe)
influenţează rezultatul obţinut.

Selecţia datelor
Pentru a selecta dintre date pe acelea care ne interesează la un moment dat se
utilizează criterii de selecţie. Acestea pot fi:

• Simple. Se plasează la intersecţia coloanei câmpului pentru care formulăm criteriul cu

linia Criterii din grila QBE. Principalele criterii simple sunt:
o apartenenţa la un interval de valori – se formulează cu ajutorul cuvântului
rezervat BETWEEN. De exemplu, dacă ne interesează elevii cu note între 7 şi 9
criteriul pentru câmpul apreciere va fi: BETWEEN 7 AND 9;
o apartenenţa la o listă de valori – este de forma: IN (valoare1, valoare2, …). Dacă
dorim să vedem datele elevilor din clasele 5, 7 şi 8, criteriul pentru câmpul clasa
va fi: IN (5, 7, 8);
o utilizarea operatorilor de comparaţie: <,>,<=,>=,= şi <>(diferit). Dacă dorim să
selectăm elevii cu punctaj mai mare sau cel puţin egal cu 80, criteriul pentru
câmpul punctaj va fi: >=80;
o utilizarea negaţiei – se realizează cu ajutorul operatorului NOT. Dacă ne
interesează toţi elevii care nu învaţă la şcoala 19, atunci criteriul pentru câmpul
şcoala va fi NOT "19, Al.I.Cuza" (valoarea negată apare între ghilimele deoarece
câmpul este de tip text);
o după o dată relativă la data curentă – se realizează cu ajutorul funcţiei DATE( ).

• Compuse. Se constituie din criterii simple, legate între ele prin operatorii logici AND
(conjuncţia) şi OR (disjuncţia). În acest sens, grila QBE utilizează mai multe linii
Criterii, iar regulile pentru construcţia criteriilor compuse sunt următoarele:
o criteriile simple aflate pe aceeaşi linie Criterii sunt implicit conectate prin AND
(deci vor fi satisfăcute simultan);
o dacă selecţia valorilor unui câmp se face după mai multe criterii simple conectate
prin OR, acestea se vor specifica pe aceeaşi linie. Exemplu:

69
 o dacă selecţia se face după mai multe criterii simple aplicate unor câmpuri diferite,
criteriile fiind conectate prin OR, acestea se vor specifica pe linii diferite.
Exemplu:

Operaţii predefinite
Access permite realizarea unor operaţii de calcul predefinite, care se pot realiza
asupra unui întreg tabel sau asupra unui grup de înregistrări. Sunt disponibile următoarele
operaţii predefinite:
• SUMĂ – calculează suma valorilor unui câmp;
• MEDIE – calculează media aritmetică a valorilor unui câmp;
• MIN – returnează valoarea minimă;
• MAX – returnează valoarea maximă;
• CONTOR – numără valorile dintr-un câmp;
• STDEV (de la Standard deviation) – calculează abaterea medie pătratică sau
varianţa valorilor unui câmp (reprezintă o măsură a abaterii valorilor de la media lor);
• VAR – varianţa statistică a valorilor luate de un anumit câmp;
• PRIM - întoarce prima valoare din câmp;
• ULTIM – întoarce ultima valoare din câmp.

70
 Pentru realizarea unei operaţii de acest gen asupra tuturor înregistrărilor tabelei se
realizează următorii paşi (vom exemplifica pentru a calcula media notelor elevilor):
• se creează o cerere care conţine doar câmpurile asupra cărora vor acţiona operaţiile
de calcul;
• se acţionează View, Totals, efectul fiind introducerea în grila QBE a liniei TOTALS,
care va conţine pentru toate câmpurile operaţia Goup By în capul unei liste derulante;
• se alege din lista derulantă operaţia dorită;
• se execută cererea prin Query, Run şi se observă rezultatul.
Iată cererea în mod proiectare şi imaginea execuţiei acesteia:

Pentru realizarea unei operaţii predefinite asupra unui grup de înregistrări, cel puţin un câmp
din cerere trebuie să conţină operaţia Group By, pentru a se preciza gruparea. Dacă sunt
prezente mai multe criterii de grupare, ordinea de evaluare este de la stânga la dreapta. Iată
o cerere care determină mediile elevilor, grupaţi după cele 4 cursuri. În grila de proiectare se
observă gruparea înregistrărilor după câmpul cod curs:

Iată şi rezultatul execuţiei cererii, pe setul de date utilizat până acum:

71
Se observă formatul general al câmpului AvgOfapreciere (afişarea tuturor zecimalelor
semnificative), iar pentru ultima valoare rotunjirea ultimei poziţii.

Rapoarte
Rapoartele (Reports) sau situaţiile finale constituie prezentări ale datelor pe suport de
hârtie. Aceste rapoarte au fost folosite totdeauna, constituindu-se în documente oficiale,
purtătoare ale semnăturilor persoanelor autorizate. Realizarea unui raport implică
prezentarea datelor dorite într-un format cât mai convenabil, conform cu necesităţile de
informare (de exemplu pot conţine totaluri, subtotaluri, grafice, diagrame). În general, datele
care apar în rapoarte sunt preluate din tabele sau din cereri. Mai ales dacă datele provin din
mai multe tabele se preferă realizarea mai întâi a unei cereri şi apoi a raportului
corespunzător. În afară de datele propriu-zise, situaţiile finale mai conţin:
• controale;
• zone de text;
• cadre (pentru imagini şi grafice);
• etichete (pentru realizarea unui format cât mai atrăgător).
Pentru a crea un raport putem folosi instrumente wizard sau proiectarea directă, dar o
metodă convenabilă este (ca şi în cazul formularelor) îmbinarea acestor două facilităţi, astfel:
• în fereastra Database se activează Rapoarte, apoi Creare raport utilizând Expertul;
• se selectează numele tabelei sau cererii care furnizează datele raportului;
• se trece în mod proiectare (cu clic pe Design View) şi se modifică raportul conform
dorinţei proiectantului, adăugându-se text, controale, etc.
Spre exemplificare, să construim un raport care să prezinte situaţia elevilor înscrişi la
cursurile suplimentare în anul curent. Elevii să fie grupaţi pe şcoli şi pentru fiecare să se
precizeze clasa şi cursul pe care îl frecventează.
Observăm că datele cerute în raport se află în trei tabele: ELEVI (numele, clasa, şcoala),
REPARTIŢIE (corespondenţa elev-curs) şi CURSURI (denumirea cursului). Construim mai
întâi o cerere care să adune aceste date. Iată structura sa, în mod proiectare:

72
 Utilizând metoda descrisă anterior, construim o situaţie finală cu ajutorul instrumentului
wizard, după care o modificăm astfel încât să se plaseze frumos pe o pagină A4, adăugăm un
titlu, un subsol şi linii separatoare între grupurile de elevi aparţinând aceleiaşi şcoli. Forma
Vizualizare Proiect a raportului este următoarea:

Zona de început a situaţiei imprimate corespunde imaginii de mai jos:

ultimele date sunt:

iar sfârşitul listei conţine ziua, data şi numărul paginii curente (din totalul de pagini).

73
 Se observă că structura situaţiei finale include: antetul general, antetul de pagină, antetul
de grup (în cazul de mai sus, cel referitor la şcoală), rândul de detaliu, subsolul de pagină şi
subsolul de raport. După crearea unei situaţii finale, rezultatul poate fi vizualizat (înainte de
imprimare), ceea ce permite verificarea datelor şi a aspectului general al raportului.
Ca şi în cazul celorlalte obiecte, cititorul care studiază aplicaţia Access va descoperi
numeroase posibilităţi de a realiza un raport.

74
 10.2. Bază de date pentru o activitate comercială
În cadrul acestei aplicaţii vom simula activitatea comercială a unei firme. Vom descrie
furnizorii şi produsele achiziţionate de firmă, personalul firmei, clienţii si comenzile pe care
aceştia le emit, precum şi modul de transport al produselor către clienţi. Vom presupune că
un produs, identificat prin codul său, Produs_id, este cumpărat de la un singur furnizor, pentru
a putea relaţiona tabelele Furnizori şi Produse printr-o legătură de tip 1-n. Tot pentru
simplitate, vom considera că fiecare client emite câte o comandă pentru fiecare produs, astfel
că tabelele Clienţi şi Comanda au o relaţie 1-n, iar tabelele Comanda şi Produs_comanda au
o relaţie 1-1.
Aplicaţia este constituită din 8 tabele, având următoarele câmpuri:

1. Agenţi (Agent_id, Nume_agent, Prenume_agent, Funcţie, Născut, Angajat, Adresă,

Oraş, JudeT, Cod_poştal, Tel_acasă, notes)
2. Categorie (Categorie_id, Categorie_nume, Descriere)
3. Clienţi (Client_id, Denumire_client, Persoana_contact, Funcţie_contact, Adresa, Oraş,
Judeţ, Cod_poştal, Telefon, Max_comanda, Min_comanda, Discount)
4. Comanda (Comanda_id, Client_id, Transportator_id, Număr_comandă, Data_comandă,
Client_nume, Client_adresa, Client_oraş, Client_cod_poştal, Discount,
Data_livrării, notes, Agent_id)
5. Furnizori (Furnizor_id, Denumire_furnizor, Persoana_contact, Funcţie_contact, Adresa,
Oraş, Judeţ, Cos_postal, Telefon)
6. Produs_comanda (Comandă_id, Produs_id, Pret_unitar, Cantitate)
7. Produse (Produs_id, Furnizor_id, Categorie_id, Nume_produs, Unitate_măsură,
Preţ_unitar)
8. Transportatori (Transportator_id, Denumire_transportator).

Acest model logic al aplicaţiei evidenţiază atât cheile primare (subliniate cu linie
continuă), cât şi cheile externe (subliniate cu linie punctată).
Crearea tabelelor se poate realiza în trei moduri:
• utilizând fereastra de proiectare (Creare tabel în modul Vizualizare proiect). Este
modalitatea recomandată, pe care o vom explica în continuare.
• utilizând instrumentul Wizard (Creare tabel utilizând Expertul). Se creează tabele prin
alegerea unor câmpuri standard.
• prin introducerea datelor (Creare tabel prin introducere date). Această modalitate nu
poate fi aplicată aplicaţiilor complexe, dar este utilă în cazul aplicaţiilor foarte simple, în
care avem nevoie de rapiditate în crearea tabelelor.
Dacă selectăm opţiunea Creare tabel în modul Vizualizare proiect, se deschide o
fereastră în care se precizează structura tabelului: numele câmpurilor, tipul şi proprietăţile
acestora.

75
Tipurile de bază din Access sunt următoarele:
• Text. Un câmp de acest tip conţine cel mult 255 caractere (implicit, lungimea este de
50). De tip text sunt definite câmpurile care conţin nume de persoane, denumiri,
adrese etc.
• Memo. Pot conţine cel mult 64000 caractere (cu comentarii, explicaţii). Câmpurile de
tip Text şi Memo sunt numite alfanumerice (pot conţine caractere şi/sau numere). Iată
exemple de valori alfanumerice (le vom delimita cu " "): "Dragoş", "Mircea cel
Bătrân", "Oţel laminat OL 50", "X4532A", "345990".
• Număr. Este tipul numeric, cu mai multe subtipuri disponibile, determinate de
dimensiunea câmpului:
o Octet – valori întregi, pozitive, reprezentate pe un octet;
o Întreg - valori întregi, pozitive şi negative, pe doi octeţi;
o Întreg lung – valori întregi, pozitive şi negative, pe patru octeţi;
o Simplă precizie – valori reale, cu cel mult 7 zecimale, pozitive şi negative, pe
patru octeţi;
o Dublă precizie - valori reale, cu cel mult 15 zecimale, pozitive şi negative, pe opt
octeţi;
o ID reproducere – identificator global unic, pe 16 octeţi;
o Zecimal - valori întregi, pozitive şi negative, pe 16 octeţi.
• Dată/Oră. Este un tip special creat pentru date calendaristice sau de tip oră, întrucât
aceste valori se întâlnesc adesea în documente, înregistrări. Permite, de asemenea,
diferite formate de afişare, de exemplu: Sunday, August 11, 2003 şi 8/11/03
reprezintă data de 11 august 2003, duminică iar 5:00:00 PM şi 17:00 reprezintă ora 3
după amiază.
• Monedă. Acest format fix, cu patru zecimale, permite lucrul cu valori monetare.
• AutoNumerotare. Câmpurile de acest tip sunt completate în mod automat pentru
fiecare înregistrare adăugată într-o tabelă, fie crescător, fie cu valori aleatoare
(întâmplătoare), după cum alege utilizatorul.
• Da/Nu. Conţin de fapt valori logice, reprezentate prin –1 (pentru Yes, True –
adevărat) şi prin 0 (pentru No, False – fals).
Observaţie. Câmpurile de tip: Număr, AutoNumerotare, Da/Nu şi Monedă sunt
de tip numeric, deci conţin numere reprezentând: cantităţi, coduri, sume de
bani, valori logice de adevăr. Iată exemple de valori numerice: 23.90, 6785,
1. Vom vedea că o dată numerică poate fi afişată în formate diferite.
• Obiect OLE. Reprezintă obiecte mari, de tipul imaginilor, desenelor, fişierelor audio.
• Hyperlink. Conţine un text ce este o adresă a unei pagini Web.
• Expert căutare. Creează câmpuri care permit alegerea de valori din cadrul unor
structuri (tabele, liste), deci permit legarea informaţiilor.

Iată fereastra de proiectare a tabelului Agenţi:

76
 Observăm cheia primară Agent_id şi proprietăţile câmpului Nume_agent. După
realizarea tuturor tabelelor, relaţiile se construiesc astfel: se acţionează butonul Relationships
de pe bara Database, în fereastra Afişare Tabel se includ toate tabelele deja create, prin
selectarea lor şi apoi punctarea repetată a butonului Adăugare:

Apoi se realizează fiecare relaţie (asociere), prin glisare a mouse-ului de la tabelul

care conţine cheia primară, către tabelul care conţine cheia externă. La fiecare relaţie, va
apărea câte o fereastră de editare, unde se punctează opţiunea Impunere integritate
referenţială, pentru a proteja baza de date la erori cum ar fi următoarea: există produse
dintr-o categorie care nu este încă definită.

Imaginea finală a ferestrei Relaţii este prezentată în continuare.

77
 Introducerea articolelor în tabele se realizează astfel: în fereastra Bază de date se
efectuează dublu-clic pe numele tabelului (de exemplu, Furnizori) şi se introduc valorile
câmpurilor din fereastra care se deschide. În imaginea următoare, se observă cum tabelul
Furnizori are 15 articole. La fel se introduc articole în toate tabelele, în ordinea indicată de
relaţiile deja definite. Dacă se produc erori din punctul de vedere al integrităţii referenţiale,
acestea sunt semnalate printr-un mesaj care cere corectarea câmpului respectiv.

O metodă alternativă pentru introducerea de articole într-un tabel este realizarea unui
formular, care să ofere o altă prezentare a câmpurilor. Un formular creat în modul Vizualizare
proiect este individualizat, deoarece permite intervenţia programatorului la un nivel înalt. În
continuare vom prezenta crearea în acest mod a formularului pentru introducerea comenzilor.
În fereastra Bază de date se selectează opţiunea Formulare şi apoi Creare formular
în modul Vizualizare proiect. După apariţia ferestrei de editare a formularului, prin clic dreapta
pe titlul ferestrei deschidem un meniu contextual din care alegem ultima opţiune: Proprietăţi.

78
 Fereastra Formular permite
alegerea tabelului în care vom
introduce date, prin clic de eticheta
Date şi derularea listei de opţiuni
posibile pentru Sursă înregistrări.
Alegem tabelul Comanda şi
observăm că apare o nouă fereastră
care conţine lista câmpurilor
acestuia:

Prin tragerea câmpurilor din această fereastră (cu ajutorul mouse-ului) până în zona
Detaliu a formularului, fixăm poziţiile lor pe grilă.

Fiecare element al formularului este alcătuit dintr-un text explicativ, respectiv numele
câmpului şi o zonă de introducere a valorii câmpului respectiv. În figura de mai jos este
selectat elementul corespunzător numărului comenzii. Deplasarea relativă a componentelor
se realizează prin tragere de colţul stânga-sus, evidenţiat. Deplasarea integrală se face prin
tragere de margine.

79
 Pentru a obţine o aliniere, se pot selecta
mai multe elemente, prin menţinerea apăsată
a tastei Shift şi tragere de mouse. Apoi se
deschide meniul contextual ataşat prin clic
dreapta pe unul dintre elementele selectate.
Din acesta alegem opţiunea Align, Stânga.
Prin clic dreapta pe grilă putem alege opţiunea
Proprietăţi, care permite selectarea din
eticheta Format a unei culori a grilei (opţiunea
Culoare fundal).

Din acelaşi meniu putem îmbogăţi formularul prin adăugarea unui antet/subsol ale
paginii sau ale întregului formular (Page Header/Footer, Form Header/Footer).
Întroducerea datei şi a orei curente se face prin alegerea din meniul Insert a opţiunii
Date and Time.
Introducerea numărului curent de pagină se face din acelaşi meniu, opţiunea Page
numbers.
La subsolul formularului, introducem menţiunea de responsabilitate, sub forma unei
etichete care conţine numele persoanei care a realizat formularul.
Imaginea următoare prezintă formularul, în modul proiectare.

80
 Acest formular, folosit la introducerea datelor, are următorul aspect:

Să presupunem acum că patronatul doreşte o situaţie a angajaţilor, în care să se

specifice, grupat pe funcţii:
- numele complet al agenţilor,
- data angajării,
- oraşul de domiciliu şi
- numărul lor de telefon.
Pentru a rezolva această cerinţă, se va edita o interogare: în fereastra Bază de date
se selectează Interogări şi se alege opţiunea Creare interogare în modul Vizualizare proiect.
Se adaugă apoi tabela Agenţi, iar în grilă se introduc câmpurile preluate:
- Nume_agent
- Prenume_agent
- Functie
- Angajat
- Oras
- Tel_acasa.
Pentru a realiza cererea, pe rândul Sortare se selectează Ascendentă la câmpurile
Functie şi Angajat. Interogarea se salvează cu numele Agenti Query şi se execută prin dublu
clic pe numele său în fereastra Bază de date.

Iată rezultatul execuţiei interogării Agenti Query:

81
 Rapoartele sunt situaţii finale, care nu mai permit intervenţii ale operatorului. Să
presupunem că se doreşte realizarea unui raport care să conţină agenţii firmei, grupaţi după
oraşele de reşedinţă. În fereastra Bază de date se selectează Rapoarte şi se alege opţiunea
Creare raport utilizând Expertul. În prima fereastră de dialog se aleg câmpurile care se includ
în raport, prin transfer din stânga în dreapta cu ajutorul butoanelor şi . Primul buton
transferă câmpul curent, iar cel de-al doilea transferă toate câmpurile în viitorul raport.

Urmează adăugarea nivelurilor de grupare a articolelor, în cazul nostru este necesară

gruparea după câmpul Oraş, care se alege prin clic pe butonul .

82
 Pentru o aşezare plăcută a articolelor în raport, se alege o sortare a agenţilor din
fiecare grup, crescătoare după câmpul Nume_agent.

Dintre modurile de prezentare, alegem Block, stilul Comun:

83
 În final, alegem numele raportului: Agenţi. Observăm că aplicaţia poate manevra
obiecte diferite (tabel şi raport) cu acelaşi nume.

84
 După salvare, executăm raportul prin dublu-clic pe numele său din fereastra Bază de
date. Imaginea următoare prezintă o parte din raportul Agenţi.

85
 10.3. Bază de date pentru gestiunea unui parc auto
Această aplicaţie propune realizarea unei baze de date conţinând informaţii despre
maşinile dintr-un garaj. Pentru fiecare maşină se vor memora informaţii cum ar fi:
- tipul maşinii;
- destinaţia: transport de persoane sau marfă;
- firma producătoare;
- data fabricaţiei;
- capacitatea cilindrică;
- număr km. parcurşi;
- consumul specific;
- data achiziţionării.;
Aplicaţia va fi dotată cu facilităţi referitoare la validarea datelor introduse. Când
numărul opţiunilor (pentru valorile unei anumite date) este mic, se vor pune la dispoziţia
utilizatorilor opţiunile din care aceştia să aleagă. Vor fi prevăzute principalele operaţii
efectuate asupra datelor în bazele de date:
- adăugarea de noi date;
- modificarea datelor existente;
- ştergerea datelor;
- afişarea datelor pe ecran şi la imprimantă.

Tipul datelor necesar a fi stocate sugerează „un inventar al garajului” la un moment

dat. Maşinile garajului au între ele elemente comune (de exemplu: pot fi de aceeaşi marcă şi
tip sau culoare), după cum la momentul executării „inventarului” unele maşini pot fi plecate în
cursă. De asemenea, pot apărea maşini noi în garaj. Există date ce evoluează datorită unor
„tranzacţii” neevidenţiate (km parcurşi). Modelul informatic al unui garaj real este mai complex
decât cel sugerat aici. În această abordare, nu considerăm modificarea tabelelor, adică nu
vom modela situaţii de genul:
- apariţia unor maşini noi;
- casarea unor maşini;
- plecarea în cursă a unor maşini;
- vopsirea (în altă culoare) a unor maşini;
- schimbarea numărului de circulaţie.
Singurul câmp care se modifică natural, ca urmare a efectuării curselor şi nu ca
urmare a unor greşeli sau evenimente excepţionale, este „numărul de km parcurşi”. Formula
de actualizare a acestui câmp este:
n
[numar km parcursi] = [nr km initiali] + ∑ [nr km cursa]i
i =1

Tabelul următor prezintă datele ce vor trebui memorate:

Câmp Entitate Evolutiv

Tipul maşinii B
Destinaţie: transport de persoane sau marfă B
Firma producătoare A
Data fabricaţiei C
Capacitatea cilindrică B
Număr km. parcurşi D Da
Consumul specific B
Data achiziţionării C

De aici rezultă primele patru entităţi:

• firma producătoare de maşini;
• tipul (marca) maşinii;
• maşina propriu-zisă;
• cursa;
Vom observa că, la modul general, asimilând cursa cu un convoi auto omogen, o cursă poate
avea mai multe maşini şi mai mulţi şoferi.

86
 Cerinţele problemei specifică validarea datelor introduse. Validarea este un
instrument informatic ce împiedică apariţia unor greşeli de introducere simple cât şi a unor
inconsistenţe greu de verificat fără instrumente informatice (exemplu: coduri unice atribuite
repetat). Bazele de date relaţionale s-au îndepărtat puternic de modelul „validării batch”, care
se aplică post-factum pe loturi de date, deoarece au introdus integritatea referenţială bazată
pe chei unice, chei străine şi verificări simple (numerice, logice) înglobate direct în baza de
date şi nu în program. Validările bazate pe integritatea referenţială sunt însă adeseori
completate cu validări-program pe formularele de introducere.
În cele ce urmează, vom înţelege garajul ca o unitate (agent economic) ce dispune de
maşini cu care efectuează curse. Aceste curse determină tranzacţii, stocate fiecare din ele în
baza de date. Ca urmare a curselor, se modifică numărul de km. parcurşi de fiecare maşină.
Iată cum arată fereastra Relationships a bazei de date.

Cu excepţia colţului din stânga-jos, unde sunt specificate două interogări necesare
pentru calculul numărului de km. parcurşi, toate celelalte sunt tabele, având relaţii între ele.
În plus fată de tabele definite deja, în procesul de analiză s-au considerat necesare şi:
• şoferi;
• culori (ale maşinilor);
• tip transport;
• date (adică tranzacţiile curselor).
Cursele sunt cele care determină tranzacţiile. Şoferii fac parte integrantă din
„resursele principale ale curselor”, împreună cu maşinile. Culorile nu apar la fel de importante,
însă în proiectare unei baze de date amănuntele sunt semnificative. Am disociat tip transport
de marca maşinii, deoarece reprezintă o caracteristică comună mai multor maşini, ca şi
culorile maşinilor (pot fi mai multe astfel de caracteristici comune: cauciucuri, tip carburant,
ulei, practic lista poate fi mare, dar ne vom limita la acestea două). Datele (tranzacţiile
curselor) construiesc numărul de km. parcurşi ai fiecărei maşini.
Relaţiile sunt toate de tipul 1 - n, având fiecare coduri interne ale bazei de date cu
cheie unică pe partea 1 a relaţiilor (reprezentată cu bold). Tabelul Date are cheie unică pe
toate cele 3 câmpuri concatenate, pentru asigurarea unei normalizări suficiente şi protecţie la
duplicate incorecte. Acest lucru se realizează astfel: după definirea numelui câmpurilor, a
tipului şi descrierii lor, se selectează cu butonul Shift ţinut apăsat toate câmpurile tabelului şi
se efectuează clic pe butonul Primary Key din bara de instrumente Table Design.
Selecţia câmpurilor se face prin tragere de mouse, în faţa numelui câmpurilor, pe zona gri.
Rezultatul este prezentat în imaginea următoare.

87
Următoarea imagine prezintă fereastra Bază de date a aplicaţiei, cu obiectele de tip tabel.

Paşii necesari realizării aplicaţiei sunt următorii:

1. Proiectarea „pe hârtie” a structurilor de date, conform modelului „entitate-relaţie”;
2. Crearea în access a tabelelor (câmpuri, indecşi, chei unice, validări interne), adică a
celor 8 tabele din structura anterioară;
3. Legarea tabelelor, prin relaţii, asigurând integrităţile referenţiale cu cheia străină
(secundară);
4. Proiectarea părţii vizuale a formularelor (fără elemente de programare VBA access);
5. Adăugarea de cod de validare vba pe câmpurile de introducere date ale formelor;
6. Legarea (după o logica simplă) a formularelor între ele, prin cod vba;
7. Crearea rapoartelor şi conectarea prin diverse controale;
8. Crearea de interogări înglobate pentru aflarea numărului de km parcurşi.

88
S-au folosit controale vizuale: câmpuri text/numerice/date calendaristice, combo, liste,
butoane, control-tab. S-au folosit atât forme simple, cât şi mai complexe (tab-uri, master-
detail), pentru care Access oferă suport puternic şi accesibil. S-au folosit controalele de
navigare implicite ale Access. Toate cheile unice sunt pe câmpuri de tip Autonumerotare
(secvenţe). Următoarea imagine prezintă fereastra Bază de date a aplicaţiei, cu obiectele de
tip formular.

Formularul Startup se autolansează. Codul Visual Basic este următorul

Option Compare Database

Private Sub Detail_Click()

End Sub

Private Sub Form_Open(Cancel As Integer)

DoCmd.SelectObject acForm, "Startup", True
DoCmd.Minimize
DoCmd.Hourglass False
End Sub

Private Sub Start_Click()

On Error GoTo Err_Start_Click
Dim stDocName As String
Dim stLinkCriteria As String
stDocName = "Curse"
DoCmd.Close
DoCmd.OpenForm stDocName, , , stLinkCriteria
Exit_Start_Click:
Exit Sub
Err_Start_Click:
MsgBox Err.Description
Resume Exit_Start_Click
End Sub

Imaginea formularului care se deschide automat la lansarea aplicaţiei este următoarea:

89
După clic pe butonul , acest formular lansează formularul Curse, care este practic cel
mai complex formular al aplicaţiei. În continuare sunt oferite trei imagini ale acestui formular,
pentru a prezenta respectiv: resursele cursei, resursele pentru toate cursele şi distanţa totală
parcursă.

90
Schema obiectelor este următoarea:

91
 Formular Cod Cursa Distanta (km)
Curse Data Start Note
Data Sfarsit

Resursele Grid R/W Forma Soferi

Cursei (soferi,masini)
Forma Masini

Buton soferi
Buton masini
Buton Preview Raport: Curse
Buton Listare
Buton Adaugare
Buton Stergere

Resursele Grid R/O

tururor (soferi,masini-total)

Distanta Grid R/O

Parcursa Totala (distante pe masini)

Observaţii:
- săgeţile groase deschid prin dublu clic (pe grid) opţiunile respective;
- săgeţile groase punctate deschid prin clic opţiunile respective.

Codul formularului Curse este următorul:

Option Compare Database

Private Sub AddSofer_Click()

On Error GoTo Err_AddSofer_Click
DoCmd.GoToRecord , , acNewRec
Exit_AddSofer_Click:
Exit Sub
Err_AddSofer_Click:
MsgBox Err.Description
Resume Exit_AddSofer_Click
End Sub

Private Sub Data_Sfarsit_Exit(Cancel As Integer)

On Error GoTo Err_Data_Sfarsit_Exit
If IsNull(Me![Data Sfarsit]) Then
MsgBox "Completati Data Sfarsit"
Cancel = -1
Else
If Not IsNull(Me![Data Start]) Then
If Me![Data Start] > Me![Data Sfarsit] Then
MsgBox "Data de sfarsit nu poate fi inaintea datei de start"
Cancel = -1
End If
End If

92
 End If
Exit_Data_Sfarsit_Exit:
Exit Sub
Err_Data_Sfarsit_Exit:
MsgBox Err.Description
Resume Exit_Data_Sfarsit_Exit
End Sub

Private Sub Data_Start_Exit(Cancel As Integer)

On Error GoTo Err_Data_Start_Exit
If IsNull(Me![Data Start]) Then
MsgBox "Completati Data Start"
Cancel = -1
Else
If Not IsNull(Me![Data Sfarsit]) Then
If Me![Data Start] > Me![Data Sfarsit] Then
MsgBox "Data de sfarsit nu poate fi inaintea datei de start"
Cancel = -1
End If
End If
End If
Exit_Data_Start_Exit:
Exit Sub
Err_Data_Start_Exit:
MsgBox Err.Description
Resume Exit_Data_Start_Exit
End Sub

Private Sub DeleteBtn_Click()

On Error GoTo Err_DeleteBtn_Click
DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70
Exit_DeleteBtn_Click:
Exit Sub
Err_DeleteBtn_Click:
MsgBox Err.Description
Resume Exit_DeleteBtn_Click
End Sub

Private Sub Distanta_Exit(Cancel As Integer)

On Error GoTo Err_Distanta_Exit
If IsNull(Me![Distanta]) Or Me![Distanta] = 0 Then
MsgBox "Distanta cursei trebuie sa fie mai mare ca zero"
Cancel = -1
End If
DoCmd.Requery
DoCmd.DoMenuItem acFormBar, acRecordsMenu, 5, , acMenuVer70
[Note].SetFocus
Exit_Distanta_Exit:
Exit Sub
Err_Distanta_Exit:
MsgBox Err.Description
Resume Exit_Distanta_Exit
End Sub

Private Sub Open_Soferi_Click()

On Error GoTo Err_Open_Soferi_Click
Dim stDocName As String
Dim stLinkCriteria As String
stDocName = "Soferi"

93
 DoCmd.OpenForm stDocName, , , stLinkCriteria
Exit_Open_Soferi_Click:
Exit Sub
Err_Open_Soferi_Click:
MsgBox Err.Description
Resume Exit_Open_Soferi_Click
End Sub
Private Sub Open_Masini_Click()
On Error GoTo Err_Open_Masini_Click
Dim stDocName As String
Dim stLinkCriteria As String
stDocName = "Masini"
DoCmd.OpenForm stDocName, , , stLinkCriteria
Exit_Open_Masini_Click:
Exit Sub
Err_Open_Masini_Click:
MsgBox Err.Description
Resume Exit_Open_Masini_Click
End Sub

Private Sub TabCtl10_Change()

On Error GoTo Err_TabCtl10_Change
DoCmd.Requery
DoCmd.DoMenuItem acFormBar, acRecordsMenu, 5, , acMenuVer70
Exit_TabCtl10_Change:
Exit Sub
Err_TabCtl10_Change:
MsgBox Err.Description
Resume Exit_TabCtl10_Change
End Sub

Private Sub PreviewBtn_Click()

On Error GoTo Err_PreviewBtn_Click
Dim stDocName As String
stDocName = "Curse"
DoCmd.OpenReport stDocName, acPreview
Exit_PreviewBtn_Click:
Exit Sub
Err_PreviewBtn_Click:
MsgBox Err.Description
Resume Exit_PreviewBtn_Click
End Sub

Private Sub PrintBtn_Click()

On Error GoTo Err_PrintBtn_Click
Dim stDocName As String
stDocName = "Curse"
DoCmd.OpenReport stDocName, acNormal
Exit_PrintBtn_Click:
Exit Sub
Err_PrintBtn_Click:
MsgBox Err.Description
Resume Exit_PrintBtn_Click
End Sub

Formularul Maşini permite vizualizarea datelor şi introducerea de noi articole în baza de date.

94
Butonul acţionat cu dublu clic deschide forma de editare/adăugare item listă. Butonul

permite vizualizarea unui raport asupra maşinilor. Butonul permite tipărirea

acestui raport, iar butonul permite ştergerea unui maşini din baza noastră de date.

Formularul Tip_Transport este mai simplu:

Codul VBA al acestui formular este următorul:

Option Compare Database

Private Sub Form_Load()

If Me.OpenArgs = "GotoNew" And Not IsNull([Cod Tip Transport]) Then

95
 DoCmd.DoMenuItem acFormBar, 3, 0, , acMenuVer70
End If
End Sub

Private Sub SaveBtn_Click()

On Error GoTo Err_SaveBtn_Click
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, ,
acMenuVer70
Exit_SaveBtn_Click:
Exit Sub
Err_SaveBtn_Click:
MsgBox Err.Description
Resume Exit_SaveBtn_Click
End Sub

Private Sub DelBtn_Click()

On Error GoTo Err_DelBtn_Click
DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70
Exit_DelBtn_Click:
Exit Sub
Err_DelBtn_Click:
MsgBox Err.Description
Resume Exit_DelBtn_Click
End Sub

Private Sub ExitBtn_Click()

On Error GoTo Err_ExitBtn_Click
DoCmd.Close
Exit_ExitBtn_Click:
Exit Sub
Err_ExitBtn_Click:
MsgBox Err.Description
Resume Exit_ExitBtn_Click
End Sub

Dintre rapoartele ce se pot realiza în cadrul aceastei aplicaţii, prezentăm Curse şi Tip maşină:

96
Interogările Distanţe şi Distante Query sunt prezentate în continuare.

Fereastra interogării Distanţe presupune adăugarea tabelelor Date şi Curse, iar în

grila QBE a câmpurilor Cod Identificare Masina, Cod Cursa din tabela Date şi a câmpului
Distanţa din tabelul Curse.

Comanda SQL corespunzătoare interogării este:

SELECT DISTINCT Date.[Cod Identificare Masina], Date.[Cod Cursa], Curse.Distanta

FROM Curse INNER JOIN [Date] ON Curse.[Cod Cursa]=Date.[Cod Cursa];

Această comandă este vizibilă dacă din meniul View se alege opţiunea SQL View.

97
 Interogarea Distante Query necesită adăugarea tabelelor Masini şi Distante, iar în
grilă se includ câmpurile Cod Identificare Masina, Număr Maşină, Nr Km Iniţiali din tabela
Maşini şi câmpul calculat Distanţe Parcurse, aflat pe baza valorilor câmpului Distanţa din
tabela Distanţe. În plus, se afişează articolele sortate ascendent după primul câmp al
interogării.

Comanda SQL aferentă acestei interogări este:

SELECT DISTINCTROW Masini.[Cod Identificare Masina], Masini.[Numar Masina],

Masini.[Nr Km Initiali], Sum(Distante.Distanta) AS [Distante Parcurse]
FROM Masini
LEFT JOIN Distante ON Masini.[Cod Identificare Masina] = Distante.[Cod Identificare Masina]
GROUP BY Masini.[Cod Identificare Masina], Masini.[Numar Masina], Masini.[Nr Km Initiali]
ORDER BY Masini.[Cod Identificare Masina];

Funcţiile aplicaţiei

Aplicaţia „Garaj” asigură gestiunea operativă a principalelor resurse ale unui garaj
(privit ca un agent economic), care efectuează curse cu maşini şi şoferi. Fiecare cursă este
memorată individual:
- data start a cursei;
- data sfârşit a cursei;
- distanţa cursei;
- note despre cursă;
- maşini în cursă (pot fi mai multe într-o cursă);
- şoferi în cursă (pot fi mai mulţi într-o cursă).
Se pot adăuga resurse (maşini, şoferi) la garaj. Se pot şterge doar cele complet
nefolosite. Pot exista mai multe maşini de acelaşi tip în garaj. Cursele determina tranzacţiile
curselor:
Tranzacţie=(cod cursă, cod maşină, cod şofer).
Aplicaţia este scrisă în Microsoft Access 2000, constând dintr-un fişier Garaj_lg.mdb
(conform paradigmei Access, acesta conţine tabele, relaţiile între tabele, formulare, rapoarte,
interogări, codul VBA). Pentru introducerea datelor se folosesc formulare cu funcţii de
validare (care ghidează utilizatorul).
Funcţiile aplicaţiei sunt cele generale ale unei aplicaţii de baze de date, dar şi
specifice. Pe scurt, aplicaţia Garaj memorează utilizarea în curse a resurselor (maşini, şoferi)
pentru o anumită perioadă de timp, furnizând un punct de vedere raţional asupra gradului de
utilizare a acestor resurse, cât şi asupra distanţelor parcurse sau planificarea consumului de
carburant pentru curse. Funcţia principală este aceea că oferă managementului garajului

98
suport atât pentru deciziile operative, cât şi pentru planificare şi pentru control, având în
centrul atenţiei cursele auto.
Toate intrările/ieşirile sunt conforme cu schema:

Utilizator → Aplicaţie → Microsoft Access → Sistem de operare PC → hard disc PC

→ monitor PC
→ imprimantă

Elementele vizuale (formulare şi rapoarte) ale aplicaţiei au fost deja prezentate.

Formularul autoexecutabil Startup determină lansarea formularului Curse (ecranul principal al
aplicaţiei). Gridul Resursele cursei este manevrabil cu instrumente implicite (tastele Insert,
Delete, Escape) la nivel de rând, pe care se face şi validarea. Dublu clic pe câmpurile Maşini,
Şoferi ale grid-ului din Resursele cursei lansează formularele Maşini/Şoferi (ceea ce se poate
face şi cu butoanele respective).

În aplicaţie, simbolul este alăturat unei liste ce ramifică programul spre forme de
introducere date (sau editare).

Posibilităţi de modernizare/dezvoltare a aplicaţiei

Având în vedere că este vorba de o aplicaţie simplă, posibilităţile de
modernizare/dezvoltare sunt vaste:
• adăugarea de validări suplimentare atât pe baza de date propriu-zisă, cât şi pe
formulare;
• adăugarea ca tranzacţii noi a celor determinate de cumpărarea/vânzarea unor maşini
din garaj;
• adăugarea ca tranzacţii a consumului efectiv de combustibil (curse, maşini);
• adăugarea diagramelor de planificare a resurselor garajului;
• adăugarea unor rapoarte de consum de combustibil;
• crearea unei aplicaţii mono-formular (formularele multiple pot fi obositoare);
• adăugarea suportului tranzacţional multi-user;
• trecerea la modelul client/server.

99
 10.4. Bază de date pentru contabilitatea TVA

Aplicaţia Access prezentată în acest paragraf a fost realizată în scopul automatizării

contabilităţii TVA din cadrul unei societăti comerciale, pe care să o numim, fictiv, SC ADES
SA. Aplicaţia urmăreşte eficientizarea activităţii contabile, a intrărilor şi a ieşirilor de mărfuri cu
documentele aferente acestei activităţi.
Societatea comercială ADES SRL are ca obiect principal de activitate comerţul cu
ridicata al mărfurilor alimentare. Se doreşte, ca în baza evidenţelor corespunzătoare facturilor
de intrări şi ieşiri să se realizeze rapoartele jurnal de cumpărare şi vânzare pentru luna
decembrie 2004; din acestea se extrag situaţiile referitoare la TVA-ul deductibil şi TVA-ul
colectat, din care să rezulte TVA-ul de plată sau TVA-ul de recuperat de la bugetul de stat.

Nivelul (modelul) conceptual

Nivelul conceptual este nivelul central care reflectă datele structurate astfel încât
acestea să poată fi preluate şi prelucrate cu ajutorul unui SGBD.
Schema conceptuală stă la baza modelului conceptual care va permite definirea
proprietăţilor elementare ale obiectelor care interesează în cadrul SC ADES SA, gruparea
acestora, în funcţie de criterii de omogenitate stabilite, în scopul descrierii obiectelor lumii
reale şi a relaţiilor dintre ele. Sunt definite regulile de care trebuie să se ţină seama în
manevrarea datelor existente. Pe baza regulilor de gestiune se stabilesc cardinalităţi sau
conectivităţi între realizările atributelor din entităţi şi cele ale proprietăţilor din asocieri
(corespondenţe). Acestea exprimă maniera de participare a valorilor atributelor din entităţi la
fiecare apariţie de valori din asocieri. Putem vorbi despre o conectivitate minimă (0 sau 1) şi
una maximă (1 sau n). Vom utiliza modelul entitate – asociere.
În urma analizei problemei rezultă următoarele entităţi, care sunt modelate de tabele:

t_soc, t_furn, t_fact_furn, t_fact_furn_prod, t_client, t_fact_client, t_fact_client_prod.

Identificarea corespondenţelor între aceste entităţi este următoarea:

• t_furn cu t_fact_furn - un furnizor poate emite de la 1 la n facturi, rezulta o corespondenţă

EMITE;
• t_fact_furn cu t_fact_furn_prod - este o relaţie de la 1 la n, unei facturi îi corespund una
sau mai multe înregistrări din tabela t_fact_furn_prod, rezultă deci o corespondenţă LINIE
FACTURA - PRODUSE FURNIZOR;
• t_client cu t_fact_client, se emite factura către clienţi, este o relaţie de 1 la n,
corespondenţa este RECEPTIE;
• t_fact_client cu t_fact_client_prod, relaţia este de 1 la n, corespondenţa este LINIE
FACTURA - PRODUSE CLIENT.

Stabilirea cardinalităţilor

Corespondenţa EMITE
a) dinspre entitatea furnizor (1, n)
- un furnizor emite cel puţin o factură (cardinalitate 1)
- un furnizor poate emite mai multe facturi (cardinalitate n)
b) dinspre entitatea factură (1, 1)
- factura este emisă de cel puţin şi de cel mult un furnizor (cardinalitate 1, 1)

Corespondenţa LINIE FACTURA PRODUSE FURNIZOR

a) dinspre entitatea factura (1, n)
- factura conţine cel puţin un produs (cardinalitate 1)
- factura poate conţine mai multe produse (cardinalitate n)
b) dinspre entitatea produse (1, n)
- un produs este inclus în cel puţin o factură (cardinalitate 1)
- un produs poate fi inclus în mai multe facturi (cardinalitate n)

100
Corespondenţa RECEPTIE
a) dinspre entitatea client (1, n)
- un client primeşte cel puţin o factură (cardinalitate 1)
- un client poate primi mai multe facturi (cardinalitate n)
b) dinspre entitatea factura (1, 1)
- factura este recepţionată de cel puţin şi de cel mult un client (cardinalitate 1,1)

Corespondenţa LINIE FACTURA - PRODUSE CLIENT

a) dinspre entitatea factură (1, n)
- factura conţine cel puţin un produs (cardinalitate 1)
- factura poate conţine mai multe produse (cardinalitate n)
b) dinspre entitatea produse (1, n)
- un produs este inclus în cel puţin o factură (cardinalitate 1)
- un produs poate fi inclus în mai multe facturi (cardinalitate n).

Nivelul logic sau modelul relaţional al datelor

Modelul logic al datelor este reprezentat de următoarea colecţie de tabele:

• t_soc (id-soc, denumire, CUI, judet, localit, strada, cod_postal, sector, telefon,
administrator, banca, cont_bancar)
• t_furnizor (id-furn, cui, denumire, sediu, telefon)
• t_fact_furn (id-fact, id_furn, nr_fact, data, cota_tva)
• t_fact_furn_prod (id-fact, nr_crt, explicatie, cant, pret_fara_tva)
• t_client (id-client, cui, denumire, sediu, telefon)
• t_fact_client (id-fact, id_client, nr_fact, data, cota_tva)
• t_fact_client_prod (id-fact, nr_crt, explicatie, cant, pret_fara_tva)

În reprezentarea de mai sus, atributele subliniate cu linie continuă caracterizează în

mod unic realizările de entitate (un identificator de societate este specific unei societăţi şi
numai uneia, aceeaşi proprietate este valabilă pentru identificatorul unui furnizor, fiecare
furnizor are un identificator de furnizor).
Câmpurile subliniate cu linie punctată au un rol de legătură, modelează relaţiile între
entităţile identificate în faza de analiză. Aceste câmpuri sunt cheile secundare sau externe
(de exemplu, id_furn pentru tabela t_fact_furn, id_client pentru tabela t_fact_client).

Nivelul intern sau modelul fizic al datelor

Nivelul intern (modelul fizic) este cel ce corespunde structurii în care sunt stocate
datele în interiorul calculatorului. Sunt specificate tabelele (fişierele) care le conţin (nume,
organizare, localizare, etc.), componentele fiecărui fişier (lungime, câmpuri), căile de acces la
componentele tabelelor (indecşi, relaţii, legături între tabele).

Relaţii între tabele

Pentru eficientizarea bazei de date este necesară separarea datelor în mai multe
tabele, fiecare având o temă bine definită. Prin această separare se evită redundanţa.
Tabelele astfel rezultate se relaţionează, adică se leagă prin relaţii.
În figura următoare se poate observa fereastra de relaţii a bazei de date.

101
 Primul pas în stabilirea relaţiilor între tabelele bazei de date constă în alegerea tipului
de relaţie folosit: în această aplicaţie, toate cele patru relaţii sunt de tipul 1 - n. Urmează
realizarea acestor relaţii: se deschide fereastra Relaţii şi se adaugă toate tabelele; apoi se
trage cu ajutorul mouse-ului câmpul din prima tabelă către câmpul corespondent din cea de-a
doua tabelă; la deschiderea ferestrei Editare relaţii se bifează opţiunile Impunere integritate
referenţială, Actualizare în cascadă câmpuri corelate, Ştergere în cascadă câmpuri corelate.

102
Formulare
Formularele acestei aplicaţii oferă o interfaţă atractivă pentru vizualizarea sau
introducerea datelor din tabele. Prin faptul că urmăresc introducerea sau modificarea datelor
din tabele, după anumite reguli stricte, impuse de programator, permit eliminarea erorilor
provocate de utilizatori la manevrarea datelor.
În cadrul acestei aplicaţii formularele îndeplinesc funcţii de:
• introducere a datelor, formularele fiind create pentru fiecare tabel, în scopul introducerii
datelor în altă formă decât cea tabelară, creându-se o interfaţă deosebită;
• afişare a datelor într-o formă dorită de utilizator, în scopul consultării acestora;
• editare a datelor, datele afişate în cadrul formularelor pot fi modificate sau şterse.

Aplicaţia conţine următoarele formulare :

1. Formularul principal, în care sunt evidenţiate funcţiile acestei aplicaţii:

2. Formularul cu datele de identificare ale societăţii:

103
3. Formularul cu datele despre furnizorii de produse:

4. Formularul ce conţine facturile emise de furnizorii societăţii ADES SA, cu produsele

achiziţionate de la aceştia:

5. Formularul cu datele de identificare ale clienţilor:

104
6. Formularul ce conţine facturile emise clienţilor de către SC ADES SA, cu produsele
vândute acestora:

7. Subformular ce conţine facturile emise de furnizori cu produsele aferente achiziţionate de

SC ADES SA :

105
8. Subformular ce conţine facturile emise clienţilor de societate:

Interogări

Interogările sunt realizate pentru extragerea datelor şi afişarea organizată a acestora

în diferite modalităţi necesare utilizatorilor. Interogările realizate în cadrul acestei aplicaţii sunt
complexe, utilizându-se mai multe tabele, din care datele sunt extrase prin precizarea unor
criterii.
Pentru realizarea interogărilor s-a ales lucrul în modul Proiectare:
- în fereastra Bază de date, clic pe Interogări şi apoi pe Nou;
- apare caseta de dialog Interogare nouă, în care se alege Vizualizare proiect;
- din caseta AfişareTabel am selectat tabelele şi/sau cererile din care am extras
date.
Fereastra Interogare de selectare are două zone: cea superioară, în care vedem tabelele
şi/sau cererile selectate, împreună cu legăturile dintre ele şi cea inferioară, numită grila de
proiectare, în care s-a proiectat efectiv cererea.
Dintre interogările construite, vom prezenta modul de realizare pentru
q_fact_client_prod, care afişează produsele facturate clienţilor şi valorile TVA aferente
acestora. În caseta Afişare Tabel se aleg cele două tabele care vor participa la interogare:
t_fact_client_prod şi t_fact_client. În grilă se completează, pe coloane, câmpurile pe care le
dorim afişate, mai întâi cele preluate din tabele, iar ultimele două sunt câmpuri calculate cu
formulele: val_fara_tva = [pret_fara_tva] * [cant] şi val_tva = [cant] * [pret_fara_tva] *
[cota_tva] / 100.

106
La execuţia cererii, se obţin următoarele date:

Ce-a de a doua interogare pe care o vom prezenta foloseşte date din 2 tabele şi două
interogări anterioare, pentru a răspunde la întrebarea: Care este valoarea fără TVA şi
valoarea TVA pe fiecare factură? Interogarea q_jv_19 calculează, pentru fiecare factură,
valoarea fără TVA şi valoarea TVA, dacă valoarea din câmpul cota_tva este 19, iar
interogarea q_jv_9 calculează pentru fiecare factură valoarea fără TVA şi valoarea TVA, dacă
valoarea din câmpul cota_tva este 9. După includerea în fereastră a celor patru obiecte care
vor participa la interogare, se trece la completarea grilei. Câmpurile preluate se aleg din
tabele sau din interogări, iar singurul câmp calculat se obţine prin adunarea bazei de
impozitare cu valoarea TVA.

107
Rapoarte

Rapoartele sau situaţiile finale permit extragerea datelor din tabele, constituind
prezentări ale datelor pe suport de hârtie.
Raportul este un obiect al bazei de date asemănător cu interogarea - din punct de
vedere al structurii. Diferenţa faţă de interogări constă în aceea că raportul nu este destinat
afişării pe ecran, ci tipăririi la o imprimantă. Din acest motiv, raportul nu poate fi deschis şi
afişat pe ecran (precum tabelele, formularele şi interogările). Este posibilă numai o
previzualizate a modului cum va arata raportul tipărit.
Rapoartele acestei aplicaţii sunt următoarele:
1. Decontul privind taxa pe valoarea adăugată, este un document contabil, o
declaraţie financiară, ce se întocmeşte de societate în cadrul compartimentului financiar-
contabil pentru fiecare lună. Documentul prezentat reflectă activitatea de vânzare-cumpărare
a societăţii pentru luna decembrie 2004, valoarea facturilor emise de furnizori către SC ADES
SA, precum şi valoarea facturilor emise de SC ADES SA către clienţi, cu procentul taxei pe
valoare adăugată.
Cotele de impozitare prevăzute de lege se aplică la baza de impozitare şi astfel se
determină T.V.A. Aceste cote de impozitare se regăsesc în această aplicaţie şi sunt:
- 19% pentru operaţiunile referitoare la vânzarea-cumpărarea de bunuri şi prestări de
servicii;
- 9% pentru o serie de produse de strictă necesitate cum sunt: carnea de animale şi
păsări, vândute în stare proaspătă, preparate şi conserve, peşte şi produse din peşte,
etc. sau diverse formulare tipizate.

108
Exemplu de calcul a T.V.A. :
În data de 08.12.2004 SC Ades SA vinde către SC Bio Sim SRL 100 de kg.
grâu Dobrogea la preţul unitar de 7000 lei, conform facturii nr. 2584151.
100 kg. x 7000 lei / kg = 700000 lei, care este valoarea facturii fără T.V.A
700000 x 19% = 133000 lei, care este valoarea T.V.A
700000 + 133000 = 833000 lei, care este valoarea totală a facturii (inclusiv T.V.A).
Cu ocazia vânzării produselor, întreprinderea furnizoare percepe (facturează şi
încasează) şi TVA de 19% sau 9% asupra livrărilor. Aceasta suma reprezintă ceea ce numim
TVA colectată. Cum fiecare întreprindere în calitatea ei de client, în momentul aprovizionării a
plătit la rându-i furnizorului său TVA, această TVA deductibilă se va scădea din TVA
colectată, rezultând TVA de plată la buget. Daca TVA colectată este mai mică decât TVA
deductibilă, diferenţa reprezintă TVA de recuperat. Raportul Decont vizualizat în modul
proiect are următoarea imagine.

În partea de antet se observă valori preluate, dar în partea de detaliere se apelează

funcţia complexă DLookUp, care afişează valoarea câmpului care este primul său argument
din tabela al cărei nume este al doilea său argument. Raportul aşa cum ar apărea la
imprimată este prezentat în imaginea care urmează.

109
 Din decontul SC ADES SA aferent lunii decembrie 2004 rezultă următoarele:
Valoarea totală a facturilor recepţionate de la furnizori cu cota de 19% este de 74.256.000 lei
din care:
- 62.400.000 lei este valoarea fără TVA ,
- 11.856.000 fiind valoarea TVA de 19%.
Valoarea totală a facturilor emise clienţilor cu cota de 19% şi 9% este de 89.301.120 lei din
care:
Vânzări de produse cu cota de 19% :
- 71.500.000 lei este valoarea fără TVA,
- 13.585.000 fiind valoarea TVA de 19%.
Vânzări de produse cu cota de 9% :
- 3.868.000 lei este valoarea fără TVA,
- 348.120 lei fiind valoarea TVA de 9%.
Din valoarea totală a TVA aferentă vânzărilor de 13.933.12 lei minus valoarea totală a TVA
aferentă cumpărărilor de 11.856.000 lei obţinem TVA-ul de plată către bugetul de stat de
2.077.120 lei datorită faptului că societatea a înregistrat venituri din vânzarea mărfurilor.
2. Jurnalul pentru cumpărări este un document contabil în care sunt reflectate
achiziţiile de produse, cumpărările efectuate de SC Ades SA. Jurnalul de cumpărări al
societăţii este:

110
Acest raport este obţinut prin execuţia raportului rpt_jc:

3. Jurnalul pentru vânzări este un document contabil care reflectă vânzările de bunuri
către clienţi. Jurnalul de vânzări al SC Ades SA se prezintă astfel:

111
 11. Teste

Testele prezentate în acest capitol oferă posibilitatea autoevaluării, conţinând

subiecte similare celor propuse la examenele de baze de date sau de licenţă (pentru
specializările profilului Economic). Fiecare din testele 11.1 – 11.5 conţine câte 9 itemi, pentru
fiecare acordându-se câte 1 punct (1 punct se acordă din oficiu). Între cele 5 variante de
răspuns, una singură este corectă. Testele 11.6 şi 11.7 sunt mai complexe şi conţin câte 8
itemi pentru care răspunsul trebuie dezvoltat, precum şi o aplicaţie care necesită parcurgerea
tuturor etapelor de realizare a unei baze de date, fiind potrivite abordării în colectiv.

11.1 Testul 1
1. Indicele de calitate a informaţiei ce exprimă „necesitatea de a se dispune de cât mai
multe informaţii (dacă este posibil, de toate informaţiile) referitoare la un sistem economic
analizat” se numeşte:
a. Precizie
b. Oportunitate
c. Completitudine
d. Concizie
e. Actualitate

2. Precizaţi care dintre variante indică alegerea corectă a cheilor candidate şi cea mai
bună alegere a cheii primare, pentru relaţia
Curs (Cod-curs, Denumire-curs, Sala, Ora, Profesor)
Cheia primară este cea subliniată.
a. Cod-curs, Sala
b. Cod-curs, Ora
c. Cod-curs, Profesor
d. Cod-curs, Denumire-curs
e. Cod-curs, Denumire-curs

3. Fie relaţia Personal, ce conţine informaţii despre angajaţii unei fabrici de confecţii:

Marca Nume Prenume Sectia Profesie Salariu

23 Barbu Andreea 1 Inginer confecţii 7000000
67 Barbu Codrin Mihai 2 Economist 7000000
55 Constantinescu Adela 1 Designer 6000000
31 Manoliu Cristian 2 Economist 6000000
20 Parincea Maria Monica 3 Matematician 6000000
11 Semenov Alexandru 1 Inginer maşini 5000000

şi următoarea frază SELECT:

SELECT Nume, Prenume, Salariu
FROM Personal
WHERE Sectia=1;
Această interogare returnează:

a. Lista conţinând numele, prenumele şi salariul tuturor angajaţilor

b. Lista conţinând marca şi profesia angajaţilor secţiei 1
c. Lista conţinând numele, prenumele şi salariul angajaţilor secţiei 1
d. Totalul salariilor angajaţilor
e. Toate informaţiile conţinute în tabela de date

4. Obiectele Microsoft ACCESS care permit accesul la date prin intermediul browserelor
Internet sunt:
a. Tabelele
b. Formularele

112
 c. Cererile de interogare
d. Paginile Web
e. Modulele

5. Formatul corespunzător datei numerice $4,107.85 este:

a. General Number
b. Currency
c. Fixed
d. Standard
e. Percent

6. Operaţia care s-a realizat în cadrul schemei de mai jos este:

Sursă Destinaţie Cost

Iaşi Bacău 100000

Sursă Destinaţie Cost Sursă Destinaţie Cost

Iaşi Bacău 100000 Bucureşti Bacău 250000
Iaşi Bucureşti 300000 Galaţi Bacău 200000
Iaşi Paşcani 40000 Constanţa Bacău 300000
Iaşi Vaslui 120000 Iaşi Bacău 100000
Iaşi Cluj-Napoca 400000

a. Proiecţia
b. Intersecţia
c. Joncţiunea
d. Diviziunea
e. Selecţia

7. Indicaţi tipul relaţiei reprezentate conceptual prin diagrama de mai jos:

CURSURI GRUPE

a. 1-1
b. 1-n
c. n-1
d. m-n
e. 1–3

8. Redundanţa datelor este nulă dacă:

a. Datele apar o singură dată în sistem
b. Nu se realizează validări ale datelor
c. Ansamblul datelor reflectă fidel realitatea pe care o modelează
d. Nu se admit date de intrare în format electronic
e. Datele nu se arhivează

9. Conceptul de partajare a datelor într-o bază de date se referă la:

a. Salvarea din timp în timp a unor copii coerente ale bazei de date
b. Identificarea utilizatorilor bazei de date prin nume sau cod
c. Autentificarea utilizatorilor prin parole
d. Înlănţuirea tranzacţiilor solicitate simultan pe aceeaşi bază de date şi deservirea
ulterioară a acestora
e. Gestiunea unui jurnal de tranzacţii.

113
 11.2 Testul 2

1. Atributul se defineşte ca fiind:

a. O proprietate a unei entităţi sau a unei asocieri
b. Corespondentul unui obiect din lumea reală
c. O instanţiere a unei entităţi
d. O legătură logică între două realizări de entitate
e. O colecţie de instanţe de entitate de acelaşi tip

2. Formularul de analiză (utilizat în faza de analiză a sistemului informaţional existent)

care conţine: volumul şi periodicitatea documentelor, timpul estimat pentru completarea
acestora, tipul lor (de intrare sau de ieşire), forma documentelor (tipizate sau nu) precum şi
necesitatea documentelor se numeşte:
a. Grilă informaţională
b. Lista purtătorilor de informaţie
c. Flux informaţional
d. Lista procedurilor existente
e. Chestionar de opinie

3. Categoria de personal care se ocupă cu asigurarea securităţii datelor şi a cererilor de

informaţie precum şi refacerea bazei de date în cazuri de incoerenţă sau deteriorări
accidentale se referă la:
a. Analişti de sistem
b. Programatori
c. Ingineri de sistem
d. Administrator
e. Operatori

4. Fie relaţia

Contracte (Cod-contract, Tip, Client, Data)

care stochează date despre contractele încheiate de firma de leasing „X” cu clienţii săi şi
interogarea:

SELECT COUNT(*) AS var_1

FROM Contracte
WHERE Data BETWEEN #01/01/03# AND #06/30/03#;

Această interogare are ca rezultat:

a. Lista clienţilor firmei X

b. Lista contractelor cu cea mai mare valoare
c. Lista contractelor încheiate între 1 ianuarie 2003 şi 30 iunie 2003
d. Numărul clienţilor care au încheiat contracte cu firma X între 1 ianuarie 2003 şi 30
iunie 2003
e. Valoarea totală a contractelor încheiate între 1 ianuarie 2003 şi 30 iunie 2003

5. Care din următoarele afirmaţii este falsă?

a. Datorită utilizării pe scară largă a calculatoarelor şi a echipamentelor electronice
cuplate la acestea, majoritatea sistemelor informaţionale au o componentă
informatică.
b. Sistemul informaţional asigură legătura între sistemul de conducere şi sistemul
de execuţie.
c. Sistemul informaţional are un rol de interfaţă între unitatea economică şi mediul
exterior.
d. Un sistem informaţional se creează şi se dezvoltă odată cu activitatea pe care o
reflectă, iar delimitarea lui se realizează prin acte normative.
e. Sistemul informaţional este un subsistem al celui informatic

114
 6. O regulă de validare are următorul rol:
a. Realizează iniţializarea câmpurilor unei tabele
b. Testează, conform unui criteriu furnizat, valorile introduse într-un câmp
c. Stabileşte obligativitatea introducerii unei valori într-un câmp
d. Realizează eliminarea unui index
e. Stabileşte tipul unui câmp

7. Să se precizeze prin ce operaţie a algebrei relaţionale se poate obţine lista cu

localităţile de domiciliu ale studenţilor:

Localitate
Iaşi
Bacău
Constanţa

pornind de la următoarea relaţie STUDENT:

Nume_student Secţie Localitate

Traian Marius CIG Iaşi
Ionescu Maria Biologie Bacău
Dobre Raluca CIG Iaşi
Popovici Ioana Matematică Constanţa
Filipescu Alexandru Biologie Constanţa
Iordan Mihai CIG Bacău

a. Reuniune.
b. Proiecţie.
c. Selecţie.
d. Diviziune.
e. Intersecţie.

8. Dacă un câmp are definiţia NOT NULL, atunci:

a. Poate rămâne necompletat
b. Poate primi numai valori numerice, nenule
c. Este obligatorie introducerea unei valori pentru acesta
d. Poate primi numai valoarea 0
e. Nu poate fi modificat

9. Relaţia CORESPONDENŢI, cu structura şi conţinutul:

Ţara Jurnalişti
Franţa Marin Gabriel, Iurea Victor
Italia Pricop Adrian, Dan Irina
Spania Manoliu Alexandru

se află în forma normală:

a. FN1
b. FN2
c. FN3
d. FN4
e. Nici una dintre acestea.

115
 11.3 Testul 3
1. Operaţiile de: selectare, codificare, conversie de suport, validare sunt specifice,
într-un sistem informatic, fazei de:
a. Culegere şi pregătire a datelor
b. Pelucrare a datelor
c. Memorare a datelor
d. Ahivare a datelor
e. Comunicare / raportare

2. SGBD Micrososft ACCESS este de tip:

a. Ierarhic
b. Reţea
c. Relaţional
d. Funcţional
e. Soft pentru gestiunea unui depozit de date

3. Fie relaţia
CATALOG(nr_matricol, nume, an, nota)
care conţine date despre studenţii secţiei Informatică (numărul matricol, numele, anul de
studiu şi nota la un concurs de baze de date) şi următoarea frază SQL ACCESS:

SELECT nume, nota

FROM Catalog
WHERE an in (2,3) AND nota BETWEEN 8 AND 10
ORDER BY 2;

Această interogare realizează:

a. Lista studenţilor cu note mai mari decât 8, din anii 2 şi 3.
b. Lista studenţilor din anii 2 şi 3 şi nota lor la concurs, ordonată descrescător după
notă.
c. Lista numelor şi notelor studenţilor din anii 2 şi 3, cu note între 8 şi 10, sortată
alfabetic (crescător) după nume.
d. Lista numelor şi notelor studenţilor cu note între 8 şi 10.
e. Afişarea mediei notelor obţinute la concurs de studenţii din anii 2 şi 3

4. Funcţia totalizatoare COUNT, folosită într-o interogare de selecţie SQL ACCESS,

returnează:
a. Numărul de înregistrări care respectă condiţiile stabilite prin clauza WHERE
b. Suma tuturor valorilor dintr-un câmp precizat
c. Valoarea medie a unui câmp numeric precizat
d. Valoarea cea mai mică dintr-un câmp precizat
e. Valoarea cea mai mare dintr-un câmp precizat

5. Care dintre următoarele elemente nu reprezintă obiecte ale unei baze de date
ACCESS:
a. Tabele
b. Fişiere de parametri
c. Formulare
d. Rapoarte
e. Cereri de interogare

6. Având în vedere că un furnizor poate avea mai mulţi clienţi şi un client se poate
aproviziona de la mai mulţi furnizori, relaţia între entităţile FURNIZORI şi CLIENŢI este de tip:
a. 1-1
b. 1-n
c. n-1
d. m-n
e. nici unul din tipurile a,b,c,d

116
 7. Una sau mai multe colecţii de date aflate în interdependenţă, împreună cu descrierea
datelor şi a relaţiilor dintre acestea reprezintă:
a. un fişier
b. un server
c. o structură arborescentă
d. o bază de date
e. o arhivă electronică

8. Pentru o bază de date, care dintre următoarele afirmaţii este falsă?

a. Datele sunt independente de prelucrări
b. Totdeauna, redundanţa datelor este nulă
c. Redundanţa datelor este controlată
d. Este asigurată confidenţialitatea datelor
e. Pot fi utilizate tehnici de prelucrare pentru îmbunătăţirea timpului de optimizare.

9. O comandă Macro reprezintă:

a. Un obiect care conţine proceduri definite de utilizator, scrise în Visual Basic
b. Un obiect care conţine o definiţie structurată a uneia sau mai multor acţiuni pe
care ACCESS le realizează ca răspuns la un anumit eveniment
c. Un obiect care permite vizualizarea informaţiilor obţinute prin prelucrarea datelor
din una sau mai multe tabele şi/sau cereri de interogare.
d. Un obiect care include un fişier HTML şi alte fişiere suport, în vederea furnizării
accesului la date prin intermediul browser-elor Internet
e. Un obiect în care sunt stocate date primare.

117
 11.4 Testul 4
1. Fie asocierea

CLIENT FACTURA

de tip 1-n, unde relaţiile au intensia:

CLIENT(CodClient, Nume, Localitate) şi
FACTURA(NrFactura, Data, ValoareFacturata, CodClient)
iar extensia relaţiei CLIENT este:

10 Microsistem Bacău
20 InfoData Bacău
30 Flamingo Computers Iaşi

Precizaţi care dintre următoarele tupluri poate fi adăugat în tabela FACTURA, astfel încât
pentru atributul CodClient să fie satisfăcută proprietatea de integritate referenţială:

a. 100 12/07/04 3000 40

b. 200 08/08/04 500 80
c. 500 03/23/05 1000 50
d. 101 06/25/04 1000 10
e. 400 01/10/05 700 40

2. Să se precizeze care dintre următoarele colecţii de date se prezintă în a treia formă

normală.

a. PRODUSE1
CodProducător Ţara Caracteristici
Gr11 Grecia Varietatea1; Recolta2
Sp20 Spania Varietatea1; Recolta2
Ro30 România Varietatea2; Recolta1

b. PRODUSE2
CodProducător Ţara ConţinutZahăr Producător
Gr11 Grecia z1000 Alexis
Sp20 Spania z0800 Jose
Ro30 România z0450 Tudor
Gr12 Grecia z1000 Alexis
Sp22 Spania z0800 Jose

c. PRODUSE3
CodProducător Ţara ConţinutZahăr Producător
Gr11 Grecia z1000 Alexis
Sp20 Spania z0800 Jose
Ro30 România z0450 Tudor
Gr12 Grecia z1000 Alexis
Sp22 Spania z0800 Jose

TIP
ConţinutZahăr Producător
z1000 Alexis
z0800 Jose
z0450 Tudor

118
d. PRODUSE4
Ţara CantitateaImportată
Grecia 1000000; 95000
Spania 50000; 70000; 20000

e. PRODUSE5
CodProducător NrLot Data Cantitate
Gr11 N0001 09-04 10000
Gr11 N0001 12-04 10000
Gr11 N0001 01-05 10000
Gr11 N0002 11-04 20000
Sp20 N0005 02-05 25000

3. Precizaţi care dintre următoarele funcţii (ce pot fi incluse în clauza Group By, pentru
gruparea tuplurilor) furnizează valoarea medie pentru atributul specificat?
a. Count
b. StDev
c. Max
d. Min
e. Avg

4. Care următoarele linii ale grilei Query Design permite inhibarea afişării realizărilor
unui câmp?
a. Table
b. Sort
c. Criteria
d. Show
e. Or

5. Proiectarea logică a unui sistem informatic trebuie să se realizeze avându-se în

vedere:
a. O soluţie hardware viitoare
b. O tehnologie existentă
c. Funcţie de cunoştinţele actuale ale programatorilor
d. Independent de echipamente şi software
e. În conformitate cu un sistem deja existent

6. Care dintre următoarele aspecte este esenţial pentru elegerea unui atribut drept
cheie primară a unei tabele?
a. Valorile atributului să fie de tip numeric
b. Valorile atributului să fie de tip caracter
c. Valorile atributului să fie unice
d. Tabela să conţină cel puţin două înregistrări
e. Tabela să fie deja indexată după atributul respectiv

7. Care dintre atributele de mai jos este adecvat pentru a deveni cheia primară a entităţii
CLIENŢI?
a. Nume
b. Cod fiscal
c. Telefon
d. Adresa
e. Banca

8. Câte niveluri de imbricare a formularelor sunt admise în Access?

a. Cel mult două
b. Maximum trei
c. Maximum şapte

119
 d. Nu sunt admise imbricări ale formularelor
e. Oricâte se doreşte.

9. Dată tabela

PRODUSE
CodProdus DenumireProdus Gestiune
A201 Carton Canson 1
A205 Vopsea acrilică 1
A700 Creion B3 2
X309 Pânză pictură 3
B285 Cărbune desen 2

alegeţi varianta care conduce la obţinerea relaţiei

MAGAZII
Gestiune
1
2
3

a. SELECTION (PRODUSE; Gestiune<=3)

b. PROJECT (PRODUSE; Gestiune)
c. PROJECT (PRODUSE; Cod Produs, Gestiune)
d. SELECTION (PRODUSE, DenumireProdus=”Creion B3”)
e. Nici una dintre variantele de mai sus.

120
 11.5 Testul 5
1. Fie relaţiile

STUDENŢI
NumeStudent NumărMatricol
Ionescu Mihai 101
Popa Angela 103
Zaharia Florin 107

şi

NOTE1
NumărMatricol NotaProgramare
101 9
103 8
107 10

Relaţia

LISTA
NumeStudent NumărMatricol NotaProgramare
Ionescu Mihai 101 9
Popa Angela 103 8
Zaharia Florin 107 10

este rezultatul unei operaţii:

a. UNION (STUDENŢI, NOTE1)
b. MINUS (STUDENŢI, NOTE1)
c. SELECTION (STUDENŢI, NotaProgramare>=7)
d. PROJECT (STUDENŢI, NotaProgramare)
e. JOIN (STUDENŢI, NOTE1; STUDENŢÎ.NumărMatricol=NOTE1. NumărMatricol)

2. Dată relaţia CARTE(Autor, Titlu, ISBN, Preţ), precizaţi care dintre următoarele fraze
SELECT va furniza titlurile cărţilor cu preţul între 50000 şi 200000:
a. SELECT DISTINCTROW [Titlu], Preţ FROM CARTE
WHERE Preţ<=200000;
b. SELECT Titlu FROM CARTE
WHERE Preţ>=50000;
c. SELECT DISTINCT Autor FROM CARTE;
d. SELECT Titlu FROM CARTE
WHERE Preţ IN (50000, 100000, 200000);
e. SELECT Titlu FROM CARTE
WHERE Preţ BETWEEN 50000 AND 200000;

3. Pentru tabela PRODUSE creată cu comanda

CREATE TABLE PRODUSE (CodProdus TEXT(4), DenProdus TEXT(15), Um TEXT(4), Preţ
NUMBER, Calitatea NUMBER CONSTRAINT CodProdus PRIMARY KEY(CodProdus));
precizaţi care dintre următoarele comenzi de inserare este corectă:
a. INSERT INTO PRODUSE VALUES ("129”, "AGENDA”, "BUC”, 50000, 1);
b. INSERT INTO PRODUSE VALUES (129, AGENDA, "BUC”, 50000, 1);
c. INSERT INTO PRODUSE VALUES ("129”, "AGENDA”, 50000, "BUC”, 1);
d. INSERT INTO PRODUSE VALUES ("129”, "AGENDA”, "BUC”, "50000", "1");
e. INSERT INTO PRODUSE VALUES (129, "AGENDA”, BUC, 50000, 1);

121
 4. Într-o bază de date, alegerea arhitecturii de stocare a datelor nu trebuie să fie
influenţată de:
a. Cantitatea de date ce urmează a fi memorată
b. Numărul de utilizatori ce vor accesa datele
c. Numărul de tranzacţii pe unitate de timp
d. Limbajul de programare cunoscut de către managerul unităţii beneficiare
e. Resursele financiare disponibile

5. Dacă într-o bază de date s-ar proceda la ştergerea unor date care fac parte din tupluri
în care se găsesc şi alte date care mai sunt încă necesare, această manevră ar reprezenta:
a. O anomalie de modificare
b. O anomalie de adăugare
c. O anomalie de ştergere
d. O violare a integrităţii entităţii
e. O violare a integrităţii referirii

6. Un obiect Access care conţine o definiţie structurată a uneia sau mai multor acţiuni pe
care Access le realizează ca răspuns la un anumit eveniment este:
a. O cerere de interogare
b. Un raport
c. Un formular
d. O comandă macro
e. Un modul

7. O valoare care este atribuită automat unui câmp, atunci când utilizatorul nu introduce
nici o valoare în câmp, se numeşte:
a. Etichetă (Caption)
b. Regulă de validare (Validation Rule)
c. Text de validare (Validation Text)
d. Valoare iniţială (Default Value)
e. Câmp memo

8. Dacă U este o mulţime de atribute şi se manifestă dependenţa X→Y, atunci regula

de inferenţă:
{X→Y, Z⊂U}╞ XZ→YZ
se numeşte:
a. Reflexivitatea dependenţelor funcţionale
b. Amplificarea dependenţelor funcţionale
c. Tranzitivitatea dependenţelor funcţionale
d. Complementarea dependenţelor multivaloare
e. Tranzitivitatea dependenţelor multivaloare

9. Structura care conţine informaţii şi metode de prelucrare a acestora se numeşte:

a. Dicţionar
b. Obiect
c. Clasă
d. Ierarhie
e. Mesaj.

122
 11.6 Testul 6

1. Precizaţi ordinea corectă a etapelor ce trebuie urmate în proiectarea unei baze de

date:
a. alegerea SGBD-ului
b. încărcarea datelor
c. proiectarea schemei interne
d. proiectarea schemei externe
e. proiectarea schemei conceptuale
f. analiza structurală
g. analiza cerinţelor informaţionale
h. analiza temporală
i. integrarea modelelor
j. exploatarea şi întreţinerea

2. Restricţiile de integritate de comportament:

a. se definesc prin egalitatea sau inegalitatea unor valori din cadrul relaţiilor
b. sunt proprii unei anumite baze de date relaţionale
c. sunt obligatoriu de definit.
Precizaţi o restricţie de comportament pentru o bază de date în care figurează relaţia:

PENSIONAR(Nume, Prenume, Vârsta, Adresa)

3. Fie relaţia OLIMPIADA, ce conţine informaţii despre elevii participanţi la un concurs

de informatică organizat la Bacău:

Legiti- Numele Prenumele Clasa Liceul Punctajul

maţie
23 Barbu Andreea 9 „Ferdinand I” Bacău 68
67 Barbu Codrin Mihai 9 „Gh.Vrânceanu” Bacău 70
55 Constantinescu Adela 10 „N. Comăneci” Oneşti 61
31 Manoliu Cristian 9 „H. Coandă” Bacău 84
20 Parincea Maria Monica 10 „Letea” Bacău 50
11 Semenov Alexandru 9 „G. Apostu” Bacău 37

Să se scrie o frază SELECT ce permite afişarea numelor şi punctajului elevilor din

clasa a 9-a, care au obţinut cel puţin 50 de puncte, în ordinea descrescătoare a punctajului.
Câte tupluri conţine rezultatul? Să se scrie numerele de legitimaţie corespunzătoare acestor
tupluri.

4. Transformaţi relaţia de mai jos (de tip ) în două relaţii de tip 1-n:

REVISTE CITITORI

AI Journal Ionuţ

PC Magazine Ştefan

CD Forum Maria

5. Care sunt caracteristicile SGBD Access? Ce instrumente de ajutor oferă? Ce tipuri de

obiecte pot fi incluse într-o bază de date Access?

123
 6. Ce este un depozit de date? Indicaţi câteva elemente specifice unui depozit de date.

7. Cum se realizează protecţia unei baze dae date la nivel utilizator?

8. Cum pot fi accesate bazele de date Access pe Internet?

9. Aplicaţie. Catedra de Informatică organizează un simpozion cu participare

internaţională. Pentru aceasta, responsabilul cu activitatea ştiinţifică decide implementarea
unei baze de date relaţionale. Se doreşte ca, utilizând datele incluse în baza de date, să se
obţină următoarele informaţii:
- Lista secţiunilor simpozionului (codul şi denumirea)
- Lista lucrărilor şţiinţifice prezentate pe secţiuni
- Lista lucrărilor ştiinţifice pe Institute de Învăţământ Superior, în numele cărora s-au
înscris lucrările la simpozion
- Lista autorilor (nume, prenume, adresa profesională şi adresa personală) care vor
susţine lucrări pe secţiuni.
Se cere să se elaboreze modelul relaţional al bazei de date.

124
 11.7 Testul 7
1. Ce înseamnă modelarea datelor şi de ce este necesară?

2. În ce constă optimizarea unei baze de date?

3. Ce înseamnă replicarea unei baze de date?

4. Ce înseamnă normalizarea datelor şi care este scopul normalizării?

5. Care sunt implicaţiile accesului concurent la o bază de date?

6. Care sunt caracteristicile bazelor de date distribuite?

7. Ce este o bază de cunoştinţe?

8. Care sunt problemele actuale ale dezvoltării de aplicaţii cu baze de date?

9. Aplicaţie. Se propune realizarea informatizării bibliotecii unei Instituţii de Învăţământ

Superior, folosind o bază de date relatională. Se fac următoarele precizări:
- În bibliotecă se află exemplare ale unor lucrări de mare interes; fiecare exemplar are
un cod de identificare unică;
- Fiecare lucrare are un titlu, un număr ISBN, o editură în care apare şi unul sau mai
mulţi autori;
- Exemplarele pot fi imprumutate de catre cadrele didactice, doctoranzi sau studenţi;
- Exemplarele se împrumută în baza unui bon de împrumut, în care se pot trece mai
multe cărţi imprumutate;
- În momentul împrumutului se precizează data de împrumut şi data returnării cărţilor.
Cititorilor le sunt utile următoarele informaţii:
- Lista lucrărilor existente în bibliotecă;
- Lista exemplarelor existente în bibliotecă pentru fiecare lucrare;
- Lista cititorilor care nu au returnat la termen exemplarele împrumutate;
- Lista lucrărilor existente în bibliotecă pe o anumită temă.
Se cere să se elaboreze modelul relaţional al bazei de date.

125
 BIBLIOGRAFIE

1. [Bas97] Bâscă O. – Baze de date, Editura All, Bucureşti, 1997

2. [Bro98] Browne A., Balter A. – Bazele Access 95, Editura Teora, 1998

3. [Dim99] Dima G., Dima M. – FoxPro 2.5, 2.6 sub DOS, Editura Teora, 1999

4. [Ede02] Edelhauer, E. Ionică, A. – Sistemele de Gestiune a Bazelor de date Access,

FoxPro. Manual de utilizare, Editura Universitas, Petroşani, 2002

5. [Fel96] Felea, V. – Baze de date relaţionale. Dependenţe, Editura Universităţii Al. I.

Cuza, Iaşi, 1996

6. [Flo99] Florescu V., Stanciu V., Cozgarea G., Cozgarea A. – Baze de date, Editura
Economică, Bucureşti, 1999

7. [Gro96] Grommes, B., Hampe K. – Secretele sistemului FoxPro 2.5 pentru DOS,
Editura Teora, 1996

8. [Lue99] Luers, T. – Bazele Oracle 7, Editura Teora, 1999

9. [Lun95] Lungu I., Bodea C., Bădesc G., Ioniţă C. – Baze de date. Organizare,
proiectare şi implementare, Editura All, Bucureşti, 1995

10. [Lun96] Lungu I., Muşat N., Velicaru M. – Sistemul FoxPro 2.6. Prezentare şi aplicaţii,
Editura All, 1996

11. [Nas00] Năstase P., Mihai F., Cosăcescu L., Bărbulescu B., Stanciu A., Şova R.A.,
Covrig L. – Baze de date. Microsoft Access 2000, Editura Teora, Bucureşti,
2000

12. [Opr02] Oprea D., Airinei D., Fotache M. – Sisteme informaţionale pentru afaceri,
Editura Polirom, 2002

13. [Tod02] Todoroi D., Micuşa D., Clocotici V., Linga I., Ţapcov V., Drucioc N., Calcatin A.,
Morari M. – Data Bases and Communication Tools. MS Access 2000, Editura
ASEM, Chişinău, 2002

14. [Tod04] Todoroi D., Micuşa D., Spătaru S., Andronatiev V., Todoroi Z., Donici S. –
Databases and Multimedia Communications (Teaching Aids), Series IEEE-
2000, Chişinău, 2004

127