Вы находитесь на странице: 1из 56

Limbajul bazelor de date relaţionale SQL

Limbajul bazelor de date relaţionale SQL


Lecţia 13. Limbajul SQL. Funcţiile şi posibilităţile de bază.
13.1. SEQUEL/SQL SGBD System R
Limbajul de interacţiune cu BD SQL a apărut la mijlocul anilor 70 şi a fost elaborat pe
baza proiectului SGBD System R relaţionale experimentale. Denumirea primară a limbajului
SEQUEL(Structured English Query Language) reflectă doar parţial esenţa acestui limbaj.
Desigur, în mod general, limbajul a fost orientat spre o formulare mai comodă şi mai înţeleasă a
adresărilor către BD relaţionale, dar în realitate era de acum un un limbaj complet de BD,
conţinînd, în afară de operaţiile formulării adresărilor şi manipulărilor BD, mijloace de
manipulare şi determinare cu schema BD: determinarea limitelor integrităţii şi a trigherilor,
afişării BD, posibilităţile determinării structurilor nivelului fizic, care determină executarea
efectivă a adresărilor; autorizaţiile accesului la relaţii şi la cîmpurile lor; a punctelor de salvare a
tranzacţiilor. În limbaj lipseau mijloacele de sincronizare a accesului la obiectele BD din partea
tranzacţiilor efectuate paralel: de la bun început se presupunea că sincronizarea neapăratăeste
executată de SGBD.
Să analizăm posibilităţile acestui limbaj un pic mai amănunţit.

13.1.1. Adresările şi operatorii de manipulare cu datele


După cîte ştim, două limbaje de bază de adresare către BD relaţionale sunt limbajul
algebrei relaţionale şi a calculului relaţional. Cu toată stricteţea şi statornicia sa teoretică aceste
limbaje se utilizează rar în SGBD relaţionale moderne, în calitate de mijloace a interfeţei
utilizatorului. Adresările în aceste limbaje sînt greu de formulat şi de înţeles. SQL reprezintă o
combinaţie oarecare a calculului relaţional combinaţional a cortejelor şi a algebrei relaţionale, în
afară de aceasta încă nu este clar căror din cele clasice acest limbaj este mai apropiat. Cu toate
acestea limbajul SQL are posibilităţi mai largi, ca limbajele relaţionale de bază, de exemplu, în
caz general este imposibilă translarea adresei, formulată în SQL, într-un cuvînt a algebrei
relaţionale, este nevoie de o oarecare lărgire. Proprietăţile de bază a sublimbajului de adresări
SQL sunt posibilităţi de a formula uşor adresările cu legătura cîtorva relaţii şi subadreselor
depuse în predicatele alegerii. Deci posedarea concomitentă a ambelor mijloace este extensivă,
dar acest fapt dă posibilitatea utilizatorului, în timpul formulării adresării, de a alege varianta
cea mai clar înţeleasă.
În predicatele cu subadresările depuse în SQL System R este posibil de a utiliza teoretic o
mulţime de operatori de comparaţie, ceea ce permite de a formula adresări cuantificate(ceea ce
de obicei, cel mai greu este înţeles de utilizatori, de aceea în SQL au apărut predicate
cuantificabile).
O deosebire principală a limbajului SQL este posibilitatea prezenta în adresare
necesitatea grupării apartenenţei-rezultatului pe cîmpurile determinate, cu ajutorul condiţiilor de
selectare a întregii grupe. Aşa fel de condiţii de selectare pot conţine funcţii de agregat, calculate
pe grupă. Această posibilitate a SQL în mod principal deosebeşte acest limbaj de limbajele
algebrei relaţionale şi a calculului relaţional, care nu conţine surse analogice.
O altă deosebire a limbajului SQL nu este ştergerea neapărată a cortejelor-dublicate în
relaţii – rezultatele finale sau intermediare. Altfel spus, rezultatul operatorului ştergerii în
limbajul SQL este mulţimea cortejelor şi nu a relaţiilor. În cazurile cînd semantica adresărilor
cere prezenţa relaţiei, distrugerea predicatelor are loc neclar.
Cel mai general tip de adresare în limbajul SQL este expresia algebrică alcătuită din
adresări elementare. În SQL System R erau admise toate operaţiile de bază(UNION,
INTERSECT şi MINUS).
Lucrul cu expresiile nedeterminate în SQL System R nu a fost gîndit pînă la urmă, cu
toate că se presupunea utilizarea logicii cu trei simboluri, în cazul determinării expresiilor logice.
Operatorii de manipulare cu datele UPDATE şi DELETE sunt construite pe baza
aceloraşi principii ca şi operatorul de seşlecţie a datelor SELECT. Colectarea cortejurilor relaţiei
date, care aparţin modificării sau ştergerii, se determină cu ajutorul expresiei logice care face
parte din operatorul dat şi care poate conţine predicate compuse şi de asemenea cu subadresări
depuse.
În operatorul de includere a cortejurilor în relaţia dată, cortejul ce se va include poate fi
definit atît în formă literară, cît şi cu ajutorul suboperatorului interior de selecţie.

13.1.2. Operatori de manipulare şi determinare a schemei BD


Din componenţa operatorilor de determinare a schemei BD SQL System R făceau parte
operatorii de creare şi distrugere a relaţiilor păstrate permanent şi temporar(CREATE TABLE şi
DROP TABLE) şi crearea şi distrugerea relaţiilor afişabile(CREATE VIEW şi DROP VIEW). În
limbaj şi în realizarea System R nu se interzicea utilizarea operatorilor de utilizare a schemei în
limitele tranzacţiei, care conţine operatorii de selecţie şi de manipulare cu datele. Se permitea, de
exemplu, utilizarea operatorilor de selecţie şi de manipulare cu datele, în care se accentuiează
relaţia neexistentă în baza de date în timpul compilării 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 adăuga
cîmpurile selectate la relaţie existentă. În descierea limbajului se determina, că execuţia acestui
operator nu trebuie să aducă la faptul că compilarea operatorilor asupra relaţiei să nu fie
adevărată, relaţie schema căreia se schimbă şi că sensul cîmpurilor din nou determinate în
cortejele existente a relaţiei devin nedeterminate.
13.1.3. Determinarea limitelor integrităţii şi a trigherelor
Limbajul SQL System R includea surse foarte puternice de control şi menţinere a
integrităţii BD. Sursele de control se bazau pe aparatul de limite a integrităţii(ASSERTIONS).
După ideie, limita integrităţii – este expresia logică, determinată pe starea actuală a BD,
neadevărul căreia corespunde cu starea neintegră a BD. Expresia logică a limitei integrităţii
poate conţine orice predicat admisibil în limbaj.
Mai precis, limitele integrităţii se împart în două clase: controlabile în urma executării
operatorului de manipulare cu datele şi controlabile la sfîrşitul tranzacţiei sau la executarea
operatorului special INFORCE INTEGRITY. Tipurile predicatelor ce pot fi utilizate în în
operatorii de determinare a limitelor integrităţii de clase diferite, diferă. În operaţiile din prima
clasă se controlează cortejul actual, cu care are loc manipularea. În cazul doi se controlează
relaţiile accentuate în limitele integrităţii, adică toate cortejele lor. Se deosebeşte şi reacţia
determinată în limbaj, reacţia sistemului la încălcarea limitelor integrităţii diferitor clase. În
primul caz încălcarea limitelor integrităţii aduce la înapoierea tranzacţiei în punctul care e
neapărat premărgător operaţiilor de manipulare cu datele, îndeplinirea căruia a dus la încălcarea
limitei integrităţii. În cazul doi se efecuiează înapoierea tranzacţiei pînă 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 menţinere automată a
integrităţii BD. La determinarea trigherului se spunea de condiţia de control a utilizării
trigherului(numele relaţiei şi tipul operaţiei de manipulare cu datele). Condiţia de utilizare a
trigherului(expresia logică, construită construită după regulile apropiate de regulilepentru
limitele integrităţii primei clase) şi funcţia, cre trebuie să fie îndeplinită asupra bazei de date în
caz că condiţiile aplicaţiei sunt adevărate. Aşa funcţie putea fi exprimată cu ajurtorul
operatorului de sine stătător de manipulare cu date. În timpul execuţiei funcţiei puteau să
înceapă şi alte trighere, ş.a.
Mecanismul de limitare a integrităţii şi trigherelor în System R erau foarte puternice şi
comune, dar realizarea lor eera grea(după cum s-a mai spus, trigherele aşa şi nu au mai fost
realizate în System R). O greutate adăugătoare în realizare a fost faptul că se permitea(în tot
cazul nu se interzicea de către limbaj) determinarea limitelor integrităţii şi a trigherilor în limitele
aceleieaşi tranzacţii, în care se îndeplinesc operatorii de manipulare cu datele. În cazul unei
realizărim mai ample, ar fi fost nevoie de un număr mai mare de acţiuni adăugătoare în timpul
execuţiei tranzacţiei. În afară de aceasta, în multe cazuri absenţa semanticii fixate a construcţiilor
corespunzătoare a limbajului, aduc la o înţelegere sinonimă a îndeplinirii tranzacţiei.

13.1.4. Configuraţiile bazelor de date


În limbaj se permitea utilizarea relaţiilor memorabile şi a relaţiilor dispuse a BD.
Varianta cea mai bună era utilizarea operatorilor de selecţie pentru determinarea cionfiguraţiei
sau afişării înfăţişării aparatului comun. Orice operator de selecţie poate fi utilizat pentru
determinarea configuraţiei.
În limbaj lipsesc oarecare limite în introducerea utilizării configuraţiilor: în orice operator
SQL în care se permite utilizarea numelui relaţiei memorabile, se permite şi utilizarea numelui
configuraţiei a tabloului. În SQL System R nu se vorbeşte nimic despre metoda recomandabilă
de realizare a accesului către tablouri, dar în orice metodă efectul trebuie să fie în aşa mod, ca
cînd s-ar fi realizat materializarea totală a tabloului pînă la execuţia operatorului.
Un şir de probleme, cercetări şi propuneri a născut posibilitatea potenţială de execuţie a
operatorilor de manipulare cu datele asupra tablourilor. Este clar că această posibilitate este uşor
de realizat pentru tablourile simple, dar în cazurile mult mai complicate, nu numai realizarea, dar
şi semantica operaţiilor 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 relaţional, precum este SQL, operaţiile de creare şi ştergere a
nivelului fizic, care menţin efecuarea efectivă a adresărilor către BD, a apărut î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 vorbeşte despre două tipuri de aşa structuri: indexurile şi
legăturile(links).
Indexul, în închipuirea lingvistică, abstractă a sa – este un fişier invertit, care asigură
accesul către cortejurile relaţiei corespunzătoare, 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 arăta necesitatea utilizării indexului existent în
cazul execuţiei operatorului de selecţie, hotărîrea despre aceasta se apela la realizare.
Cu ajutorul operatorului de determinare a indexului era posibil de a exprima două
afirmaţii adăugătoare referitor la schema logică a relaţiei şi la structura fizică a păstrării sale. La
determinarea indexului, utilizarea cuvîntului cheie UNIQUE înseamnă că cheiea acestui index
este cheiea posibilă a relaţiei corespunzătoare. În fond aceasta demonstrează existenţa
mecanismului adăugător de determinare a limitelor integrităţii relaţiei. Unul din indexii relaţiei
date putea fi determinat cu ajutorul cuvîntului cheie CLUSTERING. Aceasta arată necesitatea
clasterizării fizice în memoria externă a cortejurilor relaţiei cu sensuri apropiate sau egale cu cele
ale indexului.
Operatorii de determinare a legăturii, permiteau, în stilul modelului de reţea a datelor,
organizarea în memoria externă a listelor cortejurilor relaţiei date. Ca şi în cazul indexilor,
operatorii permiteau de a crea şi de a distruge aşa liste, dar nu includeau posibilitatea de a arăta
clar necesitatea utilizării listelor externe la execuţia operatorilor de manipulare cu datele şi
dificultatea efectuării calculelor preţului utilizării lor la execuţia operatorului de selecţie, au
adus la aceea că mecanismul de legături a dispărut din limbaj, de acum în stadia tîrzie de
îndeplinire a proiectului System R. De atunci, acest mecanism, după cum ştim, nu a apărut nici
într-unul din variantele SQL.

13.1.6. Autorizarea accesului la relaţie şi cîmpurile ei


O deosebire de bază a limbajului SQL, care a apărut în el de la bun început este
îndestularea protecţiei accesului la date de către sursele limbajului. Ideiea principală a acestui
pas constă în faptul că, pentru atîrnarea faţă de orice relaţie a BD şi faţă de orice coloană a
relaţiei se introduce un set definit de privilegii. Cu fiecare tranzacţie se face indirect legătura cu
identificatorul utilizatorului, de la numele căruiea ea se îndeplineşte(metodele de legătură şi de
identificare a utilizatorilor nu se fixează în limbaj şi se determină de realizare).
După crearea relaţiei noi toate privilegiile legate de această relaţie şi de toate coloanele
sale, aparţin doar utilizatorului creator al acestei relaţii. În componenţa 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 înfăptuită la aplicarea operatorului SQL
REVOKE.
Controlul împuternicirii accesului la date are loc pe baza informaţiei despre
împuternicirile existente în timpul compilării operatorului SQL corespunzător. Asemănător cu
ceea ce am spus despre limitele integrităţii şi trighere, în SQL System R lipseau careva limite în
legătură cu utilizarea operatorilor GRANT şi REVOKE. Acest fapt aducea la dificultăţi tehnice
impunătoare în realizare, dar cîte o dată şi la o înţelegere nesimilară a comportării.
Un timp îndelungat pasul spre protecţia datelor de la accesele nesancţionate era înfăptuit
practic fără critică, însă în legătură cu utilizarea răspîndită a SGBD relaţionale în adăugările
netradiţionale, tot mai des apare critica. Dacă, de exemplu, în sistema BD trebuie să se menţină o
protecţie a mai multor nivele de date, aşa sistemă de împuterniciri corespunzătoare este foarte
greu, dar cîte o date e şi imposibil de a construi pe baza surselor SQL.

13.1.7. Punctele de salvare, memorare şi înapoierea tranzacţiilor


În SQL System R au existat doi operatori speciali pentru implimentarea aşa numitelor
puncte de salvare, memorare a tranzacţiilor şi de înapoiere a tranzacţiilor spre punctul de salvare
implimentat mai devreme. În literatura referitoare la System R cercetarea acestor posibilităţi
practic nu se găseşte, de unde rezultă că ele nu au fost realizate.
Realizarea liniară a acestor posibilităţi nu duce la careva dificultăţitehnice, dar şi nu-i
chiar de folos, deoarece după execuţia parţială a înapoierii tranzacţiei pentru prelungirea cu
succes a lucrului programului adăugător, ar fi fost nevoie şi de restabilirea stării lui în punctul
corespunzător, ceea ce nicidecum nu se menţine. Este clar că, în cazul unei analize mai
amănunţite trebuie să fie legate mecanismele punctelor de salvare şi control a integrităţii. De
exemplu ar fi natural ca în timpul execuţiei operatorului ENFORCE INTEGRITY, dacă careva
limite a integrităţii se încalcă, s-ar produce înapoierea automată a tranzacţiilor către punctul de
salvare cel mai apropiat, în care încălcarea integrităţii 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 tranzacţiilor din cauza apariţiei impasurilor sincronizate.
Să accentuăm încă două proprietăţi principale a limbajului SQL System R, care în
modalităţi diferite sunt prezente în toate variantele dezvoltate, postmergătoare ale limbajului.

13.1.8. SQL implantat


În SQL System R sunt prezenţi operatori speciali, care menţin implantarea operaţiilor
SQL în limbajele tradiţionale de programare(în System R un aşa limbaj era PL/1).
Problema fundamentală de implementare a lui SQL în limbaj de programare constă în
faptul că SQL – este un limbaj relaţional, adică operatorii lui în cea mai mare parte lucrează cu
mulţimile, în timp ce în limbajul de programare, operaţiile scalare sunt de bază. Hotărîrea lui
SQL constă în faptul că în limbaj se includ adăugător operatorii, care vor permite accesul pe
corteje a rezultatului adresării la BD.
Pentru aceasta în limbaj se introduc sensul de cursor, cu care se leagă operatorul de
selecţie. Asupra unui cursor dat se poate efectua operatorul OPEN, care indică materializarea
relaţiei – rezultatul adresării, operatorul FETCH, care permite alegerea sfîrşitului de lucru cu
cursorul dat.
La realizarea unor programe adăugătoare, cu SQL implantat, o elasticitate adăugătoare
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 incluşi operatorii, care permit în timpul efectuării tranzacţiei, compilarea şi efectuarea
oricărui operator SQL.
Operatorul PREPARE induce compilarea dinamică a operatorului SQL, textul căruia se
conţine în rîndul simbolic schimbător al programului de conectare.
Operatorul DESCRIBE slujeşte pentru primirea informaţiei despre operatorul SQL dat,
pregătit mai înainte de operatorul PREPARE. Cu ajutorul acestui operator, putem afla mai întîi,
este operatorul pregătit un operator de selecţie şi în al doilea rînd dacă acesta e operator de
selecţie, de primit informaţia întreagă despre numărul şi tipurile coloanelor relaţiei rezultante.
Pentru îndeplinirea operatorului SQL pregătit mai devreme, care nu este un operator de
selecţie, este operatorul EXECUTE. Pentru îndeplinirea operatorului de selecţie pregătit dinamic,
se utilizează aparatul de cursoare cu careva deosebiri în ceea ce priveşte exercitarea adreselor
variabilelor programului de conectare, în care trebuie să fie incluse sensul coloanelor cortejului
rezultant actual.
Concluzionînd această scurtă descriere a calităţilor de bază a SQL System R, să
accentuăm, că necătînd la pregătirea tehnică nesatisfăcătoare, după ideie limbajul conţinea toate
mijloacele necesare, care permiteau utilizarea lui ca limbaj de bază a SGBD.

13.2. Limbajul SQL în realizări comerciale

13.2. Limbajul SQL în realizări comerciale


în timpul actual SQL e realizat practic în toate SGBD relaţionale comerciale, toate
firmele îşi proclamă corespunderea realizărilor sale la standartul SQL, şi într-adevăr dialectele
realizate sunt apropiate. Aceasta a avut loc nu deodată şi nu uşor.
Cele mai apropiate de System R erau două sisteme ale firmei IBM – SQL/DS şi DB2.
după cum se pare(demonstrări 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 părţi, care nu erau îndeajuns
prelucrate( de exemplu punctele de salvare) sau reaalizarea cărora ducea la dificultăţi foarte
mari(de exemplu limitele integrităţii şi trigherele). Putem numi această cale spre realizarea
comercială a SQL mişcare de sus în jos.
O altă apropiere se utiliza în aşa sisteme ca Oracle şi Informix. Necătînd la deosebirile în
metodele de realizare a acestor sisteme, realizarea SQL avea loc „de jos în sus”. În primele
realizări SQL ieşite pe piaţă, în aceste sisteme se utilizează numărul minimal şi foarte limitat a
submulţimilor SQL System R. În parte, în prima realizare cunoscută autorului a SQL SGBD
Oracle în operatorii de selecţie nu se admitea utilizarea subîntrebărilor implimentate.
Cu toate acestea, necătînd la aceste limite şi la eficacitatea slabă în primele stadii,
orientarea firmelor la menţinerea diferitor platforme de aparate şi de cointeresarea utilizatorilor
în trecerea la sistemele relaţionale a permis firmelor să dobîndească succes comercial spre
perfecţionarea realizărilor sale. În versiunile actuale Oracle şi Informix se menţin dialecte SQL
destul de puternice, cu toate că realizarea cîte o dată induce îndoieli.
O deosebire a majorităţii SGBD comerciale actuale, care îngreunează analiza dialectelor
existente SQL, este aparenţa descrierii întregi a limbajului. De obicei descrierea este împrăştiată
pe diferite manuale şi este amesticată cu descrierea limbajelor sursă, specifice pentru sistema
dată, care nu au legătură cu SQL. Dar putem spune că, colecţia de bază a operatorilor SQL,
incluzînd operatorii de determinare a schemei BD, de selecţie şi de manipulare cu datele
autorizaţiei accesului la date, menţinerea implantării SQL în limbajele de programare şi
operatorii SQL dinamic, în realizările comerciale s-a menţinut şi mai mult sau mai puţin
corespunde standartului.

13.3. Standartizarea SQL

13.3. Standartizarea SQL


Lucrările pentru standartizarea limbajului SQL au început practic concomitent cu apariţia
primelor realizări comerciale ale lui. Primul din volumul de documente, ce aparţineau 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 rînd această
variantă a limbajului nu era prelucrată tehnic în momentul cuvenit. În al doilea rînd, 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 realizări comerciale se deosebeau atît 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, utilizînd nu
numai rezultatele ştiinţifice. În rezultat standartul Internaţional SQL, primit în 1989 în marea
majoritate a părţilor sale, are un caracter comun şi permite o descifrare forte largă. În acest
standart lipsesc complet aşa compartimente principale, ca manipularea cu schema BD şi SQL
dinamic. Multe din aspectele principale ale limbajului, în corelaţie 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 selecţie şi mai includ posibilităţile de determinare
a cheilor primare şi secundare a relaţiilor şi aşa numitele limitele de control a integrităţii, care
reprezintă din sine submulţimea limitelor integrităţii SQL System R de clasa întîi. Sursele de
determinare a cheilor exterioare permit formularea uşoară a aşanumitor necesităţi a integrităţii
BD după legături. Această necesitate răspîndită poate fi formulată şi pe baza mecanismului
general a limitelor integrităţii SQL System R, dar formularea pe baza sensului cheii externe este
mai simplă şi mai înţeleasă. Văzînd necompletarea standartului SQL, pe fonul încheierii lucrului
aupra prelucrării acestui standart, specialiştii diferitor firme au pornit lucrul cu standartul SQL2.
acest lucru de asemenea s-a prelungit cîţiva ani, au fost elaborate o mulţime de proiecte de
standarte, pînă cînd în sfîrşit, î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 tranzacţiile(din nou au apărut punctele de
salvare, memorare) şi cu sesiile(sesia - este o succesiune a tranzacţiilor, în limitele cărora se
păstrează relaţia temporală), conexiunea la BD, SQL dinamic. În sfîrşit sunt standartizate
rfelaţiile-registre a BD, ceea ce nu-i legat neapărat de limbaj, dar foarte mult acţionează asupra
realizării.
Uimeşte faptul lipsei în standart a surselor de dirijare cu indexii. Desigur aceste surse, de
obicei, se află departe de operaţiile de bază SQL, dar autorului nu-i este cunoscută nici o
realizare în care ei ar lipsi.
În sfîrşit, odată cu finisarea lucrului saupra standartului SQL2 a luat naştere prelucrarea
standartului SQL3. se presupune că SQL3 va conţine mecanismul trigherilor şi posibilitatea
utilizării tipurilor abstracte de date. Sensul de standart se planifică doar în anul 1995. să sperăm
că macăr de această dată va fi posibil de urmărit prelucrarea lui.
Concluzionînd această scurtă excursie prin istoria standartizării SQL, să observă, că în
cele mai multe cazuri(nu în toate) procesul standartizării 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!).
Lecţia 14. Limbajul standart a bazelor de date SQL

