Capitolul 2.

Modelul relaional de
organizare a datelor
Ca n attea alte domenii, i n teoria i practica bazelor de date se manifest o
dorin apsat de a scpa de btrni, de a ncerca i altceva. Modelul relaional
este btrnul care nu vrea s se retrag. Comparaia cu Ion Iliescu se oprete aici,
modelul relaional fiind infinit mai benefic pentru istoria recent a omenirii.
Aprut la nceputul anilor 70, modelul s-a dovedit a avea oarecum soarta rock-
ului acelorai ani, cu contestatari destul de vocali, dar cu nlocuitori mult mai palizi
(ex. disco-ul, punk-ul), la propriu, la figurat i mai ales la trecerea timpului.
Afirmaia de mai sus este incorect politic, imposibil de demonstrat tiinific i
degrab aductoare de ranchiun. Aa c nu are rost s v enervai (mai bine v
punei CD-ul cu albumul London Calling al celor de la The Clash). Lumea
academic, n general, lumea liber-schimbist n ale bazelor de date fremta, spre
finalul anilor 80 i nceputul 90, la ideea c relaionalul i-a gsit naul n persoana
modelului obiectual. Statisticile indicau c n anul 2000, odat cu sfritul lumii,
bazele de date orientate pe obiecte vor trece de 50% din pia. Dup cum spuneam
n primul capitol, nici n prezent procentul BDOO nu ar trece de 5 sau 6 %.
N-a vrea s nelegei c relaionalul nu va fi depit ntr-o zi de obiectual sau
de alt model (sau post-model, cum este XML-ul). De asemenea, mrturisesc c nu
am (deocamdat) contract cu modelul relaional. Afirmaia la care subscriu este c
modelul relaional s-a dovedit un model bun i, din multe puncte de vedere, este
nc valabil pentru gestiunea datelor n firme i organizaii, att sub forma sa
original, ct mai ales mbogit cu tipuri de date definite de utilizator (vezi
capitolul 19).
Modelul relaional de organizare a datelor s-a conturat n dou articole
publicate n 1969 i 1970 de ctre E.F. Codd, matematician la centrul de cercetri
1
din San Jose (California) al firmei IBM . n acel moment, tehnologia bazelor de
date era centrat pe modelele ierarhic i reea, modele ce depind ntr-o mai mare
msur de organizarea intern a datelor pe suportul de stocare (celebrii pointeri pe
care i-am pomenit fr a-i arta n primul capitol). Codd a propus o structur de
date tabelar, independent de tipul de echipamente i software de sistem pe care

1 Extrase din lucrarea [Codd 1970] se gsesc la adresa http://www.acm.org/classics/nov95/. De

asemenea, o excelent analiz a articolelor lui Codd este n [Date 1998].
32 Capitolul 2

este implementat, structur "nzestrat" cu o serie de operatori pentru extragerea

datelor. Dei puternic matematizat, modelul relaional este relativ uor de neles.
Fa de modelele ierarhice i reea, modelul relaional prezint cteva avantaje:
propune structuri de date uor de utilizat;
amelioreaz independena logic i fizic;
pune la dispoziia utilizatorilor limbaje ne-procedurale;
optimizeaz accesul la date;
mbuntete integritatea i confidenialitatea datelor;
permite tratarea unei largi varieti de aplicaii;
abordeaz metodologic definirea structurii bazei de date (normalizarea).

Dei puternic contestat, i cu neajunsurile sale, modelul relaional de organizare

a bazelor de date rmne cel mai utilizat. Cu foarte puine excepii, toate aplicaiile
software realizate pentru bnci, buticuri, universiti (ordinea este, n ciuda
aparenelor, pur ntmpltoare) sunt realizate cu produse/instrumente ce
gestioneaz baze de date relaionale sau relaional-obiectuale.
Un model de date are trei piloni: componenta structural, adic modul n care,
efectiv, la nivel logic, datele sunt stocate n baz, componenta de integritate, adic
regulile/restriciile ce pot fi declarate pentru datele din baz, i o component
manipulatorie, adic modul n care obinem informaii din bazele de date (ceea ce
presupune o serie de operatori aplicabili uneia sau mai multor relaii). Modelului
relaional i este asociat teoria normalizrii, care are ca scop prevenirea
comportamentului aberant al relaiilor n momentul actualizrii lor, eliminarea
datelor redundante i nlesnirea nelegerii legturilor semantice dintre date2.
Prezentul capitol va fi dedicat componentei structurale i celei de integritate din
modelul relaional.

2.1. Structura
Modelul relaional al datelor se poate defini printr-o serie de structuri de date
(relaii alctuite din tupluri), operaii aplicate asupra structurilor de date (selecie,
proiecie, jonciune etc.) i reguli de integritate care s asigure consistena datelor
3
(chei primare, restricii refereniale s.a.) .

2 Pentru detalii privind normalizarea, vezi (i) [Fotache2005], [Sitar-Tut2006].

3 Codd este cel care impune cele trei axe de discuie ale unui model de date: structur, integritate i
manipulare. Vezi [Codd 1981].
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 33

La modul simplist, o baz de date relaional (BDR) poate fi definit ca un

ansamblu de relaii (tabele); fiecare tabel (sau tabel), alctuit din linii (tupluri),
are un nume unic i este stocat pe suport extern (de obicei disc). La intersecia
unei linii cu o coloan se gsete o valoare atomic (elementar, nedecompozabil).
O relaie conine informaii omogene legate de anumite entiti, procese, fenomene:
CRI, STUDENI, LOCALITI, PERSONAL, FACTURI etc. Spre exemplu, n
figura 2.1 este reprezentat tabela CLIENI.

Figura 2.1. Relaia (tabela) CLIENI

Teoria relaional folosete termenul relaie. Practica, ns, a consacrat termenul
tabel (engl. table). Un tuplu sau o linie este o succesiune de valori de diferite tipuri.
n general, o linie (re)grupeaz informaii referitoare la un obiect, eveniment etc.,
altfel spus, informaii referitoare la o entitate: o carte (un titlu sau un exemplar din
depozitul unei biblioteci, depinde de circumstane), un/o student(), o localitate
(ora sau comun), un angajat al firmei, o factur emis etc. Figura 2.2 conine al
doilea tuplu din tabela CLIENI, tuplu referitor la firma MODERN SRL. Linia este
alctuit din patru valori ce desemneaz: codul, numele, adresa i codul potal al
localitii i adresei referitoare la clientul MODERN SRL.

Figura 2.2. Un tuplu al tabelei CLIENI

Teoretic, orice tuplu reprezint o relaie ntre clase de valori (n cazul nostru, ntre
patru clase de valori); de aici provine sintagma baze de date relaionale, n sensul
matematic al relaiei, de asociere a dou sau mai multe elemente. Firete, toate
tuplurile relaiei au acelai format (structur), ceea ce nseamn c n tabela
CLIENI, din care a fost extras linia din figura 2.2, fiecare linie este constituit
dintr-o valoare a codului, o valoare a numelui, o valoare a adresei, i o valoare a
codului potal. Ordinea tuplurilor nu prezint importan din punctul de vedere al
coninutului informaional al tabelei.
34 Capitolul 2

Fiecare atribut este caracterizat printr-un nume i un domeniu de valori pe care le

poate lua. Domeniul poate fi definit ca ansamblul valorilor acceptate (autorizate)
pentru un element component al relaiei:
ntr-o tabel destinat datelor generale ale angajailor, pentru atributul Sex,
domeniul este alctuit din dou valori: Femeiesc i Brbtesc;
pentru atributul Regiune, domeniul, dei limitat, este ceva mai mare;
valorile autorizate pot fi: Dobrogea, Banat, Transilvania, Oltenia, Muntenia,
Moldova.
domeniul atributului Jud este alctuit din indicativele auto (dou
caractere) ale fiecrui jude (plus Bucureti).
domeniul atributului Judet este alctuit din numele fiecrui jude (plus
Bucureti).
domeniul unui atribut precum PreUnitar, care se refer la preul la care a
fost vndut un produs/serviciu, este cu mult mai larg, fiind alctuit din
orice valoarea cuprins ntre 1 i 999999.994 lei (ceva mai noi).
Firete, n funcie de specificul bazei de date, domeniul poate fi extins sau
restrns dup cerine. De exemplu, la regiunile luate n discuie mai sus, mai pot fi
adugate i provincii precum: Bucovina, Maramure, Criana.

i acum, cteva senzaii tari (urmeaz un pic de matematic) ! Dac notm cu

D1 domeniul atributului CodClient, cu D2 domeniul atributului NumeClient, cu D3
domeniul pentru Adresa, i cu D4 domeniul atributul CodPostal, se poate spune c
fiecare linie a tabelei CLIENI este un tuplu de patru elemente,

(v1 , v 2 , v 3 , v 4 ) unde v 1 D1 , v 2 D 2 , v 3 D 3 , v 4 D 4
iar relaia n ansamblu corespunde unui subansamblu din ansamblul tuturor
tuplurilor posibile alctuite din patru elemente, ansamblu care este produsul
cartezian al celor patru domenii.
4
Di
i =1

Generaliznd, orice relaie R poate fi definit ca un subansamblu al produsului

cartezian de n domenii Di:

4 Punctul indic marca, zecimal, cei doi de nou ce urmeaz punctului fiind asociai banilor
(subdiviziunii leului).
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 35

R D1 x D2 x D3 x ... x Dn ,
n fiind gradul sau ordinul relaiei. Relaiile de grad 1 sunt unare, cele de grad 2 -
binare, ..., cele de grad n - n-are. Aceast definiie pune n eviden aspectul
constant al relaiei, de independen n timp (se spune c n acest caz relaia este
definit ca un predicat).
O a doua definiie abordeaz o relaie R ca un ansamblu de m-uplete (m-
tupluri) de valori:
R = { t 1 , t 2 , ..., t k , ..., t m}, unde t k = (dk1 ,dk2 , ..., d ki ,...,dkn )
n care:
dk1 este o valoare n D1, dk2 este o valoare n D2, , dkn este o valoare n Dn;
n - reprezint ordinul lui R;
m - cardinalitatea lui R.
Pentru un (mic) plus de claritate, vezi figura 2.3. Reprezentarea sub form de
tabel, deci ca ansamblu de tupluri, pune n eviden aspectul dinamic, variabil al
relaiei. Abordarea predicativ (prima definiie) sau ansamblist (a doua definiie)
reprezint un criteriu important de delimitare a limbajelor de interogare a bazelor
de date relaionale.

Figura 2.3. Ilustrarea celei de-a doua definiii a unei relaii

Avnd n vedere cele dou definiii ale relaiei, se poate reformula conceptul de
atribut, ca fiind elementul care determin ansamblul de valori luate de fiecare
36 Capitolul 2

5
domeniu al relaiei . Precizarea fr ambiguitate a rolului jucat de fiecare domeniu
n cadrul relaiei impune ca numele atributelor s fie diferite. O relaie poate fi
simbolizat i astfel:

