1

Capitolul 1
Chestiuni introductive privind crearea de aplicaii cu baze de date

Este un fapt evident acela c majoritatea aplicaiilor n domeniul economic utilizeaz

date ntr-o form sau alta. Aceste date sunt memorate adesea n una sau mai multe baze de
date. Mediul Visual Basic poate crea, cu un efort de planificare i proiectare nu prea mare,
programe puternice de gestionare a datelor. Unul din factorii cei mai importani ai acestei
planificri se refer la modul de organizare a datelor. O baza de date prost structurat poate s
conduc la eec chiar avnd cel mai bine gndit program, n schimb o baz de date bine
proiectat poate uura mult munca programatorului.
Pentru a crea o structur de date bine organizat, va trebui s ne familiarizm cu dou
probleme:
1) Va trebui s nvm cum s proiectm o baz de date. n aceast etap va trebui s
decidem care date vor trebui incluse n baza de date i cum vor fi ele organizate;
2) Va trebui s nvm modul de implementare a bazei de date proiectate n baza de
date efectiv, propriu-zis.
n acest capitol voi lua ca exemplu proiectarea i crearea unei baze de date care conine
informaii cu privire la situaia la nvtur a unor studeni dintr-o anumit serie i an de
studiu (note la diferitele discipline, absene, total credite obinute, calculul mediei etc.). Pe
baza ei vor fi exemplificate i alte noiuni din aceast carte.
1.1. Elemente de proiectare a unei baze de date
Pentru a proiecta o aplicaie cu baze de date trebuie stabilite nu doar rutinele-program,
pentru o performan ct mai bun, ci trebuie acordat de asemenea o foarte mare atenie
organizrii fizice i logice a modului de stocare a datelor. O bun proiectare a bazelor de date
asigur urmtoarele:
timp minim de cutare la localizarea unor nregistrri specifice;
memorarea datelor n modul cel mai eficient posibil pentru a mpiedica baza de date
s creasc exagerat de mult;
actualizarea datelor ntr-un mod ct mai uor cu putin;
o suficient flexibilitate pentru a permite includerea unor noi funcii cerute de
program.
La proiectarea unei baze de date trebuie avute n vedere mai multe obiective, care vor
fi enumerate mai jos. Dei ar fi ideal s poat fi mplinite toate aceste obiective de proiectare,
n unele cazuri ele se exclud reciproc i ca trebui cutat o soluie optim. Cele mai
importante obiective n proiectarea unei baze de date sunt:

eliminarea datelor redundante;

capacitatea de a localiza foarte rapid anumite nregistrri individuale;
posibilitatea de a face mbuntiri uor de implementat pentru baza de date;
pstrarea unei uoare ntreineri a bazei de date.

Crearea unui proiect bun de baze de date implic urmtoarele ase etape:
1. Modelarea aplicaiei
2. Determinarea datelor necesare pentru aplicaie;
3. Organizarea datelor n tabele i stabilirea relaiilor ntre acestea;
4. Stabilirea cerinelor de indexare i de validare pentru datele respective;
5. Crearea i memorarea interogrilor necesare pentru aplicaie;
6. Revederea proiectrii.
1

n cele ce urmeaz vom lua n discuie etapele de mai sus.

1.1.1. Modelarea aplicaiei

Atunci cnd modelm o aplicaie, primul lucru pe care trebuie s-l facem este s
determinm sarcinile pe care aplicaia trebuie s le rezolve. De exemplu atunci cnd inem
evidena studenilor i a rezultatelor acestora la nvtur, se tie c se dorete posibilitatea
calculului mediei fiecruia dintre acetia, a numrului total de credite cumulat de fiecare n
parte i eventual anumite statistici pe ani, grupe, sex sau alte criterii. Determinnd sarcinile ce
trebuiesc rezolvate de ctre aplicaie se creeaz aa-numita specificaie funcional. Atunci
cnd aplicaia pe care o creai este chiar pentru dumneavoastr, probabil c v sunt clare toate
sarcinile pe care dorii ca aplicaia s le efectueze. Totui a scrie aceste sarcini ntr-un
document de specificaii este o idee bun. Acest document v poate ajuta s nu pierdei din
vedere nimic din ceea ce dorii ca programul s rezolve. Dac ns aplicaia pe care o creai
este pentru altcineva, o specificaie funcional poate deveni un acord, o nelegere cu
utilizatorul, asupra a ceea ce aplicaia va trebui s rezolve. Aceste specificri pot constitui
jaloane de atins pe parcursul proiectrii aplicaiei.
Atunci cnd creai programul pentru altcineva, cea mai bun cale de a nva ce operaii
trebuiesc efectuate este de a vorbi cu persoana (beneficiarul) n cauz i a pune ntrebri. Ca
un prim pas ar trebui aflat dac ei nu au deja un sistem pe care doresc s-l nlocuiasc cu altul
mai bun, sau dac au anumite rapoarte pe care doresc s le obin. Punei apoi o sumedenie de
ntrebri, pn cnd ai neles scopurile utilizatorului pentru programul pe care vi-l solicit.
1.1.2. Determinarea datelor necesare pentru aplicaie

