Note de Curs Si Aplicatii

Note de curs şi aplicaţii 7
CUPRINS
PARTEA ÎNTÂI
1. Bazele de date – instrument util pentru gestionarea unui volum

mare de date .............................................................................................. 11
1.1 Noţiuni fundamentale .................................................................... 11
1.2 Cuplul informaţie-decizie într-o economie sistemică ................. 13
1.3 Aspecte generale privind bazele de date ..................................... 15
1.4 Arhitectura unei baze de date........................................................ 18
1.4.1 Independenţa datelor ............................................................. 18
1.4.2 Nivele de abstractizare a datelor ........................................... 19
1.4.3 Modelarea datelor la nivel conceptual ................................... 21
1.5 Etape în evoluţia bazelor de date .................................................. 27
1.5.1 Etapele 1 şi 2 ......................................................................... 27
1.5.2 Etapele 3 şi 4 ......................................................................... 29
1.5.3 Tendinţe în dezvoltarea bazelor de date ............................... 30
1.6 Sisteme de gestiune a bazelor de date ......................................... 31
1.6.1 Avantajele utilizării SGBD-urilor ............................................. 32
1.6.2 Funcţia de administrare a bazelor de date............................. 33
1.7 MS-Access – un SGDB modern..................................................... 34
1.7.1 MS-Access – componentă Microsoft Office ........................... 34
1.7.2 Instalare şi lansare ................................................................. 36
1.7.3 Interfaţa şi moduri de lucru .................................................... 38
2. Obiecte MS-Access. Creare, utilizare, proprietăţi ................................ 41

2.1 Tabele .............................................................................................. 42
2.1.1 Tipuri de date ......................................................................... 43
2.1.2 Exemplu ................................................................................. 49
8 Sisteme de gestiune a bazelor de date
2.2 Cheia primară. Utilitarul LookUp Wizard ...................................... 52

2.2.1 Noţiunea de cheie primară ..................................................... 52
2.2.2 Exemplu ................................................................................. 52
2.2.3 Afişarea datelor dintr-o listă folosind Lookup Wizard ............ 55
2.2.4 Exemplu ................................................................................. 55
2.2.5 Lookup Wizard folosind un alt tabel ....................................... 58
2.2.6 Exemplu ................................................................................. 60
2.3 Relaţii ............................................................................................... 64
2.3.1 Fereastra Relationships ......................................................... 64
2.3.2 Tipuri de relaţii ....................................................................... 66
2.3.3 Proprietăţile relaţiilor .............................................................. 68
2.4 Interogări ........................................................................................ 72
2.4.1 Interogări de selecţie ............................................................. 75
2.4.2 Exemplu ................................................................................. 78
2.4.3 Interogări de acţiune .............................................................. 84
2.4.4 Exemplu ................................................................................. 86
2.5 Formulare ....................................................................................... 91
2.5.1 Formulare pentru introducerea / vizualizarea datelor ........... 95
2.5.2 Exemplu ................................................................................. 96
2.5.3 Sortarea şi filtrarea datelor în formulare .............................. 108
2.5.4 Exemplu ............................................................................... 109
2.5.5 Formulare tip meniu ............................................................. 110
2.5.6 Exemplu ............................................................................... 111
2.5.7 Diagrame incluse în formulare ............................................. 112
2.5.8 Exemplu ............................................................................... 113
2.6 Rapoarte ....................................................................................... 115
2.6.1 Rapoarte de sinteză ............................................................. 116
2.6.2 Exemplu ............................................................................... 117
2.6.3 Etichete ................................................................................ 122
2.6.4 Exemplu ............................................................................... 123
2.7 Macro-uri ...................................................................................... 125
2.7.1 Rolul macrocomenzilor ........................................................ 125

2.7.2 Exemplu ............................................................................... 127
2.8 Elemente de VBA ......................................................................... 130
2.8.1 Obiecte ................................................................................. 131
2.8.2 Evenimente .......................................................................... 132
2.8.3 Noţiuni de programare ......................................................... 135
2.8.4 Exemplu ............................................................................... 138
PARTEA A DOUA
3. Aplicaţii .................................................................................................... 143

3.1 Consideraţii privind realizarea unui sistem informatic ............. 143
3.1.1 Proiectul director .................................................................. 144
3.1.2 Elemente de analiză şi proiectare ........................................ 146
3.1.3 Documentaţia însoţitoare ..................................................... 148
3.1.4 Principalele etape în realizarea unei aplicaţii ....................... 149
3.2 Efectuarea reducerilor de preţuri într-un magazin en-gros ...... 151
§1. Consideraţii privind aplicaţia .................................................... 151
§2. Analiza şi proiectarea aplicaţiei. ............................................... 151
§2.1. Elemente de analiză ......................................................... 152
§2.2. Alegerea SGBD-ului adecvat ............................................ 155
§2.3. Proiectarea tabelelor şi stabilirea relaţiilor ........................ 156
§2.4. Descrierea obiectelor folosite ........................................... 161
§2.4.1. Implementarea reducerilor de preţ ...................... 163
§2.4.2. Definitivarea succesiunii de operaţii .................... 168
§2.4.3. Introducerea / modificarea datelor ....................... 171
§2.4.4. Proiectarea listelor ............................................... 175
§2.4.5. Alcătuirea meniurilor ............................................ 180
§3. Utilizarea aplicaţiei ................................................................... 181
§3.1. Prezentarea meniurilor ........................................... 181
§3.2. Rapoarte ................................................................. 184
§4. Anexă (organigrama aplicaţiei) ................................................ 186
3.3 Aplicaţie pentru evidenţa tranzacţiilor de acţiuni ..................... 187

§1. Aspecte privind tranzacţiile de acţiuni în cadru organizat ........ 187
§2. Analiza şi proiectarea aplicaţiei................................................ 188
§2.1. Elemente de analiză ....................................................... 188
§2.2. Alegerea SGBD-ului adecvat .......................................... 191
§2.3. Proiectarea tabelelor şi stabilirea relaţiilor ...................... 192
§2.4. Descrierea obiectelor folosite ......................................... 197
§2.4.1. Înregistrarea tranzacţiilor ..................................... 198
§2.4.2. Introducerea / modificarea datelor ....................... 204
§2.4.3. Proiectarea listelor ............................................... 208
§2.4.4. Alcătuirea meniurilor ............................................ 217
§3. Utilizarea aplicaţiei ................................................................... 218
§3.1. Prezentarea meniurilor ................................................... 218
§3.2. Rapoarte ......................................................................... 221
§4. Anexă (organigrama aplicaţiei) ................................................ 224
4. Probleme rezolvate................................................................................. 225

4.1 Evidenţa rezervărilor de locuri într-o reţea de bilete de tratament .... 225
4.2 Calculator de birou ......................................................................... 234
4.3 Evidenţa mişcărilor de carte într-o bibliotecă ..................................... 237
Bibliografie ................................................................................................... 246

1. BAZELE DE DATE – INSTRUMENT UTIL PENTRU GESTIONAREA

UNUI VOLUM MARE DE DATE
Societatea românească se află în plin proces de transformare; opţiunea

fundamentală de restructurare a sistemului economico-social în condiţiile unei
economii de piaţă funcţionale impune mutaţii esenţiale inclusiv în modalităţile de
organizare şi prelucrare a datelor. Având în vedere natura cuantificabilă a
informaţiei economice, sistemele de gestiune a bazelor de date oferă un
instrument de lucru eficient pentru culegerea, prelucrarea şi interpretarea datelor
provenite din mediul economic.
1.1 Noţiuni fundamentale
Datele sunt un ansamblu de semne cu un sens bine determinat, organizate

după anumite reguli şi principii; ele se reprezintă prin cifre, litere, cuvinte, sau
coduri predefinite, în scris sau pe un alt suport de memorare a datelor. Ele
reprezintă o măsură cantitativă sau calitativă a realităţii dintr-un anumit domeniu.
Fiind bazate pe observaţii şi măsurători, datele au un caracter obiectiv.
Prin procese de prelucrare specifice, datele se transformă în informaţie pe
măsură ce ele pot sugera o anumită stare sau schimbare de stare a unui fenomen,
proces, activitate, obiect, etc. la care data respectivă se referă.
Astfel, informaţia este o redare specifică a realităţii economico-sociale,
fiind destinată funcţiei de gândire umană în vederea descifrării semnificaţiilor sale
şi transformării ei în decizii menite să regleze întregul sistem.
Informaţia tehnico-economică este orice comunicare cu grad de noutate
care se referă explicit la mijloacele de producţie, procesele şi fluxurile tehnologice,
stadiile de transformare ale obiectului muncii, natura acestor transformări,
evidenţierea calitativă şi cantitativă a efectelor transformărilor endogene şi
exogene, a efectelor economice ale activităţii depuse de o unitate economică, etc.
Fiind o reflectare a realităţii prin prisma gândirii umane, informaţia are un

caracter subiectiv.
 După frecvenţa de generare şi utilizare, informaţia tehnico-economică poate
fi operativă, periodică, statistică sau previzională:

 Informaţia operativă redă starea şi dinamica fenomenelor şi proceselor
economice, care fac obiectul cuantificării pe intervale mici de timp (oră,
schimb, zi), astfel încât prezintă în mod continuu evoluţia sistemului.
 Informaţia periodică este formată din cumularea informaţiilor cu caracter
operativ la anumite intervale de timp prestabilite (ex.: decadă, lună,
trimestru, semestru, an), în aşa fel încât fenomenele şi procesele
economice să poată fi cuantificate la încheierea acestor intervale de timp.
 Informaţia statistică se bazează pe utilizarea informaţiei cu caracter
operativ şi periodic; ea reflectă dinamica şi structura fenomenelor şi
proceselor economice prin comparaţii între două intervale de timp
(intervale de referinţă).
 Informaţia previzională provine din coroborarea informaţiei operative,
periodice şi statistice în vederea determinării evoluţiei viitoare a
fenomenelor şi proceselor economice pe baza căreia se vor fundamenta
deciziile cu caracter previzional.
 În funcţie de conţinut şi nivelul de detaliere, informaţia tehnico-economică
poate fi analitică sau sintetică:

 Informaţia analitică descrie în detaliu fenomenele şi procesele economice
elementare care nu mai pot fi descompuse. Ea reflectă starea şi dinamica
fenomenelor şi proceselor cu un grad redus de prelucrare şi
prezentativitate.
 Informaţia sintetică prezintă starea şi dinamica fenomenelor şi proceselor
economice complexe. Ea rezultă din cumularea informaţiei analitice la
anumite intervale de timp (ex.: lună, trimestru, semestru, an) şi nivele de
referinţă (ex.: comandă de fabricaţie, secţie de producţie, cont sintetic).
Prin noţiunea de document, se denumeşte generic suportul material al
informaţiei. Acesta poate fi constituit din hârtie, dischetă, cd-rom, diapozitive sau
orice altă formă de stocare şi prezentare a datelor prelucrate.
În condiţiile economiei de piaţă, luarea deciziei corecte depinde esenţial de

informaţia disponibilă. Astfel, datele, transformate în informaţie şi prezentate în
mod analitic sau sintetic conduc la luarea deciziilor.
Pentru a conduce la decizii „bune”, informaţia trebuie să fie:
• Disponibilă în timp util;
• Corectă;
• Necontradictorie;
• Neredondantă;
• În formă adecvată necesităţilor factorului de decizie.
O informaţie disponibilă imediat ce s-a produs evenimentul la care se referă
poate fi utilizată în momentul deciziei şi este oportună în vederea unor decizii
bazate pe un fond cât mai mare de date.
Corectitudinea informaţiei se referă la fidelitatea acesteia în redarea realităţii
înconjurătoare nefalsificate.
O informaţie necontradictorie este consistentă; fiind obţinută din surse
diferite este interpretată în acelaşi mod şi conduce la decizii univoce.
Neredondanţa este o condiţie legată de gradul de repetare a datelor în
cadrul activităţii de decizie. Există riscul ca, la o repetare nenecesară a unei
informaţii, aceasta să nu fie utilă, să deranjeze procesul sau să conducă la
scăderea gradului de relevanţă al altor informaţii.
Pentru a fi utilă, informaţia trebuie să fie prezentată într-o formă
interpretabilă, adecvată procesului decizional şi modului de gândire al decidentului.
1.2 Cuplul informaţie-decizie într-o economie sistemică
Activitatea umană, privită ca totalitatea proceselor economico-sociale

organizate şi corelate, are la bază unitatea economică. Teoriile moderne
consideră unitatea economică formată din sisteme şi subsisteme care comunică
şi interacţionează între ele astfel ca unitatea să îşi îndeplinească funcţiile care îi
revin în cadrul societăţii umane.
O privire sistemică a unităţii economice conduce la delimitarea a trei

sisteme constitutive principale: sistemul de conducere, sistemul operativ şi
sistemul informaţional (FIG.1).
sistem de
conducere
sistem informaţional
sistem
operativ
FIG.1
Sistemul de conducere cuprinde ansamblul activităţilor de conducere,

coordonare, comandă, reglare şi control în vederea asigurării funcţionării optime
a întregii unităţi; el primeşte informaţii de la sistemul informaţional şi transmite
decizii către acesta.
Sistemul operativ sau executiv cuprinde ansamblul activităţilor specifice
unităţii: producţia, aprovizionarea, desfacerea, transportul, exportul, etc. Volumul
şi calitatea acestor activităţi sunt consemnate în documentele justificative care
redau starea şi dinamica fenomenelor şi proceselor conduse. Sistemul operativ
furnizează date către sistemul informaţional şi funcţionează pe baza deciziilor
primite de la acesta.
Sistemul informaţional realizează legătura dintre sistemul condus şi
sistemul de conducere; el reprezintă un ansamblu ierarhizat de procese
informaţionale şi se compune din totalitatea informaţiilor, surselor de informaţie,
nivelurilor receptoare, canalelor de circulaţie a fluxurilor informaţionale, precum şi
a procedurilor şi mijloacelor de tratare şi transmitere a informaţiei.
Într-o unitate economică modernă, prelucrarea datelor are loc cu ajutorul
sistemelor automate mai mult sau mai puţin complicate. În acest context,
sistemul informaţional “se informatizează”, adică sistemul informatic al unităţii

economice devine cea mai importantă componentă a sistemului informaţional.
Informaţia economică e folosită în conducerea, desfăşurarea şi controlul
fenomenelor şi proceselor economice care au loc la nivel micro, mezo şi
macroeconomic. Având rolul de declanşator al deciziei, informaţia devine
obiectul schimbului între organismele economice ale economiei de piaţă:
societăţi comerciale, clienţi, furnizori, acţionari, bănci, instituţii financiare şi
instituţiile guvernamentale de sinteză.
1.3 Aspecte generale privind bazele de date
În ultimii cincizeci de ani, producţia şi utilizarea tehnicii de calcul –

hardware şi software – a cunoscut o dezvoltare dramatică. Ea reprezintă o parte
semnificativă din produsul naţional brut al ţărilor industrializate; semnificativă
este SUA, unde peste 50% din capitalul investit este cheltuit pe tehnologie de
calcul. Costul “informaţiei" a ajuns la 1 trilion de dolari (aproximativ produsul
naţional brut al Marii Britanii) în anul 2000 şi la peste 1,5 trilioane în 2005 (după
Michael Spindler – fost preşedinte la Apple Computer).
Un sistem de gestionarea al bazelor de date, numit pe scurt SGBD, este
un software specializat în stocarea şi prelucrarea unui volum mare de date.
Termenul de bază de date se referă la modul de organizare al informaţiei iar
termenul de gestiune se referă la modalităţile de culegere, prelucrare,
vizualizare şi interpretare a informaţiei.
Tehnologia informaţiilor face permanente modificări mijloacelor de muncă
în întreaga lume. Informaţii care erau altădată stocate în depozite pline de
dulapuri pot fi accesate acum la o singură apăsare a butonului mouse-ului.
Pentru a stoca informaţii în orice mediu imaginabil, în zilele noastre sunt folosite
sisteme de baze de date. De la bazele mari de date, cum ar fi sistemele de
rezervare a biletelor companiilor aeriene şi până la colecţia de fişe dintr-un
cabinet medical, sistemele de baze de date sunt folosite pentru memorarea şi
distribuirea datelor de care încep să depindă vieţile noastre. Până în urmă cu
câţiva ani, sistemele mari de baze de date puteau fi executate numai pe

calculatoare de tip mainframe. În mod obişnuit, era foarte costisitor să fie
proiectate, achiziţionate şi întreţinute aceste maşini. Odată cu apariţia
calculatoarelor din clasa staţiilor de lucru, care sunt puternice şi ieftine,
programatorii au posibilitatea de a proiecta rapid şi ieftin produse software pentru
întreţinerea şi distribuirea datelor.
Stocarea, manipularea şi prezentarea informaţiei a depăşit de mult
teritoriul centrelor de calcul. Produsele program se întâlnesc în cele mai
obişnuite situaţii: unităţi economice, scoli, biblioteci, etc. Ele controlează
echipamente industriale (linii tehnologice automate, maşini cu comandă
numerică, roboţi), mijloace de transport şi de comunicaţii, tranzacţii financiare şi
bancare, reţele energetice, sisteme de apărare naţională, etc.
Cel mai folosit model de stocare a datelor este baza de date relaţională.
Acest nou model s-a dezvoltat pornind de la un articol scris de Dr. E. F. Codd în
anul 1970. Ideea lui Codd pentru un sistem de administrare a bazelor de date
relaţionale foloseşte conceptele matematice de algebră relaţională pentru a
grupa datele în mulţimi şi a stabili relaţii între submulţimile domeniile comune.
În plus faţă de dezvoltarea unui model de bază de date relaţională, alte
două tehnologii au condus la dezvoltarea rapidă a ceea ce acum este numit un
sistem de baze de date client/server.
Prima tehnologie importantă a fost calculatorul personal, care a făcut
posibil ca aplicaţii ieftine, uşor de folosit, să permită utilizatorilor crearea
documentelor şi administrarea datelor rapid şi corect. Utilizatorii s-au obişnuit să
modernizeze continuu sistemele, deoarece rata schimbului a fost echilibrată
rapid de scăderea preţului celor mai avansate sisteme.
A doua tehnologie importantă a fost dezvoltarea reţelelor locale de
calculatoare (LAN). Deşi utilizatorii erau obişnuiţi cu terminalele conectate la
calculatorul mainframe comun, acum fişierele procesate puteau fi stocate local şi
accesate de la orice calculator ataşat în reţea. Totodată, cantităţi mari de date
puteau fi transferate la serverele de date departamentale.
În acest context, sistemul, denumit client/server deoarece procesarea este
separată între calculatoarele client şi un server de baze de date, constituie o
modificare radicală de la programarea aplicaţiilor bazată pe calculatoarele

mainframe. Această arhitectură este total recursivă, pe rând serverele putând
deveni clienţi şi cere servicii de la alte servere din reţea. Datorită puterii crescute
a hardware-ului calculatoarelor personale, informaţiile critice ale bazei de date
pot fi memorate pe un server independent, care poate fi înlocuit mai târziu cu
foarte puţine (sau chiar fără) modificări.
Ultima dintre arhitecturile dezvoltate este cea a aplicaţiilor distribuite pe
web. Clientul devine o aplicaţie cât mai simplă posibil, accesat de obicei printr-un
banal browser de internet. Serverul de date şi cel de aplicaţii web preiau cea mai
mare parte a sarcinilor, fiind plasate în general pe calculatoare puternice. Se
revine astfel la structura oarecum centralizată, dar pe o spirală evidentă a
tehnologiei.
Complexitatea actuală a aplicaţiilor de management al bazelor de date
face necesară o combinaţie a procesării tranzacţiilor on-line, a încărcării şi a
creşterii sprijinului decizional. În scopul satisfacerii acestor necesităţi, este nevoie
de baze de date scalabile şi performante care pot fi ajustate dinamic pentru a
realiza un compromis între bazele de date (mai mari) şi utilizatorii simultani (mai
mulţi). De asemenea, sunt necesare tehnologii pentru baze de date proiectate
pentru a maximiza capacităţile configuraţiei hardware / software disponibile,
incluzând arhitecturi simplu şi multi-procesor, precum si pentru valorificarea unor
arhitecturi hardware, cum ar fi clustere cuplate larg şi maşini paralele puternice.
Serverele de date de astăzi se apropie de aceste cerinţe printr-o arhitectură
paralelă de nouă generaţie a bazelor de date care furnizează scalabilitate,
manevrabilitate şi performanţă, o regie minimală a sistemului de operare, şi o
distribuire automată a încărcărilor de lucru. Arhitectura multifilară este proiectată
pentru a utiliza cât mai bine resursele hardware şi poate fi reconfigurată dinamic
on-line pentru a urmări cererile în schimbare.
Performanţa este aspectul critic al succesului, şi având în vedere creşterea
dramatică a numărului de utilizatori, date fiind aplicaţiile de comerţ electronic şi
noile modele de calcul, presiunea exercitată asupra bazelor de date este mai
mare ca oricând.
1.4 Arhitectura unei baze de date
Arhitectura unei baze de date reprezintă modul de organizare a datelor,

între calculatorul care operează asupra datelor sub formă de biţi şi utilizatorul
unei baze de date. Caracteristic arhitecturii unei baze de date sunt nivelele de
independenţă şi de abstractizare a datelor.
1.4.1 Independenţa datelor
Independenţa datelor constituie un scop esenţial în concepţia şi

organizarea oricărei baze de date. Independenţa datelor înseamnă că există o
delimitare netă între reprezentarea fizică a datelor şi imaginea pe care o are
utilizatorul asupra acestora, modul concret în care se realizează memorarea şi
organizarea datelor fiind transparent pentru utilizator.
Realizarea independenţei totale a datelor ridică probleme deosebite de
implementare, care în momentul de faţă sunt doar parţial rezolvate.
Problema independenţei datelor prezintă două aspecte: independenţa
fizică a datelor şi independenţa logică a datelor.
Independenţa fizică a datelor înseamnă:
 Imunitatea aplicaţiilor faţă de structura fizică a datelor;
 Pentru utilizator, datele sunt entităţi cu nume;
 Aplicaţia nu conţine referire la:
 Tipul fişierelor;
 Tipul dispozitivelor de memorare;
 Strategia de acces la date.
Independenţa logică a datelor este mai greu de realizat practic şi depinde
esenţial de modelul de date folosit. Ea înseamnă:
 Imunitatea modelului propriu al fiecărui utilizator faţă de modificările
ulterioare în structura logică a datelor;

 Se pot defini noi câmpuri sau date fără a afecta utilizatorii deja existenţi –
cu anumite limitări, de exemplu e interzisă eliminarea datelor.

1.4.2 Nivele de abstractizare a datelor
Abstractizarea este un procedeu prin care se neglijează aspectele

nerelevante ale datelor concomitent cu evidenţierea proprietăţilor care prezintă
interes în momentul respectiv. Criteriul de relevanţă este determinat de scopul
propus.
Abstractizarea este folosită pentru obţinerea categoriilor de date.
Asigurarea independenţei datelor în cadrul bazelor de date impune
adoptarea unei arhitecturi organizate pe cel puţin trei nivele. În funcţie de nivelul
de abstractizare se deosebesc (FIG.2):
 nivelul intern (baza de date fizică);
 nivelul conceptual (modelul conceptual sau schema conceptuală);
 nivelul extern (modelul extern, subschemă, vedere).
FIG.2 - Schema generală a unei baze de date

Nivelul intern sau baza de date fizică este o colecţie de fişiere conţinând
datele fizice, la care se adaugă diverse structuri auxiliare menite să asigure
accesul operativ la aceste date. Structurile auxiliare pot fi: directoare, indecşi,
pointeri, etc.
Baza de date fizică este rezidentă în memoria permanentă a calculatorului,
în general pe discuri magnetice sau optice. Modul de organizare al bazei de date
fizice depinde puternic de configuraţia echipamentelor hardware care suportă
baza de date şi de sistemul de operare. Schimbarea sistemului de operare sau
modificarea echipamentului de calcul pot atrage modificări ale bazei de date
fizice. Dacă e satisfăcută condiţia de independenţă fizică a datelor, modificările la
nivelul intern al bazei de date nu vor afecta nivelele superioare ale acesteia.
Modelul conceptual este o abstractizare a unei părţi din lumea reală şi
constă din descrierea structurii logice a datelor în baza de date. Fiecare bază de
date are un model conceptual propriu prin care sunt numite şi descrise toate
unităţile logice şi legăturile dintre acestea.
Modelul conceptual integrează viziunile tuturor utilizatorilor asupra datelor
şi specifică ce anume poate face parte din baza de date (descrierea datelor) şi
ce nu poate fi memorat în baza de date (constrângerile la care sunt supuse
datele).
Independenţa fizică a datelor este realizată de nivelul conceptual al bazei
de date. La acest nivel nu se face referire la modul de memorare al datelor sau la
strategia de acces la date.
Modelul extern poate fi privit ca o descriere a unei baze de date,
corespunzătoare fiecărui utilizator în parte. Modelul extern cuprinde o parte a
unităţilor logice din modelul conceptual, la care se adaugă un număr de unităţi
"virtuale" care nu au corespondent în baza de date fizică.
Unităţile logice "virtuale" pot fi obţinute prin modificare unor unităţi logice
din modelul conceptual sau prin combinarea acestora potrivit nevoilor unui
utilizator. Unităţile "virtuale" pot intra în operaţii de prelucrare alături de unităţile
logice reale, cu anumite limitări legate de ştergerea datelor sau logica prelucrării.
La nivel extern se defineşte conceptul de vedere, ca o viziune
individualizată şi simplificată asupra bazei de date, corespunzătoare unui anumit
utilizator sau grup de utilizatori. Cu ajutorul vederilor se controlează accesul la

date al utilizatorilor.
Modelul extern realizează independenţa logică a datelor. Modificări în
modelul conceptual pot determina modificări în descrierea vederilor, dar nu pot
modifica vederea în sine, respectiv modelul extern.
În cadrul unei baze de date, trecerea de la un nivel la altul se realizează cu
ajutorul transformărilor care definesc interfaţa între două nivele succesive.
1.4.3 Modelarea datelor la nivel conceptual
Modelarea datelor este un instrument care conduce la interpretarea

datelor. Din punctul de vedere al interpretării, organizarea datelor prezintă cerinţe
contradictorii, şi anume:
 Să reprezinte cât mai fidel realitatea;
 Să fie adecvată prelucrării pe calculator.
Un model de date cuprinde descrierea tuturor entităţilor unei baze de date
împreună cu toate legăturile existente între ele.
La nivel conceptual, modelarea datelor este un formalism constând
dintr-un set de reguli pentru organizarea datelor alături de un set de reguli pentru
manipularea acestora.
Regulile pentru organizarea datelor reprezintă proprietăţile statice ale
modelului de date; ele se exprimă prin Limbajul de descriere a datelor (LDD).
Regulile generatoare (G) se exprimă prin reguli de definire şi constrângeri
impuse datelor (FIG.3).
G = Gs + Gc
Structura +
constrangeri Constrangeri
implicite explicite
FIG.3. – LDD, componentă a modelului conceptual

Regulile pentru manipularea datelor reprezintă proprietăţile dinamice ale

modelului de date; ele se exprimă prin Limbajul de manipulare a datelor (LMD).
Regulile de manipulare a datelor constă într-un set de operaţii permise care nu
modifică structura datelor, conservând modelul conceptual.
Din punct de vedere al organizării datelor, modelele de date pot fi strict
tipizate şi slab tipizate. Modelele de date strict tipizate utilizează categoriile de
date – dacă un set de date nu poate fi inclus într-una dintre categoriile deja
definite, el nu poate face parte din model. Modelele de date slab tipizate oferă un
grad ridicat de flexibilitate deoarece categoriile sunt utilizate numai în măsura în
care se dovedesc utile pentru aplicaţie.
Modele de date strict tipizate stau la baza sistemelor de gestiune a bazelor
de date şi au următoarele caracteristici:
 Toate datele sunt “forţate” in categorii;
 Proprietăţile datelor pot fi abstractizate şi permit dezvoltarea unor
demonstraţii, în sens algebric;
 Categoriile sunt omogene, predefinite si nu pot evolua dinamic;
 Lipsa de expresivitate, lipsa de flexibilitate;
 Sunt adecvate prelucrării pe calculator.
O entitate este o realitate obiectivă care există prin ea însăşi. Entitatea

este caracterizată prin proprietăţile sale, numite atribute. Un tip de entitate este
o reprezentare în cadrul unui model de date care corespunde unei categorii din
lumea reală şi constituie intensiunea acelei categorii. Extensiunea unui tip de
entitate este formată din mulţimea entităţilor având proprietăţi comune, descrise
prin tipul de entitate considerat. Fiecare entitate din această mulţime este o
instanţiere a tipului de entitate căruia îi aparţine. Entităţile individuale,
aparţinând unui anumit tip de entitate, se deosebesc între ele prin valorile diferite
ale atributelor lor.
În cadrul modelelor de date intervin două forme de structurare a datelor:
 modalitatea de asociere a atributelor pentru a forma structura de
date, reprezentată grafic prin diagrama structurii de date;
 reprezentarea legăturilor între mulţimile de entităţi de date.
Astfel, există trei tipuri esenţiale de modele de date: modelul ierarhic,

modelul reţea şi modelul relaţional.
Modelul ierarhic foloseşte ambele forme de structurare a datelor,
concretizate prin tipurile de înregistrări şi legăturile explicite.
Diagrama structurii de date este un graf strict orientat reprezentând tipuri
de entităţi şi legături funcţionale între acestea. Nodurile grafului corespund
tipurilor de entităţi; fiecare arc al grafului reprezintă o legătură funcţională între
tipurile de entităţi aflate la capetele sale. Sensul funcţionalităţii este opus
sensului arcului. În acest mod sunt reprezentate relaţiile unu-la-unu şi unu-la-
mai-mulţi. Relaţiile de tipul mai-multi-la-mai-multi nu pot fi reprezentate direct prin
arcele diagramei structurii de date.
Nodurile sunt organizate pe nivele, fiecare nod, exceptând nodul rădăcină,
are o singură legătură către un nod de pe nivelul superior şi un număr arbitrar de
legături către noduri de pe nivelul imediat inferior. Sensul legături funcţionale
este totdeauna de la nodul tată către nodul fiu.
Descrierea unei baze de date de tip ierarhic folosind un LDD presupune
definirea a trei elemente esenţiale:
 arborele de definiţie ierarhic, prin specificare nodului rădăcină şi a legăturilor
de tip tată-fiu;
 tipurile de înregistrări constituind nodurile arborelui;
 câmpurile din cadrul înregistrărilor, caracterizate prin tip şi dimensiune.
Principalul avantaj al acestui model de date este apropierea de
reprezentarea şi utilizarea fişierelor manuale. Astfel, se pot folosi chiar şi fişiere
de tip secvenţial. Modelul este relativ simplu şi implică un număr relativ redus de
operatori algebrici.
Dintre dezavantajele modelului ierarhic, cele mai importante sunt:
 Flexibilitate scăzută, fiind adecvat doar reprezentării relaţiilor de tip
unu-la-unu şi unu-la-mai-multi;
 Redundanţă ridicată în reprezentarea datelor, ceea ce implicit,
conduce şi la inconsistenţa datelor;
 Asimetrie în tratarea interogărilor, motiv pentru care se limitează sever
tipul interogărilor care se pot rezolva eficient.
Modelul de date reţea este bazat pe tabele şi grafuri, pentru

reprezentarea lui folosindu-se ambele structuri: tipul de înregistrare şi legăturile
explicite.
Modelul conceptual al unei baze de date de tip reţea este reprezentat
printr-o diagramă a structurii de date care este un graf oarecare. Nodurile
reprezintă tipuri de entităţi iar arcele reprezintă legăturile dintre acestea.
Configuraţia diagramei fiind un graf oarecare, un anumit tip de entitate poate fi
legat la mai multe tipuri de entităţi părinte, sau chiar prin mai multe arce la
acelaşi tip de entitate părinte. Din acest motiv, arcele sunt etichetate.
Arcele etichetate se numesc tipuri de set şi reprezintă o legătură logică
între două tipuri de înregistrări: tipul de înregistrare proprietar şi tipul de
înregistrare membru. Sensul funcţionalităţii este de la tipul de înregistrare
membru la tipul de înregistrare proprietar.
Un tip de set poate fi folosit pentru reprezentare explicită a relaţiilor unu-la-
unu şi unu-la-mai-multi, fără a reprezenta eficient relaţiile de tipul mai-multi-la-
mai-multi.
Proprietăţile seturilor şi tipurilor de set sunt următoarele:
 Fiecare tip de set are un tip de înregistrare proprietar;
 Fiecare instanţiere a unui tip proprietar este proprietarul unui set. Un set
nu include în mod necesar şi înregistrările membru;

 Fiecare tip de set include cel puţin un tip de înregistrare membru. Unele
tipuri de set pot include mai mult de un tip membru;

 Un tip de articol nu poate fi în acelaşi timp proprietar şi membru al
aceluiaşi tip de set;

 Nici o instanţiere de tip înregistrare nu poate participa la mai mult de o
instanţiere a unui tip de set.

Implementarea tipurilor de set se realizează de obicei prin pointeri. Pentru
înlănţuirea înregistrărilor dintr-un set, administratorul bazei de date poate folosi
pointerii Next, Prior şi Owner precum şi combinaţii ale acestora.
Modelul de date reţea poate reprezenta explicit legăturile unu-la-unu şi
unu-la-mai-multi. Legăturile de tipul mai-multi-la-mai-multi se descompun în două
legături de tipul unu-la-mai-multi prin introducerea unui tip de înregistrare
intermediar. Înregistrările tipului intermediar, numite şi înregistrări de legătură,

pot să fie sau să nu fie purtătoare de informaţie utilă pentru sistemul considerat.
Deşi introduce un anumit grad de redundanţă în reprezentarea datelor,
modelul de date reţea prezintă avantaje importante faţă de modelul ierarhic:
 Simetrie în tratarea interogărilor;
 Gama interogărilor posibile e limitată doar de structura bazei de date;
 Sunt eliminate anomaliile de ştergere, adăugare şi actualizare a datelor.
Principalul dezavantaj al modelului de date reţea este faptul că are o

structură prea apropiată de structura de memorare. Astfel, legăturile dintre
entităţi sunt explicite fiind realizate prin pointeri. Întreaga structură de pointeri
este vizibilă iar gestiunea acesteia cade în sarcina utilizatorului.
Modelul de date relaţional a apărut relativ târziu, doar după atingerea
unui anumit nivel de performanţă al echipamentelor de calcul. El constituie
punctul de plecare pentru realizarea unor SGBD-uri competitive. Principiile care
stau la baze acestui model sunt cele din matematica relaţiilor, extinse şi adaptate
corespunzător.
Modelele de date relaţionale au asociate limbaje relaţionale, având
capacitatea de a defini noi relaţii pe baza celor existente.
Fiind dată o colecţie de mulţimi D1, D2, ...Dn, se defineşte o relaţie R pe
aceste n mulţimi ca fiind mulţimea n-tuplelor ordonate (d1, d2, ...dn) astfel încât
d1 D1, d2  D2, ..., dn  Dn.
Astfel, orice relaţie este o mulţime ale cărei elemente sunt n-tuple. De aici
rezultă că într-o relaţie nu există două n-tuple identice, adică două n-tuple diferă
cel puţin prin valoarea unuia dintre elemente. Ordinea n-tuplelor unei relaţii este
nerelevantă, deci ele pot fi reordonate după necesităţile aplicaţiei.
Un atribut este un domeniu cu nume. Atributele sunt proprietăţi ale n-
tuplelor care derivă din domeniul din care fac parte.
Cheia unei relaţii R este un subset K al atributelor relaţiei R care satisface
proprietăţile de identificare unică şi neredondantă. În orice relaţie există cu
certitudine o cheie – mulţimea tuturor atributelor. Problema găsirii unei chei care
include setul minimal de atribute este importantă în timpul rezolvării unei aplicaţii.
Orice atribut care face parte dintr-o cheie se numeşte atribut prim. Cheia
primară este aceea cheie a unei baze de date pe care un SGBD o foloseşte
pentru identificarea unică a n-tuplelor. Asupra unei chei primare se impun
următoarele restricţii:
 Nu sunt admise valori nedefinite pentru atributele unei chei primare.
 Nici o valoare a unui atribut al cheii primare nu poate fi modificat în
cadrul operaţiilor de actualizare în baza de date.
Modelul relaţional foloseşte o singură modalitate de structurare a datelor:
relaţiile. Structurarea datelor implică definirea schemei de relaţii. Astfel, modelul
conceptual al bazei de date relaţionale include numele relaţiilor şi atributele
acestora.
Intensiunea unei baze de date relaţionale este tocmai schema de relaţii.
Extensiunea unei astfel de baze de date este reprezentarea ei sub formă de
tabele.
Un subset FK al atributelor unei relaţii R2 este o cheie străină dacă:
 Există o relaţie R1, nu neapărat distinctă, având o cheie K;
 Pentru fiecare valoare a lui FK din relaţia R2 există o valoare
identică a cheii K, în relaţia R1.
În cazul unei baze de date relaţionale, se pune problema respectării
următoarelor principii:
 Principiul integrităţii domeniului. Acesta se referă la posibilitatea verificării
semantice şi sintactice a valorilor din baza de date folosind definiţia
domeniului din care fac parte. Realizarea acestui principiu face imposibilă
înregistrarea de valori din afara domeniului de definiţie al unui atribut.
 Principiul integrităţii entităţii sau al relaţiei. Acesta se referă la condiţiile
impuse cheilor primare, de a avea valori unice şi nenule.
 Principiul integrităţii referinţei care se enunţă astfel: Dacă A este o cheie
