Limbajul bazelor de date relaionale SQL

Limbajul bazelor de date relaionale SQL Lecia 13. Limbajul SQL. Funciile i posibilitile de baz. 13.1. SEQUEL/SQL SGBD System R Limbajul de interaciune cu BD SQL a aprut la mijlocul anilor 70 i a fost elaborat pe baza proiectului SGBD System R relaionale experimentale. Denumirea primar a limbajului SEQUEL(Structured English Query Language) reflect doar parial esena acestui limbaj. Desigur, n mod general, limbajul a fost orientat spre o formulare mai comod i mai neleas a adresrilor ctre BD relaionale, dar n realitate era de acum un un limbaj complet de BD, coninnd, n afar de operaiile formulrii adresrilor i manipulrilor BD, mijloace de manipulare i determinare cu schema BD: determinarea limitelor integritii i a trigherilor, afirii BD, posibilitile determinrii structurilor nivelului fizic, care determin executarea efectiv a adresrilor; autorizaiile accesului la relaii i la cmpurile lor; a punctelor de salvare a tranzaciilor. n limbaj lipseau mijloacele de sincronizare a accesului la obiectele BD din partea tranzaciilor efectuate paralel: de la bun nceput se presupunea c sincronizarea neaprateste executat de SGBD. S analizm posibilitile acestui limbaj un pic mai amnunit. 13.1.1. Adresrile i operatorii de manipulare cu datele Dup cte tim, dou limbaje de baz de adresare ctre BD relaionale sunt limbajul algebrei relaionale i a calculului relaional. Cu toat stricteea i statornicia sa teoretic aceste limbaje se utilizeaz rar n SGBD relaionale moderne, n calitate de mijloace a interfeei utilizatorului. Adresrile n aceste limbaje snt greu de formulat i de neles. SQL reprezint o combinaie oarecare a calculului relaional combinaional a cortejelor i a algebrei relaionale, n afar de aceasta nc nu este clar cror din cele clasice acest limbaj este mai apropiat. Cu toate acestea limbajul SQL are posibiliti mai largi, ca limbajele relaionale de baz, de exemplu, n caz general este imposibil translarea adresei, formulat n SQL, ntr-un cuvnt a algebrei relaionale, este nevoie de o oarecare lrgire. Proprietile de baz a sublimbajului de adresri SQL sunt posibiliti de a formula uor adresrile cu legtura ctorva relaii i subadreselor depuse n predicatele alegerii. Deci posedarea concomitent a ambelor mijloace este extensiv, dar acest fapt d posibilitatea utilizatorului, n timpul formulrii adresrii, de a alege varianta cea mai clar neleas. n predicatele cu subadresrile depuse n SQL System R este posibil de a utiliza teoretic o mulime de operatori de comparaie, ceea ce permite de a formula adresri cuantificate(ceea ce de obicei, cel mai greu este neles de utilizatori, de aceea n SQL au aprut predicate cuantificabile). O deosebire principal a limbajului SQL este posibilitatea prezenta n adresare necesitatea gruprii apartenenei-rezultatului pe cmpurile determinate, cu ajutorul condiiilor de selectare a ntregii grupe. Aa fel de condiii de selectare pot conine funcii de agregat, calculate pe grup. Aceast posibilitate a SQL n mod principal deosebete acest limbaj de limbajele algebrei relaionale i a calculului relaional, care nu conine surse analogice. O alt deosebire a limbajului SQL nu este tergerea neaprat a cortejelor-dublicate n relaii rezultatele finale sau intermediare. Altfel spus, rezultatul operatorului tergerii n limbajul SQL este mulimea cortejelor i nu a relaiilor. n cazurile cnd semantica adresrilor cere prezena relaiei, distrugerea predicatelor are loc neclar. Cel mai general tip de adresare n limbajul SQL este expresia algebric alctuit din adresri elementare. n SQL System R erau admise toate operaiile de baz(UNION, INTERSECT i MINUS). Lucrul cu expresiile nedeterminate n SQL System R nu a fost gndit pn la urm, cu toate c se presupunea utilizarea logicii cu trei simboluri, n cazul determinrii expresiilor logice. Operatorii de manipulare cu datele UPDATE i DELETE sunt construite pe baza acelorai principii ca i operatorul de selecie a datelor SELECT. Colectarea cortejurilor relaiei date, care

aparin modificrii sau tergerii, se determin cu ajutorul expresiei logice care face parte din operatorul dat i care poate conine predicate compuse i de asemenea cu subadresri depuse. n operatorul de includere a cortejurilor n relaia dat, cortejul ce se va include poate fi definit att n form literar, ct i cu ajutorul suboperatorului interior de selecie. 13.1.2. Operatori de manipulare i determinare a schemei BD Din componena operatorilor de determinare a schemei BD SQL System R fceau parte operatorii de creare i distrugere a relaiilor pstrate permanent i temporar(CREATE TABLE i DROP TABLE) i crearea i distrugerea relaiilor afiabile(CREATE VIEW i DROP VIEW). n limbaj i n realizarea System R nu se interzicea utilizarea operatorilor de utilizare a schemei n limitele tranzaciei, care conine operatorii de selecie i de manipulare cu datele. Se permitea, de exemplu, utilizarea operatorilor de selecie i de manipulare cu datele, n care se accentuieaz relaia neexistent n baza de date n timpul compilrii operatorului. Desigur, aceast posibilitate ngreuna considerabil realizarea i n fond i utilizarea foarte rar. Operatorul de manipulare cu schema BD ALTER TABLE avea posibilitatea de a aduga cmpurile selectate la relaie existent. n descierea limbajului se determina, c execuia acestui operator nu trebuie s aduc la faptul c compilarea operatorilor asupra relaiei s nu fie adevrat, relaie schema creia se schimb i c sensul cmpurilor din nou determinate n cortejele existente a relaiei devin nedeterminate. 13.1.3. Determinarea limitelor integritii i a trigherelor Limbajul SQL System R includea surse foarte puternice de control i meninere a integritii BD. Sursele de control se bazau pe aparatul de limite a integritii(ASSERTIONS). Dup ideie, limita integritii este expresia logic, determinat pe starea actual a BD, neadevrul creia corespunde cu starea neintegr a BD. Expresia logic a limitei integritii poate conine orice predicat admisibil n limbaj. Mai precis, limitele integritii se mpart n dou clase: controlabile n urma executrii operatorului de manipulare cu datele i controlabile la sfritul tranzaciei sau la executarea operatorului special INFORCE INTEGRITY. Tipurile predicatelor ce pot fi utilizate n n operatorii de determinare a limitelor integritii de clase diferite, difer. n operaiile din prima clas se controleaz cortejul actual, cu care are loc manipularea. n cazul doi se controleaz relaiile accentuate n limitele integritii, adic toate cortejele lor. Se deosebete i reacia determinat n limbaj, reacia sistemului la nclcarea limitelor integritii diferitor clase. n primul caz nclcarea limitelor integritii aduce la napoierea tranzaciei n punctul care e neaprat premrgtor operaiilor de manipulare cu datele, ndeplinirea cruia a dus la nclcarea limitei integritii. n cazul doi se efecuieaz napoierea tranzaciei pn la nceputul ei. Un mecanism important determinat n SQL System R este mecanismul trigherilor. n contextul System R acest mecanism era privit n mod principal ca surs de meninere automat a integritii BD. La determinarea trigherului se spunea de condiia de control a utilizrii trigherului(numele relaiei i tipul operaiei de manipulare cu datele). Condiia de utilizare a trigherului(expresia logic, construit construit dup regulile apropiate de regulilepentru limitele integritii primei clase) i funcia, cre trebuie s fie ndeplinit asupra bazei de date n caz c condiiile aplicaiei sunt adevrate. Aa funcie putea fi exprimat cu ajurtorul operatorului de sine stttor de manipulare cu date. n timpul execuiei funciei puteau s nceap i alte trighere, .a. Mecanismul de limitare a integritii i trigherelor n System R erau foarte puternice i comune, dar realizarea lor eera grea(dup cum s-a mai spus, trigherele aa i nu au mai fost realizate n System R). O greutate adugtoare n realizare a fost faptul c se permitea(n tot cazul nu se interzicea de ctre limbaj) determinarea limitelor integritii i a trigherilor n limitele aceleieai tranzacii, n care se ndeplinesc operatorii de manipulare cu datele. n cazul unei realizrim mai ample, ar fi fost nevoie de un numr mai mare de aciuni adugtoare n timpul execuiei tranzaciei. n afar de aceasta, n multe cazuri absena semanticii fixate a construciilor corespunztoare a limbajului, aduc la o nelegere sinonim a ndeplinirii tranzaciei.

13.1.4. Configuraiile bazelor de date n limbaj se permitea utilizarea relaiilor memorabile i a relaiilor dispuse a BD. Varianta cea mai bun era utilizarea operatorilor de selecie pentru determinarea cionfiguraiei sau afirii nfirii aparatului comun. Orice operator de selecie poate fi utilizat pentru determinarea configuraiei. n limbaj lipsesc oarecare limite n introducerea utilizrii configuraiilor: n orice operator SQL n care se permite utilizarea numelui relaiei memorabile, se permite i utilizarea numelui configuraiei a tabloului. n SQL System R nu se vorbete nimic despre metoda recomandabil de realizare a accesului ctre tablouri, dar n orice metod efectul trebuie s fie n aa mod, ca cnd sar fi realizat materializarea total a tabloului pn la execuia operatorului. Un ir de probleme, cercetri i propuneri a nscut posibilitatea potenial de execuie a operatorilor de manipulare cu datele asupra tablourilor. Este clar c aceast posibilitate este uor de realizat pentru tablourile simple, dar n cazurile mult mai complicate, nu numai realizarea, dar i semantica operaiilor devine netrivial. Apropo, n System R operatorii de manipulare cu datele, se admiteau numai asupra tablourilor simple. 13.1.5. Determinarea strucurilor de comand Introducerea n limbajul relaional, precum este SQL, operaiile de creare i tergere a nivelului fizic, care menin efecuarea efectiv a adresrilor ctre BD, a aprut n SQL System R ca o rezolvare pragmatic, care asigura posibilitatea tuturor tipurilor de lucru cu BD cu ajutorul unui singur limbaj. n SQL System R se vorbete despre dou tipuri de aa structuri: indexurile i legturile(links). Indexul, n nchipuirea lingvistic, abstract a sa este un fiier invertit, care asigur accesul ctre cortejurile relaiei corespunztoare, pe baza sensului dat de una sau mai multe coloane, care reprezint cheiea indexului. Operatorii limbajului permiteau de a crea i a distruge indexii, dar n nici un caz nu permiteau de a arta necesitatea utilizrii indexului existent n cazul execuiei operatorului de selecie, hotrrea despre aceasta se apela la realizare. Cu ajutorul operatorului de determinare a indexului era posibil de a exprima dou afirmaii adugtoare referitor la schema logic a relaiei i la structura fizic a pstrrii sale. La determinarea indexului, utilizarea cuvntului cheie UNIQUE nseamn c cheiea acestui index este cheiea posibil a relaiei corespunztoare. n fond aceasta demonstreaz existena mecanismului adugtor de determinare a limitelor integritii relaiei. Unul din indexii relaiei date putea fi determinat cu ajutorul cuvntului cheie CLUSTERING. Aceasta arat necesitatea clasterizrii fizice n memoria extern a cortejurilor relaiei cu sensuri apropiate sau egale cu cele ale indexului. Operatorii de determinare a legturii, permiteau, n stilul modelului de reea a datelor, organizarea n memoria extern a listelor cortejurilor relaiei date. Ca i n cazul indexilor, operatorii permiteau de a crea i de a distruge aa liste, dar nu includeau posibilitatea de a arta clar necesitatea utilizrii listelor externe la execuia operatorilor de manipulare cu datele i dificultatea efecturii calculelor preului utilizrii lor la execuia operatorului de selecie, au adus la aceea c mecanismul de legturi a disprut din limbaj, de acum n stadia trzie de ndeplinire a proiectului System R. De atunci, acest mecanism, dup cum tim, nu a aprut nici ntr-unul din variantele SQL. 13.1.6. Autorizarea accesului la relaie i cmpurile ei O deosebire de baz a limbajului SQL, care a aprut n el de la bun nceput este ndestularea proteciei accesului la date de ctre sursele limbajului. Ideiea principal a acestui pas const n faptul c, pentru atrnarea fa de orice relaie a BD i fa de orice coloan a relaiei se introduce un set definit de privilegii. Cu fiecare tranzacie se face indirect legtura cu identificatorul utilizatorului, de la numele cruiea ea se ndeplinete(metodele de legtur i de identificare a utilizatorilor nu se fixeaz n limbaj i se determin de realizare).

Dup crearea relaiei noi toate privilegiile legate de aceast relaie i de toate coloanele sale, aparin doar utilizatorului creator al acestei relaii. n componena privilegiilor intr i privilegia de a transmite toate sau o parte din privilegii altui utilizator, inclusiv i privelegia de a transmite privilegii. n mod tehnic transmiterea privilegiilor are loc la ndeplinirea operatorilor SQL GRANT. Exist i privilegia de a extrage o parte sau toate privilegiile de la un utilizator, caruiea acestea i-au fost transmise mai devreme. Aceast privilegie de asemenea poate fi transmis. n mod tehnic extragerea privilegiilor poate fi nfptuit la aplicarea operatorului SQL REVOKE. Controlul mputernicirii accesului la date are loc pe baza informaiei despre mputernicirile existente n timpul compilrii operatorului SQL corespunztor. Asemntor cu ceea ce am spus despre limitele integritii i trighere, n SQL System R lipseau careva limite n legtur cu utilizarea operatorilor GRANT i REVOKE. Acest fapt aducea la dificulti tehnice impuntoare n realizare, dar cte o dat i la o nelegere nesimilar a comportrii. Un timp ndelungat pasul spre protecia datelor de la accesele nesancionate era nfptuit practic fr critic, ns n legtur cu utilizarea rspndit a SGBD relaionale n adugrile netradiionale, tot mai des apare critica. Dac, de exemplu, n sistema BD trebuie s se menin o protecie a mai multor nivele de date, aa sistem de mputerniciri corespunztoare este foarte greu, dar cte o date e i imposibil de a construi pe baza surselor SQL. 13.1.7. Punctele de salvare, memorare i napoierea tranzaciilor n SQL System R au existat doi operatori speciali pentru implimentarea aa numitelor puncte de salvare, memorare a tranzaciilor i de napoiere a tranzaciilor spre punctul de salvare implimentat mai devreme. n literatura referitoare la System R cercetarea acestor posibiliti practic nu se gsete, de unde rezult c ele nu au fost realizate. Realizarea liniar a acestor posibiliti nu duce la careva dificultitehnice, dar i nu-i chiar de folos, deoarece dup execuia parial a napoierii tranzaciei pentru prelungirea cu succes a lucrului programului adugtor, ar fi fost nevoie i de restabilirea strii lui n punctul corespunztor, ceea ce nicidecum nu se menine. Este clar c, n cazul unei analize mai amnunite trebuie s fie legate mecanismele punctelor de salvare i control a integritii. De exemplu ar fi natural ca n timpul execuiei operatorului ENFORCE INTEGRITY, dac careva limite a integritii se ncalc, s-ar produce napoierea automat a tranzaciilor ctre punctul de salvare cel mai apropiat, n care nclcarea integritii BD nu s-a depistat. Acest fapt ar fi ngrelat realizarea, dar ar fi de folos. Analog s-ar fi putut de utilizat mecanismul punctelor de salvare n cazul napoierii automate a tranzaciilor din cauza apariiei impasurilor sincronizate. S accentum nc dou proprieti principale a limbajului SQL System R, care n modaliti diferite sunt prezente n toate variantele dezvoltate, postmergtoare ale limbajului. 13.1.8. SQL implantat n SQL System R sunt prezeni operatori speciali, care menin implantarea operaiilor SQL n limbajele tradiionale de programare(n System R un aa limbaj era PL/1). Problema fundamental de implementare a lui SQL n limbaj de programare const n faptul c SQL este un limbaj relaional, adic operatorii lui n cea mai mare parte lucreaz cu mulimile, n timp ce n limbajul de programare, operaiile scalare sunt de baz. Hotrrea lui SQL const n faptul c n limbaj se includ adugtor operatorii, care vor permite accesul pe corteje a rezultatului adresrii la BD. Pentru aceasta n limbaj se introduc sensul de cursor, cu care se leag operatorul de selecie. Asupra unui cursor dat se poate efectua operatorul OPEN, care indic materializarea relaiei rezultatul adresrii, operatorul FETCH, care permite alegerea sfritului de lucru cu cursorul dat.

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

Limbajul SQL n realizri comerciale n timpul actual SQL e realizat practic n toate SGBD relaionale comerciale, toate firmele i proclam corespunderea realizrilor sale la standartul SQL, i ntr-adevr dialectele realizate sunt apropiate. Aceasta a avut loc nu deodat i nu uor. Cele mai apropiate de System R erau dou sisteme ale firmei IBM SQL/DS i DB2. dup cum se pare(demonstrri documentale la aceasta autorul nu are) ambele aceste sisteme utilizau direct realizarea System R. De unde i apropierea limitat a dialectelor realizate SQL i SQL System R. Din SQL SystemR au fost excluse doar acele pri, care nu erau ndeajuns prelucrate( de exemplu punctele de salvare) sau reaalizarea crora ducea la dificulti foarte mari(de exemplu limitele integritii i trigherele). Putem numi aceast cale spre realizarea comercial a SQL micare de sus n jos. O alt apropiere se utiliza n aa sisteme ca Oracle i Informix. Nectnd la deosebirile n metodele de realizare a acestor sisteme, realizarea SQL avea loc de jos n sus. n primele realizri SQL ieite pe pia, n aceste sisteme se utilizeaz numrul minimal i foarte limitat a submulimilor SQL System R. n parte, n prima realizare cunoscut autorului a SQL SGBD Oracle n operatorii de selecie nu se admitea utilizarea subntrebrilor implimentate. Cu toate acestea, nectnd la aceste limite i la eficacitatea slab n primele stadii, orientarea firmelor la meninerea diferitor platforme de aparate i de cointeresarea utilizatorilor n trecerea la sistemele relaionale a permis firmelor s dobndeasc succes comercial spre perfecionarea realizrilor sale. n versiunile actuale Oracle i Informix se menin dialecte SQL destul de puternice, cu toate c realizarea cte o dat induce ndoieli. O deosebire a majoritii SGBD comerciale actuale, care ngreuneaz analiza dialectelor existente SQL, este aparena descrierii ntregi a limbajului. De obicei descrierea este mprtiat pe diferite manuale i este amesticat cu descrierea limbajelor surs, specifice pentru sistema dat, care nu au legtur cu SQL. Dar putem spune c, colecia de baz a operatorilor SQL, incluznd operatorii de determinare a schemei BD, de selecie i de manipulare cu datele autorizaiei

accesului la date, meninerea implantrii SQL n limbajele de programare i operatorii SQL dinamic, n realizrile comerciale s-a meninut i mai mult sau mai puin corespunde standartului. 13.3. 13.3. Standartizarea SQL