Dup determinarea specificaiilor funcionale pentru program se poate trece la

determinarea datelor de care are nevoie aplicaia. n cazul aplicaiei propuse, cu privire la
situaia la nvtur a unor studeni, va trebui s cunoatem datele personale a fiecrui
student, dac acesta este sau nu n regim cu tax i dac i-a achitat sau nu taxele pentru anul
n curs, inclusiv adresa sau telefonul la care acesta poate fi contactat n caz de neplat la timp a
taxelor de colarizare. Apoi trebuiesc cunoscute disciplinele i creditele aferente fiecrei
discipline, respectiv notele obinute la aceste discipline, datele examenelor i numele
profesorilor care au dat notele. De asemenea, n cazul cerinei unor situaii pe grupe de studiu
este necesar un index sau o interogare care s afieze studenii pe grupe, i n cadrul grupelor
alfabetic. Se poate astfel observa c modelul aplicaiei nu d doar indicii cu privire la datele
necesare, ci definete de asemenea alte componente ale bazei de date.
1.1.3. Organizarea datelor n tabele i stabilirea relaiilor ntre acestea

Unul din aspectele cheie a unei proiectri eficiente a bazelor de date este determinarea
modului n care datele vor fi organizate n baza de date. Pentru o bun proiectare, datele
trebuiesc organizate ntr-un mod care s permit o uoar extragere a informaiilor i care s
fac baza de date uor de ntreinut. n cadrul unei baze de date, datele sunt memorate n una
sau mai multe tabele. Pentru cele mai multe aplicaii cu baze de date se poate obine o
organizare eficient a datelor prin memorarea datelor n mai multe tabele i prin stabilirea unor
relaii ntre aceste tabele.
Tabele. Un tabel este o colecie de informaii cu privire la un anumit subiect. Stabilind
un subiect-cheie pentru fiecare tabel se poate stabili dac o anumit dat i are locul sau nu
n respectivul tabel. De exemplu, dac instituia de nvmnt dorete s in o eviden att a
studenilor ct i a profesorilor, proiectantul bazei de date ar putea fi tentat s introduc datele
ambelor categorii de persoane n aceeai tabel ambele necesitnd nume, prenume, adresa,
telefon. Totui, uitndu-ne la datele necesare studenilor, observm c pentru acetia ar fi
necesare i informaii cu privire la grupa de care aparin, la forma de nvmnt (cu sau fr
2

tax) i la achitarea sau nu a taxei pentru cei n regim cu tax. Dac s-ar crea o singur tabel
pentru studeni i profesori, multe cmpuri ar rmnea astfel necompletate n dreptul
profesorilor. De asemenea ar fi necesar atunci s se adauge un cmp care s fac distincia
ntre un student i un profesor. n mod clar aceast metod ar conduce la mult spaiu de
memorare ocupat fr nici un rost. De asemenea ar rezulta o procesare mai lent a tranzaciilor
care vizeaz numai studenii sau numai profesorii, deoarece programul va trebui s sar tot
timpul peste anumite nregistrri din tabel care nu intereseaz. Figura 1.1. arat o tabel de
baz de date cu cele dou categorii (studeni i profesori) combinate. Figura 1.2. arat
reducerea numrului de cmpuri ntr-un tabel doar cu profesorii.

Figura 1.1. Combinarea ntr-o singur tabel a studenilor i profesorilor duce la risip mare de spaiu

1.1.3.1. Normalizarea datelor

A normaliza datele nseamn a elimina datele redundante dintr-o baz de date.

nchipuindu-ne normalizarea dus la extrem, acest lucru ar nsemna ca fiecare informaie s nu
apar dect o singur dat ntr-o baza de date. Practic ns acest lucru nu este ntotdeauna
posibil i nici de dorit.

Figura 1.2. O tabel separat pentru profesori conine doar cmpurile care intereseaz i este mai
eficient

Observai, privind la figura 1.2, c nu am introdus n tabela Studenti nici o informaie

