Sunteți pe pagina 1din 239

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
Întrebări pentru autoevaluare ................................................................ 46
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
Întrebări pentru autoevaluare ................................................................ 56
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
Baze de date Capitolul 1
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
Baze de date Capitolul 1

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
Baze de date Capitolul 1
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
Baze de date Capitolul 1
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
Baze de date Capitolul 1
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
Baze de date Capitolul 2

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
Baze de date Capitolul 2
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
Baze de date Capitolul 2
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
Baze de date Capitolul 2
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
Baze de date Capitolul 2
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
Baze de date Capitolul 2
Î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
Baze de date Capitolul 2

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
Baze de date Capitolul 2

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
Baze de date Capitolul 2

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
Baze de date Capitolul 2
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
Baze de date Capitolul 2

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
Baze de date Capitolul 2
î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
Baze de date Capitolul 2

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
Baze de date Capitolul 2
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
Baze de date Capitolul 2

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
Baze de date Capitolul 2
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
Baze de date Capitolul 2
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 ........
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
Baze de date Capitolul 2

Studenti

StudID Nume Prenume OrasStudent <<alte câmpuri>>


6001 Studenti
Pop Remus Reghin ........
6002 Szabo Zoltan Oradea ........
6003 Costea Florian Zalau ........
6004 Timocea Sebastian Brasov ........
6004 Mocean Vasile Fagaras ........

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
Baze de date Capitolul 2
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
Baze de date Capitolul 2
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
Baze de date Capitolul 2
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.

Întrebări pentru autoevaluare


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
Baze de date Capitolul 2
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
Baze de date Capitolul 3

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
Baze de date Capitolul 3

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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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).

Întrebări pentru autoevaluare


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
Baze de date Capitolul 3

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
Baze de date Capitolul 3
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.

Întrebări pentru autoevaluare


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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
 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
Baze de date Capitolul 3
 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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
Î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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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.

Întrebări pentru autoevaluare

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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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.

Specificaţii de câmp

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
Baze de date Capitolul 3
 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
Baze de date Capitolul 3
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
Baze de date Capitolul 3

Specificaţii de câmp
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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.

Întrebări pentru autoevaluare


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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3

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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3

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


Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3

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
Baze de date Capitolul 3
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
StudID 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 .....

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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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 Cursuri Indemnizatie Catedra Sali Personal Studenti
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
Baze de date Capitolul 3
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 Cursuri Indemnizatie Catedra Sali Personal Studenti


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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
 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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
î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
Baze de date Capitolul 3

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
Baze de date Capitolul 3

Această linie simbolizează tipul de participare


Obligatorie pentru acest tabel
Clienti
Angajati
ClientID ChP
AngajatID ChP AngajatID ChE
............

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
Baze de date Capitolul 3
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
AngajatID ChP AngajatID ChE
............

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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3

Fig. 3.36. Formular pentru o regulă de


desfăşurare a activităţii
94
Baze de date Capitolul 3
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
Baze de date Capitolul 3

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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
 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
Baze de date Capitolul 3

100
Fig. 3.38. Formular pentru vedere
Baze de date Capitolul 3
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
Baze de date Capitolul 3

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
Baze de date Capitolul 3

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
Baze de date Capitolul 3
 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
desfăşurare a activităţii.

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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
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
Baze de date Capitolul 3
Î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
Denumire Character(250) Not Null
DomeniuID ChE Long Integer Not Null
AnAparitie Integer
Pagini Integer
Valoare Single
Stoc Integer
tblDomenii DomeniuID ChP AutoNumber Not Null
Denumire Character(50) 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
Denumire Character(75) Not Null
Abreviere Character(2) Not Null
tblProfesii ProfesiaID ChP AutoNumber Not Null
Denumire Character(75) Not Null
Explicatii Character(200)

107
Baze de date Capitolul 3
Î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
Baze de date Capitolul 3

Fig. 3.40. Foaia de specificaţie


109 pentru câmpul DataN
Baze de date Capitolul 3

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
Baze de date Capitolul 3
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
desfăşurare a activităţii.

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
Baze de date Capitolul 3

Fig. 3.42. Regulă de desfăşurare a activităţii specifică unui câmp

112
Baze de date Capitolul 3

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
desfăşurare a activităţii.

Î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
Baze de date Capitolul 3

Fig. 3.43. Regulă de desfăşurare a activităţii specifică unei relaţii

114
Baze de date Capitolul 3

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
Baze de date Capitolul 3

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
Baze de date Capitolul 3

Fig. 3.45. Foaie de specificaţii117


