I. Noțiuni introductive … … … … 3 [604743]

1 Cuprins

Introducere ………………………….. ………………………….. ………………………….. ………………………….. ……… 2
I. Noțiuni introductive ………………………….. ………………………….. ………………………….. ………………. 3
I.1. Organizarea dat elor………………………….. ………………………….. ………………………….. ……………… 3
I.2. Baze de date ………………………….. ………………………….. ………………………….. ……………………….. 5
I.3. Baze de date relaționale ………………………….. ………………………….. ………………………….. ……….. 7
II. Sistemul de gestiune a bazelor de date Microsoft Access ………………………….. ………………….. 11
II.1. Microsoft Access. Prezentare general ………………………….. ………………………….. ………………. 11
II.2. Arhitectura Micros oft Access ………………………….. ………………………….. ………………………….. 13
II.2.1. Tabele ………………………….. ………………………….. ………………………….. ……………………….. 13
II.2.2. Interogări ………………………….. ………………………….. ………………………….. …………………… 15
II.2.3. Formulare ………………………….. ………………………….. ………………………….. ………………….. 17
II.2.4. Rapoarte ………………………….. ………………………….. ………………………….. ……………………. 18
II.3. Macrocomenzi și module ………………………….. ………………………….. ………………………….. …… 19
III. Prezentarea aplicației ”Bază de date pentru evidența operațiunilor prin casierie” ………… 24
I.1. Op erațiuni efectuate prin casierie ………………………….. ………………………….. ……………………. 24
III.2. Prezentarea generală a aplicației ………………………….. ………………………….. ……………………. 27
III.3. Prezentare interfață ………………………….. ………………………….. ………………………….. …………. 37
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ……….. 46
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ……. 48
Anexa 1 ………………………….. ………………………….. ………………………….. ………………………….. …………. 49
Anexa 2 ………………………….. ………………………….. ………………………….. ………………………….. …………. 50
Anexa 3 ………………………….. ………………………….. ………………………….. ………………………….. …………. 51
Anexa 4 ………………………….. ………………………….. ………………………….. ………………………….. …………. 52
Anexa 5 ………………………….. ………………………….. ………………………….. ………………………….. …………. 52
Anexa 6 ………………………….. ………………………….. ………………………….. ………………………….. …………. 53

2 Introducere

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
depre baze de date .
Procesul de i nstruire î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. Putem spune că
disciplina "Baze de Date" se ocupă cu câteva din mecanismele de gestiune a informațiilor
și a cunoștințelor.
Construirea unei aplicații care să manipuleze informații dintr -o bază de date
presupune atât înțelegerea principiilor de organizare a bazelor de date, a limbajului S QL,
dar și observarea atentă a structurii de date în discuție, a cerințelor și a tipului clienților, a
specificului informațiilor (frecvența de modificare, complexitatea, tipul frecvent de căutări
– selecții, dimen siunea estimată a bazei de date . Căutând m odalitatea de a grupa datele
pentru o cât mai eficientă manevrare, dar și pentru a le as igura o cât mai bună protecție. La
nivel mondial, cei mai importanți furnizori de sisteme de gestiune a bazelor de date sunt
Oracle, IBM, Microsoft, Sybase.
Integrarea operațiuilor ecomice într -o bază de date informatizată permite
managerilor și, cu oarecare extensii, părților externe să obțină informațiile necesare pentru
planificare, luarea deciziilor și control, fie că informațiile sunt pentru marketing,
contabilitate , sau alte arii financiare ale entității economice. Producătorii de produse
software au dezvoltat programe care leagă toate subsistemele informatice într -o singură
aplicație.
În general, sistemele informatice de contabilitate sunt organizate astfel încât s ă
corespundă arhitecturii contabilității din România în care se remarc ă trei mari componente
[15]:
1. contabilitatea generală (aprovizionare și furnizori; vânzări și clienți; cheltuieli;
venituri; datoriilor; creanțelor; stocuri și obiecte de inventar; mijlo ace fixe; capital;
salarii; operații diverse, de închidere);
2. contabilitatea financiară /de gestiune financiară : trezoreria, investițiile financiare,
finanțările – încasări de la clienți, plăți către 16 furnizori, evidențierea plasamentelor,
plata impozitel or și taxelor etc.;
3. controlul prin bugete – elaborarea de bugete și urmărirea acestora prin intermediul
contabilității generale. Din aspectele descrise până acum putem trage concluzia că
majoritatea acțiunilor desfășurate în cadrul unei entități economice necesită utilizarea
sistemului informatic de contabilitate.
Rolul sistemului informatic de contabilitate este de a furniza informații importante
referitoare la: venituri, urmărirea clienților (facturi emise neîncasate), dinamica încasărilor
și plăților, c ontabilitatea costului, (calculația costului), cheltuieli, etc. Informațiile furnizate
pot îmbrăca forme diverse atât electronic (documente electronice, foi de prezentare
electronice, notificări electronice (e -mail), imagini, imagini video, secvențe audio, etc.), fie
sub formă „tradițională” (pe suport de hârtie sau folii pentru proiectoare, etc.). Furnizarea
informațiilor trebuie să se facă în timp util, cât mai exact, pentru toți destinatarii
informației contabile (manageri, personal aparținător altor sub sisteme). Un sistem
informatic de contabilitate modern este capabil să preia automat datele furnizate de către
alte subsisteme.

3 I. Noțiuni introductive

Evoluția metodelor și tehnicilor de organizare a datelor a fost determinată de
necesitatea de a avea un acces cât mai rapid și mai ușor la un volum din ce în ce mai mare
de informații precum și de perfecționarea echipamentelor de culegere, memorare,
transmitere și prelucrare a datelor.

I.1. Organizarea datelor

Datele sunt reprezentări simbolice ale unor fe nomene, procese, obiecte etc.
susceptibile a fi stocate pe un suport de memorie externă, și care pot fi manevrate folosind
diverse mijloace tehnice (exemple de date: cifre, șiruri de caractere, imagini, culori etc.).
Informația reprezintă sensul pe care oa menii îl acordă datelor (astfel că aceeași
dată poate reprezenta diverse informații, funcție de cei care o folosesc). [15]
Organizarea datelor presupune efectuarea următoarele activități:
– definirea, structurarea, ordonarea și gruparea datelor;
– stabilirea le găturilor ( relațiilor ) între date, între elementele unei colecții de date și
între colecții de date;
– stocarea datelor pe un suport informațional, prelucrabil într -un sistem de calcul.
Organizarea datelor se realizează pentru a permite regăsirea lor autom ată după
anumite criterii și forme.
Obiectivele urmărite la organizarea datelor sunt:
– realizarea unui acces rapid la date stocate pe diferite suporturi de memorie;
– spațiul de memorie internă și externă ocupat să fie cât mai mic (economie de
memorie);
– datel e să apară o singură dată în sistem (unicitatea datelor);
– modul de organizare a datelor să reflecte, pe cât posibil, toate legăturile dintre
obiectele, fenomenele, procesele pe care acestea le reprezintă;
– schimbarea structurii datelor și a relațiilor dintr e ele să se facă fără a modifica
programele ce le gestionează (flexibilitatea datelor).
Colecția de date reprezinta o mulțime relativ omogenă de date care privește un
anumit domeniu, proces, activitate sau obiect.
Definirea în plan informațional a colecții lor de date presupune înțelegerea
conceptelor de entitate, membru, atribut, valoare. [5]
– Entitatea reprezintă o componentă unitară care poate fi individualizată
informațional într -un domeniu, o activitate sau într -un mediu economic. Entitatea
este conceptu l corespondent, în plan informatic, al unei colecții de date.
– Atributele reprezintă caracteristicile care descriu informațion al proprietățile unei
entități.
– Membrii unei entități reprezintă elementele colecției de date. Ei moștenesc
individual atributele care descriu entitatea, de aceea se consideră că o entitate este o
colecție omogenă de date.

4 Organizarea datelor în cadrul unui sistem informațional, în general sau în
activitatea de elaborare a unui program reprezintă procesul de identificare, definire,
evaluare, structurare și memorare a informațiilor. 2

Organizarea datelor presupune:
– definirea, structurarea, ordonarea și gruparea datelor în colecții de date omogene;
– stabilirea relațiilor dintre date, dintre elementele colecțiilor și dintre colecții;
– stocarea datelor pe suport informațional, prelucrabil prin intermediul unui sistem de
calcul.
Obiectivele urmărite în organizarea datelor:
 minimizarea timpului de acces la date;
 minimizarea spațiului de memorie (internă și externă) ocupat de date;
 minimiza rea redundanței datelor;
 reflectarea tuturor legăturilor dintre obiectele, fenomenele și procesele economice
pe care aceste date le reprezintă;
Criterii de clasificare a datelor:
Datele din sistemul informațional, generate în timpul și datorită proceselor
economice, se împart în funcție de nivelul de detaliere în două categorii : date elementare și
date compuse.
Datele elementare, numite și scalari, sunt indivizibile, atât la nivel informațional
cât și la nivel de prelucrare. Acestea sunt identificate prin nume și au o anumită valoare.
Identificatorul datei, numele, este un simbol asociat datei pentru a o distinge de alte
date si pentru a o refe ri în procesele de prelucrare. Atributele precizează proprietățile datei
si determina modul în care va fi tratată în procesul de prelucrare:
– tip întreg, real, logic, sir de caractere etc.
– precizia reprezentării interne : virgula mobila precizie simpla, virgula mobila
precizie dubla etc.
– modul de adresare a memoriei
– valoarea inițială etc.
Valorile datei se pot prec iza prin enumerare și sunt str âns legate de tipul datei . Dacă
pe parcursul proceselor de prelucrare data păstrea ză aceeași valoare este denumită
constantă. Pentru constante se utilizează ca identificator valoarea acestora. Dacă valorile
datei sunt diferite în timpul procesului de prelucrare discut ăm despre variabile
Din punct de vedere fizic unei date îi c orespunde o zonă de memorie de o anumită
mărime identificată printr -un nume, situată la o anumită adresă.
Cele mai des întâlnite tipuri de date elementar e sunt:
1. numerice – sunt incluse numerele întregi, reale si complexe (virgulă fixă, virgulă
mobilă, precizie simpla, precizie dublă etc.). Asupra lor se pot realiza operații de
adunare, scădere, înmulțire, împărțire etc.;
2. logice (boolean) – utilizate pent ru precizarea stărilor de adevăr (adevărat, fals). Asupra
acestora se pot efectua operații logice precum ȘI, SAU, NU;
3. caracter (text, string) – conțin o mulțime de simboluri alfanumerice utilizând codul
ASCII. Asupra acestora se pot defini operații de cău tare, concatenare, ordonare.
Datele compuse sunt mulțimi de date elementare, omogene din punct de vedere al
descrierii și al prelucrării. Datele compuse au apărut din nevoia de a descrie din punct de
vedere informațional un anumit obiect sau proces din rea litatea înconjurătoare ale cărui
caracteristici nu puteau fi sintetizate de un singur scalar.
Datele pot fi clasificate în funcție de modul de alocare a memoriei , astfel existând
date de tip static și date de tip dinamic.

5 Structurile de date interne se referă la modul de amplasare în memoria internă a
datelor elementare aparținând unei colecții. În această categorie sunt incluse structurile de
tip masiv, înregi strare (articol), mulțime, listă și arbore.
Structurile externe se referă la modul de memorare a datelor pe suporți de memorie
magnetică. Din această categorie fac parte fișierele și bazele de date.

I.2. Baze de date

Baza de date este o colecție de date legate logic, proiectată pentru a satisface
necesitățile unui sistem informatic. Datele sunt st rânse într -o colecție unică și sunt folosite
simultan de către mai mulți utilizatori.
Baza de date poate fi organizată ca un singur tabel de mari dimensiuni, sau tabele
mici, care sunt legate după o schemă pe care proiectantul trebuie să o impună.
Conceptu l de bază de date s -a definit în 1969 cu ocazia prezentării primului proiect
de raport CODASYL (Raportul final s -a prezentat în 1971). Ideea principală în organizarea
datelor se baza pe existența a trei componente de bază:
 schema de rețea – care reprezenta organizarea logica a întregii baze de date
 subschema – care reprezenta o parte a bazei de date așa cum e vazută de
utilizator sau de programele de aplicație
 un limbaj de gestionare a datelor – care definea caracteristicile datelor, structura
lor și care m anipula datele
Pentru standardizare, s -au propus trei limbaje:
 un limbaj de definire a datelor (LDD) la nivel de schemă
 un limbaj ajutător la nivel de subschemă
 un limbaj de manipulare a datelor (LMD)
Cu toate că nu a fost adoptată formal de ANSI (American National Standard
Institute) propunerea DBTG a fost aplicată într -o serie de sisteme dezvoltate ulterior și ea
stă la baza conceptului modern de bază de date.
Proiectul ierarhic și cel prezentat de CODASYL reprezintă prima generație de
Sisteme de Gestiune a Bazelor de Date (SGBD).
În 1978 E.F.Codd de la IBM Research Laboratory a elaborat o lucrare care a avut o
influență covârșitoare în dezvoltarea bazelo r de date, l ucrarea trata modelul de date
relațional.
După această dată s-au proiecta t multe sisteme di ntre care menționă m System R
dezvoltat la IBM's San Jose Research Laboratory din California, la sfârșitul anilor '70.
Acest proiect a dus la:
 dezvoltarea unui limbaj structurat de interogare (numit SQL) care de atunci a
devenit un standard pentru sistemele relaționale;
 producerea în anii '80 de sisteme comerciale arhicunoscute dintre care
menționăm: DB2 și SQL/DS de la IBM și ORACLE de la ORACLE Corporation.
Dintre sitemele relaționale pentru microcalculatoare enumerăm aici: Paradox și
dBase IV de la Borlan d, Access de la Microsoft, FoxPro și R:base de la Microrim. Toate
acestea const ituie generaț ia a doua de SGBD.
În funcție de condițiile concrete în care se realizează, o bază de date se încadrează
într-o anumită categorie, având anumite caracteristici. Ast fel criteriile ce se au în vedere la
proiectarea și realizarea bazelor de date și particularitățile SGBD -ului pot constitui, în
același timp, și criterii de clasificare a bazelor.
Dintre acestea, următoarele sunt considerate ca fiind cele mai importante [13]:

6 a. domeniul de aplicații;
b. modul de organizare, structurare și accesare a datelor;
c. gradul de centralizare a datelor;
d. modul de prelucrare.
După domeniul de aplicații bazele de date pot fi:
Baze de date universale , care satisfac toate cerințele în cadr ul unei anumite
structuri organizatorice și funcționale (la nivelul unei unități economice);
Baze de date specializate , care satisfac cerințele unor anumite sectoare de
activitate (baze de date privind sistemul de sănătate, baze de date privind activitate a de
cercetare, de învățământ, baze de date multimedia, baze de date GIS, baze de date spațiale
etc.).
Din punct de vedere al modului de organizare, structurare și accesare a datelor ,
cele mai cunoscute tipuri de baze de date sunt:
 baze de date de tip re țea;
 baze de date ierarhice;
 baze de date relaționale;
 baze de date orientate pe obiecte.
Toate acestea au caracteristicile modelelor de structurare a datelor corespunzătoare
(ierarhice, rețea, relaționale sau pe obiecte), astfel:
Bazele de date de ti p rețea au la bază organizarea și structurarea datelor după
modelul de tip rețea.
Bazele de date ierarhice se caracterizează prin faptul că elemen -tele componente
au relații de subordonare de tip unu la mulți, astfel încât fiecare entitate are în subordine
una sau mai multe entități și este subordonată, la rândul ei, unei singure entități superioare,
conform modelului ierarhic de organizare a datelor.
Bazele de date relaționale au la bază modele de date relaționale și vor fi tratate în
detaliu în capitolel e următoare.
Bazele de date orientate pe obiecte , numite și baze de date obiectuale, sunt
construite pe modele de date complexe, structurate pe obiect.
Bazele de date centralizate sunt colecții de date grupate, atât din punct de vedere
fizic cât și logic , într -un punct central unde se asigură prelucrarea integrată a acestora. În
cadrul bazelor de date centralizate se poate asigura un înalt grad de protecție și securitate a
datelor.
Bazele de date distribuite reprezintă colecții de date care, din punct de vedere
fizic, sunt dispersate în diferite puncte (stații) ale unei rețele, iar din punct de vedere logic
sunt integrate în cadrul unui sistem informatic, fie prin relații funcționale, fie prin aceea că
reprezintă copii ale aceluiași fișier, astfel încât a cestea const ituie o colecție unică de date.
După modul de prelucrare , bazele de date se împart în:
 baze de date operaționale
 baze de date analitice.
Bazele de date operaționale sunt utilizate în principal în scenarii de tipul OLTP
(On-Line Transaction P rocessing), când datele sunt introduse și actualizate zilnic. Datele
stocate sunt dinamice, acest tip de baze de date, conținutul acestora fiind disponibil la puțin
timp după actualizare.
Bazele de date analitice sunt utilizate în scenarii de tip OLAP (On -Line Analytical
Processing) în care datele stocate sunt istorice și dependente de timp. Acest tip de date sunt
statice, actualizarea lor realizându -se rar.
Bazele de date relaționale și cele orientate pe obiect sau dovedit mult superioa re,
având cea mai mare aplicabilitate în practica informatică actuală.

7 I.3. Baze de date relaționale

Modelul relațional asociază unei entități o tabelă bidimen sională numită relație, în
care coloanele tabelei reprezintă atributele entității și liniile (rândurile) tabelei reprezintă
membrii entității.
Fiecare coloană are un nume distinct, prima linie fiind destinată amplasării acestor
nume de atribute. O linie dintr -o relație se numește tuplu. Tuplurile sunt distincte, dublurile
nu sunt admise. Numărul de tupluri dintr -o relație reprezintă cardinalitatea relației.
La nivelul organizării fizice există următoarele corespondențe:
– relație poate fi asociată unui fișier,
– un tuplu se asociază cu o înregistrare,
– coloană corespunde unui câmp din înregistrare
Cheia primară obținută pr in concatenarea mai multor atribuite este necesară atunci
când nu există un singur câmp care să identifice unic un tuplu. În cazul în care există mai
multe atribute care pot fi definite drept chei de identificare, acestea formează mulțimea
cheilor candidat e, din care se alege cheia primară.
Schema relației reprezintă mulțimea atributelor prin care se descrie o relație,
împreună cu domeniile asociate acestora și numele atributelor
Restricțiile de integritate sunt reguli care asigură corectitudinea și coere nța datelor:
 unicitatea cheii (UNIQUE)
 referențială – cheie externă (REFERENTIAL)
 integritatea entității (NOT NULL)
 cheie primară (PRIMARY KEY)
 comportament (CHECK)
 dependența datelor (la proiectare)
În legătură cu cheia primară, este necesar a fi r espectate două cerințe de integritate:
a) integritatea entității – conform căreia nici un atribut care participă la formarea cheii nu
poate avea valori nule;
b) integritatea referențială – conform căreia, dacă într -o relație apare un atribut prin care
se face referință la un alt tuplu din relația curentă sau o altă relație, atribut care se
numește în acest caz cheie externă, atunci el trebuie să aibă valori valide, care să existe
în relația către care face referință; cu alte cuvinte, dacă tuplul t1 referă un tuplu t2
atunci acest tuplu trebuie să existe.
Cheia secundară (externă) reprezintă atribut sau grup de atribute dintr -o relație R1
ale cărui valori sunt definite pe același domeniu ca și cheie primară a unei relații R2, care
are rolul de a modela aso cierea între entităților reprezentate prin R1 și R2
Pentru a ajunge la o schemă de relații și chei primare convenabile pentru
reprezentarea corectă a entităților și a legăturilor dintre ele este nevoie de un proces de
proiectare care include și optimizare a structurii relațiilor.
Această modalitate de descriere a structurii datelor face mai flexibilă și descrierea
legăturilor dintre colecțiile de date, relațiile dintre aceste colecții. Aceste relații se
concretizează în:
 câmpuri comune existente în cadrul entităților aflat într -o anumită relație;
 tabele sau fișiere de legături, fișiere index, constituite pe baza valorilor acestor
