Universitatea de tiine Agricole i Medicin Veterinar

Ion Ionescu de la Brad Iai

Lector dr. Marius Clin

INFORMATIC
Partea a II-a
Curs pentru nvmnt la Distan

2003

Cuprins
1. Introducere 3
2. Date i baze de date

3. Baze de date relaionale 9

3.1. Relaii, tupluri, atribute 10
3.2. Diagrama entitate-asociere 11
4. Interogarea bazei de date relaionale 18
4.1. SGBD-ul i utilizatorii si 18
4.2. Limbajul de manipulare a datelor 20
4.3. Indexare 26
4.4. Tenhici declarative de manipulare a datelor 28
Referat i tem pentru aplicaie practic 33

1
Introducere
n 1880, Biroul de Recensmnt al SUA (U.S. Census Bureau) a cerut
matematicianului Herman Hollerith s gseasc o posibilitate de sporire a ritmului de
prelucrare a datelor obinute n urma recensmntului populaiei. Ca urmare a acestei
solicitri Hollerith a creat cartela perforat, codul de perforaii prin care datele de pe fiele de
recensmnt s fie reprezentate pe cartele i a conceput o main care s manipuleze
cartelele. El a luat ca surs de inspiraie rzboiul de esut automat, inventat de Joseph Marie
Jaquard in 1804, la care modelul esturii era codificat i nregistrat tot pe o suit de cartele
perforate pe care maina le "citea" pentru a face operaiile corespunztoare. Prin transpunerea
n practic a conceptelor lui Hollreith, rezultatele recensamntului din 1890 au fost finalizate
in circa trei ani n loc de unsprezece, cum estimase iniial U.S. Census Bureau.
Cartelele perforate i codul Hollerith au fcut carier n prelucrarea automat a
datelor pn la nceputul anilor optzeci ai secolului nostru, iar creatorul lor a intrat n istoria
calculatoarelor. Jaquard a intrat n istoria industriei textile, principiile mainii lui sunt
utilizate i astzi, iar furia "jacardurilor" reapare cu o ciclicitate de civa ani n moda
tricotajelor. ntr-o istorie a tehnologiei informaiei, "momentul Hollerith" este scos n
eviden pentru a marca o prim utilizare pe scar mare a codificrii informaiilor primare,
codul Hollerith, precum i apariia unui suport viabil, cartela perforat, pe care codurile s fie
nregistrate pentru a fi oferite, spre prelucrare, mainii. Motivul pentru care acest moment
istoric a fost amintit aici este altul, i anume deznodmntul su: durata prelucrrii datelor a
fost redus la o treime. Pe de alt parte, mai important pentru cele ce vor fi discutate n
acest capitol, este urmtoarea observaie: acum mai bine de o sut de ani, o organizaie (U.S.
Census Bureau), confruntndu-se cu problema stocrii i manipulrii unui volum imens de
date, a decis s fac un efort considerabil de modernizare n aceast direcie.
Organizarea i exploatarea unor mari colecii de date este astzi o cerin obinuit n
orice domeniu. ~n orice domeniu de activitate, economie, industrie, administra]ie,
agricultur\, cantitatea de informa]ii care trebuie `nregistrate [i manipulate cre[te continuu. n
acest punct credem c este util sublinierea distinciei care trebuie fcut ntre date i
informaii. Datele sunt "fapte" reprezentate prin valori - numere, iruri de caractere, sau
simboluri care au semnificaie ntr-un anumit context [2]. n cazul calculatoarelor aceste
3

valori sunt stocate pe suporturi specifice. Cartela perforat inventat de Herman Hollerith a
fost un astfel de suport de stocare; astzi vorbim despre discuri magnetice, discuri optice
(CD-ROM), casete cu band magnetic. Datele sunt, deci, fapte, adic materia prim pentru
obinerea informaiilor. Din acest punct de vedere, ele pot fi considerate informaii doar ntrun sens limitat [3]. Informaiile sunt ceea ce rezult n urma prelucrrii electronice a datelor
ntr-un anumit scop. Am fcut aceste observaii avnd n vedere utilizrile "clasice" ale
calculatorului, adic n scop tiinific, ingineresc, sau economic; cu puin imaginaie ele se
pot extinde asupra celor mai neconvenionale situaii, deci chiar i atunci cnd datele de
intrare provin de la un microfon, sau cnd informaiile de ieire reprezint comorile ascunse
ntr-un labirint dintr-un joc video.
Astzi conceptul de baz de date este foarte des folosit. Trebuie spus c, n destul de
multe cazuri, folosirea este abuziv i c eticheta de baz de date este aplicat unor colecii
oarecare de nregistrri ce nu ndeplinesc, nici ca mod de organizare i nici ca mod de
exploatare, rigorile impuse de termen. n acest capitol vom trece n revist ideile principale
care definesc noiunea de baz de date i vom schia o abordare din punctul de vedere al unui
profesionist neinformatician. Scopul este de a oferi acestuia un punct de plecare pentru o
potenial colaborare cu informaticianul n dezvoltarea unei baze de date. Vom discuta inti
de ce este recomandat tehnologia bazelor de date atunci cnd apare situaia organizrii,
manipulrii i exploatrii unor cantiti mari de date. Dei, la prima vedere, poate prea
superflu, credem c o astfel de discuie este util mai ales pentru a clarifica "ce se poate
pretinde unei baze de date". De altfel, toate lucrrile din domeniu includ un astfel de
segment. Un exemplu este [2] cartea lui Gordon G. Everest n care o parte important este
dedicat unei asfel de discuii. ncepnd cu a doua jumtate a anilor cincizeci problema
organizrii marilor colecii de date a constituit n permanen un domeniu de interes care a
devenit un important cmp de activitate pentru cercettori i pentru proiectani, cel al
sistemelor de gestiune a bazelor de date. Au rezultat fundamentri teoretice, tipuri de
arhitecturi, medii de dezvoltare lansate pia de marii productori de software.
Dintre modele consemnate n prezent am ales sistemele de gestiune a bazelor de
date relaionale pentru a exemplifica posibilitile de rezolvare practic a cerinelor legate
de alegerea materialelor. Aceasta deoarece modelul relaional este astzi cel mai utilizat,
marile firme de software folosindu-l pentru realizarea mediilor de dezvoltare a bazelor de
date. n afar de lucrarea citat anterior s mai menionm i [5], care se ocup exclusiv de
acest model.
Nu vom discuta detalii tehnice i nu ne vom concentra asupra unui anumit sistem de
gestiune a bazelor de date. Considerm c aceasta ar ncrca inutil coninutul capitolului,
innd cont de categoria de cititori crora li se adreseaz aceast carte. Produsele software
moderne sunt nsoite de documentaii bine elaborate i au comenzi tip Help foarte eficiente.
n cazul n care o persoan implicat n proiectarea construciilor metalice are pasiunea i
timpul necesar aprofundrii unui SGBD, o va putea face utiliznd direct produsul pe care l
are la dispoziie.

2
Date i baze de date
ncepnd cu mijlocul anilor '50 o problem abordat cu prioritate de specialitii din
tiina calculatoarelor a fost dezvoltarea limbajelor de programare deoarece, fr programe
un calculator nu face nimic, iar fr limbaje dezvoltarea de programe performante nu este
posibil. Un obiectiv avut n vedere a fost ca limbajele s fie ct mai apropiate de necesitile
categoriilor de utilizatori crora li se adresau. Astfel, primul limbaj de programare de nivel
nalt, FORTRAN, a fost creat pentru dezvoltare de programe n scop tiinific i tehnic, iar
primul limbaj pentru gestiunea marilor colecii de date a fost COBOL. De notat c
limbajul COBOL a deinut supremaia n realizarea aplicaiilor de gestiune a datelor pn la
apariia i dezvoltarea sistemelor de gestiune a bazelor de date.
n aceast perioad preocuprile n legtur cu structurile de date au fost mai reduse;
ele s-au axat mai degrab spre perfecionarea tehnicilor de stocare pe noile suporturi fizice
aprute: banda magnetic i discul magnetic. A fost studiat i dezvoltat conceptul de fiier
care desemneaz o colecie organizat de nregistrri pe un anumit suport. Cercetrile sau concentrat asupra organizrii fizice i logice a nregistrrilor precum i asupra metodelor
de acces la nregistrri. n realizarea aplicaiilor informatice programul era punctul central
(Fig. 1). Fondul de date ntreinut i exploatat n cadrul unei aplicaii era stocat pe suport
magnetic sub forma mai multor de fiiere de date, un fiier fiind o colecie de nregistrri.
nregistrrile unui fiier de date conineau o anumit categorie de date structurate n
cmpuri, care erau utilizate n cadrul aplicaiei informatice. La modul cel mai general, nu era
obligatoriu ca toate nregistrrile din fiier s arate la fel: s aib aceeai dimensiune i
aceleai cmpuri. Chiar dac anumite fiiere de date erau pstrate i actualizate n
permanen (de exemplu, fiierul de personal al unei ntreprinderi), n schema bloc a
aplicaiei programele i succesiunea execuiei lor constituiau firul director.
n aceast manier au fost dezvoltate sisteme informatice de mari dimensiuni. Un
astfel de sistem ntreinea i exploata un numr de fiiere de date prin intermediul unei
colecii de programe. Limbajul COBOL a fost cel mai utilizat pentru scrierea acestor
programe, el fiind dezvoltat special pentru realizarea aplicaiilor de gestiune. nsui numele
su este o prescurtare care exprim acest lucru (Common Business Oriented Language limbaj orientat spre probleme de afaceri/gestiune). Pe msur ce aplicaiile informatice
deveneau mai complexe au aprut i unele neajunsuri. S enumerm cteva.

Redundana datelor, adic apariia acelorai cmpuri de date n mai multe fiiere.
Pe lng consumul inutil de spaiu de stocare se punea problema urmririi foarte atente a
acestor redundane pentru a nu "scpa" necorelri ntre fiierele aplicaiei.

Date de
intrare

Rezultatele
prelucrrii

PROGRAM

Fisiere
permanente
(initiale)

Fig. 1 Abordarea clasic a

unei probleme de prelucrare a
datelor; programul este punctul
central.

Fisiere
permanente
(actualizate)

Probleme la actualizarea structurii datelor, legate de redundana exprimat mai

sus. Atunci cnd aprea necesitatea unor schimbri n aceast privin, modificrile trebuiau
fcute n toate fiierele n care apreau datele respective. Aceasta nsemna scriere de
programe noi, ceea ce consuma timp i efort.
Lipsa independenei ntre programe i date. Din aceast cauz modificrile asupra
structurii unor date trebuiau urmate de modificarea tuturor programelor care le prelucrau.
Neajunsurile enumerate mai sus i nu numai ele, duceau la ntreinerea
necorespunztoare a aplicaiilor de gestiune. n [3] se d ca exemplu sistemul informatic al
unei universiti n care, elementul NUME-STUDENT aprea n treisprezece fiiere, fiind
reprezentat n cinci formate diferite.
Creterea complexitii sistemelor informatice, n special a celor de gestiune, a
determinat studierea mai profund a structurilor de date. Datele se dovedeau a fi o resurs
important pentru organizaii (economice, financiare etc.), iar gestionarea lor trebuia fcut
cu aceeai atenie ca i a celorlalte resurse. Toate acestea au declanat o schimbare
fundamental pe care G. C. Everest [2] o numete "o revoluie copernician n procesarea
datelor". Copernic a rsturnat n secolul al aisprezecelea orgolioasa teorie geocentric a lui
Ptolemeu i a demonstrat n cadrul teoriei heliocentrice c, de fapt, Soarele este n centru, iar
noi i celelalte planete ne nvrtim n jurul lui. n cazul aplicaiilor informatice care
gestioneaz colecii mari de date, schimbarea fundamental a concepiei const n integrarea
acestor colecii ntr-o schem de interdependen, structurat clar, care s asigure o descriere
unitar a datelor i a relaiilor dintre ele. Aceast structur integrat, numit baz de date
(BD), trebuie s ocupe punctul central al sistemului, programele aplicaiei "gravitnd" n
jurul su (Fig. 2).
Baza da date este creat, ntreinut i exploatat prin intermediul unui produs
software numit sistem de gestiune a bazelor de date (SGBD). Un SGBD asigur realizarea
urmtoarelor activiti:
- definirea structurii BD, adic a coleciilor de nregistrri i a legturilor dintre ele
precum i descrierea datelor elementare i a relaiilor dintre acestea;
- ntreinerea BD, adic ncrcarea iniial, adugarea unor noi nregistrri,
eliminarea altora, modificarea (actualizarea) datelor nregistrate;

- exploatarea BD, adic interogarea (cutarea i vizualizarea datelor conform unor

criterii anumite) i editarea de rapoarte (liste de date referitoare la anumite probleme).

Rezultate

Date de
intrare
VALIDARE

EDITARE DE
RAPOARTE

BAZA
DE
DATE

PROGRAM

PROGRAM
Date de
intrare

Rezultatele
prelucrrii

Date de
intrare

Rezultatele
prelucrrii

Fig. 2 Abordarea tip baz de date; datele ocup poziia central

Deci manevrabilitatea bazei de date, n toate privinele, este dat de ctre SGBD-ul
care o manipuleaz; acesta trebuie s permit dezvoltarea unor aplicaii a cror ntreinere i
exploatare s fie accesibil nu numai informaticienilor, ci i utilizatorilor finali, beneficiarii
informaiilor.
n cazul sistemelor mari (societi comerciale importante, bnci etc.) baza de date
este accesat de o gam divers de utilizatori (compartimente administrative, secii de
producie etc.). Din acest motiv este obligatorie o anumit disciplin a muncii: ntreinerea
BD este coordonat de un administrator al bazei de date, singurul care are control total
asupra acesteia. Administratorul BD este autoritatea desemnat s stabileasc structurile de
date i standardele aferente, s acorde diferitelor categorii de utilizatori drepturile de acces
corespunztoare pentru consultarea sau actualizarea BD, s le pun acestora la dispoziie
imaginea global a prii din BD la care au acces i s le ofere instrumentele adecvate de
lucru.
n cazul sistemelor mici, un SGBD este folosit pentru a organiza datele i a simplifica
accesul al ele. Acest lucru este foarte important pentru utilizatorii care trebuie s afecteze o
mare parte a timpului de lucru consultrii coleciilor da date (fie, documentaii, standarde).
Acesta este i cazul inginerului care caut cea mai bun marc de oel pentru o construcie
metalic.
SGBD-urile, aceste medii de dezvoltare, ntreinere i exploatare a bazelor de date,
sunt produse de firmele de software. Cele mai cunoscute, utilizabile pe calculatoarele din
familia PC, sunt: "btrnul" dBase al firmei Ashton Tate, FoxPro i, n prezent, Visual Fox
dezvolate de Microsoft. Marii productori de software au lansat pe pia pachete integrate de
soft de aplicaie. Acestea conin, n principal, trei module: un procesor de texte, un modul de
calcul tabelar (spreadsheet) i un SGBD. Cele mai importante sunt:

SGBD-ul Access inclus de Microsoft, mpreun cu procesorul de texte Word i

spreadsheet-ul Excel, n pachetul Microsoft Office;
SGBD-ul Paradox inclus de Borland, mpreun cu procesorul de texte WordPerfect
i spreadsheet-ul QuatroPro, n pachetul Borland Office;
SGBD-ul Approach inclus de Lotus, mpreun cu procesorul de texte Ami Pro i
spreadsheet-ul 1-2-3, n pachetul Lotus SmartSuite.
S mai menionm aici i pachetul Works al firmei Microsoft. Modulele sale,
similare cu cele ale produselor enumerate mai sus, au putere mai mic, dar i complexitate
mai sczut. De aceea Works este uor de nvat, putnd fi utilizat de neinformaticieni n
rezolvarea problemelor curente de redactare, de calcul i de gestiune a coleciilor simple de
date.
Toate produsele enumerate mai sus au o trstur comun: folosesc modelul
relaional pentru structurarea logic a datelor; este abordarea cea mai utilizat astzi n
realizarea de SGBD-uri. De aceea, n capitolul 3 vom discuta mai pe larg despre baze de date
relaionale.

3
Baze de date
relaionale
O baz de date (nu neaprat relaional) conine informaii despre entiti. n general,
prin entitate nelegem orice obiect concret sau abstract din lumea real, n legtur cu care
dorim s colectm date. Entitile sunt descrise prin atribute. O instan, adic o entitate
particular este caracterizat de valorile atributelor. S dm un exemplu pentru a ilustra
ideea:
- entitatea este PERSOANA;
- atributele sale sunt NUME, PRENUME, DATA_NATERII, LOCALITATE, JUD;
- o instan este: Popa, Ion, 11/04/1951, Roman, NT.
Ideea nu este complet diferit de abordarea clasic n care fiierele sunt colecii de
nregistrri; n principiu, fiecare nregistrare este purttoare de informaii n legtur cu un
obiect, informaiile fiind date prin valori ale cmpurilor din care este format nregistrarea.
De aceea, n multe cazuri termenii "fiier", "nregistrare", "cmp" sunt folosii i cnd se
discut despre bazele de date, pentru c sun mai familiar. Dar aceast utilizare trebuie s
aib permanent n vedere diferenele eseniale dintre o sum de fiiere i o baz de date.
Conceptul de baz de date relaional a fost lansat de E. F. Codd n 1970. Modelul
relaional nu este primul n istoria structurrii logice a datelor. Dintre tehnicile prerelaionale
care au avut succes n implementare sunt cunoscute: structurile tip list, structurile ierarhice,
structurile tip reea. Structurile de tip relaional au ctigat popularitate datorit unor
caracteristici care le deosebesc de celelalte; s le enumerm n continuare.
- simplitatea n exploatare a ctigat simpatia utilizatorilor;
- claritatea pe care o ofer asupra sistemului de date a atras deopotriv pe
proiectani i pe utilizatori;
- limbajul de manipulare unificat, simplu i puternic este atractiv nu numai pentru
profesioniti, ci i pentru utilizatorii finali;
- modelul relaional teoretic, suportul pe care se bazeaz implementrile practice de
SGBD ofer sigurana corectitudinii i garanii pentru dezvoltrile viitoare.
n 1985 Codd a lansat conceptul de sistem de gestiune a bazelor de date relaionale
(SGBDR) sub forma unui set de 13 reguli pe care acesta trebuie s le ndeplineasc.
Majoritatea SGBDR-urilor nu respect n totalitate regulile lui Codd, dei chiar Regula Zero,
9

cea fundamental, arat c un sistem care este prezentat ca, sau se pretinde a fi un SGBDR,
trebuie s fie capabil de a gestiona baze de date n ntregime pe ci relaionale. Setul
reprezint mai degrab un ideal fa de care se poate evalua n ce msur un SGBD poate fi
considerat relaional. O astfel de evaluare este util deoarece unii productori, din dorina de
a fi "n pas cu moda", au prezentat drept SGBDR sisteme care nu respect de loc acest
standard. Regulile lui Codd sunt enumerate i comentate n lucrrile de specialitate (de
exemplu [4], [5]). n aceast prezentare general a SGBDR vom face doar trimiteri la ele
atunci cnd va fi cazul.

3.1. Relaii, tupluri, atribute.

Esena modelului relaional este de a reprezenta datele ca un set de relaii, numite i
tabele, n care sunt stocate datele. Tabelele constau dintr-un numr de tupluri (numite i
linii, nregistrri) fiecare tuplu descriind o entitate. Toate liniile conin acelai atribute
(numite coloane, cmpuri); deci ntr-o tabel se consemneaz aceleai lucruri n legtur cu
toate entitile. Fiecare tabel are un nume. Aceast reprezentare (Fig. 3) este formulat ca o
cerin n Regula 1 a lui Codd: Toate informaiile dintr-o baz de date relaional sunt
reprezentate explicit la nivel logic ntr-un singur mod - ca valori n tabele. Nivelul logic
reprezint imaginea pe care utilizatorul o are n legtur cu datele din BD. Reprezentarea a
avut succes nu numai la proiectani, ci i la utilizatori deoarece seamn foarte bine cu
metodele "pe hrtie", neinformatice, de prezentare i stocare a datelor.
Tuplu 
(linie,
nregistrare)

Atribut (coloan, cmp)

Fig. 3 Modelul relaional; relaia (tabela) este elementul principal

n Fig. 4 a, b i c sunt descrise trei relaii (tabele): STUDENTI [i CAMINE. La

fiecare se observ atributele (coloanele, cmpurile) i cteva tupluri (linii, nregistrri).
STUDENI
Atribute
valori
valori
valori

Nume
Popa
Ionescu
Georgesu

Prenume
Ion
Dan
Alina

Matricola
1122
1123
1124

Localit
Bacau
Birlad
Tecuci

Jud
BC
VS
GL

Cmin
C1

Cam
22

C3

31

a) Entitile sunt studeni

CMINE
Atribute
valori
valori

Cmin
C1
T3

Adresa
Sadoveanu 2
Tudor Vladimirescu 22

Telefon
343434
565656

Nr. camere
30
50

a) Entitile sunt c\mine

Fig. 4. Exemple de tabele n care se pot stoca tipuri de entitate ntr-o BD.

10

n cadrul tabelei trebuie s existe un identificator unic pentru fiecare entitate. Pentru
aceasta se desemneaz o cheie primar. Cheia primar este un atribut sau un grup de
atribute din cadrul tabelei cu proprietatea c nu va avea niciodat aceeai valoare n
dou entiti diferite. Cheia primar este un element esenial. Unul din rolurile sale este de
a garanta accesul la date, principiu exprimat de Regula 2 a lui Codd: Pentru orice dat
(valoare atomic) este garantat accesul logic prin utilizarea unei combinaii formate din
numele tabelei, valoarea cheii primare i numele coloanei (atribut). De exemplu, putem afla
numrul de telefon al unui c\min de oel intrnd n tabela CAMINE, indicnd valoarea din
cmpul "Camin" (cheia primar) i examinnd valoarea atributului "Tel".
Pentru tabela STUDENTI atributul "Matricola" poate fi desemnat cheie primar, iar
pentru tabela CAMINE acest rol poate fi jucat de atributul "Camin". Deci aceste tabele au
cheile primare formate din cte un singur atribut. n cazul unor tabele nu exist un atribut
care s asigure o valoare unic pentru fiecare linie a tabelei. ntr-un astfel de caz cheia
primar trebuie s fie o combinaie de mai multe atribute care, n ansamblu, dau unicitatea
valorii. O astfel de combinaie exist ntotdeauna, chiar dac ea ar trebui format din toate
atributele entitii. n caz contrar ar nsemna c exist posibilitatea apariiei a dou linii
indentice n tabel, ceea ce ar contrazice Regula 2.

3.2. Diagrama entitate-asociere

Cnd se proiecteaz o baz de date relaional, ntr-o faz iniial trebuie elaborat o
diagram entitate-asociere. De fapt o astfel de diagram nu este legat strict de bazele de
date relaionale ci este valabil pentru orice aplicaie de gestiune, inclusiv pentru cele
realizate cu fiiere clasice. Rolul ei este de imagine global a structurilor de date n cadrul
aplicaiei respective; dup definitivare, ea va fi punctul de plecare n realizarea bazei de date.
Toate metodologiile de analiz de sistem i de proiectare recomand realizarea unei astfel de
diagrame. Dei apar diferene ntre diversele abordri, ntr-o diagram entitate-asociere apar
ntotdeauna trei elemente de baz: tipuri de entitate, atribute i asocieri. Vom discuta n
continuare aceste trei categorii de baz, i vom face particularizrile pentru modelul
relaional.
Tipuri de entitate.
Un tip de entitate este orice tip de obiect, fizic sau abstract, din lumea real, n
legtur cu care dorim s stocm date. Un obiect particular de tipul respectiv este o entitate,
sau instan (a tipului de entitate). Deci, un tip de entitate desemneaz o categorie de obiecte
i, din acest motiv, mai este numit mulime de entiti, iar entitile (instanele tipului de
entitate) sunt numite elemente ale mulimii de entiti, fiecare ocupnd o linie a tabelei. n
modelul relaional tipurile de entitate se memoreaz n tabele (devin relaii).
Atribute.
Un tip de entitate este caracterizat de atribute. n modelul relaional toate entitile de
un anumit tip au aceleai atribute; ele formeaz coloanele tabelei.
Tabelele din Fig. 4 a, b i c memoreaz cte un tip de entitate; fiecare entitate
(instan) ocup o linie i este caracterizat de anumite valori ale atributelor.
n diagrama entitate-relaie tipurile de entitate i atributele se reprezint n diferite
forme: prin nume urmat de listarea atributelor (Fig. 5 a) sau prin figurarea numelui ntr-un

11

dreptunghi central i a atributelor (eventual, doar a acelora semnificative) n elipse conectate

la dreptunghi (Fig. 5. b).

STUDENI

CMINE
Nume
Prenume
Matricola
Localit
Jud
Cmin
Cam

Cmin
Adresa
Telefon
Nr. Camere

Cam

Prenume

Nume

Cmin

STUDENTI

Matricola
Jud

Adresa
Cmin

Telefon

CMINE

Nr.camere

Fig. 5 Dou moduri de reprezentare a tipurilor de entitate

i ale atributelor ntr-o diagram entitate-asociere

Asocieri.
Pe lng tipuri de entitate i de atribute, asocierile (legturile) sunt al treilea element
important n diagrama entitate-asociere. Asocierile sunt acelea care transform setul de tabele
ntr-un tot integrat care este baza de date. SGBD-ul ofer mijloace de definire a asocierilor i
apoi de manipulare a datelor din baz exploatnd aceste legturi.
CURSURI
Curs
Cadru_did
Ore_curs
Ore_apl
Credite
Tip

PROFI
Nume
Prenume
ID_prof

NOTE
Student_matricola
Curs
Nota

12

Fie, pe lng tabelele STUDENI i CMINE definite anterior, tabelele CURSURI

i PROFI i NOTE, avnd urmtoarele structuri:
S considerm tabelele STUDENTI i CURSURI. Exist vreo legtur ntre cele
dou tipuri de entitate? Evident, un student frecventeaz mai multe cursuri, iar un curs poate
fi frecventat de mai muli studen]i. Sunt, deci, dou legturi ntre tabele, avnd sensuri
opuse. Putem pune reprezenta aceste asocieri ca n Fig. 6. Cele dou asocieri au fost figurate
prin sgei i li s-au ataat denumiri care arat semnificaiile acestora.
Frecventeaza

STUDENTI

CURSURI
Sunt frecventate de

Fig. 6 Reprezentarea asocierilor ntre tabelele STUDENTI i CURSURI

Pe lng semnificaia unei asocieri este foarte important tipul asocierii. Acesta poate
fi privit din mai multe puncte de vedere, rezultnd astfel diverse moduri de clasificare.
Clasificarea dup numrul de tabele ntre care se face asocierea:
asociere unar - ntre entiti din aceeai tabel (de acelai tip).
asociere binar - ntre entiti din dou tabele (de dou tipuri).
asociere ternar - ntre entiti din trei tabele (de trei tipuri).
Asocierile binare sunt cele mai frecvente. n general, asocierile ntre trei sau mai
multe tabele pot fi descompuse ntr-un numr de asocieri binare; uneori, pentru aceasta este
nevoie de crearea unor tabele suplimentare.
Clasificarea dup cardinalitate.
asociere una la una (sau 1-la-1) - fiecrei entiti dintr-o tabel i corespunde o
entitate, i numai una singur, n cealalt; n acest caz se poate elimina asocierea prin
reuniunea celor dou tabele iniiale i crearea uneia noi.
asociere una la multe (sau 1-la-n) - fiecrei entiti din prima tabel i corespund mai
multe entiti din cea de-a doua; aceasta este situaia cea mai frecvent. Considernd inversa
unei astfel de asocieri, observm c fiecrei entiti din a doua tabel i corespunde una
singur din prima. O astfel de asociere poate fi definit ntre tabele STUDENTI i CAMINE:
unei entiti din tabela CAMINE (un cmin) i pot corespunde mai multe n tabela
STUDENTI, cte una pentru fiecare student care locuieste n cminul respectiv.
asociere multe la multe (sau n-la-n) - unei entiti din prima tabel i pot corespunde
mai multe entiti din a doua; de asemenea, unei entiti din a doua i pot corespunde mai
multe din prima. Acesta este cazul cu relaia din Fig. 6 exemplificat\ anterior.
Clasificarea dup opionalitate (obligativitatea asocierii).
Opionalitatea precizeaz dac este obligatoriu (prin natura asocierii) ca fiecare
entitate dintr-o tabel s aib entiti corespondente (una sau mai multe) n cealalt tabel,
ori dac acest lucru este opional, deci pot exista i entiti n prima care s nu aib neaprat
corespondent ntr-a doua.

13

a.

b.

Fig. 7. Asociere de tip una la multe. a) obligatorie. b) opional

Cardinalitatea i opionalitatea dau gradul asocierii. Gradul arat cte entiti din
fiecare tabel pot fi puse n coresponden prin asocierea dat. Cardinalitatea arat numrul
maxim, iar opionalitatea arat numrul minim.
Situaiile pot fi exprimate intuitiv lund ca exemplu dou tipuri de entitate (tabele) A
i B i o asociere R, de tip una la multe, a lui A cu B. Vom figura grafic (Fig. 7) cele dou
tipuri de entitate ca mulimi, entitile componente ca elemente ale mulimii, iar asocierea
prin conexiunile dintre elementele mulimilor. Diferena ntre Fig. 7 a i Fig. 7 b exprim
opionalitatea: n primul caz, orice entitate din A are, obligatoriu, cel puin o entitate
corespondent n B, n timp ce n al doilea caz acest lucru este opional.
Exist diferite convenii de notaie pentru a figura pe diagrama entitate-asociere
gradul unei asocieri. Una dintre ele, destul de simpl i sugestiv, este convenia SSADM
(Structured System Analysis and Design Method). Pentru exemplul anterior n care R este
asocierea lui A cu B, i n care vom nota cu S inversa lui R, asocierea ntre B i A, convenia
de notaie SSADM arat ca n Fig. 8. Urmrind diagrama de la A spre B se citete relaia R.
Cardinalitatea acesteia este exprimat de segmentul unic ce iese din A, avnd semnificaia
una i de cele trei segmente care intr n B, avnd semnificaia multe; deci R este o relaie de
tip una la multe. Opionalitatea se exprim n convenia SSADM prin dou expresii
nuanate: "trebuie s fie asociat", cu semnificaia "obligatoriu", i "poate fi asociat", cu
semnificaia "opional". n reprezentarea grafic, "trebuie s fie" este figurat prin linie
continu, iar "poate fi", prin linie punctat. Urmrind diagrama de la B spre A se citete, n
acelai mod, relaia S.

b
Fig. 8. Reprezentarea convenional n notaie SSADM
pentru relaiile din Fig. 7

Deci reprezentarea din Fig. 8 a nseamn: fiecare entitate din A trebuie s fie
asociat prin relaia R cu (una sau) mai multe entiti din B; fiecare entitate din B trebuie

14

s fie asociat prin relaia S cu o singur entitate din A. Reprezentarea din Fig. 8 b
nseamn: o entitate din A poate fi asociat prin relaia R cu (una sau) mai multe entiti
din B; fiecare entitate din B trebuie s fie asociat prin relaia S cu o singur entitate din
A.
n Fig. 9 sunt ilustrate asocieri de diverse grade. Fiecare schem intuitiv este nsoit
de reprezentarea convenional SSADM.
A

Fig. 9. Diferite grade de asociere ntre dou tipuri de entiti

n Fig. 9, n a i b sunt asocieri tip una la una, iar n c i d sunt asocieri tip multe la
multe. O asociere tip multe la multe se poate nlocui cu dou asocieri una la multe, iar
aceasta se face prin crearea unei tabele intermediare. n exemplul care va urma vom discuta
i acest aspect.
S aplicm cele expuse n legtur cu asocierile asupra tipuilor de entiti
STUDENTI i CURSURI. n general, un student frecventeaz mai multe cursuri, iar un curs
este frecventat de mai muli studeni; acestea ar fi cele dou asocieri, una fiind inversa
celeilalte. n privina cardinalitii, suntem n situaia de tip multe la multe.

15

Analiznd opionalitatea, putem defini asocierea "frecventeaz" de la STUDENTI la

CURSURI ca fiind obligatorie. Deci, oricare entitate din tabela STUDENTI trebuie s fie
asociat prin relaia "frecventeaz" cu (una sau) mai multe entiti din tabela CURSURI. La
prima vedere asocierea invers "este frecventat de", ntre CURSURI i STUDENTI, trebuie
definit ca obligatorie. Dac, ns, inem cont c exist cursuri facultative care sunt
frecventate doar dac exist studeni interesai de ele, trebuie s admitem c s-ar putea s
existe vreun curs care s nu fie frecventat de nimeni. Prin urmare este preferabil ca aceast
asociere s fie opional, de tip poate fi (Fig. 10.).

frecventeaz
STUDENTI

sunt
frecventate de

CURSURI

Fig. 10. Notaia SSADM pentru relaiile

dintre tabelele STUDENTI i CURSURI

Vom discuta n continuare cum se realizeaz efectiv asocierile n cazul bazelor de

date relaionale; s nu uitm, diagramele entitate-asociere se utilizeaz n proiectarea oricror
sisteme de gestiune a datelor, nu numai pentru modelul relaional. n cazul bazelor de date
relaionale, cheia primar este aceea care, pe lng rolul pe care l are n localizarea datelor,
este utilizat i n stabilirea de asocieri ntre tabele. Astfel, pentru realizarea unei asocieri
a unei tabele A cu o tabel B, cheia primar a tabelei A, cmp sau combinaie de
cmpuri, trebuie s se regseasc i n cadrul tabelei B.
Aplicnd aceast idee la tabelele STUDENTI i CURSURI constatm c, de fapt,
asocierile "frecventeaz" i "este frecventat de" pe care le-am discutat anterior, nu pot fi
realizate pentru c tabela STUDENTI descrie doar datele personale ale fiecrui student, iar
tabela CURSURI conine doar atribute care definesc cursul. n tabela STUDENTII nu exist
nici un cmp n care s se memoreze coduri de curs, deci n care s se regseasc valori ale
cheii primare din CURSURI; la fel, n tabela CURSURI nu este nici un artibut care s ia
valori din mulimea matricolelor de studeni, cheia primar a tabelei STUDENTI. Se pune
problema cum pot fi concretizate aceste legturi.
Soluia de implementare a unei asocieri ntre dou tabele este adugarea i n a doua
tabel, a atributelor care constituie cheia primar a primei tabele, astfel nct entitile din
cele dou tabele care se conecteaz prin asociere s aib aceeai valoare. n tabela a doua,
corespondenta cheii primare din prima se numete cheie extern. Deci, ntr-o baz de date
relaional, o asociere ntre dou tipuri de entiti se realizeaz prin coincidena
valorilor ntre cheia primar din prima tabel i cheia extern din a doua. Cheia
primar este un atribut sau o combinaie de atribute cu rolul principal de indentificare unic a
entitilor, deci nu vor exista n cadrul tabelei dou nregistrri cu aceeai valoare a cheii
primare. n ceea ce privete cheia extern, aceasta poate lua aceeai valoare n mai multe
nregistrri din a doua tabel. n acest caz se realizeaz o asociere de tip una la multe ntre
prima tabel i cea de-a doua. Dac i cheia extern are valori unice, atunci asocierea este de
tip una la una.
Este posibil ca, n afara cheii primare, s mai existe i alte atribute sau combinaii de
atribute cu proprietatea de unicitate a valorii pentru toate entitile tabelei, deci prin care
acestea pot fi indentificate cu exactitate. Un astfel de atribut sau combinaie de atribute se
16

numete cheie candidat pentru c ar putea s joace la fel de bine rolul de cheie primar.
Prin urmare, o cheie candidat, ca identificator exact al entitilor, poate fi pus n
legtur cu o cheie extern pentru definirea unei asocieri.
Revenind la implementarea asocierii dintre tabelele CURSURI i STUDENTI, vedem
c problema nu este, nc, rezolvat. S presupunem c am include i n tabela STUDENTI
cmpul "Curs" cu intenia de a-l desemna cheie extern pentru omologul su din tabela
CURSURI. S mai presupunem, pentru exemplificare, c cursul Mate este frecventat de
studenii 1111, 3333 i 4444, iar cursul Info este frecventat de 2222 i 4444. Valoarea Mate,
din cheia primar a tabelei CURSURI va trebui s se regseasc n cheia extern a
nregistrrilor 1111, 3333 i 4444, iar valoarea Info, n cheia extern a nregistrrilor 2222 i
4444 din tabela STUDENTI.
n cmpul Curs al nregistrrii 4444 din tabela STUDENTI ar trebui s apar att
valoarea Mate ct i valoarea Info, ceea ce este, evident, imposibil (Fig. 11). Problema a
aprut din cauza faptului c asocierea dintre tabelele CURSURI i STUDENTI este de tip
multe la multe.
CURSURI
Curs
Mate
Info

Cadru_did
...
...

Ore_curs
...
...

Ore_apl
...
...

Credite%
...
...

Tip
...
...

STUDENTI
Nume
...
...
...
...

Prenume
...
...
...
...

Matricola
1111
2222
3333
4444

Localit
...
...
...
...

Jud
...
...
...
...

Camin
...
...
...
...

Cam
...
...
...
...

Curs
Mate
Info
Mate
????

Fig. 11 Problemele de implementare a asocierilor multe la multe

Rezolvarea unei astfel de situaii se face prin transformarea legturii de tip multe la
multe n dou legturi de tip una la multe. Aceasta presupune introducerea unei tabele
suplimentare n care cheia primar s fie o combinaie a cheilor primare din cele dou tabele
iniiale. n cazul nostru, o astfel de tabel exist deja: tabela NOTE care, n plus mai are un
atribut: nota primit la examen. Diagrama entitate-asociere va arta ca n Fig. 12.

STUDENTI

NOTE

CURSURI

Fig. 12 Transformarea unei asocieri multe-la-multe

n dou asocieri una-la-multe

n legtura de tip una la multe dintre tabelele STUDENTI i NOTE, atributul

Matricola din prima este cheia primar, iar atributul Student_matricola din a doua este
cheia extern. n legtura dintre tabelele CURSURI i NOTE, de acelai tip, atributul Curs

17

din prima este cheia primar, iar atributul Curs din a doua este cheia extern. Cheia primar
a tabelei NOTE este format din cmpurile Student_matricola i Curs.
CURSURI
Curs
Mate
Info

Cadru_did
...
...

Ore_curs
...
...

Ore_apl
...
...

Credite%
...
...

Tip
...
...

STUDENTI
Nume
...
...
...
...

Prenume
...
...
...
...

Matricola
1111
2222
3333
4444

Localit
...
...
...
...

Jud
...
...
...
...

Camin
...
...
...
...

Cam
...
...
...
...

NOTE
Student_matricola
1111
3333
4444
2222
4444

Curs
Mate
Mate
Mate
Info
Info

Nota
6
8
4
7
10

Fig. 13. Exemplificarea asocierilor din Fig. 12

n Fig. 13 sunt artate valorile care trebuie completate n cele trei tabele n aa fel
nct s se rezolve problema din exemplul precedent.
S mai facem o precizare, dei credem c lucrurile sunt de la sine nelese:
nregistrarea unei asocieri, precum i exploatarea ulterioar a acesteia, adic toate cutrile,
comparaiile de valori ntre cheia primar i cheia extern, sunt fcute automat de ctre
SGBD n urma unor comenzi primite de la utilizator. Acestea vor fi discutate mai pe larg n
paragraful urmtor.
n ncheierea acestui paragraf s mai menionm pe scurt un aspect legat de
corectitudinea bazei de date. Asigurarea acestei corectitudini se face prin verificarea
respectrii unor reguli de integritate pe care datele din baz trebuie s le respecte. Pentru
corectitudinea aplicrii modelului relaional este minimal obligatorie [4,5] respectarea
urmtoarelor reguli:
- regula de unicitate a cheii care interzice ca dou entiti din aceeai tabel s aib
aceeai valoare a cheii primare;
- regula entitii care stabilete c nici unul din cmpurile din componena cheii
primare nu poate avea valoarea NULL (nu poate rmne necompletat);
- regula integritii refereniale care impune ca ntr-o asociere valorile cheii externe
s se regseasc printre valorile cheii primare sau s fie valori NULL.
SGBD-urile relaionale in cont de aceste reguli i verific automat respectarea lor.

18

4
Interogarea bazei de
date relaionale
4.1. SGBD-ul i utilizatorii si
La punctul precedent am discutat despre structurarea datelor n cadrul unei baze de
date relaionale. n continuare ne vom ocupa, pe scurt, de partea de exploatare a unei BDR.
Scopul crerii unei baze de date este asigurarea accesului operativ la fondul de date ncrcat
n ea. Datorit modificrilor pe care le sufer acest fond, baza de date trebuie supus unei
permanente ntreineri. Iat, deci, c n general bazele de date sunt accesate de diferii
utilizatori: unii o ntrein, alii doar o consult. Toate acestea, prin intermediul SGBD-ului.
n cel mai general sens, utilizatorii unui SGBD pot fi mprii n utilizatori indireci
i utilizatori direci.
Utilizatorii indireci apeleaz la SGBD prin intermediul altor persoane i a un rol
pasiv fa de baza de date. De exemplu, un cltor apeleaz o baz de date a SNCFR atunci
cnd cumpr un bilet din Gara de Nord; dei poate c nu se gndete la acest lucru, ca
utilizator indirect al bazei de date el are cteva avantaje. Pe de o parte, poate s-i cumpere
biletul de la orice casierie i nu numai de la "Ghieul nr. ..."; pe de alt parte, are garania c
nu va cumpra un tichet de loc care a mai fost vndut o dat la alt cas sau la agenia de
voiaj.
Utilizatorii direci ai SGBD-ului sunt cei care ne intereseaz aici n primul rnd. Ei
folosesc nemijlocit instrumentele oferite de SGBD. Exist i aici o distincie: ntr-o categorie
este informaticianul care folosete SGBD-ul ca mediu de lucru pentru realizarea bazei de
date i care, ulterior, se va ocupa de ntreinerea (administrarea) acesteia, iar n cealalt
categorie este utilizatorul final, adic beneficiarul informaiilor din baz. Efortul
informaticianului care dezvolt i ntreine baza de date este pus n slujba utilizatorului final.
De cnd au aprut microcalculatoarele aceast distincie nu mai este aa de net. Opernd
direct le calculator, utilizatorul final i intreine singur baza de date. El devine, n bun
msur, administratorul acesteia: nu va cuta, n general, s modifice structurarea logic a
datelor (tabelele, asocierile etc.), dar va dori s aib la dispoziie mijloace puternice i

19

flexibile pentru tratarea celorlalte aspecte ale administrrii: adugri de nregistrri noi,
modificri de cmpuri etc. De asemenea, el va avea nevoie de modaliti eficace de regsire a
informaiilor stocate. Un astfel de utilizator este i inginerul care folosete o baz de date
pentru alegerea materialelor.
Atunci cnd apeleaz la baza de date utilizatorul final se va gndi la tabelele n care
sunt nregistrate datele, la operaii de actualizare a acestor date, la interogarea (consultarea)
bazei de date, la editarea de rapoarte (liste) prin extragerea unor informaii stocate n ea. Se
observ c utilizatorul final are n vedere, n general, submulimi ale unei mulimi de
nregistrri din baza de date. Aceste submulimi se definesc prin enunarea unor
criterii. Sa dm cteva exemple.
a) Este necesar lista studentilor care locuiesc in cminul C2 la camera 40
b) Care sunt cursurile opionale din anul al doilea (semestrele 3 i 4)
c) S-a dat examen la Mate. Este necesar selectarea tuturor studenilor care au
frecventat cursul de Mate pentru a le completa notele luate. Lista s fie pe grupe,
alfabetic.
Toate situaiile din exemplele de mai sus se rezolv prin interogarea bazei de date;
am subliniat condiiile ce definesc diferitele submulimi de nregistrri care vor rezulta n
urma interogrii, adic criteriile de selecie. Un aspect care trebuie remarcat este acela c
interogarea poate fi fcut n diverse scopuri: afiarea unor informaii, eliminarea unor
nregistrri, completarea unor cmpuri etc. Din ultimul exemplu se mai observ ceva. n
multe cazuri, pentru a obine submulimile respective trebuie investigate mai multe tabele;
pentru exemplul c) acestea sunt STUDENTI i NOTE.

4.2. Limbajul de manipulare a datelor

Instrumentele de interogare a bazei de date relaionale sunt oferite de SGBDR prin
intermediul unui limbaj de manipulare a datelor. Crearea unor asfel de limbaje a fost, pe
lng preocuparea pentru metodele de reprezentare a datelor, o a doua preocupare major a
cercettorilor din sfera bazelor de date.
Suportul teoretic pentru dezvoltarea limbajelor relaionale de manipulare a datelor
este algebra relaional. Aceasta conine un set de operatori1 relaionali a cror aplicare
succesiv permite realizarea de combinaii pentru regsirea oricror submulimi ale datelor
colectate baz. Dezvoltarea limbajelor de manipulare a datelor bazate pe algebra relaional a
fost stimulat de mai multe considerente, unul important fiind acela c formalizarea
matematic a operatorilor relaionali i gsete un corespondent imediat n fraze-ablon
exprimate n limbaj natural. Algebra relaional ofer deci o form de exprimare uoar, dar
n bun msur standardizat, a cererilor de interogare a bazei de date. Astfel, se poate vorbi
[5] de dou posibiliti de scriere a expresiilor algebrei relaionale: forma greac (adic cea
folosind simbolistica specific matematicii) forma englez (adic cea folosind fraze-ablon).
Aceast din urm form poate constitui sursa pentru implementarea instruciunilor unui
limbaj puternic de manipulare a datelor, aa cum este, de exemplu, SQL. n ceea ce ne
privete, ne putem gndi la o traducere n romn a formei engleze a expresiilor relaionale
1

n sens general, un operator este o funcie care definete o operaie. Cu toii am avut ocazia s utilizm
operatori dei acest lucru nu era, poate, exprimat explicit: nc n liceu, am efectuat operaii de adunare a dou
numere complexe, de intersecie a dou mulimi, de derivare a unei funcii, deci am aplicat operatorii de
adunare, de intersecie, de derivare. n latin, operator = "care acioneaz asupra cuiva"

20

i, n acest fel, am avea la dispoziie o posibilitate de descriere "pe hrtie", n romnete, a

operaiilor de manipulare a coninutului bazei de date. Am obine ceva asemntor
exprimrii n pseudo-cod, care este utilizat n proiectarea programelor clasice (de tip
COBOL, PASCAL,...) pentru descrierea preliminar, n limbaj natural, a succesiunii
prelucrrilor.
Operatorii acioneaz asupra tabelelor. Exist diferite clasificri ale acestora. O
vom cita aici pe cea din [4] deoarece pune n eviden, ntr-o categorie separat, acei
operatori care sunt specifici strict algebrei relaionale.
Operatori tradiionali pe mulimi: reuniunea, intersecia, diferena, produsul
cartezian
Operatori relaionali speciali: selecia, proiecia, jonciunea, diviziunea, etc.
Pentru ilustrare, vom da detalii n legtur cu operatorul de selecie i cel de proiecie.
Selecia.
Scopul aplicrii acestui operator este de a regsi anumite linii (tupluri) dintr-o tabel.
Care sunt aceste linii, rezult din impunerea unei condiii, numit predicat, care va fi
verificat n legtur cu fiecare tuplu. Submulimea rezultat este format din liniile pentru
care predicatul este adevrat. n Fig. 14 a se ilustreaz intuitiv aplicarea operatorului de
selecie; liniile de culoare mai nchis formeaz submulimea celor care ndeplinesc condiia.
S exprimm operaia n scriere greac i n scriere englez
Scrierea greac.
predicat (nume-tabel)
este notaia pentru operatorul de selecie, indicele precizeaz predicatul (condiia),
iar parametrul nume-tabela indic tabela asupra creia acioneaz selecia.
Scrierea englez:
SELECT nume-tabela WHERE predicat [GIVING tabel-nou];
Preciznd c SELECT nseamn "selecteaz", WHERE nseamn "unde", iar
GIVING nseamn "dnd, rezultnd", s admitem c aceast form de scriere, dei mai
lung, este mai atractiv. S mai observm c, fcnd o traducere a propoziiei englezeti,
putem obine un "pseudocod" n limba romn. Rmne de discutat dac merit efortul. S
mai observm c n scrierea englez mai apare i segmentul GIVING... ; el este scris n
paranteze ptrate, aceasta nsemnnd c utilizarea sa este opional. Atunci cnd este folosit,
partea GIVING... indic numele unei noi tabele care va fi creat din prima, prin aplicarea
operatorului de selecie.

b
Fig. 14. a) Aciunea operatorului de selecie
b) Aciunea operatorului de proiecie

21

Proiecia.
Operatorul de proiecie trebuie aplicat atunci cnd se dorete alegerea unor anumite
coloane ale tabelei.
Scrierea greac:
col1,...,colN (nume-tabel)
este simbolul operatorului de proiecie
nume-tabel identific tabela asupra creia acioneaz operatorul
col1, ..., colN este lista coloanelor vizate.
O imagine intuitiv este dat n Fig. 14 b; coloanele de culoare mai nchis sunt cele
asupra crora a acionat operatorul de proiecie.
Scrierea englez:
PROJECT nume-tabel OVER (col1,...,colN)
[GIVING tabel-nou];
Compunerea operatorilor.
Operatorii fiind funcii, se poate vorbi despre compunerea acestora. S lum ca
exemplu compunerea operatorilor de selecie i de proiecie.
Scrierea greac:
col1,...,colN (predicat (nume-tabel))
n scrierea englez apar doi pai consecutivi:
SELECT nume-tabel
WHERE predicat
GIVING tabel-temporar;
PROJECT tabel-temporar
OVER col1, ..., colN;
Se observ apariia unei tabele temporare care este necesar pentru a transforma
rezultatul operaturului SELECT n parametru de intrare pentru operatorul PROJECT.
n scriere englez, compunere celor doi operatori ai algebrei relaionale s-a tradus
ntr-o aplicare succesiv a acestora. n cazul de fa, ordinea de aplicare a operatorilor ar
putea fi inversat: nti proiecia, apoi selecia. n alte cazuri, ns, este important ordinea
aplicrii operatorilor la fel cum, n cazul unui program (de exemplu n limbajul BASIC),
ordinea instruciunilor este esenial pentru corectitudinea desfurrii prelucrrilor. Aceasta
este o abordare de tip limbaj procedural: trebuie descris fiecare pas, precum i ordinea n
care acetia trebuie executai. Chiar i pentru cazul discutat se poate analiza dac nu cumva
adoptarea uneia dintre succesiunile de aplicare a operatorilor este mai avantajoas dect
cealalt pentru a mri viteza de extragere a submulimii finale. Abordarea procedural poate
crea dificulti utilizatorilor mai puin experimentai. Exist o alternativ pe care o putem
adopta, iar despre ea se va discuta mai jos, n partea dedicat limbajului SQL.
Aceast discuie a operatorilor de selecie i de proiecie a fost fcut cu scopul de a
ilustra conceptul de operator relaional. Tratri detaliate, n diferite maniere, ale acestei
chestiuni se gsesc, de exemplu, n lucrrile [4] i [5].

22

Orice SGBD pune la dispoziie un limbaj pentru descrierea i manipularea datelor.

Prin intermediul su se realizeaz practic toate aciunile legate de o baz de date: creare,
ntreinere, exploatare. Dar, deoarece majoritatea aciunilor asupra unei BD se execut n
urma unei interogri a acesteia, iar interogarea se face prin exprimarea unei cereri, limbajele
de descriere i manipulare a datelor mai sunt numite i limbaje de interogare, sau limbaje de
cereri. n cazul BD relaionale, limbajul trebuie s includ comenzi pentu definirea coleciei
de tabele i a tuturor aspectelor legate de aceasta, pentru implementarea conceptelor algebrei
relaionale, pentru accesarea datelor, pentru organizarea prezentrii rezultatelor (pe ecran,
sau la imprimant). Cel mai cunoscut rezultat n acest domeniu este limbajul SQL
(Structured Query Language). Exist astzi cteva standarde SQL; majoritatea SGBDurilor relaionale includ n limbajul de descrierea i manipluarea datelor principalele comezi
ale acestui limbaj. Vom face o descriere n linii generale a instrumentelor pe care SQL le
pune la dispoziie.
Cteva dintre caracteristicile care au asigurat popularitatea limbajului SQL sunt
legate n primul rnd de accesibilitatea pe care acesta o ofer; acest lucru se observ imediat
dac examinm implementarea noiunilor algebrei relaionale. Astfel, cererile exprimate n
SQL sunt foarte lizibile, sintaxa limbajului fiind asemntoare cu "scrierea englez" a
operatorilor relaionali. Mai mult dect att, SQL este mai degrab un limbaj declarativ
dect unul procedural. Aceasta nseamn urmtorul lucru: utilizatorul trebuie s precizeze n
cadrul comenzii doar care sunt criteriile care definesc submulimea rezultat (al interogrii).
Secvena de operatori relaionali care trebuie aplicai, precum i operaiile intermediare
asupra structurilor de date sunt n sarcina interpretorului1 SQL; ele rmn invizibile pentru
cel care a introdus comanda.
Vom da n continuare cteva exemple de comenzi SQL pentru a ilustra instrumentele
pe care acesta le pune la dispoziia utilizatorului. n redactarea formei generale a comenzilor
vom folosi cteva convenii de notaie, consacrate, de altfel. S le explicm:
- prile din comand incluse n paranteze ptrate [ ] sunt opionale i, n general,
utilizarea, sau nu, a unui astfel de segment opional d rezultate diferite;
- bara vertical | arat c trebuie utilizat una din prile separate prin acest semn, ca o
variant din mai multe posibile; n multe cazuri una dintre ele este implicit, adic va fi
aplicat automat de ctre interpretor atunci cnd nu s-a introdus n comand nici una dintre
variante;
- trei puncte ... arat c grupul de elemente precedent poate fi folosit de mai multe ori
n cadrul comenzii.

Interpretor - un program care traduce n cod main i pune efectiv n execuie, sub aceast form,
instruciunile/comenzile scrise ntr-un limbaj de programare. De exemplu, muli tineri au nvat s scrie
programe n limbajul BASIC. Doar o parte din ei tiu c maina ("calculatorul") nu poate decodifica direct
instruciunile BASIC pentru a le executa; singurele instruciuni pe care maina, mai precis microprocesorul, "le
nelege" i le poate pune n execuie sunt cele reprezentate ntr-un cod binar, specificat la proiectarea acestuia
i care este numit, din acest motiv, cod main. Faptul c instruciunile programului BASIC sunt executate, se
datoreaz interpretorului BASIC, un program care traduce instruciunile din acest limbaj n cod main, ele
devenind, astfel, executabile. La fel se petrec lucrurile i n cazul altor limbaje, de exemplu SQL. A lucra ("la
calculator") ntr-un limbaj de programare nseamn, implicit, a folosi interpretorul pentru acel limbaj. Exist i
o alt categorie de programe destinate traducerii dintr-un limbaj de programare n cod main, dar care lucreaz
ntr-o manier diferit fa de interpretoare; un astfel de program se numete compliator. Pentru limbajul
BASIC, de exemplu, exist att interpretoare, ct i compilatoare.

23

Comanda CREATE TABLE

Comanda se folosete pentru a crea o tabel i are sintaxa n urmtoarele variante:
CREATE TABLE nume-tabel
(nume-coloan tip-dat [NULL|NOT NULL] ... );
CREATE TABLE nume-tabel
(nume-coloan tip-dat [NULL|NOT NULL] ... )
AS cerere;
Identificatorul nume-tabel arat numele pe care l va primi tabela nou creat.
n continuare se vor enumera n parantez precizrile necesare pentru fiecare coloan
(atribut): numele acesteia, ce fel de date pot fi stocate n ea (numere, texte etc.) i care este
dimensiunea acestor date.
S insistm mai mult asupra opiunii NULL|NOT NULL. Pentru fiecare coloan, se
specific una din variantele NULL sau NOT NULL prin care se arat dac este sau nu
obligatoriu ca, la ncrcarea efectiv a unei noi nregistrri n tabel, coloana respectiv s
aib neaprat o valoare, sau ar putea fi lsat, eventual, necompletat; NOT NULL este
varianta care impune obligativitatea completrii, iar NULL este varianta implicit. S mai
adugm c aceast opiune este o reflectare a Regulii 3 a lui Codd care impune tratarea
riguroas a valorilor NULL: Un SGBD relaional trebuie s asigure utilizarea valorii NULL;
valoarea NULL semnific lipsa informaiilor n legtur cu o anumit dat, indiferent de
tipul acesteia, deci trebuie s fie distinct de valoarea numeric zero, sau de irul de
caractere vid. Orice tabel trebuie s aib mcar un cmp pentru care s se impun condiia
NOT NULL, adic pentru care s fie obligatorie existena unei valori completate: este vorba
de cmpul/cmpurile care constituie cheia primar a tabelei.
Exemplu. Vom scrie comanda pentru a crearea tabelei STUDENTI :
CREATE TABLE STUDENTI
(Nume CHAR (25) NOT NULL,
Prenume CHAR (30) NOT NULL,
Matricola NUMBER (4,0) NOT NULL,
Localit CHAR (25) NOT NULL,
Jud CHAR (2) NOT NULL,
Camin CHAR (5),
Cam NUMBER (3,0));
Comanda de mai sus este pentru crearea tabelei STUDENTI. n parantez sunt
enumerate cmpurile din care este compus aceast tabel precizndu-se, pentru fiecare,
tipul, dimensiunea i dac este obligatorie completarea sa.
S mai facem precizarea, valabil pentru toate comenzile, c ntre implementrile
standardului SQL realizate de diferite firme de software exist diferene; de pild, declararea
tipurilor de date (caracter, numeric etc.) poate avea alte forme dect n exemplul dat mai sus.
n legtur cu o tabel creat exist comenzi de manipulare a datelor, cum sunt:
INSERT - pentru introducere de noi entiti (nregistrri) n tabel;
DELETE - pentru eliminare de entiti din tabel;
UPDATE - pentru modificarea valorilor unuia sau mai multor atribute (coloane) ale
tabelei (Update = aducere la zi, actualizare);

24

DROP TABLE - pentru eliminarea unei tabele din arhitectura bazei de date;
ALTER TABLE - pentru modificarea structurii tabelei (modificri, adugri de
coloane).
Comanda SELECT
Aceasta este comanda principal pentru interogarea bazei de date; este folosit
interactiv, pentru a se obine un rspuns imediat, sau poate fi inclus ntr-un program pentru
a participa la operaii complexe de regsire i manipulare a datelor.
Sintaxa de baz este:
SELECT list-cmpuri-1
FROM nume-tabel
[WHERE criteriu-de-cutare-1]
[GROUP BY list-cmpuri-2]
[HAVING criteriu-de-cutare-2]
[ORDER BY list-cmpuri-3];
O traducere a cuvintelor cheie sugereaz imediat sensul frazei: SELECT = selecteaz,
FROM = din, WHERE = unde, GROUP BY = grupeaz dup, HAVING = avnd, ORDER
BY = ordoneaz dup. Celelalte elemente din comand au semnificaiile urmtoare:
list-cmpuri-1 arat cmpurile (coloanele) care intereseaz din tabel, deci d
informaii pentru aplicarea operatorului de proiecie;
nume-tabel arat tabela n care se face cutarea;
criteriu-de-cutare-1 arat condiiile pe care s le ndeplineasc
nregistrrile care vor fi selectate, deci constituie predicatul pentru operatorul de selecie;
list-cmpuri-2 din clauza GROUP BY arat cum vor fi grupate nregistrrile
extrase prin interogare;
criteriu-de-cutare-2 din clauza HAVING arat care dintre nregistrrile
grupate (ca efect al lui GROUP BY) s fie afiate, deci exprim predicatul ntr-o nou
aplicare a operatorului de selecie;
list-cmpuri-3 din clauza ORDER BY arat ordinea n care vor fi afiate
nregistrrile selectate; pentru fiecare cmp din list, reprezentnd un criteriu de sortare, se
va preciza varianta de ordonare, ASC (ascendent) sau DESC (descendent).
Exemplu. Vom scriem fraza SELECT pentru afiarea student[ilor care locuiesc `n
c\minul C2, camera 40.
SELECT Nume, Prenume, Matricola
FROM STUDENTI
WHERE Cmin = C2 AND Cam = 40
ORDER BY Nume ASC, Prenume ASC;
Comanda SELECT se folosete i pentru cutri mai complexe. n unele situaii
cutarea se face prin investigarea mai multor tabele. ntr-un astfel de caz, listcmpuri-1 va conine numele cmpurilor care intereseaz din fiecare tabel, iar n clauza
FROM se va preciza lista tabelelor care vor fi examinate. Din punctul de vedere al algebrei
relaionale, n acest tip de cutare este folosit i operatorul de jonciune (n englez, join).
n alte situaii se folosete o comand SELECT pentru exprimarea unei "subcereri" n
cadrul unei cereri, exprimat i ea printr-o fraz SELECT; operaia se numete imbricare (a
unei/unor comenzi n cadrul alteia). n aceste cazuri, subcererile SELECT vor aprea ca
predicate n clauzele WHERE i/sau HAVING ale cererii generale, putnd avea, la rndul