R(A1 , A 2 ,..., A n ) sau (A1 : D 1 , A 2 : D 2 ,..., A n : D n )

unde Ai sunt atributele relaie.

Reinem corespondena noiunilor relaie-tabel, tuplu-linie i atribut-coloan.

Numrul de tabele, atributele adunate n fiecare tabel, domeniul fiecruia

dintre atribute prezint diferene majore de la o baz la alta, chiar dac uneori
reflect acelai tip de procese. Intrm astfel n sfera proiectrii bazelor de date, a
dependenelor i normalizrii.
Relaia CLIENI conine informaii despre firmele crora compania noastr le
vinde produsele pe care le producem i/sau comercializm. Fiecare linie se refer
la un singur client. n figura 2.1 pe a treia linie a tabelei apare o valoarea curioas
notat NULL. Valoarea NULL este considerat o metavaloare i indic faptul c, n
acel loc, informaia este necunoscut, inexistent sau inaplicabil (n acest caz nu
cunoatem adresa clientului Modern SRL), fiind valabil indiferent de tipul
atributului (numeric, ir de caractere, date calendaristice). Valoarea NULL este
diferit, ns de valorile 0 sau spaiu. Uneori, importana sa este (din pcate)
major n expresii i funcii, dup cum tiu cei cu oarecare experien n limbajul
SQL.

Principalele caracteristici ale unei relaii pot fi, astfel, sistematizate dup cum
urmeaz:
- n cadrul unei baze de date, o relaie prezint un nume distinct de al
celorlalte relaii.
- Valoarea unui atribut ntr-un tuplu oarecare este simpl (atomic sau
elementar).
- Fiecare atribut are un nume distinct.
- Orice valoare a unui atribut face parte din domeniul pe care a fost definit
acesta.
- Ordinea dispunerii atributelor n relaie nu prezint importan.
- Fiecare tuplu este distinct, adic nu pot exista dou tupluri identice ntr-o
aceeai relaie.

5 [Saleh 1994],p.29
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 37

- Ordinea tuplurilor nu influeneaz coninutul informaional al relaiei.

Structura unei baze de date mai cuprinde restricii i alte obiecte discutate n
paragrafele 2.2 i 2.3.

2.2. Restricii
De ce ne intereseaz restriciile ntr-o baz de date ? Termenul de restricie
(regul sau constrngere) este oarecum iritant, att pentru studeni, ct i pentru
profesori, deoarece semnaleaz existena unor constrngeri instituite i oarecum
obligatorii, i, 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 restriciilor este (supra)vegheat de o anumit autoritate nzestrat cu
anumite instrumente de constrngere, de la bastoane de cauciuc, la creterea i
scderea impozitelor, salariilor, banilor de buzunar etc.
Ei bine, n bazele de date, regulile sunt ceva mai acceptabile. Cei care lucreaz
cu bazele de date sunt foarte interesai n declararea restriciilor, pentru c, odat
definite, de respectarea lor se va ngriji SGBD-ul. Esenial este c, ajutai de reguli,
putem crete gradul de corectitudine i de ncredere pentru datele din baz. n cele
ce urmeaz vor fi prezentate, pe scurt, cele mai importante restricii definibile ntr-
o BD relaional: de domeniu, de atomicitate, de unicitate, refereniale i
restriciile-utilizator.

2.2.1. Restricia de domeniu

Dup cum am vzut n paragraful anterior, un atribut este definit printr-un

