Sunteți pe pagina 1din 14

Vederi (Tabele virtuale) Tabelele unei baze de date definesc structura i organizarea datelor acesteia.

SQL ne permite s privim datele din baza de date i n alte moduri dect cele prezentate de tabele, prin utilizarea vederilor. O vedere este o interogare SQL stocat n baza de date i creia i se asociaz un nume. SQL permite accesul la rezultatele acestei interogri ca i cnd aceasta ar fi o tabel real. Vederile sunt o parte important a SQL-ului, din cteva motive: Ofer utilizatorilor mai multe perspective asupra datelor din baza de date. Restricioneaz accesul la date, astfel nct un utilizator va avea acces numai la anumite linii sau coloane dintr-o tabel. Simplific accesul la baza de date prin faptul c prezint unui anumit utilizator datele din baza de date n modul cel mai natural pentru acesta. O vedere este deci o tabel virtual a bazei de date, al crei coninut este definit pe baza unei interogri. Pentru utilizatorii bazei de date, vederea apare ca i o tabel real, cu un set de nume de coloane i linii cu date. Dar, spre deosebire de o tabel real, o vedere nu exist n baza de date ca o mulime de valori stocate. Liniile i coloanele vizibile prin intermediul unei vederi sunt de fapt rezultatele interogrii care definete vederea. SQL creeaz iluzia unei vederi prin faptul c atribuie interogrii un nume, ca i n cazul unei tabele, i stocheaz definiia vederii n baza de date.

Figura 5.26 O vedere cu dou tabele surs Vederea din figura 5.26 este una tipic. A fost denumit REPDATA i este definit pe baza urmtoarei interogri:

Datele din vedere provin din tabelele SALESREPS i OFICES. Acestea sunt numite tabelele surs ale vederii deoarece ele reprezint sursa datelor care vor fi vizibile n vederea respectiv. Aceast vedere conine cte o linie pentru fiecare agent de vnzri i cuprinde, n plus, oraul n care lucreaz i regiunea n care este situat acesta. Dup ce o vedere a fost definit, ea poate fi utilizat n instruciunea SELECT, ca o tabel real. S se afieze agenii care si-au depit cota de vnzri, preciznd oraul i regiunea n care lucreaz.

Numele vederii, REPDATA, apare n clauza FROM la fel ca i numele unei tabele iar coloanele vederii sunt referite n instruciunea SELECT la fel ca i coloanele unei tabele reale. Pentru unele vederi putem utiliza, de asemenea, instruciunile INSERT, DELETE, i UPDATE pentru a modifica datele din vedere, la fel ca i in cazul tabelelor reale. Aadar, n practic, vederea poate fi utilizat n instruciunile SQL ca i o tabel real. Cnd SGBD-ul ntlnete o referin la o vedere ntr-o instruciune SQL, caut definiia acesteia n baza de date apoi transform cererea care face referire la vedere ntr-una echivalent dar care se refer la tabelele surs. Crearea unei vederi (CREATE VIEW) Pentru crearea unei vederi se utilizeaz instruciunea CREATE VIEW. Instruciunea atribuie un nume vederii i precizeaz interogarea care definete vederea. Opional, instruciunea CREATE VIEW poate atribui un nume coloanelor vederii nou create. Dac este prezent o list cu nume de coloane, aceasta trebuie s aib acelai numr de elemente ca i al coloanelor furnizate de interogare. Menionm c nu pot fi specificate dect numele coloanelor; tipul de dat, dimensiunea sau alte caracteristici ale coloanelor sunt derivate din definiiile coloanelor din tabelele surs. Dac lista de coloane este omis, fiecare coloan din vedere va avea acelai nume cu al coloanei din interogare. Numele coloanelor unei vederi trebuie specificate explicit doar n cazul n care

interogarea cuprinde coloane calculate sau dou coloane cu acelai nume, provenite din tabele surs diferite. Vederi orizontale Una dintre utilizrile obinuite ale vederilor este de a permite accesul utilizatorilor numai la unele dintre liniile unei tabele. De exemplu, dorim s permitem unui manager s vad numai acele linii din tabela SALESREPS care corespund agenilor din regiunea managerului respectiv. S se creeze o vedere pentru agenii de vnzri din regiunea Eastern.