25

lor, subcereri incluse n caluzele proprii. De asemenea, sunt implicate, de obicei, mai multe
tabele.
Eumerarea celor cteva comenzi, fcut mai sus, a avut rolul de a ilsutra
caracteristicile generale ale limbajului SQL i modul su de folosire. S-a observat caracterul
declarativ al comenzilor acestuia: n fraza SELECT, de pild, utilizatorul descrie, de fapt,
rezultatul pe care vrea s-l obin n urma interogrii, iar interpretorul SQL este cel care
aplic, n ordinea "tiu de el", operatorii necesari din algebra relaional. SQL nu este,
totui, un limbaj pur declarativ; el are i trsturi procedurale, un exemplu fiind folosirea
blocurilor de comenzi imbricate.

4.3. Indexare
Indexarea este o metod de sporire a vitezei de acces la datele din baz. Conceptul
este legat de aspecte privind organizarea la nivel fizic a datelor; pentru a-l explica, vom
puncta din nou cteva momente din istoria evoluiei tehnicii de calcul. Vom face i unele
analogii cu situaii pe care le ntlnim zi de zi, care nu au (aparent) nici o legtur cu
calculatoarele.
Primele suporturi de mare capacitate pentru stocarea datelor au fost benzile
magnetice. Entitile unei colecii logice (cum sunt liniile unei tabele) erau nregistrate
secvenial. Pentru a ajunge la o anumit nregistrare, trebuiau parcurse toate nregistrrile
(deci o "citire n gol") pn era gsit ceea ce se cuta. Am putea compara acest lucru cu
cutarea unei melodii pe o band de magnetofon: ar trebui, n principiu, s le ascultm pe
toate pn apare cea cutat. Acesta este accesul secvenial la nregistrri. Dac nregistrarea
se afla spre sfritul benzii, timpul necesar regsirii era de ordinul minutelor.
Apariia discurilor magnetice ca nou soluie de stocare, a revoluionat performanele
n privina vitezei de acces la informaii. Pe discul magnetic informaiile sunt nregistrate pe
piste concentrice, iar pistele sunt mprite n sectoare (Fig 15). Toate pistele au acelai
numr de sectoare, toate sectoarele au aceeai capacitate de nregistrare (deci pe pistele
exterioare nregistrarea este mai "rarefiat" dect pe cele interioare), iar aceast capacitatea
are o valoare fix, independent de natura informaiilor care se nregistreaz pe disc. Sectorul
este unitatea elementar de transfer ntre disc i memorie: la o citire de pe (ori la o scriere
pe) disc se transfer un ntreg sector de informaii; el reprezint nregistrarea fizic. Capul
de citire/scriere se deplaseaz pe direcie pe direcie radial fa de disc i se poziioneaz
direct pe pista pe care se afl nregistrarea dorit (am luat n discuie citirea de pe disc, dar
lucrurile se petrec similar i la scriere); discul se nvrtete, iar sectorul pe care se afl
nregistrarea cutat este citit (copiat n memorie) n momentul trecerii prin dreptul capului.
Pn aici am descris principiul de nregistrare pe o fa a discului. Dischetele (Floppy Disk)
au piste pe ambele fee, iar staiile de citire/scriere au dou capete, cte unul pentru fiecare
fa; ele se deplaseaz solidar, poziionndu-se simultan, pe ambele fee, pe pistele cu acelai
numr de ordine; pistele cu acelai numr de ordine de pe fiecare fa formeaz un cilindru.
Deci, la un moment dat, capetele sunt poziionate pe un cilindru, iar unul din ele citete sau
scrie un sector al acestuia. La discurile dure (Hard Disk) principiul general este acelai, dar
aici este vorba de mai multe discuri fixate pe un ax comun; deci sunt mai multe fee i
numrul corespunztor de capete de citiree/scriere. Bineneles, un cilindru este format din
toate pistele de pe fiecare fa care au acelai numr de ordine. n Fig. 15 sunt ilustrate foarte
sumar cele descrise mai sus.
Acest principiu de funcionare prin care capetele de citire/scriere se
poziioneaz pe cilindrul unde se afl nregistrarea reprezint accesul direct la