Standartizarea SQL Lucrrile pentru standartizarea limbajului SQL au nceput practic concomitent cu apariia primelor realizri comerciale ale lui. Primul din volumul de documente, ce aparineau autorului, dateaz cu luna octombrie a anului 1985 i este de acuma un alt proiect al standartului ANSI/ISO. Este clar c n calitate de standart se putea utiliza SQL System R. n primul rnd aceast variant a limbajului nu era prelucrat tehnic n momentul cuvenit. n al doilea rnd, aceasta ar fi fost foarte greu de realizat(cine tie cum s-ar fi aranjat istoria, dac ar fii fost realizate complet toate ideile System R). Din alt punct de vedere, primele realizri comerciale se deosebeau att de mult, c nici unul din dialectele realizate nu aveau anse de a fi primite n calitate de standart. Analiza documentelor accesibile arat, c procesul decurgea foarte dificil, utiliznd nu numai rezultatele tiinifice. n rezultat standartul Internaional SQL, primit n 1989 n marea majoritate a prilor sale, are un caracter comun i permite o descifrare forte larg. n acest standart lipsesc complet aa compartimente principale, ca manipularea cu schema BD i SQL dinamic. Multe din aspectele principale ale limbajului, n corelaie cu standartul se determin n realizare. Se preapoate, c cele mai importante scopuri atinse de limbajul SQL sunt standartizarea clar a sintaxei i semnaticii a operatorilor de selecie i mai includ posibilitile de determinare a cheilor primare i secundare a relaiilor i aa numitele limitele de control a integritii, care reprezint din sine submulimea limitelor integritii SQL System R de clasa nti. Sursele de determinare a cheilor exterioare permit formularea uoar a aanumitor necesiti a integritii BD dup legturi. Aceast necesitate rspndit poate fi formulat i pe baza mecanismului general a limitelor integritii SQL System R, dar formularea pe baza sensului cheii externe este mai simpl i mai neleas. Vznd necompletarea standartului SQL, pe fonul ncheierii lucrului aupra prelucrrii acestui standart, specialitii diferitor firme au pornit lucrul cu standartul SQL2. acest lucru de asemenea s-a prelungit civa ani, au fost elaborate o mulime de proiecte de standarte, pn cnd n sfrit, n martie 1992 nu a fost elaborat proiectul final a standartului. Acest standart este cu mult mai amplu i cuprinde practic toate aspectele necesare pentru realizare: manipularea cu schema BD, dirijarea cu tranzaciile(din nou au aprut punctele de salvare, memorare) i cu sesiile(sesia - este o succesiune a tranzaciilor, n limitele crora se pstreaz relaia temporal), conexiunea la BD, SQL dinamic. n sfrit sunt standartizate rfelaiile-registre a BD, ceea ce nu-i legat neaprat de limbaj, dar foarte mult acioneaz asupra realizrii. Uimete faptul lipsei n standart a surselor de dirijare cu indexii. Desigur aceste surse, de obicei, se afl departe de operaiile de baz SQL, dar autorului nu-i este cunoscut nici o realizare n care ei ar lipsi. n sfrit, odat cu finisarea lucrului saupra standartului SQL2 a luat natere prelucrarea standartului SQL3. se presupune c SQL3 va conine mecanismul trigherilor i posibilitatea utilizrii tipurilor abstracte de date. Sensul de standart se planific doar n anul 1995. s sperm c macr de aceast dat va fi posibil de urmrit prelucrarea lui. Concluzionnd aceast scurt excursie prin istoria standartizrii SQL, s observ, c n cele mai multe cazuri(nu n toate) procesul standartizrii se limiteaz la o prelucrare tehnic atent a ideilor SQL System R, ceea ce nc o dat accentuieaz unicitatea acestui proiect(au trecut 12 ani de la finisarea lui!). Lecia 14. Limbajul standart a bazelor de date SQL Lecia 14. Limbajul standart a bazelor de date SQL n aceast lecie vom analiza pe scurt proprietile de baz a limbajului Lecia 14. Limbajul standart a bazelor de date SQL 1989.

14.1. 14.1.

Tipuri de date

Tipuri de date n limbajul 14.1. Tipuri de date/89 se menin urmtoarele tipuri de date: CHARACTER, NUMERIC, DECIMAL, INTEGER, SMALLINT, FLOAT, DOUBLE, PRECISION. Aceste tipuri de date se clasific pe tipurile expresiilor simbolurilor, numerelor ntregi i numerelor reale. Primei clase i se atribuie CHARACTER(length), unde length returneaz lungimea cuvntului tipului dat. S atragem atenia, c n 14.1. Tipuri de date/89 lipsete tipul cuvintelor de mrime variabil. Cu toate c n multe realizri ele se admit. Cuvintele literare ale simbolurilor se reprezint n form de ir de simboluri(de exemplu exemple). Reprezentri ale clasei a doua de tipuri sunt NUMERIC, DECIMAL(DEC), INTEGER(INT) I SMALLINT. Specificatorul tipului NUMERIC are aspectul NUMERIC[(PRECISION[,SCALE])]. Se specific numerele ntregi, reprezentate cu precizia precision i cu scara scale. Aici i pe viitor, dac este scpat scara, atunci ea se poate socoti ca fiind egal cu 0, iar dac este scpat precizia. Atunci sensul ei se determin n realizare. Specificatorul tipului DECIMAL(sau DEC) are aspectul NUMERIC[(precision[,scale])]. Se specific numerele ntregi, reprezentate cu scara scale i precizia mai mare sau egal cu valoarea precision. Integer specific tipul de date a numerelor ntregi cu scara 0 i cu o precizie determinat de realizare. SMALLINT specific tipul de date a numerelor ntrgi cu scara 0 i cu precizia determinat n realizare, nu mai mare ca precizia numerelor tipului INTEGER. Sensurile literare a numerelor ntregi n caz general se prezint sub forma [+ ]<intreg_fara_semn>[.<intreg_fara_semn>]. n sfrit, la clasa tipurilor de date a numerelor reale se refer tipurile FLOAT, REAL, i DOUBLE PRECISION. Specificatorul tipului FLOAT are aspectul FLOAT[(precision)]. Sunt specifice numerele reale cu precizie binar mai mare sau egal cu valoarea precision. REAL specific tipul de date a numerelor reale i n caz general se reprezint sub forma <structura_literara_a_numarului>&<intreg_cu_semn>. S atragem atenia c cu toate c odat cu utilizarea limbajului SQL putem determina schema BD, care conine datele oricrui tip din cele numite, posibilitatea de a le utiliza n sistemele adugtoare depinde de limbajul de programare utilizat. Gama ntreag a tipurilor de date poate fi folosit dac se programeaz n PL/1. de aceea n unele realizri SQL tipurile de date cu scar i precizie n genere nu se menin. Cu toate c regulile de implimentare a SQL n limbajul C nu se determin n SQL/89, n majoritatea relizrilor, ce susin aa implimentare, are loc urmtoarea corelaie ntre tipurile de date SQL i tipurile de date C: CHARACTER corespunde caracterelor C; INTEGER corespunde long; SMALLINT corespunde short; REAL corespunde float, DOUBLE PRECISION corespunde lui double(anume aa corelaie este admis n SQL/92). S atenionm c, n marea majoritate a realizrilor SQL, se menin unele tipuri de date adugtoare, ca de exemplu, DATE, TIME, INTERVAL, MONEY. Unele din aceste tipuri se specific n standartul SQL/92, dar n realizrile actuale realizrile sintactice i semantice se pot deosebi. 14.2. 14.2. Surse de determinare a schemei

Surse de determinare a schemei Sursele de determinare a schemei BD n stanartul SQL/89 se refer la prile mai slabe ale standartului i care permit o interpretare diferit. Mai mult ca att, nu ne este cunoscut nici o realizare , n care s-ar menine fix aa set de surse de determinare a schemei. De aceea pentru obinerea mobilitatea sistemeiadugtoare n o clas destul de larg de realizare SQL/89, trebuie de localizat clar componentele de determinare a schemei BD. Cred c ar

fi mai bine de concentrat tot lucrul cu schema BD ntr-un singur modul i de avut n vedere c reconstruirea acestui modul. S atragem atenia, c n SQL/89 n genere lipsesc carevasurse de schimbare a schemei BD: nu-I posibilitatea de a nltura schema tabelului; de aduga n schema tabelului o coloan nou, .a. n toate realizrile aa surse se menin, dar ele pot s difere i dup sintactic i dup semantic. Nectnd la lipsa oricror sperane c vom reui s ntlnim o realizare, ce ar susine limbajul de determinare a schemelor SQL/89, noi, pe scurt, vom descrie acest limbaj(fr mijloace sintactice), pentru a aprecia la nivelul cuvenit posibilitile SQL/89 i de a primi mcar careva surse de comparaie a diferitor realizri. 14.2.1. Operatorul de determinare a schemei n legtur, corespunderii cu regulile SQL/89 fiecare tabel a BD date are un nume simplu i calificat. n calitate de calificator a numelui este identificatorul mputernicirilor tabelului, care de obicei, n realizare coincide cu numele a careva utilizator i numele calific a tabelului are forma: <identificatorul_imputrnicirilor>.<nume_simplu>. Paii ctre determinarea schemei n SQL/89 constau n faptul c toate tabelele cu unl i acelai identificator de mputernicire se creeaz(determin) pe calea ndeplinirii unui operator dedeterminare a schemei. Cu toate acestea, n standart nu se determin posibilitatea de ndeplinire a operatorului de determinare a schemei: trebuie oare el s fie ndeplinit numai n refim interactiv sau poate fi mplementat n program, scris n limbajul tradiional de programare. n operatorul de determinare a schemei, se conine identificatorul mputernicirilor i lista elementelor schemei, unde fiecare din elemente poate fi determinantul tabelului, determinantul afirii(view) sau determinantul privelegiilor. Fiecare din acetideterminani se reprezint de un operator aparte SQL/89, dar toi ei, cum s-a mai spus, trebuie s fie implementai n operatorul determinrii schemei. Pentru aceti operatori, vom scrie sintactica, cci aceasta va permite descrierea deosebirilor lor. 14.2.2. Determinarea tabelului Operatorul de determinare a tabelului are sintactica urmtoare: <table definition>::= CREATE TABLE<table_name>(<table_element>) [{,<table_element>}] <table_element>::= <column_definition> |<table_constraint_definition>. n afar de numele tabelului, n operator se specific lista elementelor tabelului, unde fiecare din elemente slujete sau pentru determinarea coloanei, sau pentru determinarea limitelor integritii a tabelului determinat. Este nevoie de prezentat macr a unei determinri a coloanei. Operatorul CREATE TABLE determin, aa numitul tabel de baz, adic depozitul real de date. Pentru determinarea coloanelor tabelului i a limitelor integritii se utilizeaz operatori speciali, care trebuie inclui n operatorul de determinare a tabelului. 14.2.3. Determinarea coloanei Operatorul de determinare a coloanei se descrie prin regula sintactic urmtoare: <column definition>::= <column name><date type> [<default clause>][<column constraint>] <default clause>::= DEFAULT {<literal>|USER|NULL} <column constraint>::=

NOT NULL[<unique specification>] |<references specification> |CHECK (<search condition.>). Dup cum se vede, n afar de partea principal, n care se determin numele coloanei i tipul ei de date, determinarea coloanei poate conine i dou disprituri secundare, de care ne putem lipsi: dispritura coloanei propriuzis i despritura limitelor integritii coloanelor. n despritura nsemntii propriuzis se arat nsemntatea, care trebuie s fie inclus n rndul, care se nscrie n tabelul dat, dac nseamntate acestei coloane nu se d. nsemntatea propriuzis poate fi dat sub form de constant literar cu tipul, care corespunde tipului coloanei date; pe calea definirii cuvntului cheie USER, cruiea, n timpul execuiei operatorului de introducere a cuvntului, i corespunde cuvntul simbolic, ce conine numele utilizatorului curent(n acest caz coloana trebuie s aib tipul cuvintelor simbolice); sau pe calea definirii cuvntului cheie NULL, care indic c nsemntatea propriuzis este o nsemntate nedeterminat. Dac nsemntatea coloanei propriuzis nu-i specificat, i n despritura limitelor integritii coloanei este artat NOT NULL, atunci nceracrea de a introduce n tabel cuvntul cu nsemntatea nespecificat a coloanei date va duce la greeal. Definirea n despritura de limitare a integritii NOT NULL duce la crearea unei limite a integritii de ncercare pentru tot tabelul(uite subdiviziunea urmtoare) CHECK (C IS NOT NULL) (unde C numele coloanei date). Dac limita NOT NULL nu-i dat, i despritura propriuzislipsete, atunci are loc crearea despriturii propriuzise DEFAULT NULL. Dac este dat specificarea unicalitii, atunci are loc crearea specificaiei corespunztoare a unicalitii pentru tabel. Dac n despritura limitelor integritii este dat limita dup legtur a coloanei date (<reference specification>), atunci are loc crearea determinrii limitelor integritii corespunztoare dup legturi pentru tabel: FOREIGN KEY(C) <reference specification> n sfrit, dac este dat limita de control a coloanei, atunci condiiile de cutare a acestei limite trebuie s se bazeze doar pe aceast coloan, i de asemenea are loc crearea corespunztoare a limitei de control a integritii tabelului. 14.2.4. Determinarea limitelor integritii tabelului Limitele integritii tabelului posed sintactica urmtoare: <table constraint definition>::= |<unique constraint definition> |<referential constraint definition> |<check constraint definition> <unique constraint definition>::= <unique specification>(<unique column list>) <unique specification>::=UNIQUE | PRIMARY KEY <unique column list>::=<column name>[{, <column name>}] <referential constraint definition>::= FOREIGN KEY(<referencing column >)<references specification> <references specification>::= REFERENCES<referenced table in column> <referencing columns>::= <reference column list> <referenced table in columns>::= <table name>[(<reference column list>}] <reference column list>::=<column name>[{,<column name>}] <check constraint definition>::=CHECK(<search condition>) Pentru un singur tabel pot fi date cteva limite a integritii, inclusiv i cele ce se creeaz de ctre limitele integritii coloanelor.

Standartul SQL/89 adopt, c limitele tabelului practic se controleaz la ndeplinirea fiecrui operator SQL. Atenie: posedarea setului corect selectat de limite a BD este foarte important pentru funcionarea temeinic a sistemului informaional aplicat. Cu toate acestea n unele SGBD limitele integritii practic nu se menin. De aceea la proiectarea sistemului aplicativ trebuie de luat decizia ce este mai principal: s ne bazm pe susinerea limitelor integritii, dar s ne limitm setul posibilelor SGBD, sau s ne dezicem de utilizarea lor la nivelul SQL, pstrnd posibilitatea utilizrii nu a celor mai noi SGBD. n continuare T arat tabelul, pentru care se determin limitele integritii. Limita unicitii Fiecare nume a coloanei, din lista unicitilor trebuie s numeasc coloana T i nu trebuie s fie inclus n aceast list mai mult de o singur dat. La determinarea coloanei, ce intr n lista unicalitilor trebuie s fie dat pe limita coloanei NO NULL. Printre limitele unicalitii T nu trebuie s fie mai mult de o singur determinare a cheii primare(limita unicalitii cuvntului cheie PRIMARY KEY). Lucrul limitei unicalitii const n faptul c, n tabelul T nu se admite apariia a dou sau mai multe rnduri, sensurile coloanelor unicalitii crora coincid. Limita dup legtur Limita dup legtur de la setul de coloane date CT a tabelului T pe setul de coloane CT1 dat de un tabel oarecare la momentul dat T1 determin condiia asupra coninutului ambelor acestor tabele, fr de care legturile le putem considera corecte. Dac lista coloanelor CT1 este specificat clar n determinarea limitei dup legturi, atunci trebuie ca aceast list s intre ntr-o oarecare determinare a unicalitii tabelului T1. dac lista CT1 nu se specific n determinarea limitei dup legturi a tabelului T, atunci este nevoie ca n determinarea tabelului T1 s fie prezent determinarea cheii primare i lista CT1 se presupune c coincide cu lista numelor coloanelor din determinarea cheii primare a tablului T1. Numele coloanelor listelor CT i CT1 trebuie s fie luate de coloanele tabelelor T i T1 corespunztor i nu trebuie s apar n liste mai mult de o singur dat. Listele coloanelor CT i CT1 trebuie s conin un numr egal de elemente i coloana tabelului T, identificat de elementul i a listei CT trebuie s fie de acelai tip ca i coloana tabelului T1, identificat de elementul i a listei CT1. Dup determinare, tabelele T i T1 corespund limitei date dup legturi, dac pentru fiecare rnd S a tabelului T aa c toate nsemntile coloanelor S identificate de lista CT, nu sunt nedeterminate, exist rndul S1 a tabelului T1, aa c, nsemntatea coloanelor S1, identificate de lista CT1, sunt egale dup poziia nsemntilor coloanelor S, identificate de lista CT. Mai clar acest lucru poate fi formulat n felul urmtor: limita dup legturi se satisface dac pentru fiecare legtur corect exist un obiect, la care ea s-ar trimite. n terminologia deprins de programatori, limita dup legturi nu permite crearea legturilor atrnate, care nu conduc nspre nici un obiect. Limita de control Limita de control specific condiia, care trebuie s fie satisfcut de fiecare rnd n parte a tabelului T. Aceast condiie nu trebuie s conin subadresri, specificaii a funciilor agregate dar i a legturilor spre parametrii sau variabile externe. n ea pot intra doar numele coloanelor tabelului dat i constantele literare. Tabelul satisface limita de control a integritii n acel caz i numai n acela, cnd calculul condiiei pentru nfiecare rnd a tabelului ne d TRUE. Atenie: n unele realizri se permite mecanisme mai lrgite a limitelor dup legturi i a limitelor de control. Trebuie s fim ateni, dac nu dorim s ieim din limitele posibilitilor standartului. 14.2.5. Determinarea configuraiilor Mecanismul configuraiilor(view) este o surs puternic a limbajului SQL, ce permite ascunderea structurii real a BD de careva utilizatori, pe baza determinrii configuraiei BD, care

este o oarecare adresare ctre BD memorabil cu coloane enumrate, dar pentru utilizator nu se deosebete cu nimic de tabelul de baz a BD(innd seama de limitele tehnice). Orice realizare trebuie s garnteze, c starea tabelului dat coincide ntocmai cu starea tabelelor de baz, pe baza crora este determinat configuraia. De obicei determinarea tabelului nchipuit (materializarea adresrii corespunztoare) are loc de fiecare dat la utilizarea configuraiei. n standartul SQL/89 operatorul de determinare a configuraiei are sintaxa: <view definition>::= CREATE VIEW <table name>[(<view column list>)] AS <query specification>[WITH CHECK OPTION] <view column list>::=<column name>[{,<column name>}...] Tebelul V determinabil este schimbtor(adic n corespundere cu V putem utiliza operatorii DELETE i UPDATE) n acel caz i doar n acela, dac se ndeplinesc urmtoarele condiii pentru specificarea adresrii: n lista de selecie nu se indic cuvntul cheie DISTINCT; fiecare expresie afirmativ n lista de selecie este o specificaie a coloanei i specificaia unei coloane nu apare mai mult de o singur dat; n despritura FROM este artat doar un singur tabel care este sau tabel de baz sau tabelul nchipuit schimbtor; n condiia de selecie a despriturii WHERE nu se utilizeaz subadresri; n expresia tabelar lipsesc despriturile GROUP BY SO HAVING. Atenie: Aceste limite sunt foarte puternice. n realizri ele pot fi slbite. Dar dac s aspirm la mobilitate, n-ar fi de dorit s utilizai posibilitile lrgite. Dac n lista de selecie n specificarea adresrii este mcar o singur expresie afirmativ, compus nu dintr-o singur specificaie a coloanei, sau dac un nume a coloanei face parte din lista de selecie mai mult dect o singur dat, determinarea configuraiei trebuie s conin lista numelor coloanelor tabelului nchipuit. Mai simplu trebuie de enumerat coloanele tabelului nchipuit, dac aceste nume nu sunt motenite de la coloanele tabelelor despriturii FROM de specificare a adresrii. Cererea WITH CECK OPTION n determinarea configuraiei are sens numai n cazul determinrii tabelului nchipuit schimbtor, care se determin de specificarea adresrii, care conine despritura WHERE. n cazul posedrii acestei cereri nu se admit schimbri a tabelului nchipuit ce duc la apariia n tabelele de baz a rndurilor, ce nu se vd n tabelul nchipuit, adic aa rnduri, care nu ndestuleaz condiia de cutare a despriturii WHERE de specificare a adresrii. Dac WITH CECK OPTION n determinarea configuraiei lipsete, aa control nu se nfptuiete. 14.2.6. Determinarea privelegiilor n coresponden cu ideologia limbajului SQL controlul drepturilor de acces a utilizatorului dat ctre tabele BD are loc pe baza mecanismului de privelegii. De fapt, acest mecanism const din aceea, c pentru ndeplinirea oricrui lucru asupra tabelului utilizatorul trebuie s posede privelegiile corespunztoare(real tot lucrul posibil este descris de setul fixat standart de privelegii). Utilizatorul, ce a creat tabelul, automat devine posesorul a tuturor privilegiilor posibile la ndeplinirea operaiilor asupra acestui tabel. n componena acestor privelegii intr i privelegiul de transmitere a tuturor sau a crorva privilegii n legtur cu tabelul dat ctre ali utilizatori, inclusiv privelegiul de transmitere a privelegiilor. Uneori are loc i apariia inversei de luare a privelegiilor de la utilizator, care le-a primit mai nainte. n SQL/89 se determin schema simplificat a mecanismului privilegiilor. n primul rnd, mprirea privelegiilor este posibil doar n cazul dewterminrii tabelului. n al doilea rnd, utilizatorul, ce a primit careva privilegii de la ali utilizatori, le poate transmite mai departe doar n cazul determinrii schemei. Determinarea privilegiilor are loc dup sintactica urmtoare: <privilege definition>::= GRANT <priveleges> ON <table name> TO <grantees> [{,<grantee>}][WITH GRANT OPTION]