nume i un domeniu. Orice valoare a atributului trebuie s se ncadreze n
domeniul definit. Exist mai multe moduri de percepie a acestei restricii.
O parte dintre informaticieni substituie domeniul tipului atributului: numeric,
ir de caractere, dat calendaristic, logic (boolean) etc. i, eventual, lungimii
(numrul maxim de poziii/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 jude (vezi plcuele de nmatriculare) poate fi una din
valorile: IS, TM, B etc. reprezint o restricie de comportament sau, mai simplu, o
restricie definit de utilizator.
Cea de-a doua categorie privete domeniul deopotriv sintactic i semantic.
Astfel, domeniul sintactic al atributului Jud (indicativul judeului) este un ir de
dou caractere, obligatoriu litere (sau o liter i un spaiu, pentru Bucureti), i,
chiar mai restrictiv, literele sunt obligatoriu majuscule. Din punct de vedere
semantic, indicativul poate lua una din valorile: IS, TM
Majoritatea SGBD-urilor permit definirea tuturor elementelor ce caracterizeaz
domeniul (sintactic i semantic) atributului Jud prin declararea tipului i lungimii
atributului i prin aa-numitele reguli de validare la nivel de cmp (field validation
rule). Sunt ns i produse la care domeniul poate fi definit explicit, sintactic i
38 Capitolul 2

semantic, dndu-i-se un nume pe care vor fi definite atributele n momentul crerii

tabelelor.

2.2.2. Atomicitate

Conform teoriei bazelor de date relaionale, orice atribut al unei tabele oarecare
trebuie s fie atomic, n sensul imposibilitii descompunerii sale n alte atribute.
Implicit, toate domeniile unei baze de date sunt musai atomice (adic elementare).
n aceste condiii, se spune c baza de date se afl n prima form normal sau prima
form normalizat (1NF).
Astzi, atomicitatea valorii atributelor a devenit o int predilect a atacurilor
dumnoase la adresa modelului relaional, pe motiv de imposibilitate a
gestionrii unor structuri de date mai complexe, specifice unor domenii ca
proiectare asistat de calculator, baze de date multimedia etc. Muli autori, dintre
care merit amintii cu deosebire Chris J. Date i Hugh Darwen, se opun ideii de
atomicitate formulat de Codd.
La drept vorbind, singurul lucru cert despre atomicitate este relativitatea
acesteia. S relum un exemplu de atribut compus (non-atomic) - Adresa6. Fiind
alctuit din Strad, Numr, Bloc, Scar, Etaj, Apartament, discuia 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 filiale
CONEL sau ROMTELECOM, sau pentru poliie, preluarea separat a fiecrui
element constituent al adresei este foarte important. Pentru un importator direct,
ns, pentru un mare en-grossist sau pentru o firm de producie lucrurile stau
ntr-o cu totul alt lumin. Partenerii de afaceri ai acestora sunt persoane juridice,
iar adresa intereseaz numai la nivel general, caz n care atributul Adresa nu este
considerat a fi non-atomic.
Alte exemple de atribute ce pot fi considerate, n funcie de circumstane,
simple sau compuse: DataOperaiuniiBancare (Data + Ora), BuletinIdentitate (Serie
+ Numr), NrnmatriculareAuto (privit global, sau pe cele trei componente:
numr, jude, combinaie trei de litere).
O relaie (tabel) n 1NF nu trebuie s conin atribute care se repet ca grupuri
(grupuri repetitive). ntr-o alt formulare, toate liniile unei tabele trebuie s conin
acelai numr de atribute. Fiecare celul a tabelei (intersecia unei coloane cu o
linie), altfel spus, valoarea unui atribut pe o linie (nregistrare), trebuie s fie

6 Este un exemplu dintre cele mai frecvente n majoritatea crilor despre baze de date.
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 39

atomic. Detalii despre atomicitate i grupuri repetitive gsii (i) n [Fotache 2005]
i [Sitar-Tut 2006].

2.2.3. Nenulitate

Modelul relaional prevede ca, atunci cnd nu se cunoate valoarea unui atribut
pentru o anumite entitate, sau cnd pentru acel obiect, entitate, persoan etc.
atributul este inaplicabil, s se foloseasc (meta)valoarea NULL. Dup cum am
discutat, celui de-al treilea client din figura 2.1 nu i se cunoate adresa. Dac am
avea o tabel PRODUSE cu atributele CodProdus, DenumireProdus, UM, Culoare,
este posibil ca, pentru anumite sortimente, cum ar tricouri, cmi, jachete,
atributul s fie important, n timp ce pentru altele, precum vodc, cafea, lapte
atributul Culoare s nu furnizeze nici o informaie, adic s nu fie aplicabil. Iar
dac laptele poate fi doar alb, vodca chiar c nu are culoare (sunt foarte muli
specialiti n acest domeniu, i putei interoga !).
ntr-o baz de date relaional avem posibilitatea de a le impune unora dintre
atribute (sau tuturora) s aib ntotdeauna valori specificate, altfel spus, le
interzicem valorile nule, n timp ce altor atribute li se pot permite valori nule. Ca
regul, atributele importante, ce in de identificarea sau caracterizarea unei entiti,
proces, fenomen, precum i cele implicitate n calculul unor informaii importante,
sunt declarate NOT NULL, iar atributele fr importan deosebit pot fi mai
relaxate.

2.2.4. Unicitate

O relaie nu poate conine dou linii identice (dou linii care prezint aceleai
valori pentru toate atributele). Mai mult, majoritatea relaiilor prezint un atribut,
sau o combinaie de atribute, care difereniaz cu siguran un tuplu de toate
celelalte tupluri ale relaiei. Cheia primar a unei relaii (tabele) este un atribut sau
un grup de atribute care identific fr ambiguitate fiecare tuplu (linie) al relaiei
(tabelei). Dup Codd, exist trei restricii pe care trebuie s le verifice cheia
primar:
- unicitate: o cheie identific un singur tuplu (linie) al relaiei;
- compoziie minimal: atunci cnd cheia primar este compus, nici un
atribut din cheie nu poate fi eliminat fr distrugerea unicitii tuplului n
cadrul relaiei; n cazuri limit, o cheie poate fi alctuit din toate atributele
relaiei;
40 Capitolul 2

- valori non-nule: valorile atributului (sau ale ansamblului de atribute) ce

desemneaz cheia primar sunt ntotdeauna specificate, deci ne-nule i,
mai mult, nici un atribut din compoziia cheii primare nu poate avea valori
nule; aceast a treia condiie se mai numete i restricie a entitii.

7
Joe Celko inventariaz patru proprieti dezirabile pentru o cheie :
Familiaritate: valorile cheii s fie uor de neles pentru utilizatori.
Stabilitate: valorile cheii nu trebuie s fie volatile.
Minimalitate.
Simplitate: sunt de preferat chei scurte i simple.
Tot el atrage atenia ca cele patru proprieti pot intra, uneori, n conflict. O
cheie stabil poate s se dovedeasc complex i dificil de gestionat. Identificarea
cheii primare pentru o relaie face parte (mpreun cu stabilirea tabelelor prin
gruparea atributelor, stabilirea celorlalte restricii) din procesul de proiectare a
bazei de date. Uneori, precum n cazul tabelei JUDEE, stabilirea cheii primare nu
ridic probleme. Fiecare jude are un indicativ auto unic, deci atributul Jud
candideaz la postul de cheie a relaiei. La fel se poate spune i despre denumirea
judeului. Rezult c relaia JUDEE prezint dou chei candidate: Jud i Judet.
Alegerea unei dintre cheile candidat are n vedere criterii precum lungimea,
uurina n reinere i/sau editare. Fiind mai scurt, desemnm atributul Jud drept
cheie primar, situaie n care Judet devine cheie alternativ.
Tabela CLIENI are cheia primar simpl CodClient. CodClient reprezint un
numr unic asociat fiecrei firme creia i-am fcut vnzri (clienii notri sunt
exclusiv persoane juridice, adic firme). Exist ns suficiente cazuri n care cheia
primar este compus din dou, trei s.a.m.d. sau, la extrem, toate atributele relaiei.
S lum spre analiz o relaie PERSONAL care conine date generale despre
angajaii firmei. Fiecare tuplu al relaiei se refer la un angajat, atributele fiind:
Nume, Prenume, DataNaterii, Vechime, SalariuTarifar.
- Atributul Nume nu poate fi cheie, deoarece chiar i ntr-o ntreprindere de
talie mijlocie, este posibil s existe doi angajai cu acelai nume.
- Dac apariia a dou persoane cu nume identice este posibil, atunci
apariia a dou persoane cu acelai Prenume este probabil.
- Nici unul din aceste atributele DataNaterii, Vechime, SalariuTarifar nu
poate fi "nzestrat" cu funciunea de identificator.
n acest caz, se ncearc gruparea a dou, trei, patru s.a.m.d. atribute, pn cnd
se obine combinaia care va permite diferenierea clar a oricrei linii de toate

7 [Celko1999], p.247
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 41

celelalte. Combinaia Nume+Adres pare, la primele dou vederi, a ndeplini

"cerinele" de identificator. Ar fi totui o problem: dac n aceeai firm
(organizaie) lucreaz mpreun soul i soia ? Ambii au, de obicei, acelai nume
de familie i, tot de obicei, acelai domiciliu. Este adevrat, cazul ales nu este prea
fericit. Dar este suficient pentru a compromiterea combinaiei.
Urmtoarea tentativ este grupul Nume+Prenume+Adres, combinaie
neoperant dac n organizaie lucreaz tatl i un fiu (sau mama i o fiic) care au
aceleai nume i prenume i domiciliul comun. Ar rmne de ales una dintre
soluiile (Nume+Prenume+Adres+Vechime) sau (Nume+Prenume+Adresa+Da-
taNaterii).
Oricare din cele dou combinaii prezint riscul violrii restriciei de entitate,
deoarece este posibil ca, la preluarea unui angajai n baz, s nu i se cunoasc
adresa sau data naterii, caz n care atributul respectiv ar avea valoarea NULL.
Dificultile de identificare fr ambiguitate a angajailor au determinat firmele ca,
la angajare, s aloce fiecrei persoane un numr unic, numr denumit Marc. Prin
adugarea acestui atribut la cele existente, pentru relaia PERSONAL problema
cheii primare este rezolvat mult mai simplu. Actualmente, pentru cetenii
romni sarcina este simplificat i prin utilizarea codului numeric personal (CNP),
combinaie de 13 cifre care prezint avantajul c rmne neschimbat pe tot
parcursul vieii persoanei.

Problema unicitii a suscitat o serie de discuii n modelul relaional. Clasicii

modelului, Codd i Date, s-au pronunat mpotriva repetrii tuplurilor n cadrul
unei relaii, cerin pe care standadele SQL nu au luat-o n considerare. Exist i
situaii reale n care repetarea liniilor este inevitabil. David Beech a prezentat
ntr-o lucrare naintat Consiliului de Standardizare a bazelor de date ANSI X3H2,
8
i mai apoi n revista Datamation , problema consacrat n literatura de specialitate
9
drept argumentul cutiilor cu mncare pentru pisici : ntr-un supermagazin n
care casele de marcat sunt legate la o baz de date, un client cumpr patru cutii
Whiskas10 pentru pisici care cost, fiecare (cutie), 10 lei; pe bon apare de patru ori
cutii Whiskas. Autorul afirm, pe bun dreptate, c la nivelul conceptual la care
se nregistreaz informaiile, nu exist nici o valoare prin care cele patru rnduri s
fie difereniate. Astfel nct, pentru a respecta canoanele modelului relaional, este
necesar introducerea unei coloane suplimentare fr prea mare relevan, dar care

8 Beech, D. New Life for SQL, Datamation, Febr. 1, 1989

9 [Celko1999], p.45
10 Am rugmintea de a nu v lsa manipulai de reclame ieftine (ci numai de cele scumpe) !
42 Capitolul 2

s asigure unicitatea fiecrui tuplu. n acest sens, E.F. Codd a propus consiliului
ANSI X3H2 o funcie special care s msoare gradul de repetabilitate a valorii
unuia sau mai multor atribute, funcie care ar semna ntructva cu funcia
11
COUNT() din SQL folosit mprerun cu GROUP BY .
Pe lng noiunile cheie-candidat, cheie primar, cheie alternativ, modelul
relaional utilizeaz i sintagma supercheie. O supercheie poate fi definit ca un set
de coloane ce ndeplinete condiia de cheie (unicitate), dar care conine cel puin
12
un subset care este, el-nsui, cheie . Cu alte cuvinte, din cele trei condiii ale cheii
primare, o supercheie o ndeplinete numai pe prima (unicitate), fr a avea ns
compoziia minimal i fr a pune problema restriciei de entitate (valorile nule
ale atributelor componente).
Domeniul unui atribut care este cheie primar ntr-o relaie este denumit
domeniu primar. Dac ntr-o relaie exist mai multe combinaii de atribute care
confer unicitate tuplului, acestea sunt denumite chei candidate. O cheie candidat
care nu este identificator primar este referit drept cheie alternativ.

2.2.5. Restricia referenial

O baz de date relaional este alctuit din relaii (tabele) aflate n legtur.
Stabilirea legturii se bazeaz pe mecanismul cheii strine (externe) i, implicit, a
restriciei refereniale. Figura 2.4 prezint o legtur n care sunt implicate tabelele
FACTURI i CLIENI. Atributul CodClient joac un rol de agent de legtur
ntre tabelele CLIENI i FACTURI. Pentru relaia CLIENI, atributul CodClient
este cheie primar, n timp ce n tabela FACTURI, CodClient reprezint coloana de
referin sau cheia strin (extern), deoarece numai pe baza valorilor sale se poate
face legtura cu relaia printe CLIENI.
Cheile strine, denumite i chei externe sau coloane de referin, sunt deci atribute
sau combinaii de atribute care pun n legtur linii (tupluri) din relaii diferite.
Tabela n care atributul de legtur este cheie primar se numete tabel-printe (n
cazul nostru, CLIENI), iar cealalt tabel-copil.
Legat de noiunea de cheie strin apare conceptul de restricie referenial. O
restricie de integritate referenial apare atunci cnd o relaie face referin la o
13
alt relaie. C.J.Date definete restricia de integritate referenial astfel : Fie D un

11 Vezi [Celko1999], p.49

12 [Celko1999], p.52
13 [Date1986], p.89
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 43

domeniu primar i R1 o relaie ce prezint un atribut A definit pe D - notate R1 (...,

A:D, ...). n orice moment, orice valoare a lui A n R1 trebuie s fie:
a. ori nul,
b. ori egal cu o valoare a lui V, unde V este cheie primar sau candidat ntr-
un tuplu al unei relaii oarecare R2 (R1 i R2 nu trebuie s fie neaprat distincte),
cheie primar definit pe acelai domeniu primar D.

Figura 2.4. O restricie referenial ntre FACTURI (tabel-copil) i CLIENI (printe)

ntr-o alt formulare, se iau n discuie dou tabele (relaii) T1 i T2. Ambele au
atributul sau grupul de atribute notat CH care pentru T1 este cheie primar, iar
pentru T2 cheie strin. Dac n T2 se interzice apariia de valori nenule ale CH
care nu exist n nici un tuplu din T1, se spune c ntre T2 i T1 s-a instituit o
restricie referenial.
Instituirea restriciei refereniale ntre tabela CLIENI (printe) i FACTURI
(copil) permite cunoaterea, pentru fiecare factur, a denumirii i adresei clientului
creia i-a fost adresat. Dac n FACTURI ar exista vreo linie n care valoarea
atributului CodClient ar fi, spre exemplu 9988, este clar c acea linie ar fi orfan
(nu ar avea linie corespondent n tabela printe CLIENI).

Observaii
- Pentru muli utilizatori i profesioniti ai bazelor de date, denumirea de
"relaional" desemneaz faptul c o baz de date este alctuit din tabele
puse n legtur (relaie) prin intermediul cheilor externe i primare.
Aceasta este, de fapt, a doua accepiune a termenului de baze de date
relaionale (i cea eronat), prima, cea "clasic", avnd n vedere percepia
fiecrei linii dintr-o tabel ca o relaie ntre clase de valori.
- Majoritatea SGBD-urilor prezint mecanisme de declarare i gestionare
automat a restriciilor refereniale, prin actualizri n cascad i
interzicerea valorilor care ar nclca aceste restricii.
- Respectarea restriciilor refereniale este una din cele mai complicate
sarcini pentru dezvoltatorii de aplicaii ce utilizeaz baze de date. Din
44 Capitolul 2

acest punct de vedere, tentaia este de a sparge baza de date n ct mai

puine tabele cu putin, altfel spus, de a avea relaii ct mai corpolente.
Gradul de fragmentare al bazei ine de normalizarea bazei de date, care, ca
parte a procesului de proiectare a BD, se bazez pe dependenele
funcionale, multivaloare i de jonciune ntre atribute pe care, din fericire,
nu le atacm n aceast carte.

2.2.6. Restricii-utilizator

Restriciile utilizator mai sunt denumite i restricii (reguli) de comportament sau

restricii (reguli) ale organizaiei. De obicei, iau forma unor reguli la nivel de atribut
(field validation rules), reguli la nivel de linie (record validation rules), sau reguli
complexe, inter-atribute/linii/tabele, implementabile prin aseriuni (assertions),
reguli (rules) sau declanatoare (triggers).

Reguli la nivel de atribut

O restricie la nivel de atribut poate preveni introducerea n baza de date a unor
valori din alte intervale dect cele autorizate, n alte formate dect cele permise etc.
O astfel de regul nlocuiete (sau completeaz, mai bine zis) o restricie de
domeniu. Forma clasic a unei restricii la nivel de atribut este o expresie n care
apar constante, funcii-sistem i, nu n ultimul rnd, atributul respectiv. De obicei,
expresia conine, pe lng constante i funcii sistem (nici funciile sistem nu sunt
tolerate ntotdeauna), numai atributul pentru care se definete restricia. De
exemplu, pentru atributul CodCl din tabela CLIENI, se poate declara restricia:
CodCl BETWEEN 1001 AND 5678. Sau, n tabela STUDENI, exist atributul
CicluStudii, care, n condiiile (oarecum) noului sistem universitar european14
(Bologna), poate avea valorile 1, 2 sau 3, iar regula poate fi formulat n mai multe
variante:
CicluStudii > 0 AND CicluStudii < 4
CicluStudii >= 1 AND CicluStudii <= 3
CicluStudii BETWEEN 1 AND 3
CicluStudii IN (1, 2, 3)
Numrul anilor de studii pe fiecare ciclu este ns uor diferit. Ciclurile 1
(licen) i 3 (doctorat) se ntind pe durata a trei ani15, n timp ce al doilea ciclu

14 Afirmaia este discutabil, ca i noul sistem, dealtminteri.

15 Regula se aplic n universitaile clasice, universitile de medicin i politehnice avnd o alt
structur.
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 45

(specializare & master) dureaz doi ani. Aa c, pentru AnStudii regula este
similar atributului CicluStudii:
AnStudii >= 1 AND AnStudii <= 3
AnStudii BETWEEN 1 AND 3
AnStudii IN (1, 2, 3)
Dac, ns, dorim s fim mai exaci i s inem cont c valoarea maxim a anului
de studii pentru al doilea ciclu este 2, putem imagina o regul mai complex: CASE
WHEN CicluStudii IN (1,3) THEN AnStudii BETWEEN 1 AND 3 ELSE AnStudii
BETWEEN 1 AND 2 END. Ei bine, aceast regul (expresie) conine dou atribute,
nefiind una la nivel de atribut, ci la nivel de nregistrare.

La orice editare a atributului cu pricina (declanat la inserarea unei linii n

tabela din care face parte, sau la modificarea valorii sale), expresia este evaluat i,
dac rezultatul evalurii are valoarea logic adevrat (TRUE), atunci insera-
rea/modificarea este permis, iar dac rezultatul este FALSE, atunci inserarea/mo-
dificarea este blocat. Astfel, dac se insereaz o nregistrare n tabela STUDENI,
nregistrare ce corespunde unui student proaspt nmatriculat (n urma admiterii
sau transferului), iar valoarea specificat pentru atributul CicluStudii este 4, atunci
expresia CicluStudii BETWEEN 1 AND 3 are valoarea logic FALS, iar SGBD-ul nu
va tolera inserarea. Ulterior, o alt comand de inserare n care valoarea atributului
ar fi cuprins ntre 1 i 3, ar putea fi acceptat, n caz c nicio alt restricie nu ar fi
nclcat.

Reguli la nivel de nregistrare

Dup cum am vzut mai sus, expresia care definete o restricie la nivel de
nregistrare conine dou sau mai multe atribute: CASE WHEN CicluStudii IN (1,3)
THEN CASE WHEN AnStudii BETWEEN 1 AND 3 THEN TRUE ELSE FALSE END
ELSE CASE WHEN AnStudii BETWEEN 1 AND 2 THEN TRUE ELSE FALSE END
END16. Restricia la nivel de nregistrare este evaluat la inserarea unei linii sau la
modificarea valorii a mcar unui atribut ntr-o nregistrare din tabel. Dac,
teoretic (i, uneori, practic) restricia unui atribut se verific imediat dup
modificarea valorii acestuia, restricia la nivel de nregistrare se verific dup
modificarea tuturor atributelor de pe linia respectiv. n practic, este greu de
delimitat aceste momente, pentru c deseori se produc aproape simultan.

16 Este o alt variant (care se vrea mai impresionant) a restriciei prin care anul de studii se
sincronizeaz cu ciclul de studii.
46 Capitolul 2

Tabela FACTURI ar putea conine, printre altele, dou atribute valorice, unul
pentru pstrarea valorii totale (inclusiv TVA) a facturii respective, i un altul care
stocheaz cuantumul TVA colectate pentru factur. Majoritatea produselor i
serviciilor comercializate la noi n ar au un procent al taxei pe valoarea adugat
de 19%. Exist, ns, i produse la care procentul poate fi 9% sau chiar 0%) De
aceea, TVA colectat pentru o factur este mai mic sau cel mult egal dect/cu
19% din valoarea fr tva. S ncercm o formul: ValoareaTotal = ValoareaFrTVA
+ TVA. Dac factura conine numai produse cu 19%: ValoareaTotal =
ValoareaFrTVA + 0.19 * ValoareaFrTVA, sau ValoareaTotal = 1.19 * ValoareaF-
rTVA. Dar tabela noastr are doar atributele ValoareTotal i TVAColectat, aa
c nlocuim ValoareaFrTVA prin diferena celorlalte dou. Scriem: ValoareTotal
= 1.19 * (ValoareTotal TVAColectat), i dup calcule de matematic superioar,
TVAColectat * 1.19 = 0.19 * ValoareTotal, altfel spus TVAColectat = ValoareTotal *
0.19 / 1.1917. Prin urmare, expresia restriciei la nivel de nregistrare este:
TVAColectat BETWEEN 0 AND ValoareTotal * 0.19 / 1.1918.