Lecţia 14. Limbajul standart a bazelor de date SQL


În această lecţie vom analiza pe scurt proprietăţile de bază a limbajului Lecţia 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 menţin următoarele 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 cuvîntului tipului dat. Să atragem atenţia, că în 14.1. Tipuri de date/89
lipseşte tipul cuvintelor de mărime variabilă. Cu toate că în multe realizări ele se admit.
Cuvintele literare ale simbolurilor se reprezintă în formă de ‚şir de simboluri’(de exemplu
‚exemple’).
Reprezentări 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 scăpată scara, atunci ea se poate socoti ca
fiind egală cu „0”, iar dacă este scăpată 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 sfîrşit, 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 atenţia că cu toate că odată
cu utilizarea limbajului SQL putem determina schema BD, care conţine datele oricărui tip din
cele numite, posibilitatea de a le utiliza în sistemele adăugătoare 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 realizări SQL tipurile de date cu scară şi precizie în genere nu se menţin.
Cu toate că regulile de implimentare a SQL în limbajul C nu se determină în SQL/89, în
majoritatea relizărilor, ce susţin aşa implimentare, are loc următoarea corelaţie î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 aşa corelaţie este admisă în SQL/92).
Să atenţionăm că, în marea majoritate a realizărilor SQL, se menţin unele tipuri de date
adăugătoare, ca de exemplu, DATE, TIME, INTERVAL, MONEY. Unele din aceste tipuri se
specifică în standartul SQL/92, dar în realizările actuale realizările 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 părţile mai slabe
ale standartului şi care permit o interpretare diferită. Mai mult ca atît, nu ne este cunoscută nici o
realizare , în care s-ar menţine fix aşa set de surse de determinare a schemei.
De aceea pentru obţinerea mobilitatea sistemeiadăugătoare î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 atenţia, că în SQL/89 în genere lipsesc carevasurse de schimbare a schemei
BD: nu-I posibilitatea de a înlătura schema tabelului; de adăuga în schema tabelului o coloană
nouă, ş.a. În toate realizările aşa surse se menţin, dar ele pot să difere şi după sintactică şi după
semantică.
Necătînd la lipsa oricăror speranţe că vom reuşi să întîlnim o realizare, ce ar susţine
limbajul de determinare a schemelor SQL/89, noi, pe scurt, vom descrie acest limbaj(fără
mijloace sintactice), pentru a aprecia la nivelul cuvenit posibilităţile SQL/89 şi de a primi măcar
careva surse de comparaţie a diferitor realizări.

14.2.1. Operatorul de determinare a schemei


În legătură, 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>.
Paşii către determinarea schemei în SQL/89 constau în faptul că toate tabelele cu unl şi
acelaşi 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 tradiţional de programare.
În operatorul de determinare a schemei, se conţine identificatorul împuternicirilor şi lista
elementelor schemei, unde fiecare din elemente poate fi determinantul tabelului, determinantul
afişării(view) sau determinantul privelegiilor. Fiecare din aceştideterminanţi se reprezintă de un
operator aparte SQL/89, dar toţi ei, cum s-a mai spus, trebuie să fie implementaţi în operatorul
determinării schemei. Pentru aceşti operatori, vom scrie sintactica, căci aceasta va permite
descrierea deosebirilor lor.

14.2.2. Determinarea tabelului


Operatorul de determinare a tabelului are sintactica următoare:
<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 slujeşte sau pentru determinarea coloanei, sau pentru determinarea limitelor
integrităţii a tabelului determinat. Este nevoie de prezentat macăr a unei determinări a coloanei.
Operatorul CREATE TABLE determină, aşa numitul tabel de bază, adică depozitul real de date.
Pentru determinarea coloanelor tabelului şi a limitelor integrităţii se utilizează operatori speciali,
care trebuie incluşi în operatorul de determinare a tabelului.

14.2.3. Determinarea coloanei


Operatorul de determinare a coloanei se descrie prin regula sintactică următoare:
<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 conţine şi două dispărţituri secundare, de care ne
putem lipsi: dispărţitura coloanei propriuzisă şi despărţitura limitelor integrităţii coloanelor. În
despărţitura însemnătăţii propriuzisă se arată însemnătatea, care trebuie să fie inclusă în rîndul,
care se înscrie în tabelul dat, dacă înseamnătate acestei coloane nu se dă. Însemnătatea
propriuzisă poate fi dată sub formă de constantă literară cu tipul, care corespunde tipului
coloanei date; pe calea definirii cuvîntului cheie USER, căruiea, în timpul execuţiei operatorului
de introducere a cuvîntului, îi corespunde cuvîntul simbolic, ce conţine numele utilizatorului
curent(în acest caz coloana trebuie să aibă tipul cuvintelor simbolice); sau pe calea definirii
cuvîntului cheie NULL, care indică că însemnătatea propriuzisă este o însemnătate
nedeterminată. Dacă însemnătatea coloanei propriuzisă nu-i specificată, şi în despărţitura
limitelor integrităţii coloanei este arătat NOT NULL, atunci înceracrea de a introduce în tabel
cuvîntul cu însemnătatea nespecificată a coloanei date va duce la greşeală. Definirea în
despărţitura de limitare a integrităţii NOT NULL duce la crearea unei limite a integrităţii de
încercare pentru tot tabelul(uite subdiviziunea următoare) „CHECK (C IS NOT NULL)” (unde C
– numele coloanei date). Dacă limita NOT NULL nu-i dată, şi despărţitura propriuzisălipseşte,
atunci are loc crearea despărţiturii propriuzise DEFAULT NULL. Dacă este dată specificarea
unicalităţii, atunci are loc crearea specificaţiei corespunzătoare a unicalităţii pentru tabel.
Dacă în despărţitura limitelor integrităţii este dată limita după legătură a coloanei date
(<reference specification>), atunci are loc crearea determinării limitelor integrităţii
corespunzătoare după legături pentru tabel:
FOREIGN KEY(C) <reference specification>
În sfîrşit, dacă este dată limita de control a coloanei, atunci condiţiile de căutare a acestei
limite trebuie să se bazeze doar pe această coloană, şi de asemenea are loc crearea
corespunzătoare a limitei de control a integrităţii tabelului.

14.2.4. Determinarea limitelor integrităţii tabelului


Limitele integrităţii tabelului posedă sintactica următoare:
<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 cîteva limite a integrităţii, inclusiv şi cele ce se creează
de către limitele integrităţii coloanelor.
Standartul SQL/89 adoptă, că limitele tabelului practic se controlează la îndeplinirea
fiecărui operator SQL.
Atenţie: posedarea setului corect selectat de limite a BD este foarte important pentru
funcţionarea temeinică a sistemului informaţional aplicat. Cu toate acestea în unele SGBD
limitele integrităţii practic nu se menţin. De aceea la proiectarea sistemului aplicativ trebuie de
luat decizia ce este mai principal: să ne bazăm pe susţinerea limitelor integrităţii, dar să ne
limităm setul posibilelor SGBD, sau să ne dezicem de utilizarea lor la nivelul SQL, păstrînd
posibilitatea utilizării nu a celor mai noi SGBD. În continuare T arată tabelul, pentru care se
determină limitele integrităţii.
Limita unicităţii
Fiecare nume a coloanei, din lista unicităţilor 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
unicalităţilor trebuie să fie dată pe limita coloanei NO NULL. Printre limitele unicalităţii T nu
trebuie să fie mai mult de o singură determinare a cheii primare(limita unicalităţii cuvîntului
cheie PRIMARY KEY).
Lucrul limitei unicalităţii constă în faptul că, în tabelul T nu se admite apariţia a două sau
mai multe rînduri, sensurile coloanelor unicalităţii cărora coincid.
Limita după legătură
Limita după legătură 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ă condiţia asupra conţinutului ambelor
acestor tabele, fără de care legăturile le putem considera corecte.
Dacă lista coloanelor CT1 este specificată clar în determinarea limitei după legături,
atunci trebuie ca această listă să intre într-o oarecare determinare a unicalităţii tabelului T1. dacă
lista CT1 nu se specifică în determinarea limitei după legături 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
corespunzător şi nu trebuie să apară în liste mai mult de o singură dată. Listele coloanelor CT şi
CT1 trebuie să conţină un număr egal de elemente şi coloana tabelului T, identificată de
elementul i a listei CT trebuie să fie de acelaşi tip ca şi coloana tabelului T1, identificată de
elementul i a listei CT1.
După determinare, tabelele T şi T1 corespund limitei date după legături, dacă pentru
fiecare rînd S a tabelului T aşa că toate însemnătăţile coloanelor S identificate de lista CT, nu
sunt nedeterminate, există rîndul S1 a tabelului T1, aşa că, însemnătatea coloanelor S1,
identificate de lista CT1, sunt egale după poziţia însemnătăţilor coloanelor S, identificate de lista
CT. Mai clar acest lucru poate fi formulat în felul următor: limita după legături se satisface dacă
pentru fiecare legătură corectă există un obiect, la care ea s-ar trimite. În terminologia deprinsă
de programatori, limita după legături nu permite crearea legăturilor „atîrnate”, care nu conduc
înspre nici un obiect.
Limita de control
Limita de control specifică condiţia, care trebuie să fie satisfăcută de fiecare rînd în parte
a tabelului T. Această condiţie nu trebuie să conţină subadresări, specificaţii a funcţiilor agregate
dar şi a legăturilor spre parametrii sau variabile externe. În ea pot intra doar numele coloanelor
tabelului dat şi constantele literare.
Tabelul satisface limita de control a integrităţii în acel caz şi numai în acela, cînd calculul
condiţiei pentru nfiecare rînd a tabelului ne dă TRUE.
Atenţie: În unele realizări se permite mecanisme mai lărgite a limitelor după legături şi a
limitelor de control. Trebuie să fim atenţi, dacă nu dorim să ieşim din limitele posibilităţilor
standartului.

14.2.5. Determinarea configuraţiilor


Mecanismul configuraţiilor(view) este o sursă puternică a limbajului SQL, ce permite
ascunderea structurii real a BD de careva utilizatori, pe baza determinării configuraţiei BD, care
este o oarecare adresare către BD memorabilă cu coloane enumărate, dar pentru utilizator nu se
deosebeşte cu nimic de tabelul de bază a BD(ţinînd seama de limitele tehnice). Orice realizare
trebuie să garnteze, că starea tabelului dat coincide întocmai cu starea tabelelor de bază, pe baza
cărora este determinată configuraţia. De obicei determinarea tabelului închipuit (materializarea
adresării corespunzătoare) are loc de fiecare dată la utilizarea configuraţiei.
În standartul SQL/89 operatorul de determinare a configuraţiei 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 schimbător(adică în corespundere cu V putem utiliza
operatorii DELETE şi UPDATE) în acel caz şi doar în acela, dacă se îndeplinesc următoarele
condiţii pentru specificarea adresării: în lista de selecţie nu se indică cuvîntul cheie DISTINCT;
fiecare expresie afirmativă în lista de selecţie este o specificaţie a coloanei şi specificaţia unei
coloane nu apare mai mult de o singură dată; în despărţitura FROM este arătat doar un singur
tabel care este sau tabel de bază sau tabelul închipuit schimbător; în condiţia de selecţie a
despărţiturii WHERE nu se utilizează subadresări; în expresia tabelară lipsesc despărţiturile
GROUP BY SO HAVING.
Atenţie: Aceste limite sunt foarte puternice. În realizări ele pot fi slăbite. Dar dacă să
aspirăm la mobilitate, n-ar fi de dorit să utilizaţi posibilităţile lărgite.
Dacă în lista de selecţie în specificarea adresării este măcar o singură expresie afirmativă,
compusă nu dintr-o singură specificaţie a coloanei, sau dacă un nume a coloanei face parte din
lista de selecţie mai mult decît o singură dată, determinarea configuraţiei trebuie să conţină lista
numelor coloanelor tabelului închipuit. Mai simplu trebuie de enumerat coloanele tabelului
închipuit, dacă aceste nume nu sunt moştenite de la coloanele tabelelor despărţiturii FROM de
specificare a adresării.
Cererea WITH CECK OPTION în determinarea configuraţiei are sens numai în cazul
determinării tabelului închipuit schimbător, care se determină de specificarea adresării, care
conţine despărţitura WHERE. În cazul posedării acestei cereri nu se admit schimbări a tabelului
închipuit ce duc la apariţia în tabelele de bază a rîndurilor, ce nu se văd în tabelul închipuit, adică
aşa rînduri, care nu îndestulează condiţia de căutare a despărţiturii WHERE de specificare a
adresării. Dacă WITH CECK OPTION în determinarea configuraţiei lipseşte, aşa control nu se
înfăptuieşte.

14.2.6. Determinarea privelegiilor