primară monoatribut în relaţia R1 şi B este o componentă a unei chei
primare multiatribut în relaţia R2, B fiind definită pe acelaşi domeniu cu
atributul A, atunci mulţimea valorilor lui B în R2 trebuie să fie inclusă în
mulţimea valorilor lui A în R1.
1.5 Etape în evoluţia bazelor de date
Activitatea de organizare şi prelucrare a datelor a avut în ultimii ani o

evoluţie spectaculoasă, determinată în principal de necesităţi şi posibilităţi. Cei
doi factori sunt contradictorii, în sensul că necesităţile au fost mereu în creştere
fiind nevoie de acces rapid, operativ, la date din ce în ce mai multe. Concomitent,
apariţia de noi posibilităţi care satisfac necesităţile, determină formularea de noi
cerinţe privind serviciile oferite de o bază de date.
În literatura de specialitate este acceptată delimitarea a 4 etape de evoluţie
a dezvoltării bazelor de date, alături de specificarea tendinţelor si prefigurarea
caracteristicilor pentru etapa a 5-a.
1.5.1 Etapele 1 şi 2
Prima etapă a evoluţiei tehnicilor de organizare şi prelucrare a datelor se

caracterizează prin adaptarea tipurilor de organizare a datelor existente în
condiţiile de prelucrare manuală la condiţiile tehnice impuse de utilizarea
calculatoarelor electronice.
Principalul tip de organizare a datelor utilizat în această etapă este
fişierul. Sistemele de prelucrare electronică a datelor au preluat această formă
de organizare din sistemul manual, fără a-i aduce perfecţionări de fond. În
această etapă, datele sunt organizate, în principal, sub formă de fişiere
secvenţiale, organizare condiţionată de utilizarea pe scară largă a benzilor
magnetice ca suport extern de memorare a datelor; nu există o diferenţiere clară
între structura logică a datelor şi structura fizică, acestea fiind, de regulă similare.
Structura datelor este proiectată pentru a deservi o singură aplicaţie, ceea ce
implică o redundanţă mare în memorarea datelor, ca urmare a faptului că date
reprezentând acelaşi aspect al lumii reale sunt memorate separat pentru fiecare
aplicaţie care are nevoie de aceste date. La aceasta se mai adaugă şi
dependenţa aplicaţiilor faţă de date, concretizată prin faptul că o modificare în

structura datelor implică modificări ale programelor de aplicaţie, şi deci,
recompilarea lor. În această etapă, se foloseşte în exclusivitate prelucrarea pe
loturi (batch-processig)
Etapa a doua este marcată de separarea dintre structura logică de date şi
structura fizică, separaţie prin care se realizează independenţa fizică a datelor.
Se utilizează pe scară tot mai largă fişierele secvenţial-indexate şi cele în acces
direct având ca suport extern de memorare discul magnetic. Prin separarea
structurii logice de structura fizică se asigură independenţa aplicaţiilor atât faţă
de modificările echipamentelor hardware (bandă magnetică, disc magnetic), cât
şi faţă de modul de organizare al fişierelor (secvenţiale, secvenţial-indexate,
aleatoare). Aceasta înseamnă că se pot schimba dispozitivele de memorare fără
a afecta aplicaţiile. Schimbarea dispozitivelor de memorare afectează, eventual,
structura fizică a datelor, nu şi structura logică. Aplicaţiile, dependente doar de
structura logică, nu sunt afectate de asemenea schimbare. În această etapă apar
primele facilităţi simple de protecţie a datelor.
O caracteristică comună a primelor două etapa constă în faptul că datele
sunt organizate în fişiere specifice fiecărei aplicaţii în parte; fiecare aplicaţie
operează cu un grup propriu de fişiere, fără a avea nici o legătură cu fişierele
utilizate de alte aplicaţii. Acest mod de organizare are o serie de inconveniente:
 Redundanţa datelor, care constă în aceea că aceleaşi date, folosite în
aplicaţii diferite, sunt înregistrate în mai multe fişiere. Aceasta conduce
la utilizarea ineficientă a spaţiului de memorare şi ridică probleme la
executarea operaţiilor de actualizare.
 Absenţa unor legături logice între datele din grupuri de fişiere diferite,
ceea ce în cazul aplicaţiilor mai complexe duce fie la creşterea excesivă
a timpului de prelucrare, fie la creşterea excesivă a numărului de fişiere.
 Flexibilitatea redusă a sistemului, care se manifestă prin aceea că, la
apariţia unei noi aplicaţii, este necesară fie crearea unuia sau mai
multor fişiere noi, fie reorganizarea celor existente.
1.5.2 Etapele 3 şi 4
Etapa a treia este definită de apariţia fişierelor integrate. Aceasta elimină

majoritatea inconvenientelor primelor două etape, prin înlocuirea grupurilor de
fişiere destinate unor aplicaţii particulare cu un sistem complex de elemente de
date a căror organizare este determinată de legăturile logice intrinseci existente
între acestea, şi mai puţin de modul de prelucrare din cadrul fiecărei aplicaţii.
Fişierele integrate permit realizarea mai multor fişiere logice pe baza
aceloraşi date fizice. Se reduce astfel redundanţa datelor, fiind posibilă utilizarea
în comun a aceloraşi date fizice de către mai multe aplicaţii. Prin integrarea
fişierelor rezultă o structură logică unitară care urmăreşte să răspundă cerinţelor
tuturor aplicaţiilor. Aceste structuri integrate constituie originea modelului
conceptul din cadrul bazelor de date actuale.
Etapa a patra este etapa bazelor de date propriu-zise.
Trecerea la utilizarea fişierelor integrate, care a oferit posibilitatea
exploatării în comun a aceloraşi date de către mai multe aplicaţii, a făcut tot mai
imperioasă necesitatea realizării independenţei aplicaţiilor faţă de structura logică
a datelor. Aceasta se impunea deoarece orice modificare în structura datelor,
pentru a satisface cerinţele unei noi aplicaţii, putea atrage după sine modificări
ale tuturor aplicaţiilor care exploatau structura de date respectivă. Din acest
motiv era necesară desprinderea din cadrul programelor de aplicaţii a descrierii
structurii de date. Aceste descrieri care se referă strict la datele unei aplicaţii
poartă numele de model extern. Prin apariţia modelelor externe, la independenţa
fizică a datelor se adaugă şi independenţa logică. Aceasta înseamnă că sunt
posibile modificări în structura logică a bazei de date (la nivelul modelului
conceptual), fără ca acestea să afecteze datele.
În această etapă se concretizează modelul conceptual ca nivel virtual de
organizare a datelor, la care se adaugă modelele externe asociate fiecărui
utilizator. Tot în această etapă, apar tehnici şi proceduri speciale pentru protecţia
şi securitatea datelor, cât şi funcţia de administrare a bazei de date. Redundanţa
datelor este redusă la minimum.
1.5.3 Tendinţe în dezvoltarea bazelor de date
Majoritatea covârşitoare a sistemelor de gestiune a bazelor de date aflate

azi în exploatare au fost proiectate pentru a satisface cerinţe specifice, din
domeniul economic. Caracteristica comună a acestor operaţii este volumul mare
de date asupra căruia se aplică un număr limitat de operaţii, de regulă operaţii
relativ simple. Prelucrările din aceste aplicaţii sunt dominate de operaţii de tip
adăugare, ştergere, actualizare, regăsire a datelor care satisfac nişte condiţii
date.
Limbajele de manipulare a datelor din cadrul acestor sisteme au fost
adaptate clasei de aplicaţii cărora le sunt destinate. Ele rezolvă cu eficienţă
problema accesului operativ la un volum mare de date, dar au o putere de
expresie limitată, considerabil mai redusă decât a limbajelor de programare
convenţionale.
În ultimii ani apar tot mai multe aplicaţii de baze de date care prin
caracteristicile lor nu se mai încadrează în clasa aplicaţiilor pentru care au fost
destinate SGBD-urile actuale. Ele se caracterizează prin necesitatea de a
accesa şi manipula volume mari de date, dar şi prin necesitatea de a efectua
operaţii complexe asupra acestora. Astfel, este tot mai evidentă necesitatea de a
dispune de limbaje de manipulare a datelor cu o expresivitate mare, comparabilă
cu ceea a limbajelor de programare convenţionale.
La ora actuală, se conturează două alternative: abordarea orientată pe
obiect şi abordarea logică.
Abordarea orientată pe obiect este caracteristică sistemelor de gestiune a
bazelor de date orientate pe obiect. În cadrul acestora, o parte a complexităţii
prelucrării datelor este transferată asupra structurii datelor. Principalele
caracteristici ale acestor sisteme sunt:
 Posibilitatea de manipulare a obiectelor complexe. Se pot defini tipuri de
date complexe, care la rândul lor se pot imbrica. Se pot defini ierarhii de
tipuri şi subtipuri derivate, cu proprietăţi speciale.
 Încapsularea constă în posibilitatea de a defini proceduri care se aplică

numai obiectelor de un anumit tip. Aceste proceduri constituie singura
posibilitate de a accesa şi manipula obiectele tipului respectiv. Fiecare tip
are două componente: o interfaţă şi o implementare. Implementarea poate
fi modificată fără a schimba interfaţa; astfel, programele de aplicaţii vor fi
independente faţă de modul de implementare al obiectelor.
 Identitatea obiectelor se referă la faptul că se poate face distincţie între
două obiecte identice, având aceleaşi proprietăţi şi aceleaşi valori ale
proprietăţilor. Cele două obiecte nu se vor confunda, ci va avea fiecare o
identitate proprie, sistemul tratându-le ca obiecte distincte.
Abordarea logică este reprezentată de sistemele de gestiune a bazelor de
cunoştinţe. Acestea satisfac următoarele condiţii:
 Furnizează toate serviciile oferite de un SGBD obişnuit: acces eficient la
volume mari de date, gestiunea tranzacţiilor, etc.
 Includ un limbaj declarativ a cărui putere de expresie este egală sau chiar
mai ridicată decât cea a limbajelor de programare convenţionale.
1.6 Sisteme de gestiune a bazelor de date
Printr-un Sistem de Gestiune a Bazelor de Date se înţelege o colecţie de

elemente software utilizată pentru prelucrarea unui volum mare de date. Astfel,
un SGBD este întregul ansamblu software care tratează toate cererile de acces
la date. Cu ajutorul acestuia se implementează sintagma "o bază de date a fost
creată pentru a fi interogată".
Un fişier bază de date este o colecţie de obiecte specifice folosite pentru
organizarea, stocarea şi gestionarea datelor referitoare la rezolvarea unei
probleme.
SGBD-urile moderne permit crearea bazelor de date relaţionale.
Caracterul relaţional al unei baze de date decurge din existenţa unor legături
logice între obiectele componente.
Pentru ca un SGBD să fie considerat total relaţional, el trebuie să respecte

cele trei principii enunţate anterior pentru modelul relaţional şi, în plus, să
furnizeze utilizatorului un Limbaj de Manipulare a Datelor cel puţin echivalent ca
putere de expresie cu algebra relaţională.
Pentru a-şi realiza obiectivul, un SGBD foloseşte toate nivelele de
abstractizare ale bazei de date şi toate interfeţele dintre acestea (FIG.2), facilităţi
de descriere a datelor (FIG.3) şi facilităţi de manipulare a acestora.
Din punct de vedere al descrierii datelor, un SGBD:
 Descrie datele la nivel conceptual şi logic, uneori chiar şi la nivel fizic;
 Descrie rolul şi modul de funcţionare al interfeţelor;
 Efectuează operaţii de întreţinere a datelor: încărcare, menţinerea

integrităţii, etc.
Din punct de vedere al manipulării datelor, un SGBD asigură interfaţa cu
utilizatorii prin operaţii de adăugare, actualizare, ştergere a datelor, interogare a
bazei de date, etc.
În acest sens, principalele funcţii ale unui SGBD sunt:
 definirea şi descrierea datelor;
 proiectarea interfeţei pentru culegerea datelor;
 stocarea datelor pe un suport de memorie nevolatilă;
 actualizarea informaţiei (modificare, adăugare, inserare, ştergere);
 efectuarea unor operaţii de ordonare şi căutare a datelor;
 crearea şi actualizarea sistemului de relaţii între date;
 interogarea bazelor de date (selectare, afişare, raportare, tipărire, etc.);
 administrarea datelor (stabilirea drepturilor de acces, protecţia datelor şi a
programelor, etc.).
1.6.1 Avantajele utilizării SGBD-urilor
Principalele avantaje ale utilizării SGBD-urilor derivă din avantajele utilizării

bazelor de date. Cele mai importante avantaje şi semnificaţiile acestora sunt:
 Reducerea redundanţei datelor memorate

 Mai multe aplicaţii utilizează acelaşi fişier de date, evitând utilizarea
ineficientă a suportului de memorie şi creând condiţii pentru evitarea
inconsistenţei datelor.
 Evitarea inconsistenţei datelor
 Datele sunt inconsistente dacă pentru aceeaşi dată pot exista valori
diferite în copii diferite. O astfel de situaţie poate crea confuzii sau erori
în procesul de prelucrare a datelor.
 Partajarea datelor
 Deoarece mai multe aplicaţii utilizează acelaşi fişier de date, se pot
dezvolta aplicaţii noi cu datele existente.
 Introducerea standardelor
 Standardizarea în domeniul bazelor de date oferă posibilitatea
transferului datelor de la o bază de date la alta.
 Introducerea unor restricţii de securitate a datelor
 Autorizarea si controlul accesului la date se face centralizat.
 Menţinerea integrităţii datelor
 Din punctul de vedere al bazelor de date, datele se consideră corecte
dacă ele sunt consistente şi validate prin proceduri specifice aplicaţiei.
1.6.2 Funcţia de administrare a bazelor de date
Fiind enumerată ca ultima dintre funcţiile unui SGBD, administrarea

bazelor de date este o activitate importantă, încredinţată unei persoane sau unui
compartiment specializat având următoarele atribuţii:
 Atribuţii de proiectare
 Determină necesităţile de informaţie al utilizatorilor;
 Decide conţinutul bazei de date (entităţi şi legături);
 Stabileşte structura fizică şi strategia de acces la date;
 Descrie modelul conceptual şi modelul extern al bazei de date;
 Stabileşte transformările efectuate de interfeţe;
 Stabileşte constrângeri şi proceduri de validare;

 Stabileşte drepturi de acces global şi la fiecare nivel.
 Atribuţii administrative
 Rezolvă cerinţele şi reclamaţiile utilizatorilor;
 Impune disciplina şi folosirea de standarde;
 Consultanţă la achiziţionarea de hardware.
 Atribuţii operative
 Reorganizează structura fizică în funcţie de echipamentele hardware
disponibile;
 Stabileşte strategia de arhivare, recuperare şi refacere a datelor;
 Modificarea drepturilor de acces după necesităţi momentane.
 Atribuţii de coordonare
 Optimizarea şi creşterea eficienţei în utilizarea bazelor de date.
1.7 MS-Access – un SGBD modern
Câteva dintre cele mai populare SGBD-uri sau produse soft cu facilităţi de
SGBD, sunt: dBase, Paradox, Clipper, FoxPro, Lotus, QuattroPro, Excel, Access,
Oracle, etc. Fiecare utilizator va alege dintre aceste produse pe cel care se
potriveşte cel mai bine dimensiunii bazei de date, aplicaţiei pe care o concepe
şi/sau cunoştinţelor sale în domeniu.
Programul MS-Access se adresează celor care doresc să creeze o bază
de date de complexitate medie, dispunând de o interfaţă prietenoasă, cu un efort
de programare cât mai redus.
1.7.1 MS-Access – componentă Microsoft Office
Programul MS-Access este parte integrantă a pachetului de aplicaţii

Microsoft Office, începând cu versiunea ‘95. Produs al firmei Microsoft, familia de
programe MS-Office lucrează sub sistemul de operare Windows. Există mai
multe versiuni de Microsoft Office care includ diferite combinaţii ale aplicaţiilor
primare şi secundare. Principalele componente ale familiei sunt:
 Microsoft Word – un editor de texte profesional. El permite scrierea, editarea
şi tipărirea documentelor de tip text. Include facilităţi superioare pentru
controlul fontului, stilului şi mărimii caracterelor, configurarea paragrafelor şi
paginilor, crearea şi prelucrarea de tabele, inserarea şi prelucrarea figurilor,
verificarea ortografică şi sintactică a textului în mai multe limbi, realizarea de
sinteze şi cuprinsuri automate, îmbinarea textului în vederea automatizării
corespondenţei, etc.
 Microsoft Excel – un program de calcul tabelar deosebit de complex care
include şi facilităţi rudimentare pentru prelucrarea bazelor de date. El permite
utilizarea unor funcţii complexe incorporate pentru efectuarea calculelor
matematice, statistice şi economice. Aceste calcule pot fi de la cele mai
simple, precum totalul sau media valorilor pe un rând sau o coloană, la cele
mai complexe, precum evaluarea duratei de amortizare a unei investiţii.
Totodată, programul include facilităţi de analiză a datelor şi statistică
economică. Gama largă de funcţii financiare, multitudinea de tipuri de
diagrame disponibile şi interfaţa prietenoasă fac din mediul MS-Excel unul
dintre cele mai utilizate programe.
 Power Point – un sistem grafic pentru crearea prezentărilor pe folii
transparente, hârtie, diapozitive sau pe monitor. El permite formatarea
avansată a textelor, adăugarea de diagrame, imagini, tabele, comentarii şi
elemente de animaţie utilizate pentru mărirea impactului vizual al informaţiei
prezentate.
 Microsoft Access – un sistem profesional de gestiune şi programare pentru
baze de date (iniţial, inclus numai în versiunea profesională a pachetului
MS-Office). El permite memorarea şi organizarea informaţiei în seturi de
tabele, definirea conversaţională şi utilizarea relaţiilor între tabele, interogarea
tabelelor şi afişarea informaţiei sub formă de liste, formulare sau rapoarte,
efectuarea unor operaţii statistice, calculul mediilor şi totalurilor, ordonarea şi
căutarea datelor, realizarea de grafice, etc.
 Microsoft Outlook – un sistem de utilizare a poştei electronice şi de gestionare

a corespondenţei. El permite organizarea mesajelor de poştă electronică,
alcătuirea agendei şi a listelor de lucrări.
 Microsoft Publisher – un program pentru tehnoredactare computerizată. El
oferă instrumentele necesare pentru a crea publicaţii cu aspect profesional,
ca de exemplu buletine informative, foi volante, cărţi de vizită, etc.
 FrontPage – un program de creare pentru Web (inclus în pachetul MS-Office
numai începând cu versiunea 2000). El permite crearea conversaţională a
site-urilor de web, astfel încât rezultatele sunt spectaculoase chiar dacă
utilizatorul are doar foarte puţine cunoştinţe despre sistemul de coduri HTML
(HyperText Markup Language).
Acestor aplicaţii primare li se adaugă aplicaţii secundare sau opţionale; cele
mai utilizate aplicaţii secundare sunt: MS-PhotoDraw, MS-Graph, ClipArt Gallery,
MS-OrganizationChart, Word Art, MS-Map.
Gruparea aplicaţiilor într-un pachet de programe reprezintă mult mai mult

decât adunarea lor sub acelaşi nume. Microsoft Office este un produs soft unitar
care, prin integrarea completă a aplicaţiilor, asigură:
 funcţionarea corelată a aplicaţiilor componente;
 interfaţă grafică (GUI) comună, standard pentru toate aplicaţiile;
 utilizarea în comun a datelor şi resurselor;
 compatibilitatea datelor în caz de transfer de la o aplicaţie la alta;
 comunicarea uşoară între toate aplicaţiile componente pe baza
standardului OLE (Object Linking and Embeding).
1.7.2 Instalare şi lansare
În prezent, aplicaţia Microsoft Access este unul dintre cele mai utilizate
SGBD-uri relaţionale care lucrează sub Windows.
Prima versiune stabilă a programului a fost Access 2.0. Deşi avea toate
caracteristicile unui mediu avansat de programare şi dezvoltare, versiunea 2.0 a
pătruns relativ greu pe o piaţă în care leader absolut era produsul FoxPro.
Principalele motive sunt legate de necesarul superior de resurse hard şi de
reticenţa programatorilor profesionişti faţă de utilizarea obiectelor predefinite şi a
interfeţei grafice în activitatea de programare.
Creşterea performanţelor configuraţiilor hard “uzuale”, integrarea
programului Access în pachetul MS-Office – versiunile ‘95 şi ‘97, facilităţile noi
introduse, precum şi îmbunătăţirile aduse funcţionării produsului, recomandă
mediul MS-Access ca fiind cel mai adecvat realizării aplicaţiilor de gestiune
avansată a bazelor de date de dimensiune şi complexitate medie.
Programul MS-Access 97 este o versiune stabilă care utilizează facilităţile
oferite de arhitectura pe 32 de biţi a sistemului de operare, exploatează memoria
în mod eficient, introduce noi tipuri de date şi noi obiecte, utilizează noul
mecanism Jet 3.5, îmbunătăţeşte utilitarul CodeBuilder şi pe cel de introducere a
comenzilor din module, etc.
Versiunile Access 2000 şi Access XP aduc noi îmbunătăţiri, poate mai
puţin evidente. Din punctul de vedere al utilizatorului, se constată o interfaţă uşor
schimbată, mici modificări în scrierea Macro-urilor, apariţia obiectului Pages şi a
unor noi utilitare, etc.
La fel ca majoritatea produselor Microsoft, diferitele versiuni ale mediului
Access sunt compatibile de sus în jos, dar există mai multe limitări ca la
celelalte programe.
Chiar dacă există “moda”, destul de controversată, a traducerii
programelor în limba română, până în prezent complexitatea produsului Access
a împiedicat apariţia unei versiuni complete în limba română. Pe lângă
dificultatea traducerii profesioniste, unul din motivele întârzierii ar putea fi şi lipsa
de solicitare din partea utilizatorilor. Aceasta, deoarece facilităţile de programare
ale mediului Access vizează totuşi un segment de utilizatori avansaţi, care sunt
obişnuiţi cu folosirea în limba engleză a noţiunilor de informatică.
Configuraţia hard minimă recomandată pentru utilizarea programului

Access 2000 este: PC standard incluzând un procesor Pentium, 32 MB memorie
RAM, 2 GB Hdd, monitor SVGA, tastatură, mouse. Pentru exploatarea facilităţilor
oferite de integrarea aplicaţiilor în pachetul de programe Office 2000, se

recomandă folosirea unui calculator performant care permite instalarea completă
şi utilizarea eficientă a sistemului de operare Windows XP sau a versiunilor
ulterioare. Un eventual program de compresie a discului fix reduce sensibil
performanţele programului. Pentru instalarea pachetului Microsoft Office 2000,
calculatorul trebuie să fie echipat cu o unitate de CD-ROM. Imprimanta nu este
obligatorie, dar se recomandă o imprimantă A4 cu jet de cerneală.
Instalarea programului Access se efectuează de pe CD-ROM-ul de
instalare livrat la cumpărarea produsului. Comanda de instalare a pachetului de
aplicaţii Microsoft Office (setup.exe) se lansează sub sistemul de operare
Windows. Se poate opta pentru o instalare tipică sau pentru instalarea selectivă
a diferitelor componente. La o instalare tipică, Microsoft Office 2000 ocupă cca.
200 MB spaţiu pe hard-disc.
Lansarea în execuţie a programului Access se realizează prin oricare
modalitate permisă de sistemul de operare Windows. Modalităţile uzuale sunt:
 click pe icoana în formă de cheie de culoare galbenă din
MicrosoftOfficeToolbar \ Programs;
 dublu-click pe icoana corespunzătoare în aplicaţia MyComputer. La o
instalare tipică: C: \ ProgamFiles \ MicrosoftOffice \ Office10 \ MSAccess;
 selectarea opţiunii corespunzătoare de pe Taskbar. În mod obişnuit, aceasta
este: Start \ AllPrograms \ MicrosoftAccess.
1.7.3 Interfaţa şi moduri de lucru
Un fişier bază de date creat şi exploatat cu ajutorului mediului Access are

extensia .mdb. Acesta conţine toate obiectele necesare pentru gestionarea
informaţiei aferente aplicaţiei.
Interfaţa mediului MS-Access este asemănătoare cu interfaţa prezentată
de celelalte componente MS-Office. Meniurile şi opţiunile din meniuri permit
lansarea facilităţilor tipice ale programului Access. Din acest motiv, există câteva
diferenţe de interfaţă, sesizabile chiar la deschidere.
Astfel, la crearea unui nou fişier bază de date, mediul Access solicită
precizarea numelui fişierului şi a directorului în care va fi salvat. Conţinutul
fişierului poate fi stabilit doar după denumirea acestuia.
Pentru economie de timp, utilizatorului i se oferă aplicaţii “prefabricate”,
adică şabloane de fişiere, accesibile la crearea unui nou fişier, prin opţiunea
Database Wizard. Şabloanele se referă la baze de date tipice (adrese,
gestionarea contactelor sau a clienţilor, evidenţa şi efectuarea corespondenţei,
aplicaţii de facturare, etc). Modificarea şabloanelor în concordanţă cu necesităţile
utilizatorului se face conversaţional. Totuşi, în mod obişnuit este mai rapidă
creare unei baze de date pornind de la un fişier blank, deoarece structura, datele
de intrare şi situaţiile de ieşire reale, de regulă, diferă foarte mult de cele propuse
de şablon. Mai mult, pentru utilizatorii finali ai aplicaţiei create cu ajutorul
şablonului, trebuie adaptate numele de câmpuri şi traduse meniurile din limba
engleză.
Spre deosebire de semnificaţia generală de salvare a fişierului curent sub
un alt nume sau o altă versiune, opţiunea File \ SaveAs… din MS-Access
permite multiplicarea sau copierea diferitelor obiecte ale bazei de date. Pentru
realizarea unei copii a fişierului .mdb, de exemplu pe o dischetă, trebuie utilizat
un program de gestionare a fişierelor cum ar fi Windows Explorer sau
My Computer.
Una dintre facilităţile specifice deosebit de utile este compactarea
fişierului lansată simplu prin opţiunea Tools\ DatabaseUtilities\ Compact and
Repair Database. Aceasta permite reducerea substanţială a dimensiunilor
fişierului bază de date curent prin eliberarea spaţiului neutilizat dar declarat
ocupat. Acest spaţiu excedentar “fals ocupat” provine din zonele în care s-au
stocat temporar date precum şi din nedeclararea liberă a zonelor din care s-au
şters date pe parcursul proiectării sau utilizării aplicaţiei. Se recomandă
compactarea fişierului după fiecare sesiune de lucru sau înainte de copierea lui
pe un alt mediu de stocare.
Mediul Access efectuează salvarea automată a obiectelor după cele mai
multe operaţii ale utilizatorului. Astfel, opţiunea Edit \ Undo este rareori activă,
ceea ce limitează posibilitatea anulării acţiunilor anterioare.
Programul Access permite exploatarea obiectelor în modul de lucru

“utilizare” (termenul englezesc diferă de la obiect la obiect: DatasheetView,
PrintPreview, FormView, etc.) şi “proiectare” (DesignView). Pentru anumite
obiecte există şi un al treilea mod de lucru, specific acestuia.
Comutarea afişării între modurile de lucru permise, se face fie utilizând
opţiunile meniului View, fie acţionând controlul corespunzător de pe bara cu
butoane standard.
Pentru crearea obiectelor există în principal două modalităţi:
 folosirea unui utilitar (Wizard);
 modul de proiectare (Design).
Experienţa arată că pentru crearea fiecărui obiect se recomandă una
dintre modalităţile precizate; pentru modificarea obiectelor se utilizează modul de
lucru Design.
Utilitarele de tip Wizard, pentru introducerea conversaţională a expresiilor
(Build) şi crearea controalelor (ControlWizard) sunt active numai dacă butonul
comutator corespunzător este activat (FIG.4).
FIG.4
Asistenţa soft în timpul utilizării mediului Access este disponibilă în

acelaşi mod ca la celelalte componente Microsoft Office, prin opţiunile meniului
Help de pe bara cu instrumente standard. În plus, majoritatea configuraţiilor de
ecran includ o zonă de Help contextual iar utilitarul de autocompletare se
activează automat ori de câte ori este posibil.
Una dintre principalele facilităţi datorită căreia mediul Access a reuşit să
acapareze un segment relativ mare de utilizatori este posibilitatea de transfer de
date din / către alte SGBD-uri de largă răspândire. Pe lângă compatibilitatea
totală cu tabelele, funcţiile, diagramele şi tabelele pivot din foile de calcul Excel,
mediul Access poate crea cu uşurinţă legături sau realiza importuri de date din
fişierele FoxPro sau Clipper. Obiectele Access pot fi prelucrate cu ajutorul altor
medii de programare, de exemplu VisualBasic sau VisualFoxPro.
2. OBIECTE MS-ACCESS. CREARE, UTILIZARE, PROPRIETĂŢI.
Un fişier bază de date al mediului Access este o colecţie de obiecte care

implementează o aplicaţie destinată gestionării datelor folosind mediul de
programare şi dezvoltare MS-Acces. Pentru denumirea fişierului se utilizează
regulile obişnuite ale sistemului de operare Windows. Extensia implicită a
fişierului bază de date este .mdb. Alte extensii uzuale ale mediului MS-Access
sunt: .mda pentru fişierele care conţin biblioteci de programe şi .mde, în care
codul VBA apare sub formă executabilă şi se utilizează pentru front-end
databases.
Obiectele conţinute de un fişier bază de date sunt:
 Tabele (Tables)
 Interogări sau Cereri de interogare (Queries)
 Formulare sau Forme (Forms)
 Rapoarte (Reports)
 Pagini web (Pages)
 Macro-uri (Macros)
La lansarea obişnuită a programului MS-Access, este afişată fereastra
Database prin intermediul căreia utilizatorul poate accesa diferitele obiecte în
vederea creării, modificării, afişării sau utilizării lor.
Denumirea obiectelor se realizează la prima salvare. Se recomandă:
 respectarea convenţiilor uzuale privind denumirea obiectelor (tbl, qry, frm,
rpt, pag, mac, etc.);
 folosirea unor nume care să sugereze rolul obiectului în cadrul aplicaţiei;
 evitarea caracterelor “space” şi “hyphen” deoarece ulterior complică
sintaxa comenzilor.
În cele ce urmează, se vor prezenta succint obiectele utilizate de mediul

MS-Access şi principalele lor proprietăţi. Exemplele sunt astfel concepute încât
să parcurgă paşii necesari pentru construirea unei aplicaţii de gestiune a unui
examen de admitere cu două probe.
2.1 Tabele
Tabelele sunt obiecte Access care îndeplinesc rolul de organizare şi

stocare a datelor. Tabelul este o colecţie organizată de componente de acelaşi
tip. Componentele se numesc înregistrări (Records) sau articole. Structura
tabelului, deci şi structura fiecărui articol în parte, se compune din câmpuri.
Tabelele se creează de obicei în modul Design şi poartă denumiri după
şablonul tbl_numetabel sau tblNumetabel. În modul de lucru DatasheetView,
selectarea, ştergerea şi dimensionarea liniilor şi coloanelor se face asemănător
cu operaţiile similare efectuate în mediul MS-Excel.
Crearea tabelelor se face în mod asemănător creării fişierelor .dbf din
mediul FoxPro. Fereastra uzuală pentru crearea tabelelor este prezentată în
FIG.5. Astfel, crearea unui tabel înseamnă precizarea structurii de câmpuri, a
tipului de date care se va stoca în acestea şi a proprietăţilor lor. Descrierea
câmpului este facultativă şi are rol de comentariu.
FIG.5
Conţinutul zonei FieldProperties se modifică în funcţie de tipul câmpului,

oferind posibilitatea stabilirii proprietăţilor specifice tipului respectiv de date.
Proprietăţile de formatare şi validare a datelor sunt grupate în tab-ul General iar
cele referitoare la căutarea datelor sunt grupate în tab-ul LookUp.
2.1.1 Tipuri de date
Datele cu care operează mediul MS-Access se deosebesc după tipul

valorilor pe care le reprezintă. Stabilirea tipului de date care se va memora
într-un câmp măreşte simplitatea şi siguranţa manipulării informaţiei.
Tipurile de câmpuri admise de Access sunt:
 tipul text (Text)
 tipul memo (Memo)
 tipul numeric (Number)
 tipul dată calendaristică (Date/Time)
 tipul simbol monetar (Currency)
 tipul numerotare automată (AutoNumber)
 tipul logic (Yes/No)
 tipul OleObject (OLE Object)
 tipul HyperLink
 LookUp Wizard…
Câmpul de tip Text are o lungime de maxim 255 caractere şi poate să

conţină litere mici şi majuscule, cifre şi semne speciale cuprinse în tabela ASCII.
Câmpurile de tip text se aliniază automat la stânga, iar informaţia conţinută în
acestea se memorează exact aşa cum a fost introdusă.
Principalele proprietăţi ale unui câmp de tip text sunt: FieldSize, Format,
Caption, DefaultValue, ValidationRule, Required, Indexed.
Proprietatea FieldSize permite stabilirea lungimii maxime a datelor,
contribuind la dimensionarea corectă a fişierului şi utilizarea eficientă a memoriei.
Proprietatea Format permite stabilirea unui şablon pentru datele din câmp.
Mediul Access include un număr de şabloane prestabilite, dar utilizatorul îşi
poate defini propriile şabloane. Principalele caractere folosite în definirea
şabloanelor pentru câmpurile de tip text sunt:
- @ - acceptă doar introducerea unui caracter de tip text sau a unui spaţiu;
- > - transformă textul introdus în majuscule (UpperCase);
- < - transformă textul introdus în caractere mici (LowerCase);
- # - acceptă doar introducerea unei cifre, afişează o cifră sau nimic;
- 0 - acceptă doar introducerea unei cifre, afişează o cifră sau „0”.
Pentru valorile Null sau ZeroLength se pot defini valori iniţiale implicite după
sintaxa “şablon câmp ; valoare în caz de Null sau lungime Zero”.
De exemplu, pentru a converti în majuscule, automat, la introducerea
datelor, valorile unui câmp Numele, se va utiliza şablonul “>”. Pentru
un câmp NumeleTatalui, se poate utiliza şablonul “> ; necunoscut”;
astfel, în cazul în care lipseşte numele tatălui unui candidat, câmpul
va fi completat automat cu valoarea “necunoscut”.
Proprietatea Caption permite afişarea în capul de tabel a unui text diferit
de numele câmpului.
De exemplu, dacă pentru simplitate un câmp a fost denumit
Nume_Pren, pentru utilizatorul aplicaţiei se poate afişa textul: Numele
şi Prenumele.
Proprietatea DefaultValue stabileşte o valoare implicită pentru câmpul
respectiv, valoare care se introduce automat în cazul în care utilizatorul nu
efectuează modificări asupra ei.
De exemplu, dacă tabelul conţine candidaţii pentru o şcoală militară,
unde majoritatea sunt băieţi, un câmp denumit Sexul_(M/F) va fi
iniţializat cu valoarea “M”, economisind astfel timp la introducerea
datelor.
Proprietatea ValidationRule permite validarea datelor la introducere,
adică stabilirea unor condiţii pe care datele trebuie să le îndeplinească pentru a fi
acceptate. Se elimină astfel o mare parte a greşelilor de operare la culegerea
datelor. Regula de validare conţine o expresie a cărei evaluare conduce la un
rezultat de tip logic. În mod implicit, comparaţia cu o valoare introdusă este

efectuată non case sensitive.
De exemplu, în cazul câmpului Sexul_(M/F), regula de validare poate
fi “M” or “F”. Operatorul poate introduce valorile “M”, “m”, “F”, sau “f”.
Proprietatea Required poate avea valoarea Yes sau No, şi stabileşte dacă
valoarea câmpului poate rămâne necompletată. Astfel se poate evidenţia setul
minimal de date necesar de cunoscut la introducerea unui articol.
Proprietatea Indexed poate avea valorile No, Yes (NoDuplicates) sau Yes
(DuplicatesOK). Un câmp index serveşte pentru aplicarea tehnicilor de căutare
rapidă a informaţiei în baza de date. În plus, clauza NoDuplicates contribuie la
validarea datelor prin împiedicare introducerii unei valori atribuite anterior
aceluiaşi câmp dintr-un alt articol.
De exemplu, dacă identificarea univocă a candidaţilor la examenul de
admitere se face pe baza legitimaţiei de concurs, câmpul Legitimaţie
va avea proprietatea Indexed = Yes (NoDuplicates), evitând
introducerea accidentală a doi candidaţi cu acelaşi număr pe
legitimaţia de concurs.
Observaţie: Proprietăţile Caption, DefaultValue, ValidationRule, Required,
Indexed se regăsesc la majoritatea tipurilor de câmp utilizate în tabelele Access.
Câmpul de tip Memo se utilizează pentru introducerea unor comentarii la

fiecare articol. Valoarea unui astfel de câmp nu poate fi folosită pentru calcule,
sortare sau indexare. Spre deosebire de mediul FoxPro unde datele de tip Memo
implică crearea unui fişier adiţional, mediul Access stochează conţinutul
câmpurilor Memo în fişierul .mdb curent.
Câmpul de tip Number conţine valori numerice formate din cifre, punctul
zecimal şi semn. El prezintă o mare varietate de subtipuri, în funcţie de destinaţia
datelor. Principalele proprietăţi ale unui câmp de tip Number sunt: FieldSize,
Format, DecimalPlaces, Caption, DefaultValue, ValidationRule, Required,
Indexed.
Proprietatea FieldSize serveşte la stabilirea subtipului numeric. Utilizatorul

