Universitatea Al.I.

Cuza Iasi
Facultatea de Economie si Administrarea AIacerilor
Contabilitate si InIormatic de Gestiune
InIormatic Economic
2007
2 Baze de date
INTRODUCERE
ncepnd cu anul universitar 2006-2007 si, implicit, prima promotie de bolognisti
1
,
disciplina Ba:e de date I a Iost introdus n al doilea an de studii si la specializarea
Contabilitate i Informatic de Gestiune. Probabil c multi si-au adus aminte de bancul cu
,asta ne mai trebuia acuma. Oricum, mpreun cu studentii de la specializarea Informatic
Economic, veterani n luptele de strad cu bazele de date, v puteti reuni, mcar periodic, sub
sigla ,SuIerint Ir Irontiere.
Poate suna paradoxal, dar nu avem de gnd s v tinem o pledoarie lacrimogen
despre importanta bazelor de date pentru contabilitate si tot ceea ce tine de un sistem
inIormational. O (mic) parte dintre dvs. poate va gsi ceva interesant n cele peste 150 de
pagini. Ceea ce dorim s v consiliem (initial voiam s scriem ,s v atragem atentia, dar
suna prea apstor) este c, pentru a rmne cu ceva Iixat din curs si, implicit, pentru a-l
promova, nu este att de important s lecturati cartea de Iat, ci mai ales s o ntelegeti si s
exersati.
Pentru a ne ncadra n limita procustian de pagini, am scos din manual rezumatele
capitolelor si tipurile de probleme de la examen. Acestea, mpreun cu diverse listinguri
(secvente de comenzi SQL), diagrame si alte materiale suplimentare sunt postate pe portal, la
sectiunea aIectat disciplinei. V ncurajm, de asemenea, s Iolositi grupul de discutii al
disciplinei petru a v exprima neclarittile (nedumeririle, consternrile etc.) n speranta unor
eventuale lmuriri (sau mcar intimidri ale proIesorilor).
ncheiem urndu-v un sincer ,s v Iie bazele de date usoare ! si, de asemenea,
propunem s ncepem materia cu un mic moment de reculegere pentru toate viitoarele
,victime ale cursului Ba:e de date I.

Noiembrie 2006

Echipa BD1: Marin Fotache, Ctlin Strmbei, Liviu Cretu, Octavian Dospinescu, Florin Srbu

1
Beneficiari ai prevederilor Conven[iei de la Bologna
FEAA nfoEc + CG - 2006/2007 3
4 Baze de date
CapitoIuI 1
DESPRE BAZE DE DATE


Obiective:
I. Argumentarea importan(ei bazelor de date pentru sistemele
informa(ionale actuale
II. Definirea bazelor de date, prin compara(ie cu organizarea datelor n
fiyiere independente
III. Prezentarea frugal a principalelor modele de structurare a datelor
n bazele de date




Rezultate ayteptate:
Nici unul

FEAA nfoEc + CG - 2006/2007 5
1.1 NEVOIA DE BAZE DE DATE

Dup cum discutam n cursul de Instrumente software pentru afaceri, Iolosim bazele de date
pentru c avem memoria prea scurt si stm prost cu calculele. Ca si n alte privinte, avem nevoie de
baze de date pentru c suntem niste limitati. Deoarece trim ntr-o lume asezat pe un morman de
hrtii & hrtoage, ne este cu neputint s reconstituim ceea ce am Icut adineori, darmite ieri,
sptmna trecut sau acum un an sau cinci. Necazul e c, de cele mai multe ori, trebuie s stim nu
numai ce-am Icut noi, dar ce-au Icut si colegii si partenerii de aIaceri.
SimpliIicnd si exagernd nepermis lucrurile, am putea spune c exist doi poli ntre care
poate Ii pozitionat orice problem inIormatic. Pe de o parte, cel al chestiunilor interesante, nu
neaprat cu Iormule si calcule complexe, care reclam un anumit grad de ingeniozitate n rezolvare -
mult invocata si asteptata "Iis". Cellalt pol regrupeaz probleme n care complexitatea calculelor
rareori depseste nivelul celor patru operatii aritmetice elementare - adunare, scdere si nc dou; n
schimb, volumul inIormatiilor si zecile/sutele moduri de regrupare si agregare a lor este deconcertant.
Fr a Iace concurent vreunui manual de IilosoIie, putem spune c, din pcate, ca si n viat,
ponderea problemelor din a doua categorie s le spunem plicticoase este mult mai mare dect
ponderea problemelor cu adevrat interesante. Aceasta ar Ii vestea proast. Vestea bun este c se
cstig enorm de multi bani din chestiunile plicticoase. O veste intermediar ar Ii c, n majoritate,
problemele pe care le are de rezolvat un inIormatician presupun elemente din ambele categorii. De
Iapt, cei doi poli de care vorbim au o existent virtual, Iiind utili mai degrab din ratiuni didactice &
pedagogice.
Cert este c, nc de la nceputurile sale, inIormatica a Iost conIruntat nu numai cu eIectuarea
de calcule soIisticate, stiintiIice, dar si cu stocarea si gestionarea unui volum de inIormatii din ce n ce
mai mare. AstIel nct aparitia unor instrumente soItware dedicate gestiunii si prelucrrii datelor a Iost
doar o problem de timp.
Prin urmare, avem nevoie de baze de date pentru a pstra, ntr-un Iormat utilizabil, date si
inIormatii legate de evenimente, tranzactii etc. si, la nevoie, de a le regsi si prelucra dup cum ne cer
mprejurrile. Bazele de date nu reprezint singurul instrument de stocare si prelucrare a inIormatiilor.
Si ntr-un banal Iisier .DOC (document Word, WordPerIect...), prezentare PowerPoint sau Ioaie de
calcul (Excel, Lotus 1-2-3...) pstrm date. Ca s nu mai vorbim de pagini Web. Problema este c n
documente, Ioi de calcul, prezentri, Iisiere HTML etc. datele sunt slab structurate. Pentru a localiza
inIormatiile trebuie Iolosite instrumente de cutare care s depisteze prezenta unor cuvinte cheie,
eventual n preajma unor alte cuvinte cheie (cu o aIacere de genul acesta s-au umplut de bani cei de la
Google).
ncheiem acest mini-paragraI cu dou vesti. Cea bun este c, la acest moment, bazele de date
reprezint cel mai bine structurat mod de pstrare si scotocire a inIormatiilor. Este motivul pentru care
piata produselor de lucru cu bazele de date se exprim n valori de ordinul miliardelor de dolari.
Vestea rea tine de Iaptul c, dintre toate datele si inIormatiile pe care le vehiculm/gestionm/prelu-
crm pe hrtie, la teleIon, pe band sau disc magnetic, optic etc., doar o mic parte sunt preluate si
preluabile n bazele de date.
6 Baze de date
1.2 LA NCEPUT A FOST FI$IERUL
Prima care a resimtit acut nevoia unor instrumente soItware dedicate administrrii unor
cantitti imense de inIormatii a Iost armata SUA. n a doua parte a anilor '50 Departamentul Aprrii
al SUA a Iormat un grup de specialisti pentru eborarea unui limbaj destinat aplicatiilor administrative,
n care diIicultatea major tinea de volumul imens de resurse materiale si Iinanciare ce trebuia
"chivernisit" si pentru care erau necesare rapoarte dintre cele mai diverse. La acel moment apruse
FLOWMATIC, limbaj precursor celui care a Iost considerat cteva decenii regele inIormaticii
economice COBOL (Common Business Oriented Language).
Arhitectura aplicatiilor de acest tip speciIic nu numai COBOL-ului, ci multor limbaje din a
III-a generatie, denumit flat-files architecture tradus, ntr-o doar, n romneste drept fiiere
independente este reprezentat n Iigura 1.1. SpeciIic acestui mod de lucru, reIerit ca file-based sau
flat files (Iisiere independente), este Iaptul c Iiecare dat (Data1, Data2,... Datan) este descris (nume,
tip, lungime), autonom, n toate Iisierele n care apare. Mai mult, descrierea Iiecrui Iisier de date
(cmpurile care-l alctuiesc, tipul si lungimea Iiecruia, modul de organizare (sercvential, indexat,
relativ etc.)) este obligatorie n toate programele care l 'citesc sau modiIic. ntre FISIER1,
FISIER2, ... FISIERn nu exist nici o relatie deIinit explicit.
Data 1
Data 2
Data 3
Data 4
Data 2
Data 4
Data 5
Data 6
Data 1
Data 5
Data 7
Data 8
FISIER 1
FISIER 2
FISIER 3
PRELUCRARE 1
PRELUCRARE 2
PRELUCRARE 3
Raport 1
Fisier de
legturi
Raport 4
Raport 3
Raport 2
Raport 5
DATE FI$IERE PRELUCRRI IE$IRI

Figura 1.1. Sistem informatic ba:at pe organi:area datelor in fiiere independente
Spre exemplu, Data2 este prezent n dou Iisiere de date, FISIER1 si FISIER2. Dac, prin
program, se modiIic Iormatul sau valoarea acesteia n FISIER1, modiIicarea nu se Iace automat si n
FISIER2; prin urmare, o aceeasi dat, Data2, va prezenta dou valori diIerite n cele dou Iisiere, iar
necazurile bat la us: inIormatiile Iurnizate de sistemul inIormatic sunt redundante si prezint un mare
risc de pierdere a coerentei.
Se poate proiecta un mecanism de mentinere a integrittii datelor, astIel nct actualizarea unei
date ntr-un Iisier s atrag automat actualizarea tuturor Iisierelor de date n care aceasta apare, ns, n
sistemele mari, care gestioneaz volume uriase de inIormatii, implementarea unui asemenea mecanism
este extrem de complex si costisitoare. n plus, Iisierele de date sunt uneori proiectate si
implementate la distante mari n timp, n Iormate diIerite: de exemplu, FISIER1 este posibil s Ii Iost
FEAA nfoEc + CG - 2006/2007 7
creat cu ajutorul limbajului COBOL, FISIER2 n FORTRAN iar FISIER3 n BASIC. n asemenea
conditii, punerea n oper a mecanismului de mentinere a integrittii devine o utopie.
Chiar numai si din cele prezentate mai sus, se pot desprinde cteva dezavantaje ale organizrii
datelor dup modelul Iisierelor independente:
- Redundanta i inconsistenta datelor: o aceeasi dat apare n mai multe Iisiere; n aceste cazuri exist
riscul modiIicrii acesteia ntr-un Iisier Ir a Iace modiIicrile si n toate celelalte Iisiere.
- Dificultatea accesului. ntr-o ntreprindere, o aceeasi inIormatie este exploatat de mai multi
utilizatori. Spre exemplu, pentru departamentul care se ocup cu gestiunea stocurilor, intrrile de
materiale trebuie ordonate pe magazii (depozite) si repere, n timp ce pentru departamentul care se
ocup cu decontrile cu partenerii de aIaceri ai ntreprinderii, intrrile trebuie ordonate pe Iurnizori ai
materialelor. Or, Iisierele traditionale nu Iaciliteaz accesarea datelor dup mai multe criterii, speciIice
diIeritilor utilizatori sau grupuri de utilizatori.
- I:olarea datelor: cnd datele sunt stocate n Iormate diIerite, este diIicil de scris programe care s
realizeze accesul ntr-o manier global a tuturor celor implicate n derularea unei tranzactii.
- Complexitatea apstoare a actuali:rilor. O actualizare presupune adugarea, modiIicarea sau
stergerea unor inIormatii din Iisiere. Cum prelucrrile se desIsoar n timp real, de la mai multe
terminale (n mediile multi-utilizator), pot apare situatii conIlictuale atunci cnd doi utilizatori doresc
modiIicarea simultan a unei aceleasi date. Rezolvarea acestui gen de conIlicte presupune existenta
unui program-supervizor al prelucrrilor, care este greu de realizat cu o multitudine de Iisiere, create la
distant n timp si, n Iormate diIerite.
- Problemele de securitate tin de diIicultatea crerii unui mecanism care s protejeze pe deplin datele
din Iisiere de accesul neautorizat.
- Probleme legate de integritatea datelor. InIormatiile stocate n Iisiere sunt supuse la numeroase
restrictii semantice. Toate aceste restrictii alctuiesc mecanismul de integritate a datelor, deosebit de
complex n mediile de lucru multi-utilizator si eterogene.
- Inabilitatea de a obtine rspunsuri rapide la probleme ad-hoc simple.
- Costul ridicat se datoreaz gradului mare de redundant a datelor, eIorturilor deosebite ce trebuie
depuse pentru interconectarea diIeritelor tipuri de Iisiere de date si pentru asigurarea Iunctionrii
sistemului n conditiile respectrii unui nivel minim de integritate si securitate a inIormatiilor.
- Inflexibilitatea fat de schimbrile ulterioare, ce sunt inerente oricrui sistem inIormational.
- Modelarea indecvat a lumii reale.
Aceste dezavantaje sunt mai mult dect convingtoare, nct v puteti ntreba dac au existat
asa inconstienti care s-si arunce banii pe apa... Iisierelor independente. Ei bine, o serie de aplicatii
dezvoltate n anii '60 sau '70 au Iost mostenite si Iolosite pn zilele noastre. De ce ? Datorit
consistentelor sume investite, care au putut Ii amortizate (trecute pe costuri) doar n ani buni, chiar
decenii. Un alt motiv a Iost ns Iunctionalitatea si viteza unor asemenea aplicatii, precum si
experienta acumulat de o larg cateogorie de proIesionisti n ale IT-ului.
1.3 CE ESTE O BAZ DE DATE ?
Sintagma ba: de date apare pentru prima dat n titlul unei conIerinte organizate la Santa
Monica (CaliIornia) n 1964 de System Development Corporation. Consacrarea deIinitiv a termenului
8 Baze de date
este marcat de publicarea n anul 1969, de ctre CODASYL, n cadrul unei conIerinte dedicate
limbajelor de gestiune a datelor, a primului raport tehnic n care este prezentat conceptul de baz de
date. Fat de modelul Iisierelor independente, noutatea o constituie existenta unui fiier de descriere
global a bazei, astIel nct s se poat asigura independenta programelor Iat de date, dup cum o
arat si Iigura 1.2.
Avantajele organizrii inIormatiilor n baze de date decurg tocmai din existenta acestui Iisier
de descriere global a bazei, denumit, n general, dictionar de date (alte titulaturi: repertoar de date
sau catalog de sistem). Extragerea si modiIicarea datelor, altIel spus, lucrul cu Iisierele de date, se
deruleaz exclusiv prin intermediul dictionarului n care se gsesc inIormatii privitoare la structura
datelor si restrictiile ndeplinite de acestea.
O ba: de date (BD) repre:int un ansamblu structurat de fiiere, care grupea: datele
prelucrate in aplicatiile informatice ale unei persoane, grup de persoane, intreprinderi, institutii etc.
Formal, BD poate fi definit ca o colectie de date aflate in interdependent, impreun cu descrierea
datelor i a relatiilor dintre ele, sau ca o colectie de date utili:at intr-o organi:atie, colectie care
este automati:at, partafat, definit riguros (formali:at) i controlat la nivel central.
Fisier de date n
Dic(ionar
de date
B A Z A DE D A T E
Aplicatia 1
Fisier de date 2
Fisier de date 1
Aplicatia 2 Aplicatia 3

Figura 1.2. Schem de principiu a unei ba:e de date
Atunci vorbim despre o baz de date, trebuie avute n vedere dou aspecte Iundamentale
aceste acesteia, schema si continutul. Organizarea bazei de date se reIlect n schema sau structura sa,
ce reprezint un ansamblu de instrumente pentru descrierea datelor, a relatiilor dintre acestea, a
semanticii lor si a restrictiilor la care sunt supuse. Ansamblul inIormatiilor stocate n baz la un
moment dat constituie continutul sau instantierea sau reali:area acesteia. n timp ce volumul prezint
o evolutie spectaculoas n timp, schema unei baze rmne relativ constant pe tot parcursul utilizrii
acesteia. Corespunztor celor dou aspecte complementare, schem/continut, limbajele de programare
dedicate bazelor de date se mpart n limbaje de deIinire a datelor (DDL Data DeIinition Language)
si limbaje de manipulare a datelor (DML Data Manipulation Language). Limbajele aIlate n uz, cum
ar Ii SQL-ul, prezint optiuni att pentru declararea structurii, ct si pentru editarea continutului si
consultarea/interogarea bazei.

FEAA nfoEc + CG - 2006/2007 9
ntr-un sistem inIormatic ce utilizeaz BD, organizarea datelor poate Ii analizat din mai multe
puncte de vedere si pe diIerite paliere. De obicei, abordarea se Iace pe trei nivele: fi:ic sau intern,
conceptual sau global si extern.
Nivelul fi:ic (sau intern). Reprezint modalitatea eIectiv n care acestea sunt "scrise" pe
suportul de stocare - disc magnetic, disc optic, band magnetic etc.
Nivelul conceptual (sau global). Este nivelul imediat superior celui Iizic, datele Iiind privite
prin prisma semanticii lor; intereseaz continutul lor eIectiv, ca si relatiile care le leag de alte date.
Reprezint primul nivel de abstractizare a lumii reale observate. Obiectivul acestui nivel l constituie
modelarea realittii considerate, asigurndu-se independenta bazei Iat de orice restrictie tehnologic
sau echipament anume. Toti utilizatorii si exprim nevoile de date la nivel conceptual, prezentndu-le
administratorului bazei de date, acesta Iiind cel care are o viziune global necesar satisIacerii tuturor
cerintelor inIormationale.
Nivelul extern. Este ultimul nivel de abstractizare la care poate Ii descris o baz de date.
Structurile de la nivelul conceptual sunt relativ simple, ns volumul lor poate Ii deconcertant. Iar dac
la nivel conceptual baza de date este abordat n ansamblul ei, n practic, un utilizator sau un grup de
utilizatori lucreaz numai cu o portiune speciIic a bazei, n Iunctie de departamentul n care si
desIsoar activitatea si de atributiile sale (lor). SimpliIicarea interactiunii utilizatori-baz, precum si
cresterea securittii bazei, sunt deziderate ale unui nivel superior de abstractizare, care este nivelul
extern. AstIel, structura BD se prezint sub diIerite machete, reIerite, uneori si ca sub-scheme, scheme
externe sau imagini, n Iunctie de nevoile Iiecrui utilizator sau grup de utilizatori.
Lund n considerare cele trei nivele de abstractizare, schematizarea unui sistem de lucru cu o
baz de date se poate Iace ca n Iigura 1.3.
DeIinirea structurii
interne de stocare
(Schema intern)
Baza de date memorat pe disc
Imagine global
(nivel global)
InterIat dintre nivelele
Iizic si global
Schema
conceptual
(global)
InterIat A
dintre nivelele
global si extern
InterIat B
dintre nivelele
global si extern
Imagine A
(nivel extern)
Imagine B
(nivel extern)
Schem extern
A
Schem extern
B
Aplicatie
Comenzi
autonome
Aplicatie Aplicatie
Comenzi
autonome
Utilizator A1 Utilizator B1 Utilizator B2 Utilizator B3 Utilizator A2
SISTEM DE
GESTIUNE A
BAZEI
DE DATE

Figura 1.3. Schemati:are a unui sistem de lucru cu o ba: de date
10 Baze de date
Posibilitatea modiIicrii structurii la un nivel, Ir a aIecta structura nivelului sau nivelurilor
superioare, se numeste autonomie a datelor stocate n baz, analizabil pe dou paliere.
Autonomia fi:ic reprezint posibilitatea modiIicrii arhitecturii bazei la nivel intern, Ir ca
aceasta s necesite schimbarea schemei conceptuale si rescrierea programelor pentru exploatarea bazei
de date. Asemenea modiIicri sunt necesare uneori pentru ameliorarea perIormantelor de lucru (vitez
de acces, mrimea Iisierelor etc.). Tot autonomia Iizic este cea care asigur portarea bazei de date de
pe un sistem de calcul pe altul Ir modiIicarea schemei conceptuale si a programelor.
Autonomia logic presupune posibilitatea modiIicrii schemei conceptuale a bazei (modiIicare
datorat necesittii rezolvrii unor noi cerinte inIormationale) Ir a rescrie programele de exploatare.
Autonomia logic a datelor este mai greu de realizat dect autonomia Iizic, deoarece programele de
exploatare sunt dependente, n Ioarte mare msur, de structura logic a datelor pe care le consult si
actualizeaz, n ciuda existentei dictionarului de date. Fireste, un element important l reprezint si
anvergura modiIicrii schemei conceptuale.
Datele stocate ntr-o BD prezint, ntr-o msur mai mare sau mai mic, urmtoarele
caracteristici:
partafabilitate disponibilitate pentru un mare numr de utilizatori si aplicatii;
persistent existent permanent, din momentul prelurii n baz pn n momentul
actualizrii sau stergerii;
securitate protejarea de accesul neautorizat, att n ceea ce priveste citirea si copierea, ct si
modiIicarea si stergerea;
validitate reIerit si ca integritate sau corectitudine priveste gradul de adecvare dintre
datele din baz si realitatea, procesele pe care le reIlect aceste date;
consistent ori de cte ori diverse aspecte ale proceselor sau Ienomenelor reale sunt preluate
n baz sub Iorma a doua sau mai multor entitti sau atribute, aceste entitti/atribute trebuie s
Iie n concordant unele ce celelalte, s respecte relatiile existente ntre aspectele
proceselor/Ienomenelor reale;
nonredundant - pe ct posibil, o entitate din realitate ar trebui s aib un singur corespondent
n baza de date;
independent priveste autonomia logic si Iizic evocate mai sus.
1.4 MODELE DE ORGANIZARE A DATELOR N BD
Nucleul unei baze de date l reprezint dictionarul de date ce contine structura bazei, structur
care se materializeaz prin instructiuni scrise cu ajutorul unui limbaj de deIinire a datelor (DDL).
Analiza, proiectarea si implementarea structurii (schemei) bazei se realizeaz utiliznd un model de
date. Un asemenea model reprezint un ansamblu de instrumente conceptuale care permit descrierea
datelor, relatiilor dintre ele, a semanticii lor, ca si a restrictiilor la care sunt supuse.
Modelul datelor este o reprezentare a obiectelor lumii reale si a evenimentelor asociate lor.
Presupune un demers de abstractizare care se concentreaz pe aspectele esentiale ale organizatiei/apli-
catiei, Iurniznd conceptele de baz si notatiile care vor permite utilizatorilor bazelor de date s
comunice clar si rapid inIormatiile si cunostintele lor despre datele organizatiei.
FEAA nfoEc + CG - 2006/2007 11
O grupare "traditional" a modelelor utilizate n bazele de date delimiteaz trei categorii:
modele logice bazate pe obiect, modele logice bazate pe nregistrare si modele Iizice. Din punctul
nostru de vedere, intereseaz numai nivelele conceptual si extern de abstractizare a datelor; de aceea,
vom prezenta, n linii mari, numai reprezentantii principali ai primelor dou categorii.
Modelul ierarhic. Primele produse-soItware (Sisteme de Gestiune a Bazelor de Date - SGBD)
lucrau bu baze de date ierarhice. Structura datelor este prezentat sub Iorma unui arbore - vezi Iigura
1.4 -, partea superioar a arborelui Iiind rdcina (arborele este vzut "cu verdele n jos"). Un nod-tat
poate avea mai multe noduri-Iii. Un Iiu nu poate exista independent de tatl su. Legtura
(reprezentat prin linie) se Iace exclusiv ntre tat si Iii. Orice Iiu poate Ii si tat, deci poate avea, la
rndul su, Iii.
AstIel, n clasa a IX-a A (proIil Uman) exist doi elevi: Pop I. Vasile ce are numrul matricol
4545 si domiciliaz pe strada Primverii nr. 22, iar al doilea, Ion V. Viorel, are matricolul 4550 si
locuieste pe strada Coruptiei nr. 13 bis. Vasile a luat la Iizic (proIesor Cernat Dan, nscut pe 21
aprilie 1968) un 5 pe 8 Iebruarie si un 9 pe 15 Iebruarie. La istorie (proIesor Pal Dana, nscut pe 12
noiembrie 1975) st ceva mai bine, avnd un 8 (cpatat pe 21 Iebruarie), un 7 (pe 28 Iebruarie) si un 8
(pe 7 martie). n acelasi mod poate Ii intepretat Iigura pentru Ion V. Viorel, cu mentiunea special c
istoria nu e punctul lui Iorte.

Figura 1.4. Arbore de structur specific modelului ierarhic
Modul n care nregistrrile se nlntuie presupune Iolosirea unor pointeri (un soi de adrese
Iizice) ce nu sunt reprezentati n Iigur (din considerente umanitare). AIlarea inIormatiilor din baza de
date presupune navigarea ntre nregistrr cu ajutorul pointerilor. n plus, modiIicarea structurii bazei
de date presupune actualizarea nlntuirii pointerilor, ceea ce extrem de laborios. A alt problem a
acestui model o reprezint imposibilitatea reprezentrii cazului n care un copil este, pardon,
"rezultatul" a mai multi tati. Situatia nu este att de scandaloas cum v-ati nchipuit, si aceasta doarece
modelul ierarhic nu Iace nici o reIerire la mama Iiului.
Figura 1.4 este relevant pentru gradul de redundant impus de reprezentarea ierarhic. Codul,
denumirea, numrul de ore ale Iiecrei discipline, precum si datele despre proIesor, apar pentru Iiecare
elev, desi acestea sunt comune la nivel de an de studii (numele disciplinei, numrul de ore) sau la nivel
de clas (proIesorul titular).
12 Baze de date
Modelul retea. Este o dezvoltare a modelului ierarhic, prin care se pot reprezenta si situatiile
n care un Iiu "posed" mai multi tati. nregistrrile sunt privite n BD ca o colectie de graIuri cu o
structur asemntoare celei din Iigura 1.5. Navigarea se Iace tot prin pointeri.

Figura. 1.5. Graf specific repre:entrii utili:and modelul retea
Modelul retea elimin o serie de redundante speciIice modelului ierarhic. Spre exemplu, cazul
ilustrat n Iigura 1.4 poate Ii reprezentat dup logica modelului retea ca n Iigura 1.5. Se observ c
Iiecare disciplin (si proIesorul care o pred la clasa respectiv) apare o singur dat, Iiind legat prin
linii de toate notele obtinute de Iiecare dintre elevi.
Modelul relational a Iost urmtorul n ordinea cronologic si rmne cel care domin copios
piata bazelor de date si la acest moment, motiv pentru care cea mai mare parte a acestui curs i este
dedicat.
Modelul obiectual. ncepnd cu anii `60, n programare si, ceva mai trziu, n analiz si
proiectare, orientarea pe obiecte (OO) a avut un succes urias, reusit s depseasc metodologiile
structurate. Pe baza acestui succes, s-a crezut c si n materie de baze de date, modelul obiectual l va
surclasa pe cel relational. Rezultatele sunt ns deprimante pentru suporterii OO-ului, piata SGBD OO
Iiind sub 6 din valoarea total a pietii bazelor de date.
Modelul relational-obiectual. Este un model mai recent ce ncearc s valoriIice deopotriv
atuurile relationalului cu orientarea pe obiecte. Desi privit mai degrab cu nencrederile n cercurile
teoreticienilor, acest model se impune ncet-ncet datorit marilor productori de soItware dedicat
bazelor de date. Ca si n cazul modelului ,curat OO, tehnoloIia relational-obiectual nu Iace...
obiectul cursului de Iat, Iiind studiat la discipla Baze de date avansate din ciclul II (specializarea
InIormatic economic).

FEAA nfoEc + CG - 2006/2007 13
Capitolul 2
MODELUL RELATIONAL

Obiective:
I. Explicarea no(iunilor fundamentale ale modelului ra(ional:
rela(ie/tabel, domeniu, atribut/coloan, tuplu/linie
II. Discutarea restric(iilor implementabile n bazele de date rela(ionale:
restric(ia de domeniu, atomicitarea, nenulitatea, unicitatea, restric(ia
referen(ial, regulile de validare la nivel de atribut yi nregistrare
III. Exemplificarea schemei yi con(inutului unei baze de date rela(ionale

14 Baze de date
Modelul relational de organizare a datelor s-a conturat n dou articole publicate n 1969 si
1970 de ctre E.F. Codd, matematician la centrul de cercetri din San Jose (CaliIornia) al Iirmei
IBM
2
. n acel moment, tehnologia bazelor de date era centrat pe modelele ierarhic si retea, modele ce
depind ntr-o mai mare msur de organizarea intern a datelor pe suportul de stocare (celebrii pointeri
pe care i-am pomenit acum cteva pagini). Codd a propus o structur de date tabelar, independent de
tipul de echipamente si soItware de sistem pe care este implementat, structur "nzestrat" cu o serie
de operatori pentru extragerea datelor. Desi puternic matematizat, modelul relational este relativ usor
de nteles. Fat de modelele ierarhice si retea, modelul relational prezint cteva avantaje:
propune structuri de date usor de utilizat;
amelioreaz independenta logic si Iizic;
pune la dispozitia utilizatorilor limbaje ne-procedurale;
optimizeaz accesul la date;
mbuntteste integritatea si conIidentialitatea datelor;
ia n calcul o larg varietate de aplicatii;
abordeaz metodologic deIinirea structurii bazei de date.

Un model de date are trei piloni: componenta structural, adic modul n care, eIectiv, la nivel
logic, datele sunt stocate n baz, componenta de integritate, adic regulile ce pot Ii declarate pentru
datele din baz si o component manipulatorie, adic modul n care obtinem inIormatii din bazele de
date (ceea ce presupune o serie de operatori aplicabili uneia sau mai multor relatii). Modelului
relational i este asociat teoria normalizrii, care are ca scop prevenirea comportamentului aberant al
relatiilor n momentul actualizrii lor, eliminarea datelor redundante si nlesnirea ntelegerii legturilor
semantice dintre date (vezi capitolul 3). Prezentul capitol va Ii dedicat componentei structurale si celei
de integritare din modelul relational.
Desi puternic contestat, si cu neajunsurile sale, modelul relational de organizare a bazelor de
date rmne cel mai utilizat. Cu Ioarte putine exceptii, toate aplicatiile soItware realizate pentru bnci,
buticuri, universitti (ordinea este, n ciuda aparentelor, pur ntmpltoare) sunt realizate cu
produse/instrumente ce gestioneaz baze de date relationale.
2.1 STRUCTUR
Modelul relational al datelor se poate deIini printr-o serie de structuri de date (relatii alctuite
din tupluri), operatii aplicate asupra structurilor de date (selectie, proiectie, jonctiune etc.) si reguli de
integritate care s asigure consistenta datelor (chei primare, restrictii reIerentiale s.a.).
La modul simplist, o baz de date relational (BDR) poate Ii deIinit ca un ansamblu de relatii
(tabele); Iiecare tabel (sau tabel), alctuit din linii (tupluri), are un nume unic si este stocat pe
suport extern (de obicei disc). La intersectia unei linii cu o coloan se gseste o valoare atomic
(elementar). O relatie contine inIormatii omogene legate de anumite entitti, procese, Ienomene:
CRTI, STUDENTI, LOCALITTI, PERSONAL, FACTURI etc. Spre exemplu, n Iigura 2.1 este
reprezentat tabela CLIENTI.

2
Extrase din lucrarea [Codd70] se gsesc la adresa http://www.acm.org/classics/nov95/. De asemenea, o
excelent analiz a articolelor lui Codd este n [Date98].
FEAA nfoEc + CG - 2006/2007 15

Figura 2.1. Relatia (tabela) CLIEN]I
n teoria relational se Ioloseste termenul relatie. Practica, ns, a consacrat termenul tabel
(engl. table). Un tuplu sau o linie este o succesiune de valori de diIerite tipuri. n general, o linie
regrupeaz inIormatii reIeritoare la un obiect, eveniment etc., altIel spus, inIormatii reIeritoare la o
entitate: o carte (un titlu sau un exemplar din depozitul unei biblioteci, depinde de circumstante), un/o
student(), o localitate (oras sau comun), un angajat al Iirmei, o Iactur emis etc. Figura 2.2 contine
al doilea tuplu din tabela CLIENTI, tuplu reIeritor la Iorma MODERN SRL. Linia de mai sus este
alctuit din patru valori ce desemneaz: codul, numele, adresa si codul postal al localittii si adresei
reIeritoare la clientul MODERN SRL.

Figura 2.2. Un tuplu al tabelei CLIEN]I
Teoretic, orice tuplu repre:int o relatie intre clase de valori (n cazul nostru, ntre patru clase
de valori); de aici provine sintagma ba:e de date relationale, n sensul matematic al relatiei, de
asociere a dou sau mai multe elemente. Fireste, toate tuplurile relatiei au acelasi Iormat (structur),
ceea ce nseamn c n tabela CLIENTI, din care a Iost extras linia din Iigura 2.2, Iiecare linie este
constituit dintr-o valoare a codului, o valoare a numelui, o valoare a adresei, si o valoare a codului
postal. Ordinea tuplurilor nu prezint important din punctul de vedere al continutul inIormational al
tabelei.
Fiecare atribut este caracterizat printr-un nume si un domeniu de valori pe care le poate lua.
Domeniul poate Ii deIinit ca ansamblul valorilor acceptate (autorizate) pentru un element component
al relatiei:
ntr-o tabel destinat datelor generale ale angajatilor, pentru atributul 8ex, domeniul este
alctuit din dou valori: Femeiesc si Brbtesc;
pentru atributul Regiune, domeniul, desi limitat, este ceva mai mare; valorile autorizate pot
Ii: Dobrogea, Banat, Transilvania, Oltenia, Muntenia, Moldova.
domeniul atributului Jud este alctuit din indicativele auto (dou caractere) ale Iiecrui judet
(plus Bucuresti).
16 Baze de date
domeniul atributului Judet este alctuit din numele Iiecrui judet (plus Bucuresti).
domeniul unui atribut precum Pre[Un|tar, care se reIer la pretul la care a Iost vndut un
produs/serviciu, este cu mult mai larg, Iiind alctuit din orice valoarea cuprins ntre 1 si
99999999 lei (ceva mai noi).
Fireste, n Iunctie de speciIicul bazei de date, domeniul poate Ii extins sau restrns dup
cerinte. De exemplu, la regiunile luate n discutie mai sus, mai pot Ii adugate si provincii precum:
Bucovina, Maramures, Crisana.

Si acum, cteva senzatii tari (urmeaz un pic de matematic) ! Dac notm cu D1 domeniul
atributului 6od6||ent, cu D2 domeniul atributului Nume6||ent, cu D3 domeniul pentru Adresa, si cu
D4 domeniul atributul 6odPosta|, se poate spune c Iiecare linie a tabelei CLIENTI este un tuplu de
patru elemente, iar relatia n ansamblu corespunde unui subansamblu din ansamblul tuturor tuplurilor
posibile alctuite din patru elemente, ansamblu care este produsul cartezian al celor patru domenii.
n general, orice relatie R poate Ii deIinit ca un subansamblu al produsului cartezian de n domenii D
i
:
R D x D x D x ... x D
1 2 3 n
,
n Iiind denumit gradul sau ordinul relatiei. Relatiile de grad 1 sunt unare, cele de grad 2 - binare, ...,
cele de grad n - n-are. Aceast deIinitie pune n evident aspectul constant al relatiei, de independent
n timp (se spune c n acest caz relatia este deIinit ca un predicat).
O a doua deIinitie abordeaz o relatie R ca un ansamblu de m-uplete (m-tupluri) de valori:
R = { t , t , ..., t , ..., t }
1 2 k m
, unde t (d ,d , ..., d ,...,d
k k1 k2 ki kn
= ) n care:
d
k1
este o valoare n D
1
, d
k2
este o valoare n D
2
, . , d
kn
este o valoare n D
n
;
n - reprezint ordinul lui R;
m - cardinalitatea lui R.

Pentru un (mic) plus de claritate, vezi Iigura 2.3.

Figura 2.3. Ilustrarea celei de-a doua definitii a unei relatii
Reprezentarea sub Iorm de tabel, deci ca ansamblu de tupluri, pune n evident aspectul
dinamic, variabil al relatiei. Abordarea predicativ (prima deIinitie) sau ansamblist (a doua deIinitie)
reprezint un criteriu important de delimitare a limbajelor de interogare a bazelor de date relationale.

Retinem corespondenta notiunilor relatie-tabel, tuplu-linie si atribut-coloan.

FEAA nfoEc + CG - 2006/2007 17
Numrul de tabele pe care le contine o baz de date, atributele 'adunate n Iiecare tabel,
domeniul Iiecruia dintre atribute prezint diIerente majore de la o baz la alta, chiar dac uneori
reIlect acelasi tip de procese. Intrm astIel n sIera proiectrii bazelor de date, a dependentelor si
normalizrii.
Relatia CLIENTI contine inIormatii despre Iirmele crora compania noastr le vinde
produsele pe care producem si/sau comercializm. Fiecare linie se reIer la un singur client. n Iigura
2.1 pe a treia linie a tabelei apare o valoarea curioas notat NULL. Valoarea NULL este considerat o
metavaloare si indic Iaptul c, n acel loc, inIormatia este necunoscut sau inaplicabil (n acest caz
nu cunoastem adresa clientului Modern SRL). Valoarea NULL este diIerit, ns de valorile 0 sau
spatiu. Uneori, importanta sa este (din pcate) major n expresii si Iunctii, dup cum stiu cei cu
oarecare experient n limbajului SQL.

n ncheiere, principalele caracteristici ale unei relatii sunt sistematizate dup cum urmeaz:
n cadrul unei baze de date, o relatie prezint un nume distinct de al celorlalte relatii.
Valoarea unui atribut ntr-un tuplu oarecare contine a singur valoare (o valoare atomic sau
elementar).
Fiecare atribut are un nume distinct.
Orice valoare a unui atribut Iace parte din domeniul pe care a Iost deIinit acesta.
Ordinea dispunerii atributelor n relatie nu prezint important.
Fiecare tuplu este distinct, adic nu pot exista dou tupluri identice.
Ordinea tuplurilor nu inIluenteaz continutul inIormational al relatiei.
2.2 RESTRICTII
De ce ne intereseaz restrictiile ntr-o baz de date ? Termenul de restrictie este oarecum
iritant, att pentru studenti, ct si pentru proIesori, deoarece semnaleaz existenta unor constrngeri
instituite si oarecum obligatorii, si, de vreme ce sunt impuse, nsemn c nu sunt prea plcute (dect,
n cel mai bun caz, pentru cel care le-a instituit). Partea cea mai enervant este c respectarea
restrictiilor este (supra)vegheat de o anumit autoritate nzestrat cu anumite instrumente de
constrngere, de la bastoane de cauciuc, la cresterea si scderea impozitelor, salariilor, banilor de
buzunar etc.
Ei bine, n bazele de date, restrictiile sunt ceva mai acceptabile. Cei care lucreaz cu bazele de
date sunt Ioarte interesati n declararea restrictiilor, pentru c, odat deIinite, de respectarea lor se va
ngriji sistemul de gestiune a bazelor de date (adic programele de lucru cu bazele de date). Esential
este c, ajutati de restrictii, putem creste gradul de corectitudine si de ncredere al datelor din baz. n
cele ce urmeaz vor Ii prezentate pe scurt cele mai importante restrictii deIinibile ntr-o baz de date
relational: restrictia de domeniu, de atomicitate, de unicitate, reIerential si restrictiile-utilizator.
2.2.1 Restric(ia de domeniu
Dup cum am vzut n paragraIul anterior, un atribut este deIinit printr-un nume si un
domeniu. Orice valoare a atributului trebuie s se ncadreze n domeniul deIinit. Exist mai multe
moduri de perceptie a acestei restrictii.
18 Baze de date
O parte din inIormaticieni substituie domeniul tipului atributului: numeric, ir de caractere,
dat calendaristic, logic (boolean) etc. si, eventual, lungimii (numrul maxim de pozitii/caractere pe
care se poate 'ntinde un atribut). Dup cum se observ, este luat n calcul numai aspectul sintactic al
domeniului. Faptul c indicativul auto al unui judet (vezi plcutele de nmatriculare) poate Ii una din
valorile: IS, TM, B etc. reprezint o restrictie de comportament sau, mai simplu, o restrictie deIinit de
utilizator.
Cea de-a doua categorie priveste domeniul deopotriv sintactic si semantic. AstIel, domeniul
sintactic al atributului Jud (indicativul judetului) este un sir de dou caractere, obligatoriu litere (sau o
liter si un spatiu, pentru Bucuresti), si, chiar mai restrictiv, literele sunt obligatoriu majuscule. Din
punct de vedere semantic, indicativul poate lua una din valorile: IS, TM .
Majoritatea SGBD-urilor permit deIinirea tuturor elementelor ce caracterizeaz domeniul
(sintactic si semantic) atributului Jud prin declararea tipului si lungimii atributului si prin asa-numitele
reguli de validare la nivel de cmp (Iield validation rule). Sunt ns si produse la care domeniul poate
Ii deIinit explicit, sintactic si semantic, dndu-i-se un nume la care vor legate atributele n momentul
crerii tabelelor.
2.2.2 Atomicitate
ConIorm teoriei bazelor de date relationale, orice atribut al unei tabele oarecare trebuie s Iie
atomic, n sensul imposibilittii descompunerii sale n alte atribute. Implicit, toate domeniile unei baze
de date sunt musai atomice (adic elementare). n aceste conditii, se spune c baza de date se aIl n
prima Iorm normal sau prima Iorm normalizat (1NF).
Astzi, atomicitatea valorii atributelor a devenit o tint predilect a 'atacurilor dusmnoase la
adresa modelului relational, datorit imposibilittii nglobrii unor structuri de date mai complexe,
speciIice unor domenii ca: proiectare asistat de calculator, baze de date multimedia etc. Multi autori,
dintre care merit amintiti cu deosebire Chris J. Date si Hugh Darwen, se opun ideii de atomicitate
Iormulat de Codd.
La drept vorbind, singurul lucru cert despre atomicitate este relaticitatea acesteia. S lum un
exemplu de atribut compus (non-atomic) - Adresa. Fiind alctuit din 8trada, Numar, |oc, 8cara, Etaj,
Apartament, discutia despre atomicitatea adresei pare de prisos, iar descompunerea sa imperativ.
Trebuie ns s ne raportm la obiectivele bazei. Fr ndoial c pentru BD a unei Iiliale CONEL sau
ROMTELECOM, sau pentru politie, preluarea separat a Iiecrui element constituent al adresei este
Ioarte important. Pentru un importator direct, ns, pentru un mare en-grossist sau pentru o Iirm de
productie lucrurile stau ntr-o cu totul alt lumin. Partenerii de aIaceri ai acestora sunt persoane
juridice, iar adresa intereseaz numai la nivel general, caz n care atributul Adresa nu este considerat a
Ii non-atomic.
Alte exemple de atribute ce pot Ii considerate, n Iunctie de circumstante, simple sau compuse:
0ata0pera[|un||ancare (0ata 0ra), u|et|n|dent|tate (8er|aNumar), Nr|nmatr|cu|areAuto (privit
global, sau pe cele trei componente: numr, judet, combinatie trei de litere).
O relatie (tabel) n 1NF nu trebuie s contin atribute care se repet ca grupuri (grupuri
repetitive). ntr-o alt Iormulare, toate liniile unei tabele trebuie s contin acelasi numr de atribute.
Fiecare celul a tabelei (intersectia unei coloane cu o linie), altIel spus, valoarea unui atribut pe o linie
FEAA nfoEc + CG - 2006/2007 19
(nregistrare), trebuie s Iie atomic. Detalii despre atomicitate si grupuri repetitive gsiti n |Fotache
2005|. Noi o s relum aceast discutie si n capitolul 3.
2.2.3 Nenulitate
Modelul relational accept ca, atunci cnd nu se cunoaste valoarea unui atribut pentru o
anumite entitate, sau cnd pentru acel obiect, entitate, persoan etc. atributul este inaplicabil, s se
Ioloseasc (meta)valoare NULL. Dup cum am discutat, celui de-al treilea client din Iigura 2.1 nu i
cunoaste adresa. Dac am avea o tabel PRODUSE cu atributele CodProdus, DenumireProdus, UM,
Culoare, este posibil ca, pentru anumite sortimente, cum ar tricouri, cmsi, jachete, atributul s Iie
important, n timp ce pentru altele, precum vodc, caIea, lapte atributul culoare s nu Iurnizeze nici o
inIormatie, adic s nu Iie aplicabil. Iar dac laptele poate Ii doar alb, vodca chiar c nu are culoare
(sunt Ioarte multi specialisti n acest domeniu, i puteti ntreba !).
ntr-o baz de date relational avem posibilitatea de a le impune unora dintre atribute (sau
tuturora) s aib ntotdeauna valori speciIicate, altIel spus, le interzicem valorile nule, n timp cel altor
atribute li se pot permite valori nule. Ca regul, atributele importante, ce tin de identiIicarea sau
caracterizarea unei entitti, proces, Ienomen, precum si cele implicitate n calculul unor inIormatii
importante, sunt declarate NOT NULL, iar atributele Ir important deosebit pot Ii mai relaxate.
2.2.4 Unicitate
Dup cum am discutat n primul paragraI al acestui capitol, ntr-o relatie nu pot exista dou
linii identice (dou linii care prezint aceleasi valori pentru toate atributele). Mai mult, majoritatea
relatiilor prezint un atribut, sau o combinatie de atribute, care diIerentiaz cu sigurant un tuplu de
toate celelalte tupluri ale relatiei. Cheia primar a unei relatii (tabele) este un atribut sau un grup de
atribute care identiIic Ir ambiguitate Iiecare tuplu (linie) al relatiei (tabelei). Dup Codd, exist trei
restrictii pe care trebuie s le veriIice cheia primar:
unicitate: o cheie identiIic un singur tuplu (linie) al relatiei.
compo:itie minimal: atunci cnd cheia primar este compus, nici un atribut din cheie nu
poate Ii eliminat Ir distrugerea unicittii tuplului n cadrul relatiei; n cazuri limit, o cheie
poate Ii alctuit din toate atributele relatiei.
valori non-nule: valorile atributului (sau ale ansamblului de atribute) ce desemneaz cheia
primar sunt ntotdeauna speciIicate, deci ne-nule si, mai mult, nici un atribut din compozitia
cheii primare nu poate avea valori nule; aceast a treia conditie se mai numeste si restrictie a
entittii.
Joe Celko inventariaz patru proprietti dezirabile pentru o cheie
3
:
Familiaritate: valorile cheii s Iie usor de nteles pentru utilizatori.
Stabilitate: valorile cheii nu trebuie s Iie volatile.
Minimalitate
Simplitate: sunt de preIerat chei scurte si simple.

3
[Celko99], p.247
20 Baze de date
Tot el atrage atentia ca cele patru proprietti pot intra, uneori, n conIlict. O cheie stabil poate s se
dovedeasc complex si diIicil de gestionat. IdentiIicarea cheii primare pentru o relatie Iace parte
(mpreun cu stabilirea tabelelor prin gruparea atributelor, stabilirea celorlalte restrictii) din procesul
de proiectare a bazei de date. Uneori, precum n cazul tabelei JUDETE, stabilirea cheii primare nu
ridic probleme. Cum Iiecare judet are un indicativ auto unic, rezult c atributul Jud candideaz la
postul de cheie a relatiei. La Iel se poate spune si despre denumirea judetului. Rezult c relatia
JUDETE prezint dou chei candidate: Jud si Judet. Alegerea unei dintre cheile candidat are n vedere
criterii precum lungimea, usurinta n retinere si/sau editare. Fiind mai scurt, desemnm atributul Jud
drept cheie primar, situatie n care Judet devine cheie alternativ.
n tabela CLIENTI cheia primar este simpl - 6od6||ent, 6od6||ent reprezint un numr unic
asociat Iiecrei Iirme creia i-am Icut vnzri. Exist ns suIiciente cazuri n care cheia primar este
compus din dou, trei s.a.m.d. sau, la extrem, toate atributele relatiei. S lum spre analiz o relatie
PERSONAL care contine date generale despre angajatii Iirmei. Fiecare tuplu al relatiei se reIer la un
angajat, atributele Iiind: Nume, Prenume, 0ataNater||, Vech|me, 8a|ar|uTar|far.
- atributul Nume nu poate Ii cheie, deoarece chiar si ntr-o ntreprindere de talie mijlocie, este
posibil s existe doi angajati cu acelasi nume.
- dac aparitia a dou persoane cu nume identice este posibil, atunci aparitia a dou persoane
cu acelasi Prenume este probabil.
- nici unul din aceste atributele DataNasterii, Vechime, SalariuTariIar nu poate Ii "nzestrat"
cu Iunctiunea de identiIicator.
n acest caz, se ncearc gruparea a dou, trei, patru s.a.m.d. atribute, pn cnd se obtine
combinatia care va permite diIerentierea clar a oricrei linii de toate celelalte. Combinatia
NumeAdres pare, la primele dou vederi, a ndeplini "cerintele" de identiIicator. Ar Ii totusi o
problem: dac n aceeasi Iirm (organizatie) lucreaz mpreun sotul si sotia ? Ambii au, de obicei,
acelasi nume de Iamilie si, tot de obicei, acelasi domiciliu. Este adevrat, cazul ales nu este prea
Iericit. Dar este suIicient pentru a 'compromiterea combinatiei.
Urmtoarea tentativ este grupul NumePrenumeAdres, combinatie neoperant dac n
organizatie lucreaz tatl si un Iiu (sau mama si o Iiic) care au aceleasi nume si prenume si domiciliul
comun. Ar rmne de ales una dintre solutiile (NumePrenumeAdresVechime) sau
(NumePrenumeAdresaDataNasterii).
Oricare din cele dou combinatii prezint riscul violrii restrictiei de entitate, deoarece este
posibil ca, la preluarea unui angajai n baz, s nu i se cunoasc adresa sau data nasterii, caz n care
atributul respectiv ar avea valoarea NULL. DiIiculttile de identiIicare Ir ambiguitate a angajatilor au
determinat Iirmele ca, la angajare, s aloce Iiecrei persoane un numr unic, numr denumit Harca.
Prin adugarea acestui atribut la cele existente, pentru relatia PERSONAL problema cheii primare este
rezolvat mult mai simplu. Actualmente, sarcina este simpliIicat si prin utilizarea codului numeric
personal (6NP), combinatie de 13 ciIre care prezint avantajul c rmne neschimbat pe tot parcursul
vietii persoanei.
Pe lng notiunile cheie-candidat, cheie primar, cheie alternativ, modelul relational
utilizeaz si sintagma supercheie. Dup Celko
4
o supercheie poate Ii deIinit ca un set de coloane ce
ndeplineste conditia de cheie (unicitate), dar care contine cel putin un subset care este, el-nsusi,

4
[Celko99], p.52
FEAA nfoEc + CG - 2006/2007 21
cheie. Cu alte cuvinte, din cele trei conditii ale cheii primare, o supercheie o ndeplineste numai pe
prima (unicitate), Ir a avea ns compozitia minimal si Ir a pune problema restrictiei de entitate
(valorile nule ale atributelor componente).
Domeniul unui atribut care este cheie primar ntr-o relatie este denumit domeniu primar. Dac ntr-o
relatie exist mai multe combinatii de atribute care conIer unicitate tuplului, acestea sunt denumite chei
candidate. O cheie candidat care nu este identiIicator primar este reIerit ca si cheie alternativ.
2.2.5 Restric(ia referen(ial
O baz de date relational este alctuit din relatii (tabele) aIlate n legtur. Stabilirea
legturii se bazeaz pe mecanismul cheii strine si, implicit, a restrictiei reIerentiale. Figura 2.4
prezint o relatie n care sunt implicate tabelele FACTURI si CLIENTI.

Figura 2.4. O restrictie referential intre FACTURI (tabel-copil) i CLIEN]I (printe)
Atributul 6od6||ent joac un rol de 'agent de legtur ntre tabelele CLIENTI si FACTURI.
Pentru relatia CLIENTI, atributul 6od6||ent este cheie primar, n timp ce n tabela FACTURI,
6od6||ent reprezint coloana de reIerint sau cheia strin, deoarece numai pe baza valorilor sale se
poate Iace legtura cu relatia printe CLIENTI.
Cheile strine sau coloanele de reIerint sunt deci atribute sau combinatii de atribute care pun
n legtur linii (tupluri) din relatii diIerite. Tabela n care atributul de legtur este primar se
numeste tabel-printe (n cazul nostru, CLIENTI), iar cealalt tabel-copil.
Legat de notiunea de cheie strin apare conceptul de restrictie reIerential. O restrictie de
integritate reIerential apare atunci cnd o relatie Iace reIerint la o alt relatie. Cnd dou tabele
(relatii), T1 si T2, prezint atributul sau grupul de atribute notat CH, care, pentru T1, este cheie
primar, iar pentru T2 cheie strin, dac in T2 se inter:ice aparitia de valori nenule ale CH care nu
exist in nici un tuplu din T1, se spune c intre T2 i T1 s-a instituit o restrictie referential.
Instituirea restrictiei reIerentiale ntre tabela CLIENTI (printe) si FACTURI (copil) permite
cunoasterea, pentru Iiecare client, a denumirii localittii si a judetului n care-si are sediul. Dac n
FATURI ar exista vreo linie n care valoarea atributului 6od6||ent ar Ii, spre exemplu 9988, este clar
c acea linie ar Ii orIan (nu ar avea linie corespondent n tabela printe CLIENTI).



22 Baze de date

Observatii
1. Pentru multi utilizatori si proIesionisti ai bazelor de date, denumirea de "relational" desemneaz Iaptul c o
baz de date este alctuit din tabele puse n legtur prin intermediul cheilor strine. Aceasta este, de Iapt, a
doua acceptiune a termenului de BDR, prima, cea "clasic", avnd n vedere perceptia Iiecrei linii dintr-o
tabel ca o relatie ntre clase de valori.
2. Majoritatea SGBD-urilor prezint mecanisme de declararea si gestionare automat a restrictiilor reIerentiale,
prin actualizri n cascad si interzicerea valorilor care ar nclca aceste restrictii.
3. Respectarea restrictiilor reIerentiale este una din cele mai complicate sarcini pentru dezvoltatorii de aplicatii
ce utilizeaz baze de date. Din acest punct de vedere, tentatia este a 'sparge baza de date n ct mai putine
tabele cu putint, altIel spus, de a avea relatii ct mai 'corpolente. Gradul de Iragmentare al bazei tine de
normali:area bazei de date, care, ca parte a procesului de proiectare a BD, se bazez pe dependentele
Iunctionale, multivaloare si de jonctiune ntre atribute.

2.2.6 Restric(ii-utilizator
Restrictiile utilizator mai sunt denumite si restrictii de comportament sau restrictii ale
organizatiei. De obicei, aceste restrictii iau Iorma unor reguli de validare la nivel de atribut, la nivel de
linie/tabel sau a unor reguli implementate prin declansatoare (triggere).
O restrictie la nivel de atribut poate preveni introducerea n baza de date a unor valori din alte
intervale dect cele stabilite, n alte Iormate dect cele acceptate etc. Forma clasic a unei restrictii la
nivel de atribut este o expresie n care apar constante, Iunctii-sistem si, nu n ultimul rnd, atributul
respectiv. La orice editare a atributului cu pricina (declansat n cazul inserrii unei linii n tabela din
care Iace parte, sau la modiIicarea sa) expresia este evaluat si dac rezultatul evalurii este TRUE
(adevrat), atunci inserarea/modiIicarea este permis, iar dac rezultatul este FALSE, atunci
inserarea/modiIicarea este blocat.
Expresia care deIineste o restrictie la nivel de nregistrare poate contine dou sau mai multe
atribute si este evaluat la inserarea sau modiIicarea oricrei linii din tabel. Tabela FACTURI
contine, printre altele dou atribute 'valorice, unul pentru pstrarea valorii totale (inclusiv TVA)
Iacturii respective si un altul care indic 'doar cuantumul TVA colectate pentru Iactur. Majoritatea
produselor si serviciilor comercializate la noi n tar au un procent al taxei pe valoarea adugat de
19. Exist, ns, si produse la care procentul poate Ii 9 sau chiar scutite de TVA (0). De aceea,
TVA colectat pentru o Iactur este mai mic poate Ii egal sau dect 19 din valoarea fr tva. S
punem sub Iorm de Iormul: ValoareaTotal ValoareaFrTVA TVA. Dac Iactura contine
numai produse cu 19: ValoareaTotal ValoareaFrTVA 0.19 * ValoareaFrTVA, sau
ValoareaTotal 1.19 * ValoareaFrTVA. Dar tabela noastr are doar atributele ValoareTotal si
TVAColectat, asa c nlocuim ValoareaFrTVA prin diIerenta celorlalte dou. Scriem:
ValoareTotal 1.19 * (ValoareTotal TVAColectat), si dup calcule de matematic superioar,
TVAColectat * 1.19 0.19 * ValoareTotal, altIel spus TVAColectat ValoareTotal * 0.19 / 1.19.
Exist si alte tipuri de restrictii a cror validare presupune 'citirea unor date aIlate n tabele
diIerite. Spre exemplu, se poate institui o regul care interzice emiterea unei noi Iacturi (o nou
vnzare) dac datoriile Iirmei client sunt mai mari de 200000 RON, iar directorul acesteia nu este
membru n partidul/partidele de guvernmnt. Acestea reclam ntrebuintarea unor proceduri speciale,
numite declansatoare (triggere). Curiosii n-au dect s urmeze specializarea InIormatic Economic.
FEAA nfoEc + CG - 2006/2007 23
2.3 SCHEMA $I CONTINUTUL UNEI BAZE DE DATE RELATIONALE
Asa cum era prezentat n primul capitol, exist dou aspecte complementare de abordare a
bazelor de date: schema (structura, intensia) si continutul (instantierea, extensia). Pentru o BD
relational continutul unei relatii este reprezentat de ansamblul tuplurilor ce o alctuiesc la un moment
dat. Schema unei baze de date contine denumiri ale tabelelor, numele, tipul si lungimea atributelor,
restrictii de unicitate, de non-nulitate, restrictii la nivel de atribut, linie si alte eventuale tipuri de
restrictii de comportament, precum si restrictii reIerentiale. La acestea se adaug cele privind
drepturile utilizatorilor, deIinitia si restrictiile tabelelor virtuale, indecsi etc. Foarte importante n
lumea proIesionistilor dezvoltrii de aplicatii cu bazele de date sunt procedurile stocate programe de
Iorma Iunctiilor, procedurilor, pachetelor si mai ales declansatoarelor (triggerelor) care, dup cum le
spune si numele sunt memorate n schema bazei de date si Iac parte integrant din aceasta.
Schema unei baze de date poate Ii reprezentat graIic, avantajul principal Iiind o mai bun
sugestivitate. Iat cteva reguli pentru reprezentarea graIic a unei BDR
5
:
O tabel se reprezint pe dou linii, pe prima Iiind scris numai numele relatiei iar pe cea de-a doua
numele atributelor. Ordinea prezentrii atributelor nu are important. Totusi, n scopul usurrii
ntelegerii schemei, coloanele care desemneaz cheia primar se dispun succesiv (binenteles, atunci
cnd sunt mai multe). La Iel si coloanele care constituie o cheie strin. n general, cheia primar este
plasat la marginea stng a tabelei (prima sau primele coloane).
Numele coloanelor ce alctuiesc cheia primar se subliniaz cu o linie continu, iar cele care
alctuiesc identiIicatorii secundari se subliniaz cu linie punctat.
Numele unei coloane Iacultative este scris ntre paranteze.
Dac o cheie strin este alctuit din mai multe coloane, se utilizeaz acolada pentru a le grupa.
O restrictie reIerential este reprezentat printr-o sgeat care pleac de la numele coloanei de
reIerint (sau de la vrIul acoladei, n cazul unui grup de reIerint) si are vrIul n atributele tabelei la
care se Iace reIerinta (tabela printe).

n capitolele care vor urma, va Ii utilizat cu precdere o baz de date 'martor, denumit VNZRI, a
crei schem simpliIicat este cea din Iigura 2.5. Discutia tabelelor, atributelor si restrictiilor legate de aceast
baz de date se aIl n Anexa 1 (vezi portalul disciplinei).

Pe lng tabele, atribute si restrictii, dictionarul de date al unei BD relationale contine multe
alte tipuri de obiecte, dintre care vom zbovi Ioarte putin asupra tabelelor virtuale (view-uri) si
procedurilor stocate.
O tabel virtual stabileste o legtur semantic ntre relatii statice si/sau alte relatii dinamice,
neIiind deIinit explicit, prin tupluri proprii, ca o relatie de baz (static), ci printr-o expresie
relational. Continutul (instantierea) relatiei virtuale depinde, la un moment oarecare dat, de continutul
tabelelor de baz din care deriv. Pentru a ntelege mai bine diIerenta, explicatia se poate rezuma
astIel: tabela virtual este cea pentru care pe disc se memoreaz numai schema, nu si continutul.

5
[Hainaut94], pp. 24-25
24 Baze de date

Figura 2.5. Schema simplificat a ba:ei de date JINZRI
Tabelele virtuale oIer oricrui utilizator al unei baze de date posibilitatea prezentrii datelor
n Iunctie de nevoile sale speciIice. De asemenea, ratiuni de securitate si conIidentialitate a anumitor
inIormatii pot conduce la izolarea unor date Iat de utilizatorii neautorizati, lucru deplin posibil prin
intermediul imaginilor. Pornind de la aceleasi tabele de baz, se pot crea un mare numr de tabele
virtuale, n Iunctie de situatie. Tabele virtuale constituie suportul crerii schemelor externe. Odat
deIinit, o tabel virtual poate Ii reIerit ca o tabel de baz oarecare. De asemenea, ca si relatiile de
baz, si "imaginile" pot Ii actualizate, ceea ce atrage modiIicarea tabelelor statice din care deriv. n
aceste situatii apar o serie de probleme. Este clar c modiIicarea continutului tabelelor de baz
presupune modiIicarea continutului tabelei (sau tabelelor) derivate. ns ce inIormatii pot Ii modiIicate
n tabelele de baz, pornind de la modiIicrile tabelei virtuale ? Solutiile implementate n SGBDR-
urile actuale diIer de la caz la caz.
O procedur stocat este o secvent de program (cod) care Iace parte integrant din baza de
date. Avantajele utilizrii procedurilor stocate decurg din Iaptul c acestea sunt parte din structura
(schema) bazei, Iiind pstrare n dictionarul de date (catalogul sistem). Exist mai multe tipuri de
proceduri stocate: Iunctii-utilizator pentru validarea tabelelor, Iunctii pentru calculul unor valori
implicite, proceduri/Iunctii de validare la nivel de linie sau tabel, Iunctii/proceduri de calcul a unor
expresii complexe etc.
Declansatorul (trigger) este un tip special de procedur stocat care este executat automat
cnd un eveniment predeIinit (inserare, actualizare sau stergere) modiIic o tabel. Utilitatea
declansatoarelor este evident la Iormularea unor restrictii mai complexe dect 'suport comenzile
FEAA nfoEc + CG - 2006/2007 25
CREATE/ALTER TABLE, actualizarea automat a unor atribute calculate, jurnalizarea modiIicrilor
suIerite de baza de date, pstrarea integrittii reIerentiale etc.
Exist diIerente sensibile ntre SGBD-uri si n ceea ce priveste sintaxa declansatoarelor,
deoarece acestea sunt redactate n extensiile procedurale ale SQL care prezint diIerentieri majore de
la un productor la altul. Poate Ii evocat, spre exemplu, diversitatea declansatoarelor n Oracle, DB2
etc. Iat de Visual FoxPro.
AstIel, dac n VFP exist numai trei tipuri de declansatoare, pentru adugare, pentru
modiIicare si pentru stergere. n schimb, n Oracle, pentru Iiecare din cele trei operatiuni exist o
prim separare ntre declansatoare lansate naintea operatiei (actualizrii) si cele dup operatiune. La
aceast delimitare se mai adaug si cea dintre triggere la nivel de linie, ce intr n actiune la Iiecare
inserare/modiIicare/stergere a unei linii si cele la nivel de comand care se execut o singur dat,
indiIerent cte linii aIecteaz comanda de actualizare respectiv (row versus statement).
26 Baze de date
CAPITOLUL 3
PROIECTAREA SCHEMEI BAZELOR DE DATE FOLOSIND
NORMALIZAREA

Obiective:
I. Conytientizarea nevoii de normalizare
II. Expunerea cadrului general al normalizrii prin descompunere yi prin sintez
III. Definirea dependen(elor func(ionale, inclusiv a celor par(iale yi tranzitive
IV. Discutarea no(iunilor de rela(ie universal yi a condi(iilor necesare pentru prima
form normalizat
V. Prezentarea detaliat a metodologiei de aducere a unei baze de date n formele
normale 2, 3 yi Boyce-Codd
VI. Definirea dependen(elor multi-valoare yi celei de-a patra forme normale
V. n(elegerea folosirii cheilor surogat yi dependen(elor de incluziune
VI. Ilustrarea ntregului demers al normalizrii pentru mai multe cazuri practice
VII. Conytientizarea ctorva dificult(i yi capcane ale normalizrii


Rezultate ayteptate:
A. n(elegerea modului n care poate fi adaptat normalizarea la proiectarea
schemei bazelor de date
B. Formarea capacit(ii de a proiecta schema oricrei baze de date, pornind de la
cerin(ele unei aplica(ii reale

FEAA nfoEc + CG - 2006/2007 27
3.1 CE ESTE NORMALIZAREA ?
Dintre multiplele metodologii si instrumente de proiectare a structurii unei baze de date, n
acest capitol (si curs) vom trata doar normalizarea. Motivul principal este acela normalizarea lucreaz
strict cu terminologia relational, Ir la mai deIini notiuni speciIice metodologiilor de tip Entittii-
Relatii (E/R), Object-Role Modeling etc: clas de entitti/relatii, cardinalitti, specializare,
generalizare etc.
Totusi, normalizarea este un demers complex. Chiar dac pe parcursul acestui capitol voi
ncerca s Iiu ct mai limpede cu putint, cred c este necesar recurgerea la materialul aditional din
care este extras prezentul material (pentru cei neatenti, tocmai sunteti n mijlocul unui moment
publicitar)
6
.
3.1.1 Nevoia de normalizare
Unul dintre cele mai bune argumente n Iavoarea normalizrii tine de punerea n evident a
ceea ce s-ar ntmpla n absenta sa. S lum un prim exemplu, cel din Iigura 3.1 care este dedicat
stocrii datelor privitoare la studentii Faculttii de Economie i Administrarea Afacerilor (sau oricare
alta), mai ales n ceea ce priveste situatia scolar a acestora. Fiecare student are un identiIicator unic -
Matricol, este nscris la o specializare ntr-un an de studii si sustine examenele la disciplinele din
planul de nvtmnt. Orice disciplin are alocat un numr de credite prin planul de nvtmnt al
specializrii. Fiecare student poate sustine un examen de mai multe ori pn l promoveaz (sau este
exmatriculat). AstIel, Zineanu Ion a picat examenul la Ba:e de date I n prima sesiune (pe 29 ianuarie
2004), dar l-a luat n restante (pe 12 Iebruarie).

STUDENTI_EXAMENE
MatricoI NumePrenume An SpeciaIizare CodDisc
EL13455 Popovici Vasile 3 nformatic economic A3501
EL13456 Zineanu W on 3 nformatic economic A3501
EL13457 Ablaei R Zicu 3 nformatic economic A3501
EL13455 Popovici Vasile 3 nformatic economic A3502
EL13456 Zineanu W on 3 nformatic economic A3502
EL13457 Ablaei R Zicu 3 nformatic economic A3502
EL13456 Zineanu W on 3 nformatic economic A3501
EL13457 Ablaei R Zicu 3 nformatic economic A3502
EL13458 Spag M Michael 3 nformatic economic A3503

DenumireDisc NrCredite DataExamen Nota
Baze de date 6 29/01/2004 8
Baze de date 6 29/01/2004 4
Baze de date 6 29/01/2004 9
Programare vizual i RAD 7 01/02/2004 10
Programare vizual i RAD 7 01/02/2004 8
Programare vizual i RAD 7 01/02/2004 4
Baze de date 6 12/02/2004 8
Programare vizual i RAD 7 15/02/2004 9
Analiza sistemelor informa[ionale 6 04/02/2004 7
Figura 3.1 Relatie supus normali:rii

6
Fotache, M. Proiectarea bazelor de date. Normalizare i postnormalizare. mplementri SQL i Oracle, Editura
Polirom, ai, 2005
28 Baze de date
Deoarece Iiecare linie se reIer la un examen sustinut la o anumit dat de un student, cheia
primar a relatiei este combinatia (Matricol, CodDisc, DataExamen).
Redundanje
Este lesne de observat c relatia de mai sus contine redundante. AstIel, dac un student
sustine, pe parcursul primelor n semestre de studii, 25 de examene, atunci matricolul, numele, anul si
specializarea sunt prezente n toate cele 25 de linii. Dac pentru o disciplin s-au consemnat n baza de
date 1500 de examinri, atunci nu numai codul, ci si denumirea si numrul de credite alocat disciplinei
apar de acelasi numr de ori.
Cu ct baza de date este mai mare, cu att risipita de spatiu este mai important. Chiar dac
spatiul de stocare nu mai este o problem din punctul de vedere al costului, obezitatea unei tabele
precum cea de mai sus poate atrage serioase probleme de vitez n exploatare (timpi de asteptare la
preluarea noilor note etc.).
Anomalii la inserare
S lum n discutie studentii din anul I. Dup examenul de admitere, ce are loc n lunile iulie
si septembrie acestia sunt nmatriculati. Dac, ns, baza de date are schema relatiei de mai sus,
preluarea este imposibil pn n momentul primului examen al studentului respectiv. Aceasta
deoarece n cheia primar sunt incluse si atributele CodDisc si DataEx, iar modelul relational
interzice valori nule pentru atributele-cheie (restrictia de entitate). Ori, la data nmatriculrii, studentii
din anul I nu au nici un examen sustinut (asta ar mai trebui !), iar prima sesiune e abia n ianuarie
viitor, asa c si CodDisc si DataEx sunt n acel moment NULL.
Anomalii la modificare
Presupunem c ntr-o Iurtunoas sedint de catedr se decide ca disciplina Programare
vi:ual i RAD s Iie redenumit Programare I, titulatur sub care v aprea si n Ioile matricole ale
studentilor din actualul an III care vor absolvi, mai devreme sau mai trziu, specializarea Informatic
economic. n baza de date exist cteva sute de nregistrri reIeritoare la studenti examinati la aceast
disciplin, si toate trebuie modiIicate. Dac, dintr-un motiv sau altul, modiIicarea se Iace pe numai o
parte dintre liniile cu pricina, putem aIirma c datele si pierd consistenta. Dup O'Neil & O'Neil,
avem de-a Iace cu o anomalie de modiIicare ntr-o relatie atunci cnd modiIicarea valorii unui atribut
atrage obligativitatea actualizrii aceleasi valori pe mai multe linii
7
.
Anomalii la ytergere
Anomaliile la stergere se maniIest atunci cnd prin eliminarea unei linii dintr-o tabel se
pierd involuntar nu numai inIormatiile despre entitatea reIlectat pe linia respectiv, ci si alte
inIormatii. AstIel, dac stergem ultima linie din relatia de mai sus, cea care contine nota examenului la
Anali:a sistemelor informationale sustinut de studentul Spag Michael pe 4 Iebruarie 2004, se pierd
nu numai datele despre examenul respectiv, ci si toate inIormatiile despre studentul Spag M. Aceasta
deoarece aceasta era singura linie n care aprea studentul cu pricina.

7
[O'Neil & O'Neil 01 ] p.357
FEAA nfoEc + CG - 2006/2007 29
3.1.2 Definirea normalizrii
Proiectarea bazelor de date relationale (BDR) presupune deIinirea atributelor, gruparea lor n
tabele, stabilirea legturilor dintre ele, a mecanismelor de integritate si securitate, Iiind un proces
diIicil n care cunostintele teoretice, experienta, inteligenta, intuitia si creativitatea proiectantilor se
mbin ntr-un mod mai mult sau mai putin armonios. Structura Iinal a BD trebuie s asigure un
echilibru ntre, pe de o parte, obtinerea unui volum maxim de inIormatii ntr-un interval de timp ct
mai scurt si, pe de alt parte, eliminarea anomaliilor de stocare si actualizare, toate n conditiile unui
grad apreciabil de securitate si integritate.
Vzut ca rigoare (matematic sau nu), art (n sensul de curat. interpretabil, dar si de
bazat pe intuitie, creatoare), 'meserie (deprins prin imitatie si desvrsit prin experient), ceea ce
se poate spune cu sigurant despre normalizare este, vorba lui C. J. Date, c nu reprezint un panaceu.
Exist dou mari abordri ale normalizrii, descompunerea si sinteza. Ambele discut despre
relatia initial (universal) si o serie de Iorme normalizare ale bazei de date. ns, n timp ce prin
decompunere relatia initial este ,spart (decompus) n relatii tot mai mici, prin sintez se porneste
de la dependentele dintre atributele din baz si se construieste schema bazei direct ntr-o Iorm
normal acceptabil.
Teoretic, schema unei BD poate contine o singur relatie (tabel) ce grupeaz toate atributele
bazei. Aceasta este relatia universal. Dincolo de avantajul compactrii, relatia universal ridic
serioase probleme privind redundanta datelor si genereaz anomalii importante la adugarea,
modiIicarea sau stergerea unor linii (tupluri), dup cum vzut n Irugalul exemplu din paragraIul 3.1.1.
Ca si consecint direct, este necesar spargerea bazei n mai multe tabele care sunt legate prin
restrictii de integritate reIerential. Este tocmai obiectivul central al normalizrii. Spargerea relatiei nu
trebuie Icut oricum, deoarece apare riscul pierderilor de inIormatii. De asemenea, un numr prea
mare de tabele necesit un eIort sporit pentru controlul bazei si respectarea restrictiilor. n plus, trebuie
s tinem seama de Iaptul c obtinerea multor inIormatii dintr-o baz de date Iragmentat este posibil
prin operatiunea de jonctiune, mare consumatoare de resurse. Normalizarea si propune ca principale
obiective:
minimizarea spatiului necesar stocrii datelor;
minimizarea riscului aparitiei de date inconsistente n cadrul BD;
minimizarea anomaliilor ce pot aprea la actualizare (inserarea datelor, dar mai ales
modiIicare si stergere).;
ameliorarea structurii bazei, reprezentarea diverselor conexiuni dintre atributele bazei.
diminuarea nevoii de reorganizare periodic a modelului.
Obiect al numeroase studii, nu se poate aIirma c exist o unanimitate de idei si instrumente
privind normalizarea. Importanta normalizrii nu trebuie absolutizat, deoarece adesea aceasta vine
uneori n contradictie cu parametri extrem de importanti ai aplicatiilor de lucru cu bazele de date:
vitez de acces, securitate mrit, resurse hard/soIt disponibile, reducerea traIicului pe retea etc. Se
poate spune c o BD riguros normalizat nu este neaprat una optim.
Teoria clasic a normalizrii este construit n jurul a cinci Iorme care n literatura noastr sunt
reIerite ca normale sau normali:ate. Codd, printele modelului relational, a deIinit initial trei Iorme
normale, notate prin 1NF, 2NF si 3NF. ntruct, ntr-o prim Iormulare, deIinitia 3FN ridica ceva
probleme, Codd si Boyce au elaborat o nou variant, cunoscut sub numele Bovce-Codd Normal
30 Baze de date
Form (BCNF). Desi este vorba, n principiu, de o Iormulare mai riguroas a aceleasi 3FN, BCNF este
prezentat separat n majoritatea lucrrilor.

Relatie universal - R
Exist grupuri
repetitive ?
Atomizarea atributelor
Relatia R are
cheie primar ?
Descompunere n relatii
ce au cheie primar
1 FN
Exist DF
partiale ?
Aducerea relatiilor n 2FN
Inceput
Exist DF
tranzitive ?
Aducerea relatiilor n 3FN
3 FN
da
da
da
da
nu
nu
nu
nu
2FN


Exist DF
multivaloare ?
Aducerea relatiilor n 4FN
4 FN
Exist dependente
de jonctiune ?
Aducerea relatiilor n 5FN
5 FN
da
da
nu
nu
Toti determinantii
sunt chei candidate ?
Aducerea relatiilor
n BCFN
BCFN
da nu
SIrsit

Figura 3.2. Etapele clasice ale normali:rii ba:elor de date relationale
Formele 4 si 5, legate de numele lui Ronald Fagin, sunt tratate mai cu retinere, ca s nu spun
pudoare, n literatura consacrat analizei si proiectrii bazelor de date. Ba chiar unele lucrri cu tent
mai pragmatic se opresc declarat la 3FN, pe care o consider suIicient n elaborarea BDR.
Fundamentul normalizrii BDR l constituie dependentele dintre atribute. Primele trei Iorme
normale pot Ii determinate pe baza dependentelor Iunctionale elementare (totale) si tranzitive. Forma a
patra (4FN) se bazeaz pe dependentele multivaloare, n timp ce a cincea Iorm normal (5FN) pe
FEAA nfoEc + CG - 2006/2007 31
dependentele de jonctiune. Problema este c dependentele multivaloare, si (mai ales) cele de jonctiune
sunt diIicil de identiIicat si rar ntlnite n practic.
Normalizarea BDR poate Ii imaginat ca un proces prin care, pornindu-se de la relatia initial R
(universal), se realizeaz descompunerea succesiv a acesteia n sub-relatii dup succesiunea din
Iigura 2.4
8
. Relatia R poate Ii ulterior re-construit din cele n relatii obtinute n urma normalizrii, prin
operatii de jonctiune aplicate asupra acestora.
Nu putem ncheia acest crochiu al normalizrii Ir a insista asupra Iaptului c, esentialmente,
ingredientul acesteia este de natur semantic. Normalizarea reIlect relatii care se maniIest ntre
atribute ale bazei. Este imposibil de normalizat o relatie Ir a cunoaste Ienomenul, procesul pe care l
reIlect.
3.1.3 Descompunere fr pierdere de informa(ii
Descompunerea succesiv a relatiei universale trebuie s se bazeze exclusiv pe dependentele
ntre atribute, altminteri este posibil pierderea de inIormatii. Pentru detalii, vezi |Fotache 2005|,
paragraIul 2.5 (pp.44-46)
3.1.4 Punctul de pornire - rela(ia universal
Prima etap a normalizrii const n identiIicarea inIormatiilor ce trebuie stocate si gestionate
cu ajutorul bazei de date. Este momentul n care la aplicatiile complexe intr n scen analistii de
sistem, cei care observ cum se deruleaz procesele, operatiunile ce constituie obiectul aplicatiei/bazei
de date, discut cu toate categoriile de utilizatori, ncearc s identiIice solutii anterioare de la aceeasi
organizatie sau de la organizatii similare pentru a putea anticipa problemele cele mai diIicile etc.
Pentru aplicatiile mari munca analistilor si proiectantilor este extrem de laborioas si consumatoare de
timp si nervi. Este unul dintre motivele pentru care aceast categorie proIesional are salarii mari si
este destul de "curtat". Noi vom ncerca s ne plasm ntr-o zon mai "aerisit", Ir a cdea in
derizoriu.
Notiunea de relatie universal este unul dintre destulele ingrediente ale modelului relationa
care ncep prin a prea jenant de banal, si din care, n Iinal, Iiecare ntelege ce vrea, Ir a ajunge la un
punct comun, ci doar la un ,nor de puncte de vedere comun. Noi o s considerm relatia universal
drept relatia alctuit din toate atributele identiIicate ca Iiind relevante pentru aplicatie si toate
tuplurile posibile cu valorile acestor atribute
9
. Prin urmare, schema relatiei universale contine toate
atributele bazei de date.

Baza de date VNZRI
Pe parcusul acestui capitol si urmtoarelor ne propunem s elaborm (si) schema unei prime
baze de date prin care s poat Ii gestionate inIormatiile relevante despre vnzrile unei Iirme
comerciale, de productie etc. Pentru o mai bun vizualizare, se poate recurge la o Iorm tabelar de
prezentare a datelor, n care coloanele ar Ii: numele atributului, asa cum este Iolosit n baza de date
(ceva mai scurt), numele ntreg al atributului, tipul atributului, lungimea, explicatii suplimentare,
restrictii etc.

8
Vezi i [Oprea99], p.343
9
Din acest punct de vedere, de plasm mai aproape de accep[iunea lui Chris Date ([Date04], p.195)
32 Baze de date
Tabelul 3.1 este ceva mai modest, avnd doar dou coloane, dedicate numelui atributului si
unor explicatii sumare. Atributele care intereseaz n mod deosebit sunt cele legate de:
clienti: codul, denumirea, adresa, codul postal, localitate, judetul (inclusiv regiunea), codul
Iiscal, numrul de teleIon;
produse: codul, denumirea, unitatea de msur, grupa (textile, ncltminte, buturi
rcoritoare, buturi spirtoase etc.), procentul de TVA aplicat;
Iacturi: numrul, data ntocmirii, clientul, observatii (note despre clauze din Iactur), apoi
produsele vndute n Iactura respectiv: linia pe care apare Iiecare produs, cantitatea si pretul
Iacturat.
ncasri: codul unic asociat Iiecrei ncasri, date despre documentul pe baza cruia se Iace
ncasarea (ordin de plat, cec etc.), numrul Iacturii ncasate, transa ncasat din Iactura
respectiv.
Tabel 3.1. JINZRI - dictionarul datelor (simplificat)
Atribut Descriere
Jud ndicativul auto al jude[ului (2 caractere)
Jude[ Denumirea jude[ului
Regiune Regiunea [rii din care face parte jude[ul
CodPost Codul potal al unei adrese
Localitate Denumirea oraului sau satului
Comuna Denumirea comunei din care face parte satul curent
CodCl Codul firmei client
DenCl Denumirea firmei-client
CodFiscal Codul fiscal al firmei client
StradaCl Strada pe care se afl sediul clientul
NrStradaCl Numrul la care se afla adresa clientului
BlocScApCl Eventualele informa[ii suplimentare despre adresa clientului: bloc, scar, etaj, apartament
TelefonCl Telefonul firmei client
CodPr Codul produsului / sortimentului comercializat
DenPr Denumirea produsului
UM Unitatea de msur a produsului/sortimentului
Grupa Grupa sortimental (Bere, Ciocolat, Cafea etc.) n care se ncadreaz produsul curent
ProcTVA Procentul TVA aplicat n mod obinuit produsului
NrFact Numrul facturii emise
DataFact Data ntocmirii facturii
Obs Observa[ii privitoare la factur
Linie Linia curent (corespunztoare unui produs) dintr-o factur
Cantitate Cantitatea vndut din produs n factur (pe linia curent)
Pre[Unit Pre[ul unitar de vnzare (fr TVA) al produsului n factur (pe linia curent)
Codnc Codul ncasrii
Datanc Data ncasrii (n care banii intr n casierie sau n contul bancar)
CodDoc Codul documentului de ncasare
NrDoc Numrul documentului de ncasare
DataDoc Data la care a fost ntocmit documentul de ncasare
Tran Trana primit din factur prin ncasarea (documentul) curent

Una dintre cele mai importante observatii ce se cuvine a Ii Icute n acest moment tine de
Iaptul c o serie de inIormatii Ioarte importante, precum:
valoarea Ir TVA a unui produs Iacturat (de pe o linie a Iiecrei Iacturi);
TVA calculat pe linia unei Iacturi (pentru un produs vndut);
valoarea cu TVA a unei linii (produs) dintr-o Iactur;
valoarea Ir TVA a unei Iacturi;
TVA colectat aIerent unei Iacturi;
valoarea total (cu TVA) a unei Iacturi;
valoarea total a ncasrilor pentru o Iactur;
valoarea total a vnzrilor ctre Iiecare client;
valoarea total a ncasrilor de la un client;
FEAA nfoEc + CG - 2006/2007 33
restul de plat pentru Iiecare client (diIerenta vnzri - ncasri);
valoarea vnzrilor pentru Iiecare localitate;
valoarea vnzrilor pentru Iiecare judet;
valoarea vnzrilor pentru Iiecare regiune (Moldova, Banat etc.);
si multe altele au Iost eliminate din dictionarul de date, deoarece pot Ii calculate pornind ce la celelalte
prezente n dictionar. Vom vedea ceva mai trziu c atunci cnd este vorba de date accesate n mod
Irecvent, pentru calcularea crora este necesar un consum de resurse important, se poate recurge la
introducerea controlat a unor atribute redundante.
O Iactur contine mai multe linii si poate Ii ncasat n una, dou sau mai multe transe.
Deoarece exist un interval ntre momentul ntocmirii de ctre client a documentului de plat
(DataDoc) si momentul intrrii eIective a banilor n contul (sau casieria) Iirmei (Datanc), se
Iolosesc ambele atribute.

Baza de date FILMOGRAFIE
Pentru un centru de nchirieri video se pune problema constituirii unei baze de date cu
inIormatii despre Iilmele aIlate pe casetele sau DVD-urile oIerite (legal) spre nchieriere. Fiecare Iilm
are un cod unic (identiIicator), iar atributele principale sunt cele din tabelul 3.2.
Tabel 3.2. FILMOGRAFIE - dictionarul datelor (simplificat)
Atribut Descriere
dFilm Codul unic al filmului
TitluOriginal Titlul n englez, francez etc., aa cum apare la lansarea filmului
TitluRO Traducerea romneasc a titlului original
AnLans Anul lansrii
Productori Productorul sau productorii filmului
Regizori Regizorul sau regizorii filmului
Distribu[ie Actorii i rolurile interpretate n film
Genuri Genul/genurile la care se ncadreaz filmul (horror, comedie etc.)
Premii Numele premiului - tipul (Oscar, Leul de argint, Ursul de aur etc.), categoria (cel mai bun film,
cel mai bun actor n rol principal) anul premiului i, eventual, numele actorului.

Un Iilm poate Ii produs si regizat de una, dou sau mai multe persoane. Pentru Iiecare actor
distribuit n Iilm intereseaz si personajul sau personajele (dac actorul e n dublu rol) interpretate. O
pelicul se poate ncadra la mai multe categorii (dram, comedie) simultan. Dac un premiu se reIer
la regie, scenariu etc., intereseaz numele, tipul si anul decernrii, iar dac se reIer la o perIormant
actoriceasc, la inIormatiile anterioare se adaug si numele actorului laureat. Practic, dou tupluri din
aceast relatie s-ar prezenta c n Iigura 3.3.

IdFiIm TitIuOriginaI TitIuRO AnLans Productori Regizori
11899 As Good As t Gets Mai bine nu se poate 1997 James Brooks, Bridget Johnson,
Kristi Zea
James Brooks
12345 Bicentennial Man Omul bicentenar 1999 Michael Barnathan, Chris
Columbus, Gail Katz
Chris Columbus

Distribu|ie Genuri Premii
Jack Nicholson (Levin Udall)
Helen Hunt (Carol Connelly)
Greg Kinnear (Simon Bishop)
Cuba Gooding Jr. (Frank Sachs)
comedie
dram
romantic

Oscar - cel mai bun actor n rol principal (Jack Nicholson) - 1998
Oscar - cea mai bun actri[ n rol principal (Helen Hunt) - 1998
Globul de aur - cea mai bun imagine - 1998
Globul de aur - cel mai bun actor ntr-o comedie/musical (Jack
Nicholson) - 1998
Globul de aur - cea mai bun actri[ ntr-o comedie/musical
(Helen Hunt) - 1998
Robin Williams (Andrew Martin)
Embeth Davidtz (Little Miss
SF
dram

34 Baze de date
Amanda Martia / Portia
Charney)
Sam Neil (Richard Martin)
Oliver Platt (Rupert Burns)
Kiersten Warren (Galatea)
romantic
Figura 2.5. O descompunere a relatiei universale FILMOGRAFIE
Aceste dou relatii universale, ca si altele, vor Ii supuse, n capitolele urmtoare, normalizrii
si tuturor discutiilor si problemelor legate de acest demers.
3.2 PRIMA FORM NORMALIZAT
Prima Iorm normalizat (1NF) este, n general, tratat cu superIicialitate de majoritatea
practicienilor n materie de proiectare a bazelor de date. Aceasta deoarece principala cerint
atomicitatea valorilor este un deziderat usor de ndeplinit, cel putin la prima vedere. Cele mai
sensibile chestiuni n aducerea relatiilor n 1NF sunt legate de atomicitate, eliminarea grupurilor
repetitive, precum si de stabilirea cheii primare, cheie primar care devine o problem delicat atunci
cnd se porneste de la o relatie cu zeci sau sute de atribute.
Pe de alt parte, notiunea de atomicitate este una destul de alunecoas. Desi n primele lucrri
Codd nu Iormuleaz o deIinitie riguroas a atomicittii, timp de aproape trei decenii majoritatea
autorilor din "zona" relationalului au considerat ca pe o prim "porunc" a unei relatii (tabele)
necesitatea ca valoarea oricrui atribut pe orice linie (tuplu) s Iie una scalar (atomic,
nedecompozabil). De ctva timp, ns, Chris Date si alti relationisti ncearc c depseasc limitele
atomicittii, nlocuind domeniile cu tipuri care pot Ii att scalare, ct si compozite (deIinite de
utilizator).
Teoria normalizrii nu Iace parte, propriu-zis, din modelul relational. Dintre toate Iormele
normalizate, doar prima are caracter de obligativitate. O baz de date este normalizat dac toate
relatiile (tabelele) care o alctuiesc se aIl mcar n 1NF. Celelalte Iorme normale sunt dezirabile
pentru diminuarea redundantelor, spatiului ocupat pe disc sau anomaliilor maniIestate la actualizare,
ns nu sunt obligatorii.
Dup Codd, o relatie este in prima form normal dac. nici unul dintre domeniile sale nu
contine elemente care sunt, la randul lor, seturi (ansambluri)
10
. Se cuvine de adugat remarca lui Date
care crede ca ar Ii Iost mai nimerit ca, n locul termenului domenii, Codd s-l Ii Iolosit pe cel de
atribute. Actualmente, multi "relationisti" preIer termenul tip celui de domeniu
11
.
Unele lucrri
12
deIinesc o relatie aflat in 1NF ca acea relatie in care fiecare atribut pre:int
numai valori atomice, adic toate atributele sunt ne-decompo:abile; dup R.Riordan, o relatie este n
1NF dac domeniile pe care sunt definite atributele relatiei sunt scalare
13
. n editia a treia a crtii
dedicate sistemelor de baze de date, Connoly si Begg sunt mai transanti: o relatie in 1NF este o relatie
in care intersectia oricrei linii cu oricare coloan contine o valoare i numai una
14
. AstIel, 1NF
respinge ideea de set de valori, tuplu de valori sau combinatia acestora ca valoare a unui singur atribut
pe un oricare tuplu (linie) a relatiei.

10
[Codd72]
11
[Date04]
12
[Date86], [Miranda&Busta90], [Connoly s.a.96], [Dollinger98]
13
[Riordan99]
FEAA nfoEc + CG - 2006/2007 35
Alti autori Iormeaz explicit pentru 1NF si restrictia: toate atributele ce compun relatia s fie
in dependent functional fat de cheia relatiei, ceea este, oarecum, o tautologie, ntruct una dintre
"poruncile" valabile pentru orice tabel stipuleaz negru pe alb c ntr-o relatie nu pot exista dou
tupluri identice sau, altIel spus, ntr-o relatie trebuie s existe mcar un atribut sau combinatie de
atribute ale cror valori s deosebeasc orice tuplu de toate celelalte sau orice relatie posed o cheie
primar.
Formularea care a generat cele mai multe conIuzii este legat de notiunea de grupuri
repetitive
15
: O relatie n 1NF nu trebuie s contin grupuri repetitive.
De obicei, notiunea de grup repetitiv este raportat direct la cea de atomicitate. DiIerentierea
atomicitate grup repetitiv apare n |Lungu s.a.95|, pentru care un atribut atomic este unul simplu (ne-
compus): ,O relatie este n 1NF dac domeniile pe care sunt deIinite atributele relatiei sunt constituite
numai din valori atomice (elementare). n plus, un tuplu nu trebuie s contin atribute sau grupuri de
atribute repetitive
16
. Din pcate, autorii se opresc aici cu deIinitia, pstrnd o remarcabil discretie
vis-a-vis de ceea ce consider grup repetitiv. La Iel stau lucrurile si la dna. Ileana Popescu
17
.
Un plus de claritate aduce deIinitia lui Toby Teorey, pentru care o relatie este n 1NF dac si
numai dac toate coloanele contin numai valori atomice; aceasta nseamn c nu exist grupuri
(coloane) repetitive in cadrul vreunei linii a tabelei. Imediat autoarea precizeaz c un grup repetitiv
apare intr-o tabel atunci cand unui atribut multi-valoare ii sunt permise dou sau mai multe valori
repre:entate in cadrul unei aceleai linii
18
. Sau, dup cum spunea Chris Date pn n editia a sasea a
celei mai cunoscute crti a sa, un grup repetitiv reprezint o coloan care contine cteva valori n
Iiecare linie, sau, altIel spus, un numr diIerit de valori pe linii diIerite
19
.
n concluzie, aducerea unei relatii n 1NF presupune discutarea urmtoarelor elemente:
raportul atribut simplu/atribut compus;
grupuri repetitive de atribute (pe orizontal);
grupuri repetitive de valori n cadrul Iiecrei celule a tabelei.
Atribute simple yi atribute compuse
Primele vizate de 'stigmatul neatomicittii sunt atributele compuse. Cu ani buni n urm, n
cursurile de proIil, exemplul clasic al unui atribut compus era DataCalendaristica, alctuit, cum
altIel, din cmpurile: Ziua, Luna, An. Era vremea nIloritoare a COBOLului si FORTRANului, cnd
nu existau mecanisme de declarare si gestionare a variabilelor si atributelor de tip DATE; veriIicarea
corectitudinii datei calendaristice cdea n sarcina programatorului ce trebuia s scrie o rutin special.
Astzi, nu exist SGBD sau mediu de programare care s nu prezinte tipul de dat DATE prin
care se gestioneaz simultan toate cele trei elemente; prin Iunctii de conversie se pot obtine: ziua
(DAY), luna (MONTH), anul (YEAR), ba chiar calcula numrul de zile, luni, ani dintre dou date

14
[Connoly & Begg 02], p.388
15
[Date86], [Pratt&Adamski91], [Oprea99]), [Lungu s.a.95]
16
[Lungu s.a. 95], p.169
17
[Popescu 01], p.78
18
[Teorey99], p.99
19
Preluare din edi[ia a opta a cr[ii ([Date 04], p.153), unde Date se autociteaz pentru a demonstra c
n[elesese greit no[iunea de domeniu (tip) i, n consecin[ greise atunci cnd a formulat defini[ia 1NF.
36 Baze de date
calendaristice si alte minuntii. Ca s nu mai vorbim de tipul DATETIME si acesta omniprezent n
produsele soItware ale zilelor noastre.
Un alt exemplu celebru privind atribute compuse (non-atomice) este Adresa, discutat n
capitolul 2. Fiind alctuit din Strada, Numar, Bloc, Scara, Etaj, Apartament, plus CodPostal
(dup noul sistem de codiIicare) discutia despre atomicitatea adresei pare de prisos, iar descompunerea
sa imperativ. Din nou ns trebuie s ne raportm la obiectivele bazei. Fr ndoial c, pentru BD a
unei Iiliale CONEL sau ROMTELECOM, sau pentru politie, preluarea separat a Iiecrui element
constituent al adresei este vital. Intereseaz, spre exemplu, ce abonati sunt pe strada Tran:itiei sau
cte cereri sunt depuse de cetteni de pe strzile Lascr Catargi, Titu Maiorescu si Marina Scupra.
Sau, un cioranian ce lucreaz n cadrul Politiei, ar putea Ii interesat s aIle dac gradul de sinucidere al
persoanelor ce locuiesc la etajul trei este mai mare dect cel al persoanelor de la parter.
Cu totul altIel stau lucrurile pentru un importator direct, pentru un mare en-grossist sau pentru
o Iirm de productie. Partenerii de aIaceri ai acestora sunt persoane juridice, iar adresa intereseaz
numai la nivel general. Este drept c imediat dup Revolutie deveniser mari Iurnizori nationali de
cupru si aluminiu si persoane Iizice (vezi cazul bulibasei din Ciurea, dar asta-i alt poveste.).
n relatia universal FILMOGRAFIE, al crei dictionar de date simpliIicat este cel din tabelul
3.2, cel putin dou atribute sunt compuse si trebuie "sparte", Distributie si Premii. AstIel, n
Distributie pot Ii delimitate mcar dou inIormatii, Actor si Rol. n cazul premiilor, ar trebui
detaliat discutia prin introducerea atributelor:
denumire premiu (Oscar, Globul de aur etc.);
locul atribuirii (Hollywod, Cannes, Berlin, Venetia, Bucuresti etc.);
categoria (regie, scenariu, actor n rol principal etc.)
anul decernrii;
numele actorului, dac categoria este pentru interpretare.
AstIel, noua Iorm a dictionarului de date este cea din tabelul 3.3.
Tabel 3.3. FILMOGRAFIE - dictionarul datelor (simplificat) - versiunea 2
Atribut Descriere
dFilm Codul unic al filmului
TitluOriginal Titlul n englez, francez etc, aa cum apare la lansare filmului
TitluRO Traducerea romneasc a titlului original
AnLans Anul lansrii
Productori Productorul sau productorii filmului
Regizori Regizorul sau regizorii filmului
Rol Rolul din film
Actor Actorul care interpreteaz rolul/filmul curente
Genuri Genul/genurile la care se ncadreaz filmul (horror, comedie etc.)
DenPremiu Numele premiului - tipul (Oscar, Leul de argint, Ursul de aur etc.)
LocDecernare Locul n care se organizeaz festivitatea sau festivalul
Categorie Categoria premiului (pentru ce anume se acord premiul)
AnPremiu Anul decernrii

Concluzionnd n termeni rabinici, ambele variante, descompunerea sau nedescompunerea
atributelor compuse, sunt valabile de la caz la caz, alegerea solutiei Iiind n concordant cu speciIicul
bazei de date (si inspiratia proiectantului).
FEAA nfoEc + CG - 2006/2007 37
Despre grupuri repetitive yi urmrile lor
O relatie (tabel) n 1NF nu trebuie s contin atribute care se repet ca grupuri. ntr-o alt
Iormulare, toate liniile unei tabele trebuie s contin acelasi numr de atribute. Fiecare celul a tabelei
(intersectia unei coloane cu o linie), altIel spus, valoarea unui atribut pe o linie (nregistrare), trebuie
s Iie atomic. Dup |Connoly s.a.96|, un grup repetitiv este un atribut sau grup de atribute dintr-o
tabel care apare cu valori multiple pentru o singur aparitie a cheii primare a tabelei ne-normalizate.
S lum exemplul tabelei BIBLIOTEC din Iigura 3.4. Tabela gestioneaz inIormatii despre
crtile existente n depozitul bibliotecii Faculttii de Economie i Administrarea Afacerilor (FEAA).
De remarcat c n blibliotec exist dou exemplare ale crtii cu ISBN-ul 973-683-709-2 si trei
exemplare de cea dedicat Visual FoxPro. Prima carte a Iost scris de patru autori si i sunt asociate
opt cuvinte-cheie, iar a doua are un singur autor. Relatia nenormalizat contine trei grupuri repetitive:
Cote, Autori si CuvinteCheie.
BIBLIOTEC
ISBN TitIu Cote Autori
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii
aplica[iilor profesionale
-13421, -13422,
-13423
Marin Fotache, oan Brava, Ctlin
Strmbei, Liviu Cre[u
973-683-709-2 SQL. Dialecte DB2, Oracle i
Visual FoxPro
-10678, -10679 Marin Fotache

Editura LocSediuEd AnApari|ie CuvinteCheie
Polirom ai 2002 baze de date, SQL, proceduri stocate, FoxPro,
formulare, orientare pe obiecte, client-server, web
Polirom ai 2001 baze de date, algebr rela[ional, SQL
Figura 3.4. Relatia universal nenormali:at BIBLIOTEC
n paragraIele 3.3.1 (pp.55-56), 3.3.2 (pp.57-61) si 3.3.3 (pp.61-67) din |Fotache 2005| sunt
prezentate cteva solutii de eliminare a grupurilor repetitive:
adugarea de atribute suplimentare (grupuri repetitive pe orizontal);
adugarea unui numr minim de linii o valoare atomic pentru Iiecare atribut compozit;
adugarea unui nr. de linii egal cu suma valorilor elementare ale atributelor de tip grup repetitiv
adugarea unui numr maxim de tupluri egal cu produsul valorilor elementare ale atributelor de tip
grup repetitiv (vezi Iigura 3.5).
BIBLIOTEC_TUPLURI_NOI_SOLUTIA_3 (fragment)
ISBN TitIu Cot Autor
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale -13421 Marin Fotache
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale -13421 oan Brava
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale -13421 Ctlin Stmbei
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale -13421 Liviu Cre[u
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale -13421 Marin Fotache
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale -13421 oan Brava
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale -13421 Ctlin Stmbei
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale -13421 Liviu Cre[u
... (nc 88 de linii pentru cartea de Visual FoxPro, plus 6 pentru cea de SQL )

Editura LocSediuEd AnApari|ie CuvntCheie
Polirom ai 2002 baze de date
Polirom ai 2002 baze de date
Polirom ai 2002 baze de date
Polirom ai 2002 baze de date
Polirom ai 2002 SQL
Polirom ai 2002 SQL
Polirom ai 2002 SQL
Polirom ai 2002 SQL
...
Figura 3.5. Completarea cu tupluri - solutia 3
38 Baze de date
eliminarea grupurilor de repetitive prin contruirea de noi relatii.

Trebuie precizat, ns, c nu ntotdeauna grupurile repetitive reprezint o problem major.
Spre exemplu, ntr-o relatie gen PERSOANECONTACT atributul Telefoane poate avea valori ne-
atomice, deoarece pot exista mai multe numere att la birou, ct si mobile (multi manageri au cte un
aparat pe Iiecare retea - Orange, Conex, Zapp)...
3.3 DEPENDENTE FUNCTIONALE
Problema stabilirii dependentelor dintre atribute este Iundamental n procesul elaborrii
bazelor de date relationale. Aducerea structurii bazei ntr-o variant care minimizeaz redundantele si
anomaliile maniIestate la adugarea/modiIicarea/stergerea unor linii din tabele presupune parcurgerea
unui proces de normalizare a relatiilor, normalizare care este centrat tocmai pe conceptul de
dependent dintre atributele bazei.
3.3.1 Defin(ii
Dependenta Iunctional reprezint o generalizare a conceptului de cheie primar
20
. Desemnm
prin Data2 un atribut sau combinatie de atribute dintr-o relatie oarecare si prin Data1 un alt atribut
sau grup de atribute din aceeasi relatie. Se spune c Data2 este n dependent functional (sau
depinde Iunctional) de Data1 atunci cnd cunoasterea unei valori pentru Data1 permite
determinarea (cunoasterea) a maximum o valoare pentru Data2. Data1 se numeste sursa sau
determinantul dependentei Iunctionale, iar Data2 reprezint destinatia (scopul sau determinatul)
dependentei Iunctionale.
Formal, dac notm relatia R A
1
, A
2
,...., A
n
} - unde R este numele relatiei, A
i
sunt atributele
relatiei R - si prin X si Y dou subansambluri din A
1
, A
2
,...., A
n
}, se spune c exist o dependent
Iunctional ntre X si Y (simbolizat XY) dac si numai dac :
Iiecare aparitie (valoare) a lui X poate Ii asociat unei singure aparitii a lui Y,
dou aparitii identice ale lui X nu pot Ii asociate dect aceleiasi aparitii a lui Y.
ntr-o prezentare si mai explicit, Date
21
deIineste dependenta Iunctional dup cum urmeaz: dat
Iiind o relatie R, subansamblul de atribute Y din R depinde Iunctional de subansamblul X (tot din R),
dac si numai dac, ori de cte ori dou tupluri din R prezint aceeasi valoare pentru X, obligatoriu
valoarea celor dou tupluri este identic si pentru Y.
Se spune despre o dependent c este trivial dac si numai dac destinatia este un subset al
sursei: dac Y X, atunci X Y.

Revenim asupra relatiei universale VNZRI prezentat n tabelul 3.1. Cunoasterea numrului
Iacturii permite determinarea cu exactitate a codului clientului, deoarece o Iactur este (conIorm legii
si metodologiei n vigoare) ntocmit pentru un singur client. Se poate scrie:
NrFact DataFact; NrFact CodCl; NrFact Obs

20
Vezi i [Garcia-Molina s.a.02], [Date86]
21
[Date86], p.365
FEAA nfoEc + CG - 2006/2007 39
dar si
NrFact (DataFact, CodCl); NrFact (DataFact, CodCl, Obs)

Situatia de mai sus se ncadreaz n cazurile n care sursa (determinantul) este cheia primar a
relatiei. Implicit, n orice relatie R exist dependentele Iunctionale: cheia lui R celelalte atribute
ale lui R.
Lum un alt exemplu: un cod postal nu poate desemna adrese din orase si comune diIerite. Se
poate scrie, deci: CodPostal Localitate si CodPostal Judet.

Observa(ii
1. Uneori, nceptorii au probleme n ceea ce priveste "sensul" dependentelor Iunctionale. Dependenta
Iunctional CodPostal Localitate nu nseamn c o localitate are un singur cod postal, ci,
invers, c unui cod potal ii corespunde o singur localitate.
2. dependent Iunctional n care scopul (destinatia) este alctuit dintr-un singur atribut se
numeste dependent functional canonic sau dependent Iunctional n Iorm canonic
22
.

Dou atribute nu sunt n dependent Iunctional atunci cnd cunoasterea unei valori oarecare
a primului atribut:
Iie nu permite cunoasterea nici uneia dintre valorile celui de-al doilea (nu exist nici un
"raport" ntre cele dou atribute); n acest caz dependenta ne-Iunctional echivaleaz cu
inexistenta vreunei dependente ntre cele dou atribute;
Iie permite cunoasterea mai multor valori ale celui de-al doilea atribut.

n relatia VNZRI ntre atributele DataFact si CodCl nu exist dependent Iunctional. O
valoare a atributului DataFact nu Iurnizeaz nici o inIormatie cu privire la valoarea de pe aceeasi
linie a atributului CodCl. Se scrie: DataFact / CodCl. De asemenea, deoarece pentru un client
se pot ntocmi mai multe Iacturi (aIerente Iiecrei vnzri): CodCl / NrFact. ntr-o Iactur se
poate consemna vnzarea mai multor produse/servicii; prin urmare, unei valori a NrFact, i corespund
mai multe valori ale atributului CodPr. Se noteaz: NrFact / CodPr.

S examinm n continuare tabela de mai jos.
NotaContabiI Data Opera|iune ContDebitor ContCreditor Suma
150 30.11.2006 1 300 401 10000000
150 30.11.2006 1 4426 401 1800000
150 30.11.2006 2 401 5311 7000000
150 30.11.2006 2 401 5121 4800000
151 01.12.2006 1 5121 700 5250000
Figura 3.6. Tabela LINIIARTICOLECONTABILE
- o not contabil este alctuit din mai multe articole contabile:
(NotaContabila, Data) / Operatiune
- un articol contabil (nregistrare) poate Ii compus, adic alctuit din mai multe corespondente
ContDebitor ContCreditor:
(NotaContabila, Data, Operatiune) / ContDebitor
(NotaContabila, Data, Operatiune) / ContCreditor
(NotaContabila, Data, Operatiune, ContDebitor) / ContCreditor

22
[Saleh94], p.76. Vezi i [Garcia-Molina s.a 01], p.89
40 Baze de date
(NotaContabila, Data, Operatiune, ContCreditor) / ContDebitor
Atunci cnd Iirmele si centralizeaz operatiunile, utiliznd de la o lun la alta aceleasi numere pentru
notele contabile: NotaContabila / Data.
Pe lng aceste dou exemple, am mai putea aminti Iaptul c localitti cu aceeasi denumire
exist n mai multe judete. Spre exemplu, localitatea Jintori exist n judetele Vrancea, Galati, Iasi,
Neamt etc. Aceasta nseamn c: Localitate / Judet
Dependentele Iunctionale reprezint legturi semantice ntre atribute ale bazei de date. Au Iost
propusi algoritmi de identiIicare si gestionare a dependentelor Iunctionale ntr-o relatie. Cea mai mare
parte a acestora sunt total inutili, pentru c, eIectiv, nimeni nu poate stabili o dependent Ir a
cunoaste regula sau restrictia care se ascunde n spatele acesteia, altIel spus, Ir a cunoaste temeinic
realitatea modelat. Cu att mai mult calculatorul care are mari probleme n a lucra la nivel semantic,
ca s nu mai vorbim de cel pragmatic.
3.3.2 Dependen(e func(ionale cu sursa compus
Exist dependente Iunctionale care prezint n partea stng (sursa dependentei Iunctionale
sau determinantul) dou sau mai multe atribute. Acestea sunt dependentele Iunctionale cu sursa
compus. AstIel, n relatia VNZRI:
- o Iactur contine mai multe linii: NrFact / Linie
- pe o Iactur pot aprea mai multe produse: NrFact / CodPr
- un produs apare, de obicei, pe mai multe Iacturi: CodPr / NrFact
- pentru Iiecare Iactur, o linie este unic: (NrFact, Linie) CodPr; (NrFact, Linie)
Cantitate; (NrFact, Linie) PretUnit
- dac stabilim c un produs nu poate aprea pe o Iactur dect o singur dat, atunci sunt valabile DF:
(NrFact, CodPr) Linie; (NrFact, CodPr) Cantitate; (NrFact, CodPr)
PretUnit

n tabela LINIIARTICOLECONTABILE din Iigura 3.6 stabilirea dependentelor Iunctionale
depinde de modul n care Iirma si organizeaz evidenta contabil. AstIel, marea majoritate a Iirmelor
si centralizeaz operatiunile, pe tipuri (intrri de materiale, consumuri de materiale, operatiuni legate
de casierie, conturile din banc etc.), utiliznd, de la o lun la alt, aceleasi numere pentru notele
contabile (ex: nota 1 - ncasri prin casierie, nota 10 - pentru nregistrarea amortizrii etc.). n acest
caz, exist dependenta Iunctional: (1) (NotaContabila, Data, Operatiune, ContDebitor,
ContCreditor) Suma. Dac unele Iirme, cu un volum de activitate mai redus, ar conta Iiecare
document primit/ntocmit, genernd astIel o nou not contabil, dependentele Iunctionale s-ar putea
scrie sub Iorma: (2) NotaContabila Data; (3) (NotaContabila,Operatiune, ContDe-
bitor, ContCreditor) Suma.
Fireste, este valabil si dependenta (4) (NotaContabila, Operatiune, ContDebitor,
ContCreditor) Data

Tabela BIBLIOTECTUPLURINOISOLUTIA3 din Iigura 3.5, aIlat n prima Iorm
normal, prezint ca si cheie primar combinatia (Cota, Autor, CuvntCheie). De aceea, se pot
inventaria urmtoarele cinci dependente Iunctionale, n care destinatii sunt atributele necheie.
FEAA nfoEc + CG - 2006/2007 41
(1) (Cota, Autor, CuvntCheie) ISBN
(2) (Cota, Autor, CuvntCheie) Titlu
(3) (Cota, Autor, CuvntCheie) Editura
(4) (Cota, Autor, CuvntCheie) LocSediuEd
(5) (Cota, Autor, CuvntCheie) AnAparitie
Alte elemente luate n discutie pentru stabilirea DF:
- o carte poate Ii scris de mai multi autori: ISBN / Autor
- un autor scrie mai multe crti: Autor / ISBN si despre mai multe subiecte: Autor /
CuvntCheie
- ntr-o carte sunt tratate mai multe subiecte: ISBN / CuvntCheie
- pentru o carte sunt n depozit mai multe exemplare: ISBN / Cota
Cota este codul care identiIic n mod unic o carte aIlat n depozit, asadar:
(6) Cota ISBN (7) Cota Titlu (8) Cota Editura
(9) Cota LocSediuEd (10) Cota AnAparitie
Fiecare titlu de carte este identiIicat Ir ambiguitate de ISBN:
(11) ISBN Titlu (12) ISBN Editura (13) ISBN LocSediuEd
(14) ISBN AnAparitie
O editur are un singur sediu central: (15) Editura LocSediuEd.
Prin urmare, dintre cele 15 DF inventariate, primele cinci au sursa compus, celelalte sursa
simpl.

n baza de date VNZRI, dat Iiind numrul de atribute si speciIicul aplicatiei, n acest caz
discutiile sunt ceva mai laborioase:
- Iiecare judet are un nume si un indicativ unice:
(1) Jud Regiune (2) Judet Regiune (3) Jud Judet
(4) Judet Jud
- pe baza discutiei de la exemplul anterior (CODURINOIV2):
(5) CodPost Localitate (6) CodPost Comuna (7) CodPost Jud
(8) CodPost Judet
- Iiecare Iirm-client este identiIicat n mod unic att prin cod (CodCl):
(9) CodCl DenCl (10) CodCl CodFiscal (11)CodCl StradaCl
(12) CodCl NrStradaCl (13) CodCl BlocScApCl
(14) CodCl TelefonCl (15) CodCl CodPost (16) CodCl Localitate
(17) CodCl Comuna (18) CodCl Jud (19) CodCl Judet
(20) CodCl Regiune
- ct si prin cod Iiscal (CodFiscal):
(21) CodFiscal DenCl (22) CodFiscal CodCl
(23) CodFiscal StradaCl (24) CodFiscal NrStradaCl
(25) CodFiscal BlocScApCl (26) CodFiscal TelefonCl
(27) CodFiscal CodPost (28) CodFiscal Localitate
42 Baze de date
(29) CodFiscal Comuna (30) CodFiscal Jud
(31) CodFiscal Judet (32) CodFiscal Regiune
- elementul care identiIic un produs este codul acestuia:
(33) CodPr DenPr (34) CodPr UM (35) CodPr Grupa
(36) CodPr ProcTVA
- o Iactur se ntocmeste pentru un singur client:
(37) NrFact CodCl (38) NrFact CodFiscal
- o Iactur se ntocmeste o singur dat: (39) NrFact DataFact (40)NrFact Obs
- o Iactur contine mai multe linii: NrFact / Linie
- Iiecare linie dintr-o Iactur se reIer la vnzarea unui produs (CodPr), indicnd cantitatea si pretul
unitar la care s-a Icut vnzarea:
(41) (NrFact, Linie) Cantitate (42) (NrFact, Linie) PretUnit
(43) (NrFact, Linie) CodPr (44) (NrFact, Linie) DenPr
(45)(NrFact, Linie) UM (46) (NrFact, Linie) ProcTVA
- ntr-o Iactur, un produs apare pe o singur linie:
(47) (NrFact, CodPr) Cantitate (48) (NrFact, CodPr) PretUnit
(49) (NrFact, CodPr) Linie
- o ncasare are la baz un document primar (Ordin de plat, Chitant etc.):
(50) Codnc Datanc (51) Codnc CodDoc
(52) Codnc NrDoc (53) Codnc DataDoc
- documentele de ncasare pot prezenta numere similare de la un client la altul; spre exemplu, Ordinul
de plat cu nr. 101 poate Ii emis de mai multi clienti (binenteles, este vorba de trei documente diIerite
care au ns acelasi numr, poate chiar si dat): (CodDoc, NrDoc) / DataDoc; (CodDoc,
NrDoc) / NrFact; (CodDoc, NrDoc) / CodCl
- o Iactur este ncasat n mai multe transe: NrFact / Codnc
- o ncasare poate achita mai multe Iacturi: Codnc / NrFact
- ntr-o ncasare, o trans se reIer la o singur Iactur: (54) (Codnc, NrFact) Transa,
nu ns si (Codnc, Transa) NrFact, deoarece, ntr-o aceeasi ncasare pot exista dou transe
egale (ex. 5 000 000 lei) reIeritoare la dou Iacturi diIerite.
3.3.3 Dependen(e func(ionale simetrice yi redundante
Deseori, o baz de date sau relatie prezint mai multe chei candidat. Alegerea dintre acestea a
cheii primare are n vedere, pe lng unicitate, compozitie minimal si valori nenule ale oricrui
atribut component, si elemente ce tin de Iacilitatea utilizrii: usurinta retinerii (de ctre utilizator),
lungime ct mai mic, constant n timp etc.
n procesul normalizrii, problemele ridicate de aceste dependente reciproce dintre cheile
candidat trebuie tratate cu prudent. De cele mai multe ori, este recomandat ca dintre dependentele ale
unei relatii s Iie eliminate toate cele n care sursa este o cheie candidat si pstrarea numai celor n care
determinantul este atributul cheie-primar.
FEAA nfoEc + CG - 2006/2007 43
Revenim la cele 54 de dependente din relatia universal VNZRI tratate n urm cu cteva
pagini. Este evident c dependentele (3), Jud Judet, si (4), Judet Jud, sunt simetrice.
Desi corecte, si dependentele (1) - Jud Regiune - si (2) - Judet Regiune - "se calc
pe picior. Pentru comoditate, putem alege atributul Jud ca identiIicator "de baz" al unui judet,
eliminnd (pe nedrept), pe lng (4), toate DF n care sursa simpl este atributul Judet iar destinatiile
identice cu cele ale dependentelor n care surs este Jud. Ce-i drept, eIortul nu este chiar
supraomenesc, deoarece este o singur dependent de acest tip, (2).
La Iel se pune problema si pentru perechile de atribute CodCl si DenCl si CodCl si
CodFiscal. Toate identiIic un acelasi tip de entitate - o Iirm client. Investim CodCl drept
"reprezentant unic" al unui client. DenCl neIiind luat prea mult n seam n setul de DF, avem de
eliminat doar DF n care CodFiscal este surs simpl: (21) - (32). n privinta perechii CodPr si
DenPr nu avem a ne epuiza, deoarece, aproape intentionat, au Iost omise din setul DF cele n care
DenPr apare ca surs.

Aten(ie ! Nu Iacem acelasi lucru n relatia BIBLIOTECTUPLURINOISOLUTIA3 cu atributele Cota si
ISBN, deoarece primul se reIer la un exemplar "Iizic" al unei crti din bibliotec, n timp ce al doilea se reIer
la un titlu (carte publicat la o editur).

Tipul acesta de redundant e usor de identiIicat si eliminat, chiar dac nu se leag vizibil de
nici o teorem sau lem ce constituie Iundamentul normalizrii. Setul DF contine ns si un alt tip de
redundant/circularitate. AstIel, deoarece Iiecare linie dintr-o Iactur se reIer la un produs vndut la
un pret unitar si ntr-o anumit cantitate, sursele DF n care destinatiile sunt Cantitate, PretUnit
(plus DenPr, UM si ProcTVA) pot Ii att (NrFact, Linie), ct si (NrFact, CodPr). Procednd
analog situatiei de mai sus (dar cu mai mult strngere de inim), decidem ca Iiecare linie/produs
dintr-o Iactur s Iie identiIicat de sursa (NrFact, Linie). Asa c eliminm dependentele n care
surs este "concurentul", adic (NrFact, CodPr) si destinatiile sunt identice: (47), (48) si (49).
3.3.4 Graful dependen(elor func(ionale
ntr-un graI al dependentelor Iunctionale, acestea sunt reprezentate prin sgeti ce leag sursa si
destinatia. La dependentele Iunctionale simple sgeata uneste cele dou atribute. Cnd sursa este
compus, se Ioloseste un conector care leag, n prima instant, atributele-determinant, iar sgeata
uneste acest conector cu atributul destinatie.
Dependentele discutate n paragraIul anterior pentru relatia BIBLIOTECATU-
PLURINOISOLUTIA3 (Iigura 3.5) pot Ii reprezentate sub Iorm de graI ca n Iigura 3.7.

Figura 3.7. Repre:entarea sub form de graf a DF din relatia
BIBLIOTECATUPLURINOISOLU]IA3
44 Baze de date
Din baza de date VNZRI, pentru simpliIicare, n Iigura 3.8 sunt reprezentate numai DF (1),
(3), (5)-(7), (9)-(15), (33)-(46), (50)-(54).

Figura 3.8. Graful simplificat al DF din BD JINZRI
3.4 A DOUA FORM NORMALIZAT
Cea de-a doua Iorm normal (2NF) se bazeaz pe dependentele Iunctionale totale sau
elementare. Drept care acest paragraI ncepe cu prezentarea acestui tip de dependente Iunctionale esi
se continu cu discutarea modalittile de 'rupere a bazei de date n mai multe relatii aIlate n 2NF.
3.4.1 Dependen(e func(ionale totale
Notiunea de dependent functional total a Iost introdus de MelkanoII. O dependent
Iunctional Data1 Data2 este total dac nu exist nici un atribut/combinatie Data3 ca
subansamblu al Data1, care s veriIice dependenta Iunctional Data3 Data2. Formal, dac X
A
i
, A
f
,...., A
k
} reprezint un grup de atribute ale relatiei R, iar A
m
un atribut al aceleiasi relatii,
unde A
m
X. Se spune c exist o dependent Iunctional total ntre X si A
m
dac:
1. X A
m
si 2. nu exist nici un subansamblu S de atribute, S X, pentru care S A
m
.
total
Se noteaz: X A
m

Dependenta Iunctional total mai este denumit si elementar, plin, deplin sau complet.
Implicit, toate dependentele n care sursa este simpl (alctuit dintr-un singur atribut) sunt dependente
Iunctionale complete. Problema prezint important n cazul dependentei Iunctionale cu sursa
compus. AstIel, n BD VNZRI, dependentele : (NrFact, Linie) CodPr; (NrFact, Linie)
Cantitate si (NrFact, Linie) PretUnit sunt totale, deoarece: NrFact / CodPr;
NrFact/Cantitate; NrFact/PretUnit; Linie/CodPr; Linie/ Cantitate;
Linie / PretUnit.
Dac se utilizeaz cel de-al doilea sistem de contare, caz n care sunt valabile DF (2)-(4),
atunci pentru LINIIARTICOLECONTABILE din Iigura 3.6 dependenta (4) este una partial
datorit (2).
FEAA nfoEc + CG - 2006/2007 45
n relatia BIBLIOTECTUPLURINOISOLUTIA3 din Iigura 3.5 primele cinci
dependente Iunctionale: (1) (Cota, Autor, CuvntCheie) ISBN; (2) (Cota, Autor,
CuvntCheie) Titlu; (3) (Cota, Autor, CuvntCheie) Editura; (4) (Cota,
Autor, CuvntCheie) LocSediuEd; (5) (Cota, Autor, CuvntCheie) AnAparitie
sunt partiale, deoarece: (6) Cota ISBN; (7) Cota Titlu; (8) Cota
Editura; (9) Cota LocSediuEd; (10) Cota AnAparitie
Cu alte cuvinte, un atribut component al determinatului dependentelor (1)-(5) este, el singur,
surs ntr- serie de DF n care destinatiile sunt identice.
3.4.2 Trecerea rela(iilor n a doua form normal (2NF)
ncepnd cu a doua Iorm normal, relatiile pot Ii decupate (decompuse, sparte) n sub-relatii,
n scopul diminurii problemelor legate de stocare si actualizare. n general, atunci cnd ntr-o relatie
R exist o DF de tip X Y si X nu este cheie candidat, atunci R contine o anumit doz de
redundant
23
.
Jan Heath a demonstrat
24
c orice relatie alctuit din trei atribute, notat R(X, Y, Z), n care
exist dependenta Iunctional X Y poate Ii descompus n dou relatii R1(X, Y) si R2(X, Z);
R1 si R2 reprezent proiectiile relatiile R pe atributele X si Y, respectiv X si Z. Esential este Iaptul c
descompunerea s se Iac Ir pierdere de inIormatii, adic R s poat Ii "recompus" prin jonctiunea
tabelelor R1 si R2. n alti termeni, la spargerea oricrei relatii trebuie ca toate dependentele din
acoperirea minimal s se regseasc n structura noilor relatii
25
. Ca o consecint indirect, se poate
astIel rezolva si problema cheii primare a relatiei universale, n cazul nclcrii restrictiei de entitate
(un atribut din cheia primar prezint valori nule).
O relatie se aIl n 2NF dac: 1. Se aIl n 1NF; 2. Toate DF ce leag cheia primar la celelalte
atribute sunt DF elementare (totale).
O baz de date este n 2NF cnd toate relatiile care o alctuiesc sunt n 2NF. Problema trecerii
unei relatii din prima n a doua Iorm normal se pune numai cnd cheia primar a relatiei este
compus din mai multe atribute. ntr-o Iormulare mai lejer, se poate spune c o relatie in 2NF nu
contine DF partiale intre atributele-cheie i celelalte atribute.
n general, trecerea de la 1NF la 2NF se poate realiza dup urmtoarea succesiune de pasi:
a) Se identiIic posibila cheie primar a relatiei universale, care conIer unicitate oricrui tuplu din
relatie, chiar n conditiile violrii restrictiei de entitate;
b) Se inventariaz toate dependentele dintre atributele relatiei (nchiderea DF), cu exceptia celor n
care destinatia este un atribut component al cheii primare.
c) Se trec n revist toate dependentele care au ca surs (determinant) un atribut sau sub-ansamblu de
atribute din cheia primar.
d) Pentru Iiecare atribut (sau sub-ansamblu) al cheii de la pasul c), se creeaz o relatie care va avea
drept identiIicator primar atributul (subansamblul) respectiv, iar celelalte atribute vor Ii cele care apar
ca destinatii n dependentele de la pasul c).

23
[Date00], p.333
24
Heath, .J. - Unacceptable File Operations in a Relational Database, Proc.1971 ACM SGFDET Workshop on
Data Description, Access and Control, nov. 1971
25
Vezi i [O'Neil & O'Neil 01], p.387
46 Baze de date
e) Din relatia initial sunt eliminate toate atributele destinatie (noncheie) din relatiile "proaspt"
obtinute, pstrndu-se numai atributele cheie ale noilor relatii (se asigur, astIel, cheile strine care vor
Iace legturile ctre noile relatii).
I) n ,rmsitele relatiei universale (initiale) se veriIic dac cheia primar initial respect restrictia
de entitate, iar dac nu, se mai elimin dintre atribute, iar, la limit, chiar toat relatia-,rmsite.

Important !
Etapele sugerate sunt aplicabile mai ales n situatiile n care cheia primar a relatiei universale
ncalc restrictia de entitate, adic atunci cnd combinatia ar conIeri unicitate, ns unul sau mai multe
dintre atributele cheie ar risca valori nule (vezi discutia din paragraIul 3.4). Este vorba de violare
rusinoas a "poruncilor" relationale, deoarece, dup cum am promis, ncepnd cu 2NF orice relatie
obtinut va respecta scupulos (si) restrictia de entitate.
La limit, prin descompuneri, din relatia universal (initial) este posibil s nu rmn dect
atributele cheie. Acum, ns, orice pericol privind nulitatea vreunui atribut cheie va atrage dup sine
eliminarea atributului respectiv, sau, la limit a relatiei respective, dup cum vom vedea chiar n acest
paragraI, pentru relatia VNZRI.

Rela(ia LINII_ARTICOLE_CONTABILE
Pentru relatia din Iigura 3.6, dac se utilizeaz primul sistem de contare, n care singura
dependent dintre cele discutate n paragraIul 3.3 este (1), atunci nu se mai pune problema trecerii n
2NF. n al doilea caz, n care DF sunt valabile (2), (3) si (4), ultima este partial. Urmm cei sase pasi:
a) Cheia primar este combinatia: (NotaContabila, Operatiune, ContDebitor, ContCreditor)
b) Inventarierea tuturor DF: (2), (3), (4)
c) Singura DF n care determinantul e parte din cheia primar este (2): NotaContabila Data
d) Pentru atributul NotaContabila se constituie relatie care l va avea identiIicator primar, iar cel
de-al doilea atribut Data. Din tabela initial se elimin atributul necheie preluat n noua relatie.
e) Din relatia initial rmne: R` NotaContabila, Operatiune, ContDebitor, ContCreditor,
Suma}
I) n R` cheia primar nu pericliteaz restrictia entittii, deci R` si poate pstra structura.

n consecint, n 2NF relatia LINIIARTICOLECONTABILE se descompune n dou relatii,
NOTECTB NotaContabila, Data} si ARTICOLECTB NotaContabila, Operatiune,
ContDebitor, ContCreditor, Suma} prezentate n Iigura 3.9.

NOTE_CTB ARTICOLE_CTB
NotaContabiI Data NotaContabiI Opera|iune ContDebitor ContCreditor Suma
150 30.11.2006 150 1 300 401 10000000
151 01.12.2006 150 1 4426 401 1800000
150 2 401 5311 7000000
150 2 401 5121 4800000
151 1 5121 700 5250000
Figura 3.9. Tabela LINIIARTICOLECONTABILE adus in 2NF
La drept vorbind, nu putem spune c economia de spatiu si diminuarea anomaliilor la actualizri sunt
spectaculoase din cale-aIar prin aducerea relatiei n 2NF. Datorit simplittii, exemplul este ns util.

Rela(ia BIBLIOTEC_TUPLURI_NOI_SOLUTIA_3
Relatia ilustrat n Iigura 3.5 prezint, dintre cele discutate n paragraIul 3.3, dependente
partiale si, astIel, constituie un bun "obiect" de normalizare n 2NF. Dealtminteri, relatia abund n
redundante si anomalii de inserare si modiIicare:
FEAA nfoEc + CG - 2006/2007 47
nregistrarea receptiei unui titlu, introducerea datelor despre o carte (titlu) sunt imposibile pn
n momentul n care mcar o carte primeste cot;
dac un titlu a Iost introdus initial eronat, corectia trebuie operat pe destule linii ale tabelei;
la Iiecare achizitie ulterioar a unei aceleasi crti (ISBN) trebuie introduse din nou ISBN-ul,
titlul, editura etc.
Parcurgem cei sase pasi, dup cum urmeaz:
a) Cheia primar a relatie initiale este: (Cota, Autor, CuvntCheie)
b) Ansamblul DF: (1)-(15)
c) n dependentele (6)-(10), atributul Cota, component al cheii relatiei, este surs simpl
d) Se constituie o relatie n care Cota este cheie primar, iar celelalte atribute sunt destinatiile DF (6),
(7), (8), (9) si (10).
e) Din relatia initial se elimin toate atributele-destinatie preluate n proaspt tabel, rmnnd doar
atributele cheie: Cota, Autor, CuvntCheie}.
I) Nici unul dintre cele trei atribute de la punctul e) nu pericliteaz restrictia de entitate, asa nct
relatia-,rmsit se pstreaz n aceast Iorm.
Prin urmare, n a doua Iorm normalizat, relatia initial (universala) s-ar putea descompune
n: CRTI Cota, ISBN, Titlu, Editura, LocSediuEd, AnAparitie} si TITLURIAU-
TORICUVINTECHEIE Cota, Autor, CuvntCheie} - vezi Iigura 3.10.
CR|I
Cot ISBN TitIu Editura LocSediuEd AnApari|ie
-13421 973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale Polirom ai 2002
-13422 973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale Polirom ai 2002
-13423 973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor profesionale Polirom ai 2002
-10678 973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro Polirom ai 2001
-10679 973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro Polirom ai 2001

TITLURI_AUTORI_CUVINTECHEIE (fragment)
Cota Autor CuvntCheie
-13421 Marin Fotache baze de date
-13421 Marin Fotache SQL
-13421 Marin Fotache proceduri stocate
-13421 Marin Fotache FoxPro
-13421 Marin Fotache formulare
-13421 Marin Fotache orientare pe obiecte
-13421 Marin Fotache client-server
-13421 Marin Fotache web
...
Figura 3.10. Relatia BIBLIOTECTUPLURINOISOLU]IA3 in 2NF
Chiar dac o parte din redundante au Iost eliminate, mai rmn destule, astIel nct structura de mai
sus va constitui subiect att pentru a trei Iorm normalizat (3NF), ct si pentru cea de a patra (4NF).

Rela(ia STUDENTI_EXAMENE
Senzatia de deja-vu care v ncearc este ndrepttit. Acesta este relatia din paragraIul 3.1.1
(Iigura 3.1) cu care am nceput s nchinm osanale normalizrii. Este o relatie simpl care se preteaz
la normalizare, maniIestnd redundante si anomalii la actualizare. Cheia primar Iiind combinatia
(Matricol, CodDisc, DataExamen), automat sunt valabile urmtoatele DF:
(1) (Matricol, CodDisc, DataExamen) NumePrenume
(2) (Matricol, CodDisc, DataExamen) An
(3) (Matricol, CodDisc, DataExamen) Specializare
(4) (Matricol, CodDisc, DataExamen) DenumireDisc
(5) (Matricol, CodDisc, DataExamen) NrCredite
48 Baze de date
(6) (Matricol, CodDisc, DataExamen) Nota
STUDENTIEXAMENE ar Ii n 2NF dac nici una din aceste sase dependente nu ar Ii partial. Fr a
ne ntrebuinta prea serios, e suIicient s ne reamintim c matricolul este desemnat s identiIice n mod
unic Iiecare student. Dintr-un Ioc avem trei dependente: (7) Matricol NumePrenume;
(8)Matricol An; (9)Matricol Specializare.
Si codul disciplinei are pretentii de identiIicare Ir ambiguitare a Iiecrei "materii" parcurse
de studenti: (10) CodDisc DenumireDisc; (11) CodDisc NrCredite.
Din dependentele (7)-(9) construim relatia STUDENTI Matricol, NumePrenume, An,
Specializare}, din (10) si (11) DISCIPLINE CodDisc, DenumireDisc, NrCredite} iar din
relatia initial rmne: EXAMENE Matricol, CodDisc, DataExamen, Nota} care nu are
probleme cu valorile nule ale vreunui atribut-cheie.
Avem toate motivele s Iim multumiti. Redundantele au Iost eliminate. Numele, specializarea
si anul de studiu al Iiecrui student apar acum o singur dat (n tuplul corespunztor studentului din
relatia STUDENTI). Tot o singur dat apar si denumirea unei discipline si numrul de credite alocat
acesteia (relatia DISCIPLINE). Lucrurile stau la Iel de bine si n ceea ce priveste diminuarea
anomaliilor maniIestate la editarea datelor. AstIel, privitor la anomaliile de inserare, din momentul
nscrierii n anul I, pn la cel al primului examen, studentul poate Ii inserat n tabela STUDENTI,
urmnd ca, odat cu prima sa sesiune de examene, s-i Iie introduse nregistrri n EXAMENE.
ModiIicarea denumirii unei discipline sau numrul de credite, sau corectarea unei eventuale erori
strecurate n numele studentului sau al specializrii/anului, toate se Iac ntr-un singur loc, pe tuplul
corespunztor din STUDENTI sau DISCIPLINE, ceea ce nseamn c am scpat si de anomaliile de
modiIicare. n Iine, tot n paragraIul 3.1.1 se atrgea atentia asupra riscului pierderii unor inIormatii
valoroase la stergerea unei linii din STUDENTIEXAMENE (un soi de aruncatul copilului odat cu
albia). Nici acest pericol nu mai este de actualitate n noua structur.

Rela(ia VNZRI
Si relatia universal VNZRI ncalc preceptele relationalului (n Iapt, am putea s-i spunem
tabel, pentru a respecta adevrul, tabela Iiind asociat cu SQL-ul care este mult prea tolerant cu
elemente ce Iac dintr-o tabel s nu Iie o relatie - unicitate, valori nule, lipsa cheii primare etc.),
ntruct unul din atributele care asigur unicitate Iiecrui tuplu din relatia initial, Codnc (codul
ncasrii) are valori nule pentru Iacturile 'proaspt emise, de Iapt, pentru toate Iacturile din care nu s-
a ncasat nici o letcaie. Dac nu s-ar Ii pus problema restrictiei de entitate, combinatia de atribute care
diIerentiaz cu sigurant orice tuplu de celelalte este (NrFact, Linie, Codnc). Lucrurile nu sunt
att de grave, deoarece n setul de DF apar destule surse care sunt subansambluri ale pseudo-cheii
primare. Asadar, s parcurgem cele sase etape ale deja celebrului ,ndrumar de aducere a unei baze
de date n 2FN.
a) Cheia primar a relatiei este: (NrFact, Linie, Codnc).
b) Dependentele maniIestate n relatie sunt cele 54 din paragraIul 3.3.
c) Dependentele (50), (51), (52) si (53) au drept surs Codnc. Cu totul altIel stau lucrurile pentru
NrFact. Dac initial identiIicasem dependentele (37), (38), (39) si (40), datorit tranzitivittii acestora
li se mai pot aduga nc 12, adic: (55) NrFact DenCl; (56) NrFactCodFiscal; (57)
NrFact StradaCl; (58) NrFact NrStradaCl; (59) NrFact BlocScApCl; (60)
FEAA nfoEc + CG - 2006/2007 49
NrFactTelefonCl; (61)NrFactCodPost; (62)NrFactLocalitate; (63) Nr-
Fact Comuna; (64) NrFactJud; (65) NrFactJudet; (66)NrFact Regiune.
Am ncheiat inventarierea DF n care sursele sunt simple si atribute-cheie si continum cu surse
compuse, alctuite din dou dintre cele trei atribute, la acest ,capitol avnd o singur dependentele
(54) si cele de la (41) la (46).
d) Crem noile relatii. Din (50), (51), (52) si (53) rezult: NCASRI Codnc, Datanc, CodDoc,
NrDoc, DataDoc}. Din (37), (38), (39) si (40), plus (55)-(66) se obtine: FACTURI NrFact, CodCl,
DataFact, Obs, DenCl, CodFiscal, StradaCl, NrStradaCl, BlocScApCl, TelefonCl,
CodPost, Localitate, Comuna, Jud, Judet, Regiune}. Din dependenta (54) se poate 'izola
relatia: NCASFACT Codnc, NrFact, Transa} Pe baza DF (41)-(46) se construieste: LI-
NIIFACTURI NrFact, Linie, Cantitate, PretUnit, CodPr, DenPr, UM, ProcTVA, Grupa}.
e) Din relatia initial rmne: FACTURIINCASRI NrFact, Linie, Codnc}.
I) n aIara celor trei atribute cheie din relatia initial - nimic. Dac n 1NF eludam problema restrictiei
de entitate, pe motiv c n 2NF lucrurile se rezolv, acum ne propunem s transm discutia. Pentru ca
s respecte restrictia de entitate, relatia FACTURINCASRI nu poate "primi" tupluri, dect n
momentul unei prime ncasri a unei Iacturi. Dar, de Iapt, ceea ce se ncaseaz ntr-o trans nu este o
linie (un produs) dintr-o Iactur, ci o parte sau intreaga Iactur, lucrul pe care-l reIlect pe deplin
dependenta (54) si relatia NCASFACT. Prin urmare, aceast ultim relatie nu ne este de nici un
Iolos, si, pur si simplu, renuntm la ea. Senzatia este oarecum ciudat, mai ales c un asemenea
demers nu este Iundamentat prea riguros n teoria att de matematizat a normalizrii.
n concluzie, n 2NF, relatia universal VNZRI va avea structura relatiilor: NCASRI,
FACTURI, NCASFACT si LINIIFACTURI.
3.5. A TREIA FORM NORMALIZAT $I FORMA NORMAL
BOYCE-CODD
A treia Iorm normalizat (3NF) prezint un interes aparte, deoarece este considerat de multi
specialisti drept un minimum acceptabil pentru structura unei baze de date relationale. Bazat pe a
doua Iorm normal si dependentele Iunctionale tranzitive (de Iapt, pe eliminarea lor), 3NF a cunoscut
dou deIinitii majore, una 'original, Iormulat de Codd nsusi (cu variantele sale 'Iolclorice) si a
doua, ce acoper cteva lipsuri ale primeia, numit, dup autorii si, Bovce-Codd Normal Form, n
traducere oarecum liber forma normal Bovce-Codd, mai pe romneste, BCNF.
3.5.1 Dependen(e func(ionale directe/tranzitive
O dependent Iunctional Data1 Data2 este direct atunci cnd nu exist o Data3
care angajeaz o dependent Iunctional tranzitiv de genul: Data1 Data3 Data2.

Pentru relatia BIBLIOTECTUPLURINOISOLUTIA3, DF (7), (8), (9) si (10) sunt
tranzitive deoarece: CotaISBN Titlu; CotaISBNEditura; CotaISBN
LocSediuEd; CotaISBN AnAparitie. n plus si DF (13) este tranzitiv, ntruct
ISBN Editura LocSediuEd.
50 Baze de date
Pentru relatia VNZRI dependentele tranzitive simple sunt mai numeroase: CodPost
Jud Judet; CodPost Jud Regiune; CodCl CodPost Localitate;
CodClCodPost Comuna; CodCl CodPostJudJudet; CodCl Cod-
Post Jud Regiune; NrFact CodCl DenCl; NrFactCodCl Cod-
Fiscal; NrFactCodClStradaCl; NrFactCodCl NrStradaCl; NrFact
CodClBlocScApCl; NrFactCodCl TelefonCl; NrFactCodCl
CodPost, NrFactCodCl CodPost Localitate, ., dar si (NrFact,Linie)
CodPrDenPr; (NrFact,Linie) CodPr UM; (NrFact,Linie) CodPr
ProcTVA; (NrFact, Linie) CodPr Grupa.
Pe baza notiunilor prezentate se poate deIini inchiderea tran:itiv a unui ansamblu de
dependente Iunctionale. Inchidere tran:itiv reprezint ansamblul dependentelor totale directe
dependentele totale tran:itive.

Acoperirea minimal, deIinit n capitolul anterior, este subansamblul
minimal de dependente Iunctionale elementare care permit determinarea tuturor celorlalte dependente
Iunctionale. Cu alte cuvinte: (1) nici o dependent Iunctional nu este redundant si (2) orice
dependent Iunctional total Iace parte din nchiderea tranzitiv. Spre deosebire de ceea ce am
discutat n capitolul anterior, acum suntem n msur s eliminm din ansamblul DF si pe cele
tranzitive.
AstIel, pentru relatia BIBLIOTECTUPLURINOISOLUTIA3, acoperirea minimal este
alctuit din patru DF: CotaISBN; ISBNTitlu; ISBNEditura; ISBN An-
Aparitie; EdituraLocSediuEd, iar nchiderea tranzitiv este urmtorul ansamblu de
dependente: CotaISBN; CotaTitlu; CotaEditura; CotaLocSediuEd;
Cota AnAparitie; ISBN Titlu; ISBN Editura; ISBN LocSediuEd;
ISBN AnAparitie; Editura LocSediuEd.
Acoperirea minimal poate Ii usor reprezentat prin graIul DF. Dependentele tranzitive sunt
Ioarte usor de identiIicat si eliminat. Spre exemplu, dac din Iigura 3.7 eliminm sgetile ce reprezint
drumul direct dintre dou atribute/grupe si un atribut destinatie, atta timp ct ntre respectivele
atribute/conectori exist un 'traseu ocolitor, se obtine graIul acoperirii minimale vezi Iigura 3.11.

Figura 3.11. Graful DF din acoperirea minimal pentru relatia
BIBLIOTECTUPLURINOISOLU]IA3
Este drept, atributele Autor si CuvntCheie atrn inutil n Iigur, stricnd imaginea
graIului. Le-am pstrat ns pentru a nu omite nici un atribut din relatia universal si de a indica cheia
primar a relatiei.

Pentru baza de date VNZRI acoperirea minimal, adic setul initial de DF din care au Iost
eliminate dependentele simetrice (redundante), partiale si tranzitive este urmtorul set de dependente
FEAA nfoEc + CG - 2006/2007 51
Iunctionale reprezentat n Iigura 3.8: Jud Judet; Jud Regiune; CodPost Loca-
litate; CodPost Comuna; CodPost Jud; CodCl DenCl; CodCl CodFis-
cal; CodCl StradaCl; CodCl NrStradaCl; CodCl BlocScApCl; CodCl
TelefonCl; CodCl CodPost; CodPr DenPr; CodPr UM; CodPr Grupa;
CodPr ProcTVA; NrFact CodCl ; NrFact DataFact; NrFact Obs; (Nr-
Fact,Linie) Cantitate; (NrFact,Linie) PretUnit; Codnc Datanc;
Codnc CodDoc; Codnc NrDoc; Codnc DataDoc; (Codnc,NrFact)
Transa.
3.5.2 Aducerea rela(iilor n a treia form normal
Prima deIinitie a celei de-a treia Iorme normale a unei relatii poate Ii Iormulat relativ simplu
si incremental, prin raportare la 2NF. O relatie se aIl n 3NF dac: 1. Se gsete in 2NF, 2. Toate
atributele care nu apartin cheii primare nu depind functional de un alt atribut (ansamblu de atribute)
care nu face parte din cheie. A doua conditie poate Ii exprimat si n maniera: toate dependentele
functionale care leag cheia primar de celelalte atribute sunt directe (netran:itive).
O alt Iormulare a 3NF utilizeaz tot dou conditii: a) toate atributele ne-cheie din R sunt
independente unele de altele, n sensul c nici unul dintre atributele neparticipante n cheia primar nu
apare n vreo DF n care sursa este constituit dintr-o combinatie de celelalte atribute ne-cheie; b) toate
atributele ne-cheie din R sunt dependente ireductibil de cheia primar.

Important !
Chris Date este poate singurul care, precaut, la nceputul discutiilor legate de primele trei
Iormele normale, aIirm c situatiile luate n considerare pornesc de la premisa c nu exist chei
candidat. Premisa este Ioarte important, ntruct atunci cnd nu se elimin dependentele simetrice si
redundante pomenite n capitolul anterior, iar o relatie are dou mai multe chei candidat, sunt sanse
mare s apar complicatii. Vom reveni la sIrsitul acestui paragraI cu analiza bazei de date VNZRI
si vom vedea c si precautia lui Date este insuIicient, deoarece, n Iapt, problema nu este numai a
cheilor candadidat ale unei relatii, ci a dependentelor simetrice si redundante.

Trecerea din 2NF n 3NF presupune eliminarea DF tranzitive si se poate Iace, pentru o relatie,
n urmtoarea manier:
a) Se identiIic toate atributele ce nu Iac parte din cheie si sunt surse ale unor dependente Iunctionale.
b) Pentru toate atributele identiIicate la punctul a), se constituie cte o relatie n care cheie primar va
Ii atributul respectiv, iar celelate atribute destinatiile din dependentele considerate.
Operatiile a) si b) se repet si pentru relatiile "proaspt" obtinute prin decompozitie. De Iiecare dat,
din relatiile supuse descompunerii se elimin atributele destinatie ale surselor non-cheie (sun bine,
nu-i asa ?), pstrndu-se atributele surs, n vederea stabilirii legturilor ntre tabele (cheile strine) si,
implicit, declarrii restrictiilor reIerentiale.

Relatia LINIIARTICOLECONTABILE a Iost adus n paragraIul 3.4.2 n 2NF prin
descompunerea n dou relatii, NOTECTB NotaContabila, Data} si ARTICOLECTB
NotaContabila, Operatiune, ContDebitor, ContCreditor, Suma} prezentate n Iigura 3.9.
ntruct nici una din cele dou relatii nu contine dependente Iunctionale tranzitive, n 3NF baza de
date are aceasi structur ca si n 2NF.

52 Baze de date
Pentru a ndeplini cerintele 2FN, relatia BIBLIOTECTUPLURINOISOLUTIA3 a Iost
rupt n tabelele CRTI Cota, ISBN, Titlu, Editura, LocSediuEd, AnAparitie} si
TITLURIAUTORICUVINTECHEIE Cota, Autor, CuvntCheie} - vezi Iigura 3.10. Cea de-a
doua este alctuit exclusiv din atribute-cheie, deci nu se pune n discutie 3NF (adic relatia este deja
n 3NF). AltIel stau lucrurile n CRTI. Relatia este n 2NF si contine dependente tranzitive. Exist
dou atribute din aIara cheii primare, ISBN si Editura, care sunt surse de DF, astIel nct
dependentele (7), (8), (9), (10) si (13) sunt tranzitive. Trecerea n 3NF se realizeaz prin constituirea a
dou relatii pe care o s le numim EDITURI Editura, LocSediuEd} si TITLURI ISBN, Titlu,
Editura, AnAparitie}, iar din CRTI rmne EXEMPLARE Cota, ISBN}. n concluzie, n
3NF baza de date BIBLIOTEC este alctuit din patru tabele: EDITURI Editura, LocSediuEd},
TITLURI ISBN, Titlu, Editura, AnAparitie }, EXEMPLARE Cota, ISBN} si TITLURIA-
UTORICUVINTECHEIE Cota, Autor, CuvntCheie} vezi Iig. 3.12.
EDITURI

TITLURI
Editura LocSediuEd ISBN TitIu Editura AnApari|ie
Polirom ai 973-683-889-7 Visual FoxPro.Ghidul dezvoltrii aplica[iilor profesionale Polirom 2002
973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro Polirom 2001

EXEMPLARE TITLURI_AUTORI_CUVINTECHEIE (fragment)
Cot ISBN Cota Autor CuvntCheie
-13421 973-683-889-7 -13421 Marin Fotache baze de date
-13422 973-683-889-7 -13421 Marin Fotache SQL
-13423 973-683-889-7 -13421 Marin Fotache proceduri stocate
-10678 973-683-709-2 -13421 Marin Fotache FoxPro
-10679 973-683-709-2 -13421 Marin Fotache formulare
-13421 Marin Fotache orientare pe obiecte
-13421 Marin Fotache client-server
-13421 Marin Fotache web
...
Figura 3.12. Relatia BIBLIOTECTUPLURINOISOLU]IA3 in 3NF
Din pcate, ne rmne pe constiint ultima tabel, TITLURIAUTORICUVINTECHEIE
care contine un grad de ridicat de redundant a datelor, problem rezolvat pe baza unui alt tip de
dependente - multivaloare (vezi capitolul viitor).

Ultimul exemplu din pagraIul 4.4 a adus relatia universal VNZRI n a doua Iorm
normalizat, prin ruperea acesteia n patru tabele: NCASFACT, NCASRI, LINIIFACTURI si
FACTURI. Dar, dup cum am vzut n paragraIul precedent, exist o serie de dependente tranzitive.
S examinm pe rnd cele cinci relatii.
* NCASFACT Codnc, NrFact, Transa} are un singur atribut ne-cheie, deci nici vorb de DF
tranzitive.
* NCASRI Codnc, Datanc, CodDoc, NrDoc, DataDoc} nu prezint nici un atribut n aIara
Codnc care s Iie surs de DF.
* Cu LINIIFACTURI NrFact, Linie, Cantitate, PretUnit, CodPr, DenPr, UM, ProcTVA,
Grupa} situatia este diIerit. Atributul ne-cheie CodPr este determinant n o serie de dependente,
(33)-(36), pe baza acestora construindu-se relatia PRODUSE CodPr, DenPr, UM, ProcTVA, Grupa};
din LINIIFACTURI se elimin toate destinatiile celor patru DF, obtinndu-se LINIIFACT
NrFact, Linie, CodPr, Cantitate, PretUnit}.
FEAA nfoEc + CG - 2006/2007 53
* n tabela FACTURI NrFact, CodCl, DataFact, Obs, DenCl, CodFiscal, StradaCl,
NrStradaCl, BlocScApCl , TelefonCl, CodPost, Localitate, Comuna, Jud, Judet,
Regiune} lucrurile sunt si mai interesante:
- mai nti, se cuvine de observat c Jud este surs a DF (1) si (3), asa nct FACTURI se
descompune n JUDETE Jud, Judet, Regiune} si FACTURI1 NrFact, CodCl, DataFact,
Obs, DenCl, CodFiscal, StradaCl, NrStradaCl, BlocScApCl, TelefonCl, CodPost,
Localitate, Comuna, Jud};
- dar si FACTURI1 prezint DF; n dependentele (5), (6) si (7) CodPost este surs, asa nct
FACTURI1 se descompune n CODURIPOSTALE CodPost, Localitate, Comuna, Jud} si
FACTURI2 NrFact, CodCl, DataFact, Obs, DenCl, CodFiscal, StradaCl, NrStradaCl,
BlocScApCl, TelefonCl, CodPost};
- n FACTURI2 a mai rmas un singur atribut ne-cheie ce este surs n DF (8)-(16), CodCl, astIel
nct si aceasta se descmpune n CLIENTI CodCl, DenCl, CodFiscal, StradaCl, NrStradaCl,
BlocScApCl, TelefonCl, CodPost} si FACT NrFact, CodCl, DataFact, Obs}.
n concluzie, n 3NF relatia initial VNZRI este 'spart n urmtoarele opt relatii:
NCASFACT Codnc, NrFact, Transa}, NCASRI Codnc, Datanc, CodDoc, NrDoc,
DataDoc}, PRODUSE CodPr, DenPr, UM, ProcTVA, Grupa}, LINIIFACT NrFact, Linie,
CodPr, Cantitate, PretUnit}, JUDETE Jud, Judet, Regiune}, CODURIPOSTALE
CodPost, Localitate, Comuna, Jud}, CLIENTI CodCl, DenCl, CodFiscal, StradaCl,
NrStradaCl, BlocScApCl, TelefonCl, CodPost} si FACT NrFact, CodCl, DataFact, Obs}.
3.5.3 Cheile candidat yi influen(a lor asupra 3NF
Promiteam n deschiderea paragraIului cteva detalii despre implicatiile cheilor alternative
asupra aducerii unei relatii n 3NF, implicatii prea putin evocate n literatura de proIil. AstIel, revenim
la relatia n 2NF LINIIFACTURI NrFact, Linie, Cantitate, PretUnit, CodPr, DenPr, UM,
ProcTVA, Grupa} din baza de date VNZRI. Dac lum n consideratie c si denumirea produsului
este unic, altIel spus, nu exist dou sortimente cu nume absolut identic, rezult o serie de dependente
paralele:
CodPr DenPr DenPr CodPr
CodPr UM DenPr UM
CodPr Grupa DenPr Grupa
CodPr ProcTVA DenPr ProcTVA

Dac urmm algoritmul prescris de trecere a relatiei LINIIFACTURI din 2NF n 3NF, ar
trebui s consituim cte o relatie pentru Iiecare surs de DF care nu Iace parte din cheia primar a
relatiei, iar n relatia ce rmne din LINIIFACTURI (LINIIFACT2) s pstrm pe post de chei
strine att CodPr, ct si DenPr: PRODUSE1 CodPr, DenPr, UM, ProcTVA, Grupa},
PRODUSE2 DenPr, CodPr, UM, ProcTVA, Grupa} si LINIIFACT2 NrFact, Linie, CodPr,
DenPr, Cantitate, PretUnit}.
Gogomnia este evident, ns, ca n attea alte cazuri, Iundamentat stiintiIic ! Iar dac
demostratia nu a Iost suIicient de impresionant, ce ziceti de relatia FACTURI n 2FN, n care orice
client poate Ii identiIicat Ir ambiguitate att de CodCl, ct si de DenCl si de CodFiscal.

54 Baze de date
CodCl DenCl
CodCl CodFiscal
CodCl StradaCl
CodCl NrStradaCl
CodCl BlocScApCl
CodCl TelefonCl
CodCl CodPost
CodCl Localitate
CodCl Comuna
CodCl Jud
CodCl Judet
CodCl Regiune
DenCl CodCl
DenCl CodFiscal
DenCl StradaCl
DenCl NrStradaCl
DenCl BlocScApCl
DenCl TelefonCl
DenCl CodPost
DenCl Localitate
DenCl Comuna
DenCl Jud
DenCl Judet
DenCl Regiune
CodFiscal CodCl
CodFiscal DenCl
CodFiscal StradaCl
CodFiscal NrStradaCl
CodFiscal BlocScApCl
CodFiscal TelefonCl
CodFiscal CodPost
CodFiscal Localitate
CodFiscal Comuna
CodFiscal Jud
CodFiscal Judet
CodFiscal Regiune

Asa c din LINIIFACTURI obtinem n prima Iaz a trecerii la 3NF nu mai putin de patru
relatii, apoi s continum cu descompunem celor trei constituite pe baza seriilor de dependente de mai
sus s.a.m.d.
Solutia este cea pe care am sugerat-o n capitolul 4. Pentru identiIicarea oricrei entitti
(produs, client, Iactur) pstrm doar cheia primar (practic, renuntm la celelate chei calndidat), iar
toate dependentele ce decurg din calitatea de cheie alternativ nu sunt luate n considerare.
3.5.4 Aducerea rela(iilor n 3NF prin grafuri ale DF
Modul n care a Iost prezentat transIormarea sucesiv a relatiei universale initiale n 1NF,
2NF si 3NF prin descompuneri succesive are certe valente pedagogice si aplicabilitate practic.
Descompunerea nu este ns singura manier de normalizare a unei baze de date relationale.
Philip A. Berstein este autorul unui model de normalizare prin sinte:a unor relatii binare
(construite pe baza DF) n relatii mai mari si, astIel, aducerea bazei n 3NF
26
. n plus, autorul a
demonstrat c schema obtinut contine un numr minim de relatii. Desi s-a demonstrat c algoritmul
este corect, aplicarea sa eIectiv ridic destule diIicultti, deoarece, dup cum am mai discutat,
nchiderea si acoperirea minimal ale seturilor de DF chiar si pentru relatii nu Ioarte voluminoase sunt
greu de manevrat. Chris Date reproseaz modelului (si Bernstein accept observatia) c operatiunile
executate n cadrul algoritmului de sintez sunt exclusiv de natur sintactic si nu iau n considerare
latura semantic
27
. ns exemplul luat de Date pentru a pune n diIicultate algoritmul de sintez
constituie o capcan si pentru varianta descompunerii.
O variant mult mai direct si relevant pentru practicieni apartine lui Henry Smith care a
publicat n Communications of the ACM un Ioarte interesant articol n care arat c o structur deplin
normalizat poate Ii obtinut pe baza unei riguroase diagrame de DF
28
. De Iapt, diagramele sale
seamn mai degrab cu graIuri, dect Iorma lor consacrat
29
. Smith aIirm c descompunerea clasic,
pornind de la relatia universal este greoaie, iar construirea relatiei universale reclam, de multe ori,
un eIort important. Lucrarea lui Smith este cu att mai tentant cu ct nu opereaz cu algoritmi pentru
determinarea nchiderilor si acoperirilor de seturi de DF. Tinnd seama c, n 3NF, relatiile nu trebuie
s contin dependente partiale si tranzitive, se va reprezenta graIic acoperirea minimal.

26
[Berstein76]
27
[Date00], pp. 377-378
28
[Smith85]
29
vezi, spre exemplu, [Date86] sau [Pratt & Adamski91]
FEAA nfoEc + CG - 2006/2007 55
De Iapt, un avantaj decisiv al graIurilor DF este posibilitatea identiIicrii imediate si eliminrii
att a dependentelor partiale, ct si a celor tranzitive. n plus, exist situatii n care normalizarea
,clasic genereaz probleme, n timp ce, Iolosind graIul, schema obtinut este net superioar.

AstIel, pentru BD BIBLIOTEC, graIul acoperirii minimale este reprezentat n Iigura 3.11.
Totusi, pentru ilustrarea modului de identiIicare si eliminare dependentelor partiale si tranzitive
pornim de la graIul din stnga Iigurii 3.13. Spre deosebire de Iigura ,surs, sgetile ce reprezint
dependente partiale sau tranzitive sunt punctate. Eliminndu-le, obtinem graIul din dreapta Iigurii pe
care delimitm cte o relatie pentru Iiecare surs, simpl sau compus. Relatia corespondent va
contine sursa, drept cheie primar, plus toate destinatiile sale directe (si totale).

Figura 3.13. Cele patru tabele in 3NF pentru relatia BIBLIOTECTUPLURINOISOLU]IA3
n Iinal, nu ne mai rmne dect s dm cte un nume Iiecreia dintre cele patru relatii:
EDITURI, TITLURI, EXEMPLARE, TITLURIAUTORICUVINTECHEIE.

Cele 11 dependente ale relatiei STUDENTIEXAMENE identiIicate n paragraIul 3.4.2 pot Ii
lesne reprezentate ca un graI - vezi Iigura 3.14. Dependentele punctate sunt partiale, deoarece
destinatiile lor sunt legate de surse simple, asa c n Iinal sunt eliminate din calcul.

Figura 3.14. Aducerea relatiei STUDEN]IEXAMENE in 3NF cu afutorul grafului DF
Pe graI sunt trei surse, asa nct vom obtine trei relatii, cu urmtoarele atribute: Matricol,
NumePrenume, An, Specializare}, CodDisc, DenumireDisc, NrCredite} si Matricol,
CodDisc, DataExamen, Nota}. Schema seamn leit cu cea din paragraIul 3.4.2.

Pentru BD VNZRI, prin reprezentarea sub Iorm de graI, economia de timp pentru aducerea
n 3NF este si mai spectaculoas, dup cum reiese si din Iigura 3.15. Singura problem tine de atentie
n delimitarea tuturor surselor si dependentelor lor, ceea ce poate creea oarecare conIuzie.
56 Baze de date

Figura 3.15. Decuparea relatiilor in 3NF pentru ba:a de date JINZRI
Pentru majoritatea cazurilor ntlnite n practic, construirea graIului dependentelor
Iunctionale ce alctuiesc acoperirea minimal, este una din cele mai simple si la ndemn modalitti
de aducere a bazei de date n 3NF. De o manier asemntoare se pot determina relatiile celei de-a
treia Iorme normale utiliznd matricea dependentelor incluse n acoperirea minimal.
3.5.5 Forma normal Boyce-Codd
DeIinirea celei de-a treia Iorme normale, asa cum a Iost Iormulat initial de Codd, ridica o
serie de probleme n anumite circumstante, probleme pe care Iormularea din acest patagraI le rezolv.
Chris Date este de prere c situatiile n care deIinitia original a 3NF este insuIicient se traduce prin
trei conditii simultane
30
: a) relatia are mai multe chei candidate; b) o parte din cheile candidate sunt
compuse; c) cheile compuse au atribute n comun.
ntruct ndeplinirea simultan a celor trei conditii se ntlneste destul de rar n practic, a treia
Iorm normal, asa cum a Iost Iormulat n paragraIul precedent, este suIicient. Se spune despre o
relatie c este n Iorma normal Boyce-Codd (BCNF) dac: 1. se afl defa in 3NF, 2. nu exist nici o
DF a crei surs s fie un atribut ne-component al cheii, iar destinatia un atribut din cheie.
ntr-o alt Iormulare, o relatie R este in BCNF dac si numai dac orice determinant (surs de
dependent functional sau supercheie) este o cheie-candidat. Aceast exprimare are si avantajul de a
nu lega BCNF de 3NF, unii autori preIernd s discute problema normalizrii direct n termenii
BCNF, Ir a trece prin Iormele intermediare
31
. Numele Iormei normalizate este discutabil, deoarece
primul care elaboreaz o deIinitie echivalent a ceea ce reprezint astzi BCNF este Ian Heath. n
penultima editie a crtii sale ce a mplinit recent 25 de ani, Chris Date aIirm c ar Ii Iost mai indicat
titulatura forma normal a lui Heath (Heath Normal Form)
32
.


30
[Date86], p.374
31
Vezi, spre exemplu, [Garcia-Molina s.a.]
32
[Date00], p.366
FEAA nfoEc + CG - 2006/2007 57
Rela(ia PROIECTE
Candace Fleming si Barbara von Halle exempliIic utilitatea BCNF prin relatia PROIECTE
din Iigura 3.16
33
n care se maniIest urmroarele restrictii:
la Iiecare proiect exist mai multi supervizori si mai multi membri;
un membru poate participa la oricte proiecte;
persoan poate superviza un singur proiect;
un supervizor poate coordona (n cadrul aceluiasi proiect) mai multi membri;
ntr-un proiect, un membru este coordonat de un singur supervizor.

Figura 3.16. Relatie aflat in 3NF, nu ins i in BCNF
n aceste conditii, se veriIic urmtoarele DF: (1) (ProiectNr, Membru) Supervizor
si (2) (Supervizor, Membru) ProiectNr.Prin urmare, relatia are dou chei candidat.
Totodat, ns, exist si DF Supervizor ProiectNr, ceea ce Iace din dependenta (2) una
partial. Atributul Supervizor este determinant Ir a Ii cheie candidat. n aceste conditii, relatia nu
este n BCNF. Pentru a o aduce n aceast Iorm normalizat este necesar transIormarea graIului DF,
asa cum arat Iigura 3.17.

Figura 3.17. Transformarea grafului DF pentru relatia PROIECTE
Cele dou relatii obtinute sunt: SUPERVIZORI Supervizor, ProiectNr} si MEMBRI Super-
vizor, Membru } reprezentate n Iigura 3.18.

Figura 3.18. Aducerea relatiei PROIECTE in BCNF

33
Exemplul este preluat i n alte lucrri, precum [Teorey99]
58 Baze de date
O prima problem semnalat de cele dou autoare se reIer la pierderea unei restrictii de
integritate: la un proiect, un membru are un singur supervi:or. Cu alte cuvinte, noua structur a BD
permite ca unui membru s-i Iie asociati doi supervizori n cadrul aceluiasi proiect, ceea ce este
incorect n conditiile date. n plus, exemplului prezentat i se poate reprosa si rigiditatea, deoarece n
decursul anilor un supervizor poate rspunde de mai multe proiecte, dar acest din urm neajuns este
mai degrab unul mrunt.

Profesori, cursuri yi specializri
Cred c, de la C.J. Date ncoace, cel mai Irecvent ntlnit exemplu pentru ilustrarea Iormei
normale Boyce-Codd este cel privitor la cursuri-proIesori-studenti. Nu vom Iace rabat de la 'regul si
deIinim tabela SCP, reprezentat n Iigura 3.19, n conditiile n care un profesor poate preda la oricate
speciali:ri, dar numai un singur curs!

Figura 3.19. Relatia SCP
S analizm dependentele Iunctionale.
- un proIesor pred un singur curs: Profesor Curs
- un proIesor pred la mai multe specializri: Profesor / Specializare
- un acelasi curs poate Ii tinut de mai multi proIesori: Curs / Profesor
- un acelasi curs poate Ii predat la mai multe specializri: Curs / Specializare
- la o specializare, se predau mai multe cursuri (din pcate): Specializare / Curs
- la o specializare predau cursuri mai multi proIesori: Specializare / Profesor
- la o specializare, un curs este predat de un singur proIesor: (Specializare, Curs) Profesor
- un proIesor poate tine cursul la mai multe specializri: (Profesor, Curs) / Specializare
Cuplul de atribute (Specializare, Curs) este cheie primar. Pe baza dependentei
Iunctionale Profesor Curs n BCNF tabela SCP va Ii descompus n dou tabele, SP si PC,
prezentate n Iigura 3.20.

Figura 3.20. Tabelele SP i PC aflate n BCNF
FEAA nfoEc + CG - 2006/2007 59
3.5.6 Dependen(e tranzitive necanonice
n exemplele de pn acum am avut de lucrat cu dependente Iunctionale n Iorm canonic
cele n care destinatia este alctuit dintr-un singur atribut. Lucrurile nu sunt grozav de complicate,
identiIicarea dependentelor Iiind o operatiune lesnicioas. Din pcate, n unele situatii este posibil ca
tranzitivitatea s se stabileasc prin dependente ale cror destinatii sunt compuse. La normalizarea
relatiilor este recomandabil ca, n situatia unor dependente Iunctionale de genul: A B, A
C, A D, A E, dependente ce deriv din rolul de cheie primar pe care l ndeplineste
atributul A, s se veriIice dac nu cumva exist Iie o dependent Iunctional simpl, de genul B
D, Iie o dependent Iunctional cu sursa compus, de genul (B, C) D. Dac una din cele dou
aIirmatii de mai sus este adevrat, atunci dependenta Iunctional A E nu este direct.
Pentru un plus de credibilitate, s relum cazul bazei de date destinat evidentierii rezultatelor
obtinute de studenti la examene programate n sesiunile de pe parcursul unui universitar
(STUDENTIEXAMENE) creia i extindem structura: R Matricol, NumePren, An, Modul, Spec,
Grupa, CodDisc, DenDisc, NrCredDisc, CodProf, NumeProf, GradProf, DataEx, SalaEx,
Nota}, al crei dictionar simplicat este prezentat n tabelul 3.4
Tabel 3.4. Dictionarul datelor pentru ba:a de date EXAMENE
Atribut Descriere Tip
Matricol O combina[ie de litere i cifre ce identific n mod unic un student CHAR
NumePren Numele i prenumele studentului CHAR
An Anul de studiu NUMERC
Modul Modulul de studiu: este o liter ce desemneaz un grup de specializri CHAR
Spec Specializarea ('C' de la contabilitate, '' de la nformatic economic etc.) CHAR
Grupa Grupa de studiu NUMERC
CodDisc Codul disciplinei din planul de nv[mnt al specializrii CHAR
DenDisc Denumirea disciplinei CHAR
NrCredDisc Numrul de credite alocat disciplinei NUMERC
CodProf Codul profesorului CHAR
NumeProf Numele profesorului CHAR
GradProf P - profesor, C - conferen[iar, L - lector, A - asistent, R -preparator, A -
din afar (colaborator din afara universit[ii)
CHAR
DataEx Data examenului DATE
SalaEx Sala de desfurare a examenului CHAR
Nota Nota ob[inut NUMERC

Pentru simpliIicare, am luat n calcul numai studentii de la proIilul Economic, cursuri de zi. O
linie din R reprezint rezultatul obtinut de un student la o disciplin ntr-o sesiune de examinare. Spre
exemplu, un student (matricol EL001103) poate obtine la disciplina Microeconomie (cod AE1001)
nota 4 (scuze) n prima sesiune de examinare ianuarie 2005 (data examenului: 19 ianuarie 2005) si
nota 9 n a doua sesiune de examinare Iebruarie 2005 (data ex: 14/02/2005). Cei mai putin dispusi la
eIort se pot caliIica n Iaze superioare ale competitiei (sesiunea mai 2005 s.a.m.d.). Acestea Iiind
spuse, cheia primar a relatiei R este, ca si n cazul STUDENTIEXAMENE, (Matricol, CodDisc,
DataEx), pe baza creia pot Ii scrise urmtoarele DF:
(1) (Matricol, CodDisc, DataEx) NumePren
(2) (Matricol, CodDisc, DataEx) An
(3) (Matricol, CodDisc, DataEx) Modul
(4) (Matricol, CodDisc, DataEx) Spec
(5) (Matricol, CodDisc, DataEx) Grupa
(6) (Matricol, CodDisc, DataEx) DenDisc
60 Baze de date
(7) (Matricol, CodDisc, DataEx) NrCredDisc
(8) (Matricol, CodDisc, DataEx) CodProf
(9) (Matricol, CodDisc, DataEx) NumeProf
(10) (Matricol, CodDisc, DataEx) GradProf
(11) (Matricol, CodDisc, DataEx) SalaEx
(12) (Matricol, CodDisc, DataEx) Nota
Relatia R este n prima Iorm normalizat. Dup cum am vzut n capitolul precedent, pentru a
demonstra c nu este n 2NF trebuie s gsim n ansamblul DF (1)-(12) mcar o DF partial. Lucru
destul de simplu, dac tinem seam de urmtoarele DF n care sursa o constituie unul dintre atributele
componente ale cheii.
Matricolul identiIic n mod unic un student nscris la o specializare ntr-un an de studii: (13)
Matricol NumePren; (14) Matricol An; (15) Matricol Modul;
(16) Matricol Spec; (17) Matricol Grupa.
CodDisc identiIic n mod unic Iiecare discplin din planul de nvtmnt al specializrii: (18)
CodDisc DenDisc; (19) CodDisc NrCredDisc.
Pe baza ultimelor sapte DF, relatia universal R se poate descompune astIel: R1 Matricol,
NumePren, An, Modul, Spec, Grupa}, R2 CodDisc, DenDisc, NrCredDisc}, R3 Matricol,
CodDisc, CodProf, NumeProf, GradProf, DataEx, SalaEx, Nota}.
Cele trei relatii sunt n 2NF, iar pn aici similitudinea cu discutia pricinuit de relatia
STUDENTIEXAMENE este tulburtoare. Aducerea BD n 3NF echivaleaz cu eliminarea
dependentelor tranzitive din R1, R2 si R3. n R1 singurele DF existente sunt (13)-(17), deci aceast
relatie este n 3NF. Nici R2 nu contine dependente tranzitive; n schimb R3 da:
CodProf identiIic n mod unic un proIesor: (20) CodProf NumeProf;
(21)CodProf GradProf. Pe baza DF (20) si (21), putem spune c (9) si (10) sunt tranzitive,
asa nct rupem R3 n R31 CodProf, NumeProf, GradProf } si R32 Matricol, CodDisc,
CodProf, DataEx, SalaEx, Nota}. AstIel, n 3NF, relatia universal R are o schem alctuit din
patru relatii, dup cum urmeaz: STUDENTI Matricol, NumePren, An, Modul, Spec, Grupa},
DISCIPLINE CodDisc, DenDisc, NrCredDisc }, PROFESORI CodProf, NumeProf,
GradProf }, NOTE1 Matricol, CodDisc, CodProf, DataEx, SalaEx, Nota}.
Nici una din cele patru relatii nu contine DF tranzitive. Cu toate acestea, schema este departe
de a Ii optim. Fat de DF discutate, mai exist dou restrictii neluate n calcul n normalizare:
a. La o serie de curs (seriile de curs se constituie, pentru Iiecare disciplin, la nivel de an, modul,
specializare) titular este un singur proIesor: (22)(CodDisc, An, Modul, Spec) CodProf
b. Studentii unei specializri sustin examenul la o disciplin n aceeasi sal (si aceeasi zi): (23) (An,
Modul, Spec, DataEx) SalaEx
S recapitulm: n relatia NOTE exist DF: (8) (Matricol, CodDisc, DataEx)
CodProf, dar si (22) (CodDisc, An, Modul, Spec) CodProf. Deoarece exist DF (24):
Matricol An, Modul, Spec rezult ca (8) este o DF necanonic, asa nct relatia NOTE1 s-ar
descompune n: DISCSPECPROFI CodDisc, An, Modul, Spec, CodProf} si NOTE2
Matricol, CodDisc, DataEx, SalaEx, Nota}. Cstigul este considerabil.
Analog se poate proceda cu DF (23), discutia transIerndu-se n relatia NOTE2, n care, din
calitatatea de cheie primar a celor trei atribute exist dependenta: (11) (Matricol, CodDisc,
FEAA nfoEc + CG - 2006/2007 61
DataEx) SalaEx dar si DF (23) (An, Modul, Spec, CodDisc, DataEx) SalaEx. Pe
baza dependentei (24), relatia NOTE2 se sparge n SALIEX An, Modul, Spec, CodDisc, DataEx,
SalaEx} si NOTE Matricol, CodDisc, DataEx, Nota}.
Ajungem, astIel, la o cu totul alt structur a bazei de date, mult mai bun dect precedenta:
STUDENTI Matricol, NumePren, An, Modul, Spec, Grupa}, DISCIPLINE CodDisc, DenDisc,
NrCredDisc}, PROFESORI CodProf, NumeProf, GradProf }, DISCSPECPROFI CodDisc,
An, Modul, Spec, CodProf}, SALIEX An, Modul, Spec, CodDisc, DataEx, SalaEx}, NOTE
Matricol, CodDisc, DataEx, Nota}
Ca de obicei, dependentele tranzitive, canonice sau necanonice se observ mult mai lejer pe
graIul DF (vezi Iig. 3.21). Este suIicient s decupm cte o relatie prentru Iiecare surs simpl si
compus din graI, surs ce devine automat cheie a relatiei respective, si vom obtine structura de mai
sus.

Figura 3.21. Graful DF pentru ba:a de date EXAMENE
Structura Iinal ndeplineste si cerintele Iormei normale Boyce-Codd ca Iiecare surs de DF s
Iie cheie candidat. Putem institui si o regul: atunci cnd descompunerea se Iace urmnd Iiliera
clasic:
stabilirea cheii primare a relatiei initiale (universale), apoi
eliminarea, dintre dependentele Iunctionale ce decurg din calitatea de cheie primar a relatiei
initiale, a celor partiale, apoi
eliminarea, din toate relatiile obtinute n pasul anterior, a tuturor dependentelor tranzitive (n
care surse sunt cheile primare ale respectivelor relatii),
trebuie veriIicat dac n relatia initial mai existau dependente cu sursa compus ce nu apar drept cheie
primar sau candidat n nici una dintre relatiile Iinale obtinute.
3.5.7 Adugarea de atribute n schema unei baze de date
Revenim la un caz 'clasat pentru 3NF, cel al relatiei BIBLIOTECTUPLURINOISO-
LUTIA3. Combinatia care diIerentiaz orice linie de toate celelalte este (Cota, Autor,
CuvntCheie). Intuim ns un aspect pe care dependentele si, implicit, normalizarea l scap, si
anume c autorii si cuvintele cheie se reIer la o carte (adic ISBN) si nu la un exemplar Iizic din
depozit (Cota). Deci graIul DF nu ar trebui s arate ca n Iigura 3.13, ci precum n Iigura 3.22. Din
62 Baze de date
pcate, acesta este un aspect pe care l intuim, dar e mai greu de demonstrat 'stiintiIic prin
normalizare. Un argument n plus pentru a nu considera normalizarea drept un proces inIailibil, ci doar
un ghid n construirea unei scheme a BDR ct mai bune.

Figura 3.22. Autorii i cuvintele cheie corespund titlurilor, nu exemplarelor din crti
Pe baza graIului de mai sus, din schema bazei de date n 3NF se schimb ultima tabel,
TITLURIAUTORICUVINTECHEIE2 ISBN, Autor, CuvntCheie}. Continutul celor patru
relatii este acum cel din Iigura 3.23.
EDITURI
Editura LocSediuEd
Polirom ai

TITLURI
ISBN TitIu Editura AnApari|ie
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor
profesionale
Polirom 2002

973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro Polirom 2001

EXEMPLARE
Cot ISBN
-13421 973-683-889-7
-13422 973-683-889-7
-13423 973-683-889-7
-10678 973-683-709-2
-10679 973-683-709-2

TITLURI_AUTORI_CUVINTECHEIE2
ISBN Autor CuvntCheie
973-683-889-7 Marin Fotache baze de date
973-683-889-7 Marin Fotache SQL
973-683-889-7 Marin Fotache proceduri stocate
973-683-889-7 Marin Fotache FoxPro
973-683-889-7 Marin Fotache formulare
973-683-889-7 Marin Fotache orientare pe obiecte
973-683-889-7 Marin Fotache client-server
973-683-889-7 Marin Fotache web
973-683-889-7 oan Brava baze de date
973-683-889-7 oan Brava SQL
973-683-889-7 oan Brava proceduri stocate
973-683-889-7 oan Brava FoxPro
973-683-889-7 oan Brava formulare
973-683-889-7 oan Brava orientare pe obiecte
973-683-889-7 oan Brava client-server
973-683-889-7 oan Brava web
973-683-889-7 Ctlin Strmbei baze de date
973-683-889-7 Ctlin Strmbei SQL
973-683-889-7 Ctlin Strmbei proceduri stocate
973-683-889-7 Ctlin Strmbei FoxPro
973-683-889-7 Ctlin Strmbei formulare
973-683-889-7 Ctlin Strmbei orientare pe obiecte
973-683-889-7 Ctlin Strmbei client-server
973-683-889-7 Ctlin Strmbei web
FEAA nfoEc + CG - 2006/2007 63
973-683-889-7 Liviu Cre[u baze de date
973-683-889-7 Liviu Cre[u SQL
973-683-889-7 Liviu Cre[u proceduri stocate
973-683-889-7 Liviu Cre[u FoxPro
973-683-889-7 Liviu Cre[u formulare
973-683-889-7 Liviu Cre[u orientare pe obiecte
973-683-889-7 Liviu Cre[u client-server
973-683-889-7 Liviu Cre[u web
973-683-709-2 Marin Fotache baze de date
973-683-709-2 Marin Fotache algebr rela[ional
973-683-709-2 Marin Fotache SQL
Figura 3.23. O 3NF mai bun pentru relatia BIBLIOTECTUPLURINOISOLU]IA3
Se observ cu ochiul liber o diminuare a volumului ultimei tabele, astIel nct ne-am
ncumetat s reprezentm toate liniile. Rmne, n schimb, un grad de redundant chiar si n Iorma
'comprimat a tabelei.
Ca element de improvizatie, putem ncerca s adugm n BIBLIOTECTU-
PLURINOISOLUTIA3 cteva atribute care s ,atrag n dependente atributele Autor si
CuvntCheie. AstIel, pornim de la Iaptul c, pe coperta unei crti, autorii sunt trecuti ntr-o anumit
ordine, deloc ntmpltoare, iar la extragerea inIormatiilor despre crti aceast ordine trebuie
respectat. Prin urmare, introducem n schem atributul OrdineCoperta, mpreun cu DF: (ISBN,
OrdineCoperta) Autor. De asemenea, pentru a putea extrage crtile legate de unul sau mai
multe cuvinte cheie n ordinea relevantei, introducem atributul Revelanta ce indic nivelul la care
este tratat ntr-o carte o anumit notiune/sintagm (cuvnt cheie): (ISBN, CuvntCheie)
Relevanta. Pe baza acestor dou noi dependente, graIul din Iigura 3.22 se modiIic dup cum este
sugerat n Iigura 3.24.
Din noul graI, relatiile construite sunt aproape impecabile: EDITURI Editura, LocSediuEd},
CRTI ISBN, Titlu, AnAparitie, Editur}, AUTORICRTI ISBN, OrdineCopert, Autor},
CRTICUVINTECHEIE ISBN, CuvntCheie, Relevant}, EXEMPLARECRTI Cota, ISBN}.

Figura 3.24. Noul graf pentru relatia BIBLIOTEC (cu dou atribute noi)
3.6 DEPENDENTE MULTIVALOARE $I A PATRA FORM NORMAL
Formelele normalizate 4 si 5 constituie cea mai diIicil parte din procesul de normalizare a
unei baze de date. Aceasta este vestea rea. Vestea bun este c rareori proiectantii bazei trebuie s
ajung n acest stadiu al discutiilor, mai ales n ceea ce priveste 5NF, deoarece majoritatea cazurilor
practice pot Ii rezolvate onorabil prin aducerea bazei n 3NF/BCNF sau, uneori, n 4NF.
64 Baze de date
Dependentele Iunctionale discutate pn n acest paragraI sunt relativ usor de identiIicat si
explicat. n prezentul capitol vor Ii prezentate un tip dependente ceva mai diIicil depedentele multi-
valoare. ntruct incidenta practic a dependentelor de jonctiune si celei de-a cincea Iorme normale
este una nesemniIicatic, n acest curs acestea vor Ii trecute sub tcere.
3.6.1 Dependen(e multivaloare
Dependenta multivaloare sau multivaloric si, implicit, a patra Iorm normal au Iost
introduse la ctiva ani dup dependentele Iunctionale si primele trei Iorme normale, prin 1977 de ctre
Ronald Fagin
34
. Fie relatia R A
1
, A
2
,...., A
n
} si X, Y si Z trei subansambluri de atribute ale
ansamblului A
1
, A
2
,...., A
n
}. Exist o dependent multi-valoare (DMV) ntre X si Y dac si numai
dac: (a) la Iiecare aparitie (valoare) a lui X poate Ii asociat una sau mai multe aparitii (valori) ale lui
Y; (b) aceast asociatie nu depinde de aparitiile lui Z. Se noteaz X Y sau X Y , Z si
se spune c atributul Y este multidependent fat de atributul X sau c atributul X multidetermin pe
Y.
Cea mai rezonabil deIinitie a DMV o Iurnizeaz C.J. Date. Fie relatia R A
1
, A
2
,...., A
n
} si
X, Y si Z trei subansambluri ale ansamblului A
1
, A
2
,...., A
n
}. Exist o dependent multi-valoare
ntre X si Y n urmtoarea situatie: dac (x,v,:) i (x,v,:) sunt dou tuplete ale relatiei R, atunci
(x,v,:) i (x,v,:) apartin, de asemenea, lui R. ntr-o Iormulare usor schimbat, Elmasri si Navathe
deIinesc DMV de maniera urmtoare: dac n R exist dou tupluri t
1
si t
2
pentru care t
1
|X| t
2
|X|,
atunci exist n R alte dou tupluri, t
3
si t
4
, care satisIac urmtoarele conditii (notm prin Z toate
celelalte (dect X si Y) atribute din R, adic (R - (X U Y))):
t
3
|X| t
4
|X| t
1
|X| t
2
|X|
t
3
|Y| t
1
|Y| si t
4
|Y| t
2
|Y|
t
3
|Z| t
2
|Z| si t
4
|Z| t
1
|Z|
35
.
Dup cum aIirmam mai sus, aspectul contra-intuitiv al deIinitiei DMV tine de Iaptul c X este
independent de Y, ceea ce s-ar traduce prin 'X oarecare, Y oarecare. O bun explicatie n acest sens
o gsim n |Dollinger98|
36
: o valoare dat a lui X se gseste n R n combinatie (Iormeaz tupluri) cu
Iiecare pereche de valori (y,z) din produsul cartezian al multimilor Yx (valorile lui y care apar n
combinatie cu un x dat) si Zx. Aceasta nseamn ca multimile Yx si Zx sunt independente ntre ele.
Cele mai tentante exemple de DMV sunt cele teoretice, asa cum este cel din Iigura 5.24. n
aceast relatie exist nu exist nici una din dependentele Iunctionale: X / Y; X / Z ; Y
/ X; Y / Z; Z / X; Z / Y.

34
[Fagin77]
35
[Elmasri & Navathe 00], p. 514
36
[Dollinger98], p.163
FEAA nfoEc + CG - 2006/2007 65

Figura 5.24. Exemplu teoretic de relatie in care exist DMJ
La o examinare mai atent se observ dependentele multi-valoare X Y (sau X
Y , Z) si X Z (sau X Z , Y); aceasta deoarece n conditiile n care exist
tuplurile (x1,y1,z1) si (x1,y2,z2), exist si tuplurile (x1,y1,z2) si (x1,y2,z1).
Cel mai dureroas aspect al dependentelor multivaloare (si cele de jonctiune care vor urma),
tine de Iaptul c, n realitate, acestea trebuie identiIicate de ctre cei care Iac analiza si proiectarea
bazei de date, pe baza legturilor semantice dintre atributele bazei, si nu pe baza unui caz simplist (n
cazul nostru, o tabel cu sapte linii).

Profesori, cursuri & capitole
Cazul urmtor este aproape identic celui prezentat de C.J. Date n editiile sale ale lucrrii An
Introduction to Database Svstems
37
. Relatia are trei atribute: CPC Curs, Profesor, Capitol}
38
. La
o Iacultate "oarecare", pot exista mai multi proIesori titulari ai unei aceleasi discipline. Dac
presupunem c toti proIesorii cad de acord asupra unei programe unice pentru disciplina respectiv,
diIerentiat Iiind numai modul de "tratare" si ponderea Iiecrui capitol, putem imagina o situatie ca n
Iigura 5.25.
Analizm dependentele dintre atribute:
- Un acelasi curs poate Ii "tinut" de mai multi proIesori: Curs / Profesor
- Un curs este alctuit din mai multe capitole: Curs / Capitol
- Fiecare proIesor poate preda mai multe cursuri: Profesor / Curs si, implicit, Profesor
/ Capitol

Figura 5.25. Relatia CPC in care exist DMJ

37
Spre exemplu, [Date86], pp. 381-382
38
La C.J.Date rela[ia era CTX {Curs, Profesor, LucrareBibliografic}
66 Baze de date
- Un acelasi capitol poate aprea n cursuri diIerite. De exemplu, un capitol dedicat Potei Electronice
poate aprea si n cursul Ba:ele informaticii Economice si n cursul de Birotic. Capitolul Modelul
Entitate-Asociatie este n planul cursului de Ba:e de date, dar si al cursului Anali:a sistemelor
informatice (pentru modelul conceptual al datelor). Prin urmare, Capitol / Curs iar Capitol
/ Profesor.
Numai n conditiile unei programe unice, la nivelul Iaculttii, pentru Iiecare curs exist
dependentele multi-valoare: Curs Profesor; Curs Capitol.
C.J. Date Iace o observatie Ioarte bine venit: ntr-o asemenea relatie, pentru a introduce trei
proIesori si patru capitole ar Ii suIiciente patru linii, si nu 12 (3*4). Aceasta naste ns cteva
probleme: cum se realizeaz corespondenta proIesor-capitol, adic ce capitole a elaborat Iiecare
proIesor ? Numrul capitolelor Iiind mai mare ca al autorilor, pentru acele linii, ce proIesori apar ?
Cum este interpretat Iiecare linie n acest caz ? Cum se Iac actualizrile ? Dar discutiile acestea noi
le-am purtat deja mai spre nceputul capitolului.

Rela(ia COMENZI_PRODUSE_MATERIALE
O ntreprindere manuIacturier Ioloseste pentru conIectionarea unei unitti de produs Iinit o
serie de materii prime si materiale, n conIormitate cu Iisa tehnologic. Productia este pe comenzi. Se
poate imagina o tabel care s contin inIormatiile cu privire la ce materiale sunt necesare onorrii
unei anumite comenzi, COMENZIPRODUSEMATERIALE vezi Iigura 5.26.

Figura 5.26. Relatia COMENZIPRODUSEMATERIALE
n aceast tabel, este imperios necesar ca, atunci cnd un produs apare ntr-o comand, s se
introduc cte o linie pentru Iiecare material ce intr n Iabricatia produsului respectiv. Prin urmare,
exist dependentele multi-valoare: Produs Comanda , Material.

Din nou despre bibliotec
Cel mai convingtor exemplu de dependent multi-valoare este cel din relatia
BIBLIOTECTUPLURINOISOLUTIA3 pe care o prelum asa cum am lsat-o n Iigurile 3.22
(graIul) si 3.23 (continutul n 3NF-BCNF). n relatia TITLURIAUTORICUVINTECHEIE2 Iiecare
linie se reIer la un autor si un subiect (cuvnt cheie) pentru o carte (ISBN). Practic, pe baza acestei
tabele suntem n msur s obtinem inIormatii de genul:
ce crti a scris un anume autor,
FEAA nfoEc + CG - 2006/2007 67
despre ce subiecte a scris un anume autor,
care sunt autorii unei crti,
ce subiecte sunt tratate ntr-o carte,
care sunt crtile n care apare tratat un anume subiect,
care sunt autorii care au scris despre un subiect dat.
Pentru ca nici una dintre aceste inIormatii s nu se piard, exist un pret adecvat. Dac, pentru
o carte, apare o nou sintagm (cuvnt cheie), n relatie trebuie introdus nu un tuplu, ci n, unde n este
egal cu numrul autorilor acelei crti. Pentru o carte cu 5 autori si 10 cuvinte cheie, n relatia TI-
TLURIAUTORICUVINTECHEIE2 trebuie introduse nu mai putin de 50 de linii.
Pe baza Iaptului c pentru o carte, un autor trebuie s apar n combinatie cu toate
sintagmenele tratate si, vice-versa, orice sintagm apare n combinatie cu toti autorii crtii, exist
DMV: ISBN Autor , CuvntCheie si ISBN CuvntCheie , Autor.
3.6.2 A patra form normal
Desi mai exotic dect primele trei si BCNF, a patra Iorm normal (4NF) isi are importanta
sa. Margaret Wu
39
aIirma c, n timp ce majoritatea universitarilor si autorilor din zona normalizrii
tinde s neglijeze 4NF si 5NF, un studiu ntreprins ntr-o serie de Iirme ce Ioloseau (la nceputul aniloe
`90) aplicatii cu baze de date a scos la iveal c mai mult de 20 dintre schemele bazelelor de date
analizate violau 4FN. Prin comparatie, Wu nu a identiIicat nici un caz de violare a 5NF.
n lucrarea mentionat n paragraIul anterior, Ronald Fagin Iormuleaz o teorem conIorm
creia o relatie R cu trei atribute A, B si C poate Ii descompus Ir pierdere de inIormatii n dou
proiectii ale sale: R1A, B} si R2 A, C} dac si numai dac exist dependent multivaloare A
B , C. Aceasta este teorema care ne va permite aducerea unei relatii n 4NF.
O relatie este n 4NF dac si numai dac: (a) Este in BCNF, (b) Toate dependentele care se
manifest in cadrul su sunt dependente functionale, altfel spus, eventualele dependente multi-valoare
continute sunt, de fapt, dependente functionale.
Vom lua pe rnd exemplele prezentate n paragraIul anterior si vom ndeplini Iormalitatea
aducerii lor n 4NF. ncepem cu cel mai ndrgit exemplu, primul. Relatia XYZ din Iigura 5.24
prezint, asa cum am discutat, dependenta multi-valoare X Y , Z, n virtutea creia o putem
descompune n dou: XY X, Y} si XZ X, Z} ca n Iigura 5.27.

Figura 5.27. Aducerea relatiei XYZ in 4NF
Pe baza dependentelor multivaloare prezentate n paragraIul precedent, relatia CO-
MENZIPRODUSEMATERIALE (Iigura 5.26) se descompune ca n Iigura 5.28.

39
[Wu92]
68 Baze de date

Figura 5.28. Aducerea relatiei COMENZIPRODUSEMATERIALE in 4NF
Ceva mai interesant este situatia relatiei BIBLIOTECTUPLURINOISOLUTIA3 care,
dup cum am vzut n paragraIul precedent, contine o dependent multi-valoare. Prin eliminarea
acesteia (dependentei) vom aduce relatia n 4NF. Desi rareori ntlnit n literatura de specialitate,
reprezentarea graIic a DMV n graIul dependentelor nu ridic probleme deosebite, mai ales atunci
cnd cele trei atribute (X, Y si Z din deIinitiile noastre) sunt simple. Iat, n Iigura 5.29, care ar Ii o
posibil reprezentare si modul de decupare al relatiilor n 4NF din graI.

Figura 5.29. Graf ce contine deopotriv DF i DMJ
ConIorm obiceiului, se va constitui cte o relatie pentru Iiecare surs de dependent
Iunctional (Cota, ISBN si Editura). La aceste relatii se va adug cte o relatie pentru Iiecare
destinatie de dependent multi-valoare (Autor si CuvntCheie). Schema Iinal a bazei de date,
precum si continutul relatiilor sunt ilustrate n Iigura 5.30.
EDITURI
Editura LocSediuEd
Polirom ai

TITLURI
ISBN TitIu Editura AnApari|ie
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplica[iilor
profesionale
Polirom 2002

973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro Polirom 2001

EXEMPLARE
Cot ISBN
-13421 973-683-889-7
-13422 973-683-889-7
-13423 973-683-889-7
-10678 973-683-709-2
-10679 973-683-709-2

FEAA nfoEc + CG - 2006/2007 69
TITLURI_AUTORI
ISBN Autor
973-683-889-7 Marin Fotache
973-683-889-7 oan Brava
973-683-889-7 Ctlin Strmbei
973-683-889-7 Liviu Cre[u
973-683-709-2 Marin Fotache

TITLURI_CUVINTECHEIE
ISBN CuvntCheie
973-683-889-7 baze de date
973-683-889-7 SQL
973-683-889-7 proceduri stocate
973-683-889-7 FoxPro
973-683-889-7 formulare
973-683-889-7 orientare pe obiecte
973-683-889-7 client-server
973-683-889-7 web
973-683-709-2 baze de date
973-683-709-2 algebr rela[ional
973-683-709-2 SQL
Figura 5.30. 4NF pentru relatia BIBLIOTEC
Iat c, dup atta amar de capitole si discutii, am reusit s rezolvm de o manier acceptabil
problema schemei bazei de date destinate gestionrii inIormatiilor revelante despre crtile aIlate n
biblioteca unei Iacultti/universitti. Este, cred, inutil s mai intrm n delalii vis-a-vis de reducerea
volumului bazei, ca si cvasi-disparitia oricrei Iorme de anomalie la inserarea, modiIicarea sau
stergerea unei linii n oricare dintre cele cinci tabele.
3.6.3 Un mini-caz practic - baza de date FILMOGRAFIE
Discutiile despre aceast baz de date au rmas suspendate nc de pe la nceputul capitolului.
n paragraIul 3.2 semnalam necazurile pricinuite de valorile nule ale cheii primare n conditiile n care
o parte dintre premii era acordat la nivel de Iilm (Oscar pentru regie, Oscar pentru cel mai bun film
etc.), iar alt parte la nivel de actor pentru prestatia dintr-un Iilm (Oscar pentru cel mai bun
actor/actrit in rol principal/secundar). La acel moment singura solutia era constituirea a dou tabele
dedicate premiilor.
Pentru ceea ce urmeaz considerm atributele din tabelul 3.3. (paragraIul 3.2) ntre care
ncercm s determinm dependentele Iunctionale si multivaloare. AstIel, atributul IdFilm identiIic
Ir ambiguitate orice Iilm, asa c avem urmtoarea serie de DF: (1) IdFilm TitluOriginal;
(2) IdFilm TitluRO; (3)IdFilm AnLans.
Deoarece un Iilm poate Ii ncadrat la mai multe genuri (vezi Iigura 2.5) si avea mai multi
productori, regizori, actori si premii, IdFilm / Gen; IdFilm / Producator; IdFilm
/ Regizor; IdFilm / Actor; IdFilm / DenPremiu.
Un premiu se decerneaz ntr-o localitate (ex. Oscarul la Hollywood, Leul de argint la
Venetia, Ursul de aur la Berlin etc.): (4)DenPremiu LocDecernare
Premiile au, de obicei, mai multe categorii (ex. Oscarul are categoriile: Cel mai bun film, Cel
mai bun film strin, Efecte speciale, Regie etc.) si se acord de multi ani: DenPremiu /
Categorie; DenPremiu / AnPremiu.
Ne punem problema reIlectrii prin dependente a distributiei ntr-un Iilm. Dup cum am vzut
mai sus (de Iapt, stiam de mult), ntr-un Iilm sunt distribuiti mai multi actori; ns si un actor poate
70 Baze de date
juca n multe Iilme - Actor / IdFilm. Am avea de ales ntre dependentele (IdFilm, Actor)
Rol (poate era mai nimerit ca atributul s se numeasc Personaj) sau (IdFilm, Rol)
Actor. Dumneavoastr pe care ati alege-o ? Ei bine, prima n-ar Ii chiar indicat, deoarece exist Iilme
n care un actor joac un dublu rol (v mai amintiti Zmeura de aur pentru dublul rol al lui Leonardo di
Caprio din Iilmul Masca de fier, n care l interpreteaz pe regele Ludovic al XIV-lea si pe Iratele
regelui, unul "original" iar cellalt "mascatul" ?). n acest situatii valorile grupului (IdFilm, Actor)
sunt identice, n timp ce valorile atributul Rol sunt diIerite, ceea ce inIirm dependenta. Privitor la cea
de-a doua dependent, pericolul invalidrii ei ar aprea n situatia cnd ntr-un Iilm acelasi rol este
jucat de mai multi actori. Din Iericire rolurile nu sunt tocmai asa. Chiar si n Iilmele biograIice, sau
marile saga de Iamilie, diIeritele etape din viata unui personaj (copil, adolescent etc.) sunt marcate de
roluri diIerite. Asa c numrm a cincea dependent a relatiei, (5) (IdFilm, Rol) Actor.
Cel putin la Iel de interesant stau lucrurile si cu premiile. Faptul c Globul de aur
(DenPremiu) pentru Cea mai bun imagine (Categorie) a Iost decernat n 1988 (AnPremiu)
Iilmului Mai bine nu se poate (titlul original - As Good As It Gets), Iilm ce are codul (IdFilm) 11899
n baza noastr de date, ne-ar determina s scriem dependenta n Iorma: (DenPremiu, Categorie,
AnPremiu) IdFilm.
Ce ne Iacem, ns, cnd un premiu la aceeasi categorie este acordat simultan la dou Iilme ?
Nu e cazul Oscarurilor, dar, spre exemplu, cte o mentiune special din partea furiului (Categorie)
la editia din 2007 (AnPremiu) a Iestivalului Ursul de aur (Denpremiu) ar pute Ii acordat Iilmelor cu
identiIicatorii 7898843, 8967883 si 9312299. Dependenta este aruncat n aer. Solutia este ns pe-
aproape: un Iilm nu poate lua un acelasi premiu, la aceeasi categorie, n ani diIeriti, asa c schimbm
pozitia a dou atribute: (6) (DenPremiu, Categorie, IdFilm) AnPremiu.
Dependenta de mai sus nu rezolv problema premiilor acordate pentru prestatiile actoricesti, n
care laureat este un actor pentru prestatia dintr-un Iilm. Am putea alege ntre varianta (DenPremiu,
Categorie, AnPremiu, IdFilm) Actor si (DenPremiu, Categorie, AnPremiu, Actor)
IdFilm. Prima variant este minat dac ntr-un an un premiu (la aceeasi categorie) este
acordat simultan pentru doi actori care joac n acelasi Iilm. Situatia nu pare a Ii prea Irecvent, dar
nici imposibil, dac ne gndim la Iestivalurile mai putin poleite dect Oscar, Palme DOr etc. A doua
variant are si ea un competitor, croit dup analogia cu dependenta (6): (DenPremiu, Categorie,
IdFilm, Actor) AnPremiu. Initial eram tentat de aceast ultim Iorm, deoarece era similar
celei care reIlecta celelalte tipuri de premii. Exist, ns, o categorie de premii ce creaz o serie de
dureri de cap: premiile pentru ntreaga carier. Acestea nu sunt legate de un Iilm anume, ci rspltesc
o carier, mai lung sau mai scurt, de cineast. NeIiind legat de un Iilm, sursa dependentei, pe baza
creia vor constitui o relatie, ar contine n aceste situatii o valoare NULL (pentru IdFilm), ceea ce e
inadmisibil pentru o component a cheii primare. Cu toate acestea, vom pstra aceast dependent,
ntruct premiul pentru ntreaga carier nu se acord numai actorilor, ci si regizorilor (teoretic si altor
proIesiuni legate de industria/arta cinematograIic), iar dac optam pentru a doua variant tot nu
scpam de valori nule, e drept, pentru un atribut necheie. Ca s transm discutia, ntruct baza de date
se reIer la inIormatii despre Iilme, nu ne propunem s prelum premiile individuale, asa c ne
declarm multumiti de dependenta: (7) (DenPremiu, Categorie, IdFilm, Actor) AnPremiu
FEAA nfoEc + CG - 2006/2007 71
Au rmas neluate n seam trei atribute, Producator, Regizor si Gen. Intuitia ne spune c
este imposibil de stabilit vreo dependent ntre ele, chiar dac se reIer la acelasi Iilm. Pe de alt parte,
cele trei atribute par ct se poate de independente unele de altele. VeriIicm, mai nti, cerinta DMV
pentru primele dou. Dac Iilmul X cu id-ul 234556 are, printre regizori, pe Reg1 si Reg2 si cel putin
doi productori, Prod1 si Prod2, atunci trebuie s veriIicm c, dac atributele ar aprea ntr-o relatie
de tip R IdFilm, Producator, Regizor}, oricare dintre tuplurile urmtoare sunt posibile:

RELx
IdFiIm Productor Regizor
... ... ...
234556 Prod1 Reg1
234556 Prod2 Reg2
234556 Prod1 Reg2
234556 Prod2 Reg1
... ... ...
Figura 5.31. Raportul dintre atributele Productor i Regi:or
Prezenta ultimelor dou tupluri n relatia din Iigura 5.31 pare a Ii agreat, nu ns si necesar.
Schema de mai sus, ns, trebuie s Iurnizeze rspunsul corect la ntrebarea Care sunt filmele in care
productorul Prod1 a lucrat cu regi:orul Reg1 ? Faptul c, pentru a-si pstra viabilitatea
inIormational, relatia trebuie s contin toate cele patru tupluri constituie motiv suIicient pentru a
"trmbita" dependenta multivaloric: IdFilm Producator , Regizor.
Pe acelasi calapod, pornind de la rspunsul la ntrebarea Ce genuri de filme a produs/regi:at
un anumit cineast ?, putem demonstra c: IdFilm Producator , Gen sau IdFilm
Regizor , Gen. Forma Iinal a graIului dependentelor Iunctionale si multivalorice ar putea Ii cea
din Iigura 5.32.

Figura 5.32. Graful dependentelor pentru BD FILMOGRAFIE
Urmeaz partea cea mai Irumoas - decuparea relatiilor din graI. Sunt dou surse simple de
DF - DenPremiu si IdFilm si trei surse compuse - (IdFilm, Rol), (IdFilm, DenPremiu,
Categorie) si (IdFilm, Actor, DenPremiu, Categorie), asa c cinci relatii vor Ii obtinute din
dependentele Iunctionale. La acestea se mai adaug trei corespunztoare dependentelor multi-valoare.
Iat, deci, schema Iinal: PREMIIDENUMIRI DenPremiu, LocDecernare}, FILME IdFilm,
TitluOriginal, TitluRO, AnLans}, DISTRIBUTIE IdFilm, Rol, Actor}, PREMIIFILME
IdFilm, DenPremiu, Categorie,AnPremiu}, PREMIIINTERPRETARE IdFilm, Actor ,
DenPremiu, Categorie, AnPremiu}, PRODUCTORI IdFilm, Producator}, REGIZORI
IdFilm, Regizor}, FILMEGENURI IdFilm, Gen}.
72 Baze de date
3.7 CHEI SUROGAT
Folosind limbajul de lemn al tehnologiei inIormationale, putem spune c bazele de date
stocheaz persistent si gestioneaz varii inIormatii privitoare la Ienomene, procese, tranzactii,
persoane etc. din mai toate domeniile de activitate, n Iunctie de aplicatiile pentru care sunt proiectate
si implementate. Una din problemele de cpti n lucrul cu aceste entitti, procese, tranzactii etc. tine
de posibilitatea identiIicrii lor Ir ambiguitate.
3.7.1 Nevoia de surogate (n bazele de date)
nchipuiti-v ce-ar nsemna ca Iirma noastr s vireze cteva sute de milioane de lei n contul
unui client, pltind astIel o Iactur, iar contul respectiv s Iie conIundat cu un altul, al altui client. Sau
ce s-ar ntmpla dac la plata "pe card" a salariilor pltite s-ar produce niscaiva conIuzii: cei mai
oropsiti s-ar oripila vznd ct cstig seIii (conIirmnd luminoasa tez "impozita-i-ar naiba !" a unor
presedinti retardati istoric si economic), iar seIii ar Ii cel putin la Iel de oripilati, dac nu chiar ngroziti
de mnia popular/proletar.
Asa c vedem n jurul nostru tot soiul de "ingrediente" menite a Iace diIerentieri sau, altIel
spus, a identiIica Iiecare persoan, carte, Iactur, plat etc. Privind retrospectiv, n relatia
STUDENTIEXAMENE - Iigura 3.1, paragraIul 3.1.1 - Iiecare student este identiIicat de matricolul
su, iar disciplinele au un cod (CodDisc) unic prin care evitm conIuzia ce s-ar putea genera prin
Iolosirea exclusiv a denumirii disciplinei (respectiv, numelui studentului). De asemenea, valoarea
atributului NrFact este unic pentru orice Iactur emis de Iirma noastr si trimis unui client (baza
de date VNZRI). ISBN-ul este un cod unic asociat, la nivel mondial, unei crti tiprite, n timp ce
cota identiIic ntr-o bibliotec un exemplar al unei crti. Codul numeric personal (CNP-ul) este cel
mai bun mod de a identiIica o persoan, n timp ce codul Iiscal este un element de ncredere cnd ne
propunem s identiIicm un client.
Din contr, n paragraIul 3.1.4, n dictionarul bazei de date VNZRI (tabelul 3.1), am apelat
atribute cu oarecare doz de artiIicialitate CodCl (codul Iiecrui client), CodPr (codul Iircrui
produs), CodDoc (codul documentului) ca s nu mai vorbim de Codnc (codul Iiecrei ncasari).
Aceste atribute sunt exemple de cheie surogat. Dealtminteri, notiunea de surogat desemneaz un
produs artiIicial sau sintetic care este utilizat drept substitut pentru un produs natural. O cheie surogat
este o cheie artiIicial sau sintetic utilizat ca substitut al unei chei "naturale".
De cele mai multe ori, cheile surogat simpliIic graIul dependentelor Iunctionale si, implicit,
sarcina demarcrii relatiilor. AstIel, revenind la relatia LINIIARTICOLECONTABILE din Iigura
3.6 (paragraIul 3.3.1), stiind c o not contabil are mai multe operatiuni care, la rndul lor, contin mai
mai multe corespondente ContDebitor - ContCreditor, introducem dou atribute care s preia
explicatiile/comentariile despre note, respectiv, operatiuni - ExplicatiiNota si ExplicatiiOp.
Din paragraIul 3.3.1 stim c, n Iunctie de modul de contare, conIiguratia dependentelor poate Ii
sensibil diIerit. Pentru uniIormizarea celor dou variante de numerotare a notelor contabile, putem
recurge la dou atribute de tip cheie surogat. IdNotaContabila va Ii un numr unic asociat Iiecrei
note contabile, iar IdOperatiune va identiIica orice operatiune, indiIerent de nota contabil din care
Iace parte. GraIul ia conIiguratia din Iigura 5.33.
FEAA nfoEc + CG - 2006/2007 73

Figura 5.33. Dou chei surogat pentru LINIIARTICOLECONTABILE
Schema obtinut prin decuparea dependentelor din graI este: NOTECONTABILE
IdNotaContabila, NrNota, Data, ExplicatiiNota}, OPERATIUNI IdOperatiune, NrOp,
IdNotaContabila, ExplicatiiOp} si DETALIIOPERATIUNI IdOperatiune, ContDebi-
tor, ContCreditor, Suma}.
3.7.2 Puncte de vedere privind cheile surogat
Prerile despre cheile surogat sunt, Iireste, mprtite. Exist autori care Iac distinctia ntre chei
surogat deIinite/controlate de utilizatori si chei surogat gestionate exclusiv de sistem (SGBD). Pentru
Codd, cheile primare definite i controlate de utili:ator Iolosite ca surogate permanente pentru entitti,
ar prezenta trei diIicultti la ntrebuintare
40
:
Valorile cheilor surogat trebuie uneori schimbate. De exemplu, atunci cnd dou
companii Iuzioneaz, angajatii trebuie reuniti ntr-o sigur tabel, si nu este exclus ca,
datorit suprapunerilor, unele mrci s Iie modiIicate.
Dou relatii ar putea avea chei surogat utilizator deIinite pe domenii diIerite, chiar
dac entittile pe care le identiIic sunt aceleasi; de exemplu, o Iirm poate Ii
deopotriv client si Iurnizor al companiei noastre. n tabela FURNIZORI Iirma ar
putea Ii identiIicat prin CodFurnizor, iar n tabela CLIENTI prin CodClient. Desi
Iirma este aceeasi, ea este identiIicat prin dou chei surogat diIerite.
Uneori este necesar preluarea inIormatiei despre o entitate naintea atribuirii unei
chei surogat utilizator pentru aceasta sau, pe de alt parte, pstrarea valorii cheii
surogat chiar si dup ce entitatea nu mai constituie subiect al aplicatiei. Cazurile tipice
sunt cele ale candidatilor pentru angajarea pe un post (li se va atribui o marc doar
dac vor Ii angajati, atribuirea petrecndu-se dup angajare), sau cele ale angajatilor
pensionati.
Cele trei diIicultti sunt suIiciente lui Codd pentru a justiIica Iolosirea cheilor surogat sistem,
pe care utilizatorul nu le poate nici modiIica, iar uneori nici mcar vizualiza. AstIel, Iiecare entitate ar
avea propria cheie surogat, unic la nivelul ntregii baze de date. Dou chei surogat sunt identice dac
si numai dac desemneaz aceeasi entitate. Codd se gndea chiar si la o comand special de Iuzionare
(COALESCE) a dou chei surogat care desemneaz, n Iapt, aceeasi entitate. Mai mult, n articolul su
din 1979 publicat n ACM Transactions on Database Svstems, autorul pledeaz pentru un model
relational extins n care, printre multe altele, unul dintre domenii s serveasc drept surs pentru toate
cheile surogat din baz.

40
[Codd79]
74 Baze de date
La ntrebarea "Ce e mai preIerabil, s Iolosim cheile primare "naturale" sau cele surogat ?" nu
exist un rspuns universal sau, chiar dac ar exista, am evita s-l dm. Atunci cnd atributul/atributele
ce identiIic entitatea sunt disponibile si stabile n timp, solutia "natural" este mai la ndemn: CNP-
ul pentru persoane, ISBN-ul pentru crti, CodFiscal pentru Iirme. Cnd apar probleme de
identiIicare, iar unicitatea este asigurat de un mare grup de atribute, sau cnd atributul/atributele
potentiale chei nu prezint stabilitate pe termen lung, atunci solutia "surogat" este cea mai indicat. La
exemplele din acest paragraI, mai putem aduga:
Seria si numrul de buletin/carte de identitate - desi identiIic Iiecare persoan, peste
un numr de ani, datorit schimbrii buletinului/crtii de identitate, combinatia si
schimb valoarea, iar dac s-au Icut deja arhivri, vor aprea complicatii.
Matricol - n multe scoli, licee si universitti s-a practicat un sistem simplu de
atribuire a numrului matricol, astIel nct, dup ctiva ani, un matricol era "reciclat".
Cutarea n baza de date arhiv a liceului ar ridica probleme mari, dac intervalul care
intereseaz este de ordinul deceniilor. Necazuri similare ar aprea dac unele Iirme ar
recicla, n timp, mrcile angajatilor, numerele de inventar ale mijloacelor Iixe etc.
Asemenea gen de discutii este valabil ns si la reciclarea cheilor surogat, asadar ideea Iolosirii
unor surogate-sistem se poate dovedi beneIic.
Dintre materialele dedicate cheilor surogat, v-am recomanda pe cele scrise de Mike Lonigro
41
,
Ian Harrington
42
, Graeme C. Simsion
43
si Fabian Pascal. n ceea ce m priveste, nu mprtsesc nici
lehamitea unor autori Iat de cheile surogat, mergndu-se, n acest sens, pn la a le "demasca" drept
identiIicatoare deghizate de obiecte (celebrele OID-uri din orientarea pe obiecte), dar nici Irenezia
"surogrii" maniIestat de multi proiectanti de baze de date, desi, recunosc, Irenezia cu pricina nu are
nimic toxic n ea, ci, mai degrab, tine de un soi de lene (subscriu cu toat inima la ideea c lenea nu e
toxic, dac nu e nsotit de "aditivi").
O alt temere legat de cheile surogat priveste ngreunarea accesului la inIormatiile din baza
de date, ntruct acesta nu se mai realizeaz prin atribute explicite, ci prin numere destul de irelevante
pentru obiectul/entitatea n cauz. Ori, utilizatorii obisnuiti ar Ii obligati s retin kilograme ntregi de
ciIre nesuIerite, doar pentru a obtine datele de care au nevoie. Nici acest neajuns nu trebuie s
descurajeze, deoarece trebuie s vedem o aplicatie, indiIerent de tipologia sa, pe cel putin dou
straturi, date si interfat. n majoritatea coplesitoare a cazurilor, utizatorii interactioneaz cu baza doar
prin meniuri, rapoarte si mai ales Iormulare, iar cheile surogat pot Ii chiar ascunse.
n orice caz, dac nu am reusit s transm discutia chei naturale-chei surogat, mcar s artm
cu degetul pe cele mai toxice: cheile inteligente. AstIel, au existat Iirme n care angajatii
compartimentelor personal-salari:are audiaser sau au citiser n cursurile de baze de date sau
analiz/proiectare despre teoria codurilor si, la angajarea unei persoane la compartimentul
Contabilitate, i atribuiau o marc de tip CTB85CC101, n care primele trei litere semnalizau c este
ncadrat la compartimentul Contabilitate, iar cele dou C-uri semnalizau biroul Calculatia costurilor,
n cadrul compartimentului Contabilitate. Partizanii acestui sistem argumentau c marca ar contine, n
acest Iel, inIormatii pretioase (compartimentul si biroul) despre Iiecare angajat, cheia Iiind chiar, dup
unii autori, inteligent.

41
[Lonigro98]
42
[Harrington02], pp.77-82
FEAA nfoEc + CG - 2006/2007 75
Dup cinci ani, ns, persoana respectiv se transIer la compartimentul Financiar. Asta
nseamn c marca, Iiind inteligent, trebuie schimbat. Costul schimbrii depinde de ntrebarea: unde
se aIl cele 5 (ani) * 12 (luni) nregistrri despre calcululul lunar al salariului, plus 5(ani) * 12 (luni) *
20 (zile lucrtoare) nregistrri, dac pontajul se preia zilnic ? Rspunsul poate Ii nsotit de apstoare
dureri de cap.
Nu ntotdeauna atributele implicate n schema bazei pot Ii identiIicate cu usurint. Mai mult,
deseori nu stric o doz rezonabil de artiIicial, de improvizatie, doz care poate salva pe termen lung
o schem sau mcar s o scuteasc de multe necazuri. Desi mai putin intuitiv dect modelul obiectual,
relationalul are certe atuuri n ceea ce priveste mecanismul de declarare a restrictiilor si mai ales n
ceea ce priveste optiunile de extragere a inIormatiilor din baz (mecanismul de manipulare a datelor).
Chiar si asa, rmn n discutie o mare parte din restrictii care tin de integritatea bazei de date, dar sunt
legate nu att de reguli intrinseci modelului (cheie primar, restrictie de entitate, integritate
reIerential), ct de regulile aplicatiei, sau, altIel spus, reguli ale aIacerii. Din pcate, nici un model de
date nu oIer un mecanism inIailibil de declarare a tuturor restrictiilor semantice dintr-o baz de date.
3.8 DEPENDENTE DE INCLUZIUNE
Este greu de explicat motiv pentru care toate crtile majore care trateaz problema
normalizrii si, n general, proiectarea bazelor de date, sunt att de discrete n materie de dependente
de incluziune. Nu-i vorb c notiunea ar Ii din cale-aIar de diIicil, ci mai deagrab c n aplicatiile
economice, chiar de calibru mediu, este aproape imposibil s nu se maniIeste un asemenea gen de
dependent.
ntr-o exprimare lejer, ntre dou atribute X si Y exist o dependent de incluziune (DI) dac
si numai dac orice valoare a lui X este obligatoriu si valoare a lui Y si se noteaz simplu X Y. Mai
general, o DI semniIic Iaptul c proiectia pe m atribute date ale relatiei R este un subset al proiectiei
pe m atribute date din relatia S. De aici si caracterizarea DI ca dependente interrelatii
44
. DeIinitia ns
nu oblig ca R si S s Iie neaprat distincte, deci DI se poate institui ntre atribute si grupe de atribute
ale aceleasi relatii. Dup Casanova s.a., DI semnalizeaz relatiile de tip este-un/o
45
, iar Sciore este si
mai limpede cnd scrie c Iolosim DI pentru a arta c dou atribute din relatii diIerite se reIer la
acelasi lucru
46
. Am putea amenda aIirmatia lui Sciore prin precizarea Iaptului c atributele nu trebuie
neaprat s Iie din relatii diIerite.
Cel mai Irecvent exemplu de DI este Manager Angajat
47
, care nseamn c orice manager
este un angajat al companiei. GraIul din Iigura 5.34 ilustreaz o situatie comun n Iirmele de
pretutindeni: Iiecare angajat al unei ntreprinderi este arondat unui compartiment (Productie,
Marketing, Personal, Financiar, Contabilitate etc.); Iiecare compartiment are un singur seI; Iiecare seI
este, si el, angajat, chiar dac mai uit uneori de lucrul acesta.

43
[Simsion01], pp.282-285
44
[Fagin 81]
45
[Casanova s.a.82]
46
[Sciore83]
47
[Fagin81], [Casanova s.a.82], [Johnson & Klug82], [Sciore83]
76 Baze de date

Figura 5.34. O dependent de inclu:iune
Dependenta de jonctiune reprezentat prin sgeata punctat este, deci, MarcaSef Marca.
Decuparea relatiilor din graI nu ridic mari probleme. Avem dou surse de DF, prin urmare cele dou
relatii vor Ii: PERSONAL Marca, NumePren, Adresa, Compartiment} si COMPARTIMENTE
Compartiment, MarcaSef}. Dependenta de incluziune va Ii ncorporat n schem sub Iorma
restrictiei reIerentiale dintre COMPARTIMENTE.MarcaSef si PERSONAL.Marca.

Frunze yi conturi
Ne ndeprtm de exemplele consacrate, apelnd la baza de date CONTABILITATE, pe care,
dup discutia din paragraIele precedente, am adus-o la schema: NOTECONTABILE
IdNotaContabila, Data, ExplicatiiNota}, OPERATIUNI IdOperatiune,
IdNotaContabila, ExplicatiiOp, NrConturiDebitoare, NrConturiCreditoare,
UnContDebitor, UnContCreditor} si DETALIIOPERATIUNI IdOperatiune,
ContDebitor, ContCreditor, Suma}. Ei bine, a sosit momentul pentru a introduce una din cele
mai importante restrictii ale unei aplicatii de contabilitate general: conturile care apar n operatiunile
contabile nu trebuie s aib conturi sintetice/analitice subordonate !
S ncepem explicatiile mai din "amonte". Pentru reIlectarea elementelor patrimoniale, a
capitalului, datoriilor si obligatiilor, contabilitatea Ioloseste conturi organizate n serii, clase si grupe
48
.
De exemplu, n seria 1 sunt incluse conturile organice de bilant, n seria 2 conturile de procese, n seria
3 conturile de rezultate, n seria 4 conturile n aIara bilantului (extrapatrimoniale), iar n seria 5
conturile privind circuitul contabilittii manageriale. Seria 1 contine 7 clase, pentru: capitaluri, active
imobilizate, stocuri, terti, trezorerie, regularizare si conturi rectiIicative. Fiecare clas are una sau mai
multe serii de conturi. AstIel, clasa Stocuri are sapte grupe: materii si materiale, obiecte de inventar;
productie n curs; produse; stocuri la terti; animale; mrIuri; ambalaje. n Iiecare grup sunt conturile
propriu-zise care pot Ii sintetice de ordinul 1 (alctuite din trei ciIre) sau de ordinul 2 (patru ciIre).
Fiecare sintetic de ordinul 2 apartine unui sintetic de ordinul 1. Tabelul 3.5 indic o portiune din
planul de conturi al Iirmei X. Orice tip cont sintetic poate Ii descompus pe conturi analitice, n Iunctie
de speciIicul si interesele ntreprinderii.
Tabel 3.5. Extras din planul de conturi al unei firme
SimboI cont TipCont Denumire cont

CIasa: Conturi de CAPITALURI
...
101 pasiv Capital social
1011 pasiv Capital social subscris ne-vrsat
1012 pasiv Capital social subscris vrsat
...

48
Vezi, spre exemplu, Horomnea, E. - Bazele contabilittii. Concepte, aplicatii, lexicon, Editura Sedcom Libris,
ai, 2004, pp. 178-180
FEAA nfoEc + CG - 2006/2007 77
211 activ Terenuri i amenajri
2111 activ Terenuri
2112 activ Amenajri
....
301 activ Materii prime
301.01 activ Nisip
301.02 activ Ciment
301.03 activ Var
301.09 activ Alte materii prime
...
308 bifunc[ional
49
Diferen[e de pre[ la materii prime
...
401 pasiv Furnizori
401.01 pasiv Furnizor A
401.02 pasiv Furnizor B
401.99 pasiv Al[i furnizori
...
428 bifunc[ional Alte crean[e i datorii fa[ de salaria[i
4281 activ Alte crean[e fa[ de salaria[i
4282 pasiv Alte datorii fa[ de salaria[i
...
411 activ Clien[i
...
4426 activ TVA deductibil
4427 pasiv TVA colectat
...
601 activ Cheltuieli cu materii prime
601.01 activ Cheltuieli cu nisipul
601.02 activ Cheltuieli cu cimentul
601.03 activ Cheltuieli cu varul
601.09 activ Cheltuieli cu alte materii prime
...

AstIel, contul 301 - Materii prime este decompus pe patru analitice. Primele trei, 301.01,
301.02 si 301.03, reprezint cele mai importante materii prime pentru Iirm, iar ultimul, 301.09 le
grupeaz pe toate celelalte. Mai sunt descompuse pe analitice conturile de furni:ori (401) si cheltuieli
cu materiile prime (600). Interesant c un cont sintetic de gradul I biIunctional (428) poate avea un
"subordonat" de activ (4281), si un altul de pasiv (4282) !
Din moment ce am devenit mai rigurosi, este evident c, practic, putem introduce n schem
atributele SimbolCont, TipCont, DenumireCont, iar ntre ContDebitor si SimbolCont, pe de o
parte, si ContCreditor si SimbolCont, pe de alt parte, avem de-a Iace cu o dependent de
incluziune. GraIul dependentelor ia Iorma din Iigura 5.35.

Figura 5.35. Dependentele functionale i de inclu:iune pentru BD CONTABILITATE
78 Baze de date
Relatia nou ce rezult din graI este evident: PLANCONTURI SimbolCont, TipCont,
DenumireCont}, iar cele dou dependente de incluziune se vor materializa la implementarea bazei n
dou restrictii reIerentiale (vezi listingul de pe pagina web).

Proiecte vechi yi noi
Am recurs la un exemplu privind proiectele derulate ntr-o Iirm cu ocazia paragraIului 5.4,
pentru a ilustra Iorma normalizat Boyce-Codd. Acum, ns, ne apropiem de realitatea dintr-o
companie, lund n calcul urmtoarele elemente:
un angajat, identiIicat prin Marca este inclus n schema unui compartiment Iunctional
(Contabilitate, Marketing etc.);
orice compartiment are un singur seI (MarcaSef);
Iirma, datorit speciIicului activittii sale, lucreaz pe baz de proiecte; Iiecare proiect are un
identiIicator (IdProiect), demareaz la o anumit dat (DataProiect) si are un termen de
realizare (Termen);
un proiect este alctuit din una sau mai multe activitti (IdActivitate), o activitate avnd o
titulatur (DenActivit) si o scurt descriere (DescActivit);
orice angajat este capabil s desIsoare una sau mai multe activitti;
un angajat poate lucra la mai multe proiecte;
la un proiect sunt angajate una sau mai multe persoane;
activitate poate Ii inclus n unul sau mai multe proiecte;
n cadrul unui proiect, Iiecare activitate ncepe la o anumit dat (Datanceput), se
Iinalizeaz la o alt dat (DataFinal) si const ntr-o serie de operatii, responsabilitti si
rezultate (Detalii);
aceeasi persoan poate desIsura, n acelasi proiect, una, dou sau mai multe activitti;
activitate ntr-un proiect poate Ii desIsurat de mai multe persoane.
Dependentele corepunztoare acestor cerinte pot Ii reprezentate sub Iorm de graI ca n Iigura 5.36.
n graIul de mai sus exist o serie de inIormatii care nu pot Ii Iurnizate de schema construit
pe baza decuprii relatiilor:
- care sunt activittile pe care le poate desIsura o persoan ?
- n ce proiecte a Iost implicat un angajat ?
- care sunt persoanele implicate ntr-un anumit proiect ?
- care este activitatea, sau activittile, desIsurate de o anumit persoan ntr-un proiect dat ?
- care sunt persoanele care au desIsurat o anumit activitate ntr-un anumit proiect ?


49
A fost o vreme cnd la aceast facultate picai sigur la examele de Contabilitate dac afirmai c exist conturi
bifunc[ionale. Acum pute[i pica i pentru alte motive !
FEAA nfoEc + CG - 2006/2007 79

Figura 5.36. Dependentele ba:ei de date PROIECTE
O prim artiIiciu ar Ii introducerea n schema bazei si alte atribute care s "Iixeze" toate
legturile neprinse n dependente. AstIel, un angajat poate Ii "legat" de o anumit activitate pe care o
poate desIsura printr-un atribut nou, Competente, care s sugereze abilittile si experienta
angajatului n privinta activittii cu pricina: (Marca, IdActivitate) Competente. Pe de alt
parte, participarea unui angajat ntr-o activitate din cadrul unui proiect poate Ii descris cu ajutorul a
trei atribute - Atributii, Probleme si Rezultate - care indic ce sarcini a avut angajatul legat de
acea activitate din cadrul proiectului, ce probleme a ntmpinat si care au Iost rezultatele muncii sale.
Dependentele sunt evidente: (Marca, IdProiect, IdActivitate) Atributii, (Marca,
IdProiect, IdActivitate) Probleme si (Marca, IdProiect, IdActivitate)
Rezultate. Noul graI s-ar prezenta ca n Iigura 5.37, noile atribute Iiind scrise "aplecat" (italic).

Figura 5.37. Noul graf al dependentelor BD PROIECTE
Relatiile decupate din graI sunt urmtoarele: PERSONAL Marca, Numepren, Adresa,
Compartiment}, COMPARTIMENTE Compartiment, MarcaSef}, ACTIVITTI IdActivi-
tate, DenActivit, DescrActivit}, COMPETENTE Marca, IdActivitate, Competente},
PROIECTE IdProiect, TitluProiect, MarcaSefProiect, DataLansare, Termen}, ACTIVI-
TTIPROIECTE IdProiect, IdActivitate, Datanceput, DataFinal, Detalii} si PER-
SOANEACTIVITTIPROIECTE IdProiect, IdActivitate, Marca, Atributii, Probleme,
Rezultate}.

Alte frunze, dar aceleayi conturi
Solutiei la care am ajuns n acest paragraI pentru schema bazei de date CONTABILITATE i
se poate reprosa, printre altele, Iaptul c, uneori, la inserarea unei linii n PLANCONTURI trebuie
80 Baze de date
modiIicate alte linii din aceeasi tabel, ceea ce nu este posibil n toate SGBD-urile. Iar dac la inserare
lucrurile mai pot Iunctiona, declansatorul de modiIicarea are sanse considerabile s se mpotmoleasc.
Pentru a ncerca s ajungem la urmtoarea solutie, pornim de la dependentele continute n
graIul din Iigura 5.35. Dependentele de incluziune dintre ContDebitor, pe de o parte, si
ContCreditor, pe de alt parte, si SimbolCont sunt discutabile. De Iapt, restrictia este ca toate
conturile debitoare si creditoare din orice nregistrare contabil s Iie elementare (Irunze), adic s nu
Iie descompuse pe analitice (sau sintetice de ordinul 2). Putem deIini, deci, un atribut denumit ContE-
lementar care identiIic (printr-o valoarea boolean TRUE sau sir de caractere "Da") un cont
"Irunz". Putem vorbi de o "specializare" a conturilor, cele dou dependente de incluziune initiale
Iiind acum ContDebitor ContElementar, respectiv ContCreditor ContElementar, la care
se adaug ContElementar SimbolCont. Spre deosebire de celelate dou, ultima DI indic o
specializare. Noul graI al dependentelor este cel din Iigura 5.38.


Figura 5.38. Trei dependente de inclu:iune, dintre care una semnific o speciali:are
Decupnd relatiile din graI, obtinem: PLANCONTURI SimbolCont, TipCont,
DenumireCont}, CONTURIELEMENTARE ContElementar }, NOTECONTABILE IdNo-
taContabila, Data, ExplicatiiNota}, OPERATIUNI IdOperatiune, IdNotaContabila,
ExplicatiiOp, NrConturiDebitoare, NrConturiCreditoare, UnContDebitor,
UnContCreditor} si DETALIIOPERATIUNI IdOperatiune, ContDebitor, ContCreditor,
Suma}. Lucrurile sunt chiar interesante, deoarece acum restrictiile reIerentiale se stabilesc astIel: (a)
ntre DETALII_OPERATIUNI.ContDebitor (copil) si CONTURI_ELEMENTARE.ContElementar
(printe); (b) ntre DETALII_OPERATIUNI.ContCreditor (copil) si CONTURI_ELEMENTA-
RE.ContElementar (printe); (c) ntre CONTURI_ELEMENTARE.ContElementar (copil) si
PLAN_CONTURI.SimbolCont.
3.9 CAZ PRACTIC - CENTRU DE NCHIRIERE CASETE VIDEO
Desi nu ntotdeauna la zi cu legislatia pentru protectia drepturilor de autor, centrele de
nchiriere de casete video au constituit o aIacere tentant, mai ales n anii '90 si, am putea spune, si are
nc clientela sa, desi HBO-ul, n general, televiziunea prin cablu constituie un concurent Ioarte
puternic. Pentru a-l putea diIerentia de concurent, vrem ca baza de date a centrului pentru care lucrm
s oIere si date care s ajute la Iidelizarea clientilor:
FEAA nfoEc + CG - 2006/2007 81
- inIormatii despre Iilme: genul de Iilm, distributie, realizare (scenariu, regie) etc.;
- premiile importante luate de Iilme: premiul, categoria, anul decernrii;
- date despre mprumuturi, restituiri si ntrzieri;
- inIormatii statistice, de genul: Iilmele cele mai cerute, clientii cei mai Iideli, clientii cu cele mai mari
ntrzieri la returnarea casetelor;
- date despre clienti: zi de nastere/onomastic, genuri preIerate si, implicit, structura pe vrste si
ocupatii ale clientilor;
- un sistem de evaluare (rating, n termeni elevati) a Iilmelor de ctre clienti.
Ceea ce am discutat despre baza de date FILMOGRAFIE n capitolele anterioare ne este deci
de mare Iolos pentru cele ce urmeaz. n privinta atributelor surogat, de la nceput este evident c am
avea nevoie de cel putin trei:
IdFilm - pentru identiIicarea Ir ambiguitate a unui Iilm;
IdCaseta - un numr unic pentru diIerentierea ntre ele a casetelor;
Idmprumut - numr atribuit Iiecrui mprumut de una sau mai multe casete, la un moment
oarecare.
Pentru identiIicarea clientilor am putea s considerm codul numeric personal (CNP-ul) ca
Iiind multumitor. Din paragraIul 3.6.3 ne-au rmas cteva dependente memorabile, unele Iunctionale:
(1) IdFilm TitluOriginal
(2) IdFilm TitluRO
(3) IdFilm AnLans
(4) DenPremiu LocDecernare
(5) (IdFilm, Rol) Actor
(6) (DenPremiu, Categorie, IdFilm) AnPremiu.
(7) (DenPremiu, Categorie, IdFilm, Actor) AnPremiu
iar altele multi-valorice: IdFilm Producator , Regizor; IdFilm Producator ,
Gen sau IdFilm Regizor , Gen. Adugm si scenaristul, asa c: IdFilm
Producator , Scenarist sau IdFilm Regizor , Gen.
Caseta este identiIicat de atributul IdCaseta, astIel c putem scrie:
(8) IdCaseta DataCumpararii
(9) IdCaseta ProducatorCaseta
(10) IdCaseta AnProdCaseta
(11) IdCaseta PretCumparare
Anticipnd o cerere mai mare, un Iilm poate Ii comprat n mai multe exemplare, deci pe mai
multe casete: IdFilm / IdCaseta. Nici reciproca nu e prea valabil, ntruct pe o caset pot Ii
adunate Iilme de mai mic dimensiune, scurt metraje (doar trei exemple: Iilmuletele cu Stan si Bran,
Chaplin si Tom si Jerry): IdCaseta / IdFilm.
Pentru a putea gestiona coerent toate Iimele (scurt metraje sau nu) de pe o caset, apelm la un
atribut de genul FilmNr, adic numrul de ordine al Iilmului de pe o caset (v amintiti de atributul
Linie pentru Iacturi ?). Asa c:
(12) (IdCaseta, FilmNr) IdFilm
82 Baze de date
Am zice c problema raportului Iilme-casete este transat. Da' de unde ! Persoanele mai
simtitoare poate-si amintesc de Iebra pre-telenovelist declansat de un Iilm epopee - Pasrea Spin. Ei
bine, ca si alte Iilme-maraton, acesta se ntinde pe mai multe casete. AstIel nct, spre exemplu, pe o
caset poate Ii partea a patra a Iilmului XYZ. Din Iericire, dependenta de mai sus nu este compromis,
ns am avea nevoie de un atribut aditional - ParteFilm, iar dependenta s-ar putea scrie:
(13) (IdCaseta, FilmNr) ParteFilm
Ba chiar putem Ii siguri c, pe o caset, casa productoare poate s introduc ultima parte a
unui Iilm plus un scurt-metraj de acelasi regizor sau un medalion actoricesc etc.
Despre clienti, numai de bine:
(14) CNPClient NumeClient
(15) CNPClient AdresaClient
(16) CNPClient TelefonClient
(17) CNPClient DataNastereClient
(18) CNPClient NivelStudiiClient
Un client poate mprumuta una sau mai multe casete. Fiecare mprumut este identiIicat printr-
o cheie surogat - Idmprumut, asa c:
(19) Idmprumut DataOraImprumut
(20) Idmprumut CNPClient
Deoarece simultan se pot mprumuta mai multe casete, Idmprumut / IdCaseta, ceea
ce e destul de nelinistitor, atta vreme ct obiectivul central al aplicatiei este de a gestiona
mprumuturile de casete. Fireste, prima tentantie este de a recurge la un atribut suplimentar, ca n cazul
liniilor din Iacturi, atribut creia i putem spune chiar NrCrtmpr (adic un soi de numr curent al
mprumutului, numr care indic a cta caset din mprumut este cea curent), asa c, cu un pic de
crpeal, problema s-ar rezolva:
(Idmprumut, NrCrtmpr) IdCaseta
Dac adugm c restituirea casetelor nu este ntotdeauna simultan, adic un client poate
mprumuta trei casete ntr-o smbt dimineat si s returneze una smbt seara si celelalte dou
duminic, se poate scrie, Iie (Idmprumut, NrCrtmpr) DataOraRestituirii, Iie
(Idmprumut, IdCaseta) DataOraRestituirii. Eu, unul, as alege varianta din urm.
Ei bine, dac privim mai atent ultima dependent, observm c, la o adic, aceasta ar Iace de
prisos atributul NrCrtmpr. DiIerenta dintre varianta Iolosirii atributului NrCrtmpr (varianta 1) si
cea Ir (a doua) este ilustrat n Iigura 5.39.

Figura 5.39. Dou variante de dependente pentru imprumuturi i restituiri
FEAA nfoEc + CG - 2006/2007 83
Fiecare si are avantajele si dezavantajele sale. Prima pare mai complicat si, totodat, are un
usor aer de artiIicialitate indus de Iolosirea NrCrtmpr. Cel mai important avantaj al su tine de
Iaptul c preia Ioarte bine succesiunea temporal mprumut (prima DF cu sursa compus) - restituire
(a doua). Consecinta esential este c n schem nu apar valori nule. GraIul din dreapta Iigurii este
mult mai simplu. Din momentul mprumutului pn n cel al restituirii valoarea atributului DataO-
raRestuirii ar Ii NULL. AstIel, pentru a aIla n orice moment casetele aIlate la clienti, conditia n
SQL ar Ii DataOraRestuirii S NULL. Tocmai adversarii Iolosirii valorilor nule ar dezaproba aceast a doua
solutie. Noi, ns, neIiind dusmani (dar nici prieteni) ai nulittii n bazele de date relationale, vom opta
pentru aceast a doua solutie, chiar dac lenea a cntrit mult n alegere. Asadar:
(21) (Idmprumut, IdCaseta) DataOraRestituirii

S adunm tot ce-am discutat pn acum ntr-un graI. Figura 5.40 este reprezentare destul de
bun a ansamblului de dependente Iunctionale (1)-(21), plus cele multivaloare. Este drept, aglomeratia
este cam mare, dar arta cere sacriIicii.

Figura 5.40. Graful DF pentru BD Centru de inchiriere - versiunea 1.0
Decupm relatiile din graI: PREMIIDENUMIRI DenPremiu, LocDecernare}, FILME
IdFilm, TitluOriginal, TitluRO, AnLans}, DISTRIBUTIE IdFilm, Rol, Actor}, PRE-
MIIFILME IdFilm, DenPremiu, Categorie,AnPremiu}, PREMIIINTERPRETARE
IdFilm, Actor , DenPremiu, Categorie, AnPremiu}, PRODUCTORI IdFilm, Produca-
tor}, REGIZORI IdFilm, Regizor}, SCENARISTI IdFilm, Scenarist}, FILMEGENURI
IdFilm, Gen}, CASETE IdCaseta, DataCumpararii, ProducatorCaseta, AnProdCaseta,
PretCumparare}, CASETEFILME IdCaseta, FilmNr, IdFilm, ParteFilm}, CLIENTI
CNPClient, NumeClient, AdresaClient, TelefonClient, DataNasteriiClient, Ni-
velStudiiClient}, MPRUMUTURI Idmpr, DataOrampr, CNPClient}, si CASETEM-
PRUMUTATE Idmpr, IdCaseta, DataOraRestituirii}

Schema pare a rspunde necesarului inIormational pe care ni-l propusesem initial. AstIel,
putem aIla: numrul de casete mprumutate de un client pe o anumit perioad; ponderea comediilor
84 Baze de date
ntre Iilmele nchiriate de un client, sau pe tot centrul; ce genuri de Iilme preIer tinerii ntre 30 si 35
de ani cu studii medii etc. S ne ocupm ns de regulile scrise sau nescrise ale centrului:
- un client nu poate mprumuta mai mult de patru casete simultan !
- la Iiecare 10 casete mprumutate, un client are dreptul la o caset mprumutat gratuit;
- mprumutul este pentru 48 de ore; la remiterea casetei se calculeaz o penalizare de 75 din pretul
de nchiriere al casetei pentru Iiecare zi de ntrziere; iat si tariIele zilnice la nchiriere:
50 000 lei pentru casetele produse n anul calendaristic curent si cel precedent;
40 000 lei pentru casetele produse n urm cu doi si trei ani;
30 000 lei pentru restul.
- pierderea sau distrugerea unei casete antreneaz o amend care reprezint dublul pretului casetei.

Pentru prima regul se poate introduce un atribut redundant numit NrCaseteNerestituite,
atribut actualizabil la declansatoarele de inserare, modiIicare si stergere n
CASETEMPRUMUTATE. Acest atribut ar depinde de CNPClient: CNPClient
NrCaseteNerestituite. Ba chiar am putea exagera si mai mult, Iolosind dou atribute depen-
dente de CNPClient, unul NrCasetemprumutate si altul NrCaseteRestituite. Paradoxal,
desi ideea pare deplasat, exist argumente n Iavoarea sa. Iar, ntruct a doua regul spune c la
fiecare 10 casete imprumutate, un client are dreptul la o caset imprumutat gratuit chiar ne convin
ambele atribute, asa c, n dezaprobarea publicului, ne precipitm si scriem:
(22) CNPClient NrCasetemprumutate
(23) CNPClient NrCaseteRestituite

A doua regul e centrului reprezint o tentativ de a Iideliza clientii, mai ales pe cei depen-
denti: la 10 casete inchiriate, a 11-a este imprumutat gratuit. Noroc de atributul NrCasetempru-
mutate de mai sus, pentru c, n conditiile n care acesta este actualizat corect, putem sti n orice
moment dac se cuvine s acordm gratuitatea sau nu. Pentru a cunoaste, totusi, n timp, cte casete au
Iost mprumutate cu titlu gratuit, am putea recurge la un atribut nou, Gratuita, care s ia valorile
,D (da) sau ,N si s depind Iunctional astIel: (24) (Idmprumut, IdCaseta) Gratuita.

A treia regul e ceva mai dur: imprumutul este pentru 48 de ore, la remiterea casetei se
calculea: o penali:are de 75 din pretul casetei pentru fiecare :i de intar:iere. Implementarea sa ar
presupune c, la "de-nulizarea" valorii unui atribut DataOraRestituirii s veriIicm dac
diIerenta CASETE_MPRUMUTATE.DataOraRestituirii - MPRUMUTURI.Datampr este mai
mare de dou zile (ntruct cele dou atribute sunt de tip DATETIME, adic dat si or, diIerenta lor
Iurnizeaz, de obicei, numrul de zile dintre cele dou momente). Dac da, atunci calculm penaliza-
rea dup relatia: Penalizare := 0.75 * (CASETE_MPRUMUTATE.DataOraRestituirii -
MPRUMUTURI.Datampr -2). Este evident nevoia de atributul Penalizare care va depinde
Iunctional astIel: (25) (Idmprumut, IdCaseta) Penalizare. Cu aceast ocazie, ne
putem propune s rezolvm o problem pe care trebuia s-o avem n vedere mai demult, si anume Cat
trebuie s achite clientul la fiecare imprumut (inchirierea a una, dou, trei sau patra casete) ? Pentru
acest scop apelm la atributul Valoarenchir (de la valoare nchiriere): (26) Idmprumut
Valoarenchir.

FEAA nfoEc + CG - 2006/2007 85
n Iine, ultima regul, potrivit creia pierderea sau distrugerea unei casete antrenea: o
amend care repre:int dublul pretului casetei, are o dubl implicatie: pe de o parte, regretabilul
eveniment trebuie consemnat la (un soi de) restituire, iar atributul Penalizare va contine acum
dublul contravalorii casetei; pe de alt parte, trebuie s existe cumva n baza de date o indicatie
precum c respectiva caseta nu mai poate Ii nchiriat, adic este pierdut sau distrus. Solutia stergerii
nregistrrii corespunztoare din tabela CASETE nu este una prea ingenioas, ntruct ar trebui s
pierdem toti "copiii" acestei nregistrri, deci inclusiv de cte ori si cui a Iost mprumutat, si, astIel,
inIormatiile statistice privind Iilmele, clientii si mprumuturile vor Ii serios aIectate. Cel mai nimerit
pare s recurgem la un atribut numit StareCaseta care s aib o valoare implicit OK (sau nul,
desi nu suntem Iani nullisti) si, dac este cazul, Pierdut, Distrus, ba chiar, dac tot l avem, putem
consemna si situatiile n care caseta a Iost scoas din uz "de moarte bun" (Casat) sau se apropie de
aceast stare (U:at): (27) IdCaseta StareCaseta
Nu este ns suIicient s cunoastem starea casetei, ci si de la ce mprumut i se trage pierderea
sa distrugerea. As c apelm la un atribut special, StareLaRestituire, care indic halul n care un
client ne-a restituit caseta (s Iim ntelesi: e vorba de halul casetei, nu al clientului !) si care depinde
Iunctional astIel: (28) (Idmprumut, IdCaseta) StareLaRestituire.
Ca un alt artiIiciu propus, ne imaginm c, n ton cu vremurile, clientii vor putea s-si
rezerve/comande casete pe web, iar centrul s aib un serviciu de Iurnizare a casetelor la domiciliu (de
tipul pi::a deliverv) sau, n cel mai ru caz, datorit dimensiunii impresionante a centrului (d,
Doamne !), vor Ii amplasate trei-patru terminale ntr-un colt prin care clientul poate s caute Iilmele
dup actori, regizori, subiect etc. Tocmai pentru a evita executia unei interogri care s implice
tabelele CASETE, MPRUMUTURI si CASETEMPRUMUTATE prin care s se aIle dac o caset
este disponibil sau mprumutat la un moment dat, se poate recurge la un alt atribut redundant numit
Disponibilitate, actualizabil automat prin declansatoarele tabelei CASETEMPRUMUTATE:
(29) IdCaseta Disponibilitate.
Apropo, ne propusesem si un mic mecanism de rating al Iilmelor de ctre clienti, desi, din cte
am vzut pe site-urile romnesti dedicate vnzrilor (legale) de carte si CD-uri, sistemul nu prea a
prins la noi. La modul cel mai simplu, putem alege o scal de punctare de la 0 la 5, de genul celei
practicate de Laurentiu Brtan n revista 22, atributul Punctaj Iiind "implicat" n dependenta: (30)
(IdFilm, CNPClient) Punctaj.

Tot Irmntndu-ne mintea cu mecanismul de cutare a inIormatiilor despre Iilme, realizm
c, la un moment dat, este posibil ca unii clienti s doreasc a viziona Iilme n care joac actori
spanioli, sau Iilme regizate de cineasti nscuti n perioada 1930-1940 sau site-ul/pagina Web dedicat
unei anumite personalitti cinematograIice. Putem vorbi de generalizare: actorii, regizorii si scenaristii
sunt toti cineasti, ca s nu amintim numerosi actori care sunt si regizori, sau regizori ce sunt si
productori si scenaristi. Asa c am putea introduce o serie de atribute pentru identiIicarea si
caracterizarea oricrui actor/scenarist/productor/regizor: IdCineast, NumeCineast,
DataNasterii, DataMortii, Nationalitate, PaginaWeb. Fr a schimba numele celor patru
atribute (ar Ii Iost mai nimerite titulaturile IdScenarist, IdProducator, IdRegizor si
IdActor), reprezentm cele patru dependente de incluziune Scenarist IdCineast,
Producator IdCineast, Regizor IdCineast, Actor IdCineast.
86 Baze de date
Punnd cap la cap tot ceea ca am discutat despre legturile semantice dintre atributele bazei de
date, obtinem reprezentarea sub Iorm de graI din Iigura 5.41. Pentru un plus de lizibilitate, am grupat
toate destinatiile surselor IdFilm, IdCineast, IdCaseta si CNPClient.

Figura 5.41. Graful DF pentru BD Centru de inchiriere - versiunea 2.0
Pe baza graIului, schema Iinal a bazei de date este urmtoarea: PREMIIDENUMIRI
DenPremiu, LocDecernare}, FILME IdFilm, TitluOriginal, TitluRO, AnLans},
CINEASTI IdCineast, NumeCineast, DataNasterii, DataMortii, Nationalitate, Pagi-
naWeb}, DISTRIBUTIE IdFilm, Rol, Actor*}, PREMIIFILME IdFilm, DenPremiu,
Categorie,AnPremiu}, PREMIIINTERPRETARE IdFilm, Actor* , DenPremiu, Categorie,
AnPremiu}, PRODUCTORI IdFilm, Producator*}, REGIZORI IdFilm, Regizor*},
SCENARISTI IdFilm, Scenarist*}, FILMEGENURI IdFilm, Gen}, CASETE IdCaseta,
DataCumpararii, ProducatorCaseta, AnProdCaseta, PretCumparare, StareCaseta,
Disponibilitate}, CASETEFILME IdCaseta, FilmNr, IdFilm, ParteFilm}, CLIENTI
CNPClient, NumeClient, AdresaClient, TelefonClient, DataNasteriiClient,
NivelStudiiClient, NrCasetemprumutate, NrCaseteRestituite}, MPRUMUTURI
Idmpr, DataOrampr, CNPClient, Valoarenchir}, CASETEMPRUMUTATE Idmpr,
IdCaseta, DataOraRestituirii, Gratuita, Penalizare, StareLaRestituire }, APRECI-
ERIFILME IdFilm, CNPClient, Punctaj}.
Atributele marcate cu asterisc sunt chei strine, printele comun Iiind cmpul IdCineast din
tabela CINEASTI.

FEAA nfoEc + CG - 2006/2007 87
CapitoIuI 4
CREAREA I POPULAREA TABELELOR UNEI UNEI BAZE DE
DATE

Obiective:
I. Prezentarea principalelor module yi func(ionalit(i ale unui sistem de
gestiune a bazelor de date
II. Clarificarea tipologiei op(iunilor pentru Limbajele de Definire a
Datelor yi Limbajele de Manipulare a Datelor
III. Caracterizarea atribu(iilor administratorului bazei de date yi altor
categorii de utilizatori
IV. Conturarea principalor segmente ale pie(ei SGBD-urilor
V. Enumerarea principalelor tipuri de date gestionabile prin SQL
VI. Prezentarea principalelor clauze SQL pentru declararea restric(iilor
unei baze de date rela(ionale
VII. Exemplificarea comenzilor SQL de editare a con(inutului unei tabele:
INSERT, UPDATE, DELETE

Rezultate ayteptate:
A. Deprinderea principalelor clauze ale comenzii CREATE TABLE
pentru crearea tabelelor yi declararea restric(iilor
B. Cunoayterea modului de editare a tabelelor dintr-o baz de date
rela(ional

88 Baze de date
4.1 SISTEME DE GESTIUNE A BAZELOR DE DATE
Aprute n anii '60, Sistemele de Gestiune a Bazelor de Date (prescurtat SGBD-uri) reprezint
un ansamblu de programe ce permit utilizatorilor (proIesionisti si neproIesionisti) s interactioneze cu
o baz de date, n vederea crerii, actualizrii si interogrii acesteia. SGBD-ul este soItware-ul care
asigur si supervizeaz: introducerea de inIormatii n baza de date; actualizarea si extragerea datelor
din baz; autorizarea si controlul accesului la date; pstrarea independentei dintre structura bazei si
programe
50
. Obiectivul esential al unui SGBD este Iurnizarea unui mediu eIicient, adaptat utilizatorilor
care doresc s consulte sau s actualizeze inIormatiile continute n baz. Bazele de date sunt concepute
pentru a prelucra un volum mare de inIormatii. Gestiunea acestora impune nu numai o structurare
riguroas a datelor, dar si o rationalizare a procedurilor de acces si prelucrare.
Principalele Iunctiuni ale unui SGBD vizeaz:
- descrierea ansamblului de date la nivel Iizic si conceptual;
- crearea (initializarea) si exploatarea (consultarea si actualizarea) bazei de date;
- controlul integrittii bazei;
- conIidentialitatea inIormatiilor continute n baz;
- accesul simultan al mai multor utilizatori la inIormatii;
- securitatea n Iunctionare.
- Iurnizarea unui set de comenzi si instructiuni, necesare att utilizatorilor pentru consultarea direct a
bazei, prin intermediul unui limbaj de manipulare, ct si programatorilor, pentru redactarea
programelor de lucru cu baza de date;
- revizia si restructurarea bazei;
- monitorizarea perIormantelor.
Un SGBD prezint, n general, urmtoarele module
51
:
Gestionarul Iisierelor, care se ocup cu aIectarea spatiilor de memorie pe disc si cu structurile Iizice
de date care servesc la reprezentarea inIormatiilor pe suport.
Gestionarul bazei de date Iace legtura datelor "Iizice" din baz cu aplicatiile-program de
consultare si actualizare.
Procesorul de consultare "traduce" instructiunile limbajului de consultare n instructiuni elementare,
"inteligibile" pentru gestionarul bazei. Mai mult, acesta optimizeaz consultarea, pentru a obtine
rezultatele ntr-un timp ct mai scurt.
Modulele DML (Data Manipulation Language) realizeaz conversia instructiunilor limbajului de
manipulare a datelor (DML) inserate ntr-un program de aplicatie, n proceduri curente ale limbajului-
gazd, interactionnd cu procesorul de consultare n vederea producerii secventelor de cod adecvate.
Modulele Limbajului de DeIinire a Datelor - DDL (Data DeIinition Language) "traduc" (prin
compilare sau interpretare) si execut instructiunile DDL, obtinndu-se ansamblul de tabele ce
reprezint metadatele stocate n dictionarul de date.
Aceste cinci module interactioneaz cu o serie de componente Iizice ale bazei:
Fisierele de date reprezint suportul propriu-zis al bazei.

50
[G. Dodescu s.a. 87], p. 511
51
[Korth&Silberschatz88], pp.17-18
FEAA nfoEc + CG - 2006/2007 89
Dictionarul de date nmagazineaz inIormatii relative la structura bazei, Iiind solicitat n toate
operatiunile de consultare si actualizare.
Indecsi, ntr-un numr suIicient pentru mrirea vitezei de acces la date.
Sintetic, structura unui sistem de lucru cu o baz de date este prezentat n Iigura 4.1
52.

Aplicatii-program Apeluri-sistem
Consultare
(interogare)
Structura bazei
Utilizatori Iinali
curenti
Programatori
Utilizatori Iinali
ocazionali
Administratorul bazei
Compilatorul limbajului
de deIinire a datelor
Procesorul de
consultare
Precompilatorul
limbajului de
manipulare a datelor
Coduri-obiect ale
aplicatiilor-program
Gestionarul bazei de date
Sistemul de gestiune a bazei de date
Gestionarul Iisierelor
Fisier de date
Dictionar
de
date
Baza de date

Figura 4.1 Structura unui sistem de lucru cu o ba: de date
Pentru a-si ndeplini Iunctiunile, un SGBD pune la dispozitia utilizatorilor si dou tipuri de
comenzi/instructiuni. Primul modul este destinat lucrului cu schema bazei de date si, de aceea, n
literatura de proIil se Ioloseste titulatura DDL (Data DeIinition Language) limbaj de deIinire a
datelor. Al doilea priveste continutul bazei de date, adic inserarea, modiIicarea si stergerea datelor,
precum si cutarea datelor n baz (cu sau Ir prelucrarea lor), motiv pentru care comenzile/instruc-
tiunile de acest tip sunt reIerite ca optiuni DML (Data Manipulation Language) limbaj de manipulare
a datelor. Multe lucrri desprind din categoria DDL o a treia categorie denumit DCL (Data Control
Language) limbaj pentru controlul datelor, care priveste gestiunea utilizatorilor/grupurilor de
utilizatori si drepturile de acces ale acestora la anumite obiecte ale bazei.

Limbaje de definire a datelor
Arhitectura unei baze de date este speciIicat printr-o serie de deIinitii redactate sub Iorm de
instructiuni scrise n DDL. Executia acestor deIinitii se materializeaz ntr-un ansamblu de tabele care
sunt memorate ntr-un Iisier special, denumit dictionar (sau repertoar) de date. Un dictionar de date
contine deci metadate, adic date relative la alte date, Iiind consultat naintea oricrei citiri sau
modiIicri a datelor din baz (dictionarul de date a Iost explicat chiar n primul capitol).
Principale Iunctiuni ale DDL sunt:
- Descrierea logic a bazei de date si sub-schemelor proprii Iiecrui grup de utilizatori.

52
Preluare din [Korth&Silberschatz88], p.19
90 Baze de date
- IdentiIicarea schemei, sub-schemelor si diverselor agregri de date.
- SpeciIicarea Iisierelor de date si a legturilor logice dintre acestea. Pe baza acestor speciIicatii se
poate realiza accesul la date chiar si n conditiile co-existentei mai multor modele de organizare ntr-o
aceeasi BD.
- DeIinirea restrictiilor semantice la care sunt supuse datele. Acestea reprezint ansamblul valorilor
permise ale Iiecrei date, eventual Iormula de calcul a unei date pe baza valorilor altor date.
- Respectarea acestor restrictii asigur coerenta bazei.
- DeIinirea cheilor de acces rapid si a cheilor conIidentiale (parolelor).
- DeIinirea metodelor de exploatare a Iisierelor ce vor Ii utilizate n aplicatii pentru selectarea
nregistrrilor.
- DeIinirea procedurilor speciale de criptare, n vederea generrii cheilor de acces.
- DeIinirea modului de indexare sau de localizare a entittilor.
- Determinarea tipului unei date, n sensul de dat de baz sau derivat (calculat printr-o expresie, pe
baza valorilor altor date).
Dat Iiind complexitatea structurilor de memorare si metodelor de acces la acestea, la nivel
elementar Iisierele de date si dictionarul de date sunt accesibile numai specialistilor. n schimb, pentru
descrierea schemei BD, marea majoritate a limbajelor de interogare prezint comenzi adecvate, ce pot
Ii utilizate si de ne-inIormaticieni.

Limbaje de manipulare a datelor
Prin manipularea datelor se ntelege eIectuarea uneia dintre urmtoarele operatiuni:
extragerea unor date din baz (consultare);
scrierea de noi date n baz (adugare);
stergerea datelor perimate sau eronate (uneori chiar si a celor corecte);
modiIicarea valorii unor date.
Comenzile DML sunt utilizate pentru a prelucra datele n Iunctie de structura lor. La nivel
Iizic, prin DML se vizeaz identiIicarea si implementarea unor algoritmi perIormanti de acces la date,
n timp ce la nivel extern DML trebuie s Iaciliteze dialogul utilizatorului cu baza n vederea obtinerii
inIormatiilor dorite. n mod curent, termenul consultare sau interogare desemneaz actiunea de
cutare si identiIicare a datelor necesare, dintre cele aIlate n baz. Ansamblul instructiunilor DML
pentru cutare si identiIicarea datelor constituie limbajul de consultare.

Gestionarul bazei
O baz de date consum un volum considerabil de memorie, astIel nct poate Ii stocat
numai pe disc, memoria intern (RAM) a calculatorului Iiind insuIicient (si volatil). Programele de
exploatare Iac Irecvent transIeruri de date ntre memoria intern si disc. Deoarece viteza de transIer
este mult mai mic, prin comparatie cu viteza de lucru a procesorului, gsirea unor solutii, la nivel
Iizic, pentru transIerul rapid al datelor prezint o important deosebit.
Pe de alt parte, obiectivul esential al bazelor de date este de a Iacilita exploatarea datelor, n
vederea obtinerii de ctre utilizatori a inIormatiilor necesare. Acest obiectiv priveste nivelul extern,
utilizatorul neIiind realmente interesat de modul n care inIormatia se gseste Iizic pe suportul de
nregistrare.
FEAA nfoEc + CG - 2006/2007 91
Rezolvarea acestor probleme cade sub incidenta gestionarului bazei de date, care este un
modul de programe ce realizeaz interIata dintre datele interne (de pe suport) continute n baz si
programele (sau comenzile) de consultare si actualizare; principalele sale sarcini pot Ii grupate astIel:
Interactiunea cu gestionarul de Iisiere. Datele brute sunt stocate pe disc prin intermediul sistemului
de gestiune a Iisierelor, care este o component a sistemului de operare al calculatorului. Gestionarul
BD traduce instructiunile diverselor DML n instructiuni-sistem, la nivel elementar, Iiind "responsabil"
si de buna desIsurare a operatiilor de scriere/citire a datelor n/din baz.
Validitatea (corectitudinea) datelor. Datele stocate trebuie s satisIac anumite restrictii de
integritate, speciIicate de administratorul bazei. Dup implementarea mecanismului de integritate,
gestionarul veriIic dac toate actualizrile se deruleaz cu respectarea restrictiilor.
Securitatea datelor. Accesul la date trebuie s Iie selectiv, gestionarul bazei Iiind cel care asigur
respectarea drepturilor de acces ale Iiecrui utilizator.
Salvare si restaurare. Si sistemele inIormatice sunt supuse accidentelor: distrugerea supraIetei
magnetice, ntreruperi n Iurnizarea energiei electrice, erori ale programelor etc. sunt inerente chiar si
n tri super-dezvoltate. n multe cazuri, datelor ce erau n curs de prelucrare n momentul accidentului
se altereaz sau se pierd n totalitate. Gestionarul are diIicila misiune de a detecta la timp avariile si de
restaura datele pierdute n Iorma si continutul dinaintea accidentului. Aceasta se realizeaz prin
intermediul unor programe speciale de salvare-restaurare.
Prelucrri simultane (concurente). ntruct n acelasi timp pot lucra cu baza doi sau multi utilizatori,
trebuie asigurat coerenta datelor prin aIectarea unor nivele de prioritate la nivel de operatii si
utilizatori.

Administratorul bazei de date
Din cele prezentate pn acum, reiese clar c un sistem de gestiune a bazei de date reprezint
un ansamblu de programe ce asigur controlul complet al datelor, dar si al aplicatiilor care le
exploateaz. Administratorul unei baze de date este persoana responsabil de sistem n ansamblul su.
Rolul acestuia este determinant n cteva activitti Ioarte importante.
DeIinirea arhitecturii bazei de date se realizeaz prin scrierea deIinitiilor care vor Ii transIormate de
compilatorul DDL ntr-un ansamblu de tabele stocate permanent n dictionarul de date.
DeIinirea modalittilor n care va Ii structurat memoria extern si a metodelor de acces la date.
Acestea devin operationale prin redactarea unor speciIicatii scrise ca instructiuni ale limbajului de
deIinire (descriere) a datelor.
ModiIicarea arhitecturii si organizrii Iizice a bazei de date poate Ii realizat prin intermediul
instructiunilor DDL, obtinndu-se astIel actualizrile corespondente ale dictionarului de date.
Autorizarea accesului la date se acord Iiecrui utilizator al bazei de date, administratorul Iiind cel
care decide asupra datelor ce pot Ii consultate si actualizate de Iiecare utilizator sau grup de utilizatori.
SpeciIicarea restrictiilor de integritate. Aceste restrictii sunt stocate pe disc si consultate de
gestionarul bazei la Iiecare actualizare.
n plus, administratorul bazei de date este cel care: asigur legtura cu utilizatorii; deIineste
procedurile de veriIicare a drepturilor de acces si a procedurilor de validare a integrittii datelor;
deIineste strategia de salvare (nregistrarea copiilor de sigurant)/restaurare a bazei; monitorizeaz
perIormantele bazei si o adapteaz la modiIicrile ulterioare ale sistemului inIormational.
92 Baze de date
Utilizatorii bazelor de date
n ciuda complexittii unui SGBD, tipologia utilizatorilor ce pot utiliza bazele de date este
extrem de generoas. Cert este c exist categorii proIesionale (cum ar Ii administratorii de baze de
date) care si cstig existenta exclusiv din ,mnuirea SGBD-urilor, asa cum exist utitzatori (cum ar
Ii personalul de la ghiseele bncilor) care nu au nici cel mai mic habar despre baza de date n care si
stocheaz datele si si extrag inIormatiile.
Cu riscul de a simpliIica lucrurile excesiv, ne putem opri numai la patru categorii de utilizatori
ce pot interactiona cu sistemul:
- Administratorii BD. Dup cum am vzut n paragraIul precedent, un administrator este un Iel de il
capo di tutti capi pentru o baz de date. Trebuie s Iie n egal msur proIesionist si de caracter,
deoarece acces la cele mai intime inIormatii stocate n baz.
- Programatorii (dezvoltatorii) de aplicatii. Sunt inIormaticienii care interactioneaz cu baza de date
prin intermediul instructiunilor DML integrate n programe scrise ntr-un limbaj-gazd (Cobol, Pascal,
C, Visual Basic, Java etc.) sau n limbajul SGBD-lui respectiv.
- Utilizatori ocazionali, dar cunosctori. Acestia sunt persoane care interactioneaz cu sistemul, nu
prin intermediul programelor de aplicatii, ci printr-un limbaj de consultare speciIic bazei (SQL).
Cunoscnd portiuni din schema bazei (Ir a avea drepturi de administrare), ei pot lansa interogri prin
care pot obtine ad-hoc inIormatii punctuale necesare.
- Utilizatorii curenti neproIesionisti (neinIormaticieni) sunt persoane care eIectueaz operatii de rutin
asupra bazei de date, utiliznd aplicatiile disponibile, Ir a cunoaste schema bazei si Ir a pricepe
prea multe din tehnologia bazelor de date (asa cum sunteti dvs. acum !).
4.2 PIATA ACTUAL A SGBD-urilor
Desi IBM a Iost prima care a initial un proiect destinat elaborrii unui SGBD relational
(System/R, ncepnd cu 1974), prima Iirm care a lansat primul SGBDR comercial a Iost Relational
SoItware Inc., astzi Oracle. InIiintarea Iirmei a avut loc n 1977, iar lansarea produsului n 1979.
Impunerea pe piat a SGBD-urilor greIate pe modelul relational a Iost mult mai diIicil dect s-ar
putea ntelege astzi. Abia n deceniul 9, datorit vitezei ameliorate, securittii sporite si mai ales
productivittii dezvoltatorilor de aplicatii, modelul relationat a cstigat suprematia. n tara noastr cel
mai utilizat SGBD al deceniului 9 a Iost FoxPro, desi piata sa mondial se diminuase nc de la
mijlocul anilor `90.
Exist o larg tipologie a SGBDR-urilor, asa nct orice categorisire si are riscul su. Cele
mai accesibile si, implicit, cele mai utilizate sunt SGBD-urile dedicate initial uzului individual:
Access, Paradox, Visual FoxPro. Astzi, multe dintre acestea au caracteristici proIesionale si pot Ii
Iolosite la dezvoltarea aplicatiilor pentru simulant a zeci de utilizatori.
Pentru aplicatiile complexe din bnci, corporatii, organizatii si institutii de mari dimensiuni s-
au impus SGBDR-urile de "categoria grea": Oracle, DB2 (IBM), InIormix (IBM), Sysbase, SQL
Server (MicrosoIt). Acestea sunt mult mai robuste, mult mai Iiabile, dar si costisitoare.
n ultimul timp si-au Icut aparitia, ca alternative la marii colosi, asa zisele Free-DBMS-uri,
precum PostgreSQL, MySQL, mSQL etc. Acestea ruleaz, de obicei, pe sisteme de operare de tip
Linux (Ioarte ieItine) si se ntrevd ca adversari seriosi ai marilor productori. Se pare c cel mai mare
FEAA nfoEc + CG - 2006/2007 93
segment de piat din categoria SGBD-urilor Open-Source l are MySQL, desi n materie de
Iunctionalitti SQL si proceduri stocate, acest produs a Iost, pn de curnd, Ioarte slab.
4.3 CREAREA TABELELOR IN LIMBA1UL SQL
Pn n acest moment al cursului, discutiile au Iost strict teoretice, urmrind Iamiliarizarea cu
notiunile Iundamentale ale bazelor de date. Din acest paragraI (nu chiar imediat, ci cteva pagini mai
ncolo), vom trece si la chestiuni aplicative, ce pot Ii lansate n executia de la consola unui SGBD. Si
tot din acest paragraI, vom ncepe s gravitm n jurul celui mai important limbaj din lumea bazelor de
date, si anume SQL.
4.3.1. Prezentare general a limbajului SQL (partea I)
SQL (de la Structured Query Language) a devenit, de o bun bucat de vreme, limbajul-cheie
n lumea bazelor de date. Nu exist astzi lucrri sau publicatii n domeniul SGBD-urilor care s nu
prezinte mecanismul de lucru al acestui limbaj sau ultimele produse/tendinte din lumea SQL. Impactul
su este proIund. Devenit un soi de esperando al limbajelor pentru baze de date, SQL are toate sansele
de a nu cdea n desuetitudinea esperando-ului propriu-zis, aceasta deoarece a Iost altoit pe toate
tipurile de SGBD-uri, de la cele dedicate microcalculatoarelor (PC), la cele care opereaz n medii
distribuite/eterogene/client-server. SQL este, pe de o parte, unul dintre "responsabilii" noii aproprieri a
non-inIormaticianului de datele sale, iar, pe de alt parte, pentru proIesionisti, reprezint nucleul
dezvoltrii aplicatiilor ce utilizeaz bazele de date.
Desi este reIerit, n primul rnd, ca un limbaj de interogare, SQL este mult mai mult dect un
instrument de consultare a bazelor de date, deoarece permite, n egal msur:
DeIinirea datelor
Consultarea BD
Manipularea datelor din baz
Controlul accesului
Partajarea bazei ntre mai multi utilizatori ai acesteia
Mentinerea integrittii BD.
AstIel c principale comenzi SQL pot Ii rezumate ca n tabelul 4.1.

Tabel 4.1 Cele mai importante comen:i SQL
Comand Scop
Pentru manipularea datelor
SELECT Extragerea datelor din baz
NSERT Adugarea de noi linii ntr-o tabel
DELETE Stegerea de linii dintr-o tabel
UPDATE Modificarea valorilor unor atribute

Pentru definirea bazei de date
CREATE TABLE Adugarea unei noi tabele n baza de date
DROP TABLE Stergerea unei tabele din baz
ALTER TABLE Modificarea structurii unei tabele
CREATE VEW Crearea unei tabele virtuale
DROP VEW Stergerea unei tabele virtuale
94 Baze de date

Pentru controlul accesului la BD
GRANT Acordarea unor drepturi pentru utilizatori
REVOKE Revocarea unor drepturi pentru utilizatori

Pentru controlul tranzactiilor
COMMT Marcheaz sfritul unei tranzac[ii
ROLLBACK Abandoneaz tranzac[ia n curs
4.3.2. Tipuri de date SQL
La crearea eIectiv a oricrei tabele, pentru Iiecare atribut, pe lng nume si eventuale
restrictii trebuie obligatoriu declarat tipul acestuia dac este un numr, un sir de caracterre, o dat
calendaristic etc. Desi exist unele diIerente semniIicative ntre SQL-urile, urmtoarele categorii de
tipuri de date sunt cvasi-prezente.
- SMALLINT: ntregi - scurte (4 pozitii, reprezentate pe 16 biti),
- INTEGER sau INT: ntregi (9 pozitii, 32 biti),
- NUMERIC(p,s) sau DECIMAL(p,s) sau DEC(p,s) - reale, cu un total de p pozitii, din care s la partea
Iractionar ,
- FLOAT: reale, virgul mobil (20 pozitii ptr. mantis),
- REAL: real, virgul mobil (cu precizie mai mic dect FLOAT, dar la nivelul de intrare este
identic),
- DOUBLE PRECISION: reale, virgul mobil, dubl precizie (30 de pozitii ptr. mantis),
- CHAR(n) sau CHARACTER(n): sir de caractere de lungime n (max. 240),
- VARCHAR(n) sau CHAR VARYING(n) sau CHARACTER VARYING(n): sir de caractere de
lungime variabil (max. 254),
- DATE: dat calendaristic,
- TIME: ora etc.,
- TIMESTAMP: an, lun, zi, ora, minutul, secunda, plus o Iractiune zecimal dintr-o secund.
Joe Celko trateaz riguros Iiecare categorie de dat, asa cum este prezent n SQL-92
53
. n
ceea ce priveste datele temporale, el opereaz o delimitare ntre:
evenimente, pentru care exist tipurile DATE, TME, TMESTAMP,
intervale perioade de timp dintre dou evenimente (momente) - tipul NTERVAL (YEAR,
MONTH, DAY, HOUR, MNUTE, SECOND) si
perioade sunt intervale cu un moment Iix de nceput, pentru care este necesar o combinatie
de dou cmpuri, Iie TMESTAMP - TMESTAMP, Iie TMESTAMP - NTERVAL.
4.3.3. Crearea tabelelor: CREATE TABLE
Crearea unei baze de date are o component tehnic pronuntat, mai ales n cazul serverelor de
baze de date: Oracle, DB/2, SQL Server, InIormix, PostgreSQL etc. Chiar dac exist instrumente de
admistrare care usureaz considerabil aceast activitate, crearea unei baze de date necesit cunostinte
de administrare, strict legate de produsul soItware de gestiune a bazei.
n cele ce urmeaz, vom eluda elementele tehnice/Iizice (spatiile-tabel, segmentele de
rollback, Iisierele de date, procesele sistem etc.), lsndu-le n seama administratorilor BD; vom

53
[Celko99]
FEAA nfoEc + CG - 2006/2007 95
considera baza de date creat din punct de vedere Iizic, astIel nct ne intereseaz numai crearea
tabelelor, modiIicarea structurii lor si declararea restrictiilor.
Comanda SQL utilizat pentru crearea unei tabele este CREATE TABLE. Precizm c este
vorba de crearea structurii tabelei. Popularea cu nregistrri si actualizarea ulterioar se realizeaz prin
alte comenzi: INSERT, UPDATE, DELETE. Tabele sunt cele din baza de date VNZRI. Pentru
crearea unei tabele si declararea atributelor acesteia, Ir nici o reIerire restrictii, comanda CREATE
TABLE are, n cazul tabelei JUDETE, urmtoarea Iorm:
CREATE TABLE JUDETE
(Jud CHAR(2),
Judet VARCHAR(25),
Regiune VARCHAR (15))
ntruct atributele acestei tabele sunt exclusiv de tip sir de caractere, s-au Iolosit optiunile CHAR si
VARCHAR. CHAR este preIerat pentru atributul Jud, deoarece indicativul auto al judetului este
Iormat exclusiv din dou litere (cu exceptia Bucurestiului). ntruct denumirile judetului si regiunii au
lungime variabil, pentru aceste atribute a Iost preIerat tipul VARCHAR. Pentru ilustrarea si altor
dou tipuri de date, prezentm comanda de crearea a tabelei FACTURI:
CREATE TABLE FACTUR ( NrFact NUMERC(8), DataFact DATE, CodCl DECMAL(6), Obs VARCHAR(50) )
NrFact si CodCl sunt de tip numeric, n timp ce DataFact de tip dat calendaristic. Se mai cuvine
de adugat c unele atribute pot Ii initializate cu o valoare implicit la adugarea unei linii n tabela
respectiv. Clauza este DEFAULT:
CREATE TABLE FACTUR ( NrFact NUMERC(8), DataFact DATE DEFAULT CURRENT_DATE,
CodCl DECMAL(6) DEFAULT 1001, Obs VARCHAR(50) )
Ca urmare a clauzei DEFAULT, n orice linie adugat n tabela FACTURI, valoarea
implicit (dac nu este speciIicat n comanda INSERT) a DataFact va Ii data sistemului (data
curent), iar CodCl se va initializa cu valoarea 1001.
4.3.4. Declararea restric(iilor
n SQL se pot declara toate tipurile de restrictii ale unei BDR: valori obligatorii (nenule),
unicitate, restrictii reIerentiale si restrictii utilizator.

Valori nenule
Unele atribute, obligatoriu cele din cheia primar, nu pot prezenta valori nule. Pentru aceasta,
la crearea tabelei si declararea atributului se Ioloseste optiunea NOT NULL:
CREATE TABLE FACTUR (
NrFact NUMERC(8) NOT NULL, DataFact DATE DEFAULT CURRENT_DATE NOT NULL,
CodCl DECMAL(6) DEFAULT 1001 NOT NULL, Obs VARCHAR(50) )

Cheie primar/unicitate
Cheia primar a unei relatii este deIinit prin clauza PRIMARY KEY, plasat Iie imediat,
dup atributul cheie, Iie dup descrierea ultimului atribut al tabelei. A doua variant este ntrebuintat
cu precdere atunci cnd cheia primar a tabelei este compus. Pentru atributele de tip cheie candidat
se poate Iolosi clauza UNIQUE care va asigura respectarea unicittii valorilor. Iat cteva variante de
Iolosire a clauzelor PRIMARY KEY si UNIQUE:
CREATE TABLE FACTUR (
96 Baze de date
NrFact NUMERC(8) NOT NULL PRMARY KEY, DataFact DATE DEFAULT SYSDATE NOT NULL,
CodCl DECMAL(6) DEFAULT 1001 NOT NULL, Obs VARCHAR(50) ) ;
CREATE TABLE JUDETE (
Jud CHAR(2) PRMARY KEY, Judet VARCHAR(25) NOT NULL UNQUE, Regiune VARCHAR (15) ) ;
CREATE TABLE LNFACT (
NrFact NUMERC(8) NOT NULL, Linie SMALLNT NOT NULL, CodPr NUMERC(6) NOT NULL,
Cantitate NUMERC(10) NOT NULL, PretUnit NUMBER (12),
PRMARY KEY (NrFact, Linie), UNQUE (NrFact, CodPr) ) ;
Pentru tabela LINIIFACT cheia primar este combinatia de atribute (NrFact, Linie); restrictia de
unicitate pentru cuplul (NrFact, CodPr) nseamn c se interzice ca, pe o Iactur, un produs s apar
repetat.

Restric(ii referen(iale
Declarea restrictiilor reIerentiale se realizeaz utiliznd clauza FOREIGN KEY. AstIel, pentru
stabilirea legturii LINIIFACT-FACTURI comanda de creare are Iorma:
CREATE TABLE LNFACT (
NrFact NUMERC(8) NOT NULL, Linie SMALLNT NOT NULL, CodPr NUMERC(6) NOT NULL,
Cantitate NUMERC(10) NOT NULL, PretUnit NUMBER (12),
PRMARY KEY (NrFact, Linie),
UNQUE (NrFact, CodPr),
FOREGN KEY NrFact REFERENCES FACTUR(NrFact),
FOREGN KEY CodPr REFERENCES PRODUSE(CodPr) )
Este drept, si urmtoarea variant este corect:
CREATE TABLE LNFACT (
NrFact NUMERC(8) NOT NULL REFERENCES FACTUR(NrFact),
Linie SMALLNT NOT NULL,
CodPr NUMERC(6) NOT NULL REFERENCES PRODUSE(CodPr),
Cantitate NUMERC(10) NOT NULL, PretUnit NUMBER (12),
PRMARY KEY (NrFact, Linie), UNQUE (NrFact, CodPr) )
n SQL92 se poate speciIica si modul n care va Ii pstrat integritatea bazei de date la
stergerea unei linii-printe sau modiIicarea unei chei primare ce prezint nregistrri-copil. Pentru a
interzice stergerea unor Iacturi (nregistrri din FACTURI) pentru care exist tupluri corespondente n
LINIIFACT si, pe de alt parte, pentru ca la modiIicarea unui numr de Iactur (NrFact) n FACTUR
s se modiIice automat, n cascad, toate liniile-copil din LINIIFACT, Iorma comenzii se schimb n:
CREATE TABLE LNFACT ( NrFact NUMERC(8) NOT NULL, Linie SMALLNT NOT NULL,
CodPr NUMERC(6) NOT NULL, Cantitate NUMERC(10) NOT NULL, PretUnit NUMBER (12),
PRMARY KEY (NrFact, Linie), UNQUE (NrFact, CodPr),
FOREGN KEY NrFact REFERENCES FACTUR(NrFact)
ON DELETE RESTRCT ON UPDATE CASCADE,
FOREGN KEY CodPr REFERENCES PRODUSE(CodPr)
ON DELETE RESTRCT ON UPDATE CASCADE )

Restric(ii-utilizator
n SGBD-urile actuale, restrictiile-utilizator, denumite si restrictii de comportament, sunt
implementate sub Iorma regulilor de validare la nivel de cmp (field validation rule), la nivel de
nregistrare (record validation rule) sau, eventual, pot Ii incluse n declansatoare (triggere). Cu rezerva
c aceste reguli pot avea Iorme complexe si ntrebuinta elemente avansate de SQL si/sau extensiile
FEAA nfoEc + CG - 2006/2007 97
procedurale ale SQL n mediul respectiv, prezentm n continuare o regul de validare pentru atributul
DataFact n tabela FACTURI si o alta pentru atributul Linie n LINIIFACT.
CREATE TABLE FACTUR (
NrFact NUMERC(8)
CONSTRANT nn_facturi_nrfact NOT NULL
CONSTRANT pk_facturi PRMARY KEY,
DataFact DATE DEFAULT CURRENT_DATE
CONSTRANT nn_datafact NOT NULL
CONSTRANT ck_datafact CHECK (DataFact >= '01/08/2005' AND DataFact <= '31/12/2010'),
CodCl DECMAL(6) DEFAULT 1001
CONSTRANT nn_facturi_codcl NOT NULL
CONSTRANT fk_facturi_clienti REFERENCES CLENT(CodCl)
ON DELETE RESTRCT ON UPDATE CASCADE,
Obs VARCHAR(50) ) ;
CREATE TABLE LNFACT (
NrFact NUMERC(8) CONSTRANT nn_liniifact_nrfact NOT NULL,
Linie SMALLNT CONSTRANT nn_linie NOT NULL CONSTRANT ck_linie CHECK (Linie > 0),
CodPr NUMERC(6) CONSTRANT nn_liniifact_codpr NOT NULL,
Cantitate NUMERC(10) CONSTRANT nn_cantitate NOT NULL,
PretUnit NUMERC (12) CONSTRANT nn_pretunit NOT NULL,
CONSTRANT pk_liniifact PRMARY KEY (NrFact, Linie),
CONSTRANT un_liniifact UNQUE (NrFact, CodPr),
CONSTRANT fk_liniifact_facturi FOREGN KEY NrFact REFERENCES FACTUR(NrFact)
ON DELETE RESTRCT ON UPDATE CASCADE,
CONSTRANT fk_liniifact_produse FOREGN KEY CodPr REFERENCES PRODUSE(CodPr)
ON DELETE RESTRCT ON UPDATE CASCADE )

Ca urmare a clauzei CHECK, data unei Iacturi nu poate avea valori n aIara intervalului 1
august 2005 31 decembrie 2010, iar atributul Linie trebuie s prezinte valori ntregi mai mari ca 0.
Ca un alt element de noutate, Iiecrei restrictii (cheie primar, unicitate, regul la nivel de
atribut etc.) i s-a dat un nume, lucru util atunci cnd, la un moment dat (slvari, restaurri, ncarcarea
BD), vrem sa dezactivm una sau mai multe dintre acestea. Pentru a usura lucrul, se preIixeaz numele
Iiecrei restrictii cu tipul su:
pk_ (PRIMARY KEY) pentru cheile primare
un_ (UNIQUE) pentru cheile alternative
nn_ (NOT NULL) pentru atributele obligatorii (ce nu pot avea valori nule)
ck_ (CHECK) pentru reguli de validare la nivel de atribut
fk_ (FOREIGN KEY) pentru cheile strine.

n Anexa 2 (disponibil pe portal) este disponibil listingul cu toate comenzile pentru crearea
tabelelor din baza de date VNZRI.
4.3.5. Modificarea structurii unei tabele
Odat creat o tabel, schema sa rmne constant. Dac totusi, ulterior, se doreste introducerea,
modiIicarea sau stergerea unor atribute, sau declararea/anularea unor restrictii, comanda necesat este ALTER
TABLE. Cteva exemple:
98 Baze de date
- Adugarea atributului DataNast (data nasterii) n tabela PERSOANE se realizeaz astIel:
ALTER TABLE PERSOANE ADD DataNast DATE
- Stergerea unui atribut: ALTER TABLE PERSOANE DROP COLUMN DataNast
- ModiIicarea tipului/lungimii unui atribut: ALTER TABLE PERSOANE MODFY (Nume VARCHAR(21))
- Adugarea/modiIicarea valorii implicite: ALTER TABLE PERSOANE MODFY (Sex DEFAULT 'F')
- Anularea unei valori implicite: ALTER TABLE PERSOANE MODFY (Sex DEFAULT NULL)
- Instituirea restrictiei de nenulitate: ALTER TABLE PERSOANE MODFY (Sex NOT NULL)
- Invers, acceptarea valorilor NULL: ALTER TABLE PERSOANE MODFY (Sex NULL)
Toate restrictiile: cheie primar - PRIMARY KEY, unicitate - UNIQUE, reIerential -
FOREIGN KEY, de comportament - CHECK pot Ii declarate ulterior crerii tabelei si, binenteles,
anulate la un moment dat. Spre exemplu, Iormatul general al comenzii pentru dezactivarea cheii
primare este: ALTER TABLE PERSOANE DROP PRMARY KEY. Pentru reinstituirea cheii primare a
tabelei PERSOANE comanda are Iorma: ALTER TABLE PERSOANE ADD PRMARY KEY (CNP).
4.3.6. $tergerea tabelelor
Orice tabel creat poate Ii stears prin comanda DROP TABLE. Dac, ns, tabela este un
printe (adic are copii), stergerea trebuie Icut mpreun cu toti copii (DELETE CASCADE),
altminteri SGBD-ul se va mpotrivi (va aIisa un mesaj de eroare).
4.4 COMENZI PENTRU MODIFICAREA CONTINUTULUI
SQL prezint comenzi dedicate modiIicrii continutului unei tabele, ntelegnd prin aceasta
trei actiuni prin care se actualizeaz baza:
a) adugarea de noi linii la cele existente n tabel,
b) stergerea unor linii,
c) modiIicarea valorii unui atribut.
Comanda SQL de adugare de noi linii este INSERT. Exemple:
NSERT NTO judete VALUES ('S', 'asi', 'Moldova') ;
NSERT NTO coduri_postale VALUES ('700505', 'asi', 'S') ;
NSERT NTO clienti VALUES (1001, 'Client 1 SRL', 'R1001', 'Tranzitiei, 13 bis', '700505', NULL) ;
NSERT NTO persoane VALUES ('CNP1', 'oan', 'Vasile', '.L.Caragiale, 22', 'B', '700505', '123456', '987654',
'094222222', NULL) ;
NSERT NTO persclienti VALUES ('CNP1', 1001, 'Director general');
NSERT NTO produse VALUES (1, 'Produs 1','buc', 'Tigari', .19) ;
NSERT NTO facturi (nrfact, datafact, codcl) VALUES (1111, TO_DATE('01/08/2005','DD/MM/YYYY'), 1001);
VALUES (1121, TO_DATE('07/08/2005','DD/MM/YYYY'), 1001);
NSERT NTO liniifact (nrfact, linie, codpr, cantitate, pretunit) VALUES (1111, 1, 1, 50, 1000) ;
NSERT NTO liniifact (nrfact, linie, codpr, cantitate, pretunit) VALUES (1111, 2, 2, 75, 1050) ;
NSERT NTO incasari VALUES (1234, TO_DATE('15/08/2005','DD/MM/YYYY'),
'OP', '111', TO_DATE('10/08/2005','DD/MM/YYYY')) ;
NSERT NTO incasfact VALUES (1234, 1111, 53996) ;
FEAA nfoEc + CG - 2006/2007 99
Ordinea valorilor din clauza VALUES trebuie s Iie identic cu cea declarat la crearea (sau
modiIicarea structurii) tabelelor. ModiIicarea este posibil numai prin enumerarea, dup numele
tabelei, a atributelor ce vor primi valorile speciIicate.
Pentru tabelele FACTURI si LINIIFACT au Iost incluse n clauza VALUES mai putine valori
dect atributele tabelei. Este obligatorie, n aceste cazuri, precizarea atributelor care vor primi valorile.
Restul, adic cele nespeciIicate, vor avea, pe liniile respective, valori NULL. Functia TODATE ajut
la speciIicarea datelor calendaristice (DD/MM/YYY nseamn c dou primele dou pozitii
desemneaz ziua, urmtoarele dou de dup bara oblic luna, iar ultimele patru anul).

Comanda SQL pentru stergerea uneia sau mai multor linii dintr-o tabel este DELETE, al
crei Iormatul general este: DELETE FROM nume-tabel WHERE predicat. Din tabel vor Ii sterse
toate liniile care ndeplinesc conditia speciIicat n predicatul din clauza WHERE:.
- DELETE FROM FACTUR WHERE NrFact = 1122 elimin din tabela Iacturi toate liniile n care valoarea
atributului NrFact este egal cu 1122, altIel spus, din tabela FACTURI este stears linia care se reIer la Iactura
1122. Cnd pentru aceast Iactur exist nregistrri copil n LINIIFACT sau INCASFACT, SGBD-ul tine cont
de optiunea declarat la crearea tabelei. Dac s-a speciIicat (implicit sau explicit) ON DELETE RESTRICT,
stergerea este interzis. n cazul ON DELETE CASCADE sunt sterse, odat cu linia din FACTURI, toate liniile
copil din LINIIFACT si INCASFACT.
- DELETE FROM JUDETE WHERE Regiune = 'Moldova' elimin din baza de date toate judetele din
Moldova (sterge toate liniile tabelei JUDETE n care valoarea atributului Regiune este Moldova).

Pentru a modiIica valoarea unuia sau mai multor atribute pe una sau mai multe linii dintr-o
tabel se Ioloseste comanda UPDATE cu Iormatul general (simpliIicat): UPDATE tabel SET atribut1
= expresie1 [, atribut2= expresie2 ..] WHERE predicat. ModiIicarea se va produce pe toate liniile
tabelei care ndeplinesc conditia Iormulat prin predicat. Exemple:
- Noul numr de teleIon al clientului ce are codul 1001 este 0232-313131: UPDATE CLENT SET
Telefon = '0232-313131' WHERE CodCl = 1001
- n cadrul unei noi relaxri Iiscale, se decide cresterea procentului TVA de la 19 la 22 pentru
toate produsele. Atributul modiIicat este ProcTVA din tabela PRODUSE, pe toate liniile: UPDATE
PRODUSE SET ProcTVA = .22

n Anexa 3 (disponibil pe portal) este disponibil listingul cu toate comenzile pentru popularea
cu nregistrri a tabelelor din baza de date VNZRI.

100 Baze de date
CapitoIuI 5
ALGEBRA RELA|IONAL


Obiective:
I. Definirea unui limbaj de interogare
II. Explicarea operatorilor ansambliyti (reuniune, intersec(ie, diferen(,
produs cartezia) yi rela(ionali (selec(ie, proiec(ie, jonc(iune, diviziune)
III. nln(uirea operatorului pentru a ob(ine rspunsul la interogri



Rezultate ayteptate:
Desprinderea redactrii de interogri n algebra rela(ional

FEAA nfoEc + CG - 2006/2007 101
n capitolul 2 am vzut c modelul relational Iormulat de Codd are la baz trei elemente:
structuri, operatii si reguli de integritate. Pentru exprimarea operatiilor aplicabile structurilor de date
prezentul capitol prezent algebra relational, limbaj teoretic bazat pe teoria ansamblurilor (seturilor).
Chiar dac are cusurul de a Ii teoretic, algebra relational poate constitui un bun punct de plecare n
ntelegerea chestiunilor esentiale ale celui mai important limbaj dedicat bazelor de date SQL.
5.1 GENERALITTI DESPRE LIMBA1ELE DE INTEROGARE
Odat cu aparitia bazelor de date, s-a incercat elaborarea Iudamentelor teoretice are unor
limbaje care s prelucreze continutul acestora. Pentru modelul relational, au Iost propuse att limbaje
ansambliste (Alpha, algebra relational, SQL), ct si predicative (calcul relational, QBE), att teoretice
(algebra relational, calcul relational), ct si aplicative (SQL, QBE, Que). Noi vom zbovi doar asupra
ctorva elemente care ar trebui s ajute la ntelegerea modalittilor n care sunt extrase inIormatiile
dintr-o baz de date relational.
Asa cum algebra 'obisnuit aplic operatori, cum Ii adunarea, scderea etc., asupra unor
numere, rezultatul operatorilor Iiind tot un numr, trebuie spus c:
- operatorii relationali se aplic relatiilor luate n ntregime, adic tuturor tuplurilor care alctuiesc
relatiile respective;
- rezultatul Iiecrui operator (rezultatul consultrii) este o nou relatie ce poate servi ca argument ntr-
o alt consultare s.a.m.d.;
- logica operatorilor se bazeaz pe valorile atributelor, ceea ce constituie dealtminteri suportul
singurului mod de acces n BD. ntruct consultrile mono si multi-relatii sunt eIectuate exclusiv prin
compararea valorilor atributelor (deIinite pe domenii compatibile), accesul total independent de limbaj
este asigurat.
Limbajul algebric relational cuprinde dou tipuri de operatori: ansambliti - REUNIUNE,
INTERSECTIE, DIFERENT, PRODUS CARTEZIAN - si relationali - SELECTIE, PROIECTIE,
JONCTIUNE si DIVIZIUNE. O alt clasiIicare distinge operatorii Iundamentali, ireductibili
(reuniunea, diIerenta, produsul cartezian, selectia, proiectia) de cei derivati, a cror Iunctionalitate
poate Ii realizat prin combinarea operatorilor Iundamentali (intersectia, jonctiunea, diviziunea).
Pentru cele ce urmeaz se noteaz cu: t sau r, un tuplu al unei relatii (linie a unei tabele) si t(A), un
sub-tuplu al relatiei R, relativ la atributul A (valoarea atributului A n linia t).
Algebra, ca si calculul relational, serveste ca punct de reIerint n caracterizarea unui limbaj ca
Iiind complet sau incomplet, din punct de vedere relational. Dac un limbaj permite exprimarea tuturor
operatorilor enumerati mai sus si oIer cel putin Iacilittile algebrei relationale, se spune c acesta este
un limbaj relational complet
54
.
5.2 OPERATORII ANSAMBLI$TI
Trei dintre operatorii ansamblisti - reuniunea (""), intersectia ("") si diferenta ('-') - pot
opera numai cu dou relatii uni-compatibile. Fie R
1
( A
1
, A
2
, ..., A
n
,) si R
2
(B
1
, B
2
, ..., B
m
) dou

54
[Saleh94], p.35
102 Baze de date
relatii. Se spune despre R
1
si R
2
c sunt unicompatibile dac: (a) n m; (b) i 1,2, ..., n}, A
i
si B
i

sunt de acelasi tip sintactic (aceasta nu nseamn c trebuie s prezinte, neaprat, domenii identice de
deIinire). Relatiile R1 si R2 din Iigura 5.1 sunt unicompatibile deoarece: (a) ambele au acelasi numr
de atribute; (b) atributele A, B, C din R1 (le putem nota si R1.A, R1.B, R1.C) corespund sintactic
(sunt de acelasi tip) atributelor C, D si E din R2 (R2.C, R2.D, R2.E).

Figura 5.1. Dou relatii unicompatibile
Reuniunea
Reuniunea a dou relatii unicompatibile, R
1
si R
2
, este deIinit astIel: R
1
R
2
tuplu t ,
t R
1
sau t R
2
}. Se noteaz: R3 R1 R2. Continutul tabelei reuniune R3 este prezentat
n Iigura 5.2. Primele trei tupluri din rezultat sunt preluate din R1, iar ultimele dou din R2. R3 are
numai cinci tupluri deoarece un tuplu este comun tabelelor R1 si R2. Algebra relational elimin
automat dublurile (tuplurile identice), astIel nct restrictia de unicitate este asigurat dup orice
operatie.

Figura 5.2. Reuniunea a dou relatii
Exist suIiciente situatii inIormationale care Iac uz de reuniunea a dou tabele. S lum dou
exemple:
A. Tabelele ce reIlect tranzactii economice pot Ii descompuse (sparte) n Iunctie de anul (luna sau
cincinalul, deceniul) la care se reIer; dac ne raportm la baza noastr de date, tabela LINIIFACT
poate Ii rupt n alte dou, LF20002001 care ar contine Iacturile emise n anii 2000 si 2001 si
LINIIFACT ce contine numai nregistrri aIerente anului calendaristic 2002. ncepnd cu 2002, orice
situatie statistic privind vnzrile n perioada 2000-2002, 2000-2003 etc. necesit reuniunea celor
dou tabele, LF20002001 si LINIIFACT.
B. Pentru a aIla care sunt clientii care au cumprat cel putin unul din produsele Produs 1 si Produs 2,
se poate proceda la reuniunea tabelei ce contine clientii care au cumprat Produs 1 cu tabela clientilor
care au cumprat Produs2.
FEAA nfoEc + CG - 2006/2007 103
Reuniunea este comutativ. Singura problem neclar ar Ii legat de numele atributelor n
relatia rezultat. n acest sens, se poate institui regula potrivit creia numele atributelor relatiei-reuniune
sunt numele primei relatii participant n operatie. Aceasta nu are important asupra comutativittii,
deoarece continutul tabelei-rezultat este identic, indiIerent care este prima relatie enumerat.

Intersec(ia
Intersectia a dou relatii uni-compatibile, R1 si R2, poate Ii deIinit astIel: R1 R2 tuplu
t t R1 si t R2 } Se noteaz: R4 R1 R2. Continutul tabelei intersectie R4 este
prezentat n Iigura 5.3. Cum numai un tuplu este absolut identic si n R1 si R2, tabela rezultat este
alctuit dintr-o singur linie.

Figura 5.3. Intersectia a dou relatii
Exemple ce inIormatii care Iac necesar recurgerea la intersectie:
- Pentru a aIla care sunt clientii care au cumprat si Produs 1 si Produs 2, se poate proceda la
intersectia tabelei clientilor care au cumprat Produs 1 cu tabela alctuit din clientii care au cumprat
Produs2;
- Zilele n care s-a Icut vnzri si clientului Client 1 SRL si clientului Client 2 SA;
- Persoanele de la Iirmele-client care cumuleaz posturile de Director van:ri si Sef aprovi:ionare.
Ca si reuniunea, intersectia este comutativ, iar numele atributelor relatiei-intersectie sunt
extrase din prima relatie participant n operatie.

Diferen(a
DiIerenta a dou relatii uni-compatibile, notate R
1
si R
2
, este deIinit astIel: R
1
-

R
2
tuplu
t t R
1
yi t R
2
}. Se noteaz: R5 R1 R2. Continutul tabelei-diIerent R5 (Iigura
5.4) contine numai tuplurile din prima relatie, R1, care nu se regsesc n a doua relatie, R2.

Figura 5.4. Diferenta a dou relatii
104 Baze de date
Asadar, din rezultat este eliminat al treilea tuplu din R1, deoarece valorile acestuia exist si n
R2 (al doilea tuplu din R2). Exemple ce inIormatii care Iac necesar recurgerea la diIerent:
- Care sunt clientii care au cumprat Produs 1 dar nu au cumprat Produs 2 ?
- Care sunt zilele n care s-a Icut vnzri clientului Client 1 SRL dar nu exist nici o Iactur ctre
Client 2 SA ?
Spre deosebire de reuniune si intersectie, diIerenta nu este este comutativ. Atributelor
relatiei-diIerent sunt cele ale primei relatii (desczutul), iar tuplurile sunt extrase din relatia desczut
nu se regsesc n relatia scztor. n plus, nu exist restrictii privind cardinalitatea (numrul de tupluri)
celor dou relatii, adic nu este musai ca relatia desczut s contin mai multe tupluri dect cea
scztor.

Produsul cartezian
Produsul cartezian al dou relatii R1 si R2, denumit de Codd jonctiune ncrucisat (CROSS
JOIN), este ansamblul tuturor tuplurilor obtinute prin concatenarea Iiecrei linii din tabela R1 cu toate
liniile tabelei R2. Formal, dac notm cele dou relatii: R1 (A1, A2, ..., An) si R2 (B1, B2, ..., Bm),
produsul cartezian este deIinit astIel: R1 R2 ( t1 , t2 ) t1 R1 si t2 R2 }. Spre
deosebire de celelalte trei operatiuni precedente, produsul cartezian nu Iace apel la notiunea de relatii
uni-compatibile, iar relatia rezultat cumuleaz atributele celor dou relatii-argument. n Iigura 5.5 este
ilustrat rezutatul produsului cartezian a tabelelor R1 si R2.

Figura 5.5. Produsul carte:ian
Se noteaz: R6 R1 R2. Tabela rezultat R6 are o nou structur - sase atribute (trei
preluate din R1 si trei din R2). ntruct exist un atribut cu nume comun, C, pentru a diIerentia cele
dou aparitii, acestea sunt preIixate, n antetul tabelei, cu numele relatiei din care provine. Prima linie
din R6 este obitinut prin 'lipirea primului tuplu din R1 cu primul tuplu din R2, a doua din primul
tuplu din R1 cu al doilea din R2 etc. Cum R1 are 3 tupluri, iar R2 tot 3, relatia-rezultat al produsului
cartezian are 3 * 3 9 tupluri.
Nu prea exist situatii care s reclame Iolosirea direct si exclusiv a produsului cartezian. Cel
mai important 'merit al acestuia n algebra relational este c permite 'alipirea a dou relatii,
Iundamentnd astIel operatorul-cheie care este jonctiunea.
FEAA nfoEc + CG - 2006/2007 105
5.3 OPERATORII RELATIONALI
Cei patru operatori prezentati n paragraIul precedent sunt generali, spre deosebire de
urmtorii care sunt speciIici algebrei relationale. De obicei gruparea operatorilor relationali se Iace
astIel: (a) operatori unari de restrictie, care permit decupajul unei relatii, pe orizontal - SELECTIA si
pe vertical - PROIECTIA; (b) operatori binari de extensie: JONCTIUNEA si DIVIZIUNEA. O alt
deosebire major Iat de paragraIul precedent este c vom putea recurge si la exemple concrete din
baza de date 'cobai prezentat n capitolul anterior.

Selec(ia
Selectia triaz dintr-o relatie (tabel) numai tuplurile ce satisIac o conditie speciIicat printr-
un predicat. Ca preambul, deIinim notiunea de Iormul F asupra unei relatii R, ca o expresie logic
compus din: operan:i care sunt nume de atribute sau constante; operatori de comparatie aritmetic:
>, , <, , ,; operatori logici: SI, SAU, NON. Selectia unei relatii R, printr-o conditie F, notat
SF(R), poate Ii deIinit: SF(R) tuplu t (t R si F(t) adevrat)}. O notatie ceva mai
pmnteasc este: R1 SELECTIE (R; expresie-logic~), dar, de dragul stiintei, vom detalia:
R este relatia R (A1,A2,...An) asupra creia se aplic selectia (Ai sunt atributele sale).
R1 este noua relatie obtinut n urma selectiei, care va avea aceeasi schem relational cu R -
R1 (A1,A2, ... An).
expresie-logic~ poate Ii scris mai analitic astIel:
expresie-logic~ (termen1) si/sau (termen2) ... si/sau (termenk), unde
o termen j

expresie
1
expresie
2
.
o expresie
1
sau expresie
2
sunt expresii calculate plecnd de la atributele A
i
.
o poate Ii unul dintre operatorii pentru comparatie.

Exemplu 1. Pentru a pune n oper savanta notatie de mai sus, lum n discutie o prim
problem: Care sunt liniile din R1 pentru care valorile atributelor A i C sunt mai mari decat 20 ?
Ajungem, astIel, la notatia:
R SELECTIE (R1; A ~ 20 AND C ~ 20). Tabela R este prezentat n Iigura 5.6.

Figura 5.6. Re:ultat selectie exemplul 1
Exemplu 2. Care sunt fudetele din Moldova ?
Mai nti, se identiIic n baza de date tabela (sau tabelele) din care se extrage rezultatul. n
acest exemplu, aceasta este JUDETE. Apoi se stabilesc atributele (atributul) asupra crora se va aplica
predicatul de selectie. Se obtine: R SELECTIE (JUDETE; Regiune 'Moldova) vezi Iig. 5.7.

Figura 5.7. Re:ultat selectie exemplul 2
106 Baze de date
Exemplu 3. Care sunt facturile emise in perioada 2-5 august 2000 ?
Tabela n care va opera operatorul de selectie este FACTURI. Predicatul de selectie utilizeaz atributul
DataFact: R SELECTIE (FACTURI; DataFact ~ 02/08/2000 AND DataFact 05/08/2000)

Figura 5.8. Re:ultat selectie exemplul 3
Proiec(ia
Prin proiectie, o relatie poate Ii "decupat" pe vertical. Dac selectia extrage dintr-o tabel
anumite linii, pe baza conditiei ndeplinite de valorile unora dintre atribute, proiectia permite
selectarea ntr-o tabel-rezultat numai a coloanelor (atributelor) dorite dintr-o relatie. Formal, Iie o
relatie R (A
1
,A
2
,...A
n
). Proiectia relatiei R asupra unui subansamblu alctuit din atribute proprii este o
relatie care se obtine dup parcurgerea a doi pasi: a. eliminarea dintre A
i
a acelor atribute care nu sunt
speciIicate si b. suprimarea dublurilor (tuplurile identice). Se noteaz: R1 PROIECTIE (R; Aj,
Ak, ..., Ax). Spre deosebire de R, schema relatiei R
1
este alctuit numai din atributele indicate: R
1
(A
j
, A
k
, ..., A
x
). Dac dup extragerea coloanelor nu exist tupluri (linii) identice, R
1
va avea acelasi
numr de linii ca si relatia R. n caz contrar, numrul lor va Ii mai mic, n Iunctie de numrul
dublurilor.

Exemplu 4. ncepem, ca de obicei, cu un exemplu ceva mai arid - Care sunt valorile
combinatiei atributelor A i C in relatia R1 ?
R PROIECTIE (R1; A, C). Tabela R are dou coloane, A si C, si trei linii, ca n Iigura 5.9.

Figura 5.9. Re:ultat proiectie exemplul 4
Exemplu 5. Ce regiuni ale trii sunt preluate in ba: ?
Tabela n care se aIl rspunsul este JUDETE. Singura coloan care intereseaz este Regiune.
R PROIECTIE (JUDETE; Regiune). n primul pas, se Iace decupajul pe vertical, obtinndu-se o
relatia notat R`, apoi se elimin dublurile, rezultatul Iinal Iiind relatia R.

Figura 5.10. Re:ultat proiectie exemplul 5
FEAA nfoEc + CG - 2006/2007 107
Exemplu 6 - Care sunt. codul, denumirea i numrul de telefon ale fiecrui client ?
Tabela care intereseaz este CLIENTI, din care se decupeaz trei coloane: CodCl, DenCl si Telefon.
R PROIECTIE (CLIENTI; CodCl, DenCl, Telefon).

Figura 5.11. Re:ultat proiectie exemplul 6
nln(uirea consultrilor
Rezultatul unei consultri este o relatie (tabel) nou. Pe baza acestui Iapt, se pot nlntui dou
sau mai multe operatiuni, redactndu-se astIel interogri complexe.

Exemplu 7 - Care este numrul de telefon al clientul Client 2 SA ?
Solutia este una Ioarte simp. Cu ajutorul selectiei se decupeaz din relatia CLIENTI numai linia
corespunzoare clientului 'incriminat. Se obtine o relatie nou-nout denumit (de noi) R1. Asupra lui
R1 se aplic o proiectie, deoarece intereseaz numai numrul de teleIon; astIel, R2 contine rspunsul
la problema luat n discutie (vezi Iigura 5.12).
R1 SELECTIE (CLIENTI; DenCl Client 2 SA)
R2 PROIECTIE (R1; Telefon)

Figura 5.12. Inlntuirea unei selectii cu o proiectie exemplul 7
Exemplu 8 - Care sunt denumirile i codurile potale introduse pentru localittile (pre:ente in
ba:) din fudetele Iai (IS) i Jrancea (JN) ?
Tabela 'interogat este CODURIPOSTALE. Pentru a rspunde la ntrebarea pe care tot noi am
Iormulat-o, putem alege ntre urmtoarele dou solutii:
Solutia 1 Iigura 5.13:
R1 SELECTIE (CODURIPOSTALE; Jud IS OR Jud VN)
R2 PROIECTIE (R1; Loc, CodPost)

Figura 5.13. Exemplu 8 solutia 1
Solutia 2 Iigura 5.14:
108 Baze de date
R1 SELECTIE (CODURIPOSTALE; Jud IS)
R2 PROIECTIE (R1; Loc, CodPost)
R3 SELECTIE (CODURIPOSTALE; Jud VN)
R4 PROIECTIE (R3; Loc, CodPost)
R5 R2 R4

Figura 5.14. Exemplu 8 solutia 2
Prima solutie este, prin simplitate, cea mai tentant. Este, ns, un prim caz n care pentru
rezolvarea unei probleme pot Ii Iormulate dou (sau mai multe) solutii.

Exemplu 9 - Care sunt codurile produselor care apar deopotriv in factura 1111 i in factura
1117 ?
Tabela din care vor Ii extrase datele este LINIIFACT. Solutia se bazeaz pe intersectia relatiei care
contine produsele prezente n Iactura 1111 (R2) cu relatia produselor prezente n Iactura 1117 (R4),
dup cum reiese din Iigura 5.15.
R1 SELECTIE (LINIIFACT; NrFact 1111)
R2 PROIECTIE (R1; CodPr)
R3 SELECTIE (LINIIFACT; NrFact 1117)
R4 PROIECTIE (R3; CodPr)
R5 R2 R4

Figura 5.15. Solutie - exemplu 9
1onc(iunea
ntr-un paragraI anterior am vzut c produsul cartezian permite Iuzionarea a dou tabele ntr-
o tabel mamut ce contine toate atributele si liniile obtinute prin combinarea Iiecrui tuplu dintr-o
FEAA nfoEc + CG - 2006/2007 109
relatie cu Iiecare tuplu din cealalt. Tot atunci ne exprimam regretul sincer c operatorul produs
cartezian nu poate Ii Iolosit, de unul singur, n interogri, dar c acest 'neajuns va Ii compensat din
plin de operatorul derivat fonctiune.
Dac produsul cartezian este o Iuziune neconditionat a dou tabele, jonctiunea reprezint
Iuziunea a dou relatii care au o proprietate comun. Fie dou relatii, notate: R1 (A1, A2, ..., An) si
R2 (B1, B2, ..., Bp). Fie Ai si Bj dou atribute deIinite pe acelasi domeniu si ansamblul operatorilor
de comparatie: , ~, , , , }, ce pot Ii aplicati celor dou atribute Ai si Bj. Jonctiunea relatiei R1,
prin Ai, cu relatia R2, prin Bj, notat R1 (Ai Bj) R2 sau R1

R2, este relatia ale crei
tupluri sunt obtinute prin concatenarea Iiecrui tuplu al relatiei R1 cu tuplurile relatiei R2, pentru care
este veriIicat conditia instituit ntre Ai si Bj. R1 (Ai Bj) R2 t , t R1 R2 si t(Ai) t(Bj)}.
Jonctiunea este echivalenta unui produs carte:ian urmat de o selectie. Jonctiunea deIinit mai
sus este reIerit n lucrrile de specialitate ca theta-fonctiune. n lucrul cu BDR se utilizeaz cu
precdere echi-fonctiunea, ce reprezent un caz particular al theta-jonctiunii, atunci cnd este
operatorul de egalitate (""). Formal, echijonctiunea se deIineste astIel: R1 (Ai Bj) R2 t , t R1
R2 si t(Ai) t(Bj)}. Apelm si la o alt notatie, mai usor de reprezentat si suIicient de inteligibil.
R ECHI-JONCTIUNE (R1, R2; AiBj)

Exemplu 10 Theta-fonctiune
ncepem exempliIicrile cu aceleasi dou tabele Iolosite din precedentul paragraI, R1 si R2. Rezultatul
jonctiunii (theta-jonctiunii) exprimat prin expresia: R JONCTIUNE (R1, R2; R1.A ~ R2.E) va
Ii obtinut n doi pasi, dup este descris n Iigura 5.16.

Figura 5.16. Mecanismul de (theta)fonctionare - exemplul 10
Exemplu 11 Echi-fonctiune
Operatorul de comparatie dintre cele dou atribute este, obligatoriu, semnul de egalitate.
R JONCTIUNE (R1, R2; R1.A R2.E)
110 Baze de date

Figura 5.17. Echi-fonctiune - exemplul 11
Exemplu 12 Jonctiune natural
Jonctiunea natural presupune nu numai ca operatorul de comparatie s Iie semnul de egalitate, ci si
denumirea identic a atributelor de legtur dintre cele dou tabele. R JONCTIUNE (R1, R2; R1.C
R2.C). Datorit Iaptului c ambele atribute au acelasi nume, se poate considera c tabela rezultat
pstreaz numai unul din cele dou atribute, ca n Iigura 5.18 si se poate recurge la o notatie
simpliIicat: R JONCTIUNE (R1, R2; C).

Figura 5.18. Jonctiune natural - exemplul 12
De ce se insist att de mult pe importanta jonctiunii ? n primul rnd pentru c permite re-
compunerea relatiei universale initiale. Modelul relational se bazeaz pe spargerea bazei n relatii,
astIel nct nivelul redundantei datelor si problemele la actualizarea tabelelor s Iie reduse la minim.
Cele mai multe interogri, ns, opereaz cu date si predicate aplicate simultan atributelor din dou sau
mai multe tabele. Cum selectia este un operator unar (poate Ii aplicat unei singure relatii), este
necesar Iuzionarea prealabil a celor dou, trei. relatii si obtinerea unei relatii-agregat, relatie
agregat la care se aplic predicatul suplimentar de selectie.
Fuzionarea este posibil prin jonctiune. Prin jonctionarea tuturor relatiilor dintr-o baz de date
se obtine relatia universal (cea initial, atot-cuprinztoare). Nu ne permitem s reconstituim structura
FEAA nfoEc + CG - 2006/2007 111
si continutul relatiei universale ale bazei de date VINZARI, ns, prin exemple, vom ncerc s
demonstrm utilitatea jonctiunii.

Exemplu 13 - S se obtin, pentru fiecare localitate. codurile potale, denumirea, indicativul
fudetului, denumirea fudetului i regiunea din care face parte
Practic, tabelei CODURIPOSTALE i trebuie 'alipite la dreapta inIormatiile din tabela JUDETE.
Problema este diIicil de Iormulat, ns rezolvarea sa este ct se poate de simpl: jonctionarea celor
dou relatii. R JONCTIUNE (CODURIPOSTALE, JUDETE; Jud)
Una din ntrebrile 'clasice pentru veriIicarea modului n care a Iost sau nu nteleas
jonctiunea este: Cate linii are tabela-re:ultat al fonctiunii ? n cazul nostru (de obicei n BDR)
rspunsul este: cate linii are tabela-copil. Rspunsul este corect numai atunci cnd se respect
integritatea reIerential, altIel spus, numai atunci cnd toate valorile cheii strine se regsesc n tabela-
printe. Ca de obicei, lucrurile sunt mai complicate n realitate, deoarece jonctiunea nu se instituie
musai ntre o tabel printe si una copil.

Exemplu 14 - Care sunt localittile din Banat ?
Solutia 1 - dup calapodul exemplului anterior:
R1 JONCTIUNE (CODURIPOSTALE, JUDETE; Jud)
R SELECTIE (R1; Regiune 'Banat)
Solutia 2: Mai nti, se aplic selectia asupra tabelei JUDETE, iar tabela intermediar se
jonctioneaz cu CODURIPOSTALE:
R1 SELECTIE (JUDETE; Regiune 'Banat)
R JONCTIUNE (CODURIPOSTALE, R1; Jud)
A doua variant pare mai bun dect prima, deoarece jonctiunea opereaz asupra a dou relatii mai
reduse ca dimensiuni. DiIerenta este cu att mai vizibil atunci cnd relatia JUDETE contine toate
judetele trii, iar CODURIPOSTALE are cteva sute de nregistrri. Iar dac ne gndim c naintea
oricrei jonctiuni se calculeaz produsul cartezian, apare drept Iireasc ideea amnrii jonctiunii, astIel
nct aceasta s opereze asupra unor tabele cu numr ct mai mic de linii si coloane. Cobornd cu
picioarele pe pmnt, trebuie spus c discutia noastr are un caracter de principiu, deoarece algebra
relational este, totusi, un limbaj. curat teoretic.

Exemplu 15 - In ce :ile s-a vandut produsul cu denumirea 'Produs 1` ?
Elementul de noutate l reprezint interesul pentru o inIormatie ce provine dintr-o relatie (atributul
DataFact din FACTURI) pe baza unei conditii aplicate altei relatii (atributul DenPr din PRODUSE),
iar cele dou relatii, FACTURI si PRODUSE nu sunt n raportul printe-copil. n aceste cazuri, este
necesar atragerea altor relatii, pn se completeaz 'lantul. Interogarea ce rezolv problema ridicat
n acest exemplu necesit si tabela LINIIFACT.
Solutie 1 - neoptimizat
R1 JONCTIUNE (PRODUSE, LINIIFACT; CodPr)
R2 JONCTIUNE (R1, FACTURI; NrFact)
R3 SELECTIE (R2; DenPr 'Produs 1)
R PROIECTIE (R3; DataFact)
112 Baze de date
Solutie 2 optimizat la snge
R1 SELECTIE (PRODUSE; DenPr 'Produs 1)
R2 PROIECTIE (R1; CodPr)
R3 JONCTIUNE (R2, LINIIFACT; CodPr)
R4 PROIECTIE (R3; NrFact)
R5 JONCTIUNE (R4, FACTURI; NrFact)
R PROIECTIE (R4; DataFact)
n cea de-a doua solutie, Iideli principiului 'jonctiunii celei mai economicoase, am eliminat nu numai
tuplurile, dar si atributele de prisos naintea calculrii relatiei intermediare.

Exemplu 16 - In ce fudete s-a vandut produsul cu denumirea 'Produs 1` in perioada 3-5
august 2005 ?
Relatia rezultat trebuie s contin valori ale atributului Judet din tabela JUDETE. Predicatul de
selectie se aplic ns, n alte dou tabele: PRODUSE, n care DenPr 'Produs 1 si FACTURI ale
crei tupluri trebuie s veriIice conditia: DataFact ~ 03/08/2005 AND DataFact < 03/08/2005.
R1 SELECTIE (PRODUSE; DenPr 'Produs 1)
R2 JONCTIUNE (R1, LINIIFACT; CodPr)
R3 PROIECTIE (R2; NrFact)
R4 SELECTIE(FACTURI; DataFact ~ 03/08/2005 AND DataFact < 03/08/2005)
R5 JONCTIUNE (R3, R4; NrFact)
R6 JONCTIUNE (R5, CLIENTI; CodCl)
R7 PROIECTIE (R6; CodPost)
R8 JONCTIUNE (R7, CODURIPOSTALE; CodPost)
R9 PROIECTIE (R8; Jud)
R10 JONCTIUNE (R9, JUDETE; Jud)
R PROIECTIE (R10; Judet)

Exemplu 17 - In ce :ile s-au vandut i produsul cu denumirea 'Produs 1` i cel cu
denumirea 'Produs 2` ?
Rezultatul contine atributul DataFact. Predicatul de selectie se aplic tabelei PRODUSE.
Solutie 1
R1 SELECTIE (PRODUSE; DenPr 'Produs 1)
R2 JONCTIUNE (R1, LINIIFACT; CodPr)
R3 JONCTIUNE (R2, FACTURI; NrFact)
R4 PROIECTIE (R3; DataFact)
R5 SELECTIE (PRODUSE; DenPr 'Produs 2)
R6 JONCTIUNE (R5, LINIIFACT; CodPr)
R7 JONCTIUNE (R6, FACTURI; NrFact)
R8 PROIECTIE (R7; DataFact)
R R4 R8
Solutie 2
R1 SELECTIE (PRODUSE; DenPr 'Produs 1)
R2 JONCTIUNE (R1, LINIIFACT; CodPr)
FEAA nfoEc + CG - 2006/2007 113
R3 JONCTIUNE (R2, FACTURI; NrFact)
R4 SELECTIE (PRODUSE; DenPr 'Produs 2)
R5 JONCTIUNE (R5, LINIIFACT; CodPr)
R6 JONCTIUNE (R6, FACTURI; NrFact)
R7 JONCTIUNE (R3, R6; DataFact)
R PROIECTIE (R7; DataFact)
Prima variant este una 'cuminte. Se intersecteaz relatia zilelor n care s-a vndut primul produs
(R4) cu relatia zilelor n care s-a Iacturat produsul 2 (R8). A doua e ceva mai insolit. Pur si simplu, n
loc de intersectie Iolosim jonctiunea. Cum, spre deosebire de intersectie, relatiile jonctionate nu
trebuie s Iie unicompatibile, putem s operm direct jonctiunea ntre R3 si R6.
Retinem ideea: putem s simulm intersectia a dou relatii prin jonctiune. Pentru a Ii mai
convingtor, rogu-v s examinati Iigura 5.19 n care, pornind de la relatiile R1 si R2, se obtine
relatia-intersectie R direct prin operatorul intersectie (stnga Iigurii) si mai pe ocolite, Iolosind
jonctiunea (dreapta).

Figura 5.19. Intersectia prin fonctiune
Exemplu 18 - Ce clienti au cumprat 'Produs 2` i 'Produs 3`, dar nu au cumprat
'Produs 5` ?
Bun ntrebare ! Lucrurile nu ns att de complicate precum par, deoarece Iolosim elemente din
exemplul anterior (intersectia) plus operatorul. diIerent.
R1 SELECTIE (PRODUSE; DenPr 'Produs 2)
R2 JONCTIUNE (R1, LINIIFACT; CodPr)
R3 JONCTIUNE (R2, FACTURI; NrFact)
R4 JONCTIUNE (R3, CLIENTI; CodCl)
R5 PROIECTIE (R4; DenCl)
R6 SELECTIE (PRODUSE; DenPr 'Produs 3)
R7 JONCTIUNE (R6, LINIIFACT; CodPr)
R8 JONCTIUNE (R7, FACTURI; NrFact)
R9 JONCTIUNE (R8, CLIENTI; CodCl)
R10 PROIECTIE (R9; DenCl)
114 Baze de date
R11 SELECTIE (PRODUSE; DenPr 'Produs 5)
R12 JONCTIUNE (R11, LINIIFACT; CodPr)
R13 JONCTIUNE (R12, FACTURI; NrFact)
R14 JONCTIUNE (R13, CLIENTI; CodCl)
R15 PROIECTIE (R14; DenCl)
R R5 R10 R15

Exemplu 19 - Ce facturi au fost emise in aceeai :i cu factura 1120 ?
Spre deosebire de interogrile de pn acum, conditia de selectie este una indirect. n prealabil,
trebuie determinat ziua n care a Iost ntocmit Iactura cu numrul 1120. Apoi trebuie extrase, din
relatia FACTURI, liniile pentru care DataFact are valoarea zilei Iacturii-reper.
R1 SELECTIE (FACTURI; NrFact 1120)
R2 PROIECTIE (R1; DataFact)
R3 JONCTIUNE (FACTURI, R2; DataFact)
R PROIECTIE (R3; NrFact)

1onc(iunea extern
Ideea de baz a jonctiunii externe este de a include n rezultat si tupluri din una din relatii, sau
din ambele relatii, care prezint valori ale atributului de legtur ce nu se regsesc n cealalt relatie.
Dac precedentele tipuri de jonctiune sunt comutative, n cazul jonctiunii externe trebuie speciIicat din
care relatie se extrag liniile Ir corepondent n cealalt relatie. De aceea, exist fonctiune extern la
stanga si fonctiune extern la dreapta. La acestea se adaug fonctiunea extern total (denumit si
plin sau deplin) care reprezint reuniunea celor dou. Apelnd la aceleasi tabele 'abstracte, R1 si
R2, diIerenta dintre jonctiunea intern (echi-jonctiunea) si cele trei tipuri de jonctiune extern apare cu
mai mult claritate n Iigura 5.20.

Figura 5.20. Diferenta dintre echi-fonctiune i fonctiunile externe
Exemplu 20 - Care sunt localittile in care nu avem nici un client ?
FEAA nfoEc + CG - 2006/2007 115
Solutia 1 se bazeaz diIerenta dintre tabela tuturor localittilor (din tabela CODURIPOSTALE) si
tabela localittilor n care exist clienti (tabela CLIENTI).
R1 PROIECTIE (CODURIPOSTALE; CodPost)
R2 PROIECTIE (CLIENTI; CodPost)
R3 R1 R2
R JONCTIUNE (R3, CODURIPOSTALE; CodPost)
Solutia 2 utilizeaz proaspta jonctiune extern.
R1 JONCTIUNE EXTERN LA STNGA (CODURIPOSTALE, CLIENTI;
CODURIPOSTALE.CodPost CLIENTI.CodPost)
R SELECTIE (R1; CodCl IS NULL)
Pentru a identiIica localittile Ir clienti, s-au extras, din jonctiunea extern la stnga a relatiilor
CODURIPOSTALE si CLIENTI, numai liniile n care unul din atributele preluate din CLIENTI (noi
ne-am oprit asupra primului, CodCl) are valoarea NULL.

Diviziunea
Este cel mai complex si mai greu de explicat dintre operatorii prezentati n acest capitol. Codd
l-a imaginat ca operator invers al produsului cartezian. Pentru a-l deIini, se porneste de la dou relatii
R1(X,Y) si R2(Y); prima are, care va s zic, dou atribute sau grupe de atribute, notate X si Y, n
timp ce a doua numai atributul sau grupul de atribute notat cu Y (deIinit pe acelasi domeniu ca si n
relatia R1). O prim restrictie: relatia R2(Y), Iiind numitorul diviziunii, nu trebuie s Iie vid.
Diviziunea relational R1 R2 are ca rezultat o relatie deIinit ca ansamblul sub-tuplurilor
R1(X) pentru care produsul (lor) cartezian cu R2(Y) este un subansamblu al R1(X,Y). Rezultatul
expresiei R1 R2 reprezint ctul diviziunii, Iiind o relatie ce poate Ii notat R3(X). ntr-o alt
Iormulare, xi R3 dac si numai dac yi Y R2 (xi, yi) R1. Pentru
simpliIicarea prezentrii, n continuare am considerat X si Y dou atribute, desi, dup cum reiese din
preambul, acestea pot Ii grupe (ansambluri) de atribute. S examinm elementele din Iigura 5.21.

Figura 5.21. Divi:iunea relational
Determinarea relatiei R3 R1 R2 este sinonim cu rezolvarea problemei: care dintre x1,
x2, x3, x4 si x5 apar n R1, n tupluri mpreun cu toate valorile lui Y din R2, respectiv y1, y2, y3,
y4 si y5 ?
116 Baze de date
Se parcurg pe rnd valorile xi ale atributului X din relatia R1:
x1 apare cu y1 (n tuplul 1), cu y2 (n tuplul 4), cu y3 (n tuplul 7), cu y4 (n tuplul 10) si cu y5
(n tuplul 13). Deci x1 ndeplineste conditia si va Ii inclus n relatia R3;
x2 apare cu y1 (n tuplul 2) dar nu apare cu y2 - nu va Iace parte din R3;
x3 apare cu y1 (n tuplul 3), cu y2 (n tuplul 5), cu y3 (n tuplul 8), cu y4 (n tuplul 11) si cu y5
(n tuplul 15) - ndeplineste conditia si va Ii tuplu n R3;
x4 nu apare cu y1 - nu va Iace parte din R3.
x5 nu apare cu y1 - nu va Iace parte din R3.
n urma rationamentului de mai sus, tabela R3 va Ii alctuit din dou tupluri. Desi pare un operator
ceva mai metaIizic, diviziunea relational este deosebit de util pentru Iormularea consultrilor n care
apare clauza "" ("oricare ar Ii" sau "pentru toate").

Exemplu 22 - Care sunt clientii pentru exist cel putin cate o factur emis in fiecare :i ?
ntr-o alt Iormulare, ne intereseaz clientii care au cumprat 'cte ceva n toate zilele n care s-au
eIectuat vnzri ? Prin urmare, ctul va Ii o tabel cu singur atribut, DenCl (denumirea clientului), iar
divizorul va Ii o relatie alctuit numai din atributul DataFact (contine toate zilele n care s-au eIectuat
vnzri). Dac am merge pe calapodul prezentat, am putea nota R3(DenCl), R2(DataFact). Cunoscnd
structura ctului si a divizorului, putem determina structura tabelei-demprtit: R1(DenCl, DataFact).
Relatia R1 va contine denumirile clientilor si zilele n care exist mcar o Iactur pentru clientul
respectiv. Solutia poate Ii redactat n urmtorii pasi:
a. construire relatiei-demprtit:
R11 JONCTIUNE (FACTURI, CLIENTI; CodCl)
R1 PROIECTIE (R1; DenCl, DataFact)
b. construire relatie-numitor: R2 PROIECTIE (FACTURI; DataFact)
c. n Iine, apoteoza: R3 R1 R2
Schema si continutul relatiilor implicate n aceast solutie sunt prezentate n Iigura 5.22.

Figura 5.22. Divi:iunea relational exemplu 22
FEAA nfoEc + CG - 2006/2007 117
Poate o s spuneti c n-a meritat eIortul, dar acest gen de solutii se aplic la o larg gam de
probleme. S discutm cteva spete.

Exemplu 23 - In ce :ile s-au vandut i produsul cu denumirea 'Produs 1` i cel cu denumirea
'Produs 2` ?
V gnditi, probabil, c ati mai vzut undeva acest enunt. Este chiar textul problemei de la exemplul
17. La acel moment, am Iormulat dou solutii: una 'clasic, bazat pe intersectie si una mai
neconventional ce utilizeaz jonctiunea. Adugm la acestea o alta, ncadrabil probabil tot n
categoria 'neconventionale.
Solutie 3
R11 SELECTIE (PRODUSE; DenPr 'Produs 1 OR DenPr 'Produs 2)
R12 JONCTIUNE (R11, LINIIFACT; CodPr)
R13 JONCTIUNE (R12, FACTURI; NrFact)
R1 PROIECTIE (R13; DataFact, CodPr)
R2 PROIECTIE (R11; CodPr)
R3 R1 R2
Relatia divizor este alctuit din dou tupluri ce contin codurile celor dou produse. Demprtitul este
alctuit din atributele DataFact si CodProd si contine toate produsele vndute n Iiecare din zilele de
Iacturare.

Exemplu 24 - Ce facturi au fost emise in aceeai :i cu factura 1120 ?
Desi reprezint un regres vizibil Iat de nivelul interogrilor precdente, revenim discret la enuntul
exemplului 19. Pentru aceast problem se poate ncropi si o variant de rezolvare bazat pe
diviziunea relational.
R1 PROIECTIE (FACTURI; NrFact, DataFact)
R2` SELECTIE (FACTURI; NrFact 1120)
R2 PROIECTIE (R2`; DataFact)
R DIVIZIUNE (R1, R2)

Exemplu 25 - Cror clienti le-au fost vandute toate produsele firmei ?
R11 JONCTIUNE (LINIIFACT, FACTURI; NrFact)
R1 PROIECTIE (R11; CodCl, CodPr)
R2 PROIECTIE (PRODUSE; CodPr)
R3 DIVIZIUNE (R1, R2)
R JONCTIUNE (R3, CLIENTI; CodCl)

118 Baze de date

CapitoIuI 6
INTEROGRI SQL (1)

Obiective:
I. Scurt incursiune n standardele SQL
II. Reflectarea n SQL a operatorilor ansambliyti
III. Prelucrarea datelor calendaristice
IV. Folosirea operatorilor BETWEEN, LIKE, IN
V. 1onc(iunile n SQL
VI. Func(ii agregat: COUNT, SUM, AVG, MIN, MAX
VII. Gruparea tuplurilor: GROUP BY yi HAVING
VIII. Manipularea valorilor NULL yi jonc(iuni externe
IX. Structuri alternative
X. Subconsultri


Rezultate ayteptate:
Deprinderea tuturor op(iunilor pentru redactarea interogrilor de
complexitate medie
FEAA nfoEc + CG - 2006/2007 119
6.1 ISTORICUL SQL. STANDARDE
Dup multi autori, momentul decisiv n nasterea SQL ca limbaj l constituie lansarea
proiectului System /R de ctre Iirma IBM, eveniment ce a avut loc n 1974. Tot n 1974 Chamberlin si
Boyce au publicat o lucrare n care este prezentat Iorma unui limbaj structurat de interogare,
"botezat" SEQUEL (Structured English as QUEry Language). n 1975 Chamberlin, Boyce, King si
Hammer public un articol n care prezint sub-limbajul SQUARE, asemntor SEQUEL-ului, dar
care utiliza expresii matematice si nu cuvinte din limba englez. Autorii celor dou studii au
demonstrat c limbajele SEQUEL si SQUARE sunt complete din punct de vedere relational.
Un colectiv de autori, condus de Chamberlin, elaboreaz n 1976 o nou lucrare n care se Iace
reIerire la SEQUEL 2, acesta Iiind "preluat" ca limbaj de interogare al SGBD-ului System /R al Iirmei
IBM. n 1980 Chamberlin schimb denumirea SEQUEL n SQL - Structured Query Language (Limbaj
Structurat de Interogare), dar si astzi multi specialisti pronunt SQL ca pe predecesorul su. Anii
urmtori au nregistrat aparitia a o serie ntreag de lucrri care l-au perIectionat, ultimul deceniu
consacrndu-l ca pe cel mai rspndit limbaj de interogare a BDR, Iiind prezent n numeroase
"dialecte" speciIice tuturor SGBDR-urilor actuale, de la DB2 la MicrosoIt SQL Server, de la Oracle la
FoxPro si ACCESS.
American National Standard Institute public n 1986 standardul SQL ANSI X3.136-1986.
Este un standard care se bazeaz, ntr-o mare msur, pe "dialectul" SQL al produsului DB2 de la
IBM. n 1989 are loc revizuirea extinderea acestui standard, "nscndu-se" SQL-89, care mai este
denumit si SQL1. Desi recunoscut ca baz a multor SGBDR-uri comerciale, SQL1 si-a atras
numeroase critici. n plus, variantele comercializate de diIeritii productori, desi asemntoare n
esent, erau (si sunt) incompatibile la nivel de detaliu. Pentru a umple golurile SQL1, ANSI a elaborat
n 1992 "versiunea" SQL2, speciIicatiile Iiind prezentate la un nivel mult mai detaliat (dac SQL1 se
ntindea pe numai 100 de pagini, SQL2 a Iost publicat n aproape 600). IBM a avut un aport
incontestabil la aparitia si maturizarea SQL, Iiind un productor cu mare inIluent n "lumea" SGBD-
urilor, iar produsul su, DB2, este unul din standardele de Iacto ale SQL.
Standardul SQL:1999 a Iost amnat de cteva ori pn la publicarea sa, iar cea mai recent
versiune este SQL:2003. Actualmente, principalele orientri ale SQL vizeaz transIormarea acestuia
ntr-un limbaj complet, n vederea deIinirii si gestionrii obiectelor complexe si persistente. Aceasta
include: generalizare si specializare, mosteniri multiple, polimorIism, ncapsulare, tipuri de date
deIinite de utilizator, triggere (declansatoare) si proceduri stocate, suport pentru sisteme bazate pe
gestiunea cunostintelor, expresii privind interogri recursive si instrumente adecvate de administrare a
datelor.
La momentul actual, SQL reprezint cel mai important limbaj actual n domeniul bazelor de
date, att prin gama comenzilor si optiunilor de care dispune, dar mai ales datorit Iaptului c s-a
reusit standardizarea sa si portarea pe toate Sistemele de Gestiune a Bazelor de date semniIicative. Cu
att mai mult, cu ct, spre deosebire de majoritatea covrsitoare a altor limbaje, poate Ii deprins relativ
usor de neinIormaticieni si utilizat pentru chestiuni de mare Iinete de ctre proIesionisti. Acest capitol
se doreste a Ii o prezentare a elementelor esentiale prin care, dat Iiind structura unei baze de date
relationale, pot Ii Iormulate interogri (Iraze SELECT) prin care se obtin rspunsuri la gam eterogen
120 Baze de date
de ntrebri. n plus, sunt evocate pe scurt comenzile pentru actualizarea unei tabele (INSERT,
UPDATE, DELETE), precum si cele de declarare a structurii bazei de date (CREATE TABLE).
Din perspectiva prezentei lucrri, obiectivul principal al SQL const n a oIeri utilizatorului
mijloacele necesare Iormulrii unei consultri numai prin descrierea rezultatului dorit, cu ajutorul unei
asertiuni (expresie logic), Ir a Ii necesar si explicitarea modului eIectiv n care se Iace cutarea n
BD. AltIel spus, utili:atorul calific (specific) re:ultatul, iar sistemul se ocup de procedura de
cutare. Desi toate clasiIicrile l ncadreaz la limbaje de generatia a IV-a, SQL nu este, totusi, un
limbaj de programare propriu-zis, prin comparatie cu Basic, Pascal, C, COBOL etc. SQL nu contine
(pn la SQL3) instructiuni/comenzi pentru codiIicarea secventelor alternative si repetititive, cu att
mai putin Iacilitti de lucru cu obiecte vizuale, speciIice Iormularelor de preluare a datelor (csute-
text, butoane radio, liste, butoane de comand etc.). Din acest punct de vedere, poate Ii reIerit ca sub-
limbaj orientat pe lucrul cu bazele de date. Comenzile sale pot Ii, ns, inserate n programe redactate
n limbaje de programare "clasice".
Principalele atuuri ale SQL sunt:
1. Independenta de productor, neIiind o tehnologie "proprietar".
2. Portabilitate ntre diIerite sisteme de operare.
3. Este standardizat.
4. "FilosoIia" sa se bazeaz pe modelul relational de organizare a datelor.
5. Este un limbaj de nivel nalt, cu structur ce apropie de limba englez.
6. Furnizeaz rspunsuri la numeroase nterogri simple, ad-hoc, neprevzute initial.
7. Constituie suportul programatic pentru accesul la BD.
8. Permite multiple imagini asupra datelor bazei.
9. Este un limbaj relational complet.
10. Permite deIinirea dinamic a datelor, n sensul modiIicrii structurii bazei chiar n timp ce o parte
din utilizatori sunt conectati la BD.
11. Constituie un excelent suport pentru implementarea arhitecturilor client-server.
6.2 SINTAXA DE BAZ A FRAZEI SELECT
Fr ndoial, cea mai gustat parte din SQL este cea legat de interogarea bazei, adic de
obtinerea de inIormatii din cele mai diverse, prin prelucrri, grupri etc. n SQL o interogare se
Iormuleaz printr-o Iraz SELECT care un Iormat pe ct de simplu, pe att de Ilexibil. Cele trei
clauze principale sunt SELECT, FROM si WHERE
55
, din care numai primele dou sunt obligatorii.
Pentru nceput, vom Iace o paralel cu operatorii algebrei relationale prezentati n capitolul 5.
6.2.1 Reflectarea operatorilor din algebra rela(ionale (1)

Selec(ia yi proiec(ia
Clauza SELECT corespunde operatorului proiectie din algebra relational, Iiind utilizat
pentru desemnarea listei de atribute (coloanele) din rezultat. Clauza FROM este cea n care sunt
enumerate relatiile din care vor Ii extrase inIormatiile aIerente consultrii. Prin WHERE se
desemneaz predicatul selectiv al algebrei relationale, relativ la atribute ale relatiilor care apar n
clauza FROM.


55
La adresa http://w3.one.net/~jhoffman/sqltut.htm este un bun curs introductiv despre SQL
FEAA nfoEc + CG - 2006/2007 121
Prin executia unei Iraze SELECT se obtine un rezultat de Iorm tabelar. Acesta poate Ii o
list (text), o tabel propriu-zis sau o tabel temporar (care, de obicei, nu poate Ii actualizat), dar si
o tabel derivat (imagine). Uneori rezultatul poate Ii obtinut si ca o variabil masiv (tablou). Atunci
cnd clauza WHERE este omis, se consider implicit c predicatul P are valoarea logic "adevrat",
astIel nct vor Ii incluse n rezultat toate liniile din tabela, sau produsul cartezian al tabelelor,
enumerat/enumerate n clauza FROM. Dac, n locul coloanelor C1, C2, ... Cn, apare simbolul *,
rezultatul va Ii alctuit din toate coloanele (atributele) relatiilor speciIicate n clauza FROM. De
asemenea, atributele rezultatului preiau numele din tabela/tabelele speciIicate n FROM. Schimbarea
numelui se realizeaz prin clauza AS.
n capitolul 1 era subliniat echivalenta notiunilor relatie-tabel. ConIorm restrictiei de
unicitate, ntr-o relatie nu pot exista dou linii identice. n SQL, tabela obtinut dintr-o consultare
poate contine dou sau mai multe tupluri identice. Spre deosebire de algebra relational, in SQL nu
se elimin automat tuplurile identice (dublurile) din re:ultat. Pentru aceasta este necesar utilizarea
optiunii DSTNCT:
SELECT DSTNCT C1, C2, ..., Cn
FROM R1, R2, ..., Rm
WHERE P
n concluzie, o Iraz SELECT, n Iorma n care a Iost prezentat, corespunde: unei selectii algebrice
(clauza WHERE - P); unei proiectii (SELECT - Ci); unui produs cartezian (FROM - R1 R2 ...
Rm), si conduce la obtinerea unui rezultat cu n coloane, Iiecare coloan Iiind un atribut din R1, R2, ...,
Rm sau o expresie calculat pe baza unor atribute din R1, R2, ..., Rm. Acum vom trece n SQL cteva
interogri din algebra relational, pe baza exemplelor din capitolul 5.
Exemplul 1 - selectie
SELECT * FROM R1 WHERE A > 20 AND C > 20
Exemplul 2 selectie (Care sunt fudetele din Moldova ?)
SELECT * FROM JUDETE WHERE Regiune = "Moldova
Exemplul 3 selectie (Care sunt facturile emise in perioada 2-5 august 2005 ?)
Formatul standard al unei constante de tip dat calendaristic este YYYY-MM-DD, asa nct o
interogarea n SQL-92 (si n dialectul PostgreSQL) poate avea Iorma:
SELECT * FROM FACTUR WHERE DataFact >= '2005-08-02' AND DataFact <= '2005-08-05'
Exemplul 4 proiectie
SELECT A,C FROM R
Exemplul 5 (Care sunt regiunile trii preluate in ba: ?)
Dup cum aminteam mai sus, spre deosebire de algebra relational, SQL nu elimin automat dublurile.
Tabela obtinut prin consultarea:
SELECT Regiune FROM JUDETE
are structura si continutul identice cu R` (Iigura 5.10). Pentru a obtine rspunsul de Iorma tabelei R (o
regiune s apar o singur dat n rspuns) se Ioloseste clauza DISTINCT:
SELECT DSTNCT Regiune FROM JUDETE
Exemplul 6 (Care sunt. codul, denumirea i numrul de telefon ale fiecrui client ?)
SELECT CodCl, DenCl, Telefon FROM CLENT
Nu este necesar clauza DISTINCT, deoarece CodCl este cheia primar a tabelei CLIENTI.

122 Baze de date
Exemplul 7 (Care este numrul de telefon al clientul Client 2 SA ?)
SELECT Telefon FROM CLENT WHERE DenCl = 'Client 2 SA'
Exemplul 8 (Care sunt denumirile i codurile potale ale localittilor (pre:ente in ba:) din
fudetele Iai (IS) i Jrancea (JN) ?)
SELECT Loc, CodPost FROM coduri_postale WHERE Jud = 'S' OR Jud = 'VN'

Reuniunea
Un rezultat identic cu tabela R3 din Iigura 5.2. se obtine prin Iraza SELECT urmtoare:
SELECT * FROM R1 UNON SELECT * FROM R2
La reuniunea a dou tabele, SQL elimin automat liniile identice din rezultat. Dac se doreste
preluarea tuturor liniilor celor dou relatii, si, implicit, aparitia de linii duplicate se Ioloseste clauza
ALL astIel:
SELECT * FROM R1 UNON ALL SELECT * FROM R2

Revenim la exemplul 8 din capitolul 5 (Care sunt denumirile si codurile postale ale
localittilor (prezente n baz) din judetele Iasi (IS) si Vrancea (VN) ?). Fraza SQL echivalent
solutiei 2 (bazat pe reuniune este):
SELECT Loc, CodPost FROM CODUR_POSTALE WHERE Jud = 'S'
UNON SELECT Loc, CodPost FROM CODUR_POSTALE WHERE Jud = 'VN'

Intersec(ia
Raportndu-ne la exemplul din Iigura 2.3, echivalentul tabelei R4 se obtine n SQL prin:
SELECT * FROM R1 NTERSECT SELECT * FROM R2
SQL92 permite, ca si n cazul reuniunii, prezenta repetat n rezultat a unor linii (tupluri duplicate),
binenteles atunci cnd cele dou relatii asupra crora se aplic intersectia nu respect restrictia de
unicitate:
SELECT * FROM R1 NTERSECT ALL SELECT * FROM R2
Dac tuplul t1 apare repetat si n R1 si n R2, mai precis, de n ori n R1 si de m ori n R2, n rezultatul
operatorului INTERSECT t1 apare o singur dat, n timp ce utiliznd INTERSECT ALL t1 va aprea
de un numr de ori care este minimul dintre n si m.
Pentru o prim ilustrare a utilizrii a intersectiei, transcriem solutia din algebra relational
Iormulat la exemplul 9 (Care sunt codurile produselor care apar simultan si n Iactura 1111 si n
Iactura 1117 ?):
SELECT CodPr FROM LNFACT WHERE NrFact = 1111
NTERSECT SELECT CodPr FROM LNFACT WHERE NrFact = 1117
Exemplele de mai sus Iunctioneaz n DB2, Oracle, si PostgreSQL nu ns si n alte SGBD-
uri (ex. Visual FoxPro) care nu are implementat operatorul INTERSECT, astIel nct intersectia
trebuie realizat prin alte clauze si operatori.

Diferen(a
Operatorul asteptat ar Ii MINUS. n standardul SQL92, si n cteva SGBDR-uri precum DB2,
operatorul MINUS nu exist, Iiind substituit de EXCEPT, iar n alte SGBD-uri nu exist nici unul, nici
altul. Tabela R5 din Iigura 2.5, calculat prin expresia R1-R2, se obtine n SQL (si PostgreSQL) prin
interogarea:
FEAA nfoEc + CG - 2006/2007 123
SELECT * FROM R1 EXCEPT SELECT * FROM R2
Ca si n cazul reuniunii si intersectii, eliminarea tuplurilor duplicate se Iace automat, iar repetarea lor
se asigur prin EXCEPT ALL.
ModiIicm enuntul exemplului 9 n urmtorul: Care sunt codurile produselor care apar in
factura 1111, dar nu apar in factura 1117 ?
SELECT CodPr FROM LNFACT WHERE NrFact = 1111
EXCEPT SELECT CodPr FROM LNFACT WHERE NrFact = 1117

Produsul cartezian
SQL nu pune la dispozitie vreun operator special dedicat produsului cartezian. Nici nu este nevoie.
Tabela R6 din Iigura 5.5 se obtine, pur si simplu, prin enumerarea celor dou relatii n clauza FROM:
SELECT * FROM R1, R2
6.2.2 Coloane-expresii
O Iacilitate important n multe interogri SQL tine de deIinirea, pe lng atributele
tabelelelor, a unor coloane noi, pe baza unor expresii. Clauza AS permite denumirea coloanelor
calculate, sau redenumirea unor coloane ale tabelelor. S lum un exemplu banal: Care este, pentru
fiecare produs din factura 1111, codul, cantitatea, pretul unitar i valoarea fr TJA ?
SELECT CodPr, Cantitate, PretUnit, Cantitate * PretUnit AS ValFaraTVA
FROM LNFACT WHERE NrFact = 1111
Rezultatul interogrii este prezentat n Iigura 6.1.

Figura 6.1. Exemplu de coloan calculat
A patra coloana este denumit ValFaraTVA, dup cum a Iost speciIicat n clauza AS. Valorile sale sunt
determinate pe baza expresiei Cantitate * PretUnit.
Un alt tip de expresie este cel bazat pe concatenare, adic pe alipirea mai multor constante si
variabile ntr-o coloan nou. Operatorul SQL pentru concatenare este alctuit din dou bare verticale
(,,). Spre exemplu, interogarea urmtoare produce rezultatul din Iigura 6.2.
SELECT 'Judetul ' || Judet || ' se afla in ' || Regiune AS Exemplu_Concatenare
FROM JUDETE

Figura 6.2. Concatenarea unor literali i atribute ir de caractere
n PostgreSQL si Oracle se pot concatena direct, adic Ir conversie prealabil, literali,
atribute-sir de caractere, numerice etc. Alte SGBD-uri, precum DB2, necesit transIormarea valorilor
124 Baze de date
non-sir de caractere (atribute/constante numerice, dat calendaristic etc.), operatiune realizat prin
Iunctia CAST. Spre exemplu, n Oracle si PostgreSQL interogarea urmtoare este Iunctional:
SELECT 'Factura ' || NrFact || ' a fost emisa pe data ' || DataFact AS Concatenare_Oracle_PgSQL
FROM FACTUR
n timp ce DB2 nu o suport. Folosind Iunctia de conversie CAST, putem redacta urmtoarea variant
a interogrii care Iunctioneaz si n PostgreSQL:
SELECT 'Factura ' || CAST (NrFact AS CHAR(8)) || ' a fost emisa pe data ' ||
CAST (DataFact AS VARCHAR(10)) AS Concatenare_DB2_PgSQL
FROM FACTUR
Valorile atributului NrFact sunt transIormate si siruri de caractere de lungime Iix (8 pozitii), n timp
ce ale DataFact vor Ii convertite n siruri de caractere de lungime variabil (vorba vine, deoarece
Iormatul datei este unitar pentru toate liniile rezultatului) de maximum 10 pozitii.
n Iinalul discutiei despre coloanele-expresii, mai zbovim pret de cteva rnduri la expresiile
de tip dat calendaristic. Modurile n care au Iost implementate aceste Iunctiuni sunt Ioarte eterogene
de la SGBD la SGBD. S presupunem c orice Iactur trebuie ncasat n maximum dou sptmni.
DataFact Iiind un atribut de tip DATE, implicit se consider 14 ca Iiind numrul zilelor:
SELECT NrFact AS Factura, DataFact AS Data_Facturare, DataFact + 14 AS Scadenta_ncasare
FROM FACTUR
SpeciIicarea intervalelor calendaristice este o sarcin usoar n mai toate serverele de baze de
date. AstIel, interogarea urmtoare este redactat n PostgreSQL si Iurnizeaz acelasi rezultat n
privinta datei scadente:
SELECT NrFact AS Factura, DataFact AS Data_Facturare,
DataFact + 14 AS Scadenta_ncasare1,
DataFact + NTERVAL '14 DAYS' AS Scadenta_ncasare2,
DataFact + NTERVAL '2 WEEKS' AS Scadenta_ncasare3
FROM FACTUR
Dac am presupune c scadenta ar Ii peste dou luni de la Iacturare, interogrile ar trebui
modiIicate astIel n PostgreSQL:
SELECT NrFact AS Factura, DataFact AS Data_Facturare,
DataFact + NTERVAL '2 MONTHS' AS Scadenta_ncasare
FROM FACTUR
sau
SELECT NrFact AS Factura, DataFact AS Data_Facturare, DataFact + NTERVAL '2' MONTH
AS Scadenta_ncasare FROM FACTUR
Ultima variant Iunctioneaz si n Oracle care are ns si o Iunctie proprie ADDMONTHS:
SELECT NrFact AS Factura, DataFact AS Data_Facturare,
ADD_MONTHS(DataFact,2) AS Scadenta_ncasare
FROM FACTUR
Complicndu-ne si mai zdravn, dorim s aIism pentru Iiecare Iactur ce dat va Ii peste 1
an, dou luni si 25 de zile de la momentul emiterii.
Solutia 1 PostgreSQL:
SELECT NrFact AS Factura, DataFact AS Data_Facturare,
DataFact + NTERVAL '1 YEAR' + NTERVAL '2 MONTH'
+ NTERVAL '25 DAY' AS O_Data_Viitoare
FEAA nfoEc + CG - 2006/2007 125
FROM FACTUR
Solutia 2 PostgreSQL:
SELECT NrFact AS Factura, DataFact AS Data_Facturare,
DataFact + NTERVAL '1 YEAR 2 MONTH 25 DAY' AS O_Data_Viitoare
FROM FACTUR
Solutia 1 Oracle (transIormarea anilor n luni):
SELECT NrFact AS Factura, DataFact AS Data_Facturare,
ADD_MONTHS(DataFact,14)+15 AS O_Data_Viitoare
FROM FACTUR
Solutia 2 Oracle:
SELECT NrFact AS Factura, DataFact AS Data_Facturare,
DataFact + NTERVAL '1-2' YEAR TO MONTH + 25 AS O_Data_Viitoare
FROM FACTUR

n ceea ce priveste operatiunile de adunare si scdere ntre dou date calendaristice, aici
lucrurile se prezint si mai diIerentiat. Spre exemplu, intereseaz intervalul scurs ntre momentul
curent si cel al emiterii Iiecrei Iacturi. Interogarea PostgreSQL/Oracle are Iorma:
SELECT NrFact, DataFact AS Data_Facturare, CURRENT_DATE - DataFact AS Timp_Scurs
FROM FACTUR
Rezultatul scderii a dou date calendaristice contine numrul zile. n Oracle, avem nevoie
uneori de cteva Iunctii speciale, precum Iunctia MONTHS_BETWEEN care calculeaz numrul
lunilor cuprinse ntre dou date calendaristice:
SELECT NrFact, DataFact, TRUNC(MONTHS_BETWEEN(TRUNC(SYSDATE), DataFact),0)
AS Luni_Scurse, ADD_MONTHS(TRUNC(SYSDATE), -
TRUNC(MONTHS_BETWEEN(TRUNC(SYSDATE), DataFact),0))
- DataFact AS Zile_Scurse
FROM FACTUR
6.2.3 Op(iunea ORDER BY
Una din caracteristicile modelului relational este c nici ordinea atributelor, nici ordinea
liniilor n relatii nu prezint important din punctul de vedere al continutului inIormational. n
practic, ns, Iorma de prezentare a rezultatelor interogrii este important. Spre exemplu, o list a
localittilor este cu mult mai de Iolos dec se prezint n ordine alIabetic. Ordonarea liniilor n
rezultatul unei interogri este posibil prin clauza ORDER BY.
S se obtin lista localittilor in ordine alfabetic.
SELECT DSTNCT loc FROM coduri_postale ORDER BY Loc
Rezultatul se prezint ca n Iigura 6.3.

Figura 6.3 Localittile ordonate alfabetic
126 Baze de date
Aranjarea se Iace implicit cresctor (ASC). Prin optiunea DESC, ordinea prezentrii se inverseaz. n
plus, se pot speciIica mai multe coloane care s serveasc drept criterii suplimentare de ordonare. La
valori egale ale primului atribut, intr n actiune criteriul de 'balotaj care este al doilea atribut etc.

S se obtin, in ordinea descresctoare a indicativului fudetelor, lista localittilor in ordinea
cresctoare a denumirii.
SELECT Jud, Loc, CodPost FROM coduri_postale ORDER BY Jud DESC, Loc ASC
Rezultatul este cel din Iigura 6.4. Ultimul indicativ de judet (e vorba de ordine alIabetic) din tabela
CODURIPOSTALE este VS (pentru Vaslui), deci primele localitti aIisate vor Ii din acest judet; prin
urmare, prima linie a rezultatului se reIer la municipiul Brlad, iar a doua la municipiul Vaslui.

Figura 6.4. Dou criterii de ordonare
6.2.4 Operatorii BETWEEN, LIKE, IN
Pentru Iormularea predicatului de selectie, SQL permite utilizarea, pe lng "clasicii" ~, , ,
, , , si a altor operatori, dintre care ne vom opri la: BETWEEN (ntre, cuprins ntre), LIKE (ca si, la
Iel ca), IN (n), la care se adaug IS NULL ce va Ii prezentat n paragraIul 6.5.

Operatorul BETWEEN este util pentru deIinire intervalelor de valori. Ne rentoarcem n
capitolul 2 la exemplul 3 (Care sunt facturile emise in perioada 2-5 august 2005 ?) Pe lng solutia
Iormulat anterior n acest capitol, vom prezenta noi variante PostgreSQL si Oracle.
Solutie PostgreSQL vizualizare rezultat (pgAdmin) - Iigura 6.5.
SELECT * FROM FACTUR
WHERE DataFact BETWEEN '2005-08-02' AND '2005-08-05'

Figura 6.5. Operator BETWEEN re:ultat PostgreSQL
Solutia Oracle rezultat Iigura 6.6. SpeciIicarea constantelor de tip dat calendaristic Iac
necesar n Oracle Iunctia TODATE.
SELECT * FROM FACTUR
WHERE DataFact BETWEEN TO_DATE('02/08/2005','DD/MM/YYYY')
AND TO_DATE('05/08/2005','DD/MM/YYYY') ;
FEAA nfoEc + CG - 2006/2007 127

Figura 6.6. Operator BETWEEN re:ultat Oracle (SQL*Plus)
S se obtin, in ordinea fudetelor, lista localittilor cu indicativul fudetului cuprins intre IS
(Iai) i TM (Timi).
SELECT Jud, Loc, CodPost FROM coduri_postale WHERE Jud BETWEEN 'S' AND 'TM'
ORDER BY Jud, Loc

Operatorul LIKE este util cnd se doreste obtinerea unor inIormatii din baz, suntem n
postura, oarecum ingrat, de a nu sti cu exactitate cum se numeste un client sau un produs, sau, pur si
simplu, unei persoane i cunoastem numai unul dintre prenume etc. Sunt numai cteva situatii pentru
rezovarea crora a Iost gndit operatorul LIKE. Operatorul LIKE permite compararea unui atribut
(expresii) cu un literal utiliznd o 'masc construit cu ajutorul speciIicatorilor multipli si .
Simbolurile procent si liniutdefos (underscore, diIerit de cratim sau liniuta-de-unire) sunt
denumite si fokeri. Procentul substituie un sir de lungime variabil, 0 - n caractere, n timp ce liniuta
un singur caracter.

Care din firmele-client sunt societti cu rspundere limitat (SRL-uri) ?
ntruct, n tabela CLIENTI, denumirea Iiecrui client se termin cu Iorma sa de societate (SA, SRL
etc.), se poate redacta consultarea:
SELECT * FROM CLENT WHERE DenCl LKE '%SRL'
Rezultatul se prezint ca n Iigura 6.7.

Figura 6.7. Clientii - SRLuri
Care dintre clienti au numele (fr forma de societate i spatiul dinainte) din 8 caractere i
sunt societi pe actiuni ?
SELECT * FROM CLENT WHERE DenCl LKE '________ SA'
Cele sapte liniute (nu se observ, dar sunt sapte), plus spatiul care le urmeaz, nu au eIect vizibil/im-
presionant pentru baza noastr de date, deoarece n capitolul 1, lenes Iiind, am denumit toti clientii o
de manier simplist - Client 1 SRL, Client 2 SA etc. Dac am avea mai multi clienti (sau mcar un
'Client 10 SA), atunci interogarea ar avea cu totul alt Iarmec.

Ce persoane au numele ce contine litera S pe a treia po:itie ?
SELECT * FROM PERSOANE WHERE Nume LKE '__s%'
128 Baze de date

Figura 6.8. Persoane cu litera 's` pe a treia po:itie a numelui
Rezultatul este vizualizat n Iigura 6.8. Atentie, dac exist persoane al cror nume are litera S
majuscul pe a treia pozitie, acestea nu sunt extrase n rezultat ! n asemenea situatii, solutia de mai jos
este ceva mai sigur:
SELECT * FROM PERSOANE WHERE Nume LKE '__s%' OR Nume LKE '__S%'

In numele cror persoane apare, mcar o dat, litera S (indiferent de po:itie/po:itii) ?
SELECT * FROM PERSOANE WHERE Nume LKE '%s%' OR Nume LKE '%S%'

Figura 6.9. Persoane al cror nume contine litera S
Care sunt persoanele ce trebuie felicitate de Sfantul Ion ?
Fireste am Ii tentati s redactm varianta:
SELECT * FROM PERSOANE WHERE UPPER(Prenume) LKE '%ON%'
Functia UPPER Iace conversia valorilor atributului Prenume n majuscule. Rezultatul se vede cu
ochiul liber n Iigura 6.10.

Figura 6.10. Tentativ ratat de a extrage 'Sfintii Ioni`
Interogarea nu si-a atins tinta, deoarece, pe de o parte, nu au Iost extrase persoanele cu prenume ca
Ioan, Ioana, Ioanid, iar, pe de alt parte, au Iost eronat extrase si persoanele cu prenumele Caraion si
Simion. Prin urmare, cele trei litere - ION trebuie s Iie plasate la nceputul prenumelui. La acest
sablon se adaug si IOAN. Bun, dar dac pe omul nostru l cheam Marius Ion (are dou prenume) ?
Cele dou sabloane trebuie s se gseasc la nceputul Iiecrui cuvnt din atributul Prenume. Iar dac
avem n vedere c uneori cele dou prenume se despart prin cratim (Marius-Ion), rezult o mndrete
de interogare (rspunsul este prezentat n Iigura 6.11):
SELECT * FROM PERSOANE
WHERE UPPER(Prenume) LKE 'ON%' OR UPPER(Prenume) LKE 'OAN%'
OR UPPER(Prenume) LKE '% ON%' OR UPPER(Prenume) LKE '% OAN%'
OR UPPER(Prenume) LKE '%-ON%' OR UPPER(Prenume) LKE '%-OAN%'

Figura 6.11. Persoanele ce trebuie felicitate de Sf. Ion
FEAA nfoEc + CG - 2006/2007 129
Varianta Iunctioneaz n aceast Iorm deopotriv n PostgreSQL/Oracle. Desi rare, exist
cazuri cnd printre caracterele cutate n valorile unui atribut sir de caractere se gseste chiar unul
dintre cele dou sabloane, sau . Dac, spre exemplu, intereseaz toti clientii care contin simbolul
n numele lor (s-ar putea ca, la un moment dat, s avem n baz clienti de genul 'Procentul vesel
SRL). Solutia este:
SELECT * FROM CLENT WHERE DenCl LKE '%\%%' ESCAPE '\'
Datorit primului si ultimului simbol procent, pozitia caracterului cutat (n cazul nostru, chiar %) nu
prezint important: poate Ii prima, ultima sau oricare ntre prima si ultima. Rezultatul corect este
obtinut gratie unui caracter declarat prin clauza ESCAPE. Aceste este backslash-ul, dar poate Ii
oricare altul. Prin clauza ESCAPE s-a indicat SQL-ului c procentul ce urmeaz simbolului \ nu este
joker, ci are regim de caracter oarecare, ce trebuie cutat n tabel ca atare.

Operatorul IN se recomand atunci cnd se veriIic dac valoarea unui atribut este
ncadrabil ntr-o list de valori dat. n locul Iolosirii abundente a operatorului OR, este mai elegant
s se apeleze la serviciile operatorului IN. Format general: expresie1 N (expresie2, expresie3, ...)
Rezultatul evalurii unui predicat ce contine acest operator va Ii adevrat dac valoarea expresiei1
este egal cu (cel putin) una din valorile: expresie2, expresie3, ....

Care sunt localittile din fudetele Iai (IS), Jaslui (JS) i Timi (TM) ?
Fr operatorul IN:
SELECT DSTNCT loc, jud FROM coduri_postale
WHERE Jud = 'S' OR Jud = 'VS' OR Jud = 'TM' ORDER BY Jud, Loc

Cu operatorul IN:
SELECT DSTNCT loc, jud FROM coduri_postale
WHERE Jud N ('S', 'VS', 'TM') ORDER BY Jud, Loc

Care sunt facturile intocmite pe 1, 3 i 7 august 2005 ?
SELECT * FROM facturi WHERE DataFact N ('01/08/2005', '03/08/2005', '07/08/2005')
Fireste, sintaxa trebuie adaptat n Iunctie de Ielul n care Iiecare SGBD lucreaz cu atribute si
constante de tip dat calendaristic.
6.2.5 Theta yi echi-jonc(iunea
Dintre tipurile de jonctiune prezentate n capitolul 5, vom insista asupra theta-jonctiunii si
echi-jonctiunii. SQL nu prezint clauze sau operatori speciali pentru jonctiune, ns asa cum am vzut,
o jonctiune este o combinatie de produs carte:ian si selectie. n consecint, pentru theta-jonctionarea
relatiilor R1 si R2 din exemplu 10 al algebrei relationale (Iigura 5.16) se scrie:
SELECT * FROM R1, R2 WHERE R1.A >= R2.E
iar pentru echi-jonctionarea din exemplul 11 (Iigura 2.18):
SELECT * FROM R1, R2 WHERE R1.A = R2.E

Jonctiunea natural poate Ii realizat numai prin speciIicarea numelor atributelor n clauza
SELECT a Irazei de interogare. n standardul SQL92 si n implementrile SQL ale multor SGBD-uri
130 Baze de date
se poate Iolosi o variant mai elegant, tinnd seama c tot ce nseamn theta si echi jonctiune
reprezint, pentru SQL, INNER JOIN (jonctiune intern). Prin urmare, cele dou solutii de mai sus pot
Ii rescrise dup cum urmeaz:
SELECT * FROM R1 NNER JON R2 ON R1.A >= R2.E
respectiv
SELECT * FROM R1 NNER JON R2 ON R1.A >= R2.E

Relum, pentru comparatie, exemple din algebra relational. Exemplul 13 (S se obtin,
pentru fiecare localitate. codul potal, denumirea, indicativul i denumirea fudetului i regiunea din
care face parte)
Varianta 1 (SQL-1):
SELECT CodPost, Loc, coduri_postale.Jud, Judet, Regiune
FROM coduri_postale, judete
WHERE coduri_postale.Jud = judete.Jud
Varianta 2 (SQL-2):
SELECT CodPost, Loc, coduri_postale.Jud, Judet, Regiune
FROM coduri_postale NNER JON judete ON coduri_postale.Jud = judete.Jud
Numai atributul Jud a Iost preIixat de numele tabelei din care provine. PreIixarea este
obligatorie atunci cnd cmpul exist n dou sau mai multe din tabelele enumerate n clauza FROM.

Exemplul 14 (Care sunt localittile din Banat ?)
Varianta SQL1:
SELECT CodPost, Loc, coduri_postale.Jud, Judet, Regiune FROM coduri_postale, judete
WHERE coduri_postale.Jud = judete.Jud AND Regiune='Banat'
n clauza WHERE, predicatului de selectie pentru realizarea jonctiunii i s-a adugat secventa de test a
regiunii.
Varianta SQL2:
SELECT CodPost, Loc, coduri_postale.Jud, Judet, Regiune
FROM coduri_postale NNER JON judete ON coduri_postale.Jud = judete.Jud
WHERE Regiune='Banat'
Avantajul celei de-a doua variante tine de separarea conditiei ce tine de regiune de conditia legat de
jonctiunea propriu-zis.

Exemplul 15 (In ce :ile s-a vandut produsul cu denumirea 'Produs 1` ?)
SELECT DSTNCT DataFact
FROM PRODUSE
NNER JON LNFACT ON PRODUSE.CodPr = LNFACT.CodPr
NNER JON FACTUR ON LNFACT.Nrfact = FACTUR.NrFact
WHERE DenPr = 'Produs 1'
De notat Iolosirea clauzei DISTINCT pentru eliminarea eventualelor dubluri.

Exemplul 16 (In ce fudete s-a vandut produsul cu denumirea 'Produs 1` in perioada 3-5
august 2005 ?)
SELECT DSTNCT Judet
FEAA nfoEc + CG - 2006/2007 131
FROM PRODUSE
NNER JON LNFACT ON PRODUSE.CodPr = LNFACT.CodPr
NNER JON FACTUR ON LNFACT.Nrfact = FACTUR.NrFact
NNER JON CLENT ON FACTUR.CodCl = CLENT.CodCl
NNER JON CODUR_POSTALE ON CLENT.CodPost = CODUR_POSTALE.CodPost
NNER JON JUDETE ON CODUR_POSTALE.Jud = JUDETE.Jud
WHERE DenPr = 'Produs 1' AND DataFact BETWEEN '03-08-2005' AND '05-08-2005'
Si n acest exemplu este recomandat Iolosirea clauzei DISTINCT.

Exemplul 17 (In ce :ile s-au vandut i produsul cu denumirea 'Produs 1` i cel cu denumirea
'Produs 2` ?)
SELECT DSTNCT DataFact
FROM PRODUSE NNER JON LNFACT ON PRODUSE.CodPr = LNFACT.CodPr
NNER JON FACTUR ON LNFACT.Nrfact = FACTUR.NrFact
WHERE DenPr = 'Produs 1'
NTERSECT
SELECT DSTNCT DataFact
FROM PRODUSE NNER JON LNFACT ON PRODUSE.CodPr = LNFACT.CodPr
NNER JON FACTUR ON LNFACT.Nrfact = FACTUR.NrFact
WHERE DenPr = 'Produs 2'
Ar mai Ii o solutie bazat pe jonctiunea tabelei cu ea-nssi, lucru pe care l vom discuta n
paragraIul urmtor.
6.2.6 Sinonime locale yi jonc(iunea unei tabele cu ea nsyi
Lucrul cu nume lungi de tabele si atribute are marele avantaj al lejerittii la citire si ntelegii
rapide a logicii de derulare a interogrii. n schimb, suIicienti inIormaticieni nu agreaz risipa de
caractere (si, implicit, de timp si nervi) presupuse de redactrile 'logoreice. Ambele prti au dreptate
n oarecare msur (sesizati sindromul rabinului !). AstIel nct n Irazele SELECT tabelelor li se pot
asocia sinonime sau aliasuri mai scurte. Pentru ilustrare, ultima interogare se poate rescrie astIel:
SELECT DSTNCT DataFact
FROM produse P NNER JON liniifact LF ON P.CodPr = LF.CodPr
NNER JON facturi F ON LF.Nrfact = F.NrFact
WHERE DenPr = 'Produs 1'
NTERSECT
SELECT DSTNCT DataFact
FROM produse P NNER JON liniifact LF ON P.CodPr = LF.CodPr
NNER JON facturi F ON LF.Nrfact = F.NrFact
WHERE DenPr = 'Produs 2'
Tabelei PRODUSE i s-a asociat sinonimul P, LINIIFACT LF, iar pentru FACTURI F. Sinonimele
preIixeaz (cnd este necesar) numele atributelor n clauzele SELECT si WHERE (eventual ORDER
BY, GROUP BY).
Exist situatii n care utilizarea sinonimelor n-are cu nimic de-a Iace cu lenea/comoditatea sau
depresiile nervoase. n aIara interogrilor corelate pe care le vom discuta ntr-un capitol viitor, o
operatiune n care musai trebuie Iolosite sinonimele este fonctionarea tabelei cu ea-insi sau, cum
spunem noi, moldovenii, cu dansa-insi.
132 Baze de date

Revenim la exemplul 19 din algebra relational: Ce facturi au fost emise in aceeai :i cu
factura 1120 ?
Este, probabil, cel mai bun exemplu pentru prezentarea subconsultrilor; noi ns ne vom servi acum
de acest caz spre a introduce noul tip de jonctiune.
SELECT F2.NrFact
FROM FACTUR F1 NNER JON FACTUR F2 ON F1.DataFact = F2.DataFact
WHERE F1.NrFact=1120
Ca piatr de incercare, revenim la a doua solutie formulat in algebra relational la
exemplul 17 (n ce zile s-au vndut si produsul cu denumirea 'Produs 1 si cel cu denumirea 'Produs
2 ?) .Jonctionm o instant obtinut prin jonctiunea PRODUSE-LINIIFACT-FACTURI (n care
DenPr `Produs 1`) cu o alt instant a aceleasi combinatii (n care DenPr `Produs 2`).
SELECT DSTNCT F1.DataFact
FROM PRODUSE P1 NNER JON LNFACT LF1 ON P1.CodPr = LF1.CodPr
NNER JON FACTUR F1 ON LF1.NrFact = F1.NrFact
NNER JON FACTUR F2 ON F1.DataFact=F2.DataFact
NNER JON LNFACT LF2 ON LF2.NrFact = F2.NrFact
NNER JON PRODUSE P2 ON LF2.CodPr = P2.CodPr
WHERE P1.DenPr = 'Produs 1' AND P2.DenPr = 'Produs 2'
6.3 FUNCTII-AGREGAT: COUNT, SUM, AVG, MIN, MAX
Formatul general al unei Iraze SELECT ce contine Iunctii agregat este:
SELECT func[ia-predefinit1, ... , func[ia-predefinitN
FROM list-tabele WHERE condi[ii.
n lipsa optiunii GROUP BY (vezi paragraIul urmtor), dac n clauza SELECT este prezent
o Iunctie agregat, rezultatul va contine o singur linie.

Func(ia COUNTcontorizeaz valorile nenule ale unei coloane sau numrul de linii dintr-un
rezultat al unei interogri, altIel spus, n rezultatul unei consultri, COUNT numr cte valori diIerite
de NULL are o coloan speciIicat sau cte linii sunt.

Cati clienti are firma ?
SELECT COUNT (*) AS NrClienti FROM CLENT
Prezenta asteriscului ca argument al Iunctiei COUNT are ca eIect numrarea liniilor tabelei CLIENTI.
Rezultatul este prezentat n Iigura 6.12.

Figura 6.12. Cati clienti are firma ?
Tabela CLIENTI are cheie primar atributul CodCl care nu poate avea valori nule; de aceea,
la Iel corect este si solutia:
SELECT COUNT (CodCl) AS NrClienti FROM CLENT

FEAA nfoEc + CG - 2006/2007 133
Cate linii are produsul carte:ian al tabelelor FACTURI i LINIIFACT ?
SELECT COUNT(*) FROM FACTUR, LNFACT

Pentru cati clienti se cunoate adresa ?
SELECT COUNT (Adresa) AS NrClienti FROM CLENT
Rezultatul, 5, putea Ii obtinut si ceva mai complicat, Iolosind n clauza WHERE operatorul S NULL
pe care-l tot amnm pentru capitolul urmtor.

Cate facturi au fost emise pe 7 august 2005 ?
SELECT COUNT(NrFact) AS NrFacturi FROM FACTUR WHERE DataFact = '07/08/2005'

Cate facturi au fost emise clientilor din fudetul Jaslui ?
SELECT COUNT(NrFact) AS NrFacturi
FROM FACTUR F, CLENT C, CODUR_POSTALE L, JUDETE J
WHERE F.CodCl = C.CodCl AND C.CodPost=L.CodPost AND L.Jud = J.Jud AND Judet='Vaslui'

Cate localitti sunt preluate in ba:a de date ?
Tabela CODURIPOSTALE poate contine mai multe linii pentru acelasi orase, deoarece orasele mai
mare prezint mai multe coduri postale:
SELECT COUNT(Loc || Jud) AS NrLocalit FROM CODUR_POSTALE
Necazul e c rezultatul obtinut, poate Ii incorect, deoarece Iunctia COUNT numr toate valorile
nenule. Exist ns o clauz prin care o valoare s se ia n calcul o singur dat: DSTNCT. Rezultatul
corect presupune varianta:
SELECT COUNT(DSTNCT Loc || Jud) AS NrLocalit FROM CODUR_POSTALE

Func(ia SUM este una dintre cele mai utilizate Iunctii n aplicatiile economice, deoarece
datele Iinanciar-contabile si cele ale evidentei tehnico-operative sunt preponderent cantitative.
Probabil c prea multe explicatii teoretice despre modul n care opereaz aceast Iunctie sunt inutile,
asa nct vom trece n revist cteva exemple.

Care este valoarea fr TJA a facturii 1111 ?
SELECT SUM(Cantitate * PretUnit) AS ValFaraTVA FROM LNFACT WHERE NrFact = 1111

Care este valoarea fr TJA a facturiilor emisei pe 7 august 2000 ?
SELECT SUM(Cantitate * PretUnit) AS ValFaraTVA_17aug2000
FROM LNFACT LF, FACTUR F
WHERE LF.NrFact = F.NrFact AND DataFact = '07/08/2000'

Care sunt cele trei valori. fr TJA, TJA i total ale facturii 1111 ?
SELECT SUM(Cantitate * PretUnit) AS ValFaraTVA,
SUM(Cantitate * PretUnit * ProcTVA) AS TVA,
SUM(Cantitate * PretUnit + Cantitate * PretUnit * ProcTVA) AS ValTotala
FROM LNFACT LF, PRODUSE P WHERE LF.CodPr = p.CodPr AND NrFact = 1111
n conditiile actuale n care procentul TVA este unic - 19 este corect si varianta:
134 Baze de date
SELECT SUM(Cantitate * PretUnit) AS ValFaraTVA,
SUM(Cantitate * PretUnit * .19) AS TVA,
SUM(Cantitate * PretUnit + Cantitate * PretUnit * .19) AS ValTotala
FROM LNFACT WHERE NrFact = 1111
Solutia propus este una atemporal, altIel spus, a-guvernamental si a-relaxare Iiscal. O vizualizare
mai elegant a rezultatului poate Ii realizat n Oracle/PostgreSQL utiliznd interogarea urmtoare:
SELECT 'Pentru factura 1111, valoarea fara TVA este '|| SUM(Cantitate * PretUnit)||
', TVA este '||SUM(Cantitate * PretUnit * ProcTVA)|| ', iar valoarea totala este '||
SUM(Cantitate * PretUnit + Cantitate * PretUnit * ProcTVA) AS Rezultat
FROM LNFACT, PRODUSE
WHERE LNFACT.CodPr=PRODUSE.CodPr AND NrFact = 1111

La cat se situea: cifra van:rilor pe data de 7 august 2005 ?
SELECT '7 aug. 2005' AS Data, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM LNFACT LF, PRODUSE P, FACTUR F
WHERE LF.CodPr = P.CodPr AND LF.NrFact = F.NrFact AND DataFact = DATE'2005-08-07'

Care este valoarea van:rilor pentru 'Client 1 SRL` ?
SELECT 'Client 1 SRL' AS Client, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM LNFACT LF, PRODUSE P, FACTUR F, CLENT C
WHERE LF.CodPr = P.CodPr AND LF.NrFact = F.NrFact AND F.CodCl = C.CodCl
AND DenCl = 'Client 1 SRL'

Care este valoarea medie a pretului (inclusiv TJA) la care a fost vandut 'Produs 1` ?
Nu, n-am trecut la Iunctia AVG Ir s v Ii anuntat din timp. Solutia se bazeaz pe raportul dintre
suma valorilor si cantitatea nsumat pentru acest produs.
SELECT SUM(Cantitate*PretUnit*(1+ProcTVA)) / SUM(Cantitate) AS PretUnitMediu
FROM LNFACT LF, PRODUSE P, FACTUR F
WHERE LF.CodPr = P.CodPr AND LF.NrFact = F.NrFact AND DenPr = 'Produs 1'

Func(ia AVG calculeaz media aritmetic a unei coloane ntr-o tabel oarecare, prin divizarea
sumei valorilor coloanei respective la numrul de valori nenule ale acesteia.

Care este valoarea (fr TJA) medie a produselor vandute in factura 1111 ?
SELECT 'Val. medie (fara TVA) a prod. din fact. 1111' AS Explicatii,
AVG(Cantitate * PretUnit) AS ValMedie
FROM LNFACT WHERE NrFact = 1111

Care este media valorilor (cu TJA) la care a fost vandut 'Produs 1` ?
SELECT 'Val. medie a vinzarilor prod. Produs 1' AS Explicatii,
ROUND(AVG(Cantitate*PretUnit*(1+ProcTVA)),2) ValTotMedie
FROM LNFACT LF, PRODUSE P, FACTUR F
WHERE LF.CodPr = P.CodPr AND LF.NrFact = F.NrFact AND DenPr = 'Produs 1'
Adesea, prin aplicarea Iunctiei AVG, sau prin Iormularea unor expresii ce contin rapoarte ntre
atribute/constante, se obtin rezultate cu numeroase zecimale. n cazul de Iat, pentru prentmpinarea
FEAA nfoEc + CG - 2006/2007 135
acestui disconIort vizual si intelectual, a Iost preIerat Iunctia ROUND ce rotunjeste media la dou
zecimale.

Func(iile MAX yi MIN sunt deosebit de utile n diverse tipuri de analiz, determinnd
valoarea maxim, respectiv minim, pentru o coloan (atribut). Se pot Iolosi si pentru atribute de tip
sir de caractere, caz n care elementul de comparatie este codul ASCII al caracterelor.

Care este localitatea cu ultima denumire, in ordine alfabetic ?
SELECT MAX(Loc) AS UltimaLoc FROM CODUR_POSTALE

Care este primul client i ultimul client (in ordinea numelui) din fudetul Iasi ?
SELECT MN(DenCl) AS Primul_Client, MAX(DenCl) AS Ultimul_Client
FROM CLENT C, CODUR_POSTALE L, JUDETE J
WHERE C.CodPost = L.CodPost AND L.Jud = J.Jud AND Judet = 'asi'

Care este cel mai mare pret unitar (fr TJA) la care a fost vandut Produs 1 ?
SELECT MAX(PretUnit) FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr = P.CodPr AND DenPr = 'Produs 1'

Din pcate, dac dorim s aIlm si n ce Iactur produsul are pretul unitar maxim, solutia:
SELECT MAX(PretUnit), NrFact
FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr = P.CodPr AND DenPr = 'Produs 1'
nu Iunctioneaz ! Pn la subconsultrile din capitolul viitor ncercm o solutie gen 'crpeal,
concatennd pretul cu numrul Iacturii:
SELECT 'Pret maxim='||MAX(TO_CHAR(LF.PretUnit,'99999999') || ', apare in fact.'||NrFact)
AS Produs1
FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr = P.CodPr AND DenPr = 'Produs 1'

Interogarea Iunctioneaz, cel putin dac ne lum dup rezultatul din Iigura 6.13, asa c n-are de ce s
ne Iie jen de improvizatie. Rezultatul este incomplet, ns, atunci cnd pretul maxim apare n dou
sau mai multe Iacturi, deoarece interogarea de mai sus extrage numai una dintre Iacturi (cea cu
numrul cel mai mare).


Figura 6.13. Pretul maxim pentru Produs 1 i factura in care apare acest pret

Care este cel mai mare i cel mai mic pret unitar (fr TJA) la care a fost vandut Produs 2 ?
SELECT MAX( 'Pret maxim=' || CAST (PretUnit AS CHAR(15)) || ', factura' ||
CAST (NrFact AS CHAR(10))) AS Max_Pret_Produs_2,
MN( 'Pret minim=' || CAST (PretUnit AS CHAR(15))
136 Baze de date
|| ', factura' || CAST (NrFact AS CHAR(10))) AS Min_Pret_Produs_2
FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr = P.CodPr AND DenPr = 'Produs 2'

Care sunt cele mai mari dou preturi unitare (fr TJA) la care a fost vandut Produs 2 ?
SELECT 'Produs 2: '|| MAX('Primul PU: '||TO_CHAR(LF1.PretUnit,'99999999999')||', al doilea PU: '||
TO_CHAR(LF2.PretUnit,'99999999999')|| ' - factura primului:'||LF1.NrFact||
', factura-al doilea:'||LF2.Nrfact) AS "Cele mai mari doua PretUnit"
FROM LNFACT LF1, LNFACT LF2, PRODUSE P
WHERE LF1.CodPr = P.CodPr AND DenPr = 'Produs 2' AND LF1.CodPr = LF2.CodPr
AND LF1.PretUnit > LF2.PretUnit
6.4 GRUPAREA TUPLURILOR. GROUP BY $I HAVING
Clauza GROUP BY Iormeaz grupe (grupuri) de tupluri ale unei relatii, pe baza valorilor
comune ale unui atribut. n Irazele SELECT Iormulate pn n acest paragraI, prin intermediul
WHERE au Iost selectate tupluri ale tabelei. Prin asocierea unei clauze HAVING la GROUP BY este
posibil selectarea anumitor grupuri de tupluri ce ndeplinesc un criteriu, criteriu valabil numai la
nivel de grup (nu si la nivel de linie).

Clauza GROUP BY
Rezultatul unei Iraze SELECT ce contine aceast clauz se obtine prin regruparea tuturor
liniilor din tabelele enumerate n FROM, extrgndu-se cte o aparitie pentru Iiecare valoare distinct
a coloanei/grupului de coloane. Formatul general este: SELECT coloan 1, coloan 2, ....,
coloan m FROM tabel GROUP BY coloan-de-regrupare

Care este valoarea fr TJA a fiecrei facturi emise ?
SELECT NrFact, SUM(Cantitate*PretUnit) as ValFaraTVA
FROM LNFACT
GROUP BY NrFact
Rezultatul se obtine prin urmtoarea succesiune de operatii:
1. Se ordoneaz liniile tabelel LINIIFACT dup atributul de grupare NrFact.
2. Se constituie un grup pentru Iiecare valoare distinct a NrFact.
3. Se execut Iunctia SUM(Cantitate*PretUnit) n cadrul Iiecrui grup.
4. Se obtine rezultatul al crui numr de linii coincide cu valorile distincte ale NrFact.

Care este valoarea total a van:rilor pentru fiecare :i in care s-au emis facturi ?
SELECT DataFact, TRUNC(SUM(Cantitate * PretUnit * (1+ProcTVA)),0) AS ValTotala
FROM LNFACT LF, PRODUSE P, FACTUR F WHERE LF.CodPr = P.CodPr
AND LF.NrFact = F.NrFact
GROUP BY DataFact
FEAA nfoEc + CG - 2006/2007 137

Figura 6.14. Jan:rile :ilnice
Care sunt numrul de facturi i valoarea van:rilor pentru fiecare client ?
SELECT DenCl, COUNT(DSTNCT F.NrFact) AS NrFacturilor,
TRUNC(SUM(Cantitate * PretUnit * (1+ProcTVA)),0) AS ValTotala
FROM LNFACT LF, PRODUSE P, FACTUR F, CLENT C
WHERE LF.CodPr = P.CodPr AND LF.NrFact = F.NrFact AND F.CodCl = C.CodCl
GROUP BY DenCl
Analiznd rezultatul din Iigura 6.15 si comparndu-l cu tabela FACTURI se observ c al cincilea
client ar trebui s aib cinci Iacturi, nu trei. Aceast anomalie aparent se datoreaz Iaptului c
Iacturile 1122 si 2122 nu au nici o linie corespondent n LINIIFACT, astIel nct aceste Iacturi 'cad
la jonctiune.

Figura 6.15. Numrul facturilor i valoarea van:rilor pe clienti
Care sunt van:rile, cantitativ i valoric, pentru fiecare produs ?
SELECT DenPr, SUM(Cantitate) AS Cantitativ, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Valoric
FROM LNFACT LF, PRODUSE P, FACTUR F
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact GROUP BY DenPr
Rezultatul vezi Iigura 6.16.

Figura 6.16. Jan:rile cantitative i valorice pe produse
O inIormatie esential care lipseste din Iigura 6.16 este unitatea de msur, Ir de care nu
putem Ii siguri dac totatul cantitativ se reIer la cutii, sticle, pachete, baxuri etc. Din pcate, varianta:
SELECT DenPr, UM, SUM(Cantitate) AS Cantitativ, SUM(Cantitate*PretUnit*(1+ProcTVA)) AS Valoric
FROM LNFACT LF, PRODUSE P, FACTUR F
138 Baze de date
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact
GROUP BY DenPr
nu Iunctioneaz, deoarece UM apare separat de atributul de grupare, neIiind inclus n Iunctia/Iunctiile
care se execut la nivelul grupului. Exist ns un remediu simplu: includerea n clauza de grupare si a
atributului UM. Altminteri, gruparea este identic, deoarece DenPr este cheie candidat a tabelei
PRODUSE, lucru observabil n Iigura 6.17.
SELECT DenPr, UM, SUM(Cantitate) AS Cantitativ, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Valoric
FROM LNFACT LF, PRODUSE P, FACTUR F
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact GROUP BY DenPr, UM

Figura 6.17. Includerea in re:ultat a unittii de msur
Care este situatia van:rilor pe clienti i :ile ?
Intereseaz valoarea Iacturilor emise pe clienti, si, pentru Iiecare client, cuantumul zilnic al acestora.
Este momentul s Iolosim o veritabil grupare dup dou atribute (spre deosebire de exemplul
precendent, cnd gruparea celor dou atribute a Iost mai mult de nevoie, dect de voie).
SELECT DenCl AS DenumireClient, DataFact AS Data,
SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM LNFACT LF, PRODUSE P, FACTUR F, CLENT C
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact AND F.CodCl = C.CodCl
GROUP BY DenCl, DataFact


Figura 6.18. Jan:rile :ilnice pentru fiecare client
FEAA nfoEc + CG - 2006/2007 139
Care este situatia van:rilor fiecrui produs pe fiecare regiune ?
SELECT DenPr AS Produs, Regiune, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM LNFACT LF, PRODUSE P, FACTUR F, CLENT C, CODUR_POSTALE L, JUDETE J
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact AND F.CodCl=C.CodCl
AND C.CodPost=L.CodPost AND L.Jud=J.Jud
GROUP BY DenPr, Regiune

Figura 6.19. Jan:rile pe regiuni ale fiecrui produs
S se obtin situatia van:rilor pe clienti i :ile, afiandu-se cate un subtotal la nivel de client
i un total general.
Ideea improvizatiei este s 'alipim, pentru Iiecare client, dup vnzrile zilnice, cte o linie care s
contin subtotalul:
SELECT DenCl AS DenumireClient, TO_CHAR(DataFact,'DD-MM-YYYY') AS Data,
TO_CHAR(SUM(Cantitate * PretUnit * (1+ProcTVA)), '999999999999') AS Vinzari
FROM LNFACT LF, PRODUSE P, FACTUR F, CLENT C
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact AND F.CodCl=C.CodCl
GROUP BY DenCl, DataFact
UNON
SELECT DenCl ||' - Subtotal' , NULL,
TO_CHAR(SUM(Cantitate * PretUnit * (1+ProcTVA)), '999999999999')
FROM LNFACT LF, PRODUSE P, FACTUR F, CLENT C
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact AND F.CodCl=C.CodCl
GROUP BY DenCl
UNON
SELECT CHR(255)||'TOTAL GENERAL' , NULL,
TO_CHAR(SUM(Cantitate * PretUnit * (1+ProcTVA)),
'999999999999')
FROM LNFACT LF, PRODUSE P
WHERE P.CodPr = LF.CodPr

Clauza HAVING
Cea mai simpl deIinitie: clauza HAVING este WHERE-ul ce opereaz la nivel de grupuri.
Dac WHERE actioneaz la nivel de tuplu, selectnd acele linii care ndeplinesc o conditie speciIicat,
HAVING permite speciIicarea unor conditii de selectie care se aplic grupurilor de linii create prin
clauza GROUP BY. Din rezultat sunt eliminate toate grupurile care nu satisIac conditia speciIicat.
Formatul general este:
SELECT coloan 1, coloan 2, .... , coloan m
FROM tabel
GROUP BY coloan-de-regrupare
HAVNG caracteristic-de-grup
140 Baze de date

Care sunt :ilele in care s-au intocmit cel putin trei facturi ?
SELECT DataFact, COUNT(*) AS Nr_Facturi FROM FACTUR
GROUP BY DataFact HAVNG COUNT(*) >= 3

Figura 6.20. Zilele in care s-au intocmit trei sau mai multe facturi
Care sunt clientii pentru care van:rile depesc 5 milioane (lei) ?
SELECT DenCl AS Client,
SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM LNFACT LF, PRODUSE P, FACTUR F, CLENT C
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact
AND F.CodCl=C.CodCl
GROUP BY DenCl
HAVNG SUM(Cantitate * PretUnit * (1+ProcTVA)) > 5000000

In ce :ilele s-au emis mai multe facturi decat pe 2 august 2005 ?
SELECT F1.DataFact AS Zi1, COUNT(DSTNCT F1.NrFact) AS Nr_Facturilor1,
F2.DataFact AS Zi2, COUNT(DSTNCT F2.NrFact) AS Nr_Facturilor2
FROM FACTUR F1, FACTUR F2
WHERE F2.DataFact = TO_DATE('02/08/2005', 'DD/MM/YYYY')
GROUP BY F1.DataFact, F2.DataFact
HAVNG COUNT(DSTNCT F1.NrFact) > COUNT(DSTNCT F2.NrFact)
S zbovim asupra logicii acestei interogri. Mai nti se eIectueaz produsul cartezian pentru dou
instante (F1 si F2) ale tabelei FACTURI, eliminndu-se pentru F2 linile n care data este alta dect 2
august 2005, adic:
SELECT *
FROM FACTUR F1, FACTUR F2
WHERE F2.DataFact = TO_DATE('02/08/2005', 'DD/MM/YYYY')
ORDER BY F1.DataFact, F2.DataFact
n pasul urmtor, se constituie grupuri pentru Iiecare combinatie de valori (F1.DataFact, F2.DataFact).
F2.DataFact are aceeasi valoare, 02/08/2005, prin urmare grupurile se constituie n Iunctie de
F1.DataFact. Pentru ca Iunctia COUNT s calculeze corect numrul Iacturilor dintr-o zi, este necesar
clauza DISTINCT.

Diviziunea rela(ional
Multe situatii ce reclam diviziunea relational pot Ii solutionate elegant cu ajutorul clauzelor
GROUP BY si HAVING. n exemplul urmtor este vorba de o intersectie 'simulat printr-un
mecanism apropiat de diviziune.

In ce :ile s-au vandut i produsul cu denumirea 'Produs 1` i cel cu denumirea 'Produs 2` ?
SELECT DSTNCT DataFact
FEAA nfoEc + CG - 2006/2007 141
FROM PRODUSE, LNFACT, FACTUR
WHERE PRODUSE.CodPr = LNFACT.CodPr AND LNFACT.Nrfact =FACTUR.NrFact AND
DenPr N ('Produs 1', 'Produs 2')
GROUP BY DataFact
HAVNG COUNT(DSTNCT LNFACT.CodPr) = 2
Pentru Iiecare grup asociat unei zile de vnzri se numr cte produse, dintre Produs 1 si Produs 2,
au Iost Iacturate. Functia COUNT() din clauza HAVING poate 'ntoarce maxim valoarea 2, caz n
care data respectiv se ncadreaz n zilele cutate.
Una din Iacilittile SQL tine de includerea n predicatul clauzei HAVING nu numai a
constantelor si/sau variabilelor, ci si a altor consultri (subconsultri). Dar despre aceast Iacilitate
vom vorbi ntr-un paragraI viitor.
6.5 VALORILOR NULE $I 1ONCTIUNI EXTERNE
6.5.1 Despre NULL-it(i n SQL
Valoarea NULL a Iost introdus n capitolul 2, la explicarea notiunilor modelului relational,
ca posibilitate de reprezentate a inIormatiilor. inexistente sau inaplicabile
56
. Raportul Interim 75-02-
09 naintat ANSI X3 (SPARC Study Group 1975) a delimitat 14 tipuri de date incomplete ce ar putea
aprea ca rezultate ale unor operatii sau valori ale atributelor, printre care: depsiri ale capacittii de
stocare, diviziune la zero, trunchierea sirurilor de caractere, ridicarea lui zero la puterea zero si alte
erori computationale, precum si valori necunoscute. La popularea bazei de date, unui client nu i se
cunostea codul Iiscal, unor clienti nu li se stia adresa sau teleIonul. Aceste trei atribute aveau, pe una
sau mai multe linii, valoarea NULL.

Pentru care dintre clienti nu se cunoate adresa ?
Solutia cvasi-general se bazeaz pe utilizarea operatorului IS NULL care extrage toate valorile NULL
pentru un atribut:
SELECT *
FROM CLENT
WHERE Adresa S NULL


Figura 6.21. Clientii ,fr adres`
Valoarea NULL nu se conIund cu valoarea 0 - pentru atributele numerice - sau cu valoarea
spatiu - pentru atributele de tip sir de caractere. Este important de notat c, n vederea identiIicrii
valorilor nule, operatorul are Iorma S NULL si nu =NULL. Prin executia Irazei SQL:
SELECT * FROM CLENT WHERE Adresa = NULL

56
Vezi i [Fotache00-2]
142 Baze de date
se va obtine o tabel cu 0 (zero) linii. Rezultatul evalurii Adresa = NULL va Ii ntotdeauna FALSE.
Logica operatorilor NOT, AND si OR este ilustrat n tabelul 6.1.

Tabel 6.1. Re:ultatele utili:rii operatorilor NOT, AND i AND
Aplicarea operatorului NOT unei condi[ii
NOT TRUE FALSE UNKNOWN
FALSE TRUE UNKNOWN

Combinarea a dou expresii utiliznd operatorul AND
AND TRUE FALSE UNKNOWN
TRUE TRUE FALSE UNKNOWN
FALSE FALSE FALSE FALSE
UNKNOWN UNKNOWN FALSE UNKNOWN

Combinarea a dou expresii utiliznd operatorul OR
OR TRUE FALSE UNKNOWN
TRUE TRUE TRUE TRUE
FALSE TRUE FALSE UNKNOWN
UNKNOWN TRUE UNKNOWN UNKNOWN

Desi baza de date prezentat este alctuit deja dintr-un numr considerabil de tabele si
atribute, introducem nc dou tabele cu scop colateral temei 'vnzri/ncasri acela de a gestiona o
parte din datele privind drepturile bnesti (salariu negociat si sporuri) ale angajatilor Iirmei. Prima se
numeste PERSONAL2 si contine date generale despre angajati: marc; nume si prenume; data
nasterii; compartiment; marca seIului (direct); salariu tariIar. A doua, SPORURI, evidentiaz sporurile
lunare primite de Iiecare angajat: sporul de vechime (SporVechime), sporul pentru orele lucrate
noaptea (SporNoapte), sporuri pentru conditii deosebite (SporCD) si sporuri diverse (AlteSpor).
Cu ajutorul valorii NULL se poate Iace diIerenta ntre angajatii pentru care nu s-a calculat
valoarea sporului pe luna curent (si care vor avea n cmpul corespunztor valoarea NULL) si cei
care nu au dreptul la un asemenea spor, adic valoarea este 0. n continuare este prezentat scriptul de
creare a celor dou tabele, iar n Iigurile 6.22 si 6.23 continuturile acestora.
Listing 6.1. Script de creare a tabelelor SPORURI i PERSONAL2
DROP TABLE sporuri ;
DROP TABLE personal2 ;

CREATE TABLE personal2 (
marca NUMERC(5) CONSTRANT pk_personal2 PRMARY KEY,
numepren VARCHAR(40),
datanast DATE,
compart VARCHAR(20),
marcasef NUMERC(5) CONSTRANT fk_personal2 REFERENCES personal2(marca),
saltarifar NUMERC(12,2) ) ;

CREATE TABLE sporuri (
an NUMERC(4),
luna NUMERC(2),
marca NUMERC(5) REFERENCES personal2 (marca),
sporvechime NUMERC(12,2),
FEAA nfoEc + CG - 2006/2007 143
spornoapte NUMERC(12,2),
sporcd NUMERC(12,2),
altespor NUMERC(12,2),
PRMARY KEY (an,luna,marca) ) ;
Datele din cele dou tabele pot Ii interpretate n maniera urmtoare: Iirma s-a nIiintat n aprilie 2005,
cnd avea numai trei angajati; La momentul curent (luna iulie 2005) sunt 10 angajati. Popularea celor
trei tabele este continut n listingul 6.2.
Listing 6.2. Script de populare a tabelelor SPORURI i PERSONAL2
DELETE FROM personal2 ;
NSERT NTO personal2 VALUES (1, 'ANGAJAT 1', '1962-07-01', 'DRECTUNE', NULL, 1600) ;
NSERT NTO personal2 VALUES (2, 'ANGAJAT 2', '1977-10-11', 'FNANCAR', 1, 1450) ;
NSERT NTO personal2 VALUES (3, 'ANGAJAT 3', '1962-08-02', 'MARKETNG', 1, 1450) ;
NSERT NTO personal2 VALUES (4, 'ANGAJAT 4', NULL, 'FNANCAR', 2, 1380) ;
NSERT NTO personal2 VALUES (5, 'ANGAJAT 5', '1965-04-30', 'FNANCAR', 2, 1420) ;
NSERT NTO personal2 VALUES (6, 'ANGAJAT 6', '1965-11-09', 'FNANCAR', 5, 1350) ;
NSERT NTO personal2 VALUES (7, 'ANGAJAT 7', NULL, 'FNANCAR', 5, 1280) ;
NSERT NTO personal2 VALUES (8, 'ANGAJAT 8', '1960-12-31', 'MARKETNG', 3, 1290) ;
NSERT NTO personal2 VALUES (9, 'ANGAJAT 9', '1976-02-28', 'MARKETNG', 3, 1410) ;
NSERT NTO personal2 VALUES (10, 'ANGAJAT 10', '1972-01-29', 'RESURSE UMANE', 1, 1370) ;

DELETE FROM sporuri ;
NSERT NTO sporuri VALUES (2005, 4, 1, 160, 0, 0, 132) ;
NSERT NTO sporuri VALUES (2005, 4, 2, 130, 45, 0, 70) ;
NSERT NTO sporuri VALUES (2005, 4, 3, 145, 156, 420, 157) ;
NSERT NTO sporuri VALUES (2005, 5, 1, 160, 0, 0, 0) ;
NSERT NTO sporuri VALUES (2005, 5, 2, 80, 45, 0, 70) ;
NSERT NTO sporuri VALUES (2005, 5, 3, 145, 0, 0, 0) ;
NSERT NTO sporuri VALUES (2005, 5, 10, 137, 0, 0, 430) ;
NSERT NTO sporuri VALUES (2005, 6, 1, 160, 0, 0, 0) ;
NSERT NTO sporuri VALUES (2005, 6, 2, 80, 0, 0, 150) ;
NSERT NTO sporuri VALUES (2005, 6, 4, 50, 15, 88, 120) ;
NSERT NTO sporuri VALUES (2005, 6, 5, 130, 15, 0, 20) ;
NSERT NTO sporuri VALUES (2005, 6, 10, 200, 12, 0, 6) ;
NSERT NTO sporuri VALUES (2005, 7, 1, 160, 0, NULL, NULL) ;
NSERT NTO sporuri VALUES (2005, 7, 2, 80, 0, 0, 158) ;
NSERT NTO sporuri VALUES (2005, 7, 3, 145, 0, 0, 0) ;
NSERT NTO sporuri VALUES (2005, 7, 4, 50, 15, NULL, 15) ;
NSERT NTO sporuri VALUES (2005, 7, 5, 130, 0, 0, 120) ;
NSERT NTO sporuri VALUES (2005, 7, 6, 110, 147, 0, 0) ;
NSERT NTO sporuri VALUES (2005, 7, 7, 60, 210, 0, 0) ;
NSERT NTO sporuri VALUES (2005, 7, 8, 130, 0, 15, 0) ;
NSERT NTO sporuri VALUES (2005, 7, 9, 140, 100, 77, 0) ;
NSERT NTO sporuri VALUES (2005, 7, 10, 200, 0, 0, 120) ;

144 Baze de date

Figura 6.22. Continutul tabelei PERSONAL2


Figura 6.23. Continutul tabelei SPORURI
Care sunt persoanele i lunile pentru care nu s-a calculat (nu se cunoate) sporul pentru
conditii deosebite ?
Prin interogarea:
SELECT SPORUR.Marca, NumePren, Compart, An, Luna
FROM PERSONAL2, SPORUR
WHERE PERSONAL2.Marca=SPORUR.Marca AND SporCD S NULL
se obtine situatia din Iigura 6.24.

Figura 6.24. Angafatii pentru care nu s-au operat sporurile pentru conditii deosebite
Care sunt angafatii i lunile in care acetia nu au primit spor pentru conditii deosebite ?
FEAA nfoEc + CG - 2006/2007 145
Att solutia ct si rezultatul sunt sensibil diIerite vezi Iigura 6.25.
SELECT SPORUR.Marca, NumePren, Compart, An, Luna
FROM PERSONAL2, SPORUR
WHERE PERSONAL2.Marca=SPORUR.Marca AND SporCD = 0
ORDER BY An, Luna, NumePren

Figura 6.25. Angafatii i lunile pentru care SporCD este :ero (neNULL)
Care dintre angafati sunt nscuti inainte de 1 ianuarie 1970 i care dup aceast dat ?
Persoanele nscute inainte (Iigura 6.26.):
SELECT * FROM PERSONAL2 WHERE DataNast < '01-01-1970'
si dup (Iigura 6.27):
SELECT * FROM PERSONAL2 WHERE DataNast >= '01-01-1970'


Figura 6.26. Persoane nscute inainte de 1 ian. 1970


Figura 6.27. Persoane nscute dup 1 ian. 1970
Se observ un lucru curios: dac reunim multimea angajatilor nscuti nainte de data Iixat cu
multimea celor nscuti dup aceast dat nu obtinem relatia initial PERSONAL2 (Iigura 6.28).
SELECT * FROM PERSONAL2 WHERE DataNast < '01-01-1970'
UNON
SELECT * FROM PERSONAL2 WHERE DataNast >= '01-01-1970'
146 Baze de date

Figura 6.28. Reuniunea persoanelor nscute inainte de 1 ian. 1970 cu persoanele nscute dup
aceast dat
Din tabela obtinut n Iigura 6.28 lipsesc angajatii care nu au precizat data nasterii, altIel
spus, persoanele 'Ir vrst. Pentru recompunerea tabelei PERSONAL2, n reuniune mai trebuie
adugate si liniile pentru care DataNast S NULL:
SELECT * FROM PERSONAL2 WHERE DataNast < '01-01-1970' UNON
SELECT * FROM PERSONAL2 WHERE DataNast >= '01-01-1970' UNON
SELECT * FROM PERSONAL2 WHERE DataNast S NULL
ORDER BY Marca
Acest exemplu este gritor n privinta logicii trivalente a modelului relational n ceea ce
priveste valorile nule. n continuare, intereseaz un alt aspect al NULLittilor: modul de evaluare a
expresiilor n care unul sau mai multi operanzi au valori nule.

Care este totalul sporurilor fiecrui angafat pe luna iulie 2005 ?
SELECT SPORUR.Marca, NumePren, Compart,
SporVechime + SporNoapte + SporCD + AlteSpor AS TotalSporuri
FROM PERSONAL2, SPORUR
WHERE PERSONAL2.Marca=SPORUR.Marca AND An = 2005 AND Luna=7
Din pcate, rezultatul este incorect vezi Iigura 6.29 deoarece, din prezentarea continutului tabelei
SPORURI (Iigura 6.23), reiese c, pe luna iulie 2005, ANGAJAT 1 are calculat spor de vechime, iar
ANGAJAT 4 are, pe acceasi lun si spor de vechime, si de noapte si alte sporuri, iar aceste sporuri nu
au Iost luate n calcul la nsumare.

Figura 6.29. Re:ultatul unei expresii in care cel putin un operand este NULL
Explicatia este simpl: dac, ntr-o expresie, unul dintre operanzi este NULL, atunci rezultatul
evalurii ntregii expresii este NULL. Fac exceptie Iunctiile statistice. Dac, spre exemplu, vrem s
calculm: Totalul sporurilor de noapte acordate pentru luna iulie 2005, Iraza:
FEAA nfoEc + CG - 2006/2007 147
SELECT SUM(SporNoapte) AS Total_SporuriNoapte_Luna_7
FROM SPORUR
WHERE An = 2005 AND Luna=7
calculeaz corect rezultatul.
Revenim la cazul cu probleme. Pentru a asigura corectitudinea totalului, ar trebui ca n
expresie orice valoare nul s Iie considerat zero. Lucru realizabil, deoarece SQL92 este 'prevzut
cu o Iunctie n acest sens COALESCE:
SELECT SPORUR.Marca, NumePren, Compart, COALESCE(SporVechime,0) +
COALESCE (SporNoapte,0) + COALESCE (SporCD,0) +
COALESCE (AlteSpor,0) AS TotalSporuri
FROM PERSONAL2, SPORUR
WHERE PERSONAL2.Marca=SPORUR.Marca AND An = 2005 AND Luna=7
Sumele obtinute sunt n acest caz cele din Iigura 6.30.


Figura 6.30. Conversia valorilor nule in :ero i evaluarea corect a expresiei
Este important de retinut c Iunctiile VALUE, COALESCE, NVL nu se aplic la nivel de
expresie, ci Iiecrui operand susceptibil de nulitate. De asemenea, un alt element interesant legat de
valorile nule tine de conversia n sens invers, dintr-o valoare oarecare, n NULL.

S se determine totalul sporurilor de noapte pentru luna iulie 2005, dar, in re:ultat, s nu fie
luate in calcul valoarea (valorile) 300000 lei.
Solutia 'clasic este:
SELECT SUM(SporVechime) FROM SPORUR
WHERE An = 2005 AND Luna=7 AND SporVechime <> 300000
O variant ceva mai elegant se redacteaz prin utilizarea Iunctiei NULLF prezent n SQL92 care, n
interogarea de mai jos, converteste orice aparitie a valorii n NULL:
SELECT SUM(NULLF(SporVechime,300000)) FROM SPORUR WHERE An = 2005 AND Luna=7
6.5.2 1onc(iunea extern
Standardul SQL2 introduce operatorii necesari jonctiunii externe:
LEFT OUTER JON pentru jonctiune extern la stnga,
RGHT OUTER JON pentru jonctiune extern la dreapta,
FULL OUTER JON pentru jonctiune extern total (n ambele directii).
148 Baze de date
Dac ne raportm la exemplul teoretic din algebra realational (paragraIul 5.3, Iigura 5.20),
atunci jonctiunile externe la stnga, la dreapta si total dintre relatiile R1 si R2 se transcriu n
standardul SQL92 astIel:
Jonctiune extern la stanga
SELECT * FROM R1 LEFT OUTER JON R2 ON R1.C=R2.C
Jonctiune extern la dreapta
SELECT * FROM R1 RGHT OUTER JON R2 ON R1.C=R2.C
Jonctiune extern total
SELECT * FROM R1 FULL OUTER JON R2 ON R1.C=R2.C
Urmtorul exemplu este desprins tot din algebra relational (exemplul 20): Care sunt
localittile in care nu avem nici un client ?
SELECT *
FROM CODUR_POSTALE LEFT OUTER JON CLENT
ON CODUR_POSTALE.CodPost = CLENT.CodPost
WHERE CLENT.CodPost S NULL


Figura 6.31. Localittile in care nu sunt clienti
Care au fost sporurile de noapte acordate angafatilor pe lunile mai i iunie 2005 ?
Situatia obtinut se reIer la dou luni. Exist ns angajati care nu au acest spor pe una sau chiar pe
ambele luni. Cu interogarea:
SELECT AN, Luna, PERSONAL2.Marca, NumePren, SporNoapte
FROM PERSONAL2, SPORUR
WHERE PERSONAL2.Marca=SPORUR.Marca AND an=2005 AND Luna N (5,6)
ORDER BY NumePren, An, Luna
rezultatul arat ca n Iigura 6.32.

Figura 6.32. Sporurile de noapte pe mai i iunie varianta 1 de afiare
Pentru acest exemplu, intereseaz ns Iormatul de prezentare din Iigura 6.33.
FEAA nfoEc + CG - 2006/2007 149

Figura 6.33. Sporurile de noapte pe mai i iunie re:ultatul dorit
Schimbm alura SELECT-ului:
SELECT AN, Luna, PERSONAL2.Marca, NumePren, SporNoapte
FROM PERSONAL2 LEFT OUTER JON SPORUR
ON PERSONAL2.Marca=SPORUR.Marca AND
An=2005 AND Luna=5
ORDER BY NumePren, An, Luna
Se obtine astIel tabela din Iigura 6.34.

Figura 6.34. Sporurile de noapte pe luna mai
Elementul mbucurtor este c n rezultat au Iost inclusi toti angajatii. Cei care nu erau
angajati n aceast perioad prezint valori NULL pentru atributele An si Luna. Pentru aIisarea pe
coloane separate a sporurilor de noapte pe lunile mai si iunie (ca n Iigura 6.33) sunt necesare dou
jonctiuni externe ale tabelei PERSONAL2 cu dou instante ale tabelei SPORURI.
SELECT PERSONAL2.Marca, NumePren, S1.SporNoapte AS SporNoapte_Mai,
S2.SporNoapte AS SporNoapte_unie
FROM PERSONAL2
LEFT OUTER JON SPORUR S1 ON PERSONAL2.Marca=S1.Marca
AND 2005=S1.An AND 5 = S1.Luna
LEFT OUTER JON SPORUR S2 ON PERSONAL2.Marca=S2.Marca
AND 2005=S2.An AND 6 = S2.Luna
ORDER BY NumePren
Elementul-cheie l constituie prezenta operatorului jonctiunii externe n dreptul atributelor An si Luna.
Prin aceast se includ n rezultat si liniile din tabela PERSONAL2 care nu prezint corespondent
dup atributul Marca cu tabela SPORURI pentru cele dou luni.

150 Baze de date
S se obtin sporurile de noapte pentru al doilea trimestru al anului 2005, atat lunar, cat i
cumulat.
Sunt necesare trei instante ale tabelei SPORURI, Iraza SELECT devenind supraponder:
SELECT PERSONAL2.Marca, NumePren, COALESCE(S1.SporNoapte,0) AS Spor_Noapte_Aprilie,
COALESCE (S2.SporNoapte,0) AS Spor_Noapte_Mai,
COALESCE (S3.SporNoapte,0) AS Spor_Noapte_unie,
COALESCE (S1.SporNoapte,0) + COALESCE (S2.SporNoapte,0)+
COALESCE (S3.SporNoapte,0) AS Spor_Noapte_Trim_
FROM PERSONAL2
LEFT OUTER JON SPORUR S1 ON PERSONAL2.Marca=S1.Marca
AND 2005=S1.An AND 4 = S1.Luna
LEFT OUTER JON SPORUR S2 ON PERSONAL2.Marca=S2.Marca
AND 2005=S2.An AND 5 = S2.Luna
LEFT OUTER JON SPORUR S3 ON PERSONAL2.Marca=S3.Marca
AND 2005=S3.An AND 6 = S3.Luna
ORDER BY NumePren
Rezultat est asemntor celui din Iigura 6.35.

Figura 6.35. Sporurile de noapte pe trimestrul al II-lea, pe luni i cumulat
6.6 STRUCTURI ALTERNATIVE: CASE, DECODE
Pn la standardul SQL:1999, SQL a Iost un limbaj pur neprocedural. Cu toate acestea,
ncepnd cu standardul 92, SQL a introdus Iacilitatea codrii structurilor alternative prin clauza CASE.

Cati dintre clienti sunt din Iai (cod potal 6600) i cati din afara Iaului ?
ncepem cu o versiune 'ajuttoare. Pentru a scrie n dreptul Iiecrui client dac e din Iasi sau din
aIara Iasului, se Ioloseste interogarea:
SELECT DenCl, CodCl, CLENT.CodPost, Loc,
CASE Loc WHEN 'asi' THEN ' Din asi' ELSE 'Din afara asiului' END AS Pozitionare
FROM CLENT NNER JON CODUR_POSTALE ON CLENT.CodPost = CODUR_POSTALE.CodPost
Rezultatul arat ca n Iigura 6.36.

FEAA nfoEc + CG - 2006/2007 151

Figura 6.36. Atribut calculat pe ba:a unei secvente alternative
Pentru a rspunde exact la ntrebare, se poate redacta o variant dup cum urmeaz (rezultatul
Iinal este prezentat n Iigura 6.37):
SELECT CASE Loc WHEN 'asi' THEN 'Din asi' ELSE 'Din afara asiului' END AS Pozitionare,
COUNT(*) AS NrClienti
FROM CLENT NNER JON CODUR_POSTALE ON CLENT.CodPost = CODUR_POSTALE.CodPost
GROUP BY CASE Loc WHEN 'asi' THEN 'Din asi' ELSE 'Din afara asiului' END

Figura 6.37. Numrul clientilor ieeni i al celor din afara Ieilor
Cati angafati au primit, pe luna iulie 2005, spor pentru conditii deosebite i cati nu ?
SELECT CASE WHEN SporCD > 0 THEN 'Au spor CD' ELSE 'Nu au spor CD' END,
COUNT(*) AS Nr
FROM SPORUR WHERE An=2005 AND Luna=7
GROUP BY CASE WHEN SporCD > 0 THEN 'Au spor CD' ELSE 'Nu au spor CD' END

Scadenta fiecrei facturi emise este 20 de :ile. Dac ins data limit cade intr-o sambt sau
duminic, atunci scadenta se mut in lunea urmtoare. Care sunt :ilele scadente in aceste conditii ?
Solutia Oracle/PostgreSQL este una simpl, un rol decisiv avndu-l, pe lng structura CASE,
puternica Iunctie TO_CHAR:
SELECT NrFact, TO_CHAR(DataFact,'YYYY-MM-DD') AS DataFact,
TO_CHAR(DataFact + 20,'YYYY-MM-DD') AS Scadenta1,
TO_CHAR(DataFact + 20,'DAY') AS NumeZi1,
CASE WHEN TO_CHAR(DataFact + 20,'DAY') = 'SATURDAY'
THEN TO_CHAR(DataFact + 22,'YYYY-MM-DD')
ELSE CASE WHEN TO_CHAR(DataFact + 20,'DAY') = 'SUNDAY'
THEN TO_CHAR(DataFact + 21,'YYYY-MM-DD')
ELSE TO_CHAR(DataFact + 20,'YYYY-MM-DD')
END
END AS Scadenta,
TO_CHAR( CASE WHEN TO_CHAR(DataFact + 20,'DAY') = 'SATURDAY'
THEN DataFact + 22
ELSE CASE WHEN TO_CHAR(DataFact + 20,'DAY') = 'SUNDAY'
THEN DataFact + 21
ELSE DataFact + 20
END
END,
152 Baze de date
'DAY') AS Zi_Scadenta
FROM FACTUR

Figura 6.38. Scadenta rectificat a incasrii facturilor
6.7 SUBCONSULTRI. OPERATORUL IN
Una din cele mai importante Iacilitti ale SQL const n includerea unei consultri n alta, pe
dou sau mai multe nivele, altIel spus, utilizarea subconsultrilor. Prin subconsultri se obtin tabele
temporare intermediare Iolosite ca 'argumente ale Irazelor SELECT superioare.

6.7.1 Operatorul IN n subconsultri
Operatorul cel mai utilizat n materie de subconsultri este IN pe care l-am ntlnit deja ntr-un
paragraI precedent ntr-o cu totul alt ipostaz - testarea ncadrrii valorii unui atribut ntr-o list de
constante. Pentru cele ce urmeaz, domeniul de test al este alctuit din liniile unei tabele obtinute
printr-o (sub)consultare.
Revenim (pentru a doua oar) la exemplul 19 din algebra relational: Ce facturi au fost emise
in aceeai :i cu factura 1120 ? ntr-un paragraI anterior a Iost Iormulat o solutie bazat pe jonctiunea
a dou instante ale tabelei FACTURI. Iat si o solutie mai simpl bazat pe subconsultri:
SELECT NrFact FROM FACTUR WHERE DataFact N
(SELECT DataFact FROM FACTUR WHERE NrFact=1120)
FEAA nfoEc + CG - 2006/2007 153
Executia acestei interogri se deruleaz n doi timp. Mai nti, se execut sub-consultarea SELECT
DataFact FROM FACTUR WHERE NrFact=1120 obtinndu-se o tabel intermediar cu o singur
linie si o singur coloan (DataFact). n al doilea pas sunt selectate liniile tabelei FACTURI care
ndeplinesc conditia DataFact = '7-08-2005'. n rezultat a Iost inclus si Iactura de reIerint 1120.
Dac se doreste excluderea acesteia, Iraza SELECT se modiIic astIel:
SELECT NrFact FROM FACTUR WHERE DataFact N
(SELECT DataFact FROM FACTUR WHERE NrFact=1120)
AND NrFact <> 1120

Ce facturi au fost emise in alte :ile decat factura 1120 ?
Acest exemplu necesit Iolosirea operatorului de negatie:
SELECT NrFact FROM FACTUR WHERE DataFact NOT N
(SELECT DataFact FROM FACTUR WHERE NrFact=1120)

Care sunt clientii crora li s-au trimis facturi in aceeai :i in care a fost intocmit factura
1120 ?
SELECT DenCl FROM CLENT WHERE CodCl N
(SELECT CodCl FROM FACTUR WHERE DataFact N
(SELECT DataFact FROM FACTUR WHERE NrFact=1120) )
Rezultatul prezentat n Iigura 6.39 se obtine Iolosind trei nivele de interogare (Iraza principal, o sub-
consultare si o sub-sub-consultare).


Figura 6.39. Clientii pentru care exist facturi emise in aceeai :i ca 1120
In ce fudete s-a vandut produsul 'Produs 2` ?
Am ales acest exemplu pentru a 'vntura, prin subconsultri, ct mai multe tabele ale bazei:
SELECT Judet FROM JUDETE WHERE Jud N
(SELECT Jud FROM CODUR_POSTALE WHERE CodPost N
(SELECT CodPost FROM CLENT WHERE CodCl N
(SELECT CodCl FROM FACTUR WHERE NrFact N
(SELECT NrFact FROM LNFACT WHERE CodPr N
(SELECT CodPr FROM PRODUSE WHERE DenPr = 'Produs 2') ) ) ) )

Revenim la tabela PERSONAL2 din Iigura 5.2: Cati subordonati directi are ANGAJAT 2 ?
La aceast problem (la care rspunsul este 2) Iormulm, pentru comparatie, dou solutii. Solutia
bazat pe jonctiune este:
SELECT COUNT(*) AS NrSubordonati
FROM PERSONAL2 SUBORDONAT, PERSONAL2 SEF
WHERE SUBORDONAT.MarcaSef=SEF.Marca AND SEF.NumePren='ANGAJAT 2'
A doua solutia utilizeaz o subconsultare:
SELECT COUNT(Marca) AS NrSubordonati
FROM PERSONAL2
154 Baze de date
WHERE MarcaSef N
(SELECT Marca FROM PERSONAL2 WHERE NumePren='ANGAJAT 2')

Tot prin subconsultri putem realiza intersectia si diIerenta relational. Raportndu-ne la
intersectia a dou relatii, R1 si R2, operatiunea se poate realoza n SQL si astIel:
SELECT * FROM R1 WHERE (A,B,C) N (SELECT C,D,E FROM R2)

Un alt exemplu de intersectie (ex. 17 algebra relational): In ce :ile s-au vandut i produsul
cu denumirea 'Produs 1` i cel cu denumirea 'Produs 2` ?
SELECT DSTNCT DataFact
FROM PRODUSE, LNFACT, FACTUR
WHERE PRODUSE.CodPr = LNFACT.CodPr AND LNFACT.Nrfact = FACTUR.NrFact AND
DenPr = 'Produs 1' AND DataFact N
(SELECT DSTNCT DataFact FROM PRODUSE, LNFACT, FACTUR
WHERE PRODUSE.CodPr = LNFACT.CodPr AND LNFACT.Nrfact = FACTUR.NrFact AND
DenPr = 'Produs 2')

Ct priveste diIerenta relational, cheia rezolvrii este NOT IN. Ce clienti au cumprat i
'Produs 2` i 'Produs 3`, dar nu au cumprat 'Produs 5` ?
SELECT DSTNCT DenCl FROM PRODUSE, LNFACT, FACTUR, CLENT
WHERE PRODUSE.CodPr = LNFACT.CodPr AND LNFACT.Nrfact = FACTUR.NrFact AND
FACTUR.CodCl = CLENT.CodCl AND DenPr = 'Produs 2' AND FACTUR.CodCl N
(SELECT CodCl FROM PRODUSE, LNFACT, FACTUR WHERE PRODUSE.CodPr =
LNFACT.CodPr AND LNFACT.Nrfact = FACTUR.NrFact AND DenPr = 'Produs 3')
AND FACTUR.CodCl NOT N
(SELECT CodCl FROM PRODUSE, LNFACT, FACTUR WHERE PRODUSE.CodPr =
LNFACT.CodPr AND LNFACT.Nrfact = FACTUR.NrFact AND DenPr = 'Produs 5')

Pn la aparitia operatorilor LEFT OUTER JON, RGHT OUTER JON si FULL OUTER
JON n multe SGBD-uri fonctiunea extern era realizat prin reuniunea liniilor obtinute din echi-
jonctiune cu liniile unei tabele (completate cu zerouri/spatii pentru atributele celeilalte tabele) ce nu au
corespondent n cealalt. Jonctiunea extern la stnga a relatiilor R1 si R2 prin atributul C ar putea Ii
realizat si astIel:
SELECT * FROM R1, R2 WHERE R1.C = R2.C
UNON
SELECT A,B,C, 0, ' ', 0 FROM R1 WHERE C NOT N
(SELECT C FROM R2)

Tot cu ajutorul operatorului IN (si NOT IN) se poate aborda si "problema" divi:iunii
relationale n SQL (parc v aud spunnd: 'Asta ne mai lipsea acuma !). Succesiunea de pasi
prezentat n Iigura 5.21 se realizeaz relativ simplu prin solutia SQL92 / DB2/PostgreSQL:
SELECT X FROM R1 EXCEPT
SELECT DSTNCT R1.X FROM R1, R2 WHERE (R1.X, R2.Y) NOT N
(SELECT X, Y FROM R1)

Aflati clientii pentru care exist cel putin cate o factur emis in fiecare :i '
FEAA nfoEc + CG - 2006/2007 155
Acesta este exemplul 22 din algebra relational (Iigura 2.27) pentru ilustrarea operatorului diviziune.
Urmm logica pe care tocmai am prezentat-o.
SELECT DenCl FROM CLENT WHERE CodCl N
(SELECT CodCl FROM CLENT C EXCEPT
SELECT DSTNCT C.CodCl FROM CLENT C, FACTUR F1, FACTUR F2
WHERE C.CodCl=F1.CodCl AND (C.CodCl, F2.DataFact) NOT N
(SELECT C.CodCl, DataFact FROM CLENT C, FACTUR F WHERE C.CodCl=F.CodCl))

In ce :ile s-au vandut i produsul cu denumirea 'Produs 1` i cel cu denumirea 'Produs 2` ?
SELECT DataFact
FROM FACTUR F, LNFACT LF, PRODUSE P
WHERE F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr AND DenPr N ('Produs 1', 'Produs 2')
EXCEPT
SELECT DSTNCT F.DataFact
FROM FACTUR F, LNFACT LF, PRODUSE P1, PRODUSE P2
WHERE F.NrFact=LF.NrFact AND LF.CodPr=P1.CodPr AND P1.DenPr N ('Produs 1', 'Produs 2')
AND P2.DenPr N ('Produs 1', 'Produs 2') AND (F.DataFact, P2.CodPr) NOT N
(SELECT DSTNCT DataFact, LF.CodPr
FROM FACTUR F, LNFACT LF, PRODUSE P
WHERE F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr AND DenPr N ('Produs 1', 'Produs 2'))
6.7.2 Operatori de compara(ie n subconsultri
Pn acum subconsultrile au Iost conectate la Iraza SELECT superioar exclusiv prin
operatorul IN. n paragraIul urmtor vom vedea c pentru (sub)interogrile comparative, pot Ii
ntrebuintati ALL, SOME, ANY. Atunci cnd rezultatul unei subconsultri se concretizeaz ntr-o
tabel cu o singur coloan si o singur linie, corelarea poate Ii Icut cu operatorii de comparatie
obisnuiti: , ~, ~, , . Vom ilustra aceast Iacilitate prin cteva exemple.

Care este cel mai mare pret unitar la care s-a vandut un produs ?
SELECT MAX(PretUnit) FROM LNFACT

Care este cel mai mare pret unitar, i care este produsul, precum i factura unde se
inregistrea: respectivul pret maxim ?
SELECT NrFact, DenPr, PretUnit FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr=P.CodPr AND PretUnit = (SELECT MAX(PretUnit) FROM LNFACT)

Care sunt cele mai mari dou preturi unitare de van:are, care sunt produsele i facturile
pentru care se inregistrea: respectivele preturi maxime ?

SELECT NrFact, DenPr, PretUnit FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr=P.CodPr AND PretUnit >=
(SELECT MAX(PretUnit) FROM LNFACT WHERE PretUnit <
(SELECT MAX(PretUnit) FROM LNFACT)
)
156 Baze de date
Pentru a ntelege mecanismul interogrii de mai sus, pornim de la SELECT-ul 'cel mai de
jos. SELECT MAX(PretUnit) FROM LNFACT extrage pretul unitar maxim din tabela LINIIFACT.
Subconsultarea superioar, (SELECT MAX(PretUnit) FROM LNFACT WHERE PretUnit < (
.ultima subconsultare. ), determin al doilea pret unitar din LINIIFACT. SELECT-ul principal
aIiseaz toate preturile unitare mai mari sau egale cu penultimul.

Care sunt cele mai mari cinci preturi unitare de van:are, produsele i facturile in care apar
cele cinci preturi maxime ? Aici voiam, de Iapt, s ajungem:
SELECT NrFact, DenPr, PretUnit
FROM LNFACT NNER JON PRODUSE ON LNFACT.CodPr=PRODUSE.CodPr
WHERE PretUnit >
(SELECT MAX(PretUnit) FROM LNFACT WHERE PretUnit <
(SELECT MAX(PretUnit) FROM LNFACT WHERE PretUnit <
(SELECT MAX(PretUnit) FROM LNFACT WHERE PretUnit <
(SELECT MAX(PretUnit) FROM LNFACT WHERE PretUnit <
(SELECT MAX(PretUnit) FROM LNFACT WHERE PretUnit <
(SELECT MAX(PretUnit) FROM LNFACT)
)
)
)
) )
ORDER BY PretUnit DESC
Celor care nu au reusit s Iie impresionati de aceast ultim variant, le sugerez s ncerce cu
primele 10, 20 s.a.m.d. preturi unitare. Revenim ns la solutia prezentat; iat rezultatul acesteia
(Iigura 6.40).

Figura 6.40. Cele mai mari cinci preturi unitare
n PostgreSQL o clauz de mare ajutr este LIMIT prin care se extrag primele n valori ale unei
exprsii dintr-un set de nregistrri:
SELECT NrFact, DenPr, PretUnit
FROM LNFACT NNER JON PRODUSE ON LNFACT.CodPr=PRODUSE.CodPr
WHERE PretUnit N
(SELECT DSTNCT PretUnit FROM LNFACT ORDER BY PretUnit DESC LMT 3)
FEAA nfoEc + CG - 2006/2007 157
6.7.3 Operatorii ALL, SOME, ANY
Cei trei operatori prezentati n acest paragraI sunt grozav de utili n interogrile cu iz
'cantitativist mai pronuntat, deoarece permit utilizarea unui predicat de comparatie care este aplicat
rezultatului unei sub-consultri, predicat bazat pe unul din operatorii: , , ~, , ~, ~ sau #. Dac,
n cea mai mare parte a cazurilor de pn acum, se compara un atribut (sau rezultatul unei
expresii/Iunctii) cu o constant, ALL, SOME si ANY permit compararea valorii atributului/Iun-
ctiei/expresiei cu un set de tupluri (absamblu de linii) extras printr-o subconsultare.

Care sunt produsele vandute la preturi unitare superioare oricrui pret unitar la care a fost
vandut Produs 1 ?
SELECT DSTNCT DenPr FROM PRODUSE P, LNFACT LF
WHERE P.CodPr=LF.CodPr AND PretUnit > ALL
(SELECT DSTNCT PretUnit FROM PRODUSE P, LNFACT LF
WHERE P.CodPr=LF.CodPr AND DenPr ='Produs 1')
Ca orice interogare pe dou nivele, ostilittile se deruleaz n doi pasi. Mai nti se execut
subconsultarea si se obtine o tabel intermediar n care se gsesc toate preturile unitare la care a Iost
vndut, n decursul istoriei, Produs 1 vezi Iigura 6.41.

Figura 6.41. Re:ultatul subconsultrii preturile unitare pentru Produs 1
Cum operatorul de conexiune a Irazei SELECT principale cu subconsultarea este > ALL, din
jonctiunea tabelelor PRODUSE si LINIIFACT vor Ii extrase numai liniile care au valoarea atributului
PretUnit mai mare dect toate valorile din Iigura 6.41. Asa nct rezultatul Iinal se prezint ca n
Iigura 6.42.

Figura 6.42 Produse cu cel putin un pret unitar superior oricrui pret unitar al Produsului 1
Care sunt produsele vandute la preturi unitare superioare mcar unui pret unitar al
Produsului 1 ?
Este genul de situatii n care se Ioloseste SOME sau ANY (au aceeasi Iunctiune).
SELECT DSTNCT DenPr FROM PRODUSE P, LNFACT LF
WHERE P.CodPr=LF.CodPr AND PretUnit > ANY
(SELECT DSTNCT PretUnit FROM PRODUSE P, LNFACT LF
WHERE P.CodPr=LF.CodPr AND DenPr ='Produs 1')
Rezultatul este cel din Iigura 6.43, deoarece, spre deosebire de ALL, si ANY (si SOME) selecteaz
liniile pentru care pretul unitar este mai mare dect mcar una din valorile obtinute prin subconsultare.
158 Baze de date

Figura 6.43. Produse cu cel putin un pret unitar superior mcar unui pret unitar al Prod. 1
Operatorul =ANY este echivalent cu N.

Cati alti angafati au salariul tarifar egal celui al ANGAJAT 2 ?
Solutia:
SELECT COUNT(*) - 1 AS Nr FROM PERSONAL2 WHERE SalTarifar N
(SELECT Saltarifar FROM PERSONAL2 WHERE NumePren='ANGAJAT 2')
este echivalent cu:
SELECT COUNT(*) - 1 AS Nr FROM PERSONAL2 WHERE SalTarifar =ANY
(SELECT Saltarifar FROM PERSONAL2 WHERE NumePren='ANGAJAT 2')

Folosirea unuia din cei trei operatori nu este obligatorie atunci cnd subconsultarea contine o
Iunctie-agregat (ce ntoarce o valoare dintr-un ansamblu de tupluri) - MIN, MAX, COUNT, SUM,
AVG.
Care este ultima factur intocmit (factura cea mai recent) i data in care a fost emis ?
SELECT DataFact, NrFact AS UltimaFactura FROM FACTUR WHERE NrFact N
(SELECT MAX(NrFact) FROM FACTUR)
sau
SELECT DataFact, NrFact AS UltimaFactura FROM FACTUR WHERE NrFact =
(SELECT MAX(NrFact) FROM FACTUR)
sau
SELECT DataFact, NrFact AS UltimaFactura FROM FACTUR WHERE NrFact =ANY
(SELECT MAX(NrFact) FROM FACTUR)
sau
SELECT DataFact, NrFact AS UltimaFactura FROM FACTUR WHERE NrFact =ALL
(SELECT MAX(NrFact) FROM FACTUR)

Fr Iunctia MAX, inteogarea este:
SELECT DataFact, NrFact AS UltimaFactura FROM FACTUR WHERE NrFact >= ALL
(SELECT NrFact FROM FACTUR)
6.7.4 Subconsultri n clauza HAVING
Predicatele incluse n clauza HAVING ale interogrilor de pn acum compar o expresie cu o
constant. n cele ce urmeaz vom discuta despre includerea n clauza HAVING a subconsultrilor.
Revenim asupra unei probleme Iormulate anterior:

Care sunt :ilele in s-au emis mai multe facturi decat pe 2 august 2005 ?
SELECT DataFact AS Zi, COUNT(NrFact) AS Nr_Facturilor
FROM FACTUR GROUP BY DataFact HAVNG COUNT(NrFact) >
FEAA nfoEc + CG - 2006/2007 159
(SELECT COUNT(NrFact) FROM FACTUR WHERE DataFact = '08/02/2005')

Care este :iua in care s-au emis cele mai multe facturi ?
SELECT DataFact, COUNT(*) AS Nr_Facturilor FROM FACTUR GROUP BY DataFact
HAVNG COUNT(*) >= ALL (SELECT COUNT(*) FROM FACTUR GROUP BY DataFact)
Subconsultarea calculeaz numrul de Iacturi corespunztor Iiecrei zile. Predicatul clauzei HAVING
compar numrul de Iacturi al Iiecrei zile cu toate valorile extrase de subconsultare. Se obtine tabela
din Iigura 6.44.

Figura 6.44. Zilele in care s-au emis cele mai multe facturi
n PostgreSQL ne putem Iolosi Ir rusine de clauza LIMIT:
SELECT DataFact, COUNT(*) AS Nr_Facturilor
FROM FACTUR GROUP BY DataFact HAVNG COUNT(*) =
(SELECT COUNT(*) FROM FACTUR GROUP BY DataFact ORDER BY COUNT(*) DESC LMT 1)

Care este clientul care a cumprat cele mai multe produse ?
SELECT DenCl, COUNT(DSTNCT CodPr) AS CiteProduse
FROM CLENT C, FACTUR F, LNFACT LF
WHERE C.CodCl=F.CodCl AND F.NrFact= LF.NrFact
GROUP BY DenCl
HAVNG COUNT(DSTNCT CodPr) >= ALL
(SELECT COUNT(DSTNCT CodPr) FROM FACTUR F, LNFACT LF
WHERE F.NrFact= LF.NrFact GROUP BY CodCl)

Care este compartimentul cu cea mai bun medie a salariilor tarifare ?
Se exclude din discutie compartimentul DIRECTIUNE n care apare, singur si Ierice, directorul
general.
SELECT Compart, ROUND(AVG(SalTarifar),2) AS Medie_Sal
FROM PERSONAL2 WHERE Compart <> 'DRECTUNE' GROUP BY Compart
HAVNG AVG(SalTarifar) >= ALL
(SELECT AVG(SalTarifar) FROM PERSONAL2 WHERE Compart <> 'DRECTUNE'
GROUP BY Compart)

Pentru aducerea aminte a structurilor alternative, putem Iolosi si variant:
SELECT Compart, AVG (CASE WHEN Compart <> 'DRECTUNE' THEN SalTarifar ELSE 0
END) AS Medie_Sal
FROM PERSONAL2
GROUP BY Compart
HAVNG AVG (CASE WHEN Compart <> 'DRECTUNE' THEN SalTarifar ELSE 0 END) >= ALL
(SELECT AVG (CASE WHEN Compart <> 'DRECTUNE' THEN SalTarifar ELSE 0 END)
FROM PERSONAL2 GROUP BY Compart)

160 Baze de date
Care este fudetul in care berea s-a vandut cel mai bine ?
n tabela PRODUSE exist un atribut care reprezint grupa n care se ncadreaz produsul
respectiv. Berea este una dintre grupele ndrgite.
SELECT Judet, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari_Bere
FROM JUDETE J, CODUR_POSTALE L, CLENT C, FACTUR F,
LNFACT LF, PRODUSE P
WHERE J.Jud=L.Jud AND L.CodPost=C.CodPost AND C.CodCl=F.CodCl
AND F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr AND Grupa='Bere'
GROUP BY Judet
HAVNG SUM(Cantitate * PretUnit * (1+ProcTVA)) >= ALL
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA))
FROM JUDETE J, CODUR_POSTALE L, CLENT C, FACTUR F,
LNFACT LF, PRODUSE P
WHERE J.Jud=L.Jud AND L.CodPost=C.CodPost AND C.CodCl=F.CodCl AND
F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr AND Grupa='Bere'
GROUP BY Judet)

Care sunt clientii cu valoarea van:rilor peste medie ?
SELECT DenCl AS Client, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM LNFACT LF, PRODUSE P, FACTUR F, CLENT C
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact AND F.CodCl=C.CodCl
GROUP BY DenCl
HAVNG SUM(Cantitate * PretUnit * (1+ProcTVA)) >=
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) / COUNT(DSTNCT F.CodCl)
FROM LNFACT LF, PRODUSE P, FACTUR F
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact)


Figura 6.45. Clienti cu van:ri peste medie
Extrageti factura cu valoarea imediat peste cea medie '
SELECT F.NrFact, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Valoare
FROM LNFACT LF, PRODUSE P, FACTUR F
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact
GROUP BY F.NrFact
HAVNG SUM(Cantitate * PretUnit * (1+ProcTVA)) <= ALL
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA))
FROM LNFACT LF, PRODUSE P, FACTUR F
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact
GROUP BY F.NrFact
HAVNG SUM(Cantitate * PretUnit * (1+ProcTVA)) >
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) / COUNT(DSTNCT F.NrFact)
FROM LNFACT LF, PRODUSE P, FACTUR F
FEAA nfoEc + CG - 2006/2007 161
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact))
AND SUM(Cantitate * PretUnit * (1+ProcTVA)) >
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) / COUNT(DSTNCT F.NrFact)
FROM LNFACT LF, PRODUSE P, FACTUR F
WHERE P.CodPr = LF.CodPr AND LF.NrFact = F.NrFact)

Element de noutate al acestei interogri este includerea, ntr-o consultare ce prezint clauza
HAVING, a unei alte subconsultri n care apare, de asemenea, HAVING.

Din nou despre diviziunea rela(ional
Revenind la cazul diviziunii relationale a R1 : R2 (altIel spus, gsirea tuturor icsilor care sunt
n R1 ncombinatie cu toti igrecii din R2), se calculeaz n SQL si astIel:
SELECT X FROM R1 GROUP BY X HAVNG COUNT(Y) = (SELECT COUNT(Y) FROM R2)

Cror clienti li s-a trimis mcar o factur in toate :ilele cu van:ri din septembrie 2005 ?
SELECT DenCl FROM FACTUR F, CLENT C
WHERE F.CodCl=C.CodCl AND EXTRACT (MONTH FROM datafact) =9
AND EXTRACT (YEAR FROM datafact) =2005
GROUP BY DenCl
HAVNG COUNT(DSTNCT DataFact) =
(SELECT COUNT (DSTNCT DataFact) FROM FACTUR
WHERE EXTRACT (MONTH FROM datafact) =9 AND EXTRACT (YEAR FROM datafact) =2005 )

Ce produse au fost vandute tuturor clientilor ?
SELECT DenPr
FROM PRODUSE P, LNFACT LF, FACTUR F
WHERE P.CodPr=LF.CodPr AND LF.NrFact=F.NrFact
GROUP BY DenPr
HAVNG COUNT(DSTNCT CodCl) =
(SELECT COUNT (CodCl) FROM CLENT)

Rspunsul este Produs 2.

162 Baze de date

CapitoIuI 7
INTEROGRI SQL (2)



Obiective:
I. Subconsultri n clauza FROM
II. Subconsultri sclarare n clauza SELECT
III. Actualizri avansate - UPDATE



Rezultate ayteptate:
Formarea deprinderilor pentru redactarea de interogri SQL complexe

FEAA nfoEc + CG - 2006/2007 163
7.1 SUBCONSULTRI N CLAUZA FROM
Posibilitatea de a deIini tabele ,ad-hoc, n clauza FROM, este unul dintre cele mai importante
daruri pe care SQL-ul l oIer utilizatorilor, deopotriv proIesionisti si neproIesionisti n ale bazelor de
date. Vom intra abrupt n cteva exemple, urmnd ca dup Iormularea solutiilor s discutm
ingredintele acestui artiIiciu.

Care sunt valorile facturate i incasate, precum i situatia ('fr nici o incasare`, 'incasat
partial` sau 'incasat total`) pentru fiecare factur ?
SELECT VNZAR.Nrfact, Facturat, COALESCE(ncasat,0) AS ncasat,
Facturat - COALESCE(ncasat,0) AS Diferenta,
CASE WHEN COALESCE(ncasat,0) = 0 THEN 'Fara nici o incasare'
WHEN Facturat > COALESCE(ncasat,0) THEN 'ncasata partial'
ELSE 'NCASATA TOTAL'
END AS Situatiune
FROM (
SELECT NrFact, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Facturat
FROM LNFACT LF NNER JON PRODUSE P ON LF.CodPr = P.CodPr
GROUP BY NrFact) VNZAR LEFT OUTER JON
(SELECT NrFact, SUM(Transa) AS ncasat FROM NCASFACT GROUP BY NrFact) NCASAR
ON VNZAR.NrFact = NCASAR.NrFact
n clauza FROM a Irazei SELECT principale au Iost deIinite dou tabele n toat regula, VINZARI si
INCASARI. Prima contine valoarea total a Iiecrei Iacturi, n timp ce a doua valoarea ncasat.
Aceste dou tabele sunt jonctionate extern dup atributul NrFact.

S se obtin sporurile de noapte pentru al doilea trimestru al anului 2005, atat lunar, cat i
cumulat.
SELECT SL1.Marca, NumePren, COALESCE(SL1.SporNoapte,0) AS Spor_Noapte_Aprilie,
COALESCE(SL2.SporNoapte,0) AS Spor_Noapte_Mai, COALESCE(SL3.SporNoapte,0) AS
Spor_Noapte_unie, COALESCE(SL1.SporNoapte,0) + COALESCE(SL2.SporNoapte,0)+
COALESCE(SL3.SporNoapte,0) AS Spor_Noapte_Trim_
FROM
(SELECT PERSONAL2.Marca, NumePren, SporNoapte FROM PERSONAL2
LEFT OUTER JON SPORUR ON PERSONAL2.Marca=SPORUR.Marca
AND An=2005 AND Luna =4) SL1
NNER JON
(SELECT PERSONAL2.Marca, SporNoapte
FROM PERSONAL2 LEFT OUTER JON SPORUR ON PERSONAL2.Marca=SPORUR.Marca
AND An=2005 AND Luna =5) SL2 ON SL1.Marca=SL2.Marca
NNER JON
(SELECT PERSONAL2.Marca, SporNoapte FROM PERSONAL2 LEFT OUTER JON
SPORUR ON PERSONAL2.Marca=SPORUR.Marca AND An=2005 AND Luna =6) SL3
ON SL1.Marca=SL3.Marca
ORDER BY NumePren
164 Baze de date
Clauza FROM principal 'calculeaz trei tabele ce contin sporurile de noapte ale lunilor
aprilie (SL1), mai (SL2) si iunie (SL3) 2005 ale Iiecrui angajat (indiIerent de data angajrii
acestuia). Cele trei tabele sunt jonctionate dup atributul Marca.

Revenim la diviziunea relational din Iigura 5.21 care poate Ii realizat n urmtoarea variant
SQL:
SELECT DSTNCT X
FROM R1
WHERE X NOT N
(SELECT DSTNCT PROD_CART.X
FROM (SELECT DSTNCT R1.X, R2.Y FROM R1,R2) PROD_CART
LEFT OUTER JON R1 ON PROD_CART.X=R1.X AND PROD_CART.Y=R1.Y
WHERE R1.X S NULL)

Putem ncerca ns si ceva mai elegant. Ce ziceti de solutia:
SELECT DSTNCT X
FROM
(SELECT X, COUNT(Y) AS Nr FROM R1 GROUP BY X) TEMP1,
(SELECT COUNT(Y) AS Nr FROM R2) TEMP2
WHERE TEMP1.Nr=TEMP2.Nr
Prima tabel, TEMP1, contine numrul valorilor lui Y pentru Iiecare X din R1, iar a doua, TEMP2
numai numrul total al valorilor lui Y din R2 Iigura 7.1.

Figura 7.1. Tabelele intermediare (ad-hoc) TEMP1 i TEMP2
Care sunt clientii pentru care exist cel putin cate o factur emis in fiecare :i ?
Este tot exemplul 22 din algebra relational Iormulat pentru ilustrarea operatorului diviziune.
Solutia 1:
SELECT DSTNCT DenCl FROM CLENT WHERE CodCl NOT N
(SELECT DSTNCT PROD_CART.CodCl FROM
(SELECT DSTNCT CLENT.CodCl, FACTUR.DataFact
FROM CLENT, FACTUR) PROD_CART LEFT OUTER JON FACTUR
ON PROD_CART.CodCl=FACTUR.CodCl AND PROD_CART.DataFact=FACTUR.DataFact
WHERE FACTUR.CodCl S NULL)

Solutia 2 (cea preIerat):
SELECT DSTNCT DenCl FROM
(SELECT CodCl, COUNT(DSTNCT DataFact) AS Nr FROM FACTUR
GROUP BY CodCl) TEMP1,
(SELECT COUNT(DSTNCT DataFact) AS Nr FROM FACTUR) TEMP2,
FEAA nfoEc + CG - 2006/2007 165
CLENT
WHERE TEMP1.Nr=TEMP2.Nr AND TEMP1.CodCl=CLENT.CodCl

In ce :ile s-au vandut i produsul cu denumirea 'Produs 1` i cel cu denumirea 'Produs 2` ?
Este (tot) exemplul 23 din capitolul dedicat algebrei relationale.
Solutia 1:
SELECT DSTNCT DataFact FROM FACTUR F, LNFACT LF, PRODUSE P
WHERE F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr AND DenPr N ('Produs 1', 'Produs 2')
AND DataFact NOT N (SELECT DSTNCT PROD_CART.DataFact
FROM
(SELECT DSTNCT DataFact, CodPr
FROM FACTUR, PRODUSE
WHERE DenPr N ('Produs 1', 'Produs 2')) PROD_CART
LEFT OUTER JON
(SELECT F.DataFact, LF.CodPr
FROM FACTUR F, LNFACT LF, PRODUSE P
WHERE F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr) TEMP1
ON
PROD_CART.DataFact=TEMP1.DataFact AND PROD_CART.CodPr=TEMP1.CodPr
WHERE TEMP1.DataFact S NULL)

Solutia 2:
SELECT DSTNCT DataFact
FROM
(SELECT F.DataFact, COUNT(DSTNCT LF.CodPr) AS Nr
FROM FACTUR F, LNFACT LF, PRODUSE P
WHERE F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr AND DenPr N ('Produs 1', 'Produs 2')
GROUP BY F.DataFact) TEMP1
WHERE Nr = 2
Din nou, solutia a doua contrasteaz evident, prin simplitate, cu prima. Tabela TEMP1
contine, pentru Iiecare dat calendaristic, numrul de produse, dintre Produs 1 si Produs 2 (1 sau 2)
care au Iost vndute n ziua respectiv.

Ce facturi contin mcar produsele din factura 1112 ?
SELECT DSTNCT NrFact FROM
(SELECT NrFact, COUNT(*) AS NrProd FROM LNFACT WHERE CodPr N
(SELECT CodPr FROM LNFACT WHERE NrFact = 1112)
GROUP BY NrFact
) T1,
(SELECT COUNT(CodPr) AS NrP1112 FROM LNFACT WHERE NrFact = 1112) T2
WHERE T1.NrProd = T2.NrP1112
T2 contine numrul produselor din Iactura 1112. T1 contine, pentru Iiecare Iactur, cte
produse sunt comune acesteia si Iacturii 1112. Prin jonctiunea T1 cu T2 prin conditia T1.NrProd =
T2.NrP1112, se extrag acele linii din T1 care au acelasi numr de produse prezente n Iactura 1112 ca
si aceasta.
166 Baze de date

Care sunt clientii crora li s-au vandut cel putin produsele vandute clientului CLIENT 4 ?
SELECT DSTNCT DenCl
FROM
(SELECT DenCl, COUNT(*) AS NrProd
FROM CLENT C, FACTUR F, LNFACT LF
WHERE C.CodCl=F.CodCl AND F.NrFact=LF.Nrfact AND CodPr N
(SELECT CodPr FROM CLENT C, FACTUR F, LNFACT LF
WHERE C.CodCl=F.CodCl AND F.NrFact=LF.Nrfact AND DenCl='Client 4' )
GROUP BY DenCl
) T1,
(SELECT COUNT(CodPr) AS NrProd
FROM CLENT C, FACTUR F, LNFACT LF
WHERE C.CodCl=F.CodCl AND F.NrFact=LF.Nrfact AND DenCl='Client 4'
) T2
WHERE T1.NrProd = T2.NrProd

Logica solutiei este ct se poate se asemntoare precedentei, doar c T2 contine numrul
produselor vndute clientului 4, iar n T1 pe Iiecare linie se gseste un client si numrul produselor
vndute clientului 4 care i-au Iost vndute si lui.

S se afie:e cate facturi sunt. neincasate deloc, incasate partial i incasate total ?
SELECT CASE
WHEN COALESCE(ncasat,0) = 0 THEN 'Fara nici o incasare'
WHEN Facturat > COALESCE(ncasat,0) THEN 'ncasata partial'
ELSE 'NCASATA TOTAL' END AS Situatiune, COUNT(*) AS Nr
FROM (SELECT NrFact, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Facturat
FROM LNFACT LF NNER JON PRODUSE P ON LF.CodPr = P.CodPr
GROUP BY NrFact) VNZAR
LEFT OUTER JON
(SELECT NrFact, SUM(Transa) AS ncasat FROM NCASFACT
GROUP BY NrFact) NCASAR ON VNZAR.NrFact = NCASAR.NrFact
GROUP BY CASE WHEN COALESCE(ncasat,0) = 0 THEN 'Fara nici o incasare'
WHEN Facturat > COALESCE(ncasat,0) THEN 'ncasata partial'
ELSE 'NCASATA TOTAL' END
Jonctiunea extern la stnga dintre VNZRI si NCASRI este completat de o structur alternativ
multipl CASE.

Care angafati au salariul tarifar egal cu cel al ANGAJAT2 ?
SELECT NumePren FROM
(SELECT NumePren, SalTarifar FROM PERSONAL2) TEMP1,
(SELECT Saltarifar FROM PERSONAL2 WHERE NumePren='ANGAJAT 2') TEMP2
WHERE TEMP1.SalTarifar = TEMP2.SalTarifar

Care este :iua in care s-au emis cele mai multe facturi ?
Din pcate (sau, din Iericire !), solutia:
FEAA nfoEc + CG - 2006/2007 167
SELECT TEMP1.DataFact, TEMP1.Nr
FROM
(SELECT DataFact, COUNT(Nrfact) AS Nr FROM FACTUR
GROUP BY DataFact) TEMP1,
(SELECT DataFact, COUNT(Nrfact) AS Nr FROM FACTUR
GROUP BY DataFact) TEMP2
WHERE TEMP1.Nr >= ALL
(SELECT Nr FROM TEMP2)
nu Iunctioneaz. Aceasta nseamn c o tabel deIinit ad-hoc ntr-o Iraz SELECT nu este
recunoscut n subconsultri. Se poate, totusi, utiliza varianta:
SELECT DataFact, COUNT(*) AS Nr_Facturi FROM FACTUR GROUP BY DataFact
HAVNG COUNT(*) = (SELECT MAX(Nr) FROM (SELECT DataFact, COUNT(NrFact) AS Nr
FROM FACTUR GROUP BY DataFact) TEMP1)
n subconsultare s-a deIinit tabela intermediar TEMP1 al crei atribut Nr este Iolosit n Iunctia MAX din clauza
SELECT.

Care este clientul care a cumprat cele mai multe produse ?
SELECT DenCl, COUNT(DSTNCT CodPr) AS Nr_Produse
FROM CLENT, FACTUR, LNFACT
WHERE CLENT.CodCl=FACTUR.CodCl AND FACTUR.NrFact=LNFACT.NrFact
GROUP BY DenCl
HAVNG COUNT(DSTNCT CodPr) = (SELECT MAX(Nr) FROM
(SELECT CodCl, COUNT(DSTNCT CodPr) AS Nr FROM FACTUR, LNFACT
WHERE FACTUR.NrFact=LNFACT.NrFact GROUP BY CodCl)
TEMP1)

Care este fudetul in care berea s-a vandut cel mai bine ?
SELECT Judet, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari_Bere
FROM JUDETE J, CODUR_POSTALE L, CLENT C, FACTUR F,
LNFACT LF, PRODUSE P
WHERE J.Jud=L.Jud AND L.CodPost=C.CodPost AND C.CodCl=F.CodCl
AND F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr AND Grupa='Bere'
GROUP BY Judet
HAVNG SUM(Cantitate * PretUnit * (1+ProcTVA)) =
(SELECT MAX(Vinzari)
FROM
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM CODUR_POSTALE L, CLENT C, FACTUR F, LNFACT LF, PRODUSE P
WHERE L.CodPost=C.CodPost AND C.CodCl=F.CodCl AND F.NrFact=LF.NrFact
AND LF.CodPr=P.CodPr AND Grupa='Bere'
GROUP BY Jud) TEMP1)

Care sunt clientii cu valoarea van:rilor peste medie ?
Solutia 1:
SELECT DenCl, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM CLENT C, FACTUR F, LNFACT LF, PRODUSE P
168 Baze de date
WHERE C.CodCl=F.CodCl AND F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr
GROUP BY DenCl
HAVNG SUM(Cantitate * PretUnit * (1+ProcTVA)) >=
(SELECT Vinzari / NrClienti FROM
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr=P.CodPr ) TEMP1,
(SELECT COUNT(DSTNCT CodCl) AS NrClienti FROM FACTUR) TEMP2)
Solutia 2:
SELECT DenCl, VNZ_CL.Vinzari
FROM
(SELECT DenCl, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM CLENT C, FACTUR F, LNFACT LF, PRODUSE P
WHERE C.CodCl=F.CodCl AND F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr
GROUP BY DenCl ) VNZ_CL,
(SELECT DSTNCT Vinzari / NrClienti AS Medie_Vinz
FROM (SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr=P.CodPr) X,
(SELECT COUNT(DSTNCT CodCl) AS NrClienti
FROM FACTUR) Y
) MEDE_VNZ
WHERE VNZ_CL.Vinzari >= MEDE_VNZ.Medie_Vinz

Care este factura cu cea mai mic valoare peste cea medie ?
SELECT NrFact, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS ValFact
FROM LNFACT LF, PRODUSE P WHERE LF.CodPr=P.CodPr
GROUP BY NrFact HAVNG SUM(Cantitate * PretUnit * (1+ProcTVA)) =
(SELECT MN(ValFact)
FROM (SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) AS ValFact
FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr=P.CodPr
GROUP BY NrFact) TEMP1
WHERE ValFact >
(SELECT Vinzari / NrFacturi AS ValMedie
FROM (SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) AS
Vinzari, COUNT(DSTNCT NrFact) AS NrFacturi
FROM LNFACT LF, PRODUSE P WHERE LF.CodPr=P.CodPr ) TEMP1))

Apelm si la o solutie care s aIiseze toate Iacturile cu valoarea peste medie, n ordinea
cresctoare a acestei valori. Prima Iactur din rezultat Iigura 7.2 - va Ii rspunsul la ntrebarea
Iormulat.
SELECT NrFact, ValFact, ValMedie
FROM
(SELECT NrFact, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS ValFact
FROM LNFACT LF, PRODUSE P WHERE LF.CodPr=P.CodPr
GROUP BY NrFact) TEMP1,
FEAA nfoEc + CG - 2006/2007 169
(SELECT ROUND(Vinzari / NrFacturi,0) AS ValMedie
FROM
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari, COUNT(DSTNCT NrFact)
AS NrFacturi FROM LNFACT LF, PRODUSE P WHERE LF.CodPr=P.CodPr) MEDE1) MED
WHERE ValFact > ValMedie
ORDER BY ValFact

Figura 7.2. Facturile cu valori peste medie
Care este fudetul cu van:ri imediat superioare fudetului Neamt ?
SELECT Judet, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM JUDETE J, CODUR_POSTALE L, CLENT C, FACTUR F,
LNFACT LF, PRODUSE P
WHERE J.Jud=L.Jud AND L.CodPost=C.CodPost AND C.CodCl=F.CodCl
AND F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr
GROUP BY Judet
HAVNG SUM(Cantitate * PretUnit * (1+ProcTVA)) =
(SELECT MN ( VNZ_JUD1.Vinzari)
FROM
(SELECT Judet, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM JUDETE J, CODUR_POSTALE L, CLENT C, FACTUR F,
LNFACT LF, PRODUSE P
WHERE J.Jud=L.Jud AND L.CodPost=C.CodPost AND C.CodCl=F.CodCl
AND F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr
GROUP BY Judet ) VNZ_JUD1,
(SELECT Judet, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM JUDETE J, CODUR_POSTALE L, CLENT C, FACTUR F,
LNFACT LF, PRODUSE P
WHERE J.Jud=L.Jud AND L.CodPost=C.CodPost AND C.CodCl=F.CodCl AND
F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr
GROUP BY Judet ) VNZ_JUD2
WHERE VNZ_JUD1.Vinzari > VNZ_JUD2.Vinzari AND
VNZ_JUD2.Judet='Neamt')

Care este clientul cel mai datornic (ce are cel mai mare rest de plat) ?
Fondul problemei este asemntor celei precedente. n interogare obtinem o tabel ad-hoc cu
diIerenta de ncasat pe clienti (TEMP1), si o alta ce contine cea mai mare diIerent de ncasat pentru
170 Baze de date
un client (TEMP2). Cele dou tabele sunt jonctionate dup diIerent si, n Iinal, pentru a aIla
denumirea clientului, adugm n jonctiune tabela CLIENTI.
SELECT DenCl, Vinzari, ncasari, Dencasat
FROM
(SELECT FACTURAT.CodCl, Vinzari, COALESCE(ncasari, 0) AS ncasari,
Vinzari - COALESCE(ncasari, 0) AS Dencasat
FROM
(SELECT CodCl, SUM(Cantitate * PretUnit * (1+ProcTVA))
AS Vinzari
FROM FACTUR F, LNFACT LF, PRODUSE P
WHERE F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr
GROUP BY CodCl) FACTURAT LEFT OUTER JON
(SELECT CodCl, SUM(Transa) AS ncasari FROM FACTUR F, NCASFACT
WHERE .NrFact=F.NrFact GROUP BY CodCl) NCASAT
ON FACTURAT.CodCl=NCASAT.CodCl
) TEMP1 NNER JON
(SELECT MAX (Vinzari - COALESCE(ncasari, 0)) AS DifMax
FROM (SELECT CodCl, SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM FACTUR F, LNFACT LF, PRODUSE P
WHERE F.NrFact=LF.NrFact AND LF.CodPr=P.CodPr
GROUP BY CodCl) FACTURAT LEFT OUTER JON
(SELECT CodCl, SUM(Transa) AS ncasari FROM FACTUR F, NCASFACT
WHERE .NrFact=F.NrFact GROUP BY CodCl) NCASAT
ON FACTURAT.CodCl=NCASAT.CodCl) TEMP2
ON TEMP1.Dencasat=TEMP2.DifMax NNER JON CLENT
ON TEMP1.CodCl=CLENT.CodCl
7.2 SUBCONSULTRI SCALARE N CLAUZA SELECT
Standardele SQL Iac trimitere si la interogrile scalare ce pot Ii deIinite ca Iraze SELECT ce
obtin un rezultat alctuit dintr-o singur linie si o singur coloan. Utilitatea acestora este vizibil n
expresii complexe. Desi este prima oar cnd pomenim de interogri scalare, le-am Iolosit de multe ori
pn acum n clauzele WHERE si HAVING. Ceea ce vom parcurge n continuare se reIer la
includerea unei interogri scalare n clauza SELECT a unei interogri.

Care sunt totalurile salariilor tarifare i ale sporurilor pe luna iulie 2005 pentru intreaga
firm ?
Solutia ,clasic este:
SELECT SUM(SalTarifar) AS Total_Sal_Tarifar,
SUM ( COALESCE(SporVechime,0) + COALESCE(SporNoapte,0)+
COALESCE(SporCD,0)+COALESCE(AlteSpor,0) ) AS Total_Sporuri_ulie
FROM PERSONAL2 NNER JON SPORUR ON PERSONAL2.Marca=SPORUR.Marca
WHERE An=2005 AND Luna=7
FEAA nfoEc + CG - 2006/2007 171
ntruct toate persoanele din tabela PERSONAL au lucrat n luna iulie 2005 (nu a plecat nici
un angajat din organizatie), se poate Iormula si interogarea:
SELECT SUM(SalTarifar) AS Total_Sal_Tarifar,
(SELECT SUM ( COALESCE(SporVechime,0) + COALESCE(SporNoapte,0)+
COALESCE(SporCD,0)+ COALESCE(AlteSpor,0))
FROM SPORUR
WHERE An=2005 AND Luna=7) AS Total_Sporuri_ulie
FROM PERSONAL2
A doua coloan a rezultatului este obtinut printr-o interogare scalar care opereaz oarecum
independent de Iraza SELECT principal, Iurnizndu-i ns o valoare.

Care sunt totalurile van:rilor i incasrilor ?
Formulm o solutie curioas PostgreSQL:
SELECT
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr=P.CodPr) AS Facturat,
(SELECT SUM (Transa) FROM NCASFACT) AS ncasat
si echivalenta sa (tot curioas) n Oracle:
SELECT
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari
FROM LNFACT LF, PRODUSE P
WHERE LF.CodPr=P.CodPr) AS Facturat,
(SELECT SUM (Transa)
FROM NCASFACT) AS ncasat
FROM dual
Fraza SELECT contine dou subconsultri scalare, una care extrage totalul vnzrilor,
cealalt, totalul ncasrilor. n PostgreSQL clauza FROM poate lipsi, n timp ce n Oracle nu, asa c,
Iiind nevoie de o tabel cu o singur linie, s-a Iolosit tabela DUAL (creat automat n Oracle la
instalare) care are o linie si un atribut.

Care este :iua in care s-au emis cele mai multe facturi ?
SELECT DataFact, COUNT(*) AS Nr_Facturi,
(SELECT MAX(NrF) FROM (
SELECT COUNT(*) AS NrF FROM FACTUR GROUP BY DataFact) T1 ) AS NrMax
FROM FACTUR
GROUP BY DataFact
HAVNG COUNT(*) >= (SELECT MAX(NrF) FROM
(SELECT COUNT(*) AS NrF FROM FACTUR GROUP BY DataFact) T2 )
Valorile coloanelor Nr_Facturi si NrMax ale rezultatului din Iigura 7.3 sunt Iurnizate de dou
subconsultri scalare, una care calculeaz numrul zilnic al Iacturilor, iar a doua a doua numrul
maxim de Iacturi emise ntr-o zi.
172 Baze de date

Figura 7.3. Zilele in care s-au intocmit cele mai multe facturi
Care sunt localittile in care se afl sediul fiecrui client ?
Revenim la un exemplu banal, rezolvat att de simplu prin jonctiune sau subconsultare pentru a
demonstra ct de mult ne putem complica viata n SQL (desi au Iost exemple mai convingtoare). Ei
bine, aceast problem suprtor de simpl poate Ii rezolvat si prin subconsultri scalare:
SELECT DenCl,
(SELECT Loc FROM CODUR_POSTALE WHERE CodPost=CLENT.CodPost) AS Loc
FROM CLENT ORDER BY 2
Figura 7.4 este ediIicatoare n ceea pe priveste corectitudinea rezultatului interogrii. Unicul
merit al exemplului este, probabil, de a demonstra c o subconsultare scalar poate Ii corelat cu tabela
din clauza FROM a Irazei principale.

Figura 7.4. Subconsultare scalar corelat cu tabela din fra:a principal
Pentru cat la sut dintre clienti s-au intocmit, :ilnic, facturi ?
SELECT DataFact, COUNT(DSTNCT CodCl) AS Nr_Clienti,
(SELECT COUNT(*) FROM CLENT) AS Nr_Total_Clienti,
(COUNT(DSTNCT CodCl) * 100) / (SELECT COUNT(*) FROM CLENT) AS Procent
FROM FACTUR
GROUP BY DataFact

Figura 7.4. Procentaful :ilnic al clientilor pentru care exist facturi
FEAA nfoEc + CG - 2006/2007 173
Pentru a obtine procentul care intereseaz se mparte rezultatul calculat de Iunctia COUNT
pentru Iiecare grup (zi calendaristic) la valoarea extras de interogarea scalar.

Care este evolutia :ilnic a van:rilor, raportat la :iua de van:ri anterioar ?
n problema de mai sus diIerenta era calculat ntre ziua curent si ziua precedent. AstIel nct, toate
zilele de luni erau raportate la zero, deoarece, pentru cea mai mare parte a Iirmelor, duminica nu se
lucreaz. Acum dorim ca diIerenta s Iie calculat ntre vnzrile din ziua curent si cele din
precedenta :i de van:ri, adic ntre luni si vineri s.a.m.d., dup cum se observ n Iigura 7.5.


Figura 7.5. Diferentele dintre dou :ile consecutive de van:ri
SELECT DataFact AS Zi,
SUM(Cantitate * PretUnit * (1+ProcTVA)) AS Vinzari_Zi_Curenta,
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA))
FROM FACTUR F2 NNER JON LNFACT LF2 ON F2.NrFact=LF2.NrFact
NNER JON PRODUSE P2 ON LF2.CodPr=P2.CodPr
WHERE DataFact N (SELECT MAX(DataFact) FROM FACTUR F3
NNER JON LNFACT LF3 ON F3.NrFact=LF3.NrFact
NNER JON PRODUSE P3 ON LF3.CodPr=P3.CodPr
WHERE DataFact < F.DataFact AND (Cantitate * PretUnit * (1+ProcTVA)) > 0)
) AS Vinzari_Zi_Precedenta,
SUM(Cantitate * PretUnit * (1+ProcTVA)) - COALESCE(
(SELECT SUM(Cantitate * PretUnit * (1+ProcTVA))
FROM FACTUR F2 NNER JON LNFACT LF2 ON F2.NrFact=LF2.NrFact
NNER JON PRODUSE P2 ON LF2.CodPr=P2.CodPr
WHERE DataFact N
(SELECT MAX(DataFact) FROM FACTUR F3
NNER JON LNFACT LF3 ON F3.NrFact=LF3.NrFact
NNER JON PRODUSE P3 ON LF3.CodPr=P3.CodPr
WHERE DataFact < F.DataFact AND (Cantitate * PretUnit * (1+ProcTVA)) > 0)
),0) AS Diferenta
FROM FACTUR F NNER JON LNFACT LF ON F.Nrfact=LF.NrFact
NNER JON PRODUSE P ON LF.CodPr=P.CodPr
GROUP BY DataFact
ArtiIiciul necesar extragerii precendentei zi de vnzri se gseste n subconsultrile din cele
dou interogri scalare. Prn jonctiunea instantelor F3 si LF3 ale tabelelor FACTURI si LINIIFACT si
conditia DataFact < F.DataFact, vor Ii extrase toate liniile din Iacturi ntocmite naintea datei curente
(F este instanta principal a tabelei FACTURI cea care indic ziua curent). Ca msur suplimentar
se precautie se veriIic dac Cantitate * PretUnit * (1+ProcTVA)) > 0 (nu cumva ca s Iie vreo zi n care
apare o Iactur n care liniile s prezinte Cantitate 0, desi situatia aceasta este greu de imaginat).
174 Baze de date
Dintre zilele de vnzare ce preced ziua curent, cea mai apropiat (calendaristic) se extrage prin
Iunctia MAX.
Nu stiu ce ziceti dumneavoastr, dar mie-mi place.
7.3 ACTUALIZAREA TABELELOR PRIN SUBCONSULTRI
Pentru o mai bun priz la public, n cele ce urmeaz apelm la ceea ce se numeste de-
normalizarea bazei de date. n practic, redundanta datelor este, uneori, condamnat cu jumtate de
gur sau chiar apreciat de multi specialisti. Aceasta deoarece un atribut redundant, adugat unei
tabele, poate duce la evitarea jonctiunilor Irecvente, mari consumatoare de resurse. Aplecndu-ne
asupra bazei noastre de date, dac tot ne apucm de treab, n tabela FACTURI adaugm nu mai putin
de trei atribute:
ValTotal reprezint valoarea total (inclusiv TVA) a Iacturii;
Reduceri: ntr-o tar civilizat, ca a noastr, dac un client plteste o Iactur nainte de
termenul obisnuit (s zicem zece zile), i putem acorda o reducere de 5 pentru c ne-am
procopsit rapid cu lichiditti.
Penalit[i: este opusul atributului anterior. Prin contract sau prin lege, dac un client este mai
retinut n a plti Iacturile la timp, i se pot aplica penalitti, Ir a avea ns certitudinea c le-
am putea ncasa vreodat.
Practic, prin aceste noi atribute, urmrirea ncasrii Iacturilor se schimb sensibil. Valoarea de ncasat
dintr-o Iactur este valoarea total plus penalitti minus reduceri. Asta e vestea bun. Vestea proast
tine de Iaptul c atributul ValTotal n-ar trebui s se modiIice dect la actualizarea tabelei
LINIIFACT, nu ? Altminteri, dac utilizatorul ar modiIica, prin UPDATE sau alt mijloc, acest atribut,
ar aprea un decalaj suprtor ntre liniile din Iacturi si valorile acestora. Actualizarea automat a unor
atribute calculate este unul din scopurile declarate ale declansatoarelor (trigger-elor). Adugm cele
trei atribute tabelei FACTURI:
ALTER TABLE FACTUR ADD ValTotala DECMAL(16) ;
ALTER TABLE FACTUR ADD Reduceri DECMAL(15) ;
ALTER TABLE FACTUR ADD Penalizari DECMAL(15) ;
Acum, dac tot le-am creat, s le 'umplem. AstIel, pentru calculul valorii totale a unei Iacturi
avem nevoie de o interogare corelat dup cum urmeaz:
UPDATE FACTUR
SET ValTotala = (
SELECT SUM(Cantitate * PretUnit * (1+ProcTVA))
FROM LNFACT LF NNER JON PRODUSE P ON LF.CodPr=P.CodPr
WHERE NrFact = FACTUR.NrFact
)
Subconsultarea ia n calcul cantitatea, pretul unitar si procentul TVA pentru Iiecare produs
vndut. Prin corelare se vor lua n considerare numai liniile din LINIIFACT (si PRODUSE)
corespunztoare Iacturii curente (linia curent din FACTURI).
Ct priveste atributul Reduceri, instituim urmtoarea regul: se acord o reducere de 5
pentru toate transele unei Iacturi ncasate n termen de 15 zile de la data vnzrii.
UPDATE FACTUR SET Reduceri = (
FEAA nfoEc + CG - 2006/2007 175
SELECT SUM ( CASE WHEN Datanc <= DataFact + NTERVAL '15' DAY
THEN Transa * 0.05 ELSE 0 END)
FROM NCASFACT NCF NNER JON NCASAR ON NCF.Codnc=.Codnc
NNER JON FACTUR F2 ON NCF.Nrfact=F2.NrFact
WHERE F2.NrFact = FACTUR.NrFact
)
Complicm un pic cazul. Acordm 10 pentru transele ncasate n mai putin de 15 zile de la
data vnzrii, 9 pentru 16 zile si 8 pentru 17 zile. Solutia este:
UPDATE FACTUR SET Reduceri = (
SELECT SUM ( CASE
WHEN Datanc <= DataFact + NTERVAL '15' DAY
THEN Transa * 0.1
WHEN Datanc <= DataFact + NTERVAL '16' DAY
THEN Transa * 0.09
WHEN Datanc <= DataFact + NTERVAL '17' DAY
THEN Transa * 0.08
ELSE 0 END)
FROM NCASFACT NCF NNER JON NCASAR
ON NCF.Codnc=.Codnc
NNER JON FACTUR F2 ON NCF.Nrfact=F2.NrFact
WHERE F2.NrFact = FACTUR.NrFact
)
Nu numai modiIicrile pot Ii operate utiliznd subconsultri, corelate sau nu, ci si stergerile.
Spre exemplu, vrem s stergem din tabela FACTURI liniile care nu au nici un copil n LINIIFACT:
DELETE FROM FACTUR WHERE NOT EXSTS
(SELECT 1 FROM LNFACT WHERE LNFACT.NrFact = FACTUR.NrFact)

O solutie mai putin impresionant utilizeaz tot o subconsultare, dar ceva mai putin corelat:
DELETE FROM FACTUR WHERE NrFact NOT N
(SELECT DSTNCT NrFact FROM LNFACT)

176 Baze de date
BIBLIOGRAFIE
|Airinei s.a. 04| Airinei, D., Filip, M., Grama, A., Fotache, M., Fnarul, L., Dumitriu, F., Tugui, A. Medii de
programare (editia a IJ-a), Editura Sedcom Libris, Iasi, 2004

|Bsc97| Bsc, O. Ba:e de date, Editura All, Bucuresti, 1997

|Bernstein76| Bernstein, A.B. Svnthesi:ing Third Normal Form Relations from Functional Dependencies,
ACM Transactions on Database Systems, Vol. 1, no.4, dec. 1976

|Boyce s.a. 75| Boyce, R.F., Chamberlin, D.D., King, W.F., Hammer, M.M. Specifving Queries as Relational
Expresions. The SQUARE Data Sublanguage, CACM 18, No 11, 1975

|Casanova s.a. 82| Casanova, M.A., Fagin, R., Papadimitrou, C.H. - Inclusion dependencies and their interaction
with functional dependencies, Proc. oI the 1st ACM SIGACT-SIGMOD symposium on Principles oI database
systems, Los Angeles, 1982

|Celko99| Celko, J. Joe Celkos Data and Databases. Concepts in Practice, Morgan KauImann, San
Francisco, 1999

|Chamberlin&Boyce 74| Chamberlin, D., Boyce, R.F. - SEQUEL. A Structured English Querv Language, ACM
- SIGMOD Workshop on Data Description, Access, and Control, Ann Arbor, Michigan, May 1974

|Chamberlin s.a. 76| Chamberlin, D. s.a. - SEQUEL 2. Definition, Manipulation and Control, IBM J. Research
and Development 20, no.6, nov. 1976

|Chamberlin80| Chamberlin, D. - A Summarv of User Experience with the SQL Data Sublanguage, Proc. oI
International ConIerence on Data Bases, Aberdeen, July 1980

|CODASYL69| CODASYL Systems Committee - A Survev of Generali:ed Data Base Management Svstems,
Technical Report, May 1969

|Codd69| Codd, E.F. - Derivabilitv, Redundancv and Consistencv of Relations Stored in Large Data Banks,
IBM Research Report RJ 599, august 1969

|Codd70| Codd, E.F. - A Relational Model of Data for Large Shared Data Banks, CACM, vol. 13, no.6, 1970

|Codd72| Codd, E.F. Further Normali:ation of the Database Relational Model, DataBase Systems, Courant
Computer Science Symposia Series, Vol.6, Englewood CliIIs, N.J.,Prentice-Hall, 1972

|Codd79| Codd, E.F. - Extending the Database Relational Model to Capture More Meaning, ACM Transactions
on Database Systems, vol. 4, no.4, Dec. 1979

|Connoly s.a.96| Connolly, T., Begg, C.E., Strachan, A.D. Database Svstems. A practical Approach to Design,
Implementation and Management, Addison-Wesley, Harlow, 1996

|Connoly&Begg 02| Connolly, T., Begg, C.E. Database Svstems. A practical Approach to Design,
Implementation and Management, 3rd edition, Addison-Wesley, Harlow, 2002

|Date86| Date, C.J. - An Introduction to Database Svstems, Addison-Wesley, Reading, Massachussets, 4
th

edition, 1986

|Date00| Date, C.J. An Introduction to Database Svstems, 7th edition, Addison-Wesley, Reading,
Massachussets, 2000

|Date04| Date, C.J. An Introduction to Database Svstems, 8th edition, Pearson Addison-Wesley, Boston, 2004

FEAA nfoEc + CG - 2006/2007 177
|Dodescu s.a.87| Dodescu, G, s.a. - Informatica, Editura StiintiIic si Enciclopedic, Bucuresti, 1987

|Dollinger98| Dollinger, R. Ba:e de date i gestiunea tran:actiilor, Editura Albastr, Cluj-Napoca, 1998

|Elmasri & Navathe 00| Elmasri, R., Navathe, S.R. - Fundamentals of Database Svstems, Addison-Wesley,
Reading, Massachussetts, 2000

|Fagin77| Fagin, R. Multivalued Dependencies and a New Normal Form for Relational Databases, ACM
Transactions on Database Systems, Vol.2, No.3, Sept. 1977

|Fagin81| Fagin, R. A Normal Form for Relational Databases That Is Based on Domains and Kevs, ACM
Transactions on Database Systems, Vol.6, No.3, Sept. 1981

|Fleming & vonHalle 89| Fleming, C., von Halle, B. Handbook of Relational Database Design, Addison-
Wesley, Reading, Mass. 1989

|Fotache97| Fotache, M. Ba:e de date relationale. Organi:are, interogare i normali:are, Editura Junimea,
Iasi, 1997

|Fotache s.a. 01| Fotache, M. SQL. Dialecte DB2, Oracle i Jisual FoxPro, Editura Polirom, Iasi, 2001

|Fotache s.a. 03| Fotache, M., Strmbei, C., Cretu, L. Oracle 9i2. Ghidul de:voltrii aplicatiilor profesionale,
Editura Polirom, Iasi, 2003

|Fotache 2005| Fotachem, M. Proiectarea ba:elor de date. Normali:are i postnormali:are. Implementri SQL
i Oracle, Editura Polirom, Iasi, 2005

|Garcia-Molina s.a. 02| Garcia-Molina, H., Ullman, J., Widom, J. - Database Svstems. The complete Book,
Prentice Hall, Upper Saddle Riner, New Jersey, 2002

|Grama s.a. 06| Grama, A., Fotache, M., Tugui, A., Dumitriu, F. Instrumente software pentru afaceri, Editura
Universittii ,Al.I.Cuza, Iasi, 2006

|Hainaut94| Hainaut, J.L. Bases de donnees et modeles de calcul. Outils et methodes pour lutilisateur,
InterEditions, Paris, 1994

|Harrington 02| Harringtom, J.L. - Relational Database Design Clearlv Explained, 2nd ed., Morgan KauIman,
Amsterdam, 2002

|Johnson & Klug82| Johnson, D.S., Klug, A. - Testing containment of confuctive queries under functional and
inclusion dependencies, Proc. oI the 1st ACM SIGACT-SIGMOD symposium on Principles oI database
systems, Los Angeles, 1982

|Korth&Silberschatz 88| Korth, H.F., Silberschatz, A. Svstemes de gestion des bases de donnees, McGraw-
Hill, Paris, 1988

|Lonigro98| Lonigro, M. - The Case for the Surrogate Kev, DataBase Programming & Design, May 1998
(Online Extra), http://www.dbpd.com/vault/9805xtra.htm

|Lungu s.a. 95| Lungu, I., Bodea, C., Bdescu, G., Ionit, C. Ba:e de date. Organi:are, proiectare i
implementare, Editura All, Bucuresti, 1995

|Miranda&Busta 90| Miranda, S., Busta, J.M. - L art des bases de donnees, vol. I-II, Eyrolles, Paris, 1990

|O'Neil & O'Neil 01| O'Neil, P., O'Neil, E. - Database. Principles, Programming, Performance, Morgan
KauImann, San Francisco, 2001

|Oprea99| Oprea, D. Anali:a sistemelor informationale, Editura Polirom, Iasi, 1999

178 Baze de date
|Oprea s.a.02| Oprea, D., Airinei, D., Fotache, M. (coordonatori) Sisteme informationale pentru afaceri,
Editura Polirom, Iasi, 2002

|Pascal00| Pascal, F. Practical Issues in Database Management. A Reference for the Thinking Practitioner,
Addison-Wesley, 2000

|Popescu96| Popescu, I. Ba:e de date relationale, Editura Universittii Bucuresti, 1996

|Popescu01| Popescu, I. Modelarea ba:elor de date, Editura Tehnic, Bucuresti, 2001

|Pratt&Adamski91| Pratt, P.J., Adamski, J.J. Database Svstems. Management and Design, 2
nd
ed.,
Boyd&Fraser, Boston, 1991

|Riordan99| Riordan, R. Designing Relational Database Svstems, MicrosoIt Press, 1999

|Saleh94| Saleh, I. - Les bases de donnees relationnels. Conception et realisation, Hermes, Paris, 1994

|Sciore 83| Sciore, E. - Inclusion Depedencies and the Universal Instance, Proc. oI the 2nd ACM SIGACT-
SIGMOD symposium on Principles oI database systems, Atlanta, Georgia, 1983

|Simsion01| Simsion, G. - Data Modeling Essentials. Analvsis, Design, and Innovation, 2nd edition, Coriolis,
Scottsdale, Arizona, 2001

|Smith85| Smith, H.C. - Database Design. Composing Fullv Normali:ed Tables From a Rigourous Dependencv
Diagram, Communication oI the ACM, Vol. 28, No. 8, August, 1985

|Teorey99| Teorey, T.J. Database Modelling & Design, Morgan KauImann, San Francisco, 1999

|Wu92| Wu, M.S. - The Practical Need for Fourth Normal Form, Proc. oI the 23rd ACM SIGCSE technical
symposium on Computer Science education, Kansan City, Missouri, 1992
FEAA nfoEc + CG - 2006/2007 179
Anexa 1
SCHEMA BAZEI DE DATE VNZRI

Pentru baza de date VNZRI, reprezentarea graIic a schemei simpliIicate este cea din Iigura
A.1.

Figura A.1.(i 2.5). Schema simplificat a ba:ei de date JINZRI

Tabela 1UDETE contine inIormatii generale despre judetele n care sunt clienti.
Fiecare linie a tabelei descrie un judet. Atributele sunt:
Jud indicativul auto al judetului (alctuit din dou litere, majuscule);
Judet denumirea judetului;
Regiune regiunea istoric (provincia) din care Iace parte judetul.
Cheia primar este atributul Jud. Atributul Judet este cheie alternativ. Pot Ii instituite o serie
de restrictii-utilizator:
180 Baze de date
Jud este alctuit numai din majuscule (eventual, un spatiu, pentru Bucuresti);
Fiecare cuvnt din Judet ncepe cu majuscul; restul literelor sunt mici;
Regiune ncepe cu majuscul; restul literelor sunt mici;
Regiune poate avea numai una din valorile: Banat, Dobrogea, Muntenia, Oltenia,
Transilvania, Moldova.

Tabela CODURI_POSTALE contine cte o linie pentru Iiecare codpostal dintr-un
oras sau comun.
CodPost;
Loc denumirea comunei/orasului;
Jud indicativul auto al judetului.

Cheia primar este atributul CodPost. Atributul Jud este cheie strin, tabela printe Iiind
JUDETE (prin atributul Jud). Pot Ii instituite o serie de restrictii-utilizator:
Jud este alctuit numai din majuscule (eventual, un spatiu, pentru Bucuresti)
Fiecare cuvnt din Localitate ncepe cu majuscul; restul literelor sunt mici

Tabela CLIENTI grupeaz date generale ale clientilor Iirmei pentru care s-a constituit
baze de date (o linie un client). Atribute:
CodCl codul clientului;
DenCl denumirea clientului (persoan juridic);
CodFiscal codul Iiscal;
Adresa adresa sediului Iirmei client;
CodPost codul postal al comunei sau orasului;
Telefon teleIonul (principal) al clientului.
Cheia primar este atributul CodCl. Atributul CodPost este cheie strin, tabela printe Iiind
LOCALITATI (prin atributul CodPost). DenCl si Adresa ncep cu majuscule. Dup cum punctam
anterior, valorile nule indic o lips de inIormatie. Pentru primul client nu se cunoaste teleIonul, celui
de-al doilea adresa etc.

Tabela PERSOANE are ca obiectiv stocarea datelor despre persoanele cheie de la
Iirmele client: directori generali, directori Iinanciari, seIi ai compartimentelor comerciale
(aprovizionare si/sau vnzri) etc. Probabil c vi se pare ciudat, dar ceea ce intentionm cu aceast
tabel (si urmtoarea) este s sprijinim fideli:area clientului. Nu cost (mai) nimic dac de SIntul Ion
se trimite cte o Ielicitare tuturor Ionilor si Ioanelor din partea Iirmei noastre. Iar pentru ca lucrurile s
Iie si mai bine puse la punct, ar Ii trebuit s prelum si inIormatii precum: data nasterii, starea civil,
numele si vrsta copiilor, pasiuni n materie de muzic, arte pastice, literatur, sport etc. Schema luat
n considerare s-a oprit la urmtoarele atribute:
CNP codul numeric al persoanei;
Nume;
Prenume;
Adresa;
FEAA nfoEc + CG - 2006/2007 181
Sex;
CodPost;
TelAcas numrul teleIonului de acas;
TelBirou numrul teleIonului (Iix) de la birou;
TelMobil numrul 'mobilului;
Email adresa e-mail.
Desi este un numr compus din 13 pozitii, este recomandabil ca CNP s Iie declarat de tip sir
de caractere. Aceasta deoarece n Iirm exist rezidenti din Republica Moldova care au pozitii de vrI
n Iirme romnesti (sau reprezentante ale unor Iirme din tara natal). Or, codul identiIicator din
pasaport este alctuit dintr-o liter si o serie de ciIre.
Cheia primar este atributul CNP. Fiind vorba de persoane exterioare ntreprinderii, un atribut
precum Marca este mai putin indicat. CNPul este greoi, relativ lung (de aceea am preIerat s scriem,
pur si simplu CNP1, CNP2.), dar stabil si unic.
Atributul CodPost este cheie strin, tabela printe Iiind LOCALITATI (prin atributul
CodPost).
Celei de-a doua persoane nu i se cunoaste domiciliul (adresa). Cu exceptia lui Vasile Ion,
nimeni nu are cont deschis pentru posta electronic.
Alte restrictii utilizator:
Fiecare cuvnt din Nume si Prenume ncepe cu majuscul; restul literelor sunt mici;
Adresa ncepe cu majuscul;
Atributul Sex poate lua numai dou valori: B de la Brbtesc si F de la Femeiesc.

Tabela PERSCLIENTI indic Iunctia detinut de Iiecare persoan la unul (sau mai
multi, desi aceste cazuri sunt rare) clienti. O linie din aceast tabel reIlect o Iunctie detinut de o
persoan la un client. O persoan poate avea mai multe Iunctii, chiar la aceeasi Iirm (cumul de
Iunctii). Cele trei atribute sunt:
CNP persoana care detine Iunctia;
CodCl Iirma la care persoana detine Iunctia;
Functie Iunctia detinut.
Cheia primar este compus din toate cele trei atribute: CNP+CodCl+Functie, aceasta
deoarece am convenit c o aceeasi persoan poate cumula dou sau mai multe Iunctii la aceiasi Iirm.
CNP si CodCl sunt chei strine, tabelele printe Iiind PERSOANE, respectiv CLIENTI. Atributul
Functie ncepe cu majuscul, restul literelor Iiind mici.

Tabela PRODUSE reprezint nomenclatorul de produse si servicii pe care le
comercializeaz Iirma (produsele sunt obtinutele prin manuIacturare sau revnzare). Atribute:
CodPr codul produsului;
DenPr denumirea;
UM unitatea de msur a produsului;
Grupa grupa de mrIuri (sortimente) n care se ncadreaz; acest atribut este important
pentru analiza vnzrilor;
182 Baze de date
ProcTVA procentul TVA care se aplic la pretul de vnzare (pret care este Ir TVA); pare
de prisos n conditiile actuale, cnd toate produsele au un singur procent, 19, dar nimeni nu poate
garanta cum vor gndi promotiile viitoare de guvernanti 'relaxarea Iiscal;
Cheia primar este atributul CodPr. Alte restrictii utilizator:
DenPr si Grupa ncep cu majuscul; restul literelor sunt mici;
unitatea de msur (UM) se scrie numai cu litere mici.
Tabela pare una 'inoIensiv, dar de modul su de organizare depinde rezolvarea unor pro-
bleme deosebit de sensibile. Este Ioarte important de stabilit regimul n care se va lucra cu produsele
care se comercializeaz sub mai multe Iorme. Dup cum se observ, atributul DenPr nu a Iost declarat
cheie alternativ. De ce ? S lum un exemplu absolut la ntmplare: o Iirm de comert en-gross vinde
(legal), printre altele, produsul Jodc Scandic si la cutii de 1 litru si la cutii de 250 ml.
Desi este acelasi produs (din prea-numeroasele mele ncercri, gustul este acelasi (sau, cel
putin, asa mi amintesc), indiIerent de tipul cutiei), pentru o evident corect a vnzrilor, este necesar
ca n tabela PRODUSE s existe dou linii aIectate vodcii Scandic, Iie ca n Iigura 1.19, Iie ca n
Iigura 1.20.

Figura 1.19. Specificarea, n DenPr, a tipului cutiei

Figura 1.20. Diferen[ierea (n afar de cod) numai prin UM

Este diIicil de spus care variant este mai bun. Eu, unul, as nclina pentru cea de-a
doua, caz n care atributul DenPr nu este cheie candidat.

Tabela FACTURI contine cte o linie pentru Iiecare Iactur emis, Iactur ce reIlect
o vnzare (ctre un client). Atribute:
NrFact numrul Iacturii;
DataFact data ntocmirii Iacturii;
CodCl codul clientului cruia i s-au vndur produsele/serviciile consemnate n Iactur;
Obs observatii; e Iolosit relativ rar, pentru a introduce aventuale detalii sau probleme care
au aprut n legtur cu o Iactur.
Cheia primar este atributul NrFact. Explicatia este una simpl: gestionarea Iacturilor emise
este, conIorm legii, strict. Nu pot exista dou Iacturi (care reIlect dou vnzri) cu un acelasi numr.
Sau, de Iapt, pot exista, dar aceasta nseamn o ilegalitate destul de grav (se mai poart nc prin
economia subteran). CodCl este cheie strin (tabela printe este CLIENTI). Ca restrictie utilizator
suplimentar, nu pot Ii introduse Iacturi ntocmite nainte de 1 august 2005 (DataFact ~
DATE`2005-08-01`).

FEAA nfoEc + CG - 2006/2007 183
Tabela LINIIFACT detaliaz tabela precedent. Un tuplu se reIer la un
produs/serviciu vndut si consemnat ntr-o Iactur emis. Pentru Iiecare Iactur vor Ii attea linii cte
produse/servicii au Iost consemnate la vnzarea respectiv. Atribute:
NrFact numrul Iacturii;
Linie numrul liniei din Iactura respectiv;
CodPr codul produsului/serviciului vndut;
Cantitate cantitatea vndut;
PretUnit pretul unitar (Ir TVA) la care s-a Icut vnzarea.
Cheia primar este combinatia NrFact+Linie. NrFact si CodPr sunt chei strine. Pentru a
determina valoarea de ncasat a unei Iacturi (inclusiv TVA), la valoarea Ir TVA pentru Iiecare linie
(obtinut prin produsul Cantitate * PretUnit) trebuie adugat TVA colectat, obtinut prin aplicarea
procentului de TVA al produsului/serviciului (atributul ProcTVA din PRODUSE) la valoarea Ir
TVA.

Tabela INCASARI reprezint un nomenclator al ncasrilor. Printr-o ncasare, un
client si stinge una sau mai multe obligatii de plat, adic achit una sau mai multe Iacturi.
Documentul primar pe baza cruia se consemneaz ncasarea poate Ii ordinul de plat, cecul, chitanta
etc. Atributele tabelei sunt:
Codnc codul ncasrii este un numr intern, util pentru a diIerentia o ncasare de celelalte;
Datanc data ncasrii - data la care banii au intrat n contul sau casieria Iirmei;
CodDoc codul documentului justiIicativ al ncasrii: OP ordin de plat, CHIT chitant,
CEC Iil cec;
NrDoc numrul documentului justiIicativ
DataDoc data la care a Iost ntocmit documentul justiIicativ; din momentul ntocmirii
documentului de plat pn la data la care banii ajung eIectiv n cont/casierie trec cteva zile sau
sptmni (datorit circuitului documentelor ntre Iirme si bnci).
Cheia primar este atributul Codnc. Ca restrictii utilizator pot Ii instituite:
data ncasrii nu o poate precede pe cea a ntocmirii documentului (DataDoc Datanc);
data documentului de ncasare nu poate Ii anterioar datei de nceput a aplicatiei: 1 august
2005 (DataDoc ~ DATE`2005-08-01`);
codul documentului se scrie numai cu majuscule.


Tabela INCASFACT detaliaz tabela precedent si indic ce Iacturi (transe din
Iacturi) sunt achitate prin Iiecare ncasare. Un client poate plti mai multe Iacturi odat (printr-o
singur plat). Pe de alt parte, orice Iactur poate Ii pltit n una sau mai multe transe, n Iunctie de
banii de care dispune clientul la momentul ntocmirii documentului de plat. Atributele tabelei sunt:
Codnc codul ncasrii;
NrFact Iactura pentru care se ncaseaz valoarea integral sau numai o trans;
Transa transa din Iactur (sau ntreaga valoare) care se ncaseaz prin documentul primar ce
st la baza ncasrii.
184 Baze de date
Cheia primar este combinatia Codnc+NrFact, deoarece la o ncasare se pot achita mai
multe Iacturi, iar, pe de alt parte, o Iactur poate Ii pltit n mai multe transe. Codnc si NrFact sunt
chei strine.


Comentarii suplimentare privind restric(iile referen(iale
Instituirea unei restrictii reIerentiale ntr-o baz de date interzice aparitia de valori
nenule n tabele copil care nu se regsesc n tabelele printe (linii orIane). De aceea, la inserarea unei
linii ntr-o tabel copil sau modiIicarea unei chei strine, SGBD-ul trebuie veriIice dac noile valorile
se regsesc n linii printe.
Inserarea unei linii ntr-o tabel printe, ca si stergerea de linii dintr-o tabel copil nu
prezint nici un pericol 'reIerential.
La stergerea unei linii dintr-o tabel printe trebuie precizat cum se va prezerva
restrictia reIerential: Iie prin stergerea n cascad a tuturor nregistrrilor copil (ON DELETE
CASCADE), Iie, pur si simplu, prin interzicerea stergerii (ON DELETE RESTRICT).
n Iine, la modiIicarea unei chei primare/alternative pentru care exist, n alte tabele,
nregistrri-copil, trebuie precizat actiunea ntreprins de SGBD: modiIicarea n cascad a tuturor
liniilor copil (ON UPDATE CASCADE) sau interzicerea modiIicrii dac exist cel putin o
nregistrare copil (ON UPDATE RESTRICT).

Pentru exempliIicare, s lum cazul tabelei FACTURI si trei situatii legate de
actualizarea acesteia.
Inserarea unei linii. Deoarece FACTURI este legat (ca tabel copil) prin restrictie
reIerential de tabela CLIENTI (printe), trebuie veriIicat dac valoarea CodCl exist n CLIENTI.
Dac nu, inserarea trebuie prohibit.
Modificarea unei linii. Aici sunt dou situatii, corespunztoare posturilor de printe si copil a
tabelei modiIicate. AstIel:
dac se modiIic valoarea atributului CodCl, trebuie veriIicat dac aceasta se regseste n
CLIENTI si, dac nu, operatiunea trebuie anulat;
dac se modiIic valoarea lui NrFact, atunci trebuie testat dac exist nregistrri copil n
tabelele LINIIFACT si INCASFACT. Dac da,
Iie se interzice modiIicarea (ON UPDATE RESTRICT),
Iie se modiIic n cascad toate liniile copil - valorile NrFact din LINIIFACT si INCASFACT
(ON UPDATE CASCADE).
Fireste, nu e obligatoriu ca actiunea s Iie identic pentru ambele tabele copil. Cu alte cuvinte,
se poate recurge, pentru LINIIFACT la ON UPDATE CASCADE, iar pentru INCASFACT la ON
UPDATE RESTRICT.
Stergerea unei linii. atunci trebuie testat dac exist nregistrri copil n tabelele LINIIFACT
si INCASFACT. Dac da,
Iie se interzice stergerea (ON DELETE RESTRICT),
Iie se sterg n cascad toate liniile copil din LINIIFACT si INCASFACT (ON DELETE
CASCADE).
FEAA nfoEc + CG - 2006/2007 185

Exist diIerente semniIicative ntre SGBD-uri n privinta deIinirii actiunilor ce trebuie
ntreprinse pentru respectarea integrittilor reIerentiale. Unele produse, Iireste, dintre cele mai bine
cotate, permit, la declararea restrictiilor reIerentiale (este de obicei, simultan cu crearea tabelelor),
instituirea oricrei reguli din cele patru: ON UPDATE CASCADE, ON UPDATE RESTRICT, ON
DELETE CASCADE, ON DELETE RESTRICT.
Altele, precum Oracle, permit declarea actiunilor numai pentru stergere, ON DELETE
CASCADE si ON DELETE RESTRICT. Pentru modiIicarea n cascad sunt necesare declansatoare
speciale construite n limbajul de dezvoltare PL/SQL.