Baze de Date - Access - Curs Mocian Ioan

Ioan Mocian
Baze de date
- pentru uzul studenţilor -
- 2008 -
Tehnoredactare computerizată: Ioan Mocian
Tiparul executat la Atelierul de multiplicare al Universităţii Petru Maior
Copyright © Ioan Mocian
Cuvânt înainte
O carte despre bazele de date nu e uşor de scris, cel puţin din două motive: sunt
foarte multe astfel de cărţi şi sunt foarte mulţi cunoscători ai domeniului. Pe de
altă parte sunt şi multe persoane care ar dori să se iniţieze în domeniu, dar cărţile
pe care le-au deschis i-au descurajat, datorită nivelului ridicat de prezentare.
Acestora li se adresează această carte, oameni cu pregătire academică într-un
domeniu conex, dar care au nevoie de cunoştinţe pentru a înţelege bazele de date,
fie pentru cultura generală, fie pentru necesităţi profesionale.
Pentru a înţelege şi utiliza bazele de date nu trebuie să fii informatician, trebuie să

ai dorinţa de a studia şi să ai o carte bună, orientată spre scopul imediat şi uşurată
de balastul greoi al explicaţiilor teoretice de strictă specialitate, care oricum nu
vor fi înţelese de un începător şi nu le va folosi niciodată. În acest spirit a fost
scrisă această carte, pentru oameni care doresc să aplice imediat cunoştinţele
dobândite.
Cartea e structurată pe 5 capitole într-o cronologie logică, de la explicarea

noţiunilor şi conceptelor până la conceperea de aplicaţii în ACCESS.
Capitolul 1 este axat pe prezentarea domeniului bazelor de date relaţionale unde

se folosesc şi la ce sunt folosite acestea.
Capitolul 2 se ocupă cu prezentarea termenilor şi conceptelor folosite în bazele

de dare relaţionale, pentru ca acestea să fie corect înţelese şi folosite.
Capitolul 3 este consacrat iniţierii în proiectarea bazelor de date relaţionale,

având în vedere că mulţi specialişti şi manageri sunt implicaţi în proiectarea de
baze de date şi sisteme informatice fără să aibă un minim de pregătire în domeniu.
Se pleacă de la constatarea că proiectarea bazelor de date nu are legătură cu
implementarea lor (pe care o fac specialiştii în informatică), iar cei care dau, în
ultimă instanţă, specificaţiile sunt chiar utilizatorii finali. De fapt, sunt aceia care
formulează cerinţele şi obiectivele bazei de date, prin intermediul caietului de
sarcini.
Capitolul 4 este dedicat iniţierii în limbajul SQL, un limbaj apropiat de limbajul

uman şi uşor de înţeles. Practica mi-a demonstrat că limbajul SQL este repede
asimilat şi folosit pentru interogarea bazelor de date de către începători.
Exemplele prezentate aici sunt foarte sugestive, bine alese şi pot fi folosite ca
modele pentru situaţii concrete.
Capitolul 5 este dedicat iniţierii în sistemul de gestiune a bazelor de date

ACCESS, folosind cunoştinţele dobândite în capitolele anterioare. Aici se învaţă
crearea tabelelor, formularelor, interogărilor şi rapoartelor.
3
Exemplele prezentate sunt inspirate din situaţii concrete, reale, care sunt bune
modele pentru propriile aplicaţii. Expresiile SQL vor fi acum testate „pe viu”
putându-se verifica imediat corectitudinea lor şi rezultatele obţinute.
Tot aici sunt prezentate modalităţile de transpunere a rapoartelor în format HTML

pentru a fi publicate pe Internet.
Lucrarea se adresează studenţilor facultăţilor de inginerie, dar este utilă şi

persoanelor care au învăţat bazele de date „din mers” şi doresc să-şi verifice şi să-
şi sistematizeze cunoştinţele.
După ce aţi parcurs acest curs, trebuie să dobândiţi capacitatea:

 de a proiecta baze de date simple la început, a căror complexitate
să crească odată cu experienţa acumulată;
 de a implementa aplicaţii de baze de date în ACCESS, la nivelul
firmelor mici şi instituţiilor;
 de a avea o bază de plecare pentru un viitor job într-o echipă
profesionistă de dezvoltare a aplicaţiilor de baze de date.
Dacă această carte a reuşit să vă îmbogăţească bagajul de cunoştinţe

generale, dacă aţi reuşit să înţelegeţi ce este o bază de date şi la ce este
bună, dacă aţi reuşit să creaţi o bază de date ACCESS şi să o folosiţi într-
un scop util, dacă aţi reuşit să publicaţi pe Internet cel puţin un raport din
baza de date pe care aţi creat-o sau din alta, înseamnă că efortul depus
pentru scrierea ei nu a fost zadarnic.
Tg. Mureş, 2008

Autorul
4
Cuprins
Cuvânt înainte ............................................................................................... 3

Capitolul 1. Noţiuni de bază despre bazele de date ................................... 11
Modelul de bază de date relaţională .......................................................... 12
Regăsirea datelor ....................................................................................... 13
Sisteme de gestiune a bazelor de date relaţionale ..................................... 14
Dincolo de modelul relaţional ................................................................... 15
Întrebări pentru autoevaluare .................................................................... 16
Capitolul 2. Terminologia bazelor de date relaţionale ............................. 17
Importanţa terminologiei .......................................................................... 17
Termeni referitori la valoare ..................................................................... 18
Date şi informaţii ................................................................................. 18
Valoare nulă ......................................................................................... 19
Termeni referitori la structură ................................................................... 20
Tabel .................................................................................................... 20
Câmp .................................................................................................... 22
Înregistrare ........................................................................................... 23
Vedere .................................................................................................. 24
Chei ...................................................................................................... 26
Index .................................................................................................... 28
Termeni referitori la relaţie ....................................................................... 29
Relaţii ................................................................................................... 29
Relaţii unu cu unu ................................................................................ 30
Relaţii unu cu mai mulţi ....................................................................... 31
Relaţii mai mulţi cu mai mulţi ............................................................. 32
Tipuri de participare ............................................................................. 34
Gradul de participare ............................................................................ 35
Termeni referitori la integritate ................................................................. 36
Specificaţie de câmp ............................................................................ 36
Integritatea datelor ............................................................................... 36
Întrebări pentru autoevaluare .................................................................... 37
Capitolul 3. Proiectarea bazelor de date relaţionale ................................. 39
5
Etapa 1 – Definirea unei declaraţii de intenţie şi a obiectivelor misiunii .. 40
Compunerea unei declaraţii de intenţie ................................................ 41
Definirea obiectivelor misiunii ............................................................. 42
Întrebări pentru autoevaluare ................................................................ 43
Etapa 2 - Analiza bazei de date curente .................................................... 44
Etapa 3 - Crearea structurilor de date ........................................................ 46
Definirea listei finale de tabele ............................................................. 47
Asocierea câmpurilor fiecărui tabel ...................................................... 50
Utilizarea unui câmp ideal pentru rezolvarea anomaliilor .................... 52
Stabilirea cheilor pentru fiecare tabel ................................................... 53
Revizuirea structurilor iniţiale de tabel ................................................ 57
Specificaţii de câmp ............................................................................. 58
Anatomia unei specificaţii de câmp .................................................. 60
Întrebări pentru autoevaluare ............................................................... 66
Etapa 4 - Determinarea şi instituirea relaţiilor între tabele ...................... 67
Diagrama relaţiilor unu cu unu ............................................................ 67
Diagrama relaţiilor unu cu mai mulţi ................................................... 70
Diagrama relaţiilor mai mulţi cu mai mulţi ......................................... 73
Relaţii cu autoreferire .......................................................................... 77
Identificarea relaţiilor existente ........................................................... 80
Stabilirea caracteristicilor relaţiilor ..................................................... 87
Definirea unei reguli de ştergere ....................................................... 87
Identificarea tipului de participare a fiecărui tabel ........................... 88
Identificarea gradului de participare a fiecărui tabel ........................ 90
Integritatea la nivel de relaţie .............................................................. 92
Etapa 5 - Determinarea şi definirea regulilor de desfăşurare a activităţii 93
Reguli specifice câmpurilor ................................................................. 93
Reguli specifice relaţiilor ..................................................................... 96
Tabele de validare ................................................................................ 97
Etapa 6 - Determinarea şi definirea vederilor .......................................... 98
Etapa 7 - Revizuirea integrităţii datelor ................................................... 102
Revizuirea şi îmbunătăţirea integrităţii datelor ................................... 103
6
Alcătuirea documentaţiei bazei de date ............................................... 105
Studiu de caz. Proiectarea unei baze de date ............................................ 106
Declaraţia de intenţie ........................................................................... 106
Obiectivele misiunii ............................................................................. 106
Analiza bazei de date curente .............................................................. 106
Crearea structurilor de date ................................................................. 107
Determinarea şi instituirea relaţiilor între tabele ................................. 110
Determinarea şi definirea regulilor de desfăşurare a activităţii ........... 111
Determinarea şi definirea vederilor ..................................................... 115
Verificarea integrităţii datelor ............................................................. 118
Concluzii privind proiectarea bazelor de date relaţionale ................... 118
Capitolul 4. Iniţiere în limbajul SQL ......................................................... 120
Prezentare generală ................................................................................... 120
Operaţiuni simple folosind limbajul SQL ................................................. 122
Regăsirea datelor ............................................................................... 122
Sortarea datelor ................................................................................. 123
Filtrarea datelor ................................................................................. 124
Operatorii clauzei WHERE .................................................. 125
Filtrare avansată ................................................................... 126
Operaţiuni avansate folosind limbajul SQL .............................................. 132
Câmpuri calculate ............................................................................. 132
Funcţii pentru manipularea datelor ................................................... 134
Gruparea datelor ............................................................................... 137
Crearea grupurilor ................................................................ 137
Filtrarea grupurilor ............................................................... 139
Lucrul cu subselecţii ......................................................................... 141
Unirea tabelelor ................................................................................ 147
Crearea unei uniri simple ..................................................... 147
Uniri avansate ...................................................................... 138
Compunerea interogărilor ................................................................. 151
Inserarea, actualizarea şi ştergerea datelor ........................................ 155
Inserarea datelor ................................................................... 155
Actualizarea datelor ............................................................. 157
Ştergerea datelor .................................................................. 159
7
Principii privind actualizarea şi ştergerea datelor ................ 160
Crearea şi manipularea tabelelor ....................................................... 162
Elemente performante ale limbajului SQL ................................................ 164
Concluzii ........................................................................................... 167
Capitolul 5. Utilizarea programului ACCESS .......................................... 168
Prezentare generală ................................................................................... 168
Interfaţa programului Access ..................................................................... 170
Crearea tabelelor ....................................................................................... 172
Relaţii între tabele ............................................................................. 174
Crearea relaţiilor cu Lookup Wizard ................................................ 177
Introducerea datelor în tabele ........................................................... 179
Formulare .................................................................................................. 181
Crearea unui formular ....................................................................... 181
Crearea automată a unui formular ......................................... 182
Crearea manuală a unui formular ......................................... 185
Formulare cu subformulare ............................................................... 189
Interogări ................................................................................................... 195
Crearea interogărilor folosind limbajul SQL .................................... 195
Crearea interogărilor cu aplicaţia Wizard(Design view) .................. 196
Legarea permanentă a două tabele .................................................... 200
Interogări cu parametri ...................................................................... 203
Rapoarte .................................................................................................... 206
Crearea unui raport simplu ................................................................ 206
Crearea unui raport cu Report Wizard .............................................. 208
Particularizarea unui raport ............................................................... 214
Macro-uri ................................................................................................... 217
Crearea macrocomenzilor cu o singură acţiune ................................. 218
Crearea macrocomenzilor cu mai multe acţiuni ................................ 220
Rularea macrocomenzilor .................................................................. 221
Rularea unei macrocomenzi din fereastra Database ............ 222
Rularea unei macrocomenzi dintr-un grup ........................... 222
Utilizarea acţiunii RunMacro ............................................... 222
Macrocomenzi ataşate evenimentelor .................................. 223
Utilizarea macrocomenzilor AutoExec şi AutoKeys ........... 223
8
Metodă rapidă de pornire a aplicaţiilor ............................... 224
Publicarea datelor pe Internet ................................................................... 225
Pagini Web statice ............................................................................ 226
Pagini Web dinamice ........................................................................ 228
Crearea unei pagini dinamice de date cu AutoPage .......... 228
Crearea paginilor dinamice cu Page Wizard ....................... 229
Comunicarea între aplicaţiile pachetului Office ....................................... 231
Exportul şi importul de date ............................................................. 232
Recomandări privind crearea aplicaţiilor Access ..................................... 232
Anexe ............................................................................................................. 235
Anexa A. Administratorul de bază de date .......................................... 235
Anexa B. Sintaxa instrucţiunilor SQL ................................................. 237
Bibliografie ..................................................................................................... 239
9
Pagină goală
10
Baze de date Capitolul 1
Noţiuni de bază despre bazele de date
Sintagma “bază de date” este folosită atât în viaţa de zi cu zi, în mijloacele de

comunicare în masă, cât şi de specialiştii din domeniul tehnologiei informaţiei. E
greu să ne gândim la un domeniu de activitate care să nu folosească, într-un fel
sau altul, baze de date. Astfel, când scoatem bani de la bancomat, parola noastră
este verificată cu o bază de date, medicul ne identifică dintr-o bază de date cu
pacienţi, când ne prezentăm la vot suntem identificaţi dintr-o bază de date, iar
exemplele pot continua.
Există mai multe definiţii ale bazelor de date, dar cea mai simplă pentru această
fază de studiu este: baza de date este un set de date stocate într-un mod organizat.
Înţelegerea acestei definiţii va fi uşurată de un exemplu. Astfel, cărţile dintr-o
bibliotecă nu sunt puse la întâmplare, ele sunt aşezate pe rafturi, după o anumită
logică, împărţite pe domenii, pentru ca atunci vrem să ajungem la o carte, ea să
poată fi localizată uşor. Prin urmare, este clar că atunci când căutăm o carte în
biblioteca personală, o găsim mai uşor dacă este ordine şi o găsim greu sau deloc
dacă ne ţinem cărţile în dezordine. Această idee o să fie aplicată în proiectarea
bazelor de date, unde este foarte importantă organizarea corectă a informaţiilor.
Termenul de bază de date este folosit de multe ori în mod eronat, confundându-se
cu softul pentru bază de date care este utilizat. În realitate, softul pentru baze de
date este numit sistem de gestiune a bazelor de date (SGBD), iar baza de date este
recipientul care conţine informaţiile, recipient creat şi manipulat prin intermediul
SGBD. Conţinutul acestui recipient se schimbă foarte des, atunci când se lucrează
cu baza de date (adăugări, ştergeri şi modificări de informaţii).
Baza de date este percepută de multe persoane ca fiind un simplu tabel. Acest
lucru nu este greşit, atâta vreme cât la studiul limbajului Excel am descoperit
tabele la care le spuneam şi baze de date. Într-adevăr, acele tabele erau baze de
date foarte simple care aveau nişte comenzi şi funcţii cu care le putem sorta, filtra
şi chiar făceam unele calcule cu ele. Cu aceste baze de date puteam rezolva multe
probleme de gestionare a unor informaţii.
Bazele de date clasice conţin mai multe tabele care sunt legate între ele prin relaţii
care vor fi studiate mai târziu. Există mai multe modele de baze de date clasice:
Model de bază de date ierarhică
Model de bază de date reţea
11
Model de bază de date relaţională
Primele două modele au numai valoare istorică, se mai folosesc foarte puţin sau
deloc, aşa că nu ne vom opri asupra lor. Modelul relaţional este cel care se
foloseşte astăzi datorită avantajelor pe care îl prezintă şi care va fi studiat în
această carte.
Modelul de bază de date relaţională

Baza de date relaţională a fost concepută în anul 1969 şi este azi cel mai folosit
model de baze de date în gestiunea bazelor de date. Acest model este fundamentat
pe două ramuri ale matematicii – teoria mulţimilor şi logica predicatelor de
ordinul întâi. Într-adevăr, numele modelului provine de la termenul relaţie, care
constituie o parte a teoriei mulţimilor.
O concepţie greşită, larg răspândită, este aceea că modelul relaţional şi-ar fi

preluat numele de la faptul că între tabelele unei baze de date relaţionale există
relaţii.
O bază de date relaţională stochează datele în relaţii, pe care un utilizator le

percepe ca pe nişte tabele. Fiecare relaţie este compusă din înregistrări şi câmpuri,
iar ordinea fizică a înregistrărilor sau a câmpurilor dintr-un tabel este complet
lipsită de importanţă, iar fiecare înregistrare a tabelului este identificată, nu după
locul unde se află, ci după un câmp care conţine o valoare unică. Prin urmare,
utilizatorul nu este obligat să cunoască locaţia fizică a unei înregistrări aşa cum se
întâmplă la celelalte modele de bază de date (ierarhic şi reţea), pentru regăsirea
datelor.
Modelul relaţional clasifică relaţiile ca fiind de tip: unu la unu, unu la mai mulţi şi
mai mulţi la mai mulţi. Aceste relaţii vor fi studiate în detaliu mai târziu. O relaţie
dintre două tabele este stabilită în mod implicit prin intermediul valorilor
echivalente ale unui anumit câmp. În figura 1, tabelele tblStudenti şi
tblSectii sunt corelate prin intermediul câmpului SectiaID; un anumit
student este corelat cu o secţie prin intermediul unui identificator de secţie identic.
Atâta timp cât utilizatorul cunoaşte relaţiile dintre tabelele incluse într-o bază de
date, poate avea acces la date într-un mare număr de moduri. De exemplu, după
cum se vede în figura 1.1, prin intermediul acelei relaţii, putem afla numele secţiei
şi cărei facultăţi aparţine. Dacă tabelul ar conţine mai multe coloane, am avea
acces la toate coloanele, aşa cum vom vedea mai târziu.
12
tblSectii
SectiaID Denumire Facultate
1 TCM Inginerie
2 IEI Inginerie
3 Informatica Stiinte
4 Istorie Stiinte
tblStudenti
StudentID Nume Prenume SectiaID Telefon
1 Pop Ioan 1 234675
2 Ban Lucia 2 234375
3 Pop Dorin 3 234076
4 Lazar Liviu 2 233777
Fig. 1.1. Exemplu de tabele corelate
Regăsirea datelor
Datele stocate într-o bază de date trebuie regăsite rapid ori de câte ori este nevoie
de ele. Datele dintr-o bază de date relaţională se regăsesc prin intermediul unui
limbaj specializat de interogare numit SQL(Structured Query Language). SQL
este limbajul standard folosit pentru crearea, modificarea, întreţinerea şi
interogarea bazelor de date relaţionale. În figura 1.2 este prezentat un exemplu de
interogare SQL pe care o putem utiliza pentru a obţine o listă cu studenţii de la
IEI.
SELECT Nume, Prenume, Telefon

FROM tblStudenti
WHERE SectiaID = ”2”
ORDER BY Nume, Prenume
Fig. 1.2. Exemplu de instrucţiune de interogare SQL
Această instrucţiune s-ar putea traduce astfel: extrage din tabelul tblStudenti
câmpurile Nume, Prenume şi Telefon, înregistrările care au valoarea
câmpului SectiaID egală cu 2, ceea ce corespunde secţiei IEI. Ordonează lista
după câmpul Nume.
13
Cele trei componente fundamentale ale unei interogări SQL le reprezintă
instrucţiunea SELECT…FROM, clauza WHERE şi clauza ORDER BY. Dar
despre toate acestea vom discuta detaliat în capitolul 4.
Sistemele de gestiune a bazelor de date relaţionale
Un sistem de gestiune a bazelor de date relaţionale (SGBDR) este un program

software folosit pentru crearea, întreţinerea, modificarea şi manipularea unei baze
de date relaţionale. Numeroase programe SGBDR furnizează şi instrumentele
necesare pentru a putea crea aplicaţii destinate utilizatorilor finali care lucrează cu
datele din baza de date. Numeroasele facilităţi oferite de diferiţi producători
evoluează foarte rapid, devenind din ce în ce mai performante.
Primele SGBDR-uri au fost concepute pentru sisteme de tip desktop. Acestea

presupun existenţa unei copii a bazei de date pe fiecare calculator care nu este un
mare avantaj, în ceea ce priveşte actualizarea datelor. În acest context a apărut
necesitatea amplasării în mod centralizat a întregii baze de date care să fie
accesată de toţi utilizatorii. Aşa au apărut SGBDR-urile de tip client-server în
care bazele de date se stochează pe un server de baze de date, iar utilizatorii
interacţionează cu datele prin intermediul unor aplicaţii rezidente pe propriul
calculator numit clientul bazei de date.
Creatorul de baze de date foloseşte programul client-server SGBDR pentru a crea

şi întreţine programele de aplicaţie de baze de date şi programele accesorii pentru
utilizatorul final. Acesta implementează integritatea şi securitatea datelor din
serverul de baze de date, având astfel posibilitatea de a fundamenta o diversitate
de aplicaţii utilizator pe acelaşi set de date, fără a afecta integritatea şi securitatea
datelor.
Cele mai cunoscute SGBDR-uri sunt:

 Microsoft Access
 Microsoft SQL Server
 Oracle
 MySQL
 PostgreSQL
Microsoft Access este un SGBDR comercial de tip desktop, folosit pentru

gestionarea bazelor de date de dimensiuni mici şi medii. Poate acoperi fără
probleme segmentul firmelor mici şi mijlocii. Este sistemul de gestiune pe care îl
vom studia şi noi în această carte.
14
Microsoft SQL Server este un SGBDR de tip client-server care acceptă baze de
date foarte mari şi un număr foarte mare de tranzacţii şi rulează numai pe
sistemele de operare Windows. Este soluţia ideală pentru firmele mari, la un preţ
de cost relativ scăzut.
Oracle este liderul mondial al pieţei SGBDR-urilor de tip client-server. Oracle

acceptă baze de date enorme şi un număr imens de tranzacţii. Oracle rulează pe
numeroase sisteme de operare, este un SGBDR complex a cărui operare şi
întreţinere trebuie făcute de un administrator special instruit pentru acest scop. Se
întâlneşte la marile companii transnaţionale, deoarece preţul său este pe măsura
performanţelor.
MySQL este un SGBDR din categoria open-source(codul sursă este pus gratuit la
dispoziţia utilizatorilor) fiind unul din liderii pieţei. MySQL este rapid, stabil şi
acceptă baze de date de mari dimensiuni, dar îi lipsesc câteva din caracteristicile
importante ale limbajului SQL. Versiunile viitoare îşi propun includerea acestor
caracteristici. Rulează pe mai multe sisteme de operare şi este gratuit pentru
utilizarea în scopuri personale(care nu aduc un câştig).
PostgreSQL este un SGBDR din categoria open-source, fiind unul din liderii
pieţei. Acceptă baze de date de mari dimensiuni, este recunoscut pentru setul său
bogat de caracteristici.
Dincolo de modelul relaţional
Programele SGBDR au fost acceptate pe scară largă fiind utilizate în aplicaţii de

afaceri concrete, precum inventarele, gestiunea pacienţilor, a materialelor şi
pieselor, în domeniul bancar, dar s-au dovedit a lipsi în aplicaţii de genul
proiectării asistate de calculator (CAD), sisteme informaţionale geografice (GIS)
şi sisteme de stocare multimedia. Ca răspuns la această problemă au apărut două
noi modele de bază de date: modelul orientat spre obiect şi modelul relaţional
obiect.
Modelul orientat spre obiect încorporează toate caracteristicile unui limbaj de

programare orientat spre obiect, iar baza de date relaţională este retrogradată la
statutul de magazie de date. Ideea fundamentală este că dezvoltatorul bazei de
date tratează fiecare aspect al acesteia, inclusiv setul de operaţiuni care
manipulează datele din baza de date, din interiorul limbajului de programare a
bazei de date orientată obiect. Nu mai există o diferenţă clară între programul de
bază de date şi programul de realizare a aplicaţiilor.
Deşi este un pas înainte, modelul orientat spre obiect nu întruneşte consensul
tuturor specialiştilor din domeniu. Viitorul va da însă verdictul în această
problemă delicată.
15
Modelul relaţional obiect a extins modelul bazei de date relaţionale prin
încorporarea a diferite elemente şi caracteristici orientate spre obiect, precum
clase, încapsulare şi moştenire. Ideea era ca aceste extensii să permită unei baze
de date relaţionale să gestioneze şi să manipuleze tipuri de date complexe, precum
secvenţe audio sau video şi desene sau reprezentări grafice.
Modelul relaţional obiect încă nu a fost definitivat, se mai lucrează la el,

majoritatea specialiştilor consideră că aceasta este direcţia corectă. El este
exploatat şi rafinat în continuare.
Internetul exercită o mare influenţă asupra modului de utilizare a bazelor de date

în cadrul organizaţiilor. Multe companii şi afaceri folosesc Web-ul pentru a-şi
extinde baza de consumatori, iar o bună parte din datele oferite acestor
consumatori, respectiv pe care le preiau de la aceştia, sunt stocate într-o bază de
date. Internetul a generat un limbaj numit XML (eXtensible Markup Language)
capabil să partajeze date din diferite sisteme eterogene. Mulţi producători de
SGBDR se orientează spre încorporarea a cât mai multe caracteristici XML în
propriile produse.
Cu toate noile orientări prezentate, bazele de date relaţionale pe care le vom studia
nu vor dispare în viitorul apropiat.
Întrebări pentru autoevaluare
De unde vine termenul de bază de date relaţională?

Cum se stochează datele într-o bază de date relaţională?
Denumiţi cele trei tipuri de relaţii existente într-o bază de date relaţională.
Indicaţi câteva avantaje ale bazelor de date relaţionale.
Ce este un sistem de gestiune a bazelor de date relaţionale?
Care sunt cele mai cunoscute sisteme de gestiune a bazelor de date
relaţionale?
16
Capitolul 2. Terminologia bazelor de date relaţionale
În acest capitol vom clarifica termenii folosiţi în teoria şi practica bazelor de date
relaţionale, pentru a evita confuziile făcute de unii membri implicaţi în procesul
de proiectare sau exploatare.
Importanţa terminologiei
Este important să înţelegem termenii prezentaţi în acest capitol înainte de a
începe studiul bazelor de date relaţionale. Proiectarea bazelor de date are
un set de termeni specifici ca, de altfel, orice profesie, meserie sau
disciplină.
Iată câteva motive care justifică importanţa învăţării acestor termeni:

 Termenii respectivi sunt utilizaţi pentru a exprima şi defini ideile şi
conceptele speciale ale modelului de baze de date relaţionale. O bună
parte din terminologie derivă din ramurile matematice ale teoriei
mulţimilor şi respectiv logicii predicatelor de ordinul întâi.
 Termenii respectivi sunt utilizaţi pentru a exprima şi defini însuşi
procesul de proiectare a bazelor de date. Procesul de proiectare devine
mai clar şi mult mai simplu de înţeles, după ce v-aţi familiarzat cu aceşti
termeni.
 Termenii respectivi sunt utilizaţi oriunde se discută despre o bază de date
relaţională sau despre un program SGBDR. Veţi întâlni aceşti termeni în
publicaţii cum ar fi reviste de comerţ, manuale de programare SGBDR,
suporturi de cursuri etc. De asemenea, veţi auzi aceşti termeni în
conversaţiile între diferite categorii de profesionişti din domeniul bazelor
de date.
Există patru categorii de termeni de care o să ne ocupăm în acest capitol,

termeni referitori la: valoare, structură, relaţie şi integritate.
17
Termeni referitori la valoare
Date şi informaţii
Valorile pe care le stocăm în bazele de date se numesc date. Acestea sunt

statice în sensul că rămân aceleaşi până nu intervine o modificare manuală
sau automată. În figura 2.1 este prezentat un exemplu de date.
George Fodor 6582421 12/05/2004

57.50
Fig. 2.1. Exemplu de date elementare
La prima vedere, aceste date sunt lipsite de sens pentru că nu ne putem da

seama ce reprezintă numărul 6582421 sau celelalte, chiar dacă observăm că
una din valori este o dată calendaristică iar ultima este un număr zecimal.
Nu ne putem da seama până nu prelucrăm datele.
Informaţiile reprezintă date pe care le prelucrăm într-un mod care le

conferă semnificaţie şi utilitate pentru noi atunci când lucrăm cu
respectivele date.George Fodorsunt
Informaţiile 6582421 12/05/2004
dinamice, în sensul că se modifică în
57.50
permanenţă după cum se modifică datele din baza de date, dar şi în sensul
că pot fi prelucrate într-un număr nelimitat de moduri. Ideea care trebuie
reţinută este că trebuie să prelucrăm datele pentru a le putea transforma în
informaţii cu sens.
Figura 2.2 demonstrează un mod în care datele din exemplul precedent pot
fi prelucrate şi transformate în iformaţii. Datele respective au fost
manipulate încât au ajuns într-o factură pentru un pacient – încât acum au
sens pentru oricine le citeşte.
George Fodor 6582421 12/05/2004
57.50
Spitalul Municipal Tg. Mures Pacient: George Fodor
Str. Clinicilor nr.66 Cod pacient: 6582421
Sectia Cardiologie Data consultaţiei: 12/05/2004
Medic: dr. Hipocrate B.
Consultaţii Analize
General 30.00 Sânge
x
EKG 27.50 Urina
x
Ultrasunete Glicemie
Total plată: 57.50
George Fodor 6582421 12/05/2004
57.50 Total plată:
Fig. 2.2. Exemplu de date transformate în informaţii
57.50
18
Total plată:
57.50
Este foarte important să înţelem diferenţa dintre date şi informaţii. O bază
de date este proiectată astfel încât să furnizeze informaţii semnificative
pentru orice persoană abilitată din cadrul unei firme sau organizaţii. Aceste
informaţii pot fi puse la dispoziţie numai dacă datele corespunzătore există
în baza de date şi dacă aceasta din urmă este astfel structurată încât să
permită obţinerea informaţiilor respective.
Dacă uitaţi vreodată care este diferenţa dintre date şi informaţii, reţineţi
următoarea axiomă:
Datele se stochează, iar informaţiile se regăsesc.
Din păcate, există cărţi comerciale în care se confundă datele cu

informaţiile.
Valoare nulă
O valoare nulă reprezintă o valoare care lipseşte sau care nu este

cunoscută. Deseori, valoarea nulă se confundă cu un zero sau unul sau mai
multe spaţii albe, ceea ce este total greşit, din următoarele motive:
Un zero poate avea mai multe semnificaţii cum ar fi nivelul stocului unui
anumit produs, numărul de apariţii a unui cod etc.
Deşi un şir text format din unul sau mai multe spaţii albe nu înseamnă
nimic pentru cei mai mulţi dintre noi, reprezintă categoric semnificaţie
pentru un limbaj de interogare cum ar fi SQL. Un spaţiu alb este un
caracter ca oricare altul cum ar fi “a”.
Un şir de lungime zero – adică două ghilimele consecutive fără spaţiu între
ele “”, este de asemenea o valoare acceptabilă pentru limbaje precum SQL
şi poate fi semnificativă în anumite circumstanţe.
De menţionat faptul că în practică, apar multe cazuri când la completarea

unui câmp al unui tabel este împiedicată de necunoaşterea, pe moment, a
valorii respective şi în acest caz va apare o valoare nulă. Acest câmp poate
fi completat ulterior, după ce se află valoarea respectivă (ex., un număr de
telefon, un cod etc.).
Principalul dezavantaj al valorilor nule este acela că pot avea efect negativ
asupra calculelor matematice, ştiut fiind că rezultatul unei operaţii
matematice în care este implicată o valoare nulă, este o valoare nulă.
Problema valorilor absente, necunoscute, precum şi faptul că vor fi folosite
19
sau nu în expresii matematice sau funcţii agregat, vor fi luate în
considerare în decursul procesului de proiectare a bazelor de date
relaţionale.
Termeni referitori la structură
Tabel
În conformitate cu modelul relaţional, datele dintr-o bază de date

relaţională sunt stocate în relaţii, care sunt percepute de utilizator sub
formă de tabele. Fiecare relaţie este alcătuită din înregistrări (tupluri) şi
câmpuri (atribute). În figura 2.3 este prezentată o structură de tabel
caracteristică.
StudentID Nume Prenume Sectia <<alte câmpuri>>

5001 Pop Mariana TCM
5002 Ban Ioan TCM
5012 Lazăr Ana IEI Înregistrări
5065 Ban Lucia IMPI
5032 Pop Dorin MEC
Câmpuri
Fig. 2.3. O structură de tabel
Tabelele reprezintă structurile esenţiale dintr-o bază de date, iar fiecare

tabel reprezintă întotdeauna un singur subiect concret, cum ar fi studenţi,
produse, vânzări etc. Ordinea logică a înregistrărilor şi a câmpurilor din
cadrul unui tabel nu are nici o importanţă, iar fiecare tabel conţine cel puţin
un câmp – cunoscut sub numele de cheie primară – care identifică în mod
unic fiecare înregistrare a tabelului. În figura 2.3, StudentID este cheia
primară a tabelului tblStudenti.
Datele dintr-o bază de date relaţională pot exista independent de modul în

care sunt stocate fizic în calculator, datorită acestor ultime două
caracteristici ale unui tabel. Pentru utilizator acest lucru este foarte bun,
deoarece acesta nu mai trebuie să cunoască locaţia fizică a unei înregistrări
pentru a putea regăsi datele.
20
Subiectul pe care îl reprezintă un tabel dat poate fi un obiect sau un
eveniment. Când subiectul este un obiect, tabelul reprezintă o cantitate
palpabilă, precum o persoană, un produs sau un lucru oarecare. Indiferent
de tipul său, un obiect are caracteristici care pot fi stocate sub formă de
date, care vor putea fi prelucrate ulterior într-un număr mare de moduri.
Când subiectul unui tabel este un eveniment, înseamnă că tabelul

reprezintă ceva care se produce la un anumit moment de timp şi care are
caracteristici pe care doriţi să le înregistraţi. Exemplul clasic care se poate
da aici este tabelul cu consultaţiile ţinute de un medic de familie. În figura
2.4 este prezentat un astfel de tabel.
PacientID Data cons. Ora cons. Medic Tensiune <<alte câmpuri>>

92001 12-1-2005 8:30 Avram I. 120/80
97004 12-1-2005 9:00 Avram I. 125/80
98023 12-1-2005 9:30 Popescu D. 130/82
93034 12-1-2005 10:30 Popescu D. 145/90
94001 12-1-2005 11:45 Avram I. 132/86
Fig. 2.4. Tabel care reprezintă un eveniment
Tabelele pot fi, într-o altă clasificare, de două tipuri:

Tabele de date care furnizează date folosite pentru furnizarea de informaţii
şi reprezintă tipul de tabel cel mai frecvent întâlnit într-o bază de date.
Datele din acest tip de tabel sunt dinamice deoarece se pot manipula
(modificare, ştergere) şi converti în informaţii într-o anumită formă sau
manieră. Cu astfel de tabele veţi lucra foarte frecvent în decursul lucrului
cu baza de date.
Tabele de validare care stochează date pe care le veţi folosi cu scopul
precis de a implementa integritatea datelor. De obicei, un tabel de validare
conţine nume de localităţi, coduri de produse, categorii de activităţi etc.
Datele din acest tip de tabel sunt statice, adică se modifică foarte rar.
În figura 2.5 este prezentat un tabel de validare pentru secţiile facultăţii de

inginerie.
SectieID Denumire
11 TCM
13 IEI
Fig. 2.5. Tabel de validare
12 Mecatronica
15 Ingineria mediului
19 Design
21
În loc să introducem greşit într-un alt tabel, numele unei secţii, vom
introduce codul său, asigurând în acest fel integritatea datelor.
Câmp
Un câmp reprezintă cea mai mică structură din baza de date şi reprezintă o
caracteristică a subiectului tabelului căruia îi aparţine. Câmpurile sunt
structurile care stochează efectiv datele, care apoi pot fi regăsite şi
prezentate ca informaţii în aproape orice configuraţie pe care o puteţi
imagina.
Calitatea informaţiilor pe care o veţi obţine din datele pe care le aveţi este
direct proporţională cu timpul dedicat asigurării integrităţii structurale şi de
date a câmpurilor înseşi.
Fiecare câmp dintr-o bază de date corect proiectată conţine singură

valoare, iar numele său va identifica tipul de valoare admis. Astfel,
procesul de introducere a datelor devine foarte intuitiv. Dacă vedeţi
câmpuri cu nume precum Nume, Prenume, Judet, Localitate, Telefon sau
Cod postal, atunci veţi şti exact ce tipuri de date veţi introduce în fiecare
câmp. De asemenea, va fi foarte simplu să sortaţi datele în funcţie de judeţ
ori să căutaţi persoanele dintr-o anumită localitate a unui judeţ.
Într-o bază de date slab proiectată sau proiectată inadecvat, veţi întâlni în
mod caracteristic alte trei tipuri de câmpuri, după cum urmează:
Un câmp multiplu (numit şi câmp cu mai multe părţi) care conţine două sau
mai multe elemente distincte în cadrul valorii acestuia.
Un câmp cu valori multiple (numit şi câmp cu mai multe valori) care
conţine mai multe apariţii ale aceluiaşi tip de valoare.
Un câmp calculat, care conţine o valoare de text concatenat sau rezultatul
unei expresii matematice.
În figura 2.6 este prezentat un tabel care conţine câte un câmp din fiecare
tip amintit mai sus.
22
Valori multiple
Câmp calculat Câmp multiplu
ProdusID Denumire Furnizor Pret Cant Valoare Loc, Judet Agent

5001 Planetara SC Lion 900 5 4500 Dej, Cluj Pop, Rusu
6023 Rulment SC RPA 23 10 230 Brasov,Bra Danciu
sov
6034 Acumulat SC 500 4 2000 Bistrita, Danciu
or Rulment Bistrita
ul
5098 Bujie SC ARC 12 100 1200 Cluj,Cluj Danciu, Pop
5067 Antigel SC Lion 10 40 400 Dej, Cluj Pop, Rusu
Fig. 2.6. Tabel cu câmpuri normale, calculate, multiple
Înregistrare
O înregistrare reprezintă o instanţă unică a subiectului unui tabel.

Înregistrarea este alcătuită din întregul set de câmpuri dintr-un tabel,
indiferent dacă respectivele câmpuri conţin sau nu valori. Datorită
modalităţii de definire a unui tabel, fiecare înregistrare este definită în baza
de date prin intermediul unei valori unice a câmpului cheie primară a
înregistrării respective. Astfel, dacă avem un tabel de persoane, o
înregistrare din tabel trebuie să identifice fiecare persoană din tabel, care
este un unicat.
În figura 2.6, fiecare înregistrare reprezintă un produs unic din cadrul

tabelului, iar câmpul ProdusID este folosit pentru a identifica un produs
din cadrul bazei de date. La rândul său, fiecare înregistrare include toate
câmpurile din tabel, iar fiecare câmp descrie un aspect al produsului
reprezentat de înregistrare.
Înregistrările reprezintă un element cheie pentru înţelegerea relaţiilor dintre

tabele, deoarece va trebui să cunoaşteţi relaţia dintre o înregistrare a unui
tabel şi alte înregistrări din alt tabel.
23
Vedere
O vedere este un tabel “virtual” compus din câmpuri dintr-unul sau mai
multe tabele ale bazei de date; tabelele care alcătuiesc vederea sunt
cunoscute sub numele de tabele de bază. Modelul relaţional îi atribuie unei
vederi atributul de virtuală deoarece îşi preia datele din tabele de bază, nu-
şi stochează propriile sale date. De fapt, singurele informaţii referitoare la o
vedere care sunt stocate în baza de date se referă la structura vederii
respective. Numeroase programe SGBDR principale lucrează cu vederi,
dar unele (precum Microsoft Access) le denumesc interogări salvate.
Programul SGBDR pe care îl utilizaţi va determina dacă obiectul respectiv
va fi denumit interogare sau vedere.
Vederile permit privirea informaţiilor din baza dumneavoastră de date din

diferite unghiuri, furnizând o mare flexibilitate în lucrul cu datele. Puteţi
crea vederi într-o varietate de moduri, iar o vedere este utilă mai ales când
se bazează pe mai multe tabele corelate. Într-o bază de date cu orare
şcolare, de exemplu, puteţi crea o vedere care sintetizează date din tabelele
ELEVI, CURSURI şi ORARE CURSURI.
În figura 2.7 este prezentată o vedere cu situaţia împrumuturilor de cărţi,

ale cărei date au fost extrase din trei tabele: Studenti, Imprumuturi, Carti.
24
Studenti
StudentID Nume Prenume Telefon <<alte câmpuri>>
60001 Crişan Ovidiu 0745-328092 …..
60002 Lazăr Denisa 0722-7575823 …..
60003 Mocean Gabriel 0744-7575939 …..
60004 Mocean Olimpiu 0723-6564321 …..
Imprumuturi
StudentID CarteID Data
60001 1001 3/10/2004
60002 1001 3/10/2004
60003 1099 5/10/2004
60004 1099 5/11/2004
Carti
CarteID Denumire Categorie <<alte câmpuri>>
1001 PUC P1 ......
1099 Baze de date P1 ......
1023 Fizica F1 .....
1009 Chimie F1 …..
Situatie împrumuturi (vedere)

Nume Prenume Denumire Data
Crişan Ovidiu PUC 3/10/2004
Lazăr Denisa PUC 3/10/2004
Mocean Gabriel Baze de date 5/10/2004
Mocean Olimpiu Baze de date 5/11/2004
Fig. 2.7. Un exemplu de vedere caracteristică
Există trei motive majore care conferă importanţă vederilor:

Vederile permit lucrul simultan cu date preluate din mai multe tabele, între
care există relaţii.
Vederile permit împiedicarea anumitor utilizatori de a vedea sau manipula
anumite câmpuri dintr-un tabel sau grup de tabele. Această posibilitate se
poate dovedi foarte avantajoasă din punctul de vedere al securităţii datelor.
25
Vederile se pot utiliza pentru implementarea integrităţii datelor, numite în
acest caz vederi de validare.
Chei
Cheile sunt acele câmpuri speciale care îndeplinesc roluri foarte bine
determinate în cadrul unui tabel, iar tipul cheii defineşte rolul acesteia în
interiorul tabelului. Un tabel poate conţine numeroase tipuri de chei, dar
cele mai importante sunt cheia primară şi cheia externă.
O cheie primară este un câmp sau un grup de câmpuri care identifică în

mod unic fiecare înregistrare din cadrul unui tabel; dacă o cheie primară
este compusă din două sau mai multe câmpuri, este cunoscută sub numele
de cheie primară compozită. O valoare a unei primare identifică o anumită
înregistrare din întreaga bază de date. Cheia primară impune integritatea la
nivel de tabel şi facilitează stabilirea relaţiilor cu alte tabele din baza de
date.
Reţineţi faptul că o cheie primară are valori unice în cadrul unui, aceasta
fiind cea mai importantă proprietate a acesteia. De regulă, cheile primare
vor fi nişte coduri numerice, uneori generate chiar de sistemul de gestiune
a bazei de date, cum ar fi sistemul Access, pe care o să-l studiem în cadrul
acestui curs şi care tipul de dată AutoNumber, special gândit pentru
generarea cheilor primare.
O cheie externă dintr-un tabel este acea cheie care este cheie primară în alt
tabel. Ea nu trebuie să fie unică după cum veţi observa în următorul
exemplu, rolul ei este, în special, de a asigura legătura cu alt tabel. În
figura 2.8 se pot vedea o cheie primară şi o cheie externă.
26
Impresari
Cheie primară ImpresarID Nume Prenume Telefon
100 Becali Ioan 0745-655482
101 Popescu Gică 0745-658312
Cheie primară 102 Becali Victor 0744-547212
Sportivi
SportivID ImpresarID Nume sportiv Telefon <<alte câmpuri>>
8001 100 Mutu Adrian 0745-657329
8002 101 Neaga Ioan 0744-768432
8003 100 Chivu Cristian 0723-546291
Cheie externă
Fig. 2.8. Exemplu de câmpuri cheie primară şi cheie externă
Se observă cum câmpul ImpresarID este cheie primară pentru tabelul

Impresari şi cheie externă pentru tabelul Sportivi. Acolo unde este cheie
externă, valoarea ei se poate repeta, ceea ce este firesc, deoarece un
impresar poate avea mai mulţi sportivi. Câmpul ImpresarID din cele două
tabele asigură legătura dintre ele, asigurând în acelaşi timp şi integritatea
datelor, adică fiecare sportiv are un impresar valabil.
Când determinaţi că între două tabele există o relaţie, în mod caracteristic

stabiliţi relaţia respectivă preluând o copie a cheii primare din primul tabel
şi încorporând-o în structura celui de-al doilea tabel, unde devine cheie
externă. Numele de „cheie externă” derivă din faptul că al doilea tabel are
deja o cheie primară proprie, iar cheia primară pe care o introduceţi din
primul tabel este „externă” pentru al doilea tabel.
Dincolo de facilitatea stabilirii relaţiilor dintre perechi de tabele, cheile

externe contribuie şi la implementarea şi asigurarea integrităţii la nivel de
relaţie. Aceasta înseamnă că înregistrările din ambele tabele vor fi
întotdeauna corelate în mod adecvat, deoarece valorile unei chei externe
trebuie să fie identice cu valorile existente ale cheii primare la care face
referire. O greşeală frecventă care se face de către începători, este că dau
tipuri de dată diferite unor câmpuri pe care doresc să le folosească pentru
legătura a două tabele.
De asemenea, integritatea la nivel de relaţie permite evitarea periculoaselor

înregistrări „orfane”, un exemplu clasic în acest sens reprezentându-l
27
înregistrarea unei comenzi fără un client asociat. Dacă nu ştiţi cine a emis
comanda, nu o puteţi prelucra şi, evident, nu o puteţi factura, iar asta o să
vă ducă de râpă vânzările trimestriale.
Câmpurile cheie joacă un rol important într-o bază de date relaţională, iar
dumneavoastră trebuie să învăţaţi să le creaţi şi să le utilizaţi.
Index
Un index este o structură pe care un program SGBDR o pune la dispoziţie pentru

îmbunătăţirea procesului de prelucrare a datelor. Un index nu are nici o legătură
cu structura logică a bazei de date. Unicul motiv pentru care discutăm despre
termenul index în acest capitol este faptul că oamenii îl confundă deseori cu
termenul cheie.
Index şi cheie reprezintă o altă pereche de termeni folosiţi eronat în mod frecvent
şi pe scară largă în industria bazelor de date. (Mai ţineţi minte deosebirile dintre
date şi informaţii?). Veţi sesiza întotdeauna diferenţa dintre cei doi termeni dacă
reţineţi că, în timp ce cheile sunt structuri logice pe care la identificarea
înregistrărilor dintr-un tabel, indecşii reprezintă structuri fizice utilizate la
optimizarea procesului de prelucrare a datelor.
Prin folosirea indecşilor, sortările şi filtrările unei baze de date se face într-un
timp mult mai scurt.
28
Termeni referitori la relaţie
Relaţii
Între două tabele există o relaţie atunci când înregistrările din primul tabel
pot fi asociate cu înregistrările din al doilea tabel. Relaţia se poate stabili
prin intermediul unui set de chei primare şi chei externe sau cu ajutorul
unui al treilea tabel, numit tabel de legătură (cunoscut şi sub numele de
tabel asociativ).
Figura 2.8 ilustrează o relaţie stabilită prin intermediul cheilor primare şi al

cheilor externe, iar figura 2.9 exemplifică o relaţie stabilită cu ajutorul unui
tabel de legătură.
Studenti
StudID Nume Prenume OrasStudent <<alte câmpuri>>
6001 Pop Remus Reghin ........
6002 Szabo Zoltan Oradea ........
6003 Costea Florian Zalau ........
6004 Timocea Sebastian Brasov ........
6004 Mocean Vasile Fagaras ........
Orar student(table de legătură) Cursuri

CursID Denumire Credite ProfesorID
StudID CursID C001 PUC 5 25461
6001 C001 C213 Baze de date 5 25461
6002 C213 C032 SIM 4 56821
6002 C001 C015 GD 5 12843
6001 C213 G001 AutoCAD 4 32584
6002 C015 G004 Inventor 5 3212
6003 C001 G007 Intellicad 4 25461
6003 C213
6001 C015
6003 G001
6001 G001
Fig.2.9. O relaţie stabilită între două tabele prin intermediul

unui tabel de legătură
29
O relaţie este o componentă importantă a unei baze de date relaţionale. O
relaţie permite crearea de vederi din tabele multiple şi este crucială pentru
integritatea datelor, întrucât contribuie la cantităţii de date redundante şi la
eliminarea datelor duplicate. Puteţi caracteriza o relaţie în trei moduri: în
funcţie de tipul relaţiei dintre tabele, de maniera în care fiecare tabel
participă la relaţie şi de gradul de participare al fiecărui tabel.
Relaţii „unu cu unu”
Două tabele au o relaţie unu cu unu când o singură înregistrare din primul
tabel este corelată cu o singură înregistrare din al doilea tabel şi o singură
înregistrare din al doilea tabel este corelată cu o singură înregistrare din
primul tabel. În figura 2.10 este reprezentată o astfel de relaţie.
Într-o asemenea relaţie, un tabel serveşte ca “tabel părinte”, iar celălalt

îndeplineşte rolul de “tabel copil”. Relaţia se stabileşte prin preluarea unei
cópii a cheii primare a tabelului părinte şi încorporarea acesteia în structura
tabelului copil, unde devine o cheie externă. Acesta este un tip special de
relaţie, deoarece este unicul în cadrul căruia ambele tabele pot folosi
efectiv aceeaşi cheie primară.
În figura 2.10 este prezentat un exemplu clasic de relaţie unu la unu. În

acest caz SALARIAŢI este tabelul părinte, iar SALARIU este tabelul
copil. Se observă că fiecare salariat din primul tabel are un singur
corespondent din al doilea tabel.
Salariaţi
SalariatID Nume Prenume Telefon <<alte câmpuri>>
100 Ban Ioan 0745-646321 …..
101 Pop Dorin 0723-548211 …..
102 Lazăr Liviu 0264-542138 …..
103 Crişan Ovidiu 0740-764282 …..
Salariu
SalariatID Salar orar Sporuri <<alte câmpuri>>
100 34.50 10% …..
101 23.00 5% …..
102 17.45 20% …..
103 16.00 18% …..
30
Fig. 2.10. Exemplu de relaţie „unu la unu”
Relaţia unu la unu poate fi imaginată ca o “rupere” în două a tabelului.

Deşi câmpurile din aceste tabele pot fi combinate într-un singur tabel,
proiectantul bazei de date a ales să plaseze în tabelul SALARIAŢI
câmpurile ce pot fi văzute de orice membru al organizaţiei şi în tabelul
SALARIU câmpurile ce pot fi văzute doar de personalul autorizat, ştiut
fiind că salariile sunt, de obicei, confidenţiale.
Relaţii „unu cu mai mulţi”
Între două tabele există o relaţie unu cu mai mulţi când o înregistrare din
primul tabel poate fi corelată cu una sau mai multe înregistrări din al doilea
tabel, în timp ce o înregistrare din al doilea tabel poate fi corelată cu o
singură înregistrare din primul tabel. Să studiem un exemplu generic
pentru acest tip de relaţie.
Modelul părinte/copil pe care l-am utilizat pentru a descrie o relaţie „unu

cu unu” se aplică şi în acest caz, partea unu a relaţiei este tabelul părinte,
iar tabelul din partea mai mulţi este tabelul copil. O relaţie de tipul unu cu
mai mulţi se stabileşte prin preluarea unei cópii a cheii primare a tabelului
părinte şi încorporarea acesteia în structura tabelului copil, unde devine o
cheie externă.
Exemplul din figura 2.11 ilustrează o relaţie de tip unu cu mai mulţi
caracteristică.
Clienti
ClientID Nume Prenume <alte câmp.> Imprumuturi
9001 Pop Dorin ....... ClientID CarteID Data
9002 Ban Ion ....... 9002 5648 ....
9003 Lazăr Ana ....... 9001 690423 ....
9004 Buzan Maria ....... 9004 6563 ....
9005 Beldean Vian ....... 9003 65323 ....
9003 09542 ....
9003 64823 ....
9002 75001 ....
9005 10045 ....
9005 76100 ....
Fig. 2.11. Exemplu de relaţie „unu cu mai mulţi”
31
O singură înregistrare din tabelul CLIENTI poate fi corelată cu una sau
mai multe înregistrări din tabelul IMPRUMUTURI, dar o înregistrare din
tabelul IMPRUMUTURI este corelată cu o singură înregistrare din tabelul
CLIENTI. După cum probabil aţi dedus, câmpul ClientID este o cheie
externă în tabelul IMPRUMUTURI.
Relaţia unu cu mai mulţi este cea mai obişnuită relaţie care există între
două tabele dintr-o bază de date şi este cea mai uşor de identificat. Relaţia
este extrem de importantă din punct de vedere al integrităţii datelor,
deoarece ea vă ajută să eliminaţi datele duplicate.
Relaţii de tip ”mai mulţi cu mai mulţi”
Între două tabele există o relaţie de mai mulţi cu mai mulţi când o
înregistrare din primul tabel poate fi corelată cu una sau mai multe
înregistrări din al doilea tabel şi o înregistrare din al doilea tabel poate fi
corelată cu una sau mai multe înregistrări din primul tabel. O relaţie din
această categorie se stabileşte cu ajutorul unui tabel de legătură. Un tabel
de legătură facilitează asocierea înregistrărilor dintr-un tabel cu
înregistrările din celălalt tabel şi asigură lipsa oricăror probleme la
operaţiile de adăugare, ştergere sau modificare a datelor corelate.
Un tabel de legătură se defineşte prin preluarea unor cópii ale cheii primare
din fiecare tabel şi utilizarea lor pentru a forma structura noului tabel. În
realitate, aceste câmpuri îndeplinesc două roluri distincte: împreună
formează cheia primară compozită a tabelului de legătură, iar separat,
fiecare poate fi asimilată unei chei externe.
O relaţie de tip mai mulţi cu mai mulţi care nu este stabilită în mod
corespunzător se numeşte „nerezolvată”. Figura 2.12 prezintă un exemplu
clasic şi clar de relaţie de tip mai mulţi cu mai mulţi nerezolvată. În acest
exemplu, o înregistrare din tabelul STUDENTI poate fi corelată cu mai
multe înregistrări din tabelul CURSURI, în timp ce o singură înregistrare
din tabelul CURSURI poate fi corelată cu mai multe înregistrări din tabelul
STUDENTI.
32
Studenti
6001 Pop Remus Reghin ........
Cursuri
CursID Denumire Credite ProfesorID Sala <<alte câmpuri>>
C001 PUC 5 25461 208 ........
C213 Baze de date 5 25461 208 ........
C032 SIM 4 56821 209 ........
C015 GD 5 12843 207 ........
G001 AutoCAD 4 32584 207 ........
G004 Inventor 5 3212 208 ........
G007 Intellicad 4 25461 208 ........
Fig. 2.12. Un exemplu tipic de relaţie „mai mulţi cu mai mulţi”

nerezolvată
Această relaţie este nerezolvată datorită particularităţii intrinseci a relaţiei

de tip mai mulţi cu mai mulţi. Principala problemă este următoarea: cum se
pot asocia cu uşurinţă înregistrări din primul tabel cu înregistrările din al
doilea tabel? Pentru a reformula întrebarea folosind tabelele din figura
2.12, cum se asociază un student cu mai multe cursuri sau un anumit curs
cu mai mulţi studenţi? Se inserează câteva câmpuri Student în tabelul
CURSURI sau mai multe câmpuri Curs în tabelul STUDENTI? Oricare
din aceste metode va îngreuna lucrul cu datele şi va afecta în mod negativ
integritatea datelor. Cea mai bună metodă constă în din crearea şi utilizarea
unui tabel de legătură, care va rezolva relaţia de tip mai mulţi cu mai mulţi
în maniera cea mai adecvată şi mai eficientă. Figura 2.13 prezintă
implementarea practică a cestei soluţii.
Este important ca dumneavoastră să cunoaşteţi tipul de relaţie care există

între tabelele dintr-o pereche, deoarece acesta determină modul în care sunt
corelate tabelele, dacă înregistrările din tabele sunt interdependente sau nu,
precum şi numărul minim şi maxim de înregistrări corelate care pot exista
în cadrul relaţiei.
33
Studenti

6001 Studenti
Pop Remus Reghin ........
Cursuri
Orar CursID Denumire Credite ProfID
StudID CursID C001 PUC 5 25461
6001 C001 C213 Baze de date 5 25461
6002 C213 C032 SIM 4 56821
6002 C001 C015 GD 5 12843
6001 C213 G001 AutoCAD 4 32584
6002 C015 G004 Inventor 5 3212
6003 C001 G007 Intellicad 4 25461
6003 C213
6001 C015
6003 G001
6001 G001
Fig.2.13. Rezolvarea unei relaţii de tip mai mulţi cu mai mulţi

cu ajutorul unui tabel de legătură
Tipuri de participare
Când stabiliţi o relaţie între două tabele, fiecare tabel participă la relaţie
într-o manieră particulară. Tipul de participare pe care îl atribuiţi unui
tabel dat determină dacă în respectivul tabel trebuie să existe o înregistrare
înainte de a putea introduce înregistrări în tabelul corelat. Există două
tipuri de participări:
Obligatorie - tabelul trebuie să conţină cel puţin o înregistrare înainte de a
putea introduce înregistrări în tabelul corelat.
Opţională – nu este obligatoriu ca tabelul să conţină vreo înregistrare
înainte de a putea introduce înregistrări în tabelul corelat.
34
De obicei, pentru majoritatea tabelelor, veţi determina tipul de participare
după ce definiţi regulile de lucru cu baza de date. În majoritatea cazurilor,
tipul de participare este evident, este de bun simţ sau este în concordanţă
cu un anumit set de standarde.
Să examinăm perechea de tabele din figura 2.11, care se găsesc într-o

relaţie unu cu mai mulţi. Ne propunem să stabilim tipul de participare a
celor două tabele în această relaţie. Pentru aceasta trebuie să răspundem la
câteva întrebări. Putem introduce înregistrări în tabelul CLIENTI dacă nu
avem nici o înregistrare în tabelul IMPRUMTURI? Răspunsul este DA,
pentru că tabelul cu potenţialii clienţi se completează la început, deci
tabelul IMPRUMUTURI are un tip de participare opţională, pentru această
relaţie. La întrebarea dacă putem introduce înregistrări în tabelul
IMPRUMTURI dacă nu avem nici o înregistrare în tabelul CLIENTI,
răspunsul este NU, pentru că trebuie să avem cel puţin un client la care să
împrumutăm, deci tabelul CLIENTI are un tip de participare obligatorie,
pentru această relaţie.
Gradul de participare
Gradul de participare determină numărul minim de înregistrări existente

într-un tabel al unei relaţii, asociate cu o singură înregistrare a unui tabel
corelat, respectiv numărul maxim de înregistrări care pot exista într-un
tabel al unei relaţii, asociate cu o singură înregistrare din tabelul corelat.
Să luăm în considerare, o relaţie dintre două tabele A şi B. Se stabileşte

gradul de participare pentru tabelul B prin indicarea numărului minim,
respectiv maxim de înregistrări din tabelul B, prin indicarea numărului
minim, respectiv maxim de înregistrări din tabelul B care pot fi corelate cu
o singură înregistrare din tabelul A. Dacă o înregistrare din tabelul A poate
fi corelată cu minimum o înregistrare din tabelul B, respectiv cu maximum
10 înregistrări din tabelul B, atunci gradul de participare al tabelului B, la
respectiva relaţie, este 1,10. (Gradul de participare se notează cu numărul
minim în stânga şi numărul maxim în dreapta, separate prin virgulă). Puteţi
stabili gradul de participare pentru tabelul A, în acelaşi mod. Puteţi
identifica gradul de participare, pentru fiecare tabel al unei relaţii prin
determinarea modului de corelare a datelor din fiecare tabel, precum şi a
modului de utilizare a datelor respective.
Să luă din nou exemplul din figura 2.11, care reprezintă două tabele care se
găsesc într-o relaţie unu cu mai mulţi. Dacă se impune (de către conducere)
35
ca un cititor (client) să poată împrumuta între 1 şi 4 cărţi, atunci gradul de
participare al tabelului IMPRUMUTURI este 1,4. Dacă doriţi să impuneţi
ca un cititor să poată împrumuta numai o carte, atunci veţi indica gradul de
participare ca fiind 1,1.
Termeni referitori la integritate
Specificaţii de câmp
O specificaţie de câmp reprezintă toate elementele unui câmp. Fiecare

specificaţie de câmp încorporează trei tipuri de elemente: generale, fizice şi
logice.
 Elementele generale reprezintă informaţiile fundamentale
referitoare la câmp şi includ elemente precum numele câmpului,
descrierea şi tabelul părinte.
 Elementele fizice determină modul de construire a unui câmp şi
modul de reprezentare a acestuia pentru persoana care îl
utilizează. Această categorie include elemente precum tipul de
date, lungimea şi formatul de afişare.
 Elementele logice descriu valorile stocate într-un câmp şi includ
articole precum valoarea obligatorie, intervalul de valori şi
valoarea prestabilită.
Aceste specificaţii de câmp o să le completaţi folosindu-vă de nişte

formulare, care vor fi descrise în detaliu în capitolul următor.
Integritatea datelor
Prin integritatea datelor se înţelege validitatea, consecvenţa şi acurateţea

datelor incluse într-o bază de date. Nu pot accentua suficient faptul că
nivelul de acurateţe al informaţiilor pe care le regăsiţi din baza de date este
direct proporţional cu nivelul de integritate al datelor pe care îl impuneţi
bazei de date. Integritatea datelor reprezintă unul dintre cele mai
importante aspecte ale procesului de proiectare a bazelor de date şi nu vă
este permis să-l subestimaţi, să-l treceţi cu vederea şi nici măcar să-l
neglijaţi parţial. Trebuie să fiţi conştient de faptul că dacă nu respectaţi
regulile de integritate, sunteţi pasibili de a obţine informaţii cu grave erori,
care sunt greu de depistat. Gândiţi-vă numai la implicaţiile posibile atunci
36
când baza dumneavoastră de date e folosită pentru tranzacţii comerciale
sau financiare.
Există patru tipuri de integritate a datelor pe care le veţi implementa pe

durata procesului de proiectare a bazelor de date. Trei dintre acestea se
bazează pe diferite aspecte ale structurii bazei de date şi sunt denumite în
conformitate cu zona (nivelul) la care operează. Cel de-al patrulea tip de
integritate a datelor se bazează pe modul în care o organizaţie îşi percepe şi
îşi utilizează datele.
În continuare vor fi prezentate descrierile fiecărui tip de integritate.

 Integritatea la nivel de tabel asigură lipsa înregistrărilor duplicate
în interiorul tabelului şi faptul că acel câmp care identifică fiecare
înregistrare din tabel este unic şi nu are niciodată valoare nulă.
 Integritatea la nivel de câmp asigură faptul că structura fiecărui
câmp este solidă, că valorile din fiecare câmp sunt valide,
consecvente şi precise, precum şi că se asigură o definire
consecventă, în întreaga bază de date, a câmpurilor de acelaşi tip
(Cod postal, de exemplu).
 Integritatea la nivel de relaţie (cunoscută şi sub numele de
integritate referenţială) asigură soliditatea relaţiei dintre două
tabele, precum şi faptul că înregistrările din tabele sunt
sincronizate ori de câte ori se introduc, se actualizează sau se
şterg date din oricare dintre cele două tabele.
 Reguli de desfăşurare a activităţii impun restricţii sau limitări
asupra anumitor aspecte ale bazei de date, pe baza modalităţilor
în care o organizaţie îşi percepe şi îşi actualizează datele. Aceste
restricţii pot afecta aspecte ale proiectării bazelor de date, precum
şi intervalul şi tipurile de valori stocate într-un câmp, tipul şi
gradul de participare a fiecărui tabel în cadrul unei relaţii, precum
şi tipul de sincronizare utilizat pentru integritatea la nivel de
relaţie, în anumite relaţii.

1. De ce este importantă terminologia?
2. Care sunt cele patru mari categorii de termeni?
3. Care este diferenţa dintre date şi informaţii?
4. Ce reprezintă valoarea nulă şi de ce este importantă?
37
5. Care sunt principalele structuri ale unei baze de date?
6. Denumiţi cele două tipuri de tabele?
7. Ce este o vedere?
8 .Care este diferenţa dintre o cheie şi un index?
9. Care sunt cele trei tipuri de relaţii care pot exista între două tabele?
10. Ce este o specificaţie de câmp?
11. Care sunt cele trei grupe de elemente ale unei specificaţii de câmp?
12. Ce este integritatea datelor? Care sunt tipurile de integritate?
38
Capitolul 3. Proiectarea bazelor de date relaţionale
Acest capitol va defini paşii prin care trebuie să trecem pentru a proiecta corect o
bază de date relaţională. Cunoştinţele dobândite vă vor permite să puteţi proiecta
singuri o astfel de bază de date.
Acum când am văzut din ce e formată o bază de date, când cunoaştem şi

înţelegem termenii bazelor de date relaţionale, e momentul să trecem la
proiectarea acestora. A înţelege cum se proiectează o bază de date
relaţională nu este foarte complicat, e cu mult mai simplu decât ne
imaginăm. Totuşi, este foarte important să aveţi o idee de ansamblu cu
privire la procesul de proiectare a bazelor de date relaţionale, precum şi o
imagine generală a etapelor pe care le implică procesul respectiv.
Înainte de a implementa o bază e date, aceasta trebuie proiectată, chiar

dacă este una mai simplă. De menţionat faptul că indiferent de baza de date
proiectată, trebuie parcurşi aceeaşi paşi sau etape. Acestea sunt:
Etapa 1 – Definirea unei declaraţii de intenţie şi a obiectivelor misiunii;
Etapa 2 – Analiza bazei de date curente;
Etapa 3 – Crearea structurilor de date;
Etapa 4 – Determinarea şi instituirea relaţiilor între tabele;
Etapa 5 – Determinarea şi definirea regulilor de desfăşurare a activităţii;
Etapa 6 – Determinarea şi definirea vederilor;
Etapa 7 – Verificarea integrităţii datelor.
Trebuie să mai menţionez faptul că întregul proces de proiectare se face

fără ajutorul vreunui program, calculatorul este folosit numai la editarea
documentelor acestui proces, aşa cum vom vedea mai departe şi la orele de
laborator.
În continuare se vor detalia etapele de proiectare a unei baze de date

relaţionale.
39
Etapa 1 – Definirea unei declaraţii de intenţie şi a

obiectivelor misiunii
Prima fază în procesul de proiectare a bazelor de date constă din definirea
unei declaraţii de intenţie şi a obiectivelor misiunii bazei de date. Această
declaraţie stabileşte finalitatea bazei de date şi oferă o orientare distinctă
pentru activitatea de proiectare.
Fiecare bază de date este creată cu un anumit rost, fie pentru rezolvarea
unei anumite probleme de afaceri, gestiunea unor tranzacţii zilnice,
gestiunea unei magazii, fie pentru a fi utilizată ca parte a unui sistem
informaţional. Destinaţia bazei dumneavoastră de date este identificată şi
definită într-o declaraţie de intenţie. Aceasta contribuie la asigurarea
dezvoltării unei structuri de baze de date adecvate, precum şi identificarea
acelor date care duc la atingerea scopului propus.
Pe lângă declaraţia de intenţie, în această etapă trebuie definite şi

obiectivele misiunii. Obiectivele misiunii sunt declaraţii care reprezintă
sarcinile generale pe care utilizatorii le pot îndeplini folosind baza de date.
Aceste obiective sprijină şi completează declaraţia de intenţie, determinând
în acelaşi timp diferitele aspecte ale structurii bazei de date. Obiectivele
misiunii se mai pot numi şi caiet de sarcini, termen încă folosit pentru
definirea cerinţelor beneficiarului.
Declaraţia de intenţie şi obiectivele misiunii fiind documente foarte

importante în proiectarea unei baze de date se pune întrebarea, cine
elaborează aceste documente?
Declaraţia de intenţie este elaborată de dezvoltatorul bazei de date (Dvs.)
împreună cu conducătorul(patronul) firmei şi personalul de conducere
care este responsabil de definirea acesteia. Este necesară participarea
celor două părţi pentru a se putea ajunge la o exprimare corectă care
să fe înţeleasă la fel atât de dezvoltator cât şi de beneficiar, altfel s-ar
putea ajunge la situaţii de genul ”nu asta am cerut” sau ”eu altceva
am înţeles din această frază”.
Obiectivele misiunii sunt elaborate de dezvoltatorul bazei de date (Dvs.)
împreună cu personalul de conducere şi utilizatorii finali (cei care vor
lucra efectiv cu aplicaţia). Această componenţă este necesară pentru
că utilizatorii finali pot avea idei valoroase pentru proiectarea corectă
a bazei de date.
40
Compunerea unei declaraţii de intenţie
O declaraţie de intenţie bună este succintă şi la obiect. Declaraţiile vagi sau

ambigui nu fac altceva decât, mai degrabă, să ascundă scopul bazei de
date.
Iată o declaraţie de intenţie bună:
Rolul bazei de date Clienţi/Furnizori este de a ţine la zi situaţiile de plăţi şi

încasări, precum şi de a furniza situaţii concrete referitoare la un anume
client sau furnizor, într-un anumit interval de timp sau la o anumită dată.
Această declaraţie este foarte generală, nu conţine date inutile, este scurtă
şi se vede clar la ce va fi folosită: să furnizeze informaţii despre starea unui
client sau furnizor, atât de importante în activitatea unei firme. Faceţi
analogia dintre o declaraţie de intenţie şi o lumânare cu care traversăm un
tunel întunecos, adică lumânarea nu ne dă amănunte despre cum să
traversăm tunelul dar ne ghidează spre capătul lui.
Iată un exemplu de declaraţie de intenţie formulată defectuos:
Rolul bazei de date a firmei SC AZUR SRL constă din a păstra evidenţa
aplicaţiilor pentru utilizarea terenurilor, păstrarea datelor cu privire la
solicitanţi, păstrarea unei înregistrări a tuturor audierilor, a tuturor
deciziilor, a tuturor apelurilor, păstrarea datelor referitoare la angajaţii
departamentului şi întreţinerea datelor în vederea utilizării generale în
cadrul biroului.
Această declaraţie de intenţie are următoarele neajunsuri:

 este prolixă, adică nu este succintă şi la obiect;
 finalitatea bazei de date nu este clară; este astfel scrisă încât este
dificil de identificat finalitatea bazei de date;
 descrie numeroase operaţii concrete, care nu-şi au rostul.
Cum am putea corecta această declaraţie de intenţie? Iată un exemplu:
Rolul bazei de date a firmei SC AZUR SRL constă din a păstrarea datelor
utilizate de biroul judecătorului de instrucţie pentru luarea de decizii
privind solicitările de utilizare a terenurilor trimise de cetăţenii judeţului X.
41
Se observă că finalitatea bazei de date a devenit mult mai clară, s-au
eliminat operaţiile şi nu dă impresia că ar fi incompletă.
Compunerea unei declaraţii de intenţie presupune din partea

dumneavoastră, a dezvoltatorului purtarea de discuţii cu patronul sau
managerul societăţii respective, pentru aflarea de informaţii despre aceasta,
profilul ei de activitate etc. Deci, prima discuţie cu patronul apoi cu ceilalţi
membrii ai conducerii sau alţi specialişti indicaţi de patron. Aţi putea să vă
întrebaţi de ce atâta zarvă pentru una sau două fraze pe care le conţine
declaraţia de intenţie? Nu uitaţi că declaraţia de intenţie este sinteza unor
discuţii, păreri contradictorii, opinii ale mai multor persoane şi că ea
trebuie să fie lumina călăuzitoare pentru finalizarea proiectului bazei de
date.
Cel mai important aspect care trebuie reţinut este acela că declaraţia de
intenţie trebuie să fie logică pentru dumneavoastră (dezvoltatorul bazei de
date) şi beneficiarii bazei de date. Tipul de declaraţii diferă de la un grup
de persoane la altul, iar formularea depinde mult de terminologia specifică
domeniului de activitate. Declaraţia dumneavoastră de intenţie este
completă atunci când conţine o propoziţie care descrie finalitatea concretă
a bazei de date, care este înţeleasă şi aplicată de toate părţile implicate.
Definirea obiectivelor misiunii
Obiectivele misiunii sunt declaraţii care reprezintă sarcinile generale

acceptate de datele păstrate în baza de date. Fiecare obiectiv reprezintă o
singură sarcină. Obiectivele misiunii furnizează informaţii pe care le veţi
folosi în decursul procesului de proiectare a bazei de date. De exemplu,
obiectivele misiunii permit definirea structurii tabelelor, a specificaţiilor de
câmp, a caracteristicilor de relaţie şi a vederilor. De asemenea, vă ajută să
impuneţi integritatea datelor şi să definiţi regulile de desfăşurare a
activităţii. În final, obiectivele misiunii sunt de natură să îndrume
demersurile de dezvoltare şi asigură faptul că structura finală a bazei de
date permite îndeplinirea declaraţiei de intenţie.
Un obiectiv de misiune bine scris reprezintă o propoziţie cu caracter

declarativ, care defineşte fără echivoc o sarcină de ordin general şi care
este lipsită de detalii inutile. Un obiectiv se exprimă în termeni generali,
succint, la obiect şi fără ambiguităţi. Iată câteva exemple de obiective de
misiune caracteristice:
42
Dorim să păstrăm informaţii complete despre studenţi.
Dorim să păstrăm evidenţa tuturor facturilor emise.
Dorim să păstrăm evidenţa tuturor recepţiilor.
Dorim să ne asigurăm că un agent de vânzări nu răspunde de mai mult
de 15 clienţi.
Dorim să păstrăm evidenţa tuturor reparaţiilor maşinilor din dotare.
Dorim să generăm agende cu numerele de telefon ale angajaţilor.
După cum se observă, obiectivele prezentate sunt foarte clare şi uşor de

înţeles. Fiecare obiectiv reprezintă o sarcină unică de ordin general şi
defineşte clar sarcina respectivă, fără detalii inutile. De exemplu, ultimul
obiectiv de misiune prezentat în lista anterioară indică faptul că se doreşte
generarea unor liste cu angajaţi nu şi modul în care vor fi generate. Nu este
necesară indicarea modalităţii de generare a listelor de angajaţi, deoarece
acest aspect face parte din procesul de dezvoltare a aplicaţiei.
De reţinut că finalitatea unui obiectiv de misiune constă din definirea

diferitelor structuri din compoziţia bazei de date şi din orientarea direcţiei
generale a dezvoltării bazei de date.
Dacă un obiectiv de misiune reprezintă mai multe sarcini generale, acesta

va trebui descompus în două sau mai multe obiective de misiune.
În concluzie, această etapă are ca rezultat un document care ne spune de ce

trebuie să proiectăm baza de date (declaraţia de intenţie) şi cam ce
probleme rezolvăm cu ea (obiectivele misiunii).

1. Ce este o declaraţie de intenţie ?
2. Indicaţi două caracteristici ale unei declaraţii de intenţie bine scrise.
3. Daţi exemple de declaraţii de intenţie.
4. Când se consideră finalizată o declaraţie de intenţie?
5. Ce este un obiectiv de misiune?
6. Indicaţi două caracteristici ale unui obiectiv de misiune bine scris.
7. Daţi exemple de obiective de misiune.
8. Cine concepe declaraţia de intenţie şi obiectivele misiunii?
43
Etapa 2 - Analiza bazei de date curente

Înainte de a începe proiectarea noii noastre baze de date trebuie să fim conştienţi
că nu suntem pe un pământ virgin, că înaintea noastră s-au mai folosit baze de
date, s-au manipulat informaţii, aşa că este înţelept să vedem ce există pentru a
putea prelua unele informaţii. De multe ori chiar există o bază de date care a fost
proiectată după posibilităţile de atunci. Această bază de date poate fi folosită ca
resursă pentru noua bază de date.
Fiind în etapa 2-a de proiectare, deja ştiţi obiectivele pe care trebuie să le

îndeplinească noua bază de date. Pentru vă face o imagine despre organizaţie
(firmă) şi informaţiile cu care lucrează, va trebui să răspundeţi la următoarele
întrebări:
 Ce tipuri de date foloseşte organizaţia?
 Cum foloseşte organizaţia datele respective?
 Cum gestionează şi păstrează organizaţia datele respective?
Răspunsurile la aceste întrebări, vă oferă informaţii vitale, pe care le puteţi

utiliza eficient în proiectarea bazei de date care răspunde cel mai bine
cerinţelor organizaţiei. Actorii acestei etape sunt, pe de o parte
dezvoltatorul bazei de date (cel care pune întrebări şi prelucrează
răspunsurile) şi beneficiarii (cei care răspund la întrebări). Este foarte
probabil ca organizaţia să utilizeze un tip sau altul de bază de date care ar
putea fi asociată cu una din următoarele categorii:
Baze de date pe suport de hârtie – sunt formate din diferite formulare şi

documente manuscrise stocate în dosare. Dosarele sunt identificate cu
ajutorul unor coduri scrise pe ele, apoi sunt puse în fişete prin intermediul
unei scheme de codificare, în funcţie de dimensiunea bazei de date. Aceste
baze de date sunt mai dificil de înţeles, de aceea este necesară conlucrarea
cu persoane din firmă care lucrează efectiv cu aceste informaţii.
Baze de date moştenite – sunt acele baze de date care au existat şi au fost
folosite mai mulţi ani. Ele sunt alcătuite din diferite tipuri de structuri de
date şi ecrane de interfaţă cu utilizatorul, care se găsesc toate într-un
calculator personal. Randamentul, funcţionalitatea şi eficienţa structurilor
şi ecranelor sunt extrem de dependente de limbajul de programare şi
programele de gestiune a bazelor de date folosit. În general, structurile şi
44
ecranele sunt nefinisate conform standardelor moderne, deoarece au fost
create atunci când aceste standarde nu existau.
Baze de cunoştinţe umane se bazează pe memoria unuia sau mai multor

angajaţi din cadrul organizaţiei. Aceste persoane posedă un anumit volum
de informaţii (de exemplu date despre clienţi, furnizori sau detalii despre
un anumit produs) care sunt foarte importante pentru derularea activităţii
organizaţiei respective. Aceste informaţii trebuie interceptate în vederea
introducerii lor în baza de date pe care o proiectaţi.
Obiectivul analizei dumneavoastră constă în a determina tipul de date pe

care le foloseşte organizaţia, modul în care le gestionează şi păstrează,
modul în care le vizualizează şi le utilizează. În decursul analizei veţi trece
în revistă diferitele moduri în care organizaţia îşi colectează şi prezintă
datele, după serii de discuţii purtate cu utilizatorii direcţi şi cu personalul
de conducere.
Cum se procedează? Informaţiile pe care le-aţi adunat le folosiţi pentru a

sintetiza o listă iniţială de câmpuri. Apoi rafinaţi această listă pentru
eliminarea câmpurilor duplicate şi a celor calculate şi plasarea acestora din
urmă într-o listă separată, care va fi folosită mai târziu în procesul de
proiectare. Lista rafinată constituie necesităţile informaţionale ale
organizaţiei respective şi furnizează un punct de început pentru proiectarea
unei noi baze de date.
După cum se ştie, nimic nu este niciodată finalizat, aşa că nici lista noastră
de câmpuri, oricât de rafinată ar fi, va fi modificată de multe ori. După ce
aţi finalizat lista de câmpuri, trimiteţi-o utilizatorilor şi personalului de
conducere, pentru o examinare succintă şi posibile modificări. Încurajaţi
opiniile celorlalţi şi luaţi în considerare sugestiile lor de modificare.
În concluzie, această etapă se va încheia cu un document care conţine o

listă preliminară de câmpuri şi o listă de câmpuri calculate.

1. În ce constă analiza bazei de date curente?
2. Care sunt cele trei surse pe care le analizăm?
3. Care este rolul dezvoltatorului şi al beneficiarului?
45
4. Cum se finalizează această etapă?
Etapa 3 - Crearea structurilor de date

În această etapă se definesc tabelele cu câmpurile lor, se stabilesc cheile şi
se stabilesc specificaţii pentru fiecare câmp.
Tabelele sunt primele structuri care se definesc într-o bază de date.

Determinarea diferitelor subiecte pe care le vor reprezenta tabelele se
execută pe baza obiectivelor misiunii, pe care le-aţi determinat în timpul
primei faze a procesului de proiectare şi a necesităţilor de date pe le-aţi
adunat pe durata celei de-a doua faze. În principiu, un subiect trebuie să se
regăsească într-un tabel, care la rândul său conţine un număr de câmpuri
care definesc complet acel subiect.
Cum se procedează? Iată paşii care vor trebui parcurşi:

 Se face o listă preliminară cu toate tabelele identificate;
 Fiecărui tabel i se definesc câmpurile;
 Se stabilesc cheile adecvate pentru fiecare tabel, principala grijă
fiind aceea ca fiecare tabel să aibă cheie primară corect definită.
Această cheie identifică în mod unic fiecare înregistrare din tabel;
 Pasul final al acestei etape constă în stabilirea specificaţiilor de
câmp aferente fiecărui câmp al bazei de date.
După ce au fost parcurşi aceşti paşi se vor purta discuţii cu utilizatorii şi

personalul de conducere pentru a verifica încă o dată specificaţiile de câmp
stabilite. În această fază pot apare mici modificări, fie la componenţa
câmpurilor unui tabel sau la specificaţiile de câmp.
Definirea listei finale de tabele
După analizarea listei de tabele şi a discuţiilor cu viitorii utilizatori ai bazei

de date pe care o proiectaţi, veţi putea defini o listă finală de tabele.
Această listă trebuie să conţină nouă noi elemente şi anume:
46
 Tipul tabelului – tabel de date, tabel de legătură, tabel subset sau
tabel de validare;
 Descrierea tabelului – care cuprinde o definire clară a subiectului
reprezentat de tabel şi precizează de ce este important acest
subiect pentru organizaţia care utilizează baza de date. Există
câteva principii de bază care vă ghidează în descrierea tabelului.
În continuare vor fi prezentate câteva principii sau linii directoare legate de

numele pe care îl daţi tabelelor şi câmpurilor.
Iată câteva linii directoare care vă vor ajuta să alegeţi numele tabelelor:
 Creaţi un nume unic, descriptiv, care să fie semnificativ pentru
întreaga organizaţie. Utilizarea numelor unice vă ajută să vă
asiguraţi că fiecare tabel reprezintă clar un subiect diferit şi că
toată lumea va înţelege ce reprezintă tabelul. Alegeţi nume
suficient de descriptive pentru a fi înţelese de la sine. “Întretinere
aparate” este un nume bun şi descriptiv.
 Creaţi un nume care identifică cu precizie, clar şi fără
ambiguităţi subiectul tabelului. Numele vagi sau ambigue indică
de obicei faptul că tabelul reprezintă mai mult de un subiect, ceea
ce nu este de dorit. Când întâlniţi astfel de nume, identificaţi
subiectele reprezentate cu adevărat de tabel, apoi trataţi fiecare
subiect ca tabel separat. “Date” este un exemplu de nume de tabel
ambiguu, care poate însemna orice fel de date, referitoare la
facturi, persoane, aparate, parametri tehnologici etc.
 Utilizaţi numărul minim de cuvinte necesar comunicării
subiectului tabelului. Orice persoană din organizaţie trebuie să
poată înţelege ce reprezintă un tabel, fără a citi descrierea
acestuia. Cu toate că obiectivul dumneavoastră este de a crea un
nume cât mai scurt, nu este indicat să folosiţi un nume ca de
exemplu “TD_1”, care este exagerat de scurt şi generează
neclaritate.
 Nu folosiţi cuvinte care comunică anumite caracteristici fizice. În
numele tabelelor evitaţi folosirea unor cuvinte ca “fisier”, “tabel”,
“câmp”, deoarece ele ar putea introduce un grad de confuzie de
care nu aveţi nevoie.
47
 Nu folosiţi acronime şi abrevieri. Acronimele sunt greu de
descifrat, abrevierile rareori reuşesc să comunice subiectul unui
tabel, iar împreună încalcă primul principiu prezentat.
 Folosiţi forma de plural a numelui. După cum ştiţi, un tabel
reprezintă un singur subiect, care poate fi un obiect sau
eveniment. Puteţi extinde această definiţie spunând că un tabel
reprezintă o colecţie de obiecte sau evenimente similare. Prin
urmare, puteţi da nume de tabel de forma “Calculatoare” sau
“Consultatii”.
 Evitaţi folosirea diacriticelor în numele de tabele. Diacriticele ş,
ţ, ă, î, â pot influenţa negativ dezvoltarea aplicaţiilor de bază de
date, deoarece unele funcţii ar putea să nu înţeleagă aceste
caractere speciale, caracteristice numai limbii române.
Pentru descrierea unui tabel ţineţi seamă de următoarele principii:

 Includeţi un enunţ care să definească cu exactitate tabelul. Din
descrierea tabelului oricine ar trebui să poată determina uşor
identitatea acestuia, fără confuzii sau ambiguităţi. Iată o definiţie
de tabel căruia îi lipseşte precizia:
Furnizori – companii care ne livrează materii prime şi
materiale.
Ce se întâmplă dacă firma (o brutărie) primeşte ingrediente şi de
la fermierii locali, care nu sunt companii? Iată o definiţie
corespunzătoare:
Furnizori – persoane şi organizaţii care ne livrează materii
prime şi materiale.
Acest enunţ poate fi utilizat ca definiţie de tabel în descrierea
unui tabel.
 Includeţi un anunţ care explică de ce acest tabel este important
pentru organizaţie. Un tabel conţine date ce sunt adunate,
întreţinute, manipulate şi preluate de către organizaţie pentru un
anumit motiv. Enunţul trebuie să explice de ce respectivele date
sunt importante pentru organizaţie.
 Compuneţi o descriere care să fie clară şi succintă. Evitaţi
greşeala obişnuită de a enunţa din nou sau reformula numele
tabelului în descrierea acestuia, ca în exemplul următor:
48
Orar Student – orarul unui student.
Evitaţi să fiţi laconic. Prin orar se pot înţelege multe. Descrierea

de mai sus nu este de mare folos pentru oricine din organizaţie.
Iată un exemplu de descriere, care este destul de lungă şi oferă
mai multă informaţie decât e necesar:
Orar Student – toate cursurile care vor fi urmate de către un

student (inclusiv zile, ore şi titularul de curs) pe parcursul
unui an şcolar. Datele din acest tabel sunt importante deoarece
permit studentului să cunoască numele, momentul şi locul în
care se presupune că se va desfăşura cursul. De asemenea,
studentul va cunoaşte atât durata cursului, cât şi numele
profesorului care îl predă.
Toată această definiţie poate fi reformulată mai clar şi mai

succint, astfel:
Orar Student – cursurile pe care studentul trebuie să le

urmeze în anul şcolar curent. Informaţia oferită de acest tabel
ajută studentul la gestionarea timpului iar şcolii să realizeze
statistici despre cursuri, studenţi, săli şi profesori. Prima
propoziţie din acest tabel oferă definiţia tabelului, iar a doua de
ce este important pentru organizaţie (şcoală).
 În descrierea tabelului nu includeţi informaţii care ţin de
implementare, ca de exemplu modul în care sau locul unde este
folosit tabelul. Evitaţi enunţuri care indică modul specific de
utilizare a tabelului sau cum îl veţi accesa fizic.
 Nu realizaţi o descriere care face trimitere la descrierea unui alt
tabel. Fiecare tabel trebuie să aibă o descriere proprie şi
independentă de orice altă descriere a unui alt tabel.
După ce aţi definitivat lista de tabele, urmează, în mod firesc, ca fiecărui

tabel să i se asocieze un număr de câmpuri.
Asocierea câmpurilor fiecărui tabel
Etapa 2-a s-a finalizat cu o listă de câmpuri. Atribuirea câmpurilor la un

tabel este un proces relativ simplu: determinaţi care câmpuri reprezintă cel
mai bine caracteristicile subiectului unui tabel şi atribuiţi aceste câmpuri
49
respectivului tabel. Repetaţi această procedură pentru toate tabelele din
lista finală de tabele. Se poate întâmpla ca un câmp sau un set de câmpuri
să fie cerut de mai multe tabele, aceasta este un lucru acceptat.
Observaţie importantă!! Sunteţi în faza de proiectare a bazei de date şi nu

aveţi nevoie decât de hârtie şi creion pentru a vă face treaba. Când lucraţi
la un proiect de baze de date, primul lucru pe care trebuie să-l faceţi este
achiziţia unui dosar plic în care să ţineţi toate listele pe care le-aţi scris,
schiţele şi notaţiile care se vor aduna. Se va trece la calculator numai
după ce aveţi proiectul complet al bazei de date. De altfel, în cadrul
acestui curs o să găsiţi un studiu de caz în care se proiectează o bază de
date.
Începeţi acest proces luând o foaie de hârtie (A4) aşezată culcat

(landscape). În partea de sus a foii scrieţi numele fiecărui tabel din lista
finală de tabele, având grijă să lăsaţi suficient spaţiu pentru a încape
numele câmpurilor pe care le veţi scrie sub ele (figura 3.1).
Studenti Discipline Profesori .....

Nume Denumire Nume
Prenume Credite Prenume
Data nasterii Profesor Grad didactic
......... ........ ........
Fig. 3.1. Crearea unei foi pentru scrierea structurilor de tabel
Practica spune că în această fază tabelele nu au încă o structură definitivă,

de aceea trebuie analizată în continuare această structură, mai ales că avem
imaginea de ansamblu a tuturor tabelelor. O primă problemă ar fi
verificarea numelor câmpurilor care au primit nume după inspiraţia de
moment, de aceea trebuie să dăm nume câmpurilor după nişte criterii sau
principii.
Iată câteva principii pe care le puteţi folosi pentru crearea numelor de

câmpuri:
 Creaţi un nume unic, descriptiv, care să aibă sens pentru
întreaga organizaţie. Un nume de câmp trebuie să apară o
50
singură dată în toată baza de date; singura excepţie de la această
regulă apare în cazul în care câmpul serveşte la stabilirea unei
relaţii între două tabele. Asiguraţi-vă că numele este suficient de
descriptiv pentru a comunica exact înţelesul câmpului pentru
oricine îl vede.
 Creaţi un nume care să identifice cu precizie, clar şi fără
ambiguităţi caracteristica reprezentată de câmp. “Număr de
telefon” este un exemplu clasic de nume de câmp ambiguu pentru
că nu ştim la ce telefon se referă, la cel de acasă, de la birou sau
la telefonul mobil. Învăţaţi să fiţi exact. Acest nume de câmp ar
putea să fie foarte exact dacă ar avea numele “Numar telefon
acasa” sau “Numar telefon birou”.
 Utilizaţi numărul minim de cuvinte necesar comunicării
înţelesului caracteristicii reprezentate de câmp. Este bine să
evitaţi numele de câmpuri lungi, dar în acelaşi timp ar fi bine să
evitaţi utilizarea unui singur cuvânt ca nume de câmp, dacă acel
cuvânt este necorespunzător. De exemplu “Angajare” este prea
scurt pentru un nume de câmp, iar “Data la care a fost angajata
persoana” este mult prea lung! Însă “Data angajarii” este un nume
de câmp foarte bun.
 Nu folosiţi acronime, iar abrevierile trebuie utilizate judicios.
Acronimele pot fi greu de descifrat şi deseori duc la neînţelegeri.
Imaginaţi-vă un câmp „CAD-UPM”. Ce aţi înţelege din această
denumire? Abrevierile se pot folosi doar dacă îmbunătăţesc
numele câmpului, o abreviere nu trebuie să facă ambiguu un
nume de câmp.
 Utilizaţi forma de singular a numelor. Un câmp cu nume de
plural, cum ar fi “Functii”, implică faptul că acel câmp ar putea
conţine două sau mai multe valori pentru o înregistrare dată, ceea
ce nu e de loc o idee bună. Un nume de câmp este la singular
deoarece el reprezintă o singură caracteristică a subiectului
tabelului căruia îi aparţine.
Ţinând cont de aceste principii, reluaţi fiecare tabel şi vedeţi dacă nu

cumva puteţi aduce îmbunătăţiri la vreunul din numele de câmpuri.
Mai departe se vor prezenta elementele unui câmp ideal pentru a ne ajuta
să rezolvăm anomaliile legate de câmpuri.
51
Utilizarea unui câmp ideal pentru rezolvarea anomaliilor
Cu toate că în lista preliminară de câmpuri aţi identificat cu atenţie

câmpurile, este foarte posibil să fi creat câteva câmpuri ce ar putea pune
probleme în structura tabelului. Câmpurile definite neglijent pot duce la
apariţia datelor duplicate sau a datelor redundante şi ele pot fi dificil de
utilizat. Dacă nu cunoaşteţi semnele de avertizare, vă va fi dificil să vă daţi
seama dacă vreunul dintr-un tabel va provoca probleme.
Cea mai bună cale de identificare a câmpurilor ce ar putea crea probleme

este să determinaţi dacă respectivele câmpuri respectă elementele
câmpului ideal. Aceste elemente constituie un set de principii pe care le
puteţi utiliza pentru a crea structuri solide de câmpuri şi pentru a depista
uşor câmpurile neglijent proiectate.
Iată elementele câmpului ideal:

 Reprezintă o caracteristică distinctă a subiectului tabelului. După
cum ştiţi, un tabel reprezintă un anumit subiect, care poate fi un
obiect sau un eveniment. Câmpul ideal reprezintă o caracteristică
distinctă a respectivului obiect sau eveniment.
 Conţine doar o singură valoare. Un câmp care poate stoca două
sau mai multe apariţii ale aceleiaşi valori este cunoscut câmp cu
mai multe valori. Câmpul ideal nu conţine decât o singură
valoare.
 Nu poate fi descompus în elemente mai mici. Un câmp care poate
stoca două sau mai multe elemente distincte în interiorul unei
valori este cunoscut drept câmp cu mai multe părţi. Similar
câmpului cu mai multe valori, acest tip de câmp provoacă
probleme atunci când încercaţi să editaţi sau să sortaţi datele din
interiorul lui. Aceste probleme nu apar la câmpul ideal deoarece
acesta reprezintă o caracteristică unică, distinctă a subiectului
tabelului căruia îi aparţine.
 Nu conţine o valoare calculată sau concatenată. Valorile
câmpurilor dintr-un tabel trebuie să fie independente, adică
valoarea unui câmp anumit câmp să nu depindă de valoarea altor
câmpuri. Un câmp a cărui valoare depinde de valorile altor
câmpuri se numeşte câmp calculat. Un astfel de câmp nu se
actualizează automat când se schimbă o valoare a unui câmp
implicat, ceea ce devine o responsabilitate nedorită a
52
utilizatorului sau programului aplicaţiei de bază de date să
actualizeze aceste câmpuri. Din această cauză trebuie să vă
ocupaţi separat de câmpurile calculate, în cadrul rapoartelor.
 Este unic în interiorul structurii întregii baze de date. Singurele
câmpuri duplicate care apar într-o bază de date corect proiectată
sunt cele care stabilesc relaţiile dintre tabele.
Stabilirea cheilor pentru fiecare tabel
Suntem în situaţia în care am creat structurile de tabele, respectând anumite

principii care sunt garanţia unui proiect bun. După cum se ştie, fiecare
tabel trebuie să aibă o cheie primară. Imediat veţi afla că există tipuri
diferite de chei, fiecare dintre acestea având un rol particular în interiorul
bazei de date. În timpul acestei etape vor fi atribuite toate cheile, mai puţin
una (care o veţi stabili ulterior când stabiliţi relaţiile între tabele).
Cheile sunt importante pentru o structură de tabel din următoarele motive:

 Cheile ne asigură că fiecare înregistrare dintr-un tabel este
identificată cu precizie. După cum se ştie, un tabel reprezintă o
colecţie unică de obiecte sau evenimente asemănătoare. Colecţia
este compusă din setul complet de înregistrări din interiorul
tabelului, iar, în interiorul acestei colecţii, fiecare înregistrare
reprezintă o instanţă unică a subiectului tabelului. Aveţi nevoie de
un mijloc de identificare cu precizie a fiecărei instanţe, iar o cheie
este instrumentul care vă permite să faceţi acest lucru.
 Cheile ajută la stabilirea şi impunerea diferitelor tipuri de
integritate. Cheile sunt o componentă majoră a integrităţii la nivel
de tabel şi a integrităţii la nivel de relaţie. De exemplu, ele vă
permit să vă asiguraţi că un tabel are înregistrări unice şi că acele
câmpuri pe care le utilizaţi la stabilirea relaţiilor între două tabele
conţin întotdeauna valori corespondente.
 Cheile servesc la stabilirea relaţiilor între tabele. Asiguraţi-vă
întotdeauna că aţi definit chei corespunzătoare pentru fiecare
tabel.
Pentru stabilirea cheilor pentru fiecare tabel, ne reamintim că există două

tipuri principale de chei: chei primare şi chei externe.
53
Într-un paragraf anterior (Cap 1/Chei), am văzut că fiecare tabel trebuie să
aibă o cheie, altfel nu putem spune că acesta este corect definit. De
asemenea, ştim că rolul de cheie poate fi îndeplinit de un anume câmp al
tabelului sau o combinaţie de câmpuri. Am spus un anume câmp, deoarece
nu orice câmp poate fi cheie într-un tabel, acesta trebuie să îndeplinească
anumite condiţii.
Iată condiţiile pe care trebuie să le îndeplinească o cheie primară:

 Nu poate fi un câmp cu mai multe părţi.
 Trebuie să conţină valori unice.
 Nu poate conţine valori nule.
 Valoare ei nu trebuie să conţină date confidenţiale cum ar fi cod
numeric personal, vreun cod de acces etc.
 Valoare ei nu poate fi opţională, adică trebuie neapărat introdusă.
 Conţine numărul minim de câmpuri necesar definirii unicităţii.
 Valorile ei trebuie să identifice în mod unic şi exclusiv fiecare
înregistrare din tabel.
 Valoarea ei trebuie să identifice exclusiv valoarea fiecărui câmp
dintr-o înregistrare dată.
 Valoarea ei nu poate fi modificată decât în cazuri rare sau
extreme.
Cum se procedează efectiv?

 Se ia un tabel în care se introduc un eşantion de date.
 Se ia pe rând câte un câmp şi se verifică dacă acesta îndeplineşte
condiţiile pentru a fi cheie primară, alcătuindu-se o listă care se
numeşte lista cheilor candidate.
 Dintre cheile candidate se va alege cheia cea mai potrivită (ceva
asemănător cu alegerea preşedintelui din lista de candidaţi). Este
adevărat că aici, un rol important îl are experienţa dumneavoastră
anterioară.
Se poate întâmpla ca lista dumneavoastră de chei candidate să fie goală,

adică nici un câmp al tabelului nu poate fi cheie primară. În acest caz, se
poate utiliza o cheie candidată artificială care nu este altceva decât un
câmp introdus forţat, care nu apare în mod “natural” în tabel. Fiind un
54
câmp artificial care nu are nici o legătură cu tabelul, putem să-i impunem
foarte uşor condiţiile pentru a fi cheie primară.
Iată un astfel de caz, prezentat în figura 3.2.
Nume piesa schimb Model Producator Pret cu amanuntul

Curea ventilator XP-035 Auto Service SRL 34.75
Acumulator TR-78-02 ROMBAT SA 1250
Bujie 16.90
Curea ventilator GF-25 29.35
Maneta viteza Dacia Dacia SA 23.85
Bucsa directie 12.55
Fig. 3.2. Tabel fără cheie candidată
După cum se poate vedea nici un câmp nu îndeplineşte condiţiile de a fi

cheie candidată:
 Câmpul NUME PIESA SCHIMB nu poate fi ales deoarece ar
putea conţine valori duplicat.
 Câmpul MODEL nu poate fi ales deoarece ar putea avea valori
nule.
 Câmpul PRODUCATOR nu poate fi ales pentru că ar putea avea
valori nule (lipsă).
 Câmpul PRET CU AMANUNTUL nici nu poate fi luat în discuţie.
Pentru a rezolva problema, introducem un câmp nou numit NUMAR

PIESA SCHIMB, care va deveni cheie primară. În figura 3.3 este prezentat
tabelul completat cu câmpul respectiv.
Nr piesa Nume piesa Model Producator Pret cu amanuntul

schimb schimb
4100 Curea ventilator XP-035 Auto Service SRL 34.75
4105 Acumulator TR-78-02 ROMBAT SA 1250
4158 Bujie 16.90
4198 Curea ventilator GF-25 29.35
4122 Maneta viteza Dacia Dacia SA 23.85
4108 Bucsa directie 12.55
Fig. 3.3. Tabel cu cheie candidată artificială
55
Din practică pot spune (nu numai eu) că pentru a avea cât mai puţine
probleme cu cheile primare, este înţelept să introducem de la început o
cheie candidată artificială, imediat ce avem dubii că un anumit câmp vizat
ar putea încălca regulile. Pentru aceasta mulţi proiectanţi de baze de date
aleg pentru cheia primară un câmp introdus artificial care are un nume
compus din literele “ID” şi numele tabelului.
Iată câteva sugestii pentru alegerea cheii primare artificiale (figura 3.4):
Nume tabel Nume cheie artificială

Profesori ProfesorID
Studenti StudentID
Discipline DisciplinaID
Plan de învatanint PlanInvID
Fig. 3.4. Exemple de chei artificiale
În acest moment aţi finalizat o etapă importantă a procesului de proiectare

în care aţi definitivat structura tabelelor şi aţi atribuit fiecăruia chei
primare.
1. Ce este lista finală de tabele?

2. Enunţaţi trei principii pentru crearea numelor de tabel.
3. Enunţaţi două principii pentru compunerea descrierilor de tabel.
4. Cum se atribuie câmpuri tabelelor din lista finală de tabele?
5. Enunţaţi trei principii pentru crearea numelor de câmpuri.
6. Enunţaţi trei elemente ale câmpului ideal.
7. Enunţaţi trei motive pentru care sunt importante cheile.
8. Ce este lista cheilor candidate?
9. Ce este o cheie artificială? Daţi un exemplu.
10. Ce este o cheie primară?
56
11. Care sunt elementele unei chei primare?
12. Ce este o cheie externă? Daţi exemple.
Revizuirea structurilor iniţiale de tabel
Ca în orice activitate omenească, este bine să ne oprim, să ne evaluăm

stadiul în care suntem şi să verificăm dacă suntem pe drumul cel bun. E ca
într-o călătorie când din când în când verificăm harta sau întrebăm pe
cineva dacă suntem pe traseu bun.
Acum avem deja tabelele şi înainte de a merge mai departe vom arunca o
privire peste ce am lucrat până acum. Primul lucru de care trebuie să avem
grijă este integritatea la nivel de tabel. Acest tip de integritate este o
componentă majoră a integrităţii generale a datelor.
Verificaţi următoarele aspecte:

 Într-un tabel nu există înregistrări duplicat;
 Cheia primară identifică exclusiv fiecare înregistrare din tabel;
 Orice cheie primară este unică;
 Valorile cheilor primare nu sunt nule.
Pentru revizuirea structurilor de tabel este bine să staţi de vorbă cu

beneficiarul şi împreună veţi îndeplini următoarele sarcini:
 Asiguraţi-vă că în baza de date sunt reprezentate toate subiectele.
Deşi în această fază de proiectare este puţin probabil să fi uitat
vreun de vreun subiect, totuşi acest lucru se poate întâmpla. Dacă
se întâmplă, identificaţi subiectul şi transformaţi-l în tabel cu
tehnica pe care aţi mai folosit-o.
 Asiguraţi-vă că numele de tabele şi descrierile acestora sunt
potrivite şi semnificative pentru toată lumea. Dacă un nume sau o
descriere pare a fi ambiguă pentru mai multe persoane, lucraţi cu
aceste persoane pentru clarificarea lucrurilor.
 Asiguraţi-vă că numele de câmpuri sunt potrivite şi semnificative
pentru toată lumea. Alegerea numelor de câmpuri generează de
57
obicei multe discuţii, care vor duce în final la armonizarea
acestora.
 Verificaţi dacă la fiecare tabel au fost atribuite toate câmpurile
corespunzătoare. Acum aveţi cea mai bună oportunitate de a vă
asigura că toate caracteristicile necesare, referitoare la subiectul
unui tabel se găsesc la locul lor. Nu este neobişnuit să descoperiţi
că aţi uitat una sau două caracteristici. Dacă s-a întâmplat,
identificaţi respectivele caracteristici şi transformaţi-le în câmpuri
adăugate tabelului.
După ce aţi terminat consultările cu viitorii beneficiari ai bazei de date,

treceţi la pasul următor, în care veţi stabili specificaţii de câmp pentru
fiecare câmp din baza de date.
Câmpurile sunt fundaţia bazei de date, ele reprezentând caracteristicile

subiectelor importante pentru o organizaţie. Câmpurile stochează date
vitale pentru organizaţia respectivă, de care depind atât succesul cât şi
dezvoltarea sa ulterioară.
Deşi au o importanţă aşa de mare, paradoxal, câmpurilor din baza de date li

se acordă cea mai mică importanţă, se pierde cel mai puţin timp pentru
asigurarea integrităţii lor structurale şi logice. Se consideră că se pierde
prea mult timp pentru a stabili integritatea datelor, dar se pierde timp
înzecit pentru repararea bazelor de date prost proiectate.
În acest paragraf veţi învăţa cum să stabiliţi integritatea datelor prin

definirea specificaţiilor de câmp pentru fiecare câmp al bazei de date.
Timpul folosit pentru stabilirea acestor specificaţii nu este un timp pierdut
ci un timp câştigat, dacă ne referim la necazurile apărute datorită datelor
inconsecvente şi eronate, a căror consecinţe negative sunt greu de estimat.
Există mai multe motive pentru care specificaţiile de câmp sunt

importante:
 Specificaţiile de câmp vă ajută să stabiliţi şi să impuneţi
integritatea la nivel de câmp. Implementarea acestor specificaţii
vă permite să garantaţi că datele din fiecare câmp sunt
consecvente şi valide.
58
 Definirea specificaţiilor de câmp pentru fiecare îmbunătăţeşte
integritatea generală a datelor. Nu uitaţi că integritatea la nivel
de câmp este una din cele patru componente ale integrităţii
generale a datelor.
 Definirea specificaţiilor de câmp vă obligă să ajungeţi la o
înţelegere totală a naturii şi scopului datelor din baza de date.
Înţelegerea datelor înseamnă că puteţi hotărî dacă anumite date
sunt cu adevărat necesare şi importante pentru organizaţie şi
puteţi învăţa cum să le utilizaţi în avantajul dumneavoastră.
 Specificaţiile de câmp constituie „dicţionarul de date” al bazei
de date. Fiecare specificaţie de câmp stochează date despre
caracteristicile unui câmp dintr-o bază de date. Acest dicţionar de
date este util, în special la implementarea bazei de date într-un
program SGBDR – îl puteţi folosi drept ghid pentru crearea
câmpurilor şi stabilirea proprietăţilor fundamentale. De
asemenea, aceste specificaţii vă ajută să stabiliţi ce tip de
proceduri de introducere şi validare a datelor trebuie să
implementaţi în orice tip de aplicaţie de interfaţă cu utilizatorul
pe care o creaţi pentru baza de date.
Trebuie să aveţi în vedere faptul că nivelurile de consecvenţă, calitate şi

acurateţe a datelor din baza de date (respectiv a informaţiei scoase din
aceste date) sunt direct proporţionale cu gradul de completare a acestor
specificaţii.
Un câmp atinge integritatea la nivel de câmp după ce aţi definit un set

complet de specificaţii de câmp pentru respectivul câmp. Integritatea la
nivel de câmp asigură următoarele:
 Identitatea şi scopul unui câmp sunt clare şi toate tabelele în care
apare respectivul câmp sunt identificate corect;
 Definiţiile câmpurilor sunt consecvente în întreaga bază de date;
 Valorile unui câmp sunt consecvente şi valide;
 Tipurile de modificări, comparaţiile şi operaţiile ce pot fi aplicate
valorilor din câmp sunt clar identificate.
În continuare vor fi prezentate toate informaţiile de care aveţi nevoie

pentru a putea completa o specificaţie de câmp.
59
Anatomia unei specificaţii de câmp
O specificaţie de câmp încorporează diferite elemente care definesc

atributele unui câmp. Elementele dintr-o specificaţie sunt împărţite în
categoriile:
 Elemente generale
 Elemente fizice
 Elemente logice
Practic, scrierea specificaţiilor pentru fiecare câmp se face într-un

formular, aşa cum se vede în figura 3.5. Deşi pare un document birocratic,
nu este de loc aşa, deoarece este foarte util, mai ales în faza de
implementare când nu mai trebuie să analizăm fiecare câmp în parte, ci
consultăm numai dosarul.
Se observă clar cele trei grupe de specificaţii, fiecare cu specificaţiile sale.

Variantele pe care le puteţi alege, acolo unde e cazul, sunt puse într-un
dreptunghi, ceea ce face ca formularul să aibă claritate.
Toţi parametrii care apar în formularul cu specificaţiile de câmp vor fi

explicate tabelar, ceea ce ne ajută să găsim relativ uşor explicaţiile despre o
specificaţie pe care am uitat-o.
60
Elemente generale
Nume câmp: StatComer Tip specificaţie: □ Unică □ Generică □ Copie
Tabel părinte: Comercianti
Specificaţie sursă: Stat
Eticheta: Stat
Partajat de:
Alias(-uri):
Descriere: Statul in care se afla cartierul general al producatorului.Aceasta informatie este o
componenta a adresei postale generale a producatorului.
Elemente fizice
Tip de date:Alfanumeric Suport caractere:
Lungime : 2 □ Litere(A-Z) □ De pe tastatura (., /, $, #, %)
Numar de cifre zecimale: □ Cifre (0-9) □ Speciale (©, ®, ™, ∞)
Masca de introducere: AA
Format de afisare: Ambele litere trebuie sa fie majuscule.
Elemente logice
Tip cheie: □ Non-Cheie □ Primară Reguli de editare:
□ Externă □ Alternativă □ permite

Se introduce imediat,
editarea
se
Structură cheie: □ Simplă □ Compusă □ Se introduce imediat, nu se

Unicitate: □ Non-unică □ Unică permite editarea
□ Se introduce ulterior, se
Suport valori nule: □ Se acceptă □ Nu se acceptă permite editarea
valori nule valori nule
□ Se introduce ulterior, nu se
Valori introduse de: □ Utilizator □ Sistem permite editarea
□ Reguli nedeterminate în acest
Valoare obligatore: □ Nu □ Da moment
Valoare prestabilită: WA
Interval de valori: CA, ID, MT, OR, WA
Comparaţii permise:
□Acelaşi câmp □ Toate □= □> □ >= □≠ □< □ <=
□Alt câmp □ Toate □= □> □ >= □≠ □< □ <=
□Valoare de expresie □ Toate □= □> □ >= □≠ □< □ <=
Operatii premise:
□ Acelaşi câmp □ Toate □+ □- □x □÷ □ Concatenare
□ Alt câmp □ Toate □+ □- □x □÷ □ Concatenare
□ Valoare de expresie □ Toate □+ □- □x □÷ □ Concatenare
61 Specificaţie câmp
Fig. 3.5. Formular
Elementele generale reprezintă atributele fundamentale ale câmpului. Ele
oferă informaţii despre scopul câmpului, numele tabelului în care apare
câmpul etc. În tabelul 3.1 sunt prezentate aceste elemente generale.
Tab. 3.1. Elemente generale

Denumire Explicaţii
element
Nume de câmp Un număr minim de cuvinte care identifică în mod unic un anumit
câmp în întreaga bază de date.
Tabel părinte Tabelul care conţine în structura sa câmpul respectiv. Acesta este
singurul tabel în care va apărea câmpul, cu excepţia cazului în care
câmpul participă la stabilirea unei relaţii.
Eticheta Este un nume alternativ (de obicei, o formă scurtă a numelui
câmpului) prin care puteţi identifica respectivul câmp în interfaţa
aplicaţiei cu utilizatorul final pe care o creaţi pentru baza de date.
De exemplu, câmpul PRET UNITAR poate avea ca etichetă PU sau
PUNIT. Etichetele sunt utile, în special, când dorim să economisim
spaţiu, sau să „înghesuim” cât mai multe câmpuri într-un raport.
Partajat de Indică numele celorlalte tabele (dacă există) care conţin câmpul
respectiv. Singurele nume de tabel care trebuie să apară aici sunt
cele care au o relaţie explicită cu tabelul părinte al câmpului.
Alias(-uri) Este un nume pe care îl utilizaţi pentru acel câmp, în situaţii extrem
de rare. Una din situaţiile în care trebuie să utilizaţi un alias este
când în acelaşi tabel trebuie să existe două apariţii ale câmpului.
Descriere Aceasta este o explicaţie completă a câmpului. Compunerea unei
descrieri de câmp este extrem de benefică deoarece vă obligă să vă
gândiţi cu atenţie la natura datelor care vor fi stocate în câmpul
respectiv. Dacă aveţi dificultăţi în descrierea unui câmp, puteţi fi
sigur că acel câmp necesită îmbunătăţiri suplimentare.
Tip specificaţie Elementele pe care le stabiliţi pentru un câmp dat depind de tipul
de specificaţie pe care îl definiţi pentru acel câmp. O specificaţie
poate fi definită în 3 moduri:
 Unică – este specificaţia prestabilită pentru toate câmpurile,
excepţia celor care servesc ca şablon pentru alte câmpuri sau a
celor care participă drept chei externe într-o relaţie între tabele.
În acest tip de specificaţie puteţi include toate elementele, mai
puţin specificaţia sursă, iar parametrii de element pe care îi pre-
cizaţi se vor aplica doar asupra câmpului indicat elementul
Nume câmp.
 Generică – această specificaţie serveşte ca şablon pentru alte
specificaţii de câmp şi vă ajută să asiguraţi definiţii
consecvente pentru câmpurile care au acelaşi înţeles general.
De exemplu, puteţi crea acest tip de specificaţie pentru un
câmp generic numit JUDET, pe care să o utilizaţi apoi ca bază
pentru orice alt câmp JUDET din baza de date, cum ar fi
JUDET_CLIENT, JUDET_ANGAJAT, JUDET_FURNIZOR.
 Copie – este specificaţia prestabilită pentru un câmp bazat pe
62
un câmp generic sau pentru un câmp care joacă rol de cheie
externă într-o relaţie între tabele şi ea preia majoritatea
parametrilor de element dintr-o specificaţie existentă. Puteţi in-
clude elementele care nu sunt încorporate în specificaţia sursă
şi puteţi altera orice parametri de element preluaţi din
specificaţia sursă.
Specificaţie sursă Acest element este precizat doar într-o specificaţie copie şi indică
numele specificaţiei unui anumit câmp pe care se bazează
specificaţia curentă.
Elementele fizice se referă la structura unui câmp. Ele sunt exprimate în

termeni generali, deoarece fiecare program SGBDR le implementează într-
un mod uşor diferit. Stabilirea acestor elemente în timpul acestei faze a
procesului de proiectare vă ajută să asiguraţi definiţii consecvente ale
câmpurilor în întreaga bază de date şi reduce timpul necesar
implementărilor structurilor de câmp într-un program SGBDR. În tabelul
3.2 sunt prezentate aceste elemente.
Tab. 3.2. Elemente fizice

Tip de date Acest element indică natura datelor stocate de câmp. Standardul
SQL defineşte câteva tipuri majore de date şi fiecare tip de date
are una sau mai multe variante unice. Iată o scurtă definire a lor:
 Character – acest tip de dată stochează un şir alfanumeric de
lungime fixă sau variabilă.
 Bit – acest tip de date stochează şiruri cu secvenţe binare, cum
ar fi imagini digitizate sau secvenţe audio.
 Exact Numeric – stochează numere întregi sau zecimale.
Majoritatea programelor SGBDR implementează acest tip sub
numele de NUMERIC, ZECIMAL şi INTEGER.
 Approximate Numeric – stochează numere cu zecimale şi
numere exponenţiale. Majoritatea programelor SGBDR
implementează acest tip sub numele de FLOAT, REAL şi
DOUBLE.
 Date/Time – stochează date calendaristice, de timp şi
combinaţia lor. De menţionat faptul că acest tip de dată diferă
destul de mult de la un SGBDR la altul. Va trebui să studiaţi
documentaţia SGBDR pentru a afla cum gestionează programul
datele şi orele.
 Boolean – se foloseşte pentru valorile TRUE şi FALSE.
 Currency – se foloseşte pentru indicarea monedei.
Lungime Precizează numărul total de caractere ce pot fi introduse de un
utilizator pentru o valoare oarecare de câmp. Se foloseşte numai
pentru datele de tip Character.
Număr de zecimale Precizează numărul de zecimale ale unui număr.
Mască de Precizează modul în care utilizatorul trebuie să introducă data
63
introducere calen-daristică în câmp. Există mai multe moduri de introducere a
unei date calendaristice, cum ar fi „01/03/05”, „01-03-05” şi „01-
mar-2005”. Utilizarea unei măşti de introducere vă ajută să vă
asiguraţi că un utilizator va introduce valorile în câmp în mod
unitar. Iată un exemplu de introducere a unei măşti: „zz/ll/aa”,
pentru o dată de forma „01/03/05”.
Format de afişare Acest element gestionează aspectul valorii câmpului atunci când
este afişată pe ecran sau este tipărită într-un raport. Un format de
afişare vă permite să afişaţi valorile într-un mod mai firesc, mai
lizibil, ca de exemplu „18/04/05” ar putea fi afişat „18 aprilie
2005” care este mult mai uşor de citit şi înţeles.
Suport de Acest element indică tipul de caractere pe care un utilizator le
caractere poate introduce într-o valoare de câmp dată. Stabilirea şi
impunerea acestui element vă ajută să vă asiguraţi că utilizatorul
nu poate introduce în câmp date lipsite de sens, iar prin acest lucru
îmbunătăţiţi integritatea la nivel de câmp. Puteţi opta pentru
includerea sau excluderea oricăruia dintre următoarele tipuri de
caractere:
 Litere – toate literele alfabetului inclusiv cele speciale ş, ţ, ă, î.
 Cifre – de la 0 la 9.
 Caractere de pe tastatură - &, ^, =, virgula, !, (, ), %, $ etc.
 Caractere speciale – orice caracter pe care îl puteţi produce
prin combinaţii specifice de taste standard şi tastele Ctrl, Alt şi
Shift.
Elementele logice – se referă în special la valorile din interiorul unui

câmp. Elementele ei stabilesc lucruri cum ar fi unicitatea unei valori, când
trebuie introdusă o valoare, dacă o valoare poate fi editată sau nu, tipurile
de comparaţii şi operaţii ce pot fi efectuate cu fiecare valoare. Precizarea
acestor elemente vă ajută să stabiliţi şi să impuneţi mare parte din
integritatea la nivel de câmp. În tabelul 3.3 sunt prezentate aceste elemente.
Tab. 3.3. Elemente logice

Denumire element Explicaţii
Tip cheie Acest element indică rolul câmpului într-un tabel, rol pe care l-aţi
identificat când aţi stabilit cheia primară pentru tabel.
Structură cheie Acest element precizează dacă un câmp desemnat cheie primară
este o cheie primară simplă (un singur câmp) sau o cheie primară
compusă (cu mai multe câmpuri).
Unicitate Acest element precizează dacă valorile câmpului sunt unice. Îi
atribuiţi valoare „Unică” atunci când elementul Tip cheie are
valoarea „Primară”; în caz contrar acest element primeşte valoarea
„Non-unică”.
Suport valori nule Acest element precizează dacă un câmp acceptă sau nu valori nule.
Recitiţi paragraful Valoare nulă din capitolul 1 pentru a vă
reaminti ce sunt valorile nule. Pentru a verifica decizia luată, gân-
64
diţi-vă ce urmări ar avea necompletarea acelui câmp (valoare
nulă). Utilizaţi judicios valorile nule şi nu folosiţi spaţii goale.
Valori introduse de Acest element indică sursa valorilor câmpului. Această sursă poate
fi un operator, fie programul de aplicaţie al bazei de date care îl
completează automat.
Valoare obligatorie Acest element precizează dacă utilizatorul este obligat să
introducă o valoare pentru câmpul respectiv.
Valoare Aceasta este valoare pe care utilizatorul o poate introduce într-un
prestabilită câmp atunci când nu este disponibilă o valoare mai bună şi când
nu sunt permise valorile nule.
Interval de valori Acest element precizează toate posibilele valori valide pentru un
câmp. Acest lucru se poate face prin mai multe căi, ca de exemplu
cu un interval (1-999) sau cu ajutorul unei liste (CJ, MS, BN, AB).
Reguli de editare Acest element precizează în ce moment utilizatorul poate introdu-
ce o valoare într-un câmp şi dacă poate modifica respectiva
valoare. Momentul de referinţă este momentul când se creează o
nouă înregistrare.
Comparaţii Acest element indică tipurile de comparaţii pe care utilizatorul le
permise poate aplica asupra unei valori de câmp date, atunci când preia
informaţie din câmp. Există 6 tipuri de comparaţii, =, diferit de, >,
<, >=, <=, aşa cum se poate observa din formular. De asemenea,
se indică dacă un utilizator poate compara o valoare de câmp dată
cu una din următoarele:
 Altă valoare din acelaşi câmp.
 Valoarea unui alt câmp din tabelul părinte sau dintr-un alt tabel
al bazei de date.
 O valoare de expresie, care este o operaţie oarecare în care este
inclusă valoarea câmpului.
Controlul asupra tipului de comparaţii îl împiedică pe utilizator să
facă anumite comparaţii lipsite de sens.
Operaţii permise Acest element precizează tipurile de operaţii pe care utilizatorul le
poate efectua cu valorile unui câmp. Există 5 tipuri de operaţii:
adunare, scădere, înmulţire, împărţire şi concatenare. De
asemenea, acest element indică dacă o operaţie poate include
vreuna din următoarele:
 Altă valoare din acelaşi câmp.
 Valoarea unui alt câmp din tabelul părinte sau dintr-un alt tabel
al bazei de date.
 Rezultatul unei expresii în care este implicată valoarea
câmpului.
Controlul asupra tipului de operaţii previne efectuarea unor
operaţii fără sens, limitând tipurile de operaţii care se pot face cu
valorile unui câmp.
Această fază este o mare consumatoare de timp, de aceea tentaţia de a

„economisi” timp este foarte mare, ceea ce este o mare greşeală. Timpul
65
astfel economisit este iluzoriu, deoarece pierderile cu repararea mai târziu a
bazei de date va fi înzecit. Acordaţi acestei faze importanţa cuvenită, altfel
tot efortul dumneavoastră de până acum va fi zadarnic.

1. Enunţaţi două motive majore pentru care sunt importante specificaţiile
de câmp.
2. Ce câştigaţi prin stabilirea integrităţii la nivel de câmp?
3. Care sunt cele trei categorii de elemente dintr-o specificaţie de câmp?
4. Numiţi trei tipuri de specificaţii.
5. Ce indică elementul Tip de date?
6. Ce indică elementul Suport de caractere?
7. Care este scopul elementului Format de afişare?
8. Care este semnificaţia elementului Interval de valori?
9. Care este scopul unei reguli de editare?
10. Care este scopul elementului Comparaţii permise? Cine îl foloseşte
efectiv?
11. Ce este o valoare de expresie?
12. Când se utilizează o specificaţie generică? Daţi un exemplu.
13. Explicaţi formularul de specificaţii.
66
Etapa 4 - Determinarea şi instituirea relaţiilor între
tabele
Suntem în faza în care avem tabelele definitivate, completate cu câmpurile
lor bine definite şi cu cheile lor primare. Sarcina noastră următoare este de
a stabili relaţiile existente între aceste tabele. Ne reamintim că între două
tabele poate exista NUMAI o relaţie. De asemenea, un tabel poate avea
relaţii cu mai multe tabele, aşa cum să vedem în studiile de caz viitoare.
În capitolul 2, la paragraful Termeni referitori la relaţie au fost prezentate

pe scurt cele trei tipuri de relaţii care pot exista între două tabele. Vă
recomand să revedeţi acel paragraf pentru a vă reîmprospăta memoria.
În această etapă veţi învăţa cum să identificaţi şi să stabiliţi relaţii între

tabelele unei baze de date şi apoi cum să stabiliţi caracteristicile fiecărei
relaţii. De asemenea, veţi învăţa cum să creaţi diagrame cu tabele şi relaţii,
lucru care vă va permite să realizaţi o reprezentare grafică a structurii
întregii baze de date.
Despre importanţa relaţiilor nu mai trebuie să vorbim, decât că ele sunt

capitale pentru funcţionarea corectă a bazei de date. Ele asigură conexiuni
între tabelele corelate logic, ajută la îmbunătăţirea structurilor de tabel şi
permit extragerea datelor din mai multe tabele simultan.
În continuare vor fi prezentate pe larg cele trei tipuri de relaţii cunoscute.
Stabilirea relaţiilor “unu cu unu”
Două tabele au o relaţie unu cu unu când o singură înregistrare din primul
tabel este corelată cu o singură înregistrare din al doilea tabel şi o singură
înregistrare din al doilea tabel este corelată cu o singură înregistrare din
primul tabel. Figura 3.6 prezintă un exemplu generic de relaţie „unu cu
unu”.
Tabel A Tabel B
Fig. 3.6. Exemplu generic de relaţie „unu la unu”

67
După puteţi vedea, o înregistrare din TABELUL A este corelată cu o
singură înregistrare din TABELUL B, iar o înregistrare din TABELUL B
este corelată cu o singură înregistrare din TABELUL A. O relaţie unu cu
unu implică de obicei un tabel subset. Figura 3.7 prezintă un exemplu de
relaţie „unu cu unu” tipică pe care o puteţi găsi într-o bază de date pentru
departamentul Personal al unei organizaţii.
Angajati
SalariatID Nume Prenume Telefon <<alte câmpuri>>
100 Ban Ioan 0745-646321 …..
101 Pop Dorin 0723-548211 …..
102 Lazăr Liviu 0264-542138 …..
103 Crişan Ovidiu 0740-764282 …..
Retributii
SalariatID Salar orar Sporuri <<alte câmpuri>>
100 34.50 10% …..
101 23.00 5% …..
102 17.45 20% …..
103 16.00 18% …..
Fig. 3.7. Exemplu de relaţie „unu la unu”
Deşi câmpurile din aceste tabele pot fi combinate într-un singur tabel,
proiectantul bazei de date a ales să plaseze în tabelul ANGAJATI
câmpurile ce pot fi văzute de orice membru al organizaţiei şi în tabelul
RETRIBUTII câmpurile ce pot fi văzute doar de personalul autorizat.
Pentru stocarea datelor privitoare la retribuţia unui angajat dat este
necesară doar o singură înregistrare, deci între o înregistrare din tabelul
ANGAJATI şi una din tabelul RETRIBUTII există o relaţie distinctă „unu
cu unu”.
Figura 3.8 prezintă un exemplu generic al modului în care se creează o

diagramă de relaţie pentru o relaţie “unu la unu”.
68
Această linie arată că o înregistrare din Această linie arată că o înregistrare din
TABELUL B este corelată cu o singură TABELUL A este corelată cu o singură
înregistrare din TABELUL A înregistrare din TABELUL B
Tabel A Tabel B
Tabel normal Tabel subset
Fig. 3.8. Realizarea unei diagrame generice pentru o

relaţie „unu la unu”
Observaţi că tabelul din stânga este un tabel normal (simbolizat printr-un

dreptunghi), iar cel din dreapta este un tabel subset (simbolizat printr-un
dreptunghi cu colţurile rotunjite). Linia care apare între tabelele din
diagramă indică tipul de relaţie şi pentru fiecare tip de relaţie veţi utiliza un
anumit tip de linie. Aici fiecare capăt are o „liniuţă” pentru relaţia “unu la
unu”.
Această
Observaţi linie arată
că tabelul dincăstânga
o este un tabel normal (simbolizat printr-un
dreptunghi), iar cel din dreapta B
înregistrare din TABELUL este un tabel subset (simbolizat printr-un
este corelată
dreptunghi cu o singură
cu colţurile rotunjite). Linia care apare între tabelele din
înregistrare
diagramă indică tipul de relaţie şi pentru fiecare tip de relaţie veţi utiliza un
din TABELUL
anumit
A tip de linie. Aici fiecare capăt are o „liniuţă” pentru relaţia “unu la
unu”.
În figura 3.9 este prezentată diagrama relaţiei dintre tabelele ANGAJATI şi

RETRIBUTII.
Angajati Retributii
Nume tabel Nume tabel

Fig. 3.9. Diagrama relaţiei dintre
tabelele SALARIATI şi SALARIU
Nume tabel 69
Observaţi că cele două tabele sunt simbolizate diferit, un dreptunghi şi un
dreptunghi cu colţurile rotunjite, primul fiind considerat tabel de date iar al
doilea este considerat tabel subset.
Stabilirea relaţiilor “unu cu mai mulţi”
Între două tabele există o relaţie “unu cu mai mulţi” când o înregistrare din
primul tabel poate fi corelată cu una sau mai multe înregistrări din al doilea
tabel, în timp ce o înregistrare din al doilea tabel poate fi corelată cu o
singură înregistrare din primul tabel. Să studiem un exemplu generic
pentru acest tip de relaţie.
Să presupunem că lucraţi cu două tabele TABEL A şi TABEL B, între care

există o relaţie „unu cu mai mulţi”. Datorită relaţiei, o înregistrare din
TABEL A poate fi corelată cu una sau mai multe înregistrări din TABEL
B. De asemenea, în sens invers, o înregistrare din TABEL B poate fi
corelată cu singură înregistrare din TABEL A
Figura 3.10 prezintă acest tip de relaţie.
Tabel A Tabel B
Tabel A Tabel B
Fig. 3.10. Exemplu generic de relaţie „unu cu mai mulţi”
70
Relaţia “unu cu mai mulţi” este cea mai obişnuită relaţie care există între
două tabele dintr-o bază de date şi este cea mai uşor de identificat. Relaţia
este extrem de importantă din punct de vedere al integrităţii datelor,
deoarece ea vă ajută să eliminaţi datele duplicate. Figura 3.11 prezintă un
exemplu obişnuit de relaţie “unu cu mai mulţi” pe care o puteţi întâlni la o
secţie de împrumut a unei biblioteci.
Imprumuturi
Clienti ClientID CarteID Data
ClientID Nume Prenume <<alte câmp.>> 9002 5648 ....
9001 Pop Dorin ....... 9001 690423 ....
9002 Ban Ion ....... 9004 6563 ....
9003 Lazăr Ana ....... 9003 65323 ....
9004 Buzan Maria ....... 9003 09542 ....
9005 Beldean Vian ....... 9003 64823 ....
9002 75001 ....
9005 10045 ....
9005 76100 ....
Fig. 3.11. Exemplu de relaţie „unu cu mai mulţi”
Un client al bibliotecii poate împrumuta oricâte cărţi, deci o înregistrare

din tabelul CLIENTI poate fi corelată cu una sau mai multe înregistrări din
tabelul ÎMPRUMUTURI. Însă o carte este asociată, în orice moment, doar
cu un singur client, deci o înregistrare din tabelul ÎMPRUMUTURI este
corelată doar cu o singură înregistrare din tabelul CLIENTI. Evident, am
introdus o ipoteză, cum că o carte se găseşte într-un singur exemplar.
În figura 3.12 este prezentat un exemplu generic pentru modul de creare a

diagramei de relaţie „unu cu mai mulţi”.
71
Această linie arată că o înregistrare din

TABELUL B este corelată cu o singură
înregistrare din TABELUL A
Tabel A Tabel B
Nume tabel Această „labă de gâscă” arată că o Nume tabel

înregistrare din TABELUL A este corelată
cu mai multe înregistrări din TABELUL B
Fig. 3.12. Realizarea diagramei pentru

o relaţie „unu cu mai mulţi”
Nume tabel
Observaţi că simbolul „labă de gâscă” este întotdeauna localizat în dreptul
tabelului din partea „mulţi” a relaţiei. Figura 3.13 prezintă diagrama
relaţiei dintre Această
tabelelelinie arată că şi
CLIENTI o ÎMPRUMUTURI din figura 3.11.
Reţineţi acesteînregistrare
notaţii pentru că le veţi Bfolosi în prezentarea structurii
din TABELUL
Nume
bazelor de date petabel
care le veţi proiecta.
este corelată cu o singură
înregistrare din TABELUL A
Clienti Imprumuturi
Imprumuturi
Nume tabelDiagrama relaţiei dintre tabelele Clienti

Fig. 3.13. Numeşitabel
Imprumuturi
Acest tip de relaţie cel mai reprezentativ dintre două

Nume tabele a unei baze de
date, este uşor de identificat şi de înţeles. tabel(B)
Nume tabel
Nume tabel
Nume tabel
Nume
tabel(A) 72
Această linie arată că o

Stabilirea relaţiilor ”mai mulţi cu mai mulţi”
Între două tabele există o relaţie de “mai mulţi cu mai mulţi” când o
înregistrare din primul tabel poate fi corelată cu una sau mai multe
înregistrări din al doilea tabel şi o înregistrare din al doilea tabel poate fi
corelată cu una sau mai multe înregistrări din primul tabel.
Să presupunem că lucraţi cu două tabele, TABEL A şi TABEL B şi între

ele există o relaţie de “mai mulţi cu mai mulţi”. Datorită relaţiei, o
înregistrare TABEL A poate fi corelată cu una sau mai multe înregistrări
din TABEL B şi o înregistrare din TABEL B poate fi corelată cu una sau
mai multe înregistrări din TABEL A, aşa cum se poate vedea în figura
3.14.
Tabel A Tabel B
Tabel A Tabel B
Tabel A Tabel B
Tabel A Tabel B
Tabel A Tabel B
Fig. 3.14. O relaţie „mai mulţi cu mai mulţi” din perspectiva ambelor tabele
Tabel A Tabel B
Tabel A
Acest tip de relaţie este al doilea ca frecvenţă de apariţie
Tabel B între două tabele
dintr-o bază de date. Ea este ceva mai dificil de identificat decât o relaţie
„unu cu mai mulţi”, deci trebuie să vă asiguraţi că aţi examinat tabelele cu
atenţie.
Tabel A Tabel B
Figura 3.15 prezintă un exemplu tipic de relaţie
Tabel A “maiB mulţi cu mai mulţi”
Tabel
pe care o puteţi întâlni în baza de date a unei instituţii de învăţământ,
respectiv tabelul cu studenţii şi tabelul cu toate cursurile care se ţin în acea
universitate.
Tabel A Tabel B
Tabel A Tabel B
73
Tabel A Tabel B
Studenti
StudentID Nume Prenume OrasStudent <<alte câmpuri>>
6001 Pop Remus Reghin .....
6002 Szabo Zoltan Oradea .....
6003 Costea Florian Zalau .....
6004 Timocea Sebastian Brasov .....
6005 Mocean Vasile Fagaras .....
Cursuri
CursID Denumire Credite ProfesorID Sala <<alte câmpuri>>
C001 PUC 5 2001 208 .....
C213 Baze de date 5 2001 208 .....
C032 SIM 4 2045 208 .....
C015 GD 5 2014 207 .....
G001 AutoCAD 4 2009 207 .....
G004 Inventor 5 2006 209 .....
G007 IntelliCAD 5 2032 209 .....
Fig. 3.15. Exemplu tipic de relaţie „mai mulţi cu mai mulţi”
Pe parcursul unui an şcolar, un student poate participa la unul sau mai

multe cursuri, deci o înregistrare din tabelul STUDENTI poate fi corelată
cu una sau mai multe înregistrări din tabelul CURSURI. În sens invers, la
un curs pot participa unul sau mai mulţi studenţi, deci o înregistrare din
tabelul CURSURI poate fi corelată cu una sau mai multe înregistrări din
tabelul STUDENTI.
Figura 3.16 prezintă un exemplu generic al modului de creare a diagramei

de relaţie “mai mulţi cu mai mulţi”. În acest caz, lângă fiecare tabel există
un simbol “labă de gâscă”.
Figura 3.17 prezintă diagrama relaţiei dintre tabelele STUDENTI şi

CURSURI din figura 3.15.
74
Această „labă de gâscă” arată că o

înregistrare din TABELUL B este corelată cu
mai multe înregistrări din TABELUL A
Tabel A Tabel B
Această „labă de gâscă” arată că o

înregistrare din TABELUL A este corelată cu
mai multe înregistrări din TABELUL B
Fig. 3.16. Realizarea diagramei pentru o relaţie „mai

mulţi cu mai mulţi”
Studenti Cursuri
Fig. 3.17. Diagrama relaţiei dintre tabelele STUDENTI

şi CURSURI
O astfel de relaţie este una nerezolvată, adică nu se poate stabili o legătură

coerentă între înregistrările celor două tabele, neputându-se efectua o
interogare în care să fie implicate cele două tabele. După cum vedeţi, între
cele două tabele nu există o legătură reală, deci nu aveţi cum să asociaţi
înregistrările dintr-un tabel cu înregistrările din celălalt tabel. O metodă cu
care aţi putea stabili o legătură între cele două tabele ar fi preluarea unui
câmp dintr-unul din tabele şi introducerea lui de un număr de ori în celălalt
tabel. Această idee este prima care ne vine în minte, dar nu este o idee
bună, deoarece măreşte nejustificat unul din tabele, fără a rezolva însă, în
totalitate problema.
O altă metodă pentru a stabili o legătură coerentă, este introducerea unui

tabel de legătură între cele două tabele.
75
Un tabel de legătură facilitează asocierea înregistrărilor dintr-un tabel cu
înregistrările din celălalt tabel şi asigură lipsa oricăror probleme la
operaţiile de adăugare, ştergere sau modificare a datelor corelate. Un tabel
de legătură se defineşte prin preluarea unor cópii ale cheii primare din
fiecare tabel şi utilizarea lor pentru a forma structura noului tabel. În
realitate, aceste câmpuri îndeplinesc două roluri distincte: împreună
formează cheia primară compozită a tabelului de legătură, iar separat,
fiecare poate fi asimilată unei chei externe.
Să reluăm tabelele din figura 3.15, şi ne punem întrebarea cum putem

asocia cu uşurinţă înregistrări din primul tabel cu înregistrări din al doilea
tabel? Altfel spus, cum putem asocia un student cu mai multe cursuri sau
un anumit curs cu mai mulţi studenţi? Cea mai bună metodă este de crea şi
utiliza un tabel de legătură care va rezolva relaţia de tip mai mulţi cu mai
mulţi în maniera cea mai adecvată şi mai eficientă. Figura 3.18 prezintă
rezolvarea practică a acestei soluţii.
Studenti
6001 Pop Remus Reghin .....
6002 Szabo Zoltan Oradea .....
6003 Costea Florian Zalau .....
6004 Timocea Sebastian Brasov .....
6005 Mocean Vasile Fagaras .....
Orar(tabel de legătură)
StudID CursID
6001 C001 Cursuri
6002 C213 CursID Denumire Credite ProfID
6002 C032 C001 PUC 5 2001
6001 C213 C213 SIM 5 2001
6002 C015 C032 Baze de date 4 2045
6003 C001 C015 GD 5 2014
6004 C213 G001 AutoCAD 4 2009
6001 C015 G004 Inventor 5 2006
6003 G001 G007 IntelliCAD 5 2032
6001 G004
6005 G007
Fig.3.18. Rezolvarea unei relaţii de tip mai mulţi cu mai

mulţi cu ajutorul unui tabel de legătură
76
Se observă că tabelul de legătură are mai multe înregistrări decât oricare
din tabelele pe care le leagă. De asemenea, între fiecare din cele două
tabele şi tabelul de legătură există o relaţie de tip unu cu mai mulţi. Prin
urmare, o relaţie de tip mai mulţi cu mai mulţi s-a transformat în două
relaţii unu cu mai mulţi, aşa cum se poate vedea în figura 3.19.
Studenti Orar Cursuri
StudentID StudentID CursID

Nume CursID Denumire
Prenume Credite
OrasStudent ProfesorID
-------- Sala
--------
Fig. 3.19. Diagrama de relaţie a

problemei rezolvate
Observaţi din figura 3.19 reprezentarea tabelului de legătură, cu cel două

linii verticale, în stânga şi dreapta dreptunghiului.
Relaţii cu autoreferire
Acest tip particular de relaţie nu există între două tabele, motiv pentru care
nu a fost amintit la tipuri de relaţii. Acest tip de relaţie există însă
înregistrările dintr-un tabel. Pe parcursul procesului de proiectare o vom
considera, totuşi, ca fiind o relaţie între tabele.
Un tabel are cu el însuşi o relaţie cu autoreferire (cunoscută şi sub numele

de relaţie recursivă) dacă o anumită înregistrare din tabel este corelată cu
alte înregistrări din acelaşi tabel. Similar tipului echivalent de relaţie pentru
perechi de tabele, o relaţie cu autoreferire poate fi „unu cu unu”, „unu cu
mai mulţi” şi „mai mulţi cu mai mulţi”.
Relaţia „unu cu unu” există când o înregistrare dată dintr-un tabel poate
fi corelată cu o singură înregistrare din acelaşi tabel. Tabelul MEMBRII
din figura 3.20 este un exemplu de tabel care are acest tip de relaţie. Astfel,
un membru dat poate sponsoriza un singur alt membru din organizaţie;
câmpul SponsorID stochează numărul de identificare al membrului care
77
joacă rolul de sponsor. Observaţi că Mocean Pavel sponsorizează pe
Obădău Anica.
Membrii
MembruID Nume Prenume SponsorID <<alte câmpuri>>
1001 Pop Dorin ------
1002 Mocean Pavel 1001 ------
1003 Ban Ionel ------
1004 Ban Lucia 1003 ------
1005 Obădău Anica 1002 ------
Fig. 3.20. Relaţie cu autoreferire „unu cu unu”
Diagrama unei astfel de relaţii se poate vedea în figura 3.21.
Membrii
Această linie laterală a tabelului Fig. 3.21. Diagrama unei relaţii cu

arată natura de auto-referiere a auto-referire „unu cu unu”
relaţiei şi tipul relaţiei.
Relaţia „unu cu mai mulţi” cu autoreferire există atunci când o

înregistrare dată din tabel poate fi corelată cu una sau mai multe
înregistrări din acelaşi tabel. Figura 3.22 arată un exemplu în care un
angajat poate fi şeful mai multor angajaţi. Observaţi că Pop Dorin este
şeful la alţi trei angajaţi.
Personal
AngajatID Nume Prenume Sef <<alte câmpuri>>
1001 Mocean Pavel 1002 ------
1002 Pop Dorin ------
1003 Ban Ionel ------
1004 Ban Lucia 1002 ------
1005 Obădău Anica 1002 ------
Fig. 3.22. Relaţie cu autoreferire „unu cu mai mulţi”
78
Figura 3.23 arată diagrama acestei relaţii.
Personal
Fig. 3.23. Diagrama

relaţiei cu auto-referire
„unu cu mai mulţi”
Relaţia „mai mulţi cu mai mulţi” cu autoreferire există când o

înregistrare dată dintr-un tabel poate fi corelată cu una sau mai multe
înregistrări din acelaşi tabel şi una sau mai multe înregistrări pot fi corelate
cu înregistrarea dată. La început, acest lucru poate apărea confuz, dar
exemplul care urmează o să vă ajute să clarificaţi problema (figura 3.24).
În acest caz, o anumit subansamblu poate fi compus din mai multe piese
componente diferite şi poate fi la rândul lui component al unui alt
subansamblu.
Piese
PiesaID Denumire piesa <<alte câmpuri>>
7001 Clema superioară .....
7002 Clema inferioară .....
7003 Şurub de strângere .....
7004 Piulită .....
7005 Ansamblu clemă .....
7006 Scaun .....
7007 Ansamblu scaun .....
7008 Corp tubular .....
7009 Suport spate .....
7010 Ansamblu cadru .....
7011 Şa .....
Fig. 3.24. Exemplu de relaţie cu autoreferire „mai mulţi

cu mai mulţi”
Subansamblu clemă (7005) este compus din patru piese (7001, 7002, 7003,
7004), deci înregistrarea respectivă poate fi corelată cu 4 înregistrări din
acelaşi tabel. În plus, subansamblu clemă intră în componenţa ansamblului
79
scaun (7007) şi al ansamblului cadru (7010), deci 2 înregistrări din tabel
pot fi corelate cu ea. Figura 3.25 prezintă diagrama pentru acest tip de
relaţie.
Piese
Fig. 3.25. Diagrama unei

relaţii cu autoreferire „mai
mulţi cu mai mulţi”
Pasul următor pe care trebuie să-l facem este identificarea relaţiilor care
există în mod curent între tabelele dintr-o bază de date.
Identificarea relaţiilor existente
În această fază avem structura finală a tabelelor, împreună cu descrierea

lor. Am văzut în paragrafele anterioare care sunt cele trei relaţii care pot
exista între tabele. Problema care se pune acum este aceea de a afla tehnica
prin care veţi identifica relaţiile dintre tabelele bazei de date la proiectarea
căreia lucraţi, ştiut fiind că această activitate nu este simplă. Experienţa
personală joacă aici un rol important deoarece nu există reguli foarte clare
pe cale să le aplicaţi.
În analiza pe care aţi făcut-o în timpul proiectării bazei de date, aţi stat de
vorbă cu multe persoane din organizaţia beneficiară, atât din conducere cât
şi din compartimentele care vor folosi nemijlocit baza de date. Ei bine,
aceste persoane vă vor fi de un real folos în identificarea relaţiilor dintre
tabele, chiar dacă ele nu au o viziune completă asupra problemei în cauză.
Începeţi procesul de identificare a relaţiilor prin crearea unei matrice cu

toate tabelele bazei de date. Pentru aceasta puteţi folosi o foaie de hârtie, o
tablă sau programul Excel. De exemplu, să presupunem că lucraţi cu
următoarele tabele:
CLADIRI
CURSURI
INDEMNIZATIE
CATEDRA
80
SALI
PERSONAL
STUDENTI
Scrieţi tabelele în partea de sus a matricei şi încă o dată în partea stângă a
matricei, ca în figura 3.26.
Cladiri Cursuri Indemnizatie Catedra Sali Personal Studenti

Cladiri
Cursuri
Indemnizatie
Catedra
Sali
Personal
Studenti
Fig. 3.26. Realizarea unei matrice de tabele pentru stabilirea relaţiilor
Selectaţi câte un tabel din partea stângă a matricei şi verificaţi dacă el are
vreo relaţie cu vreunul din tabelele din partea de sus, parcurgând matricea
pe linie. Ţineţi minte că nu căutaţi decât relaţiile directe – între tabelele
care participă la relaţie trebuie să existe o conexiune specifică. De
exemplu, tabelul CURSURI are o relaţie directă cu tabelul STUDENTI,
deoarece cursurile există ca să fie urmate de studenţi. Tabelul CURSURI
are o relaţie indirectă cu tabelul PERSONAL, prin intermediul tabelului
CATEDRA; un curs este predat de un membru al catedrei, nu de un
membru al personalului. Nu trebuie să vă ocupaţi încă de relaţiile indirecte.
Dacă nu vedeţi de la început relaţia dintre două tabele, o bună metodă este
de a „popula” tabelele cu câteva înregistrări care vă vor ajuta în depistarea
acestor relaţii. În şedinţa de lucru pentru stabilirea relaţiilor între tabele veţi
pune întrebări de genul:
 Poate o înregistrare din CURSURI să fie asociată cu una sau mai
multe înregistrări din tabelul CLADIRI?
 Se poate găsi o legătură între PERSONAL şi STUDENTI?
Reţineţi că pentru a stabili relaţia corectă dintre două tabele, veţi pune două
întrebări, una din perspectiva primului tabel şi una din perspectiva celuilalt
tabel. Răspunsurile la aceste două întrebări vor identifica tipul de relaţie
care există între cele două tabele.
81
După ce aţi identificat relaţia, indicaţi tipul relaţiei în celula aflată la
intersecţia dintre liniile celor două tabele. Pentru tipurile de relaţii folosiţi
următoarele prescurtări:
 1:1 - pentru relaţia unu cu unu.
 1:M - pentru relaţia unu cu mai multi.
 M:M - pentru relaţia mai mulţi cu mai mulţi.
În figura 3.27 este arătată matricea de tabele cu completată cu relaţiile

tabelului CURSURI.
Cladiri 1:M 1:M
Cursuri 1:1 1:M 1:1
Indemnizatie
Catedra
Sali
Personal
Studenti
Fig. 3.27. Intrările în matricea de tabele, pentru tabelele CLADIRI şi CURSURI
Iată cum putem comenta notaţiile din figura 3.21, începând din stânga sus:
 1:M - într-o clădire se pot ţine mai multe cursuri.
 1:M - o clădire are mai multe săli.
 1:1 - un curs se poate ţine numai într-o clădire.
 1:M - un curs poate aparţine mai multor catedre
 1:1 - un curs se ţine numai într-o sală.
Dacă între tabele nu există nici un fel de relaţie, lucru perfect normal,
celula corespunzătoare va fi goală. Deseori, relaţiile între două tabele vor
diferi de la o perspectivă la alta (depinde din ce parte privesc) şi trebuie să
ştiţi cum să determinaţi tipul oficial de relaţie dintre fiecare pereche de
tabele din matrice. Veţi stabili acest lucru utilizând următorul set de
formule:
 1:1 + 1:1 = 1:1
 1:M + 1:1 = 1:M
 1:M + 1:M = M:M
82
Iată, în rezumat, procedura specifică pe care o veţi utiliza la identificarea
relaţiei oficiale între două tabele din matrice, procedura incluzând
formulele de relaţie de mai sus:
1. Selectaţi o pereche de tabele şi notaţi intrarea de la intersecţia dintre
linia primului tabel şi coloana celui de-al doilea.
2. Localizaţi al doilea tabel pe aceeaşi parte a matricei pe care lucraţi şi
notaţi intrarea de la intersecţia liniei acestuia cu coloana primului
tabel.
3. Asupra celor două intrări aplicaţi una din formulele de mai sus şi
stabiliţi relaţia oficială dintre cele două tabele.
4. Construiţi diagrama relaţiei în mod corespunzător.
5. Tăiaţi ambele intrări din matrice.
Pentru cazul concret al perechii de tabele CLADIRI şi CURSURI,

rezultatul se vede în figura 3.28.

Cladiri 1:M 1:M
Cursuri 1:1 1:M 1:1 1:M
Indemnizatie 1:1
Catedra 1:M 1:1
Sali 1:1 1:M
Personal 1:1 1:1 1:M
Studenti 1:M
Fig. 3.28. Identificare relaţiei oficiale pentru perechea CLADIRI şi CURSURI
Relaţia oficială rezultată este 1:M – unu cu mai mulţi, rezultată din
compunerea relaţiilor din cele două sensuri.
Relaţia „unu cu unu” poate fi identificată observând că un tabel joacă rol

de tabel părinte şi celălalt joacă rol de tabel copil (subordonat). În tabelul
părinte trebuie să existe cel puţin o înregistrare înainte să puteţi introduce
în tabelul copil o înregistrare corelată, adică un copil nu poate exista fără
părinte, nu-i aşa?
Atribuirea rolului de părinte şi copil nu este totdeauna un lucru foarte clar,

existând cazuri când această atribuire se face arbitrar. Un lucru trebuie să
vă fie clar: relaţia unu cu unu poate fi asemuită cu un tabel mare rupt în
două, iar într-unul dintre ele s-a copiat câmpul cheie primară, care devine
83
cheie externă. De fapt, acesta este şi mecanismul cu care se relaţiile unu cu
unu.
Iată un caz concret de construcţie a unei relaţii unu cu unu (figura 3.29).
Presupunem că avem tabelul Personal, care conţine toate câmpurile legate
de descrierea unui angajat. Acest tabel se va „rupe” în două pentru a separa
datele confidenţiale de cele publice.
Personal-1
AngajatID ChP
Personal Nume
AngajatID ChP
Prenume
Nume Data nasterii
Prenume Data angajarii
Data nasterii
Specializare
Data angajarii
Adresa
Specializare
Telefon acasa
Adresa
Mobil
Telefon acasa E-mail
Mobil Web
E-mail
Web
Salariu Personal-2
Indemnizatie AngajatID ChE
Asigurare Salariu
Tip plan medical Indemnizatie
Asigurare
Tip plan medical
Fig. 3.29. Exemplu de creare a unei relaţii unu cu unu
Între PERSONAL-1 şi PERSONAL-2 există o relaţie unu cu unu foarte

clară şi uşor de depistat. Cheia primară în primul tabel, AngajatID a
devenit cheie externă în al doilea tabel, după cum se vede în figură.
În unele cazuri, mai pot fi forţate unele relaţii unu cu unu, fără ca aceste
tabele sa aibă altceva comun decât cheia primară a unuia copiată în celălalt
tabel. Practica o să vă scoată în cale şi un astfel de caz.
Relaţia „unu cu mai mulţi” poate fi stabilită într-un mod asemănător cu

relaţia „unu cu unu”. Veţi lua, pur şi simplu, o copie a cheii primare din
84
tabelul aflat în partea „unu” a relaţiei şi o veţi include în structura tabelului
din partea „mai mulţi”, unde va deveni cheie externă.
Pentru exemplificare, fie relaţia „unu cu mai mulţi” dintre tabelele

CLADIRI şi SALI, prezentată în figura 3.30.
Cladiri Sali
CladireID ChP SalaID ChP

Numar etaje Tip sala
Acces lift Nr locuri
Acces parcare Acces Intrenet
Fig. 3.30. Relaţia de tip „unu cu mai mulţi” existentă între

tabelele CLADIRI şi SALI
Relaţia logică între aceste tabele este că o clădire are mai multe săli, dar o
sală se găseşte numai într-o clădire. Utilizând procedura anterioară, veţi
stabili această relaţie luând o copie a cheii primare (CladireID) din tabelul
CLADIRI pe care o includeţi drept cheie externă în tabelul SALI.
Diagrama revizuită trebuie să fie ca cea prezentată în figura 3.31.
Sali
Cladiri
SalaID ChP
CladireID ChP CladireID ChE
Numar etaje Tip sala
Acces lift Nr locuri
Acces parcare Acces Intrenet
Fig. 3.31. Stabilirea relaţiei „unu cu mai mulţi”

între tabelele CLADIRI şi SALI
Relaţia „mai mulţi cu mai mulţi” se stabileşte cu ajutorul unui tabel de

legătură. Deci, va trebui să creaţi un nou tabel în baza de date, parcurgând
următorii paşi:
85
 Se defineşte tabelul de legătură luând cópii ale cheii primare din
fiecare tabel al relaţiei şi utilizând aceste chei pentru a forma
structura tabelului. În tabelul de legătură, aceste câmpuri au două
scopuri distincte: împreună ele constituie cheia primară compusă
a tabelului şi fiecare este o cheie externă unică care ajută la
stabilirea unei relaţii unu cu mai mulţi între tabelul său părinte şi
tabelul de legătură.
 Se dă tabelului de legătură un nume care să reprezinte natura
relaţiei dintre cele două tabele. De exemplu, între tabelele
STUDENTI şi CURSURI, numele tabelului de legătură ar putea
fi CURSURI STUDENT sau ORAR STTUDENT.
 Se adaugă tabelul de legătură în lista finală de tabele şi se
completează rubricile „Tip tabel” şi „Descriere tabel”.
Figura 3.32 vă arată cum stabiliţi o relaţie „mai mulţi cu mai mulţi” între
tabelele STUDENTI şi CURSURI. (Observaţi noul simbol de diagramă
pentru tabelul de legătură.)
Studenti Cursuri
Cursuri Student
StudentID ChP CursID ChP
Nume StudentID ChPC/ChE Denumire
Prenume CursID ChPC/ChE Credite
Data nasterii ProfesorID
Adresa Categorie
Telefon
E-mail
Fig. 3.32. Stabilirea unei relaţii „mai mulţi cu mai mulţi”

între tabelele STUDENTI şi CURSURI
Observaţi că mecanismul de stabilire a relaţiei „mai mulţi cu mai mulţi” nu

face altceva decât să transforme această relaţie în două relaţii „unu cu mai
mulţi”, adăugând în acelaşi timp un tabel nou în baza de date.
Relaţiile cu autoreferire se stabilesc relativ simplu deoarece se aplică

aceleaşi proceduri ca şi la cele 3 relaţii dintre două tabele diferite. Pentru
rezolvarea elegantă a relaţiilor cu autoreferire, o idee bună e să evităm
aceste relaţii prin regândirea structurii tabelului şi crearea altor tabele
subset. Este o idee pe care o aplic curent şi a dat rezultate bune.
86
Astfel, cazul tabelului prezentat la paragraful „Relaţii cu autoreferire”, cel
din figura 3.22, se poate rezolva mai simplu dacă introducem în baza de
date un nou tabel numit SEFI, cu care să stabilim o relaţie „unu cu mai
mulţi”. În acest fel câmpul SEF ar putea deveni cheie externă, numindu-se
SefID.
Stabilirea caracteristicilor relaţiilor
După ce aţi stabilit toate relaţiile care se găsesc între tabelele bazei
dumneavoastră de date, urmează să stabiliţi caracteristicile fiecărei relaţii.
Aceste caracteristici arată ce se întâmplă atunci când ştergeţi o înregistrare,
care este tipul de participare şi gradul de participare a fiecărui tabel în
relaţie.
Definirea unei reguli de ştergere
Prima caracteristică pe care o stabiliţi pentru relaţie este o regulă de

ştergere. Această regulă stabileşte ce trebuie să facă programul SGBDR
când cereţi să şteargă o anumită înregistrare din tabelul părinte al relaţiei.
Regulile de ştergere sunt extrem de importante pentru integritatea la nivel
de relaţie deoarece ele vă protejează împotriva înregistrărilor orfane –
înregistrări din tabelul copil care nu au nici un fel de relaţie cu nici o
înregistrare din tabelul părinte.
Puteţi defini 5 tipuri de reguli de ştergere, iar acţiunile pe care le va efectua

programul SGBDR, în cazul fiecărei reguli sunt următoarele:
 Interdicţie. Programul SGBDR nu va şterge înregistrarea din
tabelul părinte, ci o va păstra şi o va desemna ca “inactivă”.
 Restricţie. Programul SGBDR nu va şterge înregistrarea din
tabelul părinte dacă în tabelul copil există înregistrări corelate.
Programul SGBDR trebuie să şteargă toate înregistrările corelate
din tabelul copil înainte să poată şterge înregistrarea din tabelul
părinte.
 În cascadă. Programul SGBDR va efectua două acţiuni specifice:
va şterge înregistrarea din tabelul părinte, apoi automat, va şterge
toate înregistrările corelate din tabelul copil.
 Anulare. Programul SGBDR va şterge înregistrarea din tabelul
părinte apoi va actualiza la valoare nulă valorile cheii externe ale
87
înregistrărilor corelate din tabelul copil. Dacă intenţionaţi să
utilizaţi această regulă de ştergere, trebuie să modificaţi
specificaţia de câmp a cheii externe şi să atribuiţi elementul logic
Suport valori nule, valoarea “Se acceptă valori nule”.
 Folosire valoare prestabilită. Programul SGBDR va şterge
înregistrarea din tabelul părinte apoi va actualiza valoarea cheii
externe ale înregistrărilor corelate din tabelul copil la valoarea
curentă a elementului logic Valoare prestabilită din specificaţia
de câmp a cheii externe. Evident, ca să puteţi utiliza această
regulă, trebuie să fi introdus o valoare la elementul Valoare
prestabilită.
În general, este recomandabil să utilizaţi regula de ştergere Restricţie şi

celelalte reguli, după necesităţi.
Identificarea tipului de participare a fiecărui tabel
După cum se ştie de la capitolul 1, când stabiliţi o relaţie între două tabele,
fiecare tabel participă la relaţie într-o manieră particulară. Tipul de
participare pe care îl atribuiţi unui tabel dat determină dacă în respectivul
tabel trebuie să existe o înregistrare înainte de a putea introduce înregistrări
în tabelul corelat. Există 2 tipuri de participări:
Obligatorie - tabelul trebuie să conţină cel puţin o înregistrare înainte de a
putea introduce înregistrări în tabelul corelat.
Opţională – nu este obligatoriu ca tabelul să conţină vreo înregistrare
înainte de a putea introduce înregistrări în tabelul corelat.
De obicei, pentru majoritatea tabelelor, veţi determina tipul de participare

după ce definiţi regulile de lucru cu baza de date. În majoritatea cazurilor,
tipul de participare este evident, este de bun simţ sau este în concordanţă
cu un anumit set de standarde.
Pentru exemplificare, să luăm relaţia „unu cu mai mulţi” dintre tabelele

ANGAJATI şi CLIENTI, din figura 3.33.
88
Angajati Clienti
ClientID ChP
AngajatID ChP AngajatID ChE
............
Fig. 3.33. Ce tip de participare trebuie

atribuit fiecărui tabel?
Să presupunem că fiecare client trebuie atribuit unui anumit angajat. Acest

angajat acţionează ca reprezentant al clientului şi se ocupă de toate
tranzacţiile şi comunicarea dintre organizaţie şi respectivul client. Deşi
fiecare client trebuie asociat cu un anumit angajat, un angajat dat nu este
obligat să fie asociat cu vreun client. Mulţi angajaţi se ocupă de alte
probleme ale organizaţiei. Prin urmare, cele 2 tabele vor participa la relaţie
astfel:
 Tabelul ANGAJATI trebuie să primească tipul de participare
Obligatorie. Acest lucru vă asigură că există cel puţin un angajat
pe care să-l puteţi atribui unui client dat.
 Tabelul CLIENTI trebuie să primească tipul de participare
Opţională. Acest lucru vă permite să introduceţi în tabelul
ANGAJATI orice persoană angajată de organizaţie.
După ce aţi determinat tipul de participare a fiecărui tabel în relaţie,

marcaţi acest tip pe diagrama relaţiei. Pentru tipul Obligatorie, folosiţi o
linie verticală, iar pentru tipul Opţională un cerc mic. Figura 3.34 prezintă
diagrama revizuită a relaţiei dintre tabelele ANGAJATI şi CLIENTI,
arătându-vă marcarea tipului de participare. Observaţi că simbolurile
tipului de participare (linia şi cercul mic) se află între simbolurile tipului de
relaţie (linia şi laba de gâscă).
89
Această linie simbolizează tipul de participare

Obligatorie pentru acest tabel
Clienti
Angajati
ClientID ChP
............
Acest cerc simbolizează tipul de participare

Opţională pentru acest tabel
Fig. 3.34. Precizarea tipului de participare pentru tabelele

ANGAJATI şi CLIENTI
Identificarea gradului de participare a fiecărui tabel
După ce aţi determinat cum va participa fiecare tabel în cadrul relaţiei,

trebuie să stabiliţi gradul în care va participa fiecare tabel. După cum ştim
din capitolul 1, gradul de participare precizează numărul minim de
înregistrări pe care un tabel dat trebuie să le aibă asociate cu o înregistrare
din tabelul corelat şi numărul maxim de înregistrări din tabel care pot fi
asociate cu o înregistrare din tabelul corelat.
Factorii pe care îi utilizaţi la determinarea gradului de participare – situaţii

evidente, bunul simţ sau respectarea unui set oarecare de standarde – sunt
aceiaşi pe care îi folosiţi şi la determinarea tipului de participare. De
obicei, în acest moment al procesului de proiectare veţi identifica gradul de
participare pentru unele dintre tabele, iar altele le veţi revedea atunci când
stabiliţi regulile de lucru pentru baza de date.
Pentru a reprezenta gradul de participare al unui tabel dat, veţi utiliza 2

numere, separate prin virgulă şi închise între paranteze. Primul număr
precizează numărul minim de înregistrări corelate, iar al doilea număr arată
numărul maxim permis, de înregistrări corelate. De exemplu, un grad de
participare cum ar fi (2,11) arată că tabelul trebuie să aibă cel puţin 2, dar
nu mai mult de 11 dintre înregistrările sale corelate cu o singură
înregistrare dintr-un alt tabel.
90
Să luăm din nou tabelele ANGAJATI şi CLIENTI. Între aceste 2 tabele
există o relaţie „unu cu mai mulţi”, ceea ce înseamnă că un client dat poate
fi asociat cu singur angajat şi un angajat dat poate fi asociat cu orice număr
de clienţi. Judecând după o regulă de bun simţ sau decizie a conducerii
organizaţiei, un angajat nu poate să răspundă de mai mult de 10 clienţi
simultan. Pe baza acestui scenariu, puteţi deduce că gradul de participare
pentru tabelul ANGAJATI este (1,1) şi gradul de participare pentru tabelul
CLIENTI este (0,10).
După ce aţi identificat gradul de participare al unui tabel, adăugaţi această

informaţie în diagrama relaţiei. Plasaţi gradul de participare deasupra liniei
de legătură a tabelului corespunzător. Figura 3.35 prezintă diagrama
relaţiei dintre tabelele ANGAJATI şi CLIENTI, completată cu
simbolizarea gradului de participare.
Aceasta indică numărul minim şi Aceasta indică numărul minim şi numărul

numărul maxim de angajaţi cu maxim de clienţi cu care poate fi asociat
care poate fi asociat un client un angajat
Clienti
Angajati
(1,1) (0,10) ClientID ChP
............
Fig. 3.35. Indicarea gradului de participare

pentru tabelele ANGAJATI şi CLIENTI
Puteţi, de asemenea să indicaţi gradul de participare nelimitată pentru orice

tabel dintr-o relaţie între două tabele, folosind litera „N” în locul celui de-
al doilea număr (1,N).
Următoarea sarcină pe care o aveţi este să parcurgeţi toate relaţiile din baza
de date la care lucraţi şi să stabiliţi caracteristicile fiecăruia, după modelul
prezentat mai sus. Pe măsură ce finalizaţi munca la o relaţie dată, nu uitaţi
să actualizaţi diagrama relaţiei, astfel încât aceasta să reflecte rezultatele
obţinute.
91
Integritatea la nivel de relaţie
O relaţie atinge integritatea la nivel de relaţie după ce aţi verificat ca ea să

fi fost corect stabilită şi ca toate caracteristicile ei să fi fost precizate în
mod corespunzător. Integritatea la nivel de relaţie garantează următoarele:
 Conexiunea între cele două tabele (sau câmpuri cheie) implicate
într-o relaţie este solidă. Veţi obţine acest lucru folosind
câmpurile cheie primară şi externă la stabilirea relaţiilor „unu cu
unu” sau „unu cu mai mulţi” şi un tabel de legătură la stabilirea
relaţiei de tip „mai mulţi cu mai mulţi”.
 În fiecare tabel puteţi insera înregistrări noi într-o manieră
semnificativă. Acest lucru îl asiguraţi indicând tipul
corespunzător de participare pentru fiecare tabel (sau câmp cheie)
implicat în relaţie.
 Puteţi şterge o înregistrare existentă fără a produce efecte
negative. Acest lucru este garantat prin atribuirea unei reguli
corespunzătoare de ştergere pentru relaţie.
 Există o limită semnificativă pentru numărul de înregistrări ce
pot fi corelate într-o relaţie. Acest lucru îl implementaţi indicând
gradul corespunzător de participare pentru fiecare tabel (sau câmp
cheie) implicat în relaţie.
După cum ştiţi, integritatea la nivel de relaţie este a treia componentă a

integrităţii generale a datelor. (Prima este integritatea la nivel de tabel şi a
doua este integritatea la nivel de câmp.)
92
Etapa 5 - Determinarea şi definirea regulilor de
desfăşurare a activităţii
În această etapă vom determina regulile care trebuie să fie cunoscute şi
respectate de toţi utilizatorii bazei de date. Cea mai bună abordare a acestei
etape este definirea şi stabilirea regulilor de desfăşurare a activităţii
specifice câmpurilor, urmate de regulile de desfăşurare a activităţii
specifice relaţiilor. Această abordare vă ajută să rămâneţi concentrat pe
tipul de regulă pe care o definiţi. De asemenea, se evită saltul înainte şi
înapoi, de la un tip de regulă la altul, fapt care poate determina confuzie şi
sentimente de frustrare.
Reguli specifice câmpurilor
În mod normal, ar trebui ca fiecare câmp al bazei de date să aibă regulile

sale, cuprinse în dosarul de documentare a bazei de date. Practic însă,
datorită faptului că unele câmpuri nu au nevoie de reguli, acestea fiind
evidente (nume de persoane, câmpuri numerice, date calendaristice etc.),
numai unele câmpuri au într-adevăr nevoie de reguli pentru funcţionarea
corectă a bazei de date.
Pentru stabilirea regulilor de desfăşurarea activităţii specifice câmpurilor,

veţi parcurge următoarele etape:
 Selectaţi un tabel;
 Analizaţi fiecare câmp şi determinaţi dacă acesta necesită vreo
restricţie;
 Definiţi, dacă e cazul, regulile de desfăşurare a activităţii necesare
pentru respectivul câmp;
 Determinaţi cum se verifică regula;
 Notaţi regula în formularul Foaie de specificaţii pentru regula de
desfăşurare a activităţii, prezentat în pagina următoare.
Regulile de desfăşurare a activităţii se scriu într-un formular special numit

Foaie de specificaţii pentru regula de desfăşurare a activităţii, a cărui rol
este de a uniformiza modalităţile de prezentare a acestor reguli. De
asemenea, fiecare regulă este prinsă într-un document ceea ce face mai
simplă gestionarea lor. O regulă fiind tipărită pe un format A4, acestea se
pot arhiva în dosare, se pot multiplica, putând fi accesate de oricine are
nevoie de aceste reguli. În figura 3.36 este prezentat acest formular.
93
Fig. 3.36. Formular pentru o regulă de

desfăşurare a activităţii
94
Documentul Foaie de specificaţii pentru regula de desfăşurare a activităţii
conţine următoarele elemente:
 Enunţ. Acesta este textul regulii de desfăşurare a activităţii. El
trebuie să fie clar, succint şi ar trebui să comunice restricţiile
necesare, fără confuzii sau ambiguităţi. Iată un exemplu concret
de regulă:
„O grupă nu poate conţine mai mult de 30 de studenţi.”
 Restricţie. Aici se pune o scurtă explicaţie a modului în care
restricţia se aplică tabelelor şi câmpurilor. De exemplu, puteţi
utiliza următoarea explicaţie pentru restricţia impusă de regula
din exemplul precedent:
„O singură înregistrare din tabelul tblGrupe poate fi asociată cu
maximum 30 de înregistrări din tabelul tblStudenti.”
 Tip. Aici indicaţi dacă regula este orientată spre baza de date sau
este orientată spre aplicaţie.
 Categorie. Aici indicaţi dacă regula este specifică unui câmp sau
unei relaţii.
 Testare la. Aici indicaţi care acţiuni (inserare, ştergere,
actualizare) vor determina testarea restricţiei impusă de regula de
desfăşurare a activităţii.
 Structuri afectate. În funcţie de tipul de regula de desfăşurare a
activităţii, restricţia va afecta fie un câmp, fie o relaţie. Aici
specificaţi numele câmpurilor care vor fi afectate de regulă sau
numele tabelelor implicate în relaţie care vor fi afectate.
 Elemente de câmp afectate. O regulă de desfăşurare a activităţii
care ţine de un câmp poate afecta unul sau mai multe elemente
ale respectivei specificaţii de câmp. Aici indicaţi elementele
afectate de regulă.
 Caracteristici de relaţie afectate. O regulă de desfăşurare a
activităţii care ţine de o relaţie va afecta una sau mai multe
caracteristici ale respectivei relaţii. Aici indicaţi caracteristicile
afectate de regulă.
 Acţiune întreprinsă. Aici indicaţi modificările aduse elementelor
unei specificaţii de câmp sau diagramei de relaţie. Ceea ce scrieţi
aici trebuie să fie foarte clar şi fără ambiguităţi.
95
Reguli specifice relaţiilor
Procedura de efectuare a acestei operaţii presupune parcurgerea

următorilor paşi:
 Selectaţi o relaţie;
 Revizuiţi relaţia şi determinaţi dacă aceasta necesită vreo
restricţie;
 Definiţi regulile de desfăşurare a activităţii pentru relaţie;
 Modificaţi caracteristicile relaţiei;
 Determinaţi ce acţiuni vor determina testarea regulii, altfel spus
când se vede regula;
 Notaţi regula în formularul Foaie de specificaţii pentru regula de
desfăşurare a activităţii, prezentat în figura 3.36.
Se observă că această procedură este asemănătoare cu cea utilizată pentru

regulile de desfăşurare a activităţii specifice câmpurilor. Uşurinţa cu care
veţi stabili aceste reguli, depinde de experienţa pe care o aveţi. Pentru
începători, recomand studiul cu atenţie a paragrafului „Studiu de caz.
Proiectarea unei baze de date”, unde veţi găsi modele de reguli pentru
desfăşurarea activităţii, precum şi alte informaţii practice.
Regulile de desfăşurare a activităţii specifice relaţiilor se referă, în special,

la tipul de participare şi gradul de participare (vezi capitolul 2, paragraful
Termeni referitori la relaţie).
Pentru determinarea acţiunilor care testează regula, gândiţi-vă, de exemplu,

ce se întâmplă dacă se şterge o înregistrare dintr-un tabel care este legat cu
alt tabel. Dacă un tabel conţine cursuri, iar celălalt conţine profesori care
ţin aceste cursuri, este clar că nu putem şterge un profesor care are cel
puţin un curs de ţinut. Dacă s-ar putea şterge, ar apărea aşanumitele
înregistrări orfane cu grave prejudicii în funcţionarea bazei de date.
Referitor la numărul de cursuri pe care le poate preda un profesor, acesta

poate fi stabilit, de exemplu la 6. În acest caz, regula de desfăşurare a
activităţii ar putea fi următoarea:
„Un profesor trebuie să aibă cel puţin un curs, dar nu poate depăşi 6
cursuri.”
96
Dacă veţi ajunge să lucraţi în echipe complexe de proiectare şi
implementare a bazelor de date şi a sistemelor informatice, stabilirea
regulilor de desfăşurare a activităţii va deveni activitate de rutină.
Tabele de validare
În timp ce definiţi reguli pentru desfăşurarea activităţii specifice unui câmp

poate apărea situaţia în care acel câmp nu poate avea decât anumite valori,
adică un set distinct de valori. Se poate aminti aici câmpul numit JUDETE,
e clar că acesta nu poate avea altă valoare decât una din cele 42 de judeţe
ale ţării. De asemenea, câmpul cu secţiile unei facultăţi nu poate avea altă
valoare decât numele acelor secţii.
Se pune firesc întrebarea, cum stabilim acel set distinct de valori pe care le
poate lua un anumit câmp. O soluţie ar fi enumerarea valorilor într-un
„Interval de valori” de pe Foaia de specificaţii a câmpului. Acest lucru
merge bine când avem puţine valori (ex. Sex: M/F, Note: 1-10), dar nu în
cazul judeţelor ca în exemplul amintit mai sus.
Pentru un număr mare de valori trebuie neapărat să folosim un tabel de

validare. Acest tabel are cel puţin 2 câmpuri (ID şi Valoare) şi o
caracteristică utilă, aceea de a nu se schimba de loc sau foarte rar, vezi
exemplul cu judeţele şi cu secţiile unei facultăţi.
Iată cum apare tabelul de validare pentru judeţele ţării noastre, figura 3.37.
JudetID Abreviere Denumire

1 AB Alba
2 AR Arad
Fig. 3.37. Tabel de validare
... ... ...
26 MS Mures
... ... ...
Este evidentă utilitatea tabelelor de validare în integritatea datelor unei

baze de date, deoarece este împiedicată posibilitatea introducerii unor
valori greşite, cum ar fi în cazul nostru, introducerea unui judeţ sub mai
multe denumiri: Bistriţa, Bistriţa-Năsăud, Bistrita-Nasaud. Toate aceste
denumiri ale judeţului respectiv ar fi posibile, dacă ele ar fi introduse de
97
către un operator uman, dar dacă se introduce cheia primară (JudetID),
sigur nu vor fi mai multe denumiri ale acestuia.
Etapa 6 - Determinarea şi definirea vederilor

Am văzut în capitolul 2 ce este o vedere, un tabel virtual alcătuit din
câmpuri care provin din unul sau mai multe tabele ale unei baze de date.
De asemenea, poate să conţină câmpuri şi din alte vederi. Tabelele şi
vederile care compun o anumită vedere sunt cunoscute sub denumirea de
tabele de bază ale vederii. O vedere este „virtuală” pentru că extrage date
din tabelele de bază în loc să stocheze singură date.
Pentru o vedere se stochează în baza de date numai structura ei, sistemul de

gestiune a bazei de date (SGBDR) reconstruieşte şi „repopulează” vederea
de fiecare dată când este accesată. Unele SGBDR –uri folosesc pentru
vedere şi denumirea de interogare cum ar fi Microsoft Access, de care o să
ne ocupăm şi noi în capitolul 5.
Vederile vă permit să vedeţi informaţiile din baza de date din puncte de

vedere diferite, oferindu-vă multă flexibilitate când lucraţi cu datele. Puteţi
crea vederi în mai multe moduri, iar acestea sunt deosebit de utile când se
bazează pe mai multe tabele între care există relaţii.
Există mai multe motive pentru care ar trebui să definiţi şi să utilizaţi

vederi în baza de date pe care o proiectaţi. Iată câteva dintre ele:
 Lucrul cu date din mai multe tabele. Legătura dintre tabele se
materializează practic în vederi.
 În vederi se afişează cele mai frecvent folosite informaţii.
Deoarece SGBDR reconstruieşte şi repopulează vederea de
fiecare dată când o activaţi, informaţiile afişate în vedere
ilustrează cele mai recente modificări ale datelor din tabelele de
bază ale acesteia.
 Le puteţi particulariza pentru a corespunde cerinţelor specifice
fiecărui individ sau grupe de indivizi. Se pot construi vederi care
să corespundă oricărui set de cerinţe.
 Le puteţi utiliza pentru a ajuta la asigurarea integrităţii datelor.
Puteţi defini o vedere de validare care funcţionează ca şi un tabel
de validare – scopul acesteia fiind să furnizeze o gamă de valori
acceptabile pentru un câmp dat al bazei de date.
98
 Le puteţi utiliza în scopuri de securitate sau confidenţialitate.
Puteţi determina ce date sunt disponibile unui anumit grup de
utilizatori.
Definiţi vederile cu atenţie şi îndemnare, iar acestea vor deveni elemente

valoroase în exploatarea bazei de date. Desigur, nu toate vederile o să le
identificaţi încă din faza de proiectare a bazei de date. Multe dintre ele vă
vor fi sugerate de utilizatori sau de practică.
Vederile sunt de 3 tipuri şi anume:

 Vederi de date. Acestea extrag date din unul sau mai multe tabele.
Sunt cele mai întâlnite vederi.
 Vederi agregate. Sunt folosite pentru a afişa informaţii produse
prin agregarea unui set de date, într-un mod specific. Aceste
vederi folosesc funcţiile agregate Sum, Average, Minim, Maxim
şi Count.
 Vederi de validare. Sunt folosite pentru a ajuta la implementarea
integrităţii datelor.
Vederile sunt create cu ajutorul limbajului SQL, aşa cum veţi învăţa în
capitolul 4.
După ce aţi identificat vederea, aceasta va trebui trecută în documentaţia

proiectului, cu ajutorul unui document numit Foaie de specificaţii pentru o
vedere, prezentată în figura 3.38. Aceasta conţine următoarele elemente:
 Nume. Aici indicaţi numele vederii. Aveţi grijă ca aceste nume să
fie cât mai sugestive.
 Tip. Aici precizaţi dacă vederea este de date, agregată sau de
validare.
 Tabelele de bază. Aici specificaţi tabelele de bază ale vederii.
 Expresii de câmp calculat. Aici notaţi expresiile pentru câmpurile
calculate, pe care le-aţi inclus în vedere.
 Filtre. Aici notaţi criteriile pe care le va folosi vederea pentru a
filtra înregistrările pe care le afişează. Veţi nota atât câmpul testat
cât şi expresia utilizată pentru a-l testa.
Vedeţi Foaia de specificaţii pentru o vedere, prezentată în figura 3.38.
99
100
Fig. 3.38. Formular pentru vedere
Documentarea unei vederi se face prin 2 documente de bază: foaie de
specificaţii şi diagrama de vedere. Foaia de specificaţii a fost prezentată în
figura 3.38, iar pentru diagrama de vedere, cea mai bună explicaţie este
prezentarea unui exemplu concret, aşa cum se va vedea în continuare.
Să presupunem că dorim o vedere care să conţină toţi studenţii din baza de

date cu secţia de la care provin şi numărul de telefon. Această vedere are ca
tabele de bază tblStudenti şi tblSectii, iar ca şi câmpuri Student, Sectia,
Telefon. Câmpul Student este un câmp calculat, care se obţine din
alăturarea numelui şi prenumelui studentului care se găsesc în câmpuri
separate. Numele secţiei se va lua din tabelul tblSectii cu care este legat
tabelul tblStudenti. Diagrama de vedere este prezentată în figura 3.39.
tblSectii
tblStudenti
SectiaID
StudentID Sectia
Nume ……..
Prenume
SectiaID
Telefon
………
Lista studenti
Student
Sectia
Telefon
Fig. 3.39. Diagramă de vedere
Această diagramă, împreună cu foaia de specificaţii oferă informaţiile

necesare pentru crearea vederii de către echipa care implementează baza de
date proiectată.
101
Etapa 7 – Revizuirea integrităţii datelor

Aceasta este ultima etapă a procesului de proiectare a bazelor de date. Până
aici aţi realizat multe lucruri şi dacă le-aţi făcut bine la timpul potrivit, în
mod normal, acum nu prea ar trebui să aveţi probleme. Totuşi, această
etapă este importantă pentru că oferă posibilitatea de a privi în ansamblu
proiectul bazei de date, legăturile dintre părţile sale curente, o survolare a
tuturor problemelor rezolvate. Este ca şi cum aţi terminat de construit o
casă nouă, iar înainte de a vă muta în ea mai faceţi o verificare a lucrărilor.
După această etapă proiectul este gata pentru a fi livrat beneficiarului.
În primele 6 etape de elaborare a proiectului aţi:

 Înţeles avantajele modelului relaţional de baze de date;
 Învăţat să creaţi o declaraţie de intenţie pentru o nouă bază de
date;
 Învăţat ce sunt şi cum se definesc obiectivele misiunii pentru
noua bază de date;
 Efectuat o analiză complexă a bazei de date vechi;
 Identificat cerinţele organizaţiei în privinţa informaţiilor;
 Definit structuri de tabel potrivite;
 Atribuit chei primare tabelelor;
 Stabilit specificaţii de câmp;
 Stabilit relaţii între tabele;
 Definit reguli de desfăşurare a activităţii organizaţiei pentru care
aţi proiectat baza de date;
 Definit vederile adecvate;
Cu toate acestea, este în avantajul dumneavoastră să faceţi o revizie finală

a integrităţii generale a datelor din noua bază de date proiectată. Această
revizie finală ar trebui să se bazeze pe principiul „decât să regret că n-am
făcut-o, mai bine să regret că am făcut-o”, altfel spus e mai avantajos să
revizuiesc şi să nu găsesc nimic, decât să rămână o anomalie care oricum
va ieşi la iveală mai târziu, a cărui eliminare însemnând costuri înzecite.
102
Revizuirea şi îmbunătăţirea integrităţii datelor
Revizuirea integrităţii datelor este o sarcină relativ simplă dacă folosiţi o

abordare modulară, adică să revizuiţi secvenţial fiecare componentă a
integrităţii generale a datelor: integritatea la nivel de tabel, la nivel de
câmp, la nivel de relaţie, la regulile de desfăşurare a activităţii şi a
vederilor.
Dacă aţi urmat regulile de proiectare prezentate în acest curs, în mod

normal nu trebuie să aveţi probleme. Mai departe vor fi prezentate pe scurt
ideile pe care ar trebui reţinute în timp ce efectuaţi revizuirea.
La nivel de tabel. Pentru a vă asigura că aţi stabilit corect integritatea la

nivel de tabel, revizuiţi fiecare tabel şi asiguraţi-vă că tabelul respectă
condiţiile următoare:
 Nu există câmpuri duplicat în tabel;
 Nu există câmpuri duplicate în tabel;
 Nu există câmpuri cu mai multe valori în tabel;
 Nu există câmpuri cu mai multe părţi în tabel;
 Fiecare înregistrare din tabel este identificată de o valoare a cheii
primare;
 Fiecare cheie primară respectă setul de criterii de la definirea unei
chei primare.
Dacă întâlniţi vreo problemă, rezolvaţi-o folosind tehnicile învăţate.
La nivel de câmp. Vă puteţi asigura că aţi stabilit corect integritatea la

nivel de câmp după ce aţi făcut următoarele:
 Aţi verificat ca fiecare câmp să respecte setul de criterii
Elementele câmpului ideal;
 Aţi verificat că aţi definit un set de specificaţii de câmp pentru
fiecare câmp.
La nivel de relaţie. Examinaţi fiecare relaţie între tabele pentru a vă

asigura că aţi stabilit corect integritatea la nivel de relaţie. Aţi stabilit
integritatea la acest nivel după ce aţi efectuat următoarele operaţii:
103
 Aţi stabilit corect relaţia;
 Aţi definit regulile de ştergere adecvate;
 Aţi identificat tipul de participare pentru fiecare tabel al relaţiei;
 Aţi stabilit corect gradul de participare pentru fiecare tabel.
Dacă identificaţi vreo problemă legată de relaţie, rezolvaţi-o folosindu-vă

de cunoştinţele referitoare la relaţii.
La nivel de reguli de desfăşurare a activităţii. Vă puteţi asigura că

regulile de desfăşurare a activităţii sunt solide, verificând următoarele
aspecte:
 Sunteţi sigur că fiecare regulă impune o restricţie care are sens;
 Aţi determinat categoria potrivită pentru regulă;
 Aţi definit şi stabilit corect fiecare regulă;
 Aţi modificat elementele de specificaţie de câmp adecvate sau
caracteristicile relaţiei între tabele;
 Aţi stabilit tabelele de validare adecvate;
 Aţi completat o Foaie cu specificaţii pentru fiecare regulă de
Rezolvaţi problemele apărute folosindu-vă de cunoştinţele dobândite la

stabilirea regulilor de desfăşurare a activităţii.
La nivelul vederilor. Deşi vederile nu sunt legate direct de vreo

componentă a integrităţii datelor, datorită importanţei lor, ar trebui să
verificaţi toate structurile de vederi. La examinarea vederilor, veţi testa
următoarele aspecte:
 Fiecare vedere conţine tabelele de bază necesare pentru a furniza
informaţiile solicitate;
 Aţi atribuit câmpurile adecvate fiecărei vederi;
 Fiecare câmp calculat furnizează informaţii pertinente sau
îmbunătăţeşte maniera de prezentare a datelor;
 Fiecare filtru returnează setul adecvat de înregistrări;
 Fiecare vedere are o diagramă de vedere;
 Fiecare vedere este însoţită de o Foaie de specificaţii pentru
vedere.
104
După ce aţi toate aceste revizuiri, puteţi fi încredinţat că baza de date pe
care aţi proiectat-o are o structură solidă, datele pe care le va conţine sunt
unitare şi acceptabile, iar informaţiile pe care le veţi extrage din ea vor fi
exacte.
Alcătuirea documentaţiei bazei de date
Pe parcursul procesului de proiectare a bazei de date, aţi generat mai multe

liste, ciorne, foi de specificaţii şi diagrame utilizate pentru a înregistra
diverse aspecte ale proiectării bazei de date. Toate acestea ar trebui să le
arhivaţi într-un depozit centralizat, de preferat, un set de dosare.
Proiectul propriu-zis al bazei de date va trebui să conţină numai documente

necesare implementării bazei de date. Setul de documente care compun un
proiect are următoarea structură:
 Lista finală de tabele;
 Foi de specificaţii pentru câmpuri;
 Lista câmpurilor calculate;
 Diagrame ale structurii tabelelor;
 Diagrame de relaţii;
 Foi de specificaţii pentru regulile de desfăşurare a activităţii;
 Diagrame ale vederilor;
 Foi de specificaţii pentru vederi.
Toate aceste documente constituie setul complet de articole necesar

structurii logice a bazei de date. După cum aţi observat, în timpul
procesului de proiectare nu s-a făcut nici o referire la sistemul de gestiune a
bazelor de date (SGBDR) în care va fi implementată baza de date. Asta
înseamnă că un proiect de bază de date poate fi implementat în orice
SGBDR.
În paragraful următor va fi prezentat un studiu de caz din care veţi putea

vedea la modul concret cum se proiectează o bază de date.
105
Studiu de caz. Proiectarea unei baze de date
În acest paragraf va fi prezentată modalitatea practică de abordare a

proiectării unei baze de date. Vor fi parcurse toate etapele de proiectare aşa
cum au fost ele prezentate în acest capitol. După parcurgerea acestui
paragraf, studenţii trebuie să ştie ce să facă pentru a proiecta corect o bază
de date şi cum să arate un proiect.
Declaraţia de intenţie
Dorim o bază de date pentru o bibliotecă cu ajutorul căruia să gestionăm
cărţile, cititorii şi împrumuturile care se fac de către această bibliotecă.
Obiectivele misiunii
În urma discuţiilor şi analizării documentelor obţinute de la diferite
persoane aparţinând bibliotecii, împreună cu directorul ei am convenit că
baza de date care va fi proiectată va îndeplini următoarele obiective:
O evidenţă a cărţilor din bibliotecă.
O evidenţă a cititorilor cu posibilitatea de a obţine informaţii despre natura
profesiilor lor, a preocupărilor etc.
Dorim să avem evidenţa împrumuturilor de cărţi.
Alte informaţii utile.
Analiza bazei de date curente

Informaţiile care există la ora actuală se găsesc în special în tabele Excel,
documente Word şi registre scrise de mână.
Preluarea informaţiilor se va prelua manual, iar acolo unde există

posibilitatea vor fi concepute programe de transfer direct în tabelele bazei
de date. Aici se pot aminti, în special, informaţiile conţinute în tabelele
Excel.
Această etapă trebuie să se termine cu o listă preliminară de câmpuri care

se vor folosi în etapa următoare pentru crearea tabelelor. Aşa spune teoria
şi aşa este corect, dar în practică această listă de câmpuri este finalizată
odată cu tabelele din care fac parte. Nu este o abatere care să pună în
pericol proiectul nostru, trebuie mai multă atenţie din partea noastră dar se
câştigă timp preţios.
Crearea structurilor de date
106
În urma analizării obiectivelor misiunii au rezultat tabelele cu date,
stabilindu-se câmpurile şi cheile, primare sau externe. În această etapă se
vor definitiva şi specificaţiile de câmp, completând formularul Specificaţii
de câmp care se găseşte în anexa acestei cărţi.
Lista cu tabelele bazei de date este prezentată în tabelul care urmează.
Tabel Cimp Tip data Constringeri Observatii
tblAutori AutorID ChP AutoNumber Not Null
Nume Character(150) Not Null
Prenume Character(150) Not Null
Nationalitate Character(15)
DataN Data/Time zz-lll-aa
DataD Data/Time zz-lll-aa
tblEdituri EdituraID ChP AutoNumber Not Null
Denumire Character(150) Not Null
Localitate Character(150)
Tara Character(50)
tblCarti CarteID ChP AutoNumber Not Null
AutorID ChE Long Integer Not Null
EdituraID ChE Long Integer Not Null
DomeniuID ChE Long Integer Not Null
AnAparitie Integer
Pagini Integer
Valoare Single
Stoc Integer
tblDomenii DomeniuID ChP AutoNumber Not Null
Explicatii Character(250)
tblImprumuturi ImprumutID ChP AutoNumber Not Null
CarteID ChE Long Integer Not Null
CititorID ChE Long Integer Not Null
DataImprumut Data/Time zz-lll-aa
Perioada Integer
DataRestituire Data/Time zz-lll-aa
tblCititori CititorID ChP AutoNumber Not Null
Nume Character(150) Not Null
Prenume Character(150) Not Null
ProfesiaID ChE Long Integer Not Null
DataN Data/Time zz-lll-aa
Adresa Character(150)
Localitate Character(150)
JudetID ChE Long Integer Not Null
Observatii Character(150)
tblJudete JudetID ChE AutoNumber Not Null
Abreviere Character(2) Not Null
tblProfesii ProfesiaID ChP AutoNumber Not Null
Explicatii Character(200)
107
În acest moment avem toate tabelele bazei de date, cu cheile principale şi
externe, cu specificaţiile de câmp pentru toate câmpurile existente în toată
baza de date. Urmează partea ca mai spectaculoasă a proiectului nostru,
stabilirea relaţiilor dintre tabelele bazei de date.
Reamintesc că între 2 tabele nu poate exista decât o singură relaţie. De

asemenea, reamintesc că există 3 tipuri de relaţii 1:1, 1:N şi N:N, iar ultima
relaţie trebuie transformată în 2 relaţii 1:N, pentru a putea fi folosită în
rapoarte. În acest sens, au apărut tabelele de legătură tblAutoriCarti,
tblAutoriArticole, tblAutoriActivitati şi tblAutoriContracte.
Documentaţia proiectului ar trebui să cuprindă doi de specificaţii pentru

toate câmpurile tabelelor. Din motive de spaţiu, nu vom completa aici
decât o astfel de foaie, care va fi prezentată în pagina următoare.
Câmpul descris în această specificaţie va fi DataN.
108
Fig. 3.40. Foaia de specificaţie

109 pentru câmpul DataN
Determinarea şi instituirea relaţiilor între tabele

Aceasta este etapa a 4-a din proiectarea unei baze de date. În urma
parcurgerii ei, va rezulta diagrama structurii bazei de date, folosind
notaţiile şi simbolurile învăţate în acest capitol. Este documentul care va fi
folosit cel mai mult la implementarea bazei de date şi care conţine cea mai
multă informaţie concentrată într-un spaţiu redus, de regulă o pagină
tipărită.
Pentru realizarea diagramelor pot fi folosite cunoştinţele dobândite la

studiul Word-ului sau Excel-ului. Pentru cei care cunosc alte programe cu
care se pot concepe diagrame, cum ar Microsoft Visio sau SmartDraw,
această etapă va fi mult mai uşoară şi chiar plăcută.
În cazul de faţă, s-a optat pentru o diagrama de relaţii scoasă din mediul
Access, cu un program de captare de imagini (figura 3.41). Această
imagine o să mai fie întâlnită cu ocazia aplicaţiilor pe care le veţi face în
Access (cap. 5).
Fig. 3.41. Diagrama de relaţii a bazei de date ”Biblioteca”
Observaţi că relaţia 1:N, partea ”mai mulţi”, este aici notată cu simbolul
”infinit”.
110
După ce s-a creat diagrama bazei de date urmează stabilirea regulilor de
desfăşurare a activităţii, care va fi abordată în pasul următor.
Determinarea şi definirea regulilor de desfăşurare a activităţii
În această etapă trebuie să determinăm regulile de desfăşurare a activităţii

pentru baza de date proiectată. După cum ştim, există 2 tipuri de reguli de
desfăşurare a activităţii, care se referă la câmp respectiv la relaţii.
Din motive de spaţiu vom prezenta numai 2 formulare completate cu

regulile respective, una pentru câmpuri şi cealaltă pentru relaţii, pentru a
avea un model complet.
Pentru stabilirea regulilor de desfăşurare a activităţii specifice unui câmp

trebuie să parcurgem următoarele etape:
 Alegem un tabel;
 Analizăm fiecare câmp şi stabilim dacă acesta necesită vreo
restricţie;
 Dacă e necesar, definim regulile de desfăşurare a activităţii pentru
acel câmp;
 Dacă e necesar vom modifica şi elementele adecvate din
specificaţia de camp;
 Determinăm acţiunile care verifică regula;
 Înregistrăm regula pe o Foaie de specificaţii pentru regula de
Desigur, stabilirea regulilor de desfăşurare a activităţii nu este o treabă prea

simplă, experienţa joacă aici un rol important. Pentru a vă ajuta în
înţelegerea acestor aspecte se va prezenta mai jos o astfel de regulă cu care
s-a completat o foaie de specificaţii.
În figura 3.42 este prezentat un formular cu specificaţii pentru o regulă de

desfăşurare a activităţii specifică unui câmp.
111
Fig. 3.42. Regulă de desfăşurare a activităţii specifică unui câmp
112
După ce s-au stabilit regulile de desfăşurare a activităţii specifice

câmpurilor, este necesar să se stabilească asemenea reguli şi pentru relaţii.
Pentru stabilirea regulilor de desfăşurare a activităţii specifice unei relaţii

trebuie să parcurgem următoarele etape:
 Selectăm o relaţie;
 Revizuim relaţia şi determinăm dacă aceasta necesită vreo
restricţie;
 Definim regulile de desfăşurare a activităţii pentru această relaţie;
 Stabilim regula modificând în acelaşi timp caracteristicile
adecvate relaţiei;
 Determinăm ce acţiuni verifică regula;
 Notăm regula pe o Foaie de specificaţii pentru regula de
În figura 3.43 este prezentat un formular cu specificaţii pentru o regulă de

desfăşurare a activităţii specifică unei relaţii.
113
Fig. 3.43. Regulă de desfăşurare a activităţii specifică unei relaţii
114
Determinarea şi definirea vederilor
Oricâtă experienţă am avea, e greu de presupus că vom putea identifica

toate vederile în faza de proiectare. Nici nu ne propunem acest lucru.
Scopul acestui paragraf este de identifica câteva vederi ale proiectului la
care lucrăm şi a completa un formular de specificaţii pentru una dintre ele.
Iată câteva vederi care n-ar trebui să lispsească din proiectul nostru:
 Cititorii cu profesiile lor;
 Cărţile;
 Editurile;
Aceste vederi îşi extrag datele dintr-unul sau mai multe tabele. Pentru
exemplificare să luăm vederea ”Lista cititorilor bibliotecii” a cărei
structură o vedem în figura 3.44.
tblCititori
tblProfesii
tblJudete
JudetID CititorID ProfesiaID
Denumire Nume Denumirea
Abreviere Prenume Explicatii
ProfesiaID
……..
JudetID
Lista cititori
Cititor
Profesia
Adresa
Fig. 3.44. Diagrama de vedere ”Lista cititorilor

bibliotecii”
115
Observaţi că această vedere are ca tabele de bază tabelele tblJudete,

tblCititori şi tblProfesii. Între aceste tabele există relaţii ”unu la mai mulţi”
după cum se poate vedea din diagramă.
Observaţi, de asemenea, că există un câmp calculat, câmpul Cititor care

rezultă din adunarea(concatenarea) câmpurilor Nume şi Prenume.
În figura 3.45 este prezentată Foaia de specificaţii pentru vederea ” Lista

cititorilor bibliotecii”. Studiaţi cu atenţie acest document şi încercaţi să
faceţi foi de specificaţii pentru celelalte vederi.
116
Fig. 3.45. Foaie de specificaţii117

pentru vederea ”Lista cititorilor bibliotecii”
Verificarea integrităţii datelor
În această etapă sunt rezolvate toate problemele legate de proiect. Practic

se poate trece la implementarea bazei de date într-un SGBDR, dar o ultimă
verificare a proiectului nu este de prisos, deoarece ar fi putut scăpa unele
mici erori care se vor descoperi oricum într-o anumită fază a procesului de
implementare. Se verifică toate documentele proiectului, plecând de la
declaraţia de intenţie şi obiectivele misiunii, pentru a verifica dacă
proiectul şi-a atins scopul. Liniştea pe care o dobândiţi ştiind că aveţi o
bază de date temeinic proiectată merită timpul petrecut şi efortul depus
pentru această revizuire finală. Informaţiile pe care le va furniza această
bază de date vor fi exacte. Este un fel de recepţie finală a proiectului,
făcută de executantul său.
Presupunem că aţi verificat integritatea datelor la nivel de tabel, câmp,

relaţie, desfăşurarea activităţii şi la nivel de vedere. Din păcate, această
etapă nu are un document bine definit care să ateste că a fost făcută.
Concluzii privind proiectarea bazelor de date relaţionale
Proiectarea bazelor de date relaţionale este o activitate complexă,

executată, de regulă, de o echipă de specialişti formată din informaticieni,
ingineri şi economişti. În acest studiu de caz, aţi parcurs toate etapele
elaborării unui proiect temeinic de baze de date. După cum spuneam, orice
bază de date are un scop de la care nu trebuie să ne abatem nici o clipă. E
adevărat că unele obiective ale bazei de date nu sunt clar exprimate de
către beneficiari, dar asta nu e o problemă pentru că echipa de dezvoltare
poate să clarifice aceste aspecte chiar de la început.
Pe tot parcursul elaborării proiectului, aţi adunat o documentaţie

consistentă care va fi de un real folos în procesul de implementare, mai
ales atunci când vor trebui operate modificări în proiect. Dacă aţi înţeles
etapele prin care aţi trecut, dacă aţi completat formularele cerute (foile de
specificaţii pentru câmp, relaţie, vedere) înseamnă că puteţi deveni un
component de bază al unei echipe de dezvoltare a unei aplicaţii de baze de
date.
Ce rol aţi putea avea într-o echipă de dezvoltare a aplicaţiilor de baze de

date? Aţi putea definitiva declaraţia de intenţie şi obiectivele misiunii, aţi
118
putea lucra la completarea formularelor de specificaţii pentru câmp, relaţie,
vedere şi reguli de desfăşurare a activităţii. Un rol important aţi putea avea
în culegerea de informaţii de la viitorii utilizatori ai bazei de date.
Dacă sunteţi angajatul firmei beneficiare, veţi putea colabora eficient cu

echipa de dezvoltare, ca viitor utilizator al bazei de date. Dacă
împrejurările o cer, aţi putea deveni administrator al bazei de date, o muncă
extrem de importantă şi cu mare resposabilitate (vezi Anexa A).
119
Capitolul 4. Iniţiere în limbajul SQL
În acest capitol vom studia elementele de bază ale limbajului de interogare şi

manipulare a bazelor de date SQL. Vom folosi acest limbaj pentru a scoate
informaţii dintr-o bază de date, pentru a modifica datele tabelelor şi chiar pentru
crearea de noi tabele sau ştergerea lor din baza de date. Abordarea limbajului se
va face de la simplu spre complex, iar exemplele prezentate vor fi foarte sugestive
pentru înţelegerea operaţiunilor executate.
Prezentare generală
Limbajul SQL este abrevierea de la Structured Query Language (limbaj
structurat de interogare) şi este un limbaj conceput special pentru
comunicarea cu bazele de date.
Spre deosebire de alte limbaje de programare, SQL se compune din foarte

puţine cuvinte (instrucţiuni), ceea ce face să fie uşor de învăţat şi folosit.
Toate bazele de date importante acceptă limbajul SQL, aşa că învăţarea lui
este de un real folos. În ciuda aparentei simplităţi, SQL este un limbaj
foarte puternic, cu care, dacă-i utilizaţi cu inteligenţă facilităţile, puteţi
efectua operaţii complexe şi sofisticate cu bazele de date.
Limbajul SQL este un limbaj neprocedural sau declarativ deoarece nu

conţine instrucţiuni precum IF, GOTO, WHILE sau altele care să ofere un
flux de control; utilizatorul lui descrie numai informaţiile pe care vrea să le
obţină în urma interogării bazei de date, fără a fi nevoie să stabilească şi
modalităţile de a ajunge la rezultatele dorite. Este ceea ce visează fiecare
dintre noi, nu?
Există un anumit grad de standardizare a limbajului SQL, mai multe

SGBDR recunoscând principalele instrucţiuni ale acestuia. Pe plan
mondial, standardul în domeniu este considerat ANSI (American National
Standards Institute) SQL care are în vedere atât aspectele de definire,
interogare, manipulare a datelor, procesare a tranzacţiilor, cât şi
caracteristicile complexe privind securitatea informaţiilor.
120
Se cunosc în literatura de specialitate trei metode de bază privind
implementarea limbajului SQL şi anume: cea prin apelare directă, cea
modulară şi cea de tip încapsulat. Prima metodă costă în introducerea
instrucţiunilor SQL de la prompter, cea de a doua foloseşte anumite
proceduri apelate de programele aplicaţiei, iar cea de a treia variantă de
implementare are în vedere instrucţiuni încapsulate în codul program, fiind
de tip static şi dinamic.
Instrucţiunile SQL se grupează astfel:

 Instrucţiuni de definire a datelor;
 Instrucţiuni de manipulare a datelor (adăugare, modificare,
ştergere);
 Instrucţiuni de selecţie a datelor (consultare a bazei de date);
 Instrucţiuni de procesare a tranzacţiilor.
După cum spuneam, instrucţiunile SQL sunt puţine, dar ele sunt
completate cu clauze care le măresc puterea. Practic, noi trebuie să
înţelegem şi să folosim clauzele care însoţesc instrucţiunile. Sintaxa
folosită nu este pretenţioasă, singura noastră grijă este să folosim expresii
lizibile, prin evidenţierea instrucţiunilor şi a parametrilor lor.
În cadrul acestui curs vom folosi limbajul SQL corespunzător programului

ACCESS. În acest capitol vom învăţa folosirea limbajului scriind expresii
SQL pe hârtie folosind o bază de date existentă, completată cu date. Abia
în capitolul următor vom folosi limbajul SQL în cadrul programului
ACCESS.
Baza de date pe care o vom folosi în acest capitol, cea pe care o să ne

exersăm talentele, este cea proiectată în capitolul anterior şi se numeşte
BD_ITM, a cărei structură este cunoscută. Pentru unele instrucţiuni vom
folosi şi alte baze de date dacă necesităţile vor impune acest lucru.
Metoda pe care o vom folosi pentru a învăţa limbajul SQL este cea a
învăţării „din mers” a instrucţiunilor şi clauzelor, adică executăm
operaţiuni şi învăţăm instrucţiunile folosite. Operaţiunile vor fi în aşa fel
alese ca să acopere tot spectrul practic pe care o să-l întâlniţi în realitate.
Într-o anexă vor fi sistematizate instrucţiunile SQL cu clauzele şi sintaxa
lor. Această anexă vă va fi de un real folos după ce veţi dobândi o anumită
experienţă în utilizarea limbajului SQL.
121
Operaţiuni simple folosind limbajul SQL
Regăsirea datelor
Regăsirea datelor se face cu instrucţiunea SELECT, folosită pentru a regăsi

una sau mai multe coloane. Aceasta este cea mai folosită instrucţiune din
SQL.
Din tabelul tblStudenti prezentat în figura 4.1 ne propunem să extragem

numele şi prenumele studenţilor.
StudID Nume Init Prenume Sectia An Grupa Stare

1 Bogdan P. Mircea Florin IEI 1 1311 Bugetar
2 Meruta I. Cosmin IEI 3 1332 Bugetar
3 Pop T. Marius Traian IEI 2 1321 Bugetar
4 Bucur P. Mihaela IEI 2 1321 Bugetar
5 Chirila I. Laura IEI 3 1331 Bugetar
6 Cotirla L. Raluca Adina TCM 1 1111 Bugetar
7 Cotoara G. Ovidiu TCM 1 1111 Bugetar
8 Cozma D. Dumitru TCM 2 1121 Bugetar
9 Damian N. Daniel MEC 4 1241 Bugetar
10 Farcas I. Calin Florin MEC 4 1241 Taxa
Fig. 4.1. Tabelul tblStudenti simplificat
Expresie SQL:
SELECT Nume, Prenume
FROM tblStudenti;
Rezultat:
Nume Prenume
Bogdan Mircea Florin
Meruta Cosmin
Pop Marius Traian
Bucur Mihaela
Chirila Laura
Cotirla Raluca Adina
Cotoara Ovidiu
Cozma Dumitru
Damian Daniel
Farcas Calin Florin
122
Observaţi expresia SQL care se citeşte astfel: selectează coloanele Nume şi
Prenume din tabelul tblStudenti. S-a folosit şi clauza FROM, aşa cum se
vede. Rezultatul obţinut este evident.
Dacă doriţi să selectaţi toate coloanele tabelului se foloseşte expresia

următoare:
Expresie SQL:
SELECT *
FROM tblStudenti
În locul listei de coloane se pune acest simbol „ * ”.
Sortarea datelor
Prin sortarea datelor se înţelege aranjarea înregistrărilor unui tabel într-o

anumită ordine, de regulă, alfabetică sau crescătoare/descrescătoare.
Sortarea datelor se face cu ajutorul clauzei ORDER BY a instrucţiunii
SELECT.
La tabelul din figura 4.1 ne propunem să scoatem numai numele şi

prenumele studenţilor dar în ordine alfabetică.
Expresie SQL:
FROM tblStudenti
ORDER BY Nume;
Rezultat:
Nume Prenume
Bogdan Mircea Florin
Bucur Mihaela
Chirila Laura
Cotirla Raluca Adina
Cotoara Ovidiu
Cozma Dumitru
Damian Daniel
Farcas Calin Florin
Meruta Cosmin
Pop Marius Traian
123
Observaţi clauza ORDER BY care ordonează înregistrările în ordine
alfabetică după valorile din câmpul Nume. Se pune întrebare, ce ne facem
dacă vrem să ordonăm invers alfabetic (de la Z la A)? Sau dacă avem un
câmp numeric şi dorim să ordonăm descrescător după acest câmp. Iată
răspunsul:
 Pentru a indica ordinea descrescătoare de sortare se foloseşte
cuvântul cheie DESC.
 Dacă câmpul după care se face sortarea este alfanumeric, sortarea
se face alphabetic, iar dacă este numeric sau de dată
calendaristică, sortarea se face crescător/descrescător.
 Dacă nu se indică direcţia de sortare, se ia sortarea crescătoare
care este implicită. (Cazul prezentat.)
Iată cum arată o expresie SQL în care apare şi cuvântul cheie DESC:
Expresie SQL:
FROM tblStudenti
ORDER BY Nume DESC
Reţineţi că rezultatul sortării datelor este un tabel care are acelaşi număr de
înregistrări ca şi originalul.
Filtrarea datelor
Prin filtrarea datelor se înţelege extragerea dintr-un tabel numai a anumitor

înregistrări de care avem nevoie, de exemplu, din tabelul de studenţi avem
nevoie numai de cei din anul 2. Pentru a executa această operaţiune veţi
folosi clauza WHERE a instrucţiunii SELECT.
Regăsirea numai a înregistrărilor dorite, presupune includerea în expresia

SQL a unui criteriu de căutare a înregistrărilor dorite. Într-o instrucţiune
SELECT, datele sunt filtrate prin specificarea criteriilor de căutare în
clauza WHERE. Locul acesteia este imediat după numele tabelului (clauza
FROM), ca în exemplul următor. Fie tabelul din figura 4.1.
124
Ne propunem să filtrăm studenţii din anul 2. expresia SQL este
următoarea:
Expresie SQL:
SELECT StudID, Nume, Init, Prenume, Sectia, Grupa
FROM tblStudenti
WHERE An = ”2”;
Rezultat:
StudID Nume Init Prenume Sectia Grupa
3 Pop T. Marius Traian IEI 1321
4 Bucur P. Mihaela IEI 1321
8 Cozma D. Dumitru TCM 1121
Operatorii clauzei WHERE
Clauza WHERE pe care am examinat-o a testat egalitatea – determină dacă

o coloană conţine valoarea specificată. Limbajul SQL acceptă mai mulţi
operatori condiţionali, după cum urmează:
 = Egalitate
 <> Non-egalitate
 != Non-egalitate
 < Mai mic decât
 <= Mai mic sau egal cu
 !< Nu mai mic decât
 > Mai mare decât
 >= Mai mare sau egal cu
 !> Nu mai mare decât
 BETWEEN Între două valori specificate
 IS NULL Este o valoare NULL
Observaţi că pentru non-egalitate există două simboluri, aceasta pentru că

diversele SGBDR-uri acceptă pe unul sau altul dintre ele.
125
Iată câteva cazuri concrete de folosire a operatorilor:
Interval de valori: WHERE Pret BETWEEN 2.5 AND 10; (afişează toate
înregistrările care au în coloana „Pret” valori între 2.5 şi 10).
Valoare NULL: WHERE Pret IS NULL; (afişează toate înregistrările care

nu au preţ).
Non-egalitate: WHERE Stare <> ”Bugetar”; (afişează toate înregistrările din

tabelul studenţi, folosit mai înainte, care nu sunt bugetari). Este evident că
putem formula şi altfel condiţia, dar aici am folosit non-egalitatea.
Ceilalţi operatori se folosesc la fel ca cel de egalitate prezentat puţin mai în

faţă.
Filtrare avansată
Filtrările prezentate mai sus se întâlnesc mai rar în practică deoarece sunt
foarte simple. Filtrările pe care le veţi folosi în mod curent, sunt filtrări mai
complicate la care criteriile sunt exprimate prin expresii complexe. Aceste
criterii creează condiţii puternice de căutare. Vom folosi alţi operatori cum
sunt AND, OR, NOT şi IN.
De multe ori, filtrarea după o coloană nu rezolvă problema pe care o avem.

Pentru a filtra după mai multe coloane se foloseşte operatorul AND. Fie
tabelul din figura 4.2. Ne propunem să facem diferite filtrări.

2 Meruta I. Cosmin IEI 1 1312 Taxa
3 Pop T. Marius Traian IEI 2 1321 Bugetar
4 Bucur P. Mihaela IMPI 2 1321 Bugetar
5 Pop I. Laura IEI 3 1331 Taxa
7 Cotoara G. Ovidiu TCM 1 1111 Bugetar
8 Cozma D. Dumitru TCM 2 1121 Bugetar
9 Damian N. Daniel MEC 4 1241 Bugetar
10 Cozma I. Calin Florin MEC 4 1241 Taxa
Fig. 4.2. Tabel cu studenţi
126
Operatorul AND. Prima filtrare ar fi studenţii de la IEI din anul 1. Iată
expresia SQL:
Expresie SQL:
SELECT Nume, Prenume, Grupa, Stare
FROM tblStudenti
WHERE Sectia=”IEI” AND An = ”1”;
Rezultat:
Nume Prenume Grupa Stare
Bogdan Mircea Florin 1311 Bugetar
Meruta Cosmin 1312 Taxa
Urmăriţi expresia SQL şi verificaţi rezultatul obţinut. Încercaţi şi alte

filtrări asemănătoare. Observaţi folosirea operatorului AND. Cum ar trebui
modificată expresia SQL, pentru a afişa rezultatul în ordine alfabetică
inversă?
Operatorul OR. O altă filtrare pe care ne-o propunem, este să filtrăm

studenţii din anul 2 de la IEI sau TCM.
Expresie SQL:
SELECT Nume, Prenume,Sectia, Grupa, Stare
FROM tblStudenti
WHERE (Sectia=”IEI” OR Sectia=”TCM”) AND An = ”2”;
Rezultat:
Nume Prenume Sectia Grupa Stare
Pop Marius Traian IEI 1321 Bugetar
Cozma Dumitru TCM 1121 Bugetar
Observaţi folosirea parametrilor OR şi AND, respectiv apariţia celor două

paranteze. Aceste paranteze au legătură cu ordinea operaţiilor OR şi AND.
În ordinea operaţiilor, operatorul AND se execută înaintea operatorului
OR, ceea ce ar duce la rezultate eronate, de aceea a fost pus operatorul OR
în paranteză, ca să-l execute primul, ştiut fiind că parantezele au prioritate
la execuţie.
Operatorul IN. Folosirea acestui operator are ca scop specificarea unui

domeniu de condiţii, oricare dintre ele putând fi îndeplinite. Operatorul IN
127
necesită o listă de valori valide, care să fie separate prin virgule şi cuprinse
între paranteze.
Ne propunem să alegem din tabelul din figura 4.2 toţi studenţii care au
numele Pop şi Cozma.
Expresie SQL:
FROM tblStudenti
WHERE Nume IN (“Pop”, “Cozma”);
Rezultat:
Pop Marius Traian IEI 1321 Bugetar
Pop Laura IEI 1331 Taxa
Cozma Dumitru TCM 1121 Bugetar
Cozma Calin Florin MEC 1241 Taxa
Din analiza acestui exemplu, putem observa fără greutate că operatorul IN

face cam acelaşi lucru ca şi operatorul OR, deci se poate scrie o expresie
SQL cu acesta. Care este această expresie?
Se pune, pe bună dreptate, întrebarea de ce mai avem nevoie de încă un

operator dacă avem unul care face acelaşi lucru. Răspunsul este că
operatorul IN are unele avantaje care îl fac de preferat faţă de operatorul
OR. Iată aceste avantaje:
 Când lucraţi cu liste lungi de opţiuni valide, sintaxa operatorului
IN este mai simplă şi uşor de citit, principalul avantaj.
 Ordinea de evaluare este mai simplu de gestionat, când operatorul
IN este folosit în asociaţie cu operatorii AND şi OR.
 Aproape totdeauna, operatorii IN se execută mai rapid decât
listele de operatori OR.
 Un mare avantaj este că operatorul IN poate să conţină o altă
instrucţiune SELECT, şi astfel vă permite să construiţi clauze
WHERE foarte dinamice. Acest aspect va fi reluat mai târziu.
Operatorul NOT. Acest operator al clauzei WHERE are o singură funcţie

– neagă orice condiţie care îl urmează. Deoarece NOT nu este utilizat
niciodată în sine (totdeauna se foloseşte în asociaţie cu alt operator),
sintaxa lui e diferită de toţi ceilalţi operatori. Spre deosebire de alţi
128
operatori, cuvântul cheie NOT poate fi utilizat înaintea coloanei după care
se face filtrarea, nu imediat după aceasta.
Iată un exemplu sugestiv, extragerea studenţilor nebugetari din tabelul din

figura 4.2.
Expresie SQL:
FROM tblStudenti
WHERE NOT Stare=”Bugetar”;
Rezultat:
Meruta Cosmin IEI 1312 Taxa
Cozma Calin Florin MEC 1241 Taxa
După cum se vede, acelaşi lucru îl puteam obţine şi cu operatorul „<>”.

Iarăşi se pune întrebarea de ce să folosim, totuşi, operatorul NOT? Într-
adevăr, pentru clauzele WHERE simple, cum e cea prezentată, nu se poate
spune că ar exista un avantaj real în folosirea operatorului NOT. Acesta
este însă foarte util în clauzele mai complexe. De exemplu, dacă folosiţi
operatorul NOT în asociaţie cu un operator IN, va fi mult mai simplu să
găsiţi toate înregistrările care nu corespund cu o listă de criterii.
Operatorul LIKE. Aici veţi învăţa ce sunt caracterele de înlocuire, cum se

folosesc ele şi cum să faceţi căutări cu ajutorul lor. Până acuma, toţi
operatorii, foloseau valori cunoscute, iar ei se ocupau de căutarea
corespondenţelor dintre valori, dacă sunt mai mari sau mai mici decât
altele, dacă verifică un domeniu de valori etc. De multe ori apare
necesitatea filtrării înregistrărilor după unele criterii care nu folosesc valori
cunoscute în totalitate. De exemplu, doriţi să căutaţi nume de persoane care
încep cu o literă, care conţin un grup de litere etc. Acest lucru nu se poate
face cu criterii simple comparare.
O soluţie, pe care ne-o propune SQL, este folosirea caracterelor de

înlocuire. Caracterele de înlocuire sunt caractere ce au înţelesuri speciale
în clauzele WHERE din SQL, iar limbajul SQL acceptă diverse tipuri de
caractere de înlocuire.
129
Pentru a utiliza caracterele de înlocuire în clauzele de căutare, trebuie

utilizat operatorul LIKE. Acesta anunţă sistemul de gestiune a bazei de
date că în următorul model de căutare se va folosi o potrivire după
caractere de înlocuire, nu o simplă potrivire de egalitate.
Căutarea cu caractere de înlocuire poate fi utilizată numai cu câmpuri de

tip text. Reţineţi acest lucru!
În continuare vor fi prezentate caracterele de înlocuire folosite de

programul ACCESS.
Caracterul de înlocuire *. Este cel mai frecvent utilizat. Într-un şir de

căutare, „ * ” înseamnă „corespunde cu oricâte apariţii a oricărui
caracter”. Exemplul care urmează vă va ajuta să înţelegeţi acest caracter.

2 Brustur I. Cosmin IEI 1 1312 Taxa
3 Popescu T. Marius Traian IEI 2 1321 Bugetar
4 Brucan P. Mihaela IMPI 2 1321 Bugetar
5 Pop I. Laura IEI 3 1331 Taxa
7 Popa G. Ovidiu TCM 1 1111 Bugetar
8 Popovici D. Dumitru TCM 2 1121 Bugetar
9 Branea N. Daniel MEC 4 1241 Bugetar
10 Cozma I. Calin Florin MEC 4 1241 Taxa
Fig. 4.3. Tabel cu studenţi
130
Ne propunem să filtrăm toate înregistrările în care numele studenţilor, din
tabelul din figura 4.3, începe cu „Pop”.
Expresie SQL:
FROM tblStudenti
WHERE Nume LIKE ”Pop*”
ORDER BY Nume;
Rezultat:
Popa Ovidiu TCM 1111 Bugetar
Popescu Marius Traian IEI 1321 Bugetar
Popovici Dumitru TCM 1121 Bugetar
Observaţi ghilimelele care se pun şi ordonarea rezultatului după câmpul

Nume. Încercaţi şi alte filtrări folosind această tehnică.
Caracterul de înlocuire „ ? ”. Acest caracter (semnul întrebării) este

utilizat la fel ca simbolul „ * ”, dar nu asigură corespondenţa mai multor
caractere, ci numai a unuia singur. Exemplul care urmează vă ajută să
înţelegeţi folosirea lui.
Folosind tabelul din figura 4.3, scrieţi expresii SQL care să ilustreze
folosirea acestui caracter de înlocuire.
Observaţie! În diferite SGBDR semnele de înlocuire ar putea să fie

diferite. Astfel, în Oracle „ * ” este înlocuit cu „ % ”, iar „ ? ” este înlocuit
cu liniuţa de subliniere „ _ ”. Pentru a nu avea probleme este bine să
studiaţi documentaţia SGBDR-ului pe care îl veţi folosi.
131
Operaţiuni avansate folosind limbajul SQL
Câmpuri calculate
După ştiţi de la proiectarea bazelor de date, o regulă de bază ne spune că

fiecare câmp trebuie să fie independent, adică valoare sa să nu depindă de
valorile din alte câmpuri. Exemplul clasic care se poate da aici este cel al
câmpului Valoare care nu trebuie să apară într-un tabel care are Pretul
unitar şi Cantitatea, dar avem nevoie de acest câmp care este rezultatul
înmulţirii dintre preţ şi cantitate. Ei bine, acest câmp trebuie calculat. Un
alt exemplu este cel al adresei care se compune din concatenarea
rezultatelor din mai multe câmpuri.
În ambele exemple, datele stocate în tabele nu sunt exact ceea ce are

nevoie aplicaţia dumneavoastră. În loc să regăsiţi datele aşa cum sunt,
pentru ca după aceea să le reformataţi în aplicaţia client sau în raport, doriţi
să regăsiţi datele transformate, calculate sau reformatate direct din baza de
date.
Aici intervin câmpurile cu valori calculate, pe care le vom numi în

continuare câmpuri calculate. Spre deosebire de toate coloanele de până
acum, câmpurile calculate nu există, de fapt, în baza de date. Un câmp
calculat este creat din mers, în interiorul unei instrucţiuni SELECT din
limbajul SQL.
De menţionat faptul că numai baza de date ştie care coloane dintr-o

instrucţiune SELECT sunt realmente coloane din tabele şi care sunt
câmpuri calculate. Din perspectiva unui client, datele unui câmp calculat
sunt returnate în acelaşi mod ca şi datele din oricare coloană.
Cel mai simplu mod de a înţelege crearea câmpurilor calculate este de a

alege exemple sugestive pe care să le comentăm.
Câmpuri calculate prin concatenare. De multe ori apare necesitatea

concatenării valorilor text din mai multe coloane. De exemplu, într-un
raport trebuie să scriem identitatea unei persoane formată din numele
complet, aşa cum se obişnuieşte în practică. Să scriem expresia SQL care
face acest lucru pentru persoanele din tabelul din figura 4.3.
132
Expresie SQL:
SELECT Nume + “ “ + Init + “ “ + Prenume AS Student, Sectia, An, Grupa, Stare
FROM tblStudenti
ORDER BY Nume;
Rezultat:
Student Sectia An Grupa Stare

Bogdan P. Mircea Florin IEI 1 1311 Bugetar
Branea N. Daniel MEC 4 1241 Bugetar
Brucan P. Mihaela IMPI 2 1321 Bugetar
Brustur I. Cosmin IEI 1 1312 Taxa
Cotirla L. Raluca Adina TCM 1 1111 Bugetar
Cozma I. Calin Florin MEC 4 1241 Taxa
Pop I. Laura IEI 3 1331 Taxa
Popa G. Ovidiu TCM 1 1111 Bugetar
Popescu T. Marius Traian IEI 2 1321 Bugetar
Popovici D. Dumitru TCM 2 1121 Bugetar
Observaţi sintaxa folosită şi ceva nou a apărut, cuvântul cheie AS după

care urmează cuvântul Student, pe care îl regăsim în capul de tabel, ca
nume a noului câmp, obţinut prin concatenarea celor trei. Cuvântul cheie
AS introduce un alias care este un nou nume dat unui câmp. Reţineţi
această tehnică de creare a unor câmpuri.
Câmpuri calculate aritmetic. Aceste câmpuri calculate rezultă după

efectuarea unor calcule aritmetice asupra datelor regăsite. Pentru a înţelege
mecanismul creării acestor câmpuri, vom lua un exemplu practic.
Presupunem că avem un tabel în care ţinem intrările într-o magazie de
produse, al unei firme de comerţ cu piese auto. Tabelul se numeşte
tblProduse şi are coloanele Cod, Denumire, Furnizor, PU, Cantitate. Se
cere un raport al intrărilor în magazie în care apare şi câmpul Valoare,
obţinut prin produsul câmpurilor PU şi Cantitate. În figura 4.4 este
prezentat acest raport.
133
Cod Denumire Furnizor PU Cantitate Valoare

1001 Bujie DK1 Sinterom SA 12 30 360
1023 Acumulator 56A Rombat SA 124 25 3100
1231 Parbriz VW Cobra SRL 512 12 6144
1089 Antigel -30 Promaxim SRL 5.2 50 26
1904 Ulei PKT 1 Calota SRL 6.4 60 384
Fig. 4.4. Raport cu câmpul valoare calculate
Expresie SQL:
SELECT Cod, Denumire, Furnizor, PU, Cantitate, PU*Cantitate AS Valoare
FROM tblProduse;
Observaţi şi reţineţi sintaxa folosită pentru crearea noului câmp

VALOARE.
Funcţii pentru manipularea datelor
Ca aproape toate limbajele de programare, SQL acceptă folosirea funcţiilor

pentru manipularea datelor. Funcţiile sunt operaţii care, de obicei, se
efectuează asupra datelor, în general pentru a facilita transformarea şi
manipularea acestora.
Trebuie să aveţi în vedere că fiecare SGBDR are propriile funcţii şi propria

sintaxă, chiar dacă ele seamănă foarte mult, există mici diferenţe pe care
trebuie să le ştiţi studiind documentaţia sistemului pe care îl folosiţi.
Descrierea funcţiilor din acest paragraf nu o să vă creeze probleme în
folosirea funcţiilor pentru orice SGBDR întâlnit în practică.
Majoritatea implementărilor SQL acceptă următoarele tipuri de funcţii:

 Funcţiile text sunt folosite la manipularea şirurilor de text (de
exemplu, pentru ajustarea sau completarea valorilor în majuscule
şi minuscule).
 Funcţiile numerice sunt folosite pentru operaţii matematice cu
date numerice (de exemplu, pentru returnarea valorilor absolute şi
efectuarea de calcule algebrice).
134
 Funcţii de dată şi timp sunt folosite la manipularea valorilor
calendaristice de dată şi oră, şi la extragerea unor componente
caracteristice din aceste valori (an, lună, zi, oră) pentru a verifica
validitatea unor date introduse.
Funcţiile text. În această categorie vom regăsi clasicele funcţii de text care
se găsesc în toate limbajele de programare. Iată-le pe cele mai folosite:
 LEFT() - returnează caracterele indicate din stânga
şirului.
 RIGHT() - returnează caracterele indicate din dreapta şirului.
 LENGTH() - returnează lungimea unui şir.
 LOWER() - transformă toate caracterele şirului în minuscule.
 UPPER() - transformă toate caracterele şirului în majuscule.
 LTRIM() - înlătură spaţiile albe din stânga şirului.
 RTRIM() - înlătură spaţiile albe din stânga şirului.
Funcţiile numerice. În această categorie intră funcţiile folosite pentru

calcule algebrice, geometrice şi trigonometrice. Sunt mai puţin folosite la
bazele de date decât celelalte tipuri. Iată-le pe cele mai folosite:
 ABS() - returnează valoarea absolută a unui număr.
 COS() - returnează cosinusul unui unghi indicat.
 SIN() - returnează sinusul unui unghi indicat.
 TAN() - returnează tangenta unui unghi indicat.
 SQRT() - returnează rădăcina pătrată a unui număr
indicat.
 PI() - returnează valoarea lui PI.
 AVG() - returnează valoarea medie a unei coloane.
 COUNT() - returnează numărul de linii dintr-o coloană.
 MAX() - returnează valoarea cea mai mare dintr-o
coloană.
 MIN() - returnează valoarea cea mai mică dintr-o
coloană.
 SUM() - returnează suma valorilor unei coloane.
135
Ultimele cinci funcţii se mai numesc şi funcţii agregat, deoarece au în
spate algoritmi complecşi.
Funcţiile de dată şi timp. Valorile datei şi orei sunt stocate în baza de date
în formate speciale, de aceea este nevoie de funcţii speciale pentru a le
manipula. Ele sunt cele mai importante funcţii din limbajul SQL. Aceste
funcţii ne ajută să extrageţi ora, luna, ziua, anul dintr-o astfel de dată şi să
faceţi diferenţa dintre două date calendaristice. Cele mai importante sunt:
 Date() - returnează data curentă a sistemului.
 DateAdd(interval, numar, data) – returnează o dată rezultată din
adăugarea unui interval la data specificată. Parametrul “interval”
poate avea valorile: yyyy – an, q – trimestru, m – lună, d – zi etc.
Exemple: DateAdd(„yyyy‟,3,#22/11/2003#) – returnează 22/11/2006
DateAdd(„m‟,5,#22/11/2003#) – returnează 22/04/2004
 DateDiff(interval, data1, data2) – returnează diferenţa dintre două

date calendaristice, bazate pe intervalul specificat.
Exemple: DateDiff(‘d’,#15/10/2003#,#22/11/2003#) – returnează 38
 Day(data) – returnează numărul de ordine al zilei lunii dintr-o

dată calendaristică. Exemplu Day(#15/10/2003) – returnează
15.
 Hour(data) – returnează ora dintr-o dată calendaristică.
 Month(data) - returnează luna dintr-o dată calendaristică.
 Now(data) – returnează data şi ora curentă a calculatorului pe care
lucraţi.
 Time() – returnează ora calculatorului dumneavoastră.
 Year(data) – returnează anul dintr-o dată calendaristică.
Alte funcţii de dată şi sintaxa lor puteţi găsi în documentaţia SGBDR pe

care îl folosiţi.
136
Gruparea datelor
Crearea grupurilor
Am văzut în paragraful precedent că funcţiile agregat din SQL pot fi

utilizate pentru a genera sumare de date. Aceasta vă permite să număraţi
liniile, să calculaţi sume şi medii, respectiv să obţineţi valorile cele mai
mari sau cele mai mici, fără necesitatea regăsirii tuturor datelor.
Toate calculele de până acum au fost efectuate asupra tuturor datelor dintr-
un tabel, sau asupra datelor ce corespundeau clauze WHERE specifice.
Dacă aţi dori să faceţi asemenea calcule asupra unor seturi logice se
înregistrări? Aici intervine gruparea datelor. De exemplu, gruparea
vânzărilor săptămânale după numele vânzătorului care le-a făcut.
Grupurile sunt create folosind clauza GROUP BY în instrucţiunea

SELECT. Modul cel mai simplu de a înţelege crearea şi utilitatea lor este
un exemplu practic. Presupunem că avem într-o bază de date un tabel în
care ţinem evidenţa produselor vândute de mai mulţi vânzători şi dorim la
un moment dat să vedem cât a vândut fiecare, pentru a face o analiză a
activităţii, nu-i aşa? Tabelul se numeşte tblProduse şi se vede în figura 4.5.
Cod_produs Cod_vinzator Denumire produs Pret produs

100001 MR-01 Acumulator 250
100345 KL-02 Capota fata 120
100037 MR-01 Set motor 356
100445 MR-01 Cauciuc R13 65
100090 PR-02 Ulei M30 50
100552 GH-04 Antigel 34 20
Fig. 4.5. Tabelul tblProduse
O înregistrare din acest tabel reprezintă o vânzare a unui produs, făcută de

un anumit vânzător. Ne propunem să aflăm câte vânzări a făcut fiecare
vânzător.
Expresie SQL:
SELECT Cod_vinzator, COUNT(*) AS Numar_vinzari
FROM tblProduse
GROUP BY Cod_vinzator;
137
Rezultat:
Cod_vinzator Numar_vinzari
MR-01 3
KL-02 1
PR-02 1
GH-04 1
Clauza GROUP BY instruieşte sistemul de gestionare a bazei de date să

sorteze datele şi să le grupeze după coloana Cod_vinzator. În felul acesta,
numărul de vânzări va fi calculat câte o dată pentru fiecare vânzător în
parte. După cum se vede şi în rezultat, vânzătorul MR-01 a făcut 3 vânzări,
iar colegii săi, câte una.
Deoarece aţi folosit clauza GROUP BY, n-a trebuit să specificaţi fiecare
grup care trebuie evaluat şi calculat, acest lucru s-a făcut în mod automat.
Clauza GROUP BY instruieşte sistemul de gestionare a bazei de date să
grupeze datele şi apoi să aplice funcţia agregat fiecărui grup, nu asupra
întregului set de rezultate.
Iată câteva reguli pe care trebuie să le ştiţi despre utilizarea clauzei

GROUP BY:
 Clauzele GROUP BY pot conţine oricâte coloane doriţi. Asta vă
permite să imbricaţi grupuri, asigurându-vă mai mult control
asupra felului în care sunt grupate datele.
 Orice coloană enumerată în clauza GROUP BY trebuie să fie o
coloană originală sau o expresie validă (calculată, dar nu o funcţie
agregat). Dacă o expresie este utilizată în instrucţiunea SELECT,
aceeaşi expresie trebuie să fie specificată şi în clauza GROUP
BY. Nu pot fi folosite aliasuri.
 Dacă o coloană grupată conţine o linie cu o valoare NULL,
NULL va fi returnată ca grup. Deci, dacă există mai multe linii cu
valoarea NULL, ele vor fi grupate laolaltă, ceea ce este foarte
important din punct de vedere practic. De multe ori dorim să
vedem liniile cu valori nule pe o coloană, de exemplu, când
dorim să vedem integritatea datelor.
 Clauza GROUP BY trebuie plasată după toate clauzele WHERE
şi înainte de orice clauză ORDER BY.
138
Filtrarea grupurilor
Pe lângă faptul că este capabil să grupeze datele folosind clauza GROUP

BY, limbajul SQL vă permite, de asemenea, să filtraţi grupurile pe care le
includeţi sau le excludeţi. De exemplu, dacă doriţi lista tuturor
cumpărătorilor care au emis minimum 2 comenzi, trebuie să efectuaţi o
filtrare bazată pe grupul complet, nu pe linii individuale.
După cum ştim clauza WHERE filtrează liniile întregului tabel, nu a unui
grup aşa cum am dori noi. Pentru filtrarea grupurilor, limbajul SQL ne
pune la dispoziţie clauza HAVING, care este foarte asemănătoare cu
clauza WHERE. Prin urmare, clauzele WHERE şi HAVING se ocupă de
acelaşi lucru, filtrare, singura diferenţă este că prima filtrează linii, iar a
doua grupuri.
Clauza HAVING acceptă toţi operatorii clauzei WHERE. Tot ce am

învăţat despre WHERE este valabil şi pentru HAVING.
Pentru a înţelege clauza HAVING, să reluăm exemplul precedent şi să

filtrăm numai acei vânzători care au făcut mai mult de 2 vânzări. Iată
cazul:
Expresie SQL:
SELECT Cod_vinzator, COUNT(*) AS Numar_vinzari
FROM tblProduse
GROUP BY Cod_vinzator
HAVING COUNT(*) > 2;
Rezultat:
Cod_vinzator Numar_vinzari
MR-01 3
Primele trei rânduri ale instrucţiunii SELECT sunt similare cu cele

anterioare, ultimul rând, însă, adaugă o clauză HAVING care filtrează
grupurile respective cu o clauză COUNT(*) > 2 – adică 3 sau mai multe
vânzări.
După cum se vede, clauza WHERE nu funcţionează în cazul acesta,

deoarece filtrarea se bazează pe valoarea agregată a grupului, nu valorile
unor linii specifice.
139
De multe ori, în practică, apare necesitatea folosirii ambelor clauze, ceea ce
duce la mărirea vitezei de execuţie. În acest caz ordinea de execuţie ar fi
WHERE, GROUP BY şi HAVING. De exemplu, un caz real ar fi acela de
a vedea ce cumpărători au depus la noi mai mult de 2 comenzi în ultimele
12 luni. E clar că nu vom face grupuri din tot tabelul de cumpărători, ci
numai după ce i-am filtrat cu o clauză WHERE numai pe cei din ultimul
an. Încercaţi să concepeţi un astfel de tabel şi să-i aplicaţi expresia SQL
care să facă aceste lucruri.
Reţineţi că clauza HAVING se foloseşte numai în asociere cu clauza

GROUP BY. Pentru a nu confunda ordinea de folosire a clauzelor
instrucţiunii SELECT studiate până acum, iată această ordine:
SELECT
FROM
WHERE
GROUP BY
HAVING
ORDER BY
140
Lucrul cu subselecţii
Instrucţiunile SELECT sunt interogări SQL. Toate instrucţiunile SELECT

de până acum, regăseau date din tabele izolate ale bazei de date. Limbajul
SQL vă permite, de asemenea, să creaţi subselecţii: interogări înglobate în
alte interogări. De ce ar fi nevoie de aşa ceva? Exemplele care vor urma vă
vor edifica asupra acestui lucru.
Presupunem că avem structura de tabele din figura 4.6.
tblDetaliiCom
tblComenzi
DetComID ChP
Nr_comanda ChP Nr_comanda ChE
DataCom ArticolID ChE
CumparatorID ChE PretArt
Cantitate
tblCumparatori
Fig. 4.6. Diagrama de relaţii
CumparatorID ChP
NumeCump
Oras
Se vede că avem 3 tabele, câte unul pentru cumpărători, comenzi şi detalii

comenzi, între care există relaţiile desenate. Pentru a înţelege mai bine
conceptul de subselecţii vom completa aceste tabele cu date. În figura 4.7
se văd aceste tabele.
141
tblComenzi
ComandaID DataCom CumparatorID
10010 16.04.2005 6001
10011 16.04.2005 6083
10012 16.04.2005 6014
10013 16.04.2005 6025
10014 16.04.2005 6001
10015 20.04.2005 6083
10016 20.04.2005 6001
10017 20.04.2005 6014
tblDetaliiCom
DetComID ComandaID ArticolID PretArt Cantitate
20010 10010 1001 250.50 10
20011 10010 1002 115.00 12
20012 10011 1001 95.25 8
20013 10011 1052 65.00 50
20014 10012 1008 147.00 16
tblCumparatori
CumparatorID NumeCump Oras <<alte cimpuri>>
6001 ROMBAT SRL Tg. Mures ......
6002 AutoNET SRL Tg. Mures ......
6025 COMPACT SA Brasov ......
6083 ANCONA SA Sibiu ......
6014 SAVINA SRL Ludus ......
Fig. 4.7. Cele 3 tabele completate
Aceste 3 tabele fac parte dintr-o bază de date a unei firme de comerţ.
Cumpărătorii sunt firme, care comandă diferite articole produse de firma
noastră. În tabelul tblComenzi sunt ţinute comenzile, în tabelul
tblDetaliiCom sunt ţinute articolele tuturor comenzilor, iar în tabelul
tblCumparatori sunt stocaţi toţi cumpărătorii.
Ne propunem să aflăm toţi cumpărătorii care au comandat articolul 1001.

Cum procedăm? Iată paşii care trebuie urmaţi:
 Regăsiţi numele tuturor comenzilor ce conţin articolul 1001.
 Regăsiţi indicatorii tuturor cumpărătorilor care au comenzi cu
numerele returnate în pasul anterior.
142
 Regăsiţi informaţiile despre cumpărători pentru toţi identificatorii
returnaţi în pasul anterior.
Fiecare dintre aceşti paşi poate fi executat de o interogare separată.

Procedând astfel, folosiţi datele returnate de o singură instrucţiune
SELECT pentru a popula clauza WHERE a următoarei instrucţiuni
SELECT.
Puteţi, de asemenea, să folosiţi subselecţii, care să combine cele 3

interogări într-o singură instrucţiune.
Pentru primul pas, instrucţiunea SELECT care afişează numărul

comenzilor care conţin articolul 1001, este evidentă, nu-i aşa?
Expresie SQL:
SELECT ComandaID
FROM tblDetaliiCom
WHERE ArticolID = „1001‟;
Rezultat:
ComandaID
..........
10010
10011
Urmăriţi instrucţiunea SQL şi verificaţi în tabelele din figura 4.7 dacă

rezultatele întoarse sunt corecte.
Următorul pas este să găsiţi identificatorii cumpărătorilor asociaţi cu

comenzile 10010 şi 10011. Iată cum trebuie să procedaţi:
Expresie SQL:
SELECT CumparatorID
FROM tblComenzi
WHERE ComandaID IN (10010, 10011);
Rezultat:
CumparatorID
..........
6001
6083
143
Remarcaţi folosirea clauzei IN pe care aţi studiat-o puţin mai înainte.
Având indicatorii pentru cumpărătorii căutaţi, nu vă rămâne decât să

căutaţi cine sunt aceştia, în tabelul cu toţi cumpărătorii. Iată cum trebuie să
procedaţi:
Expresie SQL:
SELECT CumparatorID, NumeCump
FROM tblCumparatori
WHERE CumparatorID IN (6001, 6083);
Rezultat:
CumparatorID NumeCump
.......... .........
6001 ROMBAT SRL
6083 ANCONA SA
V-aţi descurcat foarte bine până aici, dar nu cred că sunteţi mulţumiţi cu
această metodă „băbească” de găsi informaţiile dorite. Aţi observat cum s-
au transferat rezultatele unei interogări în parametrii altei interogări.
Soluţia este să încercaţi să uniţi aceste 3 interogări într-una singură. Iată
această cale:
Expresie SQL:
SELECT CumparatorID, NumeCump
FROM tblCumparatori
WHERE CumparatorID IN (SELECT CumparatorID
FROM tblComenzi
WHERE ComandaID IN (SELECT ComandaID
FROM tblDetaliiCom
WHERE ArticolID =
„1001‟));
Rezultat:
CumparatorID NumeCump
.......... .........
6001 ROMBAT SRL
6083 ANCONA SA
Rezultatul obţinut este identic cu cel obţinut pas cu pas, dar aici aţi folosit
o singură expresie SQL. Observaţi că pentru a putea citi şi înţelege mai
144
bine această expresie am grupat-o într-un anume fel. Este o idee bună, mai
ales atunci când expresiile pe care le folosiţi sunt complicate.
O altă modalitate de utilizare a subselecţiilor este crearea de câmpuri

calculate. Să presupunem că doriţi să afişaţi numărul total al comenzilor
emise de fiecare cumpărător din tabelul tblCumparatori. Ştim că aceste
comenzi sunt stocate în tabelul tblComenzi, împreună cu identificatorii
cumpărătorilor.
Pentru a efectua această operaţie, trebuie efectuaţi următorii paşi:

 Regăsiţi lista cumpărătorilor din tabelul tblCumparatori.
 Pentru fiecare cumpărător regăsit, număraţi comenzile asociate în
tabelul tblComenzi.
Iată cum trebuie procedat (tabelele sunt cele din figura 4.7):
Expresie SQL:
SELECT NumeCump, Oras, (SELECT COUNT(*) FROM tblComenzi AS C
WHERE C.CumparatorID=tblCumparatori.CumparatorID)
AS Comenzi
FROM tblCumparatori
ORDER BY NumeCump;
Remarcaţi utilizarea aliasului C pentru tabelul tblComenzi pentru a

simplifica scrierea expresiei clauzei WHERE.
Rezultat:
NumeCump Oras Comenzi
.......... ......... ........
ANCONA SA Tg. Mures 2
AutoNET SRL Tg. Mures 0
COMPACT SA Brasov 1
ROMBAT SRL Bistrita 3
SAVINA SRL Ludus 2
Deşi subselecţiile sunt foarte utile în construirea acestui tip de instrucţiune

SELECT, trebuie avut grijă în privinţa identificării corecte a coloanelor
implicate, ştiind că sunt coloane cu acelaşi nume care apar în tabele
diferite. Aceste coloane se identifică corect dacă înaintea numelui se pune
145
numele tabelului din care face parte, ca de exemplu,
tblComenzi.CumparatorID sau tblCumparatori.CumpatatorID. Se vede
clar că câmpul CumparatorID face parte din două tabele.
Reţineţi această regulă pentru că o s-o folosiţi de multe ori!
146
Unirea tabelelor
Una din caracteristicile extrem de puternice din limbajul SQL este

capacitatea de a uni tabele din mers, în interogările de regăsire a datelor.
Unirile constituie unele dintre cele mai importante operaţii pe care le puteţi
efectua folosind instrucţiunile SELECT, şi o bună înţelegere a lor şi a
sintaxei pentru unire reprezintă o parte esenţială din învăţarea limbajului
SQL.
Ceea ce aţi învăţat în capitolele anterioare despre chei, relaţii, diagrame

sunt acum hotărâtoare pentru construirea corectă a expresiilor SQL.
Ca definiţie simplă, unirea este un mecanism folosit pentru asocierea

tabelelor într-o instrucţiune SELECT. Utilizând o sintaxă specială, mai
multe tabele pot fi unite astfel încât să fie returnat un singur set de
rezultate, iar unirea asociază din mers liniile corectate din fiecare tabel.
Crearea unei uniri simple
Crearea unei uniri este foarte simplă. În exemplul următor, vom uni două
tabele tblProduse şi tblVinzatori, al cărui rezultat este produsul cartezian al
acestora, având un număr de înregistrări egal cu produsul numerelor
acestora (figura 4.8).
tblProduse
ProdusID VinzatorID DenumireProdus PretProdus
1001 V01 Piine 2.00
1002 V03 Banane 2.50
1003 V01 Biscuiti 1.25
tblVinzatori
VinzatorID NumeVinzator OrasVinzator <<alte cimpuri>>
V01 Ban Lucia Naoiu ......
V02 Pop Mariana Sarmasel ......
Fig. 4.8. Tabelele pentru unire
Unirea celor două tabele cu o expresie SQL va genera un nou tabel cu 6

înregistrări (3 x 2).
147
Expresia SQL:
SELECT NumeVinzator, DenumireProdus, PretProdus
FROM tblVinzatori, tblProduse;
Rezultat:
NumeVinzator DenumireProdus PretProdus

Ban Lucia Piine 2.00
Ban Lucia Banane 2.50
Ban Lucia Biscuiti 1.25
Pop Mariana Piine 2.00
Pop Mariana Banane 2.50
Pop Mariana Biscuiti 1.25
Acest tip de unire nu se foloseşte niciodată sub această formă, deoarece nu

are nici un sens. Aici nu s-a pus nici un fel de condiţie, nici o legătură între
cele două tabele. Adevărata unire este cea când se fac legături între tabele,
aşa cum se vede mai departe.
Expresia SQL:
FROM tblVinzatori, tblProduse;
WHERE tblVinzatiri.VinzatorID=tblProduse.VinzatorID;
Rezultat:
NumeVinzator DenumireProdus PretProdus

Ban Lucia Piine 2.00
Ban Lucia Biscuiti 1.25
Ce s-a întâmplat de fapt? Clauza WHERE a filtrat înregistrările produsului

cartezian, rezultând numai 2 înregistrări.
Acest tip de uniri, bazate pe verificarea egalităţii dintre două tabele, se mai
numesc şi uniri interioare. Unele SGBGR-uri au sintaxe diferite,
specificând explicit tipul de unire. Studiaţi cu atenţie documentaţia
SGBDR-ului cu care lucraţi pentru a-i folosi corect sintaxa.
148
O altă variantă de unire este cea făcută în clauza FROM prin folosirea
clauzei speciale INNER JOIN ... ON, după cum se vede mai jos:
FROM tblVinzatori INNER JOIN tblProduse
ON tblVinzatiri.VinzatorID=tblProduse.VinzatorID;
Această variantă este preferată de programatori, dar ea este şi cea indicată

de specificaţiile SQL.
149
Uniri avansate
Limbajul SQL nu impune limite asupra numărului de tabele ce pot fi unite

într-o instrucţiune SELECT. Regulile de bază pentru crearea unei uniri
rămân aceleaşi. În primul rând, enumeraţi toate tabelele, apoi definiţi
relaţiile dintre ele. Iată un exemplu:
tblProduse
ProdusID VinzatorID DenumireProdus PretProdus DescriereProdus
1001 V01 Piine 2.00
1002 V03 Inghetata 1.25
1003 V01 Biscuiti 0.25
1004 V01 Ciocolata 2.65
1052 V02 Bricheta 0.35
1078 V03 Banane 2.50
tblDetaliiComenzi
DetComID ComandaID ProdusID Cantitate
20010 10010 1001 10
20011 10010 1002 12
20012 10010 1078 8
20013 10010 1052 50
20014 10012 1008 16
tblVinzatori
VinzatorID NumeVinzator Oras <<alte cimpuri>>
V01 Ban Lucia Naoiu ......
V02 Pop Mariana Sarmasel ......
V03 Baciu Mia Naoiu ......
V04 Ban Ionel Roma ......
Fig. 4.9. Tabele implicate în unire
Ne propunem să aplicăm unirea într-un caz concret de regăsire a unor

informaţii care se găsesc în trei tabele. Căutăm produsele care compun
comanda 10010, precum şi vânzătorul asociat. Studiaţi expresia SQL care
urmează şi verificaţi rezultatul obţinut.
Expresie SQL:
SELECT DenumireProdus, NumeVinzator, PretProdus, Cantitate
FROM tblProduse, tblDetaliiCom, tblVinzatori
WHERE tblDetaliiComenzi.ProdusID=tblProduse.ProdusID
150
AND tblProduse.VinzatorID=tblVinzatori.VinzatorID
AND ComandaID= „10010‟;
Rezultat:
DenumireProdus NumeVinzator PretProdus Cantitate
Piine Ban Lucia 2.00 10
Inghetata Baciu Mia 1.25 12
Banane Ban Lucia 2.50 8
Bricheta Pop Mariana 0.35 50
Primele două rânduri ale clauzei WHERE fac legătura între perechile de
tabele tblDetaliiComenzi-tblProduse şi tblProduse-tblVinzatori, iar al
treilea filtrează doar produsele pentru comanda 10010.
Iată câteva aspecte esenţiale legate de uniri şi folosirea lor:

 Consultaţi-vă documentaţia sistemului de gestionare a bazei de
date, pentru a afla sintaxa exactă a unirii pe care o acceptă.
 Asiguraţi-vă că utilizaţi condiţia corectă de unire, indiferent de
sintaxa folosită, altfel vor fi returnate date incorecte.
 Asiguraţi-vă că prevedeţi întotdeauna o condiţie de unire, altfel
veţi sfârşi cu un produs cartezian.
 Într-o unire, puteţi include mai multe tabele, ba chiar să aveţi
tipuri diferite de unire pentru fiecare. Deşi metoda este corectă şi
adesea utilă, asiguraţi-vă că testaţi separat fiecare unire, înainte de
a le testa împreună. În felul acesta depanările vor fi mult
simplificate.
 O metodă bună este folosirea aliasurilor pentru tabele, pentru a
simplifica scrierea expresiilor SQL.
Compunerea interogărilor
Interogarea bazelor de date este chiar sensul existenţei lor. Nimeni n-a
creat vreo bază de date fără să o interogheze cândva, când se adună
suficiente date în ea. Până acum noi am făcut interogări folosind o singură
instrucţiune SELECT, care returna date din unul sau mai multe tabele.
Limbajul SQL vă permite să efectuaţi mai multe interogări (mai multe
151
instrucţiuni SELECT) şi să returnaţi rezultatele sub forma unui singur set
de rezultate de interogare. De obicei, aceste interogări sunt cunoscute drept
reuniuni sau interogări compuse.
În esenţă, există două situaţii generale în care să folosiţi interogările

compuse:
 Pentru a returna date structurate similar din tabele diferite, într-o
singură interogare.
 Pentru a efectua mai multe interogări asupra unui singur tabel,
returnând datele ca o singură interogare.
Pentru a compune interogările SQL se foloseşte operatorul UNION. Cu

ajutorul lui pot fi specificate instrucţiuni SELECT multiple, iar rezultatele
acestora pot fi combinate într-un singur set de rezultate.
Folosirea operatorului UNION este destul de simplă, tot ce aveţi de făcut

este să specificaţi toate instrucţiunile SELECT şi să plasaţi între ele
cuvântul cheie UNION.
Să luăm un exemplu. Presupunem că trebuie să întocmiţi un raport despre

toţi cumpărătorii din judeţele Bistriţa-Năsăud, Braşov şi Cluj. În acelaşi
raport doriţi să includeţi toate locaţiile firmei ANCONA SA, indiferent în
ce judeţ s-ar afla ele. Desigur, se poate crea o clauza WHERE care să
realizeze acest lucru, dar acum veţi folosi operatorul UNION. Figura 4.10
conţine tabelul cu cumpărătorii, care o să fie folosit în acest exemplu.
CumparatorID NumeCumparator JudCump PersContact Email

6001 ROMBAT SA BN Pop Petru ppop@rmbat.ro
6002 AutoNET SRL MS Beldean Vian bvian@auto.ro
6004 SAVINA SRL MS Parauan Bicu pbicu@savina.ro
6025 COMPACT SRL BV Pietroi Sorina sorina@yahoo.ro
6083 ANCONA SA MS Palade Sorin sorin@ancona.ro
6084 ANCONA SA CJ Crisan Ovidiu covi@ancona.ro
Fig. 4.10. Tabelul tblCumparatori
După cum ştiţi deja, folosirea operatorului UNION implică scrierea mai
multor instrucţiuni SELECT, de aceea veţi crea mai întâi fiecare
instrucţiune SELECT, apoi le veţi compune.
152
Prima instrucţiune SELECT va căuta cumpărătorii din cele 3 judeţe
amintite.
Expresie SQL:
SELECT NumeCumparator, JudCump, PersContact, Email
FROM tblCumparatori
WHERE JudetCumparator IN ('BN', 'BV','CJ');
Rezultat:
NumeCumparator JudCump PersContact Email
ROMBAT SA BN Pop Petru ppop@rmbat.ro
COMPACT SRL BV Pietroi Sorina sorina@yahoo.ro
ANCONA SA CJ Crisan Ovidiu covi@ancona.ro
A doua instrucţiune SELECT va căuta toate locaţiile firmei ANCONA SA.
Expresie SQL:
FROM tblCumparatori
WHERE NumeCumparator= 'ANCONA SA';
Rezultat:
ANCONA SA MS Palade Sorin sorin@ancona.ro
După cum se vede, există două locaţii pentru firma ANCONA SA, una în
judeţul Mureş şi una în judeţul Cluj.
Pentru a compune cele 2 interogări veţi proceda astfel:
Expresie SQL:
SELECT NumeCumparator,JudCump, PersContact, Email
FROM tblCumparatori
WHERE JudetCumparator IN ('BN', 'BV','CJ')
UNION
FROM tblCumparatori
WHERE NumeCumparator= 'ANCONA SA';
153
Rezultat:
Deoarece ANCONA SA se găseşte în ambele interogări, SQL nu îl scrie de

două ori. Dacă totuşi, dorim să apară şi dublurile, atunci vom folosi clauza
UNION ALL. Fără extensia ALL, duplicatele se elimină automat.
Dacă dorim ca rezultatele să fie sortate, vom adăuga clauza ORDER BY

după ultima clauză WHERE. De remarcat, că operaţiile UNION acceptă o
singură clauză ORDER BY, după ultima instrucţiune SELECT. Iată cum
arată o expresie SQL cu afişarea tuturor înregistrărilor care sunt şi
ordonate:
Expresie SQL:
SELECT NumeCumparator, PersContact, Email
FROM tblCumparatori
WHERE JudetCumparator IN ('BN', 'BV','CJ')
UNION ALL
SELECT NumeCumparator, PersContact, Email
FROM tblCumparatori
WHERE NumeCumparator= 'ANCONA SA'
ORDER BY NumeCumparator;
Rezultat:
Observaţi înregistrarea dublă ANCONA SA, care apare din cauza

operatorului UNION ALL.
Iată câteva reguli pentru operaţii cu operatorul UNION:

 Toate interogările dintr-o operaţie UNION trebuie să conţină
aceleaşi coloane, expresii sau funcţii agregat.
154
 Coloanele, expresiile şi funcţiile agregat trebuie să apară exact în
aceeaşi ordine în fiecare instrucţiune SELECT din operaţia
UNION.
 Tipurile de date din coloane trebuie să fie compatibile. Nu este
necesar ca datele să fie exact de acelaşi tip, dar trebuie să fie de
un tip pe care SGBDR-ul îl poate transforma implicit (de
exemplu tipuri de date numerice diferite sau tipuri de date
calendaristice diferite).
Inserarea, actualizarea şi ştergerea datelor
Datele unei baze de date trebuie periodic actualizate, pentru a reflecta

activităţile unei firme sau organizaţii. Întreţinerea datelor este o activitate
continuă, plină de responsabilitate, fără de care, utilitatea bazei de date este
îndoielnică. Limbajul SQL oferă instrucţiuni dedicate întreţinerii datelor
unei baze.
Întreţinerea unei baze de date constă, de fapt, în introducerea de noi date,

modificarea unor date existente sau ştergerea datelor din tabelele acesteia.
Toate aceste operaţii o să le învăţaţi în cele ce urmează.
Inserarea datelor se face cu instrucţiunea INSERT
Inserarea datelor
Toate expresiile SQL de până acum începeau cu instrucţiunea SELECT. Pe

lângă aceasta, mai sunt alte 4 instrucţiuni pe care le vom învăţa în
continuare. Acestea sunt INSERT, UPDATE, DELETE şi CREATE
TABLE.
Prima dintre ele este instrucţiunea INSERT, folosită pentru inserarea de

linii (înregistrări) într-un tabel de bază de date. Inserarea se poate face în
mai multe moduri:
 Inserarea unei singure linii complete;
 Inserarea unei singure linii parţiale;
 Inserarea rezultatelor unei interogări.
Le vom studia pe rând.
155
Inserarea unei linii complete.
Cel mai simplu mod de a insera o linie într-un tabel este folosirea sintaxei
de bază a instrucţiunii INSERT, care cere numele tabelului şi valorile care
vor fi inserate în noua linie. Iată un exemplu:
INSERT INTO tblProduse ( ProdusID, CodProdus, Denumire, UM, Pret, Observatii )
VALUES ('32', '20033', 'Cafea_Jacobs', 'kg', '12.23', 'Conform normelor UE');
Această expresie SQL, inserează în tabelul tblProduse un rând cu valorile

prezentate în paranteza de după VALUES. Valorile corespund, în ordine, cu
denumirile câmpurilor din prima paranteză a expresiei SQL, indiferent de
ordinea în care apar în tabel. Dacă numărul coloanelor indicate nu este
acelaşi cu numărul valorilor, se va produce un mesaj de eroare care
precizează acest lucru.
Inserarea unei singure linii parţiale.
Există cazuri în care nu este nevoie să se completeze toate câmpurile unei

înregistrări, fie că nu se cunosc valorile în acel moment, fie că nu e
necesară valoarea acelui câmp pentru înregistrarea respectivă. În acest caz,
se completează numai acele câmpuri pentru care există valori. Este de la
sine înţeles că prin proiectarea bazei de date, este prevăzut că acele
câmpuri necompletate au voie să aibă valori nule.
Din exemplul anterior, se poate scoate câmpul Observatii care nu este

obligatoriu. Expresia SQL va arăta astfel:
INSERT INTO tblProduse ( ProdusID, CodProdus, Denumire, UM, Pret)
VALUES ('32', '20033', 'Cafea_Jacobs', 'kg', '12.23');
Deci, câmpul Observatii şi valoarea corespunzătoare nu apar în expresia

SQL.
Inserarea rezultatelor unei interogări.
Inserarea într-un tabel a unei singure înregistrări, complete sau parţiale,

este o acţiune obişnuită, de rutină, utilizată de obicei de administratorul
bazei de date pentru completări minore ale unui tabel. Cele mai
spectaculoase completări ale tabelelor sunt cele cu înregistrări provenite
din interogări ale altor tabele.
156
Aceste inserări se pot face manual de către administratorul bazei de date,
dar cel mai probabil mod de a insera într-un tabel înregistrările provenite
dintr-o interogare, este folosirea limbajului VBA, în cadrul unor aplicaţii
integrate.
Această formă de instrucţiune INSERT, care poate fi utilizată pentru a

insera rezultatul unei instrucţiuni SELECT se numeşte INSERT SELECT,
fiind alcătuită dintr-o instrucţiune INSERT şi o instrucţiune SELECT. Să
presupunem că aveţi într-o bază de date un tabel numit tblClienti care
conţine clienţii unei firme. Pentru a adăuga noi clienţi, în practică se
procedează astfel: nu toţi clienţii se introduc direct în tabel, ci mai întâi se
introduc într-un tabel temporar, apoi se decide care sunt clienţii care merită
introduşi în baza de date şi numai atunci, se introduc în tabelul tblClienti.
Această expresie SQL este prezentată mai jos:

INSERT INTO tblClienti (ClientID, Denumire, CodFiscal, PersoanaContact, Adresa)
SELECT (ClientID, Denumire, CodFiscal, PersoanaContact, Adresa)
FROM tblClientiNoi;
După cum se vede, tabelul tblClienti este completat cu înregistrări din

tabelul tblClientiNoi, dar pot fi şi alte surse de interogare. Totul este ca
numărul de câmpuri şi tipul lor de dată să coincidă.
Actualizarea datelor
Datele unei baze de date suferă dese modificări. Cum datele se găsesc în
tabele, este nevoie ca aceste tabele să fie periodic actualizate. Ca să
modificaţi datele dintr-un tabel, trebuie să folosiţi instrucţiunea UPDATE.
Ea poate fi folosită în două moduri:
 Pentru actualizarea numai a anumitor linii dintr-un tabel;
 Pentru actualizarea tuturor liniilor unui tabel.
Instrucţiunea UPDATE folosită defectuos, poate să vă producă mari

neplăceri, ştiut fiind că aici nu există posibilitatea de revenire în sensul
„undo”. Prin urmare trebuie să fiţi foarte atenţi la folosirea ei. De altfel,
unele sisteme de gestiune a bazelor de date au restricţii de securitate pentru
a împiedica unele acţiuni greşite asupra bazei de date.
Instrucţiunea UPDATE este foarte simplu de utilizat. Sintaxa ei este

alcătuită din 3 părţi:
157
 Tabelul care trebuie actualizat;
 Numele coloanelor şi noile lor valori;
 Condiţia filtru care determină liniile care trebuie actualizate.
Să examinăm un caz banal. Clientul cu codul 1000245, are acum adresă de

e-mail şi ar trebui să apară şi tabelul cu clienţii, numit tblClienti. Expresia
SQL care efectuează această actualizare este următoarea:
UPDATE tblClienti
SET E_mail = ‘alfaroom@yahoo.com’
WHERE ClientID = ’1000245’;
Este de la sine înţeles că cele 2 câmpuri (E_mail şi ClientID) sunt câmpuri

ale tabelului tblClienti.
Instrucţiunea UPDATE începe întotdeauna cu numele tabelului care este

actualizat (aici tblClienti). Urmează comanda SET, care atribuie noua
valoare unei coloane (aici coloana E_mail).
Instrucţiunea UPDATE se termină cu o clauză WHERE, care anunţă

sistemul de gestionare a bazei de date ce linie să actualizeze. Atenţie, fără
clauza WHERE sistemul ar actualiza toate liniile din tabelul tblClienti,
punând adresa de e-mail ‘alfaroom@yahoo.com’ la toţi clienţii, ceea ce ar fi un
lucru inadmisibil.
Actualizarea mai multor coloane necesită a sintaxă corespunzătoare cum se

poate vedea mai jos:
UPDATE tblClienti
SET E_mail = ‘alfaroom@yahoo.com’, PersoanaContact = ‘Mocian Ioan’
Din această expresie SQL se pot deduce următoarele:

 Perechile de câmpuri şi valorile lor (între ele este semnul = ) se
despart prin virgulă;
 Avem atâtea egaluri câte câmpuri trebuie actualizate;
 Înregistrarea care trebuie actualizată este identificată cu câmpul
ClientID, care este cheie primară în tabelul tblClienti, vă mai
amintiţi desigur ea.
158
Pentru a şterge valoarea unei coloane, tehnica este ca acea coloană să fie
setată pe valoarea NULL (condiţia este ca acel câmp să accepte valoarea
NULL). Iată expresia SQL care face acest lucru:
UPDATE tblClienti
SET E_mail = NULL
Această expresie SQL, şterge adresa de e-mail a clientului 1000245.
Mai târziu, în capitolul 5 veţi putea face teste şi simulări cu actualizări de

date pe o bază de date de test.
Ştergerea datelor
Pentru a şterge linii dintr-un tabel, necesitate practică frecventă, se

foloseşte instrucţiunea DELETE. Ea poate fi utilizată în două modalităţi:
 Pentru ştergerea numai a anumitor linii dintr-un tabel;
 Pentru ştergerea tuturor liniilor unui tabel.
Deşi este o necesitate practică, folosirea instrucţiunii DELETE antrenează

mari riscuri, de aceea este bine să faceţi teste pe o copie a unei baze de
date. Oricum, ca începători nu vă va pune nimeni să „curăţaţi” tabelele
unei baze de date reale de înregistrările inutile.
Să presupunem că printre clienţi, există câţiva care şi-au închis firma, deci
nu mai e necesar să-i avem în tabelul tblClienti, aşa că trebuie să-i ştergem
din tabel. De exemplu, clientul cu codul 1000378 trebuie şters din tabel.
Expresia SQL care face acest lucru este următoarea:
DELETE FROM tblClienti

Această expresie SQL ar trebui înţeleasă imediat, pentru că e foarte clară:

din tabelul tblClienti se şterge clientul care are câmpul ClientID la valoarea
1000378.
De remarcat faptul că instrucţiunea DELETE nu conţine nume de coloane,

ea şterge linii întregi, nu coloane. Pentru a şterge valorile din anumite
coloane veţi folosi instrucţiunea UPDATE, prezentată puţin mai înainte.
159
De asemenea, instrucţiunea DELETE nu şterge tabele, ci numai înregistrări
din tabele. Chiar dacă şterge toate înregistrările unui tabel, aceste rămâne,
dar va fi gol.
Aţi văzut cum se poate şterge dintr-un tabel o înregistrare. Întrebarea

firească este cum se pot şterge dintr-un tabel toate înregistrările. Şi aici, ca
în orice acţiune de distrugere, este foarte simplu: trebuie eliminată clauza
WHERE. Iată ce simplu puteţi „scăpa” de înregistrările unui tabel:
DELETE FROM tblClienti ;
Luaţi-vă măsurile de precauţie când lucraţi cu această instrucţiune!
Principii privind actualizarea şi ştergerea datelor
După cum spuneam, instrucţiunile UPDATE şi DELETE sunt instrucţiuni,

pe cât de utile, pe atât de periculoase. Trebuie să reţineţi faptul că în SQL
nu există un buton Undo, de anulare a unei operaţiuni greşite, de aceea fiţi
foarte atenţi când folosiţi aceste 2 instrucţiuni.
În sinteză, iată câteva principii pe care trebuie să le respectaţi, ca utilizator

al limbajului SQL:
 Nu executaţi niciodată instrucţiunile UPDATE şi DELETE fără o
clauză WHERE, decât atunci când doriţi să realmente să
actualizaţi sau să ştergeţi toate liniile unui tabel;
 Asiguraţi-vă că toate tabelele au o cheie primară (dacă aţi uitat ce
este aceasta, consultaţi capitolul respectiv) pe care să o folosiţi
într-o clauză WHERE;
 Înainte de a folosi o clauză WHERE cu instrucţiunile UPDATE
sau DELETE, testaţi-o mai întâi cu o instrucţiune SELECT, ca să
vă asiguraţi că filtrează înregistrările corecte – din cauză că la
clauza WHERE puteţi greşi destul de uşor.
 Folosiţi integritatea referenţială (vezi paragraful Integritatea la
nivel de relaţie) impusă bazelor de date astfel ca sistemul de
gestiune al bazelor de date (SGBD) să nu permită ştergerea
liniilor care au date în alte tabele asociate lor.
 Unele SGBD-uri permit administratorilor de baze de date să
impună limitări ce împiedică executarea instrucţiunilor UPDATE
şi DELETE fără o clauză WHERE.
160
 Nu vă apucaţi să executaţi operaţiuni de actualizare sau ştergere,
înainte să faceţi o copie de siguranţă a bazei de date. Veţi fi astfel
mai relaxaţi, iar în caz de o manevră greşită (oameni suntem,
nu?), puteţi reveni la ce a fost, fără nici o problemă.
 Nu executaţi operaţii de ştergere printre „alte activităţi” pentru că
aici aveţi nevoie de concentrare maximă (amintiţi-vă că aici nu
este Undo şi „ce aţi făcut, făcut rămâne”).
Respectaţi aceste câteva principii enumerate, care vă ajută mult, gândindu-

vă că oricâte lucruri bune aţi face în firma la care lucraţi ca administrator
de baze de date, o greşeală ca ştergerea completă a unor tabele sau câmpuri
vă descalifică definitiv în ochii celor care vă plătesc.
161
Crearea şi manipularea tabelelor
Limbajul SQL nu este folosit numai pentru manipularea datelor. Cu

ajutorul limbajului SQL se pot crea, modifica şi şterge tabele, chiar dacă
toate SGBD-urile au propriile unelte pentru aceste acţiuni.
În general, există două modalităţi de creare a tabelelor de baze de date:

 Majoritatea SGBD-urilor deţine propriul instrument de
gestionare, folosit şi la crearea şi administrarea interactivă a
tabelelor bazei de date.
 Tabelele pot fi create, de asemenea, în mod direct, prin
intermediul instrucţiunilor SQL.
Instrucţiunea de creare a tabelelor cu limbajul SQL este CREATE TABLE.

Trebuie menţionat faptul că atunci când folosim instrumente interactive, de
fapt folosim instrucţiuni SQL care sunt generate şi executate de sistem,
fără să ne dăm seama pentru că totul se face „în spatele” interfeţei.
Pentru a crea un tabel folosind instrucţiunea CREATE TABLE, trebuie

specificate următoarele informaţii:
 Numele noului tabel, specificat după cuvântul cheie CREATE
TABLE;
 Numele şi definirea coloanelor din tabel, separate prin virgulă;
Iată cum arată o expresie SQL de creare a unui tabel (în Access):
CREATE TABLE tblProduse
(
ProdusID Integer NOT NULL,
CodProdus Text(50) NOT NULL,
Denumire Text(80) NOT NULL,
UM Text(10) NOT NULL,
PretUnitar Number NOT NULL,
Observatii Text(255)
);
După cum se vede, instrucţiunea de mai sus creează tabelul tblProduse

care are 6 câmpuri, despărţite prin virgule. Observaţi tipurile de date
162
folosite, întreg, text şi număr real (Number). De asemenea, pentru a
specifica faptul că un câmp cere valoare obligatorie trebuie pusă expresia
NOT NULL, iar dacă lipseşte se consideră că s-a pus NULL, adică acel
câmp poate să rămână necompletat. Din cele 6 câmpuri, numai Observatii
nu este obligatoriu de completat.
Între numele coloanei, tipul de dată şi cuvântul cheie NOT NULL se pune
spaţiu. Modul de aranjare a expresiei SQL nu este important, deoarece
spaţiile suplimentare sunt ignorate, se poate folosi un singur rând pentru
definirea tuturor coloanelor sau se pot aranja pe mai multe rânduri ca în
exemplul prezentat mai înainte, pentru lizibilitate.
Numele tabelului care se creează nu trebuie să existe în baza de date, dacă

există se va produce un mesaj de eroare care indică acest lucru.
Adăugarea unei coloane. De multe ori în practică apare necesitatea

adăugării unei coloane la un tabel care a fost creat şi care are chiar date.
Limbajul SQL ne pune la dispoziţie o instrucţiune pentru a face acest lucru,
numită ALTER TABLE şi clauza ADD. Iată un exemplu de folosire a
acestei instrucţiuni:
ALTER TABLE tblProduse
ADD Furnizor Text(50);
Această expresie SQL adaugă tabelului tblProduse coloana Furnizor.
Ştergerea unei coloane. Dacă diagrama de relaţii permite, adică acel câmp
nu este implicat în vreo relaţie, coloana (câmpul) poate fi ştearsă dintr-un
tabel. Această manevră se face cu ajutorul instrucţiunii ALTER TABLE şi
clauza DROP COLUMN. Iată un exemplu de folosire a acestei
instrucţiuni:
DROP COLUMN Furnizor;
Această expresie SQL şterge din tabelul tblProduse coloana Furnizor.
Ştergerea unui tabel. Aşa cum se poate crea un tabel într-o bază de date
cu ajutorul limbajului SQL, tot aşa se poate şi înlătura un tabel din baza de
date. Operaţiunea este foarte simplă, chiar periculos de simplă.
Astfel, pentru a elimina din baza de date tabelul tblProduse folosim

expresia SQL următoare:
163
DROP TABLE tblProduse;
Operaţiunea nu este însoţită de nici un mesaj, nu poate fi anulată, tabelul

rămânând şters definitiv, aşa că trebuie să fiţi extrem de precauţi când
faceţi o astfel de manevră.
Elemente performante ale limbajului SQL

Ceea ce am studiat până acum se încadrează în nivelul propus pentru acest
curs, însă limbajul SQL nu şi-a terminat posibilităţile, oferind
programatorilor profesionişti elemente cu adevărat performante. În acest
capitol vor fi prezentate, pe scurt, aceste elemente de performanţă fără a
intra în amănunte de ordin tehnic.
În continuare vor fi prezentate aceste posibilităţi avansate ale limbajului

SQL.
Proceduri stocate. Instrucţiunile SQL folosite până acum sunt simple,

deoarece folosesc o singură instrucţiune aplicată unuia sau mai multor
tabele. Însă, nu toate operaţiile sunt atât de simple, adesea sunt necesare
mai multe instrucţiuni.
Iată un caz de operaţie complexă:

 Pentru a onora o comandă trebuie mai întâi să vedem dacă avem
în stoc articolele respective;
 Dacă există, ele trebuie trecute pe o listă rezervată şi scăzute din
stoc pentru a nu fi vândute altor cumpărători;
 Articolele care nu există în stoc şi sunt cerute de comandă,
trebuie trecute pe o listă pentru a fi aprovizionate;
 Cumpărătorul trebuie anunţat asupra articolelor existente în stoc
(adică livrabile imediat) şi asupra celor care urmează să fie
aprovizionate.
Scenariul prezentat necesită mai multe instrucţiuni SQL adresate mai

multor tabele. În plus, instrucţiunile SQL trebuie efectuate într-o anumită
ordine, iar ordinea depinde de existenţa produselor în stoc (dacă există, nu
mai trebuie comandate).
164
Cum trebuie scrise aceste instrucţiuni? Am putea să scriem individual
fiecare instrucţiune SQL, apoi pe baza rezultatului să executăm alte
instrucţiuni condiţionate. Acţiunea ar trebui repetată pentru fiecare
comandă, iar persoana care face acest lucru trebuie să aibă cunoştinţe şi
experienţă corespunzătoare.
Acelaşi lucru se poate face printr-o procedură stocată. Procedurile stocate

nu sunt altceva decât seturi de una sau mai multe instrucţiuni SQL salvate
pentru o viitoare folosire.
De ce trebuie folosite procedurile stocate? Iată câteva din motive:

 Pentru a simplifica operaţiile complexe (ca cea prezentată ma
înainte), prin înglobarea proceselor într-o singură unitate, uşor de
utilizat;
 Prin eliminarea paşilor individuali se elimină erorile umane şi se
asigură coerenţa datelor;
 Limitarea accesului la datele de bază, prin intermediul
procedurilor stocate, reduce şansa deteriorării datelor,
intenţionată sau nu.
 Procedurile stocate au formă compilată, deci se execută mult mai
repede;
 În limbajul SQL există elemente şi caracteristici disponibile
numai pentru cereri unice. Procedurile stocate le pot folosi pentru
a scrie cod mai puternic şi mai flexibil.
Prin urmare există 3 beneficii majore ale procedurilor stocate: simplitate,

securitate şi performanţă.
Pentru a practica efectiv în folosirea procedurilor stocate, va trebui să

folosiţi surse de informare care se găsesc din belşug în librării şi pe
Internet.
Tranzacţii. Tranzacţiile sunt facilităţi ale limbajului SQL care asigură că

loturile de operaţii SQL sunt executate complet sau deloc. Ştim că tabelele
unei baze de date relaţionale sunt legate între ele prin intermediul cheilor
primare şi cheilor externe. Prin urmare, unele modificări dintr-un tabel
produce modificări de date în alt tabel.
165
De exemplu, dacă se adaugă o comandă în tabelul tblComenzi, în tabelul
tblDetaliiComenzi trebuie introduse articolele acelei comenzi. Mai întâi se
completează tabelul tblComenzi, apoi se completează tabelul
tblDetaliiComenzi. Se pune întrebarea, ce se întâmplă dacă în timpul
completării articolelor comenzii în tabelul tblDetaliiComenzi, se întrerupe
curentul sau nu există suficient spaţiu pe hard-disc?
Evident, va apare o comandă care nu are articole, sau o comandă care nu

are toate articolele, oricum o situaţie nereală. Cu siguranţă, au fost multe
astfel de situaţii, ceea ce i-a forţat pe creatorii limbajului SQL să găsească
soluţii de rezolvare. Astfel au fost inventate tranzacţiile.
Prelucrarea de tranzacţii este un mecanism folosit pentru gestionarea

seturilor de operaţii SQL ce trebuie executate în loturi, pentru ca baza de
date să nu conţină niciodată rezultatele unor operaţii parţiale.
Prin intermediul prelucrării de tranzacţii, vă puteţi asigura că seturile de

operaţii nu sunt întrerupte în mijlocul prelucrării – ele sunt fie complet
executate, fie deloc. Dacă nu intervine nici o eroare, întregul set de
instrucţiuni este executat, iar datele sunt trecute în tabelele bazei de date.
Dacă apare o eroare, atunci se poate derula în mod automat o revenire la
starea iniţială, stare cunoscută şi sigură.
Datorită importanţei şi complexităţii tranzacţiilor, acestea sunt folosite

numai de programatorii profesionişti, iar nivelul acestui curs este de a vă
iniţia în folosirea limbajului SQL. Dacă aţi înţeles până acum mecanismul
acestui limbaj, veţi putea trece fără probleme şi la părţile sale avansate,
pentru că oricum aveţi baza de plecare. Desigur, trebuie să mai studiaţi
bibliografie, care se găseşte azi din belşug, atât scrisă cât şi pe Internet.
Cursoarele. Uneori şi nu de puţine ori, în aplicaţiile performante este

nevoie de parcurgerea unui set de date provenite dintr-o interogare, aşa
cum se parcurg liniile unui tabel al bazei de date. Acest lucru este realizat
cu ajutorul cursoarelor.
Un cursor este o interogare în baza de date stocată în serverul SGBD – nu o

instrucţiune SELECT, ci rezultatul acesteia, adică date efective. Odată ce
cursorul este stocat, aplicaţia poate să deruleze sau să răsfoiască în sus şi în
jos prin date, după cum este nevoie.
166
Concluzii
SQL este limbajul cel mai răspândit în lucrul cu bazele de date. Indiferent
dacă sunteţi programator de aplicaţii, administrator de baze de date (vezi
Anexa A), designer de aplicaţii Web sau utilizator al suitei Microsoft
Office, o bună cunoaştere a limbajului SQL, constituie o parte importantă a
interacţiunii cu bazele de date.
Sunt azi o mulţime de cărţi despre limbajul SQL şi unele sunt chiar foarte
bune, toate au însă un lucru comun: conţin prea multe informaţii pentru
majoritatea utilizatorilor. Lipsesc exemplele simple, sugestive care, de
multe ori, fac mai mult decât pagini întregi de explicaţii sterile.
Capitolul 4, pe care tocmai l-aţi parcurs, va pus la dispoziţie acele

cunoştinţe care vă pot ajuta să dezvoltaţi aplicaţii de baze de date la un
nivel cerut de multe firme mici sau medii în care aţi putea lucra. Exemplele
prezentate vă pot ajuta să înţelegeţi multe din aspectele practice ale
folosirii limbajului SQL.
Acei dintre dumneavoastră care vor ajunge administratori de baze de date,

găsesc aici informaţii preţioase pentru activitatea lor curentă. Pentru cei
care doresc mai mult, pot trece la studierea şi aplicarea elementelor
avansate ale limbajului SQL, cum sunt procedurile stocate, tranzacţiile,
cursoarele etc.
În capitolul următor, veţi avea ocazia să folosiţi limbajul SQL în cadrul

sistemului de gestiune a bazelor de date relaţionale ACCESS.
167
Capitolul 5. Utilizarea programului ACCESS
În acest capitol veţi învăţa să folosiţi cel mai popular sistem de gestiune a bazelor
de date relaţionale, numit Access. Acesta face parte din produsul Microsoft Office
al firmei Microsoft. Veţi aplica „pe viu” tot ce aţi învăţat în capitolele precedente,
veţi da viaţă bazelor de date pe care le-aţi proiectat. Acum veţi înţelege cu
adevărat unele lucruri peste care aţi trecut mai uşor în faza de proiectare.
Prezentare generală
Microsoft ACCESS este baza de date folosită la birou de mii de utilizatori,
care doresc să-şi stocheze şi să-şi acceseze cu uşurinţă datele de interes
personal, precum şi în medii cu mai mulţi utilizatori. În această prezentare
se va lucra cu varianta ACCESS 2002 din pachetul MS OFFICE XP, al
cărui format standard este de ACCESS 2000.
Trebuie reţinut faptul că ACCESS este atât un sistem de stocare a datelor,

cât şi un sistem de gestiune a acestora. Una dintre facilităţile sale
importante este interfaţa grafică uşor de înţeles care permite crearea
interogărilor, formularelor şi rapoartelor – facilitate care lipseşte din multe
baze de date mai mari şi mai complexe. Cu alte cuvinte, chiar şi
programatorii fără prea mare experienţă pot să se folosească de ACCESS
pentru a transforma un vraf de facturi, un fişier cu numele clienţilor, un
registru contabil şi o listă de stocuri într-o bază de date relaţională, în care
introducerea, actualizarea şi raportarea informaţiilor să se poată face cu un
clic pe un buton.
O caracteristică importantă a bazelor de date ACCESS este faptul că toate

componentele sale tabele, formulare, interogări şi rapoarte se păstrează
într-un singur fişier. Acest lucru face ca operaţiunile din interiorul bazei de
date să se facă rapid. Acest fişier are extensia .mdb şi poate fi copiat cu
uşurinţă dintr-o locaţie în alta. Limbajul SQL din ACCESS are toate
posibilităţile descrise în capitolul anterior.
168
Tot ce aţi învăţat în capitolele precedente, începând cu terminologia,
relaţiile între tabele, integritatea datelor şi diagrame veţi regăsi în ACCESS
într-o formă specifică acestui program. Mulţi începători sunt frustraţi de
faptul că tabelele ACCESS, deşi seamănă oarecum cu cele din Excel, au un
comportament total diferit. Dacă aceştia încearcă să facă vreo analogie cu
tabelele din Excel, înseamnă că au mari lacune în înţelegerea bazelor de
date.
Deoarece elementele teoretice ale bazelor de date au fost tratate în

capitolele precedente, în mediul ACCESS vom pune accent numai pe
aplicarea în practică a acestor cunoştinţe. Conceptele teoretice vor fi
amintite ca nişte lucruri cunoscute. Veţi observa că ACCESS tratează
anumite concepte într-o manieră proprie, chiar abuzează de anumite
ajutoare (wizard), care de multe ori derutează utilizatorii, împiedicându-i să
abordeze logic anumite operaţii.
Principalele caracteristici ale sistemului de gestiune a bazelor de date

ACCESS sunt:
 Lucrează sub sistemul de operare Windows;
 Este deschis comunicării cu alte sisteme de gestiune a bazelor de
date cum ar fi FoxPro sau Paradox;
 Este compatibil cu tehnologia ActiveX care permite realizarea
aplicaţiilor client/server;
 Permite aplicarea unor aplicaţii complexe prin utilizarea
limbajului Visual Basic;
 Permite comunicarea cu SQL Server, un alt produs Microsoft
care gestionează baze de date;
 Permite accesul la baze de date din reţeaua Internet, fiind un
instrument util pentru publicarea informaţiilor în paginile Web;
 Conţine instrumente wizard care permit utilizatorului crearea
facilă a unor obiecte componente ale bazei de date (tabele,
formulare, interogări, rapoarte).
 Oferă posibilitatea creării unei cópii a bazei de date;
 Permite utilizarea instrumentului wizard pentru crearea a peste 20
de tipuri comune de aplicaţii;
169
 Permite utilizarea obiectelor ACCESS în alte aplicaţii rulate sub
Windows.
 Permite utilizarea de adrese şi legături Internet.
Interfaţa programului ACCESS

Pentru a lucra cu orice aplicaţie informatică, primul lucru pe care trebuie
să-l facem este să-i cunoaştem interfaţa de pornire. Pentru ACCESS
interfaţa de pornire apare după lansarea acestuia cu metoda generală Start /
Programs / Microsoft Access. Veţi găsi repede programul observând că
iconiţa sa conţine mică cheie de yală. Toate capturile şi descrierile se referă
la versiunea Access 2002. Dacă aveţi altă versiune trebuie să ţineţi cont de
diferenţele care ar putea apare, care nu sunt, oricum, esenţiale.
Spre deosebire de alte programe Microsoft, programul ACCESS începe cu

o casetă de dialog în care vi se cere numele şi să alegeţi directorul bazei de
date pe care doriţi să o deschideţi, chiar dacă este una nouă (Blank
Database). După ce aţi dat numele bazei de date noi, numită aici „db1”, va
apare interfaţa din figura 5.1.
Fig. 5.1. Interfaţa de pornire Access (fereastra Database)
După cum se vede, o bază de date ACCESS poate fi definită ca o colecţie

de obiecte:
 Tabele (tables)
 Cereri de interogare (queries)
170
 Formulare (forms)
 Rapoarte (reports)
 Pagini Web (pages)
 Comenzi macro (macros)
 Module (modules)
În continuare vor fi prezentate, pe scurt, aceste obiecte, urmând să fie

reluate atunci când le vom folosi efectiv.
Tabele (tables) sunt obiecte definite de utilizator în care sunt stocate

datele. Sunt obişnuitele tabele ale bazelor de date.
Formulare (forms) sunt obiecte care permit introducerea datelor, afişarea

acestora sau controlul întregii aplicaţii. Acestea vă permit să faceţi aplicaţii
performante chiar dacă sunteţi un începător în baze de date.
Cereri de interogare (queries) sunt obiecte care permit vizualizarea

informaţiilor obţinute prin prelucrarea datelor din una sau mai multe tabele
şi/sau alte cereri de interogare. Aici veţi folosi din plin cunoştinţele
dobândite despre limbajul SQL.
Rapoarte (reports) sunt obiecte care permit formatarea şi tipărirea

informaţiilor obţinute în urma consultării bazei de date, sub formă de
documente pe hârtie.
Pagini Web (pages) reprezintă un obiect care include un fişier HTML şi

alte fişiere suport în vederea furnizării accesului la date prin intermediul
Internet-ului.
Comenzi macro (macros) reprezintă un obiect care conţine o definiţie

structurată a uneia sau mai multor acţiuni pe care ACCESS le realizează ca
un răspuns la un anumit eveniment.
Module (modules) reprezintă un obiect care conţine proceduri definite de

utilizator, scrise în limbajul Visual Basic. Iată o ocazie de a vă etala
cunoştinţele de Visual Basic.
Pe lângă obiectele prezentate, pe interfaţa de pornire, mai există câteva

butoane (Open, Design, New, un buton de ştergere şi câteva de afişare a
171
obiectelor) a căror înţelegere şi rol este uşor de dedus, de aceea nu vor mai
fi prezentate.
După cum spuneam, ACCESS-ul are un instrument numit wizard care vă

va ajuta să construiţi mai uşor tabele, formulare sau interogări, dar un
singur lucru nu poate face: să vă suplinească lipsa cunoştinţelor dobândite
în capitolele precedente. Astfel, dacă nu aţi înţeles mecanismul legăturilor
dintre tabele, e puţin probabil că veţi ajunge la rezultate mulţumitoare,
chiar dacă sunteţi „monitorizaţi” îndeaproape de instrumentul wizard.
Crearea tabelelor
Înainte de a începe să creaţi tabele, este de la sine înţeles că aveţi deja un
proiect de bază de date, sau dacă sunteţi la început de studiu, măcar o
diagramă de relaţii şi structurile tabelelor. Spuneam la începutul acestui
curs, cât de important e să aveţi un proiect corect de bază de date, pentru a
nu avea probleme la faza de implementare.
Crearea structurii tabelelor se poate face în trei moduri:

 Utilizând fereastra de proiectare (Create table in design view);
 Utilizând instrumentul Wizard (Create table by using wizard);
 Prin introducerea datelor (Create table by entering data).
Consider că modul cel mai eficient de creare a tabelelor, care se potriveşte

utilizatorilor români, îl reprezintă primul mod (Create table in design
view), motiv pentru care va fi prezentat numai acesta. Pentru a vă satisface
curiozitatea nu aveţi decât să le încercaţi pe celelalte două, pentru a ajunge
la o concluzie.
Revenind la primul mod de creare a unui tabel, daţi un dublu clic pe Create
table in design view şi pe ecran va apare fereastra Table din figura 5.2.
Fig. 5.2. Fereastra Table
172
Înţelegerea acestei ferestre nu e grea: sunteţi invitaţi să daţi numele

câmpurilor (Field Name), să alegeţi din combobox tipul de dată pentru
câmpul respectiv (Data Type) şi să introduceţi o scurtă descriere, acolo
unde este cazul, despre ce va conţine acel câmp (Description). Pentru
alegerea tipului de dată, revedeţi paragraful Anatomia unei specificaţii de
câmp din capitolul 3.
În toolbar-ul de sub meniul din figura 5.2, există mai multe butoane, unele
cunoscute din alte aplicaţii Windows. Există un buton (cel cu o cheiţă) pe
care nu l-aţi mai întâlnit până acum. Acest buton vă ajută să stabiliţi cheia
principală a tabelului pentru câmpul curent (cel cu săgeata din stânga),
printr-un simplu clic pe el.
În funcţie de tipul de dată ales pentru câmp, în partea de jos apare un

subtabel în care puteţi seta proprietăţile câmpului curent. Aceste proprietăţi
sunt adaptate tipului de dată: număr, text, data calendaristică etc. Să luăm
pe rând aceste proprietăţi, având ca reper tipul de dată numeric:
Field Size este dimensiunea câmpului. Executarea unui clic pe săgeata

derulantă va deschide o listă de opţiuni privind dimensiunea câmpului.
Format este formatul sub care se prezintă valoarea introdusă în câmp.

Executarea unui clic pe săgeata derulantă va deschide o listă de opţiuni
privind formatul câmpului.
Decimal Places este proprietatea care stabileşte numărul de zecimale ce

pot fi atribuite câmpului. Se poate alege un număr între 0 şi 15, sau Auto
pentru determinarea automată a numărului de zecimale.
Input Mask reprezintă impunerea unui format de introducere pentru toate

datele acelui câmp. Formatul de introducere are o mare importanţă în
cadrul câmpurilor ce conţin date de tip text sau dată calendaristică.
Caption este eticheta pentru specificarea unui nume atribuit câmpului, în

cazul în care acesta este utilizat în cadrul formularelor sau când tabelul
respectiv este afişat.
Default Value este o valoare care este atribuită automat, în momentul când
utilizatorul nu introduce nici o valoare în acel câmp.
173
Validation Rule este criteriul care va fi verificat înainte de validarea
valorii introduse în acel câmp. Criteriul este introdus sub formă de expresii
care folosesc:
 Operatorii: =, +, -, *, /, <, >, <=, >=, AND, OR, BETWEEN, IN,
IS NULL;
 Identificatorii se dau în paranteze drepte [];
 Funcţii;
 Constante;
Validation Text reprezintă textul care va apărea pe bara de mesaje în cazul

în care valoarea introdusă nu respectă criteriul impus de regula de validare.
Required este proprietatea care stabileşte dacă introducerea unei valori în

acel câmp este obligatorie. Acest câmp poate avea una din valorile Yes /
No.
Indexed este proprietatea care stabileşte dacă acel câmp are un index care
acceptă valori duplicat sau numai valori unice. Dacă nu dorim un index
pentru acel câmp se alege valoare No.
Proprietăţile descrise mai sus se refereau la tipul de câmp Numeric. Pentru

alte tipuri de câmp vor apare şi proprietăţi noi (cele mai multe rămân).
Astfel, datele de tip Text şi Memo au o proprietate numită Allow Zero
Length, adică admiterea lungimii zero. Această proprietate are valoarea Yes
sau No.
O proprietate importantă pentru câmpul care conţine date de tip

Autonumber este New Values. Opţiunile Increment sau Random permit
stabilirea modului în care câmpului respectiv i se vor acorda valori automat
de către sistem.
Relaţii între tabele
Relaţiile dintre tabele sunt lucruri cunoscute, deja, de către oricare dintre
dumneavoastră, nu-i aşa? Să vedem acum ce modalitate foloseşte
ACCESS-ul pentru a face legătura între tabele. Din punct de vedere al
momentului creării acestora, există 2 tipuri de relaţii între tabelele unei
baze de date ACCESS şi anume:
 Relaţii permanente – se stabilesc după definirea tabelelor şi sunt
cerute de modelul relaţional făcând parte din structura bazei de
174
date. Aceasta se realizează, de obicei, prin corespondenţa cheie
primară – cheie externă şi sunt memorate în baza de date.
 Relaţii temporare – se stabilesc între tabele cu ocazia definirii
unor cereri de interogare, nefiind înregistrate în structura bazei de
date.
După cum ştim, între două tabele între care există o relaţie, datele nu pot fi
introduse oricum. De exemplu, dacă într-o bază de date avem tabelele
tblFacturiPrimite şi tblFurnizori între care există o relaţie „unu cu mai
mulţi”, nu putem introduce date în tabelul tblFacturiPrimite până nu avem
cel puţin un furnizor în tabelul tblFurnizori. Cum rezolvă ACCESS-ul
această prevedere din proiectul bazei de date (tipul de participare)? Prin
impunerea integrităţii referenţiale (Enforce Referential Integrity), după
cum se vede în figura 5.3.
Fig. 5.3. Stabilirea

integrităţii
referenţiale
Cele 2 opţiuni din partea de jos, Cascade Update Related Fields şi

Cascade Delete Related Fields, se referă la actualizarea respectiv ştergerea
tuturor câmpurilor legate prin această relaţie.
În urma acestei setări, s-a făcut o legătură unu cu mai mulţi între cele două
tabele, a cărei reprezentare se vede în figura 5.4.
Fig. 5.4. Diagrama de relaţie

între cele 2 tabele, aşa cum
apare în ACCESS.
175
Stabilirea legăturilor între tabele se face, fie în faza de creare a tabelului
(folosind Lookup Wizard), fie în fereastra Relationship care se afişează cu
butonul , din toolbar-ul din fereastra Database. Printr-un clic pe acest
buton se deschide tabela Relationship prezentată în figura 5.5.
Dacă nu apar toate tabelele în fereastra Relationship, cu un clic-dreapta în

interiorul acesteia apoi alegând opţiunea Show Table va fi afişată fereastra
Show Table, cu care se pot adăuga şi celelalte tabele.
Legătura dintre tabele se face „trăgând cu mouse-ul” câmpul de legătură

dintr-un tabel „peste” câmpul corespunzător din celălalt tabel. După ce s-a
făcut legătura, putem face un clic-dreapta pe legătură, apar 2 posibilitaţi:
Edit Relationship... şi se deschide caseta de dialog pentru stabilirea
integrităţii referenţiale arătată în figura 5.3, respectiv Delete cu care putem
şterge legătura. Când citiţi această secvenţă, este bine să o faceţi cu
calculatorul în faţă, deoarece altfel, aceste manevre sunt greu de înţeles.
Dacă ceva nu aţi înţeles, întrebaţi profesorul care vă îndrumă la laborator.
Fig. 5.5. Tabela Relationship
176
Tabelele nu sunt de la început aşa frumos aranjate. O să vedeţi cum veţi
găsi aceste tabele, dar prin „tragere” cu mouse-ul se pot aranja ca să fie mai
uşor de urmărit. Încercaţi aceste manevre pentru a vă obişnui cu ele.
Crearea relaţiilor cu Lookup Wizard...
Cea mai comodă cale de a crea relaţii permanente între două tabele este
folosirea facilităţii Lookup Wizard, pusă la dispoziţia noastră de programul
ACCESS. Această metodă constă în „legarea” tabelelor în faza de
proiectare prin intermediul unei chei primare şi a unei chei externe. Prima
dată de proiectează tabelul din partea „unu” a relaţiei unu cu mai mulţi. La
cel de-al doilea tabel, când se defineşte câmpul de legătură, pentru tipul de
dată (Data Type) se alege opţiunea Lookup Wizard... (ultima dintre
opţiuni). În urma acestei manevre se deschide caseta de dialog din figura
5.6.
Fig. 5.6. Primul pas al

procedurii Lookup Wizard
Se alege prima opţiune, cea care ne spune că vom lega câmpul nostru cu un
alt câmp dintr-un tabel sau o interogare, I want the lookup.... Merită
explicată şi opţiunea a doua I will type in the values that I want, care ne
spune că putem lega acest câmp cu o listă de valori introduse de noi chiar
în această fază. Această opţiune este indicat să o folosiţi când aveţi un
număr mic de valori pe care poate să le ia un anumit câmp. Încercaţi şi
această variantă pentru a-i înţelege rolul.
Cu butonul Next se avansează în pasul următor când vi se cere să alegeţi,

dintr-o listă, tabelul cu care va fi legat. După alegerea tabelului, veţi alege
cheia primară şi un alt câmp pentru a identifica înregistrarea (acest lucru îl
veţi înţelege când veţi introduce, efectiv, date în tabel). Această manevră se
vede în figura 5.7.
177
Fig. 5.7. Alegerea

câmpului de legătură
În cazul nostru se vor selecta câmpurile TaraID şi Denumire, care vor fi

trecute în fereastra din dreapta. Cu butonul Next se va trece la pasul
următor (figura 5.8) care ne recomandă să face invizibilă coloana cu cheia
primară, pentru că la operare nu ne va ajuta cu nimic, fiind un cod numeric
fără semnificaţie pentru noi.
Fig. 5.8. Recomandarea

pentru a face invizibilă
cheia primară
Cu butonul Next se trece la pasul următor care vă cere să stabiliţi numele

câmpului care va apare în rapoarte, de regulă se lasă cel implicit, propus de
calculator. După această manevră se alege butonul Finish care ne va
avertiza că o relaţie a fost creată şi că ar trebui salvată. Dacă nu s-a greşit
nimic, se apasă butonul Next.
Fig. 5.9. Avertizarea de

salvare a relaţiei create.
178
Pentru a verifica relaţia creată se apasă butonul , care va deschide foaia

Relationships. Cu un clic-dreapta pe linia relaţiei o puteţi edita sau şterge.
Încercaţi această manevră pentru a înţelege ce se întâmplă.
Diferenţa între cele două tipuri de legături permanente, legarea prin metoda
”tragerii” (drag and drop) în fereastra Relationship şi legarea prin metoda
Lookup Wizard..., nu prea iese în evidenţă decât la crearea formularelor de
introducere a datelor. La prima metodă Access-ul va pune automat o casetă
de text (textBox) în care trebuie să introducem manual valori de la
tastatură, iar la a doua metodă va apare în formular o casetă combinată
(comboBox), din care putem alege elegant valoarea din lista afişată.
Dacă aţi reuşit să înţelegeţi aceste diferenţe, înseamnă că aţi făcut un pas
important spre a putea crea aplicaţii Access tot mai performante. Poate în
acest moment nu sesizaţi diferenţele dintre cele două metode, dar cu
siguranţă, le veţi înţelege atunci când veţi crea formulare, puţin mai târziu.
Introducerea datelor în tabele
După ce s-au definit tabelele, s-au creat legăturile între ele, urmează, firesc,
completarea acestora cu date. Cea mai simplă metodă este să faceţi un
dublu-clic pe numele tabelului, ceea ce face să se deschidă tabelul, care
seamănă mult cu un tabele Excel, şi să introduceţi pur şi simplu date.
Adesea, anumite înregistrări din tabel prezintă un interes deosebit, de aceea

acestea trebuie filtrate temporar, adică trebuie făcute invizibile celelalte.
Un filtru poate fi aplicat unui tabel, unei cereri de interogare, unui formular
sau unui raport. Filtrul este salvat împreună cu fiecare obiect şi poate fi
activat sau nu, după nevoie.
Un filtru este util pentru realizarea următoarelor operaţii:

 Selectarea unui număr de înregistrări similare;
 Lucrul cu un subset de înregistrări;
 Vizualizarea datelor într-o anumită ordine;
 Localizarea unei înregistrări folosind doar informaţiile cunoscute.
179
În momentul în care un tabel sau un formular este vizualizat, în cadrul
barei de meniuri va apare opţiune Records care permite operaţiile de
filtrare. Există mai multe opţiuni de filtrare, dar cele mai folosite sunt
următoarele două:
 Filtrarea by Selection – filtrare conform selecţiei, este cea mai
rapidă şi mai simplă metodă de aplicare a unui filtru. Pentru a
stabili criteriul de filtrare, se selectează un set de date dintr-unul
din câmpurile unui tabel, după care se apasă butonul ,
rezultând tabelul filtrat. Pentru revenire se apasă butonul
(Remove Filter). Cu această metodă se pot filtra înregistrările
numai pe baza unui criteriu aplicat unui singur câmp al tabelului.
 Filter by Form – filtrare conform formularului, este metoda în
care criteriul de filtrare se introduce într-un tabel gol. Pentru a
aplica această metodă apăsaţi butonul , care va deschide
tabelul fără nici o înregistrare. Nu aveţi decât să alegeţi valorile
dorite din câmpurile vizate, rezultând un criteriu de filtrare oricât
de complex, poate (atenţie) aşa de complex că nu vă afişează
nimic, având în vedere că toate condiţiile trebuie îndeplinite în
acelaşi timp. Pentru revenire se apasă butonul (Remove
Filter).
Salvarea tabelelor se face la ieşirea din modul de proiectare, când sunteţi

întrebat ce nume va avea noul tabel, sau în orice moment al procesului de
proiectare a tabelului, dând comanda Save, sau apăsând cunoscutul buton
de salvare a documentelor Windows.
Puteţi schimba numele unui tabel făcând un clic dreapta pe numele său. De
asemenea, puteţi face oricâte cópii ale unui tabel pentru diferite acţiuni,
mai ales când încercaţi expresii SQL, având în vedere că după ce aţi
executat o operaţie SQL nu mai puteţi reveni la starea iniţială a tabelului.
În aplicaţii, introducerea datelor se face elegant folosind formularele

specializate, cu tot felul de facilităţi, aşa cum se va vedea mai departe în
cadrul acestui curs.
180
Formulare
Formularele sunt obiecte de comunicaţie între un utilizator şi o aplicaţie de
baze de date ACCESS. Ele permit atât introducerea, cât şi vizualizarea
datelor într-o manieră cât mai atractivă.
Într-o aplicaţie formularele îndeplinesc următoarele roluri:

 Afişarea şi editarea datelor. Este rolul cel mai des folosit al unui
formular, prin care se pot afişa şi modifica date dintr-o bază de
date.
 Controlul operaţiilor realizate de o aplicaţie. Se pot proiecta
formulare de aplicaţie care să conţină interfeţe de interacţiune cu
utilizatorul, folosind proceduri Visual Basic sau macro-uri.
 Introducere de date. Introducerea datelor cu formulare clare, pe
înţelesul operatorului este una din premisele unei aplicaţii de
succes.
 Tipărirea informaţiilor. Chiar dacă mai rar, formularele pot fi
folosite pentru tipărirea de informaţii la imprimantă.
În general, un formular este compus din 3 părţi: antetul, zona de detaliu şi

subsolul. În zona de detaliu sunt prezentate, de fapt, datele. În antet şi
subsol sunt prezentate acele informaţii statice care nu se schimbă pe
măsură ce edităm alte înregistrări.
Reţineţi faptul că, în spatele fiecărui formular există un tabel sau o

interogare. Excepţie fac formularele folosite ca interfaţă a unei aplicaţii.
Majoritatea formularelor cu care lucrăm noi, în cadrul acestui curs, fac
parte din prima categorie, adică cele care au ataşate un tabel sau o
interogare.
Crearea unui formular
Un formular se poate crea prin mai multe moduri, dar cele mai utilizate
sunt cele pe care o să le folosim şi noi:
 Creare automată – prin utilizarea instrumentului wizard;
 Creare manuală – cu ajutorul ferestrei de proiectare.
181
În continuare vor fi prezentate pe larg cele două metode de creare a
formularelor.
Crearea automată a unui formular
Această metodă este cea mai facilă, practic, calculatorul face tot, noi
trebuie să alegem numai anumite opţiuni care sunt foarte sugestive şi clare.
Pentru a crea formularul, în fereastra Database se apasă, în ordine,
butoanele Forms (din stânga) şi New (de sus).
În figura 5.10 se poate vedea fereastra Database.
Fig. 5.10. Fereastra Database
În urma acestei acţiuni va apare fereastra New Form, aşa cum se vede în
figura 5.11.
Fig. 5.11. Fereastra

NewForm
Din acest comboBox se alege

tabelul asociat formularului
182
Din această fereastră alegem opţiunea Form Wizard şi alegem tabelul
tblGrupe din caseta comboBox, apoi apăsăm butonul OK.
În urma acestei manevre va apare fereastra din figura 5.12, cu ajutorul

căreia putem alege câmpurile care vor face parte din formular.
Fig. 5.12. Alegerea

câmpurilor formularului
În fereastra următoare putem selecta modul cum vor apare datele în cadrul
formularului, aşa cum se vede în figura 5.13.
Fig. 5.13. Alegerea

formei de prezentare
Puteţi încerca mai multe opţiuni pentru a vedea diferenţele dintre ele. După
ce v-aţi decis asupra unei opţiuni şi aţi apăsat butonul Next, va apare
fereastra cu ajutorul căreia puteţi alege fundalul formularului, după cum se
183
Fig. 5.14. Alegerea

fundalului formularului
După ce v-aţi decis asupra unui fundal şi aţi apăsat butonul Next, va apare
ultima fereastră a acestui scenariu, în care puteţi alege numele noului
formular pe care tocmai l-aţi creat.
Acest pas se poate vedea în figura 5.15.
Fig. 5.15. Alegerea

numelui formularului şi
încheierea operaţiunii
Pe această fereastră există 2 butoane de opţiune, primul ne spune că la

ieşirea din el, formularul va fi automat deschis, iar al doilea ne spune că
forma va fi deschisă în modul Design în care putem să facem modificări
ale acesteia. Încercaţi ambele opţiuni pentru a vedea efectul.
După apăsarea butonului Finish va apare afişat formularul pe care tocmai

l-am construit, aşa cum se vede în figura 5.16.
Fig. 5.16. Forma finală a

formularului
184
Deşi crearea automată a formularului este mai rapidă şi mai uşoară,
adevăraţii profesionişti o folosesc mai rar, deoarece este mai rigidă şi îşi
cam impune punctul de vedere. Formularele cu adevărat profesionale se fac
manual, aşa cum se va vedea în continuare.
Crearea manuală a unui formular
Cu această metodă se pot crea formulare pornind de la zero. Chiar dacă la

început această metodă poate părea dificilă, este o cale de a construi
formulare adaptate nevoilor utilizatorilor, atât din punct de vedere
funcţional cât şi al design-ului.
Abilitatea de a concepe formulare utile şi atractive se obţine numai prin

experienţă, de aceea nu trebuie să vă faceţi probleme dacă primele voastre
formulare sunt criticate de utilizatorii lor. Reţineţi aceste critici pentru a
modifica formularele sau pentru a le folosi în viitoarele formulare pe care
le veţi proiecta. De altfel, cei care veţi ajunge proiectanţi de baze de date
veţi avea propriile voastre şabloane, obţinute în urma experienţei
acumulate.
Cel mai simplu mod de a înţelege cum se crează un formular plecând de la

zero, fără nici un ajutor, este să prezentăm un exemplu. Ne propunem
construim acelaşi formular plecând de la zero. Vom executa paşii următori:
1. Din interfaţa Database selectăm Forms din bara de obiecte.
2. Din fereastra care se deschide alegem New – Design view.
3. Se va deschide fereastra din figura 5.17, care arată forma în faza

iniţială.
Se observă apariţia Toolbox-ului cu obiecte care se pot pune pe interfaţă,

care seamănă cu cel din Visual Basic.
185
Bara de titlu
Toolbox – caseta
cu obiecte
Fig. 5.17. Forma iniţială a

formularului
Caseta Toolbox poate fi mutată cu mouse-ul oriunde pe suprafaţa formei ca

să nu ne încurce vizibilitatea.Secţiunile formularului se văd în figura 5.17.
Acestea sunt:
Form Header şi Form Footer sunt antetul şi subsolul formularului în care

se afişează informaţii precum titlurile. Dacă se tipăreşte formularul,
informaţiile din antet şi subsol apar o singură dată, pe prima pagină. Nu
ezitaţi să plasaţi în antet sau subsol oricare din butoanele asociate unor
operaţii.
Page Header şi Page Footer sunt antetul şi subsolul paginilor, şi sunt

similare cu cele ataşate direct la formular, cu principala diferenţă că
secţiunile de pagină se tipăresc pe fiecare pagină, iar cele de formular
numai pe prima. Secţiunile de antet şi subsol de pagină nu apar la
vizualizareaformularului, dar sunt folosite de Access la tipărirea acestuia.
Detail este secţiunea de bază a fiecărui formular care nu poate lipsi, spre
deosebire de celelalte care pot lipsi. Aici sunt afişate, practic, informaţiile
pentru care a fost conceput formularul.
186
În exemplul nostru, mergem mai departe şi populăm formularul cu
obiectele potrivite, etichete, casete de text, butoane de navigare etc. Mai
întâi scăpăm de secţiunile de antet şi subsol ale formularului şi paginilor
dând comanda View şi deselectând opţiunile Page Hedear/Footer şi Form
Hedear/Footer.
Construim apoi obiectele de pe interfaţă, aşa cum făceam în Visual Basic.

Nu uitaţi să afişaţi instrumentele folosite, cu ajutorul butonului Toolbox (
). Rezultatul este prezentat în figura 5.18.
Proprietatea Record Source stabileşte

tabelul asociat formularului
Fig. 5.18. Formularul, aşa

cum arată în modul Design
Proprietatea Control Source face asocierea între
cele 3 casete de text şi câmpurile tabelului
asociat formularului
Observaţi cum se face legătura fiecărui câmp cu obiectul corespunzător.

Trebuie numai să selectăm fiecare obiect şi la proprietatea Control Source
să alegem câmpul corespunzător. Pentru întregul formular trebuie să
alegem tabelul asociat, în cazul prezentat acesta este tblGrupee.
187
După ce activăm formularul cu butonul , acesta va arăta ca în figura

următoare, 5.19.
Fig. 5.19. Formular obţinut

de la zero
Se observă că acest formular este mai arătos, are un titlu pus şi are
introdusă şi data la care se foloseşte – Data curenta:, în care s-a folosit
funcţia Now() ataşată de caseta de text respectivă, care-l face mai util.
Exemplul prezentat nu este unul spectaculos, dar este un bun început care
vă poate folosi ca model.
După modelul prezentat, încercaţi să creaţi un formular după un tabel pe

care l-aţi conceput singuri.
Observaţie importantă! În practică se foloseşte o tehnică mixtă, adică se

porneşte cu metoda wizard, după care se intervine manual pentru a o
modifica, ştergând unele controale inutile şi adăugând alte obiecte.
188
Formulare cu subformulare
Un formular ca cel prezentat în paragraful anterior este unul banal, bun

pentru a înţelege cam cum se pune problema. Cu siguranţă, nu vă veţi opri
la acest stadiu şi veţi dori să faceţi formulare cu adevărat utile, mai ales că
aplicaţiile cu baze de date este un domeniu tot mai căutat, nu-i aşa?
Este puţin probabil că veţi crea formulare profesionale fără să folosiţi şi

nişte subformulare.
Un subformular, nu este altceva decât un formular inclus în alt formular,

pentru a permite afişarea informaţiilor din mai multe tabele sau cereri de
interogare, aflate în relaţii 1:1 sau 1:N. Astfel, în formularul principal vor fi
afişate datele din partea unu a relaţiei, iar în subformular cele din partea
mai mulţi. Prin urmare, la un moment dat în formular va fi afişată o
înregistrare din partea unu a relaţiei, iar în subformular înregistrările
corespondente din partea mai mulţi a relaţiei.
Un formular poate conţine chiar mai multe subformulare. Pentru a crea un

formular cu subformulare incluse se poate proceda în 3 moduri:
 Crearea formularului şi subformularului concomitent;
 Crearea subformularului şi adăugarea lui la un formular existent;
 Crearea separată a celor două formulare şi apoi combinarea lor.
Dintre acestea, ultima variantă este cea mai simplă, aşa că pe aceasta o
vom folosi şi noi. În acest sens se parcurg următoarele etape:
 Se creează formularul principal şi se salvează;
 Se creează subformularul, la fel ca şi formularul principal;
 Se face legătura între formularul principal şi subformular;
 Se testează rezultatul.
Pentru a înţelege mecanismul creării unui formular care conţine un alt

formular inclus, vom lua un exemplu concret. Presupunem că avem o
porţiune dintr-o bază de date care conţine 4 tabele:
- tblFacturi
- tblDetaliiFacturi
- tblProduse
- tblFurnizori
189
Toată lumea ştie ce este o factură, mai ales comercianţii, toate fiind stocate
în tabelul tblFacturi. Fiecare factură are mai multe poziţii, corespunzătoare
mărfurilor care se facturează, dacă ne gândim la o factură din comerţ.
Aceste mărfuri facturate sunt cuprinse în tabelul tblDetaliiFacturi. Pot fi
facturate numai produsele cuprinse în tabelul tblProduse. Fiecare factură
provine de la un singur furnizor, aceştia fiind cuprinşi în tabelul
tblFurnizori.
Între aceste tabele există legături, aşa cum am învăţat în capitolul 3, la

proiectarea bazelor de date. În figura 5.20 este arătată structura acestei
porţiuni a bazei de date.
tblFacturi tblDetaliiFacturi
FacturaID ChP FacturaID ChE tblProduse
NrFactura ProdusID ChE ProdusID ChP
Data Cantitate Denumire
FurnizorID ChE Observatii UM
Pret
..............
tblFurnizori
FurnizorID ChP
Furnizor
CodFiscal
...........
Fig. 5.20. Tabelele implicate în formular
Ne propunem să construim un formular cu ajutorul căruia să putem vedea

toate facturile primite de la furnizori, precum şi detaliile fiecăreia, adică
produsele facturate. Observăm că facturile se află în tabelul tblFacturi,
care este în relaţie 1:N cu tabelul tblDetaliiFacturi. De asemenea,
observăm că cele 2 tabele conţin câte un câmp care reprezintă coduri
(FurnizorID, ProdusID) ceea ce nu ne încântă când le vedem afişate în
locul unei denumiri clare, înţelese de oricine.
După cum ştim, în spatele fiecărui formular se găseşte un tabel sau o

interogare, iar faptul că cele 2 tabele implicate conţin coduri numerice care
nu au nici o semnificaţie pentru utilizatorul obişnuit, ne face să ne gândim
190
la o interogare. Noi ştim deja să facem interogări cu limbajul SQL, învăţat
în capitolul precedent, nu-i aşa?
Prin urmare, vom scrie 2 interogări SQL, una pentru formularul principal
(cel cu facturile) şi alta pentru subformular (cel cu detaliile facturilor). Iată
cele 2 interogări:
Interogarea 1. Formularul principal:

SELECT tblFacturi.FacturaID, tblFacturi.NrFactura, tblFacturi.Data, tblFurnizori.Furnizor
FROM tblFacturi INNER JOIN tblFurnizori ON
tblFacturi.FurnizorID=tblFurnizori.FurnizorID;
Interogarea 2. Subformular:
SELECT FacturaID, Denumire, UM, Cantitate, Pret, Cantitate*Pret AS Valoare
FROM tblDetaliiFacturi AS df INNER JOIN tblProduse AS pr ON df.ProdusID=pr.ProdusID;
Observaţi în aceste expresii SQL cum se face legătura între 2 tabele

folosind clauza INNER JOIN ... ON, precum şi expresia AS cu care
stabilim alias-uri pentru numele prea lungi ale tabelelor. Observaţi, de
asemenea, cum s-a creat câmpul calculat Valoare care este produsul dintre
cantitate şi preţ.
Pentru a scrie interogările, tabelele bazei de date trebuie să fie completate

cu date pentru a putea vedea rezultatele. Fereastra Database trebuie să
arate ca în figura 5.21.
Fig. 5.21. Tabelele

bazei de date
Pentru a crea cele două interogări trebuie să ajungem în fereastra în care

putem scrie expresiile SQL. Pentru aceasta trebuie să parcurgem paşii:
191
 Apăsăm butonul Queries, apoi dublu-click pe opţiunea Create
query in Design view.
 Se deschide fereastra cu cele 4 tabele.
 Apăsăm butonul Close.
 În partea stângă-sus apare butonul , a cărui apăsare

deschide fereastra în care se scriu pe rând cele 2 expresii SQL,
adică Interogarea 1 şi Interogarea 2.
 Pentru a verifica interogările se apasă butonul Run din

toolbar-ul superior.
 Interogările vor primi numele următoare: Interogarea 1 –
qryFacturi, iar Interogarea 2 – qryDetaliiFacturi.
Dacă totul a decurs bine, trebuie să obţineţi ca rezultat al interogărilor

tabelele din figura 5.22-1, cu observaţia că datele vor fi, probabil, altele.
Interogarea 1
Interogarea 2
Fig. 5.22-1. Cele 2 interogări rezultate
În acest moment putem crea 2 formulare care să aibă în spate aceste

interogări. Este evident că pentru formularul principal folosim interogarea
qryFacturi, iar pentru subformular interogarea qryDetaliiFacturi.
Crearea celor 2 formulare se face după metoda prezentată în paragraful

precedent, cu observaţia că în loc de tabele alegem interogări pentru a le
ataşa acestora.
Prima dată se creează formularul frmDetaliiFacturi, după care se crează

formularul principal frmFacturi, în care se introduce obiectul
192
Subform/Subreport din Toolbox. Când se cere formularul de introdus,
alegeţi frmDetaliiFacturi.
Când se introduce subformularul, trebuie setate unele proprietăţi care spun

programului Access cum se leagă subformularul frmDetaliiFacturi de
formularul principal frmFacturi. Aceste proprietăţi sunt Source Object, Link
Child Fields şi Link Master Fields, adică numele subformularului şi cele două
câmpuri de legatură. Valorile setate pentru aceste proprietăţi se pot vedea
în figura 5.22-2. Câmpul de legătură, corespunzător fiecărui formular este
FacturaID.
Fig. 5.22-2. Setarea

proprietăţilor pentru
subformular
La setarea proprietăţilor amintite, cele 2 formulare implicate trebuie sa

arate ca în figura 5.23.
Câteva precizări:
 La subformularul frmDetaliiFacturi se va alege modul de
prezentare Datasheet, adică sub formă de tabel.
 Pentru a elimina butoanele de navigare din subformular,
proprietatea Navigation Buttons se va seta la valoarea No.
193
frmFacturi
frmDetaliiFacturi
Fig. 5.23. Formularul cu

subformular, în modul Design
Când se activează formularul, adică se scoate din modul Design, acesta va

arăta ca în figura 5.24.
Butoane de navigare
Fig. 5.24.
Formularul nostru
în stare de
funcţionare
Cu ajutorul butoanelor de navigare, navigăm printre facturi. La o anumită

factură va fi afişată data emiterii şi furnizorul, precum şi detaliile facturii
respective, cu ajutorul subformularului.
Încercaţi să construiţi şi alte formulare după procedura prezentată, pentru a

câştiga experienţă.
194
Interogări
Fără îndoială, interogările sunt acţiunile cele mai numeroase acţiuni pe care
o să le faceţi asupra unei baze de date. Prin interogări nu facem altceva
decât să extragem informaţii dintr-o bază de date, motivul pentru care
acestea au fost create, nu-i aşa?
Interogările care se definesc încă din faza de proiectare a bazei de date se

mai numesc şi vederi, aşa cum am văzut în capitolul 2 la definirea
terminologiilor. Rezultatul unei interogări este un tabel virtual, adică unul
care nu există în baza de date, dar care se generează ori de câte ori este
nevoie. Prin aceasta deducem că o interogare se va actualiza de fiecare
dată, dacă tabelele implicate au suferit modificări.
Interogările şi tabelele sunt singurele obiecte ale bazei de date care se

asociază formularelor. Pentru afişarea informaţiilor extrase dintr-o bază de
date se parcurge, în general traseul Interogare – Formular.
După cum am învăţat în capitolul 4, pentru extragerea informaţiilor dintr-o

bază de date se foloseşte limbajul SQL. Cunoştinţele dobândite acolo sunt
de un real folos în ceea ce vom face în continuare.
În Access există o mare problemă: generarea interogărilor se face cu

ajutorul unei aplicaţii grafice, care în faza de învăţare, cum este cazul
nostru, produce mai mult confuzii decât să clarifice lucrurile. Din acest
motiv, o să folosim limbajul SQL pentru crearea interogărilor, scriind
expresiile de la zero. O să vedem mai târziu că şi modulul grafic Wizard
generează expresii SQL, dar care nu sunt aşa de clare ca cele scrise de noi,
adică conţin şi lucruri inutile, ca orice activitate automată.
Crearea interogărilor folosind limbajul SQL
Când am învăţat limbajul SQL, am scris expresii pe care am încercat să le

înţelegem la nivel de concept, nu ne-am pus problema cum să le verificăm.
Acum avem ocazia să testăm expresiile SQL în interiorul programului
Access. De aceea este indicat să verificaţi expresiile din capitolul 4
folosind metoda explicată în continuare.
Pentru a scrie expresiile SQL trebuie să deschidem fereastra

corespunzătoare. Veţi proceda astfel:
195
 În fereastra Database se apasă butonul Queries apoi se dă dublu-
click pe opţiunea Create query in Design view .
 Se va deschide fereastra Show table unde se apasă butonul Close.
 În partea stângă a Toolbar-ului superior, va apare butonul ,

prin apăsarea căruia se deschide fereastra din figura 5.25.
Fig. 5.25. Fereastra

pentru scrierea
expresiilor SQL
Observaţi că în mod automat apare scrisă instrucţiunea „SELECT; ” care se

termină cu punct şi virgulă, care semnifică terminarea expresiei SQL. În
această fereastră se scriu de mână expresiile SQL. Nu uitaţi de simbolul „ ;
” punct şi virgulă de la sfârşitul expresiei.
Pentru verificarea expresiei SQL introduse folosiţi butonul Run SQL

localizat conform figurii 5.26.
Fig. 5. 26. Butonul Run SQL
Dacă totul a decurs bine, se va afişa un tabel cu datele generate de

interogare.
Ca exerciţiu, reluaţi toate exemplele din capitolul 4 şi verificaţi-le cu

ajutorul Access-ului. Este evident că mai întâi trebuie să introduceţi şi să
populaţi tabelele prezentate acolo.
Crearea interogărilor cu aplicaţia Wizard(Design view)
A crea o interogare cu vrăjitorul(aplicaţia Wizard) este foarte simplu şi

rapid. Singura mare problemă este că începătorii nu prea înţeleg ce fac,
196
pentru că prea îi conduce calculatorul. Este mult mai utilă atunci când aveţi
o oarecare experienţă şi v-aţi însuşit limbajul SQL.
În ce constă problema de fapt? Access-ul ne pune la dispoziţie nişte unelte

cu care putem construi interogări numai cu mouse-ul, „trăgând” tabele şi
câmpuri, punând condiţii, toate făcându-se la vedere într-o aşa-numită grilă
de proiectare a interogării. În final se obţine tot o expresie SQL, pe care o
generează calculatorul, în funcţie de manevrele făcute de noi.
Pentru a crea o interogare în modul Design view se procedează astfel:

 În fereastra Database se dă click pe Queries, apoi pe New. Se va
deschide fereastra din figura 5.27
Fig. 5.27. Pasul 1 de

creare a unei interogări
 Din caseta New Query se se alege opţiunea Design View – OK.

Se obţine caseta din figura 5.28.
Fig. 5.28. Grila de proiectare a interogărilor
197
 În caseta de dialog se dă dublu-click pe tabelul care dorim să fie
implicat în interogare, iar acesta va apare în zona de sus a
formularului. Dacă e nevoie de mai multe tabele, se repetă
acţiunea iar la sfârşit se închide caseta cu butonul Close.
 Grila de proiectare seamănă cu un tabel, a căror rânduri au
următoarele semnificaţii:
Field – aici se trag cu mouse-ul câmpurile interogării;
Table – aici va apare automat numele tabelului la care aparţine

câmpul;
Sort - aici se stabileşte ordinea de sortare, ascendent sau

descendent. Dacă nu se scrie nimic sortarea va fi
ascendentă;
Show - dacă este bifat, câmpul va fi vizibil, altfel nu;
Criteria - aici se stabilesc criteriile pe care trebuie să le

îndeplinească câmpul;
or - se foloseşte pentru criterii complexe.

 După ce sau ales tabelele, se fac legăturile între tabele, apoi se
trag câmpurile, pe linia Field. Legătura între câmpuri se face
trăgând cu mouse-ul un câmp dintr-un tabel şi suprapunându-l
peste câmpul corespunzător din celălalt tabel. Această legătură
este numai una temporară, folosită numai la interogarea
respectivă. O grilă completată se poate vedea în figura 5.29.
Fig. 5.29. Grilă completată
198
Se observă că primul câmp a fost folosit numai pentru sortare, el nefiind
vizibil în interogare. Pentru vizualizarea interogării se apasă butonul Run (
), iar rezultatul se vede în figura 5.30.
Fig. 5.30. Rezultatul interogării
Expresia SQL generată automat de Access este următoarea:
SELECT tblFacturi.NrFactura, tblFacturi.Data, tblFurnizori.Furnizor, tblFurnizori.CodFiscal

FROM tblFacturi INNER JOIN tblFurnizori ON tblFacturi.FurnizorID =
tblFurnizori.FurnizorID
WHERE (((tblFurnizori.Furnizor)="Promax"))
ORDER BY tblFacturi.FacturaID;
Prin urmare, toate manevrele făcute cu mouse-ul au avut ca rezultat această

expresie SQL care ar fi putut fi scrisă de la bun început manual. Rămâne la
alegerea voastră care metodă este mai bună şi mai instructivă.
Practica spune că metoda cea mai eficientă, din punct de vedere al însuşirii
cunoştinţelor, este varianta SQL pentru că ajută la înţelegerea deplină a
creării interogărilor şi a rolului fiecărei clauze. Deci nu ezitaţi să o folosiţi
chiar dacă vi se pare la început mai grea.
199
Legarea permanentă a două tabele
Încă din faza de proiectare a unei baze de date am văzut că între tabelele
sale există legături. Aceste legături se fac între două câmpuri fiecare
aparţinând unui tabel, aşa cum se vede din diagrama bazei de date. Ne
punem problema „traducerii” acestor legături arătate în diagrame, în cadrul
programului Access.
Am văzut că în limbajul SQL, legarea a două tabele se face prin clauza

INNER JOIN ... ON. Rolul legăturilor dintre tabele se vede în timpul
interogărilor. Cum se face legătura între 2 tabele?
Există 2 tipuri de legături pe care Access-ul le permite:

 Legături permanente, stabilite în faza de proiectare a tabelelor;
 Legături temporare, care se stabilesc în timpul creării
interogărilor.
Legăturile permanente se pot face, la rândul lor în 2 moduri: cu ajutorul

ferestrei Relationships (a), respectiv cu vrăjitorul Lookup Wizard (b).
a) Fereastra Relationships se deschide cu comanda Tools – Relationships.

Se va deschide fereastra care la început este goală, urmând ca noi să
tragem în ea tabelele şi să le legăm. În figura 5.31 este arătată o fereastră
Relationships, cu legături stabilite. Intuiţi că relaţia 1:N este aici
simbolizată prin caracterele 1 şi ∞.
Fig. 5.31. Fereastra Relationships
200
Din lista tabelelor, cu un dublu-click, acestea ajung în fereastra

Relationships, după care se face legătura între câmpuri prin operaţia drag
and drop, de la câmpul de legătură din tabelul sursă, la câmpul de legătură
din tabelul destinaţie. După ce s-a făcut legătura apare fereastra Edit
Relationships, care stabileşte şi integritatea datelor prin bifarea
proprietăţilor arătate acolo, referitoare la actualizarea şi ştergerea
câmpurilor legate, figura 5.32.
Fig. 5.32. Fereastra Edit Relationships
Stabilirea tipului de legătură se face prin fereastra Join Properties, care se

deschide cu butonul Join Type (figura 5.33).
Fig. 5.33. Fereastra Join Properties
Cele 3 tipuri de opţiuni au următoarele semnificaţii:

1: - extrage numai înregistrările din tabelul sursă care au înregistrări
echivalente în tabelul destinaţie.
2: - se mai numeşte legătură la stânga.
3: - se mai numeşte legătură la dreapta.
b) Legătura prin Lookup Wizard se face în faza de creare a tabelului,

când la alegerea tipului de dată se alege opţiunea din figura 5.34.
201
Fig. 5.34. Alegerea câmpului Lookup Wizard
În continuare „vrăjitorul” ne conduce pentru a realiza legătura propusă,

procedura este foarte clară, aşa că nu mai e cazul să fie prezentată aici.
Încercaţi-o şi nu veţi avea probleme.
Observaţie importantă!! Chiar dacă legăturile permanente dintre tabele în

Access creează unele facilităţi, evitaţi să le creaţi deoarece ar putea să vă
creeze unele neplăceri la crearea interogărilor din mai multe tabele, mai
ales când sunteţi începători. Dacă baza de date este corect proiectată, iar
legăturile dintre tabele se văd în documentaţia acesteia, cel mai înţelept
lucru este să folosiţi legăturile temporare, valabile numai pentru
interogarea respectivă.
202
Interogări cu parametri
Dacă într-o interogare este necesar să se schimbe foarte des criteriile de

selecţie, este recomandabil ca aceasta să fie transformată într-o interogare
cu parametri. Astfel, la apariţia oricărei schimbări, cererea trebuie
reproiectată, modificând criteriile, ceea ce este total ineficient. Avantajul
unei interogări cu parametri, constă în faptul că aceste criterii care se
modifică primesc valori în momentul execuţiei cererii.
Astfel, dacă într-un tabel cu facturi avem datele calendaristice la care au

fost emise şi furnizorii acestora, este foarte probabil că vom dori obţinerea
unor situaţii ca acestea:
- facturile primite într-o lună oarecare sau un interval de timp;
- facturile primite de la un anumit furnizor;
- facturile primite de la un furnizor într-un interval de timp.
Astfel de interogări nu sunt greu de făcut, inconvenientul este că pentru

orice situaţie scoasă trebuie să punem alte criterii, care de altfel, diferă
foarte puţin între ele, adică numele furnizorului sau a intervalului de timp.
Mai mult, cel care face interogarea trebuie să stăpânească procedura de
construcţie a acesteia, ceea ce ar fi prea mult pentru un utilizator obişnuit.
Dacă ar trebui să introducă numai nişte parametri pentru ca interogarea să
funcţioneze, ar fi altceva.
În continuare vom încerca să construim câteva interogări cu parametri care

să poată fi folosite ca modele pentru aplicaţiile pe care le veţi face singuri.
Să reluăm baza de date cu diagrama din figura 5.35.
Pret
..............
tblFurnizori
FurnizorID ChP
Furnizor
CodFiscal
...........
Fig. 5.35. Diagrama bazei de date
203
Ne propunem mai întâi să construim o interogare care să găsească toate
facturile primite de la un furnizor, al cărui nume să-l dăm în momentul
interogării. Pentru aceasta executăm paşii următori:
1. Deschideţi o nouă interogare în modul Design View. Introduceţi tabelele

tblFacturi şi tblFurnizori. Trageţi câmpurile aşa cum se vede în figura
5.36.
Fig. 5.36. Grila de

proiectare
2. În rândul Criterii de la câmpul Furnizor introduceţi între paranteze

drepte:
[Introduceti furnizorul:]
3. Vizualizaţi interogarea cu butonul , care va deschide caseta din

figura 5.37.
Fig. 5.37. Introducerea

parametrului interogării
Introducând un furnizor existent, se va afişa un tabel cu toate facturile

emise de acesta.
Dacă dorim, putem vedea ce expresie SQL a generat Access-ul:
204
SELECT tblFurnizori.Furnizor, tblFacturi.NrFactura, tblFacturi.Data
FROM tblFacturi INNER JOIN tblFurnizori ON tblFacturi.FurnizorID =
tblFurnizori.FurnizorID
WHERE (((tblFurnizori.Furnizor)=[Introduceti furnizorul:]));
Reluăm procedura şi vom încerca să afişăm facturile primite într-un

interval de timp. Grila de proiectare trebuie să arate ca în figura 5.38.
Fig. 5.38. Grila de

proiectare pentru un
interval de timp.
Cele 2 cereri de parametri sunt arătate în figura 5.39.
Fig. 5.39. Introducerea celor 2 parametri
Pornind de la aceste exemple, încercaţi să construiţi şi alte interogări cu

parametri pentru a acumula experienţă.
205
Rapoarte
Rapoartele nu sunt altceva decât nişte formulare cu informaţii extrase din
baza de date, care se tipăresc pe hârtie şi sunt folosite ca documente care se
pot pune în dosare sau se arhivează. Tehnica de lucru este asemănătoare cu
cea de la formulare. Ca şi formularele, rapoartele au o sursă de date care
poate fi un tabel sau o interogare.
Crearea rapoartelor este cea mai spectaculoasă acţiune dintr-o aplicaţie de

baze de date. Acest lucru se datorează faptului că rapoartele conţin tocmai
informaţiile care au stat la baza obiectivelor bazei de date. Aceste rapoarte
ajung în mâna unor persoane care au mai puţină legătură cu bazele de date,
dar sunt foarte exigente în legătură cu exactitatea acestor informaţii. Aceste
persoane pot fi manageri de top care ar putea fi singurele care înţeleg
semnificaţia unor informaţii. Forma de prezentare a acestora în cadrul
raportului este foarte importantă.
Crearea unui raport simplu
Cu siguranţă, primul raport pe care o să-l faceţi va fi unul fără pretenţii,

făcut cu ajutor din partea programului Access. Modalitatea cea mai simplă
de preluare a informaţiilor dintr-un tabel şi aducerea acestora într-un
format corespunzător pentru tipărire este folosirea procedurii AutoReport.
Aceasta permite crearea unui raport în format tabelar sau de tip coloană.
Un raport în format tabelar, cel mai uzual de altfel, este asemănător unei
foi de date Excel. Dezavantajul procedurii AutoReport este că raportul se
bazează pe un singur tabel sau interogare. De asemenea, forma de
prezentarea este una rigidă, impusă.
Cel mai indicat lucru pentru a înţelege cum se creează rapoartele este să
luăm un exemplu practic. Pentru aceasta, luăm ca exemplu baza de date pe
care am folosit-o la crearea formularelor. Această bază de date are
structura prezentată în figura 5.40.
206
Pret
..............
tblFurnizori
FurnizorID ChP
Furnizor Fig. 5.40. Diagrama bazei de
CodFiscal
...........
date
Baza de date conţine 4 tabele pentru urmărirea facturilor cu detaliile lor,

primite de o firmă de la diverşi furnizori. Tabelele conţin produsele,
facturile şi furnizorii aferenţi. Ne propunem să creăm diferite rapoarte cu
informaţii din această bază de date.
Vom crea un raport simplu care să ne afişeze toate produsele din tabelul
tblProduse, folosind procedura AutoReport. Pentru aceasta vom parcurge
următorii paşi:
1. Deschidem baza de date din figura 5.40 care are completate tabelele
cu date.
2. Executăm clic pe obiectul Reports, situat în stânga ferestrei

Database.
3.Executăm clic pe butonul New din bara de instrumente, situată în

partea de sus a ferestrei Database. Ca urmare va apare caseta de
dialog din figura 5.41.
Fig. 5.41. Alegem

tabelul tblProduse şi
opţiunea Tabular
207
4. Selectăm opţiunea AutoReport: Tabular.
5. Din lista derulantă din partea de jos, alegem tabelul tblProduse care
va fi sursa pentru raportul nostru.
6. Executăm clic pe butonul OK. În urma acestei manevre va apare

raportul în Print Preview, aşa cum se vede în figura 5.42.
Fig. 5.42. Partea de sus a raportului creat
După cum se vede, acest raport ar mai trebui aranjat puţin, în special la
alinierea coloanelor, dar pentru că l-am obţinut atât de uşor, îl putem
accepta şi aşa.
Crearea unui raport cu Report Wizard
Report Wizard este o aplicaţie inclusă în programul Access, cu ajutorul

căreia se pot face rapoarte cu adevărat performante, fără prea mare efort.
Această aplicaţie oferă un bun compromis între uşurinţa în utilizare şi
nivelul de control pe care îl avem asupra raportului în cursul elaborării lui.
Pentru a înţelege cum se elaborează un raport cu această metodă, vom lua

un exemplu concret. Având baza de date din paragraful anterior, adică
evidenţa facturilor cu detaliile lor şi pe furnizor, ne propunem să scoatem
un raport cu toate facturile şi detaliile lor pentru fiecare furnizor. Este
evident că vom avea nevoie de subtotaluri pe facturi, respectiv pe furnizori.
208
Se ştie că în spatele fiecărui raport se află, fie un tabel, fie o interogare.
Prin urmare, primul pas care trebuie să îl facem este identificarea acelui
tabel sau crearea interogării. La primul exemplu de raport am folosit un
tabel, la următorul exemplu vom folosi o interogare.
Ne propunem să elaborăm un raport care să aibă următoarele câmpuri:

Denumire, UM, Cantitate, Pret, Valoare, pentru fiecare produs primit şi să
avem subtotaluri pe facturi şi pe furnizori.
Ne vom folosi acum de cunoştinţele de SQL pentru a scrie o expresie care

să execute interogarea propusă. Iată cum arată această expresie:
SELECT Furnizor, f.NrFactura, pr.Denumire, pr.UM, df.Cantitate, pr.Pret, Cantitate*Pret
AS Valoare
FROM tblFacturi AS f, tblFurnizori, tblDetaliiFacturi AS df INNER JOIN tblProduse AS pr
ON df.ProdusID = pr.ProdusID
WHERE df.FacturaID=f.FacturaID AND f.FurnizorID=tblFurnizori.FurnizorID;
Observaţi că pe lângă câmpurile specificate s-au mai introdus câmpurile

Furnizor şi NrFactura care vor servi în raport pentru calcularea de
subtotaluri.
Rezultatul acestei interogări se poate vedea în figura 5.43.
Fig. 5.43. Interogarea

folosită în raportul care
va fi creat
Analizând această interogare, mare lucru nu înţelegem, nu putem trage nici

o concluzie despre facturi, furnizori etc. Sunt cam amestecate, dar sunt
reale şi corecte. Ceea ce va trebui să facem este să aranjăm aceste date într-
un raport tipărit care să fie inteligibil şi apoi să-l prezentăm şefului, nu-i
aşa?
209
Pentru a crea raportul propus vom parcurge etapele următoare:
1. Deschidem baza de date, care conţine interogarea de mai sus.
2. Executăm clic pe pictograma Reports.
3. În fereastra care s-a deschis, execută, dublu-clic pe opţiunea Create
Report by Using Wizard, pentru a lansa aplicaţia Report Wizard, după cum se
Fig. 5.44. Primul ecran

al aplicaţiei Report
Wizard permite
selectarea câmpurilor
raportului
4. Din comboBox-ul Tables/Queries se alege interogarea pregătită mai

devreme, în cazul nostru qryDetaliiFacturi cu furnizori.
5. Din lista Available Fields se aleg câmpurile raportului, în cazul nostru
toate, prin apăsarea butonului (>>). După ce am transferat toate câmpurile
în partea dreaptă, se apasă butonul Next pentru a trece la ecranul următor.
6. În acest ecran putem să grupăm înregistrările după câmpul furnizor, iar
în cadrul furnizorului după numărul facturii. Pentru aceasta trecem primele
2 câmpuri în partea dreaptă cu butonul (>). Rezultatul acţiunii se vede în
figura 5.45.
Fig. 5.45. Fereastra în care

configurăm nivelul de grupare
210
Se observă că prima grupare se face după câmpul NrFactura, iar a doua
după câmpul Furnizor. Se trece la ecranul următor apăsând butonul Next.
7. În ecranul următor, putem sorta înregistrările din detalii după un anumit
câmp. Noi am ales sortarea ascendentă după câmpul Denumire, după cum
se vede în figura 5.46.
Fig. 5.46. Ecran pentru

modul de sortare
Din acest ecran, prin apăsarea butonului Sumary Options se deschide un

nou ecran în care putem indica câmpurile pe care se fac totalurile parţiale.
Acest ecran este arătat în figura 5.47.
Fig. 5.47. Stabilirea

coloanelor pentru sume.
Observaţi că au fost afişate numai coloanele cu valori numerice, iar pe

lângă sumă se pot calcula media aritmetică, minimul şi maximul de pe
coloane. Dacă nu vrem să apară în raport toate detaliile, activăm opţiunea
Summary Only. Cu butonul OK se ajunge la ecranul precedent. Se apasă
butonul Next.
211
8. În acest ecran aplicaţia ne cere să alegem un model de aranjare a datelor
în raport, figura 5.48.
Fig. 5.48. Aranjarea datelor în

pagină
Alegem prima opţiune Steped, care este mai potrivită pentru raportul
nostru. Tot în acest ecran putem alege forma paginii, Portrait sau
Landscape. Se apasă butonul Next.
9. În ecranul următor aplicaţia ne cere să alegem o formă de prezentare a
raportului, figura 5.49. Alegem opţiunea Formal.
Fig. 5.49. Alegerea modului

de prezentare a raportului
Se apasă butonul Next pentru a trece la ecranul următor.
10. În fine, am ajuns la ultimul pas al elaborării raportului, în care ni se

cere să îi dăm un nume, figura 5.50.
212
Fig. 5.50. Alegerea

numelui şi terminarea
raportului.
Când apăsăm butonul Finish va apare pe ecran previzualizarea raportului.

S-ar putea ca aranjamentele coloanelor, a subtotalurilor să nu fie cea mai
potrivită. De aceea trebuie să intram în modul Design apăsând butonul
, în urma căruia va apare imaginea din figura 5.51.
Fig. 5.51. Raportul afişat

în modul Design.
În acest mod de afişare a raportului, putem să mişcăm cu mouse-ul

obiectele, să le schimbăm proprietăţile, aşa cum făceam la crearea
intefeţelor în Visual Basic.
După terminarea acestei operaţiuni raportul nostru ar trebui să apară ca în

figura 5.52.
213
Fig. 5.52. Forma finală a raportului
Din analiza acestui raport, se poate afla ce facturi are fiecare furnizor, ce
conţine fiecare factură, se văd totalurile facturilor şi totalul general pe
fiecare furnizor. Este un document util pentru managerii firmei respective.
Particularizarea unui raport
Am prezentat până acum două metode de obţinere a rapoartelor:

AutoReport şi Report Wizard. Aceste metode ne ajută să elaborăm rapoarte
tipizate, prefabricate, adică ni se propun variante iar noi alegem pe cea mai
convenabilă. Deşi se fac relativ repede, aceste rapoarte nu ne satisfac
întrutotul, de aceea este nevoie să intervenim pentru îmbunătăţirea lor, cu
unelte puse la dispoziţie de programul Access.
214
În principiu, pentru elaborarea rapoartelor performante, se pleacă cu una
din cele 2 metode amintite AutoReport sau Report Wizard, după care se
procedează la editarea acestora pentru a le aduce la forma finală. Prin
editare se pot adăuga sau şterge anumite elemente, conform cerinţelor
practice.
Pentru a edita un raport se procedează într-o manieră asemănătoare cu

editarea unui formular, de aceea este indicat să revedeţi paragraful Crearea
manuală u uni formular. Ca şi un formular, raportul are 3 părţi: Header,
Footer şi Detail. Acestea sunt puse în evidenţă în afişarea în modul Report
Design a raportului. Pentru a ajunge în această stare executaţi, în ordine
clic pe butoanele Reports şi Design, a cărui rezultat se vede în figura 5.53.
Fig. 5.53. Afişarea în modul

Design a formularului
După ce se intră în modul Design, trebuie activate casetele Toolbox şi

Properties cu butoanele arătate prin săgeţi în figura 5.53.
Cu ajutorul mouse-ului puteţi acum să selectaţi obiectele de pe formular şi

să le schimbaţi proprietăţile. De cele mai multe ori veţi schimba poziţiile
casetelor de text şi a etichetelor, mărimea şi tipul de font etc. După se aţi
făcut unele schimbări, urmăriţi-le activând raportul cu butonul View ( )
din partea stângă a Toolbar-ului.
215
Este evident faptul că obţinerea unor rapoarte aspectuoase şi performante
este legată direct de experienţa pe care o veţi dobândi. Această experienţă
nu e greu de obţinut, trebuie numai să faceţi cât mai multe rapoarte şi să
aveţi răbdarea de a le perfecţiona cât mai mult. Este o muncă migăloasă dar
merită, deoarece formularele sunt cele care se văd din întreaga aplicaţie, şi
pe care le înţelege toată lumea şi de aici pericolul de a fi mereu criticate.
216
Macrouri
Din cele studiate până acum, am văzut că o bază de date Access este o
colecţie de obiecte, tabele, interogări, formulare, rapoarte etc. Noi am
învăţat să construim aceste obiecte. Toate obiectele unei baze de date
trebuie legate într-un flux continuu de operaţii, care împreună se constituie
într-o aplicaţie de baze de date. Exploatarea unei aplicaţii de baze de date
presupune o mulţime de operaţii manuale care sunt executate de orice
operator implicat.
În cadrul unei aplicaţii Access, de o mare importanţă este automatizarea

acesteia. Prin automatizare înţelegem că pe baza unei acţiuni a
utilizatorului, cum ar fi apăsarea unui buton al interfeţei, un dublu-clic etc,
se determină realizarea uneia sau mai multor operaţii (activarea unuia sau
mai multor obiecte, rularea unor interogări etc.).
Această automatizare a aplicaţiilor realizate în Access se poate face în două

moduri:
 Prin utilizarea limbajului Visual Basic for Applications (VBA);
 Prin utilizarea macrocomenzilor, care reprezintă o formă simplificată
a limbajului VBA.
Comenzile macro sunt deosebite prin caracteristica lor unică şi anume că

permit automatizarea diverselor evenimente fără ca realizatorul aplicaţiei
să fie nevoit să cunoască un anumit limbaj de programare.
Prin evenimente putem înţelege:

 Modificări ale datelor;
 Deschiderea sau închiderea unui formular sau raport;
 Acţiunea asupra unor obiecte de control din formulare.
În Microsoft Access există un mare număr de tipuri de acţiuni care pot fi

executate în cadrul unor comenzi macro. Totul depinde de noi, să le
cunoaştem şi să le aplicăm corect, în cunoştinţă de cauză.
Iată câteva din aceste acţiuni:
217
 Deschiderea sau închiderea unor tabele, interogări, formulare sau
rapoarte;
 Vizualizarea sau tipărirea rapoartelor;
 Rularea cererilor de interogare de acţiune;
 Apelarea altor comenzi macro;
 Efectuarea condiţionată a anumitor acţiuni;
 Căutarea anumitor date în tabele;
 Deschiderea sau închiderea unor meniuri din Access;
 Afişarea anumitor mesaje;
 Ştergerea, redenumirea, copierea sau salvarea diferitelor obiecte ale
aplicaţiei;
 Comunicarea cu alte produse soft, cum ar fi Word şi Excel.
Cea mai bună metodă de a începe să proiectăm macrocomenzi este să ne

gândim la un proces pe care îl parcurgem în mod repetat, ceva care facem
de mai multe ori pe zi sau săptămânal. De exemplu, dacă în fiecare zi avem
de dat conducerii un raport cu vânzările zilei sau avem frecvent de făcut
unele modificări cu ajutorul unor interogări de acţiune. Presupunem că am
găsit un astfel de scenariu, deci putem trece la automatizarea lui.
Crearea macrocomenzilor cu o singură acţiune
Crearea macrocomenzilor se face cu ajutorul ferestrei Macro Design

prezentată în figura 5.54.
Coloana Macro Name Coloana Condition Coloana Action Coloana Comment
Zonă în care vor

fi afişate
argumentele
acţiunii curente.
Fig. 5.54. Fereastra Macro Design

218
Rolul fiecărei coloane, îl puteţi deduce după numele ei. Pentru început,
cele mai importante sunt coloanele Action şi Comment, adică cele în care
veţi defini şi comenta acţiunile. De altfel, numai aceste două coloane vor fi
afişate la început. Pentru afişarea celorlalte va trebui să apăsaţi butoanele (
) şi ( ) din toolbar-ul situat în partea de sus a ecranului.
Observaţi că acţiunile pe care doriţi să le executaţi trebuie alese din

coloana Action dintr-un comboBox, în care sunt peste 50 de acţiuni care
acoperă necesarul pentru macro-urile obişnuite. Este un obicei bun de a
comenta fiecare acţiune pentru o bună informare, mai ales pentru
intervenţiile ulterioare în modificările aduse aplicaţiei.
În partea de jos-stânga, vor fi afişate cererile de argumente pentru acţiunea

selectată.
O macrocomandă poate fi alcătuită dintr-o singură acţiune, sau din mai

multe. Ca să adăugaţi în macrocomandă o acţiune, mutaţi cursorul în
coloana Action şi deschideţi lista derulantă, de unde alegeţi una din cele
peste 50 de acţiuni, dintre care multe au subacţiuni suplimentare.
Un exemplu simplu vă va ajuta să creaţi şi să executaţi o primă

macrocomandă. Ne propunem să afişăm un formular care există în baza
noastră de date. Macrocomanda rezultată se vede în figura 5.55.
Fig. 5.55. Macromandă cu o singură

acţiune
Macrocomenzile se salvează ca şi formularele şi se lansează cu un dublu-

clic sau cu butonul Run din fereastra Database. În figura 5.56 se pot vedea
2 macrocomenzi, una care deschide un formular şi alta care produce un
semnal sonor.
219
Fig. 5.56. Frereastra

Database cu 2 macro-uri
Crearea unei macrocomenzi cu mai multe acţiuni
De multe ori în practică, este necesar de mai multe acţiuni grupate sub
aceeaşi macrocomandă. Pentru a defini acţiuni multiple, care să se execute
una după alta, trebuie doar să le adăugaţi pe următoarele linii ale ferestrei
Macro Design.
Un exemplu de folosire a mai multor acţiuni poate fi acela în care ar trebui

rulată o expresie SQL, apoi deschiderea unui formular. Desigur, folosirea
eficientă a macrocomenzilor din Access, nu este chiar la îndemâna
începătorilor. Folosirea lor curentă va veni în mod natural, pe măsură ce
practica o cere, iar experienţa o permite.
O facilitate importantă a acţiunilor multiple este folosirea condiţiilor în

macrocomenzi. Utilizând coloana Condition puteţi adăuga unele decizii,
cum ar fi, de exemplu, afişarea unor mesaje în funcţie de o anumită
condiţie. Expresiile introduse drept condiţii trebuie evaluate la valorile True
sau False. În cazul când condiţia este evaluată la True, se execută acţiunea
corespunzătoare; dacă este False, acţiunea nu se mai execută.
O altă facilitate oferită de fereastra Macro Design este posibilitatea de a

grupa macrocomenzile. Coloana Macro Name vă permite să vă gestionaţi
mai uşor macrocomenzile, mai ales când numărul lor creşte foarte mult.
Dacă specificaţi un nume în această coloană, pe prima linie,
macrocomanda dumneavoastră va fi considerată a fi un grup de
macromenzi. Într-un astfel de grup puteţi stoca sub un singur nume mai
220
multe macrocomenzi înrudite, care vor primi un nume sugestiv, ales de
dumneavoastră. În acest fel organizarea macrocomenzilor va fi mult mai
practică.
Când se rulează macrocomanda, se va rula doar primul grup. Întrebarea,

firească, pe care v-o puneţi este cum puteţi rula şi celelalte grupuri?
Răspunsul este simplu: nu puteţi. Dacă aveţi într-o macrocomandă mai
multe grupuri, pentru a rula şi alte grupuri decât primul va trebui să folosiţi
o acţiune RunMacro. În acest caz veţi putea alege numele macrocomenzii
care se va rula, vezi figura 5.57.
Fig. 5.57. Grupuri

de acţiuni
Observaţi că la acţiunea RunMacro a fost ales numele grupului Raportari

care face parte din macrocomanda Macro1.
Cu ajutorul grupurilor de macrocomenzi puteţi ţine toate acţiunile legate de

un formular sau raport într-o singură macrocomandă.
După cum spuneam, există în Access peste 50 de acţiuni care au fiecare

propriile argumente. Dacă doriţi să obţineţi o listă completă a acestor
acţiuni, precum şi descrieri succinte ale lor şi a argumentelor pe care le
folosesc, deschideţi o macrocomandă nouă şi selectaţi acţiunea care vă
interesează. Toate informaţiile importante vor fi afişate pe ecran. Dacă
doriţi mai multe exemple, le puteţi găsi în sistemul Help din Access.
Rularea macrocomenzilor
În acest paragraf vom studia diferitele moduri de accesare a

macrocomenzilor pe care le creaţi în diferite aplicaţii Access, precum şi
unele macrocomenzi speciale, native, ale sistemului Access, cum ar fi
AutoExec şi AutoKeys.
221
Rularea unei macrocomenzi din fereastra Database
Paşii pe care trebuie să-i parcurgeţi sunt următorii:
1. În fereastra Database, selectaţi obiectul Macros (dacă nu e selectat);
2. Selectaţi macrocomanda pe care doriţi să o rulaţi;
3. Executaţi clic pe butonul Run pentru a executa macrocomanda. Deşi

puteţi rula în acest mod toate macrocomenzile pe care le-aţi creat, vă
reamintesc că în cazul macrocomentilor care conţin grupuri, în acest mod
se execută numai primul grup de acţiuni, celelalte fiind ignorate.
Pentru a executa un anumit grup dintr-o macrocomandă, folosiţi meniul. În

cazul în care vreţi să rulaţi manual o anumită macrocomandă dintr-un grup
folosiţi metoda descrisă în continuare.
Rularea unei macrocomenzi dintr-un grup
1. Selectaţi din meniul principal opţiunea: Tools – Macro – Run Macro. Se va

deschide caseta de dialog din figura 5.58.
Fig. 5.58. Caseta Run Macro
2. Selectaţi din lista derulantă macromanda pe care doriţi să o executaţi.
3. Executaţi clic pe butonul OK pentru a executa macrocomanda.
Observaţi cum caseta de dialog Run Macro prezintă toate macrocomenzile

disponibile în baza de date, grupurile fiind reprezentate sub forma
macroname.macrogrup, unde macroname este numele din fereastra Database,
iar macrogrup numele unui grup din cadrul macrocomenzii respective.
Utilizarea acţiunii RunMacro
O altă metodă de execuţie a macrocomenzilor, este rularea lor dintr-o altă

macrocomandă cu ajutorul acţiunii RunMacro. În figura 5.57 se poate vedea
cum se foloseşte această metodă. La sfârşitul unui grup de acţiuni se
222
introduce acţiunea RunMacro care va lansa în execuţie macrocomanda
nominalizată de argumentul Macro Name.
Macrocomenzi ataşate evenimentelor
Probabil că metoda cea mai utilizată pentru rularea macrocomenzilor din

aplicaţiile Access, nu este rularea directă, ci ca răspuns la un eveniment
Access. Aceste evenimente pot fi declanşate de tot felul de lucruri care se
pot întâmpla la nivel de formular, raport sau chiar de control individual din
cadrul acestora – de exemplu, deschiderea unui formular declanşează
evenimentul OnOpen al formularului respectiv, la introducerea unei valori
într-o casetă de text declanşează evenimentul OnClick, iar dacă utilizatorul
actualizează datele dintr-un control al unui formular se declanşează
evenimentul AfterUpdate ataşat controlului respectiv.
Pentru a identifica evenimente ale diferitelor obiecte, nu aveţi decât să

selectaţi obiectul respectiv şi să-i studiaţi evenimentele, activând opţiunea
Event din fereastra Properties. Este de la sine înţeles că vă sunteţi pe un
formular aflat în modul Design.
În aplicaţia dumneavoastră vă puteţi folosi de aceste evenimente spunându-

i programului ruleze la apariţia unui anumit eveniment ataşat unui
formular, raport sau control o anume macrocomandă. Utilizând
evenimentele în acest mod vă puteţi perfecţiona aplicaţia, astfel încât ea să
ofere ceva în plus faţă de funcţiile oferite de Access – permiţând, de
exemplu, utilizatorilor să se deplaseze între diferite obiecte ale aplicaţiei
fără să ştie măcar de existenţa ferestrei Database.
Utilizarea macrocomenzilor AutoExec şi AutoKeys
Aceste macrocomenzi au nume speciale, rezervate şi sunt mocrocomenzi

native ale programului Access.
Macrocomanda AutoExec. Atunci când deschideţi baza de date, Access

verifică dacă în cadrul acesteia nu există o macrocomandă cu numele
AutoExec. Dacă există o astfel de macrocomandă, ea este executată
automat. Această macrocomandă poate fi folosită pentru pregătirea
aplicaţiei; de regulă ea este folosită împreună cu opţiunile de pornire a
Access-ului.
223
Observaţie importantă!! Dacă doriţi să evitaţi rularea macrocomenzii
AutoExec, menţineţi apăsată tasta Shift în timp ce deschideţi baza de date.
În general, se foloseşte comanda AutoExec pentru a apela o funcţie VBA

(prin intermediul acţiunii RunCode) personalizată pentru fiecare aplicaţie în
parte.
Macrocomanda AutoKeys. Acestei macrocomenzi, Access-ul îi acordă un

tratament special. Cu ajutorul acestei macrocomenzi puteţi să asociaţi
oricărei acţiuni, o combinaţie de taste dintre cele disponibile. Mai mult
puteţi chiar să modificaţi comportamentul prestabilit al anumitor
combinaţii de taste.
Iată un exemplu de utilizare prezentat în figura 5.59.
Fig. 5.59. Exemplu de atribuire a unei

combinaţii de taste unei macrocomenzi
În exemplul nostru, combinaţia de taste SHIFT + p lansează macrocomanda

care afişează o listă cu produse. Reţineţi că macrocomanda se numeşte
AutoKeys, iar combinaţia de taste a fost trecută în coloana Macro Name.
Metodă rapidă de pornire a aplicaţiilor
Ca o alternativă a macrocomenzii AutoExec, trebuie amintit aici că

începând cu versiunea Access 95, a fost introdusă o posibilitate de setare a
opţiunilor de pornire a aplicaţiilor.
224
Având deschisă aplicaţia ale cărei opţiuni de pornire vrem să le
automatizăm, dăm comanda Tools – Startup, care va deschide caseta de
dialog din figura 5.60.
Fig. 5.60. Caseta de dialog Startup
Setările din această casetă de dialog sunt destul de evidente. Practic, putem
să înlocuim toată ”faţada” programului Access.
Reţineţi că această manevră este ultima, după ce aplicaţia a fost testată şi

nu mai avem nimic de modificat la ea. Nu încercaţi să ascundeţi meniul
principal şi toolbar-urile, înainte de forma finală, pentru că aţi putea
ajunge să nu mai puteţi interacţiona cu aplicaţia deoarece nu mai aveţi
instrumente de acces. Pentru astfel de încercări, faceţi-vă o copie de
rezervă.
Publicarea datelor pe Internet

Toată lumea ştie ce înseamnă azi Internetul, dar mai ales ce va însemna
mâine, mai ales după integrarea României în Uniunea Europeană.
Internetul a ajuns să fie cea mai avansată formă de comunicare a zilelor
noastre.
Prin conectarea la Internet întreprinderile îşi creează un avantaj

concurenţial, demn de luat în seamă. Având în vedere că o serie de rapoarte
de sinteză ale unei firme interesează clienţii, cum să fie informaţi aceştia
dacă nu prin Internet. Rapoartele obţinându-se, în principal, dintr-o
aplicaţie de bază de date, iată legătura dintre Access şi Internet.
225
Tot ce avem de făcut este să transformăm un raport sau un formular în
document HTML, care poate fi postat pe un site de Internet. Din fericire,
programul Access, începând cu versiunea 2000, oferă facilităţi de a scoate
rapoarte direct în format HTML. Prin urmare, pe lângă formulare şi
rapoarte, vom învăţa să scoatem din Access şi documente care pot fi
publicate pe Internet.
În principiu, paginile cu documente HTML se pun pe un server Web, de

unde pot fi accesate prin intermediul unui soft numit browser. Deci noi
trebuie doar să creăm fişiere HTML şi să le punem pe serverul Web, de
unde pot fi vizualizate de oricine.
În cele ce urmează vom încerca să creăm câteva pagini HTML direct din
programul Access. Există 2 tipuri de documente pe Internet:
 Pagini Web statice;
 Pagini Web dinamice.
Le vom studia pe rând, în paragrafele următoare.
Pagini Web statice
Pagina Web statică este un document de tip prospect, adică are tot timpul
acelaşi conţinut, cum a avut la crearea sa. Acest tip de documente se pot
crea cel mai simplu dintr-un obiect al bazei de date, folosind metoda
Export. Această metodă creează o pagină Web bazată pe un singur tabel
sau interogare din baza de date curentă.
Iată paşii care trebuie parcurşi pentru a crea un document static:
1. În fereastra Database, selectaţi obiectul pe care pe care doriţi să-l salvaţi

în format HTML.
2. Selectaţi opţiunea File – Export.
3. În caseta de dialog Save, selectaţi lista derulantă Save as Type, opţiunea

HTML Documents (*.html; *.htm). Vezi figura 5.61.
226
Fig. 5.61. Crearea unei

pagini HTML statice
Bifaţi această opţiune
pentru a exporta şi
capul de tabel
4. Apăsaţi butonul Export lăsând implicite celelalte opţiuni cerute (Default

endcoding). Veţi obţine o pagină HTML, aşa cum se vede în figura 5.62.
Fig.5.62. Pagina HTML obţinută,

afişată cu Internet Explorer
Această pagină afişează în format HTML rezultatul unei interogări. Tot aşa
puteţi afişa conţinutul unui tabel. Reţineţi că dacă se schimbă ceva în
tabelele de bază ale interogării, această modificare nu se reflectă în pagina
HTML. Când folosiţi această tehnică trebuie să aveţi în vedere acest lucru.
Paginile Web statice, chiar dacă provin din exportul de obiecte din Access,
nu sunt obiecte Access, ele vor fi salvate ca pagini independente cu
extensia *.html, într-un director pe care îl puteţi alege.
227
Pagini Web dinamice
Pagina web dinamică este acel document care poate oferi mai multe
informaţii, în funcţie de cererile lansate de utilizator. Un exemplu ar putea
fi formularul creat într-o aplicaţie Access care ne permite să parcurgem
înregistrările unui tabel. Orice modificare în tabelele de bază se va reflecta
în pagina Web dinamică. Acest tip de documente o să ne preocupe în
continuare.
Versiunea 2000 a programului Access şi următoarele, permit realizarea de

pagini Web dinamice. În fapt aceste pagini sunt formulare şi rapoarte care
pot fi publicate pe Internet. Observaţi în lista obiectelor din fereastra
Access, apariţia obiectului Pages, care grupează paginile Web ale bazei de
de date curente.
Există două moduri de creare a unei pagini Web dinamice din Access: prin
utilizarea instrumentului Wizard şi constructia lui de la zero în cadrul
ferestrei de proiectare. La fel ca la formulare, nu?
Când suntem ajutaţi de instrumentul Wizard, avem două posibilităţi:

AutoPage şi Page Wizard. Le vom folosi pe rând.
Crearea unei pagini dinamice de date cu AutoPage
Cu AutoPage puteţi crea rapid o pagină Web dinamică, servind pentru

introducerea şi afişarea de date pe Web.
Iată paşii pe care trebuie să-i parcurgeţi:
1. Din fereastra Database selectaţi Pages – New.
2. În caseta de dialog New Data Access Page, selectaţi sursa de înregistrări

(un tabel sau o interogare), selectaţi AutoPage:Columnar, apoi apăsaţi
butonul OK.
3. AutoPage creează o pagină Data Access folosind toate câmpurile

conţinute în sursa de înregistrări selectată, pagină pe care o afişează în
modul Page. În figura 5.63 este afişată o astfel de pagină.
228
Fig. 5.63. Pagină Web

dinamică obţinută cu
AutoPage
Dacă nu sunteţi mulţumiţi de aspectul paginii, intraţi în modul Design şi

schimbaţi ce doriţi, la fel cum aţi procedat la tabele şi rapoarte. După
modificările aduse salvaţi pagina cu comanda File – Save As. Atenţie însă
că numele şi salvarea sunt stabilite de către programul Access, asupra
cărora nu aveţi nici un control. Acest lucru vă este anunţat după cum se
Fig. 5.64. Avertismentul legat

de conectarea la pagină
Pentru a vă putea conecta la paginile create, folosind reţeaua trebuie să

editaţi conexiunea intrând în codul HTML. Aceasta nu este o operaţiune
chiar simplă, de aceea trebuie efectuată de administratorul bazei de date.
Crearea paginilor dinamice cu Page Wizard
Utilizarea vrăjitorului (wizard) pentru crearea paginilor Data Access este

similară cu folosirea AutoPage, cu observaţia că primul oferă mai multă
flexibilitate. Utilizând Page Wizard puteţi folosi mai multe surse de date şi
aveţi posibilitatea de a selecta câmpurile pe care doriţi să le afişaţi.
Iată paşii pe care trebuie să-i parcurgeţi:
229
1. Din fereastra Database selectaţi Pages – New.
2. În caseta de dialog New Data Access Page, selectaţi Page wizard, apoi
apăsaţi butonul OK. Puteţi selecta şi o sursă de date, dar nu este obligatoriu.
3. În caseta Page Wizard, selectaţi sursa de date, un tabel sau o interogare,
şi câmpurile pe care doriţi să le afişaţi, apoi apăsaţi butonul OK.
4. În următoarea casetă de dialog puteţi selecta opţiunile de grupare. Dacă
selectaţi o asemenea opţiune, pagina va deveni read-only. Când sunteţi
gata, apoi apăsaţi butonul OK.
5. Următoarea casetă de dialog vă cere să specificaţi o ordine de sortare.
6. Ultima casetă de dialog vă permite să acordaţi paginii un nume, să
selectaţi o temă (fundal) şi să deschideţi pagina în modul Design sau View.
Dacă deschideţi pagina în modul de afişare View, Access o va salva în
dosarul prestabilit; de aceea, dacă doriţi să specificaţi şi locaţia fişierului,
recomandarea este să afişaţi mai întâi pagina în modul Design. Executaţi
clic pe butonul Finish pentru a vă putea vizualiza pagina.
7. Când sunteţi mulţumit de aspectul paginii şi doriţi să o salvaţi, daţi
comanda File – Save As, astfel încât să puteţi specifica şi locaţia fişierului.
În figura 5.65 este prezentată o pagină Web dinamică, obţinută prin această
metodă.
Fig. 5.65. Pagină Web dinamică

obţinută cu Page Wizard
230
Pagina este afişată cu browserul Internet Explorer. Pentru a exersa puteţi

încerca să puneţi în pagină Web şi alte informaţii din baza de date, pentru
că nu e departe momentul când şeful o să vă ceară să puneţi un raport la
care aţi trudit din greu, într-o locaţie de pe Internet, pentru că el e plecat la
o specializare în SUA.
Comunicarea între aplicaţiile pachetului Office
Pachetul Office al firmei Microsoft a fost conceput ca un instrument util şi

foarte performant cu ajutorul căruia să se poată realiza un număr mare de
sarcini în cadrul unui birou al unei firme sau chiar la domiciliu.
Popularitatea produsului Office se datorează, pe lângă gradul sporit de

complexitate, facilităţii sale deosebite de a permite diferitelor aplicaţii care
îl compun, să comunice între ele. Astfel, informaţiile dintr-o aplicaţie
Access pot fi transferate (exportate) în Excel, unde se pot face anumite
calcule, după care acestea pot fi transferate (exportate) în Word în vederea
realizării unui document de sinteză.
Sistemul de operare Windows conţine o facilitate Object Linking and

Embedding (Introducere şi legarea obiectului) sau pe scurt OLE.
În fond OLE este o metodă de transfer a informaţiei între diferite aplicaţii

Windows sub formă de obiecte. Metoda OLE oferă un mare avantaj
aplicaţiilor realizate în Access, putând fi create baze de date de tip
multimedia în care pot fi stocate fişiere audio(WAV), fotografii şi desene,
animaţie şi chiar filme(AVI).
Începând cu Access 2000, au fost introduse trei facilităţi noi:

 Dynamic Data Exchange, DDE - schimbul dinamic de date;
 ActiveX Objects – obiecte ActiveX;
 ActiveX Custom Controls – controale personalizate ActiveX.
Facilitatea DDE permite executarea unor funcţii precum transmiterea de

date între Access şi orice altă aplicaţie Windows care suportă facilitatea
DDE. Se pot crea conexiuni de tip DDE cu alte aplicaţii prin utilizarea
comenzilor macro sau a limbajului VBA.
231
ActiveX este o facilitate avansată a sistemului de operare Windows care
permite crearea unor anumite legături între obiecte precum şi includerea lor
în cadrul bazelor de date Access. Prin obiecte înţelegem fotografii, desene,
grafice, foi de calcul Excel şi documente.
Access poate fi folosit ca un server ActiveX, permiţând deschiderea şi

lucrul cu obiecte ale bazei de date Access (tabele, interogări şi formulare)
din cadrul altor aplicaţii de tip Windows.
Exportul şi importul de date
Comunicarea programului Access cu celelalte componente ale pachetului

Office, rămâne un element de bază. Spre exemplu dorim să realizăm un
export de date dintr-un tabel Access către un document Word. Datele vor
apare în Word într-un tabel.
Un alt caz des utilizat este exportul din Access către Excel al unui tabel sau
interogări. În ambele cazuri se foloseşte comanda File - Export. Încercaţi
această comandă pentru cazuri concrete. De multe ori este nevoie ca
anumite informaţii să fie prelucrate şi sintetizate în Excel, înainte de a fi
cuprinse într-un raport.
Importul este operaţia inversă care se execută cu comanda File – Get External
Data – Import. Încercaţi şi funcţionarea acestei comenzi.
Recomandări privind aplicaţiile ACCESS

Cu siguranţă, la primul proiect de aplicaţie Access, nu sunteţi un specialist
al domeniului. Aveţi încă multe lucruri neclare, peste care aţi trecut mai
uşor în timpul studiului. Fiţi liniştit pentru că toate acestea se vor clarifica
în timpul aplicaţiilor pe care le veţi aborda în viitor. Practica este aceea
care ar putea fi numită „evaluatorul perfect” al cunoştinţelor acumulate (si
nu numai în cazul de faţă).
Programul Access are câteva handicapuri de apreciere pe care, sincer, nu le

merită:
 Programatorii profesionişti îl evită pentru că ar fi dedicat
începătorilor şi are anumite limite, pe care e greu să le
232
argumenteze. Ei folosesc baze de date cum ar fi Oracle, SQL
Server, MySQL care sunt mult mai scumpe.
 Ceilalţi dezvoltatori de aplicaţii, au probleme cu folosirea
Access-ului din cauza lipsei de pregătire, deci sunt mai puţin
dispuşi să se aventureze într-un domeniu necunoscut.
Prin urmare, pentru unii este prea simplu iar pentru alţii prea complicat.
Posibilităţile oferite de Access, mai ales ultimele versiuni, sunt de-a dreptul
extraordinare, aşa încât utilizarea lui în firmele mici şi mijlocii pe scară
largă ar fi benefică, mai ales că aplicaţiile ar putea fi abordate cu resurse
proprii.
Programul Access e folosit de milioane de utilizatori de pe tot

mapamondul, sunt forumuri de discuţii pentru aceşti utilizatori, care se
ajută între ei cu sfaturi şi experienţe proprii. Cu siguranţă, că mulţi dintre ei
trăiesc de pe urma Access-ului, alţii îi folosesc din plin facilităţile. Dacă aţi
reuşit să înţelegeţi programul Access şi aţi făcut câteva aplicaţii cu el,
înseamnă că aţi înţeles bazele de date relaţionale şi puteţi trece şi la alte
produse de baze de date, dacă împrejurările o cer. Înseamnă că aveţi o bază
de plecare solidă.
În multe firme e nevoie de o metodă simplă de gestionare a tuturor

informaţiilor care există pe hârtie sau în aplicaţii stufoase: facturi,
înregistrări, informaţii contabile, contacte cu clienţi şi furnizori etc. De
asemenea, este nevoie de tipărirea unor rapoarte şi scrisori care nu ies
niciodată cum aţi dori, în care aveţi informaţii care trebuie calculate sau
completate de mână.
De asemenea, apare necesitatea publicării pe Web a unor informaţii

detaliate şi la zi despre afacerile firmei, pentru a fi studiate de către
parteneri sau de către alte filiale ale firmei care pot fi oriunde în lume.
Aceste oportunităţi pot fi exploatate folosind programul Access care este o

componentă a pachetului Microsoft Office. Practica mi-a demonstrat că
studenţii care au urmat acest curs au reuşit să acumuleze suficiente
cunoştinţe despre bazele de date, care au fost apoi aplicate în elaborarea
unor proiecte de diplomă valoroase sau la locurile de muncă de după
absolvire.
Wizard-urile care se găsesc din abundenţă în Access sunt nişte unelte

extrem de utile în dezvoltarea aplicaţiilor. Un formular sau un raport este
233
început cu un wizard, apoi este completat sau modificat de către
dezvoltator.
Folosirea macrourilor şi a formularului de start vă ajută să concepeţi

aplicaţii de baze de date care par a fi făcute de o echipă de profesionişti,
pentru că prin eliminarea ferestrei Database nu se mai vede că suntem în
Access (vezi pagina 208).
Exemplele care sunt prezentate în carte sunt inspirate din realitate, au fost
testate înainte de a ajunge aici, aşa că pot fi folosite fără nici o reţinere, ca
modele pentru aplicaţiile pe care le veţi face.
234
Baze de date Anexe
ANEXE
Anexa A. Administratorul de baze de date

Pentru a proiecta şi implementa o bază de date a unei firme sau instituţii
este nevoie de o echipă de profesionişti formată din reprezentaţi ai
beneficiarului şi ai furnizorului de soluţii informatice. După ce s-a
implementat şi testat baza de date şi instruit personalul care o va folosi,
echipa de dezvoltare se retrage din firmă şi începe, probabil, un nou
proiect.
Se pune problema, ce se întâmplă cu baza nostră de date după ce echipa de

dezvoltare a plecat şi au rămas numai utilizatorii finali? Aceştia ştiu să-şi
facă treaba pentru care au fost intruiţi, să opereze acolo unde au dreptul. Ce
se întâmplă dacă într-o dimineaţă, când porneşte aplicaţia, un utilizator
primeşte nişte mesaje ciudate pe care nu le înţelege, iar aplicaţia se
blochează? Cui ne adresăm? Înainte era acolo echipa de dezvoltare, care
rezolva orice problemă.
În acest moment, intră în joc administratorul bazei de date. Este de

neconceput ca o bază de date a unei firme sau instituţii, în jurul căreia se
învârte întrega activitate, să funcţioneze fără un adminstrator. Un manager
inteligent este conştient de acest lucru şi va rezolva problema chiar de la
început.
Cine poate fi aministrator de baze de date? O persoană care poate să

rezolve toate problemele cerute de post. O astfel de persoană a participat,
de regulă, din partea firmei la dezvoltarea proiectului şi a acumulat
cunoştinţe care îl ajută să-şi ducă la indeplinire sarcinile. Echipa
managerială trebuie să aibă înţelepciunea ca să numească în acest post o
persoană pregătită, pentru că datele firmei nu trebuie să fie compromise.
Prin persoană pregătită nu trebuie înţeles, o persoană cu diplomă (se ştie
cât de uşor se obţin acestea), ci una care trece nişte teste de competenţă.
Un administrator de baze de date are cunoştinţe, cel puţin la nivelul celor

prezentate în această carte, de la noţiuni de proiectare a unei baze de date,
cunoaşterea limbajului SQL, până la implementarea de aplicaţii în
ACCESS. Această meserie, este una a viitorului, pentru că tot mai multe
firme şi instituţii se informatizează şi au mult de suferit din cauză că au
235
Baze de date Anexe
probleme, de genul „nu merge bine”, rezultatele rapoartelor nu sunt corecte
etc., şi toate astea se întâmplă pentru că nu există acel administrator de
bază de date sau de sistem informatic.
Dacă firma nu-şi poate permite să ţină un administrator de baze de date cu

normă întreagă, există şi soluţia angajării unor consultanţi externi, care să
vină numai atunci când este nevoie de ei. Ar fi o soluţie temporară, până
când un angajat al firmei poate să îndeplinească această funcţie. Sigur,
decizia este luată de către conducerea firmei respective, în cunoştinţă de
cauză.
Care sunt sarcinile administratorului de bază de date? Administratorul

bazei de date are sarcini precise, care ar putea fi enumerate astfel:
 Răspunde de corectitudinea datelor introduse în baza de date;
 Răspunde de securitatea bazei de date, prin drepturile acordate
utilizatorilor;
 Salvează copii de siguranţă ale bazei de date, periodic;
 Dacă s-a produs o deteriorare a datelor, poate să intre direct în
tabele şi să le repare manual sau folosind limbajul SQL;
 Să acorde asistenţă utilizatorilor finali, pentru a elimina pe cât
posibil erorile umane;
 Să scoată rapoarte noi, care nu au fost prevăzute în proiect dar
care sunt cerute de anumite împrejurări;
 Să ţină legătura cu echipa de dezvoltare pentru a rezolva orice
problemă care îi depăşeşte competenţele;
 Să stabilească, când e cazul, reguli suplimentare pentru operatorii
finali;
 Să intercepteze şi să prevină orice evenimente care ar putea
afecta buna funcţionare a bazei de date.
Ca o concluzie a celor prezentate în această anexă, am putea spune că

administratorul de baze de date şi dacă extrapolăm, administrator de sistem
informatic, este o meserie a viitorului care va fi foarte căutată şi bine
plătită. Va fi un post cheie în orice organizaţie, o poziţie de mare
responsabilitate. Nu ar fi lipsit de interes să vă gândiţi la o carieră
profesională în acest domeniu.
236
Baze de date Anexe
Anexa B. Sintaxa instrucţiunilor SQL
În această anexă vor fi prezentate pe scurt principalele instrucţiuni SQL.
SELECT
Este instrucţiunea SQL cea mai utilizată, prima cu care luaţi contact. Se
foloseşte pentru regăsirea(interogarea) datelor din unul sau mau multe
tabele sau vederi. Sintaxa este următoarea:
SELECT NumeColoana1, NumeColoana2, ...
FROM tblTabel1, tblTabel2, ...
[WHERE ...]
[GROUP BY ...]
[HAVING ...]
[ORDER BY ...];
UPDATE
Instrucţiunea UPDATE actualizează una sau mai multe linii dintr-o

coloană. Sintaxa este următoarea:
UPDATE NumeTabel
SET NumeColoana1=valoare, NumeColoana2=valoare, ...
[WHERE ...];
INSERT
Instrucţiunea INSERT adaugă o singură linie într-un tabel. Sintaxa este

următoarea:
INSERT INTO NumeTabel [Coloana1, Coloana2, …)]
VALUES (Valoare1, Valoare2, ...);
INSERT SELECT
Instrucţiunea INSERT SELECT inserează rezultatele unei interogări, într-

un tabel. Sintaxa este următoarea:
INSERT INTO NumeTabel [Coloana1, Coloana2, …)]
SELECT Coloana1, Coloana2, … FROM Tabel1, Tabel2, …
[WHERE ...];
237
Baze de date Anexe
DELETE
Instrucţiunea DELETE şterge una sau mai multe linii dintr-un tabel.
Sintaxa este următoarea:
DELETE FROM NumeTabel
[WHERE ...];
DROP
Instrucţiunea DROP şterge permanent obiecte din bazele de date (tabele,

vederi, etc). Sintaxa, pentru ştergerea unui tabel, este următoarea:
DROP NumeTabel;
CREATE TABLE
Instrucţiunea CREATE TABLE este folosită pentru crearea de noi tabele

într-o bază de date. Sintaxa este următoarea:
CREATE TABLE NumeTabel
(
Coloana1 Tip de dată [NULL / NOT NULL],
Coloana2 Tip de dată [NULL / NOT NULL],
...
);
ALTER TABLE
Instrucţiunea ALTER TABLE este folosită pentru actualizarea schemei

unui tabel (adăugare şi ştergere de coloane). Sintaxa este următoarea:
- adăugarea unei coloane (exemplu):

ADD Furnizor Text(50);
- ştergerea unei coloane (exemplu):

DROP COLUMN Furnizor;
DROP TABLE
238
Baze de date Anexe
Instrucţiunea DROP TABLE este folosită pentru eliminarea unui tabel din
baza de date. Sintaxa este următoarea(exemplu, ştergerea tabelului
tblProduse):
DROP TABLE tblProduse;
CREATE VIEW
Instrucţiunea CREATE VIEW este folosită pentru crearea unei vederi noi a
unuia sau mai multor tabele. Sintaxa este următoarea:
CREATE VIEW NumeVedere AS
SELECT Coloana1, Coloana2, …
FROM Tabel1, Tabel2, ...
[WHERE ...]
[GROUP BY ...]
[HAVING ...] ;
Bibliografie
[1] Mocian Ioan, Baze de date – Terminologie, Proiectare, SQL, Access,

Editura MATRIX ROM, 2007.
[2] Michael J. Hernandez, Proiectarea bazelor de date, traducere din limba

engleză, Editura Teora, 2003.
[3] Susan Sales Harkins, Ken Hensen, Tom Gerhart, Utilizare Microsoft Access
2000, traducere din limba engleză, Editura Teora, 2000.
[4 Năstase Pavel, s.a., Baze de date Microsoft Access 2000, Editura Teora,
2004.
[5] Ben Forta, SQL pentru începători, traducere din limba engleză,
Editura Teora, 2002.
239

Baze de Date - Access - Curs Mocian Ioan

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Baze de Date - Access - Curs Mocian Ioan

Uploaded by

Copyright:

Available Formats

Ioan Mocian

Pentru a înţelege şi utiliza bazele de date nu trebuie să fii informatician, trebuie să

Cartea e structurată pe 5 capitole într-o cronologie logică, de la explicarea

Capitolul 1 este axat pe prezentarea domeniului bazelor de date relaţionale unde

Capitolul 2 se ocupă cu prezentarea termenilor şi conceptelor folosite în bazele

Capitolul 3 este consacrat iniţierii în proiectarea bazelor de date relaţionale,

Capitolul 4 este dedicat iniţierii în limbajul SQL, un limbaj apropiat de limbajul

Capitolul 5 este dedicat iniţierii în sistemul de gestiune a bazelor de date

Tot aici sunt prezentate modalităţile de transpunere a rapoartelor în format HTML

Lucrarea se adresează studenţilor facultăţilor de inginerie, dar este utilă şi

După ce aţi parcurs acest curs, trebuie să dobândiţi capacitatea:

Dacă această carte a reuşit să vă îmbogăţească bagajul de cunoştinţe

Tg. Mureş, 2008

Cuvânt înainte ............................................................................................... 3

Noţiuni de bază despre bazele de date

Sintagma “bază de date” este folosită atât în viaţa de zi cu zi, în mijloacele de

Modelul de bază de date relaţională

O concepţie greşită, larg răspândită, este aceea că modelul relaţional şi-ar fi

O bază de date relaţională stochează datele în relaţii, pe care un utilizator le

Fig. 1.1. Exemplu de tabele corelate

SELECT Nume, Prenume, Telefon

Sistemele de gestiune a bazelor de date relaţionale

Un sistem de gestiune a bazelor de date relaţionale (SGBDR) este un program

Primele SGBDR-uri au fost concepute pentru sisteme de tip desktop. Acestea

Creatorul de baze de date foloseşte programul client-server SGBDR pentru a crea

Cele mai cunoscute SGBDR-uri sunt:

Microsoft Access este un SGBDR comercial de tip desktop, folosit pentru

Oracle este liderul mondial al pieţei SGBDR-urilor de tip client-server. Oracle

Dincolo de modelul relaţional

Programele SGBDR au fost acceptate pe scară largă fiind utilizate în aplicaţii de

Modelul orientat spre obiect încorporează toate caracteristicile unui limbaj de

Modelul relaţional obiect încă nu a fost definitivat, se mai lucrează la el,

Internetul exercită o mare influenţă asupra modului de utilizare a bazelor de date

Întrebări pentru autoevaluare

De unde vine termenul de bază de date relaţională?

Capitolul 2. Terminologia bazelor de date relaţionale

Iată câteva motive care justifică importanţa învăţării acestor termeni:

Există patru categorii de termeni de care o să ne ocupăm în acest capitol,

Valorile pe care le stocăm în bazele de date se numesc date. Acestea sunt

George Fodor 6582421 12/05/2004

La prima vedere, aceste date sunt lipsite de sens pentru că nu ne putem da

Informaţiile reprezintă date pe care le prelucrăm într-un mod care le

Datele se stochează, iar informaţiile se regăsesc.

Din păcate, există cărţi comerciale în care se confundă datele cu

O valoare nulă reprezintă o valoare care lipseşte sau care nu este

De menţionat faptul că în practică, apar multe cazuri când la completarea

Termeni referitori la structură

În conformitate cu modelul relaţional, datele dintr-o bază de date

StudentID Nume Prenume Sectia <<alte câmpuri>>

Fig. 2.3. O structură de tabel

Tabelele reprezintă structurile esenţiale dintr-o bază de date, iar fiecare

Datele dintr-o bază de date relaţională pot exista independent de modul în

Când subiectul unui tabel este un eveniment, înseamnă că tabelul

PacientID Data cons. Ora cons. Medic Tensiune <<alte câmpuri>>

Fig. 2.4. Tabel care reprezintă un eveniment

Tabelele pot fi, într-o altă clasificare, de două tipuri:

În figura 2.5 este prezentat un tabel de validare pentru secţiile facultăţii de

Fiecare câmp dintr-o bază de date corect proiectată conţine singură

ProdusID Denumire Furnizor Pret Cant Valoare Loc, Judet Agent

Fig. 2.6. Tabel cu câmpuri normale, calculate, multiple

O înregistrare reprezintă o instanţă unică a subiectului unui tabel.

În figura 2.6, fiecare înregistrare reprezintă un produs unic din cadrul

Înregistrările reprezintă un element cheie pentru înţelegerea relaţiilor dintre