CUPRINS

CUPRINS ............................................................................................................................. 4
Introducere ........................................................................................................................... 5
I. Consideraţii generale privind stocurile de resurse materiale ale organizaţiei ........... 7
1. Definirea stocurilor organizaţiilor ............................................................................. 7
2. Proprietăţile stocurilor ................................................................................................ 9
3. Raţiunea şi necesitatea stocurilor ............................................................................. 13
II. Concepte de bază ale modelului relaţional................................................................. 17
III. Analiza şi proiectarea bazelor de date ...................................................................... 27
IV. Studiu de caz ................................................................................................................ 29
1 Descrierea obiectelor folosite ..................................................................................... 31
2. Proiectarea tabelelor şi stabilirea relaţiilor............................................................. 34
3. Crearea interogărilor ................................................................................................ 39
4. Crearea rapoartelor .................................................................................................. 58
5. Crearea formularelor ................................................................................................ 63
6. Crearea macrourilor ................................................................................................. 64
7. Realizarea meniurilor aplicaţiei ............................................................................... 66
CONCLUZII ...................................................................................................................... 79
BIBLIOGRAFIE ............................................................................................................... 80
 Introducere

Sistemul informatic este definit ca ansamblul de metode şi mijloace care asigură

preluarea datelor, transformarea lor în informaţie, prelucrarea sistematică a acesteia prin
utilizarea tehnicii de calcul şi furnizarea rezultatelor prelucrării sub formă de informaţie
interpretabilă.
Indiferent de domeniul de activitate, bazele de date reprezintă un suport
indispensabil al sistemelor informatice. S-a constatat că rezultatele cercetării în domeniul
bazelor de date au avut un impact major asupra întregii activităţi economice şi sociale,
modificând esenţial modul de operare al organizaţiilor. Astfel, bazele de date, prin evoluţia
lor, au determinat progrese fundamentale în sistemele de comunicaţii, transport şi logistică,
gestiunea financiară, aplicaţii civile şi din domeniul apărării.
Bazele de date constituie structuri ale informaţiei, accesibile cu ajutorul
calculatorului, care oferă avantajul stocării unei cantităţi mari de date, date care pot fi cu
uşurinţă accesate de mai mulţi utilizatori.
Din această categorie face parte şi produsul Microsoft Access al firmei Microsoft şi
constituie un instrument simplu şi eficace în implementarea şi exploatarea unei baze de
date. Făcând parte din pachetul Microsoft Office, Access permite comunicarea cu celelalte
programe ale pachetului (Word, Excel, PowerPoint) şi de asemenea oferă posibilitatea
comunicării directe cu serviciul Internet. De asemenea, programul permite accesarea
informaţiilor din baza de date şi prin intermediul limbajului SQL.
Aplicaţia proiectului tratează gestiunea unei societăţi comerciale care are ca obiect
de activitate către clienţi a materialelor din lemn şi pvc. Societatea se aprovizionează de la
diverşi furnizori, care în funcţie de cantitatea comandată fac periodic reduceri de preţuri..
Se urmăresc atât furnizorii care furnizează produsele şi modul de plată către aceştia, cât şi
modul de desfacere a produselor.
Informatizarea întregii activităţi presupune culegerea datelor, întocmirea automată a
listelor de preţ care includ actualizări de preţ şi vizualizarea diferitelor date statistice care
reflectă activitatea societăţii.
Lucrarea a fost împărţită în trei părţi:
Prima parte cuprinde câteva consideraţii asupra contabilităţii de gestiune. Sunt
reflectate conceptele şi obiectivele contabilităţii de gestiune, funcţiile si rolul contabilităţii
de gestiune si calculaţia costurilor, Raportul dintre contabilitatea financiara si contabilitatea
de gestiune.
Partea a doua prezintă conceptele de bază referitoare la sistemele de gestiune a
bazelor de date şi în special a sistemului de gestiune Access.
Partea a treia are în vedere etapele necesare a fi parcurse în realizarea unei aplicaţii
concrete şi prezentarea unui studiu de caz ca o exemplificare a proiectării şi realizării unui
program de gestiune bazelor de date, concret a materialelor dintr-o societate comercială.
Programul de gestiune a materialelor din societatea comercială, pe lângă aspectul
practic, urmăreşte şi atingerea principalelor facilităţi şi obiecte puse la dispoziţie de
programul Access. Astfel programul, prin interfaţa cu utilizatorul, cuprinde toate tipurile
de obiecte ce fac parte dintr-o bază de date Access, modul de accesare a acestora şi
caracterul practic al acestora.
 I. Consideraţii generale privind stocurile de resurse materiale
ale organizaţiei

1. Definirea stocurilor organizaţiilor

Stocurile reprezintă cantităţi de materiale care se acumulează în depozitele şi

magaziile agentilor economici, firmelor, într-un anumit volum, pe o perioadă determinată,
cu un scop bine precizat, reprezentând rezultatul activităţii de asigurare materială şi
desfacere.
Într-o altă abordare, ce doreşte să surprindă mai bine rolul îndeplinit de stocuri,
acestea pot fi considerate cantităţi fizice de materiale, necesare fiecărei faze a ciclului de
exploatare, pentru a asigura desfăşurarea continuă şi ritmică a activităţii de exploatare.
Scopul formării stocurilor este diferit:
-guvernul constituie stocuri sub forma rezervei pentru a pune economia naţională la
adapost de influenţa factorilor perturbatori ce pot să apară;
-organizaţiile formează stocuri de resurse materiale pentru alimentarea continuă a
locurilor de consum în vederea unei bune desfăşurări a proceselor de exploatare.
Managementul stocurilor asigură alimentarea continuă a procesului de producţie cu
resurse materiale necesare, asigură existenţa acestora în depozitele agentului economic,
acumularea lor, astfel încât la primirea comenzii să poată deservi imediat locurile de
consum.
Stocurile îndeplinesc în principal două funcţii generice:
-funcţia de regularizare, prin intermediul cărei se realizează absorbţia decalajelor
între fluxul de vânzare şi cel de reasigurare, între vânzare şi consum pe de o parte, şi între
producere şi achiziţie pe de altă parte. Aceste acţiuni se realizează în ritmuri şi cu
intensităţi diferite, fiind deci necesară armonizarea lor. Din acest punct de vedere, stocurile
au rol de tampon;
-funcţia de protecţie ce vizează în principal eliminarea cosecinţelor pe care le-ar
putea avea asupra organizaţiilor acţiunea unor factori aleatori, imprevizibili.
Raţiunea principală pentru care sunt menţinute stocurile este aceea că este fizic
imposibil şi economic nepractic ca fiecare element al stocului să ajungă exact unde este
necesar, atunci când este necesar. Chiar dacă ar fi fizic posibil ca un furnizor să realizeze
aprovizionarea cu materii prime la interval de câteva ore, aceasta ar fi totuşi prohibitiv de
scumpă. Producătorul trebuie deci să păstreze stocuri suplimentare de materii prime pentru
a le folosi când sunt necesare în procesul de conversie. Alte motive pentru menţinerea
stocurilor sunt rezumate în următorul tabel:

Nivel Motiv
Imposibilitatea fizică de a obţine
Primar volumul adecvat de stoc exact în
momentul în care este necesar
Randamentul favorabil al investiţei
Stoc tampon pentru reducerea
nesiguranţei
Decuplarea (separarea ) operaţiunilor
Secundar
Nivelarea producţiei
Reducerea costurilor costurilor de
manevrare a materialelor
Achiziţii en-gros

Controlul şi întreţinerea stocurilor reprezintă o problemă comună a tuturor

organizaţiilor din toate sectoarele economiei. Problema stocurilor nu este restrânsă doar la
societăţile comerciale ci în acelaşi mod ea se regăseşte şi în cazul societăţilor nonprofit şi
organizaţiilor nonguvernamentale. Stocurile se regăsesc şi în ferme, gospodării,
întreprinderi industriale, societăţi de comerţ cu ridicata sau cu amănuntul, spitale, biserici,
închisori, grădini zoologice, universităţi, unităţi administrative locale sau naţionale. Într-
adevăr stocurile se regăsesc de asemenea şi în gospodăriile individuale - mâncare,
îmbrăcăminte, medicamente, articole gospodăreşti, etc.
Termenul de stocuri sau “inventar” poate fi folosit cu mai multe înţelesuri cum ar
fi:
stocul de materiale existent în fiecare moment (bunuri tangibile care le putem
vedea, măsura sau număra);
listă enumerativă a tuturor bunurilor fizice;
 cantitatea articolelor existente într-o anumită gestiune;
valoarea cantităţilor de bunuri necesare unei organizaţii într-o anumită perioadă
pentru desfăşurarea optimă a activităţii.
O definiţie mai comprehensivă se referă la inventar ca fiind totalitatea materialelor
depozitate în vederea vânzării, folosirii sau transformării lor.
Stocurile se pot regăsi sub formă de furnituri, materii prime, materiale, produse
neterminate, produse finite şi mărfuri. Furniturile (cele folosite în producţie sunt
prescurtate MRO-maintenance, repair and operating) sunt articole de inventar ce se
consumă în timpul proceselor de fabricaţie şi care nu se regăsesc în produsul finit realizat
cu ajutorul lor. Cele mai des întâlnite sunt rechizitele, materialele de întreţinere, materialele
gospodăreşti, ş.a.
Materiile prime reprezintă articole de stocuri utilizate în cadrul proceselor de
producţie care fiind modificate şi transformate se regăsesc în produsele finite fabricate pe
baza lor.
Producţia în curs reprezintă produse care au parcurs anumite faze ale proceselor de
producţie fiind parţial transformate şi care urmează să mai suporte transformări până ajung
la forma de produs finit.
Produsele finite sunt cele care au parcurs toate fazele procesului de producţie şi
sunt gata pentru a fi vândute, distribuite sau stocate, depozitate.
Mărfurile reprezintă articole de inventar care sunt cumpărate cu scopul de a fi
revândute
Studierea stocului pentru oricare din aceste categorii depinde de entităţile studiate
anterior. Aceasta deoarece un produs finit dintr-o categorie poate fi materie primă pentru
un altul. De exemplu pentru o întreprindere producatoare de frigidere ţevile de cupru
reprezintă materii prime, în timp ce pentru întreprinderea producătoare de ţevi ele
reprezintă produsul finit. Clientul care cumpără un produs poate fi consumatorul final,
vânzător detailist, engrosist, sau un alt producător.
Materialele se află într-o stare nefolositoare sau incompletă înainte de o viitoare
vânzare, folosire sau transformare.

2. Proprietăţile stocurilor
Câteva proprietăţi ale stocurilor sunt universale. Cererea, reaprovizionarea,
constrângerile, costurile, sunt cele mai des întâlnite.
 Cererile reprezintă unităţi consumate din stocuri; reaprovizionările reprezintă