cu privire la vreun anumit examen, data acestuia, disciplina i profesorul, respectiv nota
primit cu acea ocazie. Aceasta deoarece este de preferat ca informaiile cu privire la examene
i note s fie separate de tabela studenilor pentru ca diferitele informaii suplimentare cu
privire la adres, telefon sex, grup, achitarea taxelor etc. s nu se repete i aici, ci referirea la
un anumit student s se fac prin numrul acestuia de identificare, deci printr-un cmp numit
de noi StudId. Similar n tabela cu nregistrrile notelor obinute la diferitele examene se va
face referirea la profesorul cu care s-a dat examenul prin numrul de identificare al acestuia,
3

numit n acest exemplu ProfId aceasta de asemenea pentru a nu ncrca tabela notelor cu
toate informaiile suplimentare care exist n tabelul Profesori cu privire la un anumit profesor.
Observaie. Aceste cmpuri de identificare, StudId din tabelul Studenti i ProfId din
tabelul Profesori conin ntotdeauna valori unice, distincte. Ele vor constitui i chei primare
n respectivele tabele. Aceasta nseamn, spre exemplu, c o anumit valoare a lui StudId
poate exista doar pentru o singur nregistrare din tabelul Studenti i nu poate fi duplicat.
Astfel va putea fi distins un anumit student de altul, chiar dac cei doi ar avea nume identice,
i poate prin absurd i adrese sau orice alte cmpuri identice.
Prin urmare, dac se plaseaz toate aceste date cu privire la notele studenilor ntr-o
singur tabel, rezultatul ar arta asemntor ce ceea se poate vedea n figura 1.3. Deja aici
citirea tabelei se complic la o simpl privire fugar, deoarece n locul numelor studentului i
al profesorului avem numerele de identificare a acestora, care trebuie s ne fac legtura cu
tabelele Studenti i Profesori pentru a putea afla cine sunt acetia.

Figura 1.3. Datele nenormalizate conduc la tabele de date mari, ineficiente

Din figura de mai sus rezult clar faptul c n tabela Note foarte multe date se repet.
Aceast repetare a unor informaii are dou urmri nedorite:
n primul rnd se risipete spaiu, deoarece multe informaii se repet de
nenumrate ori;
n al doilea rnd ar putea fi un factor de pierdere a corectitudinii unor date. Dac de
exemplu se hotrte ca unei anumite discipline s i se acorde un numr mai mare
sau mai mic de credite dect s-a tiut iniial, aceast modificare va trebui fcut
asupra tuturor nregistrrilor care se refer la respectiva disciplin, cu
posibilitatea de a grei i a lsa vreuna din nregistrrile mai vechi nemodificat.
O metod mai bun de a organiza datele va fi de a separa disciplinele de note, i chiar
i datele cu privire la un anumit examen de note. Astfel n tabela Discipline vor aprea doar
denumirea disciplinei cu numrul de credite aferent i un identificator de disciplin ( DId), n
tabela Examene doar data, identificatorul de disciplin (DId), profesorul cu care s-a dat
examenul cunoscut prin identificatorul de profesor ( ProfId) i un identificator de examen
(ExId), iar n tabela Note doar identificatorul de student (StudId), nota i identificatorul de
examen (ExId). Pentru identificatorul DId din tabela Discipline i pentru identificatorul ExId din
tabela Examene rmne valabil observaia enunat n nota anterioar: Aceste cmpuri vor
conine valori distincte i unice n tabelele respective i vor constitui chei primare n acele
tabele. Astfel rezult n locul tabelului din figura 1.3, trei tabele distincte de genul celor din
figura 1.4.
Desigur, citirea datelor din aceste trei tabele este acum mult mai abstract dect
nainte, i pentru ochiul nostru ar putea prea mult prea complicat. Totui , bazele de date aanumit relaionale se descurc foarte bine cu tabele de acest fel. Pentru aceasta ele utilizeaz
chei de date. De exemplu tabela Note din figura 1.4 are un cmp numit ExId, care, dup cum o
sugereaz i denumirea, va fi un identificator de examen. Acelai cmp ExId este coninut i n
tabela Examene, unde ns ExId este cheie primar. Aceasta nseamn, dup cum am enunat
deja n nota scris cu caractere italice mai sus, c o anumit valoare a lui ExId poate exista
doar pentru o singur nregistrare din tabela Examene.

Fig. 1.4. Normalizarea complet a tabelelor asigur eficien maxim.

Practic, fiecare nregistrare a tabelei Examene va conine un examen distinct,