S se creeze o vedere pentru agenii de vnzri din regiunea Western.

Acum putem da fiecrui manager permisiunea de a accesa doar una dintre vederile EASTREPS sau WESTREPS; n acest mod fiecare manager va avea o vedere personalizat asupra tabelei SALESPEPS, avnd acces doar la agenii din aceeai regiune cu el. Vederile de acelai tip cu EASTREPS sau WESTREPS sunt numite vederi orizontale. Aa cum se observ i n Figura 5.27, o vedere orizontal mparte tabela surs n poriuni orizontale. Doar anumite linii din tabela surs sunt vizibile n vedere.

Figura 5.27 Vederi orizontale

n continuare sunt prezentate alte exemple de vederi orizontale. S se defineasc o vedere care s conin numai birourile din regiunea Eastern.

S se defineasc o vedere corespunztoare agentului de vnzri Sue Smith (agentul cu numrul 102) care s conin numai comenzile efectuate de clienii pentru care este chiar el reprezentant de vnzri.

S se defineasc o vedere care s cuprind numai acei clieni care au efectuat comenzi n valoare total de cel puin $30.000,00.

n fiecare dintre aceste exemple, vederile deriv dintr-o singur tabel. Vederea este definit de o interogare SELECT * i, ca urmare, are exact aceleai coloane ca i tabela surs. Clauza WHERE determin care dintre liniile tabelei surs sunt vizibile n vedere. Vederi verticale O alt utilizare frecvent a vederilor este pentru a permite accesul utilizatorilor doar la anumite coloane ale unei tabele. De exemplu, departamentul de procesare a comenzilor este suficient s aib acces numai la numrul angajatului, numele i biroul la care acesta lucreaz deoarece aceste informaii sunt suficiente pentru procesarea corect a unei comenzi. Nu are nevoie s cunoasc data angajrii sau cota de vnzri a unui angajat.

O vedere similar cu REPINFO este numit adesea vedere vertical. Aa cum se observ i n Figura 5.28, o vedere vertical mparte tabela surs n poriuni verticale.

Figura 5.28 Vederi verticale S se defineasc o vedere derivat din tabela OFFICES care s cuprind doar informaii despre numrul birourilor, oraul i regiunea in care sunt acestea situate.

S se defineasc o vedere derivat din tabela CUSTOMERS, care s cuprind numai numele clientului i reprezentantul de vnzri al acestuia.

n fiecare din aceste exemple, vederea este derivat dintr-o singur tabel surs. Lista de selecie din definiia vederii precizeaz care dintre coloanele tabelei sursa sunt vizibile n vedere. Deoarece sunt vederi verticale, toate liniile din tabela sursa sunt reprezentate n vedere iar definiia vederii nu conine clauza WHERE. Vederi oarecare

SQL nu restricioneaz definiiile vederilor la cele pur orizontale sau verticale. De fapt, limbajul SQL nu cuprinde noiunile de vedere orizontal i vedere vertical. Aceste concepte, mai degrab, ne ajut s vizualizm cum sunt prezentate n vederi datele din tabelele surs. Este un fapt destul de obinuit definirea unei vederi care s mpart tabela surs att n poriuni orizontale ct i verticale, ca n urmtorul exemplu. S se defineasc o vedere care s conin numrul clientului, numele companiei i limita creditului pentru toi clienii al cror reprezentant de vnzri este Bill Adams (angajatul cu numrul 105).

Datele care sunt vizibile n aceast vedere reprezint o submulime de linii i respectiv de coloane din tabela CUSTOMERS. Numai coloanele specificate explicit n lista de selecie i liniile care satisfac condiia de selecie vor fi vizibile n vedere. Vederi la nivel de grup Interogarea specificat n definiia unei vederi poate include clauza GROUP BY. Un astfel de tip de vedere poart numele de vedere la nivel de grup. Vederile de grup realizeaz aceleai funcii ca i interogrile la nivel de grup; grupeaz liniile i furnizeaz ca rezultat al interogrii cte o singur linie, pentru fiecare grup. S se defineasc o vedere care s conin informaii sintetizatoare despre comenzile primite de fiecare agent de vnzri.