unităţi care sunt adăugate stocurilor; costurile reprezintă cheltuieli determinate de existenţa
sau din contră de inexistenţa stocurilor, iar constrângerile reprezintă limitările impuse
cererii, aprovizionării de costurile de management ori condiţiile fizice, de mediu.
Cererile pot fi categorisite în acord cu mărimea lor şi cu cererea unitară.
Mărimea cererii se referă la magnitudinea cererii şi se exprimă cantitativ. Când
mărimea este aceiaşi de la o perioadă la alta spunem că este o cerere constantă, în caz
contrar ea este variabilă. Când mărimea cererii este cunoscută, atunci spunem că avem un
sistem determinat. Atunci când mărimea cererii nu este cunoscută, sistemul este
nedeterminat. În astfel de cazuri este posibil uneori să se stabilească o distribuţie
probabilistică a cererii.
Cererea unitară este de fapt mărimea cererii pe unitate de timp. Modelul cererii se
referă la modul în care sunt scoase resursele din stoc. Articolele pot fi date în folosinţă-
scoase din stoc-la începutul perioadei, la sfârşitul perioadei, uniform pe tot parcursul
perioadei, sau în alte moduri.
Reaprovizionarea poate fi clasificată în funcţie de mărime, model şi timpul de
aprovizionare. Mărimea reaprovizionării se referă la cantitatea sau mărimea comenzii care
va fi recepţionată. Mărimea lotului poate fi constantă sau variabilă, depinde de tipul de
gestiune a stocului. Atunci când lotul de resurse materiale este recepţionat, de regulă el este
introdus în depozit şi devine o parte a inventarului organizaţiei.
Tipul aprovizionării se referă la modul în care se desfăşoară ea: instantaneu,
uniform sau pe loturi. Aprovizionarea instantanee indică faptul că întregul lot este
recepţionat în stoc în acelaşi timp.
Timpul de reaprovizionare reprezintă intervalul de timp între momentul luării
deciziei de aprovizionare a unei resurse materiale şi momentul în care resursa materială
intră în stoc, şi poate fi constant sau variabil.
Distribuţia probabilistică este folosită în descrierea timpului de aprovizionare
variabil la fel cum este folosită în descrierea cererii variabile.
Constrângerile sunt limitările sistemului de stocare. Constrângerile referitoare la
spaţiul fizic de depozitare pot limita cantitatea depozitată; constrângerile de capital
limitează volumul de bani imobilizaţi în stocuri; facilităţile, echipamentele şi personalul de
asemenea limitează capacitatea de a stoca sau opera stocurile. Politicile manageriale (cum
ar fi aceea potrivit căreia nu trebuie să existe niciodată ruptură de stoc) sau deciziile
administrative (cum ar fi contractele reciproce de aprovizionare), pot limita managementul
materialelor în nenumărate moduri.
Costurile stocării reprezintă ansamblul cheltuielilor determinate de existenţa
respectiv inexistenţa stocurilor.
Obiectivul esenţial al managementului resurselor materiale este de a stoca o
cantitate adecvată de resurse materiale, la locul potrivit, în momentul potrivit şi la cele mai
mici costuri. Costurile cu stocurile sunt asociate operaţiilor de stocare şi sunt rezultatul
acţiunii sau din contră a lipsei de acţiune a managementului în ceea ce priveşte organizarea
sistemului. Există parametrii economici de bază în orice model decizional de stocare iar cei
mai relevanţi sunt următorii:
-costul de aprovizionare;
-costurile de lansare a comenzii sau de organizare a aprovizionării;
-costul de stocare (de depozitare);
-costul cu ruptura de stoc.
De notat că pentru unele articole particulare de inventar doar acele elemente de cost
suplimentare sunt pertinente în analiză.
Costul de aprovizionare al unei resurse materiale este preţul unitar de aprovizionare
obţinut în cazul în care resursa este aprovizionată de la o sursă externă. În cazul în care
resursa materială respectivă este realizată în unitate, costul de aprovizionare reprezintă
costul unitar de producţie. Costul unitar trebuie totdeauna privit ca un cost al articolului aşa
cum apare el în inventar.
Pentru articolele aprovizionate, acest preţ include alături de preţul de aprovizionare
şi orice alte cheltuieli de transport a articolelor respective. Pentru resursele materiale
fabricate în interiorul organizaţiei, costul unitar include cheltuielile directe de personal,
materiale directe şi cheltuielile de regie.
Costul de aprovizionare se modifică în funcţie de nivelele cantitative de comandă
atunci când furnizorii acordă discounturi financiare.
Costurile de comandă se referă la cheltuielile de distribuţie plătite unui furnizor
extern sau costurile suportate în cazul aprovizionării interne. Acest cost variază de obicei
direct proporţional cu numărul de comenzi lansate şi nu în aceiaşi măsură cu cantitatea
comandată. Costul cu comanda include articole de cost cum ar fi: costuri cu formarea
comenzii, recepţia materialelor, controlul materialelor, urmărirea comenzii, etc. În cazul în
care resursa materială este fabricată în interiorul organizaţiei, acest cost cuprinde
cheltuielile cu producerea articolelor comandate.
Costurile de stocare, cuprind cheltuieli asociate cu investiţia în stocuri şi investiţia
în depozite şi întreţinerea acestora. Acestea încorporează elemente de cost cum ar fi:
costurile de capital, taxe, asigurări, manipulare, înmagazinare, costuri cu deteriorarea,
degradarea sau pierderea resurselor materiale.
Costurile de capital se referă fie la pierderea eventualelor venituri ce ar putea fi
obţinute prin investirea sumelor respective în altă afacere, costul de oportunitate, fie la
dobânzile ce trebuie plătite în cazul în care capitalul este obţinut prin împrumuturi.
În multe state, stocurile sunt tratate ca o proprietate taxabilă: cu cât stocurile sunt
mai mari, cu atât taxele ce trebuie plătite pentru deţinerea lor sunt mai ridicate.
Costurile cu asigurarea stocului sunt dependente de suma primei de despăgubire ce
ar fi primită în cazul degradării stocurilor. Prima de asigurare variază direct proporţional cu
mărimea investiţiei în stocuri.
De asemenea în timpul stocării resursele materiale se pot degrada, îşi pot pierde
unele proprietăţi, se pot pierde sau chiar fura. O teorie uzuală din cadrul managementului
materialelor ar fi că aceste costuri de stocare sunt direct proporţionale cu mărimea
investiţiei în stocuri. În general, se poate aproxima costul anual cu stocarea ca fiind între
20 şi 40% din valoarea stocului.
Costurile cu ruptura de stoc reprezintă consecinţele economice ale lipsei de stoc.
Ruptura de stoc poate apărea din cauza întârzierilor în aprovizionare sau fabricaţie.
Ruptura de stoc poate determina oprirea producţiei cu toate costurile ce pot fi antrenate,
inclusiv pierderea profiturilor ce ar fi fost obţinute prin vânzarea produselor finite ce acum
nu pot fi fabricate. La acestea se adaugă eventuala pierdere a unor clienţi în cazul în care
nu există produse finite pe stoc sau nu pot fi înlocuite cu alte produse. Cuantificarea
acestor costuri este foarte dificil de realizat.
Un obiectiv major (dar nu singurul) al managementului materialelor este
minimizarea acestor costuri. Doar costurile care se modifică odată cu modificarea nivelului
stocului trebuie analizate. De exemplu, suma cheltuielilor cu încălzirea, iluminatul,
serviciile de securitate ale unui depozit trebuie ignorate dacă nu variază odată cu
modificarea nivelului stocurilor.
Organizaţiile producătoare de bunuri acumulează costuri de fabricaţie. Până când
resursele materiale nu sunt eliberate, nici un fel de costuri de muncă sau costuri asociate
muncii nu sunt atrase. Dar odată ce fabricaţia începe, aceste resurse materiale acumulează
o valoare tot mai mare asupra lor fiind repartizate costurile cu munca, cheltuielile de
fabricaţie. În final articolele ating valoarea maximă devenind stocuri de produse finite
aşteptând să fie livrate clienţilor.
În cazul unui proces de fabricaţie intermitent unde resursele parcurg anumite stadii
de fabricaţie, în fiecare stadiu sunt adăugate unităţi noi de valoare iar timpul este
”consumat” între stadii (atunci când resursele materiale aşteaptă să intre în fabricaţie, sunt
transferate sau depozitate).
Dacă produsele sunt fabricate în loturi egale la începutul procesului de fabricaţie
resursa materială înglobează doar costul de achiziţie. Fiecare etapă adaugă costuri
adiţionale.
Profilul costurilor adiţionale arată mărimea fiecărui cost care se adaugă produselor
fabricate. Din punct de vedere al investiţiei de capital, ar fi de dorit să se scurteze timpul de
fabricaţie –timpul total pe care trebuie să îl petreacă stocurile în fabricaţie, de la
aprovizionare şi până la transformarea lor în produse finite.

3. Raţiunea şi necesitatea stocurilor

Stocurile există deoarece aprovizionarea şi consumul sunt foarte dificil de

sincronizat. Din mai multe raţiuni, aprovizionarea şi consumul diferă frecvent ca timp şi
cantitate. Aceste raţiuni pot fi explicate prin patru factori care caracterizează stocarea: -
timpul, discontinuitatea, incertitudinea şi economia.
Factorul timp –implicat de lungul proces al producţiei şi distribuţiei, necesar înainte
ca produsele să ajungă la consumatorul final. Timpul este necesar pentru a se desfăşura
programul producţiei - aprovizionarea resurselor materiale, controlul resurselor materiale,
producţia efectivă, desfacerea produsului finit. Câţiva consumatori vor trebui să fie dispuşi
să aştepte pentru a putea aproviziona produsele o anumită perioadă. Managementul
resurselor materiale ale organizaţiei trebuie să intervină pentru a reduce acest timp.
Profitabilitatea firmei poate fi intensificată printr-o bună reputaţie de a avea
produse imediat disponibile într-o perioadă rezonabilă de timp.
Factorul discontinuitate permite tratarea diferitelor operaţii într-o manieră
economică independentă. Managementul materialelor face să nu fie necesară adaptarea
producţiei direct la consum sau să forţeze consumul să se adapteze necesităţilor producţiei.
Stocurile independente de la un stadiu din cadrul procesului de aprovizionare-producţie-
desfacere permit fiecăruia să opereze mai economic. Stocul de materii prime izolează
aprovizionarea de consum, stocurile de produse produse în curs izolează departamentul
producţiei de celelalte, iar produsele finite delimitează desfacerea de producţie.
Discontinuitatea permite firmelor să programeze multe operaţii şi performanţe dezirabile
decât dacă ar trata operaţiile continuu.
Factorul incertitudine priveşte evenimentele neaşteptate care modifică planul iniţial
al organizaţiilor. El include erori în estimarea cererii, variabilitatea randamentului de
producţie, defecţiuni ale echipamentelor, condiţii atmosferice, etc. Atunci când stocurile
sunt imediat disponibile, organizaţiile au o oarecare protecţie împotriva întâmplărilor
neplanificate sau neanticipate.
Factorul economic permite organizaţiilor alternativa reducerii costurilor pe baza
unui management corespunzător al stocurilor. Organizaţiile au posibilitatea aprovizionării
resurselor materiale în cantităţi “economice”. Resursele materiale aprovizionate în cantităţi
mici pot reduce semnificativ costurile cu stocarea şi depozitarea. Pe unitate de stoc
costurile pot fi excesive dacă articolele sunt comandate separat fără să se aibă în vedere
aprovizionarea unor mărimi economice de loturi. Preţul asigurării împotriva riscurilor
determină aprovizionarea unor cantităţi mai mari de resurse. Managementul materialelor
poate să ia măsuri pentru a asigura continuitate producţiei şi a stabiliza forţa de muncă în
afaceri sezoniere sau cu fluctuaţii.
Un alt mod de a explica scopul managementului materialelor este de a introduce o
clasificare funcţională a stocurilor. Bazat pe utilitatea lor, stocurile pot fi încadrate în una
sau mai multe din următoarele categorii:
 Stoc curent;
 Stoc de siguranţă;
 Stoc anticipat, sezonier;
 Stoc în pregătire;
 Stoc de asociere, de legătură;
 Stoc psihologic.
 1.Stocul curent cunoscut şi sub denumirea de stoc de lucru reprezintă stocurile