S ne imaginm i alte asemenea restricii:

O tabel INCASRI (vezi paragraful 2.3.2), ar putea conine un atribut
Datancasrii, care s indice ziua n care ne-au intrat banii n cont (sau casierie) i
un altul, DatDocument. Ideea este c un client ne poate plti o sum printr-un
ordin de plat pe care l ntocmete pe 9 septembrie 2008 (aceasta este valoarea
atributului DatDocument), iar banii s ajung n contul nostru bancar pe 12
septembrie 2008 (aceasta este valoarea atributului Datancasrii). Regula s-ar referi
la precedena celor dou valori: CASE WHEN DataIncasarii IS NOT NULL THEN
Datancasrii >= DatDocument END.
ntr-o alt tabel GRZI din baza de date a unui spital de urgen, ar putea
exista un atribut pentru evidenierea momentului nceputului (DatOrnce-
putGard) i sfritului (DatOrSfritGard) unei grzi. Restricia la nivel de
nregistrare ar privi tot precedena celor dou valori: DatOrnceputGard < DatO-
rSfritGard.

Cele dou tipuri de restricii pot lucra n tandem. Astfel, pentru tabela
STUDENI putem declara:
- O restricie pentru atributul CicluStudii: CicluStudii IN (1, 2, 3)

17 Aceast expresie reprezint chintesena desvririi mele matematice.

18 n economia lucrrii, dup acest paragraf, pentru autor a urmat o pauz de jumtate de zi
datorat epuizrii intelectuale.
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 47

- O restricie pentru atributul AnStudii: AnStudii IN (1, 2, 3)

- O regul la nivel de nregistrare care ar avea o expresie mult simplicat:
CASE WHEN CicluStudii = 2 THEN AnStudii <= 2 END.

Reguli complexe
Exist i alte tipuri de restricii a cror validare presupune verificarea valorilor
(unuia sau mai multor atribute) de pe dou sau mai multe linii (nregistrri) ale
unei aceleai tabele, sau chiar aflate n tabele diferite. Iat cteva exemple mai mult
sau mai puin realiste:
- o factur poate avea maximum 30 de linii (produse vndute);
- se interzice emiterea unei noi facturi (o nou vnzare) dac datoriile firmei
client sunt mai mari de 20000 lei (iar directorul acesteia nu este membru n
partidul/partidele de guvernmnt);
- pentru o bibliotec universitar, numrul maxim de cri mprumutate, la
orice moment dat, depinde de categoria cititorului: 5 pentru studenii din
ciclul 1, 7 pentru studenii din ciclurile 2 i 3, i 10 pentru profesori.
Modalitile prin care aceste restricii pot fi declarate/implementate sunt destul
de eterogene n standardele SQL i n practic (SGBD-uri): aseriuni, reguli i,
probabil, cele mai frecvente, declanatoarele (triggerele) pe care le vom discuta n
detaliu mai ctre finalul crii.

2.3. Schema i coninutul unei baze de date relaionale

Aa cum era prezentat n primul capitol, exist dou aspecte complementare de
abordare a bazelor de date: schema (structura, intensia) i coninutul (instanierea,
extensia). Pentru o baz de date relaional (BDR) coninutul unei relaii este
reprezentat de ansamblul tuplurilor care o alctuiesc la un moment dat. Schema
unei baze de date conine denumiri ale tabelelor, numele, tipul i lungimea
atributelor, restricii de unicitate, de non-nulitate, restricii la nivel de atribut i de
linie, i alte eventuale tipuri de restricii de comportament, precum i restricii
refereniale. La acestea se adaug drepturile utilizatorilor, definiiile i restriciile
tabelelor virtuale, indecilor etc. Foarte importante n lumea profesionitilor
dezvoltrii de aplicaii cu bazele de date sunt procedurile stocate programe de
forma funciilor, procedurilor, pachetelor i declanatoarelor (triggerelor) care,
dup cum le spune i numele, sunt memorate n schema bazei de date i fac parte
integrant din aceasta. Mai sunt i alte ingrediente ale unei scheme de BDR, ns le
vom prezenta pe parcurs.

2.3.1. Reprezentarea schemei unei baze de date relaionale

Schema unei BDR poate fi (i chiar trebuie) reprezentat grafic. Exist o

mulime de reprezentri, mai sugestive sau mai criptice, fiind greu de fcut o
clasificare din punctul de vedere al lizibilitii/comprehensibilitii lor. Oricum,
ierahizarea ar fi, din start, contaminat de preferinele i experiena autorului.
48 Capitolul 2

Prima ediie a crii a recurs la un formalism neutru, bazat pe urmtoarele

reguli simpliste:19:
O tabel se reprezint pe dou linii, pe prima fiind scris numai numele
relaiei iar pe cea de-a doua numele atributelor; ordinea prezentrii
atributelor nu are importan, ns, pentru lizibilitate, coloana sau
coloanele care desemneaz cheia primar se dispun succesiv, la nceput
(stnga); tot alturat se dispun i atributele care constituie o cheie strin.
Numele coloanelor ce alctuiesc cheia primar se subliniaz cu o linie
continu, iar cele care alctuiesc cheile alternative se subliniaz cu linie
punctat.
Numele coloanelor facultative (atributele ce pot avea valori NULL) sunt
scrise ntre paranteze.
Dac o cheie strin este alctuit din mai multe coloane, se poate utiliza
acolada pentru a le grupa.
O restricie referenial este reprezentat printr-o sgeat care pleac din
cheia extern (sau de la vrful acoladei, n cazul unei chei strine compuse)
i are vrful nfipt n cheia primar a tabelei printe.

Figura 2.5. Una dintre reprezentrile BD TRIAJ

19 Preluare din [Hainaut 1994], pp. 24-25

SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 49

Astfel, o baz de date destul de simplist dedicat unui spital de urgen, BD

denumit TRIAJ ar putea avea schema reprezentat ca n figura 2.5. Faptul c
exist o tabel cu acelai nume ca al bazei de date nu e grozav, dar nici toxic.

Un formalism frecvent printre non-profesioniti este cel din Access vezi figura
2.6. Principalul avantaj este c, datorit modului de dispunere a atributelor n
tabele, reprezentarea relaiilor cu multe atribute nu ridic probleme precum
formalismul anterior. Exist, ns, i cteva dezavantaje majore:
- nu se pot vizualiza cheile alternative (alte atribute/grupuri de atribute cu
valori unice n tabela respectiv);
- nu se pot deosebi atributele cu valori obligatorii (NOT NULL) de cele
pentru care se pot accepta valori nule;
- restriciile refereniale trebuie ghicite dup numele atributelor, ntruct
linia care leag tabela copil de tabela printe nu este trasat (dect
accidental) n dreptul atributelor cheie extern i cheie primar;
- pentru Access, conectarea unei tabele printe cu una copil nu nseamn
automat i c restricia referenial a fost instituit.