are la dispoziţie următoarele variante:
- Byte – pentru numere întregi cu valori cuprinse între 0 şi 255, care necesită
1 byte spaţiu de memorie;
- Integer – pentru numere întregi cu valori cuprinse între –32.676 şi 32.767,
care necesită 2 bytes spaţiu de memorie;
- LongInteger – pentru numere întregi cu valori cuprinse între –2.147.483.648 şi
2.147.483.647, care necesită 4 bytes spaţiu de memorie;
- Single – pentru numere zecimale în simplă precizie, cu maxim 7 zecimale,
care necesită 4 bytes spaţiu de memorie;
- Double – pentru numere zecimale în dublă precizie, cu maxim 15 zecimale,
care necesită 8 bytes spaţiu de memorie.
Proprietăţile Format şi DecimalPlaces determină modul de afişare al
datelor în câmp.
De exemplu, pentru numere zecimale de tip Single se poate stabili
afişarea cu 2 cifre zecimale prin valorile Format = Fixed şi
DecimalPlaces = 2.
Observaţie: Celelalte proprietăţi se utilizează în mod similar cu cele
descrise la prezentarea câmpurilor de tip text.
Câmpul de tip Date/Time conţine o valoare care reprezintă data şi / sau

ora. Validarea datelor se face la introducere, astfel încât să fie reale din punct de
vedere calendaristic şi conforme cu formatul activ.
Principalele proprietăţi ale unui câmp de tip Date/Time sunt: Format,
Caption, DefaultValue, ValidationRule, Required, Indexed.
Proprietatea Format determină modul de introducere / afişare a datei şi
orei. Şabloanele aflate la dispoziţia utilizatorului sunt similare celor folosite de
mediul Excel.
Observaţie: Celelalte proprietăţi se utilizează în mod similar cu cele
descrise la prezentarea câmpurilor de tip text.
De exemplu, există posibilitatea introducerii rapide a datei curente
prin utilizarea proprietăţii DefaultValue = Date().
Câmpul de tip Currency permite afişarea automată a simbolului monetar

activ. Simbolul monetar activ este cel preluat din setările sistemului de operare.
Principalele proprietăţi ale unui câmp de tip Currency sunt: Format,
DecimalPlaces, Caption, DefaultValue, ValidationRule, Required, Indexed.
Combinarea valorilor pentru proprietăţile Format şi DecimalPlaces
determină modul de afişare a valorilor monetare.
Operaţiile ulterioare cu valorile unui câmp de tip Currency păstrează
automat afişarea simbolului monetar.
Câmpul de tip AutoNumber este specific mediului Access, începând cu

versiunea ‘95. Valorile unui câmp AutoNumber sunt atribuite automat la
introducerea unui nou articol.
Principalele proprietăţi ale unui câmp de tip AutoNumber sunt: FieldSize,
NewValues, Format, Caption, Indexed.
Proprietatea FieldSize are valoarea implicită LongInteger.
Proprietatea NewValues determină plaja de valori permise şi modul de
atribuire a acestora pentru articolele din tabel. Opţiunile aflate la dispoziţia
utilizatorului sunt:
- Increment – pentru numerotarea automată, crescătoare, în ordinea
introducerii articolelor;
- Random – pentru atribuirea unor valori aleatoare;
Dacă proprietatea Indexed se stabileşte la valoarea Yes (NoDuplicates), în

cazul ştergerii unor articole din tabel, valorile şterse ale câmpului de tip
AutoNumber nu pot fi atribuite câmpului corespunzător al articolelor nou
introduse.
De exemplu, în cazul câmpului Legitimaţie, de tip AutoNumber \
Increment, dacă s-au şters din tabel candidaţii cu numărul de
legitimaţie 4 şi 5, la introducerea unor noi candidaţi, următorul număr
de legitimaţie va fi 6, iar numerele 4 şi 5 nu mai pot fi atribuite.
Câmpul de tip Yes/No poate conţine numai valorile Yes, True sau On
pentru valoarea logică “adevărat” şi respectiv No, False sau Off pentru valoarea
logică “fals”. La introducerea datelor, câmpul de tip logic, independent de
formatul ales, este reprezentat printr-un control de tip CheckBox.
De exemplu, se poate considera un câmp logic Platit prin care se
verifică plata taxei de înscriere la concurs. În cazul în care
candidatul a plătit taxa, operatorul va “bifa” controlul; în caz contrar,
CheckBox-ul rămâne neselectat.
Principalele proprietăţi ale unui câmp de tip Yes/No sunt: Format,
DefaultValue, Caption, Required, Indexed.
Câmpul de tip OLE Object conţine un obiect legat sau încapsulat, după
regulile de legare şi încapsulare ale standardului OLE (Object Linking and
Embeding).
Valorile unui astfel de câmp sunt, de obicei, obiecte grafice care pot fi
inserate în următoarele moduri:
- crearea unui obiect grafic nou, cu ajutorul unei aplicaţii externe accesate
prin opţiunea Insert\Object…\CreateNew;
- inserarea unui fişier grafic creat şi salvat anterior, prin opţiunea
Insert\Object…\CreateFromFile;
- lipirea directă în câmp (Ctrl+V) a conţinutului Clipboard-ului.
La utilizarea tabelelor, vizualizarea obiectelor conţinute într-un câmp de tip
OleObject se realizează cu ajutorul aplicaţiei sursă în care a fost creat obiectul.
Aceasta se lansează automat la executarea unui double-cllick pe câmpul
respectiv. La utilizarea formularelor se poate opta pentru vizualizarea imediată a
conţinutului tuturor câmpurilor.
Dimensiunea obiectelor legate sau încapsulate poate fi de max. 1GB, fiind
limitată doar de spaţiul disponibil pe hard-disc.
Datorită tipului de date stocate, un câmp de tip OleObject nu poate fi folosit
pentru sortare, indexare, efectuarea de calcule, etc.
De exemplu, fotografia candidaţilor poate fi scanată şi introdusă
direct într-un câmp Poza, de tip OleObject.
Fie o bază de date care ţine evidenţa clădirilor pentru un serviciu de

cadastru, iar planurile clădirilor au fost desenate anterior cu mediul
AutoCad şi sunt salvate pe hard-disc. Mediul Access poate pune la
dispoziţia utilizatorului aceste planuri prin legarea lor într-un câmp
Schita, de tip OleObject.
Câmpul de tip HyperLink poate conţine o combinaţie de litere, cifre şi

caractere specifice, cu lungimea maximă de 3 x 2048 caractere, care reprezintă
o adresă de web. Cel mai simplu mod de introducere a datelor în câmp este
utilizarea meniului Insert \ Hyperlink…
LookUp Wizard este un utilitar care serveşte pentru introducerea

conversaţională a datelor memorate în prealabil în alte tabele, interogări sau
liste. Astfel se pot introduce date de diverse tipuri. Totodată, cu ajutorul utilitarului
LookUp Wizard se pot crea relaţii între tabele definindu-se cheile străine.
După sursa datelor, Lookup Wizard poate fi:
 cu căutare într-o listă explicită;
 cu căutare într-un tabel şi stabilirea de relaţii.
Modul de utilizare şi rezultatele obţinute se vor prezenta în capitole separate.
Operaţiile de gestiune specifice sunt aplicabile datelor în funcţie de tipul
acestora. Ca atare, la proiectarea tabelelor din baza de date trebuie să se ţină
cont de viitoarele modalităţi de prelucrare. Pentru compatibilitate, dacă este
posibil, datele se pot supune unor conversii de tip efectuate automat sau explicit.
2.1.2 Exemplu
Pentru aplicaţia de evidenţă a concursului de admitere cu două probe,

datele se vor organiza în tabele astfel:
 tbl_Candidati – conţine date referitoare la datele personale ale candidaţilor;
 tbl_Probe – conţine date referitoare la disciplinele de concurs;
 tbl_Note – conţine date referitoare la rezultatele probelor de concurs.
Proiectarea tabelelor respectă principiul separării datelor pentru a evita

inconsistenţa datelor şi a permite crearea de legături logice.
Paşii semnificativi în vederea creării tabelului tbl_Candidati, din punctul de
vedere al configuraţiei ecranului şi al opţiunilor disponibile, sunt ilustraţi şi
comentaţi în figurile următoare.
FIG.6
Alegerea tipului Autonumber

pentru a atribui automat, câte un
număr de legitimaţie fiecărui
candidat, pe măsura înscrierii în
baza de date
FIG.7 FIG.8
Se alege o lungime de max. 15 Pentru câmpul DataNast se alege
caractere pentru câmpul Nume. formatul de dată MediumDate şi
Proprietatea Indexed = Yes proprietatea Caption =Data
(DuplicatesOK) permite introdu- nasterii.
cerea a doi candidaţi cu acelaşi Comentariile apar în dreptul
nume fiecărui câmp.
FIG.10
Se alege tipul OLE object pentru
câmpul Poza
FIG.9
Pentru câmpul Sexul se stabileşte valoarea
iniţială şi condiţia de validare la introducere
FIG.11
După salvarea tabelului şi stabilirea cheii primare, valoarea câmpului Poza se
preia dintr-un fişier grafic salvat anterior. Se selectează opţiunea Link pentru a
realiza legarea şi nu încapsularea imaginii. În locul imaginii, în tabel apare
descrierea obiectului (ImageObject)
În articolul nou, se observă valoarea implicită stabilită pentru câmpul Sexul.
2.2 Cheia primară. Utilitarul LookUp Wizard
Puterea SGBD-urilor relaţionale constă în tratarea simultană a datelor

provenite din mai multe tabele distincte, prin intermediul obiectelor care
exploatează relaţiile logice dintre acestea.
Cheia primară şi relaţiile construite pe baza ei reprezintă instrumente prin
care se realizează căutarea şi prelucrarea informaţiei în mod specific bazelor de
date relaţionale.
2.2.1 Noţiunea de cheie primară
Cheia unei tabele reprezintă un ansamblu minim de atribute care identifică

în mod unic o înregistrare din tabelă. Cheia poate fi formată dintr-un singur
atribut (cheie simplă) sau din mai multe atribute (cheie compusă).
Determinarea cheii necesită cunoaşterea semnificaţiei atributelor din
tabelă. La un moment dat, într-o tabelă pot exista mai multe atribute sau
combinaţii de atribute care au proprietatea că pot identifica o înregistrare; aceste
combinaţii se numesc chei candidate. Dintre aceste chei candidate se alege o
combinaţie care se foloseşte efectiv. Această combinaţie se numeşte cheie
primară.
În cazul cel mai simplu, cheia primară sau principală este un câmp prin a
cărui valoare se pot identifica univoc articolele din tabel. După ce utilizatorul
desemnează cheia primară a tabelului, mediul Access va supraveghea
permanent datele care se introduc în câmpul respectiv. La încercarea
utilizatorului de a introduce o valoare care a fost deja atribuită, programul Access
sesizează această greşeală şi solicită corectarea ei.
Cel mai des utilizate sunt cheile primare de tip AutoNumber, deoarece ele
identifică univoc articolele prin însăşi natura datelor permise pentru acest tip.
Dacă proiectul tabelului nu permite includerea unui câmp cu valori unice,
se poate realiza o cheie primară prin combinarea a două sau mai multe câmpuri.
De exemplu, cheie primară poate fi:

- în tabelul tbl_Candidati: numărul legitimaţiei de concurs;
- în tabelul tbl_EvidentaPopulatiei: codul numeric al persoanei;
- în tabelul tbl_ SocietatiComerciale: codul unic de înregistrare.
Pentru stabilirea câmpului cheie primară, utilizatorul are la dispoziţie
următoarele modalităţi:
 Explicit, prin utilizarea butonului PrimaryKey, în formă de cheiţă galbenă, de
pe bara cu instrumente;
 La prima salvare a tabelului, în caz că utilizatorul nu a folosit metoda explicită,
mediul Access afişează un mesaj de avertizare. Utilizatorul poate reveni la
metoda explicită, sau poate lăsa la latitudinea mediului Access să stabilească
câmpul cheie primară. Astfel:
 Dacă în tabel există un câmp de tip AutoNumber, programul Access
îl va alege drept cheie primară.
 Dacă tabelul nu conţine nici un câmp de tip AutoNumber, mediul
Access va crea automat un nou câmp – cheie primară, de tip
AutoNumber, pe care îl va insera la prima poziţie a structurii tabelului.
 Dacă utilizatorul optează pentru un tabel fără cheie primară (nerecomandat),
el poate atribui ulterior oricărui câmp atributul de cheie primară. Operaţia este
posibilă dacă valorile deja introduse în câmpul respectiv sunt unice.
2.2.2 Exemplu
Pentru aplicaţia de evidenţă a admiterii se parcurg următorii paşi:
FIG.12
Pentru tabelul
tbl_Candidati, prin
selectarea câmpului
Legitimaţie şi activarea
butonului PrimaryKey, se
stabileşte explicit cheia
primară.
FIG.13
Se creează şi se salvează tabelul tbl_Probe.
FIG.14
Access afişează mesajul de avertizare.
FIG.15
Dacă utilizatorul selectează opţiunea Yes, mediul Access caută (şi găseşte !)
un câmp de tip AutoNumber pe care îl desemnează cheie primară. Se încheie
salvarea tabelului.
2.2.3 Afişarea datelor dintr-o listă folosind Lookup Wizard
Folosind utilitarul Lookup Wizard se pot crea câmpuri care aleg şi afişează
date memorate în prealabil într-o listă cu număr fix de valori.
Lista cu valori se introduce la crearea câmpului şi se poate modifica în
modul proiectare. Tipul câmpului este determinat de tipul datelor stabilit înainte
de lansarea utilitarului Lookup Wizard.
Principalele proprietăţi din tab-ul General utilizate de câmpurile de acest
tip sunt: FieldSize, Required, Indexed. În mod obişnuit valorile se repetă în câmp,
prin urmare pentru proprietatea Indexed sunt recomandat valorile No sau
Yes (DuplicatesOK).
Cele mai importante proprietăţi ale câmpurilor create folosind utilitarul
Lookup Wizard sunt grupate în tab-ul Lookup. Acestea sunt: DisplayControl,
RowSourceType, RowSource, BoundColumn, ColumnCount, ColumnWidth,
ListRows, ListWidth, LimitToList.
Semnificaţia şi modul de utilizare ale acestor proprietăţi vor fi ilustrate în
exemplele prezentate în continuare.
2.2.4 Exemplu
FIG.16
În structura tabelului
tbl_Candidati se inserează
câmpul Oraşul.
Se presupune că majoritatea
candidaţilor provin din
câteva localităţi; la
introducerea datelor,
utilizatorul va avea la
dispoziţie o listă derulantă
din care să aleagă datele.
FIG.17
Din dialogul utilitarului se alege sursa datelor
(de la tastatură la crearea tabelului).
FIG.18
Se introduce lista cu valorile cel mai des folosite.
Trecerea la valoarea următoare se face prin coborârea cursorului cu
ajutorul tastei “săgeată jos”. Apăsarea tastei “Enter” determină trecerea
la pasul următor.
FIG.19
Aspectul tab-ului FieldProperties\Lookup
după închiderea utilitarului Lookup Wizard.
Observaţii:
 Tipul câmpului rămâne Text; folosirea utilitarului LookupWizard este
evidenţiată prin proprietăţile grupate în tab-ul Lookup.
 DisplayControl – stabileşte tipul controlului care conţine valorile posibile
(implicit: ComboBox).
 RowSourceType – specifică sursa datelor. Pentru o listă care conţine valori
introduse explicit de la tastatură, RowSourceType este setată automat la
valoarea ValueList.
 RowSource – conţine valorile posibile pentru câmpul considerat. În modul
Design, proprietatea poate fi modifică explicit prin adăugarea unor noi valori;
separatorul folosit este caracterul “ ; ”.
 LimitToList - stabileşte dacă valorile posibile pentru câmp se limitează la
cele cuprinse în listă sau utilizatorului i se va permite şi introducerea unei
valori în afara listei explicite.
Dacă LimitToList = No, operatorul va putea tasta o valoare care nu se află în

lista explicită. Valoarea nouă se introduce în câmp dar nu se adaugă automat
listei şi nu va fi disponibilă pentru articolele următoare.
Notă: Completarea listei se poate realiza printr-o secvenţă VBA.
 Proprietăţile BoundCoumn şi ColumnCount sunt semnificative doar în cazul
folosirii unei liste cu mai multe coloane. Lista explicită creată cu utilitarul
Lookup Wizard conţine, de obicei, o singură coloană, prin urmare mediul
Access stabileşte pentru aceste proprietăţi valoarea 1.
 Proprietăţile ColumnHeads, ColumnWidth, ListRows şi ListWidth stabilesc
aspectul listei derulante în cazul afişării tabelului în modul DataSheet.
FIG.20
Dacă LimitToList = No, în modul DataseetView se poate
introduce o valoare care nu există în lista originală.
2.2.5 Lookup Wizard folosind un alt tabel
Folosind cealaltă variantă utilitarul Lookup Wizard se pot crea câmpuri

care aleg şi afişează date memorate în prealabil într-un alt tabel Access. Sursa
datelor poate fi şi o interogare Access, dar deoarece interogările se construiesc
pe baza tabelelor, iar procedura de folosire a utilitarului Lookup Wizard este
similară, în continuare se va trata numai cazul tabelului.
Tabelul sursă a datelor trebuie creat şi salvat anterior în aceeaşi bază de
date. După aplicarea procedurii Lookup Wizard, orice modificare (redenumirea
tabelului sursă sau a unor câmpuri, schimbarea tipului de date, etc.) atrage după
sine necesitatea de modificare manuală a proprietăţilor câmpului care se
bazează pe Lookup Wizard.
Majoritatea proprietăţilor utilizate de câmpurile create cu ajutorul
utilitarului Lookup Wizard, adică: FieldSize, Required, Indexed, DisplayControl,
RowSourceType, ColumnWidth, ListRows, ListWidth, LimitToList, au fost
prezentate şi exemplificate anterior.
Modul de utilizare a proprietăţile RowSource, BoundColumn şi
ColumnCount diferă faţă de situaţia anterioară, în care sursa datelor era o listă
explicită. Astfel:
 RowSource conţine o interogare bazată pe tabelul sursă. Ea defineşte modul
de selectare şi afişare a datelor în câmp. Interogarea este creată automat de
utilitarul LookupWizard şi afişată în modul SQL View; pentru eventuale
modificări, utilizatorul poate comuta în modul Design, mult mai uşor de folosit.
 ColumnCount specifică numărul de coloane pe care le utilizează Lookup
Wizard pentru afişare în lista derulantă.
 BoundColumn reprezintă numărul de ordine al coloanei, dintre cele cuprinse
în interogare, care va deveni valoare a controlului ComboBox.
Observaţie: În mod implicit, indiferent de tipul de dată stabilit anterior,
câmpul creat cu ajutorul utilitarului Lookup Wizard având ca sursă a datelor un
alt tabel, va prelua tipul datelor din câmpul cheie primară a tabelului sursă. În
urma selectării unei valori din ComboBox, în câmp NU se va introduce valoarea
vizualizată ci tocmai valoarea cheii primare a articolului corespunzător din
tabelul sursă.
De exemplu: Pentru o cheie primară de tip Autonumber noul câmp
va fi de tipul Numeric \ LongInteger, pentru o cheie primară de tip
Text, noul câmp va fi tot de tipul Text.
Pentru a obţine un comportament diferit de cel implicit, utilizatorul trebuie
să efectueze modificări în modul DesignView al interogării din câmpul
RowSource după care să ajusteze valorile celorlalte proprietăţi.
Clarificarea noţiunilor prezentate se realizează prin exemplele care
urmează şi coroborarea lor cu noţiunile privind relaţiile.
2.2.6 Exemplu
FIG.21
Se creează tabelul tbl_Note.

Câmpurile Candidat şi Proba
sunt de tip Text.
Pentru câmpul Nota, se alege
un tip numeric cu 2 zecimale şi
se aplică o condiţie de validare
NU se introduc date în tabel.

Datele pentru câmpurile
Candidat şi Proba se vor selecta
din tabelele create anterior.
FIG.22
În fereastra Database, obiectele apar în ordine alfabetică, independent
de ordinea în care au fost create.
FIG.23
Pentru
câmpul
Candidat
din tabelul
tbl_Note se
lansează
utilitarul
Lookup
Wizard.
FIG.24
Se alege tabelul
tbl_Candidati ca
sursă a datelor
pentru câmpul
Candidat din
tabelul tbl_Note.
FIG.25
Folosind
butoanele
“săgeţi” se
selectează
cheia
primară a
tabelului
sursă şi
câmpurile
care vor fi
afişate în
lista
derulantă.
FIG.26
Utilitarul
afişează
macheta listei
derulante şi
propune
ascunderea
cheii primare.
FIG.27
După denumire şi salvare, se vor introduce date în modul DatasheetView.
La afişare, lista conţine toate câmpurile; după selectare se afişează primul câmp
vizibil, iar valoarea controlului ComboBox e dată de valoarea câmpului desemnat
prin proprietatea BoundColumn = 1.
FIG.28
În modul Design se pot vizualiza proprietăţile câmpului creat cu utilitarul Lookup
Wizard. Câmpul a preluat numele şi tipul cheii primare din tabelul sursă (Legitimatie de
tip LongInteger) iar vechea denumire este atribuită ca valoare a proprietăţii Caption.
Corespunzător tipului numeric şi proprietăţii BoundColumn = 1 în câmp se memorează
valoarea câmpului Legitimatie.
Notă: la unele versiuni ale Access, se păstrează numele iniţial al câmpului destinaţie.
FIG.29
Interogarea
RowSource poate fi
vizualizată în modul
DesignView. Ea se
modifică similar cu
modul de prelucrare a
oricărei interogări de
tip Select.
FIG.30
Pentru câmpul Proba, se

foloseşte utilitarul Lookup
Wizard.
Se include câmpul cheie
primară ProbaID (ascuns)
şi Proba din tabelul
tbl_Probe.
Figura prezintă valoarea
proprietăţilor din tab-ul
Lookup, după salvarea
tabelului. Interpretarea lor
este similară celei
prezentate pentru câmpul
Candidat.
FIG.31
Se introduc date în
tabelul tbl_Note,
folosind listele
create prin utilitarul
Lookup Wizard.
2.3 Relaţii
Relaţiile reprezintă o legătură logică între tabele sau interogări. Relaţiile au

rolul de “a lega” datele stocate în mai multe tabele astfel încât ele să poată fi
manipulate împreună. Utilizând relaţiile se asigură separarea, consistenţa şi
integritatea datelor.
Principalele modalităţi pentru definirea relaţiilor sunt:
 folosirea utilitarului Lookup Wizard având un alt tabel ca sursă a datelor;
 direct, în fereastra Relationships.
2.3.1 Fereastra Relationships
Utilizând fereastra Relationships se pot vizualiza, şterge, crea sau edita

relaţiile între tabelele Access.
Afişarea ferestrei Relationships se realizează cu ajutorul butonului
corespunzător de pe bara cu instrumente (FIG.32), butonul este activ numai
dacă toate obiectele bazei de date sunt închise.
FIG.32
În FIG.33 se prezintă configuraţia ecranului cu vizualizarea ferestrei

Relationships. Pentru exemplificare, s-a considerat cazul concret al aplicaţiei
referitoare la admitere.
Tabele sunt reprezentate sugestiv, folosind numele lor şi al câmpurilor.
Relaţiile create între tabele sunt simbolizate printr-o linie care leagă câmpurile
corespondente.
FIG.33
Utilizarea ferestrei Relationships implică în principal următoarele operaţii:

 vizualizarea tuturor relaţiilor existente, prin acţionarea butonului ShowAll
Relationships (FIG.34);
 vizualizarea relaţiilor în care este implicat tabelul selectat, prin acţionarea
butonului ShowDirectRelationships (FIG.35);
 repoziţionarea tabelelor în fereastra Relationships, prin deplasarea lor cu
ajutorul mouse-ului;
 vizualizarea unor tabele în vederea creării de noi relaţii, prin acţionarea
butonului ShowTable (FIG.36) şi selectarea din listă a unui tabel existent;
 selectarea unei relaţii, prin click pe linia care îi corespunde; o relaţie selectată
este marcată printr-o linie îngroşată (FIG.37);
 modificarea relaţiei selectate (editare sau ştergere), prin click cu butonul drept
al mouse-ului pe linia care simbolizează relaţia (FIG.37);
 Imprimarea şi închiderea ferestrei, cu sau fără salvarea modificărilor operate,
în modul obişnuit de manipulare a unei ferestre Windows.
FIG.34 FIG.35 FIG.36

FIG.37
Ştergerea unei relaţii se realizează prin selectarea ei urmată de operaţia

de ştergere propriu-zisă. Pentru aceasta se efectuează una dintre următoarele:
 se activează opţiunea Delete din meniul suplimentar (FIG.37);
 se acţionează butonul Delete de pe bara cu instrumente;
 se apasă tasta Delete de pe tastatură.
Observaţie: ştergerea unui tabel din fereastra Relationships
determină doar ascunderea tabelului şi a relaţiilor sale directe.
Tabelul şi relaţiile sale rămân memorate în baza de date şi se
pot vizualiza oricând cu ajutorul butonului ShowAll (FIG.34).
Pentru ştergerea efectivă a relaţiei din baza de date, se
procedează în modul descris anterior.
Editarea unei relaţii înseamnă stabilirea proprietăţilor acesteia utilizând
dialogul din FIG.38 şi FIG.40.
2.3.2 Tipuri de relaţii
Legătura definită prin relaţie este o corespondenţă între articolele celor

două tabele implicate. Relaţia se bazează pe un element comun existent în
ambele tabele. De obicei, elementul comun este un câmp care face parte din
structura ambelor tabele; în acest mod se leagă un articol dintr-un tabel de
articolul corespunzător din celălalt tabel, legătura fiind concretizată prin aceeaşi
valoare a câmpului de legătură.
Din punct de vedere al corespondenţei realizate, între două tabele (A şi B)
se pot stabili relaţii de tipul:
 one-to-many sau unu-la-mai-mulţi: fiecare articol din tabelul A poate avea
unul sau mai multe articole corespondente în tabelul B şi fiecărui articol din
tabelul B îi corespunde cel mult un articol în tabelul A. Este tipul de relaţie cel
mai folosit în sistemele de gestiune a bazelor de date.
Câmpul pe baza căruia se creează relaţia este cheia primară din tabelul A.
Câmpul corespondent din tabelul B se numeşte cheie străină.
 one-to-one sau unu-la-unu: fiecare articol din tabelul A poate avea un singur
articol corespondent în tabelul B şi fiecărui articol din tabelul B îi corespunde
cel mult un singur articol în tabelul A. De obicei, cele două tabele au aceeaşi
cheie primară.
În cazul relaţiei unu-la-unu, tabelul B este o “prelungire” a tabelului A. Relaţia
este utilă dacă se doreşte separarea datelor în vederea protejării lor sau dacă
tabelul A are prea multe coloane şi o parte din ele se pot “muta” în tabelul B.
 many-to-many sau mai-mulţi-la-mai-mulţi: pe baza unui câmp, mai multe
articole din tabelul A sunt în corespondenţă cu mai multe articole din
tabelul B, adică unui articol din tabelul A îi corespund mai multe articole din
tabelul B şi invers, unui articol din tabelul B îi corespund mai multe articole din
tabelul A. Prin crearea unui tabel intermediar, o relaţie de tipul mai-mulţi-la-
mai-mulţi se descompune în două relaţii de tipul unu-la-mai-mulţi. De obicei,
tabelul de legătură are o semnificaţie utilă pentru aplicaţie.
De exemplu, pentru relaţiile prezentate în FIG.37:
 relaţia dintre tabelul tbl_Candidati şi tbl_Note este de tipul unu-la-mai-mulţi

realizată pe baza câmpului Legitimaţie. În sensul celor de mai sus, un
candidat va avea mai multe note adică, unui articol din tabelul tbl_Candidati îi
pot corespunde mai multe articole din tbl_Note.
Câmpul Legitimaţia (având Caption = “Candidat”) din tabelul tbl_Note este
cheia străină a tabelului tbl_Note faţă de tabelul tbl_Candidaţi.
 relaţia dintre tabelul tbl_Probe şi tbl_Note este de tipul unu-la-mai-mulţi

realizată pe baza câmpului ProbaID. În sensul celor de mai sus, la o probă se
vor acorda mai multe note (câte una pentru fiecare lucrare), adică unui articol
din tabelul tbl_Probe îi pot corespunde mai multe articole din tbl_Note.
Câmpul ProbaID (având Caption = “Proba”) din tabelul tbl_Note este cheia
străină faţă de tabelul tbl_Probe.
 relaţia dintre tabelul tbl_Candidati şi tbl_Probe este de tipul mai-mulţi-la-mai-
mulţi. Astfel, mai mulţi candidaţi susţin mai multe probe, adică un candidat
susţine mai multe probe şi în acelaşi timp, o probă este susţinută de mai mulţi
candidaţi. În sensul celor de mai sus, mai multor articole din tabelul
tbl_Candidati le corespund mai multe articole din tabelul tbl_Probe, şi invers,
mai multor articole din tabelul tbl_Probe le corespund mai multe articole din
tabelul tbl_Candidaţi.
 pentru a exemplifica o relaţie de tipul unu-la-unu se poate crea un tabel
tbl_DatePersonale, care să conţină date suplimentare referitoare la fiecare
candidat (FIG.39).
Cheia primară a noului tabel va fi câmpul Legitimaţie, de tip LongInteger,
pentru a asigura compatibilitate cu cheia primară a tabelului tbl_Candidati de
tip Autonumber. Relaţia se va crea prin utilitarul Lookup Wizard, aplicat la
definirea câmpului Legitimaţie din tabelul tbl_DatePersonale; sursa datelor
este tabelul tbl_Candidati.
2.3.3 Proprietăţile relaţiilor
Pentru editarea unei relaţii în vederea stabilirii proprietăţilor acesteia, se

utilizează dialogul Edit Relationship…, prezentat în FIG.38. El corespunde
relaţiei unu-la-mai-mulţi creată între tabelele tbl_Probe şi tbl_Note, conform
situaţiei din FIG.37.
FIG.38
În această fereastră, cele mai importante opţiuni se referă la:

 posibilitatea de a impune integritatea referenţială (Referential Integrity);
 tipul asocierii dintre tabele, adică modul de alegere a articolelor care să
realizeze corespondenţa (Join Type).
Impunerea integrităţii referenţiale este un procedeu prin care se

efectuează o analiză logică a datelor introduse în tabel şi se efectuează o
validare a datelor în sensul respectării acesteia. Regulile care se verifică în cazul
impunerii integrităţii referenţiale sunt:
 În câmpul cheie străină a tabelului B pot fi introduse numai valorile care
aparţin mulţimii de valori a cheii primare din tabelul A. Singura excepţie
este valoare Null, adică se permite necompletarea valorii cheii străine.
 Dacă unui articol din tabelul A îi corespund unul sau mai multe articole
din tabelul B, atunci valoarea câmpului cheie primară a tabelului A nu
poate fi editată.
 Dacă unui articol din tabelul A îi corespund unul sau mai multe articole
din tabelul B, atunci nu se permite ştergerea articolului respectiv din
tabelul A. Astfel nu există posibilitatea ca în tabelul B să rămână
articole care contravin primei reguli.
Totuşi, pentru cazul în care utilizatorul doreşte, există posibilitatea de a

efectua ştergeri sau modificări de articole în tabelul A. Prin validarea opţiunii
Cascade Delete Related Records din caseta de dialog (FIG.38) ştergerea unui
articol din tabelul A va determina ştergerea imediată a tuturor articolelor asociate
din tabelul B. Similar, prin validarea opţiunii Cascade Update Related Fields din
caseta de dialog, orice modificare a unui articol din tabelul A se va regăsi în
câmpul corespunzător din tabelul B.
FIG.39
Din punct de vedere grafic, impunerea integrităţii referenţiale este marcată

prin îngroşarea liniei care reprezintă relaţia şi adăugarea de săgeţi şi semne
grafice sugestive pentru modul în care mediul Access controlează relaţia
respectivă.
În FIG.39 se prezintă aspectul ferestrei Relationships pentru aplicaţia
referitoare la concursul de admitere, după crearea tabelului tbl_DatePersonale şi
impunerea integrităţii referenţiale pentru toate relaţiile.
De exemplu: Pentru baza de date din FIG.39, impunerea integrităţii

referenţiale înseamnă că, la introducerea de date în tabelul tbl_Note:
- nu poate fi notat un candidat inexistent adică, înainte de a i se
atribui o notă, fiecare candidat trebuie înregistrat în tbl_Candidati;
- nu se pot da note la discipline în afara concursului adică, înainte
de introducerea notelor, toate probele posibile trebuie înregistrate
în tabelul tbl_Probe.
FIG.40
Tipul de asociere este proprietatea prin care se stabileşte dacă vor exista
articole neasociate, astfel:
 Asocierea internă (inner join) este tipul de asociere implicit. Este o
asociere caracterizată prin faptul că rezultatul unei interogări bazată pe
cele două tabele va conţine numai articolele pentru care valoarea
câmpului de legătură este aceeaşi.
 Asocierea externă stânga (left-outer join) este caracterizată prin faptul
că rezultatul unei interogări bazată pe cele două tabele va include toate
articolele din tabelul primar A, chiar dacă acestea nu au articole
asociate în tabelul B.
 Asocierea externă dreapta (right-outer join) este caracterizată prin
faptul că rezultatul unei interogări bazată pe cele două tabele va include
toate articolele din tabelul B, chiar dacă în acesta există articole care nu
au corespondent în tabelul A.
Dialogul pentru stabilirea tipului de asociere, pentru relaţia editată în

FIG.37, este prezentat în FIG.40. Dialogul pentru a stabili tipul relaţiei dintre
tabelul tbl_Candidati şi tbl_Note este asemănător.
De exemplu: O situaţie centralizatoare creată ulterior pe baza unei
interogări a bazei de date, diferă în funcţie de tipul asocierii. Astfel,
pentru relaţiile unu-la-mai-mulţi prezentate în FIG.39:
- acceptând varianta implicită care propune asociere internă pentru
ambele relaţii:
O situaţie de tip catalog va include numai candidaţii care au susţinut
cel puţin o probă de examen.
O situaţie care calculează media generală a notelor obţinute la fiecare
probă, va include numai probele la care s-a prezentat cel puţin un
candidat (fără a afişa media 0.00 pentru probele încă nederulate).
- alegând asociere externă stânga pentru relaţia dintre tbl_Candidaţi şi
tbl_Note, o situaţia de tip catalog va include toţi candidaţii, inclusiv cei
neprezentaţi la nici o probă (vor avea notele necompletate).
2.4 Interogări
Interogările sunt obiecte Access folosite pentru combinarea datelor din mai
multe tabele sau alte interogări, ordonarea, sortarea, filtrarea şi totalizarea
listelor, efectuarea de calcule, actualizarea, adăugarea şi ştergerea articolelor din
tabele, precum şi pentru crearea de noi tabele pe baza unui model.
Spre deosebire de celelalte obiecte, pentru interogări există trei moduri de
vizualizare:
 DesignView – afişează fereastra de proiectare a interogării, numită şi
QBE (QueryByExample);
 DatasheetView – afişează rezultatul interogării, similar unui tabel;
 SQL View – afişează secvenţa SQL corespunzătoare interogării
(Structured Query Language).
Interogările se creează, de obicei, cu ajutorul utilitarului Query Wizard şi se

ajustează în modul Design. Fereastra de proiectare a unei interogări, în
configuraţie tipică, este prezentată în FIG.41.
FIG.41
În fereastra Design a interogării se deosebesc două zone:

 Sursa datelor trebuie precizată în partea superioară a ferestrei. Sursa
datelor pentru orice interogare este constituită din tabele legate între
ele prin relaţii.
Astfel, trebuie să fie vizualizate toate tabelele care furnizează date
pentru interogare. Includerea unui tabel se poate face automat (cu
ajutorul utilitarului Query Wizard), sau manual, prin acţionarea butonului
ShowTable de pe bara cu instrumente (identic cu cel din FIG.36).
Dacă între tabele nu există o relaţie directă, aceasta poate fi creată
local, prin tragere, chiar în zona de date a interogării. Relaţia rămâne
locală ea nu apare în fereastra Relationships şi nu poate fi utilizată în
afara interogării.
 Grila de proiectare conţine câmpurile incluse în interogare şi un set de
proprietăţi care se aplică în interogare. Liniile din grila de proiectare
diferă în funcţie de tipul interogării.
Pentru manipularea câmpurilor din grila de proiectare (selectare, mutare,

ştergere, editare, etc.) se aplică modalităţile folosite într-o foaie de calcul Excel.
Comanda Edit \ Undo permite anularea operaţiilor de proiectare anterioare.
În modul Design se pot utiliza meniurile şi bara cu butoane specifice;
totodată, majoritatea opţiunilor din meniuri sau de pe bara cu butoane pot fi
accesate şi cu ajutorul meniului suplimentar care se deschide prin click pe
butonul drept al mouse-ului.
Pentru a executa interogarea se utilizează butonul Run de pe bara cu
instrumente (FIG.42).
FIG.43
FIG.42
Interogările sunt obiecte complexe, indispensabile în proiectare bazelor de

date. După rolul pe care îl îndeplinesc, interogările pot fi:
 Interogări de selecţie (Select Queries) care servesc la combinarea,
modificarea, vizualizarea şi analiza datelor din mai multe tabele
asociate. Se pot face operaţii de filtrare şi sortare, se pot adăuga
câmpuri calculate sau se pot face totaluri cu ajutorul funcţiilor agregat.
O interogare de tip Select se creează cu ajutorul utilitarului Query
Wizard sau direct în modul Design.
 Interogări de acţiune (Action Queries) care servesc la efectuarea
operaţiilor permise asupra tabelelor şi a articolelor acestora. Pentru
crearea unei interogări de acţiune, se creează întâi interogarea de
selecţie corespunzătoare care apoi se transformă în interogare de
acţiune cu ajutorul butonului QueryType de pe bara cu instrumente
(FIG.43).
2.4.1 Interogări de selecţie
Interogările de selecţie sunt formate dintr-o colecţie de articole prin care se

