Limbajul bazelor de date relaionale SQL

Limbajul bazelor de date relaionale SQL Lecia 13. Limbajul SQL. Funciile i posibilitile de baz. 13.1. SEQUEL/SQL SGBD System R

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

S analizm posibilitile acestui limbaj un pic mai amnunit. 13.1.1. Adresrile i operatorii de manipulare cu datele

Dup cte tim, dou limbaje de baz de adresare ctre BD relaionale sunt limbajul algebrei relaionale i a calculului relaional. Cu toat stricteea i statornicia sa teoretic aceste limbaje se utilizeaz rar n SGBD relaionale moderne, n calitate de mijloace a interfeei utilizatorului. Adresrile n aceste limbaje snt greu de formulat i de neles. SQL reprezint o combinaie oarecare a calculului relaional combinaional a cortejelor i a algebrei relaionale, n afar de aceasta nc nu este clar cror din cele clasice acest limbaj este mai apropiat. Cu toate acestea limbajul SQL are posibiliti mai largi, ca limbajele relaionale de baz, de exemplu, n caz general este imposibil translarea adresei, formulat n SQL, ntr-un cuvnt a algebrei relaionale, este nevoie de o oarecare lrgire. Proprietile de baz a sublimbajului de adresri SQL sunt posibiliti de a formula uor adresrile cu legtura ctorva relaii i subadreselor depuse n predicatele alegerii. Deci posedarea concomitent a ambelor mijloace este extensiv, dar acest fapt d posibilitatea utilizatorului, n timpul formulrii adresrii, de a alege varianta cea mai clar neleas.

n predicatele cu subadresrile depuse n SQL System R este posibil de a utiliza teoretic o mulime de operatori de comparaie, ceea ce permite de a formula adresri cuantificate(ceea ce de obicei, cel mai greu este neles de utilizatori, de aceea n SQL au aprut predicate cuantificabile).

O deosebire principal a limbajului SQL este posibilitatea prezenta n adresare necesitatea gruprii apartenenei-rezultatului pe cmpurile determinate, cu ajutorul condiiilor de selectare a ntregii grupe. Aa fel de condiii de selectare pot conine funcii de agregat, calculate pe grup. Aceast posibilitate a SQL n mod principal deosebete acest limbaj de limbajele algebrei relaionale i a calculului relaional, care nu conine surse analogice.

O alt deosebire a limbajului SQL nu este tergerea neaprat a cortejelor-dublicate n relaii rezultatele finale sau intermediare. Altfel spus, rezultatul operatorului tergerii n limbajul SQL este mulimea cortejelor i nu a relaiilor. n cazurile cnd semantica adresrilor cere prezena relaiei, distrugerea predicatelor are loc neclar.

Cel mai general tip de adresare n limbajul SQL este expresia algebric alctuit din

adresri elementare. n SQL System R erau admise toate operaiile de baz(UNION, INTERSECT i MINUS).

Lucrul cu expresiile nedeterminate n SQL System R nu a fost gndit pn la urm, cu toate c se presupunea utilizarea logicii cu trei simboluri, n cazul determinrii expresiilor logice.

Operatorii de manipulare cu datele UPDATE i DELETE sunt construite pe baza acelorai principii ca i operatorul de selecie a datelor SELECT. Colectarea cortejurilor relaiei date, care aparin modificrii sau tergerii, se determin cu ajutorul expresiei logice care face parte din operatorul dat i care poate conine predicate compuse i de asemenea cu subadresri depuse.

n operatorul de includere a cortejurilor n relaia dat, cortejul ce se va include poate fi definit att n form literar, ct i cu ajutorul suboperatorului interior de selecie. 13.1.2. Operatori de manipulare i determinare a schemei BD

Din componena operatorilor de determinare a schemei BD SQL System R fceau parte operatorii de creare i distrugere a relaiilor pstrate permanent i temporar(CREATE TABLE i DROP TABLE) i crearea i distrugerea relaiilor afiabile(CREATE VIEW i DROP VIEW). n limbaj i n realizarea System R nu se interzicea utilizarea operatorilor de utilizare a schemei n limitele tranzaciei, care conine operatorii de selecie i de manipulare cu datele. Se permitea, de exemplu, utilizarea operatorilor de selecie i de manipulare cu datele, n care se accentuieaz relaia neexistent n baza de date n timpul compilrii operatorului. Desigur, aceast posibilitate ngreuna considerabil realizarea i n fond i utilizarea foarte rar.

Operatorul de manipulare cu schema BD ALTER TABLE avea posibilitatea de a aduga cmpurile selectate la relaie existent. n descierea limbajului se determina, c execuia acestui operator nu trebuie s aduc la faptul c compilarea operatorilor asupra relaiei s nu fie adevrat, relaie schema creia se schimb i c sensul cmpurilor din nou determinate n cortejele existente a relaiei devin nedeterminate. 13.1.3. Determinarea limitelor integritii i a trigherelor

Limbajul SQL System R includea surse foarte puternice de control i meninere a integritii BD. Sursele de control se bazau pe aparatul de limite a integritii(ASSERTIONS). Dup ideie, limita integritii este expresia logic, determinat pe starea actual a BD, neadevrul creia corespunde cu starea neintegr a BD. Expresia logic a limitei integritii poate conine orice predicat admisibil n limbaj.

Mai precis, limitele integritii se mpart n dou clase: controlabile n urma executrii operatorului de manipulare cu datele i controlabile la sfritul tranzaciei sau la executarea operatorului special INFORCE INTEGRITY. Tipurile predicatelor ce pot fi utilizate n n operatorii de determinare a limitelor integritii de clase diferite, difer. n operaiile din prima clas se controleaz cortejul actual, cu care are loc manipularea. n cazul doi se controleaz relaiile accentuate n limitele integritii, adic toate cortejele lor. Se deosebete i reacia determinat n limbaj, reacia sistemului la nclcarea limitelor integritii diferitor clase. n primul caz nclcarea limitelor integritii aduce la napoierea tranzaciei n punctul care e neaprat premrgtor operaiilor de manipulare cu datele, ndeplinirea cruia a dus la nclcarea limitei integritii. n cazul doi se efecuieaz napoierea tranzaciei pn la nceputul ei. Un mecanism important determinat n SQL System R este mecanismul trigherilor. n contextul System R acest mecanism era privit n mod principal ca surs de meninere automat a integritii BD. La determinarea trigherului se spunea de condiia de control a utilizrii trigherului(numele relaiei i tipul operaiei de manipulare cu datele). Condiia de utilizare a trigherului(expresia logic, construit construit dup regulile apropiate de regulilepentru limitele integritii primei clase) i funcia, cre trebuie s fie ndeplinit asupra bazei de date n caz c condiiile aplicaiei sunt adevrate. Aa funcie putea fi exprimat cu ajurtorul