Figura 2.6. Reprezentarea din Access a mini-BD TRIAJ

n aceast ediie nu vom lucra (prea mult) cu MS Access. Dintre cele patru
SGBD-uri alese (vezi paragraful 2.4), SQL Server (produs de Microsoft) pune la
dispoziie un mecanism de reprezentare la fel de simplu precum cel din Access
vezi figura 2.7, formalismul motenind, de fapt, att avantajele, ct i
dezavantajele celui din Access.

2.3.2. Scheme folosite pentru ilustrarea interogrilor n algebra

relaional i SQL

Pe parcursul urmtoarelor capitole, ne vom folosi, n principal, de dou baze de

date, dintre care prima este, mai degrab, mini sau micro baz de date.
50 Capitolul 2

Figura 2.7. Reprezentarea n SQL Server a mini-BD TRIAJ

Baza de date TRIAJ

Dei nu este cea mai important n economia lucrrii, ncepem prin a detalia BD
TRIAJ. Aceasta conine patru tabele, DOCTORI, GRZI, PACIENI i TRIAJ care
stocheaz informaii generale despre cazurile recepionate la camera de gard n
decursul unei perioade de civa ani.

Tabela DOCTORI pstreaz, pe fiecare linie (nregistrare), date generale despre

fiecare medic al clinicii (spitalului), atributele sale fiind:
- IdDoctor este un numr ntreg care identific fiecare doctor (un fel de
marc sau cod);
- NumeDoctor ir de caractere al crui rol este evident;
- Specialitate ir de caractere ce identific domeniul n care este pregtit
doctorul (boli interne, chirurgie cardio-vascular etc);
- DataNaterii o dat calendaristic asupra creia nu mai are rost s
insistm.
Cheia primar este IdDoctor, iar pentru ultimele dou atribute se pot accepta
valori nule.

Tabela GRZI conine programarea medicilor n grzile clinicii. Fiecare linie se

refer la un medic care face o gard. Atribute:
- IdDoctor este un numr ntreg care identific medicul de gard;
- nceput_Gard o combinaie dat + or (inclusiv minut, secund), s-i
zicem moment, n care medicul intr n gard;
- Sfrit_Gard momentul (ziua i ora) la care medicul a ieit sau va iei
din gard;
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 51

Cheia primar a tabelei este combinaia (IdDoctor, nceput_Gard), ceea ce

nseamn, printre altele, c, n spitalul cu pricina, ntr-o aceeai gard pot fi
programai doi sau mai muli medici (n perioadele aglomerate). Fiind componente
ale cheii primare, aceste dou atribute nu pot accepta valori nule. Ultimul, ns,
poate avea valori NULL, ceea ce ar nsemna c este vorba de gard n curs, ce nu s-
a terminat.
IdDoctor este n tabela GRZI cheie strin, cheia primar corespondent fiind
atributul cu acelai nume din tabela DOCTORI.

Tabela PACIENI ofer cte o linie pentru fiecare bolnav, fericit sau nefericit,
care a trecut pragul spitalului (i a fost nregistrat). Atribute:
- IdPacient este un numr ntreg care identific fiecare persoan-pacient;
- NumePacient ir de caractere cu funcionalitate evident;
- CNP Codul Numeric Personal al pacientului;
- Adresa ir de caractere ce indic domiciliul (din cartea de identitate)
pacientului;
- Loc localitatea n care i are domiciliul pacientul (este separat de
adres);
- Jude judeul n se care se gsete localitatea;
- ar ara n care i are domiciliul pacientul;
- Serie_Nr_Act_Identitate seria i numrul actului de identitate al
pacientului.
Cheia primar a tabelei este IdPacient. Interesant este c acesta este singurul
atribut al tabelei care nu poate accepta valori nule, ceea ce pare destul de curios.
Motivul este c la clinic pot sosi victime nensoite ale unor accidente rutiere care
nu au asupra lor niciun act de identitate, i, pn n momentul n care devin
contiente i li se recupereaz documentele, trebuie preluate n baza de date fr a
se ti mai nimic despre ele.

Tabela TRIAJ conine, pe fiecare dintre linii, un caz, adic sosirea unei
persoane n stare mai bun mai mai rea. n decursul anilor, o persoan care se
regsete n tabela PACIENI pe o singur linie/nregistrare, poate avea mai multe
linii din TRIAJ corespondente. Astfel, un ghinionist poate a avut pe 13 mai 2005 o
criz renal, pe 13 ianuarie 2007 a alunecat pe ghea i i-a rupt un picior, iar pe 13
iunie 2008 a avut un accident rutier n care i-a rupt o coast. Toate cele trei bucurii
s-au petrecut n preajma spitalului, care l poate considera client fidel. Atribute:
- IdExaminare este un numr ntreg care identific orice sosire a unui
pacient n camera de gard, sosire care devine caz;
- DataOra_Examinare momentul (data/ora) sosirii/examinrii
pacientului;
- IdPacient numrul ntreg care identific pacientul;
- Simptome ir de caractere n care medicul de gard descrie cum se
prezenta pacientul n momentul sosirii;
52 Capitolul 2

- Tratament_Imediat medicamente, masaje cardiace i alte operaiuni pe

care medicul de gard le-a administrat/aplicat pacientului, innd seama
de simptome;
- Secie_Destinaie ir de caractere care indic eventuala secie n care a
fost transferat pacientul, dup administrarea tratamentului imediat.
Cheia primar a tabelei este IdExaminare. Acest atribut, mpreun cu DataO-
ra_Examinare i IdPacient, nu pot accepta valori nule. IdPacient este cheie strin
(tabela printe fiind PACIENI).

Baza de date VNZRI

Capitolele urmtoare vor utiliza cu precdere o baz de date martor,
denumit VNZRI, a crei schem simplificat este cea din figura 2.8.

Figura 2.8. Schema simplificat a bazei de date VNZRI

Tabela JUDEE conine cte o linie pentru fiecare jude n care sunt clieni.
Atribute:
- Jud indicativul auto al judeului (alctuit din dou litere, majuscule);
- Jude denumirea judeului;
- Regiune regiunea istoric (provincia) din care face parte judeul.
Cheia primar este atributul Jud, iar atributul Jude este cheie alternativ.
Niciunul dintre atribute nu accept valori nule. Restricii-utilizator:
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 53

Valoarea atributului Jud s fie alctuit numai din majuscule (eventual, un

spaiu, pentru Bucureti);
Fiecare cuvnt din valoarea atributului Jude s nceap cu majuscul;
restul literelor s fie mici (minuscule);
Valoarea atributului Regiune s nceap cu o majuscul; restul literelor s
fie mici;
Regiune poate avea numai una din valorile: Banat, Dobrogea, Muntenia,
Oltenia, Transilvania, Moldova.

Tabela CODURI_POTALE conine cte o linie pentru fiecare cod potal dintr-
un ora sau comun:
- CodPot codul potal;
- Loc denumirea comunei/oraului;
- Jud indicativul auto al judeului n care se afl oraul/comuna.
Cheia primar este atributul CodPot. Atributul Jud este cheie strin, tabela
printe fiind JUDEE. Nici CodPost, nici Loc nu trebuie s accepte valori NULL.
Restricii-utilizator:
Valoarea lui Jud este alctuit numai din majuscule (eventual, un spaiu,
pentru Bucureti);
Fiecare cuvnt din Localitate ncepe cu majuscul; restul literelor sunt mici.

Tabela CLIENI pstreaz date generale ale clienilor firmei pentru care s-a
constituit baza de date (o linie un client). Atribute:
- CodCl codul clientului;
- DenCl denumirea clientului (persoan juridic);
- CodFiscal codul fiscal;
- Adresa adresa sediului firmei client;
- CodPot codul potal al comunei sau oraului;
- Telefon telefonul (principal) al clientului.
Cheia primar este atributul CodCl, iar CodFiscal este cheie alternativ ntruct
clienii sunt exclusiv persoane juridice (firme). Atributul CodPot este cheie
strin, tabela printe fiind CODURI_POTALE. DenCl i Adresa ncep cu
majuscule. Numai Adresa i Telefon pot avea valori NULL. De asemenea, valoarea
minim acceptat pentru atributul CodCl este 1001.

Tabela PERSOANE stocheaz cteva date despre persoanele cheie de la firmele

client: directori generali, directori financiari, efi ai compartimentelor comerciale
(aprovizionare i/sau vnzri) etc. Probabil c vi se pare ciudat, dar ceea ce
intenionm cu aceast tabel (i urmtoarea) este s sprijinim fidelizarea
clientului. Nu cost (mai) nimic dac de Sfntul Ion se trimite, din partea firmei
noastre, cte o felicitare tuturor Ionilor i Ioanelor. Iar pentru ca lucrurile s fie i
mai bine puse la punct, ar fi trebuit s prelum i informaii precum: data naterii,
starea civil, numele i 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;
54 Capitolul 2

- Nume;
- Prenume;
- Adresa adresa domiciliului stabil (din cartea de identitate);
- Sex;
- CodPot codul potal al adresei;
- TelAcas numrul telefonului de acas;
- TelBirou numrul telefonului (fix) de la birou;
- TelMobil numrul mobilului;
- Email adresa e-mail.
Dei este un numr compus din 13 poziii, este recomandabil ca CNP s fie
declarat de tip ir de caractere. Aceasta deoarece n firm exist rezideni din alte
ri care au poziii de vrf n firme romneti (sau reprezentane ale unor firme
strine). Ori, codul identificator din paaport poate fi alctuit din litere i cifre.
Cheia primar este atributul CNP (s presupunem c firma le poate obine, dei
e puin plauzibil). Fiind vorba de persoane exterioare companiei, un atribut
precum Marca este mai puin indicat. Atributul CodPost este cheie strin, tabela
printe fiind CODURI_POTALE. Alte restricii:
fiecare cuvnt din Nume i Prenume ncepe cu majuscul; restul literelor
sunt mici;
adresa ncepe cu majuscul;
atributul Sex poate lua numai dou valori: B de la Brbtesc i F de la
Femeiesc.

Cu ajutorul tabelei PERSCLIENI cunoatem funcia deinut de fiecare

persoan la unul (sau mai multe, dei aceste cazuri sunt rare) firme-client. O linie
din aceast tabel reflect o funcie deinut de o persoan ntr-o firm. O persoan
poate avea mai multe funcii, chiar la aceeai firm (cumul de funcii). Cele trei
atribute sunt:
- CNP codul numeric personal al persoanei care deine funcia;
- CodCl firma la care persoana deine funcia;
- Funcie funcia deinut.
Cheia primar este compus din toate cele trei atribute, (CNP, CodCl, Funcie),
deoarece, pe de o parte, o persoan poate cumula dou sau mai multe funcii la
aceiai firm, iar, pe de alt parte, o persoan poate, n unele cazuri s lucreze la
dou sau mai multe firme. CNP i CodCl sunt chei strine, tabelele printe fiind
PERSOANE, respectiv CLIENI. Atributul Funcie ncepe cu o majuscul, restul
literelor fiind mici.