câmpuri comune sau a unor adrese de legătură determinate cu algoritmi specifici.
Indiferent de nivelul la care se stabilesc re lațiile între date, atunci când colecțiile
sunt supuse prelucrării, relațiile devin operaționale la nivel de atribut și se realizează în
funcție de valoarea acestora. Cu ajutorul acestor relații, atât câmpurile cât și înregistrările
fișierelor aflate într -o anumită relație pot fi identificate, accesate și prelucrate cu ușurință.
După numărul de entități implicate, relațiile pot fi:

8  relații binare, în care sunt implicate elementele a două entități;
 relații complexe, în care sunt implicate mai multe entită ți;
 relații recursive, în care sunt implicate elementele aceleiași entități.
Relațiile binare, la rândul lor, sunt de două tipuri:
 unidirecționale, când presupun exis tența a două colecții: principală și secundară;
 bidirecționale, care presupun existenț a a două colecții de aceeași complexitate.
În funcție de numărul de elemente, între care se stabilesc relații, aparținând celor
două colecții, aceste relații pot fi de tip unu la unu, unu la mulți și mulți la mulți.
Relațiile de tipul 1 →1 (unu la unu) , care presupune că unui membru din colecția X
îi corespunde un singur membru din colecția Y.
Relațiile de tipul 1 →m sau m →1 (unu la mulți sau mulți la unu) , care presupune
că unui membru din prima entitate X îi corespund mai mulți membri din a doua entitate Y;
astfel de relații se mai numesc și relații ierarhice.
Relațiile de tipul m →m (mulți la mulți) , în care unui membru din entitatea X îi
corespund mai multe date din colecția Y și mai multor date din colecția X îi corespunde o
singură dată din colecția Y . O relație mulți la mulți se va descompune întotdeauna în două
relații, o rela ție tip unu la mulți și o a doua relație de tip mulți la unu prin interme diul unei
entități de legătură.
Etapele proiectării BDR . Proiectarea unei baze de date necesită parcurge rea
următoarelor etape:
 formularea problemei;
 analiza cerințelor informaționale și definirea datelor de ieșire și a datelor de intrare;
 definirea tabelelor, a structurii acestora și a relațiilor dintre tabele;
 optimizarea structurii bazei de date.
Când acest proces a fost finalizat se continuă cu:
 proiectarea procedurilor tehnologice, pentru prelucrarea bazei de date;
 elaborarea programelor;
 testarea programelor;
 definitivarea documentației.
Toate aceste activități necesită, pentru proiectele reale complexe, o muncă în echipă
pe baza unei metodologii riguroase, cunoscute că metodologia de analiză și proiectare a
sistemelor informatice. În cadrul unui sistem informatic baza de date reprezintă elementul
central în jurul căruia se concentrează celelalte componente ale sistemului.
Formularea p roblemei presupune stabilirea obiectivelor aplicației informatice care
asigura actualizarea și exploatarea bazei de date în concordanță cu cerințele
managementului activității economice pentru care este proiectată ba za de date. Obiectivele
unei aplicații informatice sunt legate de asigurarea informațională a desfășurării proceselor
decizionale specifice actului de conducere. Baza de date trebuie să permită atât obținerea
unor informații de detaliu, elementare, cât și calculul și prezentarea unor indicatori
sintetici, agregați
Analiza cerințelor informaționale , pornind de la obiectivele formulate anterior, se
concentrează asupra a două probleme:
– indicatorii, rapoartele, listele și datele de ieșire care trebuie obținute ;
– datele de intrare necesare pentru obținerea datelor de ieșire.
Acestea sunt cerințele informaționale care înglobează atât cerințele pentru datele de
intrare pe baza cărora se creează și se actualizează baza de date, cât și cerințele pentru datele de
ieșire folosite pentru urmărirea, controlul și dirijarea activității economice. Datele de intrare se
culeg, de regulă, din documentele primare care circulă în cadrul fluxului informa -țional al
firmei. Datele finale se vor integra în ansamblul de rapoarte, lis te, situații cu rezultate pe care
le furnizează sistemul informațional compartimentelor de conducere. Pentru indicatorii incluși
în rapoartele finale, în general pentru oricare din indicatorii de ieșire, trebuie să fie foarte clar

9 modul în care sunt obținu ți prin prelucrarea datelor de intrare. În consecință, acolo unde este
cazul, se precizează algoritmii de calcul, regulile de totalizare, sau alte reguli de obținere a
fiecărei coloane, sau totaluri din rapoartele finale.
Aceasta are ca punct de plecare i nventarierea câmpurilor prezente în situațiile finale și
apoi gruparea lor în tabele. Gruparea câmpurilor pe tabele se realizează prin diverse metode.
Dintre aceste metode, două sunt cele mai utilizate:
– analiza concordanței IEȘIRI – INTRĂRI;
– analiza semn ificației semantice a datelor.
Analiza concordanței IEȘIRI – INTRĂRI este o tehnică specifică proiectării sistemelor
informatice care identifică documentele primare din care se preiau datele de intrare folosite în
calculul datelor de ieșire. Aceste docume nte vor constitui sursele de creare și actualizare a
fișiere -lor/tabelelor bazei de date.
Tehnica este utilă în cazul în care proiectantul bazei de date este familiarizat cu
sistemul informațional existent.
Un indicator prezent într -o situație finală se poate obține astfel:
– prin preluarea directă din documentul primar, respectiv din tabelul bazei de date;
– prin aplicarea unui algoritm de calcul.
Indicatorii preluați direct fără nici o prelucrare din baza de date sunt considerați
indicatori de tip P. Din această categorie se detașează acele câmpuri care sunt de fapt coduri,
dintre care unele coduri vor fi ul -terior desemnate chei de identificare și regăsire a datelor.
Acești indicatori, în mod distinct sunt considerați indicatori de tip C. Pentru fiecare indicator
de tip C trebuie să existe un nomenclator de coduri și reguli de codificare.
Indicatorii care se obțin prin aplicarea unui algoritm, evaluarea unor expresii etc., sunt
indicatori de tip D, adică indicatori derivați. Pentru fiecare indicator deri vat trebuie să avem un
algoritm clar de calcul. În baza de date vor rămâne numai câmpurile primare folosite în
calcule. Excepție fac acele câmpuri care trebuie menținute în baza respectării principiului
redundanței minime și controlate.
Definirea tabelelor și relațiilor dintre tabele este etapa următoare în proiectarea bazei
de date. Analiza cerințelor informaționale și a proceselor de prelucrare va conduce la
identificarea datelor ce vor trebui stocate și care vor alcătui tabelele bazei de date. O tabelă v a
păstra datele fie despre toate caracteristicile unei colecții de date, fie numai pentru o parte
dintre aceste caracteristici. Aici intervine spiritul analitic al proiectantului. Structura unei
tabele este reprezentată de lista câmpurilor asociate tabelei împreună cu descrierea atributelor
fiecărui câmp (natură, lungime, număr de zecimale etc.). În structura unui tabel se regăsesc
următoarele categorii de câmpuri:
 câmpuri de identificare (chei primare și chei condiționate);
 câmpuri tip dată calendaristic ă;
 câmpuri cantitativ -valorice;
 câmpuri de legătură cu alte tabele;
 câmpuri de stare care păstrează informații privind ultimele operații de prelucrare care
au fost efectuate pe înregistrările din tabel.
Relațiile dintre tabele se caracterizează prin pl asarea unor câmpuri comune în structura
fiecăruia dintre tabelele aflate în relație directă. Pe baza acestor câmpuri, chei, fiecare sistem
de gestiune a bazelor de date își construiește un mecanism propriu de accesare a înregistrărilor
de date. Aceste meca nisme sunt transparente pentru utilizatorul obișnuit. Cheile candidate se
mai numesc și indecși . Operația prin care se construiește sistemul de legături pentru ordonarea
în vederea regăsirii înregistrărilor într -o tabelă se numește indexare . Prin indexare, fiecărei
tabele principale de date i se va asocia o tabelă index corespunzătoare cheilor de indexare.
Optimizarea structurii bazei de date este un proces prin care se urmărește:
 reducerea redundanței datelor;
 eliminarea anomaliilor de actualizare.

10 Redu cerea redundanței datelor până la un nivel minim și controlat urmărește eliminarea
duplicării inutile a unor câmpuri în mai multe tabele sau eliminarea câmpurilor obținute prin
calcul pe baza câmpurilor atomice.
Anomaliile de actualizare se referă la anom aliile de ștergere, res -pectiv de modificare.
Normalizarea BDR
Teoria normalizării aparține celui ce a fundamentat mode -lul relațional al bazelor de
date în 1970, americanul E. F. Codd.
Normalizarea reprezintă procesul de transformare succesivă a unei BDR în vederea
aducerii sale într -o formă standard optimizată, denumită formă normală . Prin normalizare se
are în vedere eliminarea anomaliilor, dependențelor nedorite între date, eliminarea
redundanțelor E.F. Codd presupune un proces de normalizare pe etape.
La ora actuală există cinci forme normale și o formă normală intermediară.
Pentru aducerea relației în forma normală 1 (FN1) procesul începe prin analiza
atributelor relației. Aceasta conduce la precizarea modului în care atributele de regăsesc în
cadrul t abelei: la nivel elementar sau la nivel compus.
O tabelă este în FN1 dacă sunt eliminate câmpurile/grupurile repetitive, iar toate
câmpurile sunt câmpuri atomice. Grupul de câmpuri care se repetă va forma o nouă tabelă care
se leagă de tabela principală p reluând de la aceasta cheia sa primară.
Pentru forma normală 2 (FN2) analiza se realizează la nivelul cheilor relației.
Aceasta presupune verificarea existenței cheilor concatenate. În cazul în care acestea
există, are loc verificarea existenței dependențe lor funcționale complete. Dacă există
atribute care depind funcțional numai de una din cheile concatenate, atunci are loc
descompunerea relației în două sau mai multe relații.
O tabelă este în FN2 dacă fiecare câmp este dependent funcțional de cheia prima ră a
tabelei, indiferent că este formată dintr -un singur câmp sau este cheie concatenată.
Aducerea unei tabele la FN2 înseamnă înlocuirea unei tabele aflate în FN1 cu două
sau mai multe tabele care respectă regula de nor -malizare FN2.
În situația în care nu există chei concatenate, atunci relația se află în FN2 și se trece
la evaluarea criteriului următor.
Pentru forma normală 3 (FN3) este necesar să se stabilească existența
dependențelor tranzitive în cadrul relației. Prezența dependențelor tranzitive în cadrul unei
relații impune descompunerea acesteia în mai multe relații care cuprind numai atribute ce
depind de cheie. După înlăturarea dependențelor de tip tranzitiv, relația se găsește în FN3
și se evaluează criteriul pentru forma normală 4.
Forma norma lă Boyce Codd (BCNF) este o formă intermediară. O relație este în
BCNF dacă pentru orice dependență funcțională între două atribute din cadrul relației
atunci atributul determinant este cheie candidată.
În practică procesul de normalizare se încheie la FN 3 sau BCNF.
Pentru aducerea bazei de date în forma normală 4 (FN4) se verifică existența a mai
mult de două dependențe de tip multivaloare în cadrul relației. Prezența acestui tip de
dependență impune descompunerea relației în mai multe relații, altfel, ta bela se află în FN4
și se evaluează criteriul următor de normalizare.
Forma normală 5 (FN5) are în vedere analiza existenței dependențelor de tip join.
Prezența dependențelor de tip join impune descompunerea relației considerate în mai multe
relații, altf el, tabela se află în FN5, iar structura bazei de date este normalizată.
Procesul de normalizare a tabelelor bazei de date este un proces de analiză, creativ,
prin care, pornind de la o bază de date cu structură nenormalizată, o descompunem în
tabele norm ale cu respectarea principiilor asigurării integrității datelor.

