Sunteți pe pagina 1din 58

Limbajul bazelor de date relaionale SQL

Limbajul bazelor de date relaionale SQL


Lecia 13. Limbajul SQL. Funciile i posibilitile de baz.
13.1. SEQUEL/SQL SGBD System R
Limbajul de interaciune cu BD SQL a aprut la mijlocul anilor 70 i a fost elaborat pe
baza proiectului SGBD System R relaionale experimentale. Denumirea primar a limbajului
SEQUEL(Structured English Query Language) reflect doar parial esena acestui limbaj.
Desigur, n mod general, limbajul a fost orientat spre o formulare mai comod i mai neleas a
adresrilor ctre BD relaionale, dar n realitate era de acum un un limbaj complet de BD,
coninnd, n afar de operaiile formulrii adresrilor i manipulrilor BD, mijloace de
manipulare i determinare cu schema BD: determinarea limitelor integritii i a trigherilor,
afirii BD, posibilitile determinrii structurilor nivelului fizic, care determin executarea
efectiv a adresrilor; autorizaiile accesului la relaii i la cmpurile lor; a punctelor de salvare a
tranzaciilor. n limbaj lipseau mijloacele de sincronizare a accesului la obiectele BD din partea
tranzaciilor efectuate paralel: de la bun nceput se presupunea c sincronizarea neaprateste
executat de SGBD.
S analizm posibilitile acestui limbaj un pic mai amnunit.

13.1.1. Adresrile i operatorii de manipulare cu datele
Dup cte tim, dou limbaje de baz de adresare ctre BD relaionale sunt limbajul
algebrei relaionale i a calculului relaional. Cu toat stricteea i statornicia sa teoretic aceste
limbaje se utilizeaz rar n SGBD relaionale moderne, n calitate de mijloace a interfeei
utilizatorului. Adresrile n aceste limbaje snt greu de formulat i de neles. SQL reprezint o
combinaie oarecare a calculului relaional combinaional a cortejelor i a algebrei relaionale, n
afar de aceasta nc nu este clar cror din cele clasice acest limbaj este mai apropiat. Cu toate
acestea limbajul SQL are posibiliti mai largi, ca limbajele relaionale de baz, de exemplu, n
caz general este imposibil translarea adresei, formulat n SQL, ntr-un cuvnt a algebrei
relaionale, este nevoie de o oarecare lrgire. Proprietile de baz a sublimbajului de adresri
SQL sunt posibiliti de a formula uor adresrile cu legtura ctorva relaii i subadreselor
depuse n predicatele alegerii. Deci posedarea concomitent a ambelor mijloace este extensiv,
dar acest fapt d posibilitatea utilizatorului, n timpul formulrii adresrii, de a alege varianta
cea mai clar neleas.
n predicatele cu subadresrile depuse n SQL System R este posibil de a utiliza teoretic o
mulime de operatori de comparaie, ceea ce permite de a formula adresri cuantificate(ceea ce
de obicei, cel mai greu este neles de utilizatori, de aceea n SQL au aprut predicate
cuantificabile).
O deosebire principal a limbajului SQL este posibilitatea prezenta n adresare
necesitatea gruprii apartenenei-rezultatului pe cmpurile determinate, cu ajutorul condiiilor de
selectare a ntregii grupe. Aa fel de condiii de selectare pot conine funcii de agregat, calculate
pe grup. Aceast posibilitate a SQL n mod principal deosebete acest limbaj de limbajele
algebrei relaionale i a calculului relaional, care nu conine surse analogice.
O alt deosebire a limbajului SQL nu este tergerea neaprat a cortejelor-dublicate n
relaii rezultatele finale sau intermediare. Altfel spus, rezultatul operatorului tergerii n
limbajul SQL este mulimea cortejelor i nu a relaiilor. n cazurile cnd semantica adresrilor
cere prezena relaiei, distrugerea predicatelor are loc neclar.

Cel mai general tip de adresare n limbajul SQL este expresia algebric alctuit din
adresri elementare. n SQL System R erau admise toate operaiile de baz(UNION,
INTERSECT i MINUS).
Lucrul cu expresiile nedeterminate n SQL System R nu a fost gndit pn la urm, cu
toate c se presupunea utilizarea logicii cu trei simboluri, n cazul determinrii expresiilor logice.
Operatorii de manipulare cu datele UPDATE i DELETE sunt construite pe baza
acelorai principii ca i operatorul de selecie a datelor SELECT. Colectarea cortejurilor relaiei
date, care aparin modificrii sau tergerii, se determin cu ajutorul expresiei logice care face
parte din operatorul dat i care poate conine predicate compuse i de asemenea cu subadresri
depuse.
n operatorul de includere a cortejurilor n relaia dat, cortejul ce se va include poate fi
definit att n form literar, ct i cu ajutorul suboperatorului interior de selecie.

13.1.2. Operatori de manipulare i determinare a schemei BD
Din componena operatorilor de determinare a schemei BD SQL System R fceau parte
operatorii de creare i distrugere a relaiilor pstrate permanent i temporar(CREATE TABLE i
DROP TABLE) i crearea i distrugerea relaiilor afiabile(CREATE VIEW i DROP VIEW). n
limbaj i n realizarea System R nu se interzicea utilizarea operatorilor de utilizare a schemei n
limitele tranzaciei, care conine operatorii de selecie i de manipulare cu datele. Se permitea, de
exemplu, utilizarea operatorilor de selecie i de manipulare cu datele, n care se accentuieaz
relaia neexistent n baza de date n timpul compilrii operatorului. Desigur, aceast posibilitate
ngreuna considerabil realizarea i n fond i utilizarea foarte rar.
Operatorul de manipulare cu schema BD ALTER TABLE avea posibilitatea de a aduga
cmpurile selectate la relaie existent. n descierea limbajului se determina, c execuia acestui
operator nu trebuie s aduc la faptul c compilarea operatorilor asupra relaiei s nu fie
adevrat, relaie schema creia se schimb i c sensul cmpurilor din nou determinate n
cortejele existente a relaiei devin nedeterminate.
13.1.3. Determinarea limitelor integritii i a trigherelor
Limbajul SQL System R includea surse foarte puternice de control i meninere a
integritii BD. Sursele de control se bazau pe aparatul de limite a integritii(ASSERTIONS).
Dup ideie, limita integritii este expresia logic, determinat pe starea actual a BD,
neadevrul creia corespunde cu starea neintegr a BD. Expresia logic a limitei integritii
poate conine orice predicat admisibil n limbaj.
Mai precis, limitele integritii se mpart n dou clase: controlabile n urma executrii
operatorului de manipulare cu datele i controlabile la sfritul tranzaciei sau la executarea
operatorului special INFORCE INTEGRITY. Tipurile predicatelor ce pot fi utilizate n n
operatorii de determinare a limitelor integritii de clase diferite, difer. n operaiile din prima
clas se controleaz cortejul actual, cu care are loc manipularea. n cazul doi se controleaz
relaiile accentuate n limitele integritii, adic toate cortejele lor. Se deosebete i reacia
determinat n limbaj, reacia sistemului la nclcarea limitelor integritii diferitor clase. n
primul caz nclcarea limitelor integritii aduce la napoierea tranzaciei n punctul care e
neaprat premrgtor operaiilor de manipulare cu datele, ndeplinirea cruia a dus la nclcarea
limitei integritii. n cazul doi se efecuieaz napoierea tranzaciei pn la nceputul ei. Un
mecanism important determinat n SQL System R este mecanismul trigherilor. n contextul
System R acest mecanism era privit n mod principal ca surs de meninere automat a
integritii BD. La determinarea trigherului se spunea de condiia de control a utilizrii
trigherului(numele relaiei i tipul operaiei de manipulare cu datele). Condiia de utilizare a
trigherului(expresia logic, construit construit dup regulile apropiate de regulilepentru
limitele integritii primei clase) i funcia, cre trebuie s fie ndeplinit asupra bazei de date n
caz c condiiile aplicaiei sunt adevrate. Aa funcie putea fi exprimat cu ajurtorul

operatorului de sine stttor de manipulare cu date. n timpul execuiei funciei puteau s
nceap i alte trighere, .a.
Mecanismul de limitare a integritii i trigherelor n System R erau foarte puternice i
comune, dar realizarea lor eera grea(dup cum s-a mai spus, trigherele aa i nu au mai fost
realizate n System R). O greutate adugtoare n realizare a fost faptul c se permitea(n tot
cazul nu se interzicea de ctre limbaj) determinarea limitelor integritii i a trigherilor n limitele
aceleieai tranzacii, n care se ndeplinesc operatorii de manipulare cu datele. n cazul unei
realizrim mai ample, ar fi fost nevoie de un numr mai mare de aciuni adugtoare n timpul
execuiei tranzaciei. n afar de aceasta, n multe cazuri absena semanticii fixate a construciilor
corespunztoare a limbajului, aduc la o nelegere sinonim a ndeplinirii tranzaciei.

13.1.4. Configuraiile bazelor de date
n limbaj se permitea utilizarea relaiilor memorabile i a relaiilor dispuse a BD.
Varianta cea mai bun era utilizarea operatorilor de selecie pentru determinarea cionfiguraiei
sau afirii nfirii aparatului comun. Orice operator de selecie poate fi utilizat pentru
determinarea configuraiei.
n limbaj lipsesc oarecare limite n introducerea utilizrii configuraiilor: n orice operator
SQL n care se permite utilizarea numelui relaiei memorabile, se permite i utilizarea numelui
configuraiei a tabloului. n SQL System R nu se vorbete nimic despre metoda recomandabil
de realizare a accesului ctre tablouri, dar n orice metod efectul trebuie s fie n aa mod, ca
cnd s-ar fi realizat materializarea total a tabloului pn la execuia operatorului.
Un ir de probleme, cercetri i propuneri a nscut posibilitatea potenial de execuie a
operatorilor de manipulare cu datele asupra tablourilor. Este clar c aceast posibilitate este uor
de realizat pentru tablourile simple, dar n cazurile mult mai complicate, nu numai realizarea, dar
i semantica operaiilor devine netrivial. Apropo, n System R operatorii de manipulare cu
datele, se admiteau numai asupra tablourilor simple.

13.1.5. Determinarea strucurilor de comand
Introducerea n limbajul relaional, precum este SQL, operaiile de creare i tergere a
nivelului fizic, care menin efecuarea efectiv a adresrilor ctre BD, a aprut n SQL System R
ca o rezolvare pragmatic, care asigura posibilitatea tuturor tipurilor de lucru cu BD cu ajutorul
unui singur limbaj.
n SQL System R se vorbete despre dou tipuri de aa structuri: indexurile i
legturile(links).
Indexul, n nchipuirea lingvistic, abstract a sa este un fiier invertit, care asigur
accesul ctre cortejurile relaiei corespunztoare, pe baza sensului dat de una sau mai multe
coloane, care reprezint cheiea indexului. Operatorii limbajului permiteau de a crea i a distruge
indexii, dar n nici un caz nu permiteau de a arta necesitatea utilizrii indexului existent n
cazul execuiei operatorului de selecie, hotrrea despre aceasta se apela la realizare.
Cu ajutorul operatorului de determinare a indexului era posibil de a exprima dou
afirmaii adugtoare referitor la schema logic a relaiei i la structura fizic a pstrrii sale. La
determinarea indexului, utilizarea cuvntului cheie UNIQUE nseamn c cheiea acestui index
este cheiea posibil a relaiei corespunztoare. n fond aceasta demonstreaz existena
mecanismului adugtor de determinare a limitelor integritii relaiei. Unul din indexii relaiei
date putea fi determinat cu ajutorul cuvntului cheie CLUSTERING. Aceasta arat necesitatea
clasterizrii fizice n memoria extern a cortejurilor relaiei cu sensuri apropiate sau egale cu cele
ale indexului.
Operatorii de determinare a legturii, permiteau, n stilul modelului de reea a datelor,
organizarea n memoria extern a listelor cortejurilor relaiei date. Ca i n cazul indexilor,
operatorii permiteau de a crea i de a distruge aa liste, dar nu includeau posibilitatea de a arta

clar necesitatea utilizrii listelor externe la execuia operatorilor de manipulare cu datele i
dificultatea efecturii calculelor preului utilizrii lor la execuia operatorului de selecie, au
adus la aceea c mecanismul de legturi a disprut din limbaj, de acum n stadia trzie de
ndeplinire a proiectului System R. De atunci, acest mecanism, dup cum tim, nu a aprut nici
ntr-unul din variantele SQL.

13.1.6. Autorizarea accesului la relaie i cmpurile ei
O deosebire de baz a limbajului SQL, care a aprut n el de la bun nceput este
ndestularea proteciei accesului la date de ctre sursele limbajului. Ideiea principal a acestui
pas const n faptul c, pentru atrnarea fa de orice relaie a BD i fa de orice coloan a
relaiei se introduce un set definit de privilegii. Cu fiecare tranzacie se face indirect legtura cu
identificatorul utilizatorului, de la numele cruiea ea se ndeplinete(metodele de legtur i de
identificare a utilizatorilor nu se fixeaz n limbaj i se determin de realizare).
Dup crearea relaiei noi toate privilegiile legate de aceast relaie i de toate coloanele
sale, aparin doar utilizatorului creator al acestei relaii. n componena privilegiilor intr i
privilegia de a transmite toate sau o parte din privilegii altui utilizator, inclusiv i privelegia de a
transmite privilegii. n mod tehnic transmiterea privilegiilor are loc la ndeplinirea operatorilor
SQL GRANT. Exist i privilegia de a extrage o parte sau toate privilegiile de la un utilizator,
caruiea acestea i-au fost transmise mai devreme. Aceast privilegie de asemenea poate fi
transmis. n mod tehnic extragerea privilegiilor poate fi nfptuit la aplicarea operatorului SQL
REVOKE.
Controlul mputernicirii accesului la date are loc pe baza informaiei despre
mputernicirile existente n timpul compilrii operatorului SQL corespunztor. Asemntor cu
ceea ce am spus despre limitele integritii i trighere, n SQL System R lipseau careva limite n
legtur cu utilizarea operatorilor GRANT i REVOKE. Acest fapt aducea la dificulti tehnice
impuntoare n realizare, dar cte o dat i la o nelegere nesimilar a comportrii.
Un timp ndelungat pasul spre protecia datelor de la accesele nesancionate era nfptuit
practic fr critic, ns n legtur cu utilizarea rspndit a SGBD relaionale n adugrile
netradiionale, tot mai des apare critica. Dac, de exemplu, n sistema BD trebuie s se menin o
protecie a mai multor nivele de date, aa sistem de mputerniciri corespunztoare este foarte
greu, dar cte o date e i imposibil de a construi pe baza surselor SQL.

13.1.7. Punctele de salvare, memorare i napoierea tranzaciilor
n SQL System R au existat doi operatori speciali pentru implimentarea aa numitelor
puncte de salvare, memorare a tranzaciilor i de napoiere a tranzaciilor spre punctul de salvare
implimentat mai devreme. n literatura referitoare la System R cercetarea acestor posibiliti
practic nu se gsete, de unde rezult c ele nu au fost realizate.
Realizarea liniar a acestor posibiliti nu duce la careva dificultitehnice, dar i nu-i
chiar de folos, deoarece dup execuia parial a napoierii tranzaciei pentru prelungirea cu
succes a lucrului programului adugtor, ar fi fost nevoie i de restabilirea strii lui n punctul
corespunztor, ceea ce nicidecum nu se menine. Este clar c, n cazul unei analize mai
amnunite trebuie s fie legate mecanismele punctelor de salvare i control a integritii. De
exemplu ar fi natural ca n timpul execuiei operatorului ENFORCE INTEGRITY, dac careva
limite a integritii se ncalc, s-ar produce napoierea automat a tranzaciilor ctre punctul de
salvare cel mai apropiat, n care nclcarea integritii BD nu s-a depistat. Acest fapt ar fi ngrelat
realizarea, dar ar fi de folos.
Analog s-ar fi putut de utilizat mecanismul punctelor de salvare n cazul napoierii
automate a tranzaciilor din cauza apariiei impasurilor sincronizate.
S accentum nc dou proprieti principale a limbajului SQL System R, care n
modaliti diferite sunt prezente n toate variantele dezvoltate, postmergtoare ale limbajului.


13.1.8. SQL implantat
n SQL System R sunt prezeni operatori speciali, care menin implantarea operaiilor
SQL n limbajele tradiionale de programare(n System R un aa limbaj era PL/1).
Problema fundamental de implementare a lui SQL n limbaj de programare const n
faptul c SQL este un limbaj relaional, adic operatorii lui n cea mai mare parte lucreaz cu
mulimile, n timp ce n limbajul de programare, operaiile scalare sunt de baz. Hotrrea lui
SQL const n faptul c n limbaj se includ adugtor operatorii, care vor permite accesul pe
corteje a rezultatului adresrii la BD.
Pentru aceasta n limbaj se introduc sensul de cursor, cu care se leag operatorul de
selecie. Asupra unui cursor dat se poate efectua operatorul OPEN, care indic materializarea
relaiei rezultatul adresrii, operatorul FETCH, care permite alegerea sfritului de lucru cu
cursorul dat.
La realizarea unor programe adugtoare, cu SQL implantat, o elasticitate adugtoare
este dat de posibilitatea de parametrizare a operatorilor SQL cu sensul variabilelor programului
de conectare.

13.1.9. SQL dinamic
Pentru simplificarea cererii SQL interactiv sistemelor orientate n SQL System R au
fost inclui operatorii, care permit n timpul efecturii tranzaciei, compilarea i efectuarea
oricrui operator SQL.
Operatorul PREPARE induce compilarea dinamic a operatorului SQL, textul cruia se
conine n rndul simbolic schimbtor al programului de conectare.
Operatorul DESCRIBE slujete pentru primirea informaiei despre operatorul SQL dat,
pregtit mai nainte de operatorul PREPARE. Cu ajutorul acestui operator, putem afla mai nti,
este operatorul pregtit un operator de selecie i n al doilea rnd dac acesta e operator de
selecie, de primit informaia ntreag despre numrul i tipurile coloanelor relaiei rezultante.
Pentru ndeplinirea operatorului SQL pregtit mai devreme, care nu este un operator de
selecie, este operatorul EXECUTE. Pentru ndeplinirea operatorului de selecie pregtit dinamic,
se utilizeaz aparatul de cursoare cu careva deosebiri n ceea ce privete exercitarea adreselor
variabilelor programului de conectare, n care trebuie s fie incluse sensul coloanelor cortejului
rezultant actual.
Concluzionnd aceast scurt descriere a calitilor de baz a SQL System R, s
accentum, c nectnd la pregtirea tehnic nesatisfctoare, dup ideie limbajul coninea toate
mijloacele necesare, care permiteau utilizarea lui ca limbaj de baz a SGBD.

13.2. Limbajul SQL n realizri comerciale

13.2. Limbajul SQL n realizri comerciale
n timpul actual SQL e realizat practic n toate SGBD relaionale comerciale, toate
firmele i proclam corespunderea realizrilor sale la standartul SQL, i ntr-adevr dialectele
realizate sunt apropiate. Aceasta a avut loc nu deodat i nu uor.
Cele mai apropiate de System R erau dou sisteme ale firmei IBM SQL/DS i DB2.
dup cum se pare(demonstrri documentale la aceasta autorul nu are) ambele aceste sisteme
utilizau direct realizarea System R. De unde i apropierea limitat a dialectelor realizate SQL i
SQL System R. Din SQL SystemR au fost excluse doar acele pri, care nu erau ndeajuns
prelucrate( de exemplu punctele de salvare) sau reaalizarea crora ducea la dificulti foarte
mari(de exemplu limitele integritii i trigherele). Putem numi aceast cale spre realizarea
comercial a SQL micare de sus n jos.

O alt apropiere se utiliza n aa sisteme ca Oracle i Informix. Nectnd la deosebirile n
metodele de realizare a acestor sisteme, realizarea SQL avea loc de jos n sus. n primele
realizri SQL ieite pe pia, n aceste sisteme se utilizeaz numrul minimal i foarte limitat a
submulimilor SQL System R. n parte, n prima realizare cunoscut autorului a SQL SGBD
Oracle n operatorii de selecie nu se admitea utilizarea subntrebrilor implimentate.
Cu toate acestea, nectnd la aceste limite i la eficacitatea slab n primele stadii,
orientarea firmelor la meninerea diferitor platforme de aparate i de cointeresarea utilizatorilor
n trecerea la sistemele relaionale a permis firmelor s dobndeasc succes comercial spre
perfecionarea realizrilor sale. n versiunile actuale Oracle i Informix se menin dialecte SQL
destul de puternice, cu toate c realizarea cte o dat induce ndoieli.
O deosebire a majoritii SGBD comerciale actuale, care ngreuneaz analiza dialectelor
existente SQL, este aparena descrierii ntregi a limbajului. De obicei descrierea este mprtiat
pe diferite manuale i este amesticat cu descrierea limbajelor surs, specifice pentru sistema
dat, care nu au legtur cu SQL. Dar putem spune c, colecia de baz a operatorilor SQL,
incluznd operatorii de determinare a schemei BD, de selecie i de manipulare cu datele
autorizaiei accesului la date, meninerea implantrii SQL n limbajele de programare i
operatorii SQL dinamic, n realizrile comerciale s-a meninut i mai mult sau mai puin
corespunde standartului.

13.3. Standartizarea SQL

13.3. Standartizarea SQL
Lucrrile pentru standartizarea limbajului SQL au nceput practic concomitent cu apariia
primelor realizri comerciale ale lui. Primul din volumul de documente, ce aparineau autorului,
dateaz cu luna octombrie a anului 1985 i este de acuma un alt proiect al standartului
ANSI/ISO.
Este clar c n calitate de standart se putea utiliza SQL System R. n primul rnd aceast
variant a limbajului nu era prelucrat tehnic n momentul cuvenit. n al doilea rnd, aceasta ar fi
fost foarte greu de realizat(cine tie cum s-ar fi aranjat istoria, dac ar fii fost realizate complet
toate ideile System R). Din alt punct de vedere, primele realizri comerciale se deosebeau att de
mult, c nici unul din dialectele realizate nu aveau anse de a fi primite n calitate de standart.
Analiza documentelor accesibile arat, c procesul decurgea foarte dificil, utiliznd nu
numai rezultatele tiinifice. n rezultat standartul Internaional SQL, primit n 1989 n marea
majoritate a prilor sale, are un caracter comun i permite o descifrare forte larg. n acest
standart lipsesc complet aa compartimente principale, ca manipularea cu schema BD i SQL
dinamic. Multe din aspectele principale ale limbajului, n corelaie cu standartul se determin n
realizare.
Se preapoate, c cele mai importante scopuri atinse de limbajul SQL sunt standartizarea
clar a sintaxei i semnaticii a operatorilor de selecie i mai includ posibilitile de determinare
a cheilor primare i secundare a relaiilor i aa numitele limitele de control a integritii, care
reprezint din sine submulimea limitelor integritii SQL System R de clasa nti. Sursele de
determinare a cheilor exterioare permit formularea uoar a aanumitor necesiti a integritii
BD dup legturi. Aceast necesitate rspndit poate fi formulat i pe baza mecanismului
general a limitelor integritii SQL System R, dar formularea pe baza sensului cheii externe este
mai simpl i mai neleas. Vznd necompletarea standartului SQL, pe fonul ncheierii lucrului
aupra prelucrrii acestui standart, specialitii diferitor firme au pornit lucrul cu standartul SQL2.
acest lucru de asemenea s-a prelungit civa ani, au fost elaborate o mulime de proiecte de
standarte, pn cnd n sfrit, n martie 1992 nu a fost elaborat proiectul final a standartului.
Acest standart este cu mult mai amplu i cuprinde practic toate aspectele necesare pentru
realizare: manipularea cu schema BD, dirijarea cu tranzaciile(din nou au aprut punctele de

salvare, memorare) i cu sesiile(sesia - este o succesiune a tranzaciilor, n limitele crora se
pstreaz relaia temporal), conexiunea la BD, SQL dinamic. n sfrit sunt standartizate
rfelaiile-registre a BD, ceea ce nu-i legat neaprat de limbaj, dar foarte mult acioneaz asupra
realizrii.
Uimete faptul lipsei n standart a surselor de dirijare cu indexii. Desigur aceste surse, de
obicei, se afl departe de operaiile de baz SQL, dar autorului nu-i este cunoscut nici o
realizare n care ei ar lipsi.
n sfrit, odat cu finisarea lucrului saupra standartului SQL2 a luat natere prelucrarea
standartului SQL3. se presupune c SQL3 va conine mecanismul trigherilor i posibilitatea
utilizrii tipurilor abstracte de date. Sensul de standart se planific doar n anul 1995. s sperm
c macr de aceast dat va fi posibil de urmrit prelucrarea lui.
Concluzionnd aceast scurt excursie prin istoria standartizrii SQL, s observ, c n
cele mai multe cazuri(nu n toate) procesul standartizrii se limiteaz la o prelucrare tehnic
atent a ideilor SQL System R, ceea ce nc o dat accentuieaz unicitatea acestui proiect(au
trecut 12 ani de la finisarea lui!).

Lecia 14. Limbajul standart a bazelor de date SQL