caracterizat printr-o anumit dat, un anumit profesor (referit prin ProfId) i o anumit
disciplin (referit prin identificatorul de disciplin DId).
Spunem c cele dou tabele Note i Examene sunt n relaie prin intermediul cmpului
ExId. Observai ns c n tabelul Note cmpul ExId nu va fi cheie primar, ci aici se va numi
cheie strin, deoarece este n legtur cu cmpul ExId din tabela Examene i acel cmp este
un cmp cheie. Totui, n tabela Note, acelai identificator de examen ExId se poate repeta de
cte ori este necesar.
De asemenea n tabela Examene mai apar cmpurile DId i ProfId, care se regsesc i n
tabelele Discipline i respectiv Profesori, tabele n care sunt n mod evident chei primare. Ele
vor fi ns chei strine pentru tabelul Examene, n care pot aprea de cte ori este nevoie.
Astfel nu vor fi restricii n ce privete posibilitatea ca un anumit profesor s predea mai multe
discipline sau o anumit disciplin s fie predat de mai muli profesori desigur la diveri
elevi.
n concluzie: ntr-o baz de date relaional, fiecare tabel are o cheie primar ce
reprezint un cmp (sau o combinaie de cmpuri) prin ale crui (crei) valori se identific fr
ambiguitate fiecare linie a tabelei. Unele tabele au i o cheie strin, ce reprezint un cmp,
care este cheie primar ntr-o alt tabel. Valorile cheii strine dintr-o tabel nu pot fi dect
valori ale cheii primare din tabela corespondent. Aceast regul se numete restricie
referenial.
Microsoft Access ofer o reprezentare vizual foarte sugestiv a relaiilor dintre
tabelele unei baze de date. Modul de obinere a acestei reprezentri este artat la finalul unui
paragraf viitor, i anume 1.2.1. n cazul exemplului discutat mai sus relaiile sunt reprezentate
n Microsoft Access ca n figura 1.5.

Figura 1.5. Reprezentarea relaiilor ntre tabelele unei baze de date n Microsoft Access

Cmpurile ngroate reprezint chei primare n tabelele respective, iar simbolurile

legturilor (cifra 1 i simbolul ) indic faptul c, spre exemplu, unei singure nregistrri
din tabelul Studenti, i pot corespunde mai multe nregistrri din tabelul Note.
S ncercm acum s citim prima nregistrare din tabela Note n varianta ultim din
figura 1.4. Studentul cu numrul de identificare 15 deci POPA LAURENTIU (vezi figura
1.2.) a obinut nota 7 la examenul cu numrul de identificare 3 adic cel din data de
29.06.2003 (vezi tabela Examene din figura 1.4.) la disciplina cu numrul de identificare 4
(adic Limba straina 1 dac se urmrete tabelul Discipline) cu profesorul avnd numrul de
identificare 14 deci NEGRU RADU, rezultat din tabela Profesori. Comparai acum ceea ce
ai citit cu informaiile extrase din tabela Note din figura 1.3. Desigur ele sunt identice i la fel
vor fi i urmtoarele nregistrri.
1.1.3.2. Reguli pentru organizarea tabelelor

Practic nu exist reguli absolute care s delimiteze care date n care tabele trebuiesc
introduse, dar, cu toate acestea am putea enumera cteva reguli generale care ar trebui urmrite
pentru a proiecta o baz de date bine structurat. Acestea ar fi:
Orice tabel trebuie s aib o tem, de exemplu Informaii despre abonai sau
Tranzacii ale clienilor. ncercai s v limitai la o singur tem pe tabel.
Spargei tabela n dou tabele similare n cazul n care un numr de nregistrri au
cmpuri lsate necompletate n mod intenionat (ca i desprirea tabelei Profesori de
tabela Studenti).
Mutai ntr-o alt tabel a informaiilor care se repet ntr-un numr de nregistrri i
stabilii o relaie ntre acele tabele.
Dac exist o list cu informaii de referin, pe care vrei s o pstrai (cum ar fi
disciplinele i numrul de credite aferente fiecreia), punei-le n propriul tabel.
Unde este posibil, folosii numere de identificare, ele ajutndu-v s legai tabele ntre
ele i s evitai greelile de dactilografie datorate introducerii unor iruri lungi de date
(cum sunt numele).
Nu stocai informaii ntr-un tabel dac acestea pot fi calculate din datele altor tabele.