11 I. Sistemul de gestiune a bazelor de date Microsoft Access

La începutul anilor 80 s -a produs o trecere în masă la elaborarea și utilizarea
sistemelor de gestiune a bazelor de date de tip relaț ional.Acest fenomen se explică prin
atingerea unor limite tehnice și prin flexibilitatea redusă a sistemelor de gestiune a bazelor
de date cu structuri arborescente și rețea care se foloseau pînă atunci .Înzestrate cu limbaje
de generația a patra și cu gen eratoare de aplicații puternice , SGBD de tip relațional oferă
numeroase facilități de proiectare și dezvoltare a aplicaților .Cele mai răspîndite SGBD de
acest tip sunt: Oracle, Informix, SyBase, MySQL, Interbase, Access, acesta din urmă fiind
subiectul c apitolului de față.
Sistemul de gestiune a bazelor de date MS Access 2010 (și versiunile care l -au
precedat) a fost realizat de corporația Microsoft și reprezintă o nouă ideologie în acest
domeniu, avînd performanțe sporite.

II.1. Microsoft Access. Preze ntare general

Sistemul de gestiune al bazelor de date (SGBD) Microsoft Access face parte din
pachetul de aplicații Microsoft Office exploatabil sub sistemele de operare Windows 2000
și Windows XP. Microsoft Access deține toate caracteristicile specifice u nui sistem de
gestiune a bazelor de date relaționale; puternic, flexibil și ușor de folosit, el reprezintă
totodată și un instrument complex de dezvoltare a aplicațiilor de bază de date.
Microsoft Access include avantajele oferite de sistemul de operare M icrosoft
Windows; în plus permite și facilitate de tipul drag and drop. De asemenea, este deplin
compatibil cu tehnicile de legare și încapsulare în tehnologia OLE a firmei Microsoft.
Caracteristicile definitorii ale sistemului de gestiune a bazelor de dat e Microsoft Access se
pot sintetiza în următoarele:
 Posibilitatea creării unei baze de date care să poată fi utilizată de către unul sau mai
mulți utilizatori în mod partajat;
 Interogarea bazei de date se poate realiza în mod grafic prin interfața QBE (Que ry By
Example), sau prin limbajul SQL (Standard Query Language);
 Automatizarea unor activități/acțiuni prin programare în limbajul VBA sau prin
macrocomenzi;
 Realizarea importului/exportului de date către alte aplicații ale pachetului de date
Microsoft Off ice sau alte SGBD -uri relaționale;
 Interfața utilizator GUI (Graphical Ușer Interface) este ușor de folosit și respectă
principiile de utilizare caracteristice tuturor aplicațiilor pachetului Ms Office, ceea ce
face că utilizatorul să regăsească un mediu d e lucru familiar la care să se adapteze cu
ușurință;
 Fundamentare pe concepte noi, cum sunt conceptele de obiect, proprietăți ale
obiectelor, eveniment, procedura declanșată la apariția unui eveniment, metode la
care obiectele reacționează în momentul prod ucerii unui eveniment, programare
orientată pe obiecte și evenimente;
 Asistență în dezvoltarea de aplicații și utilizarea bazei de date;
 Existența meniului Help și a facilităților de ajutor contextual;
 Înglobarea de componente Wizard pentru a ajuta utiliza torii în dezvoltarea de
aplicații;
 Tabelele din baza de date pot prelucra sute de mii de înre gistrări.

12 Microsoft Access este un instrument puternic pentru dezvoltarea și gestionarea
bazelor de date relaționale de capacitate mică/medie. Sub aspectelor perfo rmanțelor în
funcționare, acestea scad odată cu creșterea volumului bazei de date; astfel, când numărul
înregistrărilor depășește ordinul sutelor de mii, viteza de lucru este sub nivelul celei oferite
de sistemele de gestiune a bazelor de date Oracle, Micr osoft SQL Server sau Infomix .
Totodată , Microsoft Access îndeplinește cele mai multe dintre cerințele sistemelor
de bază de date de tip client/server, fiind și un instrument foarte bun pentru dezvol tarea de
aplicații front -end. În ciuda complexității sale , este un sistem ușor de utilizat chiar și de cei
care nu sunt programatori, fiind echipat cu numeroase programe Wizard, aplicații auxiliare
ce controlează mul te dintre operațiilor uzuale ale activităților de creare și editare ale
tabelelor, interogărilor, formularelor și rapoartelor.
Microsoft Access are o structură de bază de date capabilă să combine într -un singur
fișier de tip .mdb toate obiectele cu care lucrează: tabelele, interogările, formularele,
rapoartele, comenzile macro și codul Visual Basic.
Proiectarea aplicațiilor Microsoft Access utilizează fișiere .mdb separate pentru
păstrarea informațiilor, realizându -se împărțirea unei aplicații în două părți:
1. front -end – ce cuprinde elementele de interfață cu utilizatorul;
2. back -end – ce cuprinde tabelele bazei de date.
Această tehnică este foarte utilă atunci când pentru componența back -end a unei
baze de date, se apelează la un server puternic de baze de date ce pune la dispoziție toate
facilitățile unei baze de date relaționale mari, î n timp ce pentru componența front -end,
Microsoft Access pune la dispoziția utilizatorilor numeroase facilități precum formularele,
rapoartele și interogările.
Unul din principalele avantaje din perspectivă client/server îl constituie creșterea
vitezei de lucru și minimizarea traficului de rețea, garantând că atât clientul cât și serverul
lucrează la parametric optimi.
Funcții de bază și funcții suport
În ceea ce privește funcțiile de bază ale Microsoft Access 2010, acestea sunt
prezentate în continuare .
Organizarea datelor include crearea și manevrarea tabelelor ce cuprind date în
format tabelar.
Legarea tabelelor și extragerea datelor leagă mai multe tabele prin intermediul
legăturilor de date, creând tabele temporare. Pentru crearea acestor legături, Microsoft
Access folosește interogări prin intermediul cărora datele alea vor fi stocate într -un table
temporar (recordset). Capacitatea de a lega tabele prin relații este una dintre deosebirile
esențiale dintre bazele de date relaționale și aplicațiile de gestiune a fișierelor.
Introducerea și editarea datelor prespune proiectarea și implementarea modului
de vizualizare a datelor, a formularelor de introducere și de editare, ca posibilitate de
prezentare a datelor în afară de cea sub formă tabelara. Major itatea utilizatorilor preferă
formularele pentru introducerea datelor, mai ales când sunt implicate date din mai multe
tabele.
Prezentarea datelor implică existența rapoartelor prin intermediul cărora se pot
centraliza informațiile necesare tipăririi.
Funcțiile suport aplicabile funcțiilor de bază din Microsoft Access 2010 sunt
descrise în continuare.
Macrocomenzile sunt constituite din secvențe de acțiuni ce automatizează operațiile
repetitive din cadrul unei baze de date.
Modulele sunt funcții și pro ceduri scrise în Visual Basic, pentru executarea unor
operații ce depășesc macroinstrucți unile standard.

13 Securitatea este determinată din funcțiile disponibile ca opțiuni ale meniurilor fiind
esențiale într -un mediu multi -user; ele permit acordarea de drep turi citire/scriere unui grup
de utilizatori.
Tipărirea permite imprimarea a aproape orice este afișat în modul de lucru
Microsoft Access.

II.2. Arhitectura Microsoft Access
II.2.1. Tabele
Datele ce fac obiectul prelucrării (datele de intrare) vor fi memorate într -o bază de
date; elementele fundamentale ce creează o bază de date relațională sunt tabelele. Este
esențial ca fiecare tabel al bazei de date să conțină informații specifice unui singur tip de
obiecte.
Un tabel reprezintă o colecție de date legată între ele, memorată pe linii și coloane;
fiecare linie conține o înregistrare -entitate completă de date referitoare la un anumit tip de
obiecte. La rândul ei fiecare înregistrare este compusă din coloane sau câmpuri – un câmp
reprezentând cea mai mi că entitate de date. Fiecare câmp trebuie să fie legat într -un fel de
destinația tabelului din care face parte. Interacțiunea cu tabelele se face rareori direct; în
acest scop, tabelelor le sunt asociate alte obiecte Microsoft Access – interogari, formular e
și rapoarte. Atunci când programul trebuie să afișeze sau să refere datele memorate în baza
de date, un formular sau un raport va regăsi datele din tabelul sau interogarea la care este
asociat și le va afișa în format de formular sau de raport.
O bază d e date Microsoft Access poate cuprinde cel mult 32.768 de tabele, dintre
care 254 pot fi deschise simultan, dacă există suficiențe resurse disponibile. [11]
Majoritatea tabelelor unei baze de date au unul sau mai multe câmpuri ce identifică
în mod unic fiec are înregistrare din acel tabel. Acest tip de identificare unic poartă numele
de cheie primară și este folosită la indexarea tabelului respectiv. Cheile primare stabilesc
relațiile prin care mai multe tabele ale unei baze de date sunt legate la crearea une i
interogări.
În proiectarea și realizarea bazelor de date relaționale, normalizarea este o etapă de
optimizare, care are ca scop garantarea coerenței bazei de date în timpul operațiilor de
includere, modificare și suprimare de date, având ca rezultat un model ce respectă criteriile
de definire semantica și integritatea datelor. Normalizarea tabelelor implică, de fapt,
aplicarea unui set de reguli la proiectarea tabelelor unei baze de date care oferă câteva
avantaje majore: [5]
 Elimină informațiile redunda nte, ceea ce reduce probabilitatea multiplicării erorilor
de introducere care să corupă baza de date, simplificând în același timp și
întreținerea acesteia prin faptul că o valoare este păstrată într -un singur loc, deci
modificările asupra ei se pot efectu ă o singură dată;
 Reduce mărimea bazei de date deoarece fiecare tip de informație este păstrat într -o
unică locație, deci baza de date nu va fi încărcată cu copii ale aceleiași baze de date
aflate în mai multe tabele;
 Facilitează căutările ;
 Simplifica inte rogările .
Există cinci forme de normalizare, dintre care primele trei sunt cele mai utilizate:
1. prima formă normală presupune că fiecare câmp dintr -un tabel conține un singur
tip de date, deci fiecare rând conține un articol indivizibil și care nu se repet ă. Tabelele ce
respectă această formă sunt ușor de organizat pe criterii logice, fiindu -le stabilite chei
primare.

14 2. a două formă normală specifică și necesitatea dependenței între cheia primară și
celelalte coloane ale tabelului. Pentru a respecta a doua fo rmă normală trebuie îndeplinită
prima formă normală, la care se adaugă și necesitatea că orice câmp din tabel ce nu este
cheie primară să fie dependent de aceasta;
3. a treia formă normală obligă la independența între coloanele ce nu constituie chei
primare, simultan cu dependența lor de respectivul câmp.
Ceea ce diferențiază o bază de date relațională de alte aplicații de gestiune este
capacitatea acesteia de a lega două sau mai multe tabele astfel încât să apara în fața
utilizatorului că o singură tabelă. Î n acest context sunt foarte importante relațiile ce se
stabilesc între tabelele unei baze de date:
1. relațiile de tip unu-la-unu sunt cele mai simple și mai rar folosite, unde fiecare
înregistrare dintr -un tabel corespunde unei singure înregistrări d in alt t abel.
2. relațiile de tip unu-la-mai-mulți sunt cele mai frecvente tipuri, realizând legătura
dintre un rând dintr -un tabel și două sau mai multe rânduri din alt tabel. Legătura se
realizează prin cheia primară a tabelului de bază și cheile corespunzătoare ta belelor
asociate. Opusul acestei relații este cea de tipul mai -mulți-la-unul.

Figură 1. 1 Caseta de dialog Relationships pentru o legatură unu la mulți

3. relații de tipul mai-mulți -la-mai-mulți există numai în mod indirect, fi ind create
pe bază a două relații unu -la-mai-mulți, constituindu -se că asocieri libere între tabele.
Indiferent de tipul de relații existent între două sau mai multe tabele este esențial ca cele
două câmpuri participante la aceasta să aibă exact același ti p de date.
Dintre caracteristicele Microsoft Access 2010 în domeniul relațiilor dintre tabele:
 vizualizarea datelor legate într -un subtabel. Prin intermediul unui subtabel, la
selectarea unui câmp dintr -un tabel legat de unul sau mai multe tabele, sunt af ișate
toate informațiile din cadrul tabelelor corespondente;
 tipărirea relațiilor existente între tabele, așa cum apar ele pe ecran;
 utilizarea tastaturii în crearea sau editarea relațiilor dintre tabele.
Integritatea bazei de date este constituită din in tegritatea entității și din cea
referențială; integritatea entității impune ca toate cheile primare să fie unice în cadrul unui
tabel, iar integritatea referențială impune ca toate cheile externe să aibă valori
corespondente în cheia primară dintr -un tabel principal, împiedicând apa riția
“înregistrarilor orfane”. [3] Regula impusă de păstrarea integrității referențiale nu permite
efectuarea unor operații precum:
o adăugarea unei înregistrări în partea mai mulți a unei relații unu -la-mulți, fără să
existe o înregistrare corespondenta și în partea unu;