operatorului de sine stttor de manipulare cu date. n timpul execuiei funciei puteau s nceap i alte trighere, .a.

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

n limbaj se permitea utilizarea relaiilor memorabile i a relaiilor dispuse a BD. Varianta cea mai bun era utilizarea operatorilor de selecie pentru determinarea cionfiguraiei sau afirii nfirii aparatului comun. Orice operator de selecie poate fi utilizat pentru determinarea configuraiei.

n limbaj lipsesc oarecare limite n introducerea utilizrii configuraiilor: n orice operator SQL n care se permite utilizarea numelui relaiei memorabile, se permite i utilizarea numelui configuraiei a tabloului. n SQL System R nu se vorbete nimic despre metoda recomandabil de realizare a accesului ctre tablouri, dar n orice metod efectul trebuie s fie n aa mod, ca cnd s-ar fi realizat materializarea total a tabloului pn la execuia operatorului.

Un ir de probleme, cercetri i propuneri a nscut posibilitatea potenial de execuie a operatorilor de manipulare cu datele asupra tablourilor. Este clar c aceast posibilitate este uor de realizat pentru tablourile simple, dar n cazurile mult mai complicate, nu numai realizarea, dar i semantica operaiilor devine netrivial. Apropo, n System R operatorii de manipulare cu datele, se admiteau numai asupra tablourilor simple. 13.1.5. Determinarea strucurilor de comand

Introducerea n limbajul relaional, precum este SQL, operaiile de creare i tergere a nivelului fizic, care menin efecuarea efectiv a adresrilor ctre BD, a aprut n SQL System R ca o rezolvare pragmatic, care asigura posibilitatea tuturor tipurilor de lucru cu BD cu ajutorul unui singur limbaj.

n SQL System R se vorbete despre dou tipuri de aa structuri: indexurile i legturile(links).

Indexul, n nchipuirea lingvistic, abstract a sa este un fiier invertit, care asigur accesul ctre cortejurile relaiei corespunztoare, pe baza sensului dat de una sau mai multe coloane, care reprezint cheiea indexului. Operatorii limbajului permiteau de a crea i a distruge indexii, dar n nici un caz nu permiteau de a arta necesitatea utilizrii indexului existent n cazul execuiei operatorului de selecie, hotrrea despre aceasta se apela la realizare.

Cu ajutorul operatorului de determinare a indexului era posibil de a exprima dou afirmaii adugtoare referitor la schema logic a relaiei i la structura fizic a pstrrii sale. La determinarea indexului, utilizarea cuvntului cheie UNIQUE nseamn c cheiea acestui index este cheiea posibil a relaiei corespunztoare. n fond aceasta demonstreaz existena mecanismului adugtor de determinare a limitelor integritii relaiei. Unul din indexii relaiei date putea fi determinat cu ajutorul cuvntului cheie CLUSTERING. Aceasta arat necesitatea clasterizrii fizice n memoria extern a cortejurilor relaiei cu sensuri apropiate sau egale cu cele ale indexului.

Operatorii de determinare a legturii, permiteau, n stilul modelului de reea a datelor, organizarea n memoria extern a listelor cortejurilor relaiei date. Ca i n cazul indexilor, operatorii permiteau de a crea i de a distruge aa liste, dar nu includeau posibilitatea de a arta

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

O deosebire de baz a limbajului SQL, care a aprut n el de la bun nceput este ndestularea proteciei accesului la date de ctre sursele limbajului. Ideiea principal a acestui pas const n faptul c, pentru atrnarea fa de orice relaie a BD i fa de orice coloan a relaiei se introduce un set definit de privilegii. Cu fiecare tranzacie se face indirect legtura cu identificatorul utilizatorului, de la numele cruiea ea se ndeplinete(metodele de legtur i de identificare a utilizatorilor nu se fixeaz n limbaj i se determin de realizare).

Dup crearea relaiei noi toate privilegiile legate de aceast relaie i de toate coloanele sale, aparin doar utilizatorului creator al acestei relaii. n componena privilegiilor intr i privilegia de a transmite toate sau o parte din privilegii altui utilizator, inclusiv i privelegia de a transmite privilegii. n mod tehnic transmiterea privilegiilor are loc la ndeplinirea operatorilor SQL GRANT. Exist i privilegia de a extrage o parte sau toate privilegiile de la un utilizator, caruiea acestea i-au fost transmise mai devreme. Aceast privilegie de asemenea poate fi transmis. n mod tehnic extragerea privilegiilor poate fi nfptuit la aplicarea operatorului SQL REVOKE.

Controlul mputernicirii accesului la date are loc pe baza informaiei despre mputernicirile existente n timpul compilrii operatorului SQL corespunztor. Asemntor cu ceea ce am spus despre limitele integritii i trighere, n SQL System R lipseau careva limite n legtur cu utilizarea operatorilor GRANT i REVOKE. Acest fapt aducea la dificulti tehnice impuntoare n realizare, dar cte o dat i la o nelegere nesimilar a comportrii.

Un timp ndelungat pasul spre protecia datelor de la accesele nesancionate era nfptuit practic fr critic, ns n legtur cu utilizarea rspndit a SGBD relaionale n adugrile netradiionale, tot mai des apare critica. Dac, de exemplu, n sistema BD trebuie s se menin o protecie a mai multor nivele de date, aa sistem de mputerniciri corespunztoare este foarte greu, dar cte o date e i imposibil de a construi pe baza surselor SQL. 13.1.7. Punctele de salvare, memorare i napoierea tranzaciilor

n SQL System R au existat doi operatori speciali pentru implimentarea aa numitelor puncte de salvare, memorare a tranzaciilor i de napoiere a tranzaciilor spre punctul de salvare implimentat mai devreme. n literatura referitoare la System R cercetarea acestor posibiliti practic nu se gsete, de unde rezult c ele nu au fost realizate.