26

informaie. Datorit acestuia, precum i ca urmare a progreselor n tehnologia de fabricaie,

n cazul discurilor dure timpul de acces se msoar, astzi, n milisecunde. Dac la accesul
secvenial am fcut o analogie cu banda audio pentru a arta cum funcioneaz banda
magnetic pentru stocarea datelor, n cazul discurilor am putea face, iat, o analogie n sens
invers. Toat lumea tie c, n prezent, sistemul cel mai performant de nregistrare a muzicii
este CD-ul; mai tim c aparatele CD-Player dau posibilitatea selectrii prealabile a
succesiunii de melodii (n maniera 1,5,3,9,...) care vor fi reproduse. Cei care s-au ntrebat
cum se realizeaz acest lucru trebuie doar s-i aminteasc de principiul accesului direct de
la discurile magnetice i s fac analogia necesar.
Pentru a beneficia de avantajele accesului direct mai trebuia rezolvat o problem:
cum se stabilete locul n care se gsete nregistrarea cutat? n lipsa unor informaii de
localizare, pistele i sectoarele ar trebui parcurse tot secvenial pn la nregistrarea
respectiv, deci avantajul accesului direct ar disprea. Indexarea a fost una din metodele (nu
singura) de a introduce informaii de localizare a nregistrrilor n cadrul fiierelor. Tehnica a
fost preluat i este folosit n tehnologia bazelor de date relaionale pentru a mri viteza de
cutare.