Lecia 14. Limbajul standart a bazelor de date SQL
n aceast lecie vom analiza pe scurt proprietile de baz a limbajului Lecia 14.
Limbajul standart a bazelor de date SQL 1989.

14.1. Tipuri de date

14.1. Tipuri de date
n limbajul 14.1. Tipuri de date/89 se menin urmtoarele tipuri de date:
CHARACTER, NUMERIC, DECIMAL, INTEGER, SMALLINT, FLOAT, DOUBLE,
PRECISION. Aceste tipuri de date se clasific pe tipurile expresiilor simbolurilor, numerelor
ntregi i numerelor reale. Primei clase i se atribuie CHARACTER(length), unde length
returneaz lungimea cuvntului tipului dat. S atragem atenia, c n 14.1. Tipuri de date/89
lipsete tipul cuvintelor de mrime variabil. Cu toate c n multe realizri ele se admit.
Cuvintele literare ale simbolurilor se reprezint n form de ir de simboluri(de exemplu
exemple).
Reprezentri ale clasei a doua de tipuri sunt NUMERIC, DECIMAL(DEC),
INTEGER(INT) I SMALLINT. Specificatorul tipului NUMERIC are aspectul
NUMERIC[(PRECISION[,SCALE])]. Se specific numerele ntregi, reprezentate cu precizia
precision i cu scara scale. Aici i pe viitor, dac este scpat scara, atunci ea se poate socoti ca
fiind egal cu 0, iar dac este scpat precizia. Atunci sensul ei se determin n realizare.
Specificatorul tipului DECIMAL(sau DEC) are aspectul NUMERIC[(precision[,scale])].
Se specific numerele ntregi, reprezentate cu scara scale i precizia mai mare sau egal cu
valoarea precision.
Integer specific tipul de date a numerelor ntregi cu scara 0 i cu o precizie
determinat de realizare. SMALLINT specific tipul de date a numerelor ntrgi cu scara 0 i cu
precizia determinat n realizare, nu mai mare ca precizia numerelor tipului INTEGER.
Sensurile literare a numerelor ntregi n caz general se prezint sub forma
[+]<intreg_fara_semn>[.<intreg_fara_semn>]. n sfrit, la clasa tipurilor de date a numerelor
reale se refer tipurile FLOAT, REAL, i DOUBLE PRECISION. Specificatorul tipului FLOAT
are aspectul FLOAT[(precision)]. Sunt specifice numerele reale cu precizie binar mai mare sau
egal cu valoarea precision.

REAL specific tipul de date a numerelor reale i n caz general se reprezint sub forma
<structura_literara_a_numarului>&<intreg_cu_semn>. S atragem atenia c cu toate c odat
cu utilizarea limbajului SQL putem determina schema BD, care conine datele oricrui tip din
cele numite, posibilitatea de a le utiliza n sistemele adugtoare depinde de limbajul de
programare utilizat. Gama ntreag a tipurilor de date poate fi folosit dac se programeaz n
PL/1. de aceea n unele realizri SQL tipurile de date cu scar i precizie n genere nu se menin.
Cu toate c regulile de implimentare a SQL n limbajul C nu se determin n SQL/89, n
majoritatea relizrilor, ce susin aa implimentare, are loc urmtoarea corelaie ntre tipurile de
date SQL i tipurile de date C: CHARACTER corespunde caracterelor C; INTEGER corespunde
long; SMALLINT corespunde short; REAL corespunde float, DOUBLE PRECISION
corespunde lui double(anume aa corelaie este admis n SQL/92).
S atenionm c, n marea majoritate a realizrilor SQL, se menin unele tipuri de date
adugtoare, ca de exemplu, DATE, TIME, INTERVAL, MONEY. Unele din aceste tipuri se
specific n standartul SQL/92, dar n realizrile actuale realizrile sintactice i semantice se pot
deosebi.

14.2. Surse de determinare a schemei

14.2. Surse de determinare a schemei
Sursele de determinare a schemei BD n stanartul SQL/89 se refer la prile mai slabe
ale standartului i care permit o interpretare diferit. Mai mult ca att, nu ne este cunoscut nici o
realizare , n care s-ar menine fix aa set de surse de determinare a schemei.
De aceea pentru obinerea mobilitatea sistemeiadugtoare n o clas destul de larg de
realizare SQL/89, trebuie de localizat clar componentele de determinare a schemei BD. Cred c
ar fi mai bine de concentrat tot lucrul cu schema BD ntr-un singur modul i de avut n vedere c
reconstruirea acestui modul.
S atragem atenia, c n SQL/89 n genere lipsesc carevasurse de schimbare a schemei
BD: nu-I posibilitatea de a nltura schema tabelului; de aduga n schema tabelului o coloan
nou, .a. n toate realizrile aa surse se menin, dar ele pot s difere i dup sintactic i dup
semantic.
Nectnd la lipsa oricror sperane c vom reui s ntlnim o realizare, ce ar susine
limbajul de determinare a schemelor SQL/89, noi, pe scurt, vom descrie acest limbaj(fr
mijloace sintactice), pentru a aprecia la nivelul cuvenit posibilitile SQL/89 i de a primi mcar
careva surse de comparaie a diferitor realizri.

14.2.1. Operatorul de determinare a schemei
n legtur, corespunderii cu regulile SQL/89 fiecare tabel a BD date are un nume
simplu i calificat. n calitate de calificator a numelui este identificatorul mputernicirilor
tabelului, care de obicei, n realizare coincide cu numele a careva utilizator i numele calific a
tabelului are forma:
<identificatorul_imputrnicirilor>.<nume_simplu>.
Paii ctre determinarea schemei n SQL/89 constau n faptul c toate tabelele cu unl i
acelai identificator de mputernicire se creeaz(determin) pe calea ndeplinirii unui operator
dedeterminare a schemei.
Cu toate acestea, n standart nu se determin posibilitatea de ndeplinire a operatorului de
determinare a schemei: trebuie oare el s fie ndeplinit numai n refim interactiv sau poate fi
mplementat n program, scris n limbajul tradiional de programare.
n operatorul de determinare a schemei, se conine identificatorul mputernicirilor i lista
elementelor schemei, unde fiecare din elemente poate fi determinantul tabelului, determinantul
afirii(view) sau determinantul privelegiilor. Fiecare din acetideterminani se reprezint de un

operator aparte SQL/89, dar toi ei, cum s-a mai spus, trebuie s fie implementai n operatorul
determinrii schemei. Pentru aceti operatori, vom scrie sintactica, cci aceasta va permite
descrierea deosebirilor lor.

14.2.2. Determinarea tabelului
Operatorul de determinare a tabelului are sintactica urmtoare:
<table definition>::=
CREATE TABLE<table_name>(<table_element>)
[{,<table_element>}]
<table_element>::=
<column_definition>
|<table_constraint_definition>.
n afar de numele tabelului, n operator se specific lista elementelor tabelului, unde
fiecare din elemente slujete sau pentru determinarea coloanei, sau pentru determinarea limitelor
integritii a tabelului determinat. Este nevoie de prezentat macr a unei determinri a coloanei.
Operatorul CREATE TABLE determin, aa numitul tabel de baz, adic depozitul real de date.
Pentru determinarea coloanelor tabelului i a limitelor integritii se utilizeaz operatori speciali,
care trebuie inclui n operatorul de determinare a tabelului.

14.2.3. Determinarea coloanei
Operatorul de determinare a coloanei se descrie prin regula sintactic urmtoare:
<column definition>::=
<column name><date type>
[<default clause>][<column constraint>]
<default clause>::=
DEFAULT {<literal>|USER|NULL}
<column constraint>::=
NOT NULL[<unique specification>]
|<references specification>
|CHECK (<search condition.>).
Dup cum se vede, n afar de partea principal, n care se determin numele coloanei i
tipul ei de date, determinarea coloanei poate conine i dou disprituri secundare, de care ne
putem lipsi: dispritura coloanei propriuzis i despritura limitelor integritii coloanelor. n
despritura nsemntii propriuzis se arat nsemntatea, care trebuie s fie inclus n rndul,
care se nscrie n tabelul dat, dac nseamntate acestei coloane nu se d. nsemntatea
propriuzis poate fi dat sub form de constant literar cu tipul, care corespunde tipului
coloanei date; pe calea definirii cuvntului cheie USER, cruiea, n timpul execuiei operatorului
de introducere a cuvntului, i corespunde cuvntul simbolic, ce conine numele utilizatorului
curent(n acest caz coloana trebuie s aib tipul cuvintelor simbolice); sau pe calea definirii
cuvntului cheie NULL, care indic c nsemntatea propriuzis este o nsemntate
nedeterminat. Dac nsemntatea coloanei propriuzis nu-i specificat, i n despritura
limitelor integritii coloanei este artat NOT NULL, atunci nceracrea de a introduce n tabel
cuvntul cu nsemntatea nespecificat a coloanei date va duce la greeal. Definirea n
despritura de limitare a integritii NOT NULL duce la crearea unei limite a integritii de
ncercare pentru tot tabelul(uite subdiviziunea urmtoare) CHECK (C IS NOT NULL) (unde C
numele coloanei date). Dac limita NOT NULL nu-i dat, i despritura propriuzislipsete,
atunci are loc crearea despriturii propriuzise DEFAULT NULL. Dac este dat specificarea
unicalitii, atunci are loc crearea specificaiei corespunztoare a unicalitii pentru tabel.

Dac n despritura limitelor integritii este dat limita dup legtur a coloanei date
(<reference specification>), atunci are loc crearea determinrii limitelor integritii
corespunztoare dup legturi pentru tabel:
FOREIGN KEY(C) <reference specification>
n sfrit, dac este dat limita de control a coloanei, atunci condiiile de cutare a acestei
limite trebuie s se bazeze doar pe aceast coloan, i de asemenea are loc crearea
corespunztoare a limitei de control a integritii tabelului.

14.2.4. Determinarea limitelor integritii tabelului
Limitele integritii tabelului posed sintactica urmtoare:
<table constraint definition>::=
|<unique constraint definition>
|<referential constraint definition>
|<check constraint definition>
<unique constraint definition>::=
<unique specification>(<unique column list>)
<unique specification>::=UNIQUE | PRIMARY KEY
<unique column list>::=<column name>[{, <column name>}]
<referential constraint definition>::=
FOREIGN KEY(<referencing column >)<references specification>
<references specification>::=
REFERENCES<referenced table in column>
<referencing columns>::=
<reference column list>
<referenced table in columns>::=
<table name>[(<reference column list>}]
<reference column list>::=<column name>[{,<column name>}]
<check constraint definition>::=CHECK(<search condition>)
Pentru un singur tabel pot fi date cteva limite a integritii, inclusiv i cele ce se creeaz
de ctre limitele integritii coloanelor.
Standartul SQL/89 adopt, c limitele tabelului practic se controleaz la ndeplinirea
fiecrui operator SQL.
Atenie: posedarea setului corect selectat de limite a BD este foarte important pentru
funcionarea temeinic a sistemului informaional aplicat. Cu toate acestea n unele SGBD
limitele integritii practic nu se menin. De aceea la proiectarea sistemului aplicativ trebuie de
luat decizia ce este mai principal: s ne bazm pe susinerea limitelor integritii, dar s ne
limitm setul posibilelor SGBD, sau s ne dezicem de utilizarea lor la nivelul SQL, pstrnd
posibilitatea utilizrii nu a celor mai noi SGBD. n continuare T arat tabelul, pentru care se
determin limitele integritii.
Limita unicitii
Fiecare nume a coloanei, din lista unicitilor trebuie s numeasc coloana T i nu trebuie
s fie inclus n aceast list mai mult de o singur dat. La determinarea coloanei, ce intr n lista
unicalitilor trebuie s fie dat pe limita coloanei NO NULL. Printre limitele unicalitii T nu
trebuie s fie mai mult de o singur determinare a cheii primare(limita unicalitii cuvntului
cheie PRIMARY KEY).
Lucrul limitei unicalitii const n faptul c, n tabelul T nu se admite apariia a dou sau
mai multe rnduri, sensurile coloanelor unicalitii crora coincid.
Limita dup legtur

Limita dup legtur de la setul de coloane date CT a tabelului T pe setul de coloane CT1
dat de un tabel oarecare la momentul dat T1 determin condiia asupra coninutului ambelor
acestor tabele, fr de care legturile le putem considera corecte.
Dac lista coloanelor CT1 este specificat clar n determinarea limitei dup legturi,
atunci trebuie ca aceast list s intre ntr-o oarecare determinare a unicalitii tabelului T1. dac
lista CT1 nu se specific n determinarea limitei dup legturi a tabelului T, atunci este nevoie ca
n determinarea tabelului T1 s fie prezent determinarea cheii primare i lista CT1 se presupune
c coincide cu lista numelor coloanelor din determinarea cheii primare a tablului T1.
Numele coloanelor listelor CT i CT1 trebuie s fie luate de coloanele tabelelor T i T1
corespunztor i nu trebuie s apar n liste mai mult de o singur dat. Listele coloanelor CT i
CT1 trebuie s conin un numr egal de elemente i coloana tabelului T, identificat de
elementul i a listei CT trebuie s fie de acelai tip ca i coloana tabelului T1, identificat de
elementul i a listei CT1.
Dup determinare, tabelele T i T1 corespund limitei date dup legturi, dac pentru
fiecare rnd S a tabelului T aa c toate nsemntile coloanelor S identificate de lista CT, nu
sunt nedeterminate, exist rndul S1 a tabelului T1, aa c, nsemntatea coloanelor S1,
identificate de lista CT1, sunt egale dup poziia nsemntilor coloanelor S, identificate de lista
CT. Mai clar acest lucru poate fi formulat n felul urmtor: limita dup legturi se satisface dac
pentru fiecare legtur corect exist un obiect, la care ea s-ar trimite. n terminologia deprins
de programatori, limita dup legturi nu permite crearea legturilor atrnate, care nu conduc
nspre nici un obiect.
Limita de control
Limita de control specific condiia, care trebuie s fie satisfcut de fiecare rnd n parte
a tabelului T. Aceast condiie nu trebuie s conin subadresri, specificaii a funciilor agregate
dar i a legturilor spre parametrii sau variabile externe. n ea pot intra doar numele coloanelor
tabelului dat i constantele literare.
Tabelul satisface limita de control a integritii n acel caz i numai n acela, cnd calculul
condiiei pentru nfiecare rnd a tabelului ne d TRUE.
Atenie: n unele realizri se permite mecanisme mai lrgite a limitelor dup legturi i a
limitelor de control. Trebuie s fim ateni, dac nu dorim s ieim din limitele posibilitilor
standartului.

14.2.5. Determinarea configuraiilor
Mecanismul configuraiilor(view) este o surs puternic a limbajului SQL, ce permite
ascunderea structurii real a BD de careva utilizatori, pe baza determinrii configuraiei BD, care
este o oarecare adresare ctre BD memorabil cu coloane enumrate, dar pentru utilizator nu se
deosebete cu nimic de tabelul de baz a BD(innd seama de limitele tehnice). Orice realizare
trebuie s garnteze, c starea tabelului dat coincide ntocmai cu starea tabelelor de baz, pe baza
crora este determinat configuraia. De obicei determinarea tabelului nchipuit (materializarea
adresrii corespunztoare) are loc de fiecare dat la utilizarea configuraiei.
n standartul SQL/89 operatorul de determinare a configuraiei are sintaxa:
<view definition>::=
CREATE VIEW <table name>[(<view column list>)]
AS <query specification>[WITH CHECK OPTION]
<view column list>::=<column name>[{,<column name>}...]
Tebelul V determinabil este schimbtor(adic n corespundere cu V putem utiliza
operatorii DELETE i UPDATE) n acel caz i doar n acela, dac se ndeplinesc urmtoarele
condiii pentru specificarea adresrii: n lista de selecie nu se indic cuvntul cheie DISTINCT;
fiecare expresie afirmativ n lista de selecie este o specificaie a coloanei i specificaia unei
coloane nu apare mai mult de o singur dat; n despritura FROM este artat doar un singur

tabel care este sau tabel de baz sau tabelul nchipuit schimbtor; n condiia de selecie a
despriturii WHERE nu se utilizeaz subadresri; n expresia tabelar lipsesc despriturile
GROUP BY SO HAVING.
Atenie: Aceste limite sunt foarte puternice. n realizri ele pot fi slbite. Dar dac s
aspirm la mobilitate, n-ar fi de dorit s utilizai posibilitile lrgite.
Dac n lista de selecie n specificarea adresrii este mcar o singur expresie afirmativ,
compus nu dintr-o singur specificaie a coloanei, sau dac un nume a coloanei face parte din
lista de selecie mai mult dect o singur dat, determinarea configuraiei trebuie s conin lista
numelor coloanelor tabelului nchipuit. Mai simplu trebuie de enumerat coloanele tabelului
nchipuit, dac aceste nume nu sunt motenite de la coloanele tabelelor despriturii FROM de
specificare a adresrii.
Cererea WITH CECK OPTION n determinarea configuraiei are sens numai n cazul
determinrii tabelului nchipuit schimbtor, care se determin de specificarea adresrii, care
conine despritura WHERE. n cazul posedrii acestei cereri nu se admit schimbri a tabelului
nchipuit ce duc la apariia n tabelele de baz a rndurilor, ce nu se vd n tabelul nchipuit, adic
aa rnduri, care nu ndestuleaz condiia de cutare a despriturii WHERE de specificare a
adresrii. Dac WITH CECK OPTION n determinarea configuraiei lipsete, aa control nu se
nfptuiete.

14.2.6. Determinarea privelegiilor
n coresponden cu ideologia limbajului SQL controlul drepturilor de acces a
utilizatorului dat ctre tabele BD are loc pe baza mecanismului de privelegii. De fapt, acest
mecanism const din aceea, c pentru ndeplinirea oricrui lucru asupra tabelului utilizatorul
trebuie s posede privelegiile corespunztoare(real tot lucrul posibil este descris de setul fixat
standart de privelegii). Utilizatorul, ce a creat tabelul, automat devine posesorul a tuturor
privilegiilor posibile la ndeplinirea operaiilor asupra acestui tabel.
n componena acestor privelegii intr i privelegiul de transmitere a tuturor sau a crorva
privilegii n legtur cu tabelul dat ctre ali utilizatori, inclusiv privelegiul de transmitere a
privelegiilor. Uneori are loc i apariia inversei de luare a privelegiilor de la utilizator, care le-a
primit mai nainte.
n SQL/89 se determin schema simplificat a mecanismului privilegiilor.
n primul rnd, mprirea privelegiilor este posibil doar n cazul dewterminrii
tabelului. n al doilea rnd, utilizatorul, ce a primit careva privilegii de la ali utilizatori, le poate
transmite mai departe doar n cazul determinrii schemei.
Determinarea privilegiilor are loc dup sintactica urmtoare:
<privilege definition>::=
GRANT <priveleges> ON <table name> TO <grantees>
[{,<grantee>}][WITH GRANT OPTION]
<priveleges>::=
ALL PRIVELEGES
|<action>[{,<action>}]
<action>::=SELECT|INSERT|DELETE
|UPDATE [(<grant column list>)]
|REFERENCES [(<grant column list>)]
<grant column list>::=<column name>[{,<column name>}]
<grantee>::=PUBLIC|<autorization identifier>
Din aceast sintax nelegem sensul mecanismului de determinare a privelegiilor n
SQL/89. s atragem atenia doar la aceea c avem nevoie de posesia privelegiilor.
PREFERENCES n legtur cu coloanele selectate din tabelul T1 pentru a avea posibilitatea, la

determinarea tabelului T, s determinm limita dup legturi dintre acest tabel i tabelul existent
la momentul dat T1.
Cu toate c n caz general n toate SQL-SGBD orientate se menine mecanismul de
protecie a accesului pe baza privelegiilor, realizrile se pot de obicei deosebi prin detalii. Pentru
a tinde spre crearea unui sistem mobil adugtor aplicativ, atunci acest lucru analizat mai sus
trebuie localizat.

Lecia 15. Limbajul SQL. Surse de manipulare cu datele