În corespondenţă cu ideologia limbajului SQL controlul drepturilor de acces a
utilizatorului dat către tabele BD are loc pe baza mecanismului de privelegii. De fapt, acest
mecanism constă din aceea, că pentru îndeplinirea oricărui lucru asupra tabelului utilizatorul
trebuie să posede privelegiile corespunzătoare(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 operaţiilor asupra acestui tabel.
În componenţa acestor privelegii intră şi privelegiul de transmitere a tuturor sau a cărorva
privilegii în legătură cu tabelul dat către alţi utilizatori, inclusiv privelegiul de transmitere a
privelegiilor. Uneori are loc şi apariţia 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 rînd, „împărţirea” privelegiilor este posibilă doar în cazul dewterminării
tabelului. În al doilea rînd, utilizatorul, ce a primit careva privilegii de la alţi utilizatori, le poate
transmite mai departe doar în cazul determinării schemei.
Determinarea privilegiilor are loc după sintactica următoare:
<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ă înţelegem sensul mecanismului de determinare a privelegiilor în
SQL/89. să atragem atenţia doar la aceea că avem nevoie de posesia privelegiilor.
PREFERENCES în legătură cu coloanele selectate din tabelul T1 pentru a avea posibilitatea, la
determinarea tabelului T, să determinăm limita după legături dintre acest tabel şi tabelul existent
la momentul dat T1.
Cu toate că în caz general în toate SQL-SGBD orientate se menţine mecanismul de
protecţie a accesului pe baza privelegiilor, realizările se pot de obicei deosebi prin detalii. Pentru
a tinde spre crearea unui sistem mobil adăugător aplicativ, atunci acest lucru analizat mai sus
trebuie localizat.

Lecţia 15. Limbajul SQL. Surse de manipulare cu datele

Lecţia 15. Limbajul SQL. Surse de manipulare cu datele


15.1. Structura adresărilor
Pentru a vorbi mai mult sau mai puţin despre structura adresărilor în standartul Lecţia 15.
Limbajul SQL. Surse de manipulare cu datele/89 trebuie să începem cu o mulţime 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 construcţii sintactice, care încep cu cuvîntul cheie
SELECT: specificaţia cursorului(cursor specification), operatorul selecţiei(select statement) şi
subadresarea (sub query). Cea mai de bază este construcţia sintactică „expresie tabelară”(table
expreion). Semantica expresiei tabelare constă în faptul că pe baza utilizării consecutive a
dispărţiturilor from, where, group, by so hawing, din tabelele date în from se construieşte o
tabelă rezultantă, în care ordinea consecutivităţii rîndurilor nu este determinată şi printre rînduri
se pot găsi dublicate(adică, în caz general, tabelul-rezultant al expresiei tabelare este o mulţime
de rînduri). Într-adevăr anume structura expresiei tabelare în cea mai mare parte caracterizează
limbajul SQL/89. în continuare vom vedea structura şi sensul dispărţiturilor expresiei tabelarte,
dar mai înainte vom analiza cele trei tipuri de construcţii 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 rînduri la rezultatul adresării către BD. Către expresiile tabelare, ce
participă la specificarea cursorului, nu se aplică nici o limită. După cum se vede din mulţimea de
reguli sintactice, la determinarea specificaţiei cursorului se utilizează trei construcţii
adăugătoare: specificarea adresării, expresia adresărilor şi despărţitura ORDER BY.
Specificarea adresării
În specificarea adresării se dă lista de selecţie(lista expresiilor afirmative asupra
sensurilor coloanelor rezultatului expresiei tabelare şi a constantelor). În rezultatul utilizării
listei de selecţie la rezultatul expresiei tabelare are loc construirea noului tabel, se conţine acelaşi
număr de rînduri, dar în general alt număr de coloane, ce conţin rezultatele calculelor expresiilor
afirmative corespunzătoare din lista de selecţie. În afară de aceasta, în specificarea adresprii se
pot conţine cuvinte cheie ca: ALL sau DISTINCT. La posesia cuvîntului cheie DISTINCT din
tabel, a expresiei tabelare primite utilizînd în rezultat lista de selecţie, se şterg rîndurile dublicate;
la selectarea ALL (sau pur şi simplu la lipsa lui DISTINCT) nu are loc ştergerea rîndurilor
dublicate.
Expresia adresărilor
Expresia adresărilor este o expresie care se construieşte după regulile sintactice date pe
baza specificaţiei adresărilor. Unica operaţie care e permisă de a fi utilizată în expresiile
adresărilor, este operaţia UNION(unirea tabelelor) cu posibilitatea de felul următor UNION
ALL. Către tabelele-operanţilor expresiilor adresărilor se aplică acea cerinţă, că toate ele trebuie
să posede unul şi acelaşi număr de coloane şi coloanele corespunzătoare a tuturor operatorilor
trebuie să fie de unul şi acelaşi tip. Expresia adresărilor se calculează de la stînga spre dreapta,
ţinînd seama de ghilimele. La execuţia operaţiei UNION are loc unirea obişnuită a operatorilor,
adică în tabelul rezultant se şterg dublicatele. La îneplinirea operaţiei UNION ALL se formează
tabelul rezultant, în care se pot conţine rînduri dublicate.
Dispărţitura ORDER BY
În sfîrşit despărţitura ORDER BY permite crearea ordinii dorite de privire a rezulltatului
expresiei adresărilor. 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 adresărilor şi pentru fiecare coloană se arată ordinea rîndurilor rezultatului în
dependenţă de însemnătatea acestei coloane(ASC – după creştere şi DESC – în descreştere).
Coloanele pot fi date prin numele sale în cazul cînd: expresia adresărilor nu conţine operaţiile
UNION şi UNION ALL; în lista de selecţie a specificaţiei adresării acestei coloane îi corespunde
o expresie afirmativă, compusă doar din numele coloanei. În toate celelalte cazuri, în
despărţitura ORDER BY trebuie să fie dat numărul de ordine a coloanei în tabelul rezultant al
expresiei adresării.

15.1.2. Operatorul de selecţie


Operatorul de selecţie – este un operator aparte a limbajului SQL/89, ce permite de a
primi rezultatul adresării în programul aplicat fără activarea cursorului. De aceea operatorul de
selecţie are sintactica ce diferă de sintactica de specificare a cursorului şi la execuţia lui apar
limitări a rezultatului expresiei tabelare. De fapt şi una şi alta este dictată de specificul
operatorului de selecţie ca operator unar a SQL: la execuţia lui rezultatul strebuie să fie inclus în
variabilele programului aplicativ. De aceea în operator apare dispărţitura IN TO, ce conţine lista
variabilelor a programului aplicativ şi apare acea limită că tabelul rzultant trebuie să conţină nu
mai mult de un rînd. La rîndul său rezultatul expresiei tabelare de bază trebuie să conţină nu mai
mult de un rînd, dacă operatorul de selecţie nu conţine specificaţia DISTINCT şi tabelul, primit
în urma apelării la lista de selecţie către rezultatul expresiei tabelare, nu trebuie să conţină mai
mult de un rînd care nu coincide, dacă specificaţia DISTINCT este dată.
Atenţie: În dialectul SQL SGBD Oracle se menţine varianta lărgită a operatorului
selecţiei, rezultatul căruiea nu e neapărat tabelul dintr-un singur rînd. Aşa lărgire nu se susţine
nici în SQL/89, nici în SQL/92.

15.1.3. Subadresarea
În sfîrşit, ultima construcţie SQL/89, care poate conţine expresii tabelare – este
subadresarea, pedică adresarea, care poate fi inclusă în predicatul condiţiei de selecţiei a
operatorului SQL. Tabelul rezultant trebuie să conţină fix o singură coloană. De aceea în regulile
de sintaxă, ce determină subadresarea, în loc de lista de selecţie este arătată „expresia expresia,
ce determină valoarea”, adică expresia afirmativă. Să atenţionăm, că deoarece subordonarea
întotdeauna este inclusă în orice alt operator SQL, atunci în calitate de constante în expresia
afirmativă de selecţie şi în expresia logică a despărţiturilor WHERE şi HAVING. Se permite
utilizarea coloanelor a rîndurilor crescătoare a tabelelor, ce participă în adresările mai mari ca
nivelul exterior. Mai amănunţit 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 despărţiturilor FROM, WHERE, GROUP şi HAVING pentru tabelele date în lista
FROM. Despărţitura FROM are sintaxa următoare:
<from clause>::=
FROM <table reference>
({,<table reference>}…)
<table reference>::=
<table name>[<collection name>]

15.2.1. Despărţitura FROM


Ca rezultat a îndeplinirii despărţiturii FROM este derivarea extinsă a tebelelor, date de
lista tabelelor despărţirii FROM. Derivarea extinsă este de aceea că, în calitate de rezultat şi
operanţi se admit mulţimile. În standart se determină în felul următor: derivarea extinsă este R,
unde R este o multimulţime a tuturor rîndurilor r aşa, că r este concatenarea tuturor rîndurilor
dint toate tabelele identificate în aşa ordine, în care ele au fost identificateordinul lui R este
reprezintă derivata ordinelor tabelelor identificate. Numărul de ordine a coloanei în R este n+S,
unde n este numărul coloanei create în tabelul numerat T, iar S este suma puterulor tuturor
tabelelor, alături 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 despărţituri a expresiei
tabelare pentru legăturile cu rîndurile anume a acestei intrări a tabelului.
Dacă expresia tabelară conţine doar despărţitura FROM(aceasta-i unica şi neapărata
despărţitură a tabelului), atunci rezultatul expresiei tabelare coincide cu rezultatul despărţiturii
FROM.

15.2.2. Depărţitura WHERE


Dacă în expresia tabelarăeste prezentă despărţitura WHERE, atunci următoarea se va
calcula anume ea. Sintaxa acestei despărţituri 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 despărţiturii WHERE are loc după regulile: fie R rezultatul despărţirii FROM.
Atunci condiţiile căutării se admit pentru toate rîndurile R şi ca rezultat a dispărţiturii WHERE
este tabelul format din acele rînduri R, pentru care rezultatul calculelor condiţiilor de căutare
este true. Dacă condiţiile de selecţie includ subadresări, 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 aşa, ca şi cum fiecare subadresare într-adevăr s-ar fi calculat din nou
pentru fiecare cortej R). Să atenţionăm că, deoarece SQL/89 admite prezenţa în baza de date a
expresiilor nedeterminate, atunci calculul condiţiilor de căutare nu are loc în logica booleană ci
în logica trisemnificativă cu valori true, false şi unikown(nedeterminare). Operaţiile booleene
AND, OR şi NOT operează în logica trisemnificativă aşa:
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 condiţiilor de căutare în corespundere cu SQL/89 se pot găsi
următoarele predicate: predicatul comparaţiei, predicatul between, predicatul in, predicatul like,
predicatul null, predicatul cuantificării, predicatul exists. Să atenţionăm că în toate realizările
SQL asupra eficacităţii implimentării adresării influenţează mult prezenţa, în condiţia de căutare,
a predicatelor simple de comparaţie( predicate ce reprezintă comparaţia coloanei tabelului în
raport cu o constantă, prezenţa acestor predcicate dă posibilitate SGBD de a utiliza indexi la
îndeplinirea adresării, adică de a evita parcurgerea întregului tabel. În principiu, limbajul SQL le
permite utilizatorilor de a nu-şi face griji în privinţa setului concret de predicate în condiţia de
selecţie(ele să fie doar sintactic şi semantic corecte), la utilizarea reală a limbajului SQL – a
SGBD orientate, aşa detalii tehnice trebuie de luat în vedere.
Predicatele de comparaţie
Sintaxa predicatului de comparaţie se determină după regulile:
<comparison predicate>::=
<value expresion><comp op>
{<value expresion>|<subquery>}
<comp op>::=
=|<>|<|>|<=|>=
Prin „<>” se indică operaţia de neegalitate. Expresiile neafirmative a părţilor stîngi şi
drepte a predicatului de comparaţie se construiesc după regulile generale de construire a
expresiilor afirmative şi pot include în caz general numele coloanelor tabelelor din despărţitura
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 operaţiei de comparaţie e dat de subadresare, atunci limita
adăugătoare este aceea, că puterea rezultatului subadresării nu trebuie să fie mai mare ca
unitatea. Dacă macăr unul din operatorii operaţiei de comparaţie are sens nedeterminat sau sau
dacă operatorul din dreapta este o subadresare cu rezultat pustiu, atunci rezulatul predicatului
de coomparaţie este egal cu unikown.
Rezultatul expresiei afirmative nu este determinat, dacă în calculul lui participă macăr 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 rînduri, 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 următoare:
<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 următoare:
<in prredicate>::=
<value expression> {NOT] IN
{<subquery>|(<in value list>)}
<in value list>::=
<value specification>
{,<value specification>}…
Tipurile operatorului din stînga şi valorile din lista operatorului din dreapta(să amintim că
tabelul rezultant a subadresării trebuie să conţină fix o coloană) trebuie să fie compatibile.
Predicatul va avea rezultatul true atunci şi numai atunci, cînd valoarea operantului din
stînga coincide macăr 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 „subînţeles” a comparaţiei „x=y”( unde x are valoarea expresiei afirmative a
operantului stîng) 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 următoarea 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 stînga şi a exemplului trebuie să fie tipuri a
simbolurilor caracteriale. În despărţitura ESCAPE trebuie să fie specificat simbolul unical.
Rezultatul predicatului este true, dacă pattern este subrîndul coloanei date. Cu toate acestea, dacă
depărţitura ESCAPE lipseşte, 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ă despărţitura ESCAPE este prezentă şi specifică un oarecare simbol
singular x, atunci perechile de simboluri „x_” şi „x%” sunt simbolurile singulare „*” şi „%”
corespunzător.
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 cînd 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 următoare:
<quantified predicate>::=
<value expresion><comp op><cuantifier><subquery>
<quantifier>::=
<all>|<some>
<all>::=ALL
<some>::=SOME|ANY
Vom nota cu x rezultatul calculului expresiei afirmative părţii stîngi a predicatului, iar cu
S rezultatul calculului subadresării.
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 macăr 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
macăr pentru un s din S. în celelalte cazuri valoarea predicatului „x<comp op> SOME S” este
unikown.
Predicatul exists
Predicatul exists are sintaxa următoare:
<exists predicate>::=
EXISTS <subquery>
Valoarea acestui predicat în totdeauna este true sau false, şi această valoare este true
atunci şi numai atunci, cînd rezultatul calculului subadresării nu-i nul.

15.2.3. Despărţitura GROUP BY


Dacă în expresia tabelară este prezentă despărţitura GROUP BY, atunci ea se va executa
următoarea. Sintaxa ei este următoarea:
<group by clause>::=
GROUP BY <column specification>
[{,<column specification>}…]
Dacă vom nota cu R tabelul, care are rezultatul despărţiturii precedente(FROM sau
WHERE) atunci în calitate de rezultat a despărţiturii GROUP BY este despărţirea lu R într-o
mulţime de rînduri, care-i alcătuită din numărul minim a aşa grupe, că pentru fiecare coloană din
lista coloanelo despărţiturii GROUP BY în toate rîndurile fiecărei grupe, ce include mai mult de
un rînd, valorile acestei coloane sunt egale. Pentru determinarea rezultatului despărţiturii
GROUP BY în standart se utilizează termenul „tablou grupat”.

15.2.4. Despărţitura HAVING


Ultima la calculul expresiei tabelare se utilizează despărţitura HAVING(dacă ea e
prezentă). Sintaxa ei este:
<having clause>::=
HAVING <search condition>
Despărţitura HAVING poate să apară condiţionat în expresia tabelară numai în cazul
cînd în ea e prezentă despărţitura GROUP BY. Condiţia de căitare a acestei despărţituri dă
condiţie asupra grupului de rînduri a tabelului grupat. De fapt despărţitura HAVING poate fi
prezentă şi în expresia tabelară ce nu conţine GROUP BY. În acest caz se presupune că
rezultatul calculului despărţiturilor anterioare reprezintă un tabel grupat, format dintr-o grupă
fără coloane de grupare selectate.
Condiţia de căutare a despărţiturii HAVING se construieşte după aceleaşi reguli
sintactice ca şi condiţia de căutare WHERE şi poate include aceleaşi predicate. Însă sunt careva
limite speciale sintactice în cazul condiţiei de căutare a specificaţiilor coloanelor tabelelor din
despărţitura WHERE a expresiei tabelare date. Aceste limite rezultă de aceea că condiţiile de
căutare a despărţiturii HAVING dă condiţie pe toată grupa şi nu pe rînduri în parte. De aceea în
expresiile afirmative a predicatelor, care intră în condiţia de selecţie a despărţiturii HAVING,
putem utiliza direct doar specificaţiile coloanelor, arătate în calitate de coloane de grupare în
despărţitura GROUP BY. Celelalte coloane pot fi specificate doar în interiorul specificaţiei
funcţiei de agregat COUNT, SUM, AVG, MIN şi MAX, care în cazul dat, calculează o oarecare
valoare de agregat a întregii grupe de rînduri. La fel este şi cu subadresările, ce intră în
componenţa predicatelor condiţiilor de selecţie a despărţiturii HAVING: dacă în subadresare se
utilizează caracteristica grupei date, atunci ea poate fi dată doar pe calea schiţării la coloanele
grupării.
Rezultatul îndeplinirii despărţiturii HAVING este tabelul grupat ce conţine doar acele
grupări de rînduri, pentru care rezultatul calculului condiţiei de căutare este true. Dacă
despărţitura HAVING e prezentă în expresia tabelară, care nu conţine GROUP BY, atunci
rezultatul îndeplinirii ei va fi sau un tabel nul, sau rezultatul îndeplinirii despărţirilor anterioare a
expresiei tabelare, fiind privit ca o singură grupă, fără coloane de grupare.

15.3. Funcţiile de agregat şi rezultatele adresărilor

15.3. Funcţiile de agregat şi rezultatele adresărilor


Funcţiile de agregat(în standartul SQL/89 ele se numesc funcţii asupra mulţimilor) se
determină în SQL/89 de următoarele 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 funcţii
standarte de agregat: COUNT – numărul rîndurilor sau a valorilor; MAX – valoarea maximă;
MIN – valoarea minimă; SUM – valoarea sumei şi AVG – valoarea medie.

15.3.1. Semantica funcţiilor de agregat


Funcţiile de agregat sunt destinate pentru a calcula o valoare oarecare pentru mulţimea de
rînduri dată. Aşa mulţime de rînduri poate fi grupa de rînduri, dacă funcţia de agregat se
utilizează pentru tabelul grupat, sau tabelul întreg. Pentru toate funcţiile agregat, în afară de
COUNT(*), ordinea(cerută de semnatică) calculării este: pe baza parametrilor funcţiei de agregat
din mulţimea de rînduri dată se creează lista valorilor. Apoi pe baza acestei liste de valori are loc
calculul funcţiei. Dacă lista este nulă, atunci valoarea funcţiei COUNT pentru ea este zero, iar
valoarea celeilalte funcţii – null.
Fie T tipul valorilr din această listă. Atunci rezultatul calculului funcţiei COUNT este un
număr întreg cu scara şi precizia determinate în realizare. Tipul rezultatului valorilor funcţiilor
MIN şi MAX coincid cu T. La calculul funcţiei SUM şi AVG tipul T nu trebuie să fie de tipul
rîndurilor simbolice, iar tipul rezultatului funcţiei 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 funcţiei COUNT(*) are loc pe calea enumărării numărului de rînduri în
mulţimea dată. Toate rîndurile se consideră diferite, chiar dacă ele sînt compuse dintr-o singură
coloană cu valoarea null în toate rîndurile.
Dacă funcţia de agregat este specificată fără cuvîntul cheie DISTINCT, atunci lista
valorilor se construieşte 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
înlătură valorile dublicate. Apoi se calculează funcţia dată.
Dacă funcţia de agregat este specificată fără cuvîntul cheie DISTINCT(sau cu cuvîntul
cheie ALL), atunci lista de valori se formează din valorile expresiei afirmative, ce se calculează
pentru fiecare rînd al expresiei date. Apoi din listă se înlătură valorile nedeterminate şi se
calculează funcţia de agregat.
Atrageţi atenţia că în acest caz nu se permite utilizarea funcţiei COUNT.
Atenţie: Ambele limite, arătate în abzaţele anterioare, sunt mai mult tehnice decît
principiale şi pot să lipsească în realizări 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 adresărilor


Funcţiile de agregat pot fi utilizate în specificarea cursorului, a operatorului de selecţie şi
în subadresare după cuvîntul cheie SELECT(în această subdespărţitură vom numi aşa construcţii
ca listă de selecţie, şi să nu uităm că în caz de subadresare această listă e formată doar dintr-un
element) şi în condiţia despărţiturii HAVING. Standartul permite utilizarea mult mai exotică a
funcţiilor de agregat în subadresări( funcţia de agregate pe grupe de corteje a adresării
exterioare), dar în practică se întîlnesc foarte rar.
Să cercetăm diferite cazuri de utilizare a funcţiilor de agregat în lista de selecţie în
dependenţă de tipul expresiei tabelare.
Dacă rezultatul expresiei tabelare R nu este un tabel grupat, atunci apariţia macăr a unei
funcţii de agregat din mulţimea de rînduri R în lista de selecţie duce la ceea, că R este privită ca
un tabel grupat, care-i alcătuit dintr-o(sau nici una) grupă ce nu are coloane de grupare. De
aceea, în acest caz, în lista de selecţie nu se permite utilizarea directă a specificaţiilor rîndurilor
R: toate ele trebuie să se găsească în interiorul specificaţiilor funcţiilor de agregat. Ca rezultat a
adresării e tabelul, cu nu mai mult de un rînd, primit pe calea utilizării funcţiilor de agregat R.
La fel stau lucrurile şi în cazul, cînd R este un tabel grupat, dar expresia tabelară nu
conţine despărţitura GROUP BY( şi deci conţine despărţitura HAVING). Dacă în cazul abzaţului
anterior erau două variante de creare a listei de selecţie: numai cu indicarea directă a coloanelor
R sau numai cu indicarea lor în interiorul specificaţiilor a funcţiilor de agregat), atunci în cazul
dat este posibilă numai a doua variantă. Rezultatul expresiei tabelare este afişat de către tabelul
grupat, format dintr-o singură grupă şi rezultatul adresării poate fi format doar pe calea aplicării
funţiilor de agregat pentru acest grup de rînduri. Din nou ca rezultat a adresării avem un tabel,
ce conţine nu mai mult de un rînd, primit pe calea aplicării funcţiilor de agregat pentru R.
Cazul cînd R este un tabel „adevărat” grupat, adică expresia tabelară conţine despărţitura
GROUP BY şi rezultă că este determinată cel puţin o coloanăde grupare. În acest caz regulile de
formare a listei de selecţie coincid cu regulile de formare a condiţiei de selecţie a despărţiturii
HAVING: permite utilizarea directă a specificaţiei coloanei de grupare, dar specificaţiile
celorlalte coloane R, pot să apară doar în interiorul specificaţiilor funcţiilor de agregat. Ca
rezultat a adresării este tabelul, în care numărul de rînduri este egal cu numărul de grupuri în R,
şi fiecare rînd se formează pe baza valorilor coloanelor de grupare şi a funcţiilor de agregat
pentru grupa dată.

Lecţia 16. Utilizarea SQL la programarea aplicată

Lecţia 16. Utilizarea SQL la programarea aplicată