dobândite şi păstrate conform cerinţelor astfel încât comanda poate fi terminată. Ele
corespund desfăşurarii în condiţii normale a activităţii.
Loturile sunt astfel dimensionate încât să minimizeze comenzile şi costurile de
depozitare, să se obţină reduceri cantitative sau cheltuieli de transport favorabile. În
general volumul mediu al stocului existent la un moment dat, ca rezultat al loturilor
dimensionate, constituie stocul curent.
2.Stocul de siguranţă (adesea denumit şi stoc tampon) reprezintă cantitatea de
resurse materiale păstrată ca rezervă pentru a proteja împotriva incertitudinii livrărilor sau
a cererii. Stocul de siguranţă este aprovizionat peste cantitatea stocată în timpul dintre două
aprovizionări succesive ca o protecţie împotriva rupturii de stoc.
3.Stocul sezonier (sau stocul anticipat) reprezintă cantitatea de resurse materiale
aprovizionată pentru a acoperi vârfurile de cerere sezonieră sau cerinţele aleatorii ( de
exemplu programe promoţionale) sau deficienţele capacităţilor de producţie. El este
aprovizionat înaintea apariţiei cerinţei şi este consumat în timpul perioadei de maximă
cerere, pentru a păstra nivelul producţiei şi a evita ruptura de stoc.
4.Stocul în pregătire (adesea denumit stocul de tranzit sau producţie în curs)
reprezintă cantitatea de resurse materiale puse în tranzit pentru a ţine cont de timpul
necesar pentru recepţionarea materialelor sau transportul lor până la locurile de consum.
În exterior stocul în pregătire se regăseşte sub forma resurselor materiale aflate în
camioane, vase, etc. În interiorul întreprinderii acest stoc este în prelucrare, aşteaptă să fie
introdus în fabricaţie sau mutat.
5.Stocul de asociere (sau stocuri legate) reprezintă resursele materiale acumulate
între activităţi dependente pentru a reduce cerinţele, pentru o sincronizare completă a
activităţii. Se izolează o parte a sistemului de celelalte pentru a permite fiecăreia să opereze
independent.
6.Stocul psihologic (este specific activităţilor comerciale) este expus de către
comercianţii cu amănuntul pentru a stimula cererea având rol de “vânzător mut”. El
sporeşte şansa ca un produs să se vadă şi să se vândă. Rafturile pline sporesc vânzările prin
expunerea în faţa clienţilor a cât mai multă marfă, pentru a crea o vizibilitate cât mai mare.
Rafturile “sărace”, la fel ca şi ruptura de stoc determină scăderea vânzărilor şi pierderea
clienţilor.
 În timp ce celelalte tipuri de stocuri sprijină reducerea costurilor de operare, stocul
psihologic este un stoc generator de venituri. Există o preocupare în legătură cu generarea
veniturilor prin stimularea cererii versus minimizarea costurilor. Se pune întrebarea care
este orientarea aprovizionării.
Stocurile nu sunt păstrate de dragul lor, ci ele reprezintă mijloace de a obţine
rezultatele finale. Desigur sunt tipuri multiple de stocuri pentru a servi unor scopuri de
asemenea variate. Astfel că nu se poate vorbi de un management al socurilor indiferent de
felul lor, dar ele toate trebuie supravegheate şi întreţinute pentru a corespunde funcţiilor
specifice.
Stocarea reprezintă un proces necesar oricărei afaceri. În timp ce factorii funcţionali
şi clasificările funcţionale explică existenţa stocurilor, aceasta nu înseamnă că încercarea
de a le reduce nu trebuie continuată. Stocarea poate să ascundă probleme operaţionale sau
să determine uşurarea problemelor. Este mai uşor să fie eliminate problemele decât să fie
ascunse prin stocuri excesive. O strategie ar fi încercarea de a reduce stocurile prin
minimizarea sau eliminarea piedicilor operaţionale care dictează existenţa lor.
 II. Concepte de bază ale modelului relaţional

Într-o organizaţie exista trei categorii de activităţi care produc informaţii necesare
acesteia: activităţile de intrare a datelor/informaţiilor, de procesare şi de ieşire a
rezultatelor. Informaţiile produse sunt folosite pentru adoptarea deciziilor, controlul
operaţiilor, analiza problemelor şi realizarea de produse sau servicii noi.
Datele sunt fapte, statistici, opinii sau predicţii clasificate pe o anumită bază pentru
a fi stocate, procesate sau regăsite atunci când este necesar.
Informaţiile, în schimb, sunt date care au relevanţă pentru nevoile managerilor şi
contribuie la exercitarea funcţiilor manageriale.
Tehnologia calculatoarelor a mărit viteza de procesare a datelor, a crescut
capacitatea de stocare şi a îmbunătăţit metodele de printare, astfel încât managerii adesea
sunt inundaţi cu date. Dar ei au nevoie de cele mai bune informaţii şi nu de volume din ce
în ce mai mari de date. În plus, managerii se orientează atunci când achiziţionează
calculatoare după cum procedează omologii lor din alte companii, deoarece competiţia fără
o analiză rapidă şi corectă a necesitaţilor informatice din propria organizaţie nu este
posibilă.
Pentru ca informaţia să poată servi eficient procesului decizional şi operaţional, este
necesar să îndeplinească următoarele criterii de calitate:
 să fie oportună; .
 să fie clară;
 să fie completă;
 să fie concisă;
 să fie fidelă; .
 să aibă relevanţă.

Un sistem de gestiune a bazelor de date (Database Management System), pe scurt

SGBD, reprezintă un sistem software care gestionează o bază de date şi care permite
utilizatorului să interacţioneze cu aceasta.
Astfel un SGBD acţionează ca un depozit pentru toate datele şi este responsabil pentru
următoarele acţiuni:
 Stocarea datelor;
  Definirea structurilor de date;
 Manipularea datelor;
 Interogarea (extragerea şi prelucrarea) datelor;
 Asigurarea integrităţii datelor;
 Asigurarea unui mecanism de recuperare a datelor;
 Asigurarea unui mecanism de indexare care să permită un acces mai rapid la
date;
 Păstrarea securităţii datelor;
 Permiterea accesului concurent la date cu păstrarea consistenţei acestora.
Ceea ce este caracteristic aplicaţiilor bazelor de date, este faptul că accentul este pus în
mod deosebit pe operaţiile de memorare şi regăsire asupra unui volum mare de date şi mai
puţin pe operaţiile de prelucrare a datelor. Astfel principala operaţie care apare în orice
aplicaţie de baze de date, este cea de regăsire a datelor în scopul obţinerii de informaţii din
baza de date. Se poate spune că baza de date este creată pentru a fi interogată.
Definirea unui model de date presupune identificarea şi precizarea următoarelor
elemente:
 Structura de date folosită;
 Restricţiile ce trebuie impuse pentru menţinerea corectitudinii datelor.
 În figura de mai jos sunt prezentate elementele componente ale unui SGBD şi
relaţiile dintre ele.

Modelarea datelor şi arhitectura SGBD

Utilizator 1 Utilizator 2 Utilizator n

Nivelul Vedere1 Vedere2 Vedere-n

extern
.....................

Schema
Nivelul conceptual Proiectarea
conceptuală
logică/conceptuală
a bazei de date

Proiectarea
fizică
Schema
Nivelul intern internă a bazei de date

Organizarea fizică Baza de date

a datelor
 În modelul relaţional datele sunt reprezentate ca structuri bidimensionale formate
din linii şi coloane, numite relaţii sau tabele.
O relaţie (tabelă) este formată dintr-un număr fix de elemente numite atribute
(câmpuri), fiecare atribut putând lua valori într-o mulţime finită numită domeniu.
Numărul de atribute ce formează o relaţie determină aritatea sau gradul relaţiei.
Exemplu: datele despre angajaţii unei firme se pot reprezenta ca o relaţie (tabelă) de
entitate 7 astfel: angajat(cod_angajat, nume, prenume, adresă, data_naşterii, sex,
cod_departament), unde angajat reprezintă relaţia (tabela), iar elementele specificate în
paranteză reprezintă atributele.
Elementele unei relaţii, adică setul de date corespunzătoare unei linii a tabelei se
numesc tupluri.
Deci relaţiile sunt reprezentate sub forma unor tabele, în care fiecare rând
reprezintă un tuplu şi fiecare coloană reprezintă valorile tuplurilor corespunzătoare unui
anumit atribut.
Relaţiile ce constituie o bază de date trebuie să satisfacă următoarele condiţii:
a) Fiecare atribut trebuie să poarte un nume care este unic în cadrul relaţiei. Nu sunt
permise două atribute cu acelaşi nume în cadrul unei aceleiaşi relaţii, dar sunt permise două
atribute cu acelaşi nume în două relaţii diferite.
b) Fiecare atribut poate avea doar valori atomice care nu se pot descompune din punct
de vedere logic.
c) Fiecare tuplu este unic. Nu sunt permise tupluri identice (duplicat). Unicitatea unui
tuplu nu este limitată la datele existente: fiecare tuplu trebuie să fie unic tot timpul; astfel
într-o relaţie există întotdeauna unul sau mai multe atribute care asigură că tuplul va
rămâne unic tot timpul.
Un atribut sau un set de atribute care asigură că tuplul este unic, adică care
identifică în mod unic un tuplu se numeşte cheie candidată, pe scurt numită cheie.
De exemplu pentru relaţia angajat(cod_angajat, buletin, nume, prenume,
adresă,data_naşterii, sex, cod_departament), atributele cod_angajat şi buletin pot identifica
în mod unic angajatul, deci ambele pot fi chei candidate.
Pentru fiecare relaţie se alege din mulţimea cheilor candidate o cheie care se
numeşte cheie primară a relaţiei. Eventualele alte chei candidate diferite de cheia primară
se numesc chei alternative.
 În relaţia angajat dată ca exemplu mai sus, oricare din cele două chei candidate
poate fi cheie primară, cealaltă rămânând cheie alternativă.
Când mai mult de un singur atribut este necesar pentru a crea o cheie, cheia
obţinută este o cheie compusă. În cazul unei chei compuse atributele care fac parte din
cheie sunt astfel alese încât nici unul să nu fie în plus, adică nici un atribut nu poate fi şters
din cheia candidată astfel încât partea care rămâne din cheia candidată să identifice în mod
unic tuplurile. Altfel spus, o cheie trebuie să fie minimală. În relaţia angajat(nume,
prenume, adresă, data_naşterii, sex, cod_departament) cheia compusă poate fi formată din
atributele nume+prenume+adresă. Prin ştergerea oricăruia din cele trei atribute, prin cele
două rămase nu se poate identifica în mod unic fiecare tuplu, putând exista doi angajaţi cu
acelaşi nume şi acelaşi prenume.
Nici unul din atributele care alcătuiesc cheia primară nu poate avea valori NULL
pentru nici unul din tuplurile relaţiei. Valoarea NULL este o valoare convenţională prin
care se reprezintă un atribut necunoscut sau neaplicabil.
Cheia străină reprezintă un atribut sau o mulţime de atribute ale unei relaţii R1 care
există şi într-o relaţie R2, nu neapărat distinctă de R1 şi care formează cheia primară a
relaţiei R2. În acest caz se spune că cheia străină din relaţia R1 face referinţă la cheia
primară din relaţia R2.
Valorile pe care le ia cheia străină, dacă nu au valori NULL, trebuie să se
regăsească printre valorile cheii primare la care face referinţă. Altfel se încalcă o regulă de
integritate.
Există posibilitatea ca o cheie străină să facă referinţă la cheia primară din propria
relaţie.
Cod_angajat Nume Prenume Cod_manager
S1 Pop Dan
S2 Miron Valentin S1
S3 Varga Adrian S1
S4 Marinescu Anca S2

Cheie primară Chei străine

În exemplul de mai sus, valorile atributului cod_angajat identifică în mod unic
fiecare tuplu, deci fiecare angajat. In câmpul Cod_angajat aceste valori sunt unice,
distincte. Aceleaşi valori se regăsesc însă şi în câmpul Cod_manager, valori care determină
şeful fiecărui angajat, şef al cărui nume se găseşte în aceeaşi tabelă.
d) Tuplurile pot fi prezentate utilizatorului în orice ordine.
e) Atributele pot fi prezentate în orice ordine.
Relaţiile pot fi manipulate pentru a furniza utilizatorului diferite vederi asupra
datelor, rezultatul fiind o nouă relaţie. Relaţiile produse în urma interogării datelor satisfac
toate regulile la care sunt supuse relaţiile iniţiale.

Constrângeri de integritate
Constrângerile de integritate constituie restricţii aplicate bazelor de date în scopul
asigurării integrităţii datelor.
Constrângerile de integritate se împart în două categorii mari:
 Structurale – cu caracter general,care trebuie satisfăcute de orice bază de
date care foloseşte modelul relaţional. Acestea la rândul lor pot fi:
o De entitate (integritatea entităţii) – când o cheie primară nu poate
conţine atribute ce pot avea valori Null. Cheia primară trebuie să fie
unică şi minimală.
o De referinţă (integritatea referirii) – când valorile unei chei străine
trebuie să fie sau NULL sau să coincidă cu o valoare a cheii primare
la care face referinţă.
 De comportament – specifice fiecărei baze de date.
Constrângerile de comportament au în vedere semnificaţia valorii atributelor din
baza de date respectivă. De exemplu, constrângerile de domeniu restricţionează valorile
unui atribut la o anumită mulţime, iar constrângerile sintactice se pot referi la tipul datelor
sau lungimea atributelor.
De asemenea constrângerile de comportament pot exprima legătura intre valorile
unor atribute diferite; de exemplu valorile unui atribut pot fi dependente de valorile altui
atribut sau set de atribute sau o expresie formată de valorile mai multor atribute trebuie să
se încadreze între anumite limite.
O cheie străină poate fi rezultatul propagării oricărei chei, primară sau candidată.
În acest caz se spune că valoarea cheii străine reprezintă o referinţă la tuplu a cărei
cheie are o valoare identică cu a cheii străine.
 Relaţia care conţine cheia străină se numeşte relaţie de referinţă, iar relaţia care
conţine cheia din care aceasta s-a propagat se numeşte relaţie referită.
Deci condiţiile de integritate referenţială impun ca toate valorile unei chei străine să
se regăsească printre valorile cheii corespunzătoare din relaţia referită.
În cazul în care relaţia de referinţă este una şi aceeaşi cu relaţia referită, se spune că
este o relaţie autoreferită.
De exemplu relaţia ArboreGenealogic(tată, fiu) este o relaţie autoreferită.

T F
ată iu
N A
Cheie primară ULL dam Cheie străină

A C
Normalizarea bazelor de dam ain date
Elementele unui sistem real C Asunt împărţite în două categorii:
entităţi şi legături (asocieri, ain bel relaţii).
Entitatea reprezintă orice obiect de interes pentru care există date înregistrate. De
exemplu, entităţi sunt angajaţi, funcţii, secţii, respectiv profesori, studenţi, facultate.
Entităţile sunt astfel denumite prin substantive şi sunt descrise prin proprietăţi
numite atribute.
Aşa cum s-a arătat anterior, între două sau mai multe entităţi se poate stabili o
asociere nedirecţionată numită relaţie. În cadrul aceleiaşi relaţii, entităţile trebuie să aibă
nume diferite, dar entităţi care participă la relaţii diferite pot avea acelaşi nume.
În modelul relaţional, entităţile devin tabele. Aceste tabele pot fi:
Independente – dacă cheia primară nu conţine chei străine;
Dependente – la care cheia primară conţine cheia străină şi unul sau mai multe
atribute adiţionale;
Subtabele – la care cheia străină se referă la supertabelă, iar cheia primară este acea
cheie străină.
Relaţiile devin tabele speciale sau coloane speciale care fac referinţă la chei
primare.
 Atributele simple devin coloane, iar atributele multivaloare devin tabele dependente
ce conţin cheia străină.
Cardinalitatea unei relaţii este dată de numărul posibil de tuple care participă la o
relaţie. Cardinalitatea poate fi minimă sau maximă şi se împarte în trei categorii:
1:1 (one-to-one), când pentru un tuplu din prima tabelă există cel mult un tuplu în a
doua tabelă.
1:m (one-to-many), când pentru fiecare tuplu din prima tabelă există una sau mai
multe tuple în a doua tabelă. Reciproca nu este valabilă. În acest caz, tabela aflată în partea
„1” a relaţiei se numeşte tabelă primară (părinte sau referită) şi ea conţine cheia primară,
iar tabela aflată în partea „m” a relaţiei se numeşte tabelă asociată (fiu sau de referinţă) şi
ea conţine cheia străină. Astfel se spune că cheia străină din tabela asociată (de referinţă),
face referire la cheia primară a tabelei primare (referite).
M:m (many-to-many), când pentru fiecare tuplu din prima tabelă există mai multe
tuple din a doua tabelă, şi invers, pentru fiecare tuplu din a doua tabelă există mai multe
tuple în prima tabelă.
Exemplu : se consideră entităţile Angajaţi, Funcţii, Magazine, Şefi.
Între tabela Magazine şi tabela Şefi există o relaţie de tipul 1:1, deoarece la un
magazin corespunde un singur şef şi un angajat nu poate fi şef decât la un magazin.
Între tabela magazine şi tabela Angajaţi există o relaţie de tipul 1: m, deoarece la un
magazin corespund mai mulţi angajaţi, dar un angajat nu poate lucra decât într-un singur
magazin. Aceeaşi relaţie de tipul 1:m există şi între tabelele Funcţii şi Angajaţi: o funcţie
poate fi îndeplinită de mai mulţi angajaţi şi în acelaşi timp, un angajat nu poate avea mai
multe funcţii.
Între tabela Magazine şi tabela Funcţii există o relaţie m:m, deoarece într-un
magazin lucrează angajaţi cu mai multe funcţii şi reciproc, o funcţie poate fi îndeplinită de
angajaţi din mai multe magazine.

Atributele caracterizează o entitate sau o relaţie. Orice atribut se specifică prin

nume, tip, valori posibile, valori predefinite, reguli de validare, tipuri compuse.
Mulţimea finită din care atributele pot lua valori reprezintă domeniul.
Exemplu: în cazul tabelei Angajaţi se poate vorbi de domeniul numelor angajaţilor
sau domeniul domiciliilor în care locuiesc angajaţii. Popescu sau Mureşan pot fi atribute
ale domeniului numelor, iar Arad sau Timişoara pot fi atribute ale domeniului domiciliilor
angajaţilor.
La încărcarea, exploatarea şi întreţinerea bazei de date pot să apară date redundante
(care se repetă) sau anomalii de actualizare.
Anomaliile pot să apară la operaţiile de inserare, ştergere sau modificare, atât în
cazul tabelei primare, cât şi în cazul tabelei asociate.
Anomalia de adăugare apare în cazul inserării de noi articole în tabela asociată.
Astfel nu se poate insera un nou articol în tabela asociată dacă nu are corespondent în
tabela primară. Dacă nu este îndeplinită condiţia, inserarea nu se execută. De exemplu, în
cazul relaţiei dintre tabela Magazine (aflată în partea „1” a relaţiei) şi tabela Angajaţi
(aflată în partea „m” a relaţiei), nu se poate insera un angajat într-un magazin care nu există
în tabela Magazine.
Anomalia de ştergere apare în cazul tabelei primare ( referite). Astfel nu se pot
şterge articole din tabela primară atât timp cât mai există articole corespunzătoare în tabela
asociată. În acest caz pentru menţinerea integrităţii referenţiale, există două soluţii:
ştergerea restricţionată sau ştergerea în cascadă.
Conform regulii de ştergere restricţionate, nu se acceptă ştergerea unui articol din
tabela primară cât timp mai există articole asociate în tabela fiu. În exemplul considerat, nu
se poate şterge o secţie din tabela Magazine, cât timp în tabela Angajaţi mai există angajaţi
care lucrează în acel magazin.
Conform regulii de ştergere în cascadă, ştergerea unui articol din tabela primară va
fi urmată automat de ştergerea tuturor articolelor corespunzătoare din tabela fiu. De
exemplu, dacă se şterge un magazin din tabela Magazine, automat vor fi şterşi din tabela
Angajaţi toţi cei care figurau angajaţi la acel magazin.
Anomalia de actualizare apare în cazul tabelei primare. Şi în acest caz există două
soluţii: actualizarea restricţionată şi actualizarea în cascadă.
În cazul actualizării restricţionate, nu se acceptă modificarea valorii unui articol în
tabela primară cât timp există cel puţin un articol corespunzător în tabela asociată. De
exemplu, nu se acceptă modificarea numelui unui magazin în tabela Magazine, cât timp
există angajaţi ai acestui magazin în tabela Angajaţi.
Actualizarea în cascadă permite modificarea unui articol din tabela primară,
operaţie care va fi urmată automat de modificarea articolelor corespunzătoare din tabela
fiu. Astfel, modificarea numelui uni magazin din tabela Magazine aduce după sine
modificarea corespunzătoare a atributelor secţii din tabela Angajaţi
În cazul tabelei fiu, nu există nici un fel de anomalii la actualizare. Orice operaţie
de actualizare în cazul tabelei fiu este considerată ca fiind o operaţie de ştergere urmată de
una de inserare.
 III. Analiza şi proiectarea bazelor de date
Sistemul informaţional dintr-o instituţie este format din resursele care permit
colectarea, administrarea, controlul şi propagarea informaţiilor în întreaga instituţie.
Un sistem informaţional pe calculator cuprinde următoarele elemente:
 baza de date

 elementele de software ale bazei de date

 software de aplicaţie
 elementele de hardware ale calculatorului, inclusiv mediile de stocare

 personalul care utilizează şi dezvoltă sistemul.

Ca urmare, proiectarea unei baze de date relaţionale presupune parcurgerea unei
faze de documentare şi a fazei de realizare propriu-zisă a bazei de date.
In faza de documentare este necesară colectarea tuturor informaţiilor referitoare la
datele ce vor trebui să fie prelucrate şi afişate de viitoarea aplicaţie, cât şi despre viitorii
utilizatori ai bazei de date.
Astfel se pot identifica următoarele etape:
1. Identificarea problemei: conştientizarea necesităţii de a crea o nouă bază de date
sau de a modifica o bază de date existentă;
2. Analiză: studierea informaţiilor existente în vederea stabilirii cerinţelor pentru
noua bază de date;
3. Proiectarea: identificarea şi specificarea echipamentelor hard şi a instrumentelor
(exemplu Access) care urmează a fi utilizate în crearea bazei de date;
Faza de realizare propriu-zisă a bazei de date presupune parcurgerea următoarelor
etape:
 Crearea schemei conceptuale – în care sunt descrise datele şi relaţiile
necesare viitoarei baze de date;
 Crearea design-ului logic al bazei de date – etapă în care schema
conceptuală este transformată în structuri specifice unui anumit SGBD
(exemplu Access). La sfârşitul etapei vor exista un număr de tabele legate
între ele care vor permite stocarea şi manipularea corectă a tuturor datelor
necesare sistemului.
  Crearea design-ului fizic al bazei de date – etapă în care design-ul logic este
transformat într-o structură fizică.
Astfel se poate vorbi despre un ciclu de viaţă al aplicaţiei, fiecărei etape din ciclul
de viaţă al aplicaţiei bază de date, fiindu-i asociate anumite activităţi.
Analiza şi proiectarea sistemelor informatice presupune o serie de principii ,
metode, concepte şi tehnici utilizate pentru prefigurarea, elaborarea şi implementarea
sistemelor informaţionale, care se bazează pe echipamentele electronice de calcul.
Analiza şi proiectarea unei aplicaţii constă în:

 Formularea problemei
 Identificarea şi studierea actelor normative care reglementează activitatea vizată

 Analiza şi inventarierea documentelor care participă la fluxul informaţional

 Precizarea situaţiilor de ieşire (listelor)

 Stabilirea datelor de intrare necesare

 Construirea unei scheme privind structura funcţională a sistemului informatic

 Proiectarea datelor şi a tabelelor

 Stabilirea datelor de intrare-ieşire

 Stabilirea relaţiilor intre tabele

 Stabilirea metodelor de prelucrare a acestora

 Stabilirea drepturilor de acces şi proiectarea sistemului de parole pentru
securitatea informaţiei
 Stabilirea algoritmului de rezolvare pentru fiecare sarcină în parte.
Realizarea aplicaţiei constă în:

 Construirea obiectelor şi a modulelor de program, corespunzător fiecărei sarcini

a sistemului informatic.

 Testarea fiecărui modul în parte.

 Întocmirea unui meniu sau program cadru prin intermediul căruia se pot lansa
în execuţie sarcinile specifice aplicaţiei.

 Verificarea schimbului de informaţie între obiecte.

 Întocmirea documentaţiei de utilizare ce va conţine descrierea meniurilor,
prezentarea principalelor machete de ecran, structura tabelelor, modelul rapoartelor
de ieşire.
 IV. Studiu de caz

O societate comercială doreşte să-şi informatizeze activitatea. Societatea are ca

obiect de activitate desfacerea către clienţi a produselor de tâmplărie şi pvc prin
magazinele proprii. Fiecare magazin este condus de către un gestionar, iar desfacerea
produselor se face pe baza unor facturi. Fiecare factură conţine unul sau mai multe
produse, într-o anumită cantitate.
Pentru desfacerea produselor, societatea comercială se aprovizionează de la diferiţi
furnizori. Pentru fiecare furnizor se ţine evidenţa datelor, adică denumirea furnizorului,
adresa, telefon, banca unde acesta are deschis contul pentru achitarea produselor furnizate
şi sigla firmei furnizoare. Furnizarea produselor solicitate de către societatea comercială se
face pe baza unor comenzi. Fiecare comandă conţine codul produselor comandate şi
cantitatea solicitată. Codul, denumirea şi preţul fiecărui produs sunt extrase dintr-un
catalog al produselor.
Ca urmare structura informaţională a sistemului informatic presupune:
 Introducere de date cu ajutorul formularelor:
o Date referitoare la furnizorii de produse;
o Date referitoare la materialele comercializate;
o Date referitoare la magazinele prin care se desfac produsele.
 Vizualizări de date prin formulare şi interogări:
o Comenzile întocmite şi produsele de pe fiecare comandă;
o Termenele de plată către fiecare furnizor;
o Sumele care trebuie achitate furnizorilor în cazul acordării unor
reduceri pentru comenzi mai mari de 1000000 lei;
o Valorile corespunzătoare fiecărui produs, valori obţinute prin
efectuarea unor calcule cu ajutorul unor interogări cu câmp calculat;
o Întârzierile de plată către diverşi furnizori.
 Interogări de acţiune pentru obţinerea actualizării datelor.
 Întocmirea, afişarea şi tipărirea situaţiilor de ieşire cu ajutorul rapoartelor.
 Ca urmare obiectele care alcătuiesc baza de date şi modul în care acestea sunt
apelate succesiv este ilustrat în următoarea organigramă:

frmIntrareAplicaţie

frmMeniuPrincipal

frmPreluare date frmVizualizare frmInterogări frmListare

date DeAcţiune

frmIntroducere frmComenzi qryActualiz rptValoare

Furnizori Produse CresterePret/prod Produse

frmIntroducere frmFurnizori qryActualiz GRAFIC

Materiale Termene Termene

frmMagazine qryreduceri/coma qryActualiz rptComenzi

ndă ScaderePret/prod

frmValoare qryStergere rptFacturi

Produse material

qryComenzi qryStergere
LunareIncrucisata Furnizori

qryIntarziriPlata

qryComenzi/
Perioade/Banca

qryMatFurniz
DataIncrucisata
 Pentru realizarea aplicaţiei am ales sistemul de gestiune a bazelor de date Access,
un SGBD relaţional modern, componentă a pachetului de programe Microsoft Office,
foarte răspândit pe calculatoarele personale şi folosit pentru baze de date mici şi medii, aşa
cum este cazul bazei de date a acestei societăţi comerciale.

1 Descrierea obiectelor folosite

Aplicaţia, în forma sa finală, utilizează următoarele obiecte:
 Tabele – pentru stocarea datelor (în modul descris anterior)

 Interogări – pentru:
o Combinarea, sortarea şi filtrarea datelor – cu ajutorul interogărilor
de selecţie, pe care s-au aplicat diferite criterii de sortare şi filtrare;
o Efectuarea de calcule şi operaţii totalizatoare – cu ajutorul
interogărilor cu câmp calculat şi a interogărilor cu funcţii agregat
(totalizatoare);
o Actualizări de date - cu ajutorul interogărilor de acţiune.
 Formulare – pentru:
o Introducerea datelor – prin formulare simple sau formulare
compuse, de tipul formular-subformular,
o Vizualizarea datelor – prin formulare realizate pe baza interogărilor
create anterior;
o Realizarea meniurilor;
o Panouri de intrare în aplicaţie sau panouri de trecere de la un meniu
la alt meniu.

 Rapoarte - pentru:
o Sintetizarea datelor – prin rapoarte realizate pe baza interogărilor
create anterior;
o Vizualizarea grafică a datelor – prin realizarea unui raport de tip
Chart;
o Listarea rapoartelor ce ilustrează comenzile efectuate şi facturile
eliberate într-un interval de timp.
 Macro-uri – pentru ataşarea diferitelor butoane de comandă, care fac
trecerea de la un formular la alt formular, precum şi de maximizare a
formularelor create.
2. Proiectarea tabelelor şi stabilirea relaţiilor

Având în vedere considerentele de mai sus, s-au realizat următoarele tabele pe baza
datelor de intrare, tabele prezentate atât în modul design, cât şi în modul datasheet :

tblFurnizori(CodFurnizor, DenFurnizor,
LocalitateFurnizor, Strada, Nr, CodFiscal, Banca, Sediu
banca, Cont, Telefon, sigla)

Pentru câmpurile de tip text s-a aplicat în

fereastra de proprietăţi o mască, astfel încât acestea să
fie afişate numai cu majuscule, indiferent de modul de
introducere al datelor de către utilizator.

Produsele achiziţionate de la furnizori sunt comandate pe baza datelor dintr-un

catalog de produse, ilustrat prin tabelul tblMateriale.

TblMateriale(CodMaterial,
DenMaterial, UM, Preţ)
unde UM reprezintă unitatea de măsură
a produsului, iar pentru câmpul Preţ s-a impus o
mască pentru a afişa în lei şi într-un anumit
format preţul produselor.
 Produsele sunt desfăcute de societatea comercială prin magazinele proprii ale căror
date sunt păstrate în tabelul tblMagazine.

tblMagazine(Codmagazin, DenMagazin,
NumeGestionar, PrenumeGestionar).

La proprietatea caption a câmpului

DenMagazin s-a specificat valoarea Denumire
magazin pentru o mai uşoară înţelegere din partea
utilizatorului.

Evidenţa comenzilor către furnizori este realizată cu ajutorul tabelei tblComenzi,

afişată mai jos, atât în modul Design, cât şi în modul Datasheet.
 tblComenzi (NrComanda, DataComanda,
Termen, CodFurnizor)
unde Termen reprezintă termenul de plată
acordat de furnizor societăţii comerciale pentru
achitarea produselor comandate şi achiziţionate.

Fiecare comandă conţine denumirea produselor şi cantitatea în care a fost

achiziţionată, date păstrate în tabelul tblContinutComanda.
Între tabelul tblComanda şi tabelul tblContinutComanda este o relaţie de tipul 1-M,
fiecărei comenzi, identificată printr-un număr de comandă corespunzându-i un anumit
conţinut.
Denumirea produselor a fost preluată din tabelul tblMateriale, câmpul CodProdus
fiind ales de tip Lookup Wizard, astfel încât valorile câmpului CodProdus vor putea fi
alese din lista de valori ale câmpului DenProdus din tabelul tblMateriale. De asemenea şi
numărul comenzii pe care se află produsele respective a fost preluat din tabelul
tblComenzi, prin stabilirea tipului de dată Lookup Wizard în cazul câmpului NrComanda.
Ca urmare, în tabelul tblConţinutComanda câmpurile NrComanda şi CodProdus constituie
chei străine care referă cheile primare ale tabelelor tblComenzi, respectiv tblMateriale.

tblConţinutComanda(NrComanda, CodProdus, Cantitate)

 Materialele achiziţionate în magazine sunt desfăcute către clienţi pe baza unor
facturi. Evidenţa facturilor este ţinută într-un tabel tblFacturi cu următoarea structură:

tblFacturi(NrFactura, Datafactura, CodMagazin)

În tabelul Facturi câmpul Nrfactura identifică în mod unic fiecare înregistrare şi
deci poate constiuti cheie primară. Datafactură este de tip Date, pentru care s-a ales
formatul scurt. Codul magazinului unde s-a desfăcut produsul, alegându-se de tip Lookup
Wizard, a fost preluat din tabelul tblMagazine. Astfel în câmpul CodMagazin, sunt
preluate valorile câmpului cheie primară CodMagazin din tabelul tblMagazine, dar la
selectarea cîmpurilor
dorite s-a optat pentru denumirea magazinului. În proprietatea Caption a câmpului
CodMagazin s-a specificat valoarea Denumire magazin.

Fiecare factură conţine numărul facturii, produsul şi cantitatea facturată. Pentru

aceasta s-a creat tabelul tblContinutFactura, având câmpurile:
tblContinutFactura(Nrfactura, CodMaterial, CantitateIesita)

Între tabelul tblFacturi şi tabelul tblContinutFactura se stabileşte o relaţie 1-M, la o

factură corespunzându-i un anumit conţinut din tabelul tblContinutFactura.
Ca urmare pentru câmpul NrFactura valorile sunt preluate din câmpul NrFactura a
tabelei tblFacturi cu ajutorul tipului de date LookupWizard. Folosind vrăjitorul de căutare
s-au preluat şi valorile câmpului CodMaterial din câmpul CodMaterial al tabelei
tblMateriale.
 Având realizate tabele şi prin folosirea vrăjitorului Lookup wizard, între tabele s-
au creat legături ce pot fi vizualizate în fereastra Relationships.

De asemenea în fereastra de proprietăţi a

fiecărei legături s-au impus regulile de integritate
referenţială, astfel încât să se realizeze o
actualizare şi o ştergere în cascadă la modificarea
sau ştergerea înregistrărilor din tabelul părinte
spre înregistrările corespunzătoare din tabelul
copil.
Aceste reguli de integritate referenţială au fost impuse pentru toate relaţiile de tipul 1-M.
 3. Crearea interogărilor

Interogările sunt obiecte Access folosite pentru extragerea datelor din unul sau mai
multe tabele sau alte interogări, ordonarea, filtrarea şi totalizarea listelor, efectuarea de
calcule, actualizarea, adăugarea şi ştergerea articolelor din tabele, precum şi pentru crearea
unor tabele noi pe baza unui model.

Interogările, în mediul Access, se împart în două categorii mari:

 Interogări de selecţie:
o Simple, cu criterii de ordonare şi filtrare;
o Cu funcţii agregat sau totalizatoare;
o Cu câmp calculat, pentru realizarea diferitelor calcule;
o Încrucişate.
 Interogări de acţiune având rolul de :
o Creare tabel nou (Make-Table Query);
o Actualizare articole (Update Query);
o Adăugare articole (Append Query);
o Ştergere articole (Delete Query).

Rezultatul unei interogări este tot un tabel, dar spre deosebire de un tabel, unde
datele sunt memorate permanent şi au aceeaşi valoare până la modificarea lor, în cazul
interogărilor, acestea nu memorează date, ci doar structura acestora.
În cadrul aplicaţiei s-a urmărit, pe lângă partea practică a aplicaţiei şi realizarea
tuturor tipurilor de interogări.

a) Interogarea Comenzi/Perioade/Banca este o interogare simplă de selecţie, unde

s-a urmărit afişarea comenzilor, a furnizorilor către care s-au făcut aceste comenzi,
respectiv banca şi contul unde trebuie virată contravaloarea comenzilor făcute. Comenzile
au fost ordonate crescător după data calendaristică la care au fost făcute, câmpurile fiind
extrase din cele două tabele tblFurnizori şi tblComenzi aflate în relaţia 1-M.

S-au creat doi parametri pentru a lăsa libertate utilizatorului să introducă singur
perioada calendaristică care-l interesează şi numele băncii unde trebuie să vireze banii.
 Cei doi parametrii:
>[Data minima] And <[Data maxima]
[Introduceţi banca]
au fost specificaţi în paranteze pătrate pe rândul Criteria, în dreptul câmpului care s-a dorit
a fi parametrizat.

Ca urmare, la rularea interogării cu ajutorul butonului Run, prin casete de mesaj i se

va cere utilizatorului să introducă datele limită între care doreşte afişarea comenzilor şi
banca pentru care se doreşte efectuarea operaţiei de vizualizare.
 Pentru cazul exemplificat, s-a obţinut următorul rezultat:

b) Interogarea ComenziLimitaDeAchitat este o interogare cu câmp calculat, unde

pentru un termen specificat sunt afişate furnizorul căruia trebuie să i se achite factura,
comanda şi data în care s-a făcut comanda, precum şi data limită la care trebuie achitată
comanda respectivă.
Pentru data comenzii s-au considerat toate comenzile efectuate până în ziua
curentă. Termenul de plată va fi introdus de către utilizator datorită parametrului introdus
în câmpul Termen.
Pentru a calcula data limita de plată în cazul unui termen specificat, s-a introdus un
câmp calculat prin care la data comenzii se adună termenul specificat de utilizator.
 În urma rulării interogării se obţine următorul rezultat:

c) Interogarea IntMakeTable este o interogare de acţiune, prin care pornind de la o

interogare simplă de selecţie şi transformând-o în interogare MakeTable s-a obţinut tabelul
FurnizoriComenziProduseInitial. Astfel iniţial s-a obţinut o interogare de selecţie unde s-au
selectat câmpurile NrComanda, DataComanda, DenFurnizor, DenMaterial, Cantitate şi
Preţ.
Transformarea în interogare Make-Table s-a făcut cu ajutorul opţiunii Make-Table
Query din meniul principal Query. Prin rularea interogării, în fereastra rezultată s-a
introdus numele tabelului nou creat. Sunt ilustrate mai jos atât interogarea în modul
Design, cât şi rezultatul acestei interogări, adică tabelul FurnizoriComenziProduseInitial
 d) Pe baza tabelului FurnizoriComenziProduseInitial creat anterior, s-a creat o altă
interogare cu câmp calculat, interogarea intValoareProduse. Prin aceasta, cunoscând
preţul şi cantitatea achiziţionată pentru fiecare produs, s-a calculat valoarea totală a
fiecăruia din produsele comandate.

Se observă că expresia de calcul a câmpului calculat a fost specificată în prima

coloană liberă identificată prin numele Valoare.

e) În mod similar s-a creat interogarea Valoare/ProdusComandat, interogare care a

stat la baza interogării totalizatoare Valoare/Comanda. În această interogare s-a urmărit
afişarea pentru fiecare comanda, cunoscând numărul comenzii şi data comenzii, a comenzii
cu valoarea minimă, maximă, medie, numărul comenzilor şi valoarea totală a tuturor
comenzilor. Pentru aceasta s-a pornit de la o interogare simplă de selecţie, unde în grilă s-
au aruncat numărul comenzii, data comenzii şi câmpul Valoare. S-a transformat
interogarea de selecţie în interogare totalizatoare cu ajutorul butonului
Totals din bara de instrumente. Automat în grila de interogare a apărut un nou rând Total.
Din câmpul valorilor comenzilor, pe linia Total s-a ales prima funcţie agregat, funcţia Sum.
S-a repetat pasul şi pentru funcţiile Min, Max, Avg, Count.
Astfel s-a realizat gruparea înregistrărilor după numărul şi data comenzii, după care
s-au aplicat funcţiile dorite. Toate funcţiile au fost astfel aplicate într-o singură interogare.

f) Interogarea ComenziLunareIncrucisata are ca scop afişarea printr-o interogare

încrucişată a numărului de comenzi efectuate cu fiecare furnizor în lunile anterioare.
Pentru aceasta s-a creat în prealabil o interogare de selecţie, unde s-a afişat numele
furnizorului, prin funcţia Month([DataComanda]) s-a extras numărul lunii din data
comenzilor şi numărul de comenzi din luna respectivă. Interogarea s-a transformat într-o
interogare încrucişată cu ajutorul opţiunii Crosstab Query din meniul Query. Aceeaşi
operaţie putea fi făcută şi cu ajutorul butonului Query Type din bara de instrumente. Ca
urmare, automat în grila de interogare vor fi afişate încă două linii:linia Total şi linia
Crosstab. Pe linia Crosstab, pentru fiecare câmp i se stabileşte rolul de antet de rând, antet
de coloană sau valoare. Pe linia Total pentru Value s-a ales funcţia Count care să
contorizeze numărul de comenzi făcute în luna respectivă, prin numărarea datelor
comenzilor. Astfel numărul comenzilor din luna respectivă se obţine la intersecţia dintre
denumirea furnizorului (aflat la capăt de rând) şi numărul lunii (aflat la capăt de coloane).

g) O altă interogare încrucişată este interogarea MatFurnizDataIncrucisata prin

care s-a urmărit afişarea printr-o interogare încrucişată a materialelor comandate, furnizorii
la care s-a făcut comanda pentru produsele respective şi data la care s-a făcut comanda.
 Astfel ca antet de rând s-a ales denumirea materialului, ca antet de coloană
denumirea firmei furnizoare, iar la intersecţia acestora (Value) s-a afişat data comenzii.

h) Interogarea IntarzieriPlata este tot o interogare cu câmp calculat, care are ca

scop calcularea numărului de zile de întârziere faţă de termenul de plată acordat de fiecare
furnizor.

Iniţial interogarea a fost una de selecţie formată din câmpurile DenFurnizor,

NrComandă, DataComanda, Termen. La aceste câmpuri s-a adăugat un câmp calculat
numit Întârziere. Prin acest câmp s-a calculat numărul de zile de întârziere la plata
comenzii. Pentru aceasta s-a calculat diferenţa dintre data curentă şi data comenzii,
obţinându-se numărul de zile scurse de la data la care s-a făcut comanda. Apoi din acest
număr s-a scăzut numărul de zile stabilite ca termen de plată. Daca rezultatul obţinut este
pozitiv, numărul reprezintă întârzierea de plată, in caz contra rezultatul obţinut reprezintă
numărul de zile de care societatea mai dispune până la data limită de achitare a comenzii.
În interogare s-a introdus parametrul :
>[DataMinima] And <[DataMaxima]
prin care utilizatorul poate specifica intervalul de timp pentru care îl interesează întârzierile
respective de plată.

În urma rulării interogării, pentru intervalul de timp exemplificat s-a obţinut

următorul rezultat:

i) Interogarea FurnizoriTermene are ca scop crearea unui tabel prin care să se

vizualizeze pentru fiecare furnizor, data la care s-a făcut comanda, termenul de plată pe
care l-a acordat furnizorul şi banca prin care i se poate achita comanda.

În urma realizării acestei interogări s-a obţinut următorul tabel:

 j) Tabelul obţinut anterior a stat la baza interogării de acţiune ActualizTermene.
Prin această interogare de actualizare s-a urmărit recalcularea şi afişarea noului
termen de plată în cazul în care respectivul furnizor mai păsuieşte de la plată societatea
comercială cu un număr de zile specificat. Pentru aceasta s-au folosit doi parametri:
- unul pentru introducerea de către utilizator al numărului de zile specificat,
- unul pentru introducerea de către utilizator al numelui furnizorului care face
această păsuire.

În urma rulării interogării este afişat tabelul Furnizori si termene, dar cu noua
valoare actualizată.
Pentru comparaţie, este reprezentat tabelul iniţial unde termenul de plată pentru
firma Binalia este de 35 de zile şi tabelul actualizat, unde pentru aceeaşi firmă noul termen
este de 45 zile, prin suplimentarea cu 10 zile.
 Dacă iniţial, în primul tabel Furnizori şi termene, firma Binalia acorda un termen de
35 de zile, în al doilea tabel se poate observa actualizarea termenului la 45 de zile.

k) Pentru ilustrarea cazurilor de actualizare au mai fost create două interogări prin
care se presupune că un furnizor face reducere la un produs, respectiv creşte preţul la un
produs.
Pentru a nu aduce modificări bazei de date iniţiale, tabelului
FurnizoriComenziProduseInitial i s-a creat o copie, cu ajutorul comenzilor Copy-Paste. S-a
obţinut astfel tabelul FurnComProdCopie pe care s-a lucrat în continuare.
 Astfel în primul caz s-a creat o interogare prin care se urmăreşte actualizarea
preţurilor la produsele firmei furnizoare specificate de utilizator, considerându-se o creştere
de preţ cu un procent specificat de utilizator.

Pentru aceasta s-a creat o interogare de selecţie, unde din câmpurile tabelului
FurnComProdCopie s-au selectat numai câmpurile care vor intervin în modificarea de preţ,
adică Preţ şi DenFurnizor. S-a transformat interogarea simplă de selecţie în interogare de
tip Update cu ajutorul opţiunii Update Query din meniul Query sau din butonul Query
Type a barei de instrumente. În urma alegerii opţiunii în grila de interogare apare automat
un nou rând Update To, unde pentru câmpul care va fi modificat, în acest caz câmpul Preţ,
s-a impus expresia de calcul prin care se va actualiza preţul. Această expresie este
următoarea:
[Preţ]+[Preţ]*[Val procent]/100
unde câmpurile au fost scrise ca de obicei în paranteze pătrate, iar pentru valoarea
procentului s-a utilizat parametrul [Val procent] pentru ca utilizatorul să introducă
procentul dorit.
De asemenea i s-a lăsat libertate utilizatorului să introducă şi numele firmei
furnizoare care face creşterea de preţ, introducându-se în câmpul DenFurnizor parametrul
[Introduceţi furnizorul].
Prin rularea interogării, utilizatorului i se solicită introducerea procentului dorit şi a
firmei în cauză. In acest caz, pentru exemplificare am ales valoarea procentului de 10
pentru firma Binalia. Actualizările au efect numai după acţionarea butonului Run, acţiune
în urma căruia printr-un mesaj ni se specifică numărul de rânduri (articole) actualizate.
Verificarea actualizărilor făcut se realizează prin reafişarea tabelului
FurnComProdCopie asupra căruia s-a lucrat. În imaginile de mai jos este reprezentat
acelaşi tabel înainte şi după actualizare.
 În mod similar s-a procedat şi pentru reducerile de preţ. De data aceasta însă
expresia de recalculare a preţului este următoarea:
[Preţ]-[Preţ]*[Val procent]/100
De asemenea pentru procent, respectiv pentru furnizor s-a folosit câte un parametru.
S-a luat acelaşi exemplu pentru a avea acelaşi termen de comparaţie. În exemplul
dat s-a considerat reducerea de preţ cu 20%, la aceeaşi firmă Binalia. Deci în final preţul
produselor a fost cu 10% mai mic decât cel iniţial.

De asemenea pentru comparaţie, au fost reprezentate din nou toate cele trei tabele:
tabelul iniţial, cel obţinut după creşterea de preţ cu 10% şi cel obţinut după scăderea de preţ
cu 20%.
 l) Un alt tip de interogare realizat este cea de acţiune de tip Delete, prin care dintr-
un tabel pot fi şterse toate înregistrările care satisfac un anumit criteriu de filtrare.
Astfel am considerat cazul în care din baza de date se doreşte ştergerea unui
furnizor cu care societatea nu mai are relaţii de colaborare. Pentru aceasta s-a creat o
interogare de selecţie în care din tabelul FurnComProdCopie pe care s-a lucrat, s-a selectat
doar câmpul DenFurnizor. S-a transformat interogarea de selecţie în interogare de tip
Delete cu ajutorul opţiunii Delete Query a butonului Query Type, acţiune în urma căreia
automat în grila de interogare a apărut un nou rând, rândul Delete cu clauza Where. Clauza
Where solicită impunerea în rândul Criteria a înregistrărilor care se doreşte a fi şterse.
Şi în acest caz pentru identificarea furnizorului s-a folosit un parametru,
[Introduceţi furnizorul], prin care utilizatorul poate specifica singur numele furnizorului pe
care doreşte să-l scoată din baza de date.
 Pentru exemplificare am ales acelaşi furnizor Binalia şi am reprezentat acelaşi
tabel înainte de ştergere şi după operaţia de ştergere.

Se observă că în al doilea tabel firma furnizoare BINALIA nu mai figurează.

m) Tot printr-o interogare de tip Delete am considerat cazul în care societatea

numai doreşte achiziţionarea un unui produs de la o firmă furnizoare şi ca urmare doreşte
să şteargă respectivul produs din baza de date. Pentru exemplificare, ca tabel de lucru am
ales acelaşi tabel FurnComProdCopie şi unde în mod similar am folosit doi parametri
pentru introducerea materialului ce se doreşte a fi şters, respectiv specificarea firmei care
furnizează respectivul material.

Am propus ştergerea materialului numit SOLUŢIE CURĂŢIRE PROFIL furnizat

de firma ELCOSIM. Am reprezentat tabelul înainte de ştergere şi după ştergerea
produsului din baza de date.

n) Interogarea Adăugare furnizor este o interogare de tip Append, prin care se

doreşte adăugarea într-un tabel al bazei de date a unor înregistrări dintr-un alt tabel al bazei
de date sau dintr-o altă bază de date.
 Pentru exemplificare am ales cazul în care se doreşte adăugarea în tabelul
FurnComProdCopie a furnizorului şters anterior. Adăugarea se face din tabelul iniţial,
adică din tabelul FurnizorComenziProduseInitial
Pentru aceasta am creat o interogare simplă de selecţie din care s-au selectat toate
câmpurile. Am transformat interogarea de selecţie într-o interogare de tip Append, alegând
opţiunea Append Query din meniul Query sau din butonul Query Type aflat în bara de
instrumente standard. Printr-o casetă de dialog este solicitat numele tabelului în care se
doreşte adăugarea, în cazul exemplificat tabelul FurnComProdCopie.
Automat în fereastra de interogare apare un rând nou, rândul Append To prin care
se specifică numele câmpurilor în care se va face adăugarea înregistrărilor.
Pentru a permite utilizatorului să introducă singur numele firmei pentru care se
doreşte adăugarea, am folosit parametrul [Introduceţi furnizorul] aflat în rândul Criteria a
câmpului DenFurnizor.
După introducerea furnizorului în tabelul FurnComProdCopie a fost adăugat noul
furnizor.
 o) O alta interogare de tip Append este interogarea Adăugare materiale la tabel,
unde similar cazului anterior am creat o interogare de selecţie pe care ulterior am
transformat-o în interogare de tip Append.
Astfel am presupus cazul în care se doreşte adăugarea unui material dintr-un tabel
la un alt tabel.
Pentru exemplificare din tabelul FurnizorComenziProduseInitial am adăugat în
tabelul FurnComProdCopie materialul „Soluţie curăţire profil” de la firma Elcosim, şters
anterior.
Am folosit de asemenea doi parametri, unul pentru introducerea numelui
furnizorului şi unul pentru introducerea denumirii
produsului. În urma rulării interogării, în tabelul
FurnComProdCopie a fost adăugat materialul specificat.
 p) Interogarea reduceri/comanda este o interogare cu câmp calculat, dar care
foloseşte funcţia IIF.
Astfel am presupus cazul în care dacă valoarea /comandă este mai mare de 3000 lei,
furnizorul face o reducere de 25%, în caz contrar reducerea este zero.
Astfel pe baza interogării valoare/comanda, am creat interogarea simplă în care au
fost selectate câmpurile NrComanda şi suma valorii/comandă. Iniţial a fost creat câmpul
calculat Reduceri/comanda, având expresia:
IIF([SumaalValoare]>=3000;25/100*[SumaalValoare];0)
Restul de plată în cazul în care este îndeplinită condiţia anterioară, constituie un alt
câmp calculat numit RestPlata şi care este exprimat prin diferenţa dintre valoarea iniţială a
comenzii şi reducerea acordată:
[SumaalValoare]-[Reduceri/comanda]
În urma rulării interogării este afişat tabelul reduceri/comandă în care pentru fiecare
comandă identificată prin numărul său, este afişată valoarea totală a comenzii, reducerea
acordată şi restul de plată.
 4. Crearea rapoartelor

Rapoartele sunt obiecte Access folosite pentru prezentarea sintetică a informaţiei,

având drept principal scop tipărirea la imprimantă.
Specific rapoartelor este faptul că prin opţiunea Sorting and Grouping, înregistrările
pot fi sortate şi grupate după un anumit câmp. În cazul acestei aplicaţii s-au creat
următoarele rapoarte:

a) Raportul rptValoareproduse este creat pe baza interogării intValoareProduse.

Astfel pentru fiecare comandă, corespunzător furnizorului, au fost grupate
înregistrările şi pentru fiecare grup, în zona de subsol a grupului, s-au afişat cantitatea
minimă/comandă, respectiv cantitatea maximă/comandă. De asemenea, în zona de subsol a
raportului s-a afişat preţul mediu/produs raportat la întregul raport.

Pentru aplicarea unei funcţii agregat asupra câmpurilor, s-au folosit casete de text,
unde s-a introdus expresia de calcul.
Cantitatea minimă sau maximă/comandă a fost calculată prin inserarea expresiei de
calcul în zona de subsol a câmpului NrComandă.
Cantitate minimă/comandă: =min([Cantitate])
Cantitate maximă/comandă: =max([Cantitate])
 Preţul mediu/produs s-a calculat prin inserarea expresiei de calcul în zona de subsol
a raportului.
Preţ mediu: =avg([Preţ])

b) Raportul rptComenzi afişează pentru fiecare comandă, produsele pe care aceasta

le conţine. Raportul se bazează pe cele două tabele aflate în relaţia 1-M, tabelul
tblComenzi, respectiv tabelul tblContinutComenzi.
 Ca şi în cazul anterior, prin casete de text s-au aplicat funcţii totalizatoare
asupra înregistrărilor din fiecare grup, respectiv asupra tuturor înregistrărilor raportului.

c) Raportul rptFacturi s-a creat similar raportului rptComenzi, afişând pentru

fiecare factură, materialele conţinute.
 d) Raportul GRAFICE a fost realizat ca şi raport de tip Chart Wizard. Pentru
exemplificare s-a reprezentat pentru fiecare furnizor, termenele de plată şi banca prin care
se pot achita comenzile.
 S-au ales ca variabile denumirea furnizorului, termenele de plată şi banca.
Graficul a fost formatat în mod obişnuit, după activarea graficului
 5. Crearea formularelor

Formularele constituie obiecte ale mediului Access utilizate pentru introducerea şi

vizualizarea datelor din tabele şi/sau interogări.

Prin plasarea butoanelor de comandă pe formulare se pot crea meniuri simple sau
înlănţuite.
Pentru funcţionarea aplicaţiei au fost create formulare atât simple, cât şi înlănţuite
care să ducă la formularele fii.
Trecerea de la un formular la altul se face cu ajutorul butoanelor de comandă.
Fiecărui buton de comandă îi este ataşat evenimentul On clic a cărui acţiune pe care o
declanşează este specificată prin câte un macro.
Formularele pot fi create atât în mod asistat, folosind facilităţile oferite de Wizard,
cât şi în mod personalizat (design). Pentru formularele create s-au folosit ambele metode.
În general s-a folosit modul asistat, pentru ca ulterior formularele să fie
personalizate.
 6. Crearea macrourilor
Macro-urile sunt obiecte Access care asigură legarea într-un flux continuu a
execuţiei operaţiilor referitoare la anumite obiecte.
Comenzile macro permit automatizarea lansării acţiunilor prin asocierea la un
singur eveniment utilizator a întregii succesiuni de operaţii.
Macro-urile pot fi create din fereastra bazei de date, obiectul Macro, sau din
fereastra de proprietăţi a obiectului căruia i se ataşează, tab-ul Event.
Indiferent de modul de creare, pentru fiecare macro trebuie să i se specifice
acţiunea sau grupul de acţiuni şi argumentele acestor acţiuni.
În cazul macro-urilor cu caracter general, care pot fi ataşate oricărui obiect, acestea
nu au argumente. Este cazul macro-ului mcrMaximizare care determină maximizarea
oricărui obiect căruia i se ataşează.

O altă categorie de macro-uri folosite în aplicaţie sunt cele care deschid un

formular, interogare sau raport, aşa cum este cazul macro-urilor folosite în aplicaţie..
 Pentru exemplificare sunt ilustrate trei dintre macro-urile create.

Cele două macrocomenzi conţin fiecare câte o singură instrucţiune, prin care este
deschis obiectul specificat în zona de argumente.

Macrocomanda de mai sus conţine trei instrucţiuni, care în ordine determină:

- deschiderea raportului rptFacturi în modul de previzualizare;
- tipărirea la imprimantă a raportului rptFacturi;
- închiderea raportului rptFacturi.
 7. Realizarea meniurilor aplicaţiei

Meniurile aplicaţiei sunt realizate cu ajutorul formularelor înlănţuite,

trecerea de la un formular la altul (de la un meniu la altul) făcându-se cu ajutorul
butoanelor de comandă. Deschiderea formularelor sau interogărilor ce stau la baza
meniurilor, se realizează prin ataşarea unui macro evenimentului clic al fiecărui buton.
a) Aplicaţia porneşte cu un panou de intrare care constituie formularul
frmIntrareAplicatie.
Formularul a fost creat în modul Design, pe formular plasându-se etichete, o
imagine nelegată şi două butoane de comandă: unul pentru ieşirea din aplicaţie şi unul
pentru trecerea la meniul principal al aplicaţiei.
 Meniul principal grupează logic facilităţile oferite de aplicaţie în patru categorii:
- preluări de date;
- vizualizări de date;
- actualizări de date;
- listarea datelor sintetizate în rapoarte;
- ieşirea din aplicaţie.
Pentru fiecare dintre aceste meniuri s-a creat câte un formular, trecerea de la meniul
principal la celelalte meniuri făcându-se prin intermediul butoanelor de comandă.
Fiecare buton de comandă are ataşat câte un macro, prin care se specifică
formularul pe care-l va deschide evenimentul respectiv (On clic) şi modul de deschidere al
formularului.
 b) Meniul Preluare date se constituie într-un formular frmPreluareDate
realizat în modul design. Pe acest formular s-au plasat patru butaone de comandă, dintre
care trei duc la alte formulare, iar al patrulea permite revenirea la formularul anterior,
frmMeniuPrincipal.
 Cele trei butoane la evenimentul On-Clic duc fiecare la formularulcorespunzător
astfel:
 Formularul frmIntroducereFurnizori este un formular de tip columnar (o
singură înregistrare la un moment dat) creat pe baza tabelului tblFurnizori.
Pe formular, în modul design s-au adăugat butoane de comandă care duc
fiecare dintre ele la prima înregistrare, ultima înregistrare, înregistrarea
anterioară şi cea următaore. De asemenea au fost plasate butoane de
comandă pentru adăugarea unei înregistrări, ştergerea unei înregistrări,
respectiv buton pentru întoarcerea la formularul părinte frmPreluareDate.
Pentru varietate, etichetele butoanelor au fost alese fie ca imagini, fie ca şi
text.

 Formularul frmIntroducereMateriale este de tip tabular, având câmpurile

afişate pe orizontală şi creat pe baza tabelului tblMateriale.
De asemenea pe formular au fost plasate butoane de adăugare, de ştergere,
respectiv de ieşire din formular, pentru care ca şi etichete au fost alese imagini.

 Magazinele firmei şi gestionarii acestora sunt introduse prin formularul

frmMagazine. Acest este tot de tip columnar, dar formă continuă, adică la
un moment dat sunt afişate mai multe înregistrări, câmpurile fiind afişate pe
verticală. În plus, pe formular a fost plasat butonul de ieşire din aplicaţie.
 c) Meniul Vizualizare date constituie un formular frmVizualizare date, realizat în
modul design. Pe formular au fost plasate nouă butoane de comandă, fiecare
dintre ele ducând la câte un formular bazat pe interogări, deci formulare care
permit numai vizualizarea datelor.

Formularul are o secţiune de antet unde este plasată o imagine nelegată şi o etichetă
sugestivă pentru conţinutul formularului
Fiecăruia dintre butoane i s-a ataşat un macro prin care se specifică formularul sau
interogarea pe care o deschide şi modul în care se face acest lucru.
Butoanele de comandă conduc la următoarele formulare fii:
 Butonul Comenzi şi produse duce la formularul frmComenziProduse.
Acesta este realizat ca un formular cu subformular, la o comandă
corespunzând mai multe produse. Astfel câmpurile formularului părinte au
fost luate din tabelul tblComenzi, iar câmpurile subformularului au fost
luate din tabelul asociat corespunzător, adică tabelul tblContinutComanda.
În plus în fereastra de proprietăţi a formularului pentru proprietatea Navigation
Buttons s-a ales valoarea No, considerându-se că butoanele de comandă plasate pe
formular pot suplini lipsa butoanelor de navigare specifice mediului Access.

 Butonul Termene de plată duce la formularul frmFurnizoriTermene,

realizat pe baza relaţiei 1-M dintre tabelul tblFurnizori şi tabelul
tblComenzi.
 Formularul are ca scop vizualizarea termenelor de plată admise de fiecare furnizor
pentru achitarea comenzilor. Ca urmare formularul are un caracter read-only, caracter
impus prin macro-ul ataşat butonului de comandă care deschide acest formular.
Formularul mai conţine butonul de revenire la meniul părinte Vizualizare date.

 Butonul Valoare produse deschide formularul frmValoareProdus. Acesta

este realizat pe baza interogării iniValoareProdus, ceea ce este specificat şi
în proprietatea Record Source a ferestrei de proprietăţi a formularului.
 Formularul are ca scop vizualizarea valorii fiecărui produs achiziţionat, dacă se
cunoaşte preţul fiecărui produs şi cantitatea în care a fost achiziţionat. Valoarea a rezultat
prin interogarea cu câmp calculat intValoareProdus, formularul rezultat fiind de tip
columnar, single form.
 Butonul Comenzi lunare/Furnizor deschide formularul
frmComenziLunareIncrucisata, prin care pentru fiecare furnizor sunt afişate
numărul comenzilor efectuate în luna respectivă. Pentru aceasta s-a realizat
un formular bazat pe interogarea încrucişată ComenziLunareIncrucisata.

 Butonul Întârzieri de plată deschide interogarea IntarzieriPlata prin

intermediul unor ferestre de dialog prin care utilizatorul trebuie să introducă
perioada care-l interesează pentru plata comenzilor. Astfel utilizatorul poate
vizualiza numărul de zile de întârziere sau graţie până la data limită de
achitare a comenzilor.

 Butonul Comenzi-perioade-bancă deschide interogarea

ComenziPerioadeBanca prin care utilizatorul, specificând prin casete de
dialog perioada care-l interesează, va putea vizualiza comenzile făcute în
perioada respectivă de timp, denumirea furnizorului cu care s-a făcut
 comanda, banca şi contul unde trebuie livraţi banii pentru comenzile
respective. Am luat ca exemplu perioada 1-31.05.2004.

 Butonul Materiale achiziţionate deschide interogarea încrucişată

MatFurnizDataIncrucisata, prin care, printr-o interogare încrucişată, se
poate vizualiza pentru fiecare material comandat, firma furnizoare şi data la
care a fost comandat materialul respectiv.

d) Meniul Actualizări de date este deschis de butonul Actualizări date a

formularului Meniu principal.
Meniul are ca scop actualizarea datelor în cazul în care se fac modificări de preţuri,
actualizări de termene, ştergerea unui material sau furnizor din baza de date.
În acest sens, formularul frmInterogariDeActiune conţine butoane de comandă care
deschid formulare bazate pe interogări de acţiune.
 Aşa cum se poate observa, formularul conţine următoarele butoane:
 Butonul Actualizare preţ/produs (creştere de preţ) deschide interogarea de
tip Update actualizFurnComCrodCopie .
 Butonul Actualizare termene deschide interogarea de tip Update
ActualizTermene.
 Butonul Actualizare preţ/produs (scădere de preţ) deschide interogarea de
tip Update ActualizScaderePret/prod.
 Butonul Ştergere material deschide interogarea de tip Delete Ştergere
material.
 Butonul Ştergere furnizor deschide interogarea de tip Delete
ŞtergereFurnizor.
 Butonul Înapoi determină revenirea în meniul principal.

e) Meniul Rapoarte este deschis prin butonul Listare şi permite vizualizarea

diferitelor date statistice cu ajutorul rapoartelor. Astfel este deschis formularul frmListare,
formular creat în modul design şi pe care au fost plasate şase butoane de comandă.
Butoanele de comandă deschid următoarele rapoarte:
 Butonul Examinare raport Valoare/produs deschide raportul
rptValoareProduse creat pe baza interogării intValoareProduse.
 Butonul Examinare grafic termene de plata deschide raportul GRAFIC
prin care se reprezintă grafic termenele de plată ale diferiţilor furnizori.
 Examinare raport comenzi deschide raportul rptComenzi, prin care sunt
vizualizate pentru fiecare comandă, produsele conţinute.
 Examinare raport facturi deschide raportul rptFacturi, prin care sunt
vizualizate pentru fiecare factură, produsele conţinute.
 Comenzi prin care este listat raportul rptComenzi.
 Facturi prin care este listat raportul rptFacturi.
 Buton de ieşire din formular.
 CONCLUZII

Aplicaţia prezentată poate constitui un exemplu de gestiune a stocurilor pentru orice

societate comercială.
Practic, aplicaţia se adresează utilizatorilor cu cunoştinţe minime de utilizare a
calculatorului, sistemul de panouri cu butoane permiţând accesul facil la meniurile
programului.
Astfel, studiul de caz prezentat se constituie într-un exemplu al proiectării şi întreţinerii
bazelor de date, prin programul Microsoft Access. Prin exemple însoţite de imagini, sunt
prezentate modalităţile de realizare a unei baze de date şi a obiectelor pe care acestea o
compun.
Astfel, prima parte face referire la crearea şi manipularea unei baze de date. Datele sunt
stocate în tabele, pentru fiecare tabel specificându-se proprietăţile, fiecare tabel fiind
prezentat atât în modul Design, cât şi în modul datasheet. Au fost prezentate legăturile care
se pot stabili între datele stocate în baza de date în diferite tabele prin intermediul
câmpurilor chei primare.
Pe baza datelor stocate în tabele au fost realizate interogări ale bazei de date. Au fost
impuse diferite criterii de filtrare, obţinându-se interogări atât de selecţie, cât şi interogări
de acţiune. Astfel, prin exemple concrete, au fost realizate şi prezentate interogări din toate
tipurile: interogări simple de selecţie, interogări cu funcţii totalizatoare, interogări cu câmp
calculat, interogări încrucişate. Interogările de acţiune, de tip Make Table, Delete, Update
şi Append au permis operaţii de actualizare ale bazei de date.
La dispoziţia utilizatorilor au fost puse formulare, care să uşureze munca de introducere
şi actualizare a datelor, chiar şi pentru cei cu cunoştinţe minime de operare pe calculator.
Rezultatele obţinute în urma prelucrării şi sintetizării lor, au putut fi vizualizate prin
intermediul rapoartelor. Au fost realizate rapoarte simple, bazate pe tabelele relaţionate,
dar şi rapoarte sintetizatoare în care s-a realizat gruparea şi ordonarea înregistrărilor. Atât
la nivel de grup, cât şi la nivel de raport, au fost aplicate funcţii agregat (totalizatoare).
Ultima parte a prezentat mijlocul pus la dispoziţie de Access pentru a realiza interfaţa
aplicaţiei într-un aspect cât mai prietenos pentru utilizator.
Un avantaj al aplicaţiei realizate este acela că aplicaţia poate fi rulată sub orice sistem
de operare, sistemul de gestiune Access făcând parte din pachetul Microsoft Office şi
permiţând transferul datelor între SGBD Access şi alte SGBD-uri, respectiv programe ale
pachetului Microsoft Office .
 BIBLIOGRAFIE
1) Băla C. – Baze de date. Microsoft Access, Editura Mirton, Timişoara, 2003
2) Cameniţă D., Belean P., Nicolaescu C., Bazele contabilităţii, Editia a Il-a revizuită
şi adaugită, Editura Multimedia, Arad, 2000
3) Cernuşca L., Farca F. - Contabilitate de gestiune şi calculaţia costurilor, Aplicaţii
practice, Ediţia a Il-a adăugită şi revizuită, Editura Gutenberg, Arad, 2001
4) Cernuşca L., lavorschi N. - Contabilitate de gestiune, sinteze şi aplicaţii practice,
Editura Universitaţii "Aurel Vlaicu", Arad, 1999
5) Connoly T., Begg C.– Baze de date. Proiectare. Implementare. Gestiune, Editura
Teora 2001
6) Cristea H. - Contabilitatea şi calculaţiile în conducerea întreprinderii, Editura
Mirton Timişoara, 1997.
7) Cristea H., Costuri şi preţuri, Editura Mirton, Timişoara, 1991
8) Dollinger R.– Baze de date şi gestiunea tranzacţiilor, Editura Microinformatica,
Cluj, 2001
9) Donoaica S - Calculaţia costurilor, Contabilitate analitică, Editura Eficient,
Bucureşti, 1998
10) Epuran M., şi colaboratorii - Contabilitatea financiară în noul sistem contabil,
Editura de Vest, Timişoara, 1995,
11) Feleaga N., lonaşcu I.. - Tratat de contabilitate financiara, vol. 1 şi Il, Editura
Economica, Bucureşti, 1998
12) Fotache M.– SQL, Dialecte DB2, Oracle, Visual FoxPro, Editura Polirom, 2001
13) lacob C., lonescu S., Contabilitate de ges!iune, Editura Aius, Craiova, 1996 .
14) Koller E., Roşculeţ M. – Programare în Access, Editura Teora 2002
15) Kovacs S.– Microsoft Access 97, Editura Albastră, Cluj, 2001
16) lacob C. - Contabilitatea gestiunii interne a unitaţilor economice, Editura CERTI,
Craiova, 1994
17) Marquis A., Courter G. – Ghidul dumneavoastră pentru Access, Editura All, 1998
18) Nagy M.– Baze de date, Editura Mirton, Timişoara, 2002
19) Năstase P , Mihai F., Cosăcescu L.– Baze de date. Microsoft Access 2000, Editura
Teora, 2002
20) Ristea M. - Contabilitatea societăţilor comerciale, vol. Il, Editura Economică,
Bucureşti, 1996