Adeseori, din motive de performan, se ocolesc unele din aceste reguli. De exemplu,
dac pentru a obine vnzrile totale pentru un anumit vnztor este necesar nsumarea mai
multor mii de nregistrri, poate se merit a include un cmp de Vanzari totale n tabela
Vanzatori, cmp care s fie actualizat de cte ori se face o vnzare. n acest fel, atunci cnd
sunt generate rapoarte, aplicaia nu va trebui s efectueze un numr mare de calcule i procesul
de raportare va fi mult mai rapid.
Un alt motiv pentru a devia de la aceste reguli este evitarea deschiderii unui numr prea
mare de tabele n acelai timp. Aceasta deoarece fiecare tabel deschis utilizeaz resurse
preioase i de asemenea spaiu de memorare, nct aplicaia ar putea pierde considerabil din
vitez.
Pe de alt parte, devierea de la aceste reguli de structurare a tabelelor conduce la dou
probleme majore:
creterea mrimii bazei de date din cauza datelor redundante;
posibilitatea de a avea la un moment dat date incorecte din cauz c s-a modificat
coninutul anumitor cmpuri i, dintr-un motiv sau altul, nu toate nregistrrile afectate au fost
actualizate.
n concluzie va trebui cutat un optim ntre performana aplicaiei i eficiena stocrii
datelor n tabele.
1.1.4. Utilizarea indecilor

Atunci cnd se introduc date ntr-un tabel, nregistrrile sunt stocate n general n
ordinea n care ele sunt introduse. Aceasta este ordinea fizic a datelor. De obicei ns
utilizatorii doresc s proceseze datele ntr-o ordine diferit de cea n care au fost introduse
nregistrrile n tabele. Aceasta presupune definirea unei aa-numite ordini logice. Aceast
ordine logic va fi de asemenea util atunci cnd se va dori cutarea ntr-un tabel a unei
anumite nregistrri.
Indexarea este metoda cel mai des utilizat de a ordona tabelele de date. Un index este
de asemenea o tabel, care conine o valoare cheie (derivat de obicei din valorile a unul sau
mai multe cmpuri) pentru fiecare nregistrare din tabela de date; indexul nsui este memorat
ntr-o ordine logic specific i conine pointeri (indicatori de adrese) care spun motorului de
baze de date unde este localizat nregistrarea curent.
Indecii sunt setai la proiectarea tabelei cu scopul de a mri viteza i de a garanta
unicitatea unei nregistrri. Cartea de telefoane de exemplu este o list indexat dup nume.
Atunci cnd cutai numrul de telefon al unei persoane l putei gsi rapid uitndu-v doar la
cteva pagini, dac tii care este numele persoanei. Dac numerele de telefon ar fi date n
cartea de telefon n ordinea n care au fost ele atribuite abonailor, o astfel de carte nu ar folosi
nimnui, fiind aproape imposibil de a gsi numrul unei anumite persoane.
O tabel poate avea mai muli indeci diferii asociai, pentru a asigura pentru anumite
situaii ordonarea datelor ntr-un fel sau n altul. De exemplu tabela studenilor ar putea fi util
n ordine alfabetic a acestora sau poate n ordinea grupelor i eventual alfabetic n cadrul
fiecrei grupe sau, poate, descresctor dup media rezultat n urma introducerii notelor de
examen. Fiecare index arat aceleai date ntr-o ordine diferit, pentru un scop diferit.
Observaii.
1. Chiar dac este de dorit s putem avea vederi diferite asupra datelor n toate
ordonrile posibile, trebuie avut n vedere c pentru baze de date mari a menine o varietate
foarte mare de indeci poate prejudicia performana aplicaiei, deoarece toi indicii trebuie
actualizai ori de cte ori datele se modific. i n aceast problem programatorul aplicaiei
va trebui s aleag o variant optim de compromis.
2. Se pot ns crea diferite vederi a informaiilor dintr-un tabel i prin sortarea
nregistrrilor sau prin specificarea unei ordini dorite utiliznd clauza ORDER BY a unei
comenzi SQL (Structured Query Language). Chiar dac indecii nu sunt utilizai direct de un

motor SQL, prezena lor mresc viteze procesului de sortare atunci cnd exist o clauz
ORDER BY.
Indexul poate fi un cmp sau o combinaie de cmpuri, iar cmpurile ar putea necesita
valori unice sau nu. Dac un index necesit o valoare unic, el este denumit index unic.
Cele mai obinuite tipuri de indeci sunt cei cu expresii cheie singulare, adic cei
bazai pe valoarea unui singur cmp din tabel. Exemple de astfel de indeci sunt identificatorul
de student (StudId) sau numele studentului (Nume) sau grupa (Grupa) etc. pentru tabela
Studenti. Atunci cnd exist mai multe nregistrri cu aceeai valoare a cheii de indexare, aa
cum ar putea fi cazul cu numele studentului sau cum este sigur cazul cu indexarea dup grup,
nregistrrile multiple sunt prezentate n ordinea fizic n cadrul ordinii impuse de indexul
cheie singular. Figura 1.6 arat cum va arta tabela Studenti (cu ordinea fizic dat n figura
1.2) n urma indexrii dup cmpul Grupa.