Aa cum se observ din acest exemplu, definiia unei vederi la nivel de grup conine ntotdeauna o list cu numele coloanelor. Lista atribuie nume coloanelor din vedere, coloane care sunt derivate din funcii de agregare (la nivel de grup) cum sunt SUM( ), MIN( ) etc. De asemenea, se poate atribui unei coloane din vedere un alt nume dect cel pe care l are aceasta n tabela de baz. n acest exemplu, coloana REP din tabela ORDERS a devenit WHO n vederea ORD_BY_REP. Dup ce a fost definit, o vedere la nivel de grup poate fi utilizat pentru a simplifica interogrile. De exemplu, urmtoarea interogare genereaz un raport care sintetizeaz informaiile despre comenzile primite de fiecare agent de vnzri. 6

S se afieze numele, numrul de comenzi, valoarea total a comenzilor precum i media valorilor comenzilor primite de ctre fiecare agent de vnzri.

Spre deosebire de vederile orizontale sau de cele verticale, n cazul vederilor la nivel de grup nu exist o corespondent unu-la-unu ntre liniile din vedere i cele din tabela surs. O vedere la nivel de grup nu este doar un filtru asupra tabelei surs, care s afieze doar anumite linii sau coloane ale acesteia; ea sintetizeaz informaiile din tabela surs i din aceast cauz SGBD-ul depune un efort substanial pentru procesarea interogrii din definiia vederii i pentru a da iluzia unei tabele. Vederile la nivel de grup pot fi utilizate n interogri dar nu pot fi actualizate. Spunem c vederile la nivel de grup sunt read-only. Reamintim c funciile de agregare imbricate, ca de exemplu MIN(MIN(A)), nu sunt permise n SQL. Dei vederile la nivel de grup ascund funciile de agregare din lista de selecie, SGBD-ul tie de existena acestora i mpiedic nclcarea acestei restricii. S considerm urmtorul exemplu: Pentru fiecare birou de vnzri, s se arate intervalul n care sunt cuprinse vnzrile medii ale angajailor care lucreaz la biroul respectiv.

Aceast interogare produce o eroare, dei pare corect. Este o interogare a dou tabele, care grupeaz liniile din vederea ORD_BY_REP dup codul biroului de vnzri. Dar 7

funciile de agregare MIN( ) i MAX( ) din lista de selecie determin apariia problemei. Argumentul acestor funcii, coloana AVERAGE, este ea nsi rezultatul unei funcii de agregare. Interogarea care va fi procesat de SQL este, de fapt, urmtoarea:

Aceast interogare este incorect din cauza prezenei de dou ori a clauzei GROUP BY i a funciilor de agregare. Vederi de tip join Una dintre cele mai uzuale utilizri ale vederilor este pentru simplificarea interogrilor. Prin specificarea, n definiia vederii, a unei interogri care se refer la dou sau trei tabele putem crea o vedere de tip join, care culege date din dou sau mai multe tabele diferite i prezint rezultatele interogrii sub forma unei tabele virtuale. Dup ce a fost definit, putem utilizata o interogare simpl asupra vederii , ca n cazul unei tabele reale, n locul unei interogri asupra a dou sau mai multor tabele. De exemplu, s presupunem c Sam Clark, vicepreedinte de vnzri, interogheaz adesea tabela ORDERS. Totui, el nu dorete s lucreze cu id-urile agenilor de vnzri sau ale clienilor ci cu numele acestora. S se creeze o vedere similar tabelei ORDERS dar care s utilizeze nume n locul idurilor.

Vederea este definit pe baza unei interogri care implic trei tabele. Ca i n cazul vederilor la nivel de grup, procesrile efectuate de SGBD pentru a crea iluzia unei tabele, sunt considerabile. Fiecare linie din vedere este derivat din combinarea a trei linii, provenind cte una - din tabelele ORDERS, CUSTOMERS i SALESREPS. Dei are o definiie relativ complicat, aceast vedere furnizeaz avantaje considerabile. n continuare, este prezentat o interogare care genereaz un raport referitor la situaia comenzilor pe ageni de vnzri. S se afieze totalul comenzilor primite de fiecare agent de vnzri.

Observm c aceast interogare se refer la o singur tabel i este considerabil mai simpl dect instruciunea SELECT din definiia vederii. S se genereze un raport cu privire la comenzile mai mari de $20.000,00 , artnd clienii care le-au efectuat i agenii de vnzri care le-au primit.