Fig. 15.
Principiul de nregistrare a
informaiilor pe Hard Disk;
toate pistele cu acelai numr de
ordine formeaz un cilindru.

Ideea este aceeai ca n cazul folosirii unui manual. Dac dorim s citim un anumit
capitol am putea s rsfoim cartea, pagin cu pagin, pn gsim capitolul, dar aceast
"accesare secvenial" ar lua prea mult timp. Bineneles, mult mai rapid este s consultm
nti cuprinsul care este, iat, o tabel index n care sunt listate nite chei de acces
(denumirile capitolelor) nsoite de informaii de localizare (numerele paginilor); cutm n
tabel (cuprins) cheia de acces (numele capitolului), lum informaia de localizare

27

corespunztoare (numrul paginii), apoi mergem direct la pagina respectiv, deci facem o
accesare direct a fondului de informaii. O alt situaie, la fel de frecvent ntlnit: dorim
informaii n legtur cu o anumit noiune tratat n carte. Am putea s folosim aceeai
metod, depistnd capitolul n care tim c se afl noiunea, iar n cadrul capitolului cutm
secvenial. Dar ar fi i mai convenabil dac manualul ar avea, ca anex, un indice alfabetic al
noiunilor, deci o a doua tabel index, organizat altfel; n ea am gsi mai uor noiunea care
ne intereseaz (cheia de acces) i paginile la care se discut despre ea (informaiile de
localizare). Bineneles, aceste dou tabele index (cuprinsul i indicele alfabetic) ocup
pagini suplimentare ("spaiu de stocare") i au consumat timp pentru a fi puse al punct, dar
acesta este preul care trebuie pltit pentru a avea la dispoziie dou instrumente de acces
direct, rapid, la fondul de informaii. S mai subliniem i faptul, foarte important, c cele
dou tabele index de care am vorbit mai sus rezolv cutarea rapid n dou tipuri de
situaii care apar foarte frecvent, dar nu rezolv orice fel de cutare. Dac dorim, de
exemplu, s revedem Figura 81 din carte, nici cuprinsul, nici indicele alfabetic nu ne ajut cu
nimic i va trebui s folsim tot accesul secvenial. Am putea s construim o a treia tabel
index, pentru figuri; trebuie, ns, s cntrim dac ea va fi att de des folosit pentru a
merita s consumm timp i pagini de carte pentru a o realiza.
Aplicnd ideea la bazele de date relaionale, rezult imediat c indexarea unei tabele
nseamn crearea unor tabele suplimentare speciale, tabele index, pentru accesarea
direct, n diferite moduri, a informaiilor din tabela vizat. O tabel index este definit
de ctre utilizator printr-o comand cu caracter declarativ i este generat automat de ctre
SGBD, n urma acestei comenzi. Ea are dou coloane: prima coloan conine valorile cheii
de indexare (de acces), iar n a doua coloan se afl, corespunztor, pointeri (informaii de
localizare) la nregistrrile din tabel. Cheia din tabela index se definete ca o combinaie de
cmpuri din structura nregistrrii tabelei care a fost supus indexrii i folosete tocmai la
identificarea nregistrrilor (entitilor). Tabelele index sunt folosite automat de ctre SGBD.
Cnd face o cutare ntr-o tabel a bazei de date folosind o tabel index asociat ei, SGBD-ul
caut valoarea cheii de indexare pentru a identifica nregistrarea, apoi folosete pointerul
(informaia de localizare) pentru a accesa direct linia corespunztoare din tabela de origine.
SQL posed comand pentru indexare: comanda CREATE INDEX ("creaz index").
Sintaxa de baz a comenzii este:
CREATE [UNIQUE] INDEX nume-index
ON (coloan1 [ASC|DESC], ...);
nume-tabela este tabela din baza de date care este supus indexrii.
coloan1, coloan2, ... sunt coloanele din tabel care vor participa (n
aceast ordine!) la formarea cheii de acces (coloana stng a tebelei index); pentru fiecare
coloan se specific ordinea de sortare a valorilor din ea: ascendent (ASC), care este i
varianta implicit, sau descendent (DESC).
nume-index este numele pe care l primete tabela index nou creat. Utilizatorul
nu va folosi explicit acest nume atunci cnd va face interogri ale bazei de date; dup cum
am vzut mai sus, sintaxa comenzii SELECT nu conine nici un segment referitor la index.
SGBD-ul decide dac, pentru rezolvarea unei cereri de interogare, i este util folosirea uneia
din tabelele index asociate tabelei investigate. Rolul lui nume-index este de a indentifica
tabela index atunci cnd se va dori eliminarea ei, deci cnd se va renuna la indexarea
respectiv; comanda corespunztoare acestei operaii este DROP INDEX.
UNIQUE este o opiune care se folosete pentru a preveni apariia valorilor duplicate
n cmpurile indexate. Dac aceast opiune a fost folosit i se face o tentativ de
introducere n tabel a unei linii (nregistrri) care are aceeai valoare a indexului cu o
28