<priveleges>::= ALL PRIVELEGES |<action>[{,<action>}] <action>::=SELECT|INSERT|DELETE |UPDATE [(<grant column list>)] |REFERENCES [(<grant column list>)] <grant column list>::=<column name>[{,<column name>}] <grantee>::=PUBLIC|<autorization identifier> Din aceast sintax nelegem sensul mecanismului de determinare a privelegiilor n SQL/89. s atragem atenia doar la aceea c avem nevoie de posesia privelegiilor. PREFERENCES n legtur cu coloanele selectate din tabelul T1 pentru a avea posibilitatea, la determinarea tabelului T, s determinm limita dup legturi dintre acest tabel i tabelul existent la momentul dat T1. Cu toate c n caz general n toate SQL-SGBD orientate se menine mecanismul de protecie a accesului pe baza privelegiilor, realizrile se pot de obicei deosebi prin detalii. Pentru a tinde spre crearea unui sistem mobil adugtor aplicativ, atunci acest lucru analizat mai sus trebuie localizat. Lecia 15. Limbajul SQL. Surse de manipulare cu datele Lecia 15. Limbajul SQL. Surse de manipulare cu datele 15.1. Structura adresrilor Pentru a vorbi mai mult sau mai puin despre structura adresrilor n standartul Lecia 15. Limbajul SQL. Surse de manipulare cu datele/89 trebuie s ncepem cu o mulime de reguli sintactice: <cursor specifiction>::= <query expresion>[<order by clause>] <query expresion>::=<query term> |<query expresion> UNION [ALL]<query term> <query term>::=<query specification> |(<query expression>) <query specification>::= (SELECT [ALL|DISTINCT]<select list><table expresion>) <select statement>::= SELECDT [ALL|DISTINCT]<select list> INTO <select target list> <table expresion> <subquery>::= (SELECT [ALL|DISTINCT]<result specification> <table expression> <table expression>::= <from clause> [<where clause>] [<group by clause>] [<hawing clause>] Limbajul permite trei tipuri de construcii sintactice, care ncep cu cuvntul cheie SELECT: specificaia cursorului(cursor specification), operatorul seleciei(select statement) i subadresarea (sub query). Cea mai de baz este construcia sintactic expresie tabelar(table expreion). Semantica expresiei tabelare const n faptul c pe baza utilizrii consecutive a dispriturilor from, where, group, by so hawing, din tabelele date n from se construiete o tabel rezultant, n care ordinea consecutivitii rndurilor nu este determinat i printre rnduri se pot gsi dublicate(adic, n caz general, tabelul-rezultant al expresiei tabelare este o mulime de rnduri). ntr-adevr anume structura expresiei tabelare n cea mai mare parte caracterizeaz limbajul

SQL/89. n continuare vom vedea structura i sensul dispriturilor expresiei tabelarte, dar mai nainte vom analiza cele trei tipuri de construcii ce include expresiile tabelare. 15.1.1. Specificarea cursorului Cursor o determinare a limbajului SQL, ce permite cu ajutorul setului de operatori speciali de a primi accesul pe rnduri la rezultatul adresrii ctre BD. Ctre expresiile tabelare, ce particip la specificarea cursorului, nu se aplic nici o limit. Dup cum se vede din mulimea de reguli sintactice, la determinarea specificaiei cursorului se utilizeaz trei construcii adugtoare: specificarea adresrii, expresia adresrilor i despritura ORDER BY. Specificarea adresrii n specificarea adresrii se d lista de selecie(lista expresiilor afirmative asupra sensurilor coloanelor rezultatului expresiei tabelare i a constantelor). n rezultatul utilizrii listei de selecie la rezultatul expresiei tabelare are loc construirea noului tabel, se conine acelai numr de rnduri, dar n general alt numr de coloane, ce conin rezultatele calculelor expresiilor afirmative corespunztoare din lista de selecie. n afar de aceasta, n specificarea adresprii se pot conine cuvinte cheie ca: ALL sau DISTINCT. La posesia cuvntului cheie DISTINCT din tabel, a expresiei tabelare primite utiliznd n rezultat lista de selecie, se terg rndurile dublicate; la selectarea ALL (sau pur i simplu la lipsa lui DISTINCT) nu are loc tergerea rndurilor dublicate. Expresia adresrilor Expresia adresrilor este o expresie care se construiete dup regulile sintactice date pe baza specificaiei adresrilor. Unica operaie care e permis de a fi utilizat n expresiile adresrilor, este operaia UNION(unirea tabelelor) cu posibilitatea de felul urmtor UNION ALL. Ctre tabelele-operanilor expresiilor adresrilor se aplic acea cerin, c toate ele trebuie s posede unul i acelai numr de coloane i coloanele corespunztoare a tuturor operatorilor trebuie s fie de unul i acelai tip. Expresia adresrilor se calculeaz de la stnga spre dreapta, innd seama de ghilimele. La execuia operaiei UNION are loc unirea obinuit a operatorilor, adic n tabelul rezultant se terg dublicatele. La neplinirea operaiei UNION ALL se formeaz tabelul rezultant, n care se pot conine rnduri dublicate. Dispritura ORDER BY n sfrit despritura ORDER BY permite crearea ordinii dorite de privire a rezulltatului expresiei adresrilor. Sintactica ORDER BY este: <order by clause>::= ORDER BY <sort specifiction [{,<sort specification>}] <sort specification>::= {unsigned integer>|<volum specification>} [ASC|DESC] Dup cum vedem din aceste reguli sintactice, practic se d lista coloanelor rezultatului expresiei adresrilor i pentru fiecare coloan se arat ordinea rndurilor rezultatului n dependen de nsemntatea acestei coloane(ASC dup cretere i DESC n descretere). Coloanele pot fi date prin numele sale n cazul cnd: expresia adresrilor nu conine operaiile UNION i UNION ALL; n lista de selecie a specificaiei adresrii acestei coloane i corespunde o expresie afirmativ, compus doar din numele coloanei. n toate celelalte cazuri, n despritura ORDER BY trebuie s fie dat numrul de ordine a coloanei n tabelul rezultant al expresiei adresrii. 15.1.2. Operatorul de selecie Operatorul de selecie este un operator aparte a limbajului SQL/89, ce permite de a primi rezultatul adresrii n programul aplicat fr activarea cursorului. De aceea operatorul de selecie are sintactica ce difer de sintactica de specificare a cursorului i la execuia lui apar limitri a rezultatului expresiei tabelare. De fapt i una i alta este dictat de specificul operatorului de selecie ca operator unar a SQL: la execuia lui rezultatul strebuie s fie inclus n variabilele programului aplicativ. De aceea n operator apare dispritura IN TO, ce conine lista variabilelor

a programului aplicativ i apare acea limit c tabelul rzultant trebuie s conin nu mai mult de un rnd. La rndul su rezultatul expresiei tabelare de baz trebuie s conin nu mai mult de un rnd, dac operatorul de selecie nu conine specificaia DISTINCT i tabelul, primit n urma apelrii la lista de selecie ctre rezultatul expresiei tabelare, nu trebuie s conin mai mult de un rnd care nu coincide, dac specificaia DISTINCT este dat. Atenie: n dialectul SQL SGBD Oracle se menine varianta lrgit a operatorului seleciei, rezultatul cruiea nu e neaprat tabelul dintr-un singur rnd. Aa lrgire nu se susine nici n SQL/89, nici n SQL/92. 15.1.3. Subadresarea n sfrit, ultima construcie SQL/89, care poate conine expresii tabelare este subadresarea, pedic adresarea, care poate fi inclus n predicatul condiiei de seleciei a operatorului SQL. Tabelul rezultant trebuie s conin fix o singur coloan. De aceea n regulile de sintax, ce determin subadresarea, n loc de lista de selecie este artat expresia expresia, ce determin valoarea, adic expresia afirmativ. S atenionm, c deoarece subordonarea ntotdeauna este inclus n orice alt operator SQL, atunci n calitate de constante n expresia afirmativ de selecie i n expresia logic a despriturilor WHERE i HAVING. Se permite utilizarea coloanelor a rndurilor cresctoare a tabelelor, ce particip n adresrile mai mari ca nivelul exterior. Mai amnunit despre aceasta vom vorbi la descrierea semnaticii expresiilor tabelar. 15.2. 15.2. Expresia tabelar

Expresia tabelar Standartul SQL/89 recomand s primim calculul expresiei tabelareca o utilizare consecutiv a despriturilor FROM, WHERE, GROUP i HAVING pentru tabelele date n lista FROM. Despritura FROM are sintaxa urmtoare: <from clause>::= FROM <table reference> ({,<table reference>}) <table reference>::= <table name>[<collection name>] 15.2.1. Despritura FROM Ca rezultat a ndeplinirii despriturii FROM este derivarea extins a tebelelor, date de lista tabelelor despririi FROM. Derivarea extins este de aceea c, n calitate de rezultat i operani se admit mulimile. n standart se determin n felul urmtor: derivarea extins este R, unde R este o multimulime a tuturor rndurilor r aa, c r este concatenarea tuturor rndurilor dint toate tabelele identificate n aa ordine, n care ele au fost identificateordinul lui R este reprezint derivata ordinelor tabelelor identificate. Numrul de ordine a coloanei n R este n+S, unde n este numrul coloanei create n tabelul numerat T, iar S este suma puterulor tuturor tabelelor, alturi de numele tabelului putem specifica nc un nume corelation name. De fapt aceasta este un sinonim a numelui tabelului care poate fi folosit n alte desprituri a expresiei tabelare pentru legturile cu rndurile anume a acestei intrri a tabelului. Dac expresia tabelar conine doar despritura FROM(aceasta-i unica i neaprata despritur a tabelului), atunci rezultatul expresiei tabelare coincide cu rezultatul despriturii FROM. 15.2.2. Depritura WHERE Dac n expresia tabelareste prezent despritura WHERE, atunci urmtoarea se va calcula anume ea. Sintaxa acestei desprituri este: <where clause>::=WHERE <search condition>

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

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

Predicatul null Acest predicat se descrie de sintaxa dat: <null predicate>::= <column specification> IS [NOT] NULL Acest predicat n totdeauna are rezultatul true sau false. Cu toate acestea rezultatul x IS NULL este egal cu true atunci i numai atunci cnd valoarea lui x nu-i determinat. Rezultatul predicatului x NOT IS NULL este egal cu rezultatul NOT x IS NULL Predicatul de cuantificare Acest predicat are sintaxa urmtoare: <quantified predicate>::= <value expresion><comp op><cuantifier><subquery> <quantifier>::= <all>|<some> <all>::=ALL <some>::=SOME|ANY Vom nota cu x rezultatul calculului expresiei afirmative prii stngi a predicatului, iar cu S rezultatul calculului subadresrii. Predicatul x<comp op> ALL S are valoarea true, dac S este pustie sau valoarea predicatului x<comp op> S e egal cu true pentru fiecare S, care se include n S. predicatul x<comp op> ALL S are valoarea false, dac valoarea predicatului x<comp op> S este egal cu false macr pentru un S care se include n S. n celelalte cazuri valoarea predicatului x<comp op> ALL S este egal cu unicown. Predicatul x<comp op> SOME S are valoarea false, dac S este nul sau valoarea predicatului x<comp op> S este egal cu false pentru fiecare s din S. Predicatul x<comp op> SOME S are valoarea true, dac valoarea predicatului x<comp op> S este egal cu true macr pentru un s din S. n celelalte cazuri valoarea predicatului x<comp op> SOME S este unikown. Predicatul exists Predicatul exists are sintaxa urmtoare: <exists predicate>::= EXISTS <subquery> Valoarea acestui predicat n totdeauna este true sau false, i aceast valoare este true atunci i numai atunci, cnd rezultatul calculului subadresrii nu-i nul. 15.2.3. Despritura GROUP BY Dac n expresia tabelar este prezent despritura GROUP BY, atunci ea se va executa urmtoarea. Sintaxa ei este urmtoarea: <group by clause>::= GROUP BY <column specification> [{,<column specification>}] Dac vom nota cu R tabelul, care are rezultatul despriturii precedente(FROM sau WHERE) atunci n calitate de rezultat a despriturii GROUP BY este desprirea lu R ntr-o mulime de rnduri, care-i alctuit din numrul minim a aa grupe, c pentru fiecare coloan din lista coloanelo despriturii GROUP BY n toate rndurile fiecrei grupe, ce include mai mult de un rnd, valorile acestei coloane sunt egale. Pentru determinarea rezultatului despriturii GROUP BY n standart se utilizeaz termenul tablou grupat. 15.2.4. Despritura HAVING Ultima la calculul expresiei tabelare se utilizeaz despritura HAVING(dac ea e prezent). Sintaxa ei este: <having clause>::= HAVING <search condition>

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

15.3. Funciile de agregat i rezultatele adresrilor Funciile de agregat(n standartul SQL/89 ele se numesc funcii asupra mulimilor) se determin n SQL/89 de urmtoarele reguli sintactice: <set function specification>::= COUNT (*)|<distinct set function> |<all set function> <distinct set function>::= {AVG|MAX|MIN|SUM|COUNT} (DISTINCT<column specification>) <all set function>::= {AVG|MAX|MIN|SUM}([ALL] <value expresion>) Dup cum vedem n aceste reguli, n standartul SQL/89 sunt determinate 5 funcii standarte de agregat: COUNT numrul rndurilor sau a valorilor; MAX valoarea maxim; MIN valoarea minim; SUM valoarea sumei i AVG valoarea medie. 15.3.1. Semantica funciilor de agregat Funciile de agregat sunt destinate pentru a calcula o valoare oarecare pentru mulimea de rnduri dat. Aa mulime de rnduri poate fi grupa de rnduri, dac funcia de agregat se utilizeaz pentru tabelul grupat, sau tabelul ntreg. Pentru toate funciile agregat, n afar de COUNT(*), ordinea(cerut de semnatic) calculrii este: pe baza parametrilor funciei de agregat din mulimea de rnduri dat se creeaz lista valorilor. Apoi pe baza acestei liste de valori are loc calculul funciei. Dac lista este nul, atunci valoarea funciei COUNT pentru ea este zero, iar valoarea celeilalte funcii null. Fie T tipul valorilr din aceast list. Atunci rezultatul calculului funciei COUNT este un numr ntreg cu scara i precizia determinate n realizare. Tipul rezultatului valorilor funciilor

MIN i MAX coincid cu T. La calculul funciei SUM i AVG tipul T nu trebuie s fie de tipul rndurilor simbolice, iar tipul rezultatului funciei este de tip de numere ntregi cu scara i precizia determinabile n realizare, dac T tip de numere ntregi i tip de numere reale cu precizia determinat n realizare, dac T tip de numere aproximative. Calculul funciei COUNT(*) are loc pe calea enumrrii numrului de rnduri n mulimea dat. Toate rndurile se consider diferite, chiar dac ele snt compuse dintr-o singur coloan cu valoarea null n toate rndurile. Dac funcia de agregat este specificat fr cuvntul cheie DISTINCT, atunci lista valorilor se construiete din valorile coloanei selectate(s subliniem c n acest caz nu se permite calculul expresiilor afirmative). Apoi din aceast list se exclud valorile nedeterminate i se nltur valorile dublicate. Apoi se calculeaz funcia dat. Dac funcia de agregat este specificat fr cuvntul cheie DISTINCT(sau cu cuvntul cheie ALL), atunci lista de valori se formeaz din valorile expresiei afirmative, ce se calculeaz pentru fiecare rnd al expresiei date. Apoi din list se nltur valorile nedeterminate i se calculeaz funcia de agregat. Atragei atenia c n acest caz nu se permite utilizarea funciei COUNT. Atenie: Ambele limite, artate n abzaele anterioare, sunt mai mult tehnice dect principiale i pot s lipseasc n realizri concrete. Cu toate acestea ele sunt limite ale standartului SQL/89 i trebuie s inem cont de ele la programarea mobil. 15.3.2. Rezultatele adresrilor Funciile de agregat pot fi utilizate n specificarea cursorului, a operatorului de selecie i n subadresare dup cuvntul cheie SELECT(n aceast subdespritur vom numi aa construcii ca list de selecie, i s nu uitm c n caz de subadresare aceast list e format doar dintr-un element) i n condiia despriturii HAVING. Standartul permite utilizarea mult mai exotic a funciilor de agregat n subadresri( funcia de agregate pe grupe de corteje a adresrii exterioare), dar n practic se ntlnesc foarte rar. S cercetm diferite cazuri de utilizare a funciilor de agregat n lista de selecie n dependen de tipul expresiei tabelare. Dac rezultatul expresiei tabelare R nu este un tabel grupat, atunci apariia macr a unei funcii de agregat din mulimea de rnduri R n lista de selecie duce la ceea, c R este privit ca un tabel grupat, care-i alctuit dintr-o(sau nici una) grup ce nu are coloane de grupare. De aceea, n acest caz, n lista de selecie nu se permite utilizarea direct a specificaiilor rndurilor R: toate ele trebuie s se gseasc n interiorul specificaiilor funciilor de agregat. Ca rezultat a adresrii e tabelul, cu nu mai mult de un rnd, primit pe calea utilizrii funciilor de agregat R. La fel stau lucrurile i n cazul, cnd R este un tabel grupat, dar expresia tabelar nu conine despritura GROUP BY( i deci conine despritura HAVING). Dac n cazul abzaului anterior erau dou variante de creare a listei de selecie: numai cu indicarea direct a coloanelor R sau numai cu indicarea lor n interiorul specificaiilor a funciilor de agregat), atunci n cazul dat este posibil numai a doua variant. Rezultatul expresiei tabelare este afiat de ctre tabelul grupat, format dintr-o singur grup i rezultatul adresrii poate fi format doar pe calea aplicrii funiilor de agregat pentru acest grup de rnduri. Din nou ca rezultat a adresrii avem un tabel, ce conine nu mai mult de un rnd, primit pe calea aplicrii funciilor de agregat pentru R. Cazul cnd R este un tabel adevrat grupat, adic expresia tabelar conine despritura GROUP BY i rezult c este determinat cel puin o coloande grupare. n acest caz regulile de formare a listei de selecie coincid cu regulile de formare a condiiei de selecie a despriturii HAVING: permite utilizarea direct a specificaiei coloanei de grupare, dar specificaiile celorlalte coloane R, pot s apar doar n interiorul specificaiilor funciilor de agregat. Ca rezultat a adresrii este tabelul, n care numrul de rnduri este egal cu numrul de grupuri n R, i fiecare rnd se formeaz pe baza valorilor coloanelor de grupare i a funciilor de agregat pentru grupa dat. Lecia 16. Utilizarea SQL la programarea aplicat

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