combină date din mai multe tabele şi / sau interogări aflate într-o relaţie de
asociere. Pentru simplitatea exprimării, în continuare se va folosi doar elementul
“tabel” pe lângă care se subînţelege expresia “alte interogări salvate anterior”.
Cu ajutorul interogărilor, utilizatorul poate specifica numele câmpurilor pe
care doreşte să le vizualizeze (se pot afişa simultan câmpuri provenite din mai
multe tabele asociate), în ce ordine să fie afişate câmpurile respective, care să
fie criteriile de sortare şi filtrare a articolelor afişate. De asemenea, este posibilă
includerea unor câmpuri calculate sau efectuarea de operaţii totalizatoare pe
grupuri de articole folosind funcţiile agregat.
Dacă o interogare de selecţie se bazează pe un singur tabel, ea poate fi
folosită şi pentru introducerea unor noi articole în tabel.
Lista obţinută în fereastra DatasheetView a unei interogări de selecţie este
foarte asemănătoare cu fereastra DatasheetView a tabelelor. Deosebirea
esenţială este în modul de creare a acestei liste: într-un tabel datele sunt
memorate permanent şi au aceeaşi valoare până la modificarea lor, în tip ce
într-o interogare nu se memorează date ci structura acestora. La fiecare
lansare (Run), se efectuează consultarea datelor din tabelele aflate la baza
interogării astfel încât rezultatul interogării va conţine totdeauna datele actuale.
Liniile din grila de proiectare a unei interogări de selecţie au următoarea
semnificaţie:
 Field – conţine numele câmpului, aşa cum apare el în tabelul aflat la baza
interogării. Câmpurile se introduc în grilă astfel:
 automat, prin folosirea utilitarului QueryWizard;
 manual, unul câte unul, prin tragere cu mouse-ul din zona sursă a datelor;
 manual, toate câmpurile unui tabel vizualizat în zona sursă a datelor, prin
tragerea cu mouse-ul a simbolului “  “ afişat imediat sub numele tabelului;
 prin alegere din lista derulantă aflată la dispoziţia utilizatorului.
 Table – conţine numele tabelului sursă a datelor. Pentru introducerea

manuală se utilizează lista derulantă corespunzătoare.
 Sort – permite alegerea uneia dintre următoarele opţiuni: NotSorted
(implicită), Ascendent sau Descendent. Semnificaţia lor este similară cu cea a
opţiunilor corespunzătoare din fereastra SortBy a mediului Excel. Spre
deosibire de Excel, mediul Access nu limitează la 3 numărul cheilor de
sortare. Ordinul cheilor de sortare este dat de ordinea câmpurilor respective
în grila de proiectare, considerată de la stânga la dreapta.
Observaţie: Ordinea câmpurilor se poate modifica prin tragere cu mouse-ul.
Ordinea de sortare este activă numai pentru afişare în
interogare.
Ordinea câmpurilor şi a articolelor în tabelele de bază nu se
modifică.
Precizare: ordinea dată de a doua cheie de sortare acţionează
numai în cadrul submulţimii de articole pentru care valorile primei
chei de sortare sunt identice, ordinea dată de a treia cheie de
sortare acţionează numai în cadrul submulţimii de articole pentru
care valorile primelor două chei de sortare sunt identice, etc.
 Show – este un comutator a cărui poziţie selectată determină vizualizarea
câmpului respectiv în rezultatul interogării. Câmpurile neafişate pot fi
necesare pentru includerea lor în expresii de calcul, chei de sortare sau criterii
de filtrare.
 Criteria – este o zonă formată din mai multe linii în care se pot preciza
criteriile de filtrare. Modul de lucru este similar celui utilizat la operaţia de
filtrare avansată din mediul Excel.
Pentru scrierea condiţiilor se utilizează expresii introduse de la tastatură sau
scrise cu ajutorul utilitarului Build. Lansarea utilitarului se face prin acţionarea
butonului corespunzător de pe bara cu butoane (FIG.4). Totodată, mediul
Access oferă asistenţă pentru verificarea şi corectarea sintactică a expresiilor.
Notă: Prin filtrare se înţelege afişarea articolelor care îndeplinesc
condiţiile precizate şi ascunderea tuturor celorlalte articole din listă.
Astfel, pentru fiecare câmp se pot preciza condiţii independente,

numite criterii. Între criteriile scrise pe aceeaşi linie se aplică
operatorul logic And iar între rezultatul diferitelor linii se aplică
operatorul logic Or. Dacă pentru un câmp este necesară verificarea
mai multor condiţii în coloane diferite, acest câmp poate fi inclus de
mai multe ori în grila de proiectare.
Un caz particular de criteriu de filtrare constă în folosirea parametrilor.
Prin parametru se defineşte un criteriu de filtrare a cărui valoare se va stabili
ulterior. Numele parametrului se scrie între paranteze drepte şi conţine un
mesaj scurt care se va afişa la executarea interogării. Utilizatorul va introduce
valoarea parametrului în caseta de dialog corespunzătoare.
Interogările parametrizate vor fi explicate şi exemplificate în cadrul
aplicaţiei referitoare la concursul de admitere.
 Total – este o linie care poate fi vizualizată prin activarea opţiunii View\Totals.
Ea serveşte pentru scrierea funcţiilor agregat în vederea efectuării de operaţii
asupra valorilor unui câmp din toate articolele incluse în interogare.
Principalele funcţii agregat sunt: GroupBy (implicită), Sum (sumă), Avg (medie
aritmetică), Min (valoarea cea mai mică), Max (valoarea cea mai mare), Count
(numărul de valori identice), First (prima valoare, în ordinea afişării
articolelor), Last (ultima valoare, în ordinea afişării articolelor), Where, etc.
Ordinea în care se aplică aceste funcţii este dată de ordinea câmpurilor în
grilă, considerată de la stânga la dreapta.
Opţiunea implicită GroupBy se interpretează cu sensul “la valori egale se
include un singur articol”. La un astfel de grup de articole se aplică, de obicei,
o funcţie totalizatoare, ca de exemplu Sum sau Avg.
Opţiunea Where se foloseşte asemănător cu clauza Where din limbajul SQL.
În multe cazuri, vizualizarea interogării în SQL View conduce la o înţelegere
mai clară a rolului acesteia şi a rezultatelor aşteptate.
2.4.2 Exemplu
FIG.44
Fereastra de proiectare a interogării qry1_Candidati, bazată pe tbl_Candidati
Interogarea s-a creat prin QueryWizard. Dialogul de alegere a câmpurilor este
asemănător cu cel folosit la utilitarul LookupWizard.
Sunt incluse toate câmpurile din tabel şi s-a impus o sortare în ordine alfabetică a
candidaţilor. Interogarea poate fi folosită atât pentru afişare cât şi pentru
introducerea / modificarea datelor în tabelul pe care se bazează.
FIG.45
Rezultatul interogării din FIG.44.
Prin coroborarea numărului de legitimaţie cu ordinea de afişare,
la candidaţii cu Nume = “Popescu”, se observă rolul celor două chei de sortare.
FIG.46
Includerea unei condiţii de filtrare determină vizualizarea candidaţilor din
oraşul Arad. Pentru criterii impuse unui câmp de tip text, mediul Access
adaugă automat separatorul “ghilimele”.
FIG.47
Pentru a vizualiza numai candidaţii din oraşul Arad a căror nume începe cu litera
“M”, se introduce o nouă condiţie de filtrare. În scrierea expresiilor se poate folosi
caracterul global “ * “.
Cele două criterii sunt scrise pe aceeaşi linie; ele trebuie îndeplinite simultan
(se aplică operatorul logic “And”).
FIG.48
Interogarea afişează toţi candidaţii din oraşele Arad şi Timişoara.
Implicit, comparaţia este non case sensitive.
Obs.:Pentru fiecare articol, trebuie îndeplinit criteriul Arad sau criteriul Timişoara.
În loc de două criterii scrise pe două linii distincte, de poate utiliza expresia:
”Arad” or ”Timisoara”
FIG.49
Interogarea afişează toţi candidaţii născuţi după 1 ianuarie 1970.
Pentru câmpurile de tip dată calendaristică, mediul Access adaugă
separatorul “ # “.
FIG.50
Se afişează candidaţii născuţi între 1965 şi 1970. Pentru simplitatea expresiilor
interogarea conţine o dublură nevizualizată a câmpului DataNast.
FIG.51
Se creează o interogare parametrizată care permite utilizatorului să stabilească
ulterior oraşul de provenienţă al candidaţilor pe care doreşte să-i vizualizeze.
Numele parametrului este Introduceti_orasul şi trebuie scris între paranteze drepte.
FIG.52
Se lansează dialogul Query\Parameters…
Se completează numele şi tipul parametrului.
Observaţii:
- pentru parametrii de tip text, declararea este
opţională.
- dacă se utilizează mai mulţi parametrii, ordinea
declarării lor va determina ordinea în care
mediul Access va afişa dialogul utilizator
pentru introducere a valorilor.
FIG.53
La executarea interogării, se afişează
dialogul pentru a fi completat de
utilizator.
Rezultatul interogării va fi acelaşi ca în
cazul precizării valorii câmpului Oras în
grila de proiectare.
FIG.54
Cu ajutorul utilitarului Query Wizard, se creează interogarea qry2_Calcule prin
combinarea datelor din două tabele. Pentru a calcula media probelor / candidat, se
aplică funcţia agregat Avg în câmpul Nota. (se lucrează în DesignView)
Datorită integrităţii referenţiale impuse relaţiei, rezultatul interogării include numai
candidaţii care s-au prezentat la cel puţin o probă.
Obs.: Tabelul tbl_Probe figurează în zona sursă deoarece a fost folosit într-o fază de
proiectare anterioară. S-a renunţat la utilizarea datelor din acest tabel, dar s-a omis
ştergerea lui din fereastra interogării. Prezenţa unui tabel suplimentar nu influenţează
funcţionarea interogării.
FIG.55
Pentru a impune afişarea mediei cu 2 zecimale, din meniul suplimentar
care se deschide prin click cu butonul drept al mouse-ului pe câmpul
respectiv, se alege opţiunea Properties….
FIG.56
Se modifică structura tabelului tbl_Note,
introducându-se şi notele atribuite de cei
doi corectori.
Astfel, valoarea câmpului Nota va fi
calculată ca medie aritmetică a celor
două corecturi.
FIG.57
Se creează interogarea qry3_CampCalculat combinând câmpurile din cele două tabele. Se
introduce un câmp calculat Media, care va conţine media corecturilor pentru fiecare articol.
După numele câmpului calculat trebuie utilizat separatorul “ : “.
FIG.58
Pentru
construirea
expresiei de
calcul se
foloseşte
utilitarul
Build…
SELECT DISTINCTROW tbl_Candidati.Legitimatia, tbl_Candidati.Nume, tbl_Candidati.Prenume,

tbl_Note.Corectura1, tbl_Note.Corectura2, ([Corectura1]+[Corectura2])/2 AS Media
FROM tbl_Candidati INNER JOIN tbl_Note ON tbl_Candidati.Legitimatia = tbl_Note.Legitimatia
ORDER BY tbl_Candidati.Nume, tbl_Candidati.Prenume;
FIG.59
Secvenţa SQL corespunzătoare interogării qry3_CampCalculat, de tip Select
Obs.: Câmpul calculat are efect numai pentru interogare; în tabelul tbl_Nota, nu se
regăseşte media calculată pentru cele două corecturi.
2.4.3 Interogări de acţiune
Interogările de acţiune au rolul de crea, modifica sau actualiza tabelele.

Pentru crearea unei interogări de acţiune, se creează interogarea de selecţie
corespunzătoare care, apoi, se transformă în interogare de acţiune.
Transformarea unei interogări de selecţie în interogare de acţiune sau
invers, transformarea unei interogări de acţiune într-o interogare de selecţie – în
vederea efectuării de modificări sau testări ulterioare, se realizează cu ajutorul
opţiunilor din meniul Query (FIG.60) sau a listei derulante QueryType (FIG.43).
Principalele interogări din mediul MS-Access au

rolul de:
 Creare tabel nou (Make-Tabel Query),
 Actualizare articole (Update Query),
 Adăugare date (Append Query),
 Ştergere articole (Delete Query).
Simbolul specific, în funcţie de tipul şi rolul

interogării este afişat în faţa numelui interogării
în fereastra Database.
FIG.60
Make-Table Query creează un tabel nou în baza de date curentă sau

într-o altă bază de date Access. Interogarea Make-Table are la bază o interogare
de tip Select care are structura tabelului ce se va crea.
Numele noului tabel se precizează în faza de proiectare. Dacă în baza de
date mai există un tabel cu acelaşi nume, mediul Access afişează un mesaj de
avertizare, după care permite suprascrierea tabelului. Dacă rezultatul interogării
de selecţie conţine date, articolele vor fi copiate în noul tabel.
Update Query modifică date în articolele existente ale unui tabel.
Interogarea Update se creează dintr-o interogare de tip Select care are la bază
tabelul în care se fac modificări. (Update to… valoare nouă)
Rezultatul interogării constă în modificarea tuturor articolelor din tabel care
se supun criteriilor de filtrare impuse. Dacă rezultatul obţinut diferă de cel
scontat, corectarea se face prin reproiectarea atentă a interogării sau prin
introducerea unui tabel auxiliar care conţine numai articolele de modificat.
Noua valoare a câmpurilor care se actualizează poate fi o constantă sau o
expresie introdusă în grila de proiectare cu ajutorul utilitarului Build….
Append Query adaugă la un tabel existent un set de articole. Interogarea

Append se creează dintr-o interogare de tip Select care are la bază setul de
articole ce se vor adăuga. (Append to …nume tabel)
Deoarece rezultatul interogării de tip Select constituie tocmai setul de
articole care se va adăuga, structura interogării trebuie să fie aceeaşi cu
structura tabelului la care se vor adăuga datele. Corespondenţa între câmpuri se
face pe baza numelui. Dacă numele de câmp din interogare diferă de cel din
tabel, utilizatorul trebuie să precizeze manual numele câmpului corespondent din
tabel.
Delete Query şterge un set de articole dintr-un tabel existent. Interogarea
Delete se creează dintr-o interogare de tip Select care are la bază tabelul din
care se vor şterge date.
Interogarea Select se proiectează astfel încât rezultatul ei să fie tocmai
setul de articole care se vor şterge din tabel.
Observaţie:
La toate interogările de acţiune, pentru precizarea articolelor implicate în
operaţie, se poate utiliza filtrarea prin intermediul liniei Criteria şi/sau ordonarea
prin intermediul liniei Sort.
2.4.4 Exemplu
FIG.61
Se creează
interogarea
qry4_NotaZece,
de tip Select, se
transformă în
Update Query şi
se precizează
UpdateTo …
valoarea 10 pentru
câmpul Nota.
FIG.62
La fiecare lansare a
interogării se afişează
un mesaj de
avertizare.
În acest moment,
tabelul tbl_Note are 8
articole.
FIG.63
Toate cele 8 articole ale
tabelului tbl_Note se
actualizează.
Obs.: Pentru afişare,
câmpurile Corectura1 şi
Corectura2 au fost
reduse la dimensiune
zero.
FIG.64
Se creează interogarea qry5_Note, bazată pe aceleaşi tabele. După transformare în

Update Query, se introduce expresia de calcul în câmpul Nota. Rularea interogării are ca
efect actualizarea câmpului Nota a tabelului cu mediile calculate.
FIG.65
Se creează o interogare care

conţine toate câmpurile din
tbl_Candidaţi şi tbl_DatePersonale,
după care se transformă în Make-
Table Query.
FIG.66
În caseta de dialog se
completează numele noului
tabel: tbl_Inscrieri.
FIG.67
Datorită folosirii simbolului “” în

proiectarea interogării, tabelul
tbl_Inscrieri conţine toate câmpurile
ambelor tabele, inclusiv cheia
(identică).
Obs.: O copie a tabelului

tbl_Inscrieri se poate folosi la fiecare
punct de înscriere (dacă nu se
utilizează o reţea de calculatoare
care să exploateze aceeaşi bază de
date).
FIG.68
Pe baza tabelului
tbl_Inscrieri, se creează
o interogare de tip
Select care include
numai câmpurile
corespunzătoare
tabelului tbl_Candidati.
Se transformă în
Append Query.
FIG.69
Din caseta de dialog se
alege numele tabelului
tbl_Candidati, la care se
vor adăuga date.
Interogarea se va salva
sub numele de
qry7_AdaugCandidati.
Similar, pe baza tabelului tbl_Inscrieri, se creează interogarea

qry8_AdaugDatePersonale, de tip Append. Cu ajutorul ei se vor adăuga date la
tabelul tbl_DatePersonale.
Observaţie: Pentru iniţializarea unei zile de lucru la punctul de înscriere,

se efectuează următoarele operaţii:
- se rulează qry7_AdaugCandidati şi qry8_AdaugDatePersonale în
vederea completării tabelelor tbl_Candidati şi tbl_DatePersonale cu toţi
candidaţii înscrişi în ziua curentă;
- se rulează qry6_Candidati prin care se creează un nou tabel
tbl_Inscrieri, gol, peste tabelul existent din care s-au utilizat datele.
Lansarea succesivă a interogărilor şi inhibarea mesajelor de confirmare se
poate automatiza cu ajutorul macro-urilor.
FIG.70
Se creează o interogare de tip Select bazată pe tabelul tbl_Candidaţi. Pentru a şterge
toţi candidaţii de sex feminin, se scrie condiţia de filtrare în câmpul Sexul, după care
interogarea se transformă în Delete Query.
FIG.71
Înainte de ştergerea
articolelor, mediul
Acces afişează un
mesaj de avertizare /
confirmare.
Observaţie:
După prima rulare a interogărilor de acţiune, la revenirea în modul Design,
se va observa că în structura interogării există un număr mai mic de
câmpuri decât cel prevăzut iniţial de utilizator. Această modificare este des
întâlnită la interogările de tip Update. Explicaţia constă în faptul că, de
obicei, utilizatorul include toate câmpurile care îi permit să folosească
utilitarul Build… pentru construirea expresiilor; ulterior, mediul Access
elimină automat câmpurile care nu sunt absolut necesare pentru rularea
interogării.
FIG.72
După crearea interogărilor prezentate,
tab-ul Queries al ferestrei Database
are aspectul din figură. Simbolurile şi
numele interogărilor sugerează rolul
acestora.
2.5 Formulare
Formularele sunt obiecte ale mediului Access utilizate pentru introducerea

şi vizualizarea datelor din tabele şi / sau interogări. Plasând butoane de comandă
pe formulare, se pot crea meniuri simple sau înlănţuite.
Şablonul obişnuit pentru denumirea unui formular este
frm_NumeFormular sau frmNumeFormular.
Formularele se pot crea în modul Design sau folosind unul dintre utilitarele
de tip wizard. Indiferent de modul de creare, de obicei, este necesară
modificarea sau ajustarea aspectului formularelor. Aceasta se realizează în
modul de proiectare utilizând butoanele de pe bara cu instrumente Toolbox
(FIG.73) şi opţiunile din meniul Format.
Modul DesignView al unui formular “gol” este prezentat în FIG.74. El
conţine macheta care descrie modul în care se vizualizează datele. În funcţie de
aspectul preconizat şi de rolul formularului în aplicaţie, cele cinci secţiuni pot
avea dimensiune şi importanţă diferite. Singura secţiune obligatorie este banda
Detail.
FIG.73
FIG.74
Principalele secţiuni (sau “benzi”) ale oricărui formular sunt:

 Form Header este o secţiune opţională conţinând antetul de formular. În
antet se include informaţia care nu se modifică de la o înregistrare la alta (de
exemplu: numele sau antetul firmei).
 Form Footer este o secţiune opţională conţinând subsolul de formular.
Similar cu FormHeader, ea include informaţie care nu depinde de articolul
curent (de exemplu: data întocmirii sau indicaţii privind utilizarea formularului).
 Page Header este o secţiune opţională conţinând antetul de pagină. În cazul
formularelor cu mai multe pagini, antetul de pagină include informaţia care se
afişează pe fiecare pagină.
 Page Footer este o secţiune opţională conţinând subsolul de pagină.
Obs. De obicei, formularele se proiectează fără întreruperi de pagină.
Secţiunile PageHeader şi PageFooter sunt importante în cazul rapoartelor.
 Detail este secţiunea obligatorie care conţine datele şi / sau controalele care
fac obiectul formularului.
Elementele plasate în diferitele secţiuni ale unui formular se numesc

generic “controale”. Acestea pot fi: etichete, câmpuri, butoane de comandă,
butoane radio, liste derulante sau combo, etc.
La crearea formularului folosind utilitarul Form Wizard, cele mai importante
controale pot fi plasate automat în formular. În modul de proiectare, controalele
se creează folosind butoanele barei cu instrumente Toolbox. Acestea se
activează şi se desenează în spaţiul de proiectare al formularului în mod similar
butoanelor de pe bara de desenare din aplicaţia Microsoft Word.
Selectarea controalelor de pe formulare prezintă câteva particularităţi

faţă de elementele desenate în Microsoft Word sau Microsoft Excel. Astfel:
 Selectarea se face “prin tăiere”, adică este suficientă intersectarea conturului
cu una din laturile dreptunghiului de selecţie, fără a fi necesară încadrarea
întreagă a controlului.
 La selectare, în colţul “stânga-sus” al fiecărui control apare un marcaj diferit,
evidenţiat faţă de celelalte puncte marcate. La glisarea peste un marcaj
evidenţiat, cursorul mouse-ului ia formă de “mână închisă cu deget arătător”.
Folosind această formă a cursorului se poate selecta numai controlul
respectiv, separându-l dintr-o selecţie multiplă (de exemplu: se realizează
separarea etichetei de câmpul corespunzător).
 Pentru realizarea selecţiei multiple, se poate utiliza tasta Shift, menţinută
apăsată în timp ce se efectuează click cu mouse-ul pe fiecare obiect inclus în
selecţie.
 Cursorul în formă de “mână cu palma deschisă” se referă la toate obiectele
care fac parte dintr-o selecţie multiplă.
 Pentru modificarea dimensiunii controalelor selectate, în funcţie de versiunea
Access utilizată se poate folosi tasta Shift în combinaţie cu tastele săgeţi sau
doar tastele săgeţi.
 Pentru mutarea controalelor selectate se poate utiliza tasta Ctrl în combinaţie
cu tastele săgeţi sau doar tastele săgeţi.
Stabilirea proprietăţilor pentru controale şi / sau asocierea diferitelor

acţiuni se poate face automat, prin activarea prealabilă a utilitarului
ControlWizards de pe Toolbox (FIG.73). Manual, modificarea proprietăţilor
controalelor se realizează prin caseta de dialog care se afişează la alegerea
opţiunii Properties din meniul suplimentar (click cu butonul drept al mouse-ului pe
controlul selectat). Modul de lucru este asemănător celui folosit în MicrosoftExcel
pentru crearea şi legarea controalelor.
Deschiderea dialogului de stabilire a proprietăţilor pentru întregul
formular se realizează în modul Design cu ajutorul meniului suplimentar activat
prin click cu butonul drept al mouse-ului în caseta din stânga riglei.
Cele mai importante proprietăţi din categoria Format pentru întregul
formular se referă la elementele prezentate sugestiv în FIG.75 şi vor fi descrise
în cadrul aplicaţiei exemplu referitoare la examenul de admitere.
Record selector Caption MinMax buttons
Dividing
lines
Navigation buttons Scroll bars
FIG.75
2.5.1 Formulare pentru introducerea / vizualizarea datelor
Formularele pentru introducerea şi vizualizarea datelor reprezintă

principalul element de interfaţă cu operatorul care va folosi aplicaţia. Ele se
creează foarte simplu folosind utilitarul FormWizard după care se modifică în
modul Design. Ele pot avea la bază unul sau mai multe tabele sau interogări,
fiind folosite curent pentru introducerea simultană a datelor în mai multe tabele
aflate în relaţie.
Acest tip de formulare poate fi imaginat ca un ecran aşezat în faţa
tabelelor prin intermediul cărora datele sunt vizualizate în momentul şi sub forma
stabilită. Sunt permise operaţii de sortare şi filtrare a datelor.
După poziţia secţiunilor şi a datelor cuprinse în acestea, formularele pot fi
de tip Columnar, Tabular, Datasheet sau vor avea aspectul stabilit prin proiectare
manuală.
Secţiunea Detail conţine descrierea modului în care se vor vizualiza sau
edita articolele. La utilizarea formularului, banda Detail va fi particularizată pentru
fiecare articol din sursa de date.
Cele mai importante controale plasate pe un formular de acest tip sunt
câmpurile şi etichetele. Câmpurile vor lua valorile câmpurilor corespunzătoare
din sursa de date. La folosirea utilitarului FormWizard, etichetele (labels) pentru
câmpuri vor lua automat valoarea proprietăţii Caption din tabelul sursă.
Pentru modificarea formularului, se efectuează cel mai des următoarele
operaţii:
 mutarea, ştergerea, adăugarea de câmpuri sau etichete;
 modificarea antetului şi / sau subsolului de formular;
 stabilirea titlului formularului (proprietatea Caption);
 modificarea dimensiunilor formularului şi / sau a controalelor;
 adăugarea de elemente grafice (linii, chenare, imagini de background, etc.);
 separarea şi gruparea datelor în mai multe tab-uri;

 efectuarea de sortări;
 aplicarea de filtre;
 stabilirea / modificarea proprietăţilor pentru controale;
 adăugarea de câmpuri calculate;
 adăugarea de butoane de comandă;
 scrierea elementelor de VBA asociate formularului şi / sau controalelor, etc.
2.5.2 Exemplu
Pentru aplicaţia referitoare la concursul de admitere se construiesc trei

formulare cu rol de introducere a datelor, astfel:
- frm_Candidati pentru introducerea simultană a datelor în tabelele
tbl_Candidati şi tbl_DatePersonale;
- frm_Probe pentru introducerea datelor în tabelul tbl_Probe;
- frm_Note pentru introducerea datelor în tabelul tbl_Note.
Pentru vizualizarea datelor se va construi formularul frm_VizuCandidati,
pentru care se va aplica sortare şi filtrare.
Observaţie:
Formularele vor fi create folosind utilitarul FormWizard şi vor avea la bază chiar
tabelele în care se efectuează introducerea datelor. Modificarea formularelor se
va realiza cu ajutorul elementelor disponibile pe bara cu instrumente Toolbox. În
scopul exemplificării a cât mai multor proprietăţi şi operaţii aplicate formularelor
de acest tip, se vor parcurge etape care în mod obişnuit nu sunt necesare pentru
un utilizator cu experienţă.
FIG.76
Pentru crearea formularului frm_Candidati se utilizează FormWizard şi se aleg câmpuri
din ambele tabele implicate. Câmpul Legitimatia nu va fi inclus în formular deoarece
introducerea datelor de tip Autonumber se face automat.
Se alege modul Columnar şi stilul Standard, recomandate pentru formularele de
introducere a datelor, după care se denumeşte formularul.
FIG.77
Aspectul formularului obţinut, înainte de prelucrarea personalizată.
În prima fază a prelucrării s-a utilizat selecţia multiplă, ştergerea (tasta

Delete), mutarea şi redimensionarea controalelor (tragere cu mouse-ul), opţiunile
Format\Align şi Format\Size, editarea textului etichetelor, şi proprietăţile: Caption
= Introducere date candidaţi, MinMaxButtons = None, ScrollBars = Neither.
Elementele de proiectare sunt prezentate în FIG.78 (DesignView). FIG.79
vizualizează modul de deschidere a dialogului Properties pentru întreg
formularul, iar rezultatul obţinut (FormView) este prezentat în FIG.80.
Semnificaţia butoanelor de navigare reiese din adnotările incluse în FIG.80.
FIG.78
FIG.79
FIG.80
Numărul arti- Total

colului curent articole
Mută pointer-ul pe Mută pointer-ul pe

articolul anterior articolul următor
Salt la primul Salt la ultimul Introducerea unui

articol articol nou articol
FIG.81
Aspectul dialogului
Properties pentru
formularul
frm_Candidati.
Observaţie:
Formularul frm_Candidati are la bază tabelele tbl_Candidati şi
tbl_DatePersonale. În procesul de creare a formularului cu ajutorul utilitarului
FormWizard, mediul Access construieşte automat o interogare de tip Select,
bazată pe cele două tabele. În proprietatea RecordSource a formularului se
regăseşte tocmai această interogare.
FIG.82
Sursa de date pentru formularul frm_Candidati.
Interogarea este asociată formularului şi nu este salvată separat.
La cererea utilizatorului, poate apărea necesitatea construirii unui formular

cu aspect profesional. Astfel, se poate crea un formular cu mai multe tab-uri, se
poate impune interzicerea vizualizării sau modificării datelor introduse într-o
sesiune anterioară, modificarea culorii de fond, etc.
Pentru a grupa datele în două tab-uri, se deschide formularul
frm_Candidati în DesignView şi se procedează astfel:
- se alege instrumentul TabControl de pe Toolbox şi se desenează conturul
viitorului formular; modificarea numărului de tab-uri sau modificarea ordinii
acestora se realizează folosind meniul suplimentar care se deschide prin click
cu butonul drept al mouse-ului pe marginea unui tab selectat;
- se redenumesc cele două tab-uri (se modifică proprietăţile Name şi Caption

pentru fiecare pagină în parte);
- se selectează controalele care se vor plasa pe primul tab şi se copiază în
Clipboard (Ctrl+C);
- se selectează tab-ul destinaţie prin click pe eticheta acestuia;
- se lipesc controalele corespunzătoare (Ctrl + V);
- în mod similar, se plasează controalele pe cel de al doilea tab;
- se şterg controalele de pe pagina originală;
- se mută controlul tab creat în partea stânga-sus a formularului;
- se stabilesc proprietăţile: RecordSelector = No şi DividingLines = No;
- se efectuează redimensionările şi formatările necesare;
- pe tab-ul al doilea se adaugă un chenar folosind instrumentul Rectangle;
- se stabileşte proprietatea DataEntry = Yes pentru formular; astfel, la
deschiderea formularului se va adăuga automat un articol gol şi se aşteaptă
completarea lui de către utilizator. Utilizatorul va putea naviga doar între
articolele introduse în sesiunea de lucru curentă şi nu va avea nici o
informaţie referitor la celelalte articole din sursa de date.
FIG.83
Aspectul formularului în
DesignView, cu primul
tab selectat.
FIG.84
Stabilirea proprietăţilor pentru tab-ul tab_DatePersonale.
FIG.85
Aspectul celor două tab-uri ale formularului, în modul de vizualizare FormView.
FIG.86
Se creează în mod similar, formularul frm_Probe cu ajutorul
căruia se introduc date în tabelul tbl_Probe.
FIG.87
Se creează formularul frm_Note, cu ajutorul căruia se
introduc date în tabelul tbl_Note.
Formularul prezentat în FIG.87 este creat cu ajutorul utilitarului

FormWizard. Ca sursă a datelor, s-au ales câmpurile Candidat, Proba,
Corectura1 şi Corectura2 din tabelul tbl_Note.
Pentru ca fiecare sesiune de date să fie tratată independent de utilizator

(aparent, numerotarea începe cu articolul 1), pentru formularul frm_Note s-a
stabilit proprietatea DataEntry = Yes.
Media calculată este un câmp calculat care conţine media notelor acordate
de cei doi corectori, aşa cum sunt ele introduse în formular. Câmpul serveşte
numai pentru afişare; introducerea mediei în câmpul corespunzător al tabelului
tbl_Note nu se realizează în acest moment (ulterior se vor crea şi prezenta
obiectele necesare pentru actualizarea câmpului Nota).
FIG.88
Pentru crearea câmpului calculat se utilizează instrumentul TextBox de pe
Toolbox. Se stabilesc proprietăţile Name şi Caption pentru câmpul
fld_MediaCalculata şi pentru eticheta lbl_MediaCalculata corespunzatoare.
Proprietatea ControlSource a câmpului calculat va conţine expresia de calcul a
mediei, introdusă folosind utilitarul Build.
Observaţie: Media calculată şi afişată în formular nu poate fi modificată

accidental de către utilizator; interdicţia se obţine prin stabilirea proprietăţii
Locked = Yes pentru controlul fld_MediaCalculata. Efectul de culoare se
obţine prin modificarea corespunzătoare a proprietăţii BackColor pentru
acelaşi câmp.
Formularul frm_VizuCandidati (FIG.89) serveşte pentru vizualizarea

principalelor date de identificare a candidaţilor. În scop didactic se vor prezenta
mai multe variante de sortare şi filtrare.
FIG.89
Aspectul formularului frm_VizuCandidati, în modul FormView,
înainte de aplicarea sortării sau filtrării.
Formularul se creează folosind utilitarul FormWizard, modul Tabular şi

stilul Standard. Ca sursă a datelor se utilizează tabelul tbl_Candidati. Se adaugă
un câmp calculat care afişează vârsta candidaţilor.
Observaţie: în practică, de multe ori se preferă construirea unei interogări
care efectuează calculele, după care se creează formularul bazat pe
interogarea respectivă.
Noul câmp, denumit fld_Varsta, se creează cu ajutorul instrumentului

TextBox. Etichetele “Vârsta” şi “ani” se creează folosind instrumentul Label; se
observă repetarea etichetei “ani” din secţiunea Detail pentru fiecare articol din
sursa de date a formularului, în timp ce eticheta „Varsta” apare o singură dată în
antet.
FIG.90
Modul DesignView al formularului frm_VizuCandidati.
Câmpul DataNasterii a fost introdus pentru a servi la construirea expresiei de calcul
a vârstei; pentru a nu fi vizualizat în FormView, pentru câmpul DataNasterii, se
stabileşte proprietatea Visible = No.
FIG.91
Expresia de calcul a vârstei se introduce ca valoare a proprietăţii ControlSource
pentru câmpul calculat fld_Varsta;
se foloseşte dialogul ExpressionBuilder, al cărui casetă de dialog este asemănătoare
celei de introducere a funcţiilor în mediul MS-Excel.
Expresia de calcul, introdusă cu ajutorul utilitarului Build, este:
= IIf (Month(Date()) > Month ([DataNast]); Year(Date()) - Year([DataNast]);

IIf (Month(Date()) = Month([DataNast]) And Day(Date()) > Day([DataNast]);
Year(Date()) - Year([DataNast]); Year(Date()) - Year([DataNast]) - 1))
Modul de calcul efectuează diferenţa dintre anul curent şi anul naşterii

candidatului, ţinând cont şi de faptul că ziua de naştere a candidatului pentru
anul în curs are loc înainte sau după data curentă.
Pe lângă câmpurile cuprinse în formularul curent, se utilizează funcţii din
categoria Built-In. Introducerea funcţiilor se realizează conversaţional dar este
mai laborioasă decât în mediul MS-Excel.
Funcţia Date() returnează data curentă a sistemului de calcul. Funcţiile
Year, Month şi Day, având ca argument o dată calendaristică, returnează un
număr corespunzător anului, lunii sau zilei precizate de data argument. Funcţia
IIf are aceeaşi sintaxă şi se utilizează similar cu funcţia If din mediul MS-Excel.
Cuvântul cheie And implementează funcţia logică Şi.
Observaţie: expresia constă din două funcţii IIf imbricate, astfel că pe
ramura False a primei funcţii se realizează verificarea condiţiei logice
scrisă pentru a doua funcţie.
La formatarea şi alinierea controalelor s-au utilizat opţiunile

Format\Size\ToTallest, Format\Align\Top, Center (pentru textul etichetelor şi
conţinutul câmpurilor).
Pentru a permite doar vizualizarea datelor, cu interzicerea efectuării de
modificări, se stabilesc proprietăţile formularului astfel: AllowEdits = No,
AllowDeletions = No şi AllowAdditions = No. În plus, se modifică proprietăţile:
Caption, ScrollBars, MinMaxButtons şi DividingLines.
2.5.3 Sortarea şi filtrarea datelor în formulare
În cazul unui formular existent, mediul Access permite ordonarea datelor

după valorile crescătoare sau descrescătoare ale unui singur câmp. Operaţia
este similară sortării rapide din mediul MS-Excel.
Sortarea se efectuează de către utilizator, în modul FormView prin
poziţionarea cursorului pe câmpul cheie de sortare, urmată de acţionarea unuia
dintre butoanele de sortare (FIG.92).
FIG.92 FIG.93 FIG.94
Pentru filtrarea pe baza unui formular, se utilizează în mod obişnuit butonul

FilterByForm (FIG.93). Condiţiile de filtrare se referă la valorile câmpurilor din
tabelul aflat la baza formularului. Completarea condiţiilor de filtrare se realizează
conversaţional; se pot utiliza operatorii AND şi OR.
Afişarea datelor filtrate se realizează cu ajutorul butonului ApplyFilter
(FIG.94). Pentru utilizarea mai multor filtre asociate cu un acelaşi formular, filtrele
trebuie salvate sub forma unor interogări.
Observaţie: posibilităţile de sortare şi filtrare pentru formulare sunt limitate
în modul de lucru conversaţional. Pentru a exploata facilităţile avansate de
sortare şi filtrare puse la dispoziţie de mediul Access, se construiesc
interogările corespunzătoare iar pe baza lor se creează apoi rapoarte sau
formulare.
2.5.4 Exemplu
FIG.95
Sortare ascendentă (A la Z) asupra datelor din formularul frm_VizuCandidati
În momentul sortării, cursorul mouse-ului se afla pe Nume.
FIG.96
Condiţia de filtrare şi rezultatul aplicării filtrului pentru afişarea candidaţilor
de sex masculin.
2.5.5 Formulare tip meniu
Formularele tip meniu se creează în modul Design folosind comenzile

disponibile pe bara cu instrumente Toolbox (FIG.73). Ele conţin controale cu rolul
de lansa diferitele acţiuni pe care la îndeplineşte aplicaţia. Cel mai des folosite
sunt butoanele de comandă şi listele derulante.
Acţiunile asociate butoanelor de comandă se pot preciza astfel:
 folosind utilitarul ControlWizards, care se lansează automat dacă
