Baze de Date - Access - Curs Mocian Ioan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RETRIBUTII.
Angajati Retributii
Nume tabel Nume tabel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rezultatul se vede în figura 3.28.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

instrucţiune SELECT sunt realmente coloane din tabele şi care sunt
câmpuri calculate. Din perspectiva unui client, datele unui câmp calculat
sunt returnate în acelaşi mod ca şi datele din oricare coloană.

Limbă

Baze de Date - Access - Curs Mocian Ioan

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Baze de Date - Access - Curs Mocian Ioan

Încărcat de

Drepturi de autor:

Formate disponibile

Ioan Mocian

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

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

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

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

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

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

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

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

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

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

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

Tg. Mureş, 2008

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

Noţiuni de bază despre bazele de date

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

Modelul de bază de date relaţională

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

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

Fig. 1.1. Exemplu de tabele corelate

SELECT Nume, Prenume, Telefon

Sistemele de gestiune a bazelor de date relaţionale

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

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

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

Cele mai cunoscute SGBDR-uri sunt:

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

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

Dincolo de modelul relaţional

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

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

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

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

Întrebări pentru autoevaluare

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

Capitolul 2. Terminologia bazelor de date relaţionale

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

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

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

George Fodor 6582421 12/05/2004

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

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

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

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

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

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

Termeni referitori la structură

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

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

Fig. 2.3. O structură de tabel

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

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

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

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

Fig. 2.4. Tabel care reprezintă un eveniment

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

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

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

ProdusID Denumire Furnizor Pret Cant Valoare Loc, Judet Agent

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

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

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