Setul de comenzi SQL



Operaţia fundamentală în SQL este maparea reprezentată din punct de vedere sintactic printr-o construcţie SELECT-FROM-WHERE. Această construcţie corespunde unei succesiuni de operatori algebrici de forma selecţie-proiecţie-cuplare, foarte frecventă în algebra relaţională.
Clauza SELECT realizează operaţia de proiecţie şi este urmată de lista atributelor care se reţin în relaţia rezultat. Proiecţia SQL diferă de operatorul de proiecţie din algebra relaţională prin faptul că nu elimină tuplele duplicat. Eliminarea tuplelor duplicat se face de către utilizator, atunci când se doreşte, prin folosirea operatorului DISTINCT.
Operaţia de cuplare poate fi realizată prin clauza FROM, atunci când este urmată de o listă formată din cel puţin două nume de relaţie, împreună cu condiţia de cuplare formulată în cazul predicatului din clauza WHERE.
Alte operaţii fundamentale sunt cele de inserare, modificare şi ştergere a infomaţiilor din baza de date. Acestea se realizează cu ajutorul instructiunilor: INSERT, UPDATE şi DELETE.

Proceduri stocate
Folosind SQL Server la dezvoltarea aplicaţiilor există doua modalităţi în care pot fi stocate şi executate programele. Ele pot fi memorate la nivelul aplicaţiilor care trimit comenzi către SQL Server şi prelucrează rezultatele returnate de acestea, sau pot fi dezvoltate ca şi proceduri stocate.



O procedură stocată este un nume dat unui grup de instrucţiuni SQL care au fost create şi stocate pe serverul bazei de date. Procedurile stocate acceptă parametri de intrare astfel încat pot fi utilizate de mai mulţi clienti în reţea folosind date diferite. Procedurile stocate reduc traficul în reţea şi îmbunătesc performanţele. Pot fi folosite şi pentru a asigura integritatea datelor.
Avantajele procedurilor stocate faţă de programele stocate la nivelul aplicaţiilor utilizator:
. Programare modulara - o procedură stocată poate fi creată o singură dată şi apelată de mai multe ori din mai multe aplicaţii. Poate fi modificată independent de aplicaţiile care o apelează şi poate fi creată de către o persoană specializată în baze de date.
. Performanţă îmbunătăţită - în cazul programelor cu volum mare de cod sau a celor executate de mai multe ori, procedurile stocate sunt mai eficiente deoarece compilarea şi optimizarea lor se face o singură dată la crearea procedurii şi sunt memorate într-o stare direct executabilă, evitându-se repetarea compilării la fiecare apel al procedurii.
. Reducerea traficului de reţea - o prelucrare care presupune sute de linii de cod poate fi realizată printr-o singură linie de comandă care apelează procedura stocată prin care este implementată acea prelucrare.
. Oferă mecanism suplimentar de securitate - utilizatorii nu au acces direct la codul procedurilor stocate, dreptul de execuţie al unei proceduri stocate poate fi acordat sau nu în funcţie de tipul de utilizator.
Crearea unei proceduri stocate cu caracter permanet sau temporar, care urmează a fi ultilizată în sesiunea utilizatorului curent sau în sesiunile deschise la un moment dat, se realizează cu intrucţiunea CREATE PROCEDURE. Lansarea în execuţie a unei proceduri stocate se face cu comanda EXECUTE. În urma executării cu succes a instrucţiunii de creeare a procedurii stocate, numele şi textul procedurii se va înregistra în tabelele director ale serverului bazei de date, SQL Server.
Stergerea unei proceduri stocate înseamnă eliminarea definiţiei sale din baza de date. Instrucţiunea DROP PROCEDURE realizează acest lucru. Se pot şterge doar grupuri întregi de proceduri care au aceleaşi nume.