Tabela PRODUSE reprezint nomenclatorul de produse i servicii pe care le

comercializeaz firma (produsele sunt obinutele prin manufacturare sau
revnzare). Atribute:
- CodPr codul produsului;
- DenPr denumirea;
- UM unitatea de msur a produsului;
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 55

- Grupa grupa de mrfuri (sortimente) n care se ncadreaz; acest atribut

este important pentru analiza vnzrilor;
- ProcTVA procentul TVA care se aplic la preul de vnzare (pre care
este fr TVA); pare de prisos n condiiile actuale, dac toate produsele
vndute de firma noastr ar avea un singur procent, 19%; exist, ns i
produse la vnzarea crora se aplic doar 9%, i, n plus, nimeni nu poate
garanta cum vor gndi promoiile viitoare de guvernani relaxarea
fiscal;
Cheia primar este atributul CodPr. DenPr i Grupa ncep cu majuscul, restul
literelor din valoarea acestor atribute fiind mici.
Tabela pare una inofensiv, dar de modul su de organizare depinde
rezolvarea unor probleme sensibile. Este important de stabilit regimul n care se va
lucra cu produsele care se comercializeaz sub mai multe forme (cu uniti de
msur diferite. Atributul DenPr nu a fost declarat cheie alternativ. De ce ? S
lum un exemplu absolut la ntmplare: o firm de comer en-gross vinde, printre
altele, produsul Vodc X i la cutii de 1 litru i la peturi (sticle de plastic) de 250 ml.

Figura 2.9. Specificarea, n valoarea DenPr, a tipului cutiei

Dei este acelai produs, pentru o eviden corect a vnzrilor, este necesar ca
n tabela PRODUSE s existe dou linii afectate vodcii Scandic, fie ca n figura 2.9,
fie ca n figura 2.10.

Figura 2.10. Diferenierea (n afar de cod) numai prin UM

56 Capitolul 2

Fiecare variant are avantajele i dezavantajele sale.

Tabela FACTURI conine cte o linie pentru fiecare factur emis, factur ce
reflect o vnzare (ctre un client). Atribute:
- NrFact numrul facturii;
- DataFact data ntocmirii facturii;
- CodCl codul clientului cruia i s-au vndut produsele/serviciile consem-
nate n factur;
- Obs observaii; e folosit relativ rar, pentru a introduce eventuale detalii
sau probleme care au aprut n legtur cu o factur.
Cheia primar este atributul NrFact. Explicaia este una simpl: gestionarea
facturilor emise este, conform legii, strict. Nu pot exista dou facturi (care reflect
dou vnzri) cu un acelai numr20. CodCl este cheie strin (tabela printe este
CLIENI). Ca restricie utilizator suplimentar, s zicem c interzicem preluarea
facturilor ntocmite nainte de 1 ianuarie 2007 sau dup 31 decembrie 2015
(DataFact >= DATE2007-01-01 AND DataFact <= DATE2015-12-31).

Tabela LINIIFACT detaliaz tabela precedent. Un tuplu se refer la un

produs/serviciu vndut i consemnat ntr-o factur emis. Pentru fiecare factur
vor fi attea linii cte produse/servicii au fost consemnate la vnzarea respectiv.
Atribute:
- NrFact numrul facturii;
- Linie numrul liniei din factura respectiv (1, 2, 3, ...);
- CodPr codul produsului/serviciului vndut;
- Cantitate cantitatea vndut;
- PretUnit preul unitar (fr TVA) la care s-a fcut vnzarea.
Cheia primar este combinaia (NrFact, Linie). NrFact i CodPr sunt chei
strine. Pentru a determina valoarea de ncasat a unei facturi (inclusiv TVA), la
valoarea fr TVA pentru fiecare linie (obinut prin produsul Cantitate * PretUnit)
trebuie adugat TVA colectat, obinut prin aplicarea procentului de TVA al
produsului/serviciului (atributul ProcTVA din PRODUSE) la valoarea fr TVA.

Tabela INCASRI reprezint nomenclatorul ncasrilor. Printr-o ncasare, un

client i stinge una sau mai multe obligaii de plat, adic achit una sau mai

20 n ultimii ani, legislaia s-a mai domolit n privina numerotrii facturilor. Companiile pot
refolosi numere de facturi n fiecare an (prima factur din orice an poate avea, spre exemplu, numrul
100001), ns noi vom menine restricia de unicitatate a valorilor NrFact n tabela FACTURI.
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 57

multe facturi. Documentul primar pe baza cruia se consemneaz ncasarea poate

fi ordinul de plat, cecul, chitana etc. Atributele tabelei sunt:
- CodInc codul ncasrii - un numr intern, util pentru a diferenia o
ncasare de celelalte;
- DataInc data ncasrii - data la care banii au intrat n contul sau casieria
firmei;
- CodDoc codul documentului justificativ al ncasrii: OP ordin de plat,
CHIT chitan, CEC fil cec etc.;
- NrDoc numrul documentului justificativ;
- DataDoc data la care a fost ntocmit documentul justificativ; din
momentul ntocmirii documentului de plat pn la data la care banii
ajung efectiv n cont/casierie trec cteva zile datorit circuitului documen-
telor ntre firme i bnci, sau intervalul specificat n biletul la ordin sau n
cambie.
Cheia primar este atributul Codnc. Ca restricii utilizator pot fi instituite:
data ncasrii nu o poate precede pe cea a ntocmirii documentului
(Datanc >= DataDataDoc);
data documentului de ncasare i data ncasrii efective trebuie s fie n
intervalul de 1 ianuarie 2007 - 31 decembrie 2015 (DataDoc >= DATE2007-
01-01 AND DataDoc <= DATE2015-12-31);
codul documentului se scrie numai cu majuscule.

Tabela INCASFACT detaliaz tabela precedent i indic ce facturi (trane din

facturi) sunt achitate prin fiecare ncasare. Un client poate plti mai multe facturi
odat (printr-un singur document). Pe de alt parte, orice factur poate fi pltit
ntr-una sau mai multe trane, n funcie de banii de care dispune clientul la
momentul ntocmirii documentului de plat. Atributele tabelei sunt:
- Codnc codul ncasrii;
- NrFact factura pentru care se ncaseaz valoarea integral sau numai o
tran;
- Tran trana din factur (sau ntreaga valoare) care se ncaseaz prin
documentul primar ce st la baza ncasrii.
Cheia primar este combinaia (Codnc, NrFact), deoarece la o ncasare se pot
achita mai multe facturi, iar, pe de alt parte, o factur poate fi pltit n mai multe
trane. Codnc i NrFact sunt chei strine. Respectarea restriciei de entitate
presupune ca NrFact s nu poat avea valori nule, ceea ce atrage dup sine un
serios neajuns al acestei tabele imposibilitatea de a prelua ncasrile n avans
(naintea ntocmirii facturilor).

2.3.3. Alte obiecte din schema unei baze de date relaionale

Pe lng tabele, atribute i restricii, dicionarul de date al unei BDR conine

multe alte tipuri de obiecte, dintre care vom zbovi foarte puin asupra tabelelor
temporare i virtuale (view-uri), procedurilor stocate i secvenelor. Cele mai
vechi, n ordinea apariiei lor n teoria relaional sunt tabelele persistente (de
58 Capitolul 2

baz, clasice) i tabelele virutale. Unele, precum procedurile stocate i secvenele,

nu fac parte din modelul relaional i au aprut n SGBD-uri din raiuni practice,
fiind ncorporate ulterior n stardardul SQL.

Tabele temporare
O caracteristic fundamental a oricrei BD este persistena. Tabelele prezentate
pn acum sunt cele care asigur aceast caracteristic, ntruct, dup crearea lor
(i, implicit, stocarea schemei lor n dicionarul de date), informaiile introduse i
modificate sunt pstrate pe o durat nedeterminat, pn la tergerea lor explicit
sau pn la vreun nedorit dezastru hardware sau software.
Mai mult, n condiiile n care la baza de date are acces un mare numr de
utilizatori, modificrile efectuate de un utilizator (i confirmate prin ncheierea
eventualei tranzacii) n coninutul unei tabele sunt vizibile celorlali utilizatori.
Exist ns i posibilitatea de a declara tabele a cror schem s fie stocat n
dicionar, dar pentru care coninutul s fie volatil. Astfel, pot fi create tabele al
cror coninut s fie vizibil doar sesiunii de lucru care face apel la tabela respectiv,
pe perioada ntregii sesiuni. Acestea sunt tabelele temporare globale. Structura
tabelelor temporare locale este, de asemenea, pstrat n dicionarul de date, ns
vizibilitatea coninutului lor este limitat doar la un singur modul/bloc apelant n
cadrul sesiunii. La ce ar putea folosi tabele ale cror coninut ar fi aa de efemer ?
S lum un exemplu: dorim s analizm structura vnzrilor pe o regiune din care
face parte utilizatorul (sau o regiune aleas), dup mai multe criterii, pe ultimele 12
luni. Datele fiind istorice, iar BD folosit de muli utilizatori/aplicaii, n loc s
consultm repetat tabelele persistente, le putem menaja crend una sau mai
multe tabele temporare pe care s le stoarcem (pe ndelete) de informaii. Pe toat
durata vieii, liniile tabelelor temporare rmn neschimbate, deci rezultatele sunt
corecte (consistente). n capitolul 14 vom vedea modul n care pot fi create n SQL
tabelele temporare.

Tabele virtuale
n englez sintagma pentru acest tip de tabel este view, adic vedere sau
imagine. De aceea, n lucrrile romneti pot fi ntlnite mai multe titulaturi. O
tabel virtual stabilete o legtur semantic (printr-o expresie relaional sau
interogare) ntre tabele persistente i/sau alte tabele virtuale, neavnd tupluri
proprii, ca o relaie de baz (static). Coninutul (instanierea) tabelei virtuale
depinde, la un moment oarecare dat, de coninutul tabelelor de baz din care
deriv. Pentru a nelege mai bine diferena, explicaia se poate rezuma astfel: tabela
virtual este cea pentru care pe disc se memoreaz numai schema, nu i coninutul.
Ca i tabelele temporare (i cele obinuite), definiia unei tabele virtuale se
pstreaz pe disc. nregistrrile unei tabele temporare sunt stocate pn la
finalizarea modulului/blocului de cod (cazul celor locale) sau sesiunii (cazul celor
globale), n timp ce nregistrrile unei tabele virtuale nu se pstreaz. i tabelele
temporare i cele virtuale pot fi actualizate. Actualizarea nu ridic nicio problem
n cazul tabelelor temporare. n schimb, actualizarea unei tabele virtuale trebuie s
se propage n tabelele persistente din care provind tuplurile acesteia. Sunt situaii
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 59

destul de frecvente n care o modificare a unei linii ntr-o tabel virtual nu poate fi
tradus cu exactitate n modificri ale tabelelor de baz, cazuri n care, de obicei,
aceste modificri sunt respinse de ctre SGBD.
Tabelele virtuale ofer oricrui utilizator al unei baze de date posibilitatea
prezentrii datelor n funcie de nevoile sale specifice. De asemenea, raiuni de
securitate i confidenialitate a anumitor informaii pot conduce la izolarea unor
date fa de utilizatorii neautorizai, lucru deplin posibil prin intermediul view-
urilor. Pornind de la aceleai tabele de baz, se pot crea oricte tabele virtuale, n
funcie de situaie. Tabelele virtuale constituie suportul crerii schemelor externe.
Odat definit, o tabel virtual poate fi referit ca o tabel de baz oarecare.

Proceduri stocate
O procedur stocat este o secven de program (cod) a crei
definiie/semntur face parte integrant din baza de date. Avantajele utilizrii
procedurilor stocate decurg din faptul c acestea sunt parte din structura (schema)
bazei, fiind pstrate n dicionarul de date (catalogul sistem). Exist mai multe
tipuri de proceduri stocate: funcii pentru calculul unor valori implicite,
proceduri/funcii de validare la nivel de linie sau nregistrare, funcii/proceduri
de calcul a unor expresii complexe etc. ncepnd cu versiunea 1999 a standardului,
SQL-ul prezint o component important PSM (Persistent Stored Modules) care
ncearc s instituie un etalon n redactarea procedurilor stocate. Unificarea PSM
este o sarcin delicat. SQL-ul a aprut i s-a consacrat la limbaj neprocedural, care
nu lucreaz cu module de program clasice. Aa c fiecare productor de SGBD-uri
i-a perfecionat unul (sau chiar mai multe) limbaje procedurale. Alinierea la
specificaiile PSM este un proces de durat i oarecum de uzur (dar nu pentru
noi).

Declanatoare
Declanatorul (trigger) a aprut ca un tip special de procedur stocat care este
executat automat cnd un eveniment predefinit (inserare, actualizare sau tergere)
modific o tabel. Utilitatea declanatoarelor este evident la formularea unor
restricii mai complexe dect suport comenzile CREATE/ALTER TABLE, cum
ar fi: actualizarea automat a unor atribute calculate, jurnalizarea modificrilor
suferite de baza de date, pstrarea integritii refereniale etc.
Exist diferene sensibile ntre SGBD-uri i n ceea ce privete sintaxa declana-
toarelor, deoarece acestea sunt redactate n extensiile procedurale ale SQL, care
prezint diferenieri majore de la un productor la altul. n ultimii zece ani, au
aprut i alte evenimente-declanatoare n afara celor trei, cum ar fi: conectarea la
baza de date care echivaleaz cu deschiderea unei sesiuni de lucru, nchiderea
sesiunii, crearea unui obiect n BD, pornirea sau oprirea bazei de date etc.

Secvene
Secvena este un alt tip de obiect al unei BDR care nu face parte, propriu-zis,
din modelul relaional. A aprut din necesitatea asigurrii unicitii cheilor
primare/alternative. S lum cazul atributului CodCl din tabela CLIENI. La
60 Capitolul 2

inserarea unui client, valoarea sa pentru atributul CodCl ar trebui s fie superioar
celei a precedentului client introdus, sau, n orice caz, dac nu superioar, mcar
diferit. Dac ar fi un singur utilizator cu drept de introducere a firmelor client n
BD, lucrurile ar fi relativ simple, corectitudinea valorilor CodCl depinznd de
atenia sa. Acest scenariu este cu totul improbabil n aplicaiile pentru afaceri, n
care pot exista zeci, chiar sute sau mii de utilizatori ce lucreaz simultan cu baza,
iar, mai ales, n primele sptmni de la darea n folosin a aplicaiei, clienii pot fi
introdui de ctre mai muli utilizatori (uneori chiar simultan).
Secvena este un obiect care, la fiecare invocare a sa, genereaz o valoare unic,
indiferent de cte cereri/invocri simultane sunt. Crearea unei secvene
presupune, n afara numelui su, precizarea minimului, maximului i a incremen-
tului valorilor generate.

2.4. SGBDR-uri i servere de baze de date relaionale

Pn acum am folosit cei doi termeni, SGBD i server de baze de date, fr a avea
prea mare grij n a preciza ceea ce le aseamn i ceea ce le difereniaz. Nici de
acum ncolo nu vom fi prea grijulii, stabilind ns, din capul locului, c orice server
de baz de date (server BD) este un SGBD, ns nu orice SGBD este server BD.

2.4.1. Scurt istorie veche a SGBDR-urilor

n prima ediie a lucrrii am evocat principalele repere cronologice n realizarea

celor mai importante SGBD-uri relaionale. Acum o s scurtm serios povestea.
Lucrrile fondatoare ale lui E.F.Codd au fost primite cu entuziam reinut de ctre
firma la care lucra acesta IBM. Rezerva IBM era legat nu numai de faptul c era
vorba de bazele unei tehnologii noi, i nici cei mai buni prezictori nu aveau cum
s ghiceasc dac relaionalul se va dovedi viabil sau va fi un eec. IBM-ul avea, la
acel moment, unul dintre cele mai puternice SGBD-uri de pe pia IMS (care
gestiona baze de date ierarhice), n care investise muli bani i oameni. Ori,
afirmaiile lui Codd la adresa IMS-ului, fcute deseori n prezena clienilor, nu
erau dintre cele mai mgulitoare, ceea ce a iritat o serie de fee bisericeti ale
companiei21.

21 Evocarea are un uor aer de poveste. Eu le-am auzit de la Fabian Pascal, care le preluase de la
Chris Date.
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 61

Dup civa ani, IBM se hotrte s aloce bani ntr-un proiect care s se
materialezeze ntr-un SGBD relaional - System/R. Proiectul s-a derulat n
laboratorul Santa Teresa din San Jose, California. Prima faz - anii 1974 i 1975 - s-a
concretizat ntr-un prototip al SGBDR-ului, prototip care a fost rescris n anii 1976
i 1977 pentru a permite interogarea simultan a mai multor tabele i accesul multi-
utilizator. IBM a distribuit produsul pe parcursul anilor 1978 i 1979 la civa
colaboratori ai si pentru evaluri, dar n 1979 firma abandoneaz proiectul
System/R, considerndu-l nefezabil22. System/R a fost ns punctul de plecare
pentru realizarea unuia dintre cele mai cunoscute SGBDR-uri, DB2.
ntre timp, au fost realizate alte SGBD-uri, fie n stadiu de prototip, fie finisate
de-a binelea: INGRES (Interactive Graphics and Retrieval System) - al Universitii
Berkeley, QUERY BY EXAMPLE - Centrul de cercetri T.J. Watson, PRTV (Peterlee
Relationnel Test Vehicle) - Centrul tiinific Peterlee (Marea Britanie) patronat de
firma IBM, RDMS (Relational Data Management System) - General Motors,
INFORMIX (denumit iniial Relational Data Systems) etc.
Ca reper, reinem i anul 1977, cnd un grup de ingineri de la Menlo Park,
California, a fondat compania Relational Software Inc., cu scopul declarat de a
dezvolta un SGBD bazat pe limbajul SQL. Produsul, denumit Oracle, a fost lansat
n 1979 i a reprezentat primul SGBDR comercial. Dincolo de faptul c Oracle
precede cu doi ani primul SGBDR comercial al firmei IBM, orientarea sa a fost
extrem de bine gndit, rulnd pe minicalculatoarele VAX (Digital Equipment
Corporation), sensibil mai ieftine dect mainframe-urile IBM, i, deci, cu un
segment de pia mai mare. Astfel, succesul a fost considerabil. Astzi, firma,
redenumit Oracle Corporation, este liderul produselor software dedicate mediilor
de lucru cu bazele de date.
Primul SGBDR comercializat de IBM a fost SQL/DS (DS - Data System) anunat
n 1981 i comercializat n 1982. n 1983 IBM a lansat DB2, dedicat iniial
mainframe-urilor sale, dar care n timp a fost portat pe toate sistemele de operare
importante.
Pn la jumtatea anilor '80, SGBD-urile relaionale au stat n umbra celor
ierarhice i reea. Motivul principal l-a constituit viteza mai mic, parametru
esenial n sistemele "confruntate" cu accesul simultan a sute sau chiar mii de
utilizatori. n a doua parte a anilor '80 performanele SGBDR-urilor au fost net
ameliorate. Ctigul de vitez, care s-a adugat atuului principal, interogarea ad-

22 Pentru amnunte privind odiseea System R, vezi i documentele de la adresa web:

http://www.mcjones.org/System_R/SQL_Reunion_95
62 Capitolul 2

hoc prin utilizarea limbajelor de generaia a IV-a (SQL, QBE, Quel), a lrgit
continuu segmentul ocupat de SGBDR-uri.

Odat cu apariia PC-urilor, tehnologia relaional a devenit accesibil unei

largi categorii de utilizatori. Din anii '80 ncoace, produse precum dBase (Ashton-
Tate, Borland), Rbase (Microrim), Clipper (Nantucket, Computer Associates),
DBFast (Computer Associates), Foxbase-FoxPro (Fox Software, Microsoft), Paradox
(Borland, Corel), Approach (Lotus, IBM), Access (Microsoft) au fost folosite de
milioane de deintori de calculatoare personale, de la ignorani, pn la
profesioniti n dezvoltarea de aplicaii cu baze de date.
Este drept, dei categoria nceptorilor n ale bazelor de date ne intereseaz nu
numai ca posibili cumprtori ai crii, ct mai ales ca doritori de cunotine pentru
a-i folosi ct mai bine bazele de date proprii (i mai ales ca s-i doreasc mai mult
de la acest domeniu) -, n capitolele care urmeaz nu vom zbovi asupra dialectelor
SQL ale acestor SGBD-uri, ci ale patru dintre cele mai importante servere BD
actuale.