instrumentul corespunzător de pe Toolbox este activ în momentul
desenării controlului. Rezultatul este o procedură VBA, scrisă automat de
mediul Access.
 scriind explicit o procedură adecvată, corespunzător unuia dintre
evenimentele legate de controlul creat în prealabil. Toate procedurile
asociate evenimentelor specifice unui formular şi controalelor aflate pe
acesta sunt reunite într-o secvenţă de cod asociată formularului
(CodeBehindForms).
Pentru identificarea controalelor, în special dacă vor fi utilizate în secvenţe

VBA, se recomandă modificarea proprietăţii Name, astfel ca numele atribuit să
sugereze atât tipul cât şi funcţia controlului.
De exemplu: un buton de comandă care va lansa un formular pentru
introducerea datelor poate fi denumit cmd_IntroDate.
Pentru ca formularul să aibă un aspect profesional, se utilizează
proprietăţile de formatare astfel: RecordSelector = No, NavigationButtons = No
(deoarece formularul nu are la bază o sursă de date organizată pe articole),
DividingLines = No, ScrollBars = Neither, MinMaxButtons = None iar proprietăţii
Caption i se atribuie o valoare corespunzătoare.
De exemplu: pentru a inhiba titlul implicit şi a obţine un formular fără
titlu, se stabileşte Caption = “ “.
2.5.6 Exemplu
FIG.97
Se creează un formular pentru introducerea datelor.
Primul buton, creat cu ajutorul utilitarului ControlWizards, va determina
deschiderea formularului frm_Candidati.
FIG.98
Se
stabileşte
textul
(Caption) şi
numele
butonului
de
comandă.
FIG.99
În mod similar se creează butoane
de comandă pentru lansarea
celorlalte formulare.
Pentru obţinerea aspectului din
figură, se utilizează comenzile
Format\Size, Format\Align,
opţiunile privind font-ul şi utilitarul
FormatPainter.
FIG.100
Aspectul formularului prin
care se va lansa
introducerea datelor.
S-a adăugat o etichetă
(Label) pentru care s-a
ales efectul special
Etched.
2.5.7 Diagrame incluse în formulare
Mediul Microsoft Access permite realizarea de diagrame pe baza tabelelor

sau interogărilor create şi salvate anterior. Sursa de date trebuie să fie un singur
obiect, ale cărui câmpuri se pretează la reprezentare grafică.
Un pas important în construirea graficelor îl constituie alegerea tipului de
diagramă folosit. Acesta trebuie să fie în concordanţă cu tipul şi sensul sursei de
date, astfel ca diagrama rezultată să fie logic interpretabilă.
Folosirea utilitarului ChartWizard, disponibil în fereastra Forms, este
deosebit de simplă pentru un utilizator familiarizat cu diagramele din mediile
MS-Word şi MS-Excel.
2.5.8 Exemplu
Pentru aplicaţia referitoare la examenul de admitere cu două probe, se

urmăreşte construirea unei diagrame care să prezinte rezultatele candidaţilor, în
ordine alfabetică.
FIG.101
Se construieşte interogarea qry_ChartRezultate, pe baza tabelelor tbl_Candidati
şi tbl_Note. Se adaugă câmpul calculat Candidat.
Se vizualizează linia Total şi se aplică funcţia agregat Average pentru calculul
mediei celor două probe. Pentru câmpul AvgOfNota, se stabilesc proprietăţile
de formatare Fixed cu 2 zecimale.
(Se presupune că toţi candidaţii s-au prezentat la ambele probe alese.)
FIG.102
Se construieşte diagrama, folosind utilitarul ChartWizard.
Se stabilesc proprietăţile de formatare pentru formularul frm_Chart care conţine
diagrama.
FIG.103
Pentru efectuarea
de modificări
asupra diagramei,
se activează
opţiunea
ChartObject\Edit
din meniul
suplimentar care se
deschide prin click
cu butonul drept al
mouse-ului pe
diagrama din
formularul afişat în
DesignView.
FIG.104
Pentru editarea diagramei se foloseşte aplicaţia MicrosoftGraph care se
deschide automat şi tratează diagrama ca un obiect încapsulat în
formularul frm_Chart.
Utilizarea aplicaţiei MS-Graph este aceeaşi ca în cazul lansării sale din
mediul MS-Word sau dintr-o altă aplicaţie MS-Office.
2.6 Rapoarte
Rapoartele sunt obiecte Access folosite pentru prezentarea sintetică a

informaţiei în vederea interpretării sale prin prisma gândirii umane. Ele reprezintă
documentele şi situaţiile de ieşire ale unei aplicaţii. De regulă, rapoartele se
tipăresc la imprimantă.
Denumirea obişnuită a unui raport respectă şablonul rpt_NumeRaport sau
rptNumeRaport.
În cadrul unui raport se regăsesc aceleaşi secţiuni ca cele descrise pentru
formulare; semnificaţia acestora este aceeaşi atât pentru rapoarte cât şi pentru
formulare.
Mediul Access pune la dispoziţia utilizatorului un instrument puternic, de tip

wizard, pentru crearea rapoartelor. Folosirea utilitarului ReportWizard este
asemănătoare cu folosirea utilitarului FormWizard.
Principalele tipuri de rapoarte realizate în mediul Access sunt rapoartele
de sinteză şi etichetele. Pentru includerea unei diagrame într-un raport se
foloseşte acelaşi utilitar ChartWizard ca în cazul formularelor.
2.6.1 Rapoarte de sinteză
Rapoartele de sinteză sunt cele mai folosite dintre toate tipurile de situaţii
de ieşire oferite de mediul Access. Scopul lor este prezentarea informaţiei din
baza de date astfel ca să poată fi interpretată de către utilizator în vederea luării
unei decizii.
Rapoartele de sinteză se bazează pe tabele şi / sau interogări create în
prealabil. În mod obişnuit, pentru crearea rapoartelor se foloseşte utilitarul
ReportWizard. Modificarea rapoartelor create automat este necesară atât pentru
îmbunătăţirea aspectului cât şi pentru ridicarea gradului de interpretabilitate al
sintezelor.
Rapoartele se pot construi pe mai multe nivele. Utilitarul ReportWizard
analizează datele sursă din punct de vedere logic, ţine cont de relaţiile dintre
tabele şi sugerează o posibilitate a împărţirii raportului pe nivele. Utilizatorul
poate accepta cele propuse de mediul Access sau poate să îşi alcătuiască o
structură proprie, în concordanţă cu scopul raportului.
Pentru datele din secţiunea Detail se pot aplica funcţiile agregat. Utilitarul
ReportWizard oferă posibilitatea calculării de totaluri pentru majoritatea
câmpurilor, pentru toate nivelele logic posibile; se pot folosi funcţiile agregat
obişnuite: Sum, Avg, Count, Min, Max, etc. Câmpurile calculate se pot adăuga şi
ulterior, procedura fiind similară cu cea din cazul formularelor.
2.6.2 Exemplu
Pentru aplicaţia referitoare la examenul de admitere cu două probe, se

creează următoarele rapoarte:
- rpt_ListaCandidati care serveşte la tipărirea în ordine alfabetică a
numelor candidaţilor înscrişi la concurs;
- rpt_Medii care serveşte la tipărirea probelor, notelor şi mediilor obţinute
de candidaţi, în ordinea crescătoare a numărului de legitimaţie.
Câteva momente semnificative din procesul de creare a rapoartelor

rpt_ListaCandidati şi rpt_Medii sunt:
FIG.105
Utilitarul ReportWizard permite afişarea ordonată a datelor după
cel mult patru chei de sortare
Sursa datelor este tabelul tbl_Candidati.
FIG.106
Fereastra DesignView pentru raportul rpt_ListaCandidati, obţinută cu
ajutorul utilitarului ReportWizard, înainte şi după modificarea manuală.
Modificările efectuate se referă la ştergerea sau editarea etichetelor,
mutarea, dimensionare şi formatarea câmpurilor,
editarea funcţiilor şi macro-urilor implicite folosite pentru numerotarea
paginilor şi afişarea datei curente.
FIG.107
Rezultatul (PrintPreview) înainte şi după efectuarea modificărilor.
FIG.108
Pentru raportul
rpt_Medii, sursa
datelor o
constituie tabelele
tbl_Candidati,
tbl_Probe şi
tbl_Note.
Modificarea
nivelelor propuse
de utilitarul
ReportWizard se
poate face
acţionând
controlul Priority.
FIG.109
Dialogul SummaryOptions permite precizarea funcţiilor agregat.
Se aplică funcţia Average pentru câmpul Nota.
FIG.110
Fragment din raportul creat automat, înainte de efectuarea modificărilor.
FIG.111
Raportul rpt_Medii, după efectuarea modificărilor.
2.6.3 Etichete
Crearea automată şi tipărirea etichetelor de corespondenţă având la bază

datele dintr-un tabel reprezintă o problemă care trebuie rezolvată de oricare
SGBD modern. În mediul Access, etichetele de corespondenţă sunt considerate
raport şi se creează conversaţional cu ajutorul utilitarului LabelWizard.
Etichetele conţin date specifice pe un format determinat.
De exemplu: adresele pe plicuri de corespondenţă, numele şi
organizaţia de provenienţă a participanţilor la o conferinţă, etichetele
de preţ pentru produse, numerotarea rafturilor dintr-o bibliotecă, etc.
Sursa de date pentru etichete poate fi un tabel sau o interogare.
De obicei, se folosesc etichete autocolante, în format standard sau definit
de utilizator. În FIG.112 se prezintă dialogul de selectare a formatului preferat
dintre tipurile de etichete standard recunoscute de mediul Access.
După crearea etichetelor cu ajutorul utilitarului LabelWizard, se pot efectua
modificări în modul DesignView, în mod similar modificării oricărui raport.
FIG.112
2.6.4 Exemplu
Pentru aplicaţia exemplu referitoare la examenul de admitere, se vor crea

etichete de corespondenţă pentru plicuri. Pentru listare se vor folosi etichete
autocolante standard J8161, cumpărate din librării.
FIG.113
Sursa datelor pentru etichete este tabelul tbl_Candidati.
S-a completat structura tabelului prin adăugarea câmpului Adresa.
FIG.114
Modul DesignView al
etichetei create cu
ajutorul utilitarului
LabelWizard.
FIG.115
Fragment din raportul creat automat, înainte de efectuarea modificărilor.
Ordonarea datelor s-a realizat după valoarea câmpului Legitimatie.
FIG.116
Raportul rpt_Etichete, după efectuarea modificărilor.
Observaţii:
 Chenarul s-a obţinut cu ajutorul unui Rectangle de pe Toolbox; pentru
chenar s-a stabilit proprietatea BackStyle = Transparent.
 Câmpul text “Dl. / D-na.” s-a înlocuit cu un câmp nou creat, de tip TextBox,
care conţine o formulă de adresare în funcţie de valoarea câmpului Sexul
din tabel. Proprietatea DataSource a acestuia se completează cu expresia
de calcul aferentă; se foloseşte utilitarul ExpressionBuilder.
 Pentru a scrie expresia corespunzătoare formulei de adresare, este
necesară includerea câmpului Sexul din tabelul tbl_Candidati; acest câmp
se va ascunde prin stabilirea proprietăţii Visible = No.
2.7 Macro-uri
Din prezentarea obiectelor anterioare şi exemplificarea modului lor de

utilizare rezultă că o aplicaţie poate fi construită dintr-o mulţime de obiecte care
se lansează într-o succesiune bine determinată.
2.7.1 Rolul macrocomenzilor
Macro-urile sunt obiecte Access care asigură legarea într-un flux continuu
a execuţiei operaţiilor referitoare la diferite obiecte. Comenzile macro permit
automatizarea lansării acţiunilor prin asocierea la un singur eveniment utilizator a
întregii succesiuni de operaţii.
De obicei, un macro se denumeşte după şablonul: mac_NumeMacro sau
macNumeMacro..
Din punct de vedere logic, un macro este similar unei secvenţe de program
VBA care execută succesiv aceleaşi comenzi. Avantajul utilizării macro-ului este
că acesta poate fi scris în mod conversaţional, fără ca utilizatorul să aibă
cunoştinţe de programare.
Macro-urile pot fi create numai în modul Design, prin precizarea acţiunilor

care se vor efectua şi a argumentelor acestora. În sensul macrocomenzilor, prin
argument se înţelege numele obiectului la care se referă acţiunea sau, după caz,
valorile parametrilor folosiţi în executarea acţiunii respective.
Fereastra de proiectare a unui macro are aspectul din FIG.117.
FIG.117
Principalele acţiuni care pot fi lansate din fereastra macro sunt:

 deschiderea sau închiderea de tabele, formulare sau rapoarte;
 lansarea de interogări;
 apelarea altor comenzi macro;
 căutarea de date;
 ştergerea, redenumirea, copierea sau salvarea unor obiecte;
 comunicarea cu programe compatibile, etc.;
După scriere şi testare, macro-urile se asociază unui eveniment; cele mai

folosite în scopul lansării macro-urilor, sunt:
 evenimentul OnClick al unui buton de comandă plasat pe un formular;
 evenimentul BeforeUpdate al unui control sau al unui formular;
 evenimentul AfterUpdate al unui formular;
 evenimentul OnClose al unui formular, etc.
2.7.2 Exemplu
Pentru aplicaţia exemplu referitoare la concursul de admitere, se

realizează un macro care lansează automat operaţiile necesare pentru
actualizarea câmpului Nota din tabelul tbl_Note.
FIG.118
Se creează interogarea qry_ScriuNota, de tip Select, folosind toate
câmpurile din tabelul tbl_Nota (care urmează să fie actualizat).
FIG.119
Se transformă interogarea Select în
interogare de tip Update, după care se
completează expresia de calcul folosind
utilitarul Build.
După prima rulare, mediul Acces ascunde
automat câmpurile a căror valoare nu se
modifică în procesul de actualizare.
Actualizarea câmpului Nota cu valoarea mediei celor două corecturi se

efectuează printr-o interogare de acţiune de tip Update. Expresia de calcul se
scrie în linia UpdateTo din coloana corespunzătoare câmpului Nota.
FIG.120
Se creează macro-ul
mac_ScriuNota care va
lansa interogarea de
acţiune qry_ScriuNota.
Calculul şi actualizarea notei se poate efectua astfel:

 după introducerea fiecărui articol, adică la evenimentul AfterUpdate
pentru formularul de introducere frm_Note creat anterior, sau
 pentru toate articolele la închiderea formularului, adică la activarea
evenimentului OnClose pentru formularul frm_Note.
FIG.121
Pentru formularul frm_Note, se stabileşte proprietatea OnClose. În acest mod, la
activarea evenimentului OnClose (acţionarea butonului de închidere a formularului), se
lansează mac_ScriuNota şi implicit, interogarea qry_ScriuNota.
Se testează funcţionarea formularului frm_Nota prin introducerea de date,

urmată de închiderea formularului. Se observă afişarea mesajelor de avertizare /
confirmare care demonstrează executarea interogării. Apoi, se verifică
corectitudinea datelor introduse în tabelul tbl_Note, aflat atât la baza interogării
cât şi a formularului.
Printre comenzile care se pot include în macro-uri, există şi comanda de
inhibare a mesajelor de avertizare / confirmare care apar în mod obişnuit în
timpul lucrului cu sursa de date. Aceasta este comanda SetWarnings, cu
argumentul No. Se recomandă introducerea comenzii de inhibare a mesajelor
numai după verificarea funcţionării corecte a aplicaţiei.
FIG.122
Folosind opţiunea Insert \ Rows din
fereastra de proiectare a macro-ului,
se adaugă comanda
SetWarning = No
pentru inhibarea mesajelor.
Observaţie:
Pentru completarea aplicaţiei se vor crea următoarele obiecte:
- formularul frm_Vizualizare care include butoane de comandă pentru
lansarea rapoartelor;
- formularul frm_Start care include butoane de comandă pentru lansarea
fomularelor frm_IntroDate şi frm_Vizualizare.
Cititorului acestei cărţi i se recomandă crearea formularelor precizate
precum şi a altor obiecte considerate utile în rezolvarea problemei propuse.
2.8 Elemente de VBA
Limbajul de programare VBA (Visual Basic for Application) a fost conceput

ca o încercare de standardizare a codului folosit de aplicaţiile Microsoft Office.
Rezultatul a fost un cod VBA comun, adaptat caracteristicilor fiecărei aplicaţii.
Pentru mediul Access 2000 şi versiunile următoare, codul VBA reprezintă un
limbaj de programare cu o multitudine de facilităţi avansate, compatibil cu
limbajul de programare inclus în versiunile anterioare.
Secvenţele de cod VBA sunt grupate în module. Astfel, un modul este o
colecţie de declaraţii şi proceduri salvate şi identificate sub un nume în scopul
organizării codului VBA.
În mediul Access se utilizează două tipuri de module: module standard şi
module de clasă.
 Modulele standard se caracterizează prin faptul că includ proceduri şi
funcţii pe care utilizatorul le doreşte a fi disponibile spre apelare de către
alte proceduri din baza de date. Modulele standard sunt obiecte de sine
stătătoare care se vizualizează în fereastra Database în tab-ul Modules.
Cu ajutorul lor se pot crea şi gestiona toate obiectele bazei de date.
 Modulele de clasă (Class Modules) se caracterizează prin faptul că pot
include definirea unor obiecte noi. Fiecare instanţă a unei clase creează un
nou obiect. Procedurile definite în modul devin proprietăţi şi metode ale
noului obiect.
Modulele clasă pot exista de sine-stătător (caz în care sunt afişate în
fereastra Database) sau ca secvenţe de cod VBA asociate cu alte obiecte din
baza de date (formulare, rapoarte, controale, etc.). Modulele de clasă
asociate formularelor şi controalelor incluse în acestea, se cunosc şi sub
denumirea de CBF (Code Behind Forms).
Pentru cele două cazuri, editorul VBA se lansează astfel:

 pentru modulele standard sau clasă de sine-stătătoare: prin deschiderea
unui obiect modul acţionând butonul New sau Design din fereastra
Database;
 pentru modulele de clasă legate de rapoarte sau formulare: prin stabilirea
valorii [Event Porcedure] pentru una dintre proprietăţile din tab-ul Event al
obiectului căruia i se asociază codul.
Lansarea editorului VBA în vederea modificării codului sursă al unui modul
existent se poate realiza prin acţionarea butonului Code de pe bara standard a
mediul Access (FIG.123).
FIG.123
FIG.124
Butoanele Go/Continue, End, Reset şi DebugWindow (FIG.124) de pe

bara cu butoane a ferestrei de editare a codului VBA se folosesc pentru
relansarea, oprirea, anularea şi respectiv urmărirea execuţiei codului.
2.8.1 Obiecte
Mediul MS-Access este un SGBD relaţional orientat pe obiecte. În acest

context este necesară definirea câtorva noţiuni legate de obiecte.
Un obiect este un „lucru” care „ştie” tot ce e necesar pentru a îndeplini
sarcinile în vederea căruia a fost proiectat. Un obiect poate fi compus la rândul
lui din alte obiecte – „un obiect poate fi o colecţie de alte obiecte” (de exemplu, o
bază de date - Database).
Proprietăţile sunt caracteristicile obiectelor.
Metodele sunt acţiuni ataşate obiectelor.
O clasă este o colecţie de obiecte cu aceleaşi proprietăţi şi metode.
Prin instanţă a unei clase se înţelege un obiect din clasa respectivă.
O colecţie conţine obiecte ale aceleiaşi clase (de exemplu, colecţia Forms
dintr-o bază de date).
Ierarhia obiectelor de acces la date este prezentată în FIG.125.
DBEngine Errors
Workspaces
Workspace Connections
Users
Groups
Databases
FIG.125
Database TableDefs
QueryDefs
unde:
Containers
Obiect Recordsets
Colecţie Relations
2.8.2 Evenimente
Pentru formularele Access, evenimentele se definesc în sens Windows,

adică ele se referă la ferestre, formulare sau controale şi au loc, de regulă, la
iniţiativa utilizatorului.
De exemplu, evenimente sunt: mişcarea mouse-ului, click cu
mouse-ul pe un buton de comandă, închiderea unui formular, etc.
O secvenţă de cod care descrie ceea ce trebuie să se întâmple la

declanşarea evenimentului respectiv se numeşte procedură de tratare a
evenimentului şi este asociată unui anumit eveniment al obiectului care “suferă”
evenimentul.
Procedurile de tratare a evenimentelor sunt denumite automat de mediul

Access cu un identificator ce include evenimentul şi obiectul căruia i se asociază.
Pentru fiecare obiect sau control, mediul Access pune la dispoziţia utilizatorului
un număr de evenimente detectabile prin program. Acestea sunt grupate în
tab-ul Events din caseta de dialog Properties a obiectului respectiv.
Principalele proprietăţi de tip eveniment asociate formularelor şi / sau
controalelor sunt:
 OnClick, OnDblClick
Se utilizează cel mai frecvent pentru butoane de comandă sau liste
derulante (ComboBox). Se declanşează în momentul executării unui click,
respectiv a unui dublu-click, cu butonul stâng al mouse-ului atunci când
cursorul se află deasupra controlului.
Evenimentul OnDblClick declanşează automat un eveniment OnClick care
îl precede.
 OnChange
Se utilizează pentru controale de tip TextBox, ComboBox, etc. Se
declanşează atunci când datele din control sunt modificate.
 On Enter
Se utilizează frecvent pentru controale. Se declanşează chiar înainte de
transferul cursorului către control în vederea selectării. Evenimentul opus
este On Exit.
 On GotFocus
Se utilizează frecvent pentru controale. Se declanşează la selectarea unui
control, înainte de activarea acestuia. Evenimentul opus este On
LostFocus.
 BeforeUpdate
Se utilizează atât pentru controale cât şi pentru formulare. Se declanşează
chiar înainte ca datele din sursa de date aflată la baza controalelor să fie
actualizată cu noile valori.
 AfterUpdate
Se utilizează atât pentru controale cât şi pentru formulare. Se declanşează
atunci când se editează sursa de date.
 On NotInList
Se utilizează pentru controale de tip listă derulantă (ComboBox). Se
declanşează atunci când utilizatorul introduce în caseta de editare o
valoare care nu există în lista predefinită.
Observaţie: pentru un control care suportă evenimentele menţionate

anterior (de exemplu: ComboBox), ordinea de declanşare a acestora este:
On Enter  On GotFocus  On Click  OnChange 
(OnNotInList  ) SAU (BeforeUpdate  AfterUpdate )
On Exit  On LostFocus
 On Open
Se utilizează pentru formulare sau rapoarte. Se declanşează la
deschiderea obiectului, înainte de afişarea sau previzualizarea vreunui
articol din sursa de date.
 On Load
Se utilizează pentru formulare sau rapoarte. Se declanşează la
deschiderea obiectului şi încărcarea sursei de date.
 On UnLoad
Se utilizează pentru formulare sau rapoarte. Se declanşează la închiderea
obiectului, înainte de ştergerea lui de pe ecran.
 On Activate
Se utilizează pentru controale, formulare sau rapoarte. Se declanşează în
momentul în care obiectul devine fereastră activă, în sens Windows.
Observaţie: pentru un formular, ordinea de declanşare a evenimentelor

menţionate este:
On Open  On Load  On Activate 
On UnLoad  On Deactivate  On Close
 On Error
Se utilizează frecvent pentru controale şi formulare. Se declanşează în
momentul în care se produce o eroare pe formularul curent. Procedura
asociată evenimentului are doi parametri:
- DataErr – returnează codul erorii care a declanşat evenimentul;
- Response – permite utilizatorului să stabilească dacă se va afişa sau
se va omite mesajul de eroare implicit. Valorile posibile sunt date de
constantele implicite: acDataErrContinue şi respectiv acDataErrDisplay.
2.8.3 Noţiuni de programare
Programarea VBA nu face obiectul prezentei cărţi, decât în măsura în care

oferă o înţelegere mai bună a modalităţilor prin care se tratează evenimentele în
mediul Access. În cele ce urmează se vor prezenta doar câteva dintre
instrucţiunile de programare utilizate în cele mai simple module.
Editorul VBA dispune de un instrument puternic pentru autocompletarea,
verificarea sintactică şi corectarea instrucţiunilor, chiar înainte de compilarea
codului. Utilizatorul familiarizat cu un limbaj de programare de nivel mediu va
putea scrie module simple cu un efort minim.
A. Declararea variabilelor
În cazul recomandat în care antetul de modul VBA conţine comanda
Option Explicit, toţi identificatorii care denumesc variabile trebuie declaraţi
înainte de folosirea lor. Tipul variabilelor se poate alege dintr-o listă derulantă
oferită de utilitarul editorului de program.
Concordanţa de tip se aplică similar cu majoritatea limbajelor de programare.
În plus, VBA pune la dispoziţia utilizatorului tipul Variant, compatibil cu toate
celelalte tipuri de variabile.
Cel mai frecvent folosite declaraţii de variabile au sintaxa:
Dim numevariabilă As numetip

Public numevariabilă As numetip
Prin cuvântul cheie Dim se declară o variabilă locală pentru procedură iar
Public declară un identificator global, cu vizibilitate în întreg modulul.
B. Comentarii
Comentariile sunt texte introduse de către programator în scopul măririi
clarităţii textului programului; se recomandă inserarea comentariilor deoarece ele
uşurează mult înţelegerea programului şi efectuarea oricăror modificări
ulterioare. Compilatorul ignorează comentariile.
Sintaxa comentariilor în VBA este:
REM text sau

‘ text
C. Afişarea datelor
Modul cel mai simplu de afişare a mesajelor sau a valorii variabilelor este
folosirea unei casete de dialog predefinită, cu un buton <OK>. Sintaxa
simplificată a comenzii este:
MsgBox (prompt [, title])
unde:
- prompt este un argument obligatoriu care defineşte ceea ce se
afişează. Poate conţine un text, numele unei variabile sau o expresie.
- title este un argument opţional prin care utilizatorul poate personaliza
titlul casetei de dialog.
D. Casete de dialog simple

Cel mai simplu mod de a realiza o interfaţă cu utilizatorul îl reprezintă casetele
de dialog cu butoane predefinite. Cu ajutorul lor programul afişează o
întrebare şi preia răspunsul selectat de utilizator. Butoanele de răspuns
predefinite pot fi combinaţii de tipul <OK> <Cancel> sau <Yes> <No>
<Cancel>. Sintaxa comenzii este:
MsgBox (prompt [, buttons] [, title])
unde:
- prompt şi title au semnificaţia prezentată la comanda anterioară.

- buttons (argument opţional) este o constantă numerică de tip
întreg care defineşte combinaţia butoanelor pe care caseta de
dialog le pune la dispoziţia utilizatorului.
Cele mai folosite valori sunt: vbOKOnly (implicită), vbOKCancel,
vbYesNo, vbYesNoCancel, vbAbortRetryIgnore. Valorile pot fi
detectate prin program şi utilizate în vederea testării condiţiilor
din instrucţiunile de decizie.
Obs. În acest caz, MsgBox are rolul unei funcţii care returnează
valoarea corespunzătoare butonului selectat în caseta de dialog.
E. Caseta de dialog tip text

Caseta de dialog afişează un control care permite utilizatorului introducerea/
editarea unui text. Textul poate fi preluat de program şi utilizat ca valoare a
unei variabile de tip String.
Sintaxa simplificată a comenzii este:
InputBox (prompt [, title])
Semnificaţia argumentelor prompt şi title este aceeaşi ca la comenzile

anterioare. InputBox are rolul unei funcţii care returnează textul introdus de
utilizator în caseta de dialog.
F. Decizia simplă
Instrucţiunile de decizie ramifică execuţia programului în funcţie de valoarea
de adevăr a unei condiţii logice. În VBA, decizia este implementată de
instrucţiunile If şi Select Case.
Sintaxa bloc simplificată a instrucţiunii If este:
If condiţie Then
instrucţiuni_1
[Else
instrucţiuni_2]
End If
G. DoCmd
Pentru programatorul începător, obiectul DoCmd poate fi privit ca una dintre
cele mai folosite comenzi Access. Cu ajutorul lui se pot lansa comenzi
referitoare la majoritatea obiectelor, de exemplu: deschiderea / închiderea
ferestrelor, formularelor sau rapoartelor, rularea interogărilor, etc.
Sintaxa simplificată este:
DoCmd.metodă [arg1, arg2, ...]
unde:
- metodă este un argument obligatoriu care precizează comanda care
trebuie lansată (de exemplu: OpenForm, Close, OpenReport, RunSQL,
SertWarnings, etc);
- arg1, arg2,… reprezintă argumentele metodei respective.
Observaţie: în scrierea corectă a comenzii utilizatorul începător este mult
ajutat de facilitatea de autocompletare a editorului VBA.
2.8.4 Exemplu
Pentru aplicaţia de gestionare a examenului de admitere se adaugă

următoarele:
- la introducerea unui nou candidat în baza de date, înainte de modificarea
tabelului, utilizatorului i se va solicita confirmarea corectitudinii datelor;
- la introducerea notelor pentru cele două corecturi, înainte de calcularea
mediilor se va face verificarea ca ecartul dintre cele două note să nu
depăşească 1 punct. În caz afirmativ, înregistrarea nu se va trece în tabel
şi se va solicita recorectarea lucrării.
Pentru confirmarea corectitudinii datelor se utilizează un modul de

clasă, asociat formularului frm_Candidati1. Modulul conţine două subrutine
declanşate de evenimentele BeforeUpdate şi respectiv OnError.
 Procedura BeforeUpdate se declanşează dacă utilizatorul părăseşte editarea

fie trecând la un nou articol, fie închizând formularul. Mediul Access afişează
un mesaj de confirmare (FIG.126) şi în funcţie de răspunsul utilizatorului se
va actualiza tabelul sau se va anula evenimentul BeforeUpdate şi se va relua
introducerea datelor.
FIG.126
 Dacă ultimul articol din sesiunea de lucru este un articol greşit şi nu se

doreşte introducerea lui în tabel, mediul Access afişează un mesaj de eroare
predefinit (acelaşi ca în FIG.128). Mesajul de eroare poate fi anulat prin
scrierea unei proceduri declanşate de evenimentul OnError.
Dezavantajul acestui mod de lucru este că nu se va lua în considerare nici o
eroare care apare pe parcursul execuţiei modulului.
Secvenţa de cod este următoarea:
Private Sub Form_BeforeUpdate(Cancel As Integer)

Dim raspuns As Integer
raspuns = MsgBox("Datele sunt corecte ? ", vbYesNo)
If raspuns = vbNo Then
Cancel = True 'se ANULEAZA evenimentul si se revine la introd. datelor
'la inchiderea form. avand ultimul articol gresit, apare eroare
End If
End Sub
Private Sub Form_Error(DataErr As Integer, Response As Integer)

Response = acDataErrContinue 'continua, INDIFERENT ce eroare apare pe form
End Sub
Pentru verificarea diferenţei dintre notele acordate de cei doi corectori,

se utilizează un modul de clasă asociat formularului frm_Note. Modulul conţine
două subrutine, astfel:
 Preluarea valorilor introduse în controalele corectura1 şi corectura2 se
realizează în momentul calculării mediei. Pentru aceasta se utilizează o
procedură asociată câmpului calculat fld_MediaCalculata declanşată de
evenimentul OnGotFocus.
În caz că valoarea absolută a diferenţei dintre corecturi depăşeşte 1, se
afişează un mesaj de eroare şi se memorează existenţa erorii într-o variabilă
publică.
 Scrierea articolului eronat în sursa de date este împiedicată prin utilizarea
unei proceduri asociate formularului frm_Note, declanşată de evenimentul
BeforeUpdate.
Secvenţa de cod este următoarea:
Option Compare Database

Option Explicit
Public eroare As Boolean
Private Sub fld_MediaCalculata_GotFocus()

eroare = False
Dim delta As Single
delta = Me![Corectura1].Value - Me![Corectura2].Value
If Abs(delta) > 1 Then
MsgBox "Notele nu se introduc in baza de date!" & Chr(13) & _
"Diferenta intre corecturi este mai mare ca 1", , "Eroare"
eroare = True
End If
End Sub
Private Sub Form_BeforeUpdate(Cancel As Integer)

If eroare Then
Cancel = True
End If
End Sub
Observaţii:
- Variabila eroare este o variabilă globală (valoarea ei se transmite de la o
procedură la alta). Din acest motiv ea trebuie declarată în secţiunea de
declaraţii a modulului folosind clauza Public.
- Cuvântul chete Me! desemnează formularul curent.
- Funcţia chr(13) returnează caracterul CarriageReturn.
- Editarea liniei de cod pe mai multe rânduri se realizează folosind separatorul
“ _ “.
- Proprietăţile tip Events ale formularului frm_Note sunt prezentate în FIG.127.
FIG.127
- La închiderea formularului, în cazul în care ultimul articol din sesiunea de

lucru este un articol greşit şi nu se doreşte introducerea lui în tabel, mediul
Access afişează un mesaj de eroare (FIG.128).
FIG.128
Secvenţa de cod pentru inhibarea detectării erorii, este:
Private Sub Form_Error(DataErr As Integer, Response As Integer)

Response = acDataErrContinue 'continua, INDIFERENT de eroare
End Sub
- În locul folosirii unui macro pentru scrierea notelor în tabel, se poate utiliza o
procedură asociată formularului frm_Note, declanşată de evenimentul
OnClose.
Secvenţa de cod care înlocuieşte macro-ul mac_ScriuNota este:
Private Sub Form_Close()

DoCmd.SetWarnings False
DoCmd.OpenQuery "qry_ScriuNota"
End Sub
3. APLICAŢII
Automatizarea proceselor informaţional - decizionale din cadrul unei unităţi

economice se poate realiza fie prin cumpărarea şi implementarea unui produs soft
existent, fie prin crearea unei aplicaţii proprii.
Dacă efectul scontat nu justifică preţul de achiziţionare şi implementare al
unui produs soft de utilitate generală, sau pachetele de programe existente pe
piaţă nu satisfac cerinţele specifice, atunci devine necesară proiectarea şi
integrarea unui produs informatic propriu. Această alternativă poate fi mai eficientă
nu numai sub aspectul unei informatizări complete şi corelate, ci şi din punct de
vedere al asistării deciziilor managerilor. În plus, analiza şi sinteza sistemului
informaţional - decizional propriu conduce, de obicei, la perfecţionarea structurilor
funcţionale şi organizatorice prin raţionalizarea şi optimizarea fluxurilor
informaţionale.
3.1 Consideraţii privind realizarea unui sistem informatic
Sistemul informatic se defineşte ca ansamblul de metode şi mijloace care

asigură preluarea datelor, transformarea lor în informaţie, prelucrarea sistematică a
acesteia prin utilizarea tehnicii de calcul şi furnizarea rezultatelor prelucrării sub
formă de informaţie interpretabilă.
Primul pas în realizarea unui sistem informatic, în conformitate cu
standardele naţionale şi internaţionale, este elaborarea unui studiu de fezabilitate
sau cel puţin a unui proiect director.
Pe baza proiectului director şi a realităţii tehnico-economice din unitatea

economică vizată, se desfăşoară apoi activitatea de analiză, proiectare,
programare, implementare şi exploatare a sistemului informatic.
3.1.1 Proiectul director
Proiectul director este principalul document care stă la baza realizării unei
aplicaţii dedicată informatizării unei activităţi economice precizate. El este un
instrument de definire şi conducere a acţiunilor de informatizare în concordanţă cu
cerinţele specifice şi posibilităţile tehnico-economice.
Proiectul director creează cadrul organizatoric şi precizează
responsabilităţile în elaborarea, execuţia şi implementarea sistemului informatic.
Astfel, el trebuie să puncteze următoarele:
justificarea sistemului informatic prin prisma efortului şi a rezultatelor previzibile;
personalul, din interiorul sau exteriorul unităţii, care participă la realizarea şi/sau
implementarea sistemului;
principalele etape ale realizării sistemului informatic şi aproximarea perioadei de
timp afectate fiecărei etape.
La realizarea proiectului director se recomandă:

♦ asigurarea consensului conducerii, a utilizatorilor finali şi a echipei de
informaticieni asupra obiectivelor, soluţiilor şi resurselor necesare. De obicei,
are loc organizarea şi motivarea colectivelor de lucru şi de avizare, fixarea
punctelor decizionale în derularea acţiunilor şi definirea priorităţilor.
♦ prefigurarea unor soluţii flexibile, modulare şi a unor condiţii de dezvoltare
ulterioară nerestrictivă. De obicei se adoptă conceptul de sistem informatic
deschis, în care se manifestă fenomene de reglare şi autoreglare, se stabileşte
aplicarea principiului parametrizării, se ţine cont de evoluţia organizaţiei şi a
informaticii, etc.
♦ asigurarea compatibilităţii sistemului informatic cu alte sisteme informatice
sau aplicaţii existente. Se identifică conexiunile informatice, colecţiile de date şi
clasificările comune, se stabilesc standardele, normele şi recomandările
naţionale sau internaţionale care se vor respecta, etc.
Proiectul director şi sistemul informatic rezultat depind esenţial de specificul

activităţii economice care face obiectul informatizării. Experienţa arată că pentru a
realiza un produs soft competitiv, proiectul director trebuie să conţină următoarele
elemente:
date preliminare, obiectivele şi funcţiile unităţii, aria de cuprindere a
sistemului informatic, obiectivele specifice acestuia, aprecierea importanţei
demersului;
situaţia existentă privind conducerea, organizarea şi informatizarea,
structura organizatorică şi de conducere, evaluarea sistemului
informaţional existent şi stadiul informatizării;
cerinţe şi obiective globale privind perfecţionarea conducerii, organizării şi
a informatizării, cum sunt: orientări principale, structuri centralizate sau
descentralizate, procese informaţionale vizate, resurse financiare
realocabile, indicatori estimaţi în aprecierea sistemului informaţional-
decizional;
soluţii de perfecţionare a sistemului informaţional cu precizarea domeniilor
de informatizat, a priorităţilor, a tehnologiei şi a arhitecturii sistemului
informatic preconizat, precum şi a efectelor scontate. Rezultate bune în
acest sens se pot obţine utilizând tehnica scenariilor;
un calendar al activităţilor incluzând obiective, termene şi personal
implicat;
estimarea costurilor de realizare şi a surselor de finanţare;
modalităţile de urmărire a derulării activităţilor şi a îndeplinirii obiectivelor.
Principalii factori implicaţi în elaborarea proiectului director sunt:

♦ comitetul director, format din personal de conducere;
♦ colectivul de utilizatori, care vor folosi şi întreţine sistemul informatic;
♦ şeful de proiect, desemnat de comitetul director;
♦ colectivul de analiză şi proiectare, din interiorul şi / sau exteriorul unităţii.
3.1.2 Elemente de analiză şi proiectare
Analiza şi proiectarea sistemelor informatice reprezintă o serie de principii

metode, concepte şi tehnici utilizate pentru prefigurarea, elaborarea şi
implementarea sistemelor informaţionale, care se bazează pe echipamentele
electronice de calcul.
Analiza este una dintre cele mai importante activităţi în realizarea unui
sistem informatic; încercarea de a crea un sistem informatic fără a efectua în
prealabil o analiză temeinică a fenomenului vizat conduce la “produse soft
haotice”, ineficiente atât din punct de vedere funcţional cât şi economic.
Analiza trebuie să stabilească specificul unităţii economice, necesităţile
acesteia, particularităţile unităţii şi a sistemului informaţional al acesteia,
necesităţile informaţionale ale conducerii în timp şi spaţiu, performanţele şi/sau
limitele resurselor disponibile şi în particular a echipamentelor electronice
disponibile, etc.
Proiectarea este activitatea care prefigurează structura viitorului sistem
informatic. Astfel, ea stabileşte:
Structura funcţională a sistemului informatic global al unităţii economice; ea
se obţine prin descompunerea consecvent descendentă în părţi denumite
sisteme, subsisteme, module, etc. Fiecare dintre acestea este o componentă
omogenă a sistemului global orientată spre a răspunde la totalitatea
problemelor specifice ale unei funcţii distincte a unităţii (producţie, transport,
personal, contabilitate, etc.) sau ale unui domeniu specific de activitate.
Structura tehnică a sistemului informatic conţine totalitatea mijloacelor
electronice de calcul utilizate pentru culegerea, pregătirea, stocarea,
transmiterea şi prelucrarea datelor. Ea se stabileşte prin inventarierea
mijloacelor electronice disponibile şi/sau achiziţionabile.
Structura informaţională a sistemului informatic cuprinde fondul principal de
date organizate în colecţii de date gestionate cu ajutorul metodelor specifice
bazelor de date.
ORGANIZAREA ∗ CONTRACT DE PROIECTARE

ANALIZEI ∗ DEVIZUL PROIECTANTULUI
SISTEMULUI ∗ ECHIPA DE PROIECTARE
INFORMAŢIONAL ∗ DOCUMENTAREA PRELIMINARĂ
∗ CULEGEREA DATELOR
ANALIZA ∗ ANALIZA CRITICĂ A SISTEMULUI INFORMAŢIONAL
ANALIZA ∗ DEFINIREA VARIANTELOR PROPUSE PENTRU
SISTEMULUI PROPRIU-ZISĂ VIITORUL SISTEM INFORMATIC
INFORMAŢIONAL
∗ ELABORAREA DOCUMENTAŢIEI DE ANALIZĂ A
SISTEMULUI INFORMAŢIONAL
∗ ORGANIZAREA ŞI CONDUCEREA PROIECTĂRII GENERALE
∗ DEFINIREA OBIECTIVELOR SISTEMULUI INFORMATIC
∗ PROIECTAREA SITUAŢIILOR DE IEŞIRE

PROIECTAREA
∗ PROIECTAREA BAZELOR DE DATE
GENERALĂ A
SISTEMULUI ∗
INFORMATIC
∗ PROIECTAREA FLUXULUI GENERAL AL PRELUCRĂRII
∗ ELABORAREA DOCUMENTAŢIEI PROIECTĂRII GENERALE
∗ PROIECTAREA OBIECTELOR BAZELOR

DE DATE (BD) ŞI A FIŞIERELOR
∗ PROIECTAREA ATRIBUTELOR SPECIFICE

FIŞIERELOR SAU OBIECTELOR BD
∗ PROIECTAREA RELAŢIILOR
∗ PROIECTAREA SCHEMELOR EXTERNE

PROIECTAREA DE PROIECTAREA ALE BD
DETALIU A DATELOR ŞI
SISTEMULUI PROIECTAREA ∗ PROIECTAREA VIDEOFORMATELOR PT.
PRELUCRĂRILOR INTRODUCEREA/LISTAREA DATELOR
INFORMATIC
∗ PROIECTAREA INTRĂRILOR ŞI IEŞIRI-
LOR UNITĂŢILOR DE PRELUCRARE
∗ PROIECTAREA UNITĂŢILOR DE
PRELUCRARE
∗ ELABORAREA DOCUMENTAŢIEI
IMPLEMENTAREA FAZELOR DE PROIECTARE A DATELOR ŞI
SISTEMULUI PRELUCRĂRILOR
INFORMATIC
∗ TESTAREA SISTEMULUI INFORMATIC
∗ DEFINITIVAREA SISTEMULUI
∗ DAREA ÎN FOLOSINŢĂ A SISTEMULUI INFORMATIC
EXPLOATAREA ŞI ∗ RECEPŢIONAREA SISTEMULUI INFORMATIC DE CĂTRE
DEZVOLTAREA UNITATEA BENEFICIARĂ
SISTEMULUI ∗ EXPLOATAREA CURENTĂ A SISTEMULUI
INFORMATIC ∗ ÎNTREŢINEREA SISTEMULUI INFORMATIC
∗ PERFECŢIONAREA SISTEMULUI INFORMATIC
FIG.129
Principalele etape şi succesiunea acestora în realizarea unui sistem

informatic global pentru o unitate economică sunt prezentate în FIG.129. Între
etape este necesară o sincronizare foarte bine pusă la punct obţinută prin
colaborarea între echipele care participă la realizarea produsului informatic.
3.1.3 Documentaţia însoţitoare
Metodologia de analiză şi proiectare a sistemului informatic prevede o

documentaţie specifică fiecărei etape, utilizată pentru reflectarea rezultatului
etapei, schimbul de informaţii între etape şi echipele de lucru, precum şi pentru
asigurarea unui dialog permanent între beneficiar şi proiectant.
Documentaţia se compune din două părţi diferenţiate în funcţie de
momentul elaborării:
Documentaţia de analiză şi proiectare este elaborată pe parcursul
etapelor de analiză şi proiectare, cuprinde un set de formulare care
oglindesc prin reguli şi metode informatice rezultatele etapelor.
Documentaţia de utilizare şi exploatare, numită şi documentaţie
însoţitoare, este elaborată în etapa de implementare a sistemului, fiind
destinată unităţii beneficiare şi / sau unităţii informatice care exploatează
efectiv sistemul. Documentaţia însoţitoare se compune din trei părţi:
documentaţie de prezentare, documentaţie de utilizare şi documentaţie de
operare-exploatare. Acestea conţin elemente tehnico-organizatorice şi
funcţional-metodologice necesare beneficiarului pentru utilizarea optimă a
noului sistem realizat.
Elaborarea atentă a documentaţiei, mai ales a celei de analiză şi
proiectare, este menită să asigure succesul procesului de analiză-proiectare-
elaborare-realizare-implementare. O documentaţie insuficientă sau inexactă
îngreunează mult munca echipei sau echipelor care lucrează la realizarea
produsului informatic şi influenţează negativ calitatea rezultatului final.
3.1.4 Principalele etape în realizarea unei aplicaţii
Metodologia schiţată în FIG.129 pentru analiza, proiectarea,

implementarea şi exploatarea unui sistem informatic implică activitatea
organizată a mai multor echipe de specialişti, informaticieni şi economişti.
Realizarea unui sistem de asemenea anvergură depăşeşte cu mult posibilităţile
de cuprindere ale unei singure persoane.
În practică, specialistul în economie sau în informatică economică este pus
în situaţia de a realiza aplicaţii simple sau sisteme informatice de dimensiuni
reduse orientate spre rezolvarea unor probleme imediate care au o arie de
cuprindere mai mică. Munca sa va fi ghidată de următoarele etape:
I. Analiza problemei şi proiectarea aplicaţiei care constă în:

a. formularea problemei prin: studierea activităţii vizate de aplicaţie,
precizarea funcţiilor compartimentului în care se încadrează problema,
identificarea informaţională a compartimentului şi a modului de conectare
din punct de vedere informaţional cu celelalte compartimente, etc.;
b. identificarea şi studierea actelor normative care reglementează activitatea
vizată;
c. analiza şi inventarierea documentelor care participă la fluxul informaţional;
d. precizarea situaţiilor de ieşire (listelor);
e. stabilirea datelor de intrare necesare;
f. construirea unui model matematic sau a unei scheme privind structura
funcţională a sistemului informatic (prefigurarea obiectelor din baza de
date);
g. proiectarea datelor şi a tabelelor;
h. stabilirea datelor de intrare / ieşire;
i. stabilirea relaţiilor între tabele;
j. stabilirea metodelor de prelucrare necesare;
k. stabilirea drepturilor de acces şi proiectarea sistemului de parole pentru

securitatea informaţiei;
l. stabilirea algoritmului de rezolvare pentru fiecare sarcină în parte, eventual
cu reprezentare grafică printr-o organigramă.
II. Realizarea aplicaţiei care constă în:

m. construirea obiectelor şi a modulelor de program, corespunzător fiecărei
sarcini a sistemului informatic, pe baza algoritmului, folosind un limbaj de
programare sau un mediu de dezvoltare şi programare adecvat;
n. testarea morfologică şi sintactică a fiecărui modul de program în parte;
depanarea acestuia utilizând compilări şi rulări succesive;
o. întocmirea unui meniu sau program cadru prin intermediul căruia se pot
lansa în execuţie sarcinile specifice ale aplicaţiei;
p. verificarea schimbului de informaţie între obiecte; precizarea corectă a
parametrilor transmişi şi verificarea valorii variabilelor globale;
q. validarea funcţionării aplicaţiei prin urmărirea rezultatelor obţinute şi
compararea lor cu rezultatele obţinute pe altă cale sau calculate manual
pe un exemplu simplu;
r. întocmirea documentaţiei de utilizare care va conţine în mod obligatoriu
descrierea meniurilor, prezentarea principalelor machete de ecran,
structura tabelelor, modelul rapoartelor de ieşire, etc.
III. Exploatarea aplicaţiei care constă în:

s. utilizarea aplicaţiei folosind date reale, în condiţiile practice pentru care a
fost concepută;
t. actualizarea permanentă a bazelor de date;
u. eventuale modificări şi / sau îmbunătăţiri aduse aplicaţiei.
3.2 Efectuarea reducerilor de preţuri într-un magazin en-gros
Aplicaţia tratează gestiunea unui magazin en-gros de băuturi, în care se

efectuează periodic reduceri de preţuri la anumite categorii de produse. Pe lângă
utilitatea practică a aplicaţiei, s-a urmărit caracterul didactic al prezentării prin:
folosirea obiectelor studiate în capitolele anterioare;
ilustrarea facilităţilor oferite de mediul Microsoft Access;
parcurgerea explicită a etapelor de analiză şi proiectare a unei aplicaţii
reale de anvergură.
§1. CONSIDERAŢII PRIVIND APLICAŢIA
Activitatea vizată de aplicaţie se referă la un magazin en-gros de băuturi în

care se fac reduceri de preţ sezoniere. Informatizarea activităţii presupune
culegerea datelor, întocmirea automată a listelor de preţ care includ reduceri şi
refacerea preţului iniţial după trecerea perioadei de reducere. Ţinând cont de
scopul didactic al produsului informatic, sunt prezentate toate fazele necesare
realizării aplicaţiei, incluzând explicaţii detaliate, capturi de ecran şi comentarii.
§2. ANALIZA ŞI PROIECTAREA APLICAŢIEI
Etapele parcurse în fazele de analiză şi proiectare conduc la realizarea

unui produs soft care ţine o evidenţă simplificată a produselor existente în
magazin, permite efectuarea interactivă a reducerilor de preţuri şi obţinerea unor
situaţii privind preţurile practicate.
§2.1. Elemente de analiză
Analiza efectuată în vederea realizării sistemului de evidenţă a preţurilor

produselor în condiţiile efectuării periodice a unor reduceri de preţuri, parcurge
următoarele etape:
A. formularea problemei prin studierea activităţii vizate de sistemul

informatic şi identificarea informaţională a tuturor participanţilor la
rezolvarea problemei.
Prezenta analiză vizează activitatea desfăşurată în cadrul unui magazin

en-gros de băuturi, în care se efectuează reduceri de preţuri. Pentru evidenţa
preţurilor produselor se utilizează un calculator.
În magazinul considerat, se comercializează băuturi alcoolice şi
ne-alcoolice pe baza unor liste de preţuri şi elemente de analiză întocmite în
urma fiecărei modificări de preţuri.
Pentru simplificarea problemei, se consideră că preţul este o
caracteristică a produsului. Această simplificare nu afectează funcţionarea
aplicaţiei, deoarece nu se urmăreşte înregistrarea documentelor de vânzare /
cumpărare a mărfurilor din magazin; înregistrările se referă numai la date privind
preţul produselor şi reducerile de preţuri.
B. identificarea şi studierea actelor normative care reglementează

activitatea vizată de sistemul informatic.
Deoarece sistemul informatic se referă la o arie restrânsă din activitatea

magazinului de băuturi, se aplică principiile de bază ale contabilităţii de gestiune
şi normele cuprinse în Legea 82 / 1991 cu modificările şi completările ulterioare.
C. analiza şi inventarierea documentelor care participă la fluxul

informaţional.
Documentele care participă la fluxul informaţional sunt:

Lista produselor comercializate. Acesta este un document pe suport hârtie
şi conţine toate datele necesare pentru a identifica univoc fiecare produs:
categoria din care face parte, gramajul (per ambalaj) şi preţul de livrare.
Notă internă privind modificările de preţ. Acesta este un document pe
suport hârtie care conţine date referitoare la preţul produselor; preţul de
nomenclator se poate modifica în funcţie de condiţiile de aprovizionare, de
situaţia de pe piaţă, etc.
Notă internă privind reducerile de preţuri. Acesta este un document pe
suport hârtie şi conţine dispoziţia de reducere de preţ pentru o anumită
categorie de produse; reducerea de preţ se efectuează la iniţiativa
conducerii magazinului, în funcţie de raportul actual dintre vânzare, cerere,
stocuri şi posibilitatea de aprovizionare.
Liste de preţuri şi documente de analiză întocmite conform celor precizate
la pct.D.
D. precizarea situaţiilor de ieşire (listelor)
Situaţiile pe care le întocmeşte aplicaţia sunt:

Nomenclatorul de produse. Acesta conţine denumirea tuturor produselor
comercializate în magazin, grupate pe categorii.
Lista preţurilor de nomenclator. Aceasta conţine datele de identificare a
produselor şi preţurile acestora, fără a se fi efectuat reduceri de preţuri
sezoniere.
Lista de preţuri. Aceasta conţine datele de identificare a produselor şi
preţurile actuale, în condiţiile în care s-au făcut reduceri de preţuri pentru o
anumită categorie de produse.
Analiza preţurilor unitare. Acest raport conţine toate produsele inclusiv

gramajul şi preţul actual, la care se adaugă un calcul privind valoarea unui
litru în condiţiile date. Se permite astfel compararea preţului în cazul
cumpărării aceluiaşi produs în diferite ambalaje.
Etichete de preţ. Se efectuează listarea automată, pe etichete autocolante
a preţurilor actuale ale produselor, în vederea afişării lor conform legii.
E. stabilirea datelor de intrare necesare.
Datele de intrare sunt preluate de pe documentele de intrare şi constă în:

datele de identificare a fiecărui produs: denumire, gramaj, preţ;
noile preţuri ale produselor, în cazul modificărilor de preţ;
categoria de produse la care se face reducere şi mărimea reducerii
aplicate, exprimată procentual faţă de preţul de nomenclator.
F. structura funcţională a sistemului informatic obţinută prin construirea

unui model matematic sau a unei scheme sau prin precizarea detaliată a
sarcinilor impuse aplicaţiei.
Structura funcţională a programului derivă din natura activităţii vizate.

Astfel sunt:
∗ Introducere de date:
Date referitoare la categoriile de produse comercializate,
Lista gramajelor uzuale pentru băuturile comercializate,
Date referitoare la produse nou introduse în nomenclator,
Date referitoare la modificările de preţuri,
Date referitoare la reducerile de preţuri practicate.
∗ Prelucrări de date privind:

Actualizarea datelor referitoare la preţul produselor,
Actualizarea listei de preţuri în cazul reducerilor de preţ,
Verificarea gramajelor standard şi introducerea în listă a unor valori noi.
∗ Efectuarea de calcule privind:

Preţul produselor în urma aplicării reducerii de preţ,
Preţul unui litru de băutură în cazul comercializării în ambalaje de diverse
capacităţi.
∗ Sortări după diverse criterii: categoria, produsul, etc.,
∗ Interogări pentru obţinerea datelor care stau la baza situaţiilor întocmite,
∗ Întocmirea, afişarea şi tipărirea situaţiilor de ieşire.
§2.2. Alegerea SGBD-ului adecvat
SGBD-ul ales pentru realizarea aplicaţiei trebuie să îndeplinească

următoarele condiţii:
să realizeze uşor relaţii între datele din tabele;
să permită actualizări complexe şi repetate ale datelor;
să permită interogarea avansată a bazei de date;
să permită realizarea unei interfeţe prietenoase, cu efort minim;
să permită dezvoltări ulterioare, inclusiv legarea de alte aplicaţii pentru
rezolvarea unor probleme conexe;
să permită manipularea datelor în condiţii de securitate ridicată;
să poată fi folosit cu uşurinţă atât de către utilizatori cât şi de către
programatori;
să fie un SGBD de uz general, pentru care majoritatea societăţilor dispun
de licenţă.
G. Precizarea mediului de programare care se va utiliza.
Având în vedere cele de mai sus, s-a optat pentru Microsoft Access. Acesta
este un SGBD relaţional modern, componentă a pachetului de programe
Microsoft Office, deosebit de răspândit pe calculatoarele personale. MS-Access
prezintă toate facilităţile necesare pentru realizarea aplicaţiei, siguranţă în
exploatare şi rulează în condiţii de viteză satisfăcătoare pe majoritatea
calculatoarelor personale existente momentan în România.
§2.3. Proiectarea tabelelor şi stabilirea relaţiilor
Având în vedere caracterul orientat pe obiecte al SGBD-ului ales, se

realizează întâi proiectarea tabelelor de bază, se stabilesc relaţiile între tabele,
se precizează metodele de prelucrare a datelor, după care se proiectează
celelalte obiecte necesare.
H. proiectarea tabelelor, realizată pe baza analizei datelor de intrare.

Specificul aplicaţiei impune stocarea datelor aflate la dispoziţia
utilizatorului în trei tabele principale:
♦ tblCategorii conţine date despre categoriile de produse comercializate. În

FIG.130 este prezentat tabelul tblCategorii atât în modul de vizualizare
proiectare (DesignView) cât şi în modul de utilizare (DatasheetView).
Observaţii:
- Câmpul CategorieID este cheia primară a tabelului; pe baza informaţiei
din acest câmp se identifică univoc articolele tabelului.
- Tipul de date din fiecare câmp rezultă din figură.
FIG.130
♦ tblGramaj conţine o listă cu capacităţile ambalajelor uzuale în comerţul cu

băuturi. În FIG.131 se prezintă conţinutul tabelului tblGramaj.
Observaţii:
- Pentru memorarea valorilor se utilizează un
tabel (în locul unei liste simple de tip Look-up
în tabelul tblProduse) deoarece, pe parcursul
utilizării aplicaţiei, tabelul va fi completat cu
valorile întâlnite la diverse tipuri de ambalaje.
- Câmpul Gramaj este de tip text pentru a
permite introducerea datelor într-un format cât
mai apropiat de cel uzual în comerţ.
FIG.131
♦ tblProduse, prezentat în FIG.132, conţine datele referitoare produse.
FIG.132
Observaţii:
- Cheia primară este de tipul AutoNumber şi reprezintă un număr de ordine,
fără a avea o semnificaţie deosebită în evidenţa produselor. În caz că este
necesară identificarea produselor pe baza unui cod alfanumeric, se va
renunţa la câmpul de tip Autonumber şi se va folosi un câmp CodProdus, de
tip text, care va fi cheia primară a tabelului.
- Câmpul CategorieID asociază produsului una dintre categoriile prezentate în
tabelul tblCategorii. Câmpul este de tip Number şi conţine identificatorul
categoriei (CategorieID), aşa cum este el definit în tabelul tblCategorii. Pentru
uşurinţa folosirii aplicaţiei, se afişează numele categoriei, iar corespondenţa
este făcută printr-un Look-up Wizard cu căutarea datelor existente într-un alt
tabel. În figură se vizualizează începutul interogării aferente, în SQL View.
- La realizarea câmpului GramajID s-a folosit un Look-up Wizard cu căutarea
datelor într-un alt tabel. În acest mod se afişează o listă derulantă din care
utilizatorul poate selecta capacitatea ambalajului pentru produsul
comercializat sau, dacă este necesar, poate introduce o nouă valoare de tip
text.
- Preţul unitar va fi exprimat în formatul Currency, particularizat pentru afişarea

valutei „LEI”. În acest scop, valoarea proprietăţii Format va fi stabilită la:
#,##0.00" LEI";-#,##0.00" LEI"
I. funcţionarea aplicaţiei şi stabilirea tabelelor auxiliare
Pentru aplicarea reducerilor de preţ, efectuarea calculelor, actualizarea

datelor şi selectarea informaţiei în vederea obţinerii rapoartelor se vor utiliza
interogările. Din modul de funcţionare al interogărilor în Access, rezultă
necesitatea introducerii unui tabel auxiliar.
♦ Lista este un tabel cu conţinut asemănător tabelului tblProduse. El se

creează ca o “dublură” a tabelului tblProduse şi se foloseşte pentru obţinerea
listei de preţuri după efectuarea reducerii de preţ. Tabelul Lista este necesar
pentru a se putea efectua reducerile de preţ, fără ca preţurile memorate în
tabelul tblProduse, să fie modificate. Tabelul Lista se creează folosind
câmpurile din tabelele de bază, cu ajutorul unei interogări Make-Table.
Din punct de vedere funcţional, implementarea unei reduceri de preţ se

realizează după cum urmează:
se creează tabelul Lista, conţinând câmpuri din tabelele de bază;
se cere introducerea de la tastatură a numelui categoriei asupra căreia se
aplică reducerea de preţ;
se cere introducerea de la tastatură a procentului de reducere;
se aleg produsele din categoria specificată şi se aplică reducerea.
În urma acestor consideraţii, tab-ul Tables al aplicaţiei, are aspectul din
FIG.133.
FIG.133
J. stabilirea relaţiilor între tabele, în mod specifc SGBD-ului ales:
Fereastra Relationships prezentată în FIG.134 ilustrează structura datelor

ce corespunde modului de funcţionarea descris mai sus. Relaţiile între tabelele
de bază sunt controlate logic prin impunerea integrităţii referenţiale.
FIG.134
Relaţiile dintre tabele sunt stabilite în urma analizei efectuate mai sus, astfel:
unu-la-mai-mulţi, între tblCategorii şi tblProduse, astfel unui articol din
tblCategorii îi pot corespunde mai multe articole din tblProduse, adică: în mod
normal, pentru fiecare categorie se găsesc în nomenclator mai multe produse.
Câmpul de legătură este CategorieID, cheie primară în tabelul tblCategorii şi

cheie străină în tabelul tblProduse.
unu-la-mai-mulţi, între tblGramaje şi tblProduse, astfel unui articol din
tblGramaje îi pot corespunde mai multe articole din tblProduse, adică: un
anumit gramaj este caracteristic pentru mai multe produse.
Observaţii:
- Ambele relaţii au fost create automat, concomitent cu folosirea utilitarului
Look-up Wizard pentru câmpurile implicate.
- Deoarece se şterge şi se re-creează ori de câte ori se efectuează reduceri de
preţ, tabelul auxiliar nu este implicat în procesul de stabilire a relaţiilor.
§2.4. Descrierea obiectelor folosite
Aplicaţia, în forma sa finală, utilizează următoarele obiecte:

Tabele – pentru stocarea datelor (în modul descris anterior);
Interogări (FIG.135) – pentru:
- combinarea, sortarea şi filtrarea datelor,
- efectuarea de calcule şi operaţii totalizatoare;
Formulare (FIG.136) – pentru:
- introducerea datelor,
- realizarea meniurilor;
Rapoarte (FIG.137) – pentru sintetizarea datelor şi vizualizarea listelor;
Macro (mac_Afisez_ListaDePreturi) – pentru lansarea în execuţie a unui
modul;
Modul VBA (mdl_FacReduceri) – pentru preluarea interactivă a datelor şi
derularea automată a unei secvenţe de comenzi.
Majoritatea formularelor au proceduri legate de evenimente (Code Behind

Forms). Aceste proceduri s-au realizat fie cu ajutorul utilitarelor de tip Wizard, fie
aplicând elemente de programare în VBA.
Denumirea obiectelor sugerează atât tipul obiectului la care se referă cât şi

rolul pe care îl are în aplicaţie. Unde a fost necesar s-au folosit denumiri scurte
pentru a nu depăşi lungimea maximă a expresiilor SQL incluse în macro-uri
(acest lucru este necesar doar până la versiunea Access ’97).
FIG.135
FIG.136
FIG.137
§2.4.1. Implementarea reducerilor de preţ
Aplicaţia magazin1.mdb este varianta primară a soft-ului magazin2.mdb

pentru evidenţa preţurilor din magazinul considerat. În această primă fază,
obiectele utilizate sunt:
Tabele – pentru stocarea datelor (aceleaşi ca în aplicaţia finală);
Interogări – pentru implementarea reducerilor de preţ (aceleaşi ca în aplicaţia
finală);
Raportul rpt_Lista_de_preturi – pentru afişarea listei de preţuri în urma
implementării unei reduceri de preţ;
Macro mac_Fac_Reduceri – pentru derularea automată a unei succesiuni de
operaţii.
Pentru implementarea reducerilor de preţ, se utilizează 2 interogări de

acţiune (FIG.135), în următoare succesiune:
a. Se creează interogarea qry1_FacLista, de tip Make-Table, care:

- Se bazează pe tabelele tblProduse, tblCategorii, tblGramaj.
- Creează tabelul auxiliar Lista care conţine informaţia utilă pentru calculul
preţurilor în condiţiile efectuării de reduceri de preţ.
- Tabelul intermediar Lista este necesar pentru a nu modifica preţurile din
nomenclator (la un moment de timp ulterior, se va reveni la preţul de
nomenclator şi se va face, eventual, o reducere de preţ la o altă categorie
de produse).
Fereastra Design a interogării qry1_FacLista este prezentată în FIG.138.
Observaţii:
- Se creează întâi interogarea de tip Select, bazată pe câmpurile care vor
constitui viitorul tabel.
- Se transformă în interogare de tip Make-Table; numele noului tabel e Lista.
- Mesajele de avertizare pentru suprascrierea tabelului vor fi ignorate.
FIG.138
b. Se creează interogarea qry2_Reducere, de tip Update, astfel:

- Se creează interogarea de tip Select bazată pe tabelul Lista;
- Se precizează numele parametrului care va permite dialogul utilizator în
vederea selectării categoriei ce urmează a avea preţ redus (FIG.139);
- Se transformă în interogare de tip Update;
- Folosind utilitarul Build, se introduce în linia UpdateTo a câmpului Pret
expresia de calcul a preţului redus (FIG.140).
FIG.139
FIG.140
În FIG.141 este prezentată forma finală a interogării qry2_Reducere, în

modul de vizualizare Design.
FIG.141
Observaţii:
- Câmpul Pret va fi actualizat şi va conţine preţul produsului după aplicarea
reducerii de preţ; expresia pentru efectuarea calculelor, creată cu utilitarul
Build este:
[Pret]-[Pret]*[Procent reducere]/100
- Interogarea are doi parametri de tip text prin care se solicită utilizatorului
introducerea explicită a denumirii categoriei la care se face reducere şi
valoarea procentuală a acestei reduceri.
În FIG.142 se prezintă dialogul datorat celor doi parametri, pentru cazul în
care se face o reducere de 10% la bere. Dialogul se lansează la fiecare rulare
a interogării.
FIG.142
- La rularea interogării se observă că ar fi mai uşor pentru utilizator să introducă

întâi numele categoriei şi apoi valoarea procentului de reducere aplicat
asupra acesteia. Pentru a inversa ordinea în care MS-Access solicită
introducerea parametrilor se va face o declaraţie a parametrilor, în ordinea
dorită (FIG.143).
FIG.143
c. se creează raportul rpt_Lista_de_preturi, care prezintă într-o formă estetică

articolele din tabelul Lista. Rezultatul este o listă de preţuri care conţine
preţurile curente, în condiţiile existenţei unei reduceri de preţ la una dintre
categoriile comercializate.
Un fragment al listei obţinute, la o reducere de 10% aplicată pentru categoria
bere, este prezentat în FIG.144.
FIG.188
FIG.144
Observaţii:
- Raportul, creat cu ajutorul utilitarului ReportWizard, are la bază tabelul Lista;
- Gruparea produselor se face după denumirea categoriei din care fac parte;
- Pentru ca datele din câmpul Pret să fie afişate în formatul personalizat din
figură, se intervine asupra câmpului Pret din banda Detail a raportului şi se
stabileşte pentru acesta proprietatea Format la aceeaşi valoare ca în tabelul
tblProduse: #,##0.00" LEI";-#,##0.00" LEI"
- Pentru îmbunătăţirea aspectului, s-au folosit instrumentele cuprinse în
ToolBox (linii, culori), precum şi modificarea elementelor de text, antet şi
poziţii ale câmpurilor.
d. Se rulează de câteva ori cele două interogări, în ordinea în care au fost create
şi se verifică funcţionarea aplicaţiei prin afişarea listei de preţuri cu ajutorul
raportului.
e. Se creează macrocomanda mac_Fac_Reduceri care realizează lansarea

succesivă a celor 2 interogări de acţiune create anterior, urmate de fişarea
raportului.
Fereastra de proiectare a macrocomenzii este prezentată în FIG.145.
FIG.145
Observaţii:
- Comanda SetWarnings, cu argumentul No, inhibă afişarea mesajelor de
informare / confirmare aferente tuturor comenzilor care o urmează.
- Versiunile MS-Access 2000 şi XP, permit folosirea comenzii OpenQuery în loc
de comanda RunSQL, simplificând astfel scrierea argumentelor.
§2.4.2. Definitivarea succesiunii de operaţii
Interogarea cu parametru qry2_Reducere solicită utilizatorului printr-un

dialog rudimentar (FIG.142) să introducă valori de tip text. Pentru a îmbunătăţi
aspectul dialogului, în locul macrocomenzii mac_Fac_Reduceri lansarea
secvenţei de operaţii se va face cu ajutorul unui modul VBA.
Observaţie: în cele ce urmează se lucrează pe o copie a fişierului

magazin1.mdb, copie care va deveni varianta finală magazin2.mdb.
f. Se creează modulul mdl_FacReduceri, care implementează reducerea de

preţuri cu ajutorul mediului VBA.
Textul sursă al modulului mdl_FacReduceri este prezentat în continuare:

Option Explicit
Public VCateg As String
Public VRed As Integer
' Fac_Reduceri
Function Fac_Reduceri()
On Error GoTo Fac_Reduceri_Err
VCateg = InputBox("La ce categorie doriti sa faceti reducere ? ")
VRed = InputBox("Procentul de reducere aplicat: ")
' Inhib afisarea mesajelor de confirmare

' Fac tabelul Lista din tblProduse

DoCmd.OpenQuery "qry1_FacLista", acNormal, acEdit
' Efectuez reducerile de pret NUMAI la produsele din categoria stabilita

Rem DoCmd.OpenQuery "qry2_Reducere", acNormal, acEdit
Rem Preiau comanda din SQL View, modific conditiile, apoi sterg interogarea
DoCmd.RunSQL ("UPDATE Lista SET Lista.Pret = [Pret]-[Pret]*" _

& VRed & "/100" _
& " WHERE ((Lista.CategorieNume)=" & " ' " & VCateg & " ' );")
' Vizualizez raportul rpt_Lista_de_preturi

DoCmd.OpenReport "rpt_Lista_de_preturi", acPreview
' Reactivez afisarea mesajelor de confirmare

DoCmd.SetWarnings True
Fac_Reduceri_Exit:
Exit Function
Fac_Reduceri_Err:
MsgBox Error$
Resume Fac_Reduceri_Exit
End Function
Observaţii:
Modulul conţine funcţia Fac_Reduceri () care execută toate operaţiile pe care
trebuie să le îndeplinească modulul; ea va fi lansată ulterior dintr-un macro.
Pentru a renunţa la utilizarea interogărilor cu parametru, se foloseşte
comanda RunSQL.
Textul interogării, argument al comenzii RunSQL, se preia în modul următor:
- se afişează interogarea în SQL View,
- se selectează textul şi se copiază în Clipboard,
- se comută în fereastra de proiectare a modulului şi se “lipeşte” textul
interogării în zona argument a comenzii RunSQL,
- interogarea se închide fără salvare.
Se modifică textul SQL astfel încât parametrii interogărilor se înlocuiesc cu
variabilele de tip text declarate în partea publică a modulului.
Modulul conţine comentarii sugestive pentru fiecare comandă inclusă.
g. Se proiectează macro-ul mac_Afisez_ListaDePreturi, care are rolul de a

lansa în execuţie funcţia Fac_Reduceri () din modulul mdl_FacReduceri.
Fereastra Design a macrocomenzii este prezentată în FIG.146.
FIG.146
h. Se şterge definitiv interogarea qry2_Reducere deoarece nu mai este

necesară pentru funcţionarea aplicaţiei, rolul ei fiind preluat de instrucţiunea
SQL din modulul VBA.
§2.4.3. Introducerea / modificarea datelor
Aplicaţia conţine interfeţe prietenoase pentru introducerea / modificarea

datelor, realizate cu ajutorul formularelor. Formularele care afişează date au fost
create cu ajutorul utilitarelor de tip Wizard. Pentru simplitate, de regulă, s-a
păstrat denumirea şi formatul câmpurilor din tabelele sau din interogările aflate la
baza formularelor.
a. Introducerea datelor referitoare la categorii

Pentru introducerea datelor referitoare la categoriile de produse, se utilizează
formularul frm_IntroCategorii prezentat în FIG.147.
FIG.147
Observaţii:
- Formularul are la bază tabelul tblCategorii;
- S-au modificat proprietăţile Caption, MinMaxButtons şi DataEntry (Yes);

- Lista derulantă creată în tabel pentru câmpul Localitate a fost preluată
automat în formular;
- Formularul va fi folosit atât pentru introducerea datelor despre clienţii noi cât
şi pentru modificarea datelor referitoare la clienţii existenţi.
b. Introducerea capacităţii ambalajelor folosite

Pentru introducerea datelor referitor la gramajele ambalajelor, se utilizează
formularul frm_GramajNou prezentat în FIG.148.
FIG.148
Observaţii:
- Formularul are la bază tabelul tblGramaj;
- Formularul va fi folosit atât pentru introducerea datelor în mod explicit, cât şi
pentru actualizarea listei de gramaje pe parcursul introducerii unui produs
nou.
c. introducerea datelor referitoare la un produs nou

Pentru introducerea datelor referitoare la produse noi, se utilizează formularul
frm_IntroProduse prezentat în FIG.149.
FIG.149
Observaţii:
- Formularul are la bază tabelul tblProduse;
- Listele derulante pentru câmpurile Categorie şi Gramaj, create în tabel prin
utilitarul LookupWizard, au fost preluate automat în formular;
- În situaţia în care capacitatea ambalajului pentru noul produs lipseşte din listă,
programul afişează un mesaj de avertizare (FIG.150), după care iniţiază
dialogul de introducere a noului ambalaj (FIG.151).
Procedura declanşată de evenimentul NotInList din modulul de clasă asociat
formularului frm_IntroProduse este prezentată în FIG.152.
FIG.150
FIG.151
Private Sub GramajID_NotInList (NewData As String, Response As Integer)

raspuns = MsgBox ("Gramaj nou ?", vbYesNo)
If raspuns = vbYes Then
DoCmd.OpenForm "frm_GramajNou", , , , , acDialog
DoCmd.Close acTable, "tblGramaj", acSaveYes
GramajID.Value = Null
GramajID.Requery
End If
Response = acDataErrContinue 'const - nu va afisa mesajul implicit
End Sub
FIG.152
d. modificarea preţului pentru produsele din nomenclator

Se creează interogarea qry_ModificPret, de tip Select, care combină datele
din tabelele de bază şi le sortează alfabetic după valorile a două câmpuri.
Fereastra Design a interogării este prezentată în FIG.153.
FIG.153
Pentru modificarea datelor se utilizează un formular cu subformular:

frm_ModificPret şi frm_ModificPret Subform. (FIG.154)
FIG.154
Observaţii:
- Formularul are la bază interogarea qry_ModificPret.
- Formularul s-a creat cu ajutorul utilitarului FormWizard, articolele grupându-se
după câmpul CategorieNume.
- Pentru interzicerea modificărilor accidentale şi obţinerea aspectului prezentat,