Limbajul modulelor Structura modulului SQL urmtoare: <module>::= <module name clause> <language clause>

<module autorization clause> [<declare cursor>] <procedure> <module name clause>::=MODULE [<module name>] <language clause>::=LANGUAGE{COBOL|FORTRAN|PASCAL|PLI} <module autorization clause>::= AUTORIZATION<module autorization identifier> <module autorization identifier>::=<autoriyation identifier> Este important c fiecare modul SQL e orientat spre utilizare n programele scrise ntr-un limbaj concret de programare. Dac n modul sunt prezentate procedurile de lucru cu cursoarele, atunci toate cursoarele trebuie s fie specificate la nceputul modulului. S accentum c declararea cursorului nu se ncarc ntr-o careva procedur, deoarece acesta este un operator SQL de descriere i nu de ndeplinire. 16.2.1. Determinarea procedurii Procedurile n modulul SQL se determin dup construciile sintactice date: <procedure>::= PROCEDURE<procedure name> <parameter declaration>; <SQL statement>; <parameter declaration>::= <parameter name><data type> |<SQL CODE parameter> <SQL CODE parameter>::= SQLCODE <SQL statement>::= <close statement> |<comit statement> |<delete statement positioned> |<delete statement searched> |<fetch statement> |<insert statement> |<open statement> |<rollback statement> |<select statement> |<update statement positioned> |<update statement searched>. Numele fiecror proceduri ntr-un mediu trebuie s fie diferite. Orice nume a parametrului, care se conine n parametrul SQL a procedurii, trebuie s fie specificat n compartimentul de declarare a parametrilor formali, artai la declararea ei. Lista parametrilor formali a fiecrei proceduri, trebuie s conin fix un parametru SQLCODE(codul de rspuns al procedurii). 16.3. SQL implementat Deoaece n standartul SQL/89 nu sunt specificate regulile de implementare a SQL n limbajul C, vom aduce exemplu a regulilor sintactice generale de implimentare a SQL n limbajul C, vom aduce exemplu a regulilor sintactice generate de implementare, utilizate pentru orice limbaj. Aceasta va permite aprecierea nivelului de standartizare a unei realizri concrete. <embedded SQL statement>::= <SQL prefix> {<declare cursor> |<embedded exception declaration> |<SQL statement>} [<SQL terminator>] <SQL prefix>::=EXEC SQL

<SQL termination>::=END EXEC|; <embedded SQL declare section>::= <embedded SQL begin declare> [<host variable definition>] <embedded SQL end declare> <embedded SQL begin declare>::= <SQL prefix> BEGIN DECLARE SECTION[<SQL terminator>] <SQL embedded end declare>::= <SQL prefix> END DECLARE SECTION[<SQL terminator>] <embedded variable name>::=:<host identifier> <embedded exception declaration>::= WHENEVER<condition><excetion action> <condition>::=SQLERROR|NOT FOUND <exception action>::=CONTINUE|<go to> <go to>::={GOTO|GO TO}<target> <target>::=:<host identifier>|<unsigned integer>. Operaiile implimentate SQL, inclusiv i declararea cursorului, deasemenea despriturile declarrii situaiilor excepionale i a variabilelor programului de baz trebuie s fie luate n ghilimele EXEC SQL i END EXEC. Declararea cursorului trebuie s fie ntlnit textual mai devreme de orice operaie ce se bazeaz pe acest cursor. Toate variabilele programului de baz ce se utilizeaz n operatorii implimentai SQL, trebuie s fie declarai textual n despritura anterioar acestui operator de declarare a variabilelor programului de baz. Cu toate acestea sintaxa declarrii variabilelor corespunde sintaxei limbajului de programare de baz, ns la nceputul numelui variabilei se pun dou puncte. Mecanismul de prelucrare a situaiilor excepionale n SQL/89 este foarte simplu(putem spune primitiv). Putem crea reacia pentru apariia a dou feluri de condiii: SQL ERROR este condiia apariiei n variabil SQL CODE dup ndeplinirea operatorului implementat cu sens de valoare negativ; NOT FOUND este condiia apariiei n SQL CODE a valorii +100(acest cod nseamn emanarea cursorului). Reacia poate fi alctuit din execuia trecerii la semnul programului de baz(aciunea GO TO) sau poate s lipseasc(aciunea CONTINUE). Va reaciona acel operator de determinare a reaciei n caz de situaie excepional, care textual este mai aproape de la nceputul programului de operatorulSQL. S atragem atenia c n multe realizri se menin dou feluri de coduri de rspuns la execuia operatorilor SQL(implementai sau luai din modul): prin variabila SQL CODE cu codurile de rspuns, care sunt reprezentate prin numere ntregi i prin variabila SQL STATE cu codurile de rspuns, codificarte prin numere zecimale, afiate n form de text. Este tendina de trecere la utilizarea numai a mecanismului SQL STATE, dar n realizrile standarte trebuie s se menin mecanismul SQL CODE. 16.4. 16.4. Setul operatorilor de manipulare cu datele

Setul operatorilor de manipulare cu datele n standartul SQL/89 este determinat un set de operatori de manipulare cu datele foarte limitat. Ei pot fi clasificai pe grupe de operatori, legai cu cursorul, operatori singulari de manipulare cu datele i operatorii de finisare a tranzaciilor. Toi aceti operatori pot fi utilizai att n modulul SQL ct i n SQL implementat. S atragem atenia c n SQL/89 nu-I determinat setul de operaii a lui SQL interactiv. 16.4.1. Operatorii legai cu cursorul Operatorii acestei grupe sunt legai prin faptul c toi ei lucreaz cu un oarecare cursor, declararea cruiea trebuie s se conin n acelai modul sau n programul cu SQL implementat. Operatorul de declarare a cursorului