2.4.2. SGBD-uri non-servere BD

Cele mai simple i ieftine SGBDR-uri sunt cele pentru uz individual sau
aplicaii de tip file-server. Exemplele clasice sunt Visual FoxPro, Paradox i Access.
Visual FoxPro-ul a avut n ara noastr un mare succes, comparabil doar cu cel din
cteva ri est-europene. Modul n care calculatoarele i reelele de calculatoare au
ptruns i s-au extins la noi explic adoptarea sa n multe aplicaii de ntreprindere
i predarea sa n coli, licee i universiti. Generaia mea de truditori n ale bazelor
23
de date este, n bun parte, generaia Foxpro . Astzi termenul este, frecvent, unul
peiorativ, dar la timpul su (la nceputul anilor 90), cu greu se putea gsi la noi
ceva mai bun, ieftin (i uor de copiat).
Astzi Visual FoxPro (vezi figura 2.11), ajuns la versiunea 9, a ieit la pensie.
Microsoft-ul s-a hotrt s opreasc producia i suportul pentru acest SGBD
venerabil. Semnele rele erau vizibile de mai bine de zece ani. Microsoft nu a mai
venit cu modificri importante legate de gestiunea bazelor de date n FoxPro de la
versiunea Visual FoxPro 5 lansat 1994. Versiunile ulterioare au mai corectat din
erori, au mai introdus cteva opiuni privitoare la nucleul SQL (mai ales la
versiunea 9), i cam att. Este adevrat, VFP nu este doar un SGBD, ci un mediu
integrat de dezvoltare de aplicaii, cu foarte bune generatoare de rapoarte, meniuri