Aceste interogri sunt mult mai uor de exprimat prin utilizarea vederilor dect dac am utiliza o interogare asupra tuturor celor trei tabele.

Actualizarea vederilor Ce nseamn adugarea unei linii ntr-o vedere, tergerea unei linii dintr-o vedre sau modificarea unei linii deja existente ntr-o vedere? Pentru unele vedrei aceste operaii pot fi transformate uor n operaii echivalente asupra tabelei sau tabelelor surs. De exemplu, s considerm iari vederea EASTREPS, definit anterior n acest paragraf. S se creeze o vedere corespunztoare agenilor de vnzri din regiunea EASTERN.

Aceasta este o vedere orizontal simpl, derivat dintr-o singur tabel surs. Aa cum se arat n Figura 5.29, are sens s vorbim despre adugarea unei linii n aceast vedere; nseamn c noua linie va fi adugat n tabela SALESREPS, din care deriv vederea. De asemenea, are sens s vorbim despre tergerea unei linii din vederea EASTREPS; acest lucru va determina tergerea liniei corespunztoare din tabela SALESREPS. n sfrit, are sens modificarea unei linii din vederea EASTREPS; aceasta nseamn modificarea liniei corespunztoare din tabela SALESREPS. n fiecare caz, aciunea efectuat asupra vederii poate fi transformat ntr-o aciune similar efectuat asupra tabelei surs deoarece se pstreaz att integritatea tabelei surs ct i a vederii.

Figura 5.29 Actualizarea datelor prin intermediul unei vederi S considerm acum vederea la nivel de grup ORDS_BY_REP, definit anterior n acest paragraf. S se defineasc o vedere care s conin informaii sintetizatoare despre comenzile primite de fiecare agent de vnzri.

n acest caz nu exist o corespondent unu-la-unu ntre liniile vederii i liniile tabelei ORDERS, de aceea nu are sens s vorbim despre adugarea, tergerea sau modificarea unei linii a acestei vederi. Vederea ORD_BY_REP nu este actualizabil; este o vedere read_only.

10

Vederile EASTREPS i ORD_BY_REP sunt dou exemple extreme din punct de vedere al complexitii definiiei. Exist vederi mult mai complexe dect vederea EASTREPS n care au sens operaiile de actualizare, i exist vederi mult mai simple dect ORD_BY_REP n cazul crora aceste operaii nu au sens. De fapt, problema stabilirii tipurilor de vederi care pot fi actualizate i a celor care nu pot fi actualizate este, de muli ani, un important subiect de cercetare n domeniul bazelor de date relaionale. Vederile actualizabile i standardul ANSI/ISO Standardul ANSI/ISO precizeaz c o vedere este actualizabil dac satisface urmtoarele condiii: Nu trebuie s conin clauza DISTINCT; liniile duplicat nu trebuie eliminate din rezultatul interogrii. Clauza FROM trebuie s conin o singur tabel; aadar vederea trebuie s aib o singur tabel surs. Dac tabela surs este, la rndul ei, o vedere atunci fiecare element din lista de selecie trebuie s fie o referin la o coloan; lista de selecie nu poate conine expresii, cmpuri calculate sau funcii de agregare. Clauza WHERE nu trebuie s includ subinterogri. Interogarea nu trebuie s cuprind clauzele GROUP BY sau HAVING. Conceptul care st la baza acestor restricii este mai uor de memorat dect regulile: pentru ca o vedere s fie actualizabil, SGBD-ul trebuie s poat identifica, pentru fiecare linie din vedere, linia corespunztoare din tabela surs. Similar, SGBD-ul trebuie s poat stabili, pentru fiecare coloan din vedere, coloana corespunztoare din tabela surs. Dac o vedre ndeplinete aceste criterii, atunci putem defini pentru aceasta operaii de adugare, tergere sau actualizare. Vederi actualizabile i clauza CHECK Dac o vedere este definit pe baza unei interogri care conine clauza WHERE, numai acele linii din tabela surs care satisfac condiia se selecie vor fi vizibile n vedere. De exemplu, vederea EASTREPS, definit anterior n acest paragraf, conine numai acele linii din tabela SALEREPS care au anumite valori pentru coloana REP_OFFICE. S se creeze o vedere corespunztoare agenilor de vnzri din regiunea EASTERN.