Figura 1.6. Tabela Studenti indexat dup cmpul Grupa

Totui, nu de puine ori ar putea fi necesar o ordine mai exact. Acest lucru se poate
face utiliznd expresii cu chei de indexare multiple. Dup cum i numele o spune, indexul
cheie multipl se bazeaz pe valorile din dou sau mai multe cmpuri ale unui tabel. Un
exemplu ar fi s indexm tabelul Studenti dup grup i n cadrul grupei alfabetic dup nume
(i poate chiar la nume identice alfabetic dup prenume). Dac totui exist nregistrri care s
aib aceiai valoare cheie pentru dou sau mai multe nregistrri, acestea vor aprea ca i n
cazul indecilor cu chei singulare n ordinea fizic a nregistrrilor. n figura 1.7 se poate
vedea tabela Studenti indexat cu o cheie multipl dup Grupa, Nume i Prenume.

Figura 1.7. Tabela Studenti cu index cheie multipl dup cmpul Grupa, Nume i Prenume

1.1.5. Utilizarea interogrilor

Atunci cnd normalizai datele, de obicei plasai informaiile nrudite n mai multe
tabele relaionale. La accesarea datelor ns, vei dori s vedei informaiile din toate tabelele
ntr-un singur loc, denumit tabel virtual (view). Aceast tabel practic nu exist ca atare, dar
n baza de date este memorat descrierea ei. Aceast descriere precizeaz c datele view-ului
provin dintr-o poriune a unei tabele, din mai multe tabele ori din mai multe poriuni ale mai
multor tabele. Pentru a reui acest lucru este necesar crearea de seturi de nregistrri, care s
consolideze informaiile legate prin relaii i aflate n dou sau mai multe tabele.
8

Un set de nregistrri se creeaz din mai multe tabele utiliznd o comand SQL care
specific numele cmpurilor dorite, locaia cmpurilor i relaia dintre tabele. Comanda SQL
se poate ns memora ca o interogare (Query) n baza de date. (A se vedea capitolul cu privire
la comenzile SQL).
1.2. Crearea unei baze de date utiliznd Microsoft Access
Microsoft Access are o interfa vizual de proiectare foarte facil, pentru a defini
tabele, indeci, interogri i relaii ntre tabele. Este evident instrumentul cel mai performant
de lucru cu bazele de date, mult superior lui Visual Data Manager, care are nc unele lipsuri
mari (de exemplu pentru operaia simpl de modificare a tipului unui cmp dintr-o structur
existent a unui tabel trebuie recurs la artificii destul de complicate).
Foarte pe scurt va fi prezentat n continuare crearea bazei de date Catalog.mdb i a
uneia din tabelele acesteia, de exemplu tabela Studenti.
Crearea unui fiier nou de tip baz de date se face selectnd File | New | Blank
Database i alegnd apoi folderul i tastnd numele ( Catalog) pentru noul fiier .mdb care
va fi creat. La clic pe butonul Create va apare fereastra, n cazul de fa Catalog : Database,
fereastr ce va conine toate obiectele bazei de date care dup dorin se vor aduga pe
parcurs, ca: tabele (Tables), interogri (Queries), formulare (Forms), rapoarte (Reports) etc.
(vezi figura 1.8).

Figura 1.8. Fereastra Database a bazei de date Catalog.mdb

Acum utilizatorul are posibilitatea s creeze noile tabele ale bazei de date alegnd una
din cele trei variante afiate n fereastra din figura 1.8:
Create table in Design view varianta pe care o vom utiliza efectiv mai jos;
Create table by using the wizard varianta care ne conduce la alegerea unei
structuri de tabel cu ajutorul unui vrjitor, utiliznd modele de structuri tabelare
pentru cele mai diverse aplicaii economice, de afaceri, etc.;
Create table by entering data o variant simplist i cu faciliti reduse de a
defini un tabel prin introducerea liniilor de date n acesta i denumirea coloanelor
cap de tabel, care vor deveni numele cmpurilor respective.
Se recomand n general prima din variantele de mai sus ca fiind cea mai flexibil i
performant modalitate de a defini o tabel.
Alegnd cu un dublu clic de mouse prima din cele trei variante, va apare o fereastr
Table pentru definirea structurii noii tabele, ca cea din figura 1.9, n care se introduc pe rnd
numele cmpurilor, se alege din lista derulant (Data Type) tipul dorit (Text, Memo, Number,
Date/Time etc.) i se d o eventual descriere a cmpului (un comentariu) n rubrica
Description. n partea de jos a ferestrei Table, pagina General vor putea fi setate proprieti
suplimentare cu privire la cmpul respectiv, proprieti care depind de tipul cmpului ales.