Triggere
Triggerele sunt o clasă specială de proceduri stocate, asociate unei tabele. Sunt un instrument puternic pentru implementarea regulilor de business. Triggerele sunt lansate în execuţie automat la iniţierea unei operaţii de tip INSERT, UPDATE sau DELETE. Un trigger SQL poate apela proceduri stocate sau funcţii utilizator.
În comparaţie cu procedurile stocate, triggerele nu pot fi apelate direct din aplicaţii. Ele extind posibilităţile altor instrumente de verificare a integrităţii din SQL Server cum ar fi constrângeri, valori implicite şi reguli.
Atunci cand se încearcă o operaţie de modificare a unei tabele căreia îi este ataşat un trigger, are loc iniţierea triggerului. Acesta poate conţine intrucţiuni SQL complexe şi poate accesa date din tabele. Există o legătură strânsă între trigger si operaţia care îl declanşează, astfel că, daca execuţia triggerului eşuează atunci şi operaţia se anulează. La o tabelă se pot ataşa mai multe triggere.
Intrucţiunea de creeare a triggerului, CREATE TRIGGER poate fi definită cu oricare din caluzele FOR UPDATE, FOR INSERT sau FOR DELETE, în funcţie de operaţia solicitată.
Pana la versiunea SQL 7.0 existau numai triggere AFTER, care se declanşau numai dupa terminarea operaţiei care a declanşat triggerul. În SQL Server 2000 apar triggerele INSTEAD OF care se execută în locul operaţiei care a iniţiat triggerul.
Stergea unuia sau a mai multor triggere din baza de date curentă se realizează cu instrucţiunea DROP TRIGGER.
Vederi
Vederea este o tabelă virtuală al cărei conţinut este definit printr-o interogare. Constă dintr-un set de atribute şi se materializează printr-un set de tuple. Se memorează doar fraza SELECT pe baza căreia datele sunt determinate în momentul invocării vederii.
Avantajele vederilor:
. Simplificarea şi specializarea viziunii utilizatorilor asupra datelor - vederile pot fi vazute ca şi o suprastructură care oferă grupurilor de tabele a bazei de date sau de utilizatori un model al datelor mai concis şi mai uşor de înţeles.
. Un mecanism suplimentar de securitate - Se pot acorda drepturi de acces şi de manipulare la nivelul vederilor şi nu la nivelul tabelelor.
. Simplificarea manipulării datelor - Interogările şi operaţiile de manipulare date pot fi exprimate mai simplu în contextul vederilor decât în termenii tabelelor de bază.
. Simplificarea operaţiilor de import şi export date - permit adaptarea structurilor de tabele diferite aparţinând unor baze diferite între care se face un trannsfer de date.
Instrucţiunea de creare:
CREATE VIEW nume_vedere[(coloana[,n])]
[WITH ENCRYPTION]
AS
Instrucţiune_select
[WITH CHECK OPTION]

Cursoare
Cursoarele constituie un mod complementar de lucru prin care se permite accesul la tuple, una câte una, şi prelucrarea independentă a fiecărei tuple în parte. Folosirea cursoarelor nu este utilă în operaţiile obişnuite care se pot rezolva prin fraze SQL.
O prelucrare bazată pe cursoare se desfăşoară în mai multe faze:
. Declararea unui cursor - unui cursor i se asociază setul de tuple rezultat corespunzător unei fraze SELECT; de asemenea se specifică o serie de caracteristici ale cursorului.
. Deschiderea cursorului - se execută fraza SELECT asociată, realizându-se popularea cursorului.
. Încărcarea cursorului - se poziţionează cursorul în dreptul unei tuple cu care s-a populat cursorul, dar se menţine cursorul în sine împreună cu definiţia sa.
. Dealocarea cursorului - se şterge cursorul împreuna cu definiţia sa.

Tranzactii SQL
Tranzacţia este o secvenţă de operaţii realizate ca şi o singura unitate logică de lucru. Aceasta trebuie sa indeplinească patru propietăţi care poartă numele de ACID (Atomicitate, Consistenţă, Izolare şi Durabilitate) .
Tranzacţiile asigură menţinerea într o stare consistentă a unei baze de date accesate în regim concurent şi cu posibilităţi de apariţie a erorilor.
Blocul de operaţii SQL de scriere şi citire se va executa ca o singură comandă, apariţia unei erori pe parcursul execuţiei uneia dintre ele ducând la anularea efectelor comenzilor deja executate şi anularea tranzacţiei. Îndeplinirea cu succes a tuturor sarcinilor din blocul de comenzi permite încheierea tranzacţiei cu succes şi scrierea pe suport permanent a modificărilor efectuate asupra bazei de date.
Toate procedurile stocate în care apar mai mult de o comandă SQL care modifică date se vor scrie folosind o tranzacţie, prin aceasta asigurându se consitenţa bazei de date chiar şi în cazul apariţiei unor erori.
În plus, izolarea automată a tranzacţiilor permite efectuarea operaţiilor doar dacă starea actuala a bazei de date o permite.
În regim concurenţial, s ar putea ca între momentul de timp în care un utilizator lansează o cerere şi momentul în care aceasta se execută efectiv, baza de date să se fi modificat şi sa nu mai existe condiţiile logice de a duce la bun sfârşit cererea, chiar dacă în momentul lansării cererii, aceasta era perfect legitimă.