Aceasta este o vedere actualizabil. Putem aduga un nou agent de vnzri, cu o instruciune INSERT:

11

SGBD-ul va aduga noua linie n tabela SALESREPS, iar aceast linie va fi vizibil n vederea EASTREPS. Dar s vedem ce se va ntmpla cnd adugm o nou linie n vederea EASTREPS, cu aceast instruciune INSERT:

Aceasta este o instruciune SQL corect, i SGBD-ul va aduga o nou linie n tabela SALESREPS. Totui, linia nou adugat nu ndeplinete condiia de selecie din clauza WHERE a definiiei vederii. Valoarea coloanei REP_OFFICE (21) corespunde biroului din Los Angeles, care este situat n regiunea Western. Ca urmare, linia nou adugat nu apare n vedere.

Acelai lucru se ntmpl i dac modificm biroul asignat unui agent de vnzri care apare n vedere.

Aceast instruciune UPDATE modific una dintre coloanele corespunztoare liniei lui Bob Smith i determin dispariia acestei linii din vedere.

12

De fapt, eliminarea unor linii din vedere, ca rezultat al operaiilor INSERT sau UPDATE, poate produce confuzii. Am vrea ca SGBD-ul s detecteze i s previn apariia acestui tip de operaii INSERT sau UPDATE. SQL ne permite s specificm acest tip de restricii asupra vederilor, prin includerea n definiia vederii a unei clauze check. Clauza check este specificat n instruciunea CREATE VIEW, ca n urmtorul exemplu:

Cnd clauza check este inclus n definiia unei vederi, SQL verific automat fiecare operaie INSERT sau UPDATE referitoare la vederea respectiv pentru a se asigura c liniile respective ndeplinesc condiiile de selecie din definiia vederii. Dac una dintre liniile adugate sau modificate nu satisface aceste condiii, instruciunea INSERT sau UPDATE eueaz. Standardul SQL2 permite adugarea unei opiuni suplimentare la clauza check: CASCADED sau LOCAL. Aceast opiune se aplic la crearea unei vederi, cnd vederea respectiv este definit nu pe baza unei tabele de baz ci pe baza uneia sau mai multor vederi definite anterior. Acestea, la rndul lor, ar putea fi definite pe baza altor vederi, .a.m.d. fiecare dintre vederile n cauz pot sau nu s aib specificat clauza check n definiie. Dac noua vedere este creat cu opiunea WITH CASCADED CHECK OPTION, orice ncercare de actualizare a acesteia va determina SGBD-ul s parcurg ntreaga ierarhie a definiiilor vederilor pe care se bazeaz i s proceseze clauza check pentru fiecare dintre ele. Dac vederea nou este creat cu opiunea WITH LOCAL CHECK OPTION, atunci SGBD-UL verifica numai aceast vedere. Standardul SQL2 precizeaz ca opiune implicit opiunea CASCADED.

13

tergerea unei vederi (DROP VIEW) Standardul SQL2 ofer suport pentru tergerea unei vederi, prin intermediul instruciunii DROP VIEW. De asemenea, furnizeaz suport pentru controlul tergerii unei vederi de a crei definiie depind alte vederi. De exemplu, s considerm dou vederi derivate din tabela SALESREPS:

Vederea NYREPS este definita pe baza vederii EASTREPS. Conform standardului SQL2, urmtoarea instruciune DROP VIEW va terge ambele vederi din baza de date:

Opiunea CASCADE i spune SGBD-ului s tearg nu numai vederea n cauz ci i toate vederile care depind de aceasta. Instruciunea DROP VIEW urmtoare: va eua, deoarece clauza RESTRICT n spune SGBD-ului s tearg vederea numai dac nu exist alte vederi care s depind de ea. Standardul SQL2 cere ca una dintre cele dou opiuni RESTRICT sau CASCADE s fie prezent n instruciunea DROP VIEW dar multe dintre produsele comerciale SQL suport o versiune a instruciunii DROP VIEW fr vreo opiune explicit. n acest caz, comportamentul implicit al instruciunii DROP VIEW depinde de fiecare SGBD n parte.

14