Figura 1.9. Fereastra Table pentru definirea structurii unei tabele

Observaii.
1. Pentru datele de tip Text proprietatea FieldSize indic lungimea n numr de
caractere a cmpului.
2. Pentru datele numerice Number, proprietatea FieldSize ofer o list de subtipuri
numerice, ca Long Integer (valoarea implicit), Byte, Integer, Single, Double etc.
din care se poate alege cea care corespunde cel mai bine tipului de date care va fi
stocat n respectivul cmp.
3. Valoarea implicit cu care se iniializeaz un cmp la adugarea unei noi
nregistrri este specificat de proprietatea DefaultValue.
4. Dac proprietatea Required are valoarea Yes, atunci trebuie s se dea o valoare
pentru cmpul respectiv. Cmpul nu poate rmne necompletat n varianta c mai
trziu o valoare va fi oricum precizat.
5. Cmpurile de tip Text i Memo pot avea ca valoare iruri de lungime 0 (vid) dac
proprietatea AllowZeroLength are valoarea Yes.
6. Proprietatea ValidationRule permite precizarea unei condiii de validare a
cmpului respectiv, (de exemplu: >0 n dreptul unui cmp numeric).
7. Dac eventuala regul precizat de proprietatea ValidationRule nu este
ndeplinit, atunci se poate afia un mesaj de eroare precizat prin proprietatea
ValidationText.
8. Cu proprietatea Format se poate specifica un format de afiare a valorii cmpului,
format care poate fi n general ales dintr-o list derulant care este diferit de la
un tip de date la altul.
9. Pentru tipurile de date Text sau Date/Time proprietatea InputMask ofer
posibilitatea de a preciza un ablon de introducere a datelor, ca de exemplu un
anumit ablon pentru introducerea numerelor de telefon (care, avnd de multe ori
zerouri n fa, trebuiesc declarate de tip Text i nu Number!) sau pentru
introducerea datelor calendaristice.
10. Proprietatea Caption precizeaz un ir de caractere care se ataeaz cmpului i
care va aprea ca i cap de coloan n locul numelui acestuia, atunci cnd se va
deschide tabela (cu meniul Open din fereastra Database).
11. Proprietatea Indexed se refer la crearea unui index sau nu pe baza valorilor
cmpului respectiv, i permite alegerea uneia din urmtoarele trei variante:
- No nu se indexeaz dup respectivul cmp;
- Yes (Duplicates OK) se indexeaz dup cmpul respectiv, care poate avea
valori identice n dou sau mai multe nregistrri;
- Yes (No Duplicates) se indexeaz dup cmpul respectiv, nefiind permise
valori identice n dou sau mai multe nregistrri.
Dup definirea structurii tabelei prin completarea cmpurilor n fereastra Table i a
proprietilor acestora, se nchide fereastra Table cu butonul de nchidere. Va apare o fereastr
cu ntrebarea: Do you want to save changes to the design of Table1?, la care desigur c se va
10

rspunde cu Yes pentru a salva structura definit anterior, urmnd a da apoi numele tabelei,
respectiv Studenti. Dac pentru tabela respectiv nu s-a definit nici o cheie primar, va apare
mesajul din figura 1.10:

Figura 1.10. Mesajul cu privire la lipsa definirii unei chei primare

La ntrebarea din mesaj se poate alege Yes, caz n care se va crea un cmp nou cu
numele ID de tip Autonumber (numr cu autoincrementare de la o nregistrare la alta), care va
fi considerat cheie primar, sau No, caz n care se salveaz structura tabelei aa cum era, fr
nici o cheie primar. Dac se alege rspunsul Cancel se revine n fereastra de definire a
structurii Table fr a se efectua nici o salvare.
n cazul c s-a ales unul din rspunsurile Yes sau No, structura tabelei a fost creat i n
fereastra Database a aprut tabela Studenti (vezi figura 1.11).

Figura 1.11. Fereastra Database n care s-a creat tabela Studenti