pentru vederea ”Lista cititorilor bibliotecii”
Baze de date Capitolul 3

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
Baze de date Capitolul 3
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
Baze de date Capitolul 4

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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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:
SELECT Nume, Prenume
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
Baze de date Capitolul 4
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:
SELECT Nume, Prenume
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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.

StudID Nume Init Prenume Sectia An Grupa Stare


1 Bogdan P. Mircea Florin IEI 1 1311 Bugetar
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
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 Cozma I. Calin Florin MEC 4 1241 Taxa

Fig. 4.2. Tabel cu studenţi

126
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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:
SELECT Nume, Prenume,Sectia, Grupa, Stare
FROM tblStudenti
WHERE Nume IN (“Pop”, “Cozma”);

Rezultat:
Nume Prenume Sectia Grupa Stare
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
Baze de date Capitolul 4
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:
SELECT Nume, Prenume,Sectia, Grupa, Stare
FROM tblStudenti
WHERE NOT Stare=”Bugetar”;

Rezultat:
Nume Prenume Sectia Grupa Stare
Meruta Cosmin IEI 1312 Taxa
Pop Laura IEI 1331 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
Baze de date Capitolul 4

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.

StudID Nume Init Prenume Sectia An Grupa Stare


1 Bogdan P. Mircea Florin IEI 1 1311 Bugetar
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
6 Cotirla L. Raluca Adina TCM 1 1111 Bugetar
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
Baze de date Capitolul 4
Ne propunem să filtrăm toate înregistrările în care numele studenţilor, din
tabelul din figura 4.3, începe cu „Pop”.

Expresie SQL:
SELECT Nume, Prenume,Sectia, Grupa, Stare
FROM tblStudenti
WHERE Nume LIKE ”Pop*”
ORDER BY Nume;

Rezultat:
Nume Prenume Sectia Grupa Stare
Pop Laura IEI 1331 Taxa
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4

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
Baze de date Capitolul 4
 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
Baze de date Capitolul 4
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
Baze de date Capitolul 4

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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4

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
Baze de date Capitolul 4
 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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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:
SELECT NumeVinzator, DenumireProdus, PretProdus
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
Baze de date Capitolul 4
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:
SELECT NumeVinzator, DenumireProdus, PretProdus
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
Baze de date Capitolul 4

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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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:
SELECT NumeCumparator, JudCump, PersContact, Email
FROM tblCumparatori
WHERE NumeCumparator= 'ANCONA SA';

Rezultat:
NumeCumparator JudCump PersContact Email
ANCONA SA MS Palade Sorin sorin@ancona.ro
ANCONA SA CJ Crisan Ovidiu covi@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
SELECT NumeCumparator, JudCump, PersContact, Email
FROM tblCumparatori
WHERE NumeCumparator= 'ANCONA SA';

153
Baze de date Capitolul 4
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
ANCONA SA MS Palade Sorin sorin@ancona.ro

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:
NumeCumparator JudCump PersContact Email
ANCONA SA CJ Crisan Ovidiu covi@ancona.ro
ANCONA SA CJ Crisan Ovidiu covi@ancona.ro
ANCONA SA MS Palade Sorin sorin@ancona.ro
COMPACT SRL BV Pietroi Sorina sorina@yahoo.ro
ROMBAT SA BN Pop Petru ppop@rmbat.ro

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
Baze de date Capitolul 4
 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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
 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’
WHERE ClientID = ’1000245’;

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
Baze de date Capitolul 4
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
WHERE ClientID = ’1000245’;

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


WHERE ClientID = ’1000378’;

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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
 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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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:
ALTER TABLE tblProduse
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 4
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
 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
Baze de date Capitolul 5
 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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

Î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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
Î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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
Î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
Baze de date Capitolul 5
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
vede în figura 5.14.

183
Baze de date Capitolul 5

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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
Î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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
 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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
 Î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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
 Î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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5

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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
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.

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.35. Diagrama bazei de date

203
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5

tblFacturi tblDetaliiFacturi
FacturaID ChP FacturaID ChE tblProduse
NrFactura ProdusID ChE ProdusID ChP
Data Cantitate Denumire
FurnizorID ChE Observatii UM
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
vede în figura 5.44.

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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
Î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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
 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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5

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
Baze de date Capitolul 5

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
vede în figura 5.64.

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
Baze de date Capitolul 5
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
Baze de date Capitolul 5

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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
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
Baze de date Capitolul 5
î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):


ALTER TABLE tblProduse
ADD Furnizor Text(50);

- ştergerea unei coloane (exemplu):


ALTER TABLE tblProduse
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