16.1. Limbajul modulelor sau SQL implimentat
În standartul SQL/89 sunt determinate două metode de interacţiune cu BD din programul
aplicat, scris în limbajul tradiţional de programare(după cum am mai numit, SQL/89 este orientat
spre utilizare împreună cu limbajele Cobol, Fortran, Pascal şi PL/1, dar în realizări, de obicei
susţine şi limbajul C). Prima metodă constă în aceea că toţi 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 conţine un sublimbaj special – limbajul modular. La utilizarea
acestui mijloc de interacţiune cu BD, programul aplicat conţine apelul procedurilor modulului
SQL cu transmiterea către ele a parametrilor daţi şi cu primirea parametrilor rezultanţi.
A doua metodă constă din utilizarea aşa numitului SQL implimentat, cînd cu utilizarea
sintaxei speciale în programul limbajului tradiţionalde programare se implimentează operatori
SQL. În acest caz, din punct de vedere a programului aplicat, operatorul SQL se îndeplineşte
„după loc”. O parametrizare clară a operatorilor SQL lipseşte, dar în operatorii implementaţi
SQL pot fi utilizate numele variabilelor a programului de bază, şi datorită acestui fapt, se
asigură legătura dintre programul aplicat şi SGBD.
Conceptual, aceste 2 metode sunt echivalente. Mai mult ca atît, în standart se determină
reguli de creare a modulului SQL după programul cu SQL implimentat. Însă în majoritatea
realizărilor, operatorii SQL se prelucrează foarte diferit. Modulul SQL, de obicei, se compilează
aparte de programul aplicat, în rezultat se creează setul aşa numitor proceduri memorabile( în
standart acest termen nu se utilizează, dar e răspîndit în realizările comerciale). Adică în cazul
utilizării modulului SQL, compilarea operatorilor SQL are loc odată, şi apoi procedurile
corespunzătoare pot fi apelate din programul aplicat de cîte ori va fi nevoie.
Spre deosebire de aceasta, pentru operatorii SQL, implimentaţi î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 încărcarea dată a programului aplicat).
Desigur, utilizatorul nu trebuie să ştie de această diferenţă tehnică în prelucrarea a două
tipuri de interacţiuni cu SGBD. Există şi aşa sisteme, ce provoacă compilarea de o singură
folosinţă a operatorilor implimentaţi SQL şi păstrează codul compilat. Dar totuşi e bine de ţinut
cont de aceasta. Să saducem unele propoziţii pentru şi în potriva la fiecare din aceste două
metode. La utilizarea limbajelor modulelor textul programului aplicat are un volum mai mic,
interacţiunile cu SGBD sunt mult mai localizate pe baza existenţei parametrilor de apel a
procedurilor. Din altă parte, pentru înţelegerea sensului comportării 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 realizări.
SQL implimentat ne dă posibilitatea creării unor programe aplicate mult mai „auto
întreţinătoare”. Sunt mai multe afirmaţii pentru a ne baza pe simplitatea transferului a aşa
program în mediul altei SGBD, deoarece standartul implimentării mai mult sau mai puţin se
îndeplineşte. Neajunsul de bază este un oarecare PL – este tipul acestor programe, indiferent de
limbajul de bază ales. Desigur trebuie de ţinut cont de observaţiile, ce se conţin în abzaţele
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
următoare:
<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ă accentuăm 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ă construcţiile 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 fiecăror proceduri într-un mediu trebuie să fie diferite. Orice nume a
parametrului, care se conţine în parametrul SQL a procedurii, trebuie să fie specificat în
compartimentul de declarare a parametrilor formali, arătaţi la declararea ei. Lista parametrilor
formali a fiecărei proceduri, trebuie să conţină fix un parametru SQLCODE(codul de răspuns 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 impălimentare 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 realizări 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>.
Operaţiile implimentate SQL, inclusiv şi declararea cursorului, deasemenea despărţiturile
declarării situaţiilor excepţionale şi a variabilelor programului de bază trebuie să fie luate în
ghilimele EXEC SQL şi END EXEC. Declararea cursorului trebuie să fie întîlnită textual mai
devreme de orice operaţie ce se bazează pe acest cursor. Toate variabilele programului de bază
ce se utilizează în operatorii implimentaţi SQL, trebuie să fie declaraţi textual în despărţitura
anterioară acestui operator de declarare a variabilelor programului de bază. Cu toate acestea
sintaxa declarării variabilelor corespunde sintaxei limbajului de programare de bază, însă la
începutul numelui variabilei se pun două puncte.
Mecanismul de prelucrare a situaţiilor excepţionale în SQL/89 este foarte simplu(putem
spune primitiv). Putem crea reacţia pentru apariţia a două feluri de condiţii: SQL ERROR este
condiţia apariţiei în variabilă SQL CODE după îndeplinirea operatorului implementat cu sens de
valoare negativă; NOT FOUND este condiţia apariţiei în SQL CODE a valorii +100(acest cod
înseamnă emanarea cursorului). Reacţia poate fi alcătuită din execuţia trecerii la semnul
programului de bază(acţiunea GO TO) sau poate să lipsească(acţiunea CONTINUE).
Va reacţiona acel operator de determinare a reacţiei în caz de situaţie excepţională, care
textual este mai aproape de la începutul programului de operatorulSQL.
Să atragem atenţia că în multe realizări se menţin două feluri de coduri de răspuns la
execuţia operatorilor SQL(implementaţi sau luaţi din modul): prin variabila SQL CODE cu
codurile de răspuns, care sunt reprezentate prin numere întregi şi prin variabila SQL STATE cu
codurile de răspuns, codificarte prin numere zecimale, afişate în formă de text. Este tendinţa de
trecere la utilizarea numai a mecanismului SQL STATE, dar în realizările standarte trebuie să se
menţină 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 clasificaţi pe grupe de operatori, legaţi cu cursorul, operatori singulari de
manipulare cu datele şi operatorii de finisare a tranzacţiilor. Toţi aceşti operatori pot fi utilizaţi
atît în modulul SQL cît şi în SQL implementat. Să atragem atenţia că în SQL/89 nu-I determinat
setul de operaţii a lui SQL interactiv.

16.4.1. Operatorii legaţi cu cursorul


Operatorii acestei grupe sunt legaţi prin faptul că toţi ei lucrează cu un oarecare cursor,
declararea căruiea trebuie să se conţină în acelaşi 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
execu’iei organiya’iilor UNION ;I for’[rii reyultatului final. Acest oerator nu este executabil, dar
numai leag[ numele cursorului cu specifica’ia cursorului.
Operatorul de deschidere a cursorului
El este descris de regula sintactic[ urm[toare>
<open statement>::=OPEN <cursor name>.
În realizările 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 îndepliniţi, legaţi cu cursorul dat. La execuţia acestui
operator are loc pregătirea cursorului de lucru asupra lui. În parte, în acest timp are loc pregătirea
specificaţiei cursorului cu valorile variabilelor limbajului de bază în cazul SQL-ului implimentat,
sau a parametrilor în cazul modulelor.
În majoritatea realizărilor, în cazul SQL implementat, anume îndeplinirea operatorului de
deschidere a cursorului duce la compilarea specificaţiei cursorului.
Operatorii următori pot fi executaţi în ordine aleatoare asupra cursorului deschis.
Operatorul de citire a rîndului următor a cursorului
Sintaxa operatorului de citire este următoarea:
<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 despărţitura neapărată INTO, ce
conţine lista specificaţiilor destinaţiilor(lista numelor variabilelor a programei de bază în cazul
SQL implementat sau a numelor parametrilor de ieşire în cazul modulului SQL). Numărul şi
tipurile datelor în lista destinaţiilor trebuie să coincidă cu numărul şţi tipurile datelor listei de
selecţie a specificaţiilor cursorului.
Orice cursor deschis în totdeauna are poziţia: el poate fi instalat înaintea unui rînd al
tabelului rezultant(înaintea primului rînd îndată după deschiderea cursorului), într-un rînd a
rezultatului sau în ultimul rînd a rezultatului.
Dacă tabelul la care indică cursorul este nul sau cursorul e poziţionat pe ultimul rînd sau
după el, atunci la execuţia operatorului de citire cursorul se fixează în poziţia de după ultimul
rînd, parametrului SQL CODE i se atribuie valoarea 100, scopurilor identificate în despărţitura
INTO nu li se atribuie nici o valoare. Dacă cursorul este poziţionat înaintea rîndului, atunci el se
poziţionează în acest rînd şi valoarea acestui rînd i se atribuie scopurilor corespunzătoare. Dacă
cursorul este poziţionat pe rîndul r, diferit de ultimul rînd, atunci cursorul se poziţionează pe
rîndul, care imediat urmează după rîndul r şi valorile din acest rînd următor li se atribuie
scopurilor corespunzătoare.
Apare întrebarea, în ce mod putem parametriza cursorul cu o valoare nedeterminată sau
cum să vedem că valoarea aleasă din rîndul următor este nedeterminată. În SQL/89 acest lucru
se atinge pe baza utilizării aşa numitor parametri indicatori şi a variabilelor. Dacă se cunoaşte că
valoarea transmisă din programul principal de la SGBD, poate fi nedeterminată şi acest fapt îl
interesează pe programatorul aplicat, atunci specificaţia 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 poziţiei
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 poziţionat pe un oarecare rînd şi
cursorul determină tabelul schimbător, rîndul curent al cursorului se şterge, iar cursorul se
poziţionează în poziţia rîndului următor. Tabelul specificat în despărţitura FROM a operatorului
DELETE, trebuie să fie tabelul, specificat în cea mai exterioară despărţitură FROM de
specificare a cursorului.
Operatorul de modificare a poziţiei
Operatorul dat are sintaxa următoare:
<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 poziţionat pe un rînd oarecare, şi
cursorul determină tabelul schimbător, atunci rîndul curent al cursorului se modifică în
conformitate cu despărţitura SET. Poziţia cursorului nu se schimbă. Tabelul specificat în
despărţitura FROM a operatorului DELETE trebuie să fie tabelul, specificat în cea mai
exterioară despărţitură FROM a specificaţiei cursorului.
Operatorul de închidere a cursorului
Sintactica acestui operator este următoarea:
<close statement>::=CLOSE<cursor name>.
Dacă în momentul execzţiei acestui operator cursorul este în stare deschisă, atunci
operatorul transferă cursorul în stare închisă. După aceasta asupra cursorului poate fi executată
doar operaţia OPEN.

16.4.2. Operatorii singulari de manipulare cu datele


Fiecare operator al acestei grupe este independent faţă de oricare alt operator.
Operatorul de selecţie
Sintaxa lui este:
<select statement>::=
INTO<select target list><table expresion>
<select target list>::=
<target specification>
[{,<target specification>}…]
Deoarece rezultatul operatorului singular de selecţie este tabelul, ce conţine nu mai mult
de un rînd, lista scopurilor se specifică în însăşi operatorul.
Operatorul de ştergere a căutării
El este descris de sintaxa următoare:
<delete statement:searched>::=
DELETE FROM <table name>
WHERE[<searched condition>].
Tabelul T, specificat în despărţitura FROM a operatorului DELETE, trebuie să fie
schimbător. Asupra condiţiei de căutare se depune condiţia, că pentru tabelul T nu trebuie să se
conţină schiţe în nici o subadresare depusă a predicatelor despărţirii WHERE.
De fapt operatorul se execută în felul următor: se verifică succesiv toate rîndurile
tabelului T şi acele rînduri pentru care rezultatul calculului condiţiei de selecţie este true, se
şterg din tabelul T. În absenţa despărţiturii WHERE se şterg toate rîndurile tabelului T.
Operatorul de modificare a căutării
El are sintaxa următoare:
<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 schimbător. Asupra condiţiei
de căutare se depune condiţia că pentru tabelul T nu trebuie să se conţină schiţe în nici o
subadresare depusă a predicatelor despărţirii WHERE.
Operatorul se execută în felul următor: tabelul T se verifică succesiv şi fiecare rînd pentru
care rezultatul calculului de căutare este true, se schimbă în conformitate cu despărţitura SET.
Dacă expresia afirmativă în despărţitura SET conţine schiţe pentru coloanele tabelului T, atunci
la calculul expresiei afirmative se utilizează valorile coloanelor curente, pînă la modificarea lor.
Operatorii de finisare a tranzacţiei
Tranzacţia curentă poate fi finisată cu succes(cu fixarea în baza de date a schimbărilor
efectuate) pe calea execuţiei operatorului COMMIT WORK sau accidental(cu ştergerea
schimbărilor din baza de date, create de tranzacţia curentă) pe calea execuţiei operatorului ROLL
BACK WORK. La execuţia oricărui din operatorii daţi are loc închiderea forţată a tuturor
cursoarelor, deschise la momentul execuţiei operatorului de finisare a tranzacţiei.

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 implimentării în
programul scris în limbajul obişnuit de programare. De aceea în acest set sunt amestecaţi
operatorii a limbajului relaţional „adevărat” cu adresări(de exemplu operatorul de ştergere a unei
părţi de rînduri din tabel, care satisfac valorii date şi operatorii de lucru cu cursoarele, ce permit
accesul pe rînduri la tabelul – rezultat a adresării.
Este clar că în regimul de dialog setul de operatori SQL şi sintaxa lor trebuie să fie un
pic altfel. Întrebarea este cum să realizăm un aşa program de dialog. Regulile de implementare a
SQL standart în programul elaborat într-un limbaj obişnuit de programare prevăd că toată
informaţia, privind operatorii SQL, e cunoscută în statică(cu excepţia valorilor variabilelor
utilizate în calitate de constante în SQL). Nu sunt prevăzute sursele standarte de compilare cu
execuţie succesivă a operatorilor, care devin cunoscuţi doar în momentul execuţiei(de exemplu
se introduc din terminal). De aceea bazîndu-ne doar pe standart, e imposibil de a realiza
monitorul de dialog de interacţiune cu BD ţn limbajul SQL sau alt program aplicat, în care
textul operatorilor SQL apare în timpul execuţiei, adică standartul trebuie lărgit. Una din
posibilele căi de lărgire constă în utilizarea grupului special de operatori, ce asigură compilarea
dinamică(în timpul execuţiei programului aplicat) a submulţimii de bază a operatorilor SQL şi
care sisţin execuţia lor corectă. Unul din seturile de aşa operatori făcea parte din dialectul SQL,
realizat în System R, alt set mai deosebit face parte din realizarea Oracle V.6 şi în sfîrşit, în
standartul nou SQL/92 a apărut 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 întîi pe ele, pentru a avea o bază de comparaţie cu SQL/92.
În setul adăugător de oeratori, ce menţin compilarea dinamică a operaţiilor SQL de bază,
intră operatorii: PREPARE, DESCRIBE şi EXECUTE.

16.5.1. Operatorul de pregătire


Operatorul PREPARE are sintaxa:
<prepare statement>::=
PREPARE<statement name>FROM<host string variable>
<statement name>::=name.
În timpul execuţiei operatorului PREPARE rîndul caracterial ce se conţine î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 execuţia operatorului prepare rămîne acţionabil pînă la finisarea
tranzacţiei sau pînă la execuţia repetată a operatorului dat PREPARE în limitele aceleieaşi
tranzacţii. Spre deosebire de operatorii SQL incluşi 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, pregătiţi cu ajutorul operatorului PREPARE, impun analiza acestor nume ca nume
a parametrilor formali. Coincidenţa acestor parametri formali cu adresele variabilelor
programului dat se determină poziţional, în timpul execuţiei operatorului pregătit.

16.5.2. Operatorul de primire a descriere a operatorului pregătit


Operatorul DESCRIBE este prevăzut pentru determinarea tipului operatorului pregătit
mai înainte, de a determina numărul şi tipurile coloanelor tabelului rezultant, dacă operatorul
pregătit este operator de selecţie(SELECT). Acţiunea operatorului DESCRIBE constă în faptul
că în locaţia de memorie selectată a programului aplicat(structura acestei locaţii este fixată şi este
cunoscută de către utilizatori) se înscrie informaţia care caracterizează operatorul pregătit mai
devreme cu numele dat.

16.5.3. Operatorul de execuţie a operatorului pregătit


Operatorul EXECUTE sete destinat execuţiei operatorului SQL pregătit mai devreme de
tipul „N”(care nu cere aplicarea cursorului) sau pregătirii concomitente şi execuţiei a aşa
operator. Sintaxa operatorului EXECUTE este:
<execute statement>::=
EXECUTE
{<statement name>[USING<host vars list>]
(IMMEDIATE<host string variable>}.
Pentru execuţia operatorului pregătit slujeşte 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 pregătit sunt prezenţi parametri formali, atunci în operatorul
EXECUTE trebuie să se indice lista parametrilor actuali <hosrt vars list>. Numărul şi tipurile
parametrilor formali a operatorului pregătit.
Varianta a doua a operatorului EXECUTE, în Oracle este destinat pregătirii concomitente
şi execuţiei operatorului SQL de tip “N”. în acest caz parametrii execuţiei operatorului
EXECUTE este rîndul, care trebuie să conţină textul operatorului SQL(acest rînd 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 aşa operatori se utilizează lărgirea mecanismului cursoarelor
standartului SQL. În primul rînd, la determinarea cursorului putem indica nu numai specificaţia
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). Aşa dar sintactica completă a operatorului DECLARE este următoarea:
<declare cursor>::=
DECLARE <cursor name> CURSOR
FOR{<cursor specification>|<statement name>}
Deoarece, pentru aşa cursor în statică nu se cunoaşte informaţia despre variabilele
programului dat de intrare şi de ieşire, 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 ieşire: directă cu intrarea în operatorii OPEN şi/sau FETCH a listelor numelor
variabilelor a programului dat şi indirectă, cînd numele parametrilor şi adresele lor se indică
printr-o structură adăugătoare a descriptorilor.
Prima metodă se oferă pentru lucrul cu operatorii de selecţie, pentru care este fixat setul
parametrilor formali de intrare şi de ieşire. Mai precis, în ceea ce priveşte parametrii de ieşire,
trebuie să fie fixaţi numărul şi tipurile elementelor a listei de selecţie.
A doua metodă de lucru cu operatorii dinamic compilaţi, care necesită utilizarea
cursoarelor, constă în utilizarea descriptorilor a listelor parametrilor formate dinamic. În acest
caz toată răspunderea pentru coincidenţa tipurilor parametrilor formali şi actuali cade pe
programator. În rezultatul erorii la formularea a aşa liste, poate fi pierdută memoria programului
C.
Lecţia 17. Unele proprietăţi SQL/92 şi SQL-3

Lecţia 17. Unele proprietăţi SQL/92 şi SQL-3


Noi nu vom descrie nici în general posibilităţile noi a limbajului SQL în standartul
SQL/92. în prezent aceasta este foarte gîndit, căci unica realizare accesibilă SQL/92 este
versiunea scumpă Oracle V.7. Însă se pare a fi de folos, să indicăm un şir de operatori a SQL
dinamic cu mici comentarii, căci în SQL/92 este interpins primul pas de a standartiza această
parte a limbajului SQL. La sfîrşitul lecţiei se aduce o mică sumare a noilor posibilităţi, aşteptate
în standartul nou SQL-3, lucrul asupra căruia se mai înfăptuieşte 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 informaţiei despre rezultat sau despre parametrii operatorului SQL
pregătit dinamic sau pentru indicarea parametrilor a aşa operator. Sensul, că pentru destingerea
memoriei se utilizează operatorul SQL, şi nu pur şi simplu funcţia standartă ALLOC sau o
oarecare altă funcţie a adresării dinamice de memorie, constă în faptul că programul aplicat nu
cunoaşte structura descriptorului şi chiar a adresei lui. Aceasta permite de a nu lega SQL cu
posibilităţile deosebite a oricărei structuri de programare. Toate schimburile de informaţie î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
cunoaşte în statică numărul operaţiilor SQL ce lucrează simultan, descrierea cărora i-ar putea fi
necesară. Cu aceeaşi e legat faptul că numele descriptorului poate fi indicat ca rînd literal de
simboluri atît ş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
numărul elementelor de descriere, pentru care el este calculat. Dacă, de exemplu, în timpul
alocării memoriei prin descriptor în despărţitura WITH MAX se specifică un număr întreg N, iar
apoi descriptorul se utilizează pentru descrierea M(M>N) elemente(de exemplu M coloane a
rezultatului adresării, atunci acest fapt duce la apariţia situaţiei excepţionale.

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:
Execuţia 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 informaţiei din regiunea descriptorului SQL

17.3. Operatorul de primire a informaţiei 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 selecţia informaţiei de descriere,
amestecată mai devreme în descriptor cu ajutorul operatorului DESCRIBE. La o singură execuţie
a operatorului putem primi sau numărul elementelor completate(COUNT), sau informaţia, ce se
conţine î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 utilizării lui în despărţitura USING. La o singură execuţie a operatorului
valoarea o putem duce în cîmpul COUNT(numărul elementelor completate), sau parţial sau total
de creat un element a descriptorului.

17.5. Operatorul pregătirii

17.5. Operatorul de pregătire


<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 execuţie a
operatorului SQL dat sub formă de text. După execuţia reuşită a operatorului PREPARE, cu
operatorul pregătit se leagă numele dat a acestui operator, care pe urmă poate fi utilizat în
operatorul DESCRIBE, EXECUTE, OPEN CURSOR, ALLOCATE CURSOR şi
DEALLOCATE PREPARE. Legătura aceasta se păstrează pînă la execuţia operatorului
DEALLOCATE PREPARE.

17.6. Operatorul de respingere de la operatorul pregătit

17.6. Operatorul de respingere de la operatorul pregătit


<deallocate prepared statement>::=
DEALLOCATE PREPARE <SQL statement name>.
Comentariu:
Execuţia acestui operator duce la aceea că, operatorul SQL pregătit mai devreme, legat
cu numele dat a operatorului, se lichidează şi, corespunzător, numele operatorului devine
nedeterminat. Dacă operatorul pregătit este operator de selecţie, şi în timpul execuţiei
operatorului DEALLOCATE există un cursor deschis, legat de numele operatorului pregătit,
atunc DEALLOCATE returnează codul erorii. Dacă în operatorul selecţiei există cursor
nedeschis, format cu ajutorul operatorului ALLOCATE CURSOR, atunci acest cursor se
lichidează. Dacă cursorul s-a anunţat de operatorul DECLARE CURSOR, atunci acest cursor
trece în starea existentă pînă la execuţia operatorului PREPARE. Dacă cu cursorul a fost legat
operatorul pregătit(DELETE dynamic sau UPDATE), atunci pentru aceşti operatori se execută
operatorul DEALLOCATE.

17.7. Operatorul adresării la descrierea operatorului pregătit

17.7. Operatorul adresării la descrierea operatorului pregătit


<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 execuţia operatorului DESCRIBE are loc completarea descriptorului arătat în
operator, cu informaţia, ce descrie sau rezultatul operatorului SQL pregătit mai devreme(dacă
acesta-i operator de selecţie) sau numărul şi tipurile parametrilor operatorului pregătit. În <using
descriptor> se propune de scris USING SQL DESCRIPTOR.

17.8. Operatorul de execuţie a operatorului pregătit

17.8. Operatorul de execuţie a operatorului pregătit


<execute statement>::=
EXECUTE <SQL statement name>
(<result using clause>]
(<parameter using clause>]
<result using clause>::=<using clause>.
Comentariu:
Operatorul EXECUTE poate fi atribuit oricărui operator pregătit mai devreme, în afară
de <dynamic selected statement>. Dacă acesta-i operatorul <dynamic single row select
statement>, atunci operatorul EXECUTE trebuie să conţină despărţitura <result using class>, cu
cuvîntul cheie INTO. În orice caz numărul parametrilor formali atribuiţi prin despărţiturile using,
trebuie să coincidă cu numărul parametrilor formali, determinaţi în operatorul SQL pregătit.

17.9. Operatorul de pregătire cu execuţie imediată

17.9. Operatorul de pregătire cu execuţie imediată


<execute imediate statement>::=
EXECUTE IMEDIATE<SQL statement variable>.
Comentariu:
La execuţia operatorului EXECUTE IMEDIATE are loc pregătirea şi execuţia imediată a
operatorului SQL dat în formă de text. Cu toate acestea, operatorul ce se pregăteşte nu trebuie să
fie operator de selecţie, nu trebuie să conţină comentarii şi parametri formali.

17.10. Operatorul de declarare a cursorului pentru operatorul de selecţie pregătit dinamic

17.10. Operatorul de declarare a cursorului pentru operatorul de selecţie pregătit dinamic


<dynamic declare cursor>::=
DECLARE<cursor name>[INTENSIVE][SCROLL]
CURSOR FOR<statement name>.
Comentariu>
După cum se determină în noul standart, pentru toţi operatorii DECLARE CURSOR,
cursoarele se creează la începutul tranzacţiei şi se lichidează la finisarea ei. Aici <cursor name>
şi <statement name> sunt identificatori atribuiţi direct.
17.11. Operatorul de determinare a cursorului pentru operatorul de selecţie pregătit dinamic

17.11. Operatorul de determinare a cursorului pentru operatorul de selecţie pregătit 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
execuţia a aşa operator şi se lichidează la execuţia operatorului DEALLOCATE PREPARE sau
la finisarea tranzacţiei. În acest operator numele cursorului şi a operatorului SQL pregătit poate
fi dat nu numai în formă literară, dar şi prin variabile <scope option> . Se referă la sfera
vizibilităţii numelor:în luimitele modulului curent sau în limitele sesiei curente.

17.12. Operatorul de deschidere a cursorului, legat cu operatorul de selecţie dinamic pregătit

17.12. Operatorul de deschidere a cursorului, legat cu operatorul de selecţie dinamic pregătit


<dynamic open statement>::=
OPEN<dynamic cursor name>[<using clause>].
Comentariu:
De fapt, operatorul de deschidere a cursorului, legat cu operatorul SQL pregătit dinamic,
se deosebeşte doar prin posesia despărţiturii using, în care se indică parametrii formali a
operatorului de selecţie. În afară de aceasta, numele cursorului poate fi declarat prin variabilă.

17.13. Operatorul de citire a rîndului pe cursor, legat cu operatorul de selecţie pregătit dinamic

17.13. Operatorul de citire a rîndului pe cursor, legat cu operatorul de selecţie pregătit 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 deosebeşte
doar prin posesia despărţiturii using, în care se declară aranjarea valorilor rîndului 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 selecţie pregătit dinamic

17.14. Operatorul de închidere a cursorului legat de operatorul de selecţie pregătit dinamic


<dynamic close statement>::=
CLOSE<dynamic cursor name>.
Comentarii:
Operatorul de închidere a cursorului, legat de operatorul SQL pregătit dinamic şe
deosebeşte cu aceea că numele cursorului se poate indica printr-o variabilă.

17.15. Operatorul de ştergere poziţională pe cursor

17.15. Operatorul de ştergere poziţională pe cursor


<dynamic delete statement:positioned>::=
DELETE FROM<table name>
WHERE CURENT OF<dynamic cursor name>
Comentariu:
Operatorul de ştergere poziţională pe cursor, legat cu operatorul SQL pregătit dinamic, se
deosebeşte prin faptul că numele cursorului se poate atribui printr-o variabilă.

17.16. Operatorul modificării poziţionale pe cursor, legat cu operatorul de selecţie pregătit


dinamic

17.16. Operatorul modificării poziţionale pe cursor, legat cu operatorul de selecţie pregătit


dinamic
<dynamic update statement>positioned>::=
UPDATE <table name>
SET<set clause>[{<comma><set clause>}…]
WHERE CURENT OF<dinamic cursor name>.
Comentariu:
Operatorul modificării poziţionale pe cursor, legat cu operatorul SQL pregătit dinamic se
deosebeşte prin aceea că numele cursorului se poate da printr-o variabilă.

17.17. Operatorul de pregătire a ştergerii poziţionale

17.17. Operatorul de pregătire a ştergerii poziţionale


<prepare dynamic delete statement>positioned>::=
DELETE[FROM<table name>]
WHERE CURENT OF<cursor name>.
Comentariu:
Sensul de bază a apariţiei a acestuia şi a următorului operator constă în faptul că
ansamblul dintre cursorul, determinat pe operatorul de selecţie pregătit dinamic şi operatorilor de
ştergere şi modificare declaraţi static, de aceea cursorul arată destul de neclar. De aceea în
standart au apărut operatorii de ştergere şi introducere poziţională pregătiţi dinamic. Desigur că
ei trebuiesă se execute cu ajutorul operatorului EXECUTE.

17.18. Operatorul de pregătire a modificării poziţionale

17.18. Operatorul de pregătire a modificării poziţionale


<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ă comparăm 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 cîteva deosebiri
sintactice şi(ceea ce-i mai principal) stilul diferit de lucru cu descriptorii. Se presupune că cam
aceeaşi situaţie este şi în celelalte SGBD ce conţin SQL dinamic.

17.19. Lista noilor posibilităţi SQL-3

17.19. Lista noilor posibilităţi SQL-3


În standartul SQL/92, în comparaţie cu SQL/89, limbajul a fost lărgit, în mod principal,
cfantitativ, cu toate că aceste lărgiri cantitative au fost îndeajuns pentru ca standartul SQL/92 să
nu fie realizat complet pînă acum în SGBD comerciale. Deoarece SQL/92 nu satisfăcea o mare
parte de sugestii, adresate limbajului SQL, a fost formt un comitet nou, care trebuia să aleagă
standartul limbajului cu lărgiri calitative. Limbajul SQL-3 încă nu este format complet, multe
aspecte se mai consultă. De aceea către lista posibilităţilor adusă aici ca exemplu trebuie să ne
adresăm ca la una iniţiatoare.

17.19.1. Tipurile de date


Setul tipurilor de date implementate se propune de lărgit prin tipurile BOOLEAN şi
ENUMERATED. Cu toate că din cauza susţinerii valorilor nedeterminate limbajului SQL îi este
recomandată utilizarea logicii tridimensionale, tipul BOOLEAN conţine doar două valori
posibile: TRUE şi FALSE. Pentru afişarea valorii unikown se recomandă utilizarea lui NULL,
ceea ce-i desigur nu chiarbine. Tipul de enumeraţie ENUMERATED are proprietăţi
asemănătoare proprietăţilor tipului de enumeraţie în limbajele de programare.
S-au lărgit posibilităţile de lucru cu valorile nedeterminate. A apărut operatorul nou
CREATE NULL CLASS, ce permite introducerea setului enumerat de valori nedeterminate. La
determinarea domeniului putem arăta numele clasei valorilor nedeterminate, apariţia cărora este
permisă în coloanele, legate de acest domeniu. Sensul fiecărei valori nedeterminate se
înterpretează la nivelul utilizatorilor.
Se propune includerea în limbaj a posibilităţilor de utilizare a tipurilor de date
determinate de utilizator. Se vor ivi posibilităţi de a determina tipuri de date abstracte, cu o
sistemă internă complicată pe baza posibilităţilor tradiţionale de agregare şi structurizare ca
LIST, ARRAY, SET, MULTISE şi TUPLE, de asemenea şi posibilităţile de determinare a
tipurilor obiect prin metode corespunzătoare în stilul de apropiere obiect-orientat.
Apare posibilitatea utilizării principiului de moştenire a proprietăţilor tabelului
existent(supertabelului) la determinarea tabelului nou(subtabelului). Subtabelul va moşteni de la
supertabel toate determinările coloanelor şi a cheii primare. Altă posibilitate – de a crea tabelul
“asemănător” cu cel existent în sensul că tabelul nou va moşteni determinările cărorva coloane a
tabelului existent.

17.19.2. Careva alte proprietăţi a lui SQL-3


Una din problemele de realizare a lui SQL în totdeauna era problema de determinare a
“modificării” legăturilor. Dacă configuraţia include legătura de tip general, atunci teoretic este
imposibil de determinat, putem noi să interpretăm la fel operaţiile de înoire a aşa configuraţie.
Însă există cîteva clase principale de legături, care preventiv sunt schimbătoare. În SQL-3 se
propune de a determina aceste clase cu ajutorul construcţiilor sintactice speciale.
În sfîrşit apare posibilitatea de determinare a trigherelor ca combinaţii de specificare a
actului şi a cţiunii. Actul se determină ca SQL-procedură, în care se pot utiliza cît operatori SQL,
atît şi un rînd de construcţii dirijatoare. În realitate, acest mecanism este foarte aproape de cel din
Oracle v.7.
Cît despre dirijarea cu tranzacţiile, are loc întoarcerea la ideile vechi System R despre
posibilitatea instalării punctelor de salvare(savepoints) în interiorul tranzacţiilor. În operatorul
ROLLBACK putem specifica identificatorul punctului de salvare instalat mai devreme, şi atunci
va avea loc întoarcerea tranzacţiei nu către începutul său, dar către acest punct de salvare.
Deci, în SQL-3 putem aştepta multe posibilităţi interesante şi de folos. Însă, chiar
proiectele din timp ale standartului inclu de două ori mai multe pagini decît standartul SQL/92.
De aceea este greu de aşteptat o realizare rapidă a acestui standart după admiterea lui(mulţi în
genere se îndoiesc de faptul că acest standart va fi vre-o dată realizat).

Compilatorii SQL

Compilatorii SQL
Lecţia 18. Compilatorii SQL. Problemele Optimizării
Vorbind despre optimizarea adresărilor în SGBD relaţionale, se are în vedere aşa un tip
de prelucrare a adresărilor, cînd pe baza configuraţiei iniţiale a adresării, pe baza creerii lor, se
elaborează planul de produceri a execuţiei adresării, fiind cel mai optimal din structurile de
dirijare existente în baza de date. Creerile corespunzătoare a configuraţiei iniţiale a adresării se
efectuiează de componenta specială a SGBD – de către optimizator şi optimizarea planului
adresării, efectuat de optimizator, poartă caracter condiţional: planul este optimizat în
dependenţă de criteriile, declarate în optimizator.

18.1. Schema de prelucrare a aresării

18.1. Schema de prelucrare a aresării


Ne putem închipui că prelucrarea adresării către sistem este alcătuită din fazele, arătate
mai jos.
În prima fază adresarea, adresată în limbajul adresărilor, se supune analizei lexicale şi
sintactice. În acest timp mse creează configuraţia sa internă, ce reflectă structura adresării şi care
conţine informaţia ce caracterizează obiectele bazei de date arătate în adresare(relaţii, cîmpuri,
constante). Informaţia despre obiectele păstrate în baza de date se alege din cataloagele BD.
Configuraţia internă a adresării se formează şi se utilizează în stadiile următoare de prelucrare a
adresării. Forma configuraţiei interne trebuie să fie comodă pentru următoarele creeri
optimizaţionale.
În faza a doua, adresarea în configuraţia sa intrernă se impune optimizării logice. Se pot
utiliza diferite creeri, ce “îmbunătăţesc” configuraţia iniţială a adresării. Printre creeri pot fi şi
creeri echivalente, după utilizarea cărora se primeşte configuraţia internă, semantic echivalentă
celei iniţiale(de exemplu, adresarea adresării către o formă conică). Creerile pot fi şi semantice:
configuraţia primită nu este echivalentă semantic cu cea iniţială, dar se garantează că rezultatul
execuţiei adresării coincide cu rezultatul adresării în formă iniţială, la respectarea limitelor
integrităţii, existente în baza de date. După execuţia fazei a doua de prelucrare a adresării,
configuraţia sa internă rămîne neprocedurată, cu toate că într-o oarecare măsură, este mai
efectivă ca cea iniţială.
A treia etapă de prelucrare a adresării constă în selecţie pe baza informaţiei, ce o posedă
optimizatorul, a setului procedurilor alternative a planurilor de îndeplinire a adresării date în
dependenţă de configuraţia sa internă, primită în faza a doua. Pentzru fiecare plan se apreciază
preţul execuţiei adresării date. La calculele aprecierii se utilizează informaţia statistică despre
starea bazei de date accesibilă optimizatorului. Din planurile primite se alege cel mai eftin şi
configuraţia sa internă coincide acum cu adresarea prelucrată.
La etapa a patra, pe configuraţia internă a celui mai optimal plan de execuţie a adresării
se formează configuraţia executabilă a planului. Configuraţia executabilă a planului poate fi o
programă în codurile maşinii dacă ca şi în System R, sistemul este orientat spre compilarea
adresărilor în codurile maşinii, sau să fie independent—maşinal, dar cel mai comod de
interpretare dacă ca şi în cazul Ingres, sistemul e orientat spre interpretarea adresărilor. În cazl
nostru acest lucru nu este principal, căci faza a patra de prelucrare a adresării nu mai este legată
de optimizare.

18.2. Optimizarea sintactică a adresării

18.2. Optimizarea sintactică a adresării


la apropierea sintactică către organizarea optimizatorilor adresărilor la etapa optimizării
logice au loc creeri logice a configuraţiei interne a adresării, care”îmbunătăţesc” configuraţia
internă iniţială în dependenţă de strategiile fixate a optimizatorului. Caracterul “îmbunătăţirilor”
e legat de specificul organizării generale a optimizatorilor, în special de deosebirile procedurii de
căutare a planurilor procedurale posibile a adresărilor, executate în faza a treia de prelucrare a
adresării.
De aceea e greu de format caracteristica şi clasificarea întreagă a metodelor de optimizare
logică. Ne limităm la careva utilizări şi vom privi o clasă de creeri logice importantă, care se
ating de întrebări complicate, exprimate în limbajul SQL.
18.2.1. Creerile logice simple a adresărilor
Clasa următoare de creeri logice a adresărilor include crearea obiectelor ce intră în
condiţia de selecţie, către configuraţia canonică. Se au în vedere predicatele ce conţin operaţiile
de comparaţie a valorilor simple. Aşa predicat are tipul “expresie afirmativă or expresie
aritmetică”, unde “or” este operaţie de comparaţie, dar expresiile logice în părţile stînga şi
dreapta vor deţine numele cîmpurilor relaţiilor şi constante(în limbajul SQL, printre constante se
pot întîlni şi nume de variabile a programului din valorile cărora devin cunoscute nu numai la
execuşia reală a adresării).
Configuraţiile canonice pot fi diferite pentru diferite tipuri de predicate. Dacă predicatul
include un singur nume a cîmpului, atunci configuraţia lui canonică se permite de exemplu, de
avut în vedere “numele cîmpului or expresia aritmetică constantă”(aceasta e forma predicatului –
predicat simplu de selecţie - e foarte utilă pentru execuţia următoarei etape de optimizare). Dacă
configuraţia iniţială a prdicatului are tipul (a+5)or 36?(cu litere mici se indică numele
variabilelor, iar cu litere mari – numele cîmpurilor relaţiilor), atunci configuraţia canonică a
acestui predicat poate fi or36/(a+5)?. Dacă predicatul include fix două nume de cîmpuri a
duferitor relaţii(sau a două diferite intrări a unei relaţii), atunci configuraţia lui canonică poate
avea tipul “numele cîmpului or expresie aritmetică”, unde expresie aritmetică din partea stîngă
include numai constante şi al doilea nume a cîmpului(acesta de asemenea este forma utilă pentru
execuţia următorului pas de optimizare – predicatul de alipire; este deosebit de important în
cazul ecvialipirii, cînd or este egalitate). Dacă în configuraţia iniţială predicatul are tipul 5(A-a(B
or b), atunci configuraţia sa canonică este A or(b+a(B)/5.
În sfîrşit pentru predicatele de tip mai general are sens de a aduce predicatul la
configuraţia canonică de tipul “expresia aritmetică or expresia aritmetică constantă”, unde
expresia părţii drepte şi stîngi de asemenea sunt aduse la configuraţia canonică; de exemplu, în
expresii sunt deschise parantezele şi se execută ordinea lexicografică. În continuare putem face
căitarea expresiilor aritmetice comune în diferite predicate a adresării. Aceasta este justificată
căci, în timpul execuţiei adresării calculului expresiilor aritmetice se va face la selecţia fiecărui
cortej următor, adică un numă potenţial mare de ori. La aducerea predicatelor la o configuraţie
canonică se pot calcula expresiile constante şi se pot arunca negaţiile logice. Clasa următoare a
ceerilor logice este legată de aducerea la o formă canonică a expresiei logice, ce indică condiţiile
de selecţie a adresării. De regulă se utilizează forma normală disjunctivă, cît şi forma normală
conjunctivă. Alegerea formei canonice depinde de organizarea generală a optimizatorului. La
conducerea condiţiei logice către o configuraţie canonică, putem executa căutarea predicatelor
comune(ele pot exista de la început, dar pot apărea şi după aducerea predicatelor la tipul canonic
sau la procesul normalizării condiţiei logice) şi putem simplifica expresia logică pe contul, de
exemplu, codul conjuncţiei predicatelor reciproc opuse. Fragmentul expresiei logice ¼(A>5)¼
poate fi înlocuit cu ¼FALSE¼. Se admit şi simplificări mult mai “deştepte”. De exemlu
fragmentul expresiei logice ¼(A>B)AND(B=5)¼ poate fi înlocuit cu ¼(A>5)¼. Aşa simplificări
pot fi importante pentru prelucrarea de mai departe a adresării: în adresarea cu condiţie logică de
tipul întîiu se propunea alipirea relaţiilor; după creare adresarea nu cere alipire.

18.2.2. Crearea adresărilor cu schimbarea ordinii operaţiilor relaţionale


În optimizatoarele tradiţionale sunt răspîndite creeri logice, legate de schimbul ordinii de
execuţie a operaţiilor relaţionale. Ca exemplu a acestei reguli de creare în termenii algebrei
relaţionale poate fi următoarea(A şi B – nume de relaţie):
(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 relaţional a alipirii naturale a relaţiilor. Dar WHERE restriction
– operatorul de limitare a relaţiei A în dependenţă de predicatul restriction.
Cu toate că multe sisteme relaţionale au limbaje de adresare, bazate pe algebra
relaţională, regulile de creare a expresiilor algebrice pot fi utile în alte cazuri. Destul de des se
utilizează algebra relaţională în calitate de bază a configuraţiei interne a adresării. E clar că după
aceasta putem executa şi creeri algebrice.
În parte, există apropieri, legate de crearea către forma algebrică a adresărilor în limbajul
SQL. Putem accentuam două cauze principale de recreare a adresărilor în SQL către forma
algebrică. O cauză mai puţin importantă poate fi tinderea de a utiliza algebra relaţională în
calitate de interfaţă interioară unificată la SGBD relaţional. Aceasta este răspîndită la utilizarea
maşilor specializate a bazelor de date, pe baza cărora se realizează diferite interfeţe de acces la
bazele de date.
Interfaţa maşinei bazelor de date trebuie să fie unificat(de exemplu să fie algebric), iar
celelalte intefeţe, inclusiv interfaţa de bază a SQL, se aduc la cea algebrică.
A doua cauză, foarte importantă în contextul problemelor optimizării, este faptul că
algebra relaţională este mai simplă decît limbajul SQL. Crearea adresării către forma algebrică
uşurează acţiunile următoare a optimizatorului în selecţia planurilor optimale. Deci un
optimizator dezvoltat de adresări a sistemului, orientat pe SQL trebuie să destingă toate planurile
de executare posibilă a orice adresare, dar “spaţiul de căutare” a acestor planuri, în general, este
foarte mare. În fiecare optimizator concret se utilizează evristica sa pentru micşorarea spaţiului
de căutare. Unele, posibil cele mai optimale planuri, nu vor fi nici o dată analizate. Crearea
logică a adresării în SQL către configuraţia algebrică micşorează spaţiul căutării planurilor de
execuţie a adresării cu garanţia faptului, că planurile optimale nu vor fi pierdute.

18.2.3. Aducerea adresărilor cu subadresări inclşuse la subadresări cu alipiri


Deosebirea de bază a limbajului SQL de limbajul alebrei relaţionale este posibilitatea
mobilizării în condiţia logică predicaele ce conţin subadresări incluse. Adîncimea includerii nu
se limitează de către limbaj, adică poate fi liberă. Predicatele cu subadresări incluse, la posesia
sintaxei generale, pot avea o semnatică diferită. Unicul algoritm de execuţie a adresării comun
pentru toate semanticile posibile a subadresărilor incluse este calculul subadresării incluse de
fiecare dată la calculul valorii preparatului. De aceea tinderea către aşa creare a adrersării, ce
alipeşte predicate cu subadresări incluse, care va face semantica subadresării mai clară, dînd în
aşa mod pe viitor optimizatorului posibilitatea de a alege modul de execuţie a adresării, care cel
mai mult corespunde semnaticii subadresării.
Mai jos R este a i-a relaţie a bazei de date;Ck-k – cîmpul(coloana) relaţiei.
Predicatele, permise în adresările limbajului SQL, se pot împărţi în următoarele patru
grupe:
- Predicate simple. Acestea sunt predicatele de tipul Ri Ck or X, unde X – constantă
sau lista constantelor şi or – operatorul comparaţiei scalare sau operatorul de control a
apartenenţei mulţimii.
- Predicate cu subadresări incluse. Acestea sunt predicatele de tipul Ri Ck or Q, unde Q
este blocul adresării, 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ţă mulţimii se înlocuieşte
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 comparaţie scalară.
- Predicatele de divizare. Acestea sunt predicatele de tipul Qi or Qj, unde Qi şi Qj –
blocurile adresărilor, iar or poate fi operatorul de comparaţie scalară sau operatorul de
control a apartenenţei mulţimii.
Această clasificare este o simplificare a situaţiei reale în SQL. Nu se anaşizează
predicatele de alipire de tip general, ce includ expresii aritmetice cu cîmpurile a mai mult de
două relaţii.
Configuraţia canonică a adresării pentru n relaţii se numeşte adresare ce conţine n-1
predicate de alipire şi care nu conţine predicate cu subadresări incluse. De fapt forma canonică
este configuraţia algebrică a adresării.
Mai jos se dă un exemplu de două forme canonice de adresare cu predicate de tip diferit.
Aceeaşi 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…(C…Cn)=SELECT Rj Cp, AVG(Rj Cn) FROM Rj
GROUP BY Rj Cp.
Mulţimea de tipuri a aşa creeri, se datoreşte faptului, că optimizatorul primeşte
posibilitatea de selecţie a unui număr mai mare de metode de execuţie a adresărilor.
Des metodele de execuţie apărută după care sunt mai efective, ca cele utilizate în
optimizatorul tradiţional System R.
La utilizarea în optimizator a adresărilor de aşa apropiere nu-i neapărat de format creeri
formale a adresărilor. Optimizatorul trebuie, într-o măsură mai mare, să utilizeze semantica
adresării prelucarate acum, dar în ce mod ea va fi recunoscută, aceasta-i întrebare ce ţine de
tehnică.
Să observăm, că în apropierea descrisă de noi sunt cîteva incorectitudini fine în
semantică.
Sunt cunoscute metode modificate, corectate, însă ele sunt prea complicate tehnic, pentru
a le analiza la lecţiile noastre.

18.3. Optimizarea semnatică a adresărilor

18.3. Optimizarea semnatică a adresărilor


Creerile analizate a se bazează pe semantica limbajului adresărilor, în ele nu se
analizezaă semantica BD, căreia 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 relaţională adevărată, se păstrează şi o oarecare informaţie
semantică, ce de exemplu, determină integritatea bazei de date.
Dacă să vorbim despre bazele de date, menţionate în System R, atunci această informaţie
se păstrează în registrele de sistem a abzei de date în calitate de limite date a integrităţii.
Deoarece SGBD garantează integritatea bazei de date, atunci limitele integrităţii pot fi privite ca
nişte axiome, în împrejurarea cărora se formează adresarea către baza de date.

18.3.1. Crearea adresărilor pe baza informaţiei semantice


În calitate de exemple iniţiale de creare a adresărilor pe baza informaţiei semantice să
analizăm apropierile SGBD cunoscute System R şi INGRES către asigurarea lucrului bazei de
date prin configuraţii. Aceste creeri nu au fost orientate către o optimizare a adresărilor, dar au
faţă de aceasta o legătură reciprocă.
Configuraţia 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,
acelaşi obiect a bazei de date ca şi relaţia. Configuraţiile pot fi utilşizate în adresări ca şi
relaţiile memorabile(cu limite în utilizarea lor la operatorii de modificare a bazei de date).
Semantica configuraţiei cere ca aceasta să fie precisă: în momentul execuţiei adresării
pentru configuraţie, informaţia primită trebuie să coincidă stării curente a părţii memorabile a
bazei de date. execuţia adresării pentru configuraţie cere materializarea ei, adică calculul relaţiei,
determinată de adresare, care-i legată de configuraţie.
Apropierea System R şi Ingres este bazată pe aceea că configurţiile se păstrează în
registrele bazei de date în formă internă, primită în urma execuţiei analizei gramatice (de
asemenea a optimizării logice) a adresării corespunzătoare.
În timpul prelucrării adresării pentru configuraţie, înaintea execuţiei fazei optimizării
logice, are loc contopirea formelor interne a adresării şi a configuraţiei.
Se formează o formă internă nou creată şi pentru ea are loc prelucrarea de mai departe a
adresării, inclusiv optimizarea logică şi selecţia planului optimal de execuţie a adresării. În aşa
fel, optimizatorul primeşte mai multă informaţie despre adresarea dată şi poate lua hotărîri mult
mai corecte.
De exemplu:
Fie că configuraţia 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 materializării configuraţiei, s-ar fi ales metoda
execuţiei ei, bazată pe scanarea ciclică V cu selecţia cortejelor, ce stisfac condiţiei. Adresarea
aşa s-ar fi executat, pentru că în cele din urmă să dea un rezultat gol. Însă la contopirea formelor
interne a adresării şi configuraţii am fi primit o formă internă, echivalentă adresării SELECT C1
FROM R WHERE C1<6 AND C1>6.
În faza optimizării logice s-ar putea determina că această adresare este echivalentă
adresării:
SELECT C1 FROM R WHERE FALSE, de unde ar rezulta că rezultatul adresării este
gol.
Din mulţimea de cazuri acest caz de prelucrare a adresărilor pentru configuraţiile
bazelor de date permitea primirea execuţiei unei adresări mult mai efective pe baza oferirii
utilizatorului a mai multă informaţie. Aceeaşi ideie stă la baza optimizării semantice a
adresărilor: utilizarea informaţiei semantice la optimizarea adresării, informaţiei păstrate în baza
de adte indiferent de adresarea dată.
Un alt exemplu de creare a adresărilor, ce au legătură cu optimizarea, este crearea
adresărilor pentru modificarea bazei de date cu scopul satisfacerii limitelor integrităţii 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 integrităţii se numeşte expresia logică, păstrată în registrele bazei de date,
alcătuită din predicate pe obiectele bazei de date. baza de date se află în stare întreagă, dacă se
satisfac toate limitele integrităţii date.
Dacă se adresează o adresare pentru modificarea bazei de date, ce include limitele
integrităţii, satisfacerea cărora se cere la execuţia oricărei modificări, atunci putem adăuga
limitelor predicatele corespunzătoare pentru condiţia logică a adresării.
Fie că baz de date, ce caracterizează structura organizării, e alcătuită din relaţiile EMP şi
DEPT. În relaţia EMP se înregistrează organizaţiile muncitoreşti. Schema acestei relaţii
EMP(EMP#,EMPNAME,DEPT#); cîmpul EMP# conţine numărul unic a muncitorului; cîmpul
EMPNAME – numele muncitorului, iar DEPT# - numărul secţiei organizaţiei în care lucrează
acest muncitor. Relaţia DEPT păstrează informaţia despre secţii şi are schema: DEPT(DEPT#,
EMPTCOUNTS) unde în cîmpul EMPTCOUNTS se păstrează numărul total de muncitori a
acestei secţii. Fie că este dată limita integrităţii ASSERT B IMMEDIATE ON
EMP:EMP.DEPT#=6.
Această limită înseamnă interzicerea introducerii ştergerii şi modificării cortejelor în
relaţia EMP cu valoarea cîmpului DEPT# diferită de 6. Fie că se prelucrează adresarea pentru
ştergerea cortejului DELETE EMP WHERE EMPNAME =”Brown”.
Dacă la compilarea adresării nu ţinem cont de prezenţa limitei integrităţii, atunci metoda
corectă de execuţie a aşa adresare va fi: să alegem cortejele la care valoarea cîmpului
EMPNAME este “Brown”; de controlat satisfacerea următorului cortej cu limita integrităţii şi
dacă controlul este satisfăcător să se şteargă cortejul.
Dacă limitele integrităţii se iau în vedere în timpul compilării, atunci putem contopi
formele interne a adresării şi limitele integrităţii corespunzătoare, iar apoi de prelungit
optimizarea în comun. În cazul nostru după contopire se formează forma internă, echivalentă a
adresării.
DELETE EMP WHERE EMPNAME=”Brown” AND DEPT#=6
La execuţia a aşa tip de adresare nu va fi nevoie de apelurile adăugătoare a controlului
limitelor integrităţii de tipul 2, căci ele toate de acum sunt incluse în condiţia logică de execuţie a
operaţiei de ştergere. În afară de aceasta optimizatorul primeşte o libertate în alegerea modului
de execuţie a adresării, de exemplu, dacă secţiile sunt puţine şi pentru relaţia EMP se menţine
indexul pe cîmpul DEPT#, atunci, modul cel mai optimal de execuţie a adresării va fi scanarea
relaţiei prin index DEPT# cu condiţia DEPT#=6 cu ştergerea oricărui cortej ales în aşa mod, cu
valoarea cîmpului EMPNAME egal cu “Brown”. În aşa fel, metodele ce creează adresareas nu
sunt îndreptate în special spre optimizare, ele pot ajuta la o execuţie mai efectivă a adresării.
Eficacitatea execuţiei adresării se poate ridica pe contul cunoştinţelor utilizate, păstrate
independent în BD.
Exemplele studiate ne arată că ideiea optimizării semantice, în principiu, nu este nouă. Se
posedă şi diferenţa proincipală dintre adresările văzute mai sus şi cele care se creează la
optimizarea semantică. Deosebirea de bază constă în aceea, că atunci cînd are loc contopirea
formei interne a adresării cu forma internă a configuraţiei sau cu formele interne a limitelor
integrităţii, suntem obligaţi să utilizăm total şi neapărat informaţia externă independent de faptul,
va ajuta aceasta la optimizarea adresării: condiţia de selecţie a configuraţiei trebuie să fie total
adăugată prin AND către condiţia de selecţie a adresării; aceeaşi se referă şi la setul de condiţii
logice a limitelor integrităţii. De altfel semantica adresării pentru configuraţie sau operatorul de
modificare a BD va fi încălcată.

18.3.2. Utilizarea informaţiei semantice la optimizarea adresărilor


optimizarea semantică se bazează pe posesia de către BD a informaţiei semantice ce nu
este neapărat de utilizat la prelucrarea adresărilor, dar utilizarea căreia poate duce la o execuţie
mult mai optimală. Dacă optimizarea semantică are de lucru doar cu cunoştinţele prezentate în
forma limitelor integrităţii BD, atunci la optimizarea semantică se creeează o mulţime de
configuraţii interne a adresării; la fiecare creare se utilizează un oarecare set de limite a
integrităţii. Dacă, de exemplu, în BD sunt determinate două limite a integrităţii A şi B cu
condiţiile logice F1 şi F2 şi se prelucrează adresarea cu condiţia de selecţie F atunci, în mersul
optimizării semantice vor fi primite configuraţiile interne echivalente adresărilor cu condiţiile F,
F AND F1, F ANDF2 şi F AND F1 AND F2. Fiecare din configuraţiile interne primite se
impune unei prelucrări totale pe parcurs, inclusiv optimizarea logică şi alegerea planului optimal
de execuţie; din planurile primite(toate ele sunt echivalente semantic, adică au acelaşi rezultat) se
alege cel mai eftin care şi va deveni planul real de execuţie a adresării iniţiale.
Pentru utilizarea raţională a optimizării semantice este comod de a reprezenta limitele
integrităţii BD în formă implicativă. Atunci se va putea obţine o ordine mai gîndită a creerilor.
Fie, de exemplu, în baza noastră de date despre structura organizaţiei, relaţia EMP e lărgită de
cîmpurile STATUS şi SALARY. Valorile cîmpului STATUS caracterizează funcţia
lucrătorului, iar cîmpull SALARY – salariul său. Poate fi specificată limita integrităţii exprimată
prin aceea, că salariul ce întrece 40000 poate fi specificat numai şefilor de secţii:
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 considerăm caracterul implicativ a limitei integrităţii, atunci, după regulile
generale, va avea loc contopirea configuraţiilor interne a adresării şi limitei integrităţii, care nu
va da nimic. Dar dacă vom privi limita integrităţii ca regulă a creării, dar partea stîngă a
implicaţiei ca condiţie de utilizare a regulii, atunci contopirea nu va avea loc, ci în acz general va
economisi timpul prelucrării adresării. 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”
execuţia căreia poate fi cu mult mai efectivă.
După crearea adresării, în corespundere cu careva reguli, către configuraţia primită poate
fi utilizată şi altă regulă, etc. Este posibilă operaţia ciclurilor de creare. Problema construirii
setului întreg de configuraţii 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 execuţia adresării în plan mai optimal. De aceea este nevoie de a utiliza algoritmi
euristici, ce îngustează spaţiul căutării, adică care indică condiţia de încetare a generaţie a noilor
configuraţii.euristica se bazează pe minimizarea sumei externe a costului optimizării semantice
şi execuţiei adresării.
Ca exemplu de euristică aspră poate fi următorul: optimizarea se face pînă atunci, pînă
cînd cheltuielile pentru ea nu vor întrece preţul celui mai efectiv din toate planurile găsite de
execuţie a adresărilor.

18.4. Selecţia şi aprecierea planurilor alternative de execuţie a adresărilor

18.4. Selecţia şi aprecierea planurilor alternative de execuţie a adresărilor


Creerile optimizatoare, studiate mai sus, lăsau configuraţia internă a adresării
neprocedurală.
Configuraţia procedurală sau plan de execuţie a adresării se numeşte o aşa configuraţie a
ei în care este detaliată ordinea de execuţie a operaţiilor de acces la BD de nivel fizic. De regulă,
în SGBD relaţionale se depune subsistemul de dirijare cu datele la nivel fizic. În System R aşa
sistem se numeşte RSS(Relational Storage System) şi asigură interfaţa simplă, ce permite analiza
consecutivă a cortejelor relaţiilor ce satisfac condiţiilor date pentru valorile cîmpurilor, cu
utilizarea indexilor sau a scanărilor simple a paginilor BD. În afarăţ de aceasta, RSS permite
crearea fişierelor temporale sortate şi introducerea, ştergerea şi modificarea cortejelor
individuale. Aşa fel de subsisteme mai calr sau mai puţin clar se distinct în fiecare SGBD de aşa
fel. Este clar, că pînă la execuţia adresării este nevoie de crearea configuraţiei sale procedurale.
Deoarece acesta se selecţionează diferit, este nevoie de ales dintre planurile alternative a
adresărilor unul în dependenţă de careva trighere. De regulă, criteriul de selecţie a planului de
execuţie a adresării este minimizarea costului execuţiei.
Cu toate acestea, în timpul prelucrării adresării la stadiul următor după optimizarea
logică, se soluţionează două probleme. Prima problemă: reeşind din configuraţia internă a
asdresării şi informaţiei ce caracterizează structura de dirijare a bazelor de date(de exemplu
indexii), de ales setul planurilor potenţial posibile de execuţie a adresării date. problema a doua:
de apreciat preţul execuţiei adresării în dependenţă de fiecare plan alternativ şi de ales planul cu
preţul cel mai redus.

18.4.1. Generarea planurilor


La o apropiere tradiţională către organizarea optimizatorilor ambele probleme se
soluţionează pe baza algoritmilor fixaţi reglementaţi în optimizator. Optimizatorul poate fi
utilizat şi pentru faptul că limitarea oricărei relaţii, în dependenţă de predicatul dat, poate fi
executată pe calea oricărei analize consecutive a relaţiei. În aşa fel adresarea
SELECT EMPNAME FROM WHERE
DEPT#=6 AND SALARY>15000
poate fi executat pe baza scanării consecutive a relaţiei prin indexul I1, determinat pe
cîmpul DEPT#, cu condiţia de acces către indexul DEPT#=6 şi cu condiţia de selecţie a
cortejului SALARY>15000; în sfîrşit, scanării relaţiei prin indexul I2, determinat pe cîmpul
SALARY, cu condiţi a de acces la indexul SALARY>15000 şi condiţia de selecţie a cortejului
DEPT#=6.
Analog se fixează strategiile de execuţie a operaţiilor mai complicate – conexiuni
relaţionale a relaţiilor, calculul funcţiilor de agregat pe grupele cortejurilor relaţiilor ş.a. de
exemplun în System R pentru ecviconexiuni a două relaţii se utilizează două strategii de bază:
metoda ciclurilor implementate şi metoda sortării cu topiri.
Componenta optimizatorului, care generează planurile executabile a adresărilor arte o
organizare complicată; generarea planului execuţiei unei adresări complicate este un proces
momentan, în mersul căruiea se iau în consideraţie proprietăţile, ce se creează în timpul execuţiei
adresărilor după planul dat a obiectelor temporale a BD.
De exemplu, fie că adresarea e dată pentru trei relaţii şi în adresare sunt două predicate de
legătură:
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 adresării se selectează ordinea execuţiei legăturilor întîi R1 cu R2,
iar apoi relaţia temporală primită R3 şi pentru execuţia primei conexiuni se alege metoda
sortărilor cu contopiri, atunci relaţia temporală va fi sortată din timp după C5 şi de o sortare nu
va fi nevoie dacă şi a doua legătură se va executa prin aceeaşi metodă.
Componenta optimizatorului ce duce la crearea mulţimii de planuri alternative a
execuţiei adresării se bazează pe strategii de împărţire a adresării în componente elementare şi pe
strategiile de execuţie a componentelor elementare. Prima grupă de strategii determină spaţiul de
căutare a planului optimal de execuţie a adresării, a doua este îndreptată spre aceea că în acest
spaţiu într-adevăr să se găsească planuri optimale de execuţie a adresării. Cheiea către asigurarea
execuţiei efective a adresării complicate este posesia strategiilor efective de execuţie a
componentelor elementare. Aceasta este o întrebare importantă, dar nici noi nu o analizăm:
optimizatorul adresărilor utilizează strategiile implementate. Să analizăm problema mai actuală a
optimizatorului – selecţia celui mai bun plan de execuţie a adresării din mulţimea planurilor
alternative.

18.4.2. Aprecierea costului planului adresării


După generarea mulţimii de planuri a execuţiei adresării pe baza strategiilor relaţionale
de împărţire şi a strategiilor de execuţie a operaţiilor elementare trebuie de ales un singur plan, în
conformitate cu care va avea loc execuţia adresării. În caz de selecţie greşită adresarea se va
efectua neefectiv.
În primul rînd trebuie de determinat, ce se subînţelege sub eficacitatea execuţiei
subadresării. Această subînţelegere depinde de specificul mediului operaţional a SGBD. În
unele condiţii putem considera, că eficacitatea execuţiei adresării se determină de timpul
execuţiei sale, adică de reactivitatea sistemului în dependenţă de sistemul prelucrat de ea. În alte
condiţii determinativă este posibilitatea generală de permisiune a sistemului în dependenţă de
amestecul adresărilor executarea lor în paralel. Atunci ca măsură a eficacităţii putem socoti
numărul de resurse a sistemului, ce trebuiesc pentru execuţia lui, ş.a.
Urmînd tehnologia dată, , vom vorbi despre costul planului de execuţie a adresării,
determinat de resursele procesorului şi unităţile memoriei externe, care se dau la execuţia
adresării.
În SGBD relaţionale se destinge subsistemul de dirijare cu accesul către datele în
memoria externă(RSS a System R).
Tradiţional, datele în memoria externă se păstrează 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 puţine cheltuieli. De regulă
sistemele de dirijare cu accesul către date în memoria face buferizarea blocurilor bazei de date
în memoria operativă. Fiecare bloc se păstrează în unul din buferele SGBD pînă cînd nu va fi
scos de alt bloc a BD. Această deosebire a SGBD este de bază pentru ridicarea eficacităţii
generale a sistemului dar nu se scoate(în afară de cazul particular dar important) la aprecierea
costurilor planurilor de execuţie a adresărilor. În orice caz, componenta costului de execuţie a
adresării, legat de resursele memoriei externe, depinde monoton de numărul blocurilor memoriei
externe, accesul către cre va trebui pentru execuţia adresări.
Din altă parte, numărul blocurilor memoriei externe accesul către care trebuie la execuţia
adresării, depinde monoton de numărul cortejurilor, atinse de adresare.
Din aceasta rezultă importanţa indicatorului predicatului de linii, ce caracterizează partea
cortejurilor relaţiei, care satisfac predicatului dat şi care se numeşte nivelul de selecţie a
predicatului. Nivelul de selecţie a prediactelor simple de tipul R.C or const, unde R.C dă numele
cîmpului relaţiei BD, or – operaţia de comparaţie., dar const - constantă, sunt bazele pentru
costurile planurilor adresărilor. Percizia aprecierii nivelurilor de selecţie determină precizia
aprecierilor generale şi corectitudinea alegerii planului optimal a adresării.
Nivelul selectivităţii predicatului R.C or const depinde de tipul operaţiei de comparaţie,
introducerea constantelor şi răspîndirea valorilor cîmpurilor C a relaţiei R în BD. Primii doi
parametri de selecţie pot fi cunsocuţi la efectuarea aprecierilor, dar răspîndirile reale a valorilor
cîmpurilor relaţiilor, de regulă nu sunt cunoscute. Exeistă un şir de apropieri către relaţiile de
răspîndire pe baza informaţiei statistice. Vom analiza mai apoi cele mai interesante dintre ele.
Dacă este cunoscut nivelul selectivităţii a predicatului limitei relaţiei, atunci este cunoscută
puterea relaţiei rezultante(de regulă puterile relaţiilor păstrate sunt cunoscute la prelucrarea
adresării). Dar în formulele de apreciere se iau în consideraţie numărul de schimburi cu
memoria externă, care-i cerut pentru execuţa adresării. Desigur, numărul cortejurilor este preţul
superior a numărului nevoit de schimburi, dar acest cost poate fi foarte ridicat. Totul depinde
de răspîndirea cortejurilor pe blocurile memoriei externe. Într-un rînd de costuri putem primi un
preţ mai precis a numărului de blocuri. În sfîrşit, pentru adresările complicate, ce includ de
exemplu , conexiunea a mai mult de două relaţii, este nevoie de apreciat dimensiunile relaţiilor
intermediare ce apar în procesul execuţiei adresării. Pentru a aprecia puterea rezultatului a
conexiunii a două relaţii, trebuie de ştiut nivelul de selectivitate a predicatului de conexiune în
legătură cu crearea directă a relaţiilor–operanzilor. În caz general, este imposibil de determinat
pe baza informaţiei statistice nivelul de selectivitate a aşa 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 răspîndirii valorilor cîmpurilor
relaţiilor: se presupune că valorile cîmpurilor a toate relaţiile BD sunt răpîndite egal şi că
valorile a oricare două cîmpuri sunt răspîndite independent. Prima propunere permite de apreciat
selectivitatea predicatelor simple pe baza informaţiei sintactice despre BD. Pe a doua
propunere se bazează aprecierile numărului de blocuri, în care se găseşte numărul cunoscut de
corteje. Aceste două propuneri sunt obiectul de critică a System R. Ele sunt formate doar cu
scopul simplificării optimizatorului şi nu pot fi lămurite 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 adevărate.
În registrele BD, pentru fiecare relaţie R se memorează numărul cortejelor în relaţia
dată(T) şi numărul blocurilor memoriei, în care se află cortejele relaţiei(N); pentru fiecare cîmp
C a relaţiei se păstrează numărul diferitor valori a acestui cîmp(CD); valoarea memorabilă
minimală a acestui cîmp(Cmin) şi valoarea maximală(Cmax).
La posedarea acestei informaţii , luînd în consideraţie prima propunere a bazei de selecţie
a predicatelor simple, se calculează simplu(şi precis, dacă răspîndirea este egală). Fie că SEL(P)
este nivelul de selectivitate a predicatului P. Atunci:
SEL(R.C=const)=CD/(CMax-Cmin)
(la răspîndire egală nivelul selectivităţii a aşa predicat nu depinde de valoarea constantei).
SEL(R.C>const)=(Cmax-const)/(Cmax-Cmin), şi altele. La aprecierea numărului de
blocuri în care se pot afla cortejele ce satisfac predicatului R.C or const, se deosebesc cazuri de
clasterizare sau neclasterizare a relaţiei pe cîmpul C. Aceste aprecieri au sens numai la studierea
variantului sacnării relaţiei cu utilizarea indexului pe cîmpul C. La studierea relaţiei fără
utilizarea indexului va trebui de adresat în totdeauna fix la N blocuri de memorie externă.
Presupunerile despre egalitatea răspîndirii valorilor atributelor relaţiilor premit de a
aprecia simplu şi puterile relaţiilo, care sunt rezultatele operaţiilor bilocale relaţionale şi teoriilor
mulţimilor pentru relaţii.
Aprecierea selictivităţii predicatelor se utilizează şi la aprecierea cheltuirlilor resurselor
procesorului. Se presupune că partea de bază a prelucrării procesorale are loc în RSS. De aceea
cheltuielile procesorale se măsoară prin numărul de adresări şi RSS ce corespunde numărului
cortejelor, ce se primesc la scanarea relaţiei memorabile sau temporale, adică prin selectivitatea
expresiei logice, alcătuită din predicate simple(condiţia de selecţie a nivelului RSS). Propunerea
despre egalitatea şi independenţa valorilor diferitor cîmpuri a relaţiei permite uşor de apreciat
selectivitatea expresiei logice, alcătuită din predicate simple la nivelurile lor de selecţie
cunoscute.
Într-adevăr, în System R nu se apreciază selectivitatea predicatelor în mod direct.
Aprecierea optimizatorului se bazează pe informaţia statistică despre BD; execuţia oricărei
adresări constă dintr-o combinaţie a cîtorva acţiuni elementare. Ca exemple de execuţii
elemenare pot fi execţuţia limitei relaţiei pe calea scanării sale prin indexul clasterizat, sortarea
relaţiei, conexiunea celor două relaţii sortate mai devreme, ş.a. aprecierea generală a planului de
execuţie are loc într-un proces iterativ, începînd cu aprecierile operaţiilor elementare peste
relaţiile memorabile.

18.4.3. Aprecierile mult mai precise


Să trecem la analiza aprecierilor mai precise a costurilor execuţiei planurilor
adresărilor. Aceste adresări le putem diviza în două clase. La utilizarea metodelor primei clase
optmizatorul păstrează o structură aspră, analogică structurii optimizatorului SystemR, dar
luarea aprecierilor se bazează pe o informaţie statistică mai precisă, ce caracterizează
răspîndirea relaţiilor.
Metodele clasei a doua sunt mai revoluţionare şi reiese din faptul că pentru formarea
planurilor de execuţie a adresărilor şi a aprecierilor lor, optimizatorul trebuie să se satisfacă cu o
oarecare informaţie, caracteristică pentru o sferă concretă a adăugărilor. La rezultatul metodei
despre egalitatea răspîndirilor valorilor cîmpului relaţiei trebuie de specificat răspîndirea reală a
valorilor.
Există două metode de bază a aprecierilor de răspîndire a valorilor cîmpului relaţiei:
parametrică şi bazată pe metoda signaturilor.
Apropierea System R este un caz trivial particular a metodei parametrice de apreciere a
răspîndirii – orice răspîndire se apreciează ca fiind egală. Într-o apreciere mai dezvoltată, s-a
propus utilizarea seriei de răspîndiri a lui Pirson pentru aprecierea răspîndirii reale a valorilor
cîmpurilor relaţiei, în care intră răspîndirile de la egale la normale. Răspîndirea se alege din serie
pe calea calculului cărorva parametri pe baz secţiilor valorilor reale întîlnite. Exemple a
implimentării în practică a acestei apropieri nu ne sunt cunoscute.
Metoda aprecierii răspîndirii pe baza signaturilor poate fi descrisă în felul următor.
Sfera vaorilor cîmpuluise împarte în cîteva intervale. Pentru fiecare interval printr-o metodă
oarecare se stabileşte numărul de valori a cîmpului, ce nimeresc în acest interval. În acest
interval valorile se răspîndesc după o lege fixată( de regulă se aplică apropierea egală). Să
analizăm două apropieri alternative, legate de descrierea signaturală a răspîndirilor.
La apropierea tradiţională, sfera valorilor cîmpului se împarte în N intervaluri de mărimi
egale şi pentru fiecare interval se socoate numărul valorilor cîmpurilor din cortejele relaţiiei date,
care nimeresc în interval. Să presupunem că EMP este lărgită de încă un cîmp AGE, care indică
lista lucrătorului. Fie că de tot în organizaţie lucrează 60 de colaboratori în vîrstă de la 10 la 60
de ani. Atunci histograma ce reprezintă răspîndirea valorilor cîmpului AGE poate avea tipul,
arătat mai jos în desen. Histograma e construită reeşind din împărţirea diapazonului valorilor
cîmpului AGE în 10 intervaluri.
Să analizăm faptul cum putem aprecia selectivitatea predicatelor simple, indicate în
cîmpul AGE, utilizînd aşa program. . fie că în intervalul de valori AGE Si nimeresc Ki valori.
Atunci SEL(EMP.AGE=const), dacă valoarea constantei nimereşte în intervalul valorilor Si,
poate fi apreciată în felul următor: 0<=SEL(EMP.AGE)<=Ki/T(t – numarul total de corteje in
relatia EMP). De aici rezultă aprecierea medie a nivelului selectivităţii 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, decît cele ce se pot primi din propunerile despre
egalitatea răspunsurilor. Dar nu aşa de bine stau lucrurile cu aprecierile selectivităţii a
predicatelor simple cu neegalităţi.
De exemplu, fie că trebuie de apreciat nivelul selectivităţii predicatului EMP.AGE<const.
Dacă valoarea constantei nimereşte î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 selectivităţii (SUMi-1+SUMi)/(2(T) şi eroarea aprecierii
poate atinge jumătate din greutatea subsferei, în care nimereşte valoarea constantei predicatului.
Cel mai neplăcut este faptul că eoarea aprecierii depinde de valoarea constantei şi cu atîtmai
mult, cu cît sunt mai multe valori a cîmpului în intervalul dat a histigramei. De exemplu,
SEL(AGE<29) se apreciază ca 46/100<=SEL(AGE<29)<=86/100, de unde aprecierea nivelului
selectivităţii este (46+86)/200=0,66; eroarea aprecierii poate atinge 0,2. În acelaşi timp
SEL(AGE<49) se apreciază mai precis.
Pentru înlăturarea acestui neajuns a fost propusă altă apropiere către descrierea
răspîndirilor valorilor cîmpului relaţiei. Ideea apropierii constă în aceea că mulţimea valorilor
cîmpului se împarte în intervaluri de dimensiuni diferite, pentru ca în fiecare interval(în afară de
ultimul) să nimerească un număr egal de valori a cîmpului. Numărul intervalelor se alege în
dependenţă de limitele memoriei şi cu cît ele sunt mai mari, cu atît aprecierile sunt mai clare. La
împărţirea sferei valorilor în 10 intervale harta pseudohistogramică a răspîndirilor valorilor
cîmpului AGE e arătată mai jos.
Sfera valorilor cîmpului AGE a relaţiei EMP e împărţită în 10 intervale, în aşa mod, că
în fiecare interval nimeresc fix 10 valori a cîmpului AGE. Intervalele au diferite dimensiuni.
Valorile de hotar a intervalelor sunt arătate deasupra limitelor verticale. În pseudohistogramă se
admit intervale, graniţele de dreapta şi de stînga a cărora coincid, de exemplu intervalul (28;28).
El s-a format din cauza prezenţei în relaţia EMP a unui număr mare(mai mare ca 10) de corteje
cu valoarea AGE=28. La utilizarea pseudohistogramei erorile în aprecierea nivelului de
selectivitate a predicatelor cu operaţia, diferită de egalitae, scad. Mărimea erorii nu depinde de
valoarea constantei şi se micşorează la mărirea numărului de intervale. Neajunsul metodei
pseudohistogramice în comparaţie cu histogramele constă în aceea că este prezentă necesitatea
de sortare a relaţiilor după valorile cîmpurilor pentru construirea pseudohistogramei de
răspîndire a valorilor cîmpului dat. Este cunoscută apropierea , ce permite primirea
pseudohistogramei fără necesitatea sortării relaţiei întregi.
Apropierea se bazează pe statistica lui Colmogorov, din care, atribuind-o la BD
relaţionale, rezultă că din regulă se alege exemplul din 1064 de corteje şi b este porţiunea
cortejelşor în exemplu cu valorile c<V, atunci cu încrederea de 99% porţiunea cortejelor, în toată
relaţia, cu valorile cîmpului c<V se află în intervalul [b-0,05;b+0,05].
La micşorarea puterii exemplului încrederea scade.
SGBD în arhitectura “Client-Server”

SGBD în arhitectura “Client-Server”


Lecţia 19. Arhitectura “Client-Server”
Întrebuinţînd către arhitectura bazelor de date “Client-Server” este interesantă şi actuală
în primul rînd de aceea, că asifâgură rezolvarea simplă şi ieftină a problemei accesului colectiv
la bazele de date în reţeaua locală. Într-o oarecare măsură, sistemele BD, bazate pe arhitectura
“Client-Server”, sunt apropierea către sistemele răspîndite de BD, desigur o apropiere mai
simplificată, dar care nu cere soluţionarea setului de probleme a BD răspîndite.

19.1. Sistemele deschise

19.1. Sistemele deschise


Răspîndirea reală a rihitecturii “Client-Server” a devenit posibilă datorită dezvoltării şi a
implimentării largi în practică a concepţiei sistemelor deschise. Deci vom începe de la o scurtă
introducere a sistemelor deschise.
Scopul principal a apropierii de sistemele deschise este simplificarea complexităţii
sistemelor de calcul pe baza standartizării internaţionale şi naţionale a interfeţelor hard şi soft.
Cauza principală a apariţiei dezvoltării concepţiei sistemelor deschise este trecerea la folosirea
reţelelor computerizate locale şi a celor probleme de complexare a resurselor aparato-
programale, ce au fost create de această trecere. În legătură cu dezvoltarea grabnică a
tehnologiilor comunicaţiilor globale, sistemele deschise au atras o mai mare atenţie şi au o scară
mai largă. Fraza cheie a sistemelor deschise, îndreptată spre utilizator, este independenţa de
producătorul concret. Orientîndu-se spre producţia companiilor, ce se menţin de standartele
sistemelor deschise, utilizatorul, ce procură orice produs al acestei companii, nu devine rob a ei.
El poate continua creşterea puterii sistemului său pe calea procurării produselor a oricărei alte
companii, care respectă standartele. Aceasta se referă cît la mijloacele aparatale, atît şi la
mijloacele programabile şi nu este o declaraţie fără explicaţie. Posibilitatea reală de independenţă
de producător este controlată în condiţiile noastre naţionale. Baza practică a surselor sistem şi
program aplicate a sistemelor deschise este sistemul operaţional standartizat. În prezent aşa
sistem este UNIX. Firmele producătoare a diferitor variante OS UNIX în rezultatul lucrărilor
îndelungate, au reuşit să ajungă la concluzia despre standartele bazate ale acestui sistem
operaţional. Acum, toate versiunile răspîndite a OS UNIX, mai ales cele bazate pe interfeţe, sunt
colaborabile în problema interfeţelor, reprezentate programatorilor aplicaţi. După cum se pare,
necătînd la faptul apariţiei sistemului ce tinde la standart WINDOWS NT, anume UNIX va
rămîne 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 proprietăţi de
mobilitate(portability) şi de interoperabilitate(interoperability). Posibilitatea mobilităţii indică
simplitatea comparabilă a posibilităţii sistemului program în spectrul larg a surselor program-
aparatale, ce corespund standartelor. Interoperabilitatea înseamnă simplificările complexării
noilor sisteme program pe baza utilizării componentelor gata cu interfeţe standarte.
Utilizarea apropierii de sistemele deschise este convinabilă şi utilizatorilor şi
producătorilor. În primul rînd, sistemele deschise asigură soluţionarea reală a problemei
generaţiilor de surse program şi aparate. Producătorii de aşa surse nu se impun de a soluţiona
toate problemele din nou; ei pot continua complexarea sistemelor, utiliyînd componentele
existente. Să menţionăm, că în acest timp apare un nivel nou de construcţie. Toţi producătorii
sunt datori să urmărească, să asigure o sferă standartă, dar sunt impuşi să ajungă la o realizare a
ie cît 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 nepierzînd eficacitatea
lucrului sistemului.

19.2. Clienţii şi serverele reţelelor locale

19.2. Clienţii şi serverele reţelelor locale


La baza răspîndirii largi a reţelelor locale a calculatoarelor stă ideiea cunoscută de
împărţire a resurselor. Posibilitatea înaltă de permisiune a reţelelor locale asigură accesul efectiv
de la un nod al reţelei locale la resursele, din alte noduri.
Dezvoltarea acestei idei duce la delimitarea funcţională a componentelor sistemului:
este raţional 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 căruia, se dublau în cîteva noduri. Aşa noi ajungem la diferenţa dintre staţiile
lucrătoare şi a serverelor reţelei locale.
Staţia de lucru este destinată lucrului utilizatorului sau a categoriei de utilizatori şi deţine
resurse ce corespund necesităţilor locale a utilizatorului dat. Deosebirile specifice a staţiei de
lucru pot fi volumul memoriei operative(nu toate categoriile de utilizatori au nevoie de deţinerea
a unei memorii operative mari), posesia şi volumul memoriei pe disc(sunt populare staţiile de
lucru fără disc, ce utilizează memoria internă a serverului de disc), caracteristicile procesorului şi
a monitorului(unii utilizatori au nevoie de un procesor puternic, alţii au nevoie de accelerarea
graficii, ş.a.). La nevoie, putem utiliza resursele şi/sau serviciile asigurate de server.
Serverul reţelei locale trebuie să posede resursele, ce corespund scopului său funcţional
şi cerinţelor reţelei. Să accentuăm, că în legătură cu orientarea spre orientarea sistemelor
deschise, mai corect vorbeşte despre serverele logice(avînd în vedere setul de resurse şi mijloace
programare, ce asigură serviciile pe aceste resurse), care se implementează nu neapărat 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 fără necesitatea
schimbării cărorva componente atît în calculator, cît şi în programele aplicate utilizate de el.
Ca exemple de server pot fi: serverul telecomunicaţiilor, ce asigură serviciile în legătura
reţelei locale cu lumea externă; serverul de calcul, ce dă posibiitatea de a efectua calcule, ce nu
pot fi efectuate în staţiile de lucru.
Serverul bazei de date este de fapt o SGBD simplă, ce primeşte adresări prin reţeaua
locală şi care întoarce rezultatele.
Serverul reţelei locale, oferă resurse(servicii) staţiilor de lucru şi/sau altor servere.
Este convenit de numit client a reţeleilocale, ce cere servicii de la un server oarecare şi
server – componenta reţelei locale, ce oferă servicii cărorva clienţi.

19.2. Arhitectura de sistem “Client–Server”

19.3. Arhitectura de sistem “Client–Server”


Este clar că în caz general, pentru ca programul aplicat, ce se execută în staţia de lucru, să
poată adresa sau cere serviciul de la careva server, se cere ca minimum un oarecare slav
interfaţional programal, ce menţine aşa tip de conluccrare(ar fi fost nreal de cerut ca programul
aplicat să utilizeze direct primitivele nivelului de transport a reţelei locale). Din aceasta şi reiese
prinicpiile arhitecturii de sistem “Client–Server”.
Sistema se împarte în două părţi, ce se pot executa în diferite noduri a reţelei – partea
clientului şi a serverului. Programul aplicat sau utilizatorul final colaborează cu partea clientabilă
a sistemei, care în cel mai simplu caz, asigură interfaţa asupra reţelei. Partea clientabilă a
sistemei, în caz de necesitate, se adresează în reţea către partea serverului. Să accentuăm, că în
sistemele dezvoltate, adresarea de reţea către partea serverului poate să nu fie necesară, dacă
sistema ar putea ghici necesităţile utilizatorului şi în partea clientabilă se găsesc date ce pot
satisface adresarea sa următoare.
Interfaţa părţii serverului este determinată şi fixată. De aceea este posibilă crearea noilor
părţi clientabile a sistemului existent.
Problema de bază a sistemelor bazate pe arhitectura “Client–Server”, este aceea că în
corespondenţă de concepţia sistemelor deschise de la ele se cere mobilitatea în cît se poate o
clasă mai largă a hotărîrilor programo-aparatice a sistemelor deschise. Dacă UNIX s-ar limita la
reţelele locale orientate, în diferite sisteme se utilizează aparataje diferite şi protocoale de
legătură.
Încercările creării sistemelor, ce ar menţine toate protocoalele posibile duce la
supraîncărcarea lor cu detalii de reţea în înrăutăţirea funcţionalităţii.
Un alt aspect mai complicat a acestei probleme este posibilitatea utilizării diferitor
cinfiguraţii a datelor în diferite noduri a reţelei neomogene locale. În diferite calculatoare pot
exista adresări diferite, afişări a numerelor, codarea simbolurilor, ş.a. Aceasta este foarte
important pentru serverele de nivel înalt: de telecomunicaţii, de calcul, a bazelor de date.
O soluţionare comună a mobilităţii sistemelor, bazate pe arhitectura “Client–Server” este
bazarea pe pachetele programale, ce realizează protocoalele de chemare lichidată a
procedurilor(RPC – Remote Procedure Call). La utilizarrea acestor mijloace, adresarea către
serverul din nodul lichidat arată ca un apel simplu a procedurii. Sursa APC, în care, în care se
păstrează informaţia despre specificul aparatajului a reţelei locale şi a protocoalelor de reţea,
transferă apelul în consecutivitatea colaborării de reţea. Specificul sferei de reţea şi a
protocoalelor este ascunsă de programatorul aplicat.
La apelul procedurii lichidate a programei RPC creează reformarea formatului datelor
clientului în formate temporale independente maşinal, şi apoi sursele reformate în formate de
date a serverului. La transferul parametrilor de răspuns au loc creeri analogice.
Dacă sistemul e realizat pe baza pachetului standart RPC ea poate fi uşor 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 “Client–Server”, inclusiv şi părţile de server şi de client. Aşa
sisteme sunt destinate pentru păstrarea şi asigurarea accesului către BD.
Deşi de obicei, o BD se păstrează în întregime într-un nod a reţelei şi se menţine de către
un server, serverele BD sunt nişte apropieri simple şi ieşite către bazele de date împărţite,
deoarece baza de date comună este accesibilă pentru toţi utilizatorii reţelei locale.

19.4.1. Principiile de colaborare dintre părţile de client şi server


Accesul la BD de la programul aplicat sau de la utilizator are loc pe calea adresării 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 interfeţei SGBD în sisteme deschise.
Denumirea SQL-Server se referă la toate serverele BD, bazate pe SQL. Respectînd atenţia la
programe, unele care au fost analizate la lecţiile trecute, pot fi create sisteme aplicate
informaţionale, mobile în clasa SQL-Server.
Sferele bazelor de date, interfaţa cărora se bazează doar pe SQL au neajunsurile şi
plusurile sale. Plusul, desigur, este standartizarea interfeţei. Părţile clientabile a oricărui SQL a
SGBD atentate ar putea lucra cu orice SQL-Server, independent de cine l-a produs.
Neajunsul, deasemenea, este clar. La aşa un nivel înalt interfeţele dintre părţile clientabile
şi cea a serverului, de partea clientului lucrează foarte puţine programe SGBD. Aceasta este
normal dacă în partea clientului lucrează o staţie slabă. Dar dacă calculatorul clientului are
destulă putere, atunci mai des apare dorinţa de a-i adresa mai multe funcţii de dirijare cu BD,
descărcînd serverul, care este locul îngust a întregii sisteme.
Una din direcţiile perspective a SGBD este configuraţia modificabilă a sistemului, faţă de
care răspîndirea funcţiilor între părţile de client şi utilizator a SGBD se determină la instalarea
sistemului.

19.4.2. Plusurile prtocoalelor a apelului lichidat a procedurilor


protocoalele văzute mai sus a apelurilor lichidate a procedurilor sunt foarte importante în
sistemele de dirijare cu BD, bazate pe arhitectura “Client–Server”. În primul rînd utilizarea
mecanismului procedurilor lichidate permite într-adevăr de a reîmpărţi funcţiile între părţile
clientului şi a serverului sistemului, căci în textul programului de lichidare, apelul procedurii nu
se deosebeşte 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 rînd, mecanismul apelului lichidat ascundedeosebirile dintre interacţiunile
calculaoarelor. Reţeaua locală fizică neomogenă a calculatoarelor se aduce la reţeaua logică
omogenă a calculatoarelor interacţionabile programabil. În rezultat, utilizatorii nu trebuie să se
îngrijoreze de cumpararea unică a staţiilor de lucru şi a serverelor împreună.

19.4.3. împărţirea funcţiilor între client şi server


În cazul tipic pentru zilele noastre, din partea clientului SGBD lucrează numai o aşa
asigurare a programului, ce nu are acces direct la BD, dar se adresează pentru aceasta către
server, utilizînd limbajul SQL.
În unele cazuri ar fi de dorit includerea în partea clientabilă a sistemei unei fincţii 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 făcut doar pe calea creerii formale de
partea clientului a copiei locale a serverului BD şi cercetării sistemului ca un set de servere
interacţionabile.
Din altă parte, cîte o dată s-ar dori de transportat marea parte a sistemului aplicat în
partea serverului, adică diferenţa dintre puterile staţiilor de lucru a clienţilor şi serverelor este
foarte mare. În general, la utilizarea RPC, aceasta este uşor de făcut. Dar e nevoie ca asigurarea
de bază programală a serverului într-adevăr ar permite aceasta. La utilizarea OS UNIX, practic
nu apar probleme.

19.4.4. Cerinţele către posibilităţile aparatelor şi către asigurarea programală de bază a


clienţilor şi serverior
din discuţiile de mai sus se vede că cerinţele către aparataj şi asigurarea programală a
calculatoarelor serverelor şi celor a clienţilor se deosebesc de tipul utilizării sistemului.
Dacă împărţirea dintre client şi server este destul de aspră(ca în majoritatea SGBD
actuale), atunci utilizatorilor ce lucrează în staţiile de lucru sau cu calculatoarele personale, le
este totuna care aparataj sau sistem operaţional lucrează pe server, de s-ar isprăvi el cu torentul
adresărilor ce apare.
Dar dacă pot apărea necesităţile de reîmpărţire a funcţiilor dintre client şi server, atunci
nu-i la fel, care operaţie a sistemei se utilizează.

Baze de date împărţite

Baze de date împărţite


Lecţia 20. BD împărţite
Condiţia de bază a sistemelor de dirijare cu BD împărţite constă în asigurarea surselor de
integrare a bazelor de date locale, ce se află în unele noduri a reţelei de calcul, cu aceea, că
utilizatorul ce lucrează în orice nod a reţelei să aibă acces la toate aceste BD ca la o singură BD.
Cu toate acestea trebuie să fie asigurate:
- Simplitatea utilizării sistemului;
- Posibilităţile funcţionării autonome la încălcarea legăturii reţelei sau la necesităţi
administraţionale;
- Nivelul înalt de eficacitate.

20.1. Multiplicitatea felurilor sistemei împărţite

20.1. Multiplicitatea felurilor sistemei împărţite


Sunt posibile BD omogen şi neomogen împărţite. În cazul omogen fiecare bază de date
locală este dirijată de una şi aceeaşi SGBD. În sistemul neomogen BD locale pot să se refere
chiar la modele diferite de date.
Integrarea de reţea a BD neomogene este o problemă actuală, dar foarte complicată.
Multe soluţii se cunosc la nivel teoretic, dar încă nu se poate soluţiona problema principală -
eficacitatea insuficientă a sistemelor integrate.
Să atenţionăm că mult mai cu succes practic se soluţionează problema intermediară –
integrarea SQL neomogene a sistemelor orientate. E clar că standartizarea limbajului SQL ajută
în mare parte acestui fapt şi faptului respectării generale a producătorilor de SGBD a principilor
sistemelor deschise. Ne vom limita la cercetarea problemelor a SGBD împărţite omogen în
exemplul System R.

20.2. Sistemul împărţit de gestiune cu BD – System R*

20.2. Sistemul împărţit de gestiune cu BD – System R*


Scopul de bază a proiectului poate fi apreciat în felul următor: de asigurat sursele de
integrare a BD locale System R*, ce se află în nodurile reţelei de calcul, cu scopul, ca
utilizatorul, ce lucrează în orice nod a reţelei, să aibă acces la toate aceste BD, ca şi cum ele ar fi
centralizate.
În acest timp trebuie să fie asigurate:
- simplitatea utilizării sistemului;
- posibilităţile funcţionării autonome la încălcarea legăturii reţelei sau la necesităţi
administrative;
- nivelul înalt de eficacitate.
Pentru soluţionarea acestor probleme era nevoie de primit un şir de soluţii, legate de
decompoziţia adresării iniţiale, selecţii optimale a mijlocului de execuţie a adresării, execuţia
permisă a trenzacţiei, asigurarea sincronizării, restabilirea stării BD după diferite tipuri de
neregulări în nodurile reţelei.
Simplitatea utilizării sistemului se atinge datorită faptului că utilizatorii System
R*(producătorii programelor aplicate şi utilizatorii finali) rămîn în sfera limbajului SQL, adică
pot să prelungească lucrul în aceleaşi condiţii externe ca şi în System R(şi SQL/DS şi BD2).
Posibilitatea utiliyării SQL se bayeayă pe locul de aflare curent a obiectelor, apelate în adresare
de către utiliyator, de date, unul şi acelaşi program aplicat, ce include cuvîntul SQL, poate fi
executată în noduri diferite a reţelei. În fiecare nod a reţelei, la etapa compilării adresării, se
alege planul optimal de execuţie a adrersării în dependenţă de aflarea datelor în sistemul împărţit.
Asigurarea autonomiei nodurilor reţelei în System R* i se dă o mare atenţie. Fiecare BD
locală se administrează independent de altele. Este posibilă conectarea autonomă a utilizării noi,
schimbul versiei părţii autonome a sistemului, ş.a. Sistemul e proiectat în aşa mod, ca în el nu
este nevoie de slujbele de enumerare a obiectelor centralizate.
În nodurile individuale nu e nevoie de prezenţa cunoştinţelor globale despre operaţii ce se
execută în alte noduri a reţelei, lucrul cu BD accesibile poate să se continuie la ieşirea din
funcţiune a nodurilor aparte a reţelelor sau a liniilor de legătură. Nivelul înalt de eficacitate a
sistemului este una dintre cele mai importante cerinţe dintre sistemele împărţite de gestiune cu
BD în general şi către System R* în particular. Pentru atingerea aceastui scop se utilizează două
măsuri de bază. În primul rînd, ca şi în System R, în System R* înainte de execuţia adresării se
face compilarea ei. În mersul acestui proces are loc căutarea numelor, utilizate în adresare, a
obiectelor BD în registrul împărţit şi schimbul numelor cu identificatori interni; controlul
drepturilor accesului utilizatorului din numele căruiea se face compilarea pentru execuţia
operaţiilor corespunzătoare pe BD şi alegerea planului de execuţie a adresării celui mai optimal
global, care se va supune decompoziţiei şi se trimite pe părţi în nodurile corspunzătoare a reţelei,
unde are loc selecţia planurilor de execuţie a componentelor adresării celui mai optimal local şi
are l,oc generarea modulelor de acces în codurile maşinii. În rezultat, o mulţime de acţiuni are
loc la stadiul compilării pînă la execuţia reală a adresării. Programul aplicat, prelucrat după
mijloacele precompilatorului System R*, ce include propoziţii SQL, poate fi executat de mai
multe ori, fără cheltuieli adăugătoare. Utilizarea catalogului împărţit, compilaţia împărţită şi
optmimizarea adresărilor sunt aspectele cele mai interesante şi mai originale a proiectului
System R*.
A doua metodă de ridicare a eficacităţii sistemului este de a transporta relaţiile lichidate
în baza de date locală. Dialectul SQL, utilizat în System R*, include propoziţia MIGRATE
TABLE, la execuţia căreiea relaţia arătată se transferă în BD locală. Acest mijloc, ce se găseşte
în mîinele utilizatorului desigur poate ajuta la primirea unor treceri mai eficative a tranzacţiilor.
Desigur, ca pentru toate operaţiile, operaţia MIGRATE în dependenţă de relaţia accentuată de
acces nu oricărui utilizator, dar numai celora ce au permisiunea corespunzătoare. Pînă a trece la o
reluare mai detaliată a celor mai interesante aspecte a realizării System R*, să amintim careva
surse, pe care producătorii acestei sisteme şi le-au propus spre realizare în stadiul începător 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 împărţire orizomtală şi verticală a relaţiilor BD
împărţie, surse de dublare a relaţiilor în cîteva moduri cu susţinerea acordului copiilor şi surse de
menţinere a pozelor momentane a stării BD în dependenţă de adresarea dată.
Pentru adresarea împărţirii orizontale a relaţiilor în SQL a fost introdusă construcţia 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 execuţia propoziţiei de aşa tip, relaţia dată se împărţea într-un rînd de subrelaţii, ce
conţin corteje, ce satisfac predicatuluiu corespunzător din despărţitura WHERE şi fiecare
subrelaţie primitor în aşa fel trimitea în nodul specificat pentru păstrarea în segmentul cu numele
dat. Se garantează starea acordată a despărţiturilor la calculul relaţiei.
Împărţirea 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 execuţia acestei propoziţii de asemenea s-a format setul de subrelaţii cu ajutorul
proiecţiei relaţiei date pe atributele din lista dată. Fiecare subrelaţie primită se trimitea pentru
păstrare în segmentul cu numele specificat în nodul corespunzător. După aceasta sistemul e
răspunzător de menţinerea stării prrimite a despăriturilor formate.
Împărţirea verticală şi orizontală a relaţiilor nu se utilizează real în System R* cu toate că
este clar că execuţia operatorului DISTRIBUTE nu cheamă nici o dificultate tehnică.
Dificultăţile apar la asigurarea acordului despărţiturilor(uite mai jos). În afară de aceasta, relaţiile
împărţite sunt greu de utilizat. În conformitate cu ideologia sistemului darea de seamă a
prezenţei despărţiturilor relaţiilor în diferite noduri a reţelei trebuie să fie făcută de optimizator,
adică numărul planurilor potenţiale posibile de execuţie a adresărilor, care trebuie să fie apreciate
de optimizator, încă mai creşte. Cu toate că în sistemul de răspîndire numărul planurilor posibile
şi aşa este mare şi optimizatorul lucrează la limita complicării, este imposibil de utilizat relaţiile
împărţite în mod relaţional. Producătorii optimizatorului System R* nu erau în stare să ţină cont
de despărţiturile relaţiilor. De aceea introducerea în sistem a relaţiilor împărţite nu are sens.
Pentru aplicarea cerinţelor de susţinere a copiilor în cîteva noduri a reţelei se propune utilizarea
noii construcţii SQL.
DISTRIBUTE TABLE <table name> REPLICATED INTO
<name> IN SEGMENT <segment-name-site>
.
.
.
<name> IN SEGMENT <segment-name-site>
La execuţia a aşa relaţie trebuie să se producă răspîndirea copiilor relaţiei specificate
pentru păstrare în segmentele cu numele nodurilor specificate a reţelei. Sistremul trebuie
automat să menţină acordul copiilor.
Ca şi în cazul relaţiilor împărţite, în afară de problemele de menţinere a acordurilor
copiilor, o problemă este şi utilizarea relaţională a copiilor, prezenţa cărora ar trebui să se
contoreze de optimizator.
Crearea cadrului momentatn a stării BD în corespondenţă cu adresarea dată de selecţie,
trebuie să se efectuieze cu utilizarea construcţiilor noi SQL.
DEFINE SNAPSHOT <snapshot-name>(<attribute-list>)
AS <query>
REFRESHED EVERY <period>
La execuţia propoziţiei, de fapt, se execută adresarea pentru selecţia specificată în ea, iar
relaţia rezultantă se păstrează sub numele specificat în propoziţie în BD locală în acel nod, în
care se execută propoziţia. După aceasta cadrul momentan se înnoieşte periodic în dependenţă de
adresarera momentană.
Putem înnoi cadrul momental, neaşteptînd trecerea intervalului de timp specificat în
determinare, pe calea execuţiei propoziţiei
REFRESH SNAPSHOT <snapshot-name>
Utilizarea raţională a cadrului momentan este mai reală, decăt utilizarea relaţiilor
împărţite şi a relaţiilor coppiate, deoarece ele pot fi privite ca nişte configuraţii materializate a
BD. Numele cadrului momentan s-ar putea utiliza în adresarea pentru selecţie acolo, unde se pot
utiliza numele relaţiilor de bază sau a configuraţiilor. Probleme complicate sunt legate de
lămurirea relaţiilor prin cadrele sale momentane, căci în momentul înnoirii, conţinutul cadrului
momentan poate să se desprindă de conţinutul curent a relaţiei de bază.
În legătură cu cadrele momentane, probleme de menţinere a stării acordate a cadrelor
momentane şi a relaţiilor de bază de date nu există, deoarece de acordare automată nu e nevoie.
Ceea ce priveşte relaţiile împărţite şi cele recopiate, atunci pentru ele această problemă este
comună şi dificilă.
În primul rînd acordarea şi copiile aduce cheltuieli la execuţia operaţiilor de modificare a
relaţiilor memorabile. Pentru aceasta este nevoie de crearea şi respectarea protocoalelor de
modificare speciale.
În al doilea rînd, introducerea relaţiilor copiate se face nu atît pentru mărirea eficacităţii
sistemului, cît pentru mărirea accesibilităţii datelor la încălcarea legăturilor relaţiilor. În
sistemele, în care se aplică această apropiere, la încălcarea legăturilor reţelei lucrul cu BD
împărţită, de obicei, se prelungeşte numai în una din relaţiile formate. În acest timp pentru
alegerea subreţelei se utilizează algoritmii de vot; hotărîrea se adoptă pe baza dării de seamă a
numărului nodurilor de legătură a reţelei. Se aplică şi alte apropieri, dar toate ele sunt foarte
scumpe, iar cel mai principal, ele rău se votează cu apropierea de bază System R* cu condiţia
selecţiei metodei de execuţie a adresării la stadiul compilării 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ă
menţină copiile relaţiilor în cîteva noduri a reţelei.
În continuare vom analiza aspectele proiectului System R*, care şi-au găsit reflexia în
realizarea sa şi care sunt mai interesante: sursele de enumerare a obiectelor şi organizarea
registrului împărţit a BD; apropierea de compilările împărţite şi execuţiile adresărilor; deosebirile
utilizării configuraţiilor; sursele de sincrinizare.

20.2.1. Enumerarea obiectelor şi organizarea registrului împărţit


Să amintim, că numele întreg a relaţiei(de bază sau configuraţiei) în BD System R are
tipul numele-utilizatorului.numele-relaţiei, unde numele-utiizatorului identifică utilizatorul-
creatorul relaţiei, iar numele-relaţiei este numele, ce a fost specificat în propoziţiile CREATE
TABLE sau CREATE VIEW. În adresări putem specifica sau acest nume plin, sau numele local.
În al doilea caz, la compilare se utilizează regulile standarte de adăugare a numelui local pînă la
plin cu utilizarea în calitate de componentă numele-utilizatorului a identificatorului utilizatorului,
de la numele căruia se face compilare.
În System R* se utilizează dezvoltarea acestei apropieri. Numele de sistem a relaţiei
include 4 componente: identificatorul utilizatorului-creatorul relaţiei, identificatorul nodului
reţelei, în care s-a efectuat operaţiunea de creare a relaţiei; numele local a relaţiei, care i s-a dat la
creare: identificatorul nodului, în care relaţia se găsea după crearea sa(să amintim că relaţia poate
să se mute dintr-un nod în altul la execuţia operaţiei 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ă interpretări a numelui local. El poate să fie interpretat ca o parte a
numelui de sistem şi în acest caz se adaugă în descreştere pînă la simetric, reeşind din
identificatorul nodului, în care are loc compilarea şi a identificatorilor utilizatorilor de la numele
cărora 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 lărgit de operatorul de tipul
DEFINE SYNONYM <relation name> AS <system wide name>
La execuţia a aşa propoziţie în catalogul local se înscrie informaţia odată.
În aşa mod, la compilarea adresării, în totdeauna putem determina numele de sistem a
tuturor relaţiilor utilizate în el: sau ele sunt specificate clar, sau pot fi primite pe baza informaţiei
din relaţiile locale a registrelor.
Concepţia registrului împărţit System R* e bazată pe prezenţa la fiecare obiect a BD
împărţite a numelui unical de sistem. S-a luat următoarea decizie: informaţia despre locul aflării
oricărui obiect a BD(identificatorul nodului curent, în care se află obiectul) se păstrează în
registrul local a acelui nod, în care obiectul se află îndată după creare(nodului de naştere).
Deci pentru primirea informaţiei întregi despre relaţie trebuie întîi să ne folosim de
registrul local a nodului, în care are loc compilarea, apoi să ne adresăm la registrul lichidat a
nodului de natere a relaţiei date şi în sfîrşit să utilizăm registrul nodului curent. În aşa fel, pentru
primirea informaţiei de sistem precise, despre oarecare relaţie a bazei de date împărţite, poate să
apară necesitatea utilizării a cel mult două accese lichidate către relaţiile–registre.
Se utilizează o optimizare a acestei proceduri. În registrul local a nodului se pot păstra
copiile elementelor registrului altor noduri(ca un fel de căş-registru). Acordarea copiilor
elementelor registrului nu se menţine. Această informaţie se utilizează în prima stadie de
compilare a adresării, iar apoi în a doua stadie, dacă informaţia, referitoare la un obiect anume,
este imprecisă, ea se va preciza pe baza registrului local a acelui nod, în care obiectul se
păstrează acum. Definirea incorectitudinii copiei elementului registrului a numărului versiei.
Dacă vom ţine cont de inerţia informaţiei în sistem, această optimizare a r putea fi importantă.

20.2.2. Compilarea împărţită a adresărilor


După cum am menţionat, adresările în limbajul SQL pînă la execuţia sa reală se impun
compilării. Ca şi în cazul System R, compilarea adresării poate avea loc în stadiul precompilării
programului aplicat, scris în limbajul tradiţional de programare(PL/1, Cobol, Assembler) cu
includerea aplicaţiilor SQL sau în dinamica execuţiei tranzacţiei la execuţia propoziţiei
PREPARE. Din punct de vedere a utilizatorilor, procesul compilării în System R*, aduce la
aceleaşi rezultate ca şi în System R: pentru fiecare propoziţie SQL se creează programul în
codurile maşinii(selecţia modului de acces, apelurile căreia încap în textul programului aplicat
iniţial. Însă, în realitate, procesul de compilare a adresării în system R* este cu mult mai
complicat ca în System R, ceea ce este real din cauza interacţiunilor de reţea mai complicate, de
care va fi nevoie la execuţia reală a tranzacţiei. Compilarea împărţită a adresărilor în System R*
include o mulţime de rafinităţi tehnice. Să analizăm schema generală a compilării împărţite.
Vom numi nod principal, acel nod, în care este iniţializat procesul compilării a
propoziţiei SQL şi noduri adăugătoare acxele noduri, ce se includ în acest proces în mersul
execuţiei lui. În cel mai grav nivel, procesul compilării se împarte în fazele următoare:
În nodul acceptat are loc împărţirea gramatică a propoziţiei SQL cu construcţia
configuraţiei interne a adresării în formă de arbore. Pe baza informaţiei din registrul local a
nodului principal şi din registrele lichidate a nodurilor adăugătoare, are loc schimbul numelor
obiectelor, ce figurează în adresarea către identificatorii lor de sistem.
În nodul numit se generează planul global de execuţie a adresării în care se specifică doar
ordinea interacţiunilor nodurilor la execuţia reală a adresării. Pînă la crearea planului global se
utilizează lărgirea tehnicii optimizării, , arătată în System R. Planul global se reflectă în
arborele adresărilor recreat în felul corespunzător.
Dacă în planul global a aexecuţiei adresăriiiau parte nodurile adăugătoare, are loc
decompilarea lui pe părţi, fiecare dintre care se poate de îndeplinit într-un nod. Părţile
corespunzătoare a adresării se trimit în nodurile adăugătoare.
În fiecare nod, ce face parte din planul global de execuţie a adresării, se execută stadiul
final de execuţie a compilaţiei. Acest stadiu include ultimile două faze a procesului de compilare
a adresărilor în System R: optimizarea şi generarea codurilor maşinale. Se efectuiează controlul
drepturilor utilizatorului, de la numele căruiea are loc compilarea, pentru execuţia lucrului
corespunzător; are loc prelucrarea configuraţiilor BD; are loc optimizarea lexicală a părţii
prelucrate a adresării în dependenţă de indexii avuţi; are loc generarea codului.

20.2.3. Dirijarea cu tranzacţiile şi sincronizarea


Efectuarea tranzacţiei în sistemul împărţit de dirijare cu BD a System R* este răspîndită.
Tranzacţia începe în nodul pricipal la adresarea către careva secţie(la etapa compilării) a
modulului de acces pregătit mai devreme. Aceste apeluri se interpretează în stilul apelurilor
procedurilor lichidate. Deci execuţia unei tranzacţii, iniţiată într-un oarecare nod a reţelei A,
induce iniţierea tranzacţiilor în nodurile adăugătoare.
O problemă importantă, nouă în comparaţie cu System R, este problema finisării
acordate a tranzacţiei împărţite, pentru ca rezultatele execuţiei 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
tranzacţiei împărţite. Acest protocol este utilizat în comun în sistemele împărţite a BD şi-i descris
în multe izvoare literare.
Pentru descrierea protocolului se utilizează modelul următor. Sunt un şir de tranzacţii
împărţite, ce se execută sub dirijarea tranzacţiei–coordinatorului. Hotărîrea despre sfîrşitul
tranzacţiei împărţite se ia de către coordinator. Apoi se execută prima fază de finisare a
tranzacţiei, cînd coordinatorul transmite fiecărui participant mesajul “pregătiţivă de finisare”.
Primind aşa un mesaj, fiecare participant trece în starea de pregătire ca la o imediată finisare a
tranzacţiei. În termenii System R* aceasta înseamnă, că buferul revistei cu înscrieri despre
schimbările BD a participantului se împing în memoria externă, iar apucarea sincronizaţională nu
se scot. După aceasta, fiecare participant, ce şi-a executat cu succes acţiunile pregătite, trimite
mesaj către coordinator mesajul “gata de finisare”. Dacă coordinatorul primeşte aşa mesaj de la
toţi participanţii, atunci el începe faza a doua a finisării, trimiţînd tuturor participanţilor mesaje
“finisaţi tranzacţia” şi aceasta se socoate finisarea tranzacţiei împărţite. Dacă nu toţi praticipanţii
au îndeplinit cu succes prima fază, atunci coordinatorul trimite tuturor participanţilor mesajul de
“înapoiaţi tranzacţia” şi atunci efectul interacţiunii tranzacţiei împărţite pe starea BD lipseşte.
În legătură cu deosebirile de realizare a protocolului bifazic de finisare a tranzacţiei în
System R* să mai amintim că: în calitate de coordinator este tranzacţia ce se execută în nodul
principal, adică aceea, pe baza căreiea au apărut tranzacţiile adăugătoare. Adică prezenţa nodului
central nu trebuieşte, ceea ce corespunde cerinţei de autonomie a nodurilor. Pentru înapoierea
tranzacţiilor se utilizează mecanismul de bază a punctelor de salvare System R. În sfîrşit
protocolul clasic a finisării bifazate este optimizat, pentru a memoriza numărul mesajelor
necesare.
Ca şi în System R, acordul stărilor BD, la execuţia paralelă a cărorva tranzacţii în System
R* se asigură de mecanismul cheltuielilor sincronizaţionale a obiectelor BD, la respectarea
protocolului bifazic a ocupărilor. Să reamintim că aceasta înseamnă împărţirea fiecărei
tranzacţii, din punct de vedere a sincronizării, în 2 faze: faza de lucru, în care ocupările doar se
stabilesc şi faza de finisare, cînd toate ocupările a obiectelor BD, create de tranzacţia dată, se
scot. Sincronizarea are loc imediat, ca şi în System R: fiecare tranzacţie–participant se adresează
către BD locală prin RSS a nodului său.

20.3. Sistemele integrate sau federale şi multibazele datelor


Direcţia sistemei integrate sau federative a BD neomogene şi multi BD au apărut în
legătură cu necesitatea complexării sistemelor BD, bazate pe diferite modele de date şi
gestionate de diferite SGBD.
Problema de bază a integrităţii BD neomogene este prezentarea a sistemului integrat a
schemei globale a BD, arătat în