Limbile
Pagini
Legal
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
3
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.
4
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
5
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
6
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
7
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
8
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
9
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
10
Pagină goală
Baze de date Capitolul 1
11
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
Baze de date Capitolul 1
12
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.
Baze de date Capitolul 1
13
tblSectii
SectiaID Denumire Facultate
1 TCM Inginerie
2 IEI Inginerie
3 Informatica Stiinte
4 Istorie Stiinte
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
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.
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
Fig. 1.2. Exemplu de instrucţiune de interogare SQL
Baze de date Capitolul 1
14
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.
Baze de date Capitolul 1
15
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ă.
Baze de date Capitolul 1
16
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?
Baze de date Capitolul 2
17
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.
Baze de date Capitolul 2
18
Total plată: 57.50
Total plată:
57.50
Total plată:
57.50
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.
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. Informaţiile sunt dinamice, în sensul că se modifică în
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.
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
EKG 27.50 Urina
Ultrasunete Glicemie
George Fodor 6582421 12/05/2004
57.50
George Fodor 6582421 12/05/2004
57.50
George Fodor 6582421 12/05/2004
57.50
George Fodor 6582421 12/05/2004
57.50
Fig. 2.1. Exemplu de date elementare
x
x
Fig. 2.2. Exemplu de date transformate în informaţii
Baze de date Capitolul 2
19
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
Baze de date Capitolul 2
20
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ă.
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.
StudentID Nume Prenume Sectia <<alte câmpuri>>
5001 Pop Mariana TCM
5002 Ban Ioan TCM
5012 Lazăr Ana IEI
5065 Ban Lucia IMPI
5032 Pop Dorin MEC
Câmpuri
Înregistrări
Baze de date Capitolul 2
21
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
12 Mecatronica
15 Ingineria mediului
19 Design
Fig. 2.5. Tabel de validare
Fig. 2.5. Tabel de validare
Baze de date Capitolul 2
22
Î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.
Baze de date Capitolul 2
23
Î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.
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
sov
Danciu
6034 Acumulat
or
SC
Rulment
ul
500 4 2000 Bistrita,
Bistrita
Danciu
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
Câmp calculat
Câmp multiplu
Valori multiple
Baze de date Capitolul 2
24
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.
Baze de date Capitolul 2
25
Studenti
Imprumuturi
Carti
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.
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 …..
StudentID CarteID Data
60001 1001 3/10/2004
60002 1001 3/10/2004
60003 1099 5/10/2004
60004 1099 5/11/2004
CarteID Denumire Categorie <<alte câmpuri>>
1001 PUC P1 ......
1099 Baze de date P1 ......
1023 Fizica F1 .....
1009 Chimie F1 …..
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
Situatie împrumuturi (vedere)
Fig. 2.7. Un exemplu de vedere caracteristică
Baze de date Capitolul 2
26
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ă.
Baze de date Capitolul 2
27
Impresari
Cheie primară
Sportivi
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
ImpresarID Nume Prenume Telefon
100 Becali Ioan 0745-655482
101 Popescu Gică 0745-658312
102 Becali Victor 0744-547212
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 primară
Baze de date Capitolul 2
28
î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.
Baze de date Capitolul 2
29
Studenti
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ă.
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 ........
CursID Denumire Credite ProfesorID
C001 PUC 5 25461
C213 Baze de date 5 25461
C032 SIM 4 56821
C015 GD 5 12843
G001 AutoCAD 4 32584
G004 Inventor 5 3212
G007 Intellicad 4 25461
StudID CursID
6001 C001
6002 C213
6002 C001
6001 C213
6002 C015
6003 C001
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ă
Orar student(table de legătură) Cursuri
Baze de date Capitolul 2
30
Salariaţi
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.
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 …..
SalariatID Salar orar Sporuri <<alte câmpuri>>
100 34.50 10% …..
101 23.00 5% …..
102 17.45 20% …..
103 16.00 18% …..
Salariu
Baze de date Capitolul 2
31
Fig. 2.11. Exemplu de relaţie „unu cu mai mulţi”
Imprumuturi
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ă.
ClientID Nume Prenume <alte câmp.>
9001 Pop Dorin .......
9002 Ban Ion .......
9003 Lazăr Ana .......
9004 Buzan Maria .......
9005 Beldean Vian .......
ClientID CarteID Data
9002 5648 ....
9001 690423 ....
9004 6563 ....
9003 65323 ....
9003 09542 ....
9003 64823 ....
9002 75001 ....
9005 10045 ....
9005 76100 ....
Clienti
Baze de date Capitolul 2
32
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.
Baze de date Capitolul 2
33
Cursuri
Studenti
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.
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 ........
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ă
Baze de date Capitolul 2
34
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.
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 ........
StudID CursID
6001 C001
6002 C213
6002 C001
6001 C213
6002 C015
6003 C001
6003 C213
6001 C015
6003 G001
6001 G001
CursID Denumire Credite ProfID
C001 PUC 5 25461
C213 Baze de date 5 25461
C032 SIM 4 56821
C015 GD 5 12843
G001 AutoCAD 4 32584
G004 Inventor 5 3212
G007 Intellicad 4 25461
Fig.2.13. Rezolvarea unei relaţii de tip mai mulţi cu mai mulţi
cu ajutorul unui tabel de legătură
Studenti
Orar
Studenti
Cursuri
Baze de date Capitolul 2
35
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)
Baze de date Capitolul 2
36
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
Baze de date Capitolul 2
37
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ă?
Baze de date Capitolul 2
38
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?
Baze de date Capitolul 3
39
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.
Baze de date Capitolul 3
40
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.
Baze de date Capitolul 3
41
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.
Baze de date Capitolul 3
42
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:
Baze de date Capitolul 3
43
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?
Baze de date Capitolul 3
44
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
Baze de date Capitolul 3
45
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?
Baze de date Capitolul 3
46
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:
Baze de date Capitolul 3
47
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.
Baze de date Capitolul 3
48
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:
Baze de date Capitolul 3
49
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
Baze de date Capitolul 3
50
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).
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
Studenti
Nume
Prenume
Data nasterii
.........
Discipline
Denumire
Credite
Profesor
........
Profesori
Nume
Prenume
Grad didactic
........
. . . . .
Fig. 3.1. Crearea unei foi pentru scrierea structurilor de tabel
Baze de date Capitolul 3
51
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.
Baze de date Capitolul 3
52
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
Baze de date Capitolul 3
53
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.
Baze de date Capitolul 3
54
Î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
Baze de date Capitolul 3
55
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
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
schimb
Nume piesa
schimb
Model Producator Pret cu amanuntul
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.2. Tabel fără cheie candidată
Fig. 3.3. Tabel cu cheie candidată artificială
Baze de date Capitolul 3
56
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
Î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ă?
Fig. 3.4. Exemple de chei artificiale
Baze de date Capitolul 3
57
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
Baze de date Capitolul 3
58
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.
Baze de date Capitolul 3
59
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.
Baze de date Capitolul 3
60
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.
Baze de date Capitolul 3
61
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:
□ Litere(A-Z) □ De pe tastatura (., /, $, #, %)
□ Cifre (0-9) □ Speciale (©, ®, ™, ∞)
Lungime : 2
Numar de cifre zecimale:
Masca de introducere: AA
Format de afisare: Ambele litere trebuie sa fie majuscule.
Elemente logice
Tip cheie: □ Non-Cheie □ Primară
□ Externă □ Alternativă
Reguli de editare:
□ Se introduce imediat, se
permite editarea
□ Se introduce imediat, nu se
permite editarea
□ Se introduce ulterior, se
permite editarea
□ Se introduce ulterior, nu se
permite editarea
□ Reguli nedeterminate în acest
moment
Structură cheie: □ Simplă □ Compusă
Unicitate: □ Non-unică □ Unică
Suport valori nule: □ □
Valori introduse de: □ Utilizator □ Sistem
Valoare obligatore: □ Nu □ Da
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
Nu se acceptă
valori nule
Fig. 3.5. Formular Specificaţie câmp
Se acceptă
valori nule
Nu se acceptă
valori nule
Baze de date Capitolul 3
62
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
element
Explicaţii
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
Baze de date Capitolul 3
63
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
Baze de date Capitolul 3
64
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
caractere
Acest element indică tipul de caractere pe care un utilizator le
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-
Baze de date Capitolul 3
65
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
prestabilită
Aceasta este valoare pe care utilizatorul o poate introduce într-un
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
permise
Acest element indică tipurile de comparaţii pe care utilizatorul le
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
Baze de date Capitolul 3
66
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.
Baze de date Capitolul 3
67
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”
Baze de date Capitolul 3
68
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.
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 …..
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”.
SalariatID Salar orar Sporuri <<alte câmpuri>>
100 34.50 10% …..
101 23.00 5% …..
102 17.45 20% …..
103 16.00 18% …..
Retributii
Angajati
Baze de date Capitolul 3
69
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”.
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”.
În figura 3.9 este prezentată diagrama relaţiei dintre tabelele ANGAJATI şi
RETRIBUTII.
Tabel A Tabel B
Tabel normal Tabel subset
Această linie arată că o înregistrare din
TABELUL B este corelată cu o singură
înregistrare din TABELUL A
Această linie arată că o
înregistrare din TABELUL B
este corelată cu o singură
înregistrare din TABELUL
A
Această linie arată că o înregistrare din
TABELUL A este corelată cu o singură
înregistrare din TABELUL B
Retributii
Nume tabel
Angajati
Nume tabel
Nume tabel
Fig. 3.9. Diagrama relaţiei dintre
tabelele SALARIATI şi SALARIU
Baze de date Capitolul 3
70
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.
Fig. 3.10. Exemplu generic de relaţie „unu cu mai mulţi”
Tabel A
Tabel A
Tabel B
Tabel B
Baze de date Capitolul 3
71
Fig. 3.11. Exemplu de relaţie „unu cu mai mulţi”
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. 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.
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”.
ClientID CarteID Data
9002 5648 ....
9001 690423 ....
9004 6563 ....
9003 65323 ....
9003 09542 ....
9003 64823 ....
9002 75001 ....
9005 10045 ....
9005 76100 ....
ClientID Nume Prenume <<alte câmp.>>
9001 Pop Dorin .......
9002 Ban Ion .......
9003 Lazăr Ana .......
9004 Buzan Maria .......
9005 Beldean Vian .......
Clienti
Baze de date Capitolul 3
72
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 tabelele CLIENTI şi ÎMPRUMUTURI din figura 3.11.
Reţineţi aceste notaţii pentru că le veţi folosi în prezentarea structurii
bazelor de date pe care le veţi proiecta.
Acest tip de relaţie cel mai reprezentativ dintre două tabele a unei baze de
date, este uşor de identificat şi de înţeles.
Fig. 3.12. Realizarea diagramei pentru
o relaţie „unu cu mai mulţi”
Tabel B
Nume tabel
Nume
tabel(B)
Nume tabel
Tabel A
Nume tabel
Nume tabel
Nume tabel
Nume
tabel(A)
Această „labă de gâscă” arată că o
înregistrare din TABELUL A este corelată
cu mai multe înregistrări din TABELUL B
Această linie arată că o
înregistrare din TABELUL A
Această linie arată că o înregistrare din
TABELUL B este corelată cu o singură
înregistrare din TABELUL A
Această linie arată că o
înregistrare din TABELUL B
este corelată cu o singură
înregistrare din TABELUL A
Fig. 3.13. Diagrama relaţiei dintre tabelele Clienti şi Imprumuturi
Imprumuturi
Nume tabel
Clienti
Nume tabel
Nume tabel
Nume tabel
Imprumuturi
Baze de date Capitolul 3
73
Tabel A
Tabel A
Tabel A
Tabel A
Tabel A
Tabel A
Tabel B
Tabel B
Tabel B
Tabel B
Tabel B
Tabel B
Tabel A
Tabel A
Tabel A
Tabel A
Tabel A
Tabel A
Tabel A
Tabel B
Tabel B
Tabel B
Tabel B
Tabel B
Tabel B
Tabel B
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.
Acest tip de relaţie este al doilea ca frecvenţă de apariţie î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.
Figura 3.15 prezintă un exemplu tipic de relaţie “mai mulţi cu mai mulţi”
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.
Fig. 3.14. O relaţie „mai mulţi cu mai mulţi” din perspectiva ambelor tabele
Baze de date Capitolul 3
74
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 . . . . .
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.
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 . . . . .
Studenti
Fig. 3.15. Exemplu tipic de relaţie „mai mulţi cu mai mulţi”
Baze de date Capitolul 3
75
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.
Tabel A Tabel B
Această „labă de gâscă” arată că o
înregistrare din TABELUL B este corelată cu
mai multe înregistrări din TABELUL A
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
Baze de date Capitolul 3
76
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.
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 . . . . .
StudID CursID
6001 C001
6002 C213
6002 C032
6001 C213
6002 C015
6003 C001
6004 C213
6001 C015
6003 G001
6001 G004
6005 G007
CursID Denumire Credite ProfID
C001 PUC 5 2001
C213 SIM 5 2001
C032 Baze de date 4 2045
C015 GD 5 2014
G001 AutoCAD 4 2009
G004 Inventor 5 2006
G007 IntelliCAD 5 2032
Fig.3.18. Rezolvarea unei relaţii de tip mai mulţi cu mai
mulţi cu ajutorul unui tabel de legătură
Cursuri
Orar(tabel de legătură)
Studenti
Baze de date Capitolul 3
77
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.
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
Fig. 3.19. Diagrama de relaţie a
problemei rezolvate
Studenti Orar Cursuri
StudentID
Nume
Prenume
OrasStudent
- - - - - - - -
StudentID
CursID CursID
Denumire
Credite
ProfesorID
Sala
- - - - - - - -
Baze de date Capitolul 3
78
joacă rolul de sponsor. Observaţi că Mocean Pavel sponsorizează pe
Obădău Anica.
Diagrama unei astfel de relaţii se poate vedea în figura 3.21.
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.
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 - - - - - -
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 - - - - - -
Membrii
Fig. 3.20. Relaţie cu autoreferire „unu cu unu”
Membrii
Această linie laterală a tabelului
arată natura de auto-referiere a
relaţiei şi tipul relaţiei.
Fig. 3.21. Diagrama unei relaţii cu
auto-referire „unu cu unu”
Fig. 3.22. Relaţie cu autoreferire „unu cu mai mulţi”
Personal
Baze de date Capitolul 3
79
Figura 3.23 arată diagrama acestei relaţii.
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.
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
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 . . . . .
Personal
Fig. 3.23. Diagrama
relaţiei cu auto-referire
„unu cu mai mulţi”
Piese
Fig. 3.24. Exemplu de relaţie cu autoreferire „mai mulţi
cu mai mulţi”
Baze de date Capitolul 3
80
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.
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
Piese
Fig. 3.25. Diagrama unei
relaţii cu autoreferire „mai
mulţi cu mai mulţi”
Baze de date Capitolul 3
81
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.
Baze de date Capitolul 3
82
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.
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
Cladiri Cursuri Indemnizatie Catedra Sali Personal Studenti
Cladiri 1:M 1:M
Cursuri 1:1 1:M 1:1
Indemnizatie
Catedra
Sali
Personal
Studenti
Baze de date Capitolul 3
83
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.
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
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
Baze de date Capitolul 3
84
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.
Î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
Personal
AngajatID ChP
Nume
Prenume
Data nasterii
Data angajarii
Specializare
Adresa
Telefon acasa
Mobil
Web
Salariu
Indemnizatie
Asigurare
Tip plan medical
Personal-1
AngajatID ChP
Nume
Prenume
Data nasterii
Data angajarii
Specializare
Adresa
Telefon acasa
Mobil
Web
Personal-2
AngajatID ChE
Salariu
Indemnizatie
Asigurare
Tip plan medical
Fig. 3.29. Exemplu de creare a unei relaţii unu cu unu
Baze de date Capitolul 3
85
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.
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.
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:
Cladiri Sali
CladireID ChP
Numar etaje
Acces lift
Acces parcare
SalaID ChP
Tip sala
Nr locuri
Acces Intrenet
Fig. 3.30. Relaţia de tip „unu cu mai mulţi” existentă între
tabelele CLADIRI şi SALI
Cladiri
CladireID ChP
Numar etaje
Acces lift
Acces parcare
Sali
SalaID ChP
CladireID ChE
Tip sala
Nr locuri
Acces Intrenet
Fig. 3.31. Stabilirea relaţiei „unu cu mai mulţi”
între tabelele CLADIRI şi SALI
Baze de date Capitolul 3
86
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ă.)
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.
Studenti Cursuri
Cursuri Student StudentID ChP
Nume
Prenume
Data nasterii
Adresa
Telefon
CursID ChP
Denumire
Credite
ProfesorID
Categorie
StudentID ChPC/ChE
CursID ChPC/ChE
Fig. 3.32. Stabilirea unei relaţii „mai mulţi cu mai mulţi”
între tabelele STUDENTI şi CURSURI
Baze de date Capitolul 3
87
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
Baze de date Capitolul 3
88
î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.
Baze de date Capitolul 3
89
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ă).
Angajati Clienti
AngajatID ChP
............
ClientID ChP
AngajatID ChE
Fig. 3.33. Ce tip de participare trebuie
atribuit fiecărui tabel?
Baze de date Capitolul 3
90
Această linie simbolizează tipul de participare
Obligatorie pentru acest tabel
Acest cerc simbolizează tipul de participare
Opţională pentru acest tabel
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.
Angajati
AngajatID ChP
............
ClientID ChP
AngajatID ChE
Clienti
Fig. 3.34. Precizarea tipului de participare pentru tabelele
ANGAJATI şi CLIENTI
Baze de date Capitolul 3
91
(1,1) (0,10)
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.
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.
AngajatID ChP
............
Clienti Angajati
ClientID ChP
AngajatID ChE
Aceasta indică numărul minim şi
numărul maxim de angajaţi cu
care poate fi asociat un client
Aceasta indică numărul minim şi numărul
maxim de clienţi cu care poate fi asociat
un angajat
Fig. 3.35. Indicarea gradului de participare
pentru tabelele ANGAJATI şi CLIENTI
Baze de date Capitolul 3
92
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.)
Baze de date Capitolul 3
93
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.
Baze de date Capitolul 3
94
Fig. 3.36. Formular pentru o regulă de
desfăşurare a activităţii
Baze de date Capitolul 3
95
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.
Baze de date Capitolul 3
96
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.”
Baze de date Capitolul 3
97
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
... ... ...
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
Fig. 3.37. Tabel de validare
Baze de date Capitolul 3
98
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.
Baze de date Capitolul 3
99
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.
Baze de date Capitolul 3
100
Fig. 3.38. Formular pentru vedere
Baze de date Capitolul 3
101
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.
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ă.
tblStudenti tblSectii
Fig. 3.39. Diagramă de vedere
StudentID
Nume
Prenume
SectiaID
Telefon
………
SectiaID
Sectia
……..
Lista studenti
Student
Sectia
Telefon
Baze de date Capitolul 3
102
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.
Baze de date Capitolul 3
103
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:
Baze de date Capitolul 3
104
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.
Baze de date Capitolul 3
105
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.
Baze de date Capitolul 3
106
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
Baze de date Capitolul 3
107
Î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)
Baze de date Capitolul 3
108
Î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.
Baze de date Capitolul 3
109
Fig. 3.40. Foaia de specificaţie pentru câmpul DataN
Baze de date Capitolul 3
110
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).
Observaţi că relaţia 1:N, partea ”mai mulţi”, este aici notată cu simbolul
”infinit”.
Fig. 3.41. Diagrama de relaţii a bazei de date ”Biblioteca”
Baze de date Capitolul 3
111
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.
Baze de date Capitolul 3
112
Fig. 3.42. Regulă de desfăşurare a activităţii specifică unui câmp
Baze de date Capitolul 3
113
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.
Baze de date Capitolul 3
114
Fig. 3.43. Regulă de desfăşurare a activităţii specifică unei relaţii
Baze de date Capitolul 3
115
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.
Fig. 3.44. Diagrama de vedere ”Lista cititorilor
bibliotecii”
tblJudete
JudetID
Denumire
Abreviere
tblProfesii
ProfesiaID
Denumirea
Explicatii
Lista cititori
Cititor
Profesia
Adresa
tblCititori
CititorID
Nume
Prenume
ProfesiaID
……..
JudetID
Baze de date Capitolul 3
116
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.
Baze de date Capitolul 3
117
Fig. 3.45. Foaie de specificaţii pentru vederea ”Lista cititorilor bibliotecii”
Baze de date Capitolul 3
118
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
Baze de date Capitolul 3
119
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).
Baze de date Capitolul 4
120
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.
Baze de date Capitolul 4
121
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.
Baze de date Capitolul 4
122
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.
Fig. 4.1. Tabelul tblStudenti simplificat
Expresie SQL:
SELECT Nume, Prenume
FROM tblStudenti;
Rezultat:
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
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
Baze de date Capitolul 4
123
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
Baze de date Capitolul 4
124
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.
Baze de date Capitolul 4
125
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.
Baze de date Capitolul 4
126
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.
Fig. 4.2. Tabel cu studenţi
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
Baze de date Capitolul 4
127
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
Baze de date Capitolul 4
128
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
Baze de date Capitolul 4
129
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.
Baze de date Capitolul 4
130
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.
Fig. 4.3. Tabel cu studenţi
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
Baze de date Capitolul 4
131
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.
Baze de date Capitolul 4
132
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.
Baze de date Capitolul 4
133
Expresie SQL:
SELECT Nume + “ “ + Init + “ “ + Prenume AS Student, Sectia, An, Grupa, Stare
FROM tblStudenti
ORDER BY Nume;
Rezultat:
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.
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
Baze de date Capitolul 4
134
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).
Baze de date Capitolul 4
135
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.
Baze de date Capitolul 4
136
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.
Baze de date Capitolul 4
137
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.
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;
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
Baze de date Capitolul 4
138
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.
Baze de date Capitolul 4
139
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.
Baze de date Capitolul 4
140
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
Baze de date Capitolul 4
141
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.
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.
tblComenzi
Nr_comanda ChP
DataCom
CumparatorID ChE
CumparatorID ChP
NumeCump
Oras
tblCumparatori
DetComID ChP
Nr_comanda ChE
ArticolID ChE
PretArt
Cantitate
tblDetaliiCom
Fig. 4.6. Diagrama de relaţii
Baze de date Capitolul 4
142
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
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
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.
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 . . . . . .
tblComenzi
tblDetaliiCom
tblCumparatori
Fig. 4.7. Cele 3 tabele completate
Baze de date Capitolul 4
143
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
Baze de date Capitolul 4
144
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
Baze de date Capitolul 4
145
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
Baze de date Capitolul 4
146
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!
Baze de date Capitolul 4
147
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).
Unirea celor două tabele cu o expresie SQL va genera un nou tabel cu 6
înregistrări (3 x 2).
ProdusID VinzatorID DenumireProdus PretProdus
1001 V01 Piine 2.00
1002 V03 Banane 2.50
1003 V01 Biscuiti 1.25
VinzatorID NumeVinzator OrasVinzator <<alte cimpuri>>
V01 Ban Lucia Naoiu . . . . . .
V02 Pop Mariana Sarmasel . . . . . .
tblProduse
tblVinzatori
Fig. 4.8. Tabelele pentru unire
Baze de date Capitolul 4
148
Expresia SQL:
SELECT NumeVinzator, DenumireProdus, PretProdus
FROM tblVinzatori, tblProduse;
Rezultat:
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:
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.
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
NumeVinzator DenumireProdus PretProdus
Ban Lucia Piine 2.00
Ban Lucia Biscuiti 1.25
Baze de date Capitolul 4
149
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.
Baze de date Capitolul 4
150
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:
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
DetComID ComandaID ProdusID Cantitate
20010 10010 1001 10
20011 10010 1002 12
20012 10010 1078 8
20013 10010 1052 50
20014 10012 1008 16
VinzatorID NumeVinzator Oras <<alte cimpuri>>
V01 Ban Lucia Naoiu . . . . . .
V02 Pop Mariana Sarmasel . . . . . .
V03 Baciu Mia Naoiu . . . . . .
V04 Ban Ionel Roma . . . . . .
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
tblProduse
tblDetaliiComenzi
tblVinzatori
Fig. 4.9. Tabele implicate în unire
Baze de date Capitolul 4
151
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
Baze de date Capitolul 4
152
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 [email protected]
6002 AutoNET SRL MS Beldean Vian [email protected]
6004 SAVINA SRL MS Parauan Bicu [email protected]
6025 COMPACT SRL BV Pietroi Sorina [email protected]
6083 ANCONA SA MS Palade Sorin [email protected]
6084 ANCONA SA CJ Crisan Ovidiu [email protected]
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.
Fig. 4.10. Tabelul tblCumparatori
Baze de date Capitolul 4
153
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 [email protected]
COMPACT SRL BV Pietroi Sorina [email protected]
ANCONA SA CJ Crisan Ovidiu [email protected]
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:
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';
NumeCumparator JudCump PersContact Email
ANCONA SA MS Palade Sorin [email protected]
ANCONA SA CJ Crisan Ovidiu [email protected]
Baze de date Capitolul 4
154
Rezultat:
NumeCumparator JudCump PersContact Email
ROMBAT SA BN Pop Petru [email protected]
COMPACT SRL BV Pietroi Sorina [email protected]
ANCONA SA CJ Crisan Ovidiu [email protected]
ANCONA SA MS Palade Sorin [email protected]
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 [email protected]
ANCONA SA CJ Crisan Ovidiu [email protected]
ANCONA SA MS Palade Sorin [email protected]
COMPACT SRL BV Pietroi Sorina [email protected]
ROMBAT SA BN Pop Petru [email protected]
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.
Baze de date Capitolul 4
155
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.
Baze de date Capitolul 4
156
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.
Baze de date Capitolul 4
157
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:
Baze de date Capitolul 4
158
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 = ‘[email protected]’
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 ‘[email protected]’ 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 = ‘[email protected]’, 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.
Baze de date Capitolul 4
159
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.
Baze de date Capitolul 4
160
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.
Baze de date Capitolul 4
161
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.
Baze de date Capitolul 4
162
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
Baze de date Capitolul 4
163
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:
Baze de date Capitolul 4
164
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).
Baze de date Capitolul 4
165
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.
Baze de date Capitolul 4
166
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.
Baze de date Capitolul 4
167
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.
Baze de date Capitolul 5
168
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.
Baze de date Capitolul 5
169
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;
Baze de date Capitolul 5
170
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.
După cum se vede, o bază de date ACCESS poate fi definită ca o colecţie
de obiecte:
Tabele (tables)
Cereri de interogare (queries)
Fig. 5.1. Interfaţa de pornire Access (fereastra Database)
Baze de date Capitolul 5
171
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
Baze de date Capitolul 5
172
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
Baze de date Capitolul 5
173
Î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.
Baze de date Capitolul 5
174
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
Baze de date Capitolul 5
175
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.
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.3. Stabilirea
integrităţii
referenţiale
Fig. 5.4. Diagrama de relaţie
între cele 2 tabele, aşa cum
apare în ACCESS.
Baze de date Capitolul 5
176
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
Baze de date Capitolul 5
177
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.
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.
Fig. 5.6. Primul pas al
procedurii Lookup Wizard
Baze de date Capitolul 5
178
Î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.
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.7. Alegerea
câmpului de legătură
Fig. 5.8. Recomandarea
pentru a face invizibilă
cheia primară
Fig. 5.9. Avertizarea de
salvare a relaţiei create.
Baze de date Capitolul 5
179
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.
Baze de date Capitolul 5
180
Î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.
Baze de date Capitolul 5
181
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.
Baze de date Capitolul 5
182
Î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.
În urma acestei acţiuni va apare fereastra New Form, aşa cum se vede în
figura 5.11.
Fig. 5.10. Fereastra Database
Fig. 5.11. Fereastra
NewForm
Din acest comboBox se alege
tabelul asociat formularului
Baze de date Capitolul 5
183
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.
În fereastra următoare putem selecta modul cum vor apare datele în cadrul
formularului, aşa cum se vede în figura 5.13.
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.
Fig. 5.12. Alegerea
câmpurilor formularului
Fig. 5.13. Alegerea
formei de prezentare
Baze de date Capitolul 5
184
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.
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.14. Alegerea
fundalului formularului
Fig. 5.16. Forma finală a
formularului
Fig. 5.15. Alegerea
numelui formularului şi
încheierea operaţiunii
Baze de date Capitolul 5
185
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.
Baze de date Capitolul 5
186
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.
Bara de titlu
Toolbox – caseta
cu obiecte
Fig. 5.17. Forma iniţială a
formularului
Baze de date Capitolul 5
187
Î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.
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.
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
Proprietatea Record Source stabileşte
tabelul asociat formularului
Baze de date Capitolul 5
188
După ce activăm formularul cu butonul , acesta va arăta ca în figura
următoare, 5.19.
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.
Fig. 5.19. Formular obţinut
de la zero
Baze de date Capitolul 5
189
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
Baze de date Capitolul 5
190
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.
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
Fig. 5.20. Tabelele implicate în formular
tblFacturi
FacturaID ChP
NrFactura
Data FurnizorID ChE
tblDetaliiFacturi
FacturaID ChE
ProdusID ChE
Cantitate Observatii
tblFurnizori
FurnizorID ChP
Furnizor
CodFiscal ...........
tblProduse
ProdusID ChP
Denumire
UM Pret
..............
Baze de date Capitolul 5
191
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.
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:
Fig. 5.21. Tabelele
bazei de date
Baze de date Capitolul 5
192
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.
Î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
Fig. 5.22-1. Cele 2 interogări rezultate
Interogarea 1
Interogarea 2
Baze de date Capitolul 5
193
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.
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.
Fig. 5.22-2. Setarea
proprietăţilor pentru
subformular
Baze de date Capitolul 5
194
Când se activează formularul, adică se scoate din modul Design, acesta va
arăta ca în figura 5.24.
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ţă.
Fig. 5.23. Formularul cu
subformular, în modul Design
frmFacturi
frmDetaliiFacturi
Fig. 5.24.
Formularul nostru
în stare de
funcţionare
Butoane de navigare
Baze de date Capitolul 5
195
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:
Baze de date Capitolul 5
196
Î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.
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.
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,
Fig. 5.25. Fereastra
pentru scrierea
expresiilor SQL
Fig. 5. 26. Butonul Run SQL
Baze de date Capitolul 5
197
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
Din caseta New Query se se alege opţiunea Design View – OK.
Se obţine caseta din figura 5.28.
Fig. 5.27. Pasul 1 de
creare a unei interogări
Fig. 5.28. Grila de proiectare a interogărilor
Baze de date Capitolul 5
198
Î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ă
Baze de date Capitolul 5
199
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.
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.
Fig. 5.30. Rezultatul interogării
Baze de date Capitolul 5
200
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
Baze de date Capitolul 5
201
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.
Stabilirea tipului de legătură se face prin fereastra Join Properties, care se
deschide cu butonul Join Type (figura 5.33).
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.
Fig. 5.32. Fereastra Edit Relationships
Fig. 5.33. Fereastra Join Properties
Baze de date Capitolul 5
202
Î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ă.
Fig. 5.34. Alegerea câmpului Lookup Wizard
Baze de date Capitolul 5
203
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.
Fig. 5.35. Diagrama bazei de date
tblFacturi
FacturaID ChP
NrFactura
Data FurnizorID ChE
tblDetaliiFacturi
FacturaID ChE
ProdusID ChE
Cantitate Observatii
tblFurnizori
FurnizorID ChP
Furnizor
CodFiscal
...........
tblProduse
ProdusID ChP
Denumire
UM Pret
..............
Baze de date Capitolul 5
204
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.
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.
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:
Fig. 5.36. Grila de
proiectare
Fig. 5.37. Introducerea
parametrului interogării
Baze de date Capitolul 5
205
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.
Cele 2 cereri de parametri sunt arătate în figura 5.39.
Pornind de la aceste exemple, încercaţi să construiţi şi alte interogări cu
parametri pentru a acumula experienţă.
Fig. 5.38. Grila de
proiectare pentru un
interval de timp.
Fig. 5.39. Introducerea celor 2 parametri
Baze de date Capitolul 5
206
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.
Baze de date Capitolul 5
207
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.40. Diagrama bazei de
date
Fig. 5.41. Alegem
tabelul tblProduse şi
opţiunea Tabular
tblFacturi
FacturaID ChP
NrFactura
Data FurnizorID ChE
tblDetaliiFacturi
FacturaID ChE
ProdusID ChE
Cantitate Observatii
tblFurnizori
FurnizorID ChP Furnizor
CodFiscal
...........
tblProduse
ProdusID ChP
Denumire
UM Pret
..............
Baze de date Capitolul 5
208
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.
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.
Fig. 5.42. Partea de sus a raportului creat
Baze de date Capitolul 5
209
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.
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?
Fig. 5.43. Interogarea
folosită în raportul care
va fi creat
Baze de date Capitolul 5
210
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.
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.44. Primul ecran
al aplicaţiei Report
Wizard permite
selectarea câmpurilor
raportului
Fig. 5.45. Fereastra în care
configurăm nivelul de grupare
Baze de date Capitolul 5
211
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.
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.
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.
Fig. 5.46. Ecran pentru
modul de sortare
Fig. 5.47. Stabilirea
coloanelor pentru sume.
Baze de date Capitolul 5
212
8. În acest ecran aplicaţia ne cere să alegem un model de aranjare a datelor
în raport, figura 5.48.
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.
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.
Fig. 5.48. Aranjarea datelor în
pagină
Fig. 5.49. Alegerea modului
de prezentare a raportului
Baze de date Capitolul 5
213
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.
Î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.
Fig. 5.50. Alegerea
numelui şi terminarea
raportului.
Fig. 5.51. Raportul afişat
în modul Design.
Baze de date Capitolul 5
214
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.
Fig. 5.52. Forma finală a raportului
Baze de date Capitolul 5
215
Î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.
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.
Fig. 5.53. Afişarea în modul
Design a formularului
Baze de date Capitolul 5
216
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.
Baze de date Capitolul 5
217
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:
Baze de date Capitolul 5
218
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.
Fig. 5.54. Fereastra Macro Design
Coloana Macro Name Coloana Comment Coloana Condition Coloana Action
Zonă în care vor
fi afişate
argumentele
acţiunii curente.
Baze de date Capitolul 5
219
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.
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.
Fig. 5.55. Macromandă cu o singură
acţiune
Baze de date Capitolul 5
220
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
Fig. 5.56. Frereastra
Database cu 2 macro-uri
Baze de date Capitolul 5
221
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.
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.
Fig. 5.57. Grupuri
de acţiuni
Baze de date Capitolul 5
222
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.
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
Fig. 5.58. Caseta Run Macro
Baze de date Capitolul 5
223
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.
Baze de date Capitolul 5
224
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.
Î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.
Fig. 5.59. Exemplu de atribuire a unei
combinaţii de taste unei macrocomenzi
Baze de date Capitolul 5
225
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.
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.
Fig. 5.60. Caseta de dialog Startup
Baze de date Capitolul 5
226
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.
Baze de date Capitolul 5
227
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.
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.
Fig. 5.61. Crearea unei
pagini HTML statice Bifaţi această opţiune
pentru a exporta şi
capul de tabel
Fig.5.62. Pagina HTML obţinută,
afişată cu Internet Explorer
Baze de date Capitolul 5
228
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ă.
Baze de date Capitolul 5
229
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.
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:
Fig. 5.63. Pagină Web
dinamică obţinută cu
AutoPage
Fig. 5.64. Avertismentul legat
de conectarea la pagină
Baze de date Capitolul 5
230
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
Baze de date Capitolul 5
231
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.
Baze de date Capitolul 5
232
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
Baze de date Capitolul 5
233
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
Baze de date Capitolul 5
234
î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.
Baze de date Anexe
235
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
Baze de date Anexe
236
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.
Baze de date Anexe
237
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 ...];
Baze de date Anexe
238
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
Baze de date Anexe
239
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.