Dac dup ce s-a salvat tabela sub numele Studenti se constat c s-a greit sau s-a
uitat ceva la definirea structurii tabelei, se selecteaz tabela Studenti din fereastra 1.11 i se
alege din meniul contextual al acesteia Design View (sau se d clic pe butonul
).
Astfel se deschide din nou fereastra Table, n care se pot insera sau terge linii (cu
comenzile Insert Rows sau Delete Rows din meniul contextual atunci se selecteaz o anumit
linie), se pot redenumi cmpuri sau modifica proprietile acestora, se pot aduga proprieti
de indexare, reguli de validare etc. ca i la crearea structurii unei tabele noi, respectiv se poate
alege ca un anumit cmp s devin cheie primar de indexare (selectnd linia cu cmpul
respectiv i dnd un clic pe butonul
Primary Key din bara de unelte standard Microsoft
Access atunci cnd este deschis o tabel n modul Design view). n final, structura tabelei
Studenti n fereastra Design view ar arta ca n figura 1.12.

11

Figura 1.12. Structura tabelei Studenti n modul Design view

Pentru setri suplimentare a indecilor n ceea ce privete ordinea, eventual

descresctoare, de indexare, respectiv setarea unor indeci dup cmpuri multiple, va trebui,
tot din modul Design view, selectat butonul Indexes
. Pe ecran va apare fereastra
Indexes, n care se specific numele indexului, unul sau mai multe cmpuri care intr n
componena respectivului index i ordinea de sortare cresctoare (este implicit) sau
descresctoare. Figura 1.13 arat fereastra Indexes n cazul tabelei Studenti.

Figura 1.13. Fereastra Indexes pentru tabela Studenti

Observai n figura 1.13 c NumPre este numele unui index cmp multiplu, n care
indexarea se va face n primul rnd cresctor dup nume, iar la nume identice dup prenume.
Dup efectuarea tuturor modificrilor se nchide fereastra Table i apare o fereastr cu
mesajul: Do you want to save changes to the design of table Studenti ?, la care, pentru a salva
toate modificrile, se rspunde cu Yes.
Pentru a introduce date n tabelele create se d dublu clic pe tabela dorit din fereastra
Databases (sau se alege opiunea Open din meniul contextual care apare la un clic dreapta de
mouse pe tabele selectat, sau se alege butonul
aprut se introduc datele dorite, ca n figura 1.14.

) a se vedea figura 1.11. n fereastra

Figura 1.14. Datele introduse n tabela Studenti

12

Observaie. n general, datele vor fi introduse prin program i nu n modul prezentat

mai sus. S-a dat i varianta aceasta doar ca exemplu didactic.
n ceea ce privete crearea relaiilor, Microsoft Access ofer o reprezentare vizual
foarte sugestiv a relaiilor dintre tabelele unei baze de date. Aceast reprezentare permite
utilizatorului s trag o linie ntre cmpurile relaionale din tabele sau interogri. Astfel, din
mediul Access dac alegem opiunea Relationships... din meniul Tools sau dm clic pe
icon-ul corespunztor din bara de unelte standard, obinem o fereastr intitulat
Relationships. Cu un simplu clic dreapta oriunde n aceast fereastr putem aduga, prin
intermediul opiunii Show Tables, cte o tabel a bazei de date. Apoi, cu metoda
drag-and-drop se traseaz practic relaiile dintre tabele, unind cmpurile care fac legtura
ntre dou tabele. Butonul de mouse se elibereaz cnd indicatorul mouse-ului va deveni un
mic dreptunghi fixat pe cmpul destinaie. n caseta de dialog Relationships care apare se
cere definirea legturii pe care vrem s o realizm. Tot aici, de obicei, se bifeaz opiunea
Enforce Referential Integrity, care are rolul de a ne mpiedica s facem greeli la
introducerea datelor.
n cazul exemplului discutat mai sus, relaiile sunt reprezentate n Microsoft Access ca
n figura 1.5 de la paragraful 1.1.3.1.
Cmpurile ngroate reprezint chei primare n tabelele respective, iar simbolurile
legturilor (cifra 1 i simbolul ) indic faptul c, spre exemplu, unei singure nregistrri
din tabelul Studenti, i pot corespunde mai multe nregistrri din tabelul Note.
1.3. Modificri asupra unei baze de date
Orict de bine ar fi proiectat i implementat o baz de date, nu e exclus ca la un
moment dat s fie necesar modificarea structurii bazei de date i a tabelelor ei componente
pentru a gestiona i alte date. Modificrile pot nsemna noi tabele sau indeci n cadrul
tabelelor, sau schimbri n proprietile tabelelor, cmpurilor sau indecilor. Cteodat s-ar
putea dori tergerea unei tabele, unor cmpuri sau indeci.

13