s-au folosit instrumentele de pe bara cu unelte (Toolbox), proprietăţile
formularului: Caption, NavigationButtons, AllowDeletion (No), AllowAddition
(No), ScrollBars, RecordSelector, DividingLines, etc., precum şi proprietatea
Enabled (No) pentru controale.
§2.4.4. Proiectarea listelor
Listele sunt realizate cu ajutorul rapoartelor bazate pe tabele sau interogări.

Ele sunt afişate pe ecran sau pot fi listate la imprimantă.
Listele obţinute sunt prezentate în capitolul §3.
a. Nomenclatorul de produse
Pentru a realiza nomenclatorul de produse, se creează interogarea
qry_NomenclatorProduse şi raportul rpt_Nomenclator.
Interogarea qry_NomenclatorProduse, de tip Select, combină datele din

tabelul tbl_Categorii cu cele din tabelul tbl_Produse astfel încât fiecare produs
apare o singură dată, chiar dacă el este comercializat în mai multe tipuri de
ambalaje.
Ambele moduri de vizualizare ale interogării sunt prezentate în FIG.155.
FIG.155
Observaţie:
Expresia totalizatoare implementată prin funcţia agregat FirstOf, determină
includerea în foaia de calcul a primului articol din grupul pentru care celelalte
câmpuri au aceeaşi valoare. De exemplu, produsul “Suc de mere” apare o
singură dată în listă, deşi în tabelul tblProduse el figurează ca două
sortimente distincte, în ambalaj de 1 l şi 7,5 l.
Lista propriu-zisă este realizată prin raportul rpt_Nomenclator. Raportul a

fost construit folosind utilitarul ReportWizard având la bază interogarea
qry_NomenclatorProduse. Pentru a obţine o formă convenabilă, s-a intervenit
în DesignView prin mutarea unor câmpuri şi modificarea expresiei de afişare
a numărului de pagină.
b. Lista preţurilor de nomenclator

Lista preţurilor de nomenclator (fără aplicarea reducerilor de preţ) este
realizată prin raportul rpt_Preturi_fara_reducere. Raportul a fost construit
folosind utilitarul ReportWizard prin combinarea datelor din tabelele de bază.
FIG.156
Pentru a obţine o formă convenabilă, s-a intervenit în DesignView prin

mutarea unor câmpuri şi modificarea expresiei de afişare a numărului de pagină.
Fereastra Design a raportului este prezentată în FIG.156.
c. Lista de preţuri
Pentru a realiza lista care include preţurile actuale, inclusiv eventualitatea
unei reduceri de preţuri, se utilizează raportul rpt_Lista_de_preturi prezentat
anterior.
d. Analiza simplificată a preţului

Analiza simplificată a preţului se face prin compararea preţului unui litru de
băutură în cazul comercializării în diferite tipuri de ambalaje.
Pentru aceasta se utilizează qry_CalculezLitrul şi rpt_Pret_pe_litru, astfel:
Se creează interogarea qry_CalculezLitrul, de tip Select, care calculează

preţul unui litru pentru fiecare sortiment de băutură comercializat.
În FIG.157 este prezentată interogarea qry_CalculezLitrul în DesignView iar
rezultatul rulării ei vizualizat în FIG.158.
FIG.157
FIG.158
Observaţii:
- Preţul unui litru se calculează cu expresia:
Pret_pe_Litru: [Pret]*1000/IIf(Right(Left([Gramaj];Len([Gramaj])-2);1)=" ";

Trim(Left([Gramaj];Len([Gramaj])-2));Left([Gramaj];Len([Gramaj])-2)*1000)
- S-au utilizat funcţiile Right, Left, Len şi Trim pentru a selecta partea numerică
a valorii câmpului Gramaj.
- S-a utilizat funcţia IIf pentru a transmite valoarea gramajului în aceeaşi unitate
de măsură (ml).
Se creează raportul rpt_Pret_pe_Litru, bazat pe interogarea

qry_CalculezLitrul.
Fereastra de proiectare a raportului rpt_Pret_pe_litru este prezentată în
FIG.159.
Observaţie:
Pentru afişarea prietenoasă a textului din subsolul câmpului Categorie, s-a
modificat expresia totalizatoare oferită de ReportWizard.
FIG.159
e. Etichete pentru afişarea preţului

Pentru afişarea preţurilor, se folosesc etichete autocolante de tipul J8160,
având mărimea (38,10 x 63,5) mm. Etichetele se găsesc în comerţ, în număr de
21 buc. pe o coală A4.
Pentru tipărirea etichetelor se foloseşte raportul rpt_Etichete.
Fereastra de proiectare a raportului are aspectul din FIG.160.
FIG.160
Observaţii:
- Raportul se creează folosind utilitarul LabelWizard;
- Se îmbunătăţeşte aspectul estetic în modul Design astfel: se modifică
denumirea câmpurilor, se formatează şi poziţionează câmpurile în spaţiul
etichetei, se adaugă un chenar dreptunghiular, etc.
§2.4.5. Alcătuirea meniurilor
Pentru alcătuirea meniurilor se utilizează formulare cu butoane, create în

modul Design.
Pentru stabilirea acţiunilor pe care le lansează butoanele se foloseşte
utilitarul interactiv de tip Wizard, activat de pe Toolbox odată cu crearea
butoanelor de comandă. Ulterior se îmbunătăţeşte aspectul formularelor prin
modificarea proprietăţilor Caption, ScrollBars, RecordSelectors, Navigation
Buttons, DividingLines, MinMaxButtons, etc.
Facilităţile oferite de aplicaţie se grupează logic în trei categorii:
introducere / modificare date;
vizualizare date;
aplicarea reducerilor de preţ.
Corespunzător primelor două categorii, se vor crea două formulare
distincte: frm_IntroDate şi frm_Rapoarte care se vor lansa dintr-un formular
principal frm_START.
Observaţii:
- Proiectarea formularelor meniu are loc în următoarea ordine: frm_IntroDate,
frm_Rapoarte, frm_START Formularele sunt prezentate în capitolul §3.
- Butoanele create la proiectare lansează acţiunea aferentă, conform celor
descrise în capitolele anterioare. În §4.Anexă se face precizarea exactă a
obiectelor şi modul legării acestora de butoanele formularelor – meniu.
§3. UTILIZAREA APLICAŢIEI
Din punct de vedere al utilizatorului, aplicaţia este deosebit de simplă, ea

putând fi uşor învăţată şi folosită de operatori cu cunoştinţe minime în domeniul
informatic.
Pentru lansare, se activează butonul corespunzător de pe Desktop-ul
calculatorului (FIG.161).
FIG.161
§3.1. Prezentarea meniurilor
Programul dispune de o Interfaţă prietenoasă şi meniuri deosebit de

sugestive. Astfel, la lansarea aplicaţiei se deschide formularul frm_START
(FIG.162) cu ajutorul căruia se controlează toate acţiunile programului.
FIG.162
Apoi, în funcţie de opţiunea utilizatorului, se efectuează:

introduceri şi modificări de date controlate de formularul frm_IntroDate
(FIG.163).
De pe formularul frm_START se iniţiază si reducerea de preţuri.
vizualizarea situaţiilor de ieşire sub controlul formularului frm_Rapoarte
(FIG.164).
FIG.163
FIG.164
Acţionarea butonului cu textul “Reducere de preţuri” lansează dialogul

din FIG.165 (corespunzător lansării modulului mdl_FacReduceri prin macro-ul
mac_Afisez_ListaDePreturi). Acest dialog înlocuieşte dialogul rudimentar
prezentat în FIG.142 şi are ca efect afişare listei de preţuri prin lansarea
raportului din FIG.144.
FIG.165
Dacă utilizatorul doreşte să introducă date despre un set de produse noi,

va acţiona unul dintre butoanele de comanda din FIG.163. Corespunzător, se va
lansa unul dintre formularele prezentate în FIG.147, FIG.148, FIG.149 respectiv
FIG.154.
Prin acţionarea butoanelor cu textul “Nomenclator de produse”, “Preturi
de nomenclator”, “Preturi curente”, “Comparatie preturi / litru”, şi
“Etichete de pret” se vizualizează rapoartele corespunzătoare. Acestea sunt
prezentate în FIG.166, FIG.167, FIG.168, FIG.169 respectiv FIG.170.
Pentru tipărirea listelor, utilizatorul va folosi butonul Print din fereastra
PrintPreview; setările pentru imprimantă vor fi preluate automat din mediul
Windows.
Toate formularele şi listele obţinute se închid prin acţionarea butonului
Close corespunzător. La închiderea formularului frm_START, se afişează
automat Desktop-ul calculatorului.
§3.2. Rapoarte
Utilizatorul lansează în execuţie rapoartele cu ajutorul formularelor meniu

prezentate în capitolul §3.1. Situaţiile centralizatoare corespunzătoare cerinţelor
precizate în capitolul §2.1. pct.D. sunt:
FIG.166
FIG.167
FIG.168
FIG.169
FIG.170
§4. ANEXĂ (Organigrama aplicaţiei)
În FIG.171 sunt prezentate toate obiectele bazei de date şi modul în care

sunt apelate succesiv pentru îndeplinirea sarcinilor specifice ale aplicaţiei.
frm_START
(3 butoane - OnClick)
frm_IntroDate frm_Rapoarte
(4 butoane - OnClick) (5 butoane - OnClick) mac_Afisez_ListaDePreturi
frm_GramajNou frm_IntroCategorii rpt_Nomenclator rpt_Lista_de_preturi mdl_FacReduceri

(bazat pe tblGramaj) (bazat pe tblCategorii) (bazat pe (bazat pe Lista_pret_redus)
qry_NomenclatorProduse)
frm_IntroProduse frm_ModificPret rpt_Preturi_fara_reducere rpt_Pret_pe_litru qry1_FacLista

(bazat pe tblProduse) (cu frm_ModificPret Subform) (bazat pe tbl_Produse) (bazat pe qry_CalculezLitrul)
(bazat pe qry_ModificPret) qry2_Reducere
rpt_Lista_de_preturi
rpt_Etichete
(bazat pe Lista_pret_redus)
FIG.171
3.3 Aplicaţie pentru evidenţa tranzacţiilor de acţiuni
Aplicaţia se referă la informatizarea activităţii de tranzacţionare de acţiuni.

Ţinând cont de scopul didactic al produsului informatic, activitatea vizată este
mult simplificată.
Evidenţa acţiunilor pentru diferite societăţi şi înregistrarea tranzacţiilor are
o logică similară oricărei evidenţe de stocuri. Deoarece urmăreşte etapele şi
logica devenită „clasică” pentru astfel de probleme, aplicaţia a fost preluată din
[13], cu efectuarea unor modificări şi actualizări.
§1. ASPECTE PRIVIND TRANZACŢIILE DE ACŢIUNI

ÎN CADRU ORGANIZAT
Simbolul liberului schimb – bursa are o istorie ce ne duce cu mult înaintea

erei creştine, perioadă care după unii autori pun bazele înfiinţării primei „Burse
Adevărate” pe la 1540 la Paris.
Astăzi, datorită reţelei informatice, un titlu cumpărat la Paris poate fi cedat
după câteva ore la un preţ superior la New York, pentru achiziţionarea altuia la
Hong-Kong sau Tokio. Cu un program aproape 24 din 24 de ore funcţionează în
locuri şi orare diferite, în diferite colţuri ale lumii prelevându-se de diferenţele
fusului orar.
Vânzarea publică de acţiunii prin intermediul bursei dă întreprinderii
posibilitatea de a obţine bani fără a-şi pierde autonomia.
Bursa de Valori este locul în care valorile mobiliare sunt tranzacţionate
după o procedură specifică. Rolul bursei este foarte important pentru că ea
asigură libera circulaţie a valorilor mobiliare la un preţ care reflectă raportul
dintre cerere şi ofertă.
§2. ANALIZA ŞI PROIECTAREA APLICAŢIEI
Pentru aplicaţia de evidenţă a tranzacţiilor de acţiuni, etapele parcurse în

fazele de analiză şi proiectare conduc la realizarea unui produs soft care ţine o
evidenţă simplificată a operaţiunilor de vânzare / cumpărare de acţiuni efectuate
de la un terminal.
§2.1. Elemente de analiză
Analiza efectuată în vederea realizării sistemului de gestiune a tranzacţiilor

se bazează pe elementele teoretice prezentate în capitolul 3.1.
A. formularea problemei prin studierea activităţii vizate de sistemul

informatic şi identificarea informaţională a tuturor participanţilor la
rezolvarea problemei.
Prezenta analiză vizează activitatea desfăşurată de către un agent de

bursă care efectuează tranzacţii de acţiuni în cadru organizat. Pentru evidenţa
operaţiunilor se utilizează un calculator.
Pentru simplificarea problemei, se consideră că utilizatorul programului
este singurul care efectuează tranzacţii la un moment dat iar evidenţa
operaţiunilor se face în mod direct, pe acelaşi calculator.
Prin tranzacţie se înţelege derularea unei operaţiuni de vânzare sau
cumpărare de acţiuni ale oricăreia dintre societăţile comerciale cotate pe piaţa
respectivă. Numărul de acţiuni cumpărate sau vândute precum şi preţul
tranzacţiei este determinat de condiţiile momentane ale pieţei.
Stocul de acţiuni pentru fiecare societate comercială aflată în evidenţa
agentului se actualizează în timp real, după fiecare tranzacţie efectuată.
B. identificarea şi studierea actelor normative care reglementează

activitatea vizată de sistemul informatic
Bursa de Valori Bucureşti (B.V.B.) este organizată şi îşi desfaşoară

activitatea în conformitate cu Actul constitutiv propriu, prevederile Legii nr.
31/1990 privind societăţile comerciale, republicată, şi ale Legii nr. 297/2004
privind piaţa de capital, cu modificările şi completările ulterioare, cu autorizarea şi
sub supravegherea Comisiei Naţionale a Valorilor Mobiliare. În acest sens a fost
publicat şi codul Bursei de Valori Bucureşti S.A. - operator de piaţă, ediţie
actualizată în iulie 2007.
C. analiza şi inventarierea documentelor care participă la fluxul

informaţional
Documentele care participă la fluxul informaţional al aplicaţiei sunt:

Fişa societăţii comerciale. Aceasta este un document pe suport hârtie şi
conţine toate datele necesare pentru a identifica univoc fiecare societate ale
cărei acţiuni sunt cotate pe piaţă, precum şi alte date care pot fi necesare la
întocmirea diferitelor situaţii. Totalitatea societăţilor pentru care se pot efectua
tranzacţii formează Clienţii agentului respectiv.
Datele tranzacţiei. Acesta este un document fără suport hârtie care conţine
datele referitoare la operaţiunea efectuată de către agent. Introducerea
datelor privind volumul şi preţul tranzacţiei se face direct prin program.
Situaţii centralizatoare. Acestea sunt documente pe suport hârtie şi conţin
informaţii sintetice privind clienţii, stocurile de acţiuni, operaţiunile de vânzare
/ cumpărare efectuate, etc.
D. precizarea situaţiilor de ieşire (listelor)
Situaţiile centralizatoare pe care le întocmeşte aplicaţia sunt:

Jurnalul de clienţi. Acesta conţine date despre toate societăţile cotate pe piaţă
ale căror acţiuni pot fi tranzacţionate prin prezenta aplicaţie.
Situaţia stocurilor existente. Aceasta conţine date despre stocurile de acţiuni

existente pentru fiecare societate comercială. Ea poate fi întocmită în orice
moment şi va reflecta situaţia stocurilor în timp real.
Jurnalul de operaţiuni. Acesta listează date sumare despre fiecare tranzacţie
efectuată, în ordinea în care s-a realizat introducerea datelor în calculator.
Evidenţa tranzacţiilor individual, pentru fiecare societate în parte. Aceasta
listează date despre operaţiunile de vânzare / cumpărare de acţiuni pentru
fiecare societate.
Evidenţierea preţului mediu ponderat pentru vânzare şi cumpărare, pentru toţi
clienţii sau individual, pentru o anumită societate.
Top 3. Această situaţie oferă date sumare despre primele trei, cel mai bine
tranzacţionate societăţi, atât la vânzare cât şi la cumpărare, precum şi
valoarea operaţiunilor efectuate.
Adresarea plicurilor pentru şedinţă. Se efectuează listarea automată, pe
etichete autocolante a destinatarilor mapelor pentru reuniuni cu clienţii.
E. stabilirea datelor de intrare necesare
Datele de intrare sunt preluate de pe fişa societăţii la care se adaugă date

referitoare la fiecare tranzacţie:
tipul operaţiunii efectuate de agent: vânzare sau cumpărare;
volumul tranzacţiei: numărul de acţiuni vândute sau cumpărate;
preţul la care se efectuează operaţiunea: preţul unei acţiuni.
F. structura funcţională a aplicaţiei obţinută prin construirea unui model

matematic sau a unei scheme sau prin precizarea detaliată a sarcinilor
impuse produsului informatic.
Structura funcţională a aplicaţiei derivă din natura activităţii vizate. Astfel sunt:
∗ Introducere de date:
Date referitoare la societăţile comerciale cotate,
Date referitoare la societăţi nou introduse pe piaţă,

Date referitoare la tranzacţia curentă;
∗ Prelucrări de date privind:
Verificarea unicităţii societăţii în lista de clienţi,
Actualizarea Jurnalului de operaţiuni,
Actualizarea stocului curent, după fiecare tranzacţie;
∗ Efectuarea de calcule privind:
Valoarea tranzacţiei curente,
Media ponderată a valorii operaţiunilor efectuate;
∗ Efectuarea de căutări pentru întocmirea situaţiilor referitore la o anumită
societate comercială;
∗ Sortări după diverse criterii: tipul operaţiunii, numele societăţii, etc.;
∗ Interogări pentru obţinerea datelor care stau la baza situaţiilor întocmite,
∗ Întocmirea, afişarea şi tipărirea situaţiilor de ieşire.
§2.2. Alegerea SGBD-ului adecvat
SGBD-ul ales pentru realizarea aplicaţiei trebuie să dispună de facilităţile

de care au nevoie de regulă aplicaţiile de baze de date, condiţii precizate în
capitolul anterior la prezentarea aplicaţiei privind reducerile de preţ.
G. Precizarea mediului de programare care se va utiliza
Având în vedere cele de mai sus, s-a optat pentru Microsoft Access.
Acesta este un SGBD relaţional modern, componentă a pachetului de programe
Microsoft Office, deosebit de răspândit pe calculatoarele personale, care
satisface necesităţile aplicaţiei.
§2.3. Proiectarea tabelelor şi stabilirea relaţiilor
Având în vedere caracterul orientat pe obiecte al SGBD-ului ales, se

realizează întâi proiectarea tabelelor de bază, se stabilesc relaţiile între tabele,
se precizează metodele de prelucrare a datelor, după care se proiectează
celelalte obiecte necesare.
H. proiectarea tabelelor, realizată pe baza analizei datelor de intrare

Specificul aplicaţiei impune stocarea datelor aflate la dispoziţia
utilizatorului în două tabele principale:
♦ tblFirme conţine toate datele despre clienţi, aşa cum sunt ele incluse în fişa
societăţii. În FIG.172 este prezentat tabelul tblFirme în modul de vizualizare
proiectare (DesignView)
FIG. 172
Observaţii:
- Câmpul CUI este cheia primară a tabelului; pe baza informaţiei din acest
câmp se identifică univoc articolele tabelului. S-a ales un tip numeric,
caracterul R considerându-se implicit.
- Tipul de date din fiecare câmp rezultă din figură.
- Pentru câmpul Localitate, de tip text, se foloseşte un Look-up Wizard cu valori
introduse manual, prin care se creează o listă derulantă conţinând localităţile
în care îşi au sediul firmele din portofoliu.
♦ tblTranzactii corespunde unui registru de evidenţă a tranzacţiilor. El conţine

datele referitoare la tranzacţii, fiecărui articol corespunzându-i o operaţiune de
vânzare sau cumpărare.
În FIG.173 este prezentat tabelul tblTranzactii în modul de vizualizare
DesignView.
FIG. 173
Observaţii:
- Tabelul reprezintă un registru de evidenţă în care se „memorează” tranzacţiile
după ce au fost prelucrate de program. Din modul de funcţionare al aplicaţiei
rezultă ca acesta va fi un tabel independent, fără a fi în relaţie cu alte tabele.
- Cheia primară este de tipul AutoNumber şi reprezintă un număr de ordine,
fără a avea o semnificaţie deosebită în evidenţa tranzacţiilor.
- La realizarea câmpului Tip_Tran s-a folosit un Look-up Wizard cu
introducerea manuală a datelor; în acest mod se afişează o listă derulantă din
care utilizatorul poate selecta “Vânzare” sau “Cumpărare”.
I. funcţionarea aplicaţiei şi stabilirea tabelelor auxiliare
Pentru efectuarea calculelor, actualizarea datelor şi selectarea informaţiei

în vederea obţinerii rapoartelor se vor utiliza interogările. Din modul de
funcţionare al interogărilor în Access, rezultă necesitatea introducerii a două
tabele auxiliare.
♦ tblValoare_Sold conţine numărul de acţiuni disponibile pentru fiecare

societate. El se actualizează după efectuarea fiecărei tranzacţii prin adunare
(cumpărare) sau scădere (vânzare).
Structura tabelului conţine doar două câmpuri: identificatorul societăţii şi
valoarea actuală a soldului.
Din punct de vedere logic, tabelul tblValoare_Sold este o prelungire a
tabelului tblFirme, la un moment dat fiecare societate având un anumit sold. Cele
două tabele au aceeaşi cheie primară şi se află în relaţie unu-la-unu.
Din punct de vedere funcţional, câmpul Sold_Curent are rolul de locaţie
de memorie cu ajutorul căreia se transferă valoarea stocului actual de la o
tranzacţie la alta, adică:
a. valoarea câmpului Sold_Curent din tblValoare_Sold se preia la
iniţierea unei tranzacţii pentru societatea respectivă şi se transferă ca
valoare a soldului iniţial pentru tranzacţia respectivă;
b. valoarea câmpului Sold_Curent din tblValoare_Sold se actualizează

după încheierea fiecărei tranzacţii pentru societatea respectivă,
preluând soldul final rezultat în urma calculelor.
♦ tblCrt este un tabel auxiliar care are o structură similară tabelului

tblTranzactii. Tabelul conţine un singur articol ce stochează date referitoare la
tranzacţia curentă, prin urmare câmpul cheie de identificare a tranzacţiei a
fost eliminat.
Tabelul tblCrt are rolul de tabel “tampon” de memorare temporară a datelor
referitoare la tranzacţia curentă. Astfel:
- datele referitoare la tranzacţie se operează în tabelul tblCrt,
- se preia stocul actual din tblValoare_Sold ; acesta devine sold iniţial,
- se efectuează calculele,
- valoarea soldului final se transmite tabelului tblValoare_Sold pentru
actualizare,
- se “descarcă” articolul din tabelul tblCrt în tabelul tblTranzactii,
- se pregăteşte spaţiul de lucru pentru următoarea tranzacţie prin
ştergerea datelor din tabelul tblCrt.
În urma consideraţiilor de mai sus, tabelele aplicaţiei sunt cele prezentate în
FIG.174.
FIG.174
J. stabilirea relaţiilor între tabele, în mod specific SGBD-ului ales
Fereastra Relationships prezentată în FIG.175 ilustrează structura datelor

ce corespunde modului de funcţionarea descris mai sus. Relaţiile între tabele
sunt controlate logic prin impunerea integrităţii referenţiale.
FIG.175
Relaţiile dintre tabele sunt stabilite în urma analizei efectuate mai sus, astfel:
unu-la-mai-mulţi, între tblFirme şi tblCrt; deşi tblCrt conţine cel mult un articol,
relaţia este necesară pentru funcţionarea căutării de tip Look-up Wizard.
Câmpul de legătură este CUI, cheie primară în tabelul tblFirme şi cheie
străină în tabelul tblCrt.
unu-la-unu, între tblFirme şi tblValoare_Sold, astfel unui articol din tabelul
tblFirme îi corespunde un articol din tblValoare_Sold, adică fiecare client are
un număr de acţiuni actual, faţă de care se efectuează operaţiunile de
vânzare / cumpărare.
Observaţie: săgeţile marcate „a” şi respectiv „b” de pe FIG.175 ilustrează
modul de actualizare al soldului de acţiuni, conform funcţionării descrise
mai sus.
§2.4. Descrierea obiectelor folosite
Aplicaţia utilizează următoarele obiecte:

Tabele – pentru stocare datelor (în modul descris anterior);
Interogări (FIG.176) – pentru:
combinarea, sortarea şi filtrarea datelor,
efectuarea de calcule şi operaţii totalizatoare;
Formulare (FIG.177) – pentru:
introducerea datelor,
vizualizarea datelor prelucrate prin interogări,
realizarea meniurilor;
Rapoarte (FIG.178) – pentru sintetizarea datelor şi vizualizarea listelor;
Macro – pentru derularea automată a unei succesiuni de operaţii.
Nu s-au folosit module VBA independente, dar majoritatea formularelor au
proceduri legate de evenimente (CodeBehindForms).
Denumirea obiectelor sugerează atât tipul obiectului cât şi rolul pe care îl
are acesta în aplicaţie. Interogările care implementează succesiunea de operaţii
pentru o vânzare / cumpărare sunt numerotate în ordinea în care au fost create,
aceeaşi cu ordinea în care se vor executa.
FIG.176
FIG.177
FIG.178
§2.4.1. Înregistrarea tranzacţiilor
Pentru înregistrarea tranzacţiilor în tabelul tblTranzactii se utilizează

primele 5 interogări prezentate în FIG.176 şi formularul frm_Crt. La proiectare
s-au parcurs următorii paşi:
a. Se creează interogarea qry1_PreiauSoldI care efectuează operaţia marcată

“a” în FIG.175. Interogarea actualizează câmpul Sold_I a tabelului tblCrt la
valoarea Sold_curent din tabelul tblValoare_Sold, pentru societatea care
efectuează tranzacţia.
Observaţii:
- Se creează întâi o interogare de tip Select, pe baza tabelului tblCrt.
- Se transformă în interogare de tip Update.
- Se scrie expresia de actualizare cu ajutorul utilitarului Build (FIG.179).
FIG.179
- La încercarea de rulare, interogarea afişează un mesaj de eroare. Pentru a

completa datele lipsă, în zona de date se va adăuga tabelul tblValoare_Sold,
cu ajutorul butonului ShowTable. Cele două tabele nu sunt în relaţie directă,
prin urmare se realizează o relaţie „locală”, prin tragerea cheii primare CUI din
tabelul tblValoare_Sold peste câmpul corespunzător Cod din tabelul tblCrt.
- În final, fereastra de proiectare a interogării are aspectul prezentat în FIG.180.
FIG.180
- După executarea interogării pe un exemplu, conţinutul tabelului tblCrt va fi cel

din FIG.181.
FIG.181
b. Se creează interogarea qry_2CalculSoldF care calculează valoarea soldului

după tranzacţie şi o actualizează în tabelul tblCrt.
Fereastra Design a interogării are aspectul prezentat în FIG.182.
FIG.182
Observaţii:
- Se creează întâi o interogare de tip Select, pe baza tabelului tblCrt.
- Se scrie expresia de actualizare cu ajutorul utilitarului Build. Se utilizează
funcţia integrată IIF, având o sintaxă asemănătoare funcţiei IF din mediul
Excel. Expresia de calcul este:
IIf ([Tip_Tranz] = "Vanzare" ,

[Sold_I] - [Cant] * [Pret_Tranz] , [Sold_I] + [Cant] * [ Pret_Tranz])
- Se salvează şi se rulează.
- Calculul preţului mediu ponderat după fiecare tranzacţie nu face obiectul

prezentei aplicaţii; câmpul Preţ_Mediu permite dezvoltări ulterioare.
c. Se creează interogarea qry3_ActuSold care efectuează operaţia marcată “b”

în FIG.175. Interogarea actualizează câmpul Sold_Curent a tabelului
tblValoare_Sold la valoarea SoldF a tranzacţiei curente, preluată din tabelul
tblCrt.
Fereastra Design a interogării are aspectul prezentat în FIG.183.
FIG.183
Observaţii:
- Se creează întâi o interogare de tip Select, pe baza tabelului tblValoare_Sold.
- Se scrie expresia de actualizare cu ajutorul utilitarului Build.
- La încercarea de rulare, interogarea afişează un mesaj de eroare. Pentru a
completa datele lipsă, în zona de date se va adăuga tabelul tblCrt, cu ajutorul
butonului ShowTable. Cele două tabele nu sunt în relaţie directă, prin urmare
se realizează o relaţie „locală”, prin tragerea cheii primare CUI din tabelul
tblValoare_Sold peste câmpul corespunzător Cod din tabelul tblCrt.
- Se salvează şi se rulează.
d. Se creează interogarea qry4_Inregistrez, de tip Append, pentru a transfera

tranzacţia curentă din tabelul tblCrt la sfârşitul tabelului tblTranzactii.
Fereastra Design a interogării qry4_Inregistrez are aspectul din FIG.184.
FIG.184
Observaţii:
- Se creează întâi interogarea de tip Select, bazată pe tabelul tblCrt (sursa
datelor).
- Se transformă în interogare de tip Append.
- Se precizează tabelul tblTranzactii ca destinaţie a datelor; corespondenţa
între câmpurile celor două tabele se face automat, pe baza denumirilor
identice.
- Se salvează, se rulează.
e. Se creează interogarea qry5_Sterg, de tip Delete, care şterge tranzacţia

curentă – articol unic în tabelul tblCrt şi pregăteşte aplicaţia pentru
înregistrarea unei noi tranzacţii.
FIG.185
Fereastra Design a interogării qry4_Sterg are aspectul din FIG.185.
Observaţii:
- Se creează întâi interogarea de tip Select, bazată pe tabelul tblCrt (din care
se şterg articole).
- Se transformă în interogare de tip Delete.
- Se salvează, se rulează.
f. Se creează formularul frm_Crt, pe baza tabelului tblCrt. Acesta realizează

interfaţa prietenoasă pentru introducerea datelor.
Formularul are aspectul prezentat în FIG.186.
FIG.186
Observaţii:
- Formularul s-a creat cu ajutorul utilitarului Form Wizard.
- Pentru estetizarea formularului s-au utilizat proprietăţile: Caption, Record
Selector, ScrollBars, NavigationButtons, MinMaxButtons.
g. Se rulează de câteva ori cele 5 interogări anterioare, în ordinea în care au fost

create, şi se verifică funcţionarea aplicaţiei. Datele se introduc folosind
formularul frm_Crt. Rezultatul trebuie să fie înregistrarea tranzacţiilor în
tabelul tblTranzactii.
h. Se creează macro-ul macOperatii care realizează lansarea succesivă a celor

cinci interogări de acţiune create anterior. În plus, macrocomanda deschide
formularul de introducere a datelor.
Fereastra de proiectare a macrocomenzii este prezentată în FIG.187.
FIG.187
Observaţii:
- Comanda SetWarnings, cu argumentul No, inhibă afişarea mesajelor de
informare / confirmare aferente tuturor comenzilor care o urmează.
- Pentru deschiderea formularului se foloseşte comanda OpenForm; pentru a
permite introducerea datelor, proprietatea WindowMode trebuie setată la
valoarea „Dialog”.
- Argumentul comenzilor OpenQuery îl reprezintă chiar interogările respective.
§2.4.2. Introducerea / modificarea datelor
Aplicaţia conţine interfeţe prietenoase pentru introducerea / modificarea

datelor, realizate cu ajutorul formularelor. Formularele care afişează date au fost
create cu ajutorul utilitarelor de tip Wizard. Pentru simplitate, de regulă, s-a
păstrat denumirea şi formatul câmpurilor din tabelele sau interogările aflate la
baza formularelor.
a. Introducerea datelor de pe Fişa societăţii comerciale

Pentru introducerea datelor despre clienţi se utilizează formularul
frm_FirmaNoua prezentat în FIG.188.
FIG.188
Observaţii:
- Formularul are la bază tabelul tblFirme.
- S-au modificat proprietăţile Caption, MinMaxButtons şi DataEntry (Yes).
- Lista derulantă pentru câmpul Localitate, creată în tabel, a fost preluată
automat în formular.
- Formularul va fi folosit atât pentru introducerea datelor despre clienţii
noi cât şi pentru modificarea datelor referitoare la clienţii existenţi.
b. modificarea datelor referitoare la clienţii existenţi

Pentru modificarea datelor din tabelul tblTranzactii se utilizează formularele
frm_AdaugFirma şi formularul frm_FirmaNoua prezentat anterior.
Formularul frm_AdaugFirma afişează o listă derulantă din care utilizatorul
poate alege numele societăţii ale cărei date le va modifica. La actualizarea
valorii listei, se lansează formularul frm_FirmaNoua cu precizarea articolului
care trebuie afişat pentru editare.
În FIG.189 se prezintă cele două formulare în momentul în care utilizatorul

poate opera modificarea datelor.
FIG.189
Observaţii:
- În caz că utilizatorul tastează în zona de editare a ComboBox-ului numele
unei societăţi inexistente în listă, apare un mesaj de avertizare în urma căruia
utilizatorul poate opta pentru reluare sau pentru introducerea în listă a unui
nou client (FIG.190). Pentru introducere se lansează acelaşi formular
frm_FirmaNoua.
FIG.190
- Pentru a deschide formularul frm_FirmaNoua cu afişarea articolului ales şi

pentru a introduce noua firmă între valorile listei derulante (dacă este cazul),
se utilizează evenimentele BeforeUpdate şi NotInList ale ComboBox-ului
AlegSoc). Codul VBA asociat formularului frm_AdaugFirma este prezentat în
continuare:
Private Sub AlegSoc_BeforeUpdate(Cancel As Integer)

Dim soc As Long
soc = [AlegSoc].Value
DoCmd.OpenForm "frm_FirmaNoua", acNormal, , "[CUI] =" _
& soc, acFormEdit
End Sub
Private Sub AlegSoc_NotInList(NewData As String, Response As Integer)

raspuns = MsgBox("Introduceti date pentru o societate noua ?", vbYesNo)
DoCmd.OpenForm "frm_FirmaNoua", acNormal, , , , acDialog
DoCmd.Close acTable, "tblFirme", acSaveYes
AlegSoc.Value = Null
AlegSoc.Requery
End If
Response = acDataErrContinue 'const - nu va afisa mesaj implicit
End Sub
c. Introducerea datelor referitoare la tranzacţia curentă se face cu ajutorul

formularului din FIG.186. În formular sunt preluate automat formatările şi
listele derulante din tabelul tblFirme. Formularul se deschide pentru
introducerea datelor (DataEntry = Yes) şi trebuie închis după fiecare
tranzacţie.
§2.4.3. Proiectarea listelor
Listele sunt realizate cu ajutorul rapoartelor şi formularelor bazate pe tabele

sau interogări. Ele sunt afişate pe ecran sau pot fi listate la imprimantă.
Listele obţinute sunt prezentate în capitolul §3.
a. Jurnalul de clienţi
Jurnalul de clienţi este realizat prin raportul rpt_JurnalClienti. Raportul a fost
construit folosind utilitarul ReportWizard având la bază tabelul tblFirme.
Pentru a obţine o formă convenabilă, s-a intervenit în DesignView prin
mutarea unor câmpuri şi modificarea expresiei de afişare a numărului de
pagină.
b. Situaţia stocurilor existente

Pentru a realiza această listă, se creează interogarea qry_Solduri şi raportul
rpt_Solduri.
Interogarea qry_Solduri, de tip Select, combină datele din tabelul
tbl_Firme cu cele din tabelul tblValoare_Sold şi le ordonează alfabetic.
Modul Design al interogării qry_Solduri este prezentat în FIG.191.
FIG.191
Lista propriu-zisă este realizată prin raportul rpt_Solduri. Raportul a fost

construit folosind utilitarul ReportWizard având la bază interogarea
qry_Solduri. Pentru a obţine o formă convenabilă, s-a intervenit în
DesignView prin mutarea unor câmpuri şi modificarea expresiei de afişare
a numărului de pagină.
c. Jurnalul de operaţiuni
Jurnalul de clienţi este realizat prin raportul rpt_JurnalOperatiuni. Raportul a
fost construit folosind utilitarul ReportWizard prin combinarea datelor din
tabelul tblFirme şi tabelul tblTranzactii. Pentru a obţine o formă convenabilă,
s-a intervenit în DesignView prin mutarea unor câmpuri şi modificarea
expresiei de afişare a numărului de pagină.
d. Evidenţa tranzacţiilor individual, pentru fiecare societate în parte

Pentru a realiza lista care include date despre toate tranzacţiile efectuate
pentru o societate, se utilizează interogarea qry_VizuFirme_Tranzactii,
formularul frm_SocietateCombo şi raportul rpt_QryVizu. Pentru proiectare se
procedează astfel:
Se creează interogarea qry_VizuFirme_Tran, de tip Select, care combină
datele din tabelul tbl_Firme cu cele din tabelul tbl_Tranzactii.
Fereastra de proiectare a interogării este prezentată în FIG.192.Pentru a
permite o asociere corectă a datelor, s-a creat relaţia local, prin tragere.
FIG.192
Lista propriu-zisă este realizată prin raportul rpt_QryVizu. Raportul a

fost construit folosind utilitarul ReportWizard şi are la bază interogarea
qry_VizuFirme_Tran.
Fereastra de proiectare a raportului rpt_QryVizu este prezentată în
FIG.193.
FIG.193
Observaţii:
- Pentru a obţine o formă convenabilă, s-a intervenit în DesignView prin
mutarea unor câmpuri şi modificarea expresiei de afişare a numărului de
pagină.
- Faţă de interogarea qry_VizuFirme_Tran, raportul conţine în plus câmpul
Valoare Tranzactie. Pentru raport, acesta reprezintă un câmp calculat, creat
prin folosirea instrumentului TextBox şi a utilitarului Build.
- În secţiunea de titlu s-au inclus două controale, Societatea şi CUI, a căror
valoare se preia din interogare, după ce articolele acesteia au fost filtrate.
Se creează formularul frm_SocietateCombo care conţine o listă derulantă