Lecia 15. Limbajul SQL. Surse de manipulare cu datele
15.1. Structura adresrilor
Pentru a vorbi mai mult sau mai puin despre structura adresrilor n standartul Lecia 15.
Limbajul SQL. Surse de manipulare cu datele/89 trebuie s ncepem cu o mulime de reguli
sintactice:
<cursor specifiction>::=
<query expresion>[<order by clause>]
<query expresion>::=<query term>
|<query expresion> UNION [ALL]<query term>
<query term>::=<query specification>
|(<query expression>)
<query specification>::=
(SELECT [ALL|DISTINCT]<select list><table expresion>)
<select statement>::=
SELECDT [ALL|DISTINCT]<select list>
INTO <select target list> <table expresion>
<subquery>::=
(SELECT [ALL|DISTINCT]<result specification>
<table expression>
<table expression>::=
<from clause>
[<where clause>]
[<group by clause>]
[<hawing clause>]
Limbajul permite trei tipuri de construcii sintactice, care ncep cu cuvntul cheie
SELECT: specificaia cursorului(cursor specification), operatorul seleciei(select statement) i
subadresarea (sub query). Cea mai de baz este construcia sintactic expresie tabelar(table
expreion). Semantica expresiei tabelare const n faptul c pe baza utilizrii consecutive a
dispriturilor from, where, group, by so hawing, din tabelele date n from se construiete o
tabel rezultant, n care ordinea consecutivitii rndurilor nu este determinat i printre rnduri
se pot gsi dublicate(adic, n caz general, tabelul-rezultant al expresiei tabelare este o mulime
de rnduri). ntr-adevr anume structura expresiei tabelare n cea mai mare parte caracterizeaz
limbajul SQL/89. n continuare vom vedea structura i sensul dispriturilor expresiei tabelarte,
dar mai nainte vom analiza cele trei tipuri de construcii ce include expresiile tabelare.

15.1.1. Specificarea cursorului
Cursor o determinare a limbajului SQL, ce permite cu ajutorul setului de operatori
speciali de a primi accesul pe rnduri la rezultatul adresrii ctre BD. Ctre expresiile tabelare, ce
particip la specificarea cursorului, nu se aplic nici o limit. Dup cum se vede din mulimea de
reguli sintactice, la determinarea specificaiei cursorului se utilizeaz trei construcii
adugtoare: specificarea adresrii, expresia adresrilor i despritura ORDER BY.

Specificarea adresrii
n specificarea adresrii se d lista de selecie(lista expresiilor afirmative asupra
sensurilor coloanelor rezultatului expresiei tabelare i a constantelor). n rezultatul utilizrii
listei de selecie la rezultatul expresiei tabelare are loc construirea noului tabel, se conine acelai
numr de rnduri, dar n general alt numr de coloane, ce conin rezultatele calculelor expresiilor
afirmative corespunztoare din lista de selecie. n afar de aceasta, n specificarea adresprii se
pot conine cuvinte cheie ca: ALL sau DISTINCT. La posesia cuvntului cheie DISTINCT din
tabel, a expresiei tabelare primite utiliznd n rezultat lista de selecie, se terg rndurile dublicate;
la selectarea ALL (sau pur i simplu la lipsa lui DISTINCT) nu are loc tergerea rndurilor
dublicate.
Expresia adresrilor
Expresia adresrilor este o expresie care se construiete dup regulile sintactice date pe
baza specificaiei adresrilor. Unica operaie care e permis de a fi utilizat n expresiile
adresrilor, este operaia UNION(unirea tabelelor) cu posibilitatea de felul urmtor UNION
ALL. Ctre tabelele-operanilor expresiilor adresrilor se aplic acea cerin, c toate ele trebuie
s posede unul i acelai numr de coloane i coloanele corespunztoare a tuturor operatorilor
trebuie s fie de unul i acelai tip. Expresia adresrilor se calculeaz de la stnga spre dreapta,
innd seama de ghilimele. La execuia operaiei UNION are loc unirea obinuit a operatorilor,
adic n tabelul rezultant se terg dublicatele. La neplinirea operaiei UNION ALL se formeaz
tabelul rezultant, n care se pot conine rnduri dublicate.
Dispritura ORDER BY
n sfrit despritura ORDER BY permite crearea ordinii dorite de privire a rezulltatului
expresiei adresrilor. Sintactica ORDER BY este:
<order by clause>::=
ORDER BY <sort specifiction
[{,<sort specification>}]
<sort specification>::=
{unsigned integer>|<volum specification>}
[ASC|DESC]
Dup cum vedem din aceste reguli sintactice, practic se d lista coloanelor rezultatului
expresiei adresrilor i pentru fiecare coloan se arat ordinea rndurilor rezultatului n
dependen de nsemntatea acestei coloane(ASC dup cretere i DESC n descretere).
Coloanele pot fi date prin numele sale n cazul cnd: expresia adresrilor nu conine operaiile
UNION i UNION ALL; n lista de selecie a specificaiei adresrii acestei coloane i corespunde
o expresie afirmativ, compus doar din numele coloanei. n toate celelalte cazuri, n
despritura ORDER BY trebuie s fie dat numrul de ordine a coloanei n tabelul rezultant al
expresiei adresrii.

15.1.2. Operatorul de selecie
Operatorul de selecie este un operator aparte a limbajului SQL/89, ce permite de a
primi rezultatul adresrii n programul aplicat fr activarea cursorului. De aceea operatorul de
selecie are sintactica ce difer de sintactica de specificare a cursorului i la execuia lui apar
limitri a rezultatului expresiei tabelare. De fapt i una i alta este dictat de specificul
operatorului de selecie ca operator unar a SQL: la execuia lui rezultatul strebuie s fie inclus n
variabilele programului aplicativ. De aceea n operator apare dispritura IN TO, ce conine lista
variabilelor a programului aplicativ i apare acea limit c tabelul rzultant trebuie s conin nu
mai mult de un rnd. La rndul su rezultatul expresiei tabelare de baz trebuie s conin nu mai
mult de un rnd, dac operatorul de selecie nu conine specificaia DISTINCT i tabelul, primit
n urma apelrii la lista de selecie ctre rezultatul expresiei tabelare, nu trebuie s conin mai
mult de un rnd care nu coincide, dac specificaia DISTINCT este dat.

Atenie: n dialectul SQL SGBD Oracle se menine varianta lrgit a operatorului
seleciei, rezultatul cruiea nu e neaprat tabelul dintr-un singur rnd. Aa lrgire nu se susine
nici n SQL/89, nici n SQL/92.

15.1.3. Subadresarea
n sfrit, ultima construcie SQL/89, care poate conine expresii tabelare este
subadresarea, pedic adresarea, care poate fi inclus n predicatul condiiei de seleciei a
operatorului SQL. Tabelul rezultant trebuie s conin fix o singur coloan. De aceea n regulile
de sintax, ce determin subadresarea, n loc de lista de selecie este artat expresia expresia,
ce determin valoarea, adic expresia afirmativ. S atenionm, c deoarece subordonarea
ntotdeauna este inclus n orice alt operator SQL, atunci n calitate de constante n expresia
afirmativ de selecie i n expresia logic a despriturilor WHERE i HAVING. Se permite
utilizarea coloanelor a rndurilor cresctoare a tabelelor, ce particip n adresrile mai mari ca
nivelul exterior. Mai amnunit despre aceasta vom vorbi la descrierea semnaticii expresiilor
tabelar.

15.2. Expresia tabelar

15.2. Expresia tabelar
Standartul SQL/89 recomand s primim calculul expresiei tabelareca o utilizare
consecutiv a despriturilor FROM, WHERE, GROUP i HAVING pentru tabelele date n lista
FROM. Despritura FROM are sintaxa urmtoare:
<from clause>::=
FROM <table reference>
({,<table reference>})
<table reference>::=
<table name>[<collection name>]

15.2.1. Despritura FROM
Ca rezultat a ndeplinirii despriturii FROM este derivarea extins a tebelelor, date de
lista tabelelor despririi FROM. Derivarea extins este de aceea c, n calitate de rezultat i
operani se admit mulimile. n standart se determin n felul urmtor: derivarea extins este R,
unde R este o multimulime a tuturor rndurilor r aa, c r este concatenarea tuturor rndurilor
dint toate tabelele identificate n aa ordine, n care ele au fost identificateordinul lui R este
reprezint derivata ordinelor tabelelor identificate. Numrul de ordine a coloanei n R este n+S,
unde n este numrul coloanei create n tabelul numerat T, iar S este suma puterulor tuturor
tabelelor, alturi de numele tabelului putem specifica nc un nume corelation name. De fapt
aceasta este un sinonim a numelui tabelului care poate fi folosit n alte desprituri a expresiei
tabelare pentru legturile cu rndurile anume a acestei intrri a tabelului.
Dac expresia tabelar conine doar despritura FROM(aceasta-i unica i neaprata
despritur a tabelului), atunci rezultatul expresiei tabelare coincide cu rezultatul despriturii
FROM.

15.2.2. Depritura WHERE
Dac n expresia tabelareste prezent despritura WHERE, atunci urmtoarea se va
calcula anume ea. Sintaxa acestei desprituri este:
<where clause>::=WHERE <search condition>
<search condition>::=
<boolean term>
(<search condition>OR<boolean term>

<boolean term>::=
<boolean factor>
(<boolean term>AND<boolean factor>
<boolean factor>::=[NOT]<boolean primary>
<boolean primary>::=<predicate>|(<search condition>)
Calculul despriturii WHERE are loc dup regulile: fie R rezultatul despririi FROM.
Atunci condiiile cutrii se admit pentru toate rndurile R i ca rezultat a dispriturii WHERE
este tabelul format din acele rnduri R, pentru care rezultatul calculelor condiiilor de cutare
este true. Dac condiiile de selecie includ subadresri, atunci fiecare subadresare se calculeaz
pentru fiecare cortej a tabelului R(n standart se utilizeaz termenul de effectively n sensul, c
rezultatul trebuie s fie aa, ca i cum fiecare subadresare ntr-adevr s-ar fi calculat din nou
pentru fiecare cortej R). S atenionm c, deoarece SQL/89 admite prezena n baza de date a
expresiilor nedeterminate, atunci calculul condiiilor de cutare nu are loc n logica boolean ci
n logica trisemnificativ cu valori true, false i unikown(nedeterminare). Operaiile booleene
AND, OR i NOT opereaz n logica trisemnificativ aa:
true AND unikown=unikown
unikown AND true=unikown
unikown AND unikown=unikown
true OR unikown=true
unikown Or true=true
unikown OR unikown=unikown
NOT unikown=unikown
Printre predicatele condiiilor de cutare n corespundere cu SQL/89 se pot gsi
urmtoarele predicate: predicatul comparaiei, predicatul between, predicatul in, predicatul like,
predicatul null, predicatul cuantificrii, predicatul exists. S atenionm c n toate realizrile
SQL asupra eficacitii implimentrii adresrii influeneaz mult prezena, n condiia de cutare,
a predicatelor simple de comparaie( predicate ce reprezint comparaia coloanei tabelului n
raport cu o constant, prezena acestor predcicate d posibilitate SGBD de a utiliza indexi la
ndeplinirea adresrii, adic de a evita parcurgerea ntregului tabel. n principiu, limbajul SQL le
permite utilizatorilor de a nu-i face griji n privina setului concret de predicate n condiia de
selecie(ele s fie doar sintactic i semantic corecte), la utilizarea real a limbajului SQL a
SGBD orientate, aa detalii tehnice trebuie de luat n vedere.
Predicatele de comparaie
Sintaxa predicatului de comparaie se determin dup regulile:
<comparison predicate>::=
<value expresion><comp op>
{<value expresion>|<subquery>}
<comp op>::=
=|<>|<|>|<=|>=
Prin <> se indic operaia de neegalitate. Expresiile neafirmative a prilor stngi i
drepte a predicatului de comparaie se construiesc dup regulile generale de construire a
expresiilor afirmative i pot include n caz general numele coloanelor tabelelor din despritura
FROM i constante. Tipurile de date a expresiilor afirmative trebuie s fie comparabile(de
exemplu dac tipul coloanei tabelului A este un vector de caractere, atunci predicatul a=5 nu
se admite).
Dac operatorul din dreapta operaiei de comparaie e dat de subadresare, atunci limita
adugtoare este aceea, c puterea rezultatului subadresrii nu trebuie s fie mai mare ca
unitatea. Dac macr unul din operatorii operaiei de comparaie are sens nedeterminat sau sau
dac operatorul din dreapta este o subadresare cu rezultat pustiu, atunci rezulatul predicatului
de coomparaie este egal cu unikown.

Rezultatul expresiei afirmative nu este determinat, dac n calculul lui particip macr o
valoare nedeterminat. nc o remarc important din standartul SQL/89: n contextul lui
GROUP BY, DISTINCT i ORDER BY valoarea nedeterminat se reprezint ca un tip special a
valorii determinate, adic este posibil, de exemplu, formarea grupei de rnduri, unde rezultatul
coloanei date nu este determinat. Pentru asigurarea transportului programelor aplicative trebuie
atent apreciat specificul lucrului cu valorile nedeterminate ntr-o SGBD concret.
Predicatul between
Acest predicat are sintaxa urmtoare:
<between predicate>::=
<value expression>
[NOT] BETWEEN <value expression>AND<value expression>
Rezultatul x BETWEEN y AND z este egal cu rezultatul x>=y AND x<=z. rezultatul
x NOT BETWEE y AND z este egal cu rezultatul NOT (x BETWEEN y AND z).
Predicatul in
Predicatul in se determin de regulile sintactice urmtoare:
<in prredicate>::=
<value expression> {NOT] IN
{<subquery>|(<in value list>)}
<in value list>::=
<value specification>
{,<value specification>}
Tipurile operatorului din stnga i valorile din lista operatorului din dreapta(s amintim c
tabelul rezultant a subadresrii trebuie s conin fix o coloan) trebuie s fie compatibile.
Predicatul va avea rezultatul true atunci i numai atunci, cnd valoarea operantului din
stnga coincide macr cu una din valorile listei operantului din dreapta. Dac lista operantului
din dreapta e pustie(poate, dac operantul din dreapta se d ca o subadresare) sau valoarea.
Predicatul subneles a comparaiei x=y( unde x are valoarea expresiei afirmative a
operantului stng) este egal cu false pentru fiecare element y a listei operantului din dreapta ,
atunci rezultatul predicatului este egal cu unikown. Dup determinare rezultatul predicatului x
NOT IN S este egal cu rezultatul predicatului NOT (x IN S).
Predicatil like
Predicatul like are urmtoarea sintax:
<line predicate>::=
<column specification>[NOT] LIKE <pattern>
[ESCAPE<escape character>]
<pattern>::=<value specification>
<escape character>::=<value specification>
Tipurile de date a coloanei operantului din stnga i a exemplului trebuie s fie tipuri a
simbolurilor caracteriale. n despritura ESCAPE trebuie s fie specificat simbolul unical.
Rezultatul predicatului este true, dac pattern este subrndul coloanei date. Cu toate acestea, dac
depritura ESCAPE lipsete, atunci la suprapunerea ablonului cu coloana are loc nterpretarea
special a dou simboluri a ablonului: simbolul de subliniere(_) nseamn orice simbol
singular; simbolul procentului(%) nseamn consecutivitatea simbolurilor aleatoare a lungimii
aleatoare poate fi nul. Dac despritura ESCAPE este prezent i specific un oarecare simbol
singular x, atunci perechile de simboluri x_ i x% sunt simbolurile singulare * i %
corespunztor.
Rezultatul predicatului like este unikown, dac rezultatul coloanei sau a ablonului nu-i
determinat.
Rezultatul predicatului x NOT LIKE y ESCAPE z coincide cu rezultatul NOT x LIKE
y ESCAPE z.

Predicatul null
Acest predicat se descrie de sintaxa dat:
<null predicate>::=
<column specification> IS [NOT] NULL
Acest predicat n totdeauna are rezultatul true sau false. Cu toate acestea rezultatul x IS
NULL este egal cu true atunci i numai atunci cnd valoarea lui x nu-i determinat. Rezultatul
predicatului x NOT IS NULL este egal cu rezultatul NOT x IS NULL
Predicatul de cuantificare
Acest predicat are sintaxa urmtoare:
<quantified predicate>::=
<value expresion><comp op><cuantifier><subquery>
<quantifier>::=
<all>|<some>
<all>::=ALL
<some>::=SOME|ANY
Vom nota cu x rezultatul calculului expresiei afirmative prii stngi a predicatului, iar cu
S rezultatul calculului subadresrii.
Predicatul x<comp op> ALL S are valoarea true, dac S este pustie sau valoarea
predicatului x<comp op> S e egal cu true pentru fiecare S, care se include n S. predicatul
x<comp op> ALL S are valoarea false, dac valoarea predicatului x<comp op> S este egal
cu false macr pentru un S care se include n S. n celelalte cazuri valoarea predicatului
x<comp op> ALL S este egal cu unicown.
Predicatul x<comp op> SOME S are valoarea false, dac S este nul sau valoarea
predicatului x<comp op> S este egal cu false pentru fiecare s din S. Predicatul x<comp op>
SOME S are valoarea true, dac valoarea predicatului x<comp op> S este egal cu true
macr pentru un s din S. n celelalte cazuri valoarea predicatului x<comp op> SOME S este
unikown.
Predicatul exists
Predicatul exists are sintaxa urmtoare:
<exists predicate>::=
EXISTS <subquery>
Valoarea acestui predicat n totdeauna este true sau false, i aceast valoare este true
atunci i numai atunci, cnd rezultatul calculului subadresrii nu-i nul.

15.2.3. Despritura GROUP BY
Dac n expresia tabelar este prezent despritura GROUP BY, atunci ea se va executa
urmtoarea. Sintaxa ei este urmtoarea:
<group by clause>::=
GROUP BY <column specification>
[{,<column specification>}]
Dac vom nota cu R tabelul, care are rezultatul despriturii precedente(FROM sau
WHERE) atunci n calitate de rezultat a despriturii GROUP BY este desprirea lu R ntr-o
mulime de rnduri, care-i alctuit din numrul minim a aa grupe, c pentru fiecare coloan din
lista coloanelo despriturii GROUP BY n toate rndurile fiecrei grupe, ce include mai mult de
un rnd, valorile acestei coloane sunt egale. Pentru determinarea rezultatului despriturii
GROUP BY n standart se utilizeaz termenul tablou grupat.

15.2.4. Despritura HAVING
Ultima la calculul expresiei tabelare se utilizeaz despritura HAVING(dac ea e
prezent). Sintaxa ei este:

<having clause>::=
HAVING <search condition>
Despritura HAVING poate s apar condiionat n expresia tabelar numai n cazul
cnd n ea e prezent despritura GROUP BY. Condiia de citare a acestei desprituri d
condiie asupra grupului de rnduri a tabelului grupat. De fapt despritura HAVING poate fi
prezent i n expresia tabelar ce nu conine GROUP BY. n acest caz se presupune c
rezultatul calculului despriturilor anterioare reprezint un tabel grupat, format dintr-o grup
fr coloane de grupare selectate.
Condiia de cutare a despriturii HAVING se construiete dup aceleai reguli
sintactice ca i condiia de cutare WHERE i poate include aceleai predicate. ns sunt careva
limite speciale sintactice n cazul condiiei de cutare a specificaiilor coloanelor tabelelor din
despritura WHERE a expresiei tabelare date. Aceste limite rezult de aceea c condiiile de
cutare a despriturii HAVING d condiie pe toat grupa i nu pe rnduri n parte. De aceea n
expresiile afirmative a predicatelor, care intr n condiia de selecie a despriturii HAVING,
putem utiliza direct doar specificaiile coloanelor, artate n calitate de coloane de grupare n
despritura GROUP BY. Celelalte coloane pot fi specificate doar n interiorul specificaiei
funciei de agregat COUNT, SUM, AVG, MIN i MAX, care n cazul dat, calculeaz o oarecare
valoare de agregat a ntregii grupe de rnduri. La fel este i cu subadresrile, ce intr n
componena predicatelor condiiilor de selecie a despriturii HAVING: dac n subadresare se
utilizeaz caracteristica grupei date, atunci ea poate fi dat doar pe calea schirii la coloanele
gruprii.
Rezultatul ndeplinirii despriturii HAVING este tabelul grupat ce conine doar acele
grupri de rnduri, pentru care rezultatul calculului condiiei de cutare este true. Dac
despritura HAVING e prezent n expresia tabelar, care nu conine GROUP BY, atunci
rezultatul ndeplinirii ei va fi sau un tabel nul, sau rezultatul ndeplinirii despririlor anterioare a
expresiei tabelare, fiind privit ca o singur grup, fr coloane de grupare.

15.3. Funciile de agregat i rezultatele adresrilor

15.3. Funciile de agregat i rezultatele adresrilor
Funciile de agregat(n standartul SQL/89 ele se numesc funcii asupra mulimilor) se
determin n SQL/89 de urmtoarele reguli sintactice:
<set function specification>::=
COUNT (*)|<distinct set function>
|<all set function>
<distinct set function>::=
{AVG|MAX|MIN|SUM|COUNT}
(DISTINCT<column specification>)
<all set function>::=
{AVG|MAX|MIN|SUM}([ALL] <value expresion>)
Dup cum vedem n aceste reguli, n standartul SQL/89 sunt determinate 5 funcii
standarte de agregat: COUNT numrul rndurilor sau a valorilor; MAX valoarea maxim;
MIN valoarea minim; SUM valoarea sumei i AVG valoarea medie.

15.3.1. Semantica funciilor de agregat
Funciile de agregat sunt destinate pentru a calcula o valoare oarecare pentru mulimea de
rnduri dat. Aa mulime de rnduri poate fi grupa de rnduri, dac funcia de agregat se
utilizeaz pentru tabelul grupat, sau tabelul ntreg. Pentru toate funciile agregat, n afar de
COUNT(*), ordinea(cerut de semnatic) calculrii este: pe baza parametrilor funciei de agregat
din mulimea de rnduri dat se creeaz lista valorilor. Apoi pe baza acestei liste de valori are loc

calculul funciei. Dac lista este nul, atunci valoarea funciei COUNT pentru ea este zero, iar
valoarea celeilalte funcii null.
Fie T tipul valorilr din aceast list. Atunci rezultatul calculului funciei COUNT este un
numr ntreg cu scara i precizia determinate n realizare. Tipul rezultatului valorilor funciilor
MIN i MAX coincid cu T. La calculul funciei SUM i AVG tipul T nu trebuie s fie de tipul
rndurilor simbolice, iar tipul rezultatului funciei este de tip de numere ntregi cu scara i
precizia determinabile n realizare, dac T tip de numere ntregi i tip de numere reale cu
precizia determinat n realizare, dac T tip de numere aproximative.
Calculul funciei COUNT(*) are loc pe calea enumrrii numrului de rnduri n
mulimea dat. Toate rndurile se consider diferite, chiar dac ele snt compuse dintr-o singur
coloan cu valoarea null n toate rndurile.
Dac funcia de agregat este specificat fr cuvntul cheie DISTINCT, atunci lista
valorilor se construiete din valorile coloanei selectate(s subliniem c n acest caz nu se permite
calculul expresiilor afirmative). Apoi din aceast list se exclud valorile nedeterminate i se
nltur valorile dublicate. Apoi se calculeaz funcia dat.
Dac funcia de agregat este specificat fr cuvntul cheie DISTINCT(sau cu cuvntul
cheie ALL), atunci lista de valori se formeaz din valorile expresiei afirmative, ce se calculeaz
pentru fiecare rnd al expresiei date. Apoi din list se nltur valorile nedeterminate i se
calculeaz funcia de agregat.
Atragei atenia c n acest caz nu se permite utilizarea funciei COUNT.
Atenie: Ambele limite, artate n abzaele anterioare, sunt mai mult tehnice dect
principiale i pot s lipseasc n realizri concrete. Cu toate acestea ele sunt limite ale
standartului SQL/89 i trebuie s inem cont de ele la programarea mobil.

15.3.2. Rezultatele adresrilor
Funciile de agregat pot fi utilizate n specificarea cursorului, a operatorului de selecie i
n subadresare dup cuvntul cheie SELECT(n aceast subdespritur vom numi aa construcii
ca list de selecie, i s nu uitm c n caz de subadresare aceast list e format doar dintr-un
element) i n condiia despriturii HAVING. Standartul permite utilizarea mult mai exotic a
funciilor de agregat n subadresri( funcia de agregate pe grupe de corteje a adresrii
exterioare), dar n practic se ntlnesc foarte rar.
S cercetm diferite cazuri de utilizare a funciilor de agregat n lista de selecie n
dependen de tipul expresiei tabelare.
Dac rezultatul expresiei tabelare R nu este un tabel grupat, atunci apariia macr a unei
funcii de agregat din mulimea de rnduri R n lista de selecie duce la ceea, c R este privit ca
un tabel grupat, care-i alctuit dintr-o(sau nici una) grup ce nu are coloane de grupare. De
aceea, n acest caz, n lista de selecie nu se permite utilizarea direct a specificaiilor rndurilor
R: toate ele trebuie s se gseasc n interiorul specificaiilor funciilor de agregat. Ca rezultat a
adresrii e tabelul, cu nu mai mult de un rnd, primit pe calea utilizrii funciilor de agregat R.
La fel stau lucrurile i n cazul, cnd R este un tabel grupat, dar expresia tabelar nu
conine despritura GROUP BY( i deci conine despritura HAVING). Dac n cazul abzaului
anterior erau dou variante de creare a listei de selecie: numai cu indicarea direct a coloanelor
R sau numai cu indicarea lor n interiorul specificaiilor a funciilor de agregat), atunci n cazul
dat este posibil numai a doua variant. Rezultatul expresiei tabelare este afiat de ctre tabelul
grupat, format dintr-o singur grup i rezultatul adresrii poate fi format doar pe calea aplicrii
funiilor de agregat pentru acest grup de rnduri. Din nou ca rezultat a adresrii avem un tabel,
ce conine nu mai mult de un rnd, primit pe calea aplicrii funciilor de agregat pentru R.
Cazul cnd R este un tabel adevrat grupat, adic expresia tabelar conine despritura
GROUP BY i rezult c este determinat cel puin o coloande grupare. n acest caz regulile de
formare a listei de selecie coincid cu regulile de formare a condiiei de selecie a despriturii

HAVING: permite utilizarea direct a specificaiei coloanei de grupare, dar specificaiile
celorlalte coloane R, pot s apar doar n interiorul specificaiilor funciilor de agregat. Ca
rezultat a adresrii este tabelul, n care numrul de rnduri este egal cu numrul de grupuri n R,
i fiecare rnd se formeaz pe baza valorilor coloanelor de grupare i a funciilor de agregat
pentru grupa dat.

Lecia 16. Utilizarea SQL la programarea aplicat

Lecia 16. Utilizarea SQL la programarea aplicat
16.1. Limbajul modulelor sau SQL implimentat
n standartul SQL/89 sunt determinate dou metode de interaciune cu BD din programul
aplicat, scris n limbajul tradiional de programare(dup cum am mai numit, SQL/89 este orientat
spre utilizare mpreun cu limbajele Cobol, Fortran, Pascal i PL/1, dar n realizri, de obicei
susine i limbajul C). Prima metod const n aceea c toi operatorii SQL, cu care poate opera
programul aplicat dat, sunt concentrate ntr-un modul i sunt oformate ca proceduri a acestui
modul. Pentru aceasta SQL/89 conine un sublimbaj special limbajul modular. La utilizarea
acestui mijloc de interaciune cu BD, programul aplicat conine apelul procedurilor modulului
SQL cu transmiterea ctre ele a parametrilor dai i cu primirea parametrilor rezultani.
A doua metod const din utilizarea aa numitului SQL implimentat, cnd cu utilizarea
sintaxei speciale n programul limbajului tradiionalde programare se implimenteaz operatori
SQL. n acest caz, din punct de vedere a programului aplicat, operatorul SQL se ndeplinete
dup loc. O parametrizare clar a operatorilor SQL lipsete, dar n operatorii implementai
SQL pot fi utilizate numele variabilelor a programului de baz, i datorit acestui fapt, se
asigur legtura dintre programul aplicat i SGBD.
Conceptual, aceste 2 metode sunt echivalente. Mai mult ca att, n standart se determin
reguli de creare a modulului SQL dup programul cu SQL implimentat. ns n majoritatea
realizrilor, operatorii SQL se prelucreaz foarte diferit. Modulul SQL, de obicei, se compileaz
aparte de programul aplicat, n rezultat se creeaz setul aa numitor proceduri memorabile( n
standart acest termen nu se utilizeaz, dar e rspndit n realizrile comerciale). Adic n cazul
utilizrii modulului SQL, compilarea operatorilor SQL are loc odat, i apoi procedurile
corespunztoare pot fi apelate din programul aplicat de cte ori va fi nevoie.
Spre deosebire de aceasta, pentru operatorii SQL, implimentai n programul aplicat,
compilarea acestor operatori, de obicei, are loc de fiecare dat la utilizarea lor(mai bine zis, la
fiecare prima utilizare a operatorului la ncrcarea dat a programului aplicat).
Desigur, utilizatorul nu trebuie s tie de aceast diferen tehnic n prelucrarea a dou
tipuri de interaciuni cu SGBD. Exist i aa sisteme, ce provoac compilarea de o singur
folosin a operatorilor implimentai SQL i pstreaz codul compilat. Dar totui e bine de inut
cont de aceasta. S saducem unele propoziii pentru i n potriva la fiecare din aceste dou
metode. La utilizarea limbajelor modulelor textul programului aplicat are un volum mai mic,
interaciunile cu SGBD sunt mult mai localizate pe baza existenei parametrilor de apel a
procedurilor. Din alt parte, pentru nelegerea sensului comportrii programului aplicat va fi
nevoie de citirea simultan a dou texte. n afar de aceasta, dup cum se pare, sintaxa modulului
SQL se poate deosebi mult n diferite realizri.
SQL implimentat ne d posibilitatea crerii unor programe aplicate mult mai auto
ntreintoare. Sunt mai multe afirmaii pentru a ne baza pe simplitatea transferului a aa
program n mediul altei SGBD, deoarece standartul implimentrii mai mult sau mai puin se
ndeplinete. Neajunsul de baz este un oarecare PL este tipul acestor programe, indiferent de
limbajul de baz ales. Desigur trebuie de inut cont de observaiile, ce se conin n abzaele
anterioare.

Apoi vom descie pe scurt limbajul modulelor i regulile de implimentare n dependen
de standartul SQL/89(s reamintim, c regulile de implimentare nu fac parte din standart).

16.2. Limbajul modulelor

16.2. Limbajul modulelor
Structura modulului SQL n standartul SQL/89 se determin din regulile sintactice
urmtoare:
<module>::=
<module name clause>
<language clause>
<module autorization clause>
[<declare cursor>]
<procedure>
<module name clause>::=MODULE [<module name>]
<language clause>::=LANGUAGE{COBOL|FORTRAN|PASCAL|PLI}
<module autorization clause>::=
AUTORIZATION<module autorization identifier>
<module autorization identifier>::=<autoriyation identifier>
Este important c fiecare modul SQL e orientat spre utilizare n programele scrise ntr-un
limbaj concret de programare. Dac n modul sunt prezentate procedurile de lucru cu cursoarele,
atunci toate cursoarele trebuie s fie specificate la nceputul modulului. S accentum c
declararea cursorului nu se ncarc ntr-o careva procedur, deoarece acesta este un operator SQL
de descriere i nu de ndeplinire.

16.2.1. Determinarea procedurii
Procedurile n modulul SQL se determin dup construciile sintactice date:
<procedure>::=
PROCEDURE<procedure name>
<parameter declaration>;
<SQL statement>;
<parameter declaration>::=
<parameter name><data type>
|<SQL CODE parameter>
<SQL CODE parameter>::= SQLCODE
<SQL statement>::=
<close statement>
|<comit statement>
|<delete statement positioned>
|<delete statement searched>
|<fetch statement>
|<insert statement>
|<open statement>
|<rollback statement>
|<select statement>
|<update statement positioned>
|<update statement searched>.
Numele fiecror proceduri ntr-un mediu trebuie s fie diferite. Orice nume a
parametrului, care se conine n parametrul SQL a procedurii, trebuie s fie specificat n
compartimentul de declarare a parametrilor formali, artai la declararea ei. Lista parametrilor

formali a fiecrei proceduri, trebuie s conin fix un parametru SQLCODE(codul de rspuns al
procedurii).
16.3. SQL implementat
Deoaece n standartul SQL/89 nu sunt specificate regulile de implementare a SQL n
limbajul C, vom aduce exemplu a regulilor sintactice generale de implimentare a SQL n
limbajul C, vom aduce exemplu a regulilor sintactice generate de implementare, utilizate pentru
orice limbaj. Aceasta va permite aprecierea nivelului de standartizare a unei realizri concrete.
<embedded SQL statement>::=
<SQL prefix>
{<declare cursor>
|<embedded exception declaration>
|<SQL statement>}
[<SQL terminator>]
<SQL prefix>::=EXEC SQL
<SQL termination>::=END EXEC|;
<embedded SQL declare section>::=
<embedded SQL begin declare>
[<host variable definition>]
<embedded SQL end declare>
<embedded SQL begin declare>::=
<SQL prefix> BEGIN DECLARE SECTION[<SQL terminator>]
<SQL embedded end declare>::=
<SQL prefix> END DECLARE SECTION[<SQL terminator>]
<embedded variable name>::=:<host identifier>
<embedded exception declaration>::=
WHENEVER<condition><excetion action>
<condition>::=SQLERROR|NOT FOUND
<exception action>::=CONTINUE|<go to>
<go to>::={GOTO|GO TO}<target>
<target>::=:<host identifier>|<unsigned integer>.
Operaiile implimentate SQL, inclusiv i declararea cursorului, deasemenea despriturile
declarrii situaiilor excepionale i a variabilelor programului de baz trebuie s fie luate n
ghilimele EXEC SQL i END EXEC. Declararea cursorului trebuie s fie ntlnit textual mai
devreme de orice operaie ce se bazeaz pe acest cursor. Toate variabilele programului de baz
ce se utilizeaz n operatorii implimentai SQL, trebuie s fie declarai textual n despritura
anterioar acestui operator de declarare a variabilelor programului de baz. Cu toate acestea
sintaxa declarrii variabilelor corespunde sintaxei limbajului de programare de baz, ns la
nceputul numelui variabilei se pun dou puncte.
Mecanismul de prelucrare a situaiilor excepionale n SQL/89 este foarte simplu(putem
spune primitiv). Putem crea reacia pentru apariia a dou feluri de condiii: SQL ERROR este
condiia apariiei n variabil SQL CODE dup ndeplinirea operatorului implementat cu sens de
valoare negativ; NOT FOUND este condiia apariiei n SQL CODE a valorii +100(acest cod
nseamn emanarea cursorului). Reacia poate fi alctuit din execuia trecerii la semnul
programului de baz(aciunea GO TO) sau poate s lipseasc(aciunea CONTINUE).
Va reaciona acel operator de determinare a reaciei n caz de situaie excepional, care
textual este mai aproape de la nceputul programului de operatorulSQL.
S atragem atenia c n multe realizri se menin dou feluri de coduri de rspuns la
execuia operatorilor SQL(implementai sau luai din modul): prin variabila SQL CODE cu
codurile de rspuns, care sunt reprezentate prin numere ntregi i prin variabila SQL STATE cu
codurile de rspuns, codificarte prin numere zecimale, afiate n form de text. Este tendina de

trecere la utilizarea numai a mecanismului SQL STATE, dar n realizrile standarte trebuie s se
menin mecanismul SQL CODE.

16.4. Setul operatorilor de manipulare cu datele

16.4. Setul operatorilor de manipulare cu datele
n standartul SQL/89 este determinat un set de operatori de manipulare cu datele foarte
limitat. Ei pot fi clasificai pe grupe de operatori, legai cu cursorul, operatori singulari de
manipulare cu datele i operatorii de finisare a tranzaciilor. Toi aceti operatori pot fi utilizai
att n modulul SQL ct i n SQL implementat. S atragem atenia c n SQL/89 nu-I determinat
setul de operaii a lui SQL interactiv.

16.4.1. Operatorii legai cu cursorul
Operatorii acestei grupe sunt legai prin faptul c toi ei lucreaz cu un oarecare cursor,
declararea cruiea trebuie s se conin n acelai modul sau n programul cu SQL implementat.
Operatorul de declarare a cursorului
Vom repeta regulile sintactice de declarare a cursorului:
<declare cursor>::=
DECLARE <cursos name> CURSOR FOR <cursor specification>
<cursor specification>::=
<query expresion>[<order by clause>]
<query expresion>::=
<query term>
|<query expresion> UNION [ALL] <query term>
<query term>::=<query specification>|(<query expresion>)
<order by clause>::=
ORDER BY <sort specification>
[{,<sort specification>}]
<sort specification>::=
{<unsigned integer>|<column specification>}
[ASC|DESC].
La declararea cursorului se pot utiliya adres[ri de un tip mai comun cu posibilitatea
execuiei organiyaiilor UNION ;I for[rii reyultatului final. Acest oerator nu este executabil, dar
numai leag[ numele cursorului cu specificaia cursorului.
Operatorul de deschidere a cursorului
El este descris de regula sintactic[ urm[toare>
<open statement>::=OPEN <cursor name>.
n realizrile SQL implementat de obicei se cere ca declararea cursorului, textual s fie
mai nainte de operatorul de deschidere a cursorului. Operatorul de deschidere a cursorului
trebuie s fie primul n seria operatorilor ndeplinii, legai cu cursorul dat. La execuia acestui
operator are loc pregtirea cursorului de lucru asupra lui. n parte, n acest timp are loc pregtirea
specificaiei cursorului cu valorile variabilelor limbajului de baz n cazul SQL-ului implimentat,
sau a parametrilor n cazul modulelor.
n majoritatea realizrilor, n cazul SQL implementat, anume ndeplinirea operatorului de
deschidere a cursorului duce la compilarea specificaiei cursorului.
Operatorii urmtori pot fi executai n ordine aleatoare asupra cursorului deschis.
Operatorul de citire a rndului urmtor a cursorului
Sintaxa operatorului de citire este urmtoarea:
<fetch statement>
FETCH <cursor name> INTO <fetch target list>

<fetch target list>::=
<target specification>[{,<target specification>}].
n operatorul de citire se specific numele cursorului i despritura neaprat INTO, ce
conine lista specificaiilor destinaiilor(lista numelor variabilelor a programei de baz n cazul
SQL implementat sau a numelor parametrilor de ieire n cazul modulului SQL). Numrul i
tipurile datelor n lista destinaiilor trebuie s coincid cu numrul i tipurile datelor listei de
selecie a specificaiilor cursorului.
Orice cursor deschis n totdeauna are poziia: el poate fi instalat naintea unui rnd al
tabelului rezultant(naintea primului rnd ndat dup deschiderea cursorului), ntr-un rnd a
rezultatului sau n ultimul rnd a rezultatului.
Dac tabelul la care indic cursorul este nul sau cursorul e poziionat pe ultimul rnd sau
dup el, atunci la execuia operatorului de citire cursorul se fixeaz n poziia de dup ultimul
rnd, parametrului SQL CODE i se atribuie valoarea 100, scopurilor identificate n despritura
INTO nu li se atribuie nici o valoare. Dac cursorul este poziionat naintea rndului, atunci el se
poziioneaz n acest rnd i valoarea acestui rnd i se atribuie scopurilor corespunztoare. Dac
cursorul este poziionat pe rndul r, diferit de ultimul rnd, atunci cursorul se poziioneaz pe
rndul, care imediat urmeaz dup rndul r i valorile din acest rnd urmtor li se atribuie
scopurilor corespunztoare.
Apare ntrebarea, n ce mod putem parametriza cursorul cu o valoare nedeterminat sau
cum s vedem c valoarea aleas din rndul urmtor este nedeterminat. n SQL/89 acest lucru
se atinge pe baza utilizrii aa numitor parametri indicatori i a variabilelor. Dac se cunoate c
valoarea transmis din programul principal de la SGBD, poate fi nedeterminat i acest fapt l
intereseaz pe programatorul aplicat, atunci specificaia parametrului sau a variabilei n
operatorul SQL are tipul: <parameter name>[INDICATOR] <parameter name> la specificarea
parametrului i <embedded variabile name>[IDENTIFICATOR] <embedded variable name> la
specificarea variabilei. Valoarea negativ a parametrului indicator sau a variabilelor
indicatoare(ele trebuie s fie de tip ntreg) coincide cu valoarea nedeterminat a parametrului sau
a variabilei.
Operatorul de tergere a poziiei
Sintaxa acestui operator este:
<delete statement:positioned>::=
DELETE FROM <table name>
WHERE CURENT OF <cursor name>.
Dac cursorul specificat n operator este deschis i-i poziionat pe un oarecare rnd i
cursorul determin tabelul schimbtor, rndul curent al cursorului se terge, iar cursorul se
poziioneaz n poziia rndului urmtor. Tabelul specificat n despritura FROM a operatorului
DELETE, trebuie s fie tabelul, specificat n cea mai exterioar despritur FROM de
specificare a cursorului.
Operatorul de modificare a poziiei
Operatorul dat are sintaxa urmtoare:
<update statement:positioned>
UPDATE <table name>
SET<set clause:positioned>
[{,<set clause:positioned>}]
WHERE CURENT OF <cursor name>
<set clause positioned>::=
<object column:positioned>=
{<value expresion>|NULL}
<object column:positioned>::=<column name>.

Dac cursorul specificat n operator este deschis i-i poziionat pe un rnd oarecare, i
cursorul determin tabelul schimbtor, atunci rndul curent al cursorului se modific n
conformitate cu despritura SET. Poziia cursorului nu se schimb. Tabelul specificat n
despritura FROM a operatorului DELETE trebuie s fie tabelul, specificat n cea mai
exterioar despritur FROM a specificaiei cursorului.
Operatorul de nchidere a cursorului
Sintactica acestui operator este urmtoarea:
<close statement>::=CLOSE<cursor name>.
Dac n momentul execziei acestui operator cursorul este n stare deschis, atunci
operatorul transfer cursorul n stare nchis. Dup aceasta asupra cursorului poate fi executat
doar operaia OPEN.

16.4.2. Operatorii singulari de manipulare cu datele
Fiecare operator al acestei grupe este independent fa de oricare alt operator.
Operatorul de selecie
Sintaxa lui este:
<select statement>::=
INTO<select target list><table expresion>
<select target list>::=
<target specification>
[{,<target specification>}]
Deoarece rezultatul operatorului singular de selecie este tabelul, ce conine nu mai mult
de un rnd, lista scopurilor se specific n nsi operatorul.
Operatorul de tergere a cutrii
El este descris de sintaxa urmtoare:
<delete statement:searched>::=
DELETE FROM <table name>
WHERE[<searched condition>].
Tabelul T, specificat n despritura FROM a operatorului DELETE, trebuie s fie
schimbtor. Asupra condiiei de cutare se depune condiia, c pentru tabelul T nu trebuie s se
conin schie n nici o subadresare depus a predicatelor despririi WHERE.
De fapt operatorul se execut n felul urmtor: se verific succesiv toate rndurile
tabelului T i acele rnduri pentru care rezultatul calculului condiiei de selecie este true, se
terg din tabelul T. n absena despriturii WHERE se terg toate rndurile tabelului T.
Operatorul de modificare a cutrii
El are sintaxa urmtoare:
<update statement:searched>::=
UPDATE <table name>
SET<set clause:searched>
[{,<set clause:searched>>}]
[WHERE<searched condition>]
<set clause:searched>::=
<object column:searched>=
{<value exprersion>|NULL}
<object column:searched>::=<column name>.
Tabelul T, specificat n operatorul UPDATE trebuie s fie schimbtor. Asupra condiiei
de cutare se depune condiia c pentru tabelul T nu trebuie s se conin schie n nici o
subadresare depus a predicatelor despririi WHERE.
Operatorul se execut n felul urmtor: tabelul T se verific succesiv i fiecare rnd pentru
care rezultatul calculului de cutare este true, se schimb n conformitate cu despritura SET.

Dac expresia afirmativ n despritura SET conine schie pentru coloanele tabelului T, atunci
la calculul expresiei afirmative se utilizeaz valorile coloanelor curente, pn la modificarea lor.
Operatorii de finisare a tranzaciei
Tranzacia curent poate fi finisat cu succes(cu fixarea n baza de date a schimbrilor
efectuate) pe calea execuiei operatorului COMMIT WORK sau accidental(cu tergerea
schimbrilor din baza de date, create de tranzacia curent) pe calea execuiei operatorului ROLL
BACK WORK. La execuia oricrui din operatorii dai are loc nchiderea forat a tuturor
cursoarelor, deschise la momentul execuiei operatorului de finisare a tranzaciei.

16.5. SQL dinamic n Oracle V.6

16.5. SQL dinamic n Oracle V.6
setul de operatori SQL descris n standartul SQL/89 este destinat implimentrii n
programul scris n limbajul obinuit de programare. De aceea n acest set sunt amestecai
operatorii a limbajului relaional adevrat cu adresri(de exemplu operatorul de tergere a unei
pri de rnduri din tabel, care satisfac valorii date i operatorii de lucru cu cursoarele, ce permit
accesul pe rnduri la tabelul rezultat a adresrii.
Este clar c n regimul de dialog setul de operatori SQL i sintaxa lor trebuie s fie un
pic altfel. ntrebarea este cum s realizm un aa program de dialog. Regulile de implementare a
SQL standart n programul elaborat ntr-un limbaj obinuit de programare prevd c toat
informaia, privind operatorii SQL, e cunoscut n static(cu excepia valorilor variabilelor
utilizate n calitate de constante n SQL). Nu sunt prevzute sursele standarte de compilare cu
execuie succesiv a operatorilor, care devin cunoscui doar n momentul execuiei(de exemplu
se introduc din terminal). De aceea bazndu-ne doar pe standart, e imposibil de a realiza
monitorul de dialog de interaciune cu BD n limbajul SQL sau alt program aplicat, n care
textul operatorilor SQL apare n timpul execuiei, adic standartul trebuie lrgit. Una din
posibilele ci de lrgire const n utilizarea grupului special de operatori, ce asigur compilarea
dinamic(n timpul execuiei programului aplicat) a submulimii de baz a operatorilor SQL i
care sisin execuia lor corect. Unul din seturile de aa operatori fcea parte din dialectul SQL,
realizat n System R, alt set mai deosebit face parte din realizarea Oracle V.6 i n sfrit, n
standartul nou SQL/92 a aprut versiunea standart a lui SQL dinamic.
Deoarece n SGBD Oracle sursele lui SQL dinamic sunt realizate comparativ de mult,
are sens s le vedem mai nti pe ele, pentru a avea o baz de comparaie cu SQL/92.
n setul adugtor de oeratori, ce menin compilarea dinamic a operaiilor SQL de baz,
intr operatorii: PREPARE, DESCRIBE i EXECUTE.

16.5.1. Operatorul de pregtire
Operatorul PREPARE are sintaxa:
<prepare statement>::=
PREPARE<statement name>FROM<host string variable>
<statement name>::=name.
n timpul execuiei operatorului PREPARE rndul caracterial ce se conine n host string
variable, se transmite compilatorului SQL, care-l prelucreaz la fel ca i cum s-ar fi primit n
static. Codul primit la execuia operatorului prepare rmne acionabil pn la finisarea
tranzaciei sau pn la execuia repetat a operatorului dat PREPARE n limitele aceleieai
tranzacii. Spre deosebire de operatorii SQL inclui static n programul elaborat n limbajul de
programare dat are loc dup nume(adic n conformitate cu standartul n operatorul SQL
implementat pot fi utilizate pur i simplu numele variabilelor programului dat), natura dinamic
a operatorilor, pregtii cu ajutorul operatorului PREPARE, impun analiza acestor nume ca nume

a parametrilor formali. Coincidena acestor parametri formali cu adresele variabilelor
programului dat se determin poziional, n timpul execuiei operatorului pregtit.

16.5.2. Operatorul de primire a descriere a operatorului pregtit
Operatorul DESCRIBE este prevzut pentru determinarea tipului operatorului pregtit
mai nainte, de a determina numrul i tipurile coloanelor tabelului rezultant, dac operatorul
pregtit este operator de selecie(SELECT). Aciunea operatorului DESCRIBE const n faptul
c n locaia de memorie selectat a programului aplicat(structura acestei locaii este fixat i este
cunoscut de ctre utilizatori) se nscrie informaia care caracterizeaz operatorul pregtit mai
devreme cu numele dat.

16.5.3. Operatorul de execuie a operatorului pregtit
Operatorul EXECUTE sete destinat execuiei operatorului SQL pregtit mai devreme de
tipul N(care nu cere aplicarea cursorului) sau pregtirii concomitente i execuiei a aa
operator. Sintaxa operatorului EXECUTE este:
<execute statement>::=
EXECUTE
{<statement name>[USING<host vars list>]
(IMMEDIATE<host string variable>}.
Pentru execuia operatorului pregtit slujete prima variant a operatorului EXECUTE. n
acest caz ;statement name: trebuie s dea numele ce a fost utilizat mai devreme n operatorul
PREPARE. Dac n operatorul pregtit sunt prezeni parametri formali, atunci n operatorul
EXECUTE trebuie s se indice lista parametrilor actuali <hosrt vars list>. Numrul i tipurile
parametrilor formali a operatorului pregtit.
Varianta a doua a operatorului EXECUTE, n Oracle este destinat pregtirii concomitente
i execuiei operatorului SQL de tip N. n acest caz parametrii execuiei operatorului
EXECUTE este rndul, care trebuie s conin textul operatorului SQL(acest rnd poate fi
deasemenea indicat literal). Se interzice utilizarea n acest operator a variabilelor a programului
dat a parametrilor formali.

16.5.4. Lucrul cu operatorii dinamici SQL prin intermediul cursoarelor
Pentru utilizarea a aa operatori se utilizeaz lrgirea mecanismului cursoarelor
standartului SQL. n primul rnd, la determinarea cursorului putem indica nu numai specificaia
literar a cursorului, ci i numele operatorului ce se introduce cu ajutorul operatorului
PREPARE( n acest caz operatorul PREPARE trebuie s se afle textual mai sus de operatorul
DECLARE). Aa dar sintactica complet a operatorului DECLARE este urmtoarea:
<declare cursor>::=
DECLARE <cursor name> CURSOR
FOR{<cursor specification>|<statement name>}
Deoarece, pentru aa cursor n static nu se cunoate informaia despre variabilele
programului dat de intrare i de ieire, atunci se utilizeaz alt form a operatorilor OPEN i
FETCH.
Sintaxa complet a acestor operatori:
<open statement>::=
OPEN<cursor name>
[USING{<host vars list>|DESCRIPTOR<descr name>}]
<fetch statement>::=
FETCH<cursor name>
{INTO <fetch target list>
(USING<host vars list>

(USING DESCRIPTOR <descr name>}.
Dup cum se vede, se presupun duo tipuri de indicare a parametrilor de tip parametric
de intrare i de ieire: direct cu intrarea n operatorii OPEN i/sau FETCH a listelor numelor
variabilelor a programului dat i indirect, cnd numele parametrilor i adresele lor se indic
printr-o structur adugtoare a descriptorilor.
Prima metod se ofer pentru lucrul cu operatorii de selecie, pentru care este fixat setul
parametrilor formali de intrare i de ieire. Mai precis, n ceea ce privete parametrii de ieire,
trebuie s fie fixai numrul i tipurile elementelor a listei de selecie.
A doua metod de lucru cu operatorii dinamic compilai, care necesit utilizarea
cursoarelor, const n utilizarea descriptorilor a listelor parametrilor formate dinamic. n acest
caz toat rspunderea pentru coincidena tipurilor parametrilor formali i actuali cade pe
programator. n rezultatul erorii la formularea a aa liste, poate fi pierdut memoria programului
C.

Lecia 17. Unele proprieti SQL/92 i SQL-3

Lecia 17. Unele proprieti SQL/92 i SQL-3
Noi nu vom descrie nici n general posibilitile noi a limbajului SQL n standartul
SQL/92. n prezent aceasta este foarte gndit, cci unica realizare accesibil SQL/92 este
versiunea scump Oracle V.7. ns se pare a fi de folos, s indicm un ir de operatori a SQL
dinamic cu mici comentarii, cci n SQL/92 este interpins primul pas de a standartiza aceast
parte a limbajului SQL. La sfritul leciei se aduce o mic sumare a noilor posibiliti, ateptate
n standartul nou SQL-3, lucrul asupra cruia se mai nfptuiete acum.

17.1. Operatorul de destingere a memoriei sub descriptor

17.1. Operatorul de destingere a memoriei sub descriptor
<allocate descriptor statement>::=
ALLOCATE DESCRIPTOR <descriptor name>
[WITH MAX <occurences>]
<occurences>::=<simple value specification>
<descriptor name>::=
[<scope option>]<simple value specification>
<scope option>::=GLOBAL|LOCAL
<simple value specification>::=
<parameter name>
(<embedded variable name>
(<literal>.
Comentarii:
Descriptorul este partea dinamic distingibil a memoriei programului aplicat care se
utilizeaz pentru primirea informaiei despre rezultat sau despre parametrii operatorului SQL
pregtit dinamic sau pentru indicarea parametrilor a aa operator. Sensul, c pentru destingerea
memoriei se utilizeaz operatorul SQL, i nu pur i simplu funcia standart ALLOC sau o
oarecare alt funcie a adresrii dinamice de memorie, const n faptul c programul aplicat nu
cunoate structura descriptorului i chiar a adresei lui. Aceasta permite de a nu lega SQL cu
posibilitile deosebite a oricrei structuri de programare. Toate schimburile de informaie ntre
programul aplicat i descriptori au loc la fel cu ajutorul unor operatori SQL(GET i SET, uite
mai jos).
ntrebarea a doua: Pentru ce n genere s destingem dinamic memorie sub descriptori.
Aceasta se face pentru c n caz general programul aplicat, care utilizeaz SQL dinamic, nu

cunoate n static numrul operaiilor SQL ce lucreaz simultan, descrierea crora i-ar putea fi
necesar. Cu aceeai e legat faptul c numele descriptorului poate fi indicat ca rnd literal de
simboluri att i ca variabil caracterial a limbajului inclusiv, adic el poate fi generat n timpul
de ndeplinire a programului. n operatorul ALLOCATE DESCRIPTOR, se poate specifica
numrul elementelor de descriere, pentru care el este calculat. Dac, de exemplu, n timpul
alocrii memoriei prin descriptor n despritura WITH MAX se specific un numr ntreg N, iar
apoi descriptorul se utilizeaz pentru descrierea M(M>N) elemente(de exemplu M coloane a
rezultatului adresrii, atunci acest fapt duce la apariia situaiei excepionale.

17.2. Operatorul de elibirare a memoriei din descriptor

17.2. Operatorul de elibirare a memoriei din descriptor
<deallocate descriptor statement>::=
DEALLOCATE DESCRIPTOR <descriptor name>.
Comentariu:
Execuia acestui operator aduce la elibirarea memoriei din descriptorul delimitat mai
devreme. Dup aceasta utilizarea numelui descriptorului este ilegal n orice alt operator, n afar
de ALLOCATE DESCRIPTOR.

17.3. Operatorul de primire a informaiei din regiunea descriptorului SQL

17.3. Operatorul de primire a informaiei din regiunea descriptorului SQL
<get descriptor statement>::=
GET DESCRIPTOR <descriptor name>
<get descriptor information>::=
<get count>
(VALUE<item number>
<get item information>
({<comma><get item information>}]
<get count>::=
<simple target specification 1>
<equals operator> COUNT
<get item information>::=
<simple target specification 2>
<equals operator>
<descriptor item name>
<item number>::=<simple value specification>
<simple target specification 1>::=<simple target specification>
<simple target specification 2>::=<simple target specification>
<descriptor item name>
TYPE
(LENGTH
(OCTET_LENGTH
(RETURNED_LENGTH
(RETURNED_OCTET_LENGTH
(PRECISION
(SCALE
(DATETIME_INTERVAL_CODE
(DATETIME_INTERVAL_PRECISION
(NULLABLE

(INDICATOR
(DATA
(NAME
(UNNAMED
(COLLATION_CATALOG
(COLLATION_SCHEMA
(COLLATION_NAME
(CHARACTER_SET_CATALOG
(CHARACTER_SET_SCHEMA
(CHARACTER_SET_NAME
<simple target specification>::=
<parameter name>
<embedded variable name>.
Comentariu:
Operatorul GET DESCRIPTOR se utilizeaz pentru selecia informaiei de descriere,
amestecat mai devreme n descriptor cu ajutorul operatorului DESCRIBE. La o singur execuie
a operatorului putem primi sau numrul elementelor completate(COUNT), sau informaia, ce se
conine n unul din elementele completate.

17.4. Operatorul de instalare a descriptorului

17.4. Operatorul de instalare a descriptorului
<set descriptor statement>::=
SET DESCRIPTOR<descriptor name>
<set descriptor information>
<set descriptor information>::=
<set count>
(VALUE<item number><set item information>
[{<comma><set item information>}]
<set count>::=COUNT<equals operator><simple value specification 1>
<set item information>::=
<descriptor item name>
<equals operator>
<simple value specification 2>
<simple target specification 1>::=<simple target specification>
<simple target specification 2>::=<simple target specification>
<item number>::=<simple value specification>.
Comentariu:
Operatorul SET DESCRIPTOR se utilizeaz pentru completarea elementelor
descriptorului cu scopul utilizrii lui n despritura USING. La o singur execuie a operatorului
valoarea o putem duce n cmpul COUNT(numrul elementelor completate), sau parial sau total
de creat un element a descriptorului.

17.5. Operatorul pregtirii

17.5. Operatorul de pregtire
<prepare statement>
PREPARE<SQL statement name>
FROM<SQL statement variable>
<SQL statement variable>::=<simple target specification>

<preparable statement>::=
<preparable SQL data statement>
|<preparable SQL schema statement>
|<PREPARABLE SQL transaction statement>
|<preparable SQL session statement>
|<preparable implementation defined statement>
<preparable SQL data statement>
|<delete statement:searched>
|<dynamic single row select statement>
|<insert statement>
|<dynamic select statement>
|<update statement:searched>
|<preparable dynamic delete statement:positioned>
|<preparable dynamic update statement:positioned>
<preparable SQL schema statement>::=<SQL schema station>
<preparable SQL tranzaction statement >::=<SQL tranzaction station>
<preparable SQL session statement >::=<SQL session station>
<dynamic select statement>::=<cursor specification>
<dynamic simple row select statement>::=<query specification>
<SQL statement name>|<extended statement name>
<extended statement name>::=[scope option]<simple value specification>
<cursor specification>::=
<query expresion>[<order by clause>]
[<updatability clause>::=
FOR {READ UNLY | UPDATE[OF<column name list>]}
<query expresion>::=
<non-join query expresion>
|<joined table>
<query specification>::=
SELECT[<set cuantifier>]
<select list><table expresion>
<set cuantifier>::=DISTINCT|ALL.
Comentariu:
Operatorul PREPARE induce compilarea i construirea planului de execuie a
operatorului SQL dat sub form de text. Dup execuia reuit a operatorului PREPARE, cu
operatorul pregtit se leag numele dat a acestui operator, care pe urm poate fi utilizat n
operatorul DESCRIBE, EXECUTE, OPEN CURSOR, ALLOCATE CURSOR i
DEALLOCATE PREPARE. Legtura aceasta se pstreaz pn la execuia operatorului
DEALLOCATE PREPARE.

17.6. Operatorul de respingere de la operatorul pregtit

17.6. Operatorul de respingere de la operatorul pregtit
<deallocate prepared statement>::=
DEALLOCATE PREPARE <SQL statement name>.
Comentariu:
Execuia acestui operator duce la aceea c, operatorul SQL pregtit mai devreme, legat
cu numele dat a operatorului, se lichideaz i, corespunztor, numele operatorului devine
nedeterminat. Dac operatorul pregtit este operator de selecie, i n timpul execuiei
operatorului DEALLOCATE exist un cursor deschis, legat de numele operatorului pregtit,

atunc DEALLOCATE returneaz codul erorii. Dac n operatorul seleciei exist cursor
nedeschis, format cu ajutorul operatorului ALLOCATE CURSOR, atunci acest cursor se
lichideaz. Dac cursorul s-a anunat de operatorul DECLARE CURSOR, atunci acest cursor
trece n starea existent pn la execuia operatorului PREPARE. Dac cu cursorul a fost legat
operatorul pregtit(DELETE dynamic sau UPDATE), atunci pentru aceti operatori se execut
operatorul DEALLOCATE.

17.7. Operatorul adresrii la descrierea operatorului pregtit

17.7. Operatorul adresrii la descrierea operatorului pregtit
<describe input statement>
|<describe output statement>
<describe input statement>::=
DESCRIBE INPUT<SQL statement name><using descriptor>
<describe output statement>::=
DESCRIBE [OUTPUT]<SQL statement name><using descriptor>
<using clause>::=<using arguments>|<using descriptor>
<using arguments>::=
{USING|INTO}<argument>[{<comma><argument>}]
<argument>::=<target specification>
<using descriptor>::=
{USING|INTO}SQL DESCRIPTOR<descriptor name>
<target specification>::=
<parameter specification>
|<variable specification>
<parameter specification>::=
<parameter name>[<indicator parameter>]
<indicator parameter>::=[INDICATOR]<parameter name>
<variable specification>::=<embedded variable name>[<indicator variable>]
<indicator variable>::=[INDICATOR]<embedded variable name>.
Comentariu:
La execuia operatorului DESCRIBE are loc completarea descriptorului artat n
operator, cu informaia, ce descrie sau rezultatul operatorului SQL pregtit mai devreme(dac
acesta-i operator de selecie) sau numrul i tipurile parametrilor operatorului pregtit. n <using
descriptor> se propune de scris USING SQL DESCRIPTOR.

17.8. Operatorul de execuie a operatorului pregtit

17.8. Operatorul de execuie a operatorului pregtit
<execute statement>::=
EXECUTE <SQL statement name>
(<result using clause>]
(<parameter using clause>]
<result using clause>::=<using clause>.
Comentariu:
Operatorul EXECUTE poate fi atribuit oricrui operator pregtit mai devreme, n afar de
<dynamic selected statement>. Dac acesta-i operatorul <dynamic single row select statement>,
atunci operatorul EXECUTE trebuie s conin despritura <result using class>, cu cuvntul
cheie INTO. n orice caz numrul parametrilor formali atribuii prin despriturile using, trebuie
s coincid cu numrul parametrilor formali, determinai n operatorul SQL pregtit.


17.9. Operatorul de pregtire cu execuie imediat

17.9. Operatorul de pregtire cu execuie imediat
<execute imediate statement>::=
EXECUTE IMEDIATE<SQL statement variable>.
Comentariu:
La execuia operatorului EXECUTE IMEDIATE are loc pregtirea i execuia imediat a
operatorului SQL dat n form de text. Cu toate acestea, operatorul ce se pregtete nu trebuie s
fie operator de selecie, nu trebuie s conin comentarii i parametri formali.

17.10. Operatorul de declarare a cursorului pentru operatorul de selecie pregtit dinamic

17.10. Operatorul de declarare a cursorului pentru operatorul de selecie pregtit dinamic
<dynamic declare cursor>::=
DECLARE<cursor name>[INTENSIVE][SCROLL]
CURSOR FOR<statement name>.
Comentariu>
Dup cum se determin n noul standart, pentru toi operatorii DECLARE CURSOR,
cursoarele se creeaz la nceputul tranzaciei i se lichideaz la finisarea ei. Aici <cursor name>
i <statement name> sunt identificatori atribuii direct.

17.11. Operatorul de determinare a cursorului pentru operatorul de selecie pregtit dinamic

17.11. Operatorul de determinare a cursorului pentru operatorul de selecie pregtit dinamic
<allocate cursor statement>::=
ALLOCATE<extended cursor name>[INTENSIVE][SCROLL]
CURSOR FOR<extended statement name>
<extended cursor name>::=
(<scope option>]<simple value specification>.
Comentarii:
Cursoarele determinate cu ajutorul operatorului ALLOCATE CURSOR, se creeaz la
execuia a aa operator i se lichideaz la execuia operatorului DEALLOCATE PREPARE sau
la finisarea tranzaciei. n acest operator numele cursorului i a operatorului SQL pregtit poate
fi dat nu numai n form literar, dar i prin variabile <scope option> . Se refer la sfera
vizibilitii numelor:n luimitele modulului curent sau n limitele sesiei curente.

17.12. Operatorul de deschidere a cursorului, legat cu operatorul de selecie dinamic pregtit

17.12. Operatorul de deschidere a cursorului, legat cu operatorul de selecie dinamic pregtit
<dynamic open statement>::=
OPEN<dynamic cursor name>[<using clause>].
Comentariu:
De fapt, operatorul de deschidere a cursorului, legat cu operatorul SQL pregtit dinamic,
se deosebete doar prin posesia despriturii using, n care se indic parametrii formali a
operatorului de selecie. n afar de aceasta, numele cursorului poate fi declarat prin variabil.

17.13. Operatorul de citire a rndului pe cursor, legat cu operatorul de selecie pregtit dinamic

17.13. Operatorul de citire a rndului pe cursor, legat cu operatorul de selecie pregtit dinamic

<dynamic fetch statement>::=
FETCH[[<fetch orientation>]FROM]
<dinamic cursor name><using clause>.
Comentarii:
De fapt, operatorul de citire pe cursor, legat cu operatorul SQL, dinamic se deosebete
doar prin posesia despriturii using, n care se declar aranjarea valorilor rndului curent a
tabelului rezultant. n afar de aceasta, numele cursorului poate fi dat prin variabil.

17.14. Operatorul de nchidere a cursorului legat de operatorul de selecie pregtit dinamic

17.14. Operatorul de nchidere a cursorului legat de operatorul de selecie pregtit dinamic
<dynamic close statement>::=
CLOSE<dynamic cursor name>.
Comentarii:
Operatorul de nchidere a cursorului, legat de operatorul SQL pregtit dinamic e
deosebete cu aceea c numele cursorului se poate indica printr-o variabil.

17.15. Operatorul de tergere poziional pe cursor

17.15. Operatorul de tergere poziional pe cursor
<dynamic delete statement:positioned>::=
DELETE FROM<table name>
WHERE CURENT OF<dynamic cursor name>
Comentariu:
Operatorul de tergere poziional pe cursor, legat cu operatorul SQL pregtit dinamic, se
deosebete prin faptul c numele cursorului se poate atribui printr-o variabil.

17.16. Operatorul modificrii poziionale pe cursor, legat cu operatorul de selecie pregtit
dinamic

17.16. Operatorul modificrii poziionale pe cursor, legat cu operatorul de selecie pregtit
dinamic
<dynamic update statement>positioned>::=
UPDATE <table name>
SET<set clause>[{<comma><set clause>}]
WHERE CURENT OF<dinamic cursor name>.
Comentariu:
Operatorul modificrii poziionale pe cursor, legat cu operatorul SQL pregtit dinamic se
deosebete prin aceea c numele cursorului se poate da printr-o variabil.

17.17. Operatorul de pregtire a tergerii poziionale

17.17. Operatorul de pregtire a tergerii poziionale
<prepare dynamic delete statement>positioned>::=
DELETE[FROM<table name>]
WHERE CURENT OF<cursor name>.
Comentariu:
Sensul de baz a apariiei a acestuia i a urmtorului operator const n faptul c
ansamblul dintre cursorul, determinat pe operatorul de selecie pregtit dinamic i operatorilor de
tergere i modificare declarai static, de aceea cursorul arat destul de neclar. De aceea n

standart au aprut operatorii de tergere i introducere poziional pregtii dinamic. Desigur c
ei trebuies se execute cu ajutorul operatorului EXECUTE.

17.18. Operatorul de pregtire a modificrii poziionale

17.18. Operatorul de pregtire a modificrii poziionale
<preparable dynamic update statement>positioned>::=
UPDATE[<table name>]
SET<set clause>[{<comma><set clause>}]
WHERE CURENT OF<cursor name>.
Comentariu:
Uite punctul trecut.

Dac s comparm atent sursele SQL dinamic SGBD Oracle v.6 i standartul SQL/92,
atunci vom vedea c oracle practic se include n standart, dac nu vom socoti cteva deosebiri
sintactice i(ceea ce-i mai principal) stilul diferit de lucru cu descriptorii. Se presupune c cam
aceeai situaie este i n celelalte SGBD ce conin SQL dinamic.

17.19. Lista noilor posibiliti SQL-3

17.19. Lista noilor posibiliti SQL-3
n standartul SQL/92, n comparaie cu SQL/89, limbajul a fost lrgit, n mod principal,
cfantitativ, cu toate c aceste lrgiri cantitative au fost ndeajuns pentru ca standartul SQL/92 s
nu fie realizat complet pn acum n SGBD comerciale. Deoarece SQL/92 nu satisfcea o mare
parte de sugestii, adresate limbajului SQL, a fost formt un comitet nou, care trebuia s aleag
standartul limbajului cu lrgiri calitative. Limbajul SQL-3 nc nu este format complet, multe
aspecte se mai consult. De aceea ctre lista posibilitilor adus aici ca exemplu trebuie s ne
adresm ca la una iniiatoare.

17.19.1. Tipurile de date
Setul tipurilor de date implementate se propune de lrgit prin tipurile BOOLEAN i
ENUMERATED. Cu toate c din cauza susinerii valorilor nedeterminate limbajului SQL i este
recomandat utilizarea logicii tridimensionale, tipul BOOLEAN conine doar dou valori
posibile: TRUE i FALSE. Pentru afiarea valorii unikown se recomand utilizarea lui NULL,
ceea ce-i desigur nu chiarbine. Tipul de enumeraie ENUMERATED are proprieti
asemntoare proprietilor tipului de enumeraie n limbajele de programare.
S-au lrgit posibilitile de lucru cu valorile nedeterminate. A aprut operatorul nou
CREATE NULL CLASS, ce permite introducerea setului enumerat de valori nedeterminate. La
determinarea domeniului putem arta numele clasei valorilor nedeterminate, apariia crora este
permis n coloanele, legate de acest domeniu. Sensul fiecrei valori nedeterminate se
nterpreteaz la nivelul utilizatorilor.
Se propune includerea n limbaj a posibilitilor de utilizare a tipurilor de date
determinate de utilizator. Se vor ivi posibiliti de a determina tipuri de date abstracte, cu o
sistem intern complicat pe baza posibilitilor tradiionale de agregare i structurizare ca
LIST, ARRAY, SET, MULTISE i TUPLE, de asemenea i posibilitile de determinare a
tipurilor obiect prin metode corespunztoare n stilul de apropiere obiect-orientat.
Apare posibilitatea utilizrii principiului de motenire a proprietilor tabelului
existent(supertabelului) la determinarea tabelului nou(subtabelului). Subtabelul va moteni de la
supertabel toate determinrile coloanelor i a cheii primare. Alt posibilitate de a crea tabelul

asemntor cu cel existent n sensul c tabelul nou va moteni determinrile crorva coloane a
tabelului existent.

17.19.2. Careva alte proprieti a lui SQL-3
Una din problemele de realizare a lui SQL n totdeauna era problema de determinare a
modificrii legturilor. Dac configuraia include legtura de tip general, atunci teoretic este
imposibil de determinat, putem noi s interpretm la fel operaiile de noire a aa configuraie.
ns exist cteva clase principale de legturi, care preventiv sunt schimbtoare. n SQL-3 se
propune de a determina aceste clase cu ajutorul construciilor sintactice speciale.
n sfrit apare posibilitatea de determinare a trigherelor ca combinaii de specificare a
actului i a ciunii. Actul se determin ca SQL-procedur, n care se pot utiliza ct operatori SQL,
att i un rnd de construcii dirijatoare. n realitate, acest mecanism este foarte aproape de cel din
Oracle v.7.
Ct despre dirijarea cu tranzaciile, are loc ntoarcerea la ideile vechi System R despre
posibilitatea instalrii punctelor de salvare(savepoints) n interiorul tranzaciilor. n operatorul
ROLLBACK putem specifica identificatorul punctului de salvare instalat mai devreme, i atunci
va avea loc ntoarcerea tranzaciei nu ctre nceputul su, dar ctre acest punct de salvare.
Deci, n SQL-3 putem atepta multe posibiliti interesante i de folos. ns, chiar
proiectele din timp ale standartului inclu de dou ori mai multe pagini dect standartul SQL/92.
De aceea este greu de ateptat o realizare rapid a acestui standart dup admiterea lui(muli n
genere se ndoiesc de faptul c acest standart va fi vre-o dat realizat).

Compilatorii SQL

Compilatorii SQL
Lecia 18. Compilatorii SQL. Problemele Optimizrii
Vorbind despre optimizarea adresrilor n SGBD relaionale, se are n vedere aa un tip
de prelucrare a adresrilor, cnd pe baza configuraiei iniiale a adresrii, pe baza creerii lor, se
elaboreaz planul de produceri a execuiei adresrii, fiind cel mai optimal din structurile de
dirijare existente n baza de date. Creerile corespunztoare a configuraiei iniiale a adresrii se
efectuieaz de componenta special a SGBD de ctre optimizator i optimizarea planului
adresrii, efectuat de optimizator, poart caracter condiional: planul este optimizat n
dependen de criteriile, declarate n optimizator.

18.1. Schema de prelucrare a aresrii

18.1. Schema de prelucrare a aresrii
Ne putem nchipui c prelucrarea adresrii ctre sistem este alctuit din fazele, artate
mai jos.
n prima faz adresarea, adresat n limbajul adresrilor, se supune analizei lexicale i
sintactice. n acest timp mse creeaz configuraia sa intern, ce reflect structura adresrii i care
conine informaia ce caracterizeaz obiectele bazei de date artate n adresare(relaii, cmpuri,
constante). Informaia despre obiectele pstrate n baza de date se alege din cataloagele BD.
Configuraia intern a adresrii se formeaz i se utilizeaz n stadiile urmtoare de prelucrare a
adresrii. Forma configuraiei interne trebuie s fie comod pentru urmtoarele creeri
optimizaionale.
n faza a doua, adresarea n configuraia sa intrern se impune optimizrii logice. Se pot
utiliza diferite creeri, ce mbuntesc configuraia iniial a adresrii. Printre creeri pot fi i
creeri echivalente, dup utilizarea crora se primete configuraia intern, semantic echivalent
celei iniiale(de exemplu, adresarea adresrii ctre o form conic). Creerile pot fi i semantice:

configuraia primit nu este echivalent semantic cu cea iniial, dar se garanteaz c rezultatul
execuiei adresrii coincide cu rezultatul adresrii n form iniial, la respectarea limitelor
integritii, existente n baza de date. Dup execuia fazei a doua de prelucrare a adresrii,
configuraia sa intern rmne neprocedurat, cu toate c ntr-o oarecare msur, este mai
efectiv ca cea iniial.
A treia etap de prelucrare a adresrii const n selecie pe baza informaiei, ce o posed
optimizatorul, a setului procedurilor alternative a planurilor de ndeplinire a adresrii date n
dependen de configuraia sa intern, primit n faza a doua. Pentzru fiecare plan se apreciaz
preul execuiei adresrii date. La calculele aprecierii se utilizeaz informaia statistic despre
starea bazei de date accesibil optimizatorului. Din planurile primite se alege cel mai eftin i
configuraia sa intern coincide acum cu adresarea prelucrat.
La etapa a patra, pe configuraia intern a celui mai optimal plan de execuie a adresrii
se formeaz configuraia executabil a planului. Configuraia executabil a planului poate fi o
program n codurile mainii dac ca i n System R, sistemul este orientat spre compilarea
adresrilor n codurile mainii, sau s fie independentmainal, dar cel mai comod de
interpretare dac ca i n cazul Ingres, sistemul e orientat spre interpretarea adresrilor. n cazl
nostru acest lucru nu este principal, cci faza a patra de prelucrare a adresrii nu mai este legat
de optimizare.

18.2. Optimizarea sintactic a adresrii

18.2. Optimizarea sintactic a adresrii
la apropierea sintactic ctre organizarea optimizatorilor adresrilor la etapa optimizrii
logice au loc creeri logice a configuraiei interne a adresrii, carembuntesc configuraia
intern iniial n dependen de strategiile fixate a optimizatorului. Caracterul mbuntirilor
e legat de specificul organizrii generale a optimizatorilor, n special de deosebirile procedurii de
cutare a planurilor procedurale posibile a adresrilor, executate n faza a treia de prelucrare a
adresrii.
De aceea e greu de format caracteristica i clasificarea ntreag a metodelor de optimizare
logic. Ne limitm la careva utilizri i vom privi o clas de creeri logice important, care se
ating de ntrebri complicate, exprimate n limbajul SQL.

18.2.1. Creerile logice simple a adresrilor
Clasa urmtoare de creeri logice a adresrilor include crearea obiectelor ce intr n
condiia de selecie, ctre configuraia canonic. Se au n vedere predicatele ce conin operaiile
de comparaie a valorilor simple. Aa predicat are tipul expresie afirmativ or expresie
aritmetic, unde or este operaie de comparaie, dar expresiile logice n prile stnga i
dreapta vor deine numele cmpurilor relaiilor i constante(n limbajul SQL, printre constante se
pot ntlni i nume de variabile a programului din valorile crora devin cunoscute nu numai la
execuia real a adresrii).
Configuraiile canonice pot fi diferite pentru diferite tipuri de predicate. Dac predicatul
include un singur nume a cmpului, atunci configuraia lui canonic se permite de exemplu, de
avut n vedere numele cmpului or expresia aritmetic constant(aceasta e forma predicatului
predicat simplu de selecie - e foarte util pentru execuia urmtoarei etape de optimizare). Dac
configuraia iniial a prdicatului are tipul (a+5)or 36?(cu litere mici se indic numele
variabilelor, iar cu litere mari numele cmpurilor relaiilor), atunci configuraia canonic a
acestui predicat poate fi or36/(a+5)?. Dac predicatul include fix dou nume de cmpuri a
duferitor relaii(sau a dou diferite intrri a unei relaii), atunci configuraia lui canonic poate
avea tipul numele cmpului or expresie aritmetic, unde expresie aritmetic din partea stng
include numai constante i al doilea nume a cmpului(acesta de asemenea este forma util pentru

execuia urmtorului pas de optimizare predicatul de alipire; este deosebit de important n
cazul ecvialipirii, cnd or este egalitate). Dac n configuraia iniial predicatul are tipul 5(A-a(B
or b), atunci configuraia sa canonic este A or(b+a(B)/5.
n sfrit pentru predicatele de tip mai general are sens de a aduce predicatul la
configuraia canonic de tipul expresia aritmetic or expresia aritmetic constant, unde
expresia prii drepte i stngi de asemenea sunt aduse la configuraia canonic; de exemplu, n
expresii sunt deschise parantezele i se execut ordinea lexicografic. n continuare putem face
citarea expresiilor aritmetice comune n diferite predicate a adresrii. Aceasta este justificat
cci, n timpul execuiei adresrii calculului expresiilor aritmetice se va face la selecia fiecrui
cortej urmtor, adic un num potenial mare de ori. La aducerea predicatelor la o configuraie
canonic se pot calcula expresiile constante i se pot arunca negaiile logice. Clasa urmtoare a
ceerilor logice este legat de aducerea la o form canonic a expresiei logice, ce indic condiiile
de selecie a adresrii. De regul se utilizeaz forma normal disjunctiv, ct i forma normal
conjunctiv. Alegerea formei canonice depinde de organizarea general a optimizatorului. La
conducerea condiiei logice ctre o configuraie canonic, putem executa cutarea predicatelor
comune(ele pot exista de la nceput, dar pot aprea i dup aducerea predicatelor la tipul canonic
sau la procesul normalizrii condiiei logice) i putem simplifica expresia logic pe contul, de
exemplu, codul conjunciei predicatelor reciproc opuse. Fragmentul expresiei logice (A>5)
poate fi nlocuit cu FALSE. Se admit i simplificri mult mai detepte. De exemlu
fragmentul expresiei logice (A>B)AND(B=5) poate fi nlocuit cu (A>5). Aa simplificri
pot fi importante pentru prelucrarea de mai departe a adresrii: n adresarea cu condiie logic de
tipul ntiu se propunea alipirea relaiilor; dup creare adresarea nu cere alipire.

18.2.2. Crearea adresrilor cu schimbarea ordinii operaiilor relaionale
n optimizatoarele tradiionale sunt rspndite creeri logice, legate de schimbul ordinii de
execuie a operaiilor relaionale. Ca exemplu a acestei reguli de creare n termenii algebrei
relaionale poate fi urmtoarea(A i B nume de relaie):
(A JOIN B) WHERE restriction on A AND restriction on B este echivalent cu
expresia:
(A WHERE restriction on A)JOIN(B WHERE restriction on B).
Aici JOIN este operator relaional a alipirii naturale a relaiilor. Dar WHERE restriction
operatorul de limitare a relaiei A n dependen de predicatul restriction.
Cu toate c multe sisteme relaionale au limbaje de adresare, bazate pe algebra
relaional, regulile de creare a expresiilor algebrice pot fi utile n alte cazuri. Destul de des se
utilizeaz algebra relaional n calitate de baz a configuraiei interne a adresrii. E clar c dup
aceasta putem executa i creeri algebrice.
n parte, exist apropieri, legate de crearea ctre forma algebric a adresrilor n limbajul
SQL. Putem accentuam dou cauze principale de recreare a adresrilor n SQL ctre forma
algebric. O cauz mai puin important poate fi tinderea de a utiliza algebra relaional n
calitate de interfa interioar unificat la SGBD relaional. Aceasta este rspndit la utilizarea
mailor specializate a bazelor de date, pe baza crora se realizeaz diferite interfee de acces la
bazele de date.
Interfaa mainei bazelor de date trebuie s fie unificat(de exemplu s fie algebric), iar
celelalte intefee, inclusiv interfaa de baz a SQL, se aduc la cea algebric.
A doua cauz, foarte important n contextul problemelor optimizrii, este faptul c
algebra relaional este mai simpl dect limbajul SQL. Crearea adresrii ctre forma algebric
uureaz aciunile urmtoare a optimizatorului n selecia planurilor optimale. Deci un
optimizator dezvoltat de adresri a sistemului, orientat pe SQL trebuie s desting toate planurile
de executare posibil a orice adresare, dar spaiul de cutare a acestor planuri, n general, este
foarte mare. n fiecare optimizator concret se utilizeaz evristica sa pentru micorarea spaiului

de cutare. Unele, posibil cele mai optimale planuri, nu vor fi nici o dat analizate. Crearea
logic a adresrii n SQL ctre configuraia algebric micoreaz spaiul cutrii planurilor de
execuie a adresrii cu garania faptului, c planurile optimale nu vor fi pierdute.

18.2.3. Aducerea adresrilor cu subadresri incluse la subadresri cu alipiri
Deosebirea de baz a limbajului SQL de limbajul alebrei relaionale este posibilitatea
mobilizrii n condiia logic predicaele ce conin subadresri incluse. Adncimea includerii nu
se limiteaz de ctre limbaj, adic poate fi liber. Predicatele cu subadresri incluse, la posesia
sintaxei generale, pot avea o semnatic diferit. Unicul algoritm de execuie a adresrii comun
pentru toate semanticile posibile a subadresrilor incluse este calculul subadresrii incluse de
fiecare dat la calculul valorii preparatului. De aceea tinderea ctre aa creare a adrersrii, ce
alipete predicate cu subadresri incluse, care va face semantica subadresrii mai clar, dnd n
aa mod pe viitor optimizatorului posibilitatea de a alege modul de execuie a adresrii, care cel
mai mult corespunde semnaticii subadresrii.
Mai jos R este a i-a relaie a bazei de date;Ck-k cmpul(coloana) relaiei.
Predicatele, permise n adresrile limbajului SQL, se pot mpri n urmtoarele patru
grupe:
- Predicate simple. Acestea sunt predicatele de tipul Ri Ck or X, unde X constant
sau lista constantelor i or operatorul comparaiei scalare sau operatorul de control a
apartenenei mulimii.
- Predicate cu subadresri incluse. Acestea sunt predicatele de tipul Ri Ck or Q, unde Q
este blocul adresrii, iar or este la fel ca i la predicatele simple. Predicatul poate s
aib i tipul Q or Ri Ck. n acest caz operatorul de apartenen mulimii se nlocuiete
cu CONTAINS sau DOES NOT CONTAIN. Aceste dou forme sunt simetrice. Este
de ajuns de analizat doar una din ele.
- Predicatele de alipire. Acestea sunt predicatele de tipul Ri Ck or Rj Cn, unde Ri!=Rj
iar or este operatorul de comparaie scalar.
- Predicatele de divizare. Acestea sunt predicatele de tipul Qi or Qj, unde Qi i Qj
blocurile adresrilor, iar or poate fi operatorul de comparaie scalar sau operatorul de
control a apartenenei mulimii.
Aceast clasificare este o simplificare a situaiei reale n SQL. Nu se anaizeaz
predicatele de alipire de tip general, ce includ expresii aritmetice cu cmpurile a mai mult de
dou relaii.
Configuraia canonic a adresrii pentru n relaii se numete adresare ce conine n-1
predicate de alipire i care nu conine predicate cu subadresri incluse. De fapt forma canonic
este configuraia algebric a adresrii.
Mai jos se d un exemplu de dou forme canonice de adresare cu predicate de tip diferit.
Aceeai tehnic exist i pentru alte tipuri de predicate.
SELECT Ri Ck FROM Ri WHERE Ri Ck IS IN
SELECT Ri Cm FROM Rj WHERE Ri Cn=Rj Cp
este echivalent cu
SELECT Ri Ck FROM Ri, Rj WHERE
Ri. Rj Cm AND Ri Cn=Rj Cp
SELECT Ri Ck FROM Ri WHERE Ri Ck=
SELECT AVG(Rj Cm) FROM Rj WHERE Rj Cn=Ri Cp
este echivalent cu
SELECT Ri Ck FROM Ri, Rt WHERE
Ri Ck = Rt Cm AND Ri Cp=Rt Cn
-R(CCn)=SELECT Rj Cp, AVG(Rj Cn) FROM Rj
GROUP BY Rj Cp.

Mulimea de tipuri a aa creeri, se datorete faptului, c optimizatorul primete
posibilitatea de selecie a unui numr mai mare de metode de execuie a adresrilor.
Des metodele de execuie aprut dup care sunt mai efective, ca cele utilizate n
optimizatorul tradiional System R.
La utilizarea n optimizator a adresrilor de aa apropiere nu-i neaprat de format creeri
formale a adresrilor. Optimizatorul trebuie, ntr-o msur mai mare, s utilizeze semantica
adresrii prelucarate acum, dar n ce mod ea va fi recunoscut, aceasta-i ntrebare ce ine de
tehnic.
S observm, c n apropierea descris de noi sunt cteva incorectitudini fine n
semantic.
Sunt cunoscute metode modificate, corectate, ns ele sunt prea complicate tehnic, pentru
a le analiza la leciile noastre.

18.3. Optimizarea semnatic a adresrilor

18.3. Optimizarea semnatic a adresrilor
Creerile analizate a se bazeaz pe semantica limbajului adresrilor, n ele nu se
analizeza semantica BD, creia i se adreseaz adresarea.
Orice creare poate fi format indiferent de faptul, care baz de date se are n vedere. n
realitate, n fiecare baz de date relaional adevrat, se pstreaz i o oarecare informaie
semantic, ce de exemplu, determin integritatea bazei de date.
Dac s vorbim despre bazele de date, menionate n System R, atunci aceast informaie
se pstreaz n registrele de sistem a abzei de date n calitate de limite date a integritii.
Deoarece SGBD garanteaz integritatea bazei de date, atunci limitele integritii pot fi privite ca
nite axiome, n mprejurarea crora se formeaz adresarea ctre baza de date.

18.3.1. Crearea adresrilor pe baza informaiei semantice
n calitate de exemple iniiale de creare a adresrilor pe baza informaiei semantice s
analizm apropierile SGBD cunoscute System R i INGRES ctre asigurarea lucrului bazei de
date prin configuraii. Aceste creeri nu au fost orientate ctre o optimizare a adresrilor, dar au
fa de aceasta o legtur reciproc.
Configuraia bazei de date(new) n terminalele limbajelor SQL i QUEL aceasta este
adresarea enumerat a registrelor ce reprezint din sine din punct de vedere a utilizatorului,
acelai obiect a bazei de date ca i relaia. Configuraiile pot fi utilizate n adresri ca i
relaiile memorabile(cu limite n utilizarea lor la operatorii de modificare a bazei de date).
Semantica configuraiei cere ca aceasta s fie precis: n momentul execuiei adresrii
pentru configuraie, informaia primit trebuie s coincid strii curente a prii memorabile a
bazei de date. execuia adresrii pentru configuraie cere materializarea ei, adic calculul relaiei,
determinat de adresare, care-i legat de configuraie.
Apropierea System R i Ingres este bazat pe aceea c configuriile se pstreaz n
registrele bazei de date n form intern, primit n urma execuiei analizei gramatice (de
asemenea a optimizrii logice) a adresrii corespunztoare.
n timpul prelucrrii adresrii pentru configuraie, naintea execuiei fazei optimizrii
logice, are loc contopirea formelor interne a adresrii i a configuraiei.
Se formeaz o form intern nou creat i pentru ea are loc prelucrarea de mai departe a
adresrii, inclusiv optimizarea logic i selecia planului optimal de execuie a adresrii. n aa
fel, optimizatorul primete mai mult informaie despre adresarea dat i poate lua hotrri mult
mai corecte.
De exemplu:
Fie c configuraia este determinat ca:

DEFINE VIEW V(C2)AS
SELECT C1 FROM R WHERE C2>6
Adresarea se formuleaza in felul urmator:
SELECT C2 FROM V WHERE C2<6.
Dac adresarea s-ar fi compilat cu scopul materializrii configuraiei, s-ar fi ales metoda
execuiei ei, bazat pe scanarea ciclic V cu selecia cortejelor, ce stisfac condiiei. Adresarea
aa s-ar fi executat, pentru c n cele din urm s dea un rezultat gol. ns la contopirea formelor
interne a adresrii i configuraii am fi primit o form intern, echivalent adresrii SELECT C1
FROM R WHERE C1<6 AND C1>6.
n faza optimizrii logice s-ar putea determina c aceast adresare este echivalent
adresrii:
SELECT C1 FROM R WHERE FALSE, de unde ar rezulta c rezultatul adresrii este
gol.
Din mulimea de cazuri acest caz de prelucrare a adresrilor pentru configuraiile
bazelor de date permitea primirea execuiei unei adresri mult mai efective pe baza oferirii
utilizatorului a mai mult informaie. Aceeai ideie st la baza optimizrii semantice a
adresrilor: utilizarea informaiei semantice la optimizarea adresrii, informaiei pstrate n baza
de adte indiferent de adresarea dat.
Un alt exemplu de creare a adresrilor, ce au legtur cu optimizarea, este crearea
adresrilor pentru modificarea bazei de date cu scopul satisfacerii limitelor integritii existente
n baza de date. Aceast apropiere, pentru prima dat a fost utilizat n SGBD INGRES, dar se
utuilizeaz i n alte sisteme, de exemplu System R.
Limit a integritii se numete expresia logic, pstrat n registrele bazei de date,
alctuit din predicate pe obiectele bazei de date. baza de date se afl n stare ntreag, dac se
satisfac toate limitele integritii date.
Dac se adreseaz o adresare pentru modificarea bazei de date, ce include limitele
integritii, satisfacerea crora se cere la execuia oricrei modificri, atunci putem aduga
limitelor predicatele corespunztoare pentru condiia logic a adresrii.
Fie c baz de date, ce caracterizeaz structura organizrii, e alctuit din relaiile EMP i
DEPT. n relaia EMP se nregistreaz organizaiile muncitoreti. Schema acestei relaii
EMP(EMP#,EMPNAME,DEPT#); cmpul EMP# conine numrul unic a muncitorului; cmpul
EMPNAME numele muncitorului, iar DEPT# - numrul seciei organizaiei n care lucreaz
acest muncitor. Relaia DEPT pstreaz informaia despre secii i are schema: DEPT(DEPT#,
EMPTCOUNTS) unde n cmpul EMPTCOUNTS se pstreaz numrul total de muncitori a
acestei secii. Fie c este dat limita integritii ASSERT B IMMEDIATE ON
EMP:EMP.DEPT#=6.
Aceast limit nseamn interzicerea introducerii tergerii i modificrii cortejelor n
relaia EMP cu valoarea cmpului DEPT# diferit de 6. Fie c se prelucreaz adresarea pentru
tergerea cortejului DELETE EMP WHERE EMPNAME =Brown.
Dac la compilarea adresrii nu inem cont de prezena limitei integritii, atunci metoda
corect de execuie a aa adresare va fi: s alegem cortejele la care valoarea cmpului
EMPNAME este Brown; de controlat satisfacerea urmtorului cortej cu limita integritii i
dac controlul este satisfctor s se tearg cortejul.
Dac limitele integritii se iau n vedere n timpul compilrii, atunci putem contopi
formele interne a adresrii i limitele integritii corespunztoare, iar apoi de prelungit
optimizarea n comun. n cazul nostru dup contopire se formeaz forma intern, echivalent a
adresrii.
DELETE EMP WHERE EMPNAME=Brown AND DEPT#=6
La execuia a aa tip de adresare nu va fi nevoie de apelurile adugtoare a controlului
limitelor integritii de tipul 2, cci ele toate de acum sunt incluse n condiia logic de execuie a

operaiei de tergere. n afar de aceasta optimizatorul primete o libertate n alegerea modului
de execuie a adresrii, de exemplu, dac seciile sunt puine i pentru relaia EMP se menine
indexul pe cmpul DEPT#, atunci, modul cel mai optimal de execuie a adresrii va fi scanarea
relaiei prin index DEPT# cu condiia DEPT#=6 cu tergerea oricrui cortej ales n aa mod, cu
valoarea cmpului EMPNAME egal cu Brown. n aa fel, metodele ce creeaz adresareas nu
sunt ndreptate n special spre optimizare, ele pot ajuta la o execuie mai efectiv a adresrii.
Eficacitatea execuiei adresrii se poate ridica pe contul cunotinelor utilizate, pstrate
independent n BD.
Exemplele studiate ne arat c ideiea optimizrii semantice, n principiu, nu este nou. Se
posed i diferena proincipal dintre adresrile vzute mai sus i cele care se creeaz la
optimizarea semantic. Deosebirea de baz const n aceea, c atunci cnd are loc contopirea
formei interne a adresrii cu forma intern a configuraiei sau cu formele interne a limitelor
integritii, suntem obligai s utilizm total i neaprat informaia extern independent de faptul,
va ajuta aceasta la optimizarea adresrii: condiia de selecie a configuraiei trebuie s fie total
adugat prin AND ctre condiia de selecie a adresrii; aceeai se refer i la setul de condiii
logice a limitelor integritii. De altfel semantica adresrii pentru configuraie sau operatorul de
modificare a BD va fi nclcat.

18.3.2. Utilizarea informaiei semantice la optimizarea adresrilor
optimizarea semantic se bazeaz pe posesia de ctre BD a informaiei semantice ce nu
este neaprat de utilizat la prelucrarea adresrilor, dar utilizarea creia poate duce la o execuie
mult mai optimal. Dac optimizarea semantic are de lucru doar cu cunotinele prezentate n
forma limitelor integritii BD, atunci la optimizarea semantic se creeeaz o mulime de
configuraii interne a adresrii; la fiecare creare se utilizeaz un oarecare set de limite a
integritii. Dac, de exemplu, n BD sunt determinate dou limite a integritii A i B cu
condiiile logice F1 i F2 i se prelucreaz adresarea cu condiia de selecie F atunci, n mersul
optimizrii semantice vor fi primite configuraiile interne echivalente adresrilor cu condiiile F,
F AND F1, F ANDF2 i F AND F1 AND F2. Fiecare din configuraiile interne primite se
impune unei prelucrri totale pe parcurs, inclusiv optimizarea logic i alegerea planului optimal
de execuie; din planurile primite(toate ele sunt echivalente semantic, adic au acelai rezultat) se
alege cel mai eftin care i va deveni planul real de execuie a adresrii iniiale.
Pentru utilizarea raional a optimizrii semantice este comod de a reprezenta limitele
integritii BD n form implicativ. Atunci se va putea obine o ordine mai gndit a creerilor.
Fie, de exemplu, n baza noastr de date despre structura organizaiei, relaia EMP e lrgit de
cmpurile STATUS i SALARY. Valorile cmpului STATUS caracterizeaz funcia
lucrtorului, iar cmpull SALARY salariul su. Poate fi specificat limita integritii exprimat
prin aceea, c salariul ce ntrece 40000 poate fi specificat numai efilor de secii:
ASSERT A ON EMP :
IF SALARY >40000 THEN STATUS=MANAGER
Fie c se prelucreaz adresarea:
SELECT EMPNAME STATUS FROM EMP WHERE SALARY=20000
Dac s nu considerm caracterul implicativ a limitei integritii, atunci, dup regulile
generale, va avea loc contopirea configuraiilor interne a adresrii i limitei integritii, care nu
va da nimic. Dar dac vom privi limita integritii ca regul a crerii, dar partea stng a
implicaiei ca condiie de utilizare a regulii, atunci contopirea nu va avea loc, ci n acz general va
economisi timpul prelucrrii adresrii. Dar pentru adresarea
SELECT EMPNAME, STATUS FROM EMP WHERE SALARY>40000.
regula creeriieste utilizabil i aduce la adresarea semantic echivalent:
SELECT EMPNAME, STATUS FROM EMP WHERE STATUS=MANAGER
execuia creia poate fi cu mult mai efectiv.

Dup crearea adresrii, n corespundere cu careva reguli, ctre configuraia primit poate
fi utilizat i alt regul, etc. Este posibil operaia ciclurilor de creare. Problema construirii
setului ntreg de configuraii semantic echivalente pe baza setului de reguli dat este foarte
complicat. Rezolvarea prcis a acestei probleme poate cere cheltuieli, ce sunt mai mare ca cele
pentru execuia adresrii n plan mai optimal. De aceea este nevoie de a utiliza algoritmi
euristici, ce ngusteaz spaiul cutrii, adic care indic condiia de ncetare a generaie a noilor
configuraii.euristica se bazeaz pe minimizarea sumei externe a costului optimizrii semantice
i execuiei adresrii.
Ca exemplu de euristic aspr poate fi urmtorul: optimizarea se face pn atunci, pn
cnd cheltuielile pentru ea nu vor ntrece preul celui mai efectiv din toate planurile gsite de
execuie a adresrilor.

18.4. Selecia i aprecierea planurilor alternative de execuie a adresrilor

18.4. Selecia i aprecierea planurilor alternative de execuie a adresrilor
Creerile optimizatoare, studiate mai sus, lsau configuraia intern a adresrii
neprocedural.
Configuraia procedural sau plan de execuie a adresrii se numete o aa configuraie a
ei n care este detaliat ordinea de execuie a operaiilor de acces la BD de nivel fizic. De regul,
n SGBD relaionale se depune subsistemul de dirijare cu datele la nivel fizic. n System R aa
sistem se numete RSS(Relational Storage System) i asigur interfaa simpl, ce permite analiza
consecutiv a cortejelor relaiilor ce satisfac condiiilor date pentru valorile cmpurilor, cu
utilizarea indexilor sau a scanrilor simple a paginilor BD. n afar de aceasta, RSS permite
crearea fiierelor temporale sortate i introducerea, tergerea i modificarea cortejelor
individuale. Aa fel de subsisteme mai calr sau mai puin clar se distinct n fiecare SGBD de aa
fel. Este clar, c pn la execuia adresrii este nevoie de crearea configuraiei sale procedurale.
Deoarece acesta se selecioneaz diferit, este nevoie de ales dintre planurile alternative a
adresrilor unul n dependen de careva trighere. De regul, criteriul de selecie a planului de
execuie a adresrii este minimizarea costului execuiei.
Cu toate acestea, n timpul prelucrrii adresrii la stadiul urmtor dup optimizarea
logic, se soluioneaz dou probleme. Prima problem: reeind din configuraia intern a
asdresrii i informaiei ce caracterizeaz structura de dirijare a bazelor de date(de exemplu
indexii), de ales setul planurilor potenial posibile de execuie a adresrii date. problema a doua:
de apreciat preul execuiei adresrii n dependen de fiecare plan alternativ i de ales planul cu
preul cel mai redus.

18.4.1. Generarea planurilor
La o apropiere tradiional ctre organizarea optimizatorilor ambele probleme se
soluioneaz pe baza algoritmilor fixai reglementai n optimizator. Optimizatorul poate fi
utilizat i pentru faptul c limitarea oricrei relaii, n dependen de predicatul dat, poate fi
executat pe calea oricrei analize consecutive a relaiei. n aa fel adresarea
SELECT EMPNAME FROM WHERE
DEPT#=6 AND SALARY>15000
poate fi executat pe baza scanrii consecutive a relaiei prin indexul I1, determinat pe
cmpul DEPT#, cu condiia de acces ctre indexul DEPT#=6 i cu condiia de selecie a
cortejului SALARY>15000; n sfrit, scanrii relaiei prin indexul I2, determinat pe cmpul
SALARY, cu condii a de acces la indexul SALARY>15000 i condiia de selecie a cortejului
DEPT#=6.
Analog se fixeaz strategiile de execuie a operaiilor mai complicate conexiuni
relaionale a relaiilor, calculul funciilor de agregat pe grupele cortejurilor relaiilor .a. de

exemplun n System R pentru ecviconexiuni a dou relaii se utilizeaz dou strategii de baz:
metoda ciclurilor implementate i metoda sortrii cu topiri.
Componenta optimizatorului, care genereaz planurile executabile a adresrilor arte o
organizare complicat; generarea planului execuiei unei adresri complicate este un proces
momentan, n mersul cruiea se iau n consideraie proprietile, ce se creeaz n timpul execuiei
adresrilor dup planul dat a obiectelor temporale a BD.
De exemplu, fie c adresarea e dat pentru trei relaii i n adresare sunt dou predicate de
legtur:
SELECT R1.C1, R2.C2, R3.C3 FROM R!, R, R# WHERE
R1.C4=R2.C5 AND R2.C5=R3.C6.
Atunci dac n planul adresrii se selecteaz ordinea execuiei legturilor nti R1 cu R2,
iar apoi relaia temporal primit R3 i pentru execuia primei conexiuni se alege metoda
sortrilor cu contopiri, atunci relaia temporal va fi sortat din timp dup C5 i de o sortare nu
va fi nevoie dac i a doua legtur se va executa prin aceeai metod.
Componenta optimizatorului ce duce la crearea mulimii de planuri alternative a
execuiei adresrii se bazeaz pe strategii de mprire a adresrii n componente elementare i pe
strategiile de execuie a componentelor elementare. Prima grup de strategii determin spaiul de
cutare a planului optimal de execuie a adresrii, a doua este ndreptat spre aceea c n acest
spaiu ntr-adevr s se gseasc planuri optimale de execuie a adresrii. Cheiea ctre asigurarea
execuiei efective a adresrii complicate este posesia strategiilor efective de execuie a
componentelor elementare. Aceasta este o ntrebare important, dar nici noi nu o analizm:
optimizatorul adresrilor utilizeaz strategiile implementate. S analizm problema mai actual a
optimizatorului selecia celui mai bun plan de execuie a adresrii din mulimea planurilor
alternative.

18.4.2. Aprecierea costului planului adresrii
Dup generarea mulimii de planuri a execuiei adresrii pe baza strategiilor relaionale
de mprire i a strategiilor de execuie a operaiilor elementare trebuie de ales un singur plan, n
conformitate cu care va avea loc execuia adresrii. n caz de selecie greit adresarea se va
efectua neefectiv.
n primul rnd trebuie de determinat, ce se subnelege sub eficacitatea execuiei
subadresrii. Aceast subnelegere depinde de specificul mediului operaional a SGBD. n
unele condiii putem considera, c eficacitatea execuiei adresrii se determin de timpul
execuiei sale, adic de reactivitatea sistemului n dependen de sistemul prelucrat de ea. n alte
condiii determinativ este posibilitatea general de permisiune a sistemului n dependen de
amestecul adresrilor executarea lor n paralel. Atunci ca msur a eficacitii putem socoti
numrul de resurse a sistemului, ce trebuiesc pentru execuia lui, .a.
Urmnd tehnologia dat, , vom vorbi despre costul planului de execuie a adresrii,
determinat de resursele procesorului i unitile memoriei externe, care se dau la execuia
adresrii.
n SGBD relaionale se destinge subsistemul de dirijare cu accesul ctre datele n
memoria extern(RSS a System R).
Tradiional, datele n memoria extern se pstreaz sub form blocat, baza de adte
ocup un set oarecare de blocuri a unui sau mai multe volumuri de diiscuri. Se presupune, c
sursele de acces la la blocurile memoriei externe creeaz mai puine cheltuieli. De regul
sistemele de dirijare cu accesul ctre date n memoria face buferizarea blocurilor bazei de date n
memoria operativ. Fiecare bloc se pstreaz n unul din buferele SGBD pn cnd nu va fi scos
de alt bloc a BD. Aceast deosebire a SGBD este de baz pentru ridicarea eficacitii generale a
sistemului dar nu se scoate(n afar de cazul particular dar important) la aprecierea costurilor
planurilor de execuie a adresrilor. n orice caz, componenta costului de execuie a adresrii,

legat de resursele memoriei externe, depinde monoton de numrul blocurilor memoriei externe,
accesul ctre cre va trebui pentru execuia adresri.
Din alt parte, numrul blocurilor memoriei externe accesul ctre care trebuie la execuia
adresrii, depinde monoton de numrul cortejurilor, atinse de adresare.
Din aceasta rezult importana indicatorului predicatului de linii, ce caracterizeaz partea
cortejurilor relaiei, care satisfac predicatului dat i care se numete nivelul de selecie a
predicatului. Nivelul de selecie a prediactelor simple de tipul R.C or const, unde R.C d numele
cmpului relaiei BD, or operaia de comparaie., dar const - constant, sunt bazele pentru
costurile planurilor adresrilor. Percizia aprecierii nivelurilor de selecie determin precizia
aprecierilor generale i corectitudinea alegerii planului optimal a adresrii.
Nivelul selectivitii predicatului R.C or const depinde de tipul operaiei de comparaie,
introducerea constantelor i rspndirea valorilor cmpurilor C a relaiei R n BD. Primii doi
parametri de selecie pot fi cunsocui la efectuarea aprecierilor, dar rspndirile reale a valorilor
cmpurilor relaiilor, de regul nu sunt cunoscute. Exeist un ir de apropieri ctre relaiile de
rspndire pe baza informaiei statistice. Vom analiza mai apoi cele mai interesante dintre ele.
Dac este cunoscut nivelul selectivitii a predicatului limitei relaiei, atunci este cunoscut
puterea relaiei rezultante(de regul puterile relaiilor pstrate sunt cunoscute la prelucrarea
adresrii). Dar n formulele de apreciere se iau n consideraie numrul de schimburi cu
memoria extern, care-i cerut pentru execua adresrii. Desigur, numrul cortejurilor este preul
superior a numrului nevoit de schimburi, dar acest cost poate fi foarte ridicat. Totul depinde
de rspndirea cortejurilor pe blocurile memoriei externe. ntr-un rnd de costuri putem primi un
pre mai precis a numrului de blocuri. n sfrit, pentru adresrile complicate, ce includ de
exemplu , conexiunea a mai mult de dou relaii, este nevoie de apreciat dimensiunile relaiilor
intermediare ce apar n procesul execuiei adresrii. Pentru a aprecia puterea rezultatului a
conexiunii a dou relaii, trebuie de tiut nivelul de selectivitate a predicatului de conexiune n
legtur cu crearea direct a relaiiloroperanzilor. n caz general, este imposibil de determinat
pe baza informaiei statistice nivelul de selectivitate a aa un prediact. De obicei se aplic
aprecieri euristice destul de aspre, cu toate c se propun apropieri, ce asigur o precizie nalt.
Apropierea System R se pazeaz pe dou propuneri de baz a rspndirii valorilor cmpurilor
relaiilor: se presupune c valorile cmpurilor a toate relaiile BD sunt rpndite egal i c
valorile a oricare dou cmpuri sunt rspndite independent. Prima propunere permite de apreciat
selectivitatea predicatelor simple pe baza informaiei sintactice despre BD. Pe a doua
propunere se bazeaz aprecierile numrului de blocuri, n care se gsete numrul cunoscut de
corteje. Aceste dou propuneri sunt obiectul de critic a System R. Ele sunt formate doar cu
scopul simplificrii optimizatorului i nu pot fi lmurite teoretic. Pot fi aduse exemple de BD
pentru care aceste propuneri nu s-au afirmat. n aceste cazuri aprecierile optimizatorului
System R nu vor fi adevrate.
n registrele BD, pentru fiecare relaie R se memoreaz numrul cortejelor n relaia
dat(T) i numrul blocurilor memoriei, n care se afl cortejele relaiei(N); pentru fiecare cmp
C a relaiei se pstreaz numrul diferitor valori a acestui cmp(CD); valoarea memorabil
minimal a acestui cmp(Cmin) i valoarea maximal(Cmax).
La posedarea acestei informaii , lund n consideraie prima propunere a bazei de selecie
a predicatelor simple, se calculeaz simplu(i precis, dac rspndirea este egal). Fie c SEL(P)
este nivelul de selectivitate a predicatului P. Atunci:
SEL(R.C=const)=CD/(CMax-Cmin)
(la rspndire egal nivelul selectivitii a aa predicat nu depinde de valoarea constantei).
SEL(R.C>const)=(Cmax-const)/(Cmax-Cmin), i altele. La aprecierea numrului de
blocuri n care se pot afla cortejele ce satisfac predicatului R.C or const, se deosebesc cazuri de
clasterizare sau neclasterizare a relaiei pe cmpul C. Aceste aprecieri au sens numai la studierea

variantului sacnrii relaiei cu utilizarea indexului pe cmpul C. La studierea relaiei fr
utilizarea indexului va trebui de adresat n totdeauna fix la N blocuri de memorie extern.
Presupunerile despre egalitatea rspndirii valorilor atributelor relaiilor premit de a
aprecia simplu i puterile relaiilo, care sunt rezultatele operaiilor bilocale relaionale i teoriilor
mulimilor pentru relaii.
Aprecierea selictivitii predicatelor se utilizeaz i la aprecierea cheltuirlilor resurselor
procesorului. Se presupune c partea de baz a prelucrrii procesorale are loc n RSS. De aceea
cheltuielile procesorale se msoar prin numrul de adresri i RSS ce corespunde numrului
cortejelor, ce se primesc la scanarea relaiei memorabile sau temporale, adic prin selectivitatea
expresiei logice, alctuit din predicate simple(condiia de selecie a nivelului RSS). Propunerea
despre egalitatea i independena valorilor diferitor cmpuri a relaiei permite uor de apreciat
selectivitatea expresiei logice, alctuit din predicate simple la nivelurile lor de selecie
cunoscute.
ntr-adevr, n System R nu se apreciaz selectivitatea predicatelor n mod direct.
Aprecierea optimizatorului se bazeaz pe informaia statistic despre BD; execuia oricrei
adresri const dintr-o combinaie a ctorva aciuni elementare. Ca exemple de execuii
elemenare pot fi execuia limitei relaiei pe calea scanrii sale prin indexul clasterizat, sortarea
relaiei, conexiunea celor dou relaii sortate mai devreme, .a. aprecierea general a planului de
execuie are loc ntr-un proces iterativ, ncepnd cu aprecierile operaiilor elementare peste
relaiile memorabile.

18.4.3. Aprecierile mult mai precise
S trecem la analiza aprecierilor mai precise a costurilor execuiei planurilor
adresrilor. Aceste adresri le putem diviza n dou clase. La utilizarea metodelor primei clase
optmizatorul pstreaz o structur aspr, analogic structurii optimizatorului SystemR, dar
luarea aprecierilor se bazeaz pe o informaie statistic mai precis, ce caracterizeaz
rspndirea relaiilor.
Metodele clasei a doua sunt mai revoluionare i reiese din faptul c pentru formarea
planurilor de execuie a adresrilor i a aprecierilor lor, optimizatorul trebuie s se satisfac cu o
oarecare informaie, caracteristic pentru o sfer concret a adugrilor. La rezultatul metodei
despre egalitatea rspndirilor valorilor cmpului relaiei trebuie de specificat rspndirea real a
valorilor.
Exist dou metode de baz a aprecierilor de rspndire a valorilor cmpului relaiei:
parametric i bazat pe metoda signaturilor.
Apropierea System R este un caz trivial particular a metodei parametrice de apreciere a
rspndirii orice rspndire se aprecieaz ca fiind egal. ntr-o apreciere mai dezvoltat, s-a
propus utilizarea seriei de rspndiri a lui Pirson pentru aprecierea rspndirii reale a valorilor
cmpurilor relaiei, n care intr rspndirile de la egale la normale. Rspndirea se alege din serie
pe calea calculului crorva parametri pe baz seciilor valorilor reale ntlnite. Exemple a
implimentrii n practic a acestei apropieri nu ne sunt cunoscute.
Metoda aprecierii rspndirii pe baza signaturilor poate fi descris n felul urmtor. Sfera
vaorilor cmpuluise mparte n cteva intervale. Pentru fiecare interval printr-o metod oarecare
se stabilete numrul de valori a cmpului, ce nimeresc n acest interval. n acest interval valorile
se rspndesc dup o lege fixat( de regul se aplic apropierea egal). S analizm dou
apropieri alternative, legate de descrierea signatural a rspndirilor.
La apropierea tradiional, sfera valorilor cmpului se mparte n N intervaluri de mrimi
egale i pentru fiecare interval se socoate numrul valorilor cmpurilor din cortejele relaiiei date,
care nimeresc n interval. S presupunem c EMP este lrgit de nc un cmp AGE, care indic
lista lucrtorului. Fie c de tot n organizaie lucreaz 60 de colaboratori n vrst de la 10 la 60
de ani. Atunci histograma ce reprezint rspndirea valorilor cmpului AGE poate avea tipul,

artat mai jos n desen. Histograma e construit reeind din mprirea diapazonului valorilor
cmpului AGE n 10 intervaluri.
S analizm faptul cum putem aprecia selectivitatea predicatelor simple, indicate n
cmpul AGE, utiliznd aa program. . fie c n intervalul de valori AGE Si nimeresc Ki valori.
Atunci SEL(EMP.AGE=const), dac valoarea constantei nimerete n intervalul valorilor Si,
poate fi apreciat n felul urmtor: 0<=SEL(EMP.AGE)<=Ki/T(t numarul total de corteje in
relatia EMP). De aici rezult aprecierea medie a nivelului selectivitii prediactului Ki/(2(T).
De exemplu, SEL(AGE=29) se apreciaz cu 40/200=0,2, iar SEL(AGE=16) se apreciaz cu
5/200=0,025. Acestea sunt aprecieri mai precise, dect cele ce se pot primi din propunerile despre
egalitatea rspunsurilor. Dar nu aa de bine stau lucrurile cu aprecierile selectivitii a
predicatelor simple cu neegaliti.
De exemplu, fie c trebuie de apreciat nivelul selectivitii predicatului EMP.AGE<const.
Dac valoarea constantei nimerete n intervalul Si i SUMi cantitatea sumar a valorilor
AGE, ce nimeresc n intervalul S1, S2,, Si, atuncii SUMi-1/t<=SEL(AGE<const)<=SUMi/T.
Atunci aprecierea medie a nivelului selectivitii (SUMi-1+SUMi)/(2(T) i eroarea aprecierii
poate atinge jumtate din greutatea subsferei, n care nimerete valoarea constantei predicatului.
Cel mai neplcut este faptul c eoarea aprecierii depinde de valoarea constantei i cu attmai
mult, cu ct sunt mai multe valori a cmpului n intervalul dat a histigramei. De exemplu,
SEL(AGE<29) se apreciaz ca 46/100<=SEL(AGE<29)<=86/100, de unde aprecierea nivelului
selectivitii este (46+86)/200=0,66; eroarea aprecierii poate atinge 0,2. n acelai timp
SEL(AGE<49) se apreciaz mai precis.
Pentru nlturarea acestui neajuns a fost propus alt apropiere ctre descrierea
rspndirilor valorilor cmpului relaiei. Ideea apropierii const n aceea c mulimea valorilor
cmpului se mparte n intervaluri de dimensiuni diferite, pentru ca n fiecare interval(n afar de
ultimul) s nimereasc un numr egal de valori a cmpului. Numrul intervalelor se alege n
dependen de limitele memoriei i cu ct ele sunt mai mari, cu att aprecierile sunt mai clare. La
mprirea sferei valorilor n 10 intervale harta pseudohistogramic a rspndirilor valorilor
cmpului AGE e artat mai jos.
Sfera valorilor cmpului AGE a relaiei EMP e mprit n 10 intervale, n aa mod, c
n fiecare interval nimeresc fix 10 valori a cmpului AGE. Intervalele au diferite dimensiuni.
Valorile de hotar a intervalelor sunt artate deasupra limitelor verticale. n pseudohistogram se
admit intervale, graniele de dreapta i de stnga a crora coincid, de exemplu intervalul (28;28).
El s-a format din cauza prezenei n relaia EMP a unui numr mare(mai mare ca 10) de corteje
cu valoarea AGE=28. La utilizarea pseudohistogramei erorile n aprecierea nivelului de
selectivitate a predicatelor cu operaia, diferit de egalitae, scad. Mrimea erorii nu depinde de
valoarea constantei i se micoreaz la mrirea numrului de intervale. Neajunsul metodei
pseudohistogramice n comparaie cu histogramele const n aceea c este prezent necesitatea
de sortare a relaiilor dup valorile cmpurilor pentru construirea pseudohistogramei de
rspndire a valorilor cmpului dat. Este cunoscut apropierea , ce permite primirea
pseudohistogramei fr necesitatea sortrii relaiei ntregi.
Apropierea se bazeaz pe statistica lui Colmogorov, din care, atribuind-o la BD
relaionale, rezult c din regul se alege exemplul din 1064 de corteje i b este poriunea
cortejelor n exemplu cu valorile c<V, atunci cu ncrederea de 99% poriunea cortejelor, n toat
relaia, cu valorile cmpului c<V se afl n intervalul [b-0,05;b+0,05].
La micorarea puterii exemplului ncrederea scade.

SGBD n arhitectura Client-Server

SGBD n arhitectura Client-Server
Lecia 19. Arhitectura Client-Server

ntrebuinnd ctre arhitectura bazelor de date Client-Server este interesant i actual
n primul rnd de aceea, c asifgur rezolvarea simpl i ieftin a problemei accesului colectiv
la bazele de date n reeaua local. ntr-o oarecare msur, sistemele BD, bazate pe arhitectura
Client-Server, sunt apropierea ctre sistemele rspndite de BD, desigur o apropiere mai
simplificat, dar care nu cere soluionarea setului de probleme a BD rspndite.

19.1. Sistemele deschise

19.1. Sistemele deschise
Rspndirea real a rihitecturii Client-Server a devenit posibil datorit dezvoltrii i a
implimentrii largi n practic a concepiei sistemelor deschise. Deci vom ncepe de la o scurt
introducere a sistemelor deschise.
Scopul principal a apropierii de sistemele deschise este simplificarea complexitii
sistemelor de calcul pe baza standartizrii internaionale i naionale a interfeelor hard i soft.
Cauza principal a apariiei dezvoltrii concepiei sistemelor deschise este trecerea la folosirea
reelelor computerizate locale i a celor probleme de complexare a resurselor aparato-
programale, ce au fost create de aceast trecere. n legtur cu dezvoltarea grabnic a
tehnologiilor comunicaiilor globale, sistemele deschise au atras o mai mare atenie i au o scar
mai larg. Fraza cheie a sistemelor deschise, ndreptat spre utilizator, este independena de
productorul concret. Orientndu-se spre producia companiilor, ce se menin de standartele
sistemelor deschise, utilizatorul, ce procur orice produs al acestei companii, nu devine rob a ei.
El poate continua creterea puterii sistemului su pe calea procurrii produselor a oricrei alte
companii, care respect standartele. Aceasta se refer ct la mijloacele aparatale, att i la
mijloacele programabile i nu este o declaraie fr explicaie. Posibilitatea real de independen
de productor este controlat n condiiile noastre naionale. Baza practic a surselor sistem i
program aplicate a sistemelor deschise este sistemul operaional standartizat. n prezent aa
sistem este UNIX. Firmele productoare a diferitor variante OS UNIX n rezultatul lucrrilor
ndelungate, au reuit s ajung la concluzia despre standartele bazate ale acestui sistem
operaional. Acum, toate versiunile rspndite a OS UNIX, mai ales cele bazate pe interfee, sunt
colaborabile n problema interfeelor, reprezentate programatorilor aplicai. Dup cum se pare,
nectnd la faptul apariiei sistemului ce tinde la standart WINDOWS NT, anume UNIX va
rmne de baz pentru sistemele deschise.
Tehnologiile i standartele sistemelor deschise asigur posibilitatea real i controlat de
practic de elaborare a surselor de programe sistem i aplicate cu proprieti de
mobilitate(portability) i de interoperabilitate(interoperability). Posibilitatea mobilitii indic
simplitatea comparabil a posibilitii sistemului program n spectrul larg a surselor program-
aparatale, ce corespund standartelor. Interoperabilitatea nseamn simplificrile complexrii
noilor sisteme program pe baza utilizrii componentelor gata cu interfee standarte.
Utilizarea apropierii de sistemele deschise este convinabil i utilizatorilor i
productorilor. n primul rnd, sistemele deschise asigur soluionarea real a problemei
generaiilor de surse program i aparate. Productorii de aa surse nu se impun de a soluiona
toate problemele din nou; ei pot continua complexarea sistemelor, utiliynd componentele
existente. S menionm, c n acest timp apare un nivel nou de construcie. Toi productorii
sunt datori s urmreasc, s asigure o sfer standart, dar sunt impui s ajung la o realizare a
ie ct mai bun. Desigur, peste un timp, standartele existente vor ncepe s joace rolul de stopare
a procesului i atunci va trebui reanalizarea lor. Un plus pentru utilizatori este faptul c ei pot
schimba cu timpul componentele sistemului cu altele mai perfecte, astfel nepierznd eficacitatea
lucrului sistemului.

19.2. Clienii i serverele reelelor locale


19.2. Clienii i serverele reelelor locale
La baza rspndirii largi a reelelor locale a calculatoarelor st ideiea cunoscut de
mprire a resurselor. Posibilitatea nalt de permisiune a reelelor locale asigur accesul efectiv
de la un nod al reelei locale la resursele, din alte noduri.
Dezvoltarea acestei idei duce la delimitarea funcional a componentelor sistemului:
este raional de avut acces nu numai la resursele calculatorului extras, dar i de a primi de la el
un servis oarecare, care-i specific pentru resursele tipului dat i sursele program, pentru
asigurarea cruia, se dublau n cteva noduri. Aa noi ajungem la diferena dintre staiile
lucrtoare i a serverelor reelei locale.
Staia de lucru este destinat lucrului utilizatorului sau a categoriei de utilizatori i deine
resurse ce corespund necesitilor locale a utilizatorului dat. Deosebirile specifice a staiei de
lucru pot fi volumul memoriei operative(nu toate categoriile de utilizatori au nevoie de deinerea
a unei memorii operative mari), posesia i volumul memoriei pe disc(sunt populare staiile de
lucru fr disc, ce utilizeaz memoria intern a serverului de disc), caracteristicile procesorului i
a monitorului(unii utilizatori au nevoie de un procesor puternic, alii au nevoie de accelerarea
graficii, .a.). La nevoie, putem utiliza resursele i/sau serviciile asigurate de server.
Serverul reelei locale trebuie s posede resursele, ce corespund scopului su funcional
i cerinelor reelei. S accentum, c n legtur cu orientarea spre orientarea sistemelor
deschise, mai corect vorbete despre serverele logice(avnd n vedere setul de resurse i mijloace
programare, ce asigur serviciile pe aceste resurse), care se implementeaz nu neaprat pe
diferite calculatoare. O deosebire a serverului logic n sistema deschis este aceea c dac dup
eficacitate serverul complet s-ar muta la alt calculator, atunci aceasta s-ar face fr necesitatea
schimbrii crorva componente att n calculator, ct i n programele aplicate utilizate de el.
Ca exemple de server pot fi: serverul telecomunicaiilor, ce asigur serviciile n legtura
reelei locale cu lumea extern; serverul de calcul, ce d posibiitatea de a efectua calcule, ce nu
pot fi efectuate n staiile de lucru.
Serverul bazei de date este de fapt o SGBD simpl, ce primete adresri prin reeaua
local i care ntoarce rezultatele.
Serverul reelei locale, ofer resurse(servicii) staiilor de lucru i/sau altor servere.
Este convenit de numit client a reeleilocale, ce cere servicii de la un server oarecare i
server componenta reelei locale, ce ofer servicii crorva clieni.

19.2. Arhitectura de sistem ClientServer

19.3. Arhitectura de sistem ClientServer
Este clar c n caz general, pentru ca programul aplicat, ce se execut n staia de lucru, s
poat adresa sau cere serviciul de la careva server, se cere ca minimum un oarecare slav
interfaional programal, ce menine aa tip de conluccrare(ar fi fost nreal de cerut ca programul
aplicat s utilizeze direct primitivele nivelului de transport a reelei locale). Din aceasta i reiese
prinicpiile arhitecturii de sistem ClientServer.
Sistema se mparte n dou pri, ce se pot executa n diferite noduri a reelei partea
clientului i a serverului. Programul aplicat sau utilizatorul final colaboreaz cu partea clientabil
a sistemei, care n cel mai simplu caz, asigur interfaa asupra reelei. Partea clientabil a
sistemei, n caz de necesitate, se adreseaz n reea ctre partea serverului. S accentum, c n
sistemele dezvoltate, adresarea de reea ctre partea serverului poate s nu fie necesar, dac
sistema ar putea ghici necesitile utilizatorului i n partea clientabil se gsesc date ce pot
satisface adresarea sa urmtoare.
Interfaa prii serverului este determinat i fixat. De aceea este posibil crearea noilor
pri clientabile a sistemului existent.

Problema de baz a sistemelor bazate pe arhitectura ClientServer, este aceea c n
coresponden de concepia sistemelor deschise de la ele se cere mobilitatea n ct se poate o
clas mai larg a hotrrilor programo-aparatice a sistemelor deschise. Dac UNIX s-ar limita la
reelele locale orientate, n diferite sisteme se utilizeaz aparataje diferite i protocoale de
legtur.
ncercrile crerii sistemelor, ce ar menine toate protocoalele posibile duce la
suprancrcarea lor cu detalii de reea n nrutirea funcionalitii.
Un alt aspect mai complicat a acestei probleme este posibilitatea utilizrii diferitor
cinfiguraii a datelor n diferite noduri a reelei neomogene locale. n diferite calculatoare pot
exista adresri diferite, afiri a numerelor, codarea simbolurilor, .a. Aceasta este foarte
important pentru serverele de nivel nalt: de telecomunicaii, de calcul, a bazelor de date.
O soluionare comun a mobilitii sistemelor, bazate pe arhitectura ClientServer este
bazarea pe pachetele programale, ce realizeaz protocoalele de chemare lichidat a
procedurilor(RPC Remote Procedure Call). La utilizarrea acestor mijloace, adresarea ctre
serverul din nodul lichidat arat ca un apel simplu a procedurii. Sursa APC, n care, n care se
pstreaz informaia despre specificul aparatajului a reelei locale i a protocoalelor de reea,
transfer apelul n consecutivitatea colaborrii de reea. Specificul sferei de reea i a
protocoalelor este ascuns de programatorul aplicat.
La apelul procedurii lichidate a programei RPC creeaz reformarea formatului datelor
clientului n formate temporale independente mainal, i apoi sursele reformate n formate de
date a serverului. La transferul parametrilor de rspuns au loc creeri analogice.
Dac sistemul e realizat pe baza pachetului standart RPC ea poate fi uor transferat n
alt sfer deschis.

19.4. Serverele bazei de date

19.4. Serverele bazei de date
Termenul de server a bazei de date se utilizeaz de obicei pentru nsemnarea ntregii
SGBD bazat pe arhitectura ClientServer, inclusiv i prile de server i de client. Aa
sisteme sunt destinate pentru pstrarea i asigurarea accesului ctre BD.
Dei de obicei, o BD se pstreaz n ntregime ntr-un nod a reelei i se menine de ctre
un server, serverele BD sunt nite apropieri simple i ieite ctre bazele de date mprite,
deoarece baza de date comun este accesibil pentru toi utilizatorii reelei locale.

19.4.1. Principiile de colaborare dintre prile de client i server
Accesul la BD de la programul aplicat sau de la utilizator are loc pe calea adresrii la
partea clientului sistemei. n calitate de interfa de baz dintre partea serverului i cea a
clientului este limbajul BD SQL.
Acest limbaj reprezint standartul curent a interfeei SGBD n sisteme deschise.
Denumirea SQL-Server se refer la toate serverele BD, bazate pe SQL. Respectnd atenia la
programe, unele care au fost analizate la leciile trecute, pot fi create sisteme aplicate
informaionale, mobile n clasa SQL-Server.
Sferele bazelor de date, interfaa crora se bazeaz doar pe SQL au neajunsurile i
plusurile sale. Plusul, desigur, este standartizarea interfeei. Prile clientabile a oricrui SQL a
SGBD atentate ar putea lucra cu orice SQL-Server, independent de cine l-a produs.
Neajunsul, deasemenea, este clar. La aa un nivel nalt interfeele dintre prile clientabile
i cea a serverului, de partea clientului lucreaz foarte puine programe SGBD. Aceasta este
normal dac n partea clientului lucreaz o staie slab. Dar dac calculatorul clientului are
destul putere, atunci mai des apare dorina de a-i adresa mai multe funcii de dirijare cu BD,
descrcnd serverul, care este locul ngust a ntregii sisteme.

Una din direciile perspective a SGBD este configuraia modificabil a sistemului, fa de
care rspndirea funciilor ntre prile de client i utilizator a SGBD se determin la instalarea
sistemului.

19.4.2. Plusurile prtocoalelor a apelului lichidat a procedurilor
protocoalele vzute mai sus a apelurilor lichidate a procedurilor sunt foarte importante n
sistemele de dirijare cu BD, bazate pe arhitectura ClientServer. n primul rnd utilizarea
mecanismului procedurilor lichidate permite ntr-adevr de a rempri funciile ntre prile
clientului i a serverului sistemului, cci n textul programului de lichidare, apelul procedurii nu
se deosebete cu nimic de apelul lichidat, i deci, teoretic orice component a sistemului se poate
afla i de partea serverului i de partea clientului.
n al doilea rnd, mecanismul apelului lichidat ascundedeosebirile dintre interaciunile
calculaoarelor. Reeaua local fizic neomogen a calculatoarelor se aduce la reeaua logic
omogen a calculatoarelor interacionabile programabil. n rezultat, utilizatorii nu trebuie s se
ngrijoreze de cumpararea unic a staiilor de lucru i a serverelor mpreun.

19.4.3. mprirea funciilor ntre client i server
n cazul tipic pentru zilele noastre, din partea clientului SGBD lucreaz numai o aa
asigurare a programului, ce nu are acces direct la BD, dar se adreseaz pentru aceasta ctre
server, utiliznd limbajul SQL.
n unele cazuri ar fi de dorit includerea n partea clientabil a sistemei unei fincii de
lucru cu cacheul local a BD, adic cu acea parte a ei, ce este utilizat intens de programul
aplicat a clientului. n tehnologia actual aceasta poate fi fcut doar pe calea creerii formale de
partea clientului a copiei locale a serverului BD i cercetrii sistemului ca un set de servere
interacionabile.
Din alt parte, cte o dat s-ar dori de transportat marea parte a sistemului aplicat n
partea serverului, adic diferena dintre puterile staiilor de lucru a clienilor i serverelor este
foarte mare. n general, la utilizarea RPC, aceasta este uor de fcut. Dar e nevoie ca asigurarea
de baz programal a serverului ntr-adevr ar permite aceasta. La utilizarea OS UNIX, practic
nu apar probleme.

19.4.4. Cerinele ctre posibilitile aparatelor i ctre asigurarea programal de baz a
clienilor i serverior
din discuiile de mai sus se vede c cerinele ctre aparataj i asigurarea programal a
calculatoarelor serverelor i celor a clienilor se deosebesc de tipul utilizrii sistemului.
Dac mprirea dintre client i server este destul de aspr(ca n majoritatea SGBD
actuale), atunci utilizatorilor ce lucreaz n staiile de lucru sau cu calculatoarele personale, le
este totuna care aparataj sau sistem operaional lucreaz pe server, de s-ar isprvi el cu torentul
adresrilor ce apare.
Dar dac pot aprea necesitile de remprire a funciilor dintre client i server, atunci
nu-i la fel, care operaie a sistemei se utilizeaz.

Baze de date mprite

Baze de date mprite
Lecia 20. BD mprite
Condiia de baz a sistemelor de dirijare cu BD mprite const n asigurarea surselor de
integrare a bazelor de date locale, ce se afl n unele noduri a reelei de calcul, cu aceea, c
utilizatorul ce lucreaz n orice nod a reelei s aib acces la toate aceste BD ca la o singur BD.
Cu toate acestea trebuie s fie asigurate:

- Simplitatea utilizrii sistemului;
- Posibilitile funcionrii autonome la nclcarea legturii reelei sau la necesiti
administraionale;
- Nivelul nalt de eficacitate.

20.1. Multiplicitatea felurilor sistemei mprite

20.1. Multiplicitatea felurilor sistemei mprite
Sunt posibile BD omogen i neomogen mprite. n cazul omogen fiecare baz de date
local este dirijat de una i aceeai SGBD. n sistemul neomogen BD locale pot s se refere
chiar la modele diferite de date.
Integrarea de reea a BD neomogene este o problem actual, dar foarte complicat.
Multe soluii se cunosc la nivel teoretic, dar nc nu se poate soluiona problema principal -
eficacitatea insuficient a sistemelor integrate.
S atenionm c mult mai cu succes practic se soluioneaz problema intermediar
integrarea SQL neomogene a sistemelor orientate. E clar c standartizarea limbajului SQL ajut
n mare parte acestui fapt i faptului respectrii generale a productorilor de SGBD a principilor
sistemelor deschise. Ne vom limita la cercetarea problemelor a SGBD mprite omogen n
exemplul System R.

20.2. Sistemul mprit de gestiune cu BD System R*

20.2. Sistemul mprit de gestiune cu BD System R*
Scopul de baz a proiectului poate fi apreciat n felul urmtor: de asigurat sursele de
integrare a BD locale System R*, ce se afl n nodurile reelei de calcul, cu scopul, ca
utilizatorul, ce lucreaz n orice nod a reelei, s aib acces la toate aceste BD, ca i cum ele ar fi
centralizate.
n acest timp trebuie s fie asigurate:
- simplitatea utilizrii sistemului;
- posibilitile funcionrii autonome la nclcarea legturii reelei sau la necesiti
administrative;
- nivelul nalt de eficacitate.
Pentru soluionarea acestor probleme era nevoie de primit un ir de soluii, legate de
decompoziia adresrii iniiale, selecii optimale a mijlocului de execuie a adresrii, execuia
permis a trenzaciei, asigurarea sincronizrii, restabilirea strii BD dup diferite tipuri de
neregulri n nodurile reelei.
Simplitatea utilizrii sistemului se atinge datorit faptului c utilizatorii System
R*(productorii programelor aplicate i utilizatorii finali) rmn n sfera limbajului SQL, adic
pot s prelungeasc lucrul n aceleai condiii externe ca i n System R(i SQL/DS i BD2).
Posibilitatea utiliyrii SQL se bayeay pe locul de aflare curent a obiectelor, apelate n adresare
de ctre utiliyator, de date, unul i acelai program aplicat, ce include cuvntul SQL, poate fi
executat n noduri diferite a reelei. n fiecare nod a reelei, la etapa compilrii adresrii, se
alege planul optimal de execuie a adrersrii n dependen de aflarea datelor n sistemul mprit.
Asigurarea autonomiei nodurilor reelei n System R* i se d o mare atenie. Fiecare BD
local se administreaz independent de altele. Este posibil conectarea autonom a utilizrii noi,
schimbul versiei prii autonome a sistemului, .a. Sistemul e proiectat n aa mod, ca n el nu
este nevoie de slujbele de enumerare a obiectelor centralizate.
n nodurile individuale nu e nevoie de prezena cunotinelor globale despre operaii ce se
execut n alte noduri a reelei, lucrul cu BD accesibile poate s se continuie la ieirea din
funciune a nodurilor aparte a reelelor sau a liniilor de legtur. Nivelul nalt de eficacitate a

sistemului este una dintre cele mai importante cerine dintre sistemele mprite de gestiune cu
BD n general i ctre System R* n particular. Pentru atingerea aceastui scop se utilizeaz dou
msuri de baz. n primul rnd, ca i n System R, n System R* nainte de execuia adresrii se
face compilarea ei. n mersul acestui proces are loc cutarea numelor, utilizate n adresare, a
obiectelor BD n registrul mprit i schimbul numelor cu identificatori interni; controlul
drepturilor accesului utilizatorului din numele cruiea se face compilarea pentru execuia
operaiilor corespunztoare pe BD i alegerea planului de execuie a adresrii celui mai optimal
global, care se va supune decompoziiei i se trimite pe pri n nodurile corspunztoare a reelei,
unde are loc selecia planurilor de execuie a componentelor adresrii celui mai optimal local i
are l,oc generarea modulelor de acces n codurile mainii. n rezultat, o mulime de aciuni are
loc la stadiul compilrii pn la execuia real a adresrii. Programul aplicat, prelucrat dup
mijloacele precompilatorului System R*, ce include propoziii SQL, poate fi executat de mai
multe ori, fr cheltuieli adugtoare. Utilizarea catalogului mprit, compilaia mprit i
optmimizarea adresrilor sunt aspectele cele mai interesante i mai originale a proiectului
System R*.
A doua metod de ridicare a eficacitii sistemului este de a transporta relaiile lichidate
n baza de date local. Dialectul SQL, utilizat n System R*, include propoziia MIGRATE
TABLE, la execuia creiea relaia artat se transfer n BD local. Acest mijloc, ce se gsete
n minele utilizatorului desigur poate ajuta la primirea unor treceri mai eficative a tranzaciilor.
Desigur, ca pentru toate operaiile, operaia MIGRATE n dependen de relaia accentuat de
acces nu oricrui utilizator, dar numai celora ce au permisiunea corespunztoare. Pn a trece la o
reluare mai detaliat a celor mai interesante aspecte a realizrii System R*, s amintim careva
surse, pe care productorii acestei sisteme i le-au propus spre realizare n stadiul nceptor a
proiectului, dar care nu au fost realizate(careva din ele nu vor fi realizate nici o dat). Se
propunea de a prezenta n sistem a surselor de mprire orizomtal i vertical a relaiilor BD
mprie, surse de dublare a relaiilor n cteva moduri cu susinerea acordului copiilor i surse de
meninere a pozelor momentane a strii BD n dependen de adresarea dat.
Pentru adresarea mpririi orizontale a relaiilor n SQL a fost introdus construcia de
tipul
DETRIBUTED TABLE <table-name>HORIZONTALLEY INTO
<name> WHERE <predicate> IN SEGMENT <segment-name-site>
.
.
.
<name> WHERE <predicate> IN SEGMENT <segment-name-site>
La execuia propoziiei de aa tip, relaia dat se mprea ntr-un rnd de subrelaii, ce
conin corteje, ce satisfac predicatuluiu corespunztor din despritura WHERE i fiecare
subrelaie primitor n aa fel trimitea n nodul specificat pentru pstrarea n segmentul cu numele
dat. Se garanteaz starea acordat a despriturilor la calculul relaiei.
mprirea vertical avea cu ajutorul operatorului
<name> WHERE <column-name-list> IN SEGMENT <segment-name-cite>
.
.
.
<name> WHERE <column-name-list> IN SEGMENT <segment-name-cite>
La execuia acestei propoziii de asemenea s-a format setul de subrelaii cu ajutorul
proieciei relaiei date pe atributele din lista dat. Fiecare subrelaie primit se trimitea pentru
pstrare n segmentul cu numele specificat n nodul corespunztor. Dup aceasta sistemul e
rspunztor de meninerea strii prrimite a despriturilor formate.

mprirea vertical i orizontal a relaiilor nu se utilizeaz real n System R* cu toate c
este clar c execuia operatorului DISTRIBUTE nu cheam nici o dificultate tehnic.
Dificultile apar la asigurarea acordului despriturilor(uite mai jos). n afar de aceasta, relaiile
mprite sunt greu de utilizat. n conformitate cu ideologia sistemului darea de seam a
prezenei despriturilor relaiilor n diferite noduri a reelei trebuie s fie fcut de optimizator,
adic numrul planurilor poteniale posibile de execuie a adresrilor, care trebuie s fie apreciate
de optimizator, nc mai crete. Cu toate c n sistemul de rspndire numrul planurilor posibile
i aa este mare i optimizatorul lucreaz la limita complicrii, este imposibil de utilizat relaiile
mprite n mod relaional. Productorii optimizatorului System R* nu erau n stare s in cont
de despriturile relaiilor. De aceea introducerea n sistem a relaiilor mprite nu are sens.
Pentru aplicarea cerinelor de susinere a copiilor n cteva noduri a reelei se propune utilizarea
noii construcii SQL.
DISTRIBUTE TABLE <table name> REPLICATED INTO
<name> IN SEGMENT <segment-name-site>
.
.
.
<name> IN SEGMENT <segment-name-site>
La execuia a aa relaie trebuie s se produc rspndirea copiilor relaiei specificate
pentru pstrare n segmentele cu numele nodurilor specificate a reelei. Sistremul trebuie
automat s menin acordul copiilor.
Ca i n cazul relaiilor mprite, n afar de problemele de meninere a acordurilor
copiilor, o problem este i utilizarea relaional a copiilor, prezena crora ar trebui s se
contoreze de optimizator.
Crearea cadrului momentatn a strii BD n coresponden cu adresarea dat de selecie,
trebuie s se efectuieze cu utilizarea construciilor noi SQL.
DEFINE SNAPSHOT <snapshot-name>(<attribute-list>)
AS <query>
REFRESHED EVERY <period>
La execuia propoziiei, de fapt, se execut adresarea pentru selecia specificat n ea, iar
relaia rezultant se pstreaz sub numele specificat n propoziie n BD local n acel nod, n
care se execut propoziia. Dup aceasta cadrul momentan se nnoiete periodic n dependen de
adresarera momentan.
Putem nnoi cadrul momental, neateptnd trecerea intervalului de timp specificat n
determinare, pe calea execuiei propoziiei
REFRESH SNAPSHOT <snapshot-name>
Utilizarea raional a cadrului momentan este mai real, dect utilizarea relaiilor
mprite i a relaiilor coppiate, deoarece ele pot fi privite ca nite configuraii materializate a
BD. Numele cadrului momentan s-ar putea utiliza n adresarea pentru selecie acolo, unde se pot
utiliza numele relaiilor de baz sau a configuraiilor. Probleme complicate sunt legate de
lmurirea relaiilor prin cadrele sale momentane, cci n momentul nnoirii, coninutul cadrului
momentan poate s se desprind de coninutul curent a relaiei de baz.
n legtur cu cadrele momentane, probleme de meninere a strii acordate a cadrelor
momentane i a relaiilor de baz de date nu exist, deoarece de acordare automat nu e nevoie.
Ceea ce privete relaiile mprite i cele recopiate, atunci pentru ele aceast problem este
comun i dificil.
n primul rnd acordarea i copiile aduce cheltuieli la execuia operaiilor de modificare a
relaiilor memorabile. Pentru aceasta este nevoie de crearea i respectarea protocoalelor de
modificare speciale.

n al doilea rnd, introducerea relaiilor copiate se face nu att pentru mrirea eficacitii
sistemului, ct pentru mrirea accesibilitii datelor la nclcarea legturilor relaiilor. n
sistemele, n care se aplic aceast apropiere, la nclcarea legturilor reelei lucrul cu BD
mprit, de obicei, se prelungete numai n una din relaiile formate. n acest timp pentru
alegerea subreelei se utilizeaz algoritmii de vot; hotrrea se adopt pe baza drii de seam a
numrului nodurilor de legtur a reelei. Se aplic i alte apropieri, dar toate ele sunt foarte
scumpe, iar cel mai principal, ele ru se voteaz cu apropierea de baz System R* cu condiia
seleciei metodei de execuie a adresrii la stadiul compilrii ei. De aceea dup cum ni se pare, n
System R* nici o dat nu vor fi realizate surse, ce ar permite printr-un mijloc sau altul, s
menin copiile relaiilor n cteva noduri a reelei.
n continuare vom analiza aspectele proiectului System R*, care i-au gsit reflexia n
realizarea sa i care sunt mai interesante: sursele de enumerare a obiectelor i organizarea
registrului mprit a BD; apropierea de compilrile mprite i execuiile adresrilor; deosebirile
utilizrii configuraiilor; sursele de sincrinizare.

20.2.1. Enumerarea obiectelor i organizarea registrului mprit
S amintim, c numele ntreg a relaiei(de baz sau configuraiei) n BD System R are
tipul numele-utilizatorului.numele-relaiei, unde numele-utiizatorului identific utilizatorul-
creatorul relaiei, iar numele-relaiei este numele, ce a fost specificat n propoziiile CREATE
TABLE sau CREATE VIEW. n adresri putem specifica sau acest nume plin, sau numele local.
n al doilea caz, la compilare se utilizeaz regulile standarte de adugare a numelui local pn la
plin cu utilizarea n calitate de component numele-utilizatorului a identificatorului utilizatorului,
de la numele cruia se face compilare.
n System R* se utilizeaz dezvoltarea acestei apropieri. Numele de sistem a relaiei
include 4 componente: identificatorul utilizatorului-creatorul relaiei, identificatorul nodului
reelei, n care s-a efectuat operaiunea de creare a relaiei; numele local a relaiei, care i s-a dat la
creare: identificatorul nodului, n care relaia se gsea dup crearea sa(s amintim c relaia poate
s se mute dintr-un nod n altul la execuia operaiei MIGRATE).
n adresarea pe SQL putem utiliza numele de sistem a obiectelor, dar se permite i
utilizarea numelor scurte locale(sau numelelocal, calificat ca numele utilizatorului). Cu toate
acestea sunt posibile dou interpretri a numelui local. El poate s fie interpretat ca o parte a
numelui de sistem i n acest caz se adaug n descretere pn la simetric, reeind din
identificatorul nodului, n care are loc compilarea i a identificatorilor utilizatorilor de la numele
crora ea are loc(dac numele utilizatorului nu-i specificat clar). A doua interpretare posibil a
numelui local const n prelucrarea lui ca nume determinat mai devreme a sinonimului numelui
de sistem
Pentru determinarea sinonimelor, SQL e lrgit de operatorul de tipul
DEFINE SYNONYM <relation name> AS <system wide name>
La execuia a aa propoziie n catalogul local se nscrie informaia odat.
n aa mod, la compilarea adresrii, n totdeauna putem determina numele de sistem a
tuturor relaiilor utilizate n el: sau ele sunt specificate clar, sau pot fi primite pe baza informaiei
din relaiile locale a registrelor.
Concepia registrului mprit System R* e bazat pe prezena la fiecare obiect a BD
mprite a numelui unical de sistem. S-a luat urmtoarea decizie: informaia despre locul aflrii
oricrui obiect a BD(identificatorul nodului curent, n care se afl obiectul) se pstreaz n
registrul local a acelui nod, n care obiectul se afl ndat dup creare(nodului de natere).
Deci pentru primirea informaiei ntregi despre relaie trebuie nti s ne folosim de
registrul local a nodului, n care are loc compilarea, apoi s ne adresm la registrul lichidat a
nodului de natere a relaiei date i n sfrit s utilizm registrul nodului curent. n aa fel, pentru

primirea informaiei de sistem precise, despre oarecare relaie a bazei de date mprite, poate s
apar necesitatea utilizrii a cel mult dou accese lichidate ctre relaiileregistre.
Se utilizeaz o optimizare a acestei proceduri. n registrul local a nodului se pot pstra
copiile elementelor registrului altor noduri(ca un fel de c-registru). Acordarea copiilor
elementelor registrului nu se menine. Aceast informaie se utilizeaz n prima stadie de
compilare a adresrii, iar apoi n a doua stadie, dac informaia, referitoare la un obiect anume,
este imprecis, ea se va preciza pe baza registrului local a acelui nod, n care obiectul se
pstreaz acum. Definirea incorectitudinii copiei elementului registrului a numrului versiei.
Dac vom ine cont de ineria informaiei n sistem, aceast optimizare a r putea fi important.

20.2.2. Compilarea mprit a adresrilor
Dup cum am menionat, adresrile n limbajul SQL pn la execuia sa real se impun
compilrii. Ca i n cazul System R, compilarea adresrii poate avea loc n stadiul precompilrii
programului aplicat, scris n limbajul tradiional de programare(PL/1, Cobol, Assembler) cu
includerea aplicaiilor SQL sau n dinamica execuiei tranzaciei la execuia propoziiei
PREPARE. Din punct de vedere a utilizatorilor, procesul compilrii n System R*, aduce la
aceleai rezultate ca i n System R: pentru fiecare propoziie SQL se creeaz programul n
codurile mainii(selecia modului de acces, apelurile creia ncap n textul programului aplicat
iniial. ns, n realitate, procesul de compilare a adresrii n system R* este cu mult mai
complicat ca n System R, ceea ce este real din cauza interaciunilor de reea mai complicate, de
care va fi nevoie la execuia real a tranzaciei. Compilarea mprit a adresrilor n System R*
include o mulime de rafiniti tehnice. S analizm schema general a compilrii mprite.
Vom numi nod principal, acel nod, n care este iniializat procesul compilrii a
propoziiei SQL i noduri adugtoare acxele noduri, ce se includ n acest proces n mersul
execuiei lui. n cel mai grav nivel, procesul compilrii se mparte n fazele urmtoare:
n nodul acceptat are loc mprirea gramatic a propoziiei SQL cu construcia
configuraiei interne a adresrii n form de arbore. Pe baza informaiei din registrul local a
nodului principal i din registrele lichidate a nodurilor adugtoare, are loc schimbul numelor
obiectelor, ce figureaz n adresarea ctre identificatorii lor de sistem.
n nodul numit se genereaz planul global de execuie a adresrii n care se specific doar
ordinea interaciunilor nodurilor la execuia real a adresrii. Pn la crearea planului global se
utilizeaz lrgirea tehnicii optimizrii, , artat n System R. Planul global se reflect n
arborele adresrilor recreat n felul corespunztor.
Dac n planul global a aexecuiei adresriiiau parte nodurile adugtoare, are loc
decompilarea lui pe pri, fiecare dintre care se poate de ndeplinit ntr-un nod. Prile
corespunztoare a adresrii se trimit n nodurile adugtoare.
n fiecare nod, ce face parte din planul global de execuie a adresrii, se execut stadiul
final de execuie a compilaiei. Acest stadiu include ultimile dou faze a procesului de compilare
a adresrilor n System R: optimizarea i generarea codurilor mainale. Se efectuieaz controlul
drepturilor utilizatorului, de la numele cruiea are loc compilarea, pentru execuia lucrului
corespunztor; are loc prelucrarea configuraiilor BD; are loc optimizarea lexical a prii
prelucrate a adresrii n dependen de indexii avui; are loc generarea codului.

20.2.3. Dirijarea cu tranzaciile i sincronizarea
Efectuarea tranzaciei n sistemul mprit de dirijare cu BD a System R* este rspndit.
Tranzacia ncepe n nodul pricipal la adresarea ctre careva secie(la etapa compilrii) a
modulului de acces pregtit mai devreme. Aceste apeluri se interpreteaz n stilul apelurilor
procedurilor lichidate. Deci execuia unei tranzacii, iniiat ntr-un oarecare nod a reelei A,
induce iniierea tranzaciilor n nodurile adugtoare.

O problem important, nou n comparaie cu System R, este problema finisrii
acordate a tranzaciei mprite, pentru ca rezultatele execuiei sale, n toate nodurile atinse de ea,
s fie reflectate sau n starea BD locale, sau s fie complet absente.
Pentru atingerea acestui scop, n System R* se utilizeaz protocolul de finisare bifazat a
tranzaciei mprite. Acest protocol este utilizat n comun n sistemele mprite a BD i-i descris
n multe izvoare literare.
Pentru descrierea protocolului se utilizeaz modelul urmtor. Sunt un ir de tranzacii
mprite, ce se execut sub dirijarea tranzacieicoordinatorului. Hotrrea despre sfritul
tranzaciei mprite se ia de ctre coordinator. Apoi se execut prima faz de finisare a
tranzaciei, cnd coordinatorul transmite fiecrui participant mesajul pregtiiv de finisare.
Primind aa un mesaj, fiecare participant trece n starea de pregtire ca la o imediat finisare a
tranzaciei. n termenii System R* aceasta nseamn, c buferul revistei cu nscrieri despre
schimbrile BD a participantului se mping n memoria extern, iar apucarea sincronizaional nu
se scot. Dup aceasta, fiecare participant, ce i-a executat cu succes aciunile pregtite, trimite
mesaj ctre coordinator mesajul gata de finisare. Dac coordinatorul primete aa mesaj de la
toi participanii, atunci el ncepe faza a doua a finisrii, trimind tuturor participanilor mesaje
finisai tranzacia i aceasta se socoate finisarea tranzaciei mprite. Dac nu toi praticipanii
au ndeplinit cu succes prima faz, atunci coordinatorul trimite tuturor participanilor mesajul de
napoiai tranzacia i atunci efectul interaciunii tranzaciei mprite pe starea BD lipsete.
n legtur cu deosebirile de realizare a protocolului bifazic de finisare a tranzaciei n
System R* s mai amintim c: n calitate de coordinator este tranzacia ce se execut n nodul
principal, adic aceea, pe baza creiea au aprut tranzaciile adugtoare. Adic prezena nodului
central nu trebuiete, ceea ce corespunde cerinei de autonomie a nodurilor. Pentru napoierea
tranzaciilor se utilizeaz mecanismul de baz a punctelor de salvare System R. n sfrit
protocolul clasic a finisrii bifazate este optimizat, pentru a memoriza numrul mesajelor
necesare.
Ca i n System R, acordul strilor BD, la execuia paralel a crorva tranzacii n System
R* se asigur de mecanismul cheltuielilor sincronizaionale a obiectelor BD, la respectarea
protocolului bifazic a ocuprilor. S reamintim c aceasta nseamn mprirea fiecrei
tranzacii, din punct de vedere a sincronizrii, n 2 faze: faza de lucru, n care ocuprile doar se
stabilesc i faza de finisare, cnd toate ocuprile a obiectelor BD, create de tranzacia dat, se
scot. Sincronizarea are loc imediat, ca i n System R: fiecare tranzacieparticipant se adreseaz
ctre BD local prin RSS a nodului su.

20.3. Sistemele integrate sau federale i multibazele datelor
Direcia sistemei integrate sau federative a BD neomogene i multi BD au aprut n
legtur cu necesitatea complexrii sistemelor BD, bazate pe diferite modele de date i
gestionate de diferite SGBD.
Problema de baz a integritii BD neomogene este prezentarea a sistemului integrat a
schemei globale a BD, artat n