nregistrare deja existent, introducerea va fi refuzat, iar pe ecran va aprea un maesa de

eroare.
Exemplu.
CREATE UNIQUE INDEX INDX_STUDENTI
ON STUDENTI (Nume, Matricola);
S-a indexat tabela STUDENTI dup cmpurile Nume i Matricola; aceste cmpuri
vor forma, n ordinea specificat n comand, cheia de acces (partea stng a tabelei index).
Pentru ambele cmpuri se folosete ordonarea cresctoare (implicit). Tabela index a primit
numele INDX_STUDENTI.
Interogrile SQL funcioneaz i fr ajutorul tabelelor index, dar indexarea aduce un
plus de vitez, n special cnd este vorba de tabele de mari dimensiuni. Pe de alt parte,
trebuie inut cont de faptul c fiecare adugare a unui index nou unei tabele ncetinete
viteza la operaiile de actualizare (adugri i tergeri de linii). Fcnd din nou apel la
comparaia cu cartea vom vedea c, ntr-adevr, aa este. Dac autorul crii introduce un
nou capitol printre cele existente, va trebui s modifice cuprinsul (prima "tabel index"): va
introduce titlurile capitolului i ale paragrafelor i, din cauza faptului c numerotarea
paginilor s-a schimbat, va trebui s fac modificrile necesare i n cuprins. Astfel de
modificri de coninut i localizare, dar i mai laborioase, trebuie fcute i asupra indicelui
alfabetic (a doua "tabel index") unde apar noi termeni provenii din capitolul nou introdus.
De aceea spuneam la locul respectiv c, nainte de a introduce o nou "tabel index" (pentru
figuri, de exemplu) trebuie cntrit dac aceasta va fi suficient de util pentru a justifica
efortul crerii i ntreinerii sale ulterioare. Deci, atunci cnd studiem oporunitatea crerii
unui index asociat unei tabele a bazei de date, trebuie s apreciem dac avantajul pe care l
obinem prin mrirea vitezei de cutare la consultarea tabelei este mai mare dect preul care
trebuie pltit, adic micorarea vitezei la actualizare. n bun mur, acest lucru poate fi
decis, nu prin calcule, ci prin experimentri asupra bazei de date; oricum, eficiena indexrii,
chiar numai n ce privete consultarea, se pune doar n legtur cu tabele care au de la cteva
sute de nregistrri n sus.