15 o ștergerea unei înregistrări în partea unu a unei relații unu -la-mulți fără să fie șterse
toate înregistrările corespondențe din partea mai mulți;
o schimbarea valorii câmpului de cheie primară dintr -un ta bel de bază de care depind
înregistrări din tabele corelate;
o înlocuirea valorii câmpului cheie externă într -un tabel de relații, cu o valoare care
nu există în tabelul principal;
o adăugarea sau ștergerea unei înregistrări într -un tabel aflat în rela ție unu -la-unu cu
un alt tabel, fără realizarea aceleiași operații și a tabelului corespondent.
Păstrarea integrității referențiale implică de cele mai multe ori și actualizarea,
respectiv ștergerea în cascadă a înregistrărilor asociate atunci când tabelu l principal este
modificat, acțiuni pe care Microsoft Access 2010 le poate executa automat dacă în
momentul realizării relațiilor între tabele se selectează și aceste opțiuni.
II.2.2. Interogări
O interogare ( query ) este o definiție a datelor care se ext rag: care câmpuri din
tabele, din ce tabele, criteriile de selecție, ordinea de sortare. Structura unei interogări
indică datele care se vor extrage, Microsoft Access oferind următoarele posibilități:
 Selectarea anumitor câmpuri mai semnificative din înreg istrările unei tabele;
 Selectarea înregistrărilor care satisfac anumite criterii;
 Sortarea înregistrărilor într -o ordine precizată de utilizator;
 Interogarea mai multor tabele; o interogare permite combinarea înregistrărilor
din mai multe tabele și afișare a rezultatului într -un singur tabel de date;
 Interogarea altor baze de date existente în sisteme de gestiune a bazelor de date
cum sunt FoxPro, Paradox, dBase, Btrieve, Microsoft SQL Server;
 Crearea de câmpuri pentru afișarea rezultatelor unor calcule;
 Crearea de rapoarte, formulare sau alte interogări.
Odată construită, o interogare poate fi sursă de înregistrări pentru crearea unui
formular sau a unui raport. De fiecare dată când se deschide formularul sau se imprimă
raportul, interogarea folosită drept sursă de date, extrage din tabela informații actualizate.
De asemenea se pot introduce sau modifica date fie direct în tabelul de date a interogării,
fie în formularul creat pe baza acesteia.
În Microsoft Access 2010 se poate crea următoarele tipuri de in terogări: interogări
de selecție, interogări de acțiune, interogări încrucișate și interogări parametrice.
Interogările de selecție extrag informații din unul sau mai multe tabele și le
afișează sub formă de listă. Sunt cel mai ușor de creat și au avantaj ul că pot afișa un număr
redus de date dintr -un tabel de mare capacitate (datele care îndeplinesc condițiile
specificate). Ele permit și modificarea rezultatului afișat, modificare ce va fi văzută și în
tabelul sursă. De asemenea permit și folosirea de par ametri, cum este reuniunea de câmpuri
din tabele între care nu există nici o legătură.
Interogările de acțiune creează un nou tabel în baza de date sau realizează
modificări majore ale unui tabel existent. În general, toate interogările de acțiune pot fi
realizate pe bază unei interogări de selecție. Ele permit adăugarea, modificarea sau
ștergerea de înregistrări într -un tabel. Există patru tipuri de interogări de acțiune:
1. interogări de generare a unui nou tabel din datele conținute în setul de rezulta te al
interogării;
2. interogări de adăugare a noi înregistrări într -un tabel;
3. interogări de ștergere a unor interogări dintr -un tabel;
4. interogări de actualizare a unor înregistrări dintr -un tabel, conform cu o condiție ce
trebuie îndeplinită.

16 Acțiunile acestora sunt ireversibile asupra datelor din tabelele sursă, iar în cazul
ultimelor trei dintre ele, trebuie urmărită păstrarea integrității referențiale, atunci când prin
intermediul lor se acționează asupra mai multor tabele legate.
Interogăril e încrucișate centralizează în formatul unei foi de calcul tabelar datele
din unul sau mai multe tabele. Datele rezultate după execuția unei astfel de interogări sunt
prezentate într -un mod potrivit pentru analiză datelor și crearea de grafice.
Interogări le parametrice nu sunt un tip special de interogări, o funcție parametru
putând fi folosită pentru toate celelalte interogări prezentate mai sus; ele folosesc în mod
repetat o interogare, efectuând modificări în criteriile de selecție.
Crearea interogăril or
Microsoft Access include patru modalități de creare a unei interogări:
1. automat (Query Wizard). Crearea interogărilor folosind Query Wizard, este
posibilă atât pentru interogările de selecție cât și pentru interogările încrucișate. Simple
Query Wiza rd este destinat pentru crearea de interogări de selecție în principiu dintr -un
singur tabel, dar poate afișa date din două sau mai multe tabele și interogări între care
există sau nu legături directe. Printre opțiunile puse la dispoziția utilizatorului su nt și cele
de adunare/contorizare a datelor din câmpurile ce conțin valori numerice. Pentru
interogările încrucișate, Microsoft Access 2010 dispune de un program Wizard dedicate
(Crosstab Query Wizard) care se poate accesă prin intermediul butonului New. C rosstab
Query Wizard este restricționat de posibilitatea de a totaliza date doar dintr -un singur tabel.
2.manual (Query Design). Crearea manuală a interogărilor se realizează prin
intermediul opțiunii Query Design care folosește pentru interfața grafica Que ry By
Example (QBE). Aceasta permite și utilizatorilor care nu știu limbajul de programare QBE
să găsească și s ă afișeze informațiile de care au nevoie. Odată activat ă opțiunea Query
Design, Microsoft Access 2010 va considera implicit că orice generare a unei noi
interogări este o interogare de selecție. Transformarea tipului de interogare implicit se face
prin selectarea tipului dorit din meniul Query. Pentru a crea o nouă interogare în modul
Query Design, se vor parcurge următorii pași:
a) selectarea t abelelor din care se doresc a fi afișate/prelucrate datele;
b) selectarea câmpurilor care se vor transforma în coloanele tabelului rezultat al
interogării;
c) stabilirea criteriilor de selecție și a câmpurilor asupra cărora vor fi aplicate; se
poate apela la un singur criteriu de selecție sau la mai multe criterii, aplicate fie unor
câmpuri diferite, fie formând un criteriu compus aplicat aceluiași câmp;
d) stabilirea parametrilor de selecție. Parametrii funcționează pentru interogări
asemănător criteriilo r de selecție, cu deosebirea că la fiecare execuție trebuie specificată
valoarea parametrului în funcție de care se va realiza selecția;
e) stabilirea tipului de sortare a datelor afișate ca rezultat și câmpurilor asupra cărora
se vor acționa;
f) specifi carea formulei pentru câmpurile care sunt rezultatul unor operații executate
asupra unora dintre câmpurile deja existente. Acest lucru se poate face fie prin scrierea
directă a formulei, fie prin apelarea la generatoarele de funcții pentru calcule mai
comp licate sau care folosesc funcții definite deja în Microsoft Access 2010 ;
g) alegerea tipului de interogare prin selectarea din meniul Query a uneia dintre
opțiunile: interogări de selecție, interogări încrucișate, de generare a unui tabel, de
adăugare în tr-un tabel, de ștergere dintr -un tabel, de actualizare a unui tabel. În funcție de
opțiunea aleasă,
3. comenzi SQL . Crearea interogărilor utilizând comenzi SQL permite construirea
directă a interogărilor pe bază unui limbaj specializat. Dacă toată tipurile d e interogări
prezentate pot fi generate folosind QBE, există interogări ce necesită folosirea unui

17 instrument mai puternic pentru gestionarea acestora, instrument numit SQL (Structured
Query Language).
SQL este un set standard de cuvinte din engleză folos ite la descrierea unei interogări,
fiind limbajul utilizat în mod obișnuit la gestionarea bazelor de date client/server, în care
aplicația de tip client generează instrucțiuni SQL prin care adaugă, editează, șterge datele
din aplicația server a bazei de da te. SQL este un limbaj orientat pe seturi, fiind un limbaj
de aplicație pentru bazele de date relaționale.
4. prin program (bibliotecile ActiveX Data Objects, Data Microsoft Access Objects
și obiectele QueryDef) . O posibilitate avansată o reprezintă crearea interogărilor prin
program. Deși cea mai obișnuită cale de creare a unei interogări este cea manuală, există
cazuri în care este necesară generarea unei interogări în timpul execuției unui program.
Aceste interogări pot fi generate fie prin apelarea la SQL , fie prin folosirea bibliotecilor
ADO, DAO și a obiectelor de tip QueryDef.
Crearea interogărilor prin program folosind SQL se bazează pe aceleași elemente:
SELECT, FROM , WHERE.
Crearea interogărilor folosind obiectele QueryDef se realizează într -un m od
asemănător cu crearea prin program a tabelelor.
Microsoft Access 2010 are îmbunătățiri în domeniul lucrului în mod local cu
informații externe gestionate de Oracle sau Microsoft SQL Server. În acest mod se poate
interoga o legătură ODBC în același mod în care se interoghează un tabel local.
Cea mai mare diferență în lucrul direct cu o bază de date aflată pe un server în ceea
ce privește crearea interogărilor prin program o reprezintă obligativitatea specificării
parametrilor de legătură. În funcție de tipul bazei de date pe care se lucrează, se vor defini
parametrii de legătură, apoi interogarea poate fi creată în mod normal, ca pentru o bază de
date locală.
II.2.3. Formulare
Formularele sunt machete (ferestre) folosite în scopul adăugării, modificări i,
ștergerii sau consultării datelor în/din tabelele bazei de date. Formularul este destinat în
special ecranului, dar poate fi tipărit și la imprimanta. Este folosit pentru un acces aleator
la înregistrări, în sensul că după ce obține accesul la o înregis trare, utilizatorul poate trece
la sfârșitul formularului pentru a adaugă o înregistrare; ulterior va putea reveni la început
pentru a caută o altă înregistrare.
Spre deosebire de rapoarte, dacă se tipărește un formular la imprimanta apar și
culorile de f undal, împreună cu butoanele de comandă, casetele de text și alte controale.
Formularele au și anumite limite; principală limită se referă la faptul că nu pot
grupa datele după diverse criterii, inconvenientul fiind eliminat prin utilizarea rapoartelor.
Actualizarea tabelelor se poate face și direct, prin deschiderea lor din fereastra bazei
de date, însă utilizarea formularelor prezintă următoarele avantaje:
 Interfața prietenoasă este realizată prin intermediul diferitelor controale sau alte
elemente graf ice;
 Posibilitatea definirii unor reguli de validare suplimentare celor definite la
nivelul tabelelor;
 Posibilitatea actualizării mai multor tabele printr -un singur formular, operație
realizabilă prin intermediul subformularelor.
Clasificarea formularelor se poate face în funcție de următoarele criterii:
1. după sursa de date :
a) formulare legate (bound) sunt formulare care permit afișarea sau actualizarea
datelor din tabele;

18 b) formulare nelegate (unbound) sunt formulare destinate afișării sau editării unor
date care nu sunt stocate în tabele. Ele sunt folosite frecvent pentru afișarea unor mesaje,
vizualizarea unor informații din sistem, preluarea datelor necesare afișării unui raport etc.
2. în funcție de modul de afișare :
a) Single form afișează do ar înregistrarea curentă;
b) Continuous form permite vizualizarea mai multor înregistrări;
c) Datasheet form afișează datele sub formă de linii și coloane, la fel ca o foaie de
calcul tabelar;
d) Chart form afișează datele sub formă grafică.
3. după modul de interacțiune cu alte ferestre :
a) formulare modale sau formulare care nu permit accesarea obiectelor conținute în
alte ferestre până când nu sunt închise sau ascunse (se mai numesc și formulare de dialog);
b) formulare nemodale sunt formulare care permit utilizatorului să activeze și alte
ferestre.
Microsoft Access 2010 permite proiectarea formularelor în următoarele scopuri: [4,
12]
 afișarea și editarea datelor . Este cea mai obișnuită utilizare a formularelor.
Formularele oferă o modalitate de pe rsonalizare a proiectării datelor în cadrul unei aplicații
de baze de date. De asemenea formularele se pot folosi pentru schimbarea, ștergerea sau
adăugarea datelor într -o bază de date;
 controlul desfășurării aplicațiilor . Se pot proiecta formulare care lu crează cu
comenzi macro sau cu proceduri Microsoft Visual Basic for Application (VBA) destinate
automatizării afișării anumitor date sau a ordinii anumitor acțiuni. Prin intermediul
comenzilor macro și a procedurilor VBA se pot deschide alte formulare, se pot lansa în
execuție interogări, se pot limita datele afișate, se poate executa o comandă din meniu, se
pot configura valori în cadrul înregistrărilor și al formularelor, se pot afișa meniuri, se pot
tipări rapoarte și realiza o mulțime de alte acțiuni. D e asemenea se poate proiecta un
formular astfel încât realizeze comenzi macro și proceduri VBA atunci când apar anumite
evenimente (de exemplu se deschide un formular, se selectează un anumit control, se
execută click pe o opțiune sau se schimbă datele di n formular);
 acceptarea intrării . Se pot proiecta formulare folosite pentru introducerea de noi
date într -o bază de date sau pentru furnizarea valorilor de date care permit automatizarea
unei aplicații;
 afișarea mesajelor . Formularele pot oferi informații referitoare la modul de
utilizare a unei aplicații sau despre acțiunile viitoare. De asemenea, Microsoft Access
furnizează o acțiune macro MsgBox și o funcție VBA MsgBox care folosesc la afișarea
informațiilor, a mesajelor de avertizare sau de eroare;
 tipărirea informațiilor . Deși pentru tipărirea informațiilor se folosesc general
rapoarte, acest lucru se poate realiza și cu ajutorul unui formular.
În esență, formu larele din Microsoft Access 2010 creează interfața utilizatorului cu
tabelele. Ele permi t realizarea unor obiective ce nu pot fi îndeplinite prin lucrul în mod
direct cu tabelele. Prin intermediul lor se operează direct asupra datelor fie dintr -un tabel,
fie din multe tabele asociate, fiind create de cele multe ori pe baza unei interogări ca re
include toate câmpurile necesare.
II.2.4. Rapoarte
Produsul final al aplicațiilor de baze de date este un raport. În Microsoft Access,
raportul este un tip de formular continuu, destinat în mod special tipăririi.
Programul Microsoft Access combină d atele din tabele, interogări și chiar formulare
și generează un raport pe care îl tipărește. Există șase tipuri de bază: [11]