din care utilizatorul va alege clientul despre care solicită date.
Formularul este prezentat în FIG.194.
FIG.194
Observaţii:
- Se interzice tastarea numelui unui client inexistent. Pentru aceasta,
proprietatea LimitToList a controlului Combo0 este setată pe Yes.
- Alegerea unei valori din lista derulantă determină lansarea în execuţie a
raportului rpt_QryVizu. Vizualizarea raportului cu filtrarea datelor afişate,
astfel încât ele să se refere numai la societatea aleasă din listă, se realizează
prin secvenţa de cod prezentată în FIG.195.
Private Sub Combo0_BeforeUpdate(Cancel As Integer)

DoCmd.OpenReport "rpt_QryVizu", acViewPreview, , _
"CUI = Forms!frm_SocietateCombo!Combo0"
End Sub
FIG.195
e. Evidenţierea preţului mediu ponderat pentru vânzare şi cumpărare, pentru toţi

clienţii sau individual, pentru o anumită societate.
Pentru alcătuirea acestor liste se utilizează interogările qry_PMediu şi
qry_PMediu_Firma şi raportul rpt_PMediu. Astfel:
Se creează interogarea qry_PMediu, de tip Select, care calculează preţul
mediu ponderat pentru fiecare societate pe baza datelor din tabelul
tblTranzactii, folosind formula simplificată:
PM: Sum([Cant]*[Pret_Tranz])/Sum([Cant])
În FIG.196 se prezintă modul Design al interogării qry_PMediu.
FIG.196
Se creează raportul rpt_PMediu, care combină datele din tabelul tblFirme cu

cele calculate în interogarea qry_Pmediu pentru afişarea preţului mediu
ponderat pentru toţi clienţii.
Fereastra de proiectare a raportului rptPMediu este prezentată în FIG.197.
FIG.197
Observaţie: pentru afişarea datei curente în titlul raportului, s-a utilizat funcţia
Date() ca valoare a unui câmp calculat.
Se creează interogarea qry_Pmediu_Firmă, de tip Select, care calculează

preţul mediu ponderat pentru fiecare societate pe baza datelor din tabelul
tblTranzactii după care realizează filtrarea lor.
În FIG.198 este prezentată interogarea qry_PMediu_Firma, în modul de
vizualizare Design.
Observaţii:
- Interogarea qry_PMediu_Firma s-a creat prin copiere din interogarea
qry_Pmediu.
- S-a adăugat câmpul Societatea necesar pentru filtrarea datelor.
FIG.198
- Filtrarea se realizează cu ajutorul parametrului “Numele societăţii”, de tip

text. La lansarea interogării, se afişează dialogul din FIG.199, în care
utilizatorul va tasta corect numele societăţii.
FIG.199
- Rezultatul obţinut .după introducerea manuală a numelui unei societăţi,

este prezentat în FIG.200.
FIG.200
- Nu s-a mai proiectat un raport special, afişarea realizându-se cu ajutorul

interogării, în forma prezentată în FIG.200.
f. Situaţia Top3, a celor mai bine tranzacţionate acţiuni

Pentru a realiza lista care include societăţile ale căror acţiuni au fost cel mai
bine vândute sau cumpărate, pe baza preţului mediu ponderat, se utilizează
interogările qry_TopC şi qry_TopV, şi formularele frm_TopC şi frm_TopV.
Pentru proiectare se procedează astfel:
Se creează interogarea qry_TopC, de tip Select, care combină, ordonează şi
filtrează datele din tabelul tblFirme şi cele calculate în interogarea
qry_PMediu.
Fereastra de proiectare a interogării qry_TopC, inclusiv dialogul de stabilire a
proprietăţilor, este prezentată în FIG.201.
FIG.201
Observaţii:
- Se ordonează articolele descendent, după valoarea preţului mediu ponderat.
- Se filtrează pentru a obţine date referitoare numai la operaţiunile de

cumpărare.
- Ordinea câmpurilor este esenţială şi rezultă logic din rolul interogării.
- Pentru a afişa numai primele trei articole, în ordinea descendentă a valorii
PM, se setează proprietatea TopValues = 3.
Se creează interogarea qry_TopV, de tip Select.

Interogarea este corespondentul interogării qry_TopC, creată pentru
operaţiunile de vânzare.
Interogarea qry_TopV se obţine prin copiere din interogarea qry_TopC,
urmată de modificarea condiţiei de filtrare.
Se creează formularele frm_TopC şi frm_TopV, care servesc la afişarea

societăţilor al căror acţiuni au preţul cel mai ridicat la cumpărare, respectiv la
vânzare, în momentul respectiv.
Listele obţinute au aspectul prezentat în FIG.202.
FIG.202
Observaţii:
- Formularul frm_TopC se creează folosind utilitarul FormWizard, cu alegerea
stilului tabular apoi se fac modificări în fereastra DesignView.
- Se stabileşte modul de vizualizare ContinousForm.
- Se modifică denumirea câmpurilor.
- Se interzice modificarea datelor, prin setarea corespunzătoare a proprietăţilor:

AllowEdits, AllowDeletions, AllowAdditions.
- Se aduc îmbunătăţiri estetice cu ajutorul proprietăţilor Caption, ScrollBars,
RecordSelectors, NavigationButtons, DividingLines, MinMaxButtons.
- Formularul frm_TopV se creează prin copierea formularului frm_TopC şi
modificarea corespunzătoare a proprietăţilor Caption şi RecordSource.
g. Etichete pentru adresarea plicurilor

Pentru adresarea plicurilor, se folosesc etichete autocolante de tipul J8165,
având mărimea (67,73 x 99,06) mm. Etichetele se găsesc în comerţ, în număr de
8 buc. pe o coală A4.
Pentru tipărirea etichetelor se foloseşte raportul rpt_Adrese.
Fereastra de proiectare a raportului are aspectul din FIG.203.
FIG.203
Observaţii:
- Raportul se creează folosind utilitarul LabelWizard.
- Se îmbunătăţeşte aspectul estetic în modul Design astfel: se modifică
denumirea câmpurilor, se formatează şi poziţionează câmpurile în spaţiul
etichetei, se adaugă un chenar dreptunghiular, etc.
§2.4.4. Alcătuirea meniurilor
Una dintre cele mai simple modalităţi de crea meniuri în MS-Access este
utilizarea formularelor cu butoane. Spre deosebire de formularele de introducere
/ vizualizare date, formularele - meniu se creează în modul Design.
În cele mai multe cazuri, pentru stabilirea acţiunilor pe care le lansează
butoanele se foloseşte utilitarul interactiv de tip Wizard, activat de pe Toolbox
odată cu crearea butoanelor de comandă.
Ulterior se îmbunătăţeşte aspectul formularelor prin modificarea
proprietăţilor Caption, ScrollBars, RecordSelectors, NavigationButtons,
DividingLines, MinMaxButtons, etc.
Facilităţile oferite de aplicaţie se grupează logic în două categorii:
introducere / modificare date,
vizualizare date.
Corespunzător acestor două categorii, se vor crea două formulare
distincte: frm_IntroDate şi frm_Rapoarte care se vor lansa dintr-un formular
principal frm_START.
În plus, este necesară utilizarea unui formular care să selecteze cele două
posibilităţi de afişare a preţului mediu ponderat: pentru toate societăţile sau
numai pentru clientul ales de utilizator.
Observaţii:
- Proiectarea formularelor meniu are loc în următoarea ordine: frm_PretMediu,
frm_Rapoarte, frm_IntroDate, frm_START.
- Butoanele create la proiectare lansează acţiunea aferentă, conform celor
descrise în capitolele anterioare. În Anexă se face precizarea exactă a
obiectelor şi modul legării acestora de butoanele formularelor – meniu.
- Butonul Top aparţinând formularului frm_Rapoarte, cu rolul de lansare a
formularelor frm_TopC şi frm_TopV, s-a creat fără folosirea utilitarului Wizard.
Secvenţa de cod aferentă este prezentată în FIG.204.
Private Sub Top_Click()

DoCmd.OpenForm "frm_TopC"
FIG.204
DoCmd.OpenForm "frm_TopV"
End Sub
§3. UTILIZAREA APLICAŢIEI
Din punct de vedere al utilizatorului, aplicaţia este deosebit de simplă, ea

putând fi uşor învăţată şi folosită de operatori cu cunoştinţe minime în domeniul
informatic. Pentru lansare, se activează butonul corespunzător de pe Desktop-ul
calculatorului (FIG.205).
FIG.205
§3.1. Prezentarea meniurilor
Programul dispune de o Interfaţă prietenoasă şi meniuri deosebit de

sugestive. Astfel, la lansarea aplicaţiei se deschide formularul frm_START
(FIG.206) cu ajutorul căruia se controlează toate acţiunile programului.
Apoi, în funcţie de opţiunea utilizatorului, se efectuează:
introduceri şi modificări de date controlate de formularul frm_IntroDate
(FIG.207);
vizualizarea situaţiilor centralizatoare sub controlul formularului
frm_Rapoarte (FIG.208).
FIG.206
FIG.207
FIG.208
♦ Dacă utilizatorul doreşte să introducă date despre un set de firme noi, va

acţiona butonul de comandă cu textul “Clienţi noi”. Se va deschide
formularul din FIG.188 care permite introducerea interactivă a datelor.
♦ Prin acţionarea butonului cu textul “Modificare date clienţi” se lansează
formularul care conţine lista derulantă pentru a alege numele societăţii ale
cărei date se modifică.
în caz că societatea este găsită printre cele din listă, se afişează datele
specifice şi se permite modificarea acestora prin dialogul din FIG.189.
dacă utilizatorul tastează în spaţiul de editare un nume de societate
inexistent în listă, se cere confirmarea pentru introducerea în baza de
date a unei noi societăţi, conform dialogului prezentat în FIG.199.
♦ Acţionarea butonului cu textul “Înregistrare tranzacţie” lansează dialogul din
FIG.186:
valoarea câmpului Cod_Societate se alege dintr-o listă derulantă în
care sunt afişate numele tuturor clienţilor. Valoarea câmpului
tip_Tranzacţie poate fi “Vânzare” sau “Cumpărare”, la alegere din lista
derulantă aferentă. Utilizatorul va tasta cantitatea şi preţul de
tranzacţionare al unei acţiuni.
♦ Prin acţionarea butoanelor cu textul “Jurnal Clienţi”, “Jurnal de
operaţiuni”, “Sold curent” şi “Adrese pentru mape”, se vizualizează
rapoartele corespunzătoare. Acestea sunt prezentate în FIG.210, FIG.211,
FIG.212 şi respectiv FIG.213. Pentru tipărirea listelor, utilizatorul va folosi
butonul Print din fereastra PrintPreview; setările pentru imprimantă vor fi
preluate automat din mediul Windows.
♦ La acţionarea butonului cu textul “Tranzacţii efectuate”, se lansează
dialogul prezentat în FIG.194 prin care se permite utilizatorului să selecteze
numele unui client din lista derulantă. Se obţine raportul prezentat în FIG.214.
♦ La acţionarea butonului cu textul “Preţ mediu ponderat”, se lansează
formularul frm_PretMediu prezentat în FIG.209.
♦ Prin acţionarea butonului cu textul “Toţi clienţii”, se obţine raportul prezentat
în FIG.215.
FIG.209
♦ Prin acţionarea butonului cu textul “După numele firmei”, se lansează

dialogul prezentat în FIG.199. În urma tastării corecte şi complete a unui
nume de societate, se obţine situaţia din FIG.200.
♦ La acţionarea butonului cu textul “Top 3”, se afişează situaţiile prezentate în
FIG.202.
§3.2. Rapoarte
Situaţiile centralizatoare corespunzătoare cerinţelor precizate în capitolul

§2.1. pct. D. se obţin prin activarea butoanelor formularelor meniu descrise în
capitolul §3.1. Figurile următoare prezintă fragmente din previzualizarea listelor.
FIG.210
FIG.211
FIG.212
FIG.213
FIG.214
FIG.215
§4. ANEXĂ
În FIG.216 sunt prezentate toate obiectele bazei de date şi modul în care

sunt apelate succesiv pentru îndeplinirea sarcinilor specifice ale aplicaţiei.
Organigrama aplicaţiei
frm_START
(2 butoane - OnClick)
frm_IntroDate frm_Rapoarte
(3 butoane - OnClick) (7 butoane - OnClick)
frm_Crt frm_AdaugFirma frm_FirmaNoua rpt_JurnalClienti rpt_JurnalOperatiuni

(bazat pe tblFirme) (bazat pe tblTran)
mac_Operatii frm_FirmaNoua frm_FirmaNoua rpt_Solduri frm_SocietateCombo

(pt.adãugare) (pt.modificare) (bazat pe qry_Solduri)
qry1, qry2, qry3, rpt_qryVizu

qry4, qry5 (bazat pe qryVizuFirme_Tranz)
frm_PretMediu qry_TopC
qry_TopV
rpt_PMediu qry_PMediu_Firma frm_TopC

frm_TopV
rpt_Adrese
FIG.216
4. PROBLEME REZOLVATE
După cum rezultă din capitolul anterior, etapele cele mai dificile în realizarea
aplicaţiilor de baze de date sunt cele în care se proiectează tabelele, se stabilesc
relaţii între tabele, se descriu şi se implementează algoritmii de procesare a
datelor.
Problemele rezolvate în continuare sunt exemple de abordare a unor
probleme reale pentru care se construieşte structura de date, se prezintă logica
aplicaţiei şi modul de implementare a principalelor sarcini. Interfaţa aplicaţiei şi
listele utilizator pot fi realizate uşor, după modele prezentate în capitolul 3.
4.1 Evidenţa rezervărilor de locuri într-o reţea de bilete de tratament
Într-o reţea de vânzare a biletelor de tratament, se efectuează rezervări în

limita locurilor disponibile. Biletele sunt oferite de mai multe hoteluri localizate în
diverse staţiuni. Pe baza rezervărilor efectuate de clienţi, se va realiza un registru
de evidenţă a rezervărilor şi a locurilor încă disponibile.
1. Analiza făcută pe baza formulării problemei, include ipoteza simplificatoare

prin care se ignoră data şi perioada biletului de tratament.
Tabelele primare memorează numele staţiunilor şi hotelurilor, date despre
locurile disponibile şi date despre clienţi. Tabelul tblRezCrt este un tabel tampon
care conţine date despre rezervarea în curs de operare. Tabelul tblRezervari este
similar unui registru în care se ţine evidenţa rezervărilor efectuate.
Organizarea datelor şi relaţiile între tabele sunt prezentate în FIG.217.
Structura şi conţinutul tabelului tblHoteluri sunt prezentate în FIG.218.
Structura tabelelor tblRezCrt şi tblRezervari sunt prezentate în FIG.219.
FIG.217
FIG.218
FIG.219
2. Interfaţa pentru introducerea datelor referitoare la o rezervare de bilete o

constituie un formular. În FIG.220 se prezintă formularul frmRezCrt obţinut cu
ajutorul utilitarului wizard.
FIG.220
Observaţii:
- Câmpurile Disponibile şi Locuri rămase sunt adăugate ulterior, folosind
butonul TextBox de pe bara cu instrumente. Acestea rămân câmpuri
nelegate, valoarea lor fiind dată de expresii calculate.
- Butonul cmdRezervati va declanşa succesiunea de operaţii necesare pentru
efectuarea şi înregistrarea rezervării.
3. Interfaţa prietenoasă realizată prin formularul creat este necorespunzătoare

deoarece, deşi utilizatorul alege o staţiune, lista derulantă pentru selectarea
hotelului va conţine toate hotelurile, indiferent de staţiunea aleasă.
Situaţia este prezentată în FIG.221. O interfaţă corectă este cea prezentată
în FIG.222.
FIG.221
FIG.222
Interfaţa din FIG.222 se obţine în doi paşi:
- filtrarea datelor în interogarea care stă la baza listei derulante Hotelul.

Modul de accesare al proprietăţii RowSource este prezentat în FIG.223.
Stabilirea condiţiilor de filtrare se realizează interactiv, prin adăugarea
câmpului Statiunea şi introducerea expresiei cu ajutorul utilitarului Build
(FIG.224).
FIG.223
FIG.224
- actualizarea listei derulante Hotelul la fiecare modificare a valorii selectate de

utilizator în lista Statiunea.
Actualizarea se realizează prin scrierea unei proceduri legate de

evenimentul OnChange al listei derulante Statiunea. Modul de accesare al
evenimentului este prezentat în FIG.225. Procedura VBA forţează
executarea interogării sursă a listei Hotelul, ori de câte ori se modifică
valoare listei Statiunea. Se utilizează metoda Requery a obiectului Hotelul
(FIG.226).
FIG.225
Private Sub Statiunea_Change()

Hotelul.Requery
End Sub
FIG.226
4. Evidenţa rezervărilor şi a locurilor disponibile se realizează în modul

prezentat în aplicaţia de evidenţă a acţiunilor. Pentru aceasta se creează
interogările:
- qry1ActuLibere prin care se calculează numărul locurilor disponibile rămase
după scăderea celor rezervate prin formularul frmRezCrt (FIG.227);
- qry2AdaugRezervare prin care se memorează rezervarea în registrul
tblRezervari (FIG.228);
- qry3StergRezCrt prin care se goleşte tabelul tblRezCrt.
FIG.227
FIG.228
- Pentru lansarea automată a interogărilor, se creează macrocomanda

macRezervare (FIG.229).
FIG.229
5. Afişarea numărului de locuri disponibile se realizează prin controlul

Disponibile de pe formularul frmRezCrt. S-a ales un ListBox pentru a putea filtra
datele în vederea afişării locurilor disponibile în hotelul ales de utilizator.
Modul de accesare al proprietăţii RowSource şi al interogării
corespunzătoare sunt prezentate în FIG.230 şi respectiv FIG.231.
Actualizarea valorii controlului Disponibile se realizează prin executarea
interogării ori de câte ori se modifică în formular valoarea aleasă din lista Hotelul.
Pentru aceasta, se scrie o procedură legată de evenimentul OnChange al listei
Hotelul (FIG.232).
FIG.230
FIG.231
Private Sub Hotelul_Change()

Disponibile.Requery FIG.232
End Sub
6. Succesiunea de operaţii care se efectuează pentru operarea unei rezervări

se lansează prin acţionarea butonului de comandă cmdRezervati. Se scrie codul
VBA legat de evenimentul OnClick al butonului cmdRezervati, prin care:
- Se calculează numărul locurilor rămase, ca diferenţă între valoarea
controalelor Disponibile şi Locuri rezervate (Caption = „Rezervari”).
Dacă rezervarea este posibilă, atunci:
- Se salvează şi se închide formularul.
- Se lansează macrocomanda macRezervare.
Dacă rezervarea este imposibilă, numărul locurilor disponibile fiind mai mic
decât cele pentru care se doreşte rezervarea, atunci:
- Se afişează mesaj de eroare.
- Se anulează tentativa de rezervare prin golirea tabelului tblRezCrt cu ajutorul
interogării qry3StergRezCrt lansată la închiderea formularului.
Cu aceste precizări, codul CBF asociat formularului frmRezCrt devine
următorul:
Private Sub Statiunea_Change()

Hotelul.Requery
End Sub
Private Sub Hotelul_Change()

Disponibile.Requery
End Sub
Private Sub cmdRezervati_Click()

LocuriRamase.Value = Disponibile.ItemData(0) - [Locuri rezervate].Value

If LocuriRamase >= 0 Then
LocuriRamase.Visible = True ‘ initial era setat pe False
LocuriRamase.SetFocus
MsgBox ("Rezervare operata")
DoCmd.Save
DoCmd.Close
DoCmd.RunMacro "macRezervare"
Else
MsgBox ("Imposibil. Reluati ! ")
End If
End Sub
Private Sub Form_Close()

If [Locuri rezervate].Value <= 0 Then
DoCmd.OpenQuery "qry3StergRezCrt"
DoCmd.SetWarnings True
End If
End Sub
4.2 Calculator de birou
Realizarea unui calculator de birou implică crearea unui formular cu 4

butoane, corespunzător celor 4 operaţii. Operanzii se vor citi de la tastatură ca
valori ale unor controale de tip TextBox. Se va trata eroarea de împărţire cu zero.
1. Interfaţa este reprezentată de un formular cu 4 butoane (FIG.233). El se

realizează în modul de lucru Design iar butoanele sunt adăugate cu ajutorul barei
cu instrumente ToolBox, cu dezactivarea butonului wizard.
FIG.233
2. Citirea de la tastatură a celor doi operanzi, se realizează cu ajutorul unei

proceduri citeste. În zona de declaraţii a codului VBA se definesc două variabile
globale n1 şi n2 a căror valoare se obţine de la tastatură ca rezultat al funcţiei
InputBox. Procedura citeste este prezentată în FIG.234.
Sub citeste()
n1 = InputBox ("Introdu primul numar ")
FIG.234
n2 = InputBox ("Introdu al doilea numar ")
End Sub
3. Efectuarea operaţiilor se implementează în VBA prin patru proceduri

asemănătoare, declanşate de evenimentul OnClick al celor patru butoane.
Operanzii se obţin prin apelarea procedurii citeste. Rezultatul se memorează într-o
variabilă locală al cărei tip se alege în mod corespunzător. Afişarea se face cu
ajutorul unei casete MsgBox.
Ca exemplu, procedura pentru adunare este prezentată în FIG.235.
Private Sub cmdAdunare_Click()

Dim rezultat As Integer
Call citeste
FIG.235
rezultat = n1 + n2
MsgBox rezultat, , "Suma este"
End Sub
4. Tratarea erorii de împărţire cu zero presupune testarea valorii celui de al
doilea operand. Se utilizează comanda IF, cu o sintaxă similară celor mai multe
limbaje de programare. Mesajul de eroare personalizat este prezentat în FIG.236.
FIG.236
Codul VBA complet pentru realizarea calculatorului este prezentat în

continuare:

Option Explicit
Public n1 As Integer, n2 As Integer
Sub citeste()
n1 = InputBox("Introdu primul numar ")
n2 = InputBox("Introdu al doilea numar ")
End Sub
Private Sub cmdAdunare_Click()

Call citeste
rezultat = n1 + n2
MsgBox rezultat, , "Suma este"
End Sub
Private Sub cmdScadere_Click()

Call citeste
rezultat = n1 - n2
MsgBox rezultat, , "Diferenta este"
End Sub
Private Sub cmdInmultire_Click()
Call citeste
rezultat = n1 * n2
MsgBox rezultat, , "Produsul este"
End Sub
Private Sub cmdImpartire_Click()

Dim rezultat As Single
Call citeste
If n2 = 0 Then
MsgBox "Eroare!" & Chr(13) & "Impartire cu zero." 'afisare pe 2 randuri
Else
rezultat = n1 / n2
MsgBox rezultat, , "Catul este"
End If
End Sub
4.3 Evidenţa mişcărilor de carte într-o bibliotecă

Evidenţa mişcărilor de carte (împrumut / restituire) este sarcina principală a

oricărei aplicaţii de tip bibliotecă. În rezolvarea ei se vor avea în vedere
următoarele aspecte:
Un abonat poate împrumuta maximum 3 cărţi;
Orice împrumut va fi refuzat în cazul în care există un împrumut anterior
nerestituit;
Pentru fiecare împrumut nerestituit la termen se va calcula întârzierea, în
zile calendaristice;
La restituire se va afişa automat existenţa unui împrumut, precum şi titlurile
cărţilor de restituit.
1. Analizând datele manipulate într-o bibliotecă şi ţinând cont de principiul

separării datelor, fereastra Relationships a aplicaţiei are aspectul prezentat în
FIG.237.
FIG.237
2. Mişcările de carte sunt controlate de formularele frm_MiscariCarte,

frm_Imprumut şi frm_Restituiri.
Formularul frm_MiscariCarte (FIG.238) realizează identificarea abonatului
pe baza datelor din legitimaţia de bibliotecă şi permite lansarea operaţiilor de
împrumut, restituire sau verificare a credibilităţii.
FIG.238
Lista derulantă pentru alegerea abonatului preia datele din tabelul Abonati.
Valoarea proprietăţii Row Source este o interogare de tip Select realizată manual
(FIG.239).
FIG.239
În FIG.240 se prezintă modul de realizare a câmpului calculat Numeab,

obţinut prin concatenarea datelor din câmpurile Nume şi Prenume din tabelul
Abonati.
FIG.240
Cele trei butoane de comandă de pe formular lansează acţiunile

corespunzătoare: împrumut, restituire şi testarea credibilităţii.
3. Introducerea unui nou abonat poate fi făcută direct în lista derulantă

Aleg_Abonat. Evenimentul corespunzător este tratat printr-o procedură asociată
evenimentului OnNotInList al listei Aleg_Abonat.
Procedura identifică spaţiul din şirul de caractere introdus de utilizator,
separând astfel numele de prenume, defineşte un Recordset pe articolele
tabelului Abonati, îi adaugă un articol nou pe care îl actualizează cu valorile nou
introduse. Procedura este redată în continuare:
Private Sub Aleg_Abonat_NotInList(NewData As String, Response As Integer)

Dim rec As Recordset

raspuns = MsgBox("Abonat nou!" & Chr(13) & "Doriti introducerea lui”_
”in lista ?", vbYesNo)

Dim numeabonat As String, prenabonat As String
Dim locspatiu As Byte
NewData = StrConv(NewData, vbProperCase)
locspatiu = InStr(NewData, " ")
If locspatiu <> 0 Then
numeabonat = Left(NewData, locspatiu - 1)
prenabonat = Mid(NewData, locspatiu + 1)
Else
numeabonat = NewData
End If
Response = acDataErrAdded
Set rec = CurrentDb.OpenRecordset("Abonati")
With rec
.AddNew
!Nume = numeabonat
!Premune = prenabonat
.Update
.Close
End With
DoCmd.OpenForm "frm_abonati"
DoCmd.GoToRecord acDataForm, "frm_abonati", acLast
Else
Response = acDataErrContinue ’ continua, indiferent de eroare
Aleg_Abonat.Undo
End If
End Sub
4. Înregistrarea unui împrumut în tabelul Imprumut se lansează din

formularul frm_MiscariCarte. După alegerea unui abonat din listă, urmat de
acţionarea butonului de comandă Împrumut, se deschide formularul
frm_Imprumut cu aspectul din FIG.241.
Acesta este un formular simplu, creat cu ajutorul utilitarului Form Wizard.
FIG.241
Formularul frm_Imprumut preia datele de identificare ale abonatului din

formularul frm_MiscariCarte. Controlul acţiunii se efectuează din modulul clasă
asociat formularului frm_MiscariCarte. Transmiterea valorii selectate de utilizator
ca valoare a controlului Aleg_Abonat se realizează prin clauza Where a comenzii
DoCmd.OpenForm. Totodată, se verifică existenţa unui împrumut nerestituit.
Sintaxa comenzii este următoarea:
DoCmd.OpenForm "frm_Imprumut", , , "Abonat_Id = " _

"Forms!frm_MiscariCarte!Aleg_Abonat and Imprumut.Restituit = No"
Dialogul corespunzător situaţiei de refuz al unui împrumut din motivul
existenţei unui împrumut anterior nerestituit este prezentat în FIG.242.
FIG.242
În cazul opţiunii de restituire, se deschide dialogul de restituire, iar în caz

contrar, împrumutul va fi refuzat. Mesajul corespunzător este prezentat în
FIG.243.
FIG. 243
Acţionarea butonului de comandă Restituire are ca efect deschiderea

formularului frm_Restituiri cu aspectul din FIG.244. În cazul existenţei unui
împrumut, se afişează titlurile corespunzătoare. Utilizatorul va confirma
restituirea împrumutului şi va trece data restituirii. În cazul în care abonatul nu
are împrumut de restituit, se va afişa mesajul din FIG.245.
Solicitarea testului de credibilitate, are ca rezultat afişarea raportului
corespunzător (FIG.246). Întârzierea se calculează faţă de data curentă a
sistemului.
În cazul abonaţilor care restituie cărţile la termenul stabilit, se afişează
mesajul din FIG.247.
FIG.245
FIG.246
Toate acţiunile legate de formularele frm_MiscariCarte, frm_Imprumut şi

frm_Restituiri sunt controlate prin codul VBA asociat formularului
frm_MiscariCarte. Textul sursă corespunzător este:
Private Sub Imprumut_Click()

Dim raspuns
DoCmd.OpenForm "frm_Imprumut", , , _
"Abonat_Id = Forms!frm_MiscariCarte!Aleg_Abonat " &_
"and Imprumut.Restituit = No"
With Forms!frm_imprumut
If .CurrentRecord = 0 Then
.AllowAdditions = True
.DataEntry = True
.Abonat_Id = Forms!frm_MiscariCarte!Aleg_Abonat
.Abonat_Id.Locked = True
Else
raspuns = MsgBox("Exista imprumut nerestituit!" & Chr(13) & "Restituiti ?", _
vbYesNo, " ")
DoCmd.OpenForm "frm_Restituiri", , , "Abonat_Id ="_
"Forms!frm_MiscariCarte!Aleg_Abonat and Imprumut.Restituit=No"

Else
DoCmd.Close acForm, "frm_Imprumut"
MsgBox ("Imprumut Refuzat !")
End If
End If
End With
End Sub
Private Sub Restituire_Click()

DoCmd.OpenForm "frm_Restituiri", , , "Abonat_Id = "_
Forms!frm_MiscariCarte!Aleg_Abonat and Imprumut.Restituit=No"
If Forms!frm_Restituiri.CurrentRecord = 0 Then
DoCmd.Close acForm, "frm_Restituiri"
MsgBox ("Nu sunt carti de restituit !")
End If
End Sub
Private Sub Test_Click()

DoCmd.OpenReport "rpt_Intarziati", acPreview, , "Abonat_Id ="_
Forms!frm_MiscariCarte!Aleg_Abonat"
If Reports!rpt_Intarziati.HasData = 0 Then
DoCmd.Close acReport, "rpt_Intarziati"
MsgBox ("Nu are nici o intarziere!")
End If
End Sub
BIBLIOGRAFIE
1. Cameniţă D., Nicolaescu C., Belean P.,

Bazele contabilităţii, Ed. Multimedia Arad, 2000
2. Cernuşca L.,
Concepte şi practici ale contabilităţii de gestiune,
Ed. Universităţii "Aurel Vlaicu", Arad, 2004
3. Cohen J.C.,
Les informanageurs, Les édition d'organisation, Paris, 1990
4. Dollinger R.,
Baze de date şi gestiunea tranzacţiilor, Ed. Albastră, Cluj-Napoca,1998,
reeditată 2002
5. Fehily C.,
SQL, Visual Quickstart Guide, Ed. Bic-All, Bucureşti, 2004
6. Fotache M.,
Proiectarea bazelor de date. Normalizare şi postnormalizare,
Implementări SQL şi Oracle., Ed. Polirom, Iaşi, 2005
7. Hernandez M.J.,
Proiectarea bazelor de date, Ed. Teora, Bucureşti, 2003
8. Isac F.L., Rusu S.,

Management în turism, Ed. Mirton, Timişoara, 2007
9. Kovacs S.,
Access 2000. Implementarea bazelor de date,
Ed. Albastră, Cluj-Napoca, 2004
10. Kovacs S.,

Access 2000. Programarea bazelor de date,
Ed. Albastră, Cluj-Napoca, 2003
11. Marlowe K.,

Utilizare Access ’97, Ed. Teora, Bucureşti, 1999
12. Militaru Ghe.,

Sisteme informatice pentru management, Ed. Bic-All, Bucureşti, 2004
13. Nagy M.,

Baze de date. Exemple şi aplicaţii în gestiunea economică,
Ed. Mirton, Timişoara, 2002, reeditată 2006
14. Nagy M.,

Elemente de programare. Note de curs şi probleme rezolvate,
Ed. Universităţii "Aurel Vlaicu", 2000
15. Nagy M.,

Sisteme informatice în contabilitate,
16. Nagy M., Vizental M.,

Prelucrarea informaţiei economico-financiare, Note de curs şi exemple,
Ed. Mirton, Timişoara, 2003
17. Năstase P. şi colectivul,

Baze de date Microsoft Access 2000, Ed. Teora, Bucureşti, 2000
18. Năsui D.,

Pieţe financiare şi burse de valori,
19. Oprea D., Airinei D., Fotache M.,

Sisteme informaţionale pentru afaceri, Ed. Polirom, Iaşi, 2002
20. Smith R., Sussman D.,

Programare în Access 97, VBA pentru începători,
Ed. Teora, Bucureşti, 1999
21. Tăgăduan D., Gomoi C.B.,

Gestiunea financiară a întreprinderii,
22. Teodorescu A.,

Lecţii de Access, Ed. Albastră, Cluj-Napoca, 2002
23. Viescas J.L., Conrad J.,

Microsoft Office Access 2007 Inside Out, Microsoft Press, 2007
24. *** Colecţia Revistei „Capital”
25. *** Revista Română de Biblioteconomie şi Ştiinţa informării
26. *** Documentaţie Microsoft Access ‘97, 2000 şi XP
27. *** Microsoft Office 2000, Curs rapid, Ed. Teora, Bucureşti, 2000
28. www.infosrl.ro, Legea contabilităţii nr. 82/1991 - actualizată la 27.07.2007
29. www.bvb.ro
30. www.edu.ro
31. www.microsoft.com
32. www.mmssf.ro
33. www.sas.mmssf.ro

Note de Curs Si Aplicatii

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Note de Curs Si Aplicatii

Încărcat de

Drepturi de autor:

Formate disponibile

Note de curs şi aplicaţii 7

1. Bazele de date – instrument util pentru gestionarea unui volum

2. Obiecte MS-Access. Creare, utilizare, proprietăţi ................................ 41

2.2 Cheia primară. Utilitarul LookUp Wizard ...................................... 52

2.7.1 Rolul macrocomenzilor ........................................................ 125

3. Aplicaţii .................................................................................................... 143

3.3 Aplicaţie pentru evidenţa tranzacţiilor de acţiuni ..................... 187

4. Probleme rezolvate................................................................................. 225

Bibliografie ................................................................................................... 246

1. BAZELE DE DATE – INSTRUMENT UTIL PENTRU GESTIONAREA

Societatea românească se află în plin proces de transformare; opţiunea

1.1 Noţiuni fundamentale

Datele sunt un ansamblu de semne cu un sens bine determinat, organizate

Fiind o reflectare a realităţii prin prisma gândirii umane, informaţia are un

fi operativă, periodică, statistică sau previzională:

poate fi analitică sau sintetică:

În condiţiile economiei de piaţă, luarea deciziei corecte depinde esenţial de

1.2 Cuplul informaţie-decizie într-o economie sistemică

Activitatea umană, privită ca totalitatea proceselor economico-sociale

O privire sistemică a unităţii economice conduce la delimitarea a trei

Sistemul de conducere cuprinde ansamblul activităţilor de conducere,

sistemul informaţional “se informatizează”, adică sistemul informatic al unităţii

1.3 Aspecte generale privind bazele de date

În ultimii cincizeci de ani, producţia şi utilizarea tehnicii de calcul –

câţiva ani, sistemele mari de baze de date puteau fi executate numai pe

modificare radicală de la programarea aplicaţiilor bazată pe calculatoarele

1.4 Arhitectura unei baze de date

Arhitectura unei baze de date reprezintă modul de organizare a datelor,

1.4.1 Independenţa datelor

Independenţa datelor constituie un scop esenţial în concepţia şi

ulterioare în structura logică a datelor;

cu anumite limitări, de exemplu e interzisă eliminarea datelor.

1.4.2 Nivele de abstractizare a datelor

Abstractizarea este un procedeu prin care se neglijează aspectele

 nivelul conceptual (modelul conceptual sau schema conceptuală);

 nivelul extern (modelul extern, subschemă, vedere).

FIG.2 - Schema generală a unei baze de date

utilizator sau grup de utilizatori. Cu ajutorul vederilor se controlează accesul la

1.4.3 Modelarea datelor la nivel conceptual

Modelarea datelor este un instrument care conduce la interpretarea

FIG.3. – LDD, componentă a modelului conceptual

Regulile pentru manipularea datelor reprezintă proprietăţile dinamice ale

O entitate este o realitate obiectivă care există prin ea însăşi. Entitatea

Astfel, există trei tipuri esenţiale de modele de date: modelul ierarhic,

Modelul de date reţea este bazat pe tabele şi grafuri, pentru

nu include în mod necesar şi înregistrările membru;

tipuri de set pot include mai mult de un tip membru;

aceluiaşi tip de set;

instanţiere a unui tip de set.

intermediar. Înregistrările tipului intermediar, numite şi înregistrări de legătură,

 Gama interogărilor posibile e limitată doar de structura bazei de date;

 Sunt eliminate anomaliile de ştergere, adăugare şi actualizare a datelor.

Principalul dezavantaj al modelului de date reţea este faptul că are o

1.5 Etape în evoluţia bazelor de date

Activitatea de organizare şi prelucrare a datelor a avut în ultimii ani o

Prima etapă a evoluţiei tehnicilor de organizare şi prelucrare a datelor se

dependenţa aplicaţiilor faţă de date, concretizată prin faptul că o modificare în

Etapa a treia este definită de apariţia fişierelor integrate. Aceasta elimină

1.5.3 Tendinţe în dezvoltarea bazelor de date

Majoritatea covârşitoare a sistemelor de gestiune a bazelor de date aflate

 Încapsularea constă în posibilitatea de a defini proceduri care se aplică

1.6 Sisteme de gestiune a bazelor de date

Printr-un Sistem de Gestiune a Bazelor de Date se înţelege o colecţie de

Pentru ca un SGBD să fie considerat total relaţional, el trebuie să respecte