23 Vezi [Fotache s.a.2002]

SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 63

i formulare, i un limbaj de programare care a fost orientat pe obiecte cu mult

naintea Visual Basic-ului.

Figura 2.11. Afiarea coninutului unui proiect (inclusiv schema BD) n Visual FoxPro
Totui, pentru a intra n lumea bun a serverelor BD, VFP trebuia nzestrat cu
24
opiuni de creare a utilizatorilor , a profilurilor, de alocare i revocare de drepturi
pe toate obiectele bazei de date. Mai mult, ar fi trebuit s permit nativ
25
arhitecturi client/server i web , module de arhivare, restaurare i replicare, dar
mai ales s se descurce cu recuperarea bazei n cazuri de dezastre (ntreruperi de
curent, blocri ale Windows-ului). Or, responsabilii de aplicaii complexe realizate

24 Pn i Access-ul are, de civa ani, opiuni de creare de utilizatori i chiar de replicare.

25 Exist opiuni de adaptare a VFP la arhitecturi apropiate de cea c/s i web (vezi [Fotache
s.a.2002], ns efortul dezvoltatorilor de aplicaii este considerabil.
64 Capitolul 2

n VFP, cu zeci de utilizatori conectai simultan la BD, tiu ce este adrenalina cnd
26
pic nite indeci .
Dei i-a fost anunat sfritul, mai am o speran pentru VFP, i anume ca,
odat ce Microsoft i va lua minile de pe produs, ar putea intra n lumea open-
source, i cunoate o nou via (ar fi, cred, a treia).

Cel mai celebru SGBD din categoria non-serverelor BD este Access, copilul pe
27
care Microsoftul l-a preferat n dauna Visual FoxPro-ului . Access-ul are toate
atuurile care l-au fcut aa de popular, de la uurina folosirii, pn la integrarea cu
celelalte aplicaii din Office i migrarea natural la SQL Server. i Access este mai
mult dect un SGBD vezi figura 2.12.

Figura 2.12. Afiarea coninutului unui proiect (inclusiv tabelele BD) n Access
ns, dei i-au fost adugate funciuni redutabile, Access nu este (nc) un
server BD, iar dialectul su SQL este unul rezonabil, dar nu impresionant, n niciun
caz superior celui din VFP.

26 Vorbesc din propria experien. Cea mai mare jen profesional (de pn acum) o am din urm
cu vreo zece ani, cnd, mpreun cu ali colegi din Catedra de Informatic Economic, am ncercat s
modificm modul de nscriere la concursul de admitere al FEAA Iai. Ghinionul a fost c decanul a avut
ncredere n noi, dar, contrar testelor preliminare, n primele patru ore de la nceperea nscrierilor (se
adunaser vrei dou sute de persoane) ne-au picat indecii de vreo zece ori. Ulterior, am aflat c dintre
cele douzeci de staii (PC-uri) de nscriere, dou erau mufate un pic greit (i, absolut aleatoriu,
pierdeau din cnd n cnd legtura cu serverul pentru cteva fraciuni de secund).
27 n fine, poate c exprimarea e cam melodramatic, dar ca fox-ist (i ofticos pe deasupra) n-am
putut s m abin.
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 65

2.4.3. Servere de baze de date

Aplicaiile complexe din bnci, corporaii, organizaii i instituii gestioneaz

volume uriae de informaii i sunt operaionale prin efortul a mii de utilizatori ce
lucreaz simultan cu baza de date. Cerinele de vitez i fiabilitate sunt maxime.
Practic, multe aplicaii nu au niciun moment de pauz, orice ntrerupere fiind
foarte grav. Vorbim de lumea aplicaiilor critice, cu regulile ei foarte dure, iar
SGBD-urile care constituie parte din infrastructura acestor aplicaii sunt cele de
categorie grea: Oracle (Oracle), DB2 (IBM), Informix (IBM), Sysbase (Sybase), SQL
Server (Microsoft) etc. Fiind mult mai robuste, fiabile, sunt i mult mai costisitoare.

Figura. 2.13. Obiecte dintr-o baz de date Oracle (afiate de clientul SQL Developer)
Titlul figurii 1.6 fcea trimitere la structura unui SGBD. De fapt, numai
serverele BD sunt construite pe arhitectura respectiv. Conform standardului SQL
[ISO/IEC 2007-1], un server SQL:
gestioneaz sesiunile SQL care se deruleaz ntre server i un client prin
intermediul unei conexiuni SQL;
execut comenzile SQL primite de la client, recepioneaz i transmite
datele cerute;
66 Capitolul 2

menine starea sesiunilor SQL, inclusiv a identificatorului de autorizare i

altor parametri implicii ai sesiunii.

Dei au existant contradicii ntre cifrele avansate de diferite firme de estimare a

pieii bazelor de date, astzi majoritatea lucrrilor indic drept lider firma Oracle i
produsul su cu acelai nume. Figura 2.13 afieaz imaginea schemei BD aa cum
apare n clientul (de-acum clasic) SQL Developer. Serverul BD Oracle (cea mai
recenta versiune a sa fiind Oracle 11g) este un etalon n msurarea puterii i
funcionalitii unui SGBD, fiind folosit n mai toate tipurile de organizaii, de la
aplicaii pentru firme de mrime medie pn la aplicaii pentru corporaii
multinaionale. Tradiional un produs scump, sub presiunea concurenilor i
serverelor BD open-source, Oracle dispune astzi de o politic de liceniere mult
mai flexibil.

Figura. 2.14. Obiecte dintr-o baz de date DB2

Cel mai important concurent al Oracle pe piaa serverelor BD este produsul
DB2 al firmei IBM, ajuns la versiunea 9.5. Dei are o imagine foarte bun i un
numr impresionant de instalri n SUA i alte ri dezvoltate, n Romnia
prezena DB2 este mai degrab discret. Figura 2.14 ilustreaz modul n care sunt
afiate n DB2 (modulul Control Center) obiectele unei baze de date.
Pentru noi, DB2 prezint importan grozav nu att datorit pieei acoperite,
ct rolului imens pe care l-a jucat firma IBM n procesul de standardizare a SQL-
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 67

ului, cel puin primele dou standarde majore, SQL-89 i SQL-92 fiind, n mare
msur, copii ale dialectului SQL din DB2, aa cum se prezenta la acea dat.

Figura. 2.15. Obiecte dintr-o baz de date MS SQL Server

n ultimul deceniu, dintre serverele proprietare cea mai dinamic evoluie nu
a avut-o nici DB2, nici Oracle, ci produsul Microsoft denumit chiar SQL Server
68 Capitolul 2

vezi figura 2.15. Titulara produsului este un pic nepoliticoas (probabil c cea mai
28
decent denumire ar fi fost One of the SQL Servers), dar pe pia a prins .

Dinamica a fost asigurat i de faptul c produsul a aprut spre mijlocul anilor

90 (baza fiind deci foarte mic). Spre deosebire de giganii DB2/Oracle, MS SQL
Server a pornit-o de jos, ca server BD pentru grupuri de lucru, ideal pentru
aplicaii folosite de grupuri mici i mijlocii de utilizatori. Preul a fost, de la
nceput, extrem de tentant i continu s fie mult sub cele ale DB2 i Oracle. Cu
29
fiecare versiune, ultima fiind 2008 , SQL Server a continuat s ctige n
funcionalitate i fiabilitate, astfel nct astzi poate fi folosit i la aplicaii de mari
dimensiuni.
n materie de opiuni SQL, produsul Microsoft a prezentat destul de multe
diferene fa de standard. Pe parcursul capitolelor urmtoare o s observm multe
funcii i opiuni proprietare. Tendina de aliniere la standardele recente
(SQL:1999, SQL:2003, SQL:2008) ale SQL este vizibil, nsa, cu fiecare nou versiu-
ne, i poate fi una dintre explicaiile succesului comercial al SQL Server-ului.

Ultimii cincisprezece ani au consacrat un segment de pia care se constituie c

o alternativ apetisant la primadonele serverelor BD serverele BD open-source.
Inspirate din succesul sistemelor de operare de tip open source, i, ulterior,
serverelor web, serverele BD din aceast categorie au atras atenia multor
dezvoltatori de aplicaii, mai ales n condiiile ubicuitii arhitecturilor pe trei sau
mai multe straturi.
Este greu de spus care este cel mai bun produs din aceast categorie. Dac ar fi
30
dup numrul de utilizatori, probabil c cel mai bine plasat este MySQL .
Concurenii sunt, ns, foarte numeroi i puternici. Amintim doar pe
31 32 33 34 35
PostgreSQL , mini SQL (sau mSQL) , Ingres , MaxDB , Firebird . Paradoxul este
c MySQL-ul a devenit liderul pieii serverelor BD open source dup 1995 n

28 SQL Server a fost dezvoltat, iniial, printr-un parteneriat cu firma Sybase.

29 Comenzile SQL prezentate n carte au fost executate pe SQL 2005, deci produsul Microsoft a fost
oarecum discriminat n privina ultimei versiuni.
30 www.mysql.com
31 www.postgresql.org
32 www.hughes.com.au
33 www.ingres.com
34 www.sdn.sap.com/irj/sdn/maxdb
35 www.firebirdsql.org
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 69

condiiile n care avea implementat unul dintre cele mai slabe dialecte SQL, iar
procedurile stocate erau evocate doar, din cnd n cnd, pe grupurile de discuii.
De la versiunea 5, MySQL-ul este mai apropiat de un nivel decent de opiuni
specifice serverelor BD.
Nivelul jenant (n materie de SQL) al MySQL-ului a fost unul dintre motivele
alegerii (cu civa ani n urm) a PostgreSQL-ului ca server BD open-source
reprezentativ pentru lucrul cu studenii. Dei nescutit de probleme tehnice n a
doua parte a anilor 90, astzi PostgreSQL-ul, ajuns la versiunea 8.3, poate fi folosit
n aplicaii sofisticate, avnd un nivel de funcionalitate redutabil. Mai mult, n
materie de aliniere la standardele SQL, PostgreSQL merit toate laudele.
Figura 2.16 ilustreaz modul n care sunt prezentate obiectele unei baze date n,
probabil, cel mai popular client PostgreSQL i anume pgAdmin client pe care
l vom folosi i noi pentru exemplificare comenzilor SQL i modulelor de proceduri
stocate.

Figura. 2.16. Obiecte dintr-o baz de date PostgreSQL afiate n clientul pgAdmin
70 Capitolul 2