19 1. rapoarte cu o singură coloană afișează toate câmpurile unei înregistrări dintr -o
tabelă; este utilizat mai rar deoarece consuma multă hârtie;
2. rapoartele dispuse pe rânduri furnizează câte o coloană pentru fiecare câmp al
unei tabele sau interogări și tipăresc valoarea fiecărui câmp al înregistrării pe rânduri
plasate sub capul de coloană. Dacă există mai multe coloane și nu în cap pe o pagină, se
tipăresc mai multe pagini suplimentare, în ordine până la epuizarea numărului de coloane;
apoi se tipărește următorul grup de înregistrări;
3. rapoartele multicoloană se obțin din rapoartele cu o singură coloană, prin
divizarea paginii în mai multe coloane asemănător tipăririi ziarelor; formatul tabelelor
multicoloană asigură un consum mai mic de hârtie;
4. rapoartele cu grupare/totalizare sunt similare rapoartelor create de alte aplicații de
gestiune a bazelor de date. Ele însumează d atele pe grupuri de înregistrări și adaugă apoi
totaluri generale la sfârșitul raportului.
5. etichetele pentru corespondență constituie un tip deosebit de raport multicoloană,
proiectat pentru a tipări în mod grupat nume și adrese sau alte informații pro venite din mai
multe câmpuri. Fiecare grup de câmpuri con stituie o celulă într -o rețea;
6. rapoartele neasociate conțin subrapoarte care au la bază surse de date nelegate,
cum ar fi tabele sau interogări.
Primele patru tipuri de rapoarte utilizează ca su rsă de date o tabela sau o interogare,
la fel ca formularele. Ele se numesc rapoarte asociate sursei de date. Raportul principal al
unui raport neasociat nu este legat la o tabelă sau interogare. Însă subrapoartele conținute
într-un raport neasociat trebui e să fie asociate unei surse de date.
Raportul parcurge secvențial înregistrările pentru tipărirea datelor cu o frecvență
mare, permițând:
 totaluri, subtotaluri și rezumate;
 gruparea datelor pe un număr de până la 10 niveluri diferite și subrapoarte
imbri cate pe maxim trei niveluri;
 folosirea unui instantaneu al datelor;
 proiectarea unui raport care să folosească rezultatele unei interogări și nu datele
dintr -o tabelă.
Raportul nu permite editarea și modificarea datelor. Orice raport este structurat pe
următoarele secțiuni:
– Report Header – zonă rezervată începutului de raport;
– Page Header – zonă rezervată începutului de pagină;
– Detail – zonă rezervată pentru descrierea rândului de detaliu din cadrul raportului;
– Page Footer – zonă rezervată pent ru sfârșitul de pagină;
– Report Footer – zonă rezervată sfârșitului de raport.
Raportul constituie cea mai bună modalitate de a tipări o copie a informațiilor
extrase dintr -o bază de date. Rapoartele au două avantaje principale față de alte metode de
tipărire a datelor: pot compara, rezuma și subtotaliza seturi complexe de date; pot fi create
să realizeze chitanțe atractive, comenzi de cumpărare, etichete pentru corespondență,
materiale de prezentare etc., pentru o conducere eficientă a afacerilor.

II.3. Macrocomenzi și module

Un element de maximă importanță în dezvoltarea unei aplicații Access îl reprezintă
automatizarea operațiilor efectuate și elaborarea unei interfețe care să faciliteze exploatarea
bazei de date și să eficientizeze acțiunile utili zatorului. Integrarea formularelor,
interogărilor și rapoartelor într -un flux continuu, condus de evenimentele declanșate de

20 utilizator, precum și execuția condiționată a operațiilor trebuie să permită chiar și
neinițiaților în Access o deprindere rapidă a cerințelor aplicației.
Comenzile macro din Access reprezintă o modalitate simplă și eficientă pentru
automatizarea anumitor operații, oferind posibilitatea dezvoltării unor aplicații de o
complexitate sporită fără a solicita cunoștințe de programare în V isual Basic.
Trebuie specificat că macrocomenzile Access sunt diferite de macro -urile
înregistrate din Word sau Excel care se bazează pe generarea automată de către program a
codului VBA pentru o serie de comenzi ale utilizatorului.
Practic, o comandă ma cro reprezintă o acțiune sau o secvența de acțiuni selectate
dintr -o lista prestabilită, ce realizează operațiuni diverse precum deschiderea sau
închiderea formularelor, tipărirea rapoartelor, lansarea în execuție a altor programe,
salvarea înregistrărilor sau executarea unei fraze SQL.
Codul VBA ce răspunde evenimentelor este salvat, importat și exportat împreună cu
obiectele (formulare, rapoarte etc.) conducând la o mai ușoară întreținere a bazei de date.
Și din punct de vedere al securității există unel e dezavantaje: modulele pot fi protejate cu
parolă, pe când comenzile macro nu, iar în cazul conversiei bazei de date în format MDE
macro -urile rămân vulnerabile, putând fi modificate.
Pentru crearea unei noi comenzi macro este necesară p arcurgerea următoa relor
etape:
1. În secțiunea Objects din fereastra bazei de date se selectează eticheta Macros;
2. Se efectuează click pe butonul New;
3. În coloana Action se selectează din lista acțiunea dorită;
4. În coloana Comment se tastează în dreptul fiecărei acțiuni eventuale le explicații.
Aceste comentarii sunt opționale;
5. În grila Action Argument din partea inferioară a ferestrei se completează
argumentele acțiunii selectate. Conținutul grilei de argumente se modifică în funcție de
elementul selectat în lista Action, fiecare acțiune având propriile argumente.
Lansarea în execuție a comenzilor macro se poate face prin una din următoarele
variante:
 lansarea directă în execuție se poate realiza efectuând dublu click pe pictogramă
macrocomenzii dorite în fereastra Database sau se lectând din meni ul Tools – Macro – Run
Macro. În cazul în care se lansează în execuție un grup macro fără să se precizeze comanda
dorită din cadrul acestuia, va fi executată doar prima comandă a grupului.
 executarea prin intermediul unui alt macro se efect eaza selectând în lista de
acțiuni RunMacro. Argumentele acestei acțiuni permit executarea repetitivă a
macrocomenzii de un anumit număr de ori.
 lansarea în execuție ca răspuns la un eveniment se poate realiza atașând o
comandă macro unui obiect, ca răspun s la un eveniment surve nit în desfășurarea
programului . Prin intermediul modelului orientat pe obiecte și dirijat de evnimente putem
declanșa o comandă macro ca răspuns la deschiderea sau închiderea unui formular ori
raport (evenimentul OnLoad), în urma se lectării unui element dintr -o listă derulantă
(evenimentul AfterUpdate) sau a deplasării mouse -ului într -o anumită z onă a ecranului
(OnMouseMove).
Spre deosebire de programele procedurale la care execuția înseamnă parcurgerea
unui traseu bine determinat al instrucțiunilor, în Microsoft Access programarea este dirijată
de evenimente, execuția unei părți din program efectuându -se în funcție de evenimentul ce
intervine asupra unui obiect component al aplicației.
În programarea orientată pe obiecte și dirijată de evenimente, textul sursă este
organizat în proceduri și funcții și este păstrat în module componente ale bazei de date
Microsoft Access.

21 Modulele din Access sunt obiecte ale bazei de date, care permit scrierea de rutine
în limbajul Visual Basic pentru Aplicații (VBA).
În general un modul are următoarea structură:
 declarații
 procedură sau funcție
 ––––––––-
 procedură sau funcție
Fiecare modul conține o zonă de declarații unde sunt declarate variabilele și
constantele accesibile pentru toate procedurile sau funcțiile componente ale modulului și
una sau mai multe proceduri sau funcții.
Modulele se pot clasifica în următoarele categorii:
a) module globale sau standard sunt module ce constituie obiecte distincte în bază
de date, ele incluzând în zonă de declarații variabile și constante, precum și proceduri sau
funcții utilizate sau utilizabile de către orice componența a aplicației;
b) module atașate sunt module create automat la generarea de formulare sau
rapoarte și atașate acestora. Toate dec larațiile, procedurile și funcțiile asociate acestor
module sunt recunoscute numai în cadrul lor. Procedurile pot fi de tip eveniment sau
generale;
c) module clasă reprezintă fundamental programării orientate pe obiect și dirijată de
eveniment incluzând Visua l Basic. Modulele clasă cuprind de obicei proceduri sau funcții
pentru crearea de obiecte noi.
Pentru a crea un modul nou se parcurg următorii pași :
– se selectează opțiunea modules din fereastră bazei de date;
– se activează butonul New.
Pentru a modifica u n modul se selectează modulul dorit și apoi click pe butonul
Design sau dublu -click pe modulul dorit.
Pentru a șterge un modul se selectează modulul și apoi se activează tasta Delete.
Editorul, are de asemenea, facilități de colorare a cuvintelor cheie, declarațiilor
utilizator, frazelor eronate, comentariilor etc.
Cea mai puternică facilitate a editorului VBA este posibilitatea afișării contextuale
în momentul scrierii în VBA a elementelor care caracterizează un anumit context.
Instrucțiuni pentru afiș area și introducerea datelor
Evident, formularele și rapoartele reprezintă o formă elegantă de introducere și
respectiv afișare a datelor care se bazează în principal pe structura bazei de date. În afară
de acestea, există în VBA instrucțiuni pentru intro ducerea unor date izolate și afișarea de
mesaje. Această necesitate se simte mai ales în faza de test a unei proceduri sau funcții, sau
pentru afișarea de mesaje către utilizatorul bazei de date.
InputBox (mesaj, [titlu], [val_implicita], [x], [y], [fisie r_help, context]) permite
introducerea unei secvențe de caractere de la tastatură.
MsgBox ( mesaj, [butoane], [titlu], [fisier_help, context]) permite afișarea unui
mesaj și opțional poate returna o constantă, în funcție de butonul ales de utilizator din
fereastră MsgBox.
Declararea variabilelor în VBA
Variabilele pot fi declarate într -o procedura sau funcție cu ajutorul instrucțiunii:
Dim nume_variabila AS tip_de_data.
VBA acceptă două categorii de tipuri de date:
– standard (predefinite);
– utilizator.
Funcții și proceduri definite de utilizator