Vom repeta regulile sintactice de declarare a cursorului: <declare cursor>::= DECLARE <cursos name> CURSOR FOR <cursor specification> <cursor specification>::= <query expresion>[<order by clause>] <query expresion>::= <query term> |<query expresion> UNION [ALL] <query term> <query term>::=<query specification>|(<query expresion>) <order by clause>::= ORDER BY <sort specification> [{,<sort specification>}] <sort specification>::= {<unsigned integer>|<column specification>} [ASC|DESC]. La declararea cursorului se pot utiliya adres[ri de un tip mai comun cu posibilitatea execuiei organiyaiilor UNION ;I for[rii reyultatului final. Acest oerator nu este executabil, dar numai leag[ numele cursorului cu specificaia cursorului. Operatorul de deschidere a cursorului El este descris de regula sintactic[ urm[toare> <open statement>::=OPEN <cursor name>. n realizrile SQL implementat de obicei se cere ca declararea cursorului, textual s fie mai nainte de operatorul de deschidere a cursorului. Operatorul de deschidere a cursorului trebuie s fie primul n seria operatorilor ndeplinii, legai cu cursorul dat. La execuia acestui operator are loc pregtirea cursorului de lucru asupra lui. n parte, n acest timp are loc pregtirea specificaiei cursorului cu valorile variabilelor limbajului de baz n cazul SQL-ului implimentat, sau a parametrilor n cazul modulelor. n majoritatea realizrilor, n cazul SQL implementat, anume ndeplinirea operatorului de deschidere a cursorului duce la compilarea specificaiei cursorului. Operatorii urmtori pot fi executai n ordine aleatoare asupra cursorului deschis. Operatorul de citire a rndului urmtor a cursorului Sintaxa operatorului de citire este urmtoarea: <fetch statement> FETCH <cursor name> INTO <fetch target list> <fetch target list>::= <target specification>[{,<target specification>}]. n operatorul de citire se specific numele cursorului i despritura neaprat INTO, ce conine lista specificaiilor destinaiilor(lista numelor variabilelor a programei de baz n cazul SQL implementat sau a numelor parametrilor de ieire n cazul modulului SQL). Numrul i tipurile datelor n lista destinaiilor trebuie s coincid cu numrul i tipurile datelor listei de selecie a specificaiilor cursorului. Orice cursor deschis n totdeauna are poziia: el poate fi instalat naintea unui rnd al tabelului rezultant(naintea primului rnd ndat dup deschiderea cursorului), ntr-un rnd a rezultatului sau n ultimul rnd a rezultatului. Dac tabelul la care indic cursorul este nul sau cursorul e poziionat pe ultimul rnd sau dup el, atunci la execuia operatorului de citire cursorul se fixeaz n poziia de dup ultimul rnd, parametrului SQL CODE i se atribuie valoarea 100, scopurilor identificate n despritura INTO nu li se atribuie nici o valoare. Dac cursorul este poziionat naintea rndului, atunci el se poziioneaz n acest rnd i valoarea acestui rnd i se atribuie scopurilor corespunztoare. Dac cursorul este poziionat pe rndul r, diferit de ultimul rnd, atunci cursorul se poziioneaz pe rndul, care imediat urmeaz dup rndul r i valorile din acest rnd urmtor li se atribuie scopurilor corespunztoare.

Apare ntrebarea, n ce mod putem parametriza cursorul cu o valoare nedeterminat sau cum s vedem c valoarea aleas din rndul urmtor este nedeterminat. n SQL/89 acest lucru se atinge pe baza utilizrii aa numitor parametri indicatori i a variabilelor. Dac se cunoate c valoarea transmis din programul principal de la SGBD, poate fi nedeterminat i acest fapt l intereseaz pe programatorul aplicat, atunci specificaia parametrului sau a variabilei n operatorul SQL are tipul: <parameter name>[INDICATOR] <parameter name> la specificarea parametrului i <embedded variabile name>[IDENTIFICATOR] <embedded variable name> la specificarea variabilei. Valoarea negativ a parametrului indicator sau a variabilelor indicatoare(ele trebuie s fie de tip ntreg) coincide cu valoarea nedeterminat a parametrului sau a variabilei. Operatorul de tergere a poziiei Sintaxa acestui operator este: <delete statement:positioned>::= DELETE FROM <table name> WHERE CURENT OF <cursor name>. Dac cursorul specificat n operator este deschis i-i poziionat pe un oarecare rnd i cursorul determin tabelul schimbtor, rndul curent al cursorului se terge, iar cursorul se poziioneaz n poziia rndului urmtor. Tabelul specificat n despritura FROM a operatorului DELETE, trebuie s fie tabelul, specificat n cea mai exterioar despritur FROM de specificare a cursorului. Operatorul de modificare a poziiei Operatorul dat are sintaxa urmtoare: <update statement:positioned> UPDATE <table name> SET<set clause:positioned> [{,<set clause:positioned>}] WHERE CURENT OF <cursor name> <set clause positioned>::= <object column:positioned>= {<value expresion>|NULL} <object column:positioned>::=<column name>. Dac cursorul specificat n operator este deschis i-i poziionat pe un rnd oarecare, i cursorul determin tabelul schimbtor, atunci rndul curent al cursorului se modific n conformitate cu despritura SET. Poziia cursorului nu se schimb. Tabelul specificat n despritura FROM a operatorului DELETE trebuie s fie tabelul, specificat n cea mai exterioar despritur FROM a specificaiei cursorului. Operatorul de nchidere a cursorului Sintactica acestui operator este urmtoarea: <close statement>::=CLOSE<cursor name>. Dac n momentul execziei acestui operator cursorul este n stare deschis, atunci operatorul transfer cursorul n stare nchis. Dup aceasta asupra cursorului poate fi executat doar operaia OPEN. 16.4.2. Operatorii singulari de manipulare cu datele Fiecare operator al acestei grupe este independent fa de oricare alt operator. Operatorul de selecie Sintaxa lui este: <select statement>::= INTO<select target list><table expresion> <select target list>::= <target specification> [{,<target specification>}]

Deoarece rezultatul operatorului singular de selecie este tabelul, ce conine nu mai mult de un rnd, lista scopurilor se specific n nsi operatorul. Operatorul de tergere a cutrii El este descris de sintaxa urmtoare: <delete statement:searched>::= DELETE FROM <table name> WHERE[<searched condition>]. Tabelul T, specificat n despritura FROM a operatorului DELETE, trebuie s fie schimbtor. Asupra condiiei de cutare se depune condiia, c pentru tabelul T nu trebuie s se conin schie n nici o subadresare depus a predicatelor despririi WHERE. De fapt operatorul se execut n felul urmtor: se verific succesiv toate rndurile tabelului T i acele rnduri pentru care rezultatul calculului condiiei de selecie este true, se terg din tabelul T. n absena despriturii WHERE se terg toate rndurile tabelului T. Operatorul de modificare a cutrii El are sintaxa urmtoare: <update statement:searched>::= UPDATE <table name> SET<set clause:searched> [{,<set clause:searched>>}] [WHERE<searched condition>] <set clause:searched>::= <object column:searched>= {<value exprersion>|NULL} <object column:searched>::=<column name>. Tabelul T, specificat n operatorul UPDATE trebuie s fie schimbtor. Asupra condiiei de cutare se depune condiia c pentru tabelul T nu trebuie s se conin schie n nici o subadresare depus a predicatelor despririi WHERE. Operatorul se execut n felul urmtor: tabelul T se verific succesiv i fiecare rnd pentru care rezultatul calculului de cutare este true, se schimb n conformitate cu despritura SET. Dac expresia afirmativ n despritura SET conine schie pentru coloanele tabelului T, atunci la calculul expresiei afirmative se utilizeaz valorile coloanelor curente, pn la modificarea lor. Operatorii de finisare a tranzaciei Tranzacia curent poate fi finisat cu succes(cu fixarea n baza de date a schimbrilor efectuate) pe calea execuiei operatorului COMMIT WORK sau accidental(cu tergerea schimbrilor din baza de date, create de tranzacia curent) pe calea execuiei operatorului ROLL BACK WORK. La execuia oricrui din operatorii dai are loc nchiderea forat a tuturor cursoarelor, deschise la momentul execuiei operatorului de finisare a tranzaciei. 16.5. 16.5. SQL dinamic n Oracle V.6

SQL dinamic n Oracle V.6 setul de operatori SQL descris n standartul SQL/89 este destinat implimentrii n programul scris n limbajul obinuit de programare. De aceea n acest set sunt amestecai operatorii a limbajului relaional adevrat cu adresri(de exemplu operatorul de tergere a unei pri de rnduri din tabel, care satisfac valorii date i operatorii de lucru cu cursoarele, ce permit accesul pe rnduri la tabelul rezultat a adresrii. Este clar c n regimul de dialog setul de operatori SQL i sintaxa lor trebuie s fie un pic altfel. ntrebarea este cum s realizm un aa program de dialog. Regulile de implementare a SQL standart n programul elaborat ntr-un limbaj obinuit de programare prevd c toat informaia, privind operatorii SQL, e cunoscut n static(cu excepia valorilor variabilelor utilizate n calitate de constante n SQL). Nu sunt prevzute sursele standarte de compilare cu execuie succesiv a operatorilor, care devin cunoscui doar n momentul execuiei(de exemplu se introduc din

terminal). De aceea bazndu-ne doar pe standart, e imposibil de a realiza monitorul de dialog de interaciune cu BD n limbajul SQL sau alt program aplicat, n care textul operatorilor SQL apare n timpul execuiei, adic standartul trebuie lrgit. Una din posibilele ci de lrgire const n utilizarea grupului special de operatori, ce asigur compilarea dinamic(n timpul execuiei programului aplicat) a submulimii de baz a operatorilor SQL i care sisin execuia lor corect. Unul din seturile de aa operatori fcea parte din dialectul SQL, realizat n System R, alt set mai deosebit face parte din realizarea Oracle V.6 i n sfrit, n standartul nou SQL/92 a aprut versiunea standart a lui SQL dinamic. Deoarece n SGBD Oracle sursele lui SQL dinamic sunt realizate comparativ de mult, are sens s le vedem mai nti pe ele, pentru a avea o baz de comparaie cu SQL/92. n setul adugtor de oeratori, ce menin compilarea dinamic a operaiilor SQL de baz, intr operatorii: PREPARE, DESCRIBE i EXECUTE. 16.5.1. Operatorul de pregtire Operatorul PREPARE are sintaxa: <prepare statement>::= PREPARE<statement name>FROM<host string variable> <statement name>::=name. n timpul execuiei operatorului PREPARE rndul caracterial ce se conine n host string variable, se transmite compilatorului SQL, care-l prelucreaz la fel ca i cum s-ar fi primit n static. Codul primit la execuia operatorului prepare rmne acionabil pn la finisarea tranzaciei sau pn la execuia repetat a operatorului dat PREPARE n limitele aceleieai tranzacii. Spre deosebire de operatorii SQL inclui static n programul elaborat n limbajul de programare dat are loc dup nume(adic n conformitate cu standartul n operatorul SQL implementat pot fi utilizate pur i simplu numele variabilelor programului dat), natura dinamic a operatorilor, pregtii cu ajutorul operatorului PREPARE, impun analiza acestor nume ca nume a parametrilor formali. Coincidena acestor parametri formali cu adresele variabilelor programului dat se determin poziional, n timpul execuiei operatorului pregtit. 16.5.2. Operatorul de primire a descriere a operatorului pregtit Operatorul DESCRIBE este prevzut pentru determinarea tipului operatorului pregtit mai nainte, de a determina numrul i tipurile coloanelor tabelului rezultant, dac operatorul pregtit este operator de selecie(SELECT). Aciunea operatorului DESCRIBE const n faptul c n locaia de memorie selectat a programului aplicat(structura acestei locaii este fixat i este cunoscut de ctre utilizatori) se nscrie informaia care caracterizeaz operatorul pregtit mai devreme cu numele dat. 16.5.3. Operatorul de execuie a operatorului pregtit Operatorul EXECUTE sete destinat execuiei operatorului SQL pregtit mai devreme de tipul N(care nu cere aplicarea cursorului) sau pregtirii concomitente i execuiei a aa operator. Sintaxa operatorului EXECUTE este: <execute statement>::= EXECUTE {<statement name>[USING<host vars list>] (IMMEDIATE<host string variable>}. Pentru execuia operatorului pregtit slujete prima variant a operatorului EXECUTE. n acest caz ;statement name: trebuie s dea numele ce a fost utilizat mai devreme n operatorul PREPARE. Dac n operatorul pregtit sunt prezeni parametri formali, atunci n operatorul EXECUTE trebuie s se indice lista parametrilor actuali <hosrt vars list>. Numrul i tipurile parametrilor formali a operatorului pregtit. Varianta a doua a operatorului EXECUTE, n Oracle este destinat pregtirii concomitente i execuiei operatorului SQL de tip N. n acest caz parametrii execuiei operatorului EXECUTE

este rndul, care trebuie s conin textul operatorului SQL(acest rnd poate fi deasemenea indicat literal). Se interzice utilizarea n acest operator a variabilelor a programului dat a parametrilor formali. 16.5.4. Lucrul cu operatorii dinamici SQL prin intermediul cursoarelor Pentru utilizarea a aa operatori se utilizeaz lrgirea mecanismului cursoarelor standartului SQL. n primul rnd, la determinarea cursorului putem indica nu numai specificaia literar a cursorului, ci i numele operatorului ce se introduce cu ajutorul operatorului PREPARE( n acest caz operatorul PREPARE trebuie s se afle textual mai sus de operatorul DECLARE). Aa dar sintactica complet a operatorului DECLARE este urmtoarea: <declare cursor>::= DECLARE <cursor name> CURSOR FOR{<cursor specification>|<statement name>} Deoarece, pentru aa cursor n static nu se cunoate informaia despre variabilele programului dat de intrare i de ieire, atunci se utilizeaz alt form a operatorilor OPEN i FETCH. Sintaxa complet a acestor operatori: <open statement>::= OPEN<cursor name> [USING{<host vars list>|DESCRIPTOR<descr name>}] <fetch statement>::= FETCH<cursor name> {INTO <fetch target list> (USING<host vars list> (USING DESCRIPTOR <descr name>}. Dup cum se vede, se presupun duo tipuri de indicare a parametrilor de tip parametric de intrare i de ieire: direct cu intrarea n operatorii OPEN i/sau FETCH a listelor numelor variabilelor a programului dat i indirect, cnd numele parametrilor i adresele lor se indic printro structur adugtoare a descriptorilor. Prima metod se ofer pentru lucrul cu operatorii de selecie, pentru care este fixat setul parametrilor formali de intrare i de ieire. Mai precis, n ceea ce privete parametrii de ieire, trebuie s fie fixai numrul i tipurile elementelor a listei de selecie. A doua metod de lucru cu operatorii dinamic compilai, care necesit utilizarea cursoarelor, const n utilizarea descriptorilor a listelor parametrilor formate dinamic. n acest caz toat rspunderea pentru coincidena tipurilor parametrilor formali i actuali cade pe programator. n rezultatul erorii la formularea a aa liste, poate fi pierdut memoria programului C. Lecia 17. Unele proprieti SQL/92 i SQL-3

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

[WITH MAX <occurences>] <occurences>::=<simple value specification> <descriptor name>::= [<scope option>]<simple value specification> <scope option>::=GLOBAL|LOCAL <simple value specification>::= <parameter name> (<embedded variable name> (<literal>. Comentarii: Descriptorul este partea dinamic distingibil a memoriei programului aplicat care se utilizeaz pentru primirea informaiei despre rezultat sau despre parametrii operatorului SQL pregtit dinamic sau pentru indicarea parametrilor a aa operator. Sensul, c pentru destingerea memoriei se utilizeaz operatorul SQL, i nu pur i simplu funcia standart ALLOC sau o oarecare alt funcie a adresrii dinamice de memorie, const n faptul c programul aplicat nu cunoate structura descriptorului i chiar a adresei lui. Aceasta permite de a nu lega SQL cu posibilitile deosebite a oricrei structuri de programare. Toate schimburile de informaie ntre programul aplicat i descriptori au loc la fel cu ajutorul unor operatori SQL(GET i SET, uite mai jos). ntrebarea a doua: Pentru ce n genere s destingem dinamic memorie sub descriptori. Aceasta se face pentru c n caz general programul aplicat, care utilizeaz SQL dinamic, nu cunoate n static numrul operaiilor SQL ce lucreaz simultan, descrierea crora i-ar putea fi necesar. Cu aceeai e legat faptul c numele descriptorului poate fi indicat ca rnd literal de simboluri att i ca variabil caracterial a limbajului inclusiv, adic el poate fi generat n timpul de ndeplinire a programului. n operatorul ALLOCATE DESCRIPTOR, se poate specifica numrul elementelor de descriere, pentru care el este calculat. Dac, de exemplu, n timpul alocrii memoriei prin descriptor n despritura WITH MAX se specific un numr ntreg N, iar apoi descriptorul se utilizeaz pentru descrierea M(M>N) elemente(de exemplu M coloane a rezultatului adresrii, atunci acest fapt duce la apariia situaiei excepionale. 17.2. 17.2. Operatorul de elibirare a memoriei din descriptor

Operatorul de elibirare a memoriei din descriptor <deallocate descriptor statement>::= DEALLOCATE DESCRIPTOR <descriptor name>. Comentariu: Execuia acestui operator aduce la elibirarea memoriei din descriptorul delimitat mai devreme. Dup aceasta utilizarea numelui descriptorului este ilegal n orice alt operator, n afar de ALLOCATE DESCRIPTOR. 17.3. 17.3. Operatorul de primire a informaiei din regiunea descriptorului SQL Operatorul de primire a informaiei din regiunea descriptorului SQL <get descriptor statement>::= GET DESCRIPTOR <descriptor name> <get descriptor information>::= <get count> (VALUE<item number> <get item information> ({<comma><get item information>}] <get count>::= <simple target specification 1>

<equals operator> COUNT <get item information>::= <simple target specification 2> <equals operator> <descriptor item name> <item number>::=<simple value specification> <simple target specification 1>::=<simple target specification> <simple target specification 2>::=<simple target specification> <descriptor item name> TYPE (LENGTH (OCTET_LENGTH (RETURNED_LENGTH (RETURNED_OCTET_LENGTH (PRECISION (SCALE (DATETIME_INTERVAL_CODE (DATETIME_INTERVAL_PRECISION (NULLABLE (INDICATOR (DATA (NAME (UNNAMED (COLLATION_CATALOG (COLLATION_SCHEMA (COLLATION_NAME (CHARACTER_SET_CATALOG (CHARACTER_SET_SCHEMA (CHARACTER_SET_NAME <simple target specification>::= <parameter name> <embedded variable name>. Comentariu: Operatorul GET DESCRIPTOR se utilizeaz pentru selecia informaiei de descriere, amestecat mai devreme n descriptor cu ajutorul operatorului DESCRIBE. La o singur execuie a operatorului putem primi sau numrul elementelor completate(COUNT), sau informaia, ce se conine n unul din elementele completate. 17.4. 17.4. Operatorul de instalare a descriptorului Operatorul de instalare a descriptorului <set descriptor statement>::= SET DESCRIPTOR<descriptor name> <set descriptor information> <set descriptor information>::= <set count> (VALUE<item number><set item information> [{<comma><set item information>}] <set count>::=COUNT<equals operator><simple value specification 1> <set item information>::= <descriptor item name> <equals operator>

<simple value specification 2> <simple target specification 1>::=<simple target specification> <simple target specification 2>::=<simple target specification> <item number>::=<simple value specification>. Comentariu: Operatorul SET DESCRIPTOR se utilizeaz pentru completarea elementelor descriptorului cu scopul utilizrii lui n despritura USING. La o singur execuie a operatorului valoarea o putem duce n cmpul COUNT(numrul elementelor completate), sau parial sau total de creat un element a descriptorului. 17.5. 17.5. Operatorul pregtirii

Operatorul de pregtire <prepare statement> PREPARE<SQL statement name> FROM<SQL statement variable> <SQL statement variable>::=<simple target specification> <preparable statement>::= <preparable SQL data statement> |<preparable SQL schema statement> |<PREPARABLE SQL transaction statement> |<preparable SQL session statement> |<preparable implementation defined statement> <preparable SQL data statement> |<delete statement:searched> |<dynamic single row select statement> |<insert statement> |<dynamic select statement> |<update statement:searched> |<preparable dynamic delete statement:positioned> |<preparable dynamic update statement:positioned> <preparable SQL schema statement>::=<SQL schema station> <preparable SQL tranzaction statement >::=<SQL tranzaction station> <preparable SQL session statement >::=<SQL session station> <dynamic select statement>::=<cursor specification> <dynamic simple row select statement>::=<query specification> <SQL statement name>|<extended statement name> <extended statement name>::=[scope option]<simple value specification> <cursor specification>::= <query expresion>[<order by clause>] [<updatability clause>::= FOR {READ UNLY | UPDATE[OF<column name list>]} <query expresion>::= <non-join query expresion> |<joined table> <query specification>::= SELECT[<set cuantifier>] <select list><table expresion> <set cuantifier>::=DISTINCT|ALL. Comentariu: Operatorul PREPARE induce compilarea i construirea planului de execuie a operatorului SQL dat sub form de text. Dup execuia reuit a operatorului PREPARE, cu operatorul pregtit

se leag numele dat a acestui operator, care pe urm poate fi utilizat n operatorul DESCRIBE, EXECUTE, OPEN CURSOR, ALLOCATE CURSOR i DEALLOCATE PREPARE. Legtura aceasta se pstreaz pn la execuia operatorului DEALLOCATE PREPARE. 17.6. 17.6. Operatorul de respingere de la operatorul pregtit

Operatorul de respingere de la operatorul pregtit <deallocate prepared statement>::= DEALLOCATE PREPARE <SQL statement name>. Comentariu: Execuia acestui operator duce la aceea c, operatorul SQL pregtit mai devreme, legat cu numele dat a operatorului, se lichideaz i, corespunztor, numele operatorului devine nedeterminat. Dac operatorul pregtit este operator de selecie, i n timpul execuiei operatorului DEALLOCATE exist un cursor deschis, legat de numele operatorului pregtit, atunc DEALLOCATE returneaz codul erorii. Dac n operatorul seleciei exist cursor nedeschis, format cu ajutorul operatorului ALLOCATE CURSOR, atunci acest cursor se lichideaz. Dac cursorul s-a anunat de operatorul DECLARE CURSOR, atunci acest cursor trece n starea existent pn la execuia operatorului PREPARE. Dac cu cursorul a fost legat operatorul pregtit(DELETE dynamic sau UPDATE), atunci pentru aceti operatori se execut operatorul DEALLOCATE. 17.7. 17.7. Operatorul adresrii la descrierea operatorului pregtit

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

17.8.

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

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

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

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

<dynamic open statement>::= OPEN<dynamic cursor name>[<using clause>]. Comentariu: De fapt, operatorul de deschidere a cursorului, legat cu operatorul SQL pregtit dinamic, se deosebete doar prin posesia despriturii using, n care se indic parametrii formali a operatorului de selecie. n afar de aceasta, numele cursorului poate fi declarat prin variabil. 17.13. Operatorul de citire a rndului pe cursor, legat cu operatorul de selecie pregtit dinamic 17.13. Operatorul de citire a rndului pe cursor, legat cu operatorul de selecie pregtit dinamic <dynamic fetch statement>::= FETCH[[<fetch orientation>]FROM] <dinamic cursor name><using clause>. Comentarii: De fapt, operatorul de citire pe cursor, legat cu operatorul SQL, dinamic se deosebete doar prin posesia despriturii using, n care se declar aranjarea valorilor rndului curent a tabelului rezultant. n afar de aceasta, numele cursorului poate fi dat prin variabil. 17.14. 17.14. Operatorul de nchidere a cursorului legat de operatorul de selecie pregtit dinamic

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

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

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

17.17.

Operatorul de pregtire a tergerii poziionale <prepare dynamic delete statement>positioned>::= DELETE[FROM<table name>] WHERE CURENT OF<cursor name>. Comentariu: Sensul de baz a apariiei a acestuia i a urmtorului operator const n faptul c ansamblul dintre cursorul, determinat pe operatorul de selecie pregtit dinamic i operatorilor de tergere i modificare declarai static, de aceea cursorul arat destul de neclar. De aceea n standart au aprut operatorii de tergere i introducere poziional pregtii dinamic. Desigur c ei trebuies se execute cu ajutorul operatorului EXECUTE. 17.18. 17.18. Operatorul de pregtire a modificrii poziionale Operatorul de pregtire a modificrii poziionale <preparable dynamic update statement>positioned>::= UPDATE[<table name>] SET<set clause>[{<comma><set clause>}] WHERE CURENT OF<cursor name>. Comentariu: Uite punctul trecut.

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

Lista noilor posibiliti SQL-3 n standartul SQL/92, n comparaie cu SQL/89, limbajul a fost lrgit, n mod principal, cfantitativ, cu toate c aceste lrgiri cantitative au fost ndeajuns pentru ca standartul SQL/92 s nu fie realizat complet pn acum n SGBD comerciale. Deoarece SQL/92 nu satisfcea o mare parte de sugestii, adresate limbajului SQL, a fost formt un comitet nou, care trebuia s aleag standartul limbajului cu lrgiri calitative. Limbajul SQL-3 nc nu este format complet, multe aspecte se mai consult. De aceea ctre lista posibilitilor adus aici ca exemplu trebuie s ne adresm ca la una iniiatoare. 17.19.1. Tipurile de date Setul tipurilor de date implementate se propune de lrgit prin tipurile BOOLEAN i ENUMERATED. Cu toate c din cauza susinerii valorilor nedeterminate limbajului SQL i este recomandat utilizarea logicii tridimensionale, tipul BOOLEAN conine doar dou valori posibile: TRUE i FALSE. Pentru afiarea valorii unikown se recomand utilizarea lui NULL, ceea ce-i desigur nu chiarbine. Tipul de enumeraie ENUMERATED are proprieti asemntoare proprietilor tipului de enumeraie n limbajele de programare. S-au lrgit posibilitile de lucru cu valorile nedeterminate. A aprut operatorul nou CREATE NULL CLASS, ce permite introducerea setului enumerat de valori nedeterminate. La determinarea domeniului putem arta numele clasei valorilor nedeterminate, apariia crora este permis n coloanele, legate de acest domeniu. Sensul fiecrei valori nedeterminate se nterpreteaz la nivelul utilizatorilor. Se propune includerea n limbaj a posibilitilor de utilizare a tipurilor de date determinate de utilizator. Se vor ivi posibiliti de a determina tipuri de date abstracte, cu o sistem intern complicat pe baza posibilitilor tradiionale de agregare i structurizare ca LIST, ARRAY, SET,

MULTISE i TUPLE, de asemenea i posibilitile de determinare a tipurilor obiect prin metode corespunztoare n stilul de apropiere obiect-orientat. Apare posibilitatea utilizrii principiului de motenire a proprietilor tabelului existent(supertabelului) la determinarea tabelului nou(subtabelului). Subtabelul va moteni de la supertabel toate determinrile coloanelor i a cheii primare. Alt posibilitate de a crea tabelul asemntor cu cel existent n sensul c tabelul nou va moteni determinrile crorva coloane a tabelului existent. 17.19.2. Careva alte proprieti a lui SQL-3 Una din problemele de realizare a lui SQL n totdeauna era problema de determinare a modificrii legturilor. Dac configuraia include legtura de tip general, atunci teoretic este imposibil de determinat, putem noi s interpretm la fel operaiile de noire a aa configuraie. ns exist cteva clase principale de legturi, care preventiv sunt schimbtoare. n SQL-3 se propune de a determina aceste clase cu ajutorul construciilor sintactice speciale. n sfrit apare posibilitatea de determinare a trigherelor ca combinaii de specificare a actului i a ciunii. Actul se determin ca SQL-procedur, n care se pot utiliza ct operatori SQL, att i un rnd de construcii dirijatoare. n realitate, acest mecanism este foarte aproape de cel din Oracle v.7. Ct despre dirijarea cu tranzaciile, are loc ntoarcerea la ideile vechi System R despre posibilitatea instalrii punctelor de salvare(savepoints) n interiorul tranzaciilor. n operatorul ROLLBACK putem specifica identificatorul punctului de salvare instalat mai devreme, i atunci va avea loc ntoarcerea tranzaciei nu ctre nceputul su, dar ctre acest punct de salvare. Deci, n SQL-3 putem atepta multe posibiliti interesante i de folos. ns, chiar proiectele din timp ale standartului inclu de dou ori mai multe pagini dect standartul SQL/92. De aceea este greu de ateptat o realizare rapid a acestui standart dup admiterea lui(muli n genere se ndoiesc de faptul c acest standart va fi vre-o dat realizat). Compilatorii SQL Compilatorii SQL Lecia 18. Compilatorii SQL. Problemele Optimizrii Vorbind despre optimizarea adresrilor n SGBD relaionale, se are n vedere aa un tip de prelucrare a adresrilor, cnd pe baza configuraiei iniiale a adresrii, pe baza creerii lor, se elaboreaz planul de produceri a execuiei adresrii, fiind cel mai optimal din structurile de dirijare existente n baza de date. Creerile corespunztoare a configuraiei iniiale a adresrii se efectuieaz de componenta special a SGBD de ctre optimizator i optimizarea planului adresrii, efectuat de optimizator, poart caracter condiional: planul este optimizat n dependen de criteriile, declarate n optimizator. 18.1. 18.1. jos. n prima faz adresarea, adresat n limbajul adresrilor, se supune analizei lexicale i sintactice. n acest timp mse creeaz configuraia sa intern, ce reflect structura adresrii i care conine informaia ce caracterizeaz obiectele bazei de date artate n adresare(relaii, cmpuri, constante). Informaia despre obiectele pstrate n baza de date se alege din cataloagele BD. Configuraia intern a adresrii se formeaz i se utilizeaz n stadiile urmtoare de prelucrare a adresrii. Forma configuraiei interne trebuie s fie comod pentru urmtoarele creeri optimizaionale. Schema de prelucrare a aresrii Schema de prelucrare a aresrii Ne putem nchipui c prelucrarea adresrii ctre sistem este alctuit din fazele, artate mai

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

Optimizarea sintactic a adresrii la apropierea sintactic ctre organizarea optimizatorilor adresrilor la etapa optimizrii logice au loc creeri logice a configuraiei interne a adresrii, carembuntesc configuraia intern iniial n dependen de strategiile fixate a optimizatorului. Caracterul mbuntirilor e legat de specificul organizrii generale a optimizatorilor, n special de deosebirile procedurii de cutare a planurilor procedurale posibile a adresrilor, executate n faza a treia de prelucrare a adresrii. De aceea e greu de format caracteristica i clasificarea ntreag a metodelor de optimizare logic. Ne limitm la careva utilizri i vom privi o clas de creeri logice important, care se ating de ntrebri complicate, exprimate n limbajul SQL. 18.2.1. Creerile logice simple a adresrilor Clasa urmtoare de creeri logice a adresrilor include crearea obiectelor ce intr n condiia de selecie, ctre configuraia canonic. Se au n vedere predicatele ce conin operaiile de comparaie a valorilor simple. Aa predicat are tipul expresie afirmativ or expresie aritmetic, unde or este operaie de comparaie, dar expresiile logice n prile stnga i dreapta vor deine numele cmpurilor relaiilor i constante(n limbajul SQL, printre constante se pot ntlni i nume de variabile a programului din valorile crora devin cunoscute nu numai la execuia real a adresrii). Configuraiile canonice pot fi diferite pentru diferite tipuri de predicate. Dac predicatul include un singur nume a cmpului, atunci configuraia lui canonic se permite de exemplu, de avut n vedere numele cmpului or expresia aritmetic constant(aceasta e forma predicatului predicat simplu de selecie - e foarte util pentru execuia urmtoarei etape de optimizare). Dac configuraia iniial a prdicatului are tipul (a+5)or 36?(cu litere mici se indic numele variabilelor, iar cu litere mari numele cmpurilor relaiilor), atunci configuraia canonic a acestui predicat poate fi or36/(a+5)?. Dac predicatul include fix dou nume de cmpuri a duferitor relaii(sau a dou diferite intrri a unei relaii), atunci configuraia lui canonic poate avea tipul numele cmpului or expresie aritmetic, unde expresie aritmetic din partea stng include numai

constante i al doilea nume a cmpului(acesta de asemenea este forma util pentru execuia urmtorului pas de optimizare predicatul de alipire; este deosebit de important n cazul ecvialipirii, cnd or este egalitate). Dac n configuraia iniial predicatul are tipul 5(A-a(B or b), atunci configuraia sa canonic este A or(b+a(B)/5. n sfrit pentru predicatele de tip mai general are sens de a aduce predicatul la configuraia canonic de tipul expresia aritmetic or expresia aritmetic constant, unde expresia prii drepte i stngi de asemenea sunt aduse la configuraia canonic; de exemplu, n expresii sunt deschise parantezele i se execut ordinea lexicografic. n continuare putem face citarea expresiilor aritmetice comune n diferite predicate a adresrii. Aceasta este justificat cci, n timpul execuiei adresrii calculului expresiilor aritmetice se va face la selecia fiecrui cortej urmtor, adic un num potenial mare de ori. La aducerea predicatelor la o configuraie canonic se pot calcula expresiile constante i se pot arunca negaiile logice. Clasa urmtoare a ceerilor logice este legat de aducerea la o form canonic a expresiei logice, ce indic condiiile de selecie a adresrii. De regul se utilizeaz forma normal disjunctiv, ct i forma normal conjunctiv. Alegerea formei canonice depinde de organizarea general a optimizatorului. La conducerea condiiei logice ctre o configuraie canonic, putem executa cutarea predicatelor comune(ele pot exista de la nceput, dar pot aprea i dup aducerea predicatelor la tipul canonic sau la procesul normalizrii condiiei logice) i putem simplifica expresia logic pe contul, de exemplu, codul conjunciei predicatelor reciproc opuse. Fragmentul expresiei logice (A>5) poate fi nlocuit cu FALSE. Se admit i simplificri mult mai detepte. De exemlu fragmentul expresiei logice (A>B)AND(B=5) poate fi nlocuit cu (A>5). Aa simplificri pot fi importante pentru prelucrarea de mai departe a adresrii: n adresarea cu condiie logic de tipul ntiu se propunea alipirea relaiilor; dup creare adresarea nu cere alipire. 18.2.2. Crearea adresrilor cu schimbarea ordinii operaiilor relaionale n optimizatoarele tradiionale sunt rspndite creeri logice, legate de schimbul ordinii de execuie a operaiilor relaionale. Ca exemplu a acestei reguli de creare n termenii algebrei relaionale poate fi urmtoarea(A i B nume de relaie): (A JOIN B) WHERE restriction on A AND restriction on B este echivalent cu expresia: (A WHERE restriction on A)JOIN(B WHERE restriction on B). Aici JOIN este operator relaional a alipirii naturale a relaiilor. Dar WHERE restriction operatorul de limitare a relaiei A n dependen de predicatul restriction. Cu toate c multe sisteme relaionale au limbaje de adresare, bazate pe algebra relaional, regulile de creare a expresiilor algebrice pot fi utile n alte cazuri. Destul de des se utilizeaz algebra relaional n calitate de baz a configuraiei interne a adresrii. E clar c dup aceasta putem executa i creeri algebrice. n parte, exist apropieri, legate de crearea ctre forma algebric a adresrilor n limbajul SQL. Putem accentuam dou cauze principale de recreare a adresrilor n SQL ctre forma algebric. O cauz mai puin important poate fi tinderea de a utiliza algebra relaional n calitate de interfa interioar unificat la SGBD relaional. Aceasta este rspndit la utilizarea mailor specializate a bazelor de date, pe baza crora se realizeaz diferite interfee de acces la bazele de date. Interfaa mainei bazelor de date trebuie s fie unificat(de exemplu s fie algebric), iar celelalte intefee, inclusiv interfaa de baz a SQL, se aduc la cea algebric. A doua cauz, foarte important n contextul problemelor optimizrii, este faptul c algebra relaional este mai simpl dect limbajul SQL. Crearea adresrii ctre forma algebric uureaz aciunile urmtoare a optimizatorului n selecia planurilor optimale. Deci un optimizator dezvoltat de adresri a sistemului, orientat pe SQL trebuie s desting toate planurile de executare posibil a orice adresare, dar spaiul de cutare a acestor planuri, n general, este foarte mare. n fiecare optimizator concret se utilizeaz evristica sa pentru micorarea spaiului de cutare. Unele, posibil cele mai optimale planuri, nu vor fi nici o dat analizate. Crearea logic a adresrii n SQL ctre

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

La utilizarea n optimizator a adresrilor de aa apropiere nu-i neaprat de format creeri formale a adresrilor. Optimizatorul trebuie, ntr-o msur mai mare, s utilizeze semantica adresrii prelucarate acum, dar n ce mod ea va fi recunoscut, aceasta-i ntrebare ce ine de tehnic. S observm, c n apropierea descris de noi sunt cteva incorectitudini fine n semantic. Sunt cunoscute metode modificate, corectate, ns ele sunt prea complicate tehnic, pentru a le analiza la leciile noastre. 18.3. Optimizarea semnatic a adresrilor 18.3. Optimizarea semnatic a adresrilor Creerile analizate a se bazeaz pe semantica limbajului adresrilor, n ele nu se analizeza semantica BD, creia i se adreseaz adresarea. Orice creare poate fi format indiferent de faptul, care baz de date se are n vedere. n realitate, n fiecare baz de date relaional adevrat, se pstreaz i o oarecare informaie semantic, ce de exemplu, determin integritatea bazei de date. Dac s vorbim despre bazele de date, menionate n System R, atunci aceast informaie se pstreaz n registrele de sistem a abzei de date n calitate de limite date a integritii. Deoarece SGBD garanteaz integritatea bazei de date, atunci limitele integritii pot fi privite ca nite axiome, n mprejurarea crora se formeaz adresarea ctre baza de date. 18.3.1. Crearea adresrilor pe baza informaiei semantice n calitate de exemple iniiale de creare a adresrilor pe baza informaiei semantice s analizm apropierile SGBD cunoscute System R i INGRES ctre asigurarea lucrului bazei de date prin configuraii. Aceste creeri nu au fost orientate ctre o optimizare a adresrilor, dar au fa de aceasta o legtur reciproc. Configuraia bazei de date(new) n terminalele limbajelor SQL i QUEL aceasta este adresarea enumerat a registrelor ce reprezint din sine din punct de vedere a utilizatorului, acelai obiect a bazei de date ca i relaia. Configuraiile pot fi utilizate n adresri ca i relaiile memorabile(cu limite n utilizarea lor la operatorii de modificare a bazei de date). Semantica configuraiei cere ca aceasta s fie precis: n momentul execuiei adresrii pentru configuraie, informaia primit trebuie s coincid strii curente a prii memorabile a bazei de date. execuia adresrii pentru configuraie cere materializarea ei, adic calculul relaiei, determinat de adresare, care-i legat de configuraie. Apropierea System R i Ingres este bazat pe aceea c configuriile se pstreaz n registrele bazei de date n form intern, primit n urma execuiei analizei gramatice (de asemenea a optimizrii logice) a adresrii corespunztoare. n timpul prelucrrii adresrii pentru configuraie, naintea execuiei fazei optimizrii logice, are loc contopirea formelor interne a adresrii i a configuraiei. Se formeaz o form intern nou creat i pentru ea are loc prelucrarea de mai departe a adresrii, inclusiv optimizarea logic i selecia planului optimal de execuie a adresrii. n aa fel, optimizatorul primete mai mult informaie despre adresarea dat i poate lua hotrri mult mai corecte. De exemplu: Fie c configuraia este determinat ca: DEFINE VIEW V(C2)AS SELECT C1 FROM R WHERE C2>6 Adresarea se formuleaza in felul urmator: SELECT C2 FROM V WHERE C2<6. Dac adresarea s-ar fi compilat cu scopul materializrii configuraiei, s-ar fi ales metoda execuiei ei, bazat pe scanarea ciclic V cu selecia cortejelor, ce stisfac condiiei. Adresarea aa s-ar fi executat, pentru c n cele din urm s dea un rezultat gol. ns la contopirea formelor

interne a adresrii i configuraii am fi primit o form intern, echivalent adresrii SELECT C1 FROM R WHERE C1<6 AND C1>6. n faza optimizrii logice s-ar putea determina c aceast adresare este echivalent adresrii: SELECT C1 FROM R WHERE FALSE, de unde ar rezulta c rezultatul adresrii este gol. Din mulimea de cazuri acest caz de prelucrare a adresrilor pentru configuraiile bazelor de date permitea primirea execuiei unei adresri mult mai efective pe baza oferirii utilizatorului a mai mult informaie. Aceeai ideie st la baza optimizrii semantice a adresrilor: utilizarea informaiei semantice la optimizarea adresrii, informaiei pstrate n baza de adte indiferent de adresarea dat. Un alt exemplu de creare a adresrilor, ce au legtur cu optimizarea, este crearea adresrilor pentru modificarea bazei de date cu scopul satisfacerii limitelor integritii existente n baza de date. Aceast apropiere, pentru prima dat a fost utilizat n SGBD INGRES, dar se utuilizeaz i n alte sisteme, de exemplu System R. Limit a integritii se numete expresia logic, pstrat n registrele bazei de date, alctuit din predicate pe obiectele bazei de date. baza de date se afl n stare ntreag, dac se satisfac toate limitele integritii date. Dac se adreseaz o adresare pentru modificarea bazei de date, ce include limitele integritii, satisfacerea crora se cere la execuia oricrei modificri, atunci putem aduga limitelor predicatele corespunztoare pentru condiia logic a adresrii. Fie c baz de date, ce caracterizeaz structura organizrii, e alctuit din relaiile EMP i DEPT. n relaia EMP se nregistreaz organizaiile muncitoreti. Schema acestei relaii EMP(EMP#,EMPNAME,DEPT#); cmpul EMP# conine numrul unic a muncitorului; cmpul EMPNAME numele muncitorului, iar DEPT# - numrul seciei organizaiei n care lucreaz acest muncitor. Relaia DEPT pstreaz informaia despre secii i are schema: DEPT(DEPT#, EMPTCOUNTS) unde n cmpul EMPTCOUNTS se pstreaz numrul total de muncitori a acestei secii. Fie c este dat limita integritii ASSERT B IMMEDIATE ON EMP:EMP.DEPT#=6. Aceast limit nseamn interzicerea introducerii tergerii i modificrii cortejelor n relaia EMP cu valoarea cmpului DEPT# diferit de 6. Fie c se prelucreaz adresarea pentru tergerea cortejului DELETE EMP WHERE EMPNAME =Brown. Dac la compilarea adresrii nu inem cont de prezena limitei integritii, atunci metoda corect de execuie a aa adresare va fi: s alegem cortejele la care valoarea cmpului EMPNAME este Brown; de controlat satisfacerea urmtorului cortej cu limita integritii i dac controlul este satisfctor s se tearg cortejul. Dac limitele integritii se iau n vedere n timpul compilrii, atunci putem contopi formele interne a adresrii i limitele integritii corespunztoare, iar apoi de prelungit optimizarea n comun. n cazul nostru dup contopire se formeaz forma intern, echivalent a adresrii. DELETE EMP WHERE EMPNAME=Brown AND DEPT#=6 La execuia a aa tip de adresare nu va fi nevoie de apelurile adugtoare a controlului limitelor integritii de tipul 2, cci ele toate de acum sunt incluse n condiia logic de execuie a operaiei de tergere. n afar de aceasta optimizatorul primete o libertate n alegerea modului de execuie a adresrii, de exemplu, dac seciile sunt puine i pentru relaia EMP se menine indexul pe cmpul DEPT#, atunci, modul cel mai optimal de execuie a adresrii va fi scanarea relaiei prin index DEPT# cu condiia DEPT#=6 cu tergerea oricrui cortej ales n aa mod, cu valoarea cmpului EMPNAME egal cu Brown. n aa fel, metodele ce creeaz adresareas nu sunt ndreptate n special spre optimizare, ele pot ajuta la o execuie mai efectiv a adresrii. Eficacitatea execuiei adresrii se poate ridica pe contul cunotinelor utilizate, pstrate independent n BD. Exemplele studiate ne arat c ideiea optimizrii semantice, n principiu, nu este nou. Se posed i diferena proincipal dintre adresrile vzute mai sus i cele care se creeaz la optimizarea semantic. Deosebirea de baz const n aceea, c atunci cnd are loc contopirea

formei interne a adresrii cu forma intern a configuraiei sau cu formele interne a limitelor integritii, suntem obligai s utilizm total i neaprat informaia extern independent de faptul, va ajuta aceasta la optimizarea adresrii: condiia de selecie a configuraiei trebuie s fie total adugat prin AND ctre condiia de selecie a adresrii; aceeai se refer i la setul de condiii logice a limitelor integritii. De altfel semantica adresrii pentru configuraie sau operatorul de modificare a BD va fi nclcat. 18.3.2. Utilizarea informaiei semantice la optimizarea adresrilor optimizarea semantic se bazeaz pe posesia de ctre BD a informaiei semantice ce nu este neaprat de utilizat la prelucrarea adresrilor, dar utilizarea creia poate duce la o execuie mult mai optimal. Dac optimizarea semantic are de lucru doar cu cunotinele prezentate n forma limitelor integritii BD, atunci la optimizarea semantic se creeeaz o mulime de configuraii interne a adresrii; la fiecare creare se utilizeaz un oarecare set de limite a integritii. Dac, de exemplu, n BD sunt determinate dou limite a integritii A i B cu condiiile logice F1 i F2 i se prelucreaz adresarea cu condiia de selecie F atunci, n mersul optimizrii semantice vor fi primite configuraiile interne echivalente adresrilor cu condiiile F, F AND F1, F ANDF2 i F AND F1 AND F2. Fiecare din configuraiile interne primite se impune unei prelucrri totale pe parcurs, inclusiv optimizarea logic i alegerea planului optimal de execuie; din planurile primite(toate ele sunt echivalente semantic, adic au acelai rezultat) se alege cel mai eftin care i va deveni planul real de execuie a adresrii iniiale. Pentru utilizarea raional a optimizrii semantice este comod de a reprezenta limitele integritii BD n form implicativ. Atunci se va putea obine o ordine mai gndit a creerilor. Fie, de exemplu, n baza noastr de date despre structura organizaiei, relaia EMP e lrgit de cmpurile STATUS i SALARY. Valorile cmpului STATUS caracterizeaz funcia lucrtorului, iar cmpull SALARY salariul su. Poate fi specificat limita integritii exprimat prin aceea, c salariul ce ntrece 40000 poate fi specificat numai efilor de secii: ASSERT A ON EMP : IF SALARY >40000 THEN STATUS=MANAGER Fie c se prelucreaz adresarea: SELECT EMPNAME STATUS FROM EMP WHERE SALARY=20000 Dac s nu considerm caracterul implicativ a limitei integritii, atunci, dup regulile generale, va avea loc contopirea configuraiilor interne a adresrii i limitei integritii, care nu va da nimic. Dar dac vom privi limita integritii ca regul a crerii, dar partea stng a implicaiei ca condiie de utilizare a regulii, atunci contopirea nu va avea loc, ci n acz general va economisi timpul prelucrrii adresrii. Dar pentru adresarea SELECT EMPNAME, STATUS FROM EMP WHERE SALARY>40000. regula creeriieste utilizabil i aduce la adresarea semantic echivalent: SELECT EMPNAME, STATUS FROM EMP WHERE STATUS=MANAGER execuia creia poate fi cu mult mai efectiv. Dup crearea adresrii, n corespundere cu careva reguli, ctre configuraia primit poate fi utilizat i alt regul, etc. Este posibil operaia ciclurilor de creare. Problema construirii setului ntreg de configuraii semantic echivalente pe baza setului de reguli dat este foarte complicat. Rezolvarea prcis a acestei probleme poate cere cheltuieli, ce sunt mai mare ca cele pentru execuia adresrii n plan mai optimal. De aceea este nevoie de a utiliza algoritmi euristici, ce ngusteaz spaiul cutrii, adic care indic condiia de ncetare a generaie a noilor configuraii.euristica se bazeaz pe minimizarea sumei externe a costului optimizrii semantice i execuiei adresrii. Ca exemplu de euristic aspr poate fi urmtorul: optimizarea se face pn atunci, pn cnd cheltuielile pentru ea nu vor ntrece preul celui mai efectiv din toate planurile gsite de execuie a adresrilor. 18.4. Selecia i aprecierea planurilor alternative de execuie a adresrilor

18.4.

Selecia i aprecierea planurilor alternative de execuie a adresrilor Creerile optimizatoare, studiate mai sus, lsau configuraia intern a adresrii neprocedural. Configuraia procedural sau plan de execuie a adresrii se numete o aa configuraie a ei n care este detaliat ordinea de execuie a operaiilor de acces la BD de nivel fizic. De regul, n SGBD relaionale se depune subsistemul de dirijare cu datele la nivel fizic. n System R aa sistem se numete RSS(Relational Storage System) i asigur interfaa simpl, ce permite analiza consecutiv a cortejelor relaiilor ce satisfac condiiilor date pentru valorile cmpurilor, cu utilizarea indexilor sau a scanrilor simple a paginilor BD. n afar de aceasta, RSS permite crearea fiierelor temporale sortate i introducerea, tergerea i modificarea cortejelor individuale. Aa fel de subsisteme mai calr sau mai puin clar se distinct n fiecare SGBD de aa fel. Este clar, c pn la execuia adresrii este nevoie de crearea configuraiei sale procedurale. Deoarece acesta se selecioneaz diferit, este nevoie de ales dintre planurile alternative a adresrilor unul n dependen de careva trighere. De regul, criteriul de selecie a planului de execuie a adresrii este minimizarea costului execuiei. Cu toate acestea, n timpul prelucrrii adresrii la stadiul urmtor dup optimizarea logic, se soluioneaz dou probleme. Prima problem: reeind din configuraia intern a asdresrii i informaiei ce caracterizeaz structura de dirijare a bazelor de date(de exemplu indexii), de ales setul planurilor potenial posibile de execuie a adresrii date. problema a doua: de apreciat preul execuiei adresrii n dependen de fiecare plan alternativ i de ales planul cu preul cel mai redus. 18.4.1. Generarea planurilor La o apropiere tradiional ctre organizarea optimizatorilor ambele probleme se soluioneaz pe baza algoritmilor fixai reglementai n optimizator. Optimizatorul poate fi utilizat i pentru faptul c limitarea oricrei relaii, n dependen de predicatul dat, poate fi executat pe calea oricrei analize consecutive a relaiei. n aa fel adresarea SELECT EMPNAME FROM WHERE DEPT#=6 AND SALARY>15000 poate fi executat pe baza scanrii consecutive a relaiei prin indexul I1, determinat pe cmpul DEPT#, cu condiia de acces ctre indexul DEPT#=6 i cu condiia de selecie a cortejului SALARY>15000; n sfrit, scanrii relaiei prin indexul I2, determinat pe cmpul SALARY, cu condii a de acces la indexul SALARY>15000 i condiia de selecie a cortejului DEPT#=6. Analog se fixeaz strategiile de execuie a operaiilor mai complicate conexiuni relaionale a relaiilor, calculul funciilor de agregat pe grupele cortejurilor relaiilor .a. de exemplun n System R pentru ecviconexiuni a dou relaii se utilizeaz dou strategii de baz: metoda ciclurilor implementate i metoda sortrii cu topiri. Componenta optimizatorului, care genereaz planurile executabile a adresrilor arte o organizare complicat; generarea planului execuiei unei adresri complicate este un proces momentan, n mersul cruiea se iau n consideraie proprietile, ce se creeaz n timpul execuiei adresrilor dup planul dat a obiectelor temporale a BD. De exemplu, fie c adresarea e dat pentru trei relaii i n adresare sunt dou predicate de legtur: SELECT R1.C1, R2.C2, R3.C3 FROM R!, R, R# WHERE R1.C4=R2.C5 AND R2.C5=R3.C6. Atunci dac n planul adresrii se selecteaz ordinea execuiei legturilor nti R1 cu R2, iar apoi relaia temporal primit R3 i pentru execuia primei conexiuni se alege metoda sortrilor cu contopiri, atunci relaia temporal va fi sortat din timp dup C5 i de o sortare nu va fi nevoie dac i a doua legtur se va executa prin aceeai metod. Componenta optimizatorului ce duce la crearea mulimii de planuri alternative a execuiei adresrii se bazeaz pe strategii de mprire a adresrii n componente elementare i pe strategiile de execuie a componentelor elementare. Prima grup de strategii determin spaiul de cutare a

planului optimal de execuie a adresrii, a doua este ndreptat spre aceea c n acest spaiu ntradevr s se gseasc planuri optimale de execuie a adresrii. Cheiea ctre asigurarea execuiei efective a adresrii complicate este posesia strategiilor efective de execuie a componentelor elementare. Aceasta este o ntrebare important, dar nici noi nu o analizm: optimizatorul adresrilor utilizeaz strategiile implementate. S analizm problema mai actual a optimizatorului selecia celui mai bun plan de execuie a adresrii din mulimea planurilor alternative. 18.4.2. Aprecierea costului planului adresrii Dup generarea mulimii de planuri a execuiei adresrii pe baza strategiilor relaionale de mprire i a strategiilor de execuie a operaiilor elementare trebuie de ales un singur plan, n conformitate cu care va avea loc execuia adresrii. n caz de selecie greit adresarea se va efectua neefectiv. n primul rnd trebuie de determinat, ce se subnelege sub eficacitatea execuiei subadresrii. Aceast subnelegere depinde de specificul mediului operaional a SGBD. n unele condiii putem considera, c eficacitatea execuiei adresrii se determin de timpul execuiei sale, adic de reactivitatea sistemului n dependen de sistemul prelucrat de ea. n alte condiii determinativ este posibilitatea general de permisiune a sistemului n dependen de amestecul adresrilor executarea lor n paralel. Atunci ca msur a eficacitii putem socoti numrul de resurse a sistemului, ce trebuiesc pentru execuia lui, .a. Urmnd tehnologia dat, , vom vorbi despre costul planului de execuie a adresrii, determinat de resursele procesorului i unitile memoriei externe, care se dau la execuia adresrii. n SGBD relaionale se destinge subsistemul de dirijare cu accesul ctre datele n memoria extern(RSS a System R). Tradiional, datele n memoria extern se pstreaz sub form blocat, baza de adte ocup un set oarecare de blocuri a unui sau mai multe volumuri de diiscuri. Se presupune, c sursele de acces la la blocurile memoriei externe creeaz mai puine cheltuieli. De regul sistemele de dirijare cu accesul ctre date n memoria face buferizarea blocurilor bazei de date n memoria operativ. Fiecare bloc se pstreaz n unul din buferele SGBD pn cnd nu va fi scos de alt bloc a BD. Aceast deosebire a SGBD este de baz pentru ridicarea eficacitii generale a sistemului dar nu se scoate(n afar de cazul particular dar important) la aprecierea costurilor planurilor de execuie a adresrilor. n orice caz, componenta costului de execuie a adresrii, legat de resursele memoriei externe, depinde monoton de numrul blocurilor memoriei externe, accesul ctre cre va trebui pentru execuia adresri. Din alt parte, numrul blocurilor memoriei externe accesul ctre care trebuie la execuia adresrii, depinde monoton de numrul cortejurilor, atinse de adresare. Din aceasta rezult importana indicatorului predicatului de linii, ce caracterizeaz partea cortejurilor relaiei, care satisfac predicatului dat i care se numete nivelul de selecie a predicatului. Nivelul de selecie a prediactelor simple de tipul R.C or const, unde R.C d numele cmpului relaiei BD, or operaia de comparaie., dar const - constant, sunt bazele pentru costurile planurilor adresrilor. Percizia aprecierii nivelurilor de selecie determin precizia aprecierilor generale i corectitudinea alegerii planului optimal a adresrii. Nivelul selectivitii predicatului R.C or const depinde de tipul operaiei de comparaie, introducerea constantelor i rspndirea valorilor cmpurilor C a relaiei R n BD. Primii doi parametri de selecie pot fi cunsocui la efectuarea aprecierilor, dar rspndirile reale a valorilor cmpurilor relaiilor, de regul nu sunt cunoscute. Exeist un ir de apropieri ctre relaiile de rspndire pe baza informaiei statistice. Vom analiza mai apoi cele mai interesante dintre ele. Dac este cunoscut nivelul selectivitii a predicatului limitei relaiei, atunci este cunoscut puterea relaiei rezultante(de regul puterile relaiilor pstrate sunt cunoscute la prelucrarea adresrii). Dar n formulele de apreciere se iau n consideraie numrul de schimburi cu memoria extern, care-i cerut pentru execua adresrii. Desigur, numrul cortejurilor este preul superior a numrului nevoit de schimburi, dar acest cost poate fi foarte ridicat. Totul depinde de rspndirea cortejurilor pe blocurile memoriei externe. ntr-un rnd de costuri putem primi un pre mai precis a

numrului de blocuri. n sfrit, pentru adresrile complicate, ce includ de exemplu , conexiunea a mai mult de dou relaii, este nevoie de apreciat dimensiunile relaiilor intermediare ce apar n procesul execuiei adresrii. Pentru a aprecia puterea rezultatului a conexiunii a dou relaii, trebuie de tiut nivelul de selectivitate a predicatului de conexiune n legtur cu crearea direct a relaiiloroperanzilor. n caz general, este imposibil de determinat pe baza informaiei statistice nivelul de selectivitate a aa un prediact. De obicei se aplic aprecieri euristice destul de aspre, cu toate c se propun apropieri, ce asigur o precizie nalt. Apropierea System R se pazeaz pe dou propuneri de baz a rspndirii valorilor cmpurilor relaiilor: se presupune c valorile cmpurilor a toate relaiile BD sunt rpndite egal i c valorile a oricare dou cmpuri sunt rspndite independent. Prima propunere permite de apreciat selectivitatea predicatelor simple pe baza informaiei sintactice despre BD. Pe a doua propunere se bazeaz aprecierile numrului de blocuri, n care se gsete numrul cunoscut de corteje. Aceste dou propuneri sunt obiectul de critic a System R. Ele sunt formate doar cu scopul simplificrii optimizatorului i nu pot fi lmurite teoretic. Pot fi aduse exemple de BD pentru care aceste propuneri nu s-au afirmat. n aceste cazuri aprecierile optimizatorului System R nu vor fi adevrate. n registrele BD, pentru fiecare relaie R se memoreaz numrul cortejelor n relaia dat(T) i numrul blocurilor memoriei, n care se afl cortejele relaiei(N); pentru fiecare cmp C a relaiei se pstreaz numrul diferitor valori a acestui cmp(CD); valoarea memorabil minimal a acestui cmp(Cmin) i valoarea maximal(Cmax). La posedarea acestei informaii , lund n consideraie prima propunere a bazei de selecie a predicatelor simple, se calculeaz simplu(i precis, dac rspndirea este egal). Fie c SEL(P) este nivelul de selectivitate a predicatului P. Atunci: SEL(R.C=const)=CD/(CMax-Cmin) (la rspndire egal nivelul selectivitii a aa predicat nu depinde de valoarea constantei). SEL(R.C>const)=(Cmax-const)/(Cmax-Cmin), i altele. La aprecierea numrului de blocuri n care se pot afla cortejele ce satisfac predicatului R.C or const, se deosebesc cazuri de clasterizare sau neclasterizare a relaiei pe cmpul C. Aceste aprecieri au sens numai la studierea variantului sacnrii relaiei cu utilizarea indexului pe cmpul C. La studierea relaiei fr utilizarea indexului va trebui de adresat n totdeauna fix la N blocuri de memorie extern. Presupunerile despre egalitatea rspndirii valorilor atributelor relaiilor premit de a aprecia simplu i puterile relaiilo, care sunt rezultatele operaiilor bilocale relaionale i teoriilor mulimilor pentru relaii. Aprecierea selictivitii predicatelor se utilizeaz i la aprecierea cheltuirlilor resurselor procesorului. Se presupune c partea de baz a prelucrrii procesorale are loc n RSS. De aceea cheltuielile procesorale se msoar prin numrul de adresri i RSS ce corespunde numrului cortejelor, ce se primesc la scanarea relaiei memorabile sau temporale, adic prin selectivitatea expresiei logice, alctuit din predicate simple(condiia de selecie a nivelului RSS). Propunerea despre egalitatea i independena valorilor diferitor cmpuri a relaiei permite uor de apreciat selectivitatea expresiei logice, alctuit din predicate simple la nivelurile lor de selecie cunoscute. ntr-adevr, n System R nu se apreciaz selectivitatea predicatelor n mod direct. Aprecierea optimizatorului se bazeaz pe informaia statistic despre BD; execuia oricrei adresri const dintr-o combinaie a ctorva aciuni elementare. Ca exemple de execuii elemenare pot fi execuia limitei relaiei pe calea scanrii sale prin indexul clasterizat, sortarea relaiei, conexiunea celor dou relaii sortate mai devreme, .a. aprecierea general a planului de execuie are loc ntr-un proces iterativ, ncepnd cu aprecierile operaiilor elementare peste relaiile memorabile. 18.4.3. Aprecierile mult mai precise S trecem la analiza aprecierilor mai precise a costurilor execuiei planurilor adresrilor. Aceste adresri le putem diviza n dou clase. La utilizarea metodelor primei clase optmizatorul pstreaz o structur aspr, analogic structurii optimizatorului SystemR, dar luarea aprecierilor se bazeaz pe o informaie statistic mai precis, ce caracterizeaz rspndirea relaiilor.

Metodele clasei a doua sunt mai revoluionare i reiese din faptul c pentru formarea planurilor de execuie a adresrilor i a aprecierilor lor, optimizatorul trebuie s se satisfac cu o oarecare informaie, caracteristic pentru o sfer concret a adugrilor. La rezultatul metodei despre egalitatea rspndirilor valorilor cmpului relaiei trebuie de specificat rspndirea real a valorilor. Exist dou metode de baz a aprecierilor de rspndire a valorilor cmpului relaiei: parametric i bazat pe metoda signaturilor. Apropierea System R este un caz trivial particular a metodei parametrice de apreciere a rspndirii orice rspndire se aprecieaz ca fiind egal. ntr-o apreciere mai dezvoltat, s-a propus utilizarea seriei de rspndiri a lui Pirson pentru aprecierea rspndirii reale a valorilor cmpurilor relaiei, n care intr rspndirile de la egale la normale. Rspndirea se alege din serie pe calea calculului crorva parametri pe baz seciilor valorilor reale ntlnite. Exemple a implimentrii n practic a acestei apropieri nu ne sunt cunoscute. Metoda aprecierii rspndirii pe baza signaturilor poate fi descris n felul urmtor. Sfera vaorilor cmpuluise mparte n cteva intervale. Pentru fiecare interval printr-o metod oarecare se stabilete numrul de valori a cmpului, ce nimeresc n acest interval. n acest interval valorile se rspndesc dup o lege fixat( de regul se aplic apropierea egal). S analizm dou apropieri alternative, legate de descrierea signatural a rspndirilor. La apropierea tradiional, sfera valorilor cmpului se mparte n N intervaluri de mrimi egale i pentru fiecare interval se socoate numrul valorilor cmpurilor din cortejele relaiiei date, care nimeresc n interval. S presupunem c EMP este lrgit de nc un cmp AGE, care indic lista lucrtorului. Fie c de tot n organizaie lucreaz 60 de colaboratori n vrst de la 10 la 60 de ani. Atunci histograma ce reprezint rspndirea valorilor cmpului AGE poate avea tipul, artat mai jos n desen. Histograma e construit reeind din mprirea diapazonului valorilor cmpului AGE n 10 intervaluri. S analizm faptul cum putem aprecia selectivitatea predicatelor simple, indicate n cmpul AGE, utiliznd aa program. . fie c n intervalul de valori AGE Si nimeresc Ki valori. Atunci SEL(EMP.AGE=const), dac valoarea constantei nimerete n intervalul valorilor Si, poate fi apreciat n felul urmtor: 0<=SEL(EMP.AGE)<=Ki/T(t numarul total de corteje in relatia EMP). De aici rezult aprecierea medie a nivelului selectivitii prediactului Ki/(2(T). De exemplu, SEL(AGE=29) se apreciaz cu 40/200=0,2, iar SEL(AGE=16) se apreciaz cu 5/200=0,025. Acestea sunt aprecieri mai precise, dect cele ce se pot primi din propunerile despre egalitatea rspunsurilor. Dar nu aa de bine stau lucrurile cu aprecierile selectivitii a predicatelor simple cu neegaliti. De exemplu, fie c trebuie de apreciat nivelul selectivitii predicatului EMP.AGE<const. Dac valoarea constantei nimerete n intervalul Si i SUMi cantitatea sumar a valorilor AGE, ce nimeresc n intervalul S1, S2,, Si, atuncii SUMi-1/t<=SEL(AGE<const)<=SUMi/T. Atunci aprecierea medie a nivelului selectivitii (SUMi-1+SUMi)/(2(T) i eroarea aprecierii poate atinge jumtate din greutatea subsferei, n care nimerete valoarea constantei predicatului. Cel mai neplcut este faptul c eoarea aprecierii depinde de valoarea constantei i cu attmai mult, cu ct sunt mai multe valori a cmpului n intervalul dat a histigramei. De exemplu, SEL(AGE<29) se apreciaz ca 46/100<=SEL(AGE<29)<=86/100, de unde aprecierea nivelului selectivitii este (46+86)/200=0,66; eroarea aprecierii poate atinge 0,2. n acelai timp SEL(AGE<49) se apreciaz mai precis. Pentru nlturarea acestui neajuns a fost propus alt apropiere ctre descrierea rspndirilor valorilor cmpului relaiei. Ideea apropierii const n aceea c mulimea valorilor cmpului se mparte n intervaluri de dimensiuni diferite, pentru ca n fiecare interval(n afar de ultimul) s nimereasc un numr egal de valori a cmpului. Numrul intervalelor se alege n dependen de limitele memoriei i cu ct ele sunt mai mari, cu att aprecierile sunt mai clare. La mprirea sferei valorilor n 10 intervale harta pseudohistogramic a rspndirilor valorilor cmpului AGE e artat mai jos.

Sfera valorilor cmpului AGE a relaiei EMP e mprit n 10 intervale, n aa mod, c n fiecare interval nimeresc fix 10 valori a cmpului AGE. Intervalele au diferite dimensiuni. Valorile de hotar a intervalelor sunt artate deasupra limitelor verticale. n pseudohistogram se admit intervale, graniele de dreapta i de stnga a crora coincid, de exemplu intervalul (28;28). El s-a format din cauza prezenei n relaia EMP a unui numr mare(mai mare ca 10) de corteje cu valoarea AGE=28. La utilizarea pseudohistogramei erorile n aprecierea nivelului de selectivitate a predicatelor cu operaia, diferit de egalitae, scad. Mrimea erorii nu depinde de valoarea constantei i se micoreaz la mrirea numrului de intervale. Neajunsul metodei pseudohistogramice n comparaie cu histogramele const n aceea c este prezent necesitatea de sortare a relaiilor dup valorile cmpurilor pentru construirea pseudohistogramei de rspndire a valorilor cmpului dat. Este cunoscut apropierea , ce permite primirea pseudohistogramei fr necesitatea sortrii relaiei ntregi. Apropierea se bazeaz pe statistica lui Colmogorov, din care, atribuind-o la BD relaionale, rezult c din regul se alege exemplul din 1064 de corteje i b este poriunea cortejelor n exemplu cu valorile c<V, atunci cu ncrederea de 99% poriunea cortejelor, n toat relaia, cu valorile cmpului c<V se afl n intervalul [b-0,05;b+0,05]. La micorarea puterii exemplului ncrederea scade. SGBD n arhitectura Client-Server SGBD n arhitectura Client-Server Lecia 19. Arhitectura Client-Server ntrebuinnd ctre arhitectura bazelor de date Client-Server este interesant i actual n primul rnd de aceea, c asifgur rezolvarea simpl i ieftin a problemei accesului colectiv la bazele de date n reeaua local. ntr-o oarecare msur, sistemele BD, bazate pe arhitectura Client-Server, sunt apropierea ctre sistemele rspndite de BD, desigur o apropiere mai simplificat, dar care nu cere soluionarea setului de probleme a BD rspndite. 19.1. 19.1. Sistemele deschise

Sistemele deschise Rspndirea real a rihitecturii Client-Server a devenit posibil datorit dezvoltrii i a implimentrii largi n practic a concepiei sistemelor deschise. Deci vom ncepe de la o scurt introducere a sistemelor deschise. Scopul principal a apropierii de sistemele deschise este simplificarea complexitii sistemelor de calcul pe baza standartizrii internaionale i naionale a interfeelor hard i soft. Cauza principal a apariiei dezvoltrii concepiei sistemelor deschise este trecerea la folosirea reelelor computerizate locale i a celor probleme de complexare a resurselor aparato-programale, ce au fost create de aceast trecere. n legtur cu dezvoltarea grabnic a tehnologiilor comunicaiilor globale, sistemele deschise au atras o mai mare atenie i au o scar mai larg. Fraza cheie a sistemelor deschise, ndreptat spre utilizator, este independena de productorul concret. Orientndu-se spre producia companiilor, ce se menin de standartele sistemelor deschise, utilizatorul, ce procur orice produs al acestei companii, nu devine rob a ei. El poate continua creterea puterii sistemului su pe calea procurrii produselor a oricrei alte companii, care respect standartele. Aceasta se refer ct la mijloacele aparatale, att i la mijloacele programabile i nu este o declaraie fr explicaie. Posibilitatea real de independen de productor este controlat n condiiile noastre naionale. Baza practic a surselor sistem i program aplicate a sistemelor deschise este sistemul operaional standartizat. n prezent aa sistem este UNIX. Firmele productoare a diferitor variante OS UNIX n rezultatul lucrrilor ndelungate, au reuit s ajung la concluzia despre standartele bazate ale acestui sistem operaional. Acum, toate versiunile rspndite a OS UNIX, mai ales cele bazate pe interfee, sunt colaborabile n problema interfeelor, reprezentate programatorilor aplicai. Dup cum se pare, nectnd la faptul apariiei

sistemului ce tinde la standart WINDOWS NT, anume UNIX va rmne de baz pentru sistemele deschise. Tehnologiile i standartele sistemelor deschise asigur posibilitatea real i controlat de practic de elaborare a surselor de programe sistem i aplicate cu proprieti de mobilitate(portability) i de interoperabilitate(interoperability). Posibilitatea mobilitii indic simplitatea comparabil a posibilitii sistemului program n spectrul larg a surselor programaparatale, ce corespund standartelor. Interoperabilitatea nseamn simplificrile complexrii noilor sisteme program pe baza utilizrii componentelor gata cu interfee standarte. Utilizarea apropierii de sistemele deschise este convinabil i utilizatorilor i productorilor. n primul rnd, sistemele deschise asigur soluionarea real a problemei generaiilor de surse program i aparate. Productorii de aa surse nu se impun de a soluiona toate problemele din nou; ei pot continua complexarea sistemelor, utiliynd componentele existente. S menionm, c n acest timp apare un nivel nou de construcie. Toi productorii sunt datori s urmreasc, s asigure o sfer standart, dar sunt impui s ajung la o realizare a ie ct mai bun. Desigur, peste un timp, standartele existente vor ncepe s joace rolul de stopare a procesului i atunci va trebui reanalizarea lor. Un plus pentru utilizatori este faptul c ei pot schimba cu timpul componentele sistemului cu altele mai perfecte, astfel nepierznd eficacitatea lucrului sistemului. 19.2. 19.2. Clienii i serverele reelelor locale

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

19.2. 19.3.

Arhitectura de sistem ClientServer

Arhitectura de sistem ClientServer Este clar c n caz general, pentru ca programul aplicat, ce se execut n staia de lucru, s poat adresa sau cere serviciul de la careva server, se cere ca minimum un oarecare slav interfaional programal, ce menine aa tip de conluccrare(ar fi fost nreal de cerut ca programul aplicat s utilizeze direct primitivele nivelului de transport a reelei locale). Din aceasta i reiese prinicpiile arhitecturii de sistem ClientServer. Sistema se mparte n dou pri, ce se pot executa n diferite noduri a reelei partea clientului i a serverului. Programul aplicat sau utilizatorul final colaboreaz cu partea clientabil a sistemei, care n cel mai simplu caz, asigur interfaa asupra reelei. Partea clientabil a sistemei, n caz de necesitate, se adreseaz n reea ctre partea serverului. S accentum, c n sistemele dezvoltate, adresarea de reea ctre partea serverului poate s nu fie necesar, dac sistema ar putea ghici necesitile utilizatorului i n partea clientabil se gsesc date ce pot satisface adresarea sa urmtoare. Interfaa prii serverului este determinat i fixat. De aceea este posibil crearea noilor pri clientabile a sistemului existent. Problema de baz a sistemelor bazate pe arhitectura ClientServer, este aceea c n coresponden de concepia sistemelor deschise de la ele se cere mobilitatea n ct se poate o clas mai larg a hotrrilor programo-aparatice a sistemelor deschise. Dac UNIX s-ar limita la reelele locale orientate, n diferite sisteme se utilizeaz aparataje diferite i protocoale de legtur. ncercrile crerii sistemelor, ce ar menine toate protocoalele posibile duce la suprancrcarea lor cu detalii de reea n nrutirea funcionalitii. Un alt aspect mai complicat a acestei probleme este posibilitatea utilizrii diferitor cinfiguraii a datelor n diferite noduri a reelei neomogene locale. n diferite calculatoare pot exista adresri diferite, afiri a numerelor, codarea simbolurilor, .a. Aceasta este foarte important pentru serverele de nivel nalt: de telecomunicaii, de calcul, a bazelor de date. O soluionare comun a mobilitii sistemelor, bazate pe arhitectura ClientServer este bazarea pe pachetele programale, ce realizeaz protocoalele de chemare lichidat a procedurilor(RPC Remote Procedure Call). La utilizarrea acestor mijloace, adresarea ctre serverul din nodul lichidat arat ca un apel simplu a procedurii. Sursa APC, n care, n care se pstreaz informaia despre specificul aparatajului a reelei locale i a protocoalelor de reea, transfer apelul n consecutivitatea colaborrii de reea. Specificul sferei de reea i a protocoalelor este ascuns de programatorul aplicat. La apelul procedurii lichidate a programei RPC creeaz reformarea formatului datelor clientului n formate temporale independente mainal, i apoi sursele reformate n formate de date a serverului. La transferul parametrilor de rspuns au loc creeri analogice. Dac sistemul e realizat pe baza pachetului standart RPC ea poate fi uor transferat n alt sfer deschis. 19.4. 19.4. Serverele bazei de date

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

Accesul la BD de la programul aplicat sau de la utilizator are loc pe calea adresrii la partea clientului sistemei. n calitate de interfa de baz dintre partea serverului i cea a clientului este limbajul BD SQL. Acest limbaj reprezint standartul curent a interfeei SGBD n sisteme deschise. Denumirea SQL-Server se refer la toate serverele BD, bazate pe SQL. Respectnd atenia la programe, unele care au fost analizate la leciile trecute, pot fi create sisteme aplicate informaionale, mobile n clasa SQL-Server. Sferele bazelor de date, interfaa crora se bazeaz doar pe SQL au neajunsurile i plusurile sale. Plusul, desigur, este standartizarea interfeei. Prile clientabile a oricrui SQL a SGBD atentate ar putea lucra cu orice SQL-Server, independent de cine l-a produs. Neajunsul, deasemenea, este clar. La aa un nivel nalt interfeele dintre prile clientabile i cea a serverului, de partea clientului lucreaz foarte puine programe SGBD. Aceasta este normal dac n partea clientului lucreaz o staie slab. Dar dac calculatorul clientului are destul putere, atunci mai des apare dorina de a-i adresa mai multe funcii de dirijare cu BD, descrcnd serverul, care este locul ngust a ntregii sisteme. Una din direciile perspective a SGBD este configuraia modificabil a sistemului, fa de care rspndirea funciilor ntre prile de client i utilizator a SGBD se determin la instalarea sistemului. 19.4.2. Plusurile prtocoalelor a apelului lichidat a procedurilor protocoalele vzute mai sus a apelurilor lichidate a procedurilor sunt foarte importante n sistemele de dirijare cu BD, bazate pe arhitectura ClientServer. n primul rnd utilizarea mecanismului procedurilor lichidate permite ntr-adevr de a rempri funciile ntre prile clientului i a serverului sistemului, cci n textul programului de lichidare, apelul procedurii nu se deosebete cu nimic de apelul lichidat, i deci, teoretic orice component a sistemului se poate afla i de partea serverului i de partea clientului. n al doilea rnd, mecanismul apelului lichidat ascundedeosebirile dintre interaciunile calculaoarelor. Reeaua local fizic neomogen a calculatoarelor se aduce la reeaua logic omogen a calculatoarelor interacionabile programabil. n rezultat, utilizatorii nu trebuie s se ngrijoreze de cumpararea unic a staiilor de lucru i a serverelor mpreun. 19.4.3. mprirea funciilor ntre client i server n cazul tipic pentru zilele noastre, din partea clientului SGBD lucreaz numai o aa asigurare a programului, ce nu are acces direct la BD, dar se adreseaz pentru aceasta ctre server, utiliznd limbajul SQL. n unele cazuri ar fi de dorit includerea n partea clientabil a sistemei unei fincii de lucru cu cacheul local a BD, adic cu acea parte a ei, ce este utilizat intens de programul aplicat a clientului. n tehnologia actual aceasta poate fi fcut doar pe calea creerii formale de partea clientului a copiei locale a serverului BD i cercetrii sistemului ca un set de servere interacionabile. Din alt parte, cte o dat s-ar dori de transportat marea parte a sistemului aplicat n partea serverului, adic diferena dintre puterile staiilor de lucru a clienilor i serverelor este foarte mare. n general, la utilizarea RPC, aceasta este uor de fcut. Dar e nevoie ca asigurarea de baz programal a serverului ntr-adevr ar permite aceasta. La utilizarea OS UNIX, practic nu apar probleme. 19.4.4. Cerinele ctre posibilitile aparatelor i ctre asigurarea programal de baz a clienilor i serverior din discuiile de mai sus se vede c cerinele ctre aparataj i asigurarea programal a calculatoarelor serverelor i celor a clienilor se deosebesc de tipul utilizrii sistemului. Dac mprirea dintre client i server este destul de aspr(ca n majoritatea SGBD actuale), atunci utilizatorilor ce lucreaz n staiile de lucru sau cu calculatoarele personale, le este totuna

care aparataj sau sistem operaional lucreaz pe server, de s-ar isprvi el cu torentul adresrilor ce apare. Dar dac pot aprea necesitile de remprire a funciilor dintre client i server, atunci nui la fel, care operaie a sistemei se utilizeaz. Baze de date mprite Baze de date mprite Lecia 20. BD mprite Condiia de baz a sistemelor de dirijare cu BD mprite const n asigurarea surselor de integrare a bazelor de date locale, ce se afl n unele noduri a reelei de calcul, cu aceea, c utilizatorul ce lucreaz n orice nod a reelei s aib acces la toate aceste BD ca la o singur BD. Cu toate acestea trebuie s fie asigurate: - Simplitatea utilizrii sistemului; - Posibilitile funcionrii autonome la nclcarea legturii reelei sau la necesiti administraionale; - Nivelul nalt de eficacitate. 20.1. 20.1. Multiplicitatea felurilor sistemei mprite

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

Sistemul mprit de gestiune cu BD System R* Scopul de baz a proiectului poate fi apreciat n felul urmtor: de asigurat sursele de integrare a BD locale System R*, ce se afl n nodurile reelei de calcul, cu scopul, ca utilizatorul, ce lucreaz n orice nod a reelei, s aib acces la toate aceste BD, ca i cum ele ar fi centralizate. n acest timp trebuie s fie asigurate: - simplitatea utilizrii sistemului; - posibilitile funcionrii autonome la nclcarea legturii reelei sau la necesiti administrative; - nivelul nalt de eficacitate. Pentru soluionarea acestor probleme era nevoie de primit un ir de soluii, legate de decompoziia adresrii iniiale, selecii optimale a mijlocului de execuie a adresrii, execuia permis a trenzaciei, asigurarea sincronizrii, restabilirea strii BD dup diferite tipuri de neregulri n nodurile reelei. Simplitatea utilizrii sistemului se atinge datorit faptului c utilizatorii System R*(productorii programelor aplicate i utilizatorii finali) rmn n sfera limbajului SQL, adic pot s prelungeasc lucrul n aceleai condiii externe ca i n System R(i SQL/DS i BD2). Posibilitatea utiliyrii SQL se bayeay pe locul de aflare curent a obiectelor, apelate n adresare de

ctre utiliyator, de date, unul i acelai program aplicat, ce include cuvntul SQL, poate fi executat n noduri diferite a reelei. n fiecare nod a reelei, la etapa compilrii adresrii, se alege planul optimal de execuie a adrersrii n dependen de aflarea datelor n sistemul mprit. Asigurarea autonomiei nodurilor reelei n System R* i se d o mare atenie. Fiecare BD local se administreaz independent de altele. Este posibil conectarea autonom a utilizrii noi, schimbul versiei prii autonome a sistemului, .a. Sistemul e proiectat n aa mod, ca n el nu este nevoie de slujbele de enumerare a obiectelor centralizate. n nodurile individuale nu e nevoie de prezena cunotinelor globale despre operaii ce se execut n alte noduri a reelei, lucrul cu BD accesibile poate s se continuie la ieirea din funciune a nodurilor aparte a reelelor sau a liniilor de legtur. Nivelul nalt de eficacitate a sistemului este una dintre cele mai importante cerine dintre sistemele mprite de gestiune cu BD n general i ctre System R* n particular. Pentru atingerea aceastui scop se utilizeaz dou msuri de baz. n primul rnd, ca i n System R, n System R* nainte de execuia adresrii se face compilarea ei. n mersul acestui proces are loc cutarea numelor, utilizate n adresare, a obiectelor BD n registrul mprit i schimbul numelor cu identificatori interni; controlul drepturilor accesului utilizatorului din numele cruiea se face compilarea pentru execuia operaiilor corespunztoare pe BD i alegerea planului de execuie a adresrii celui mai optimal global, care se va supune decompoziiei i se trimite pe pri n nodurile corspunztoare a reelei, unde are loc selecia planurilor de execuie a componentelor adresrii celui mai optimal local i are l,oc generarea modulelor de acces n codurile mainii. n rezultat, o mulime de aciuni are loc la stadiul compilrii pn la execuia real a adresrii. Programul aplicat, prelucrat dup mijloacele precompilatorului System R*, ce include propoziii SQL, poate fi executat de mai multe ori, fr cheltuieli adugtoare. Utilizarea catalogului mprit, compilaia mprit i optmimizarea adresrilor sunt aspectele cele mai interesante i mai originale a proiectului System R*. A doua metod de ridicare a eficacitii sistemului este de a transporta relaiile lichidate n baza de date local. Dialectul SQL, utilizat n System R*, include propoziia MIGRATE TABLE, la execuia creiea relaia artat se transfer n BD local. Acest mijloc, ce se gsete n minele utilizatorului desigur poate ajuta la primirea unor treceri mai eficative a tranzaciilor. Desigur, ca pentru toate operaiile, operaia MIGRATE n dependen de relaia accentuat de acces nu oricrui utilizator, dar numai celora ce au permisiunea corespunztoare. Pn a trece la o reluare mai detaliat a celor mai interesante aspecte a realizrii System R*, s amintim careva surse, pe care productorii acestei sisteme i le-au propus spre realizare n stadiul nceptor a proiectului, dar care nu au fost realizate(careva din ele nu vor fi realizate nici o dat). Se propunea de a prezenta n sistem a surselor de mprire orizomtal i vertical a relaiilor BD mprie, surse de dublare a relaiilor n cteva moduri cu susinerea acordului copiilor i surse de meninere a pozelor momentane a strii BD n dependen de adresarea dat. Pentru adresarea mpririi orizontale a relaiilor n SQL a fost introdus construcia de tipul DETRIBUTED TABLE <table-name>HORIZONTALLEY INTO <name> WHERE <predicate> IN SEGMENT <segment-name-site> . . . <name> WHERE <predicate> IN SEGMENT <segment-name-site> La execuia propoziiei de aa tip, relaia dat se mprea ntr-un rnd de subrelaii, ce conin corteje, ce satisfac predicatuluiu corespunztor din despritura WHERE i fiecare subrelaie primitor n aa fel trimitea n nodul specificat pentru pstrarea n segmentul cu numele dat. Se garanteaz starea acordat a despriturilor la calculul relaiei. mprirea vertical avea cu ajutorul operatorului <name> WHERE <column-name-list> IN SEGMENT <segment-name-cite> . .

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

n primul rnd acordarea i copiile aduce cheltuieli la execuia operaiilor de modificare a relaiilor memorabile. Pentru aceasta este nevoie de crearea i respectarea protocoalelor de modificare speciale. n al doilea rnd, introducerea relaiilor copiate se face nu att pentru mrirea eficacitii sistemului, ct pentru mrirea accesibilitii datelor la nclcarea legturilor relaiilor. n sistemele, n care se aplic aceast apropiere, la nclcarea legturilor reelei lucrul cu BD mprit, de obicei, se prelungete numai n una din relaiile formate. n acest timp pentru alegerea subreelei se utilizeaz algoritmii de vot; hotrrea se adopt pe baza drii de seam a numrului nodurilor de legtur a reelei. Se aplic i alte apropieri, dar toate ele sunt foarte scumpe, iar cel mai principal, ele ru se voteaz cu apropierea de baz System R* cu condiia seleciei metodei de execuie a adresrii la stadiul compilrii ei. De aceea dup cum ni se pare, n System R* nici o dat nu vor fi realizate surse, ce ar permite printr-un mijloc sau altul, s menin copiile relaiilor n cteva noduri a reelei. n continuare vom analiza aspectele proiectului System R*, care i-au gsit reflexia n realizarea sa i care sunt mai interesante: sursele de enumerare a obiectelor i organizarea registrului mprit a BD; apropierea de compilrile mprite i execuiile adresrilor; deosebirile utilizrii configuraiilor; sursele de sincrinizare. 20.2.1. Enumerarea obiectelor i organizarea registrului mprit S amintim, c numele ntreg a relaiei(de baz sau configuraiei) n BD System R are tipul numele-utilizatorului.numele-relaiei, unde numele-utiizatorului identific utilizatorul-creatorul relaiei, iar numele-relaiei este numele, ce a fost specificat n propoziiile CREATE TABLE sau CREATE VIEW. n adresri putem specifica sau acest nume plin, sau numele local. n al doilea caz, la compilare se utilizeaz regulile standarte de adugare a numelui local pn la plin cu utilizarea n calitate de component numele-utilizatorului a identificatorului utilizatorului, de la numele cruia se face compilare. n System R* se utilizeaz dezvoltarea acestei apropieri. Numele de sistem a relaiei include 4 componente: identificatorul utilizatorului-creatorul relaiei, identificatorul nodului reelei, n care s-a efectuat operaiunea de creare a relaiei; numele local a relaiei, care i s-a dat la creare: identificatorul nodului, n care relaia se gsea dup crearea sa(s amintim c relaia poate s se mute dintr-un nod n altul la execuia operaiei MIGRATE). n adresarea pe SQL putem utiliza numele de sistem a obiectelor, dar se permite i utilizarea numelor scurte locale(sau numelelocal, calificat ca numele utilizatorului). Cu toate acestea sunt posibile dou interpretri a numelui local. El poate s fie interpretat ca o parte a numelui de sistem i n acest caz se adaug n descretere pn la simetric, reeind din identificatorul nodului, n care are loc compilarea i a identificatorilor utilizatorilor de la numele crora ea are loc(dac numele utilizatorului nu-i specificat clar). A doua interpretare posibil a numelui local const n prelucrarea lui ca nume determinat mai devreme a sinonimului numelui de sistem Pentru determinarea sinonimelor, SQL e lrgit de operatorul de tipul DEFINE SYNONYM <relation name> AS <system wide name> La execuia a aa propoziie n catalogul local se nscrie informaia odat. n aa mod, la compilarea adresrii, n totdeauna putem determina numele de sistem a tuturor relaiilor utilizate n el: sau ele sunt specificate clar, sau pot fi primite pe baza informaiei din relaiile locale a registrelor. Concepia registrului mprit System R* e bazat pe prezena la fiecare obiect a BD mprite a numelui unical de sistem. S-a luat urmtoarea decizie: informaia despre locul aflrii oricrui obiect a BD(identificatorul nodului curent, n care se afl obiectul) se pstreaz n registrul local a acelui nod, n care obiectul se afl ndat dup creare(nodului de natere). Deci pentru primirea informaiei ntregi despre relaie trebuie nti s ne folosim de registrul local a nodului, n care are loc compilarea, apoi s ne adresm la registrul lichidat a nodului de natere a relaiei date i n sfrit s utilizm registrul nodului curent. n aa fel, pentru

primirea informaiei de sistem precise, despre oarecare relaie a bazei de date mprite, poate s apar necesitatea utilizrii a cel mult dou accese lichidate ctre relaiileregistre. Se utilizeaz o optimizare a acestei proceduri. n registrul local a nodului se pot pstra copiile elementelor registrului altor noduri(ca un fel de c-registru). Acordarea copiilor elementelor registrului nu se menine. Aceast informaie se utilizeaz n prima stadie de compilare a adresrii, iar apoi n a doua stadie, dac informaia, referitoare la un obiect anume, este imprecis, ea se va preciza pe baza registrului local a acelui nod, n care obiectul se pstreaz acum. Definirea incorectitudinii copiei elementului registrului a numrului versiei. Dac vom ine cont de ineria informaiei n sistem, aceast optimizare a r putea fi important. 20.2.2. Compilarea mprit a adresrilor Dup cum am menionat, adresrile n limbajul SQL pn la execuia sa real se impun compilrii. Ca i n cazul System R, compilarea adresrii poate avea loc n stadiul precompilrii programului aplicat, scris n limbajul tradiional de programare(PL/1, Cobol, Assembler) cu includerea aplicaiilor SQL sau n dinamica execuiei tranzaciei la execuia propoziiei PREPARE. Din punct de vedere a utilizatorilor, procesul compilrii n System R*, aduce la aceleai rezultate ca i n System R: pentru fiecare propoziie SQL se creeaz programul n codurile mainii(selecia modului de acces, apelurile creia ncap n textul programului aplicat iniial. ns, n realitate, procesul de compilare a adresrii n system R* este cu mult mai complicat ca n System R, ceea ce este real din cauza interaciunilor de reea mai complicate, de care va fi nevoie la execuia real a tranzaciei. Compilarea mprit a adresrilor n System R* include o mulime de rafiniti tehnice. S analizm schema general a compilrii mprite. Vom numi nod principal, acel nod, n care este iniializat procesul compilrii a propoziiei SQL i noduri adugtoare acxele noduri, ce se includ n acest proces n mersul execuiei lui. n cel mai grav nivel, procesul compilrii se mparte n fazele urmtoare: n nodul acceptat are loc mprirea gramatic a propoziiei SQL cu construcia configuraiei interne a adresrii n form de arbore. Pe baza informaiei din registrul local a nodului principal i din registrele lichidate a nodurilor adugtoare, are loc schimbul numelor obiectelor, ce figureaz n adresarea ctre identificatorii lor de sistem. n nodul numit se genereaz planul global de execuie a adresrii n care se specific doar ordinea interaciunilor nodurilor la execuia real a adresrii. Pn la crearea planului global se utilizeaz lrgirea tehnicii optimizrii, , artat n System R. Planul global se reflect n arborele adresrilor recreat n felul corespunztor. Dac n planul global a aexecuiei adresriiiau parte nodurile adugtoare, are loc decompilarea lui pe pri, fiecare dintre care se poate de ndeplinit ntr-un nod. Prile corespunztoare a adresrii se trimit n nodurile adugtoare. n fiecare nod, ce face parte din planul global de execuie a adresrii, se execut stadiul final de execuie a compilaiei. Acest stadiu include ultimile dou faze a procesului de compilare a adresrilor n System R: optimizarea i generarea codurilor mainale. Se efectuieaz controlul drepturilor utilizatorului, de la numele cruiea are loc compilarea, pentru execuia lucrului corespunztor; are loc prelucrarea configuraiilor BD; are loc optimizarea lexical a prii prelucrate a adresrii n dependen de indexii avui; are loc generarea codului. 20.2.3. Dirijarea cu tranzaciile i sincronizarea Efectuarea tranzaciei n sistemul mprit de dirijare cu BD a System R* este rspndit. Tranzacia ncepe n nodul pricipal la adresarea ctre careva secie(la etapa compilrii) a modulului de acces pregtit mai devreme. Aceste apeluri se interpreteaz n stilul apelurilor procedurilor lichidate. Deci execuia unei tranzacii, iniiat ntr-un oarecare nod a reelei A, induce iniierea tranzaciilor n nodurile adugtoare. O problem important, nou n comparaie cu System R, este problema finisrii acordate a tranzaciei mprite, pentru ca rezultatele execuiei sale, n toate nodurile atinse de ea, s fie reflectate sau n starea BD locale, sau s fie complet absente.

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