Realizarea liniar a acestor posibiliti nu duce la careva dificultitehnice, dar i nu-i chiar de folos, deoarece dup execuia parial a napoierii tranzaciei pentru prelungirea cu succes a lucrului programului adugtor, ar fi fost nevoie i de restabilirea strii lui n punctul corespunztor, ceea ce nicidecum nu se menine. Este clar c, n cazul unei analize mai amnunite trebuie s fie legate mecanismele punctelor de salvare i control a integritii. De exemplu ar fi natural ca n timpul execuiei operatorului ENFORCE INTEGRITY, dac careva limite a integritii se ncalc, s-ar produce napoierea automat a tranzaciilor ctre punctul de salvare cel mai apropiat, n care nclcarea integritii BD nu s-a depistat. Acest fapt ar fi ngrelat realizarea, dar ar fi de folos.

Analog s-ar fi putut de utilizat mecanismul punctelor de salvare n cazul napoierii automate a tranzaciilor din cauza apariiei impasurilor sincronizate.

S accentum nc dou proprieti principale a limbajului SQL System R, care n modaliti diferite sunt prezente n toate variantele dezvoltate, postmergtoare ale limbajului.

13.1.8. SQL implantat

n SQL System R sunt prezeni operatori speciali, care menin implantarea operaiilor SQL n limbajele tradiionale de programare(n System R un aa limbaj era PL/1).

Problema fundamental de implementare a lui SQL n limbaj de programare const n faptul c SQL este un limbaj relaional, adic operatorii lui n cea mai mare parte lucreaz cu mulimile, n timp ce n limbajul de programare, operaiile scalare sunt de baz. Hotrrea lui SQL const n faptul c n limbaj se includ adugtor operatorii, care vor permite accesul pe corteje a rezultatului adresrii la BD.

Pentru aceasta n limbaj se introduc sensul de cursor, cu care se leag operatorul de selecie. Asupra unui cursor dat se poate efectua operatorul OPEN, care indic materializarea relaiei rezultatul adresrii, operatorul FETCH, care permite alegerea sfritului de lucru cu cursorul dat.

La realizarea unor programe adugtoare, cu SQL implantat, o elasticitate adugtoare este dat de posibilitatea de parametrizare a operatorilor SQL cu sensul variabilelor programului de conectare. 13.1.9. SQL dinamic

Pentru simplificarea cererii SQL interactiv sistemelor orientate n SQL System R au fost inclui operatorii, care permit n timpul efecturii tranzaciei, compilarea i efectuarea oricrui operator SQL.

Operatorul PREPARE induce compilarea dinamic a operatorului SQL, textul cruia se conine n rndul simbolic schimbtor al programului de conectare.

Operatorul DESCRIBE slujete pentru primirea informaiei despre operatorul SQL dat, pregtit mai nainte de operatorul PREPARE. Cu ajutorul acestui operator, putem afla mai nti, este operatorul pregtit un operator de selecie i n al doilea rnd dac acesta e operator de selecie, de primit informaia ntreag despre numrul i tipurile coloanelor relaiei rezultante.

Pentru ndeplinirea operatorului SQL pregtit mai devreme, care nu este un operator de selecie, este operatorul EXECUTE. Pentru ndeplinirea operatorului de selecie pregtit dinamic, se utilizeaz aparatul de cursoare cu careva deosebiri n ceea ce privete exercitarea adreselor variabilelor programului de conectare, n care trebuie s fie incluse sensul coloanelor cortejului rezultant actual.

Concluzionnd aceast scurt descriere a calitilor de baz a SQL System R, s accentum, c nectnd la pregtirea tehnic nesatisfctoare, dup ideie limbajul coninea toate mijloacele necesare, care permiteau utilizarea lui ca limbaj de baz a SGBD. 13.2. Limbajul SQL n realizri comerciale 13.2. Limbajul SQL n realizri comerciale

n timpul actual SQL e realizat practic n toate SGBD relaionale comerciale, toate firmele i proclam corespunderea realizrilor sale la standartul SQL, i ntr-adevr dialectele realizate sunt apropiate. Aceasta a avut loc nu deodat i nu uor.

Cele mai apropiate de System R erau dou sisteme ale firmei IBM SQL/DS i DB2. dup cum se pare(demonstrri documentale la aceasta autorul nu are) ambele aceste sisteme utilizau direct realizarea System R. De unde i apropierea limitat a dialectelor realizate SQL i SQL System R. Din SQL SystemR au fost excluse doar acele pri, care nu erau ndeajuns prelucrate( de exemplu punctele de salvare) sau reaalizarea crora ducea la dificulti foarte mari(de exemplu limitele integritii i trigherele). Putem numi aceast cale spre realizarea comercial a SQL micare de sus n jos.

O alt apropiere se utiliza n aa sisteme ca Oracle i Informix. Nectnd la deosebirile n

metodele de realizare a acestor sisteme, realizarea SQL avea loc de jos n sus. n primele realizri SQL ieite pe pia, n aceste sisteme se utilizeaz numrul minimal i foarte limitat a submulimilor SQL System R. n parte, n prima realizare cunoscut autorului a SQL SGBD Oracle n operatorii de selecie nu se admitea utilizarea subntrebrilor implimentate.

Cu toate acestea, nectnd la aceste limite i la eficacitatea slab n primele stadii, orientarea firmelor la meninerea diferitor platforme de aparate i de cointeresarea utilizatorilor n trecerea la sistemele relaionale a permis firmelor s dobndeasc succes comercial spre perfecionarea realizrilor sale. n versiunile actuale Oracle i Informix se menin dialecte SQL destul de puternice, cu toate c realizarea cte o dat induce ndoieli.

O deosebire a majoritii SGBD comerciale actuale, care ngreuneaz analiza dialectelor existente SQL, este aparena descrierii ntregi a limbajului. De obicei descrierea este mprtiat pe diferite manuale i este amesticat cu descrierea limbajelor surs, specifice pentru sistema dat, care nu au legtur cu SQL. Dar putem spune c, colecia de baz a operatorilor SQL, incluznd operatorii de determinare a schemei BD, de selecie i de manipulare cu datele autorizaiei accesului la date, meninerea implantrii SQL n limbajele de programare i operatorii SQL dinamic, n realizrile comerciale s-a meninut i mai mult sau mai puin corespunde standartului. 13.3. Standartizarea SQL 13.3. Standartizarea SQL

Lucrrile pentru standartizarea limbajului SQL au nceput practic concomitent cu apariia primelor realizri comerciale ale lui. Primul din volumul de documente, ce aparineau autorului, dateaz cu luna octombrie a anului 1985 i este de acuma un alt proiect al standartului ANSI/ISO.