4.4. Tenhici declarative de manipulare a datelor.

Am artat mai sus c SQL este un limbaj "mai degrab declarativ, dect procedural",
fiind mai apropiat de maniera declarativ , dar avnd i caracteristici procedurale. Din acest
punct de vedere, el ocup o poziie intermediar ntre limbajele procedurale, cum sunt
COBOL, BASIC, PASCAL etc., numite limbaje de generaia a treia sau 3GL (third
generation language) i o alt categorie, 4GL, limbajele de generaia a patra (fourth
generation language) la care exprimarea declarativ este o caracteristic fundamental. Dei
nu este stabilit o definiie universal acceptat pentru limbajele de generaia a patra, noiunile
prezentate n continuare sunt considerate [5] ca avnd caracteristici de tip 4GL. Ele sunt
implementate n cadrul SGBD-urilor moderne ca instrumente menite s asigure, pe de o
parte, faciliti suplimentare de interogare la ndemna utilizatorilor neinformaticieni i, pe
de alt parte, mijloace de cretere a productivitii muncii pentru informaticienii care
proiecteaz baze de date de mare complexitate. La toate exemplele care vor urma se observ
o trstur comun care a determinat includerea acestor faciliti n categoria 4GL:
utilizatorul descrie ceea ce dorete s obin, iar componenta software corespunztoare face
restul. O caracteristic important este aceea nu mai trebuie introduse de la tastatur textele
comenzilor dorite (ca n SQL, de exemplu), ci exist mijloace garfice, mult mai comode, de
29