22 O funcție/procedură reprezintă un bloc de instrucțiuni care realizează o prelucrare.
Acestea pot fi apelate ori de câte ori este nevoie, fără a mai fi necesară rescrierea lor. În
felul acesta se reduce c onsiderabil efortul de programare. Pentru a da un grad de
generalitate cât mai mare, funcțiile și/sau procedurile conțin în definirea acestora o lista de
parametri formali. În momentul apelării unei funcții și/sau proceduri se transmit către
acestea, nici unul, unul sau mai multe valori pentru fiecare parametru al procedurii sau
funcției.
Sintaxa pentru definirea unei proceduri este următoarea:
Private|Public Sub nume_procedura[([ByRef|ByVal] param_1 as
tip_date,…)
[instrucțiuni]
…
[Exit Sub]
…
[instrucțiuni]
End Sub
Unde:
 Private semnifică faptul că procedura poate fi apelată numai din modulul unde a fost
definită;
 Public semnifică faptul că procedura poate fi apelată din orice modul;
 Exit Sub permite ieșirea forțată dintr -o procedură.
Apelul unei proceduri se poate face astfel:
[Call1 nume_procedura[(valoare_pârâm_1,valoare_pârâm_2,…)]
Sintaxa unei funcții este următoarea:
[Private|Public] Function nume_funcție [([ByRef|ByVal] param_1 as
tip_date,…)] [as tip_date]
[instrucțiuni]
[nume_functie=expresie]
…
[Exit Function]
[instrucțiuni]
[nume_functie=expresie]
End Function
Unde:
 Exit Function permite ieșirea forțată dintr -o funcție;
 nume_funcție expresie ce permite asocierea unui rezultat numelui funcției.
Acest rezultat v a fi returnat în momentul terminării execuției funcției.
Apelul unei funcții se poate face astfel:
Variabila = nume_funcție [(valoare_param_1, valoare_param_2, …)]
Pentru a testa o procedura fără parametri direct dintr -un modul, se poziționează
cursor ul în corpul procedurii, apoi se selectează comandă: Run, Run Sub/User Form.
Limbajul VBA cuprinde în plus o serie de funcții predefinite care facilitează
scrierea procedurilor și funcțiilor utilizator:
 Abs( expresie_numerică ): returnează valoarea abso lută a unei expresii
numerice, sau a unui număr;
 Asc( șir_caractere ): returnează codul primului caracter din șirul de caractere
specificat;
 Chr( COD_CARACTER ): returnează caracterul cu codul specificat;
 Date(): Returnează data calendaristică;
 Day( data_ calendaristică ): returnează numărul zilei din lună;

23  Month( data_calendaristică ): returnează numărul lunei din an;
 Year( data_calendaristică ): returnează anul;
 CDate( expresie ): face conversia la tipul Date ;
 CDbl( expresie ): face conversia la tipul Do uble ;
 Dec( expresie ): face conversia la tipul Decimal ;
 Cint( expresie ): face conversia la tipul Integer ;
 CLng( expresie ): face conversia la tipul Long ;
 CSng( expresie ): face conversia la tipul Single;
 CStr( expresie ): face conversia la tipul Strin g ;
 Cos( expresie_numerică ): returnează cosinus dintr -o expresie numerică sau
dintr -un număr. Valoarea returnată este de tip Double ;
 Exp( expresie_numerică ): returnează valoarea constantei e ridicată la o putere
(expresie numerică sau număr) ;
 Log( exp resie_numerică ): returnează logaritm natural dintr -un număr sau dintr –
o expresie numerică ;
 IsDate( expresie ): returnează valoarea adevărat (TRUE) dacă expresia dintre
paranteze este compatibilă cu o data calendaristică ;
 IsEmpty( expresie ): returnează valoarea adevărat (TRUE) dacă expresia dintre
paranteze nu conține o valoare. Null este considerat valoare ;
 IsNumeric( expresie ): returnează valoarea adevărat (TRUE) dacă expresia
dintre paranteze poate fi evaluată că număr ;
 IsObject( expresie ): return ează valoarea adevărat (TRUE) dacă identificatorul
dintre paranteze este de tip obiect ;
 IsError( expresie ): returnează valoarea adevărat (TRUE) dacă expresia dintre
paranteze conține o eroare ;
 Len( șir_caractere/variabila ): returnează numărul de caract ere ale șirului de
caractere specificat sau numărul de octeți necesari pentru a stoca conținutul
unei variabile ;
 Space( număr): returnează numărul de spații specificate ;
 Str(expresie_numerică): convertește rezultatul evaluării expresiei numerice
dintre p aranteze într -un șir de caractere ;
 Val(șir_caractere): returnează rezultatul evaluării șirului de caractere specificat,
într-un număr ;
 Mid((șir_caractere, poziție_start[, lungimea])): extrage un șir de caractere dintr –
un alt șir de caractere.

24 II. Prezentar ea aplicației ”Bază de date pentru evidența
operațiunilor prin casierie”

I.1. Operațiuni efectuate prin casierie

Casierie reprezintă serviciu într -o întreprindere/instituție care efectuează încasările
și plățile.
Operațiunile de încasări și plăți în num erar, la nivelul unei instituții/firme, se
efectutează de casier și, în anumite cazuri extreme de către persoanele împuternicite de
conducătorul unității.
Operaț iunile efectuate prin casierie sunt se desfășoară în conformitate cu
reglementările în vigoare, și anume:
– Legea contabilității nr. 82/1991 republicată;
– Ordinul privind registrele și formularele financiar -contabile (include și
Monitorul Oficial al României, Partea I, nr. 23 bis) nr. 1850/2004, M.Of. 23
din 7 ianuarie 2005, M.Of. 23 bis din 7 ianuarie 2005;
– Norme de utilizare a registrelor de contabilitate REGISTRU JURNAL (Cod
1411 si cod 1411/b) 704/1993, M.O. 303/1993
În cadrul instituți ei noastre activitatea de casierie este organizată, astfel încât
încasările și plă țile în numerar să se desfășoare în codiții de siguranță, cu respectarea
dispozițiilor legale în vigoare și în limita plafonului de casă stabilit. La decontarea sumelor
în numerar, Trezoreria unde firma are deschise conturile, verifică existeța bugetului d e
venituri și cheltuieli și lista de investiții, aprobate în codițiile legii, respectarea limitelor
creditelor bugetare deschise și destinația acestora. Din conturile de disponibilități se pot
elibera sume pentru efectuarea de plăți în numerar, reprezentân d drepturi salariale și alte
cheltuieli care nu se justifică a fi efectuate prin virament.
În cadrul Direcției Financiare -Contabile, lunar, sunt dimensionate plățile pe care
urmează să le efectueze în numerar prin casierie , pentru care întocmește o program are
(Anexa nr. 1 ). Aceasta este depusă la trezorerie până la data de 25 ale lunii pentru luna
următoare.
Operațiile de încasări și plăți în numerar se efectuează de casieri. Aceștia sunt
gestionari de mijloace bănești și alte valori. Agajarea gestionarilor , constituirea de garanții
și răspunderea în legătură cu gestionarea bnunurilor se face conform prevederilor Legii nr.
22/1969, completată de Legea nr. 54/1994. Casierul nu poate încredința exercitarea
atribuțiilor sale altor persoane fără înștiințarea con ducerii istituției. Când casierul lipsește,
iar operațiile de casă nu pot fi întrerupte, acestea se vor face de perosana desemnată de
casier, cu acordul conducerii instituției. Când casierul nu desemnează o persoană sau cânnd
conducerea nu este de acord cu persoana desemnată, operațiile vor fi făcute de o persoană
delegată de conducerea instituției , fără a depăși 60 de zile. La expirarea termenului se
procedează la predarea -primirea gestiunii. La operațiile făcute de persoana delegată are
dreptul să asiste și persoana desemnată de casier.
Documentele contabile utilizate în administrarea casieriei , sunt:
 Registrul de casă;
 Dispoziția de încasare -plată;
 Cecul în numerar

25  Chitanța;
 Factura fiscală.
Registrul de casă (Anexa nr. 6)
– Este documentul in care se inregistreaza zilnic incasarile si platile in numerar
efectuate prin casieria unitatii;
– Se intocmeste un registru pentru lei si cate unul separat pentru fiecare valuta cu
care se lucreaza.
– La sfarsit de zi se stabileste soldul de casa .
– Soldul de la sfarsitul zilei se preia ca sold initial la inceputul zilei urmatoare.
– Se poate intocmi manual sau electronic.
– Se intocmeste in 2 exemplare.
– Se semnează de către casier pentru confirmarea înregistrării operațiunilor efectuate
și de către persoana din compartimentul financiar -contabil desemnată pentru
primirea exemplarului 2 și a actelor justificative anexate. Exemplarul 1 rămâne la
casier.
Dispoziția de încasare/platã (Anexa nr. 2). Acest document este:
– o dispoziție pentru casierie, în vederea achitării în numerar a unor sume, potrivit
dispozițiilor legale, inclusiv a avansurilor aprobate pentru cheltuieli de deplasare,
precum și a diferenței de încasat de către titularul de avans în cazul justificării unor
sume mai mari decât avansul primit, pentru procurare de mater iale etc.;
– dispoziție pentru casierie, în vederea încasării în numerar a unor sume care nu
reprezintă venituri din activitatea de exploatare, potrivit dispozițiilor legale;
– document justificativ de înregistrare în registrul de casă și în contabilitate, în cazul
plăților în numerar efectuate fără alt document justificativ
Se semnează de întocmire la compartimentul financiar -contabil.
Se trimite la casierie, pentru efectuarea operațiunii de încasare sau plată, după caz,
și se semnează de casier; în cazul plăț ilor se semnează și de către persoana care a primit
suma.
Cecul în numerar (Anexa nr. 3) se întocmește pentru:
– achitarea unor drepturi bănești pentru cursanții instituției;
– plata sumelor reprezetând avansuri pentru achiziția de bunuri, servcii prestate;
– deplasări în țară și în străinătate a persoanelor fizice aflate în raporturi de muncă
sau studii cu instituția;
– achitarea obligațiilor către clienți, restituirea de venituri încasate necuvenite;
– alte plăți efectuate conform reglementărilor legale în vigoare.
Cecul în numerar se completează pe suport de hârtie, într -un exemplar din care
cotorul cecului rămâne la plătitor, iar partea detașabilă se depune la Trezorerie Statului
unnde istituția are deschide conturile.
Cecul în nnumerar se completează pe verso, di stinct pentru fiecare tip de obligație
bugetară. Cecul este însoțit de componența cecului, care detaliază operațiunnile de cec
distinct pe tipuri de cheltuieli, surse de finanțare și este oglinda tuturor documentelor de
plată (ștate de plată, dispoziții de plată) care stau la baza întocmirii cecului în numerar.
Chitanța (Anexa nr. 4 și Anexa nr. 5 )
Este un document justificativ pentru depunerea unei sume în numerar la casieria
unității:
– o suma incasata de la un client,
– o restituire a avansului cu ocazia deplasarii, etc.
Se întocmește în două exemplare, pentru fiecare sumă încasată, de către casierul
unității și se semnează de acesta pentru primirea sumei.
Se numerotează în baza unei decizii interne de numerotare, ca și la facturi.

26 Factura fiscala
– servește ca document justificativ pentru cumpararea unor produse, sau prestarea
unor servicii si ca document justificativ de inregistrare in contabilitate. Se
intocmeste de vanzator sau prestator. Factura fiscală trebuie însoțită de chitanța
simplă sau de bon de casă de marcat (dupa caz).

In conformitate cu prevederile Ordonantei nr. 15/1996 privind intarirea disciplinei
financiar -valutare, cu modificarile si completarile ulterioare, se vor respecta urmatoarele:
1. Operatiunile de incasari si plati intre persoanele ju ridice se vor efectua numai prin
instrumente de plata fara numerar. Prin exceptie de la aceste prevederi, persoanele
juridice pot efectua plati in numerar in urmatoarele cazuri:
a) plata salariilor si a altor drepturi de personal;
b) alte operatiuni de pl ati ale persoanelor juridice cu persoane fizice;
2. Sumele in numerar aflate in casieriile proprii ale persoanelor juridice nu pot
depasi la sfarsitul fiecarei zile plafonul de 5.000 lei. Se admite depasirea acestui
plafon numai cu sumele aferente platii sala riilor si a altor drepturi de personal,
precum si a altor operatiuni cu persoane fizice, pentru o perioada de 3 zile
lucratoare de la data prevazuta pentru plata acestora. Sumele în numerar care
depasesc nivelul de 2.000 lei, vor fi depuse in conturile de Trezorerie ale
persoanelor juridice respective, astfel:
– în urmatoarea zi lucratoare, dacă sediul persoanei juridice se află în aceeași
localitate cu cel al unității Trezoreriei la care are deschis contul;

Verificarea registrului de casa se efectueaza d e câte ori este cazul, de către
contabil șef.
Aceasta va urmări, în ordinea menționată mai jos, dacă:
– există și sunt corect și complet întocmite toate documentele pe baza cărora s -a
întocmit registrul de casă.
– dacă toate documentele atașate, în special c hitanțele și facturile fiscale emise de
către furnizori conțin toate datele de identificare.
– dacă dispozițiile de plată către casierie sunt semnate de către: casier, persoana care
a ridicat suma, precum și dacă sunt aprobate de director și administrator f inanciar.
– dacă registrul de casă este semnat de către casier pentru întocmire.
– dacă reglementarile legale privind plafonul soldului de casă și cel de plați în
numerar au fost respectate.

27 III.2. Prezentarea generală a aplicației

Firma Bsmart SRL are ca obiect de activitate realizarea de cursuri de pregătire și
perfecțion are în domeniul IT și al limbilor străine . Se dorește realizarea unei baze de date
pentru evidența operațiilor realizate în lei în cadrul casieriei.
Zilnic se va realiza registrul de cas ăce va conține:
– data realizării operației ;
– explicația operației ;
– suma operației și tipul operației (încasare sau plată);
– numărul și tipul documentului (cec numerar, chi tanță, foaie de văsamânt,
dispoziție de plată sau încasare, state de salarii, etc.)
Regi strul de casă va conține:
– soldul inițial al zilei;
– totalul sumelor încasate ;
– totalul sumelor plătite ;
– soldul final al zilei.
Fiecare operație înregistrată în baza de date va primi un număr unic folosit la
identificare.
Încasările pot să provină din vânzar ea serviciilor proprii (taxele cursanților ce
participă la cursurile de limbi străine) sau ridicări de numerar de la bancă, aport de capital.
Plățile se pot face prin achitarea drepturilor salariale, avansuri spre decontare, cumpărări de
bunuri, depuneri d e numerar la bancă. Operațiile sunt grupate pe categorii în funcție de
sursa acestora, reținându -se pentru fiecare operație codul categoriei , denumirea acesteia și
tipul.
Principalele categorii de operații sunt taxa cursanți, ridicare numerar bancă, aport
capital, achitare drepturi salariale, avans spre decontare, cumpărare buniri, depunere de
numerar la bancă, la care pot fi adăugate ulterior (în timpul exploatării bazei de date) și alte
plăți sau încasări.
O categorie specială de operații o reprezintă ava nsurile spre decontare. Acestea
trebuie să fie justificate prin intermediul unor documente în cadrul deconturilor de
cheltuieli. Pentru fiecare decont de cheltuieli este necesară reținerea numărului și datei
acestuia, a documentelor ( număr , data, suma , tip) ce justifică cheltuiala avansului precum
și a datelor titularului avansului. D e avansuri spre decontare pot benneficia salariații firmei.
Datele fiecărui salariat ( nume , dată naștere, adresă ) vor fi înregistrate în cadrul bazei de
date o singură dată, ac esta fiind identificat cu ajutorul mărcii . Avansul neutilizat este
restituit la casierie pe baza documentului de încasare. Documentele justificate pentru
avansuri se vor scana și se vor arhiva.

Reguli de gestiune
 O operație este încadrată într -o singură c ategorie, dintr -o categorie putând
face parte mai multe operații;
 Un decont poate presupune mai multe operații prin casierie (ridicare avans
și posibile diferențe), o operație ce poate presupune ridicarea unui avans
sau restituirea diferențelor este înregi strată pe un singur decont;
 Un decont de cheltuieli poate să conțină mai multe documente justificative,
un document poate justifica cheltuielile de pe un singur decont.
 Un salariat poate avea mai multe deconturi, un decont aparținând unui
singur angajat.

28 Realizarea modelului relațional al bazei de date presupu nne parcurgerea mai
multor etape. Plecând de la informațiile de bază, respectiv atributele și relațiile stabilite
înntre acestea, se realizează succesiv normalizarea bazei de date (FN1, FN2, FN3). Se
stabilesc , în primul rând , atributele elementare și nerepetitive ce vor constitui baza
procesului de normalizare.
Deoarece baza de date va fi realizată cu ajutorul aplicației Microsoft Access 2010,
se vor folosi noile funncționalități ale acesteia și se va defini unn câmp denumit
FișierDcoument în care se va reține copia documentului justificativ.
Pe baza analizei cerințelor funcționale ale bazei de date se identifică următorul
dicționar preliminar al datelor:
NrOperatie, DataOperatiei, ExplicațieOperatie, SumaOperatie, TipOperatie,
NrDocument, TipDocument, CodCategorie, DenCategorie, TipCategorie,
NrDecont, DataDecont, DataDecont, NnrDocJustificativAvans,
DataDocJustificativAvans, SumaDocJustificativAvans, TipDocJustificativAvans,
NnumeSalariat, MarcaSalari at, DataNastereSalariat, AdresaSalariat,
FisierDocument, TotalIncasariZilnice, TotalPlatiZilnice, SoldFinalZilnic,
SoldInitialZilnic.
Prin respectarea cerințelor impuse de forma nnormalizată 1 (FN1), din dicționarul
atributelor se vor elimina atributele ca lculate și anume:
 TotalIncasariZilnice se calculează prin însumarea sumelor încasate zilnic;
 TotalPlatiZilnice obținute prin însumarea plăților zilnice;
 SoldFinalZilnic obținute prin diferența încasărilor și a plăților zilnnice la care
se adaugă soldul inn ițial;
 SoldInitialZilnic fiinnd de fapt soldul final al zilei precedente;
 TipOperatie are aceleași valori ca și TpCategorie , respectiv încasare sau plată.
Am optat pentru eliminarea atributului TipOperatie deoarece operația este
inclusă într -o altă categor ie, tipul fiind același cu cel al categoriei din care face
parte.
Respectând cerințele impuse cheilor primare (unicitate, ireductibilitate) se
identifică, în cadrul dicționarului atributelor, următoarele atribute candidat:
AtributCandidat Descriere
NrOper atie Acest atribut are valori unice, identificând înn mod unnic o
operație.
NrDecont Fiecare decont este numerotat în mod unic.
CodCategorie Acest atribut are valori unice, identificând în mod unic o valoare.
NnrDocJustificativ,
TipDocJustificativ Pot e xista mai multe tipuri de documente justificative, nmerele
fiind unice înn cadrul acestor tipuri.
MarcaSalariat Reprezintă atributul pe baza căruia este identificat un salariat.

Următoarea etapă î n cadrul normalizării o reprezintă identificarea depende nțelor
funncționale. Este recomandat ca din mulțimea dependențelor funncționale să se rețină
doar cele în care determinatul este cheie primară.
La înregistrarea unei operații i se atribuie un număr unic existând dependențe
funncționale între atributul NrOp eratie și atributele ExplicatieOperatie , SumaOperatie ,
NrDocument , TipDocument . Deoarece o operație este înncadrată într -o singură categorie,
există dependențe funncționale între atributul NrOperatie și atributele CodCategorie ,
DenCategorie , TipCategorie . O operație este înregistrată doar pe un singur decont,
existând dependențe funcționale între atributul NrOperatie și atributele NrDecont ,
DataDecont .

29 O operație de tipul acordare de avanns sau restituire diferențe se realizează pentru
un singur salariat, e xistând o dependență funcțională între atributul NrOperatie și atributul
MarcaSalariat și dependențe funcționale tranzitive între atributul NrOperatie și atributele
NumeSalariat , DataNastereSalariat , AdresaSalariat .
Fiecare decont este numerotat în mod u nic, atributul NrDecont implicâ nd
funncțion al atributu l DataDecont . Pentru că un deco nt aparține u nui singur angajat, există
dependențe funcționale între atrib utul NrDecont și atributele Num eSalariat , MarcaSalariat ,
NumeSalariat , DataNastereSalariat , AdresaS alariat .

Figură 3. 1. Depe ndențele funcționale din cadrul bazei de date