Este clar c n calitate de standart se putea utiliza SQL System R. n primul rnd aceast variant a limbajului nu era prelucrat tehnic n momentul cuvenit. n al doilea rnd, aceasta ar fi fost foarte greu de realizat(cine tie cum s-ar fi aranjat istoria, dac ar fii fost realizate complet toate ideile System R). Din alt punct de vedere, primele realizri comerciale se deosebeau att de mult, c nici unul din dialectele realizate nu aveau anse de a fi primite n calitate de standart.

Analiza documentelor accesibile arat, c procesul decurgea foarte dificil, utiliznd nu numai rezultatele tiinifice. n rezultat standartul Internaional SQL, primit n 1989 n marea majoritate a prilor sale, are un caracter comun i permite o descifrare forte larg. n acest standart lipsesc complet aa compartimente principale, ca manipularea cu schema BD i SQL dinamic. Multe din aspectele principale ale limbajului, n corelaie cu standartul se determin n realizare.

Se preapoate, c cele mai importante scopuri atinse de limbajul SQL sunt standartizarea clar a sintaxei i semnaticii a operatorilor de selecie i mai includ posibilitile de determinare a cheilor primare i secundare a relaiilor i aa numitele limitele de control a integritii, care reprezint din sine submulimea limitelor integritii SQL System R de clasa nti. Sursele de determinare a cheilor exterioare permit formularea uoar a aanumitor necesiti a integritii BD dup legturi. Aceast necesitate rspndit poate fi formulat i pe baza mecanismului general a limitelor integritii SQL System R, dar formularea pe baza sensului cheii externe este mai simpl i mai neleas. Vznd necompletarea standartului SQL, pe fonul ncheierii lucrului aupra prelucrrii acestui standart, specialitii diferitor firme au pornit lucrul cu standartul SQL2. acest lucru de asemenea s-a prelungit civa ani, au fost elaborate o mulime de proiecte de standarte, pn cnd n sfrit, n martie 1992 nu a fost elaborat proiectul final a standartului. Acest standart este cu mult mai amplu i cuprinde practic toate aspectele necesare pentru realizare: manipularea cu schema BD, dirijarea cu tranzaciile(din nou au aprut punctele de

salvare, memorare) i cu sesiile(sesia - este o succesiune a tranzaciilor, n limitele crora se pstreaz relaia temporal), conexiunea la BD, SQL dinamic. n sfrit sunt standartizate rfelaiile-registre a BD, ceea ce nu-i legat neaprat de limbaj, dar foarte mult acioneaz asupra realizrii.

Uimete faptul lipsei n standart a surselor de dirijare cu indexii. Desigur aceste surse, de obicei, se afl departe de operaiile de baz SQL, dar autorului nu-i este cunoscut nici o realizare n care ei ar lipsi.

n sfrit, odat cu finisarea lucrului saupra standartului SQL2 a luat natere prelucrarea standartului SQL3. se presupune c SQL3 va conine mecanismul trigherilor i posibilitatea utilizrii tipurilor abstracte de date. Sensul de standart se planific doar n anul 1995. s sperm c macr de aceast dat va fi posibil de urmrit prelucrarea lui.

Concluzionnd aceast scurt excursie prin istoria standartizrii SQL, s observ, c n cele mai multe cazuri(nu n toate) procesul standartizrii se limiteaz la o prelucrare tehnic atent a ideilor SQL System R, ceea ce nc o dat accentuieaz unicitatea acestui proiect(au trecut 12 ani de la finisarea lui!). Lecia 14. Limbajul standart a bazelor de date SQL Lecia 14. Limbajul standart a bazelor de date SQL

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

n limbajul 14.1. Tipuri de date/89 se menin urmtoarele tipuri de date: CHARACTER, NUMERIC, DECIMAL, INTEGER, SMALLINT, FLOAT, DOUBLE, PRECISION. Aceste tipuri de date se clasific pe tipurile expresiilor simbolurilor, numerelor ntregi i numerelor reale. Primei clase i se atribuie CHARACTER(length), unde length returneaz lungimea cuvntului tipului dat. S atragem atenia, c n 14.1. Tipuri de date/89 lipsete tipul cuvintelor de mrime variabil. Cu toate c n multe realizri ele se admit. Cuvintele literare ale simbolurilor se reprezint n form de ir de simboluri(de exemplu exemple).

Reprezentri ale clasei a doua de tipuri sunt NUMERIC, DECIMAL(DEC), INTEGER(INT) I SMALLINT. Specificatorul tipului NUMERIC are aspectul NUMERIC[(PRECISION[,SCALE])]. Se specific numerele ntregi, reprezentate cu precizia precision i cu scara scale. Aici i pe viitor, dac este scpat scara, atunci ea se poate socoti ca fiind egal cu 0, iar dac este scpat precizia. Atunci sensul ei se determin n realizare.

Specificatorul tipului DECIMAL(sau DEC) are aspectul NUMERIC[(precision[,scale])]. Se specific numerele ntregi, reprezentate cu scara scale i precizia mai mare sau egal cu valoarea precision.

Integer specific tipul de date a numerelor ntregi cu scara 0 i cu o precizie determinat de realizare. SMALLINT specific tipul de date a numerelor ntrgi cu scara 0 i cu precizia determinat n realizare, nu mai mare ca precizia numerelor tipului INTEGER.

Sensurile literare a numerelor ntregi n caz general se prezint sub forma [+][.]. 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

&. S atragem atenia c cu toate c odat cu utilizarea limbajului SQL putem determina schema BD, care conine datele oricrui tip din cele numite, posibilitatea de a le utiliza n sistemele adugtoare depinde de limbajul de programare utilizat. Gama ntreag a tipurilor de date poate fi folosit dac se programeaz n PL/1. de aceea n unele realizri SQL tipurile de date cu scar i precizie n genere nu se menin.

Cu toate c regulile de implimentare a SQL n limbajul C nu se determin n SQL/89, n majoritatea relizrilor, ce susin aa implimentare, are loc urmtoarea corelaie ntre tipurile de date SQL i tipurile de date C: CHARACTER corespunde caracterelor C; INTEGER corespunde long; SMALLINT corespunde short; REAL corespunde float, DOUBLE PRECISION corespunde lui double(anume aa corelaie este admis n SQL/92).