dialog cu sistemul1. Vom trece n revist, n acest context, dou tehnici de interogare, QBE i
QBF, dup care vom discuta, pe scurt, despre editarea rapoartelor.
QBE.
n traducere liber, QBE (Query By Example), nseamn interogare prin exemplu.
Aceasta este una din modalitile grafice, neprocedurale, de exprimare a unei cereri de
interogare. Utilizatorul are la dispoziie, pe ecran, o machet a tabelei; el va exprima cererea
prin completarea spaiilor libere din machet.
Exemplu. Pentru tabela STUDENTI, macheta QBE va avea forma din Fig. 16.
STUDENTI
Nume
Prenume

Matricola

Localit

Jud

Camin

Cam

Fig. 16 Macheta tip QBE pentru tabela STUDENTI

Pentru a afla studen]ii care locuiesc `n c\minul C2 la camera 40, utilizatorul va

completa rubricile corespunztoare din machet:

STUDENTI
Nume
Prenume

Matricola

Localit

Jud

Camin

Cam
40

Fig. 17 Exemplu de completare a machetei QBE

Am dat mai sus un exemplu foarte simplu pentru ilustrare. Tehnica QBE are, ns,
posibiliti mult mai complexe: n completarea rubricilor se poate folosi o mare diversitate de
operatori, interogarea poate fi aplicat mai multor tabele, macheta poate avea linii
suplimentare, de exemplu pentru precizarea unor criterii de sortare etc.
QBF.
Am putea traduce QBF (Query By Form) ca "cerere prin formular". Cuvntul
englez "form" are multe sensuri, printre care form i formular. Am adoptat aceast din
urm traducere deoarece credem c ilustreaz cel mai bine intenia care pare c a stat iniial
la baza dezvoltrii acestei tehnici: apropierea manipulrii bazei de date de modul tradiional
de lucru, cu formulare "de hrtie". Oricine se ntlnete, aproape zilnic, cu formularistica
tipizat: la locul de munc, la bibliotec, la pot, la banc; n fiecare din aceste situaii,
formularul are legtur cu un fond de date (stocuri de materiale, liste de abonai, conturi
financiare .a.m.d.). Formularul devenind o "component a modului de via", apare normal
conceperea unei modaliti dialog cu baza de date n aceast manier. Ideea general este c
1

Comunicarea cu utilizatorul prin mijloace grafice este, de altfel, o caracteristic generalizat la produsele
software moderne, fiind denumit, generic, GUI (Graphical User Interface - "interfa grafic cu utilizatorul").
n privina calculatoarelor din familia PC, aceast manier de realizare este promovat, n prezent, chiar prin
standardul neoficial pe care l-a impus noul sistem de operare WINDOWS care este, el nsui, produs tip GUI.

30

datele din baz (coninutul unei tabele, rezultatul unei interogri) pot fi vizualizate n dou
moduri: ca o list sau ca un formular1.
Imaginea de tip list (List View) este tabelar. Pe ecran apar mai multe nregistrri,
fiecare ocupnd o linie a listei. n cazul vizualizrii unei singure tabele, aceast imagine este
aproape identic cu macheta tabelei, aa cum a fost ea definit i inclus n diagrama
entitate-relaie la proiectarea bazei de date. Bineneles, imaginea de tip list poate arta nu
doar ntregul coninut al unei singure tabele, ci poate fi folosit pentru a vizualiza rezultatul
oricrei interogri asupra uneia sau mai multor tabele. Utilizatorul se poate deplasa prin list
pentru a face adugri, tergeri, modificri de cmpuri, poate elimina unele linii (nregistrri)
sau poate insera altele noi.
Imaginea de tip formular (Form View) afieaz pe ecran o singur nregistrare la un
moment dat. Avantajul ei este, ns, posibilitatea organizrii ecranului dup dorin. Se poate
face, de exemplu, o machetare a imaginii astfel nct aceasta s aib acelai aspect cu
formularul tipizat de pe care se face preluarea datelor; pentru o operatoare care face
culegerea datelor, acest lucru poate fi foarte important. n aceast machet pot fi incluse texte
suplimentare, explicative, care nu fac parte din nregistrare, dar care mresc sugestivitatea
imaginii sau dau indicaii de operare. La fel ca i imaginea de tip list, imaginea de tip
formular poate fi rezultatul unei interogri oarecare fcut, eventual, asupra mai multor
tabele. Utilizatorul poate intra n rubricile formularului pentru a face actualizri ale
cmpurilor corespunztoare, poate aduga o nou nregistrare completnd un formular gol
sau poate comanda eliminarea din baz a nregistrrii care este afiat la un moment dat.
QBF (Query By Form) este tehnica de interogare n care utilizatorul exprim cererea
prin completarea rubricilor necesare n cadrul unui formular ("de cerere") prestabilit; n
rubricile formularului se completeaz, de fapt, criteriile dup care se va face selectarea
nregistrrilor din tabelele bazei de date. i aici este posibil utilizarea unei multiudini de
operatori (logici, de comparare etc.) la completarea rubricilor pentru a defini criteriile
interogare. n proiectarea formularului, acestuia i se pot ataa butoane grafice de aciune sau
de opiune precum i orice alte elemente de control care, n prezent, sunt larg utilizate ca
mijloace grafice de dialog cu aplicaiile software.
Editare de rapoarte
Una din facilitile importante 4GL este editarea de rapoarte. Un raport este creat
pentru a vizualiza pe ecran sau, mai frecvent, la imprimant, informaii din baza de date.
Raportul are caracteristici proprii care l deosebesc de alte modaliti de vizualizare a datelor
(cum ar fi, de exemplu, imaginea de tip list): nregistrrile pot fi grupate pe mai multe
niveluri, iar la fiecare nivel se pot calcula totaluri, medii etc.; se pot defini titluri i capete de
tabel pentru raport i pentru fiecare pagin a acestuia, variante de numerotare a paginilor
precum i diferite modaliti de ncheiere a acestora sau a ntregului raport (de exemplu,
rubrici pentru semnturi); se pot preciza condiii de trecere la pagin nou (de exemplu, care
grupuri de linii s nceap a fi tiprite la pagin nou). Faciliti pentru editarea rapoartelor
au fost incluse i n anumite limbaje de generaia a treia; astfel, limbajul COBOL are
seciune special pentru definirea rapoartelor i instruciuni speciale pentru generarea
acestora, dar modul de lucru era, bineneles, procedural. n 4GL definirea i generarea
rapoartelor a cptat un puternic caracter declarativ; utilizatorul are al dispoziie mijloace
grafice, mult mai comode de a descrie structura i aspectul raportului (grupurile de

Pentru cuvntul englez form se ntlnesc, n acest context, diverse traduceri, de exemplu: "form" sau
"format"; credem c traducerea "formular" este la fel de bun (sau de rea) ca i celelalte.

31

nregistrri, totalurile pariale, titlurile i capetele de tabel etc.), iar generarea i vizualizarea
sau tiprirea raportului cade n sarcina SGBD-ului.

n final s menionm faptul c, n prezent, Sistemele de Gestiune a Bazelor de

Date oferite de marile firme de software sunt medii complexe de dezvoltare a aplicaiilor n
jurul bazelor de date. Pentru a le face ct mai atractive pentru utilizatori, productorii
acestora includ o gam larg de faciliti de tip CASE (Computer Aided Software
Engineering - Inginerie Software Asistat de Calculator): instrumente pentru definirea
grafic, interactiv, tabelelor i a diagramei entitate-asociere, pentru descrierea restruciilor
de validare a datelor de intrare, pentru construirea expresiilor, pentru proiectarea
formularelor de afiare, a rapoartelor, a meniurilor i casetelor de dialog n conformitate cu
standardele actuale. Continua apariie de noi versiuni ale instrumenteor de dezvoltare
demonstreaz interesul mereu actual att tiinific, ct i comercial pentru progresul
domeniului bazelor de date.

32

REFERAT I
TEM| DE APLICAIE PRACTIC
S se trateze o problem de gestiune a datelor i s se realizeze o aplicaie cu baz de
date relaional care s rezolve problema respectiv.
Baza de date trebuie s conin:
- cel puin 3 tabele conectate prin asocieri;
- cel puin 2 formulare
- cel puin 3 interogri
- cel puin 1 raport
Cel puin unul dintre tabelele bazei de date s aib 25-30 de nregistrri.
S se descrie ntr-un referat problema de prelucrare a datelor abordat i s se
evidenieze soluiile informatice adoptate n proiectarea bazei de date.
S se salveze baza de date pe o dischet i s se predea mpreun cu referatul.
SGBD-ul recomandat a fi folosit este Microsoft Access.

33