Un document poate justifica cheltuielile de pe unn singur decont, acest lucru
generând dependențe funcționale totale între grupul de atribute NrDocJus tificativ ,
TipDocJustificativ și atributele NrDecont , DataDecont . Pentru fiecare documennt trebuie
memorate data, suma și fișierul ce conține arhiva electronică existând dependențe

30 funncționnale totale nnîntre grupul de atribute NrDocJustificativ , TipDocJu stificativ și
atributele DataDocJustificativ , SumaDocJustificativ , FisierDocument .
În figura 3.1. sunt ilustrate depe ndențele funcționale din cadrul bazei de date.
Analizând aceste depedențe se observă existența depenndențelor funcționale trannzitive.
Prin eliminarea acestora se obțin tabelele ce respectă forma normală trei.
Categorie (CodCategorie , DenCategorie, TipCategorie)
Salariat (MarcaSalariat , NumeSalariat, AdresaSalariat, DataNastereSalariat)
Decont (NrDecont , DataDecont, MarcaSalariat )
Operatie (NrOperatie , DataOperatiei, SumaOperatie, ExplicatieOperatie,
NrDocument, TipDocument, NrDecont , CodCategorie )
DocumentJustificativ (NrDocumentJustificativ, TipDocumentJustificativ ,
DataDocumentJustificativ, SumaDocumentJustificativ,
NrDecont , CodCategorie)
Implementarea în Microsoft Access 2010 a tabelelor și a relațiilor di intre acestea
este prezetată în figura 3.2.

Figură 3. 2. Implementarea tabelelor aplicației și a relațiilor tabelelor în M. Access 2010
Pentru tabela Categorie se vor stabili următoarele proprietăți:
 CodCategorie este atribut cheie primară, de tip
AutoNumber -Increment;
 Tipul categoriei, TipCategorie , va putea să aibă
doar două valori „încasare” sau „plată”, valori
ce se vor alege dinntr -o listă derulantă.
Pentr u realizarea listei derulante ce va conți ne
valorile încasa re și plată, se va folosi proprietatea
Lookup Wizard a câmpului TipCategorie din tabelul
Categorie (Figura 3.3.) . În cadrul ferestr ei Lookup
Wizard se alege opțiu nea „ I will type in the values that
I want ”, iar în cadrul etapelor ulterioare se introduc
valorile Încasare și Plată.
Figură 3. 3. Proprietatea Lookup Wizard
a câmpului TipCategorie

31

Figură 3. 4. Fereastra Lookup Wizard -stabilirea valor ilor atributului TipCategorie

Angajații vor fi codificați în funcție de departamentul unde lucrează. Marca
angajatului va fi alcătuită din 5 caractere , primele 2 fiind codul compartimentului, iar
ultimele 3 reprezintă numărul angajatului în cadrul depart amentului. De exemplu,
anngajatul cu marca CO005 lucrează la departamentul contabilitate. Se realizează un
șablon de introducere a mărcii angajatului în câmpul MarcaAngajat în acest format cu
ajutorul pro prietății Input Mask (Figura 3.5 .); pentru caractere le obligatorii alfabetice se
folosește simbolul „L”, iar penntru cele nnumerice obligatorii se folosește caracterul „0”.

Figură 3. 5. Realizarea formatului de introducere a mărcii angajatului

Pentru tabela Operatie se vor stabi li următoarele proprietăți:
 Valoarea implicită pentru DataOperatie este data curentă (Figura 3.6.).
Pentru aceasta, proprietății Default Value a câmpului DataOperatie i se va atribui
funcția =Date().
 Suma operației va avea valori cuprinse între 0 și 1000.
Pentru a restricționa valorile câmpului SumaOperatiei se va folosi proprietatea
Validation Rule asociată acestui câmp di n tabelul Operatie. Realizarea acestei
restricții referitoare la domenniul de valori acceptate de atributul SumaOperatie
presupune atr ibuirea valorii „betwee n 0 and 1000” proprietății Validation Rule.
Proprietatea Validation Text va conț ine mesajul presonalizat de er oare afișat în
cazul nerespectării condiției impusă prin Validation Rule. (Figura 3.7)

32

Figură 3. 6. Valoarea implicită pentru Figură 3. 7. Regula de validare pentru
atributul DataOperatie atributul SumaOperatie

 Tipul documentului va putea să ia valorile prestabilite DP, DI, C, FV, StatSalarii ce
se vor alege dintr -o lis tă derulantă. (DP pentru dispoziție de plată, DI penntru
dispoziție de înncasare, C pentru chitanță și FV pentru foaie de vărsământ) . Pentru
realizarea acestei liste derulannte se folosește proprietatea Lookup Wizard
atributului TipDocument. (Figura 3.8)

Figură 3. 8. Stabilirea listei derulante pentru atributul TipDocument

33 Pentru extragerea și prelucrarea datelor din baza de date am realizat o serie de
interogări . Așa cum am prezentat în capitolul II, Microsoft Access pune la di spoziția
utilizatorului mai multe tipuri de interogări. Acestea sunt mici prog rame care comandă
extragerea adăugarea sau modificarea datelor dintr -un tabel. Interogările create pot fi
independente sau înglobate în formulare sau rapoarte.
Interogarea 1 . Pentru a afișa în coloane distincte sumele încasate și cele restituite
pentru fiecare di n operațiile din categoriile „Avansuri spre decontare” și „Retur avans spre
decontare” s -a realizat interogarea din figura 3.2.
Am folosit funcția IIF pentru a afișa sumel e încasate (acelea pentru care tipul
operației este încasare) și sumele plătite (acelea pentru care tipul operației este plată). În
cadrul secțiunii Criteria , pentru câmpul DenumireCategorie se vor introduce cele două
condiții „Avansuri spre decontare” și „Retur avans spre decontare” folosind operatorul OR.
(Figura 3.9)

Figură 3. 9. Interogarea 1

Interogarea 2 . Afișarea agajaților care în lunile ianuarie, februarie și martie ale
anului 2016 au justificat sumele totale mai mari d e 200 Ron pe mai puțin de 2 deconturi s -a
realizat cu ajutorul interogării 2 (F igura 3.10).
Penntru conndiția impusă datei decontului s -a folosit operatprul BETWEEN. Datele
calendaristice sunt marcate cu ajutorul caracterului „#”.

Figură 3. 10. Interogarea 2

34 Interogarea 3 . Să se afișeze sumele totale aferente operațiilor desfășurate în anul
2016 grupate pe luni și categorii. Se va folosi o interogare de tipul analiză încrucișată
(Crosstab Query). Pentru afișarea în rezultatul cer erii a tuturor lunnilor annului 2016,
numerotate de la 1 la 12, se va folosi proprietatea Column Headings asociată obiectului de
tip interogare (Query). Funcția MONTH se folosește pe ntru extragerea lunii din data
operației. Prin concatenarea tipului și den umirii categoriei folosind operatorul „&” se obțin
valorile unui nou câmp ce va avea eticheta „ Operatie ”. (Figura 3.11)

Figură 3. 11. Interogarea 3

Interogarea 4. Să se afișeze soldurile i nițiale pen tru o annumită zi introdusă ca
parametru.
Soldul inițial unei zile se calculează prin însumarea încasărilor din care se scad
totalul plăților pentru perioada precedenntă zilei introduse ca parametru. Totalul sumelor
încasate se calculează folosinnd funcția agregată SUM și funcția II F astfel ,
SUM(IIF( TipCategorie =”Incasare”, SumaOperatie ,0)). În mod asemănător se calculează
și totalul sumelor plătite. (Figura 3.12)

Figură 3. 12. Interogarea 4

35 Interogarea 5 . Să se afișeze numele și vârsta în ani a aangaja ților care au realizat
deconturi de cheltuieli.
Vârsta angajaților se calculează prin diferența dintre atributele DataNastereSalariat
și data curentă, cu funcția DateDiif astfel, DateDiff("yyyy",[DataNastereSalariat],Date()).
Pentru data curentă se foloseș te predefinită funcția Date(). (Figura 3.13)

Figură 3. 13. Interogarea 5

Interogarea 6 . Afișarea în ordine alfabetică a categoriile de operații ce fac parte
din cadrul unui anumit tip introdus ca parametru în tr-o lista derulant ă CmbTip. Apelarea
parametrului CmbTip din formularul Operatie se face cu expresia:
=[Forms]![Operatie]![CmbTip] .
SELECT CodCategorie, DenumireCategorie
FROM Categorie
WHERE TipCategorie=[Forms]![Operatie]![CmbTip]
ORDER BY TipCategorie;

Interogarea 7 . Pentru a afișa afișa tipurile de categorii de operații , un tip se va
afișa o singură dată, s -a realizat următoarea interegare SQL:
SELECT DISTINCT TipCategorie
FROM Categorie
ORDER BY TipCategorie;

Interogarea 8 . Să se afișeze primele trei documente justifi cative cu cele mai mari
sume. Pentru a afișa doar primele trei documennte se ordonează descrescător înregistrările
în funcție de sumă și se folosește cuvânntul cheie TOP urmat de numărul de înregistrări
dorite.
SELECT TOP 3 *
FROM DocumentJustificativ
ORDE R BY SumaDocJustificativ DESC;

Interogarea 9 . Pentru a afișa numărul de salariați pe fiecare categorie de vârstă s -a
creat următoarea instrucțiune SQL:
SELECT COUNT(MarcaSalariat) AS Nr,
YEAR(Date()) -YEAR([DataNastereSalariat])

36 AS Varsta FROM Salariat
GROUP BY YEAR(Date()) -YEAR([DataNastereSalariat]);

Interogarea 10 . Să se afișeze categoriile de operații pentru fiecare sumă totală
pentru anul 2016 a depășit 500 Ron. Înregistrările se vor ordona în funcție de valoarea
totală. Innstrucțiunea SQL corespunză toare acestei interogări este:
SELECT Categorie.CodCategorie, FIRST(DenumireCategorie) AS Denumire,
SUM(Operatie.SumaOperatiei) as SumaTotala
FROM Categorie INNER JOIN Operatie ON
Categorie.CodCategorie=Operatie.CodCategorie
WHERE YEAR([DataOperatiei])=2 007 GROUP BY Categorie.CodCategorie
HAVING SUM(SumaOperatiei)>500
ORDER BY SUM(SumaOperatiei) DESC;

Interogarea 11 . Să se afișeze totalul sumelor justificate, precum și operațiile
efectuate prin casierie, pentru fiecare decont. Se vor afișa numărul deconn tului, data
acestuia, total sume justificate sau suma operației(coloana denumita Suma), tipul categoriei
operației (pentru sumele totale justificate se va afișa Justicare ), denumirea categoriei din
care face parte operația (pentru sumele totale justificate se va afișa Justificare avans ),
pentru sumele totale justificate și pentru operațiile de tip încasare se va afișa în coloană
separată semnul +1, iar pentru operațiile de tip plată semnul -1. În ultima coloană,
denumită Total , se va afișa produsul dintre s uma totală justificată sau suma operației și
semnnul +1 sau -1.
Penntru reunirea informațiilor din interogări distincte se folosește operatorul UNION.
Numărul de coloanne din fiecare innterogare ce participă la reuniune trebnuie să fie
același.
Prima inter ogare va returna suma totală justificată pe fiecare decont, afișând numărul și
data decontului, suma totală calculată cu ajutorul funcției SUM, tipul operației fiind
„Justificatoare”, coloana Descriere afișând mesajul ”Justificare avans”, semnul este +1, i ar
coloana „Total” se obține prin preluarea valorii sumei totale.
Cea de a doua interogare afișează lista operațiilor participante la decont.
SELECT Decont.NrDecont, FIRST(DataDecont) AS Data,
SUM(SumaDocJust ificativ) AS Suma, 'Justifica toare' AS Tip,
'Justificare avans' AS Descriere, '+1' AS Semn,
SUM(SumaDocJustificativ) AS Total
FROM Decont INNER JOIN DocumentJustificativ ON
Decont.NrDecont=DocumentJustificativ.NrDecont
GROUP BY Decont.NrDecont
UNION
SELECT Decont.NrDecont, DataOperatiei AS Data, Su maOperatiei as Suma,
TipCategorie, DenumireCategorie, IIF(TipCategorie='Incasare','+1',' -1') AS Semn,
[Suma]*[Semn] AS Total
FROM Decont, Categorie, Operatie
WHERE Decont.NrDecont=[Operatie].[NrDecont] AND
Categorie.CodCategorie=[Operatie].[CodCategorie ]
ORDER BY Data;

37 III.3 . Prezentare interfață

Pentru a putea fi utilizată cu usurință baza de date, a fost creată o interfață între
utilizator și baza de date propriu -zisă. La deschiderea aplicației apare fereastra de
întâmpinare (Figura 3.14) care cupri nde și meniul aplicației .

Figură 3. 14. Formularul Casierie – fereastra de întâmpinare

Meniul aplicației prezintă patru butoane:
 Actualizări
 Căutări;
 Rapoarte;
 Părăsire aplicație.
Prin acționarea butonului Actualizări se deschi de formularul cu același nume care
oferă posibilitatea utilizatorului să actualizeze informațiile din tabele. (Figura 3.15)

Figură 3. 15. Formularul Actualizări

38 Pentru actualizarea deconturilor de cheltuieli, a avansurilor spre decontare și a
documentelor justificative a fost creat formularul Decont cu subformularele
AvansuriD econtare și DocumetJustificativ . (Figura 3.16)
Formularul principal va avea ca sursă tabela Decont , subformularul
AvansuriDecontare va avea ca sursă interog area Interogarea 1 , prezetată la subcapitolul
III.2 (Figura 3.9.) , iar subformularul DocumentJustificativ va avea ca sursă tabela cu
același nume. Legătura dintre formular și cele două subformulare se va realiza pri n
inntermediul atributului NrDecont .

Figură 3. 16. Formularul Decont pentru actualizarea deconturilor de cheltuieli

În cadrul formularului principal se va afișa NrDecont, DataDecont, Salariat și
situația totală a deconturilor: Suma avans, Suma justificat și diferența de încasat/restituit.
În cadrul subformularelor se vor afișa totalurile avansurilor fără restituiri și, respectiv ,
sumele justificate. Calculul avansului total fără sumele restituite se realizează în cadrul
secțiun ii Form Foot er a subformularului Ava nsDeco nntare cu ajutorul unei casete text
(Figura 3.17). Pentr u acest control, proprietatea Name va avea valoatea txtSuma .

Figură 3. 17. Calculul avansului total fără sumele restituite dinn subformularul
AvansDecon tare

39 Pentru calcul ul totalului sumelor justificative se va folosi un control de tip caseta
(TextBox) pentru care valoarea Control Source va fi =Sum([SumaDocJustificativ]) , iar
valoarea proprietății Name va fi txtSumaJustificată .
În cadrul formularului principal se vor prel ua valorile celor două controale txtSuma
și txtSumaJustificată făcându -se referire la nnumele subformularelor din care provin.
Conntroalele formularului principal care vor prelua sumele totale date ca avans și cele
justificate vor avea proprietatea Name eg ală cu txtSAvans și txtSJustificata. Afișarea
mesajului „diferență de înncasat” sau „diferență de restituit” se realizează cu ajutorul
funcției IIF, valoarea proprietății Control Source a conntrolului casetă text ce va afișa acest
mesaj va fi = IIf([txtSAv ans] – [txtSJustificata] > 0, ”Diferență de restituit”, ”Diferență de
încasat” ).
Pentru calculul sumelor ce trebuiesc restituite sau încasate se va folosi funcția IIF.
Controlul de tip casetă text va avea proprietatea ControlSource egală cu
=IIf([txtSAvan s] – [txtSJustificata] > 0, [txtSAvans] – [txtSJustificata], – [txtSAvans] +
[txtSJustificata])
Formularul pentru actualizarea deconturilor de cheltuieli în modul de proiectare
este prezentat în figura 3. 18.

Figură 3. 18. Formul arul Decont în modul de vizualizare pentru proiectare

Pentru actualizarea deconturilor de cheltuieli se folosesc butoanele aflate în partea
superi oară a formularului:
pentru a introduce un nou decont;
penntru ștergerea unui decont;
pentru salvarea m odificărilor;
butoane de navigare la prim a/anterioara / următoarea/ultima
înregistrare.
Părăsirea formular ului Decont se realizează cu ajuto rul butonului
.

40 Actualizarea tabelei salariat se realizează prin intermediul formularului
Nomenclator Salariați (Figura 3.19) care se deschide prin acționarea butonului Salariați .
Evenimentul butonului Salariați este:

Private Sub Command2_Click()
On Error GoTo Command2_Click_Err
DoCmd.OpenForm "Salariat", acNormal, "", "", , acNormal

Command2_Click_Exit:
Exit Sub

Command2_Click_Err:
MsgBox Error$
Resume Command2_Click_Exit
End Sub

Figură 3. 19. Formularul Nomenclator Salariați

Pentru realizarea acestui formular s -a utilizat opțiunea Form Wizard din cadrul
grupului de buto ane Forms din meniul Create. Sursa acestui formul ar o constituie tabelul
Salariat , iar așezarea înregistr ărilor în formular este pe coloane .
În cadrul acestui formular salariații pot fi căutați cu ajutorul listei derulante
Marca Salariat , crea tă cu obiect ul CamboBox înn modul de proiectare Designn View.
Pentru a introduce un nou salariat în baza de date se acționează butonul
Add Record,
care are asociat următorul eveniment:
Private Sub Command12_Click()
On Error GoTo Command12_Click_Err
On Error Resume Next
DoCmd.GoToRecord , "", acNewRec
If (MacroError <> 0) Then

41 Beep
MsgBox MacroError.Description, vbOKOnly, ""
End If
Command12_Click_Exit:
Exit Sub
Command12_Click_Err:
MsgBox Error$
Resume Command12_Click_Exit
End Sub

Deplasarea de la un salariat la altul , ștergerea u nui angajat și reactualizarea
salariaților din baza de date se face cu butoanele de navigare
, Delete
Record
, respectiv Refresh
.
Formularul Nomenclator Salariați se inchide prin acționarea butonu lui Inchide
formularul care are asociat următorul eveniment:
Private Sub Command9_Click()
On Error GoTo Command9_Click_Err
DoCmd.Close , ""
Command9_Click_Exit:
Exit Sub
Command9_Click_Err:
MsgBox Error$
Resume Command9_Click_Exit
End Sub

Actualizarea înregistrărilor din tabela Operatie se realizează prin intermediul
formularului Operatie (Figura 3.20). S -a realizat un control de tip listă derulantă ce
permite alegerea tipului de operație (încasare sau plată). Proprietatea Name a acestui
control are valoarea CmbTip . În funcție de tipul operației se va alege o categorie:
 Pentru Încasare se pot alege vânzarea de servicii proprii, ridicări de numerar
de la bancă, aport de capital sau alte încasări;
 Pentru Plată se poate alege achitarea drepturi lor salariale, avansuri spre
deconntare, cumpărări de bunnucri, depunnere de numerar la bancă sau alte
plăți.
Pentru selecția categoriei se va reali za o listă derulantă, CmbCategorie , ce va avea
ca sursă interogarea:
SELECT CodCategorie, DenumireCategorie
FROM Categorie
WHERE TipCategorie=[Forms]![Operatie]![CmbTip]
ORDER BY TipCategorie;
Această interogare afișează în ordine alfabetică categoriile de operații ce fac parte
din cadrul unui anumit tip introdus ca parametru în lista derulantă CmbTip .
Penntru actualizarea valorilor controlului CmbCategoriedupă actualizarea valorilor
CmbTip se va folosi procedura următoare înn ncadrul evennimentului After Update asociat
conntrolului CmbTip .

Private Sub CmbTip_AfterUpdate()
Me.CmbCategorie.Requery
End Sub

42

Figură 3. 20. Formularul Operație

Pentru afișarea rapoartelor utilizăm meniul Rapoarte care se deschide prin
acționarea butonului cu același nume. (Figura 3.21)

Figură 3. 21. Meniul Rapoarte

Registrul de casă va preze nta situația zilnică a operațiilor realizate pri n casierie
între a numite date introduse ca parametru. Se vor afișa, pe ntru fiecare dată calendaristică ,
soldul inițial (soldul final al zilei precedente), operațiile efectuate înn nacea zi (număr și tip
document), sumele încasate, respectiv plătite, precum și soldul final al zilei. (Figura 3.23)

43 Sursa acestui raport o constituie Interogarea 13, care afișează lista operațiilor
realizate între anumite date introduse ca parametru, evidențindu -se în co loane distincte
sumele plătite și cele încasate.

SELECT NrOperatie, DataOperatiei, ExplicatieOperatie,
[TipDcoument]&[NrDocument] AS Document,
IIF([TipCategorie]="Incasare", [SumaOperatiei], 0) AS Incasare,
IIF([TipCategorie]="Plata", [SumaOperatiei],0 ) AS Plata
FROM Categorie INNER JOIN Operatie ON
Categorie.CodCategorie=Operatie.CodCategorie
WHERE Operatie.DataOperatiei Between [Data inceput] AND [Data sfarsit]
ORDER BY Operatie.DataOperatiei;
În cadrul raportului se fac următoarele setări:
 se vor g rupa înregist rările pe zile, data operației fii nd câmpul de grupare.
 Totalul încasărilor zilnice se va calcula în cadrul secțiunii DataOperatie Footer cu
ajutorul unui control de tip casetă text pentru care proprietatea ControlSource va avea
valoarea =Sum (Incasare). În același fel se va proceda și pentru calculul Totalul
plăților zilnice .
 Soldul final al zilei se calculează astfel =Sum(Incasare-Plata+txtSI), unde txtSI
este numele controlului casetă text în care s -a afișat valoarea soldului inițial zilei.
Raportul Registru casă vizualizat în modul de proiectare este prezentat în figura
3.22.

Figură 3. 22. Raportul Registru casă vizualizat în modul de proiectare

Penntru aflarea soldului innițial al unnei anumite zile se r ealizează o funcție în
cadrul unnui modul VBA. Funcția va avea ca argument data pentru care se dorește
calcularea soldului innițial. În cadrul acestei funncții se va defini o variabilă de tip
QueryDef care va corespunde interogării 4, prezen tată în subcapi tolul III.2 . O variabilă de
tip Recordset se va definni pentru a se face referire la obiectul Recordset atașat obiectului
QueryDef ” Interogare4 ”. În formular soldul innițial al unnei zile este afișat c u ajutorul unei
casete text am plasate în ncadrul secțiu nii DataOperatie Header pentru care valoarea
Conntrol Source este =SoldInitial( DataOperatiei ).

Public Function SoldInitial(data As Date) As Double
se declara o variabilă de tip QueryDef
Dim q As QueryDef

44 se innițializează variabila de tip QueryDef cu obiectul de tip interogare
SolduriInitiale
Set q = CurrentDb.QueryDefs("Interogare4")
se atribuie valori pentru parametrii interogării
q.Parameters(0) = data
se declara o variabila de tip Recordset
Dim rs As Recordset
se initializeaza obiectul de tip R ecordset asociat innterogării
Set rs = q.OpenRecordset
If Not rs.EOF Then
daca exista inregistrari ce corespund cerintelor, functia va returna valoarea
atributului Soldzi
SoldInitial = Nz(rs("SoldZi"))
Else
daca nu exista inregistrari ce corespunnd ceri ntelor, functia va returna valoarea 0.
SoldInitial = 0
End If
End Function

Figură 3. 23. Raportul Registru casă

Situația decontărilor pe salariați este afișată de raportul Situație decontări . Se
afișează pe fiecare decont avans urile, retururile, precum și sumele justificate și diferențele
de încasat sau restituit. (Figura 3.24) .

45

Figură 3. 24. Raportul Situație decontări

Sursa acestui raport o connstituie interogarea11 rezolvată înn subcapitolul III.2 .
Înregistrările se vor grupa înn funcție de numărul decontului. In cadrul secțiunii NrDeconnt
Header se va afișa diferența de plătit sau încasat prin însumarea valorilor câmpului Total
din interogarea sursă a raporului (Figura 3.25). Câmpul Total nnu se v a afișa în cadrul
raportului, valoarea proprietății Visible fiind False .

Figură 3. 25. Raportul Situație decontări în modul de vizualizare proiectare

Părăs irea aplicației se realizează prin acționarea butonului Părăsire aplicaț ie din
formularul Casierie .

46 Concluzii

Complexitatea mereu crescândă a vieții moderne determină ca în cvasitotalitatea
ramurilor de activitate economică și socială să fie tot mai pregnantă necesitatea introducerii
unor mijloace economice rapide, moderne , eficiente și fiabile care să clasifice, să stocheze,
să prelucreze date și să informeze prompt pe utilizatori.
În final, după elaborarea acestei lucrări, se pot desprinde câteva concluzii:
– baza de date creată oferă avantajul utilizării unei unelte sigu re și precise pentru
introducerea și proc esarea datelor dintr -o casierie .
– ținând cont de cele arătate mai sus și de faptul că pe măsura trece rii timpului
volumul de date crește, este evident ă necesitatea unei aplicații informatice care să faciliteze
munc a casierilor ;
– tehnica de calcul și tehnica de teleprelucrare pot înlocui cu succes, acolo unde este
cazul, munca manuală mai puțin productivă.
Aplicația Aplicația “ Bază de date pentru evidența operațiunilor efectuate prin
casierie ”, realizată cu programu l Microsoft Office Access 2010 , cuprinde următoarele
obiective:
 tabele, în care se stochează datele;
 interogări, prin intermediul cărora se extrag datele;
 formulare, cu ajutorul cărora se introduc datele, dar permit și căutarea și
vizualizarea datelor;
 rapoarte, care sunt folosite pentru a afișa situații cu privire registrul de casă,
decontările salariaților ș.a.
În urma realizării acestei aplicații informatice se pune problema eficienței
economice a soluției propuse, eficiența reprezentând obiectivul princ ipal al oricărui sistem
informatic. Eficiența reprezintă raportul dintre efecte economice și resurse economice.
Aplicația i nformatică gestionează operațiile de încasări și plăți în numerar la o
firmă are ca obiect de activitate realizarea de cursuri de pre gătire și perfecționare în
domeniul IT și al limbilor străine
Avantaj ele utilizării aplicației :
 eliminarea erorilor de calcul;
 efectuarea de calcule complexe într -un timp scurt prin studiul rapoartelor
obținute;
 regăsirea rapidă a informațiilor prin folos irea filtrelor pentru selectarea
înregistrărilor care respectă anumite criterii;
 import de date;
 export de date;
 calcul automat al mediilor, creditelor etc.;
 mobilitate – poate rula pe orice calculator care are ca sistem de operare
Windows și suita Office.
Din cele arătate mai sus se poate trage concluzia că implementarea și întreținerea
aplicației informatice se realizează cu niște costuri mai mici sau cel puțin egale decât în
cazul metodei utilizate în prezent având avantajele arătate mai sus.
Aplicația i nformatică realizată ar putea fi inclusă în cadrul sistemului informațional
și ar reuși în timp real să asigure culegerea, verificarea, stocarea, transmiterea și

47 prelucrarea automată a datelor. Acesta ar imprima valențe sporite sistemului informațional,
atât sub aspect cantitativ cât și calitativ printr -o creștere a capacității de calcul sub aspectul
volumului datelor prelucrate și a operațiilor efectuate, creșterea exactității informațiilor,
sporirea complexității situațiilor de informare -raportare, cuanti ficarea rezultatelor.

48 Bibliografie

[1.] Aleca, O., Geambașu, C., Mangiuc, D., Rădulescu, C., Oancea, M., Mihai, F.,
„Baze de date Access 2007” , Editura Informega, București 2009
[2.] Dușmănescu, D., Baze de date , Editura Universitărții din Ploiești, 2005
[3.] Florescu , V., Năstase, P., Berbec, F., Baze de date -fundamente teoretice si
practice , Editura Infomega, București 2002
[4.] Iatan, I., Curs de Access 2010 cu aplicații , Editura Matrix Rom, ISBN:
9789737556370, București, 2010
[5.] Mariana Pațiru, Ionuț pațiru, Irina Pațiru "Informatica -manual pentru clasa a
XII-a" editura L&S Infomat, București, 2002.
[6.] Lungu, I., Bodea, C., Bădescu, G., Ioniță, C., Baze de date – organizare,
proiectare , implementare , Ed. All, București, 1995
[7.] Oprea, D., Analiza și proiectarea sistemelor inform aționale economice , Editura
Polirom, Iași, 1999
[8.] Popa, Gh., Iliescu, M., Udrică, M., Vasilciuc, B., Baze de date Access culegere
de probleme, Editura Cison, București 2006
[9.] Surcel, T., Marșanu, R., Pocaliu, P., Reveiu, A., Alecu, F., Bologa, R.,
Tehnologii W eb și baze de date , http://www.ase.ro/biblioteca/
[10.] Velicanu, M., Lungu, I., Muntean, M., Ionescu, S., Sisteme de baze de date ,
Editura Petrion, București, 2003.
[11.] Nastase,P. Baze de date, Micr osoft Access 2000 , Ed Teora, 2000
[12.] Patrascu, A., Tanasescu, A., Dusmanesc, D., „ Baze de date. MS -ACCESS. Teorie
și aplicații ”, ED Universitatii din Ploiesti, 2006
[13.] Velicanu, M., Lungu, I., Muntean, M., Ionescu, S., Sisteme de baze de date ,
Editura Petrion, B ucurești, 2003.
[14.] Vasilescu, R., Sisteme informatice de contabilitate, Editura Eurostampa , ISBN
978-973-687-710-0, Timișoara, 2008
http://evanngeli ne.weebly.com/uploads/5/2/1/6/5216671/sisteme_informatice_de
_contabilitate.pdf
[15.] Zaharia, M., Oprea, C., Informatică managerială, Editura Universitară București,
2010.

49 Anexa 1

50 Anexa 2

51 Anexa 3

52 Anexa 4

Anexa 5

53 Anexa 6