S atenionm c, n marea majoritate a realizrilor SQL, se menin unele tipuri de date adugtoare, ca de exemplu, DATE, TIME, INTERVAL, MONEY. Unele din aceste tipuri se specific n standartul SQL/92, dar n realizrile actuale realizrile sintactice i semantice se pot deosebi. 14.2. Surse de determinare a schemei 14.2. Surse de determinare a schemei

Sursele de determinare a schemei BD n stanartul SQL/89 se refer la prile mai slabe ale standartului i care permit o interpretare diferit. Mai mult ca att, nu ne este cunoscut nici o realizare , n care s-ar menine fix aa set de surse de determinare a schemei.

De aceea pentru obinerea mobilitatea sistemeiadugtoare n o clas destul de larg de realizare SQL/89, trebuie de localizat clar componentele de determinare a schemei BD. Cred c ar fi mai bine de concentrat tot lucrul cu schema BD ntr-un singur modul i de avut n vedere c reconstruirea acestui modul.

S atragem atenia, c n SQL/89 n genere lipsesc carevasurse de schimbare a schemei BD: nu-I posibilitatea de a nltura schema tabelului; de aduga n schema tabelului o coloan nou, .a. n toate realizrile aa surse se menin, dar ele pot s difere i dup sintactic i dup semantic.

Nectnd la lipsa oricror sperane c vom reui s ntlnim o realizare, ce ar susine limbajul de determinare a schemelor SQL/89, noi, pe scurt, vom descrie acest limbaj(fr mijloace sintactice), pentru a aprecia la nivelul cuvenit posibilitile SQL/89 i de a primi mcar careva surse de comparaie a diferitor realizri. 14.2.1. Operatorul de determinare a schemei

n legtur, corespunderii cu regulile SQL/89 fiecare tabel a BD date are un nume simplu i calificat. n calitate de calificator a numelui este identificatorul mputernicirilor tabelului, care de obicei, n realizare coincide cu numele a careva utilizator i numele calific a tabelului are forma:

.. 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: ::= CREATE TABLE() [{,}] ::= |. 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: ::= [][] ::= DEFAULT {|USER|NULL} ::= NOT NULL[] | |CHECK (). 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

(), atunci are loc crearea determinrii limitelor integritii corespunztoare dup legturi pentru tabel:

FOREIGN KEY(C) 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: ::= | | | ::= () ::=UNIQUE | PRIMARY KEY ::=[{, }] ::= FOREIGN KEY() ::= REFERENCES ::= ::= [(}] ::=[{,}] ::=CHECK() 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: ::= CREATE VIEW [()] AS [WITH CHECK OPTION] ::=[{,}...] 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: ::= GRANT ON TO [{,}][WITH GRANT OPTION] ::= ALL PRIVELEGES |[{,}] ::=SELECT|INSERT|DELETE |UPDATE [()] |REFERENCES [()] ::=[{,}] ::=PUBLIC| 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:

::= [] ::= | UNION [ALL] ::= |() ::= (SELECT [ALL|DISTINCT]) ::= SELECDT [ALL|DISTINCT] INTO ::= (SELECT [ALL|DISTINCT] ::= [] [] [] 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 |} [ASC|DESC] Dup cum vedem din aceste reguli sintactice, practic se d lista coloanelor rezultatului

expresiei adresrilor i pentru fiecare coloan se arat ordinea rndurilor rezultatului n dependen de nsemntatea acestei coloane(ASC dup cretere i DESC n descretere). Coloanele pot fi date prin numele sale n cazul cnd: expresia adresrilor nu conine operaiile UNION i UNION ALL; n lista de selecie a specificaiei adresrii acestei coloane i corespunde o expresie afirmativ, compus doar din numele coloanei. n toate celelalte cazuri, n despritura ORDER BY trebuie s fie dat numrul de ordine a coloanei n tabelul rezultant al expresiei adresrii. 15.1.2. Operatorul de selecie

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

Atenie: n dialectul SQL SGBD Oracle se menine varianta lrgit a operatorului

seleciei, rezultatul cruiea nu e neaprat tabelul dintr-un singur rnd. Aa lrgire nu se susine nici n SQL/89, nici n SQL/92. 15.1.3. Subadresarea

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

Standartul SQL/89 recomand s primim calculul expresiei tabelareca o utilizare consecutiv a despriturilor FROM, WHERE, GROUP i HAVING pentru tabelele date n lista FROM. Despritura FROM are sintaxa urmtoare:

::= FROM ({,}) ::= []

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 ::= (OR

::= (AND ::=[NOT] ::=|() 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: ::= {|} ::= =|||= 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: ::= [NOT] BETWEEN AND Rezultatul x BETWEEN y AND z este egal cu rezultatul x>=y AND x

Predicatul null Acest predicat se descrie de sintaxa dat: ::= 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: ::= ::= | ::=ALL ::=SOME|ANY Vom nota cu x rezultatul calculului expresiei afirmative prii stngi a predicatului, iar cu

S rezultatul calculului subadresrii. Predicatul x ALL S are valoarea true, dac S este pustie sau valoarea

predicatului x S e egal cu true pentru fiecare S, care se include n S. predicatul x ALL S are valoarea false, dac valoarea predicatului x S este egal cu false macr pentru un S care se include n S. n celelalte cazuri valoarea predicatului x ALL S este egal cu unicown.

Predicatul x SOME S are valoarea false, dac S este nul sau valoarea predicatului x S este egal cu false pentru fiecare s din S. Predicatul x SOME S are valoarea true, dac valoarea predicatului x S este egal cu true macr pentru un s din S. n celelalte cazuri valoarea predicatului x SOME S este unikown.

Predicatul exists Predicatul exists are sintaxa urmtoare: ::= EXISTS 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 [{,}] 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 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:

::= COUNT (*)| | ::= {AVG|MAX|MIN|SUM|COUNT} (DISTINCT) ::= {AVG|MAX|MIN|SUM}([ALL] ) Dup cum vedem n aceste reguli, n standartul SQL/89 sunt determinate 5 funcii

standarte de agregat: COUNT numrul rndurilor sau a valorilor; MAX valoarea maxim; MIN valoarea minim; SUM valoarea sumei i AVG valoarea medie. 15.3.1. Semantica funciilor de agregat

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

calculul funciei. Dac lista este nul, atunci valoarea funciei COUNT pentru ea este zero, iar valoarea celeilalte funcii null.

Fie T tipul valorilr din aceast list. Atunci rezultatul calculului funciei COUNT este un numr ntreg cu scara i precizia determinate n realizare. Tipul rezultatului valorilor funciilor MIN i MAX coincid cu T. La calculul funciei SUM i AVG tipul T nu trebuie s fie de tipul rndurilor simbolice, iar tipul rezultatului funciei este de tip de numere ntregi cu scara i precizia determinabile n realizare, dac T tip de numere ntregi i tip de numere reale cu precizia determinat n realizare, dac T tip de numere aproximative.

Calculul funciei COUNT(*) are loc pe calea enumrrii numrului de rnduri n mulimea dat. Toate rndurile se consider diferite, chiar dac ele snt compuse dintr-o singur coloan cu valoarea null n toate rndurile.

Dac funcia de agregat este specificat fr cuvntul cheie DISTINCT, atunci lista valorilor se construiete din valorile coloanei selectate(s subliniem c n acest caz nu se permite calculul expresiilor afirmative). Apoi din aceast list se exclud valorile nedeterminate i se nltur valorile dublicate. Apoi se calculeaz funcia dat.

Dac funcia de agregat este specificat fr cuvntul cheie DISTINCT(sau cu cuvntul cheie ALL), atunci lista de valori se formeaz din valorile expresiei afirmative, ce se calculeaz pentru fiecare rnd al expresiei date. Apoi din list se nltur valorile nedeterminate i se calculeaz funcia de agregat.

Atragei atenia c n acest caz nu se permite utilizarea funciei COUNT. Atenie: Ambele limite, artate n abzaele anterioare, sunt mai mult tehnice dect

principiale i pot s lipseasc n realizri concrete. Cu toate acestea ele sunt limite ale standartului SQL/89 i trebuie s inem cont de ele la programarea mobil. 15.3.2. Rezultatele adresrilor

Funciile de agregat pot fi utilizate n specificarea cursorului, a operatorului de selecie i n subadresare dup cuvntul cheie SELECT(n aceast subdespritur vom numi aa construcii ca list de selecie, i s nu uitm c n caz de subadresare aceast list e format doar dintr-un element) i n condiia despriturii HAVING. Standartul permite utilizarea mult mai exotic a funciilor de agregat n subadresri( funcia de agregate pe grupe de corteje a adresrii exterioare), dar n practic se ntlnesc foarte rar.

S cercetm diferite cazuri de utilizare a funciilor de agregat n lista de selecie n dependen de tipul expresiei tabelare.

Dac rezultatul expresiei tabelare R nu este un tabel grupat, atunci apariia macr a unei funcii de agregat din mulimea de rnduri R n lista de selecie duce la ceea, c R este privit ca un tabel grupat, care-i alctuit dintr-o(sau nici una) grup ce nu are coloane de grupare. De aceea, n acest caz, n lista de selecie nu se permite utilizarea direct a specificaiilor rndurilor R: toate ele trebuie s se gseasc n interiorul specificaiilor funciilor de agregat. Ca rezultat a adresrii e tabelul, cu nu mai mult de un rnd, primit pe calea utilizrii funciilor de agregat R.

La fel stau lucrurile i n cazul, cnd R este un tabel grupat, dar expresia tabelar nu conine despritura GROUP BY( i deci conine despritura HAVING). Dac n cazul abzaului anterior erau dou variante de creare a listei de selecie: numai cu indicarea direct a coloanelor R sau numai cu indicarea lor n interiorul specificaiilor a funciilor de agregat), atunci n cazul dat este posibil numai a doua variant. Rezultatul expresiei tabelare este afiat de ctre tabelul grupat, format dintr-o singur grup i rezultatul adresrii poate fi format doar pe calea aplicrii funiilor de agregat pentru acest grup de rnduri. Din nou ca rezultat a adresrii avem un tabel, ce conine nu mai mult de un rnd, primit pe calea aplicrii funciilor de agregat pentru R.

Cazul cnd R este un tabel adevrat grupat, adic expresia tabelar conine despritura GROUP BY i rezult c este determinat cel puin o coloande grupare. n acest caz regulile de formare a listei de selecie coincid cu regulile de formare a condiiei de selecie a despriturii

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

n standartul SQL/89 sunt determinate dou metode de interaciune cu BD din programul aplicat, scris n limbajul tradiional de programare(dup cum am mai numit, SQL/89 este orientat spre utilizare mpreun cu limbajele Cobol, Fortran, Pascal i PL/1, dar n realizri, de obicei susine i limbajul C). Prima metod const n aceea c toi operatorii SQL, cu care poate opera programul aplicat dat, sunt concentrate ntr-un modul i sunt oformate ca proceduri a acestui modul. Pentru aceasta SQL/89 conine un sublimbaj special limbajul modular. La utilizarea acestui mijloc de interaciune cu BD, programul aplicat conine apelul procedurilor modulului SQL cu transmiterea ctre ele a parametrilor dai i cu primirea parametrilor rezultani.

A doua metod const din utilizarea aa numitului SQL implimentat, cnd cu utilizarea sintaxei speciale n programul limbajului tradiionalde programare se implimenteaz operatori SQL. n acest caz, din punct de vedere a programului aplicat, operatorul SQL se ndeplinete dup loc. O parametrizare clar a operatorilor SQL lipsete, dar n operatorii implementai SQL pot fi utilizate numele variabilelor a programului de baz, i datorit acestui fapt, se asigur legtura dintre programul aplicat i SGBD.

Conceptual, aceste 2 metode sunt echivalente. Mai mult ca att, n standart se determin reguli de creare a modulului SQL dup programul cu SQL implimentat. ns n majoritatea realizrilor, operatorii SQL se prelucreaz foarte diferit. Modulul SQL, de obicei, se compileaz aparte de programul aplicat, n rezultat se creeaz setul aa numitor proceduri memorabile( n standart acest termen nu se utilizeaz, dar e rspndit n realizrile comerciale). Adic n cazul utilizrii modulului SQL, compilarea operatorilor SQL are loc odat, i apoi procedurile corespunztoare pot fi apelate din programul aplicat de cte ori va fi nevoie.

Spre deosebire de aceasta, pentru operatorii SQL, implimentai n programul aplicat, compilarea acestor operatori, de obicei, are loc de fiecare dat la utilizarea lor(mai bine zis, la fiecare prima utilizare a operatorului la ncrcarea dat a programului aplicat).

Desigur, utilizatorul nu trebuie s tie de aceast diferen tehnic n prelucrarea a dou tipuri de interaciuni cu SGBD. Exist i aa sisteme, ce provoac compilarea de o singur folosin a operatorilor implimentai SQL i pstreaz codul compilat. Dar totui e bine de inut cont de aceasta. S saducem unele propoziii pentru i n potriva la fiecare din aceste dou metode. La utilizarea limbajelor modulelor textul programului aplicat are un volum mai mic, interaciunile cu SGBD sunt mult mai localizate pe baza existenei parametrilor de apel a procedurilor. Din alt parte, pentru nelegerea sensului comportrii programului aplicat va fi nevoie de citirea simultan a dou texte. n afar de aceasta, dup cum se pare, sintaxa modulului SQL se poate deosebi mult n diferite realizri.

SQL implimentat ne d posibilitatea crerii unor programe aplicate mult mai auto ntreintoare. Sunt mai multe afirmaii pentru a ne baza pe simplitatea transferului a aa program n mediul altei SGBD, deoarece standartul implimentrii mai mult sau mai puin se ndeplinete. Neajunsul de baz este un oarecare PL este tipul acestor programe, indiferent de limbajul de baz ales. Desigur trebuie de inut cont de observaiile, ce se conin n abzaele anterioare.

Apoi vom descie pe scurt limbajul modulelor i regulile de implimentare n dependen

de standartul SQL/89(s reamintim, c regulile de implimentare nu fac parte din standart). 16.2. Limbajul modulelor 16.2. Limbajul modulelor

Structura modulului SQL n standartul SQL/89 se determin din regulile sintactice urmtoare:

::= [] ::=MODULE [] ::=LANGUAGE{COBOL|FORTRAN|PASCAL|PLI} ::= AUTORIZATION ::= 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 ; ; ::= | ::= SQLCODE ::= | | | | | | | | | |. 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.

::= { | |} [] ::=EXEC SQL ::=END EXEC|; ::= [] ::= BEGIN DECLARE SECTION[] ::= END DECLARE SECTION[] ::=: ::= WHENEVER ::=SQLERROR|NOT FOUND ::=CONTINUE| ::={GOTO|GO TO} ::=:|. Operaiile implimentate SQL, inclusiv i declararea cursorului, deasemenea despriturile

declarrii situaiilor excepionale i a variabilelor programului de baz trebuie s fie luate n ghilimele EXEC SQL i END EXEC. Declararea cursorului trebuie s fie ntlnit textual mai devreme de orice operaie ce se bazeaz pe acest cursor. Toate variabilele programului de baz ce se utilizeaz n operatorii implimentai SQL, trebuie s fie declarai textual n despritura anterioar acestui operator de declarare a variabilelor programului de baz. Cu toate acestea sintaxa declarrii variabilelor corespunde sintaxei limbajului de programare de baz, ns la nceputul numelui variabilei se pun dou puncte.

Mecanismul de prelucrare a situaiilor excepionale n SQL/89 este foarte simplu(putem spune primitiv). Putem crea reacia pentru apariia a dou feluri de condiii: SQL ERROR este condiia apariiei n variabil SQL CODE dup ndeplinirea operatorului implementat cu sens de valoare negativ; NOT FOUND este condiia apariiei n SQL CODE a valorii +100(acest cod nseamn emanarea cursorului). Reacia poate fi alctuit din execuia trecerii la semnul programului de baz(aciunea GO TO) sau poate s lipseasc(aciunea CONTINUE).

Va reaciona acel operator de determinare a reaciei n caz de situaie excepional, care textual este mai aproape de la nceputul programului de operatorulSQL.

S atragem atenia c n multe realizri se menin dou feluri de coduri de rspuns la execuia operatorilor SQL(implementai sau luai din modul): prin variabila SQL CODE cu codurile de rspuns, care sunt reprezentate prin numere ntregi i prin variabila SQL STATE cu codurile de rspuns, codificarte prin numere zecimale, afiate n form de text. Este tendina de

trecere la utilizarea numai a mecanismului SQL STATE, dar n realizrile standarte trebuie s se menin mecanismul SQL CODE. 16.4. Setul operatorilor de manipulare cu datele 16.4. Setul operatorilor de manipulare cu datele

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

Operatorii acestei grupe sunt legai prin faptul c toi ei lucreaz cu un oarecare cursor, declararea cruiea trebuie s se conin n acelai modul sau n programul cu SQL implementat.

Operatorul de declarare a cursorului Vom repeta regulile sintactice de declarare a cursorului: ::= DECLARE CURSOR FOR ::= [] ::= | UNION [ALL] ::=|() ::= ORDER BY [{,}] ::= {|} [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 . 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 INTO

::= [{,}]. 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: [INDICATOR] la specificarea parametrului i [IDENTIFICATOR] 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 FROM WHERE CURENT OF . 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 SET [{,}] WHERE CURENT OF ::= = {|NULL} ::=.

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. 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: ::= INTO ::= [{,}] 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 FROM WHERE[]. 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 SET [{,>}] [WHERE] ::= = {|NULL} ::=. Tabelul T, specificat n operatorul UPDATE trebuie s fie schimbtor. Asupra condiiei

de cutare se depune condiia c pentru tabelul T nu trebuie s se conin schie n nici o subadresare depus a predicatelor despririi WHERE.

Operatorul se execut n felul urmtor: tabelul T se verific succesiv i fiecare rnd pentru care rezultatul calculului de cutare este true, se schimb n conformitate cu despritura SET.

Dac expresia afirmativ n despritura SET conine schie pentru coloanele tabelului T, atunci la calculul expresiei afirmative se utilizeaz valorile coloanelor curente, pn la modificarea lor.

Operatorii de finisare a tranzaciei Tranzacia curent poate fi finisat cu succes(cu fixarea n baza de date a schimbrilor

efectuate) pe calea execuiei operatorului COMMIT WORK sau accidental(cu tergerea schimbrilor din baza de date, create de tranzacia curent) pe calea execuiei operatorului ROLL BACK WORK. La execuia oricrui din operatorii dai are loc nchiderea forat a tuturor cursoarelor, deschise la momentul execuiei operatorului de finisare a tranzaciei. 16.5. SQL dinamic n Oracle V.6 16.5. SQL dinamic n Oracle V.6

setul de operatori SQL descris n standartul SQL/89 este destinat implimentrii n programul scris n limbajul obinuit de programare. De aceea n acest set sunt amestecai operatorii a limbajului relaional adevrat cu adresri(de exemplu operatorul de tergere a unei pri de rnduri din tabel, care satisfac valorii date i operatorii de lucru cu cursoarele, ce permit accesul pe rnduri la tabelul rezultat a adresrii.

Este clar c n regimul de dialog setul de operatori SQL i sintaxa lor trebuie s fie un pic altfel. ntrebarea este cum s realizm un aa program de dialog. Regulile de implementare a SQL standart n programul elaborat ntr-un limbaj obinuit de programare prevd c toat informaia, privind operatorii SQL, e cunoscut n static(cu excepia valorilor variabilelor utilizate n calitate de constante n SQL). Nu sunt prevzute sursele standarte de compilare cu execuie succesiv a operatorilor, care devin cunoscui doar n momentul execuiei(de exemplu se introduc din terminal). De aceea bazndu-ne doar pe standart, e imposibil de a realiza monitorul de dialog de interaciune cu BD n limbajul SQL sau alt program aplicat, n care textul operatorilor SQL apare n timpul execuiei, adic standartul trebuie lrgit. Una din posibilele ci de lrgire const n utilizarea grupului special de operatori, ce asigur compilarea dinamic(n timpul execuiei programului aplicat) a submulimii de baz a operatorilor SQL i care sisin execuia lor corect. Unul din seturile de aa operatori fcea parte din dialectul SQL, realizat n System R, alt set mai deosebit face parte din realizarea Oracle V.6 i n sfrit, n standartul nou SQL/92 a aprut versiunea standart a lui SQL dinamic.

Deoarece n SGBD Oracle sursele lui SQL dinamic sunt realizate comparativ de mult, are sens s le vedem mai nti pe ele, pentru a avea o baz de comparaie cu SQL/92.

n setul adugtor de oeratori, ce menin compilarea dinamic a operaiilor SQL de baz, intr operatorii: PREPARE, DESCRIBE i EXECUTE. 16.5.1. Operatorul de pregtire

Operatorul PREPARE are sintaxa: ::= PREPAREFROM ::=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 {[USING] (IMMEDIATE}. 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 . 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 FOR{|} 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 [USING{|DESCRIPTOR}] ::= FETCH {INTO (USING

(USING DESCRIPTOR }. Dup cum se vede, se presupun duo tipuri de indicare a parametrilor de tip parametric

de intrare i de ieire: direct cu intrarea n operatorii OPEN i/sau FETCH a listelor numelor variabilelor a programului dat i indirect, cnd numele parametrilor i adresele lor se indic printr-o structur adugtoare a descriptorilor.

Prima metod se ofer pentru lucrul cu operatorii de selecie, pentru care este fixat setul parametrilor formali de intrare i de ieire. Mai precis, n ceea ce privete parametrii de ieire, trebuie s fie fixai numrul i tipurile elementelor a listei de selecie.

A doua metod de lucru cu operatorii dinamic compilai, care necesit utilizarea cursoarelor, const n utilizarea descriptorilor a listelor parametrilor formate dinamic. n acest caz toat rspunderea pentru coincidena tipurilor parametrilor formali i actuali cade pe programator. n rezultatul erorii la formularea a aa liste, poate fi pierdut memoria programului C. Lecia 17. Unele proprieti SQL/92 i SQL-3 Lecia 17. Unele proprieti SQL/92 i SQL-3

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

::= ALLOCATE DESCRIPTOR [WITH MAX ] ::= ::= [] ::=GLOBAL|LOCAL ::= ( (. Comentarii: Descriptorul este partea dinamic distingibil a memoriei programului aplicat care se

utilizeaz pentru primirea informaiei despre rezultat sau despre parametrii operatorului SQL pregtit dinamic sau pentru indicarea parametrilor a aa operator. Sensul, c pentru destingerea memoriei se utilizeaz operatorul SQL, i nu pur i simplu funcia standart ALLOC sau o oarecare alt funcie a adresrii dinamice de memorie, const n faptul c programul aplicat nu cunoate structura descriptorului i chiar a adresei lui. Aceasta permite de a nu lega SQL cu posibilitile deosebite a oricrei structuri de programare. Toate schimburile de informaie ntre programul aplicat i descriptori au loc la fel cu ajutorul unor operatori SQL(GET i SET, uite mai jos).

ntrebarea a doua: Pentru ce n genere s destingem dinamic memorie sub descriptori. Aceasta se face pentru c n caz general programul aplicat, care utilizeaz SQL dinamic, nu

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

::= DEALLOCATE DESCRIPTOR . Comentariu: Execuia acestui operator aduce la elibirarea memoriei din descriptorul delimitat mai

devreme. Dup aceasta utilizarea numelui descriptorului este ilegal n orice alt operator, n afar de ALLOCATE DESCRIPTOR. 17.3. Operatorul de primire a informaiei din regiunea descriptorului SQL 17.3. Operatorul de primire a informaiei din regiunea descriptorului SQL

::= GET DESCRIPTOR ::= (VALUE ({}] ::= COUNT ::= ::= ::= ::= 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 ::= . Comentariu: Operatorul GET DESCRIPTOR se utilizeaz pentru selecia informaiei de descriere,

amestecat mai devreme n descriptor cu ajutorul operatorului DESCRIBE. La o singur execuie a operatorului putem primi sau numrul elementelor completate(COUNT), sau informaia, ce se conine n unul din elementele completate. 17.4. Operatorul de instalare a descriptorului 17.4. Operatorul de instalare a descriptorului

::= SET DESCRIPTOR ::= (VALUE [{}] ::=COUNT ::= ::= ::= ::=. Comentariu: Operatorul SET DESCRIPTOR se utilizeaz pentru completarea elementelor

descriptorului cu scopul utilizrii lui n despritura USING. La o singur execuie a operatorului valoarea o putem duce n cmpul COUNT(numrul elementelor completate), sau parial sau total de creat un element a descriptorului. 17.5. Operatorul pregtirii 17.5. Operatorul de pregtire

PREPARE FROM ::=

::= | | | | | | | | | | | ::= ::= ::= ::= ::= | ::=[scope option] ::= [] [::= FOR {READ UNLY | UPDATE[OF]} ::= | ::= SELECT[] ::=DISTINCT|ALL. Comentariu: Operatorul PREPARE induce compilarea i construirea planului de execuie a

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