1.

INTRODUCERE - SISTEME DE BAZE DE DATE

Sistemele de baze de date sunt o component esenial a vieii de zi cu zi n societatea modern. n cursul unei zile, majoritatea persoanelor desfoar activiti care implic interaciunea cu o baz de date: depunerea sau extragerea unor sume de bani din banc, rezervarea biletelor de tren sau avion, cutarea unei referine ntr-o bibliotec computerizat, cumprarea unor produse etc. Bazele de date pot avea dimensiuni (numr de nregistrri) extrem de variate, de la cteva zeci de nregistrri (de exemplu, baza de date pentru o agend cu numere de telefon) sau pot ajunge la zeci de milioane de nregistrri (de exemplu, baza de date de plat pentru plata taxelor i a impozitelor). Utilizatorii unei baze de date au posibilitatea s efectueze mai multe categorii de operaii asupra datelor memorate: Introducerea de noi date (insert); tergerea unora din datele existente (delete); Actualizarea datelor memorate (update); Interogarea bazei de date (query) pentru a regsi anumite informaii, selectate dup un criteriu ales.

n sensul cel mai larg, o baz de date (database) este o colecie de date corelate din punct de vedere logic, care reflect un anumit aspect al lumii reale i este destinat unui anumit grup de utilizatori. n acest sens, bazele de date pot fi create i meninute manual (de exemplu, fiele de eviden a crilor dintr-o bibliotec, aa cum erau folosite cu ani n urm) sau computerizat, aa cum este majoritatea bazelor de date folosite n momentul de fa. O definiie ntr-un sens mai restrns a unei baze de date este urmtoarea: O baz de date (database) este o colecie de date creat i meninut computerizat, care permite operaii de introducere, tergere, actualizare i interogare a datelor. Simple colecii de fie (documente pe hrtie) sau fiiere de date, care conin nregistrri de date, dar nu permit operaii de interogare, nu sunt considerate baze de date. De exempu, datele memorate n fiiere pe disc de un instrument de calcul tabelar (ca Microsoft Excel) sau documentele memorate de un editor de text (ca Microsoft Word) nu sunt considerate baze de date.

1.1

COMPONENTELE UNUI SISTEM DE BAZE DE DATE

Un sistem de baze de date (Database System) este un sistem computerizat de meninere a evidenei unei anumite activiti, folosind baze de date. Componentele unui sistem de baze de date sunt: hardware, software, utilizatori, date persistente. Hardware. Sistemele de baze de date sunt instalate, de regul, pe calculatoare de uz general, de la calculatoare PC standard, pn la staii multiprocesor puternice. Bineneles, performanele generale de operare ale calculatorului (numrul i viteza procesoarelor, dimensiunea i viteza de operare a memoriei principale etc.) influeneaz n mod corespunztor performanele sistemului de baze de date. Dar, ceea ce intereseaz n mod deosebit n utilizarea unui calculator pentru un sistem de baze de date, este volumul (capacitatea) memoriei secundare, utilizat pentru memorarea coleciei de date persistente ale bazei de date. Dat fiind c ntr-un sistem de baze de date este necesar accesul rapid la oricare din nregistrrile de date, pentru memorarea acestora se folosesc discurile magnetice (hard-discuri). Benzile magnetice (care ofer acces secvenial la nregistrrile de date) sunt utilizate numai pentru duplicarea (back-up) i salvarea/restaurarea datelor. Software. ntre baza de date (colecia de date memorate fizic n fiiere pe hard-discuri) i utilizatorii sistemului exist un nivel software, numit Sistem de Gestiune a Bazei de Date (SGBD) - (Database Management System -DBMS) - (fig. 1.1). Baza de date
Utilizator final Program aplicaie Date Date

SGBD
Date Date

Fig. 1.1. Componente ale unui sistem de baze de date.

Sistemul de gestiune a bazei de date - SGBD - (Database Management System - DBMS) recepioneaz cererile utilizatorilor de acces la baza de date (pentru operaii de introducere, tergere, modificare sau interogare), le interpreteaz, execut operaiile corespunztoare i returneaz rezultatul ctre utilizatori. Sistemul SGBD ofer utilizatorilor o viziune (vedere - view) a bazei de date la un nivel nalt i i elibereaz de necesitatea de a cunoate organizarea particular a sistemului (driverele de disc, structura nregistrrilor de date, etc.).

Mai mult, sistemul de gestiune asigur protecia datelor fa de accese neautorizate sau defecte de funcionare, asigurnd integritatea bazei de date. Pe lng SGBD, care este cea mai important component software a unui sistem de baze de date, mai exist i alte componente: sistemul de operare, care asigur controlul execuiei programelor, biblioteci i instrumente software (toolset-uri) pentru proiectarea, dezvoltarea sau exploatarea sistemelor de baze de date i a aplicaiilor de baze de date. O aplicaie de baze de date (Database Application) este un program care ofer o anumit utilizare a unei baze de date. De exemplu, programul care permite meninerea i urmrirea activitii angajailor unei ntreprinderi (ncadrare, calificare, salarizare, etc.) folosind informaiile despre angajai memorate ntr-o baz de date reprezint o aplicaie de baze de date. Utilizatorii unui sistem de baze de date se pot mpri n cteva categorii: programatorii de aplicaii, utilizatorii finali i administratorul bazei de date. Programatorii de aplicaii sunt cei care scriu (dezvolt) aplicaiile de baze de date, folosind limbaje de programare de nivel nalt (Cobol, PL/1, Fortran, C, C++, Java, Basic) i biblioteci care permit ncorporarea operaiilor de acces la baza de date. Aplicaiile rezultate pot fi aplicaii cu execuie independent (batch-processing) sau pot fi aplicaii interactive (on-line) folosite de utilizatorii finali ai sistemului pentru a accesa (ntr-un mod mai eficient i mai sigur) baza de date. Utilizatorii finali sunt acei utilizatori care acceseaz baza de date prin intermediul unui program de aplicaie care le confer drepturi limitate de acces la date pentru anumite operaii de prelucrare. Utilizatorii finali sunt persoane cu pregtire tehnic minimal, care efectueaz un volum mare de operaii asupra bazei de date, dar nu trebuie s cunoasc mai mult dect posibilitile oferite de programul pe care l utilizeaz. De exemplu, utilizatorii finali ai unui sistem de rezervare a bietelor de avion sunt agenii de vnzri, care folosesc programul adecvat (scris de programatorii de aplicaii), fr a fi necesar s cunoasc ntreaga structur a bazei de date. Administratorul bazei de date (Database Administrator) este o persoan (sau un grup de persoane) cu nalt calificare tehnic care are ca sarcin meninerea funcionalitii bazei de date prin stabilirea drepturilor de acces ale diferitelor categorii de utilizatori, prin efectuarea operaiilor periodice de salvare a datelor (backup), prin monitorizarea performanelor sistemului i refacerea datelor atunci cnd este necesar. Datele memorate ntr-o baz de date sunt date persistente, adic date care rmn memorate pe suport magnetic, independent de execuia programelor de aplicaii. Datele persistente ale unei baze de date se introduc, se terg sau se actualizeaz folosind date de intrare (provenite de la tastatur, din citirea unor fiiere de date sau din recepionarea unor mesaje). Datele de intrare sunt, n general, date nepersistente; ele sunt generate de utilizatori i sunt memorate (devenind date persistente) numai dup ce au fost validate (acceptate) de ctre SGBD. Datele de ieire ale unui sistem de baze de date sunt, de asemenea, date nepersistente; ele provin din operaii de interogare a bazei de date i sunt puse la dispoziia utilizatorului (sub form de afiri, rapoarte tiprite, etc). Aceste tipuri de utilizatori asigur exploatarea unei baze de date dup ce aceasta a fost proiectat i realizat. Activitatea de proiectare a unei baze de date implic i alte categorii de personal cu nalt calificare tehnic (proiectani, programatori) sau administrativ (administrator de date). Proiectanii bazelor de date au responsabilitatea de a analiza realitatea reprezentat (modelat) de baza de date respectiv, de a identifica datele ce necesit s fie memorate, pentru a asigura meninerea evidenei activitii dorite. Aspecte privind proiectarea bazelor de date vor fi studiate n capitolele urmtoare. Orice SGBD suport dou categorii de limbaje conceptuale: limbaje de descriere a datelor i limbaje de manipulare a datelor. Limbajele de descriere a datelor - LDD - (Data Description Languages - DDL) permit definirea conceptual a datelor, fr referire la modul de memorare fizic a acestora. Limbajele de manipulare a datelor - LMD - (Data Manipulation Languages - DML) permit specificarea operaiilor de introducere, actualizare, tergere i interogare a datelor.

1.2

ARHITECTURA INTERN A SISTEMELOR DE BAZE DE DATE

Arhitectura intern a unui sistem de baze de date propus prin standardul ANSI/X3/SPARC (1975) conine trei niveluri funcionale: nivelul extern, nivelul conceptual i nivelul intern (fig. 1.2). Nivelul extern este o colecie de scheme externe, care sunt vederi ale diferitelor grupuri de utilizatori, existnd cte o vedere individual a datelor pentru fiecare grup; nivelul conceptual conine schema conceptual (logic) a bazei de date, iar nivelul intern conine schema intern (fizic) a bazei de date. O schem extern (vedere utilizator) (external schema, users view) conine o subschem conceptual a bazei de date, mai precis descrierea datelor care sunt folosite de acel grup de utilizatori. Schema conceptual a bazei de date (conceptual schema) corespunde unei reprezentri unice (pentru toi utilizatorii) i abstracte a datelor, descriind ce date sunt stocate n baza de date i care sunt asocierile dintre acestea. Schema intern (fizic) a bazei de date (internal schema) specific modul de reprezentare a datelor pe suportul fizic. Un sistem de baze de date suport o schem intern, o schem conceptual i mai multe scheme externe; toate aceste scheme sunt descrieri diferite ale aceleiai colecii de date, care exist doar n nivelul intern.

Nivelul extern

Vedere utilizator #1

Vedere utilizator #2

Vedere utilizator #n

Nivelul conceptual

Schema conceptual

SGBD
Nivelul intern Schema intern

Date memorate Fig. 1.2. Arhitectura intern a unui sistem de baze de date.

Toate aceste reprezentri ale datelor sunt gestionate de ctre SGBD care asigur, de asemenea, i cele dou corespondene (mappings): ntre schemele externe i schema conceptual i ntre schema conceptual i schema intern. Unele sisteme SGBD nu separ complet cele trei niveluri funcionale ale bazelor de date, existnd posibilitatea de a specifica detalii ale schemei interne sau ale schemelor externe n cadrul schemei conceptuale.

1.3

AVANTAJELE OFERITE DE SISTEMELE DE BAZE DE DATE

Fa de vechile metode de nregistrare a datelor privind diferite activiti pe fie (documente scrise) sau chiar n fiiere pe disc, sistemele de baze de date ofer avantaje considerabile, ceea ce explic extinsa utilizare a acestora. Cteva dintre avantajele oferite sunt prezentate n continuare. Compactitate ridicat: volumul ocupat de sistemele de baze de date este mult mai redus dect volumul ocupat de documente scrise sau de fiiere necorelate. Vitez mare de regsire i actualizare a informaiilor. Redundan sczut a datelor memorate, care se obine prin partajarea datelor ntre mai muli utilizatori i aplicaii. n stocarea pe fie sau n fiiere a datelor, fiecare aplicaie coninea propriile seturi de date. n sistemele de baze de date, mai multe aplicaii pot folosi date comune, memorate o singur dat. De exemplu, o aplicaie de personal i o aplicaie de rezultate la examene dintr-o universitate care exploateaz o singur baz de date, pot folosi aceleai informaii referitoare la structurarea facultilor i a seciilor. Posibilitatea de introducere a standardelor privind modul de stocare a datelor, ceea ce permite interschimbul informaiilor ntre diferite organizaii. Meninerea integritii datelor prin politica de securitate (drepturi de acces difereniate n funcie de rolul utilizatorilor), prin gestionarea tranzaciilor i prin refacerea datelor n caz de funcionare defectuoas a diferitelor componente hardware sau software. Independena datelor fa de suportul hardware utilizat. Sistemele de gestiune a bazelor de date ofer o vedere (view) extern a datelor, care nu se modific atunci cnd se schimb suportul de memorare fizic, ceea ce asigur imunitatea structurii bazei de date i a aplicaiilor la modificri ale sistemului hardware utilizat.

1.4

CLASIFICAREA SISTEMELOR DE BAZE DE DATE

Se pot lua n consideraie mai multe criterii de clasificare ale sistemelor de baze de date. Clasificare dup modelul de date. Majoritatea sistemelor de baze de date actuale sunt realizate n modelul de date relaional sau n modelul de date obiect. Dezvoltarea continu a acestor modele a condus ctre o nou categorie de baze de date, numite obiect-relaionale, care combin caracteristicile modelului relaional cu cele ale modelului obiect. De asemenea, mai sunt nc n funciune baze de date n modele mai vechi (modelul ierarhic sau modelul reea). Modelele de date utilizate de sistemele SGBD vor fi prezentate n seciunea urmtoare. Clasificare dup numrul de utilizatori. Majoritatea sistemelor de baze de date sunt sisteme multiutilizator, adic permit accesul concurent (n acelai timp) a mai multor utilizatori la aceeai baz de date. Un numr redus de sisteme de baze de date sunt de tip monoutilizator, adic suport accesul doar al unui singur utilizator (la un moment dat). Clasificare dup numrul de staii pe care este stocat baza de date. Exist dou categorii de sisteme de baze de date: centralizate i distribuite. Un sistem de baze de date centralizat (Centralized Database System) este un sistem de baze de date n care datele i sistemul de gestiune sunt stocate pe o singur staie (calculator).

Un sistem centralizat poate suporta unul sau mai muli utilizatori, dar, n orice situaie, datele i sistemul de gestiune rezid n ntregime pe o singur staie. Un sistem de baze de date distribuit (Distributed Database System) poate avea att datele, ct i sistemul de gestiune, distribuite n mai multe staii interconectate printr-o reea de comunicaie. Sistemele de baze de date pot fi reprezentate din punct de vedere al funcionrii lor printr-o arhitectur de tip client-server. ntr-un sistem centralizat (fig. 1.3) exist un singur server, care este chiar sistemul SGBD, care rspunde cererilor unui singur client (n sistemele mono-utilizator, fig. 1.3, a) sau mai multor clieni (n sistemele multi-utilizator, fig. 1.3, b), care acceseaz baza de date respectiv. Clienii sunt programe de aplicaii oferite de furnizorul sistemului de gestiune sau dezvoltate de programatori. Aplicaiile client pot fi executate pe staii diferite, conectate printr-o reea de comunicaie cu staia pe care ruleaz serverul. Aceast arhitectur permite o prelucrare distribuit a datelor i, mai mult, o configurare a sistemului adaptat cerinelor de calcul particulare. Astfel, serverul bazei de date poate fi un sistem puternic, echipat corespunztor (cu volum mare de memorie secundar), n timp ce fiecare client este o staie personal, cu putere de calcul adecvat aplicaiei executate.
Aplicaie Client Aplicaie Client Aplicaie Client Aplicaie Client

Reea de comunicaie Server Server

SGBD
BD

SGBD
BD

b a Fig. 1.3. Sisteme de baze de date centralizate: a- monoutilizator; b- multiutilizator.

Sistemele de baze de date distribuite pot fi reprezentate ntr-un mod asemntor din perspectiva structurrii client-server (fig. 1.4). O baz de date distribuit este o colecie de date care aparin din punct de vedere logic aceluiai sistem, dar care pot s fie, din punct de vedere fizic, memorate n mai multe staii de calcul (locaii - sites) conectate printr-o reea de comunicaie. Sistemul software care gestioneaz o astfel de baz de date se numete Sistem de Gestiune a Bazei de Date Distribuite - SGBDD - (Distributed Database Management System - DDBMS). Aplicaiile client ruleaz pe alte staii din reea i solicit servicii de la sistemul de gestiune distribuit.
Aplicaie Client Aplicaie Client Aplicaie Client Reea de comunicaie Server Server

SGBD
BD

SGBD
BD Fig. 1.4. Sistem de baze de date distribuit.

Exist numeroase avantaje ale sistemelor de baze de date distribuite (creterea capacitii de stocare i prelucrare a datelor, creterea disponibilitii i a partajrii datelor, etc.), dar i o cretere considerabil a complexitii acestora. Cea mai important cerin pe care trebuie s o ndeplineasc sistemele de gestiune a bazelor de date distribuite este de a asigura administrarea transparent a datelor. Transparena se refer la capacitatea unui sistem distribuit de a ascunde detaliile de implementare, astfel nct utilizatorii s poat accesa datele pe baza unui model de nivel nalt, fr a fi necesar cunoaterea exact a modului de amplasare, replicare sau comunicare a datelor. Sistemele de gestiune a bazelor de date distribuite comerciale nu ofer n momentul de fa un nivel suficient de transparen a localizrii datelor, dar dezvoltarea continu a acestora va putea s asigure n viitor aceast cerin.

1.5

MODELAREA DATELOR

Un model este o abstractizare a unui sistem, care capteaz cele mai importante trsturi caracteristice ale sistemului (concepte), relevante din punct de vedere al scopului pentru care se definete modelul respectiv. Tehnica de identificare a trsturilor caracteristice eseniale ale unui sistem se numete abstractizare. Un model de date stabilete regulile de organizare i interpretare a unei colecii de date. n proiectarea bazelor de date se folosesc, de regul, mai multe modele de date, care se pot clasifica n dou categorii: modele conceptuale de nivel nalt i modele specializate. Un model conceptual de nivel nalt al datelor conine o descriere concis a coleciilor de date care modeleaz activitatea dorit (numit schem conceptual de nivel nalt), fr s detalieze modul de reprezentare sau de prelucrare a datelor. Modelele specializate de date (cum sunt: modelul ierarhic, modelul reea, modelul relaional, etc.) impun anumite structuri speciale de reprezentare a mulimilor de entiti i a asocierilor dintre acestea, structuri pe baza crora sunt dezvoltate sistemele de gestiune a bazelor de date. ntr-un astfel de model de date, o baz de date este reprezentat printr-o schem conceptual (logic) specific. Trecerea de la modelul conceptual de nivel nalt la un model de date specific reprezint etapa de proiectare logic a bazei de date care asigur corespondena dintre schema conceptual de nivel nalt a bazei de date i schema conceptual specific modelului de date respectiv.

1.5.1

Modele conceptuale de nivel nalt

Cel mai utilizat model conceptual de nivel nalt este modelul Entitate-Asociere (E-A) care reprezint schema conceptual de nivel nalt a bazei de date prin mulimi de entiti i asocieri dintre acestea. Dezvoltarea acestui model, astfel nct s permit extinderea tipurilor de entiti, este cunosut sub numele de model Entitate-Asociere Extins (EAE). Proiectarea modelului E-A sau al modelului E-AE este, de regul, una din primele etape n proiectarea bazelor de date, etap numit proiectarea schemei conceptuale (care va fi prezentat n Capitolul 7).

1.5.1.1 Modelul Entitate-Asociere

Modelul Entitate-Asociere (Entity-Relationship Model), introdus n 1976 de P.S. Chen [Chen76], este un model conceptual de nivel nalt al unei baze de date, care definete mulimile de entiti i asocierile dintre ele, dar nu impune nici un mod specific de structurare i prelucrare (gestiune) a datelor. Elementele eseniale ale modelului Entitate-Asociere folosit n proiectarea bazelor de date sunt entitile (entities) i asocierile dintre acestea (relationships). O entitate (entity) este orice poate fi identificat n mod distinctiv"; o entitate se refer la un aspect al realitii obiective care poate fi deosebit de restul universului i poate reprezenta un obiect fizic, o activitate, un concept, etc. Orice entitate este descris prin atributele sale. Un atribut (attribute) este o proprietate care descrie un anumit aspect al unei entiti. Atributele prin care este descris o entitate se aleg pe baza criteriului relevanei relativ la domeniul de interes pentru care se definete modelul respectiv, astfel nct s asigure diferenierea acelei entiti fa de restul universului. Toate entitile similare, care pot fi descrise prin aceleai atribute, aparin unui acelai tip de entitate (entity type), iar colecia tuturor entitilor de acelai tip dintr-o baz de date constituie o mulime de entiti (entities set). n general, n modelul E-A se folosete aceeai denumire att pentru un tip de entitate ct i pentru mulimea entitilor de acel tip. De exemplu, tipul de entitate angajat (al unei instituii) reprezint orice persoan angajat a instituiei, care are o anumit funcie i primete un anumit salariu. Acest tip de entitate poate fi descris prin mai multe atribute, dintre care o parte sunt atribute de identificare a persoanei (Nume,Prenume,DataNasterii,Adresa), iar altele sunt atribute legate de activitatea acesteia n instituia respectiv (Functie,Salariu). Prin analogie cu modelul obiect, se poate spune c un tip de entitate corespunde unei clase, o entitate este o instan a unui tip de entitate i corespunde unui obiect, iar mulimea entitilor de un tip dat corespunde mulimii obiectelor (instanelor) unei clase. n proiectarea bazelor de date se consider dou categorii de entiti: entiti normale (puternice, obinuite regular entities) i entiti slabe (dependente - weak entities). Entitile normale au o existen proprie n cadrul modelului, n timp ce entitile slabe nu pot exista dect dac exist o entitate normal (puternic) cu care sunt asociate. De exemplu, o entitate dependent poate s reprezinte o persoan care depinde de un angajat al unei instituii (adic se afl n ntreinerea acestuia). O entitate angajat este o entitate puternic, deoarece ea exist n mod normal n modelul activitii instituiei, n timp ce o entitate dependent este o entitate slab: nu se va nregistra o astfel de persoan dect dac printele (susintorul) acesteia este angajat n acea instituie. n proiectarea bazelor de date se definesc asocieri ntre mulimile de entiti componente, pentru a reprezenta anumite aspecte ale realitii pe care baza de date o modeleaz. O asociere (relationship) este o coresponden ntre entiti din dou sau mai multe mulimi de entiti.

Gradul unei asocieri este dat de numrul de mulimi de entiti asociate. Asocierile pot fi binare (de gradul 2, ntre 2 mulimi de entiti) sau multiple (ntre k mulimi de entiti, k > 2). Asocierile binare sunt, la rndul lor, de trei categorii, dup numrul elementelor din fiecare dintre cele dou mulimi puse n coresponden de asocierea respectiv (fig. 1.5). Fiind date dou mulimi de entiti, E1 i E2, se definesc urmtoarele categorii de asocieri binare: Asocierea unul-la-unul (one-to-one) este asocierea prin care unui element (entitate) din mulimea E1 i corespunde un singur element din mulimea E2, i reciproc; se noteaz cu 1:1. Asocierea unul-la-multe (one-to-many) este asocierea prin care unui element din mulimea E1 i corespund unul sau mai multe elemente din mulimea E2, dar unui element din E2 i corespunde un singur element n mulimea E1; se noteaz cu 1:N. Asocierea multe-la-multe (many-to-many) este asocierea prin care unui element din mulimea E1 i corespund unul sau mai multe elemente din mulimea E2 i reciproc; se noteaz cu M:N. Cardinalitatea (multiplicitatea) unei asocieri fa de o mulime de entiti (cardinality, multiplicity) este numrul maxim de elemente din acea mulime care pot fi asociate cu un element din alt mulime a asocierii. Aa e11 e12 e13 e14 E1 r1 r2 r3 r4 e21 e22 e23 e24 E2 e11 e12 e13 Ab r1 r2 r3 r4 r5 r6 r7 E2 e21 e22 e23 e24 e25 e26 e27 Ac r1 r2 r3 r4 r5 r6 r7 e21 e22 e23 e24 e25 e26

e11 e12 e13 e14

E1

E1

E2

c a b Fig. 1.5. Categorii de asocieri ntre dou mulimi de entiti: a - asociere 1:1; b - asociere 1:N; c- asociere M:N.

De exemplu, asocierea 1:N dintre mulimile E1 i E2 prezint multiplicitatea 1 fa de mulimea E1 i multiplicitatea N (se nelege o valoare oarecare N > 1) fa de mulimea E2. Raportul dintre valorile cardinalitilor unei asocieri binare fa de cele dou mulimi de entiti se numete raport de cardinalitate (cardinality ratio). Se poate observa c cele trei categorii de asocieri descrise mai sus difer ntre ele prin raportul de cardinalitate. Asocierile multiple (k-are, k > 2) prezint cte un raport de cardinalitate pentru fiecare pereche de mulimi de entiti pe care le asociaz. O asociere ntre dou sau mai multe mulimi de entiti este, n acelai timp, o asociere ntre tipurile de entiti corespunztoare. Diagrama Entitate-Asociere (Entity-Relationship Diagram) reprezint modelul Entitate-Asociere prin mulimile de entiti i asocierile dintre acestea. Exist numeroase variante de notaii pentru redarea diagramei E-A. Una dintre cele mai folosite notaii reprezint un tip de entitate (precum i mulimea de entiti de acel tip) printr-un dreptunghi, iar atributele tipului de entitate prin elipse conectate printr-o linie continu la acesta (fig. 1.6). Pentru entitile puternice se utilizeaz un dreptunghi ncadrat cu o linie simpl, iar pentru entitile slabe se utilizeaz un dreptunghi ncadrat cu linie dubl. Tip entitate

Tip de entitate puternic Tip de entitate slab

Tip entitate Nume atribut E1

1

Atribut
N

E2

Asociere binar 1:N ntre 2 tipuri de entiti

Fig. 1.6. Notaiile diagramei Entitate-Asociere (E-A).

O asociere (tip de asociere) dintre dou sau mai multe tipuri de entiti se reprezint printr-un romb conectat prin link-uri (linii continue, formate din unul sau mai multe segmente) la tipurile de entiti asociate. O asociere poate

s aib sau nu un nume; dac are un nume, acesta poate fi nscris n rombul respectiv sau n vecintatea acestuia. Categoria asocierii se noteaz prin nscrierea multiplicitii pe fiecare link care conduce la un tip de entitate. Este posibil ca o asociere s prezinte ea nsi atribute, i aceste atribute se reprezint prin elipse conectate la asocierea respectiv. Exemplul 1.1. n continuare se exemplific dezvoltarea modelului conceptual de nivel nalt al unei baze de date a unei instituii i diagrama E-A corespunzatoare, definind cteva tipuri de entiti i asocierile ntre acestea. Diagrama E-A a acestui mic model de baz de date este prezentat n figura. 1.7.
Numr Buget Nume Salariu

SECTIE

N 1 Intretine N DEPENDENT

ANGAJAT M Lucreaza N PROIECT

Cuprinde

Nume

GradRudenie

Nume

Buget

Fig. 1.7. Exemplu de diagram E-A.

Tipul de entitate secie reprezint o unitate de organizare a instituiei i este un tip de entitate puternic (de sine stttoare). Acest tip se caracterizeaz prin mai multe atribute, de exemplu, un numr al seciei, numele seciei i bugetul alocat. Mulimea de entiti care grupeaz toate entitile de acest tip se poate denumi SECTIE sau SECTII (oricare variant poate fi folosit) i este caracterizat prin aceleai atribute care caracterizeaz tipul entitii:
SECTIE(Numar,Nume,Buget)

Tipul de entitate angajat reprezint o persoan angajat n instituie i este de asemenea un tip de entitate puternic. Acest tip de entitate, ca i mulimea de entiti care grupeaz toate entitile de acest tip, se poate defini astfel
ANGAJAT(Nume,Prenume,DataNasterii,Adresa,Functie,Salariu)

Tipul de entitate proiect reprezint o activitate a instituiei, i este de asemenea un tip de entitate puternic, care poate fi caracterizat prin numele proiectului, data nceperii, termen de realizare, bugetul proiectului:
PROIECT(Nume,DataInceperii,Termen,Buget)

Tipul de entitate dependent reprezint o persoan care depinde de un angajat al instituiei (adic se afl n ntreinerea acestuia). Acest tip de entitate este un tip de entitate slab: nu se va nregistra o astfel de persoan dect dac ntreintorul acesteia este angajat n acea instituie. Acest tip se poate defini astfel:
DEPENDENT(Nume,Prenume,DataNasterii,GradRudenie)

Asocierea SECTIE-ANGAJAT este o asociere 1:N, dac se consider c o secie cuprinde mai muli angajai, iar un angajat aparine unei singure secii. Asocierea ANGAJAT-PROIECT este o asociere M:N, dac se consider c la fiecare proiect lucreaz mai muli angajai, i fiecare angajat poate lucra la mai multe proiecte. Asocierea ANGAJAT-DEPENDENT este o asociere de tipul 1:N, deoarece un angajat poate ntreine mai multe persoane (fii, prini etc.), iar o persoan dependent este n ntreinerea unui singur susintor. Raportul de cardinalitate al unei asocieri este stabilit de proiectant astfel nct s reflecte ct mai corect modul de organizare a activitii modelate. De exemplu, asocierea ANGAJATI-PROIECTE are raportul de cardinalitate M:N dac n instituia respectiv se admite ca un angajat s lucreze la mai multe proiecte; dac s-ar impune ca un angajat s lucreze la un singur proiect, atunci asocierea respectiv ar avea raportul de cardinalitate N:1. n ambele situaii se admite c la un proiect lucreaz mai muli angajai. Sunt de remarcat cteva caracteristici generale ale modelului E-A: a) Modul de stabilire a tipurilor de entiti i a asocierilor dintre acestea nu este unic, deoarece grania dintre entiti i asocieri nu este, n general, una bine precizat. Aceeai funcionalitate se poate obine printr-o varietate de diagrame E-A, depinznd de felul n care proiectantul dezvolt modelul conceptual. O asociere poate fi considerat i ca un tip de entitate. De exemplu, pentru baza de date a unei faculti (coli) se definesc tipurile (mulimile) de entiti:

STUDENTI(Nume,Prenume,Adresa,...) DISCIPLINE(Denumire,Credite,...)

ntre aceste mulimi de entiti se poate defini asocierea STUDENTI-DISCIPLINE, cu raportul de cardinalitate M:N. Aceast asociere reprezint (n general) studierea unor discipline de ctre studeni, cu atribute ca: Nota (examenului la disciplina respectiv), DataExamen, etc. Dar, la fel de bine, este posibil s se defineasc tipul de entitate NOTE, aflat n asociere N:1 cu fiecare din tipurile de entiti STUDENTI i DISCIPLINE (fig. 1.8).
Studiaza STUDENTI M N

DISCIPLINE
N 1

(a)

STUDENTI

NOTE

DISCIPLINE

(b)

Fig. 1.8. Diferite moduri de definire a tipurilor de entiti i a asocierilor: a- asociere M:N ntre mulimile de entiti STUDENTI i DISCIPLINE; b - mulimea de entiti EXAMENE este asociat cu raportul de cardinalitate N:1 cu fiecare din mulimile de entiti STUDENTI i DISCIPLINE.

b) n modelul E-A, tipul de entitate (i mulimea de entiti corespunztoare) semnific un substantiv, n timp ce o asociere semnific un verb. Bineneles, nu este obligatoriu ca numele dat unei asocieri s fie un verb (i, de cele mai multe ori, nici nu este), dar o asociere reprezint o interaciune ntre tipurile de entiti (i mulimile de entiti corespunztoare), care poate fi exprimat printr-un verb. De exemplu, n diagrama E-A din figura 1.7, asocierea SECTIE-ANGAJAT poate fi exprimat prin verbul cuprinde, asocierea ANGAJATI-DEPENDENTI poate fi exprimat prin verbul ntreine, asocierea ANGAJATI-PROIECTE poate fi exprimat prin verbul lucreaz etc. c) Modelul E-A nu precizeaz modul cum sunt realizate asocierile ntre mulimile de entiti. Acest aspect depinde de modelul de date specializat utilizat pentru definirea bazei de date. De exemplu, n modelele ierarhic i reea, asocierile sunt realizate explicit, prin pointeri de la o entitate la entitile asociate, n timp ce n modelul relaional asocierea se realizeaz prin egalitatea valorilor unor atribute comune ale entitilor (chei). 1.5.1.2 Modelul Entitate-Asociere Extins Modelul Entitate-Asociere Extins (Enhanced Entity-Relationship Model) permite definirea de subtipuri ale unui tip de entiti, care motenesc atribute de la tipul de entitate pe care il extind (i care, n acest context, se numete supertip) i au n plus atribute specifice semnificaiei lor. Prin definirea tipurilor i a subtipurilor de entiti se pot crea ierarhii de tipuri de entiti pe mai multe niveluri. Modelul E-A prezentat n capitolul precedent este suficient pentru modelarea aplicaiilor de baze de date tradiionale, adic bazele de date utilizate pentru activiti financiare i industriale, n care se folosesc tipuri de date simple. Odat cu dezvoltarea sistemelor de baze de date, domeniile n care acestea se folosesc au devenit tot mai numeroase, ca, de exemplu: telecomunicaiile, proiectarea tehnologic, sistemele de informaii geografice, seviciul Web, etc. Tipurile de entiti definite n astfel de baze de date sunt mult mai complexe i pentru reprezentarea lor ct mai intuitiv i mai compact au fost propuse mai multe concepte noi, care au fost introduse n modelul E-A extins. Modelul E-A extins se reprezint printr-o diagram E-A extins. Ierarhiile de tipuri se pot crea prin specializare sau generalizare. Specializarea (specialization) este un proces de abstractizare a datelor prin care, pornind de la un tip de entitate dat, se definesc unul sau mai multe subtipuri, difereniate ntre ele n funcie de rolul specific pe care l au n modelul de date. De exemplu, pornind de la tipul de entitate ANGAJAT se definesc prin specializare subtipurile SECRETARA, TEHNICIAN, INGINER, pentru a diferenia funciile pe care angajaii le pot avea n ntreprinderea respectiv (fig. 1.9). Litera d din marcajul de specializare a tipurilor indic o constrngere de disjuncie impus specializrii, care va fi descris mai jos. Subtipurile de entiti motenesc atribute ale tipului iniial i fiecare dintre ele are atribute suplimentare, specifice rolului lor. De exemplu, atributele (Nume,Prenume,DataNasterii,Adresa,Salariu) ale tipului de entitate ANGAJAT sunt motenite de fiecare din subtipurile acestuia. Atributul Functie nu este motenit, deoarece specializarea subtipurilor s-a efectuat dup acest atribut. Ca atribute specifice, subtipul SECRETARA are atributul VitezaRedactare, care este o msur a calificrii, subtipul TEHNICIAN are atributul Calificare, care reprezint gradul de calificare, iar subtipul INGINER are atributul Specialitate, care este o precizare a domeniului in care lucreaz (mecanic, electric, etc.). Generalizarea (generalization) este procesul de abstractizare invers specializrii, prin care se creaz un supertip de entitate pornind de la mai multe tipuri de entiti. Pentru definirea unei generalizri, se identific atributele comune ale mai multor tipuri de entiti i aceste atribute vor caracteriza supertipul de entitate, iar atributele care difer de acestea rmn specifice fiecrui tip. 8

De exemplu, dac au fost definite tipurile de entiti: AUTOMOBIL (NrInregistrare, Marca, VitezaMaxima, Pret, NumarPasageri) i CAMION(NrInregistrare,Marca,VitezaMaxima,Pret,Tonaj), se poate defini un supertip al acestor tipuri: VEHICUL(NrInregistrare,Marca, VitezaMaxima,Pret). Acest tip va cuprinde toate atributele comune, iar tipurile iniiale, AUTOMOBIL i CAMION, devin subtipuri ale tipului VEHICUL, fiecare coninnd atributele specifice (NumarPasageri pentru tipul AUTOMOBIL i Tonaj pentru tipul CAMION). Rezultatul obinut prin generalizare este, ca i n cazul specializrii, o ierarhie de tipuri de entiti; ceea ce difer este modul n care se definesc nivelurile ierarhiei.
Nume Prenume DataNasterii ANGAJAT d Adresa Salariu

SECRETARA VitezaRedactare

TEHNICIAN Calificare

INGINER Specialitate

Fig.1.9. Diagrama E-A extins cu ierarhie de tipuri de entiti.

Motenirea atributelor. Proprietatea principal a ierarhiilor de tipuri de entiti create prin specializare sau generalizare este motenirea atributelor: atributele tipurilor de entiti de nivel ridicat (supertipuri) sunt motenite de tipurile de entiti de nivel sczut (subtipuri). Motenirea dintre un subtip de entiti i supertipul acestuia se reprezint n diagrama E-A extins printr-o legtur (link) ntre subtip i supertipul de entitate corespunztor pe care este plasat un semicerc orientat ctre subtip (aa cum se poate vedea n figura 1.9). Este evident asemnarea dintre ierarhiile de tipuri de entiti din modelul E-A extins i ierarhiile de clase din modelul obiect-orientat, dar modelul E-A extins este un model de date mult mai general (de nivel inalt), care poate fi transpus n diferite modele de date specializate, inclusiv modelul obiect-orientat. Aceste transpuneri se fac n funcie de suportul oferit de modelul specializat respectiv pentru reprezentarea entitilor, asocierilor, motenirilor, etc. 1.5.1.3 Modelul de date ierarhic n modelul ierarhic (Hierarchical Model) o baz de date se reprezint printr-o structur ierarhic de nregistrri de date (records) conectate prin legturi (links). Modelul de date ierarhic a fost primul model folosit pentru dezvoltarea bazelor de date. Cea mai cunoscut realizare de SGBD ierarhic este sistemul IMS (Information Management System) dezvoltat de firma IBM n cadrul programului de cercetri Apollo, n perioada anilor 1960. O nregistrare de date n modelul ierarhic este o instan a unui tip de nregistrare (record type) i const dintro colecie de cmpuri (fields), fiecare cmp coninnd valoarea unui atribut. Un tip de nregistrare corespunde unui tip de entitate, iar o nregistrare corespunde unei entiti din modelul E-A. Un tip de legtur n modelul ierarhic este un tip de asociere cu raportul de cardinalitate 1:N (de tip printefiu) ntre dou tipuri de nregistrri. Tipul de nregistrare din partea cu multiplicitatea 1 a asocierii este numit tip de nregistrare printe, iar tipul din partea cu multiplicitatea N a asocierii este numit tip de nregistrare fiu. Schema conceptual a unei baze de date n modelul ierarhic se reprezint printr-un numr oarecare de scheme ierarhice (fig. 1.12). O schem ierarhic este un arbore direcionat, reprezentat pe mai multe niveluri, n care nodurile sunt tipurile de nregistrri, iar arcele sunt tipurile de legturi. Fiecare nod (cu excepia nodului rdcin) are o singur legtur ctre un nod de pe un nivel superior (nodul printe) i fiecare nod (cu excepia nodurilor frunz) are una sau mai multe legturi ctre noduri de pe nivelul imediat inferior (noduri fii). Se poate stabili o coresponden ntre o schem conceptual ierarhic i o diagram E-A: tipurile de nregistrri corespund tipurilor de entiti, iar tipurile de legturi corespund tipurilor de asocieri. (fig. 1.12, a i b). n modelul ierarhic nu sunt admise dect legturi de tipul printe-fiu, care corespund asocierilor 1:1 i asocierilor 1:N din modelul E-A. Asocierile M:N din modelul E-A nu se pot reprezenta n mod direct n modelul ierarhic, ci numai prin multiplicarea nregistrrilor de tip fiu, atunci cnd sunt referite de mai multe nregistrri de tip printe. Acest lucru conduce la o mare redundan a datelor. Corespunztor schemei ierarhice a unei baze de date se pot reprezenta mai muli arbori de instaniere a datelor, care sunt, de asemenea, arbori direcionai (fig. 1.12, c). Fiecare arbore de instaniere contine ierarhii pe mai multe niveluri de nregistrri ntre care exist legturi de tipul printe-fiu.

FACULTATE FACULTATE 1 N PROFESOR M N STUDENT a STUDENT b PROFESOR FACULTATE

f1

f2

f3
PROFESOR

p1

p2

p3
STUDENT

s1

s2

s3
c

s1

s2

s4

Fig. 1.12. Baz de date ierarhic: a - diagrama E-A; b - schema conceptual a bazei de date ierarhice; c - arbori de instaniere a datelor.

Corespunztor schemei ierarhice a unei baze de date se pot reprezenta mai muli arbori de instaniere a datelor, care sunt, de asemenea, arbori direcionai (fig. 1.12, c). Fiecare arbore de instaniere contine ierarhii pe mai multe niveluri de nregistrri ntre care exist legturi de tipul printe-fiu. Avantajele modelul ierarhic sunt simplitatea i eficiena de calcul, dar n momentul de fa, pentru realizarea bazelor de date sunt preferate modele de date mai puternice (modelul relaional, modelul obiect-orientat). 1.5.1.4 Modelul de date reea Modelul reea (Network Model) folosete o structur de graf pentru definirea schemei conceptuale a bazei de date; nodurile grafului sunt tipuri de entiti (nregistrri - records), iar muchiile grafului reprezint n mod explicit asocierile (legturile-links) dintre tipurile de entiti. Aprut dup modelul ierarhic, modelul reea de reprezentare a bazelor de date a fost standardizat n 1971, de o comisie DBTG (Database Task Group). Modelul reea a avut mai multe implementri ca sisteme de gestiune comerciale: IDS II (Honeywell), UNISYS (Burroughs), IDMS (Computer Associates). Deosebirea fa de modelul ierarhic const n aceea c n modelul reea asocierile M:N se reprezint fr duplicarea nregistrrilor, fiecare nregistrare putnd fi referit de mai multe nregistrri, ceea ce elimin redundana. La fel ca i la modelul ierarhic, dezavantajul principal al modelului reea este acela c fiecare interogare trebuie s fie prevzut nc din faza de proiectare, prin memorarea explicit a legturilor ntre tipurile de entiti. n plus, complexitatea reprezentrii datelor n modelul reea este deosebit de ridicat, iar programatorii trebuie s o cunoasc pentru a putea realiza aplicaiile necesare. n momentul de fa modelul de date reea este foarte rar utilizat pentru baze de date de uz general (care implic operaii de interogare), dar exist unele domenii n care structurarea ca graf a datelor permite o parcurgere eficient a acestora. De exemplu, majoritatea bazelor de date grafice folosite n modelarea scenelor tridimensionale din realitatea virtual sunt baze de date reea [Ion96a]. 1.5.1.5 Modelul de date relaional Modelul relaional (Relational Model) se bazeaz pe noiunea de relaie (relation) din matematic, care corespunde unei mulimi de entiti de acelai tip. Modelul de date relaional a fost propus de cercettorul E.F. Codd de la compania IBM, care a publicat n anul 1970 lucrarea "Un model Relaional de Date pentru Bnci Mari de Date Partajate" [Codd70]. Alte lucrri ale lui Codd, ca i ale altor cercettori (C.J. Date, P. Chen, R. Boyce, J.D. Ullman, R. Fagin, W.W. Armstrong, M. Stonebraker, etc.) au perfecionat modelul de date relaional i au permis dezvoltarea fr precedent a sistemelor de gestiune a bazelor de date, datorit simplitii i a fundamentrii matematice a modelului. Primul Sistem de Gestiune a Bazelor de Date Relaionale (SGBDR) a fost prototipul System R, dezvoltat la compania IBM n anii 1970, dup care numeroase companii au realizat sisteme de gestiune relaionale (Oracle, Microsoft, Ingres, Sybase, etc.) iar aplicaiile de baze de date relaionale au cptat o amploare deosebit. Pe lng avantajul unui model de date precis i simplu, sistemele de baze de date relaionale mai beneficiaz i de un limbaj de programare unanim recunoscut i acceptat, limbajul SQL (Structured Query Language), pentru care au fost emise mai multe standarde de ctre ISO (International Standardization Office). Majoritatea SGBD-urilor relaionale actuale implementeaz versiunea SQL92 (sau SQL2). 1.5.1.6 Modelul de date obiect-orientat Modelul obiect (Object Model) este un concept unificator n tiina calculatoarelor, fiind aplicabil n programare, n proiectarea hardware-ului, a interfeelor, a bazelor de date, etc. Sistemele de baze de date obiect-

10

orientate se bazeaz pe limbaje de programare obiect-orientate cu capaciti de persisten, n care datele sunt independente de timpul de via al programelor care le creeaz, prin memorare pe suport magnetic (disc). Orict de folositor este modelul de date relaional pentru realizarea bazelor de date, exist unele domenii (n special acele domenii n care se manevreaz tipuri de date complexe), n care modelul relaional s-a dovedit a fi insuficient de expresiv i cu performane de execuie reduse. Domenii ca: proiectarea asistat de calculator, sisteme de informaii geografice, medicin (i altele) au impulsionat cercetri pentru gsirea unor modele mai performante, dintre care modelul obiect-orientat i modelul obiect-relaional au cunoscut i cunosc n continuare o dezvoltare semnificativ. Caracteristicile importante ale modelului obiect (abstractizarea, motenirea, ncapsularea, modularitatea) sunt intens dezbtute i analizate mai ales din perspectiva proiectrii i programrii obiect-orientate [Booch87], [Con00]. Din perspectiva realizrii bazelor de date, o alt proprietate a modelul obiect, persistena, este aceea care asigur memorarea transparent pe suport magnetic a obiectelor care alctuiesc o baz de date obiect-orientat. Pentru dezvoltarea unui sistem de gestiune a bazelor de date obiect- orientate (SGBDOO) se poate aborda una din urmtoarele strategii: Extinderea unui limbaj de programare obiect-orientat cu capaciti de administrare a obiectelor persistente. Sistemul GemStone este un astfel de SGBDOO, dezvoltat prin extinderea limbajelor C++ i Java. Extinderea unui limbaj de programare relaional cu capaciti de orientare spre obiecte. Un astfel de limbaj este limbajul ODL (Object Query Language) (sau Object SQL), specificat prin standardul propus de consoriul Object Database Management Group, din care fac parte principalii productori de sisteme de baze de date obiect-orientate. Exist mai multe astfel de sisteme, cum sunt: Ontos, Versant, O2. Dezvoltarea unui limbaj obiect-orientat pentru baze de date complet nou, care s asigure crearea i interogarea obiectelor persistente. Exist i astfel de produse, ca de exemplu sistemul SIM (Semantic Information Manager).

Dintre avantajele cele mai importante ale sistemelor de baze de date dezvoltate n modelul obiect se evideniaz capacitatea acestora de a defini i manevra tipuri de date complexe (clase), care se pot extinde prin mecanismul de motenire, ceea ce contribuie la creterea performanelor n aplicaiile de baze de date avansate. Exist, bineneles, i dezavantaje ale sistemelor de baze de date obiect-orientate, care le fac s aib o utilizare limitat, mult mai redus dect cea a sistemelor de baze de date relaionale (sub 5% din piaa sistemelor de baze de date). Principalul dezavantaj l constitue complexitatea de dezvoltare a bazei de date i a aplicaiilor, datorit faptului c proiectanii i programatorii trebuie s prevad n structura obiectelor toate asocierile (legturile) necesare tuturor interogrilor. Cu ct interogrile sunt mai complexe, cu att sunt necesare mai multe asocieri ntre obiecte i deci se complic structura acestora. La acest dezavantaj se adaug i altele, cum ar fi lipsa unui standard de limbaj de interogare care s fie unanim (sau ct mai larg) acceptat. 1.5.1.7 Modelul de date obiect-relaional Modelul obiect-relaional (Object-Relational Model) reprezint extinderea modelului relaional cu caracteristici ale modelului obiect, extindere necesar pentru realizarea bazelor de date care definesc i prelucreaz tipuri de date complexe. n esen, modelul obiect-relaional pstreaz structurarea datelor n relaii (reprezentate ca tabele), dar adaug posibilitatea definirii unor noi tipuri de date, pentru domeniile de valori ale atributelor. Tipurile de date definite de utilizator pot fi extinse prin mecanismul de motenire i pentru fiecare tip sau subtip se pot defini metode pe care le pot executa obiectele de acel tip. n general, dezvoltarea sistemelor de gestiune a bazelor de date obiect-relaionale (SGBDOR) se realizeaz prin extinderea sistemelor relaionale, de cele mai multe ori n mod gradat, adugndu-se de la o versiune la alta ct mai multe caracteristici posibile ale modelului obiect i pstrnd n continuare toate caracteristicile modelului relaional. O astfel de abordare asigur rularea n continuare a aplicaiilor relaionale existente n noile versiuni de sisteme SGBDOR, ceea ce permite productorilor s-i pstreze clienii i domeniile de utilizare. Mai muli dintre principalii productori de sisteme de gestiune (Oracle, Informix i IBM) au extins n acest mod sistemele lor relaionale pentru a deveni sisteme obiect-relaionale. Este o tendin fireasc, dat fiind c prin aceasta se pstreaz toat experiena i rezultatele obinute cu sistemele relaionale i se pot dezvolta i aplicaii complexe, obiect-relaionale. Standardele limbajelor de programare pentru sistemele de gestiune obiect-relaionale sunt extensii ale standardului SQL (ca de exemplu, versiunea din anul 1999, denumit SQL3). 1.5.1.8 Complexitatea datelor i a interogrilor M. Stonebraker a oferit o reprezentare n patru cadrane a universului bazelor de date (fig. 1.13) deosebit de simpl i de interesant, bazat numai pe complexitatea datelor i a interogrilor [Ston96]. Propus n anul 1996, aceast clasificare nu include modelele prerelaionale (modelul ierarhic i modelul reea), considerate depite n aceast faz de dezvoltare a bazelor de date. Pe abscisa diagramei este reprezentat capacitatea de definire a tipurilor de date complexe, iar pe ordonat este reprezentat capacitatea de interogare a bazelor de date. 11

n cadranul din stnga jos sunt acele aplicaii care prelucreaz tipuri de date simple i nu necesit interogarea datelor. Astfel de tipuri de aplicaii (cum sunt procesoarele de texte Word, Framemaker) folosesc direct sistemul de fiiere al sistemului de operare pentru memorarea datelor persistente.
Complexitatea interogrilor

SGBDR Sisteme de fiiere

SGBDOR SGBDOO
Complexitatea datelor

Fig. 1.13. Clasificarea sistemelor de gestiune a bazelor de date. n cadranul din stnga sus sunt sistemele de gestiune a bazelor de date relaionale (SGBDR), care prelucreaz tipuri simple de date, dar permit interogri complexe. n cadranul din dreapta jos sunt sistemele de gestiune a bazelor de date obiect-orientate (SGBDOO), care prelucreaz tipuri de date complexe, dar n care rezolvarea interogrilor este destul de dificil, dat fiind c pentru fiecare interogare trebuie s fie prevzute legturile necesare n structura obiectelor. n cadranul din dreapta sus sunt reprezentate sistemele obiect-relaionale (SGBDOR), care permit prelucrarea datelor complexe i rezolvarea interogrilor complexe. Modelul obiect-relaional este, evident, cel mai complet, deoarece admite att tipuri de date definite de utilizator ct i interogri complexe. n aceeai lucrare, Stonebraker denumete sistemele de gestiune a bazelor de date obiect-relaionale ca fiind sisteme de baze de date universale. n momentul de fa este evident tendina productorilor de sisteme de gestiune a bazelor de date de a trece la sisteme obiect-relaionale i, n general, aceast trecere se realizeaz prin adugarea treptat a caracteristicilor modelului obiect n sistemele de gestiune relaionale. Oferta de sisteme de gestiune a bazelor de date este deosebit de generoas, pe o scar extins de performane i costuri, de la sisteme care se pot folosi gratuit (fr licen sau cu licen public), pn la sisteme cu nalte performane, a cror utilizare necesit plata licenelor respective. Chiar i pentru astfel de sisteme exist versiuni de test (trial versions) care pot fi obinute gratuit prin Internet (de la adrese care sunt indicate n Bibliografie), astfel nct pot fi folosite pentru a nelege i a executa exemplele propuse n aceast lucrare. Sistemul Oracle este un sistem de gestiune a bazelor de date multi-utilizator puternic, cu implementri pe toate platformele (Windows, Unix, Linux), care ofer att performane de execuie ridicate, ct i un grad nalt de protecie i securitate a datelor. n toate versiunile, Oracle ofer implementarea complet a caracteristicilor modelului relaional (conform standardului SQL2), iar ultimele versiuni (Oracle8i, Oracle9i i Oracle 10g) sunt sisteme de gestiune obiectrelaionale distribuite, implementnd extensiile obiect-orientate prevzute n standardul SQL3 i oferind posibilitatea de dezvoltare a bazelor de date distribuite. Sistemele de gestiune Oracle, ca i diferite instrumente de dezvoltare a aplicaiilor de baze de date (Oracle Application Server, JDeveloper, Oracle Forms etc.), se pot obine de la adresa http://www.oracle.com i termenii licenei permit utilizarea acestor sisteme n scopuri necomerciale pe o perioad nelimitat; pentru utilizarea n scopuri comerciale trebuie s fie pltite licenele corespunztoare SQL Server este sistemul de gestiune a bazelor de date relaionale dezvoltat de firma Microsoft pentru sistemele de operare Windows. Au existat mai multe versiuni, versiunea actual (2007) fiind SQL Server 2005. n toate versiunile sistemul SQL Server suport complet standardul SQL2, cu implementarea performant a trsturilor avansate de stocare i prelucrare a datelor (integritate referenial, subinterogri, triggere, gestiunea tranzaciilor, etc). De la adresa http://www.microsoft.com/sql se poate obine gratuit o versiune de test a sistemului SQL Server sau se poate cumpra o versiune complet. n plus, pachetul de dezvoltare .NET SDK (.NET Software Development Kit), care se poate obine gratuit de la adresa http://msdn.microsoft.com/downloads conine o versiune mai simpl de server de baze de date numit Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) care poate fi folosit pentru dezvoltarea i execuia exemplelor prezentate n lucrare. Microsoft Access este unul din cele mai cunoscute sisteme de gestiune a bazelor de date relaionale pe platforme de calculatoare personale. MS Access dispune de un sistem de control al bazei de date (database engine) i o interfa grafic pentru interaciunea cu utilizatorul. Aplicaiile de baze de date n MS Access se pot dezvolta cu mult uurin datorit generatoarelor de aplicaii (Wizards) care permit proiectarea vizual a bazelor de date i a formularelor (forms) pentru interfeele grafice. MS Access este folosit n special pentru aplicaii personale sau pentru mici afaceri i licena acestuia se poate cumpra odat cu licena produsului Microsoft Office. MySQL este un sistem de gestiune a bazelor de date relaionale cu implementri pentru sistemele de operare Windows, Linux, Unix. La adresa http://www.mysql.com se gsete ultima versiune i documentaia sistemului de gestiune a bazelor de date MySQL care se poate utiliza gratuit (este open source). Acest sistem este compatibil cu standardul SQL2, dar unele prevederi ale standardului sunt implementate parial. Versiunea actual 2007) este versiunea 5.0 care ofera vederi, proceduri stocate, triggere (caracteristici care lipseau in versiunile precedente).

12

2 MODELUL RELAIONAL
Modelul relaional a avut, nc de la apariia sa n anul 1970, o popularitate deosebit de mare, astfel nct majoritatea sistemelor de baze de date care exist i se dezvolt la ora actual sunt sisteme relaionale. Pe lng simplitatea i precizia modului de definire a elementelor de baz ale modelului (relaii, atribute, domenii), exist un suport teoretic substanial pentru realizarea bazelor de date relaionale (constrngerile de integritate, normalizarea relaiilor, controlul concurenei), care permite crearea structurii datelor i a prelucrrii lor ntr-un mod consistent i asigur integritatea i protecia acestora.

2.1

RELAII

O baz de date relaional este compus dintr-o mulime finit de relaii, fiecare relaie reprezentnd un tip de entitate sau o asociere dintre dou sau mai multe tipuri (mulimi) de entiti. Din aceast definiie rezult c ntr-o baz de date fiecare relaie este unic (nu exist dou sau mai multe relaii de acelai fel), dat fiind c o baz de date este o mulime de relaii. O relaie se definete prin intermediul atributelor sale. Atributele unei relaii sunt atributele tipului de entitate sau de asociere pe care l reprezint relaia respectiv. Fiecare atribut al unei relaii are un domeniu de definiie i poate lua o singur valoare (din domeniul su de definiie) pentru fiecare tuplu al relaiei, ceea ce nseamn c atributele au numai valori scalare. Un domeniu de definiie (domain) este o mulime cu nume de valori atomice de acelai tip, avnd o anumit semnificaie, din care i iau valori atributele relaiilor. Nu trebuie confundat atomicitatea din punct de vedere semantic a valorii unui atribut cu atomicitatea structurii de date prin care este reprezentat valoarea acelui atribut n memoria calculatorului. De exemplu, un atribut care desemneaz un nume (de persoan, de instituie, de produs, de component, etc.) se reprezint printr-un ir (vector) de caractere, care, bineneles, poate fi descompus n elementele componente (caracterele), dar sistemul de gestiune nu atribuie nici o semnificaie unui element separat, ci numai ntregii valori (irul de caractere). Schema relaiei (relation schema), notat R(A1,A2,...Ai,...An), este compus din numele relaiei (R) i din lista ordonat a atributelor sale A1,A2,...Ai,..An, fiecare atribut Ai definit pe domeniul su de definiie, D(Ai). Schema relaiei este folosit pentru a descrie relaia respectiv i se mai numete i tipul sau intensiunea relaiei. Numrul de atribute ale schemei unei relaii se numete gradul relaiei. O relaie (relation) R definit de schema R(A1,A2,...Ai,...An) este o mulime de n-tupluri t, fiecare tuplu fiind o list ordonat de n valori t = <v1,v2,...vi,...vn>, unde 1 i n i vi este valoarea atributului Ai, aparinnd domeniului su de definiie D(Ai). Din aceast definiie rezult imediat c ntr-o relaie nu exist tupluri duplicat (dou sau mai multe tupluri identice), relaia fiind o mulime (n sens matematic) de tupluri. De asemenea, rezult c n fiecare tuplu un atribut nu poate lua dect o valoare din domeniul su de definiie, deci un scalar, nu un vector (tablou) de valori. Numrul de atribute ale relaiei se numete gradul relaiei (degree), iar numrul de tupluri se numete cardinalitatea relaiei (cardinality). O relaie corespunde, n general, unei mulimi de entiti din diagrama E-A a unei baze de date, iar un tuplu reprezint o entitate din mulimea de entiti. Atributele tipului de entitate din modelul conceptual de nivel nalt devin atributele relaiei n modelul relaional. Relaia, ca mulime de tupluri, fiecare tuplu fiind compus din valori ale atributelor sale, reprezint o variabil - variabila relaie - care se modific n cursul existenei sale, prin inserarea sau tergerea tuplurilor, sau prin modificarea (actualizarea) valorilor atributelor tuplurilor. Tipul acestei variabile este dat de schema relaiei, care nu se modific o dat ce a fost definit (sau se modific foarte rar). Valoarea la un moment dat a relaiei se mai numete i starea sau extensiunea relaiei. n general, pentru o exprimare mai concis, nu se detaliaz de fiecare dat aceste aspecte i se folosete termenul simplu de relaie, att pentru variabila relaie ct i pentru valoarea relaiei. De asemenea, n multe documentaii, se folosete numai numele relaiei (de exemplu, R), fr lista de atribute, pentru a desemna schema relaiei corespunztoare. Ca exemplu de relaie se definete relaia cu schema ANGAJATI (sau ANGAJAT) corespunztoare tipului de entitate angajat (descris n exemplele prezentate anterior) astfel: ANGAJATI(Nume,Prenume,DataNasterii,Adresa,Functie,Salariu) Domeniile de definiie ale atributelor se specific prin numele domeniului, semnificaia acestuia, tipul de date i restricii asupra valorilor n cadrul acelui tip de date. Exemple de domenii relaionale ale atributelor:

D_Nume: domeniul numelor de persoane reprezentate printr-un ir de maximum 20 caractere, n care primul caracter este liter mare, iar celelalte pot fi litere mari sau mici. D_Data: domeniul datelor calendaristice, reprezentate prin 3 numere ntregi, separate prin linii de desprire(-); primul numr reprezint anul i este format din patru cifre; al doilea numr reprezint luna i are valori cuprinse ntre 01 i 12; al treilea numr reprezint ziua i are valori cuprinse ntre 01 i 31. D_Salariu: domeniul salariului, reprezentat printr-un numr zecimal.

Domeniile de definiie a atributelor, D(A1),D(A2),...D(An), nu trebuie s fie neaprat distincte. Atributele Nume i Prenume din relaia ANGAJATI se pot defini pe acelai domeniu, domeniul D_Nume; atributul DataNasterii se definete pe domeniul D_Data, etc. Cel mai frecvent ns, n implementarea modelului relaional n cadrul diferitelor sisteme de gestiune a bazelor de date, ca domenii de definiie ale atributelor se folosesc direct tipurile de date predefinite ale limbajului de definiie a datelor (LDD) specific acelui SGBD. Acest mod simplificat de tratare a domeniilor de definiie a atributelor va fi evideniat n continuare, n seciunea dedicat limbajului SQL.

2.1.1

Reprezentarea relaiilor prin tabele

Un tabel (table) este o reprezentare a unei relaii i este compus din urmtoarele pri: Numele tabelului, care este identic cu numele relaiei pe care o reprezint. Un numr de coloane egal cu numrul de atribute ale relaiei, fiecare coloan reprezentnd un atribut. Capul tabelului, n care se nscriu numele atributelor relaiei, fiecare atribut fiind nscris n coloana corespunztoare. O mulime de linii, fiecare linie corespunznd unui tuplu (deci unei entiti); n fiecare element al unei linii se nregistreaz valoarea atributului corespunztor coloanei n care se afl elementul respectiv.

De exemplu, tabelul corespunztor strii relaiei ANGAJATI la un moment dat este prezentat n fig. 2.1. Dei n numeroase documentaii se folosete termenul de tabel pentru a desemna relaia pe care o reprezint, cele dou noiuni nu sunt identice: relaia este o noiune abstract (o mulime n sens matematic), n timp ce tabelul este o reprezentare a relaiei. Interpretarea tabelului ca relaie este posibil numai prin respectarea unor reguli bine precizate: fiecare linie desemneaz un tuplu; valorile unui atribut sunt nscrise pe aceeai coloan pentru toate liniile; numele atributului corespunztor unei coloane este nscris n capul tabelului. Numele relaiei ANGAJATI
Nume Ionescu Popescu Vasilescu Prenume Ion Petre Ana DataNasterii 1945.01.05 1972.06.21 1966.04.02 Adresa Bucureti Bucuresti Bucuresti Functie Inginer Tehnician Secretara Salariu 4000 3500 3000

Atributele relaiei

Fig. 2.1. Tabelul de reprezentare a relaiei ANGAJATI. Reprezentarea unei noiuni abstracte (relaia) ntr-o form att de uor de interpretat (tabelul) este o proprietate remarcabil a modelului relaional, dei aceast reprezentare poate sugera unele aspecte ale modelului relaional care nu sunt reale. De exemplu, tabelul sugereaz o ordonare a tuplurilor (de sus n jos), ordonare care nu este impus de noiunea de relaie, definit ca o mulime de tupluri. Chiar dac, n implementrile reale, o relaie este memorat ca un fiier pe disc, iar tuplurile relaiei sunt nregistrri (records) ale fiierului memorate ntr-o anumit ordine (exist prima nregistrare, a doua nregistrare, etc.), definiia relaiei evideniaz nivelul logic de organizare a datelor, n care tuplurile nu sunt ordonate.

2.1.2

Ordonarea valorilor atributelor n tupluri

n definiia relaiei din seciunea precedent, tuplul este considerat o list ordonat de n valori ale atributelor (A1,A2,...Ai,...An) i, n acest sens, reprezentarea printr-un tabel, n care coloanele sunt ordonate, corespunde definiiei relaiei. Aceasta este o definiie mai simpl i mai intuitiv a relaiei; totui, din punct de vedere logic, ordinea valorilor atributelor ntr-un tuplu nu are nici o importan, dac se poate face o coresponden ntre un atribut i valoarea acestuia. Aceast structurare logic a relaiei, n care atributele unui tuplu nu sunt ordonate, poate fi exprimat prin urmtoarea definiie a relaiei: Fie schema relaiei definit ca o mulime de atribute: R = {A1,A2, ...Ai,...An}. Relaia R este o mulime de n-tupluri t, fiecare tuplu compus dintr-o mulime de n perechi ordonate t = {<A1,v1>,<A2,v2>,...<Ai,vi>, ...<An,vn>}, unde vi este valoarea atributului Ai, din domeniul su de definiie. n aceast definiie ordinea atributelor nu mai conteaz, dat fiind c numele atributului i valoarea lui sunt grupate mpreun i, de aceea, aceast definiie a relaiei este mult mai general. n implementrile reale, valorile atributelor sunt cmpuri (fields) memorate ntr-o anumit ordine n cadrul nregistrrii (record) corespunztoare unui tuplu, deci exist o anumit ordine a valorilor atributelor, dar acesta nu este relevant din punct de vedere logic i de aceea se poate considera c valorile atributelor nu sunt ordonate. Totui, prima definiie a relaiei (n care tuplul este definit ca o list ordonat de valori ale atributelor) simplific notaiile i corespunde reprezentrii prin tabel a relaiei (cu coloanele corespunztoare atributelor aezate ntr-o anumit ordine) i de aceea n continuare va fi folosit destul de frecvent.

2.1.3

Catalogul sistemului SGBD

Catalogul sistemului (system catalog) este partea central a oricrui SGBD, n care se memoreaz descrierea bazelor de date pe care acesta le administreaz. Catalogul sistemului este o mic baz de date, n care sunt memorate date despre datele stocate; astfel de informaii sunt denumite meta-date. n sistemele de gestiune a bazelor de date relaionale catalogul este compus din relaii, care pot fi actualizate sau interogate folosind chiar comenzi ale sistemului SGBD. n catalog sunt descrise relaiile (numele relaiei, numele i domeniul atributelor, cheile candidate i strine), vederile, indexurile, precum i procedurile stocate, triggerele, funciile definite de utilizatori. De asemenea se memoreaz utilizatorii bazelor de date i drepturile acestora.

2.2

Limbajul SQL

Limbajul SQL (Structured Query Language) este limbajul utilizat de majoritatea sistemelor de baze de date relationale pentru definirea i manipularea datelor. Limbajul SQL a fost dezvoltat ntr-un prototip de sistem de gestiune a bazelor de date relaionale System R - la IBM, la mijlocul anilor 1970. In 1979 Corporatia Oracle a introdus prima implementare a limbajului SQL n varianta comercial. n anul 1987 Institutul National American de Standarde - ANSI (American National Standardization Institute) a elaborat standardul limbajului SQL. Ulterior au avut loc mai multe revizii ale acestui standard. n 1992 Organizaia International de Standarde - ISO (International Standardization Office) a adoptat limbajul SQL ca limbaj standard pentru sistemele de gestiune a bazelor de date relaionale sub denumirea de SQL-92 (sau, mai simplu, SQL2) [ANSI92]. Un standard ulterior, SQL-99 (numit i SQL3) adaug limbajului trsturi ale modelului obiect-relaional. Majoritatea sistemelor SGBD relaionale actuale suport standardul SQL2, dar fiecare implementeaz, de fapt, un dialect specific al limbajului SQL. n diferitele implementri ale limbajului SQL pot s lipseasc unele comenzi prevzute n standardul SQL2, dar pot exista extensii specifice, neprevzute n standard, care micoreaz oarecum gradul de portabilitate a aplicaiilor. Unele sisteme de gestiune (ca Oracle9i, PostgreSQL7.2) suport i o mare parte din specificaiile obiect-relaionale prevzute n standardul SQL99 (SQL3). Deoarece aceast lucrare este axat pe modelul relaional se vor descrie n principal instruciunile standardului SQL2. Limbajul SQL folosete termenii de tabel (table), linie (row), coloan (column) pentru a desemna o relaie, un tuplu sau un atribut, deci este orientat spre reprezentarea prin tabele a relaiilor, care este mai simpl i mai intuitiv pentru proiectani i pentru programatori. Limbajul SQL cuprinde att componenta de descriere a datelor relaionale (Limbaj de Descriere a Datelor - LDD) ct i componenta de manipulare a datelor (Limbaj de Manipulare a Datelor - LMD), ambele fiind absolut necesare n gestiunea bazelor de date. Pe lng aceste componente principale, standardul SQL2 mai prevede i alte componente ale limbajului:

Controlul tranzaciilor - conine comenzi pentru specificarea tranzaciilor. Unele implementri adaug comenzilor prevzute n standard i alte comenzi suplimentare de control al concurenei i refacerea datelor. Controlul securitii i al proteciei datelor - conine comenzi de administrare a bazelor de date, pentru definirea utilizatorilor i a drepturilor acestora de acces la tabele. Aceast component este puternic dependent de sistemul de gestiune al bazei de date, iar pentru sistemele performante, administrarea bazei de date este un capitol foarte extins, care face obiectul activitii unei categorii speciale de utilizatori ai bazei de date (administratori ai bazei de date).

Limbajul SQL este un limbaj neprocedural: o instruciune SQL specific ce informaii trebuie s fie setate sau obinute, nu modul (procedura) n care se opereaz. Limbajul SQL conine numai instruciuni de definire i manipulare a datelor i nu conine instruciuni de control al fluxului execuiei (instruciuni ca for, while, if, etc). De aceea, pentru realizarea aplicaiilor de baze de date, s-a dezvoltat o multitudine de tehnologii, limbaje, biblioteci i interfee de programare care integreaz, printr-o tehnic oarecare, instruciunile SQL de acces la date. Astfel de tehnologii vor fi prezentate n Capitolele 4 i 7.

n continuare se vor prezenta cele mai importante instruciuni de descriere i manipulare a datelor definite n standardul SQL2. Pentru a nva i testa diferite instruciuni SQL trebuie s fie instalat un sistem de gestiune a bazelor de date i un program utilitar care primete instruciuni de la consol i le transmite sistemului SGBD pentru a fi executate. Majoritatea sistemelor SGBD ofer astfel de instrumente soft (cu sau fr interfa grafic). De exemplu, pentru sistemul Microsoft SQL Server exist utilitarele isql i osql care permit executarea instruciunilor Transact-SQL (care sunt extensii ale limbajului SQL); pentru sistemele Oracle exist utilitarul SQL*Plus care permite execuia de la consol att a instruciunilor SQL, ca i a blocurilor PL/SQL; pentru sistemul mySQL exist utilitarul mySQL care execut instruciuni SQL. Aceste programe utilitare sunt descrise n primul capitol din ndrumarul de aplicaii. Bineneles, atunci cnd se testeaz o anumit instruciune SQL trebuie s fie folosit exact varianta implementat n sistemul folosit, care poate diferi ntr-o oarecare msur de forma general din standard. 2.2.1 Structura lexical a limbajului SQL

O instruciune SQL (statement) este o secven de elemente componente (tokens) terminat cu semnul punct i virgul (;). Fiecare instruciune SQL conine o comand SQL (command), care specific ce aciune se efectueaz, urmat de alte elemente componente, care specific operaii, clauze, parametri, etc. De exemplu, instruciunea:
SELECT * FROM ANGAJATI;

conine comanda SQL SELECT, urmat de alte elemente componente ale instruciunii. Un element al unei instruciuni SQL poate fi: cuvnt cheie (key word), identificator (identifier), constant (literal) sau un caracter special. Elementele componente sunt, n general, separate printr-unul sau mai multe spaii albe (whitespaces): caracter spaiu, caracter linie nou sau caracter tab. Separatorii pot lipsi dac nu exist ambiguiti n secvena de elemente ale unei comenzi. O comand se poate scrie pe una sau mai multe linii, iar ntr-o linie se pot introduce una sau mai multe comenzi. Cuvinte cheie i identificatori. Cuvintele cheie sunt elemente componente cu semnificaie fix n limbajul SQL. Acestea pot fi comenzi (SELECT, UPDATE, INSERT, etc.), operatori (AND, OR, NOT, LIKE), clauze (WHERE, SET, VALUES, etc.). De exemplu, n instruciunile urmtoare, toate cuvintele scrise ngroat (bold) sunt cuvinte cheie:
SELECT * FROM SECTII WHERE IdSectie = 1; INSERT INTO SECTII VALUES (2,Productie,500);

Identificatorii sunt elemente componente care denumesc tabele, coloane sau alte obiecte ale bazei de date. n exemplul de mai sus, SECTII, IdSectie sunt identificatori. n SQL cuvintele cheie i identificatorii trebuie s nceap cu o liter sau cu caracterul subliniere ( _ ), iar caracterele urmtoare pot fi litere, cifre sau caracterul subliniere. Cuvintele cheie i identificatorii au aceeai structur lexical i nu pot fi difereniai fr a cunoate limbajul. n cuvintele cheie i identificatori nu se difereniaz caracterele mici de cele mari (sunt case-insensitive),

deci comenzile INSERT, insert, sau Insert, etc. sunt identice. Totui, pentru evidenierea comenzilor SQL, n continuare majoritatea cuvintelor cheie vor fi scrise cu majuscule. La fel vor fi scrise i numele relaiilor. Pe lng acest tip de identificatori simpli (formai dintr-o secven de litere, cifre i caracterul subliniere), mai exist i un alt tip de identificatori, identificatorii delimitai (quoted identifiers), constnd dintr-o secven de caractere ncadrat (la nceput i la sfrit) de caracterul ghilimele ( ). Un identificator delimitat este ntotdeauna identificator (niciodat cuvnt cheie), iar literele mari sunt diferite de literele mici (este case-sensitive). De exemplu, elementul SELECT este un identificator delimitat i poate denumi o tabel sau o coloan (atribut), n timp ce elementul SELECT este un cuvnt cheie i utilizarea lui ca nume de tabel sau de atribut va produce o eroare de interpretare a comenzii. Un identificator delimitat poate conine orice caracter cu excepia caracterulul ghilimele, permind crearea unor nume (de tabele, coloane, etc.) mai complexe, care s conin spaii sau caractere speciale ( &, %, etc.), ceea ce cu identificatori simpli (ne-delimitai) nu este posibil. Constante. Constantele (literale) pot fi iruri de caractere, numere ntregi, numere reale sau constanta NULL. Ele se reprezint aproximativ la fel ca n alte limbaje de programare (de exemplu C/C++). Caractere speciale. Unele caractere care nu sunt litere sau cifre pot avea rol de operatori SQL sau pot avea o semnificaie special n cadrul comenzilor SQL. De exemplu, caracterul punct i virgul (;) este folosit pentru terminarea comenzilor; caracterul punct (.) este folosit ca punct zecimal sau pentru calificarea numelor; caracterul asterisc (*) este folosit ca operator de nmulire sau n comanda SELECT, etc. 2.2.2 Expresii, operatori i funcii SQL2

O expresie SQL const dintr-unul sau mai muli operanzi, operatori i paranteze. Un operand poate fi numele unei coloane (a unui tabel), o constant (literal), sau valoarea returnat de o functie; parantezele sunt folosite pentru a preciza o anumit ordine a operaiilor, dac aceasta este diferit de cea implicit, dat de precedena operatorilor. Un operator SQL este compus dintr-unul sau mai mai multe caractere speciale (care nu sunt litere sau cifre), ca de exemplu: +,-,*,/,%,<,>,=,~,!,@ #,&,|,^,?,,$, sau este un cuvnt cheie, ca de exemplu: AND, OR, NOT, LIKE, etc. Din punct de vedere al numrului de operanzi, operatorii SQL sunt de dou categorii, binari i unari, cei unari putnd fi operatori prefix sau operatori postfix. Din punct de vedere al tipului de operaie, operatorii SQL (din orice categorie) pot fi aritmetici, logici, de comparaie SQL, sau relationali. Operatorii aritmetici ai limbajului SQL2 sunt compui din unul sau mai multe caractere speciale i au notaie i semnificaie asemntoare cu a celor definii n diferite limbaje de programare, cu mici diferene care se pot remarca din lista de mai jos. Operatorii aritmetici binari sunt: + (adunarea), - (scaderea), * (nmulirea), / (mprirea), % (modulo), ^ (ridicarea la putere), & (AND orientat pe biti), | (OR orientat pe biti), # (XOR orientat pe biti) , << (deplasarea la stnga), >> (deplasarea la dreapta). Tot operatori aritmetici sunt i operatorii binari de comparatie: < (mai mic), > (mai mare), <= (mai mic sau egal), >= (mai mare sau egal), = (egal), <> (sau !=) (diferit). Operatorii aritmetici unari sunt: @ (valoarea absoluta), ! (factorial), !! (factorial, operator postfix), ~ (NOT orientat pe biti). Operatorii de comparaie SQL sunt descrii n tabelul urmtor.
Operator A BETWEEN min AND max A IN (v1,v2, ...vn) A IS NULL A IS NOT NULL Operaia efectuat compar A cu dou valori, min i max compar A cu o lista de valori (v1, v2,vn ) compar A cu NULL compar A cu NOT NULL compar A cu un model de ir de caractere

A LIKE model_sir

Pentru operatorii de comparaie, valoarea de comparat (A) este, de regul, valoarea unui atribut al unei relaii, dat prin numele coloanei corespunztoare a tabelului care reprezint relaia respectiv, o

constant sau valoarea unei expresii. Operatorii de comparaie (att cei aritmetici, ct i operatorii de comparaie specifici SQL), returneaz (evalueaz) valoarea logic TRUE (1), dac condiia de comparaie este ndeplinit i FALSE (0) dac condiia de comparaie nu este ndeplinit. Valoarea NULL este returnat dac ambii operanzi comparai au valoarea NULL. Operatorii logici ai limbajului SQL sunt notai prin cuvinte cheie: AND, OR, NOT. Toi aceti operatori se aplic unor variabile logice cu 3 valori (trivalente): TRUE (1), FALSE (0) i NULL; valoarea NULL semnific lipsa de informaie. Operatorii logici SQL returneaz o valoare logic trivalent (TRUE, FALSE sau NULL), aa cum se poate vedea din tabelele de adevr de mai jos.
A TRUE TRUE TRUE FALSE FALSE NULL B TRUE FALSE NULL FALSE NULL NULL A TRUE FALSE NULL A AND B TRUE FALSE NULL FALSE FALSE NULL NOT A FALSE TRUE NULL A OR B TRUE TRUE TRUE FALSE NULL NULL

Operatorii relaionali sunt notai prin cuvinte cheie: UNION (reuniune), INTERSECT (intersecie), MINUS (diferena). Ei vor fi studiai mai pe larg n Capitolul 3. Funciile definite n SQL sunt de dou categorii: funcii agregat i funcii scalare. Funciile agregat calculeaz un rezultat din mai multe linii ale unui tabel. Aceste funcii vor fi detaliate ntr-o seciune urmtoare, la descrierea instruciunii SELECT. Funciile scalare primesc unul sau mai multe argumente i returneaz valoarea calculat sau NULL n caz de eroare. Argumentele funciilor pot fi constante (literale) sau valori ale atributelor specificate prin numele coloanelor corespunzatoare. Exist mai multe tipuri de funcii scalare SQL: Funcii numerice: Majoritatea versiunilor de SQL furnizeaz funcii de calcul trigonometric (sin, cos, etc.), funcii de calcul al logaritmului (ln, log), al puterii (pow), funcii de rotunjire (floor, ceil), etc. Funcii pentru manipularea irurilor de caractere. Funcii pentru data calendaristic i timp. Funcii de conversie. Funciile scalare se folosesc n expresii, care pot s apar n diferite clauze ale instruciunilor SQL.

2.2.3

Tipuri de date i domenii SQL2

n limbajul SQL (standardul SQL2) sunt definite mai multe tipuri de date: numeric, ir de caractere, ir de bii, data (calendaristic), timp. Denumirile tipurilor de date, ca i limitele acestora (valoare minim, valoare maxim) prezint diferite variaii n funcie de implementare (versiunea de SGBD), dar n general sunt destul de asemntoare. Tipul numeric include numere ntregi de diferite dimensiuni (integer sau int reprezentat pe 4 octei, smallint reprezentat pe 2 octei), numere reale reprezentate n virgul flotant, cu diferite precizii (float, reprezentat pe 4 octei, real i double [precision], reprezentate pe 8 octei) i numere zecimale reprezentate cu precizia dorit (tipul numeric sau decimal). Formatul de reprezentare a numerelor zecimale cu precizia dorit este: numeric[(p,s)] (sau decimal [(p,s)]), unde p (precizia) este numrul total de cifre afiate, iar s (scara) este numrul de cifre dup punctul zecimal. n reprezentarea acestui tip de date poate s lipseasc parametrul s i atunci se consider s = 0 (nici o cifr dup punctul zecimal), sau pot lipsi ambii parametri i, n acest caz, se pot reprezenta numere cu orice precizie i scar (pn la limita admis de implementarea sistemului). Pentru a pstra precizia dorit, numerele de tip DECIMAL sau NUMERIC sunt memorate ca ir de caractere, fiecare caracter reprezentnd o cifr zecimal, punctul zecimal sau semnul. Tipul ir de caractere permite definirea irurilor de caractere de lungime fix (character(n) sau, prescurtat, char(n)), precum i a irurilor de caractere de lungime variabil (character varying, prescurtat varchar(n)). Ambele tipuri pot reprezenta iruri de maximum n caractere, cu diferena c, pentru

iruri de lungime mai mic dect n, la tipul char(n) se completeaz irul cu spaii albe pn la n caractere, n timp ce la tipul varchar(n) se memoreaz numai attea caractere cte are irul dat. Tipul iruri de bii definete secvene de cifre binare (care pot lua valoarea 0 sau 1) de lungime fix n (bit(n)) sau de lungime variabil, cu limita maxim n (bit varying(n)). Tipurile pentru data calendaristic i timp sunt: date, time, timestamp, interval. Tipul date permite memorarea datelor calendaristice prin utilizarea a trei cmpuri (year, month, day), n formatul yyyy-mm-dd. Sunt admise numai date valide (valori pozitive diferite de zero i mai mici dect 12 pentru lun, etc.). Tipul time este utilizat pentru memorarea timpului, folosind trei cmpuri (hour, minute, second) n formatul HH:MM:SS i, de asemenea, se admit numai valori valide. Un parametru opional p (time(P)) permite stabilirea numrului de zecimale cu care se reprezint cmpul second. Valoarea implicit a lui p este 0. Tipul timestamp(p) este folosit pentru memorarea combinat a datei calendaristice i a timpului, cu precizia p pentru cmpul second. Valoarea implicit a lui p este 6. Tipul interval este utilizat pentru memorarea intervalelor de timp. n denumirile tipurilor de date nu se difereniaz caracterele mici de cele mari (sunt case-insensitive), deci se poate scrie: INT, VARCHAR, NUMERIC, etc. Pe lng aceste tipuri definite n standardul SQL2, implementrile limbajului SQL n diferite sisteme SGBD prezint variante de tipuri de date specifice implementrii respective. De exemplu, SQL implementat de SQL Server adaug tipul tinyint, ca numr ntreg reprezentat pe 1 octet; n SGBD Oracle, tipul ir de caractere de lungime variabil este numit varchar2, etc. Standardul SQL2 nu suport tipuri de date i operaii definite de utilizator, dar aceste trsturi au fost introduse n standardul SQL3 care definete, de fapt, modelul obiect-relaional de date. n momentul de fa se poate observa c majoritatea productorilor de sisteme de baze de date relaionale introduc treptat, de la o versiune la alta, diferite caracteristici ale modelului obiect-relaional cuprinse n standardul SQL3. Domeniile atributelor n SQL2 se specific pe baza tipurilor de date predefinite ale limbajului SQL, deci sunt destul de deprtate de noiunea de domeniu relaional, aa cum a fost descris n seciunea precedent, dat fiind c nu se face nici o precizare a semnificaiei domeniului. Standardul SQL2 prevede comanda CREATE DOMAIN, care atribuie un nume de domeniu i unele constrngeri unui tip predefinit SQL2, dar aceast comand nu prea mai este implementat n sistemele de gestiune actuale, care prefer alte soluii de definire a domeniilor. De exemplu, n SQL Server, se pot crea aa-numitele tipuri definite de utilizator (user-defined types), care sunt, de fapt, echivalente cu domeniile create cu comanda SQL CREATE DOMAIN. Pentru aceasta se folosete o procedur stocat, scris n limbajul Transact-SQL care este specific sistemului SQL Server i care extinde limbajul SQL. n sistemele de baze de date Oracle 8i i Oracle 9i, se pot crea cu adevrat tipuri de date noi, folosind comanda CREATE TYPE, care permite gruparea sub un anumit nume a mai multor atribute, de diferite tipuri (predefinite sau definite de utilizator), ntr-un mod asemntor cu definirea claselor din limbajele obiect-orientate. Aceste tipuri definite de utilizator sunt folosite ca domenii ale atributelor (coloanelor) tabelelor. Pentru fiecare tip de date nou definit, se pot prevedea metode, scrise ntr-unul din limbajele C, Java sau PL/SQL. Aceste caracteristici reprezint trsturile obiect-relaionale ale sistemelor de baze de date Oracle 8i i Oracle 9i. n sistemul PostgreSQL se pot crea, de asemenea, tipuri de date noi, folosind comanda CREATE TYPE, iar tipurile nou create pot fi folosite ca domenii ale atributelor. Conveniile sintactice care se vor folosi n acest capitol i n urmtoarele pentru prezentarea limbajului SQL i a limbajelor de programare dezvoltate pe baza acestuia sunt prezentate n tabelul 2.3.
Convenie sintactic Litere mari [ ] (paranteze drepte) { } (acolade) | (bar vertical) [,...n] element1, ........ elementn lista_elemente Utilizare Cuvinte cheie ale limbajului sau denumiri de tabele. Element opional al instruciunii. Element obligatoriu al instruciunii. Separ elementele din parantezele drepte sau acolade. Numai unul din elementele separate cu bar vertical se pot introduce n instruciunea respectiv. Indic faptul c elementul precedent poate fi repetat de n ori. Elementele repetate sunt separate prin virgul. List de n elemente de acelai tip. Elementele repetate sunt separate prin virgul. List de elemente de acelai tip (separate prin virgul)

Caracterele folosite pentru a specifica o anumit convenie sintactic (paranteze, bara vertical, virgula, etc.) nu apar n instruciunile propriu-zise. Listele de elemente (compuse din mai multe elemente separate prin virgul) vor fi exprimate fie folosind una cele trei din construciile de mai sus, care se potrivete cel mai bine instruciunii respective. Pe lng aceste convenii, pentru o prezentare ct mai concis i mai uor de neles a instruciunilor, s-au mai adoptat i alte notaii: denumiri sugestive ale elementelor sintactice, renunarea la detalii minore pentru a se putea urmri caracteristicile de ansamblu, etc.

2.2.4

Instruciuni SQL de definire a datelor

Componenta de definire a datelor a limbajului SQL (numit Limbajul de Definire a Datelor - LDD) permite crearea (CREATE), modificarea (ALTER) i distrugerea (DROP) obiectelor bazei de date: tabele de baz (TABLE), tabele vedere (VIEW), indexuri (INDEX), proceduri (PROCEDURE), etc. Majoritatea dialectelor limbajului SQL conin comenzile: CREATE TABLE, CREATE VIEW, CREATE INDEX, CREATE USER CREATE FUNCTION, CREATE PROCEDURE, CREATE TRIGGER ALTER TABLE, ALTER VIEW, ALTER FUNCTION, ALTER PROCEDURE DROP TABLE, DROP VIEW, DROP INDEX, DROP USER DROP FUNCTION, DROP PROCEDURE, DROP TRIGGER n continuare vor fi descrise cele mai importante instruciuni SQL de definire a datelor.

2.2.4.1 CREAREA TABELELOR I A VEDERILOR

n limbajul SQL2 un tabel se creeaz folosind instruciunea CREATE TABLE, care are urmtoarea sintax: CREATE TABLE nume_tabel ( col1 dom1 [constrangeri_coloana], col2 dom2 [constrangeri_coloana], .......................................... coln domn [constrangeri_coloana], [constrangeri_tabel] ); Constrngerile impuse fiecrei coloane (atribut), ca i constrngerile de tabel, sunt opionale i vor fi discutate n capitolul urmtor. De exemplu, tabelul ANGAJATI corespunztor relaiei ANGAJATI (descris n seciunea precedent) se poate defini astfel: CREATE TABLE ANGAJATI ( Nume varchar(20), Prenume varchar(20), DataNasterii date, Adresa varchar(50), Functie varchar(20), Salariu numeric); Instruciunea CREATE TABLE definete att un tip de relaie (cu atributele specificate) ct i o variabil relaie care iniial este vid (nu conine nici un tuplu). Tabelele create cu instruciunea CREATE TABLE sunt numite i tabele de baz (base tables); ele sunt memorate n fiierele bazei de date i pot fi accesate pentru introducerea, modificarea i regsirea (interogarea) datelor. Vederi (views). Un tabel vedere este un tabel virtual, care nu este memorat fizic n fiiere, ci reprezint o selecie (dup un anumit criteriu) a datelor memorate n unul sau mai multe tabele de baz. Datele (valorile atributelor) sunt memorate o singur dat, n tabelele de baz, dar pot fi accesate att prin tabelele de baz ct i prin tabelele vederi. Instruciunea SQL de creare a unui tabel vedere este: CREATE VIEW nume_vedere AS (SELECT...); Formatul comenzii SELECT va fi descris n capitolul urmtor. Un tabel vedere este ntotdeauna actualizat ("la zi"), adic orice modificare efectuat n tabelele de baz se regsete imediat n orice tabel vedere creat pe baza acestora.

2.2.4.2 MODIFICAREA I TERGEREA TABELELOR

Comanda de modificare a tabelelor (ALTER TABLE) permite adugarea sau tergerea unor atribute, modificarea domeniilor unor atribute, precum i adugarea, modificarea sau tergerea unor constrngeri ale tabelului. De exemplu, instruciunea de adugare a atributului DataAngajarii n tabelul ANGAJATI se scrie n felul urmtor:
ALTER TABLE ANGAJATI ADD DataAngajarii Date;

Pentru tergerea unei coloane dintr-un tabel se folosete cuvntul cheie DROP n comanda ALTER TABLE. De exemplu, pentru tergerea coloanei DataAngajarii din tabelul ANGAJATI se introduce instruciunea: ALTER TABLE ANGAJATI DROP DataAngajarii; Instruciunile de tergere a tabelelor de baz i a vederilor sunt:
DROP TABLE nume_tabel; DROP VIEW nume_vedere;

2.2.5

INSTRUCIUNI SQL de manipulare a datelor

Instruciunile SQL de manipulare a datelor conin una din comenzile: SELECT, INSERT, UPDATE sau DELETE i vor fi studiate n continuare.

2.2.5.1 INSTRUCIUNEA SELECT

Instruciunea SELECT este instruciunea de interogare n limbajul SQL, prin care se regsesc informaiile dorite din unul sau mai multe tabele ale bazei de date. Instruciunea SELECT este foarte puternic i are urmtoarea sintax general:
SELECT [DISTINCT] lista_coloane [FROM lista_tabele] [WHERE conditie] [clauze_secundare];

Ca rezultat al instruciunii SELECT se obine un tabel care conine atributele (coloanele) din lista_coloane ale acelor linii (tupluri) ale produsului cartezian al tabelelor din lista_tabele pentru care expresia logic conditie este adevrat (are valoarea TRUE). Se remarc trei seciuni (clauze) importante ale instruciunii de interogare: SELECT, FROM i WHERE. Clauza SELECT definete coloanele tabelului rezultat. Clauza FROM indic unul sau mai multe tabele (o list de tabele) din care se selecteaz liniile tabelului rezultat. Clauza WHERE definete

condiia pe care trebuie s o ndeplineasc fiecare linie a tabelului rezultat. n afara acestor clauze, comanda SELECT mai poate conine i clauze secundare (ORDER BY, GROUP BY, HAVING), care permit ordonri sau grupri ale tuplurilor (liniilor) rezultate, etc. Singura clauz obligatorie este SELECT; restul clauzelor sunt opionale. Clauza SELECT introduce lista coloanelor unor tabele sau expresii care vor fi selectate i afiate. Coloanele din list trebuie s aparin unuia din tabelele specificate n clauza FROM. De exemplu, comanda urmtoare va selecta numele i prenumele tuturor angajailor din tabelul ANGAJATI:
SELECT Nume,Prenume FROM ANGAJATI;

Ca rezultat al instruciunii de mai sus se pot obtine dou sau mai multe linii identice, dac exista angajai cu acelai nume i prenume, deci rezultatul operaiei nu este o relaie n sensul definiiei din modelul relaional. Pentru eliminarea liniilor duplicat se introduce parametrul DISTINCT i atunci se elimin liniile duplicat iar rezultatul este o relaie n sensul definiiei din modelul relaional. Deci instruciunea de mai sus se poate scrie:
SELECT DISTINCT Nume,Prenume FROM ANGAJATI;

Dac lista de atribute este un asterisc (*), atunci se selecteaz toate atributele produsului cartezian al tabelelor indicate prin clauza FROM, care ndeplinesc condiia din clauza WHERE. De exemplu, instruciunea:

SELECT * FROM ANGAJATI;

permite selectarea tuturor coloanele i a liniilor din tabelul ANGAJATI. n clauza SELECT se pot introduce i funcii de totalizare (funcii agregat). Funciile agregat definite n limbajul SQL2 sunt date n tabelul urmtor.
Funcia COUNT SUM MAX MIN AVG Valoarea returnata numrul de linii ale rezultatului; suma tuturor valorilor dintr-o coloan valoarea cea mai mare dintr-o coloan valoarea cea mai mic dintr-o coloan media valorilor dintr-o coloan

De exemplu, comenzile urmtoare vor afia numrul de linii ale tabelului ANGAJATI i salariul maxim, minim i mediu al angajailor:
SELECT SELECT SELECT SELECT COUNT(*) FROM ANGAJATI; MAX(Salariu) FROM ANGAJATI; MIN(Salariu) FROM ANGAJATI; AVG(Salariu) FROM ANGAJATI;

Instruciunea SELECT poate s conin chiar i numai clauza SELECT, deci fr s se refere la un tabel (printr-o clauz FROM). n acest caz, comanda SELECT conine o list de expresii pe care le evalueaz i rezultatele calculate sunt returnate ca o linie a unui tabel ale crui coloane sunt chiar expresiile date. n clauza SELECT se pot redenumi atributele (coloane ale tabelelor) sau se pot specifica nume pentru expresii, folosind urmtoarea sintax:
SELECT nume1 [AS] noul_nume1 [,...n] FROM lista_tabele [alte_clauze];

Se observ c noul nume atribuit unei coloane (sau expresii) urmeaz vechiului nume (sau expresiei), precedat (optional, depinznd de implementare) de cuvntul-cheie AS. De exemplu, comanda urmtoare va afisa numele angajatului denumit NumeAngajat i 80% din salariul acestuia, denumit SalariuNet:
SELECT Nume NumeAngajat,Salariu*0.8 SalariuNet FROM ANGAJATI;

Clauza FROM este obligatorie dac ntr-una din clauzele SELECT, WHERE sau HAVING apar nume de coloane ale unor tabele. n acest caz, lista de tabele care nsoete clauza FROM trebuie s conin numele tuturor tabelelor (separate prin virgul) ale cror coloane se folosesc. Dac lista conine mai mult de un tabel, atunci numele coloanelor din clauza SELECT trebuie s fie diferite i, dac nu sunt diferite, se calific cu numele tabelului caruia i aparine, precednd numele atributului cu numele tabelului urmat de operatorul punct (.). De exemplu:
SELECT ANGAJATI.Nume,SECTII.Nume FROM ANGAJATI,SECTII;

De retinut c, dei limbajul SQL este case-insensitive, totui este necesar ca numele tabelului cu care se calific numele unui atribut s fie identic (inclusiv tipul de caracter, majuscul sau nu) cu cel declarat n clauza FROM. Clauza WHERE restrictioneaz tuplurile returnate ca rezultat la acele tupluri care ndeplinesc condiia introdus de aceast clauz sub forma unei expresii logice. O expresie logic se construieste din valori logice, operatori logici (AND, OR, NOT) i paranteze. O valoare logic se obtine, n mod obinuit, ca rezultat al comparaiei ntre doi operanzi folosind un operator de comparaie. Un operand poate fi un atribut (nume de coloan dintr-unul din tabelele introduse prin clauza FROM), o constant, valoarea unei expresii aritmetice sau o valoare returnat de o funcie. Operatorii de comparaie utilizai n clauza WHERE pot fi att operatori aritmetici de comparaie ct i operatori SQL de comparaie, aa cum se poate vedea n instruciunile urmtoare:
SELECT Nume,Prenume FROM ANGAJATI WHERE DataNasterii > 1968-01-01; SELECT Nume,Prenume FROM ANGAJATI WHERE Salariu BETWEEN 3000 AND 4000 AND Functie = Inginer;

Prima instruciune va afia toi angajaii care s-au nscut dup data de 1 Ianuarie 1968; cea de-a doua comand va afia toi angajaii cu funcia Inginer i salariul cuprins ntre 3000 i 4000.

10

Clauza ORDER BY introduce numele atributului dup care se face ordonarea liniilor tabelului rezultat. Ordonarea se face n ordine cresctoare n mod implicit sau dac numele atributului este urmat de cuvntul cheie ASC; dac numele atributului este urmat de cuvntul DESC, ordonarea liniilor se face n ordine descresctoare a valorilor acelui atribut. Ordonarea liniilor astfel obinut este ordonare logic, foarte util n prezentarea (afiarea) rezultatului i nu nseamn ordonarea nregistrrilor n fiierele relaiilor. De exemplu, pentru afiarea listei angajatilor ordonat dup numele acestora, se introduce comanda:
SELECT * FROM ANGAJATI ORDER BY Nume;

Clauza GROUP BY se folosete pentru gruparea rezultatelor funciilor agregat (totalizatoare) n funcie de valoarea uneia sau mai multor coloane. Pentru aceasta, n instruciunea SELECT se introduce clauza GROUP BY, urmat de numele coloanei (sau al coloanelor) dup valoarea crora se dorete gruparea rezultatelor funciei agregat. n acest caz, funcia agregat se aplic separat acelor linii care au aceeai valoare a atributelor specificate de clauza GROUP BY. De exemplu, salariul mediu calculat separat pe grupuri de angajati, fiecare grup fiind compus din liniile care au aceeai valoare a atributului Functie, se obine cu urmtoarea instruciune SQL:
SELECT AVG (Salariu) FROM ANGAJATI GROUP BY Functie;

Clauza HAVING. Funciile agregat (totalizatoare) nu pot fi utilizate n clauza WHERE; de exemplu instruciunea urmtoare (prin care se cere lista angajailor cu salariu mai mare dect salariul mediu) este eronat:
SELECT Nume,Prenume FROM ANGAJATI WHERE Salariu >= AVG(Salariu);

Pentru folosirea unei funcii agregat ntr-o condiie de selecie se folosete clauza HAVING. Clauza HAVING este asemntoare clauzei WHERE, adic introduce o condiie pe care trebuie s o ndeplineasca tuplurile rezultat, i, n plus, permite utilizarea funciilor agregat n expresia conditional. Exemplul de mai sus se scrie corect astfel:
SELECT Nume,Prenume FROM ANGAJATI HAVING Salariu >= AVG (Salariu);

Instruciuni SELECT imbricate. Subinterogri. Instruciunile SELECT se pot imbrica pe mai multe niveluri, o instruciune avnd ca argument rezultatul unei altei instruciuni, numit subinterogare. Exist mai multe moduri de construire a subinterogrilor, una din formele cele mai frecvent folosite fiind urmtoarea:
SELECT lista_atribute FROM tabel1 WHERE colx IN (SELECT colx FROM tabel2 WHERE conditie);

ntr-o astfel de construcie valoarea de comparaie (pentru operatorul de comparaie IN) din clauza WHERE a primei instruciuni SELECT se definete printr-o subinterogare care const dintr-o alt instruciune SELECT. Alte forme de construire a subinterogrilor vor fi prezentate n capitolele urmtoare.

2.2.5.2 INSTRUCIUNEA INSERT

Instruciunea INSERT se folosete pentru introducerea datelor n tabele i are urmtoarea sintax:
INSERT INTO nume_tabel(col1,col2,...coln)VALUES(val1,val2,...valn);

ntre valori i numele de coloane trebuie s existe o coresponden unu la unu. Valorile din list pot fi constante (literale) sau expresii. De exemplu, introducerea unei linii n tabelul SECTII se poate face cu instruciunea:
INSERT INTO SECTII (IdSectie,Nume,Buget) VALUES (1,Productie,4000000);

Lista de coloane poate s lipseasc dac se introduc valori n toate coloanele tabelului, dar n aceast situatie ordinea valorilor introduse trebuie s respecte ordinea atributelor. Aceasta ordine provine din ordinea de definire a atributelor prin instruciunea CREATE TABLE, precum i din operaiile ulterioare de alterare a tabelului respectiv, i se poate afla printr-o instruciune DESCRIBE nume_tabel. De exemplu, introducerea unei linii n tabelul ANGAJATI(IdAngajat,Nume,Prenume,DataNasterii,Adresa,Salariu), se poate face cu instruciunea:
INSERT INTO ANGAJATI VALUES(100,Mihailescu, Mihai,1950-04-05,Craiova,3000);

11

2.2.5.3 INSTRUCIUNEA UPDATE

Instruciunea UPDATE permite actualizarea valorilor coloanelor (atributelor) din una sau mai multe linii ale unui tabel. Aceasta are sintaxa:
UPDATE nume_tabel SET col1 = expr1 [,...n] [WHERE conditie];

Clauza WHERE impune ca actualizarea valorilor coloanelor s se efectueze numai asupra acelor linii care ndeplinesc condiia dat. Dac este omis clauza WHERE, vor fi modificate valorile coloanelor din toate liniile tabelului.De exemplu, pentru a modifica linia introdus mai sus n tabelul ANGAJATI, se poate introduce instruciunea:
UPDATE ANGAJATI SET Adresa = Bucuresti,Str. Victoriei WHERE IdAngajat = 100;

2.2.5.4 INSTRUCIUNEA DELETE

Instruciunea DELETE permite tergerea uneia sau mai multor linii dintr-un tabel i are forma:
DELETE FROM nume_tabel [WHERE conditie];

Din tabel se terg acele linii care ndeplinesc condiia dat n clauza WHERE. Dac este omis clauza WHERE, vor fi sterse toate liniile din tabel. De exemplu, pentru a sterge din tabelul ANGAJATI toi angajatii care au numele Ionescu, se introduce instruciunea:
DELETE FROM ANGAJATI WHERE Nume =Ionescu;

n aceast seciune au fost prezentate consideraii generale asupra comenzilor de definire i manipulare a datelor prevzute n standardul SQL2. Alte comenzi SQL vor fi prezentate pe parcursul seciunilor i a capitolelor urmtoare, o dat cu introducerea noiunilor la care se refer. In plus, exist numeroase extensii, opiuni i detalii ale comenzilor, unele depinznd de implementarea limbajului n fiecare tip i versiune de SGBD. Pentru aceste aspecte este necesar s fie consultat documentaia sistemului respectiv.

2.3

CONSTRNGERI DE INTEGRITATE

Constrngerile de integritate (integrity constraints) sunt reguli care se definesc la proiectarea unei bazei de date i care trebuie s fie respectate de orice stare a acesteia. Relaiile unei baze de date reflect realitatea modelat i de aceea valorile pe care le conin trebuie s respecte anumite reguli, care s corespund celor din realitate. Constrngerile se pot clasifica dup locul unde sunt definite i dup modul n care sunt definite. Din punct de vedere al locului unde sunt definite, constrngerile pot fi constrngeri intra-relaie i constrngeri interrelaii. Constrngerile intra-relaie sunt reguli care se impun n cadrul unei singure relaii i asigur integritatea datelor acesteia. Ele sunt, la rndul lor, de trei categorii: Constrngeri de domeniu, care sunt condiii ce se impun valorilor atributelor i asigur integritatea domeniilor atributelor. Constrngeri de tuplu, care sunt condiii ce se impun tuplurilor unei relaii i asigur identificarea corect a tuplurilor prin intermediul cheilor (primare sau candidate). Constrngeri impuse prin dependene de date (dependene funcionale, multivalorice sau de jonciune); acestea sunt constrngeri prin care valorile unor atribute ale unei relaii determin valorile altor atribute ale aceleiai relaii.

Constrngerile inter-relaii sunt reguli care se impun ntre dou sau mai multe relaii. Cele mai importante constrngeri inter-relaii sunt constrngerile de integritarea referenial, care se realizeaz prin intermediul cheilor strine i asigur asocierea corect a relaiilor. Din punct de vedere al modului de definire, constrngerile unei baze date se pot clasifica n constrngeri inerente, implicite i explicite. Constrngerile inerente sunt cele ale modelului de date nsui, care nu trebuie s fie specificate la definirea relaiilor, dar sunt respectate prin modul n care se construiesc relaiile. De exemplu, n modelul relaional constrngerea ca valoarea fiecrui atribut s fie atomic (indivizibil) este o constrngere inerent. Constrngerile implicite sunt reguli care se definesc odat cu definirea schemelor relaiilor (prin intermediul instruciunile de definire a datelor), sunt memorate n baza de date i sistemul de gestiune verific i impune automat respectarea acestora. Connstrngerile de domeniu, constrngerile de tuplu i constrngerile de integritate referenial sunt exemple de constrngeri implicite.

12

Constrngerile explicite sunt constrngeri suplimentare pe care trebuie s le respecte relaiile unei baze de date i care nu sunt impuse automat de sistemul SGBD, ci necesit proceduri speciale de verificare i impunere a respectrii lor. Ca exemple de constrngeri explicite sunt unele dependene de date, i anume cele care nu sunt determinate de cheile relaiilor. Dependenele de date sunt prezentate n Capitolul 5.

2.3.1

Constrngeri de domeniu

Constrngerile de domeniu sunt condiii impuse valorilor atributelor, astfel nct acestea s corespund semnificaiei pe care o au n realitatea modelat. Dat fiind c, n reprezentarea unei relaiei printr-un tabel, valorile atributelor sunt reprezentate pe coloane, constrngerile de domeniu se mai numesc i constrngeri de coloan. Dintre constrngerile de domeniu, constrngerea NOT NULL i constrngerea de valoare implicit (DEFAULT) sunt constrngeri cu caracter mai general, care se pot aplica oricrui atribut; constrngerea de verificare (CHECK) se poate aplica unor anumite atribute, n funcie de semnificaia acestora. Constrngerea NOT NULL. O valoare particular pe care o poate lua un atribut este valoarea NULL, care nu nseamn zero, ci lips de informaie. Valoarea NULL a unui atribut ntr-un tuplu semnific faptul c valoarea acelui atribut nu este cunoscut pentru acel tuplu sau c acel atribut nu este aplicabil acelui tuplu. Lipsa de informaie (deci valoarea NULL a unui atribut) poate s apar n diferite situaii. De exemplu, ntr-o relaie de nregistrare a datelor despre personaliti istorice, valoarea atributului DataNasterii poate s nu fie cunoscut pentru unele personaliti i n aceste tupluri se trece valoarea NULL. Faptul c nu se cunoate data de natere a unor personaliti nu trebuie s mpiedice definirea acestui atribut care, pentru majoritatea nregistrrilor, va avea valori cunoscute i important s fie memorate. O alt situaie n care poate s fie folosit valoarea NULL a unui atribut este aceea n care la nregistrarea unui tuplu nu se cunoate valoarea atributului, aceasta urmnd s fie completat ulterior. Nu orice atribut poate lua valori de NULL. De exemplu, n relaia ANGAJATI(Nume,Prenume, DataNasterii,Adresa,Functie,Salariu) nu are sens s se nregistreze un angajat al crui nume nu se cunoate, deci nu se vor admite valori de NULL pentru atributul Nume. n astfel de situaii la definirea relaiilor se impune atributului constrngerea NOT NULL, nsemnnd c atributul respectiv nu poate lua valoare NULL n nici un tuplu al relaiei. Constrngerea NOT NULL pentru un atribut se introduce la crearea unei relaii (tabel) prin comanda SQL CREATE TABLE. Opiunea implicit (dac nu se specific nimic) este admiterea valorilor de NULL. De exemplu, constrngerea NOT NULL pentru atributele Nume i Prenume ale relaiei ANGAJATI se introduce astfel:
CREATE TABLE ANGAJATI( Nume varchar(20) Prenume varchar(20) NOT NULL, NOT NULL,...);

Valori implicite ale atributelor. n limbajul SQL2 se poate stabili o valoare implicit (DEFAULT) pentru un atribut al unei relaii. n cazul n care la inserarea unui tuplu nu se specific valoarea unui atribut, atunci atributul primete valoarea implicit (dac a fost definit) sau valoarea NULL (dac nu a fost definit o valoare implicit pentru atributul respectiv, dar sunt admise valori NULL); dac nu a fost definit o valoare implicit i nici nu sunt admise valori NULL, se genereaz o eroare. n limbajul SQL2, valoarea implicit a unui atribut se poate specifica la crearea tabelului corespunztor, ca o constrngere de coloan, mpreun cu alte constrngeri. De exemplu, la crearea tabelului STUDENTI, se poate specifica valoarea implicit pentru atributul Tara astfel:
CREATE TABLE IdStudent Nume Prenume Tara STUDENTI( int PRIMARY KEY, varchar (20) NOT NULL, varchar (20) NOT NULL, varchar (20) DEFAULT (Romania) NULL ) ;

Constrngerea de verificare (CHECK). n limbajul SQL2, domeniile se pot stabili ca tipuri de date predefinite (tipuri numerice, iruri de caractere de lungime fix sau variabil, data calendaristic, timp). Pentru fiecare atribut, definit pe un tip de date SQL, se pot aduga constrngeri de verificare la definirea tabelului prin comanda CREATE TABLE. Forma general a unei constrngeri de verificare este:
[CONSTRAINT nume_constrangere] CHECK (conditie)

Numele constrngerii, precedat de cuvntul cheie CONSTRAINT este opional. Rezultatul evalurii expresiei care reprezint condiia specificat trebuie s fie o valoare logic (TRUE, FALSE sau NULL). La introducerea (sau modificarea) valorilor atributelor se admit numai acele valori pentru care conditia de verificare

13

ia valoarea TRUE. De exemplu, n relaia ANGAJATI se poate introduce condiia ca atributul Salariu s aib valori mai mari sau egale cu o valoare dat (salariul minim pe economie). Atunci, comanda SQL de creare a tabelului ANGAJATI se completeaz astfel:
CREATE TABLE ANGAJATI( Nume varchar(20) NOT NULL, Prenume varchar(20) NOT NULL, DataNasterii Date, Adresa varchar (50), Functie varchar (20), Salariu numeric, CHECK (Salariu >= 1500));

2.3.2

Constrngeri de tuplu - Cheia primar i cheile secundare

O relaie este definit ca o mulime de tupluri, deci tuplurile unei relaii trebuie s fie distincte. Aceasta nseamn c ntr-o relaie nu pot exista dou (sau mai multe) tupluri care s conin aceeai combinaie de valori ale tuturor atributelor. De obicei, ntr-o schem de relaie exist o submulime de atribute SK cu proprietatea c nu exist dou tupluri distincte ale relaiei (n orice stare s-ar afla relaia), ti i tj care s aib aceeai combinaie de valori ale atributelor submulimii respective, adic:
ti[SK] tj[SK] dac i j

O supercheie (superkey) a unei relaii este o submulime (SK) de atribute ale relaiei care prezint proprietatea de unicitate, adic orice combinaie de valori ale atributelor supercheii este unic pentru orice stare a relaiei. Acest lucru nseamn c, dac se cunoate combinaia de valori ale atributelor supercheii (valoarea supercheii), atunci acel tuplu poate fi identificat n mod unic. Orice relaie are cel puin o supercheie: mulimea tuturor atributelor sale. Un concept mai util n dezvoltarea bazelor de date l reprezint conceptul de cheie candidat (sau, mai simplu, cheie). O cheie candidat (candidate key) este o supercheie ireductibil. Conform definiiei de mai sus, o cheie candidat CK trebuie s prezinte urmtoarele dou proprieti: Unicitate: nu exist dou tupluri diferite ale relaiei care s conin aceeai combinaie de valori ale atributelor cheii CK; Ireductibilitate: nu exist nici o submulime proprie, nevid a cheii CK care s aib proprietatea de unicitate. Acest lucru nseamn c, dac se elimin un atribut oarecare din submulimea CK, noua submulime de atribute CK obtinut astfel nu mai are proprietatea de unicitate, adic vor putea exista dou sau mai multe tupluri care s prezinte aceeai combinaie de valori ale atributelor din submulimea CK. Aadar o cheie candidat este o supercheie minimal, adic o supercheie din care nu se poate elimina nici un atribut fr a se piarde proprietatea de unicitate. Proprietatea cheii de a avea o valoare unic pentru fiecare tuplu (adic nu exist dou tupluri cu aceleai valori ale atributelor cheii) este o constrngere de integritate a tuplurilor relaiei respective, care trebuie s fie respectat de orice stare a relaiei (extensiune a relaiei), n orice moment. O cheie candidat poate s fie simpl (alctuit dintr-un singur atribut), sau compus (alctuit din mai multe atribute). O cheie este determinat de nelesul atributelor i este o proprietate invariant n timp; ea trebuie s se menin atunci cnd sunt adugate tupluri noi n relaie. De exemplu, n relaia ANGAJATI(Nume,Prenume,DataNaterii,Adresa,Salariu) nu se poate desemna ca i cheie submulimea de atribute {Nume,Prenume}, deoarece nu exist nici o garanie c nu vor exista niciodat (n aceeai instituie) dou persoane cu acelai nume i prenume, chiar dac n momentul n care examinm relaia aceast situaie nu apare. n schimb, submulimea de atribute {Nume,Prenume,DataNaterii,Adresa} poate fi cheie candidat dac se consider c nu pot exista dou persoane cu acelai nume, prenume, data naterii i adres. Atunci cnd exist mai multe chei candidate, una dintre ele se alege ca i cheie primar, celelalte chei candidate fiind numite chei secundare, alternative sau unice. Aadar:

14

O cheie primar (primary key) este o cheie candidat creia proiectantul i confer un rol special de accesare i identificare a tuplurilor relaiei. Asupra cheii primare se impun urmtoarele restricii: Nici o valoare a atributelor cheii primare nu poate fi modificat prin operaii de actualizare. Nu se admit valori de NULL pentru nici unul dintre atributele cheii primare. O cheie secundar (alternativ, unic) (secondary, alternate, unique key) este o cheie candidat care nu a fost desemnat de proiectant ca i cheie primar. Cheile secundare admit valori NULL pentru unele din atributele lor dac se respect condiia de unicitate a valorilor. Alegerea cheii primare dintre mai multe chei candidate este arbitrar, dar n mod obinuit se alege acea cheie care are cel mai mic numr de atribute. Deoarece condiia de unicitate se verific la fiecare tuplu nou introdus i toate operaiile de identificare a tuplurilor se fac prin operaii de comparaie a valorilor atributelor cheii primare, este evident c aceste operaii sunt cu att mai eficiente (cu timp de execuie mai sczut) cu ct numrul de atribute ale cheii primare este mai mic. O cheie primar compus din atributele existente ale tipului de entitate se numete cheie natural. n general, cheile naturale sunt compuse din mai multe atribute (ceea ce produce scderea eficienei operaiilor relaionale) i de cele mai multe ori se folosesc chei artificiale. O cheie primar artificial este un atribut care se adaug n schema relaiei pentru identificarea unic a tuplurilor. De exemplu, n relaia ANGAJATI se adaug atributul IdAngajat, ca numr de identificare al fiecrui angajat al instituiei:
ANGAJATI(IdAngajat,Nume,Prenume,DataNasterii,Adresa,Salariu)

Acest atribut este o cheie artificial a relaiei i poate identifica n mod unic un tuplu, deoarece (prin convenie) nu se atribuie acelai numr de identificare la mai mult de un angajat. Submulimi de atribute care includ atributul IdAngajat ca {IdAngajat,Nume}, {IdAngajat,Nume,Prenume}, etc., sunt superchei ale relaiei. Rmne n grija programatorului sau a sistemului de gestiune a bazei de date s asigure unicitatea acestui numr de identificare, dar acest lucru este ntotdeauna posibil. n seciunile care urmeaz cheia primar se va marca prin subliniere sau scriere ngroat (bold). n limbajul SQL, constrngerea de cheie primar se introduce la definirea relaiei (tabelului) prin comanda CREATE TABLE. Dac cheia primar este simpl (format dintr-un singur atribut), constrngerea de cheie primar se poate specifica la definirea atributului, ca o constrngere de atribut. Dac cheia primar este compus (format din mai multe atribute), atunci constrngerea de cheie primar se specific dup definirea atributelor, ca o constrngere de tabel sub forma:
[CONSTRAINT nume_constr] PRIMARY KEY (lista_atribute)

Aceast form de definire se poate folosi i pentru o cheie primar simpl i atunci lista are un singur atribut. Cheile secundare se definesc n mod asemntor, folosind specificatorul UNIQUE n locul specificatorului PRIMARY KEY. Cu aceste notaii, definiiile mai complete ale tabelelor ANGAJATI i SECTII pot arta astfel:
CREATE TABLE ANGAJATI ( IdAngajat int PRIMARY KEY, Nume varchar(20) NOT NULL, Prenume varchar(20) NOT NULL, DataNasterii Date, Adresa varchar(50), Salariu numeric, CHECK (Salariu >= 1500), CONSTRAINT UK UNIQUE(Nume,Prenume,DataNasterii,Adresa)); CREATE TABLE SECTII ( IdSectie int PRIMARY KEY, Nume varchar(50) NOT NULL, Buget numeric);

n fiecare dintre cele dou tabele s-a definit cheia primar artificial printr-un atribut de identificare (IdSectie, respectiv IdAngajat), care trebuie s ia valori unice n cadrul tabelului. n tabelul ANGAJATI sa mai definit o cheie unic i o constrngere de verificare. Modul de asigurare a unicitii valorii cheii primare artificiale depinde de sistemul SGBD folosit. De exemplu, n sistemul Microsoft SQL Server se pot obine valori unice ale cheii primare folosind parametrul IDENTITY, care asigur incrementarea valorii atributului cheii la introducerea fiecrei linii noi. .n sistemele Oracle se pot genera chei artificiale folosind obiecte SEQUENCE. Un obiect SEQUENCE se creeaz pentru a genera cheia primar artificial a unui tabel, este memorat n baza de date i returneaz un numr unic la fiecare apel al metodei NEXTVAL.

15

2.3.3

Constrngeri ntre relaii - Cheia strin

Asocierile (relationships) ntre tipurile de entiti definite n modelul conceptual (prin diagrama Entitate-Asociere) al unei baze de date se realizeaz n modelul relaional prin intermediul cheilor strine. Relund exemplul din capitolul precedent, se consider relaiile SECTII i ANGAJATI, aflate n asociere 1:N, conform diagramei E-A i a semnificaiei celor dou mulimi de entiti. Pentru a asigura asocierea dintre relaia ANGAJATI i relaia SECTII, se adaug n relaia ANGAJATI un atribut suplimentar, IdSectie, care reprezint identificatorul (numrul) seciei n care lucreaz angajatul respectiv:
ANGAJATI(IdAngajat,Nume,Prenume,DataNasterii,Adresa,Salariu,IdSectie)

Pentru orice tuplu din relaia ANGAJATI, atributul IdSectie trebuie s aib o valoare egal cu valoarea atributului corespunztor (IdSectie) dintr-un tuplu oarecare din relaia SECTII (sau poate avea valoarea NULL, dac nu este impus constrngerea NOT NULL). Este evident c pentru starea la un moment dat a relaiilor prezentate n figura 2.2, nu poate s existe n relaia ANGAJATI un tuplu cu valorile atributelor (5,Marinescu,...5), dat fiind c n instituia respectiv nu exist o secie cu identificatorul 5. Bineneles, dac ulterior se adaug mai nti n relaia SECTII un tuplu care s aib valoarea atributului IdSectie egal cu 5 (de exemplu tuplul(5,Marketing,1000000)), atunci se poate admite n relaia ANGAJATI tuplul(5,Marinescu,... 5). SECTII
IdSectie 1 2 3 4 ANGAJATI IdAngajat 1 2 3 4 Nume Ionescu Popescu Vasilescu Ionescu Prenume Ion Petre Ana Ion DataNasterii 1945.01.05 1972.06.21 1966.04.02 1970.11.12 Adresa Bucuresti Bucuresti Bucuresti Bucuresti Salariu 4000 3500 3000 2500 IdSectie 1 1 2 3 Nume Productie Proiectare Cercetare Documentare Buget 4000000 3000000 2000000 1000000

Fig. 2.2. Tabelele SECTII i ANGAJATI.

Din punct de vedere al notaiilor, n instruciunile SQL de introducere, actualizare i interogare valorile atributelor definite ca iruri de caractere se scriu ntre ghilimele simple, de exemplu 'Marinescu', etc. La listarea sau afiarea rezultatelor ns, se va scrie numai valoarea atributului, fr acest marcaj, pentru simplificarea prezentrii exemplelor.

2.3.3.1 CHEIA STRIN

O cheie strin (foreign key) este o submulime FK de atribute ale unei relaiei R1 care refer relaia R2 i satisface urmtoarele condiii: (a) atributele cheii strine FK sunt definite pe domenii compatibile cu cele ale atributelor unei cheii candidate CK a relaiei R2 i (b) combinaia de valori ale atributelor FK ntr-un tuplu din relaia R1, fie este identic cu combinaia de valori ale atributelor CK a unui tuplu oarecare din starea curent a relaiei R2, fie ia valoarea NULL. Relaia care conine cheia strin se numete relaia care refer (R1 n definiia de mai sus), iar relaia care conine cheia candidat se numete relaia referit (R2 n definiia de mai sus). Din punct de vedere relaional, dou domenii sunt compatibile dac ele sunt comparabile din punct de vedere semantic. De exemplu, are sens s se compare atributul IdSectie din relaia SECTII cu atributul IdSectie din relaia ANGAJATI, deoarece aceste atribute reprezint numere de identificare ale seciilor, deci domeniile celor dou atribute sunt compatibile. n schimb, nu are sens s fie comparate numerele de identificare ale seciilor (atributul IdSecie) cu numerele de identificare ale angajailor (atributul IdAngajat), deci domeniile celor dou atribute sunt incompatibile. Cheia strin realizeaz asocierea N:1 ntre relaiile R1 i R2 (ceea ce este echivalent cu asocierea 1:N ntre relaiile R2 i R1) i reprezint o constrngere ntre dou relaii, numit constrngere referenial. Din punct de vedere al sistemelor SGBD reale i al limbajelor de definiie i manipulare a datelor, noiunea de compatibilitate semantic a domeniilor este mai puin evideniat. n limbajul SQL2 verificarea de compatibilitate a domeniilor se rezum la verificarea tipurilor de date ale atributelor corespondente, iar

16

compatibiltatea semantic trebuie s fie asigurat de ctre proiectant. Limbajul SQL2 admite ca i compatibile domenii care sunt definite pe acelai tip de date sau pe tipuri de date din aceeai categorie (ir de caractere, numr real, etc), chiar dac sunt incompatibile din punct de vedere semantic. De exemplu, limbajul SQL permite compararea valorilor atributului IdSectie cu valori ale atributului IdAngajat ale relaiei ANGAJATI, dat fiind c acestea sunt definite pe acelai tip de date (integer). n limbajul SQL cheia strin se specific la crearea relaiei (tabelului) care refer printr-o constrngere (CONSTRAINT) n care se specific atributele cheii strine i atributele cheii candidate (primare) corespunztoare din relaia referit:
[CONSTRAINT nume_constr] FOREIGN KEY (cheie_straina) REFERENCES relatia_referita (cheie_candidata)

Numele atributelor cheii strine nu trebuie s fie neaprat aceleai cu numele atributelor corespondente din cheia candidat referit, dei aceast notaie este frecvent folosit. Cu aceast notaie, se completeaz instruciunea de creare a tabelului ANGAJATI astfel:
CREATE TABLE ANGAJATI ( IdAngajat integer PRIMARY KEY,...... IdSecie integer, CHECK (Salariu >=1500), UNIQUE (Nume,Prenume,DataNasterii,Adresa), FOREIGN KEY (IdSectie)REFERENCES SECTII(IdSectie));

Se observ c n modelul relaional asocierea ntre relaii se realizeaz prin egalitatea valorilor atributelor cheii strine cu ale cheii referite, fr s fie necesar memorarea unor legturi (link-uri) explicite. Aceasta este una dintre cele mai remarcabile proprietile ale modelului relaional, care permite efectuarea oricrei interogri fr ca aceasta s fie prevzut prin structurarea explicit a datelor.

2.3.3.2 MENINEREA INTEGRITII REFERENIALE A DATELOR

Integritatea referenial (referential integrity) este proprietatea bazei de date care garanteaz c oricare valoare a unei chei strine se regsete printre valorile cheii candidate corespunztoare din relaia referit, sau cheia strin are valoarea NULL (dac atributele acesteia nu sunt supuse constr. NOT NULL). Operaiile de modificare a strii unei relaii (introducerea, tergerea i actualizarea tuplurilor relaiei) pot afecta integritatea referenial a unei baze de date, dac modificrile dintr-o relaie se fac individual, fr s se in seama de referinele ctre i de la aceasta. Restriciile care se impun operaiilor de modificare a relaiilor depind de rolul relaiei n diagrama de refereniere a bazei de date: relaie care refer sau relaie referit. De multe ori ns, o relaie poate avea ambele roluri, att de relaie care refer ct i de relaia referit i atunci restriciile de modificare trebuie s respecte ambele situaii. Operaia de introducere se poate face fr restricii ntr-o relaie referit. n schimb, la introducerea unui tuplu nou ntr-o relaie care refer (care conine o cheie strin) trebuie s se verifice c n relaia referit exist un tuplu care are valorile atributelor cheii referite egale cu valorile atributelor cheii strine a tuplului de introdus. Dac aceast condiie nu este satisfcut, operaia de introducere este refuzat. Operaia de tergere a unui tuplu se poate face fr nici o restricie ntr-o relaie care refer o alt relatie. ntr-o relaie referit, tergerea unui tuplu poate fi executat n dou moduri: tergere restricionat sau tergere n cascad. tergerea restricionat interzice tergerea unui tuplu din relaia referit dac acesta este referit de un tuplu din relaia care o refer. Pentru exemplul din figura 2.2, nu se poate terge tuplul (2,Proiectare,3000000) din relaia SECTII, deoarece acest tuplu este referit de tuplul (3,Vasilescu,...2) din relaia ANGAJATI. n schimb, tuplul (4,Documentare,1000000) poate fi ters din relaia SECTII, deoarece acesta nu este referit de nici un tuplu din relaia ANGAJATI. tergerea n cascad permite tergerea unui tuplu din relaia referit; dac tuplul ters era referit de unul sau mai multe tupluri, atunci se terg i acestea din relaia care o refer; dac tuplurile terse din relaia care refer sunt, la rndul lor referite de alte tupluri, atunci trebuie s fie terse i acestea, .a.m.d. Se execut deci o tegere n cascad, pe tot lanul de referiri. Operaia de actualizare poate fi privit ca o tergere urmat de o introducere, deci restriciile de actualizare reprezint combinaia restriciilor de introducere i de tergere. ntr-o relaie care refer, actualizarea cheii strine a unui tuplu este admis dac noua valoare a cheii strine se regsete ca valoare a cheii candidate corespunztoare ntr-unul din tuplurile relaiei referite. ntr-o relaie referit, actualizarea valorii cheii secundare (cheia primar nu poate fi modificat) poate fi fcut n aceleai moduri ca i tergerea tuplurilor: actualizare restricionat sau actualizare n cascad.

17

Stabilirea modului de tergere sau de actualizare a tuplurilor se face n comenzile SQL de creare sau modificare a tabelelor, prin adugarea uneia din opiunile ON DELETE, respectiv ON UPDATE, constrngerii de cheie strin. Valorile posibile ale acestor opiuni sunt RESTRICT (pentru tergerea restricionat) sau CASCADE (pentru tergerea n cascad); valoarea RESTRICT este implicit. Ca exemplu, se completeaz instruciunea SQL de creare a tabelului ANGAJATI cu opiunea de tergere n cascad pentru cheia strin IdSecie:
CREATE TABLE ANGAJATI ( IdAngajat integer PRIMARY KEY, Nume varchar (20) NOT NULL, .................................................. FOREIGN KEY (IdSectie)REFERENCES SECTII(IdSectie) , ON DELETE CASCADE );

2.4

Indexarea relaiilor

Unul din avantajele sistemelor de gestiune este acela de a elibera proiectantul bazei de date de necesitatea de a cunoate detaliile de organizare a datelor, prin asigurarea independenei datelor. Totui, aceast independen nu este complet i, n stadiul actual de realizare a sistemelor de baze de date, programatorii de aplicaii trebuie s ia n consideraie influena pe care modul de stocare i de regsire a datelor l are asupra performanelor aplicaiilor. ntr-o relaie, privit ca o colecie de elemente n care nu sunt admise elemente duplicat (deoarece este o mulime), operaiile de baz sunt, ca n orice colecie de elemente, cutarea, inserarea i tergerea unui element, crora, desigur, le corespund operaiile (interogare, inserare, tergere) din limbajele de manevrare a datelor n relaii. Relaiile unei baze de date sunt memorate n fiiere pe disc, iar comenzile de manevrare a datelor sunt transformate de SGBD n operaii asupra fiierelor care stocheaz relaiile bazei de date. Modul i timpul de execuie a acestor operaii de baz depind de modul de reprezentare a mulimii de elemente (tupluri) ale relaiei. n cazul unei mulimi reprezentate printr-o colecie neordonat de elemente, timpul de cutare a unui element crete proporional cu numrul de elemente ale mulimii, deoarece, n cazul cel mai defavorabil, este necesar s fie parcurse toate elementele coleciei pentru a gsi elementul dorit. n acest caz se poate considera timpul de cutare n O(N) pentru o mulime cu N elemente. Timpul de cutare a unui element poate s fie micorat semnificativ dac elementele mulimii sunt ordonate; de exemplu, la reprezentarea unei mulimi ca arbore binar ordonat, limita asimptotic a timpului de cutare este n O(log N). Pentru inserarea unui element ntr-o mulime, trebuie mai nti s fie cutat elementul respectiv n colecia (ordonat sau nu) prin care este reprezentat mulimea respectiv; dac exist deja un element identic, se interzice inserarea noului element; dac nu exist, atunci se introduce noul element. Timpul de inserare a unui element ntr-o mulime este compus din timpul de cutare al unui element, la care se adaug timpul de memorare propriu-zis. Observaii similare se pot face privind timpul de tergere a unui element dintr-o mulime. n general, operaiile de cutare, inserare i tergere a elementelor ntr-o mulime se execut mai rapid dac elementele mulimii sunt reprezentate printr-o colecie ordonat. Astfel se ajunge la situaia c, dei o relaie nu presupune ordonarea tuplurilor sale, pentru accelerarea operaiilor de cutare, inserare i tergere, se folosesc colecii ordonate, ca de exemplu arbori binari ordonai sau tabele de dispersie (hash table). Un index al unei relaii (index) este o structur auxiliar memorat n baza de date care permite accesul rapid la nregistrrile (tuplurile) relaiilor prin ordonarea acestora. La definirea unei relaii se stabilesc dou categorii de indexuri: indexul primar al relaiei, care determin localizarea tuplurilor n fiierele bazei de date, i zero, unul sau mai muli indexuri secundare, care nu modific localizarea tuplurilor, dar sunt folosii pentru regsirea tuplurilor dup un criteriu dat.

2.4.1

Indexul primar

Indexul primar (primary index) se definete pe unul sau mai multe atribute ale relaiei i reprezint cheia (eticheta) dup care ordoneaz tuplurile relaiei. Fiecare SGBD prevede o anumit modalitate de reprezentare a indexului primar. n continuare se va folosi termenul de etichet de ordonare, iar termenul de cheie de ordonare va fi evitat, pentru a nu se confunda cu cheia relaiei, ntruct este posibil s nu reprezinte acelai lucru, dei, n general, sistemele SGBD definesc n mod implicit indexul primar pe cheia primar a relaiei. Operaiile de cutare sau tergere n care se specific valoarea atributului index primar se execut de asemenea eficient: se calculeaz mai nti grupul cruia i aparine tuplul, prin aplicarea funciei de dispersie h asupra valorii atributului index, apoi se caut poziia tuplului n lista nlnuit corespunztoare grupului. Dup aceasta, se continu cu execuii specifice operaiei: se terge sau se citete tuplul gsit. De exemplu, pentru

18

rezolvarea interogrii "Care este oraul de domiciliu al studentului cu identificatorul 200?" se gsete tuplul (200,Marin,Dan,Craiova) folosind valoarea indexului primar (200). Dac ntr-o operaie de cutare sau tergere nu se specific valoarea atributului index primar, atunci cutarea unui anumit tuplu presupune parcurgerea (n cazul cel mai defavorabil) a tuturor listelor tuturor grupurilor tabelei de dispersie. De exemplu, interogarea "Care este oraul de domiciliu al studentului cu numele Marin?" gsete tuplul (200,Marin,Dan,Craiova) parcurgnd toate tuplurile i comparnd valoarea atributului Nume cu constanta Marin, pn este gsit tuplul care ndeplinete aceast condiie. Astfel de situaii sunt frecvent ntlnite n aplicaii, dat fiind c interogrile se formuleaz de obicei folosind un nume, nu un identificator (care este probabil cheie primar, deci conine indexul primar, dar este necunoscut utilizatorilor). Pentru rezolvarea mai eficient a unor astfel de interogri se pot defini indexuri secundare pe acele atribute care intervin frecvent n interogri.

2.4.2

Indexuri secundare

Un index secundar pe un atribut A al unei relaii (secondary index) este o structur care conine o mulime de perechi (v,L) ordonate dup v; fiecare pereche corespunde unui tuplu al relaiei, v este valoarea atributului A, iar L este adresa tuplului respectiv n structura indexului primar al relaiei. Un index secundar nu modific adresa de memorare a unui tuplu (care este coninut n structura indexului primar), dar conine informaii suplimentare care permit identificarea rapid a unui tuplu dup valoarea atributului indexului. Din punct de vedere al eficienei operaiilor de cutare n relaii este avantajos s fie definii orict de muli indexuri secundare, dar fiecare index secundar ocup spaiu de memorare suplimentar i trebuie s fie actualizat la fiecare operaie de inserare i tergere a unui tuplu, ceea ce nseamn timp de execuie suplimentar. n general, se recomand utilizarea unui numr ct mai mic de indexuri secundare, definii pe atributele care intervin cel mai frecvent n condiiile de interogare. Aceast decizie o ia proiectantul bazei de date prin analiza cerinelor din domeniul pentru care se dezvolt baza de date i aplicaiile corespunztoare. Dat fiind c indexurile sunt folosite n special pentru mbuntirea performanelor bazelor de date i nu fac parte din modelul relaional de baz, ei nu sunt cuprini n standardul limbajului SQL. ns majoritatea sistemelor SGBD ncorporeaz indexuri, coninnd instruciuni pentru crearea indexurilor de forma:
CREATE [optiuni] INDEX nume_index ON tabel (lista_atribute);

Forma exact i opiunile acestei instruciuni variaz de la un sistem SGBD la altul. Una din opiunile care se pot introduce n instruciunea CREATE INDEX este opiunea UNIQUE, care specific faptul c nu pot exista dou tupluri cu aceeai combinaie de valori ale atributelor indexului, deci acele atribute reprezint o cheie unic a relaiei. Unele sisteme SGBD adaug cte un index secundar pentru fiecare cheie unic, definit prin constrngerea UNIQUE din comanda CREATE TABLE.

19

3. INTEROGAREA BAZELOR DE DATE

Interogarea (query) este operaia prin care se obin datele dorite dintr-o baz de date, selectate conform unui anumit criteriu (condiie). Dat fiind c operaia de interogare este cea mai important operaie de manevrare a datelor, de multe ori limbajele de manevrare a datelor sunt denumite limbaje de interogare. Pentru formularea conceptual a interogrilor n bazele de date relaionale s-au dezvoltat dou limbaje abstracte de interogare: algebra relaional i calculul relaional [Date95], [Sim99]. Algebra relaional (relational algebra) const dintr-o mulime de operaii care au ca operanzi relaii, iar rezultatul este tot o relaie. Calculul relaional (relational calculus) este bazat pe calculul predicatelor i exprim o interogare formulnd o definiie a rezultatului dorit (de regul, o relaie) printr-o expresie de calcul relaional. Variabilele unei expresii de calcul relaional pot fi variabile de tuplu (variabile ale cror valori sunt definite pe mulimea tuplurilor unei anumite relaii) sau variabile de domeniu (variabile ale cror valori sunt definite pe domenii de definiie ale atributelor). Pe baza unor astfel de variabile se definete calculul relaional al tuplurilor, respectiv calculul relaional al domeniilor. Aceste limbaje de interogare abstracte, algebra relaional, calculul relaional al tuplelor i calculul relaional al domeniilor sunt echivalente din punct de vedere al capacitii de exprimare a interogrilor, diferenele constnd n modul de formulare a acestora. S-a demonstrat c, pentru orice expresie de algebr relaional, se poate gsi o expresie de calcul relaional echivalent i invers. Limbajele de interogare reale implementate n sistemele de baze de date relaionale sunt limbaje definite pe baza unuia sau altuia din limbajele de interogare abstracte, sau pe o combinaie a acestora. De exemplu: Limbajul SQL2 este n cea mai mare parte bazat pe algebra relaional, dar mai conine i construcii derivate din calculul relaional. Limbajul ISBL (Information System Base Language) al firmei IBM este bazat n ntregime pe algebra relaional. Limbajul QUEL al SGBD Ingres este bazat pe calculul relaional al tuplurilor. Limbajul QBE (Query by Example), dezvoltat la firma IBM este bazat pe calculul relaional al domeniilor. Un limbaj de interogare real este denumit relaional complet dac implementeaz toate operaiile prevzute de unul din limbajele de interogare abstracte. n general, toate limbajele relaionale implementate n sistemele SGBD sunt limbaje relaionale mai mult dect complete, coninnd i operaii care nu sunt prevzute n limbajele relaionale abstracte, ca de exemplu, efectuarea unor calcule aritmetice asupra valorilor unor atribute (sum, medie, minim, maxim), funcii de tiprire a relaiilor, etc. Limbajul SQL2 este limbajul cel mai utilizat n sistemele relaionale i de aceea, n continuare majoritatea exemplificrilor vor fi prezentate n SQL2.

3.1

ALGEBRA RELAIONAL

Algebra relaional (relational algebra) exprim interogrile prin aplicarea unor operatori specializai (operatorii algebrei relaionale) asupra relaiilor. E.F. Codd a propus opt operaii ale algebrei relaionale, grupate n dou categorii: Operaii pe mulimi: reuniunea (union), intersecia (intersection), diferena (difference) i produsul cartezian (Cartesian product). Aceste operatii reprezint adaptarea operatiilor corespunztoare din teoria mulimilor i acioneaz asupra relaiilor vzute ca mulimi de elemente (tupluri), fr a lua n consideraie compoziia fiecrui element. Operaii relaionale speciale: restricia (restriction), proiecia (projection), jonciunea (join) i diviziunea (division). Aceste operaii iau n consideraie compoziia tuplurilor, formate din valori ale atributelor relaiilor. Toate aceste operaii trebuie s asigure proprietatea de nchidere, adic rezultatul fiecrei operaii trebuie s fie tot o relaie. Aceast proprietate permite efectuarea operaiilor imbricate: proiecia unei jonciuni dintre o relaie i restricia aplicat altei relaii, etc. Restricia i proiecia sunt operaii unare (au un singur operand, o relaie); operatiile pe mulimi, jonciunea i diviziunea sunt operaii binare (au doi operanzi, dou relaii).

3.1.1

OPERAII PE MULIMI

n operaiile asupra relaiilor considerate ca mulimi se impun anumite condiii celor doi operanzi, astfel nct relaia rezultat s fie obinut ca o mulime de tupluri omogene. Aceste condiii depind de tipul operaiei: reuniunea, intersecia i diferena necesit ca relaiile s fie compatibile, iar produsul cartezian necesit ca numele atributelor celor dou relaii operand s fie distincte. Pentru ca dou relaii s fie compatibile, trebuie s aib acelai numr de atribute i atributele corespondente s fie definite pe domenii compatibile. Reuniunea a dou relaii compatibile R i S este o relaie QU = R S care conine toate tuplurile ce aparin fie relaiei R, fie relaiei S, fie ambelor relaii. Tuplurile care aparin ambelor relaii se introduc n relaia rezultat o singur dat, adic nu se duplic. Operaia de reuniune se exprim n limbajul SQL ca o reuniune a dou tabele obinute ca rezultat a dou comenzi SELECT, cu sintaxa:
SELECT lista_coloane1 FROM tabel1 [WHERE condiie1] UNION SELECT lista_coloane2 FROM tabel2 [WHERE condiie2];

Cele dou liste de coloane din clauzele SELECT trebuie s conin atribute compatibile. Tabelele din clauzele FROM, ca i condiiile din clauzele WHERE pot fi identice sau diferite. Fie relaiile: ANGAJATI(IdAngajat,Nume,Prenume,DataNasterii, Adresa,Functie, Salariu) i FURNIZORI(IdFurnizor,Nume,Prenume,DataNaterii,Adresa,Firma). O operaie de reuniune pe baza acestor relaii poate arta astfel:
SELECT Nume,Prenume FROM ANGAJATI WHERE Adresa = Bucuresti UNION SELECT Nume,Prenume FROM FURNIZORI WHERE Adresa = Bucureti;

Rezultatul va fi o relaie cu atributele (Nume,Prenume) care conine numele i prenumele tuturor angajailor i ale furnizorilor care locuiesc n oraul Bucureti. Dac exist tupluri duplicat (un angajat i un furnizor cu acelai nume i prenume, ceea ce este posibil), relaia rezultat conine un singur tuplu cu valorile respective. Opiunea SQL UNION ALL permite ca rezultatul s conin duplicate, deci acest rezultat nu mai poate fi numit relaie. Dup cum se observ, limbajul SQL admite unele construcii care nu respect cerinele teoretice ale modelului relaional. Intersecia a dou relaii compatibile R i S este o relaie QI = R S care conine toate tuplurile care aparin att relaiei R ct i relaiei S. La fel ca i reuniunea, operaia de intersecie se exprim n SQL ca intersecie a dou tabele obinute ca rezultat a dou comenzi SELECT, cu sintaxa:
SELECT lista_coloane1 FROM tabel1 [WHERE condiie1] INTERSECT SELECT lista_coloane2 FROM tabel2 [WHERE condiie2];

Diferena a dou relaii compatibile R i S este o relaie QM = R - S care conine toate tuplurile care aparin relaiei R, dar nu aparin relaiei S. Operaia de diferen se exprim n SQL ca diferen a dou tabele obinute ca rezultat a dou comenzi SELECT, cu sintaxa:
SELECT lista_coloane1 FROM tabel1 [WHERE condiie1] MINUS SELECT lista_coloane2 FROM tabel2 [WHERE condiie2];

Reuniunea i intersecia sunt comutative (R S = S R; R S = S R) i asociative (R (S T) = (R S) T; R (S T) = (R S) T). Diferena nu este nici comutativ (R S S - R), nici asociativ (R (S T) (R S) T). Produsul cartezian. n teoria mulimilor, produsul cartezian al mulimilor R i S este o mulime compus din toate perechile ordonate de elemente ale celor dou mulimi: R S = {<a,b> a R,b S}. n algebra relaional, produsul cartezian al relaiilor R(A1,A2,... An) i S(B1,B2,...Bm) este o relaie QC(A1,A2,....An,B1,B2,...Bm) = R S care are ca atribute toate atributele primei relaii plus toate atributele celei de-a doua relaii. Pentru a se obine tuplurile relaiei rezultat se combin (se concateneaz) valorile atributelor fiecrui tuplu din prima relaie cu valorile atributelor tuturor tuplurilor din cea de-a doua relaie. Din aceast definiie se observ c gradul relaiei rezultat este egal cu suma gradelor celor dou relaii operanzi, iar cardinalitatea este egal cu produsul cardinalitilor celor dou relaii operand.

Ca exemplu, se va calcula produsul cartezian al relaiilor ANGAJATI i SECTII, prezentate mai jos n figura. 3.1. ANGAJATI
IdAngajat 1 2 3 4 Nume Ionescu Popescu Vasilescu Ionescu Prenume Ion Petre Ana Ion DataNasterii 1945.01.05 1972.06.21 1966.04.02 1970.11.12 Adresa Bucuresti Bucuresti Bucuresti Bucureti Salariu 4000 3500 3000 2500 IdSectie 1 1 2 3

SECTII
IdSectie 1 2 3 Nume Productie Proiectare Cercetare Buget 4000000 3000000 2000000

ANGAJATI SECTII
IdAngajat 1 1 1 2 2 2 3 3 3 4 4 4 ANGAJATI. Nume Ionescu Ionescu Ionescu Popescu Popescu Popescu Vasilescu Vasilescu Vasilescu Ionescu Ionescu Ionescu .... ANGAJATI. IdSectie 1 1 1 1 1 1 2 2 2 3 3 3 SECTII. IdSectie 1 2 3 1 2 3 1 2 3 1 2 3 SECTII. Nume Productie Proiectare Cercetare Productie Proiectare Cercetare Productie Proiectare Cercetare Productie Proiectare Cercetare Buget 4000000 3000000 2000000 4000000 3000000 2000000 4000000 3000000 2000000 4000000 3000000 2000000

Fig. 3.1. Produsul cartezian a dou relaii. Pentru ca rezultatul produsului cartezian s fie corect din punct de vedere relaional, este necesar ca atributele celor dou relaii operand s aib nume diferite, deoarece n relaia rezultat nu pot exista dou atribute cu acelai nume. Aceast cerin se rezolv uor, prin calificarea numelor unor atribute cu numele relaiei creia i aparin sau prin redenumirea atributelor. Calificarea numelui unui atribut cu numele relaiei se realizeaz prin scrierea numelui atributului precedat de numelui relaiei, cele dou nume fiind separate prin operatorul punct (.), la fel ca n reprezentarea datelor sau funciilor membre ale unui obiect (instan a unei clase) n programarea obiect-orientat. De exemplu, atributul IdSectie din relaiile ANGAJATI i SECTII se poate diferenia prin calificare astfel: SECTII.IdSectie i ANGAJATI.IdSectie. Pentru redenumirea atributelor n algebra relaional se poate folosi o operaie special, care se adaug celor opt operaiii de baz. Sintaxa conceptual a operaiei de redenumire este:
RENAME nume_relatie.nume_atribut AS noul_nume_atribut

Operaia produs cartezian este conceptual comutativ, adic RS = SR, dac se consider c atributele unei relaii nu sunt ordonate. Dac se consider schema relaiei rezultat ca list a atributelor sale, atunci, prin convenie, atributele primei relaii operand sunt primele n lista de atribute a relaiei rezultat, iar atributele celei de-a doua relaii urmeaz n lista atributelor relaiei rezultat. Operaia produs cartezian este asociativ, dac se consider c ordinea atributelor ntr-o schem de relaie i ordinea tuplurilor ntr-o relaie nu este relevant: R (S T) = (R S) T. n limbajul SQL, produsul cartezian a dou tabele R i S se obine ca o variant a instruciunii SELECT, ntr-una din formele:

SELECT * FROM R,S; SELECT lista_coloane FROM R,S;

n prima form, limbajul SQL admite operaia produs cartezian i n situaia n care n cele dou relaii operand exist dou atribute cu acelai nume, subnelegndu-se c atributele rezultatului sunt ordonate, mai nti fiind atributele primei relatii, urmate de atributele celei de-a doua relatii. Pentru cea de-a dou form, atributele cu acelai nume trebuie s fie calificate cu numele relaiei respective. De exemplu, produsul cartezian al relaiilor SECTII(IdSectie,Nume,Buget) i ANGAJATI(IdAngajat,Nume,Prenume,DataNasterii,Adresa,Salariu,IdSectie) se poate scrie n SQL ntr-una din formele:
SELECT * FROM SECTII,ANGAJATI; SELECT SECTII.IdSectie,SECTII.Nume,Buget,IdAngajat, ANGAJATI.Nume,Prenume,DataNasterii,Adresa,Salariu, ANGAJATI.IdSectie FROM SECTII,ANGAJATI;

n plus, n limbajul SQL se pot redenumi atributele folosind cuvntul cheie AS ntre numele unui atribut i redenumirea acestuia. n aceast form, interogarea precedent poate fi scris astfel:
SELECT SECTII.IdSectie,SECTII.Nume AS SNume, Buget,IdAngajat,ANGAJATI.Nume AS ANume, Prenume,DataNasterii,Adresa,Salariu, ANGAJATI.IdSectie FROM SECTII,ANGAJATI;

n unele implementri ale limbajului SQL nu este necesar cuvntul cheie AS pentru redenumirea atributelor.

3.1.2

OPERAII RELAIONALE SPECIALE

n operaiile speciale asupra relaiilor se ia n consideraie compoziia tuplurilor (combinaii de valori ale atributelor) i se impun anumite condiii atributelor acestora. Restricia (restriction) este o operaie relaional unar care selecteaz dintre tuplurile relaiei operand acele tupluri care ndeplinesc o condiie dat. Operaia de restricie se mai numete i selecie (i, ntr-adevr, restricia face o selecie a tuplurilor), dar este mai bine s fie evitat aceast denumire deoarece se poate confunda cu instruciunea SELECT, care are rolul de instruciune general de interogare. Operaia de restricie se noteaz: (R), unde este o expresie logic specificat asupra atributelor relaiei R. n relaia rezultat sunt selectate acele tupluri ale relaiei R pentru care expresia are valoarea 1 (TRUE). Relaia rezultat are aceleai atribute ca i relaia operand. Expresia logic este format din una sau mai multe variabile logice v conectate prin operatorii logici AND, OR, NOT, ca de exemplu: = v1 AND (v2 OR v3)... Fiecare variabil logic v este rezultatul returnat de un operator de comparaie. Se pot compara valorile a dou atribute sau se poate compara valoarea unui atribut cu o constant. De exemplu, pentru a selecta din relaia ANGAJATI toi angajaii care lucreaz n secia 1 i au salarii mai mari sau egale cu 4000 i pe cei care lucreaz n secia 2 i au salarii mai mari sau egale cu 3000, se folosete restricia prezentat n figura 3.2. Rezultatul prezentat corespunde strii relaiei ANGAJATI din figura 3.1. Precedena operatorilor logici este cea cunoscut din logica matematic: NOT, AND, OR; aceast preceden se poate modifica folosind paranteze. n expresia din figura 3.2 nu sunt neaprat necesare parantezele, dar au fost introduse pentru a evidenia mai clar condiiile impuse valorilor atributelor.

(IdSectie=1
IdAngajat 1 3

AND Salariu 4000) OR (IdSectie=2 AND Salariu 3000)(ANGAJATI)

Nume Ionescu Vasilescu

Prenume Ion Ana

DataNasterii 1945.01.05 1966.04.02

Adresa Bucuresti Bucuresti

Salariu 4000 3000

IdSectie 1 2

Fig. 3.2. Operaia de restricie. O secven de restricii poate fi aplicat n orice ordine, adic:

cond1(cond2(R)) = cond2(cond1(R)) Mai mult, se poate observa i demonstra cu uurin c orice secven de restricii poate fi nlocuit printr-o singur restricie n care expresia logic de condiie se obine prin conjuncia (AND) tuturor condiiilor: cond1(cond2(..condn(R)..)) = cond1
AND cond2...AND condn(R)

Identitatea de mai sus poate fi interpretat i invers, i anume c operaia de restricie poate fi divizat (splitat) n operaii de restricii succesive cu condiii care sunt componentele conjunctive (conectate prin operatorul AND) ale condiiei de restricie. Cardinalitatea (numrul de tupluri) relaiei rezultat al operaiei de restricie este mai mic sau cel mult egal cu cardinalitatea relaiei operand. Situaia de egalitate apare dac expresia logic de condiie este evaluat la valoarea TRUE pentru oricare tuplu al relaiei operand. De regul, ns, prin operaia de restricie se obine un numr de tupluri mai mic dect numrul de tupluri al relaiei date. n limbajul SQL restricia se exprim printr-o form particular a instruciunii SELECT, n care lista de atribute este format din toate atributele unei singure relaii, iar clauza WHERE este obligatorie i introduce condiia de restricie:
SELECT * FROM tabel WHERE conditie [clauze_secundare];

De exemplu, pentru a obine restricia din figura 3.2 se introduce comanda:

SELECT * FROM ANGAJATI WHERE IdSectie = 1 AND Salariu >= 4000 OR IdSectie = 2 AND Salariu >=3000;

n termenii folosii n limbajul SQL, restricia selecteaz o parte din liniile tabelului operand. Proiecia (projection) este o operaie relaional unar prin care se selecteaz o submulime de atribute ale relaiei operand. Notaia pentru proiecie este: lista_atribute(nume_relatie). Relaia rezultat a operaiei de proiecie conine numai atributele din lista de atribute dat ca parametru, care este o submulime nevid a mulimii atributelor relaiei operand. Dou exemple de operaii de proiecie asupra relaiei ANGAJATI cu starea din figura 3.1 sunt prezentate n figura 3.3. Dac lista atributelor de proiecie este o cheie (sau conine o cheie) a relaiei operand, atunci relaia rezultat are toate tuplurile distincte (fig. 3.3, a). n aceast situaie numrul de tupluri ale relaiei rezultat este egal cu numrul de tupluri ale relaiei operand. Dac lista de atribute nu este o cheie (sau nu conine o cheie) a relaiei operand, atunci este posibil ca prin proiecie s se obin dou sau mai multe tupluri identice, dar n relaia rezultat sunt eliminate tuplurile duplicat. De exemplu, n proiecia pe atributele (Nume,Prenume) a relaiei ANGAJATI din figura 3.3, b tuplul (Ionescu,Ion) este introdus o singur dat n relaia rezultat, dei el este obinut de dou ori prin operaia de proiecie. n acest situaie, numrul de tupluri ale relaiei rezultat este mai mic dect numrul de tupluri ale relaiei operand. Gradul relaiei rezultat al unei proiecii (numrul de atribute) este mai mic sau egal cu gradul relaiei operand. Numrul de atribute al relaiei rezultat este egal cu numrul de atribute al relaiei operand dac lista de proiecie este identic cu lista atributelor relaiei date. IdAngajat,Nume,Prenume(ANGAJATI)
IdAngajat 1 2 3 4 Nume Ionescu Popescu Vasilescu Ionescu a Prenume Ion Petre Ana Ion

Nume,Prenume(ANGAJATI)
Nume Ionescu Popescu Vasilescu b Prenume Ion Petre Ana

Fig. 3.3. Operaii de proiecie: a - lista atributelor de proiecie conine o cheie a relaiei operand; b - lista atributelor de proiecie nu conine o cheie a relaiei operand. Fie o succesiune de operaii de proiecie: lista1(lista2 ...(listak(R))...)

O astfel de succesiune de proiecii este corect numai dac lista1 lista2... listak; bineneles, se consider listele de atribute ca mulimi. n aceast situaie, ntreaga succesiune de proiecii se poate nlocui cu proiecia pe lista de atribute cea mai din stnga: lista1(R). Egalitatea de mai sus se poate interpreta i reciproc: o proiecie pe o mulime de atribute (lista1) poate fi nlocuit cu o succesiune de proiecii pe mulimi de atribute care includ lista de atribute dat. n limbajul SQL, operaia de proiecie se obine tot prin instruciunea de interogare SELECT; lista de coloane introdus n instruciunea SELECT este lista atributelor de proiecie. Sub forma:
SELECT DISTINCT lista_coloane FROM nume_tabel;

instruciunea SELECT reprezint o operaie de proiecie asupra relaiei nume_tabel pe atributele date n lista_coloane. De exemplu, proiecia din figura 3.3, b se scrie poate n SQL astfel:
SELECT DISTINCT Nume,Prenume FROM ANGAJATI;

Dac lipsete clauza DISTINCT i lista de atribute nu este o supercheie a relaiei, rezultatul operaiei poate conine tupluri duplicat (deci nu este o relaie n sensul definiiei din modelul relaional). n termenii folosii n limbajul SQL, proiecia realizeaz o selecie a coloanelor unui tabel. Jonciunea (cuplarea) - (join) este o operaie binar a algebrei relaionale prin care se combin tuplurile a dou relaii ntr-o singur relaie. Jonciunea se noteaz cu semnul >< i este o operaie foarte important n bazele de date relaionale, deoarece ea permite realizarea asocierilor ntre relaii. n continuare vor fi prezentate dou forme ale operaiei de jonciune: -jonciunea i jonciunea natural.

-jonciunea a dou relaii R(A1,A2,...An) i S(B1,B2,...Bm) este o relaie QJ(A1,A2,...

An,B1,B2,...Bm) = R >< S, n care fiecare tuplu este o combinaie a dou tupluri, unul din relaia R (cu atributele A1,A2,....An), iar cellalt din relaia S (cu atributele B1,B2,...Bm), combinaie care satisface condiia de jonciune . Forma general a condiiei de jonciune este:
B

= cond1 AND cond2...AND condi...AND condn

unde fiecare condiie parial (condi) este o variabil logic, rezultat al unei operaii de comparaie # (unde # poate fi unul din operatorii: =, , <, , >, ) asupra valorilor a dou atribute Ai (care aparine relaiei R) i Bi (care aparine relaiei S), deci:
B

condi = Ai # Bi

Atributele Ai i Bi ale cror valori se compar trebuie s fie definite pe domenii compatibile. Tuplurile n care atributele din condiiile de jonciune au valori NULL nu sunt luate n consideraie pentru calculul relaiei rezultat. Se observ asemnarea operaiei de -jonciune cu produsul cartezian, dat fiind c tuplurile relaiei rezultat sunt combinaii ale tuplurilor relaiilor operand, cu numr de atribute (gradul relaiei) egal cu suma numrului de atribute (gradul) ale celor doi operanzi. Diferena esenial dintre jonciune i produsul cartezian este aceea c n operaia de jonciune se combin numai tuplurile care ndeplinesc condiia de jonciune , pe ct vreme n operaia produs cartezian n relaia rezultat se includ toate combinaiile de tupluri din relaiile operand. Ca urmare, operaia de -jonciune poate fi scris ca restricie cu condiia a produsului cartezian al celor dou relaii: R >< S = (R S). Ca exemplificare, se va calcula jonciunea:
B

ANGAJATI >< SECTII = (ANGAJATI SECTII) cu condiia: =(ANGAJATI.IdSectie = SECTII.IdSectie), asupra relaiilor ANGAJATI(IdAngajat, Nume,Prenume,DataNasterii,Adresa,Salariu,IdSectie) i SECTII (IdSectie,Nume,Buget) cu valorile date n figura 3.1. Rezultatul acestei operaii este dat n figura 3.4. ANGAJATI ><(ANGAJATI.IdSectie
IdAngajat 1 2 3 4 ANGAJATI. Nume Ionescu Popescu Vasilescu Ionescu ....
= SECTII.IdSectie)SECTII

ANGAJATI. IdSectie 1 1 2 3

SECTII. IdSectie 1 1 2 3

SECTII. Nume Productie Productie Proiectare Cercetare

Buget 4000000 4000000 3000000 2000000

Fig. 3.4. Operaie de -jonciune ntre relaiile ANGAJATI i SECTII. 6

Cea mai utilizat form de -jonciune este echijonciunea, n care se folosete numai operatorul de comparaie de egalitate (=). De altfel, exemplul prezentat mai sus este o echijonciune. ntr-o echijonciune vor exista ntotdeauna una sau mai multe perechi de atribute care au valori identice n fiecare din tuplurile relaiei rezultat, i anume perechile de atribute care sunt comparate pentru egalitate. n figura de mai sus, atributele ANGAJATI.IdSectie i SECTII.IdSectie au valori identice n toate tuplurile, dat fiind c acestea au fost comparate pentru egalitate n condiia de jonciune. Este de remarcat faptul c operatorul de comparaie de egalitate (=) folosit n modelul relaional este corespunztor operatorului (= =) din limbajul C (C++) i este identic cu operatorul de asignare; diferenierea dintre cei doi operatori cu acelai semn de reprezentare rezult din context (expresia n care apar). Jonciunea natural. Dat fiind c ntr-o relaie nu sunt necesare dou atribute cu valori identice, s-a definit o nou operaie de jonciune, numit jonciunea natural (natural join) sau, chiar mai simplu, jonciune. Jonciunea natural este o echijonciune n care fiecare pereche de atribute comparate pentru egalitate (n condiia de jonciune) se nlocuiete cu unul singur. Se poate spune c jonciunea natural este o echijonciune urmat de o proiecie pe reuniunea atributelor celor dou relaii. Dat fiind c -jonciunea este o restricie a produsului cartezian al celor dou relaii operand, rezult jonciunea natural ca o proiecie a unei restricii a produsului cartezian al celor dou relaii. Dac se noteaz relaiile operand cu R(A1,A2,...An,B1,B2,...Bm) i S(B1,B2,...Bm, C1,C2,...Ck), cu atributele comune (B1,B2,...Bm), rezultatul operaiei de jonciune natural este relaia QJ cu expresia: QJ = R >< S = A1,.An,B1,.Bm,C1,.Ck (R.B1=S.B1
B

AND R.Bm=S.Bm)(R

S)

Atributele (B1,B2,...Bm) din cele dou relaii comparate pentru egalitate n jonciunea natural se numesc atribute comune (sau atribute de jonciune) i trebuie s fie definite pe domenii compatibile. Ele se consider identice (chiar dac au denumiri diferite) i n reuniunea atributelor se introduc o singur dat. Jonciunea natural se reprezint numai cu semnul ><, fr s mai fie nsoit de condiia de jonciune, nelegnd prin aceasta c jonciunea are loc pe atributul (sau atributele) comune ale celor dou relaii. n figura 3.5 este prezentat rezultatul jonciunii dintre relaiile ANGAJATI i SECTII cu starea din figura 3.1 pe atributul comun IdSectie. Atributul comun (IdSectie) apare o singur dat n relaia rezultat. ANGAJATI >< SECTII
IdAngajat 1 2 3 4 ANGAJATI. Nume Ionescu Popescu Vasilescu Ionescu ... ... Salariu 4000 3500 3000 2500 IdSectie 1 1 2 3 SECTII. Nume Productie Productie Proiectare Cercetare Buget 4000000 4000000 3000000 2000000

Fig. 3.5. Jonciunea natural a relaiilor ANGAJATI, SECTII. Gradul relaiei rezultat al jonciunii naturale a celor dou relaii este: q = n + m + k i este mai mic dect suma gradelor celor dou relaii (sum egal cu n + 2*m + k). Dac nu exist nici o combinaie de tupluri care s ndeplineasc condiia de jonciune, rezultatul operaiei este o relaie cu zero tupluri. Dac nu se impune nici-o condiie de jonciune, jonciunea devine un produs cartezian al celor dou relaii, cu un numr de tupluri egal cu produsul (NR NS) al numrului de tupluri NR i respectiv NS, ale celor dou relaii. n cazul general, numrul de tupluri ale relaiei rezultat al operaiei de jonciune este cuprins ntre 0 i (NR NS). Operaia de jonciune natural este conceptual comutativ (adic R >< S = S >< R), dac se consider c atributele unei relaii nu sunt ordonate. Dac se consider schema relaiei rezultat ca list a atributelor sale, atunci, prin convenie, atributele primei relaii operand sunt primele n lista de atribute a relaiei rezultat, iar atributele celei de-a doua relaii, mai puin atributul (sau atributele) de jonciune, urmeaz n lista atributelor relaiei rezultat. Operaia de jonciune natural nu este, n general, asociativ. Fie mulimile de atribute disjuncte A, B, C, D i relaiile cu schemele: R(A,B), S(B,C) i T(A,D). n expresia (R >< S)>< T se efectueaz mai nti jonciunea R >< S pe atributul comun B ale celor dou relaii, rezultnd o relaie cu schema Q(A,B,C), dup care se efectueaz jonciunea Q >< T pe atributul comun A.

Asocierea de la dreapta la stnga a relaiilor date (expresia R ><(S >< T)) nu este posibil, deoarece jonciunea (S >< T) nu se poate evalua, dat fiind c relaiile S(B,C) i T(A,D) nu au nici-un atribut comun. Se poate remarca uor c exist i situaii n care jonciunea natural este asociativ, i anume cnd fiecare pereche de relaii din expresia dat au atribute comune. Operaia de jonciune natural este utilizat pentru a combina date din dou relaii, astfel nct informaia rezultat s fie cuprins ntr-o singur relaie. n cazul cel mai frecvent, jonciunea natural se calculeaz ntre o relaie care refer i relaia referit, atributul de jonciune fiind cheia strin (n relaia care refer), respectiv cheia primar (sau candidat) n relaia referit. Rezultatul obinut reflect asocierea dintre cele dou relaii. De exemplu, jonciunea natural din figura 3.5 ntre relaiile ANGAJATI i SECTII reflect asocierea N:1 ntre acestea. Din acest exemplu se poate remarca faptul c prin operaia de jonciune se obin informaii combinate din cele dou relaii operand. Pentru fiecare tuplu din relaia care refer (n exemplul de mai sus, relaia ANGAJATI) se obin toate informaiile din tuplul referit (n exemplul de mai sus, relaia SECTII), adic acel tuplu care are valoarea cheii primare egal cu valoarea cheii strine care o refer. n exemplul de mai sus, prima linie a tabelului rezultat conine toate informaiile (nume secie, buget) despre secia n care lucreaz angajatul respectiv (secia 1), etc. Fora modelului relaional const n posibilitatea de a combina informaiile din dou sau mai multe relaii pentru a obine rezultatul unei interogri, combinare care se poate face printr-una sau mai multe operaii de jonciune. Aceast posibilitate de combinare a informaiilor este denumit de unii autori ca o navigare prin baza de date. n limbajul SQL, -jonciunea se poate exprima direct cu o instruciune SELECT pe dou sau mai multe tabele, condiia de jonciune fiind introdus prin clauza WHERE. De exemplu, -jonciunea din figura 3.4 se poate obine prin instruciunea:
SELECT * FROM ANGAJATI,SECTII WHERE ANGAJATI.IdSectie = SECTII.IdAngajat;

O jonciune natural se poate exprima n limbajul SQL numai n mod explicit, adic trebuie ca lista de atribute a instruciunii SELECT s conin numai atributele diferite din cele dou relaii (fiecare atribut de jonciune se introduce o singur dat), iar n clauza WHERE trebuie introdus condiia de egalitate a atributelor corespondente. De exemplu, jonciunea natural ANGAJATI >< SECTII din figura 3.5 se obine prin instruciunea SQL:
SELECT IdAngajat,ANGAJATI.Nume,Prenume,DataNasterii, Adresa,Salariu,SECTII.IdSectie,SECTII.Nume, Buget,IdAngajat FROM ANGAJATI,SECTII WHERE ANGAJATI.IdSectie = SECTII.IdSectie;

Diviziunea (division) este o operaie binar a algebrei relaionale prin care se obine o relaie care conine atributele diferenei mulimilor de atribute ale relaiilor operand. Fie dou mulimi de atribute: A = {A1,A2,..An} i B = {B1,B2,..Bm} i dou relaii R(A,B) i S(B) astfel nct mulimea atributelor relaiei S s fie o submulime a mulimii atributelor relaiei R. Relaia QD obinut prin operaia de diviziune are ca atribute toate atributele diferenei celor dou mulimi de atribute (adic acele atribute care aparin relaiei R i nu aparin relaiei S) i conine acele tupluri t[A] care au proprietatea c pentru orice tuplu s din S exist un tuplu t n R care are atributul B egal cu tuplul s. Se poate scrie: QD(A) = R S = A R.B = S.B(R) n limbajul SQL, diviziunea se exprim printr-o instruciune SELECT, introducnd explicit lista atributelor de proiecie i condiia de egalitate a atributelor corespondente din cele dou relaii prin clauza WHERE. Algebra relaional este o colecie de operaii asupra relaiilor. Cele opt operaii propuse de E.F.Codd (reuniunea, intersecia, diferena, produsul cartezian, restricia, proiecia, jonciunea, diviziunea), la care se adaug operaia de redenumire a atributelor, nu constituie o mulime minim de operaii ale algebrei relaionale, deoarece o parte din operaii se pot exprima prin intermediul altora. Aa cum s-a prezentat mai sus, jonciunea este o proiecie a unei restricii a produsului cartezian al celor dou relaii, iar diviziunea este o proiecie a unei restricii asupra relaiei demprit. La fel, intersecia se poate exprima printr-o expresie construit pe baza operaiei de diferen: R S = R (R S). Cinci operaii (reuniunea, diferena, produsul cartezian, restricia, proiecia) sunt operaii primitive i constituie mulimea minim de operaii ale algebrei relaionale. Pe baza lor se poate construi orice expresie a algebrei relaionale. Dar i celelalte trei operaii (i n special jonciunea) sunt operaii deosebit de utile n formularea interogrilor, astfel nct algebra relaional a pstrat toate cele opt operaii propuse de E.F.Codd, la care s-a adugat operaia de redenumire a atributelor.

3.1.3

FORMULAREA INTEROGRILOR

Interogrile exprimate n limbaj natural se pot formula ntr-unul din limbajele abstracte de interogare, algebra relaional sau calculul relaional, dup care se poate gsi comanda corespunztoare n limbajul de interogare implementat de sistemul SGBD n care va fi realizat baza de date (cum este limbajul SQL). Pentru utilizator, o interogare este o metod de a regsi anumite informaii dintr-o baz de date, prin intermediul unei aplicaii de baze de date. Din punctul de vedere al programatorului aplicaiei de baze de date, interogarea se exprim printr-o comand echivalent expresiei de interogare, comand care se transmite sistemului SGBD. Din punct de vedere al sistemului de gestiune, o interogare este un program (de exemplu, n limbajul SQL) pe care l compileaz i apoi l execut. Ca orice program, o interogare este prelucrat de ctre SGBD n mai multe faze: analiza lexical, analiza sintactic i analiza semantic, pentru validarea interogrii, urmate de generarea codului. De asemenea, dac exist mai multe soluii pentru aceeai interogare, sistemul de gestiune selecteaz soluia optim. Conceptual, subsistemul SGBD de prelucrare a interogrilor const din urmtoarele componente: Compilatorul de interogri, care efectueaz analiza lexical i sintactic a interogrii; acesta valideaz din punct de vedere sintactic interogarea, adic verific existena relaiilor, a vederilor, a indexurilor i a atributelor implicate n interogare i utilizarea corect a acestora. Optimizatorul de interogri, care efectueaz analiza semantic a interogrii i selecteaz alternativa optim dintre mai multe soluii posibile de execuie a interogrii. Generatorul de cod, care genereaz programul de execuie al interogrii, conform optimizrilor efectuate. Componenta de execuie (runtime), care execut programul interogrii. Compilarea interogrii se realizeaz la fel ca orice compilare a programelor, fr aspecte specifice sistemelor de baze de date. Optimizarea interogrilor este o operaie specific sistemelor de gestiune i utilizeaz proprietile operaiilor relaionale pentru a obine performane de execuie a interogrilor ct mai bune. Optimizarea este efectuat de ctre SGBD, transparent, fr intervenia programatorului. n algebra relaional o interogare se formuleaz printr-o expresie constnd dintr-o secven de identificatori (nume de relaii, nume de atribute), constante i operatori. Pentru exprimarea unei interogri printro expresie de algebr relaional, trebuie s fie precizate urmtoarele elemente: Lista atributelor relaiei rezultat, care se numesc atribute de proiecie. Lista relaiilor din care se extrag informaiile. Condiia pe care trebuie s o ndeplineasc tuplurile relaiei rezultat.

n funcie de aceste elemente, se pot studia dou situaii de rezolvare a interogarilor: interogri care se rezolv n cadrul unei singure relaii i interogri care se rezolv folosind dou sau mai multe relaii ale bazei de date. Interogri ntr-o singur relaie. Dac toate atributele care intervin n interogare (atributele de proiecie i atributele din condiie) sunt atribute ale unei singure relaii R, atunci interogarea se poate rezolva la nivelul acelei relaii, ca o proiecie (pe atributele relaiei rezultat) a restriciei cu condiia impus asupra relaiei date, prin expresia: Q = lista_atribute conditie(R) Exemplul 3.1. Fie relaia ANGAJATI definit n figura 3.1 i interogarea: Care sunt numele i prenumele angajailor care au un salariu mai mare sau egal cu 3000?. Se observ c aceast interogare poate fi rezolvat la nivelul unei singure relaii, relaia ANGAJATI. Expresia de algebr relaional care exprim interogarea dat este: Q1 = Nume,Prenume Salariu
3000

(ANGAJATI)

Instruciunea SQL care realizeaz aceast interogare este:

SELECT Nume,Prenume FROM ANGAJATI WHERE Salariu >= 3000;

Rezultatul interogrii este urmtorul:

Nume Ionescu Popescu Vasilescu Prenume Ion Petre Ana

Exemplul 3.2. Fie relaia ANGAJATI definit n figura 3.1 i interogarea: Care sunt numele, prenumele i salariul angajailor care lucreaz n secia cu numrul 1? Analiznd aceast interogare se constat c toate atributele de proiectie (nume, prenume, data nasterii i salariul unui angajat) i atributul din condiia de interogare (numrul sectiei) sunt atribute ale relaiei ANGAJATI, deci interogarea poate fi rezolvat la nivelul acestei relaii. Expresia de algebr relaional care exprim interogarea dat este: Q2 = Nume,Prenume,Salariu IdSectie
= 1(ANGAJATI)

Comanda SQL care realizeaz aceast interogare este:

SELECT Nume,Prenume,Salariu FROM ANGAJATI WHERE IdSectie = 1;

Rezultatul interogrii este:

Nume Ionescu Popescu Prenume Ion Petre Salariu 4000 3500

Interogri n dou sau mai multe relaii. n situaia n care atributele de proiecie i atributele din condiia de interogare nu aparin unei singure relaii, pentru rezolvarea interogrii trebuie s fie folosite toate acele relaiile care, mpreun, conin aceste atribute. Conceptual, o astfel de interogare se rezolv construind mai nti o relaie care s conin toate atributele necesare prin combinarea a dou sau mai multe relaii folosind operaii de produs cartezian sau jonciuni, iar rezultatul interogrii se obine prin restricia (cu condiia de interogare) i proiecia (pe atributele de proiecie) a acestei relaii. Cazul cel mai frecvent de interogare necesit jonciunea natural a dou sau mai multe relaii asociate, folosind perechea de atribute cheia strin - cheia primar referit pentru fiecare operaie de jonciune: Q = lista_atribute conditie(R >< S >< T...) Exemplul 3.3. Fie relaiile ANGAJATI, SECTII definite n figura 3.1 i interogarea Care sunt numele, prenumele i salariul angajailor care lucreaz n secia cu numele Producie ?. Atributele de proiecie (Nume,Prenume,Salariu) sunt atribute ale relaiei ANGAJATI; atributul Nume al unei secii (care apare n condiia de interogare) nu se afl n aceeai relaie, ci n relaia SECTII de aceea, pentru a rezolva aceast interogare, este necesar combinarea celor dou relaii (fig. 3.6). ANGAJATI
IdAngajat Nume Prenume DataNasterii Adresa Salariu IdSectie

SECTII
Buget Nume IdSectie

Fig. 3.6. Exprimarea unei interogari pe dou relaii. Combinarea celor dou relaii se efectueaz prin jonciunea natural (pe atributul comun IdSectie) a celor dou relaii. Relaia rezultat al jonciunii conine toate informaiile necesare interogrii: numele, prenumele i salariul angajailor i numele seciei corespunztor numrului seciei (IdSectie) n care lucreaz fiecare angajat. Dup aceasta se face restricia (cu condiia SECTII.Nume= Productie), urmat de proiecia pe atributele de proiecie. Expresia final de algebr relaional care exprim interogarea dat este: Q3 = ANGAJATI.Nume,Prenume,Salariu SECTII.Nume='Productie'(ANGAJATI >< SECTII) Comanda SQL care realizeaz aceast interogare este:
SELECT ANGAJATI.Nume,Prenume,Salariu FROM ANGAJATI,SECTII WHERE SECTII.IdSectie = ANGAJATI.IdSectie AND SECTII.Nume = Productie;

Aa cum s-a mai precizat, n limbajul SQL trebuie s fie introdus explicit condiia de jonciune natural (SECTII.IdSectie = ANGAJATI.IdSectie), mpreun cu celelalte condiii de interogare (SECTII.Nume =Productie). Rezultatul acestei interogri asupra relaiilor cu starea din figura 3.1 este:

10

Nume Ionescu Popescu

Prenume Ion Petre

Salariu 4000 3500

Exemplul 3.4. Fie relaiile FURNIZORI, ACHIZIII, COMPONENTE (fig. 3.7), uor modificate fa de cele prezentate n capitolul precedent. FURNIZORI
IdFurnizor 1 2 3 Nume Marculescu Mircescu Amzulescu Prenume Mihai Vasile Ion Adresa Bucuresti Bucuresti Craiova

ACHIZITII
IdComponenta 1 1 2 3 IdFurnizor 1 2 2 3 Cantitate 100 200 300 300 PretUnitar 110 100 200 150

COMPONENTE
IdComponenta 1 2 3 Denumire Rezistenta Condensator Ferita Culoare Rosu Alb Negru Greutate 1 2 4

Fig. 3.7. Relaiile FURNIZORI, ACHIZITII,COMPONENTE.

Interogarea "Care sunt numele i prenumele furnizorilor care au livrat componente n cantiti mai mari sau egale cu 200 ?" necesit jonciunea relaiilor FURNIZORI i ACHIZITII care, mpreun, conin atributele ce intervin n interogare. Expresia de algebr relaional care realizeaz aceast interogare este: Q4 = Nume,Prenume Cantitate 200 (FURNIZORI >< ACHIZITII) n SQL, aceast interogare se exprim astfel:
SELECT Nume,Prenume FROM FURNIZORI,ACHIZITII WHERE FURNIZORI.IdFurnizor = ACHIZITII.IdFurnizor AND Cantitate >= 200;

Rezultatul interogrii este:

Nume Mircescu Amzulescu Prenume Vasile Ion

Exemplul 3.5. Pentru aceleai relaii din figura 3.7, se consider interogarea: "Care sunt numele, prenumele i adresa furnizorilor care au livrat componenta cu denumirea Rezistenta? ". Atributele de proiecie (Nume, Prenume, Adresa) aparin relaiei FURNIZORI, iar atributul Denumire aparine relaiei COMPONENTE. Asocierea dintre aceste relaii este realizat prin relaia ACHIZITII, astfel nct aceast interogare necesit jonciunea tuturor celor trei relaii. (fig. 3. 8). FURNIZORI
IdFurnizor Nume Nume Prenume Prenume Adresa Adresa

ACHIZITII
IdComponenta IdFurnizor Cantitate PretUnitar

COMPONENTE
IdComponenta Denumire Denumire Culoare Greutate

Fig. 3.8. Interogare pe mai multe relaii asociate.

11

Pentru realizarea interogrii date se vor executa urmtoarele operaii: R1 = ACHIZITII >< COMPONENTE R2 = FURNIZORI >< R1 = FURNIZORI>< (ACHIZITII >< COMPONENTE) R3 = Denumire ='Rezistenta' (R2) Q5 = Nume,Prenume,Adresa (R3)= Nume,Prenume,Adresa Denumire ='Rezistenta' (FURNIZORI >< (ACHIZITII >< COMPONENTE)) n limbajul SQL, interogarea de mai sus se exprim prin instruciunea:
SELECT Nume, Prenume, Adresa FROM FURNIZORI,ACHIZITII,COMPONENTE WHERE FURNIZORI.IdFurnizor = ACHIZITII.IdFurnizor AND COMPONENTE.IdComponenta = ACHIZITII.IdComponenta AND Denumire = Rezistenta;

Rezultatul acestei interogri pentru starea relaiilor din figura 3.7 este:
Nume Marculescu Mircescu Prenume Mihai Vasile Adresa Bucuresti Bucuresti

Se observ c n comanda SQL nu se evideniaz care sunt operaiile de jonciune i ordinea lor de execuie, iar condiiile de restricie i jonciune sunt cuprinse ntr-o singur expresie (n clauza WHERE). Sistemul SGBD este acela care determin modul optim de realizare a operaiilor coninute n blocul de interogare.

12

4. DEZVOLTAREA SISTEMELOR DE BAZE DE DATE

n acest capitol se vor prezenta etapele de dezvoltare a bazelor de date i a aplicaiilor de baze de date, activiti care se desfoar n strns corelare. Pentru baze de date de dimensiuni mici, care sunt folosite de un singur utilizator sau de un numr redus de utilizatori, proiectarea este destul de simpl. ns, pentru baze de date de dimensiuni medii sau mari, care fac parte din sistemul informatic al unei organizaii extinse, proiectarea este mult mai complicat. Astfel de baze de date, care trebuie s satisfac cerinele a numeroase aplicaii i utilizatori trebuie s fie proiectate cu mult grij i testate ct mai riguros. Sistemul informatic (information system) include toate resursele unei organizaii care sunt implicate n colectarea, administrarea, utilizarea i diseminarea informaiilor. Sistemele informatice ale anilor 1960 erau dominate de sisteme de fiiere (pe disc sau band magnetic). Dup anul 1970, numeroase organizaii au trecut treptat la sisteme informatice care folosesc sisteme de baze de date, deoarece acestea permit gestionarea unor volume de date mai mari ntr-un timp mai redus, cu multiple posibiliti de securitate i protecie a datelor.

4.1

PROIECTAREA BAZELOR DE DATE

Dezvoltarea sistemelor de baze de date comport mai multe etape, care pot fi prezentate succint astfel: 1. Analiza i definirea sistemului: definirea scopului sistemului de baze de date, a utilizatorilor i a aplicaiilor acestuia. 2. Proiectarea sistemului: n aceast etap se realizeaz proiectul logic i proiectul fizic al sistemului, pentru un anumit SGBD ales. 3. Implementarea: este etapa n care se scriu definiiile obiectelor bazei de date (tabele, vederi, etc.) i se implementeaz aplicaiile software. 4. Testarea i validarea: noul sistem de baze de date este testat i validat ct mai riguros posibil.
n general, se consider c etapa de proiectare a unei baze de date se pot diviza, la rndul ei, n mai multe faze :

1. 2. 3. 4.

Proiectarea conceptual a bazei de date. Alegerea unui SGBD. Proiectarea logic a bazei de date. Proiectarea fizic a bazei de date.

n mod tipic, dezvoltarea unei baze de date const din desfurarea a dou categorii de activiti paralele, aa cum se poate vedea n figura de mai jos. Faza 1: Colectarea i analiza cerinelor Faza 2: Proiectare conceptual
Cerinele de date

Cerinele de prelucrare Proiectarea tranzaciilor (independente de SGBD)

Proiectarea schemei conceptuale i a schemelor externe (independente de SGBD)

Faza 3: Alegerea unui SGBD Faza 4: Proiectare logic Proiectarea schemei conceptuale i a schemelor externe (dependente de SGBD) Proiectarea schemei interne (dependent de SGBD) Instruciuni de descriere a datelor (LDD) (dependente de SGBD) Implementarea tranzaciilor (dependente de SGBD)

Faza 5: Proiectare fizic

Faza 6: Implementare

Prima categorie de activiti se refer la proiectarea structurii i a coninutului bazei de date, iar cea dea doua categorie se refer la proiectarea modului de prelucrare a datelor. Aceste dou categorii de activiti sunt strns corelate: toate prelucrrile care se efectueaz n tranzacii depind de structura datelor memorate, iar proiectarea fizic a bazei de date depinde de prelucrrile necesare n tranzacii. Cele ase faze de proiectare i implementare enumerate mai sus nu se desfoar strict ntr-o singur secven. n multe cazuri este necesar modificarea proiectului dintr-o faz iniial ntr-una din fazele ulterioare, pentru a se obine rezultatele dorite. Aceste bucle de reacie ntre faze (sau n interiorul unei faze) sunt, n general frecvente n cursul proiectrii unei baze de date, dar nu au mai fost reprezentate n figura 7.1, pentru a nu complica diagrama respectiv.

4.1.1

COLECTAREA I ANALIZA CERINELOR

nainte de a se proiecta efectiv o baz de date, este necesar s se cunoasc ce rezultate se ateapt utilizatorii poteniali s obin de la baza de date respectiv i ce informaii primare sunt disponibile pentru aceasta. De asemenea, este necesar s se cunoasc ce aplicaii se vor efectua (aplicaii de gestiune a stocurilor, aplicaii contabile, aplicaii de urmrire a consumurilor, aplicaii de salarizare, etc.). Toate aceste activiti ofer informaii slab structurate, n general n limbaj natural, pe baza crora se pot construi diagrame, tabele, grafice, etc., manual sau folosind diferite instrumente software de proiectare. Aceast faz este puternic consumatoare de timp, dar este crucial pentru succesul sistemului informatic.

4.1.2

PROIECTAREA CONCEPTUAL A BAZELOR DE DATE

Faza de proiectare conceptual a bazelor de date implic dou activiti paralele: proiectarea schemei conceptuale i a schemelor externe ale bazei de date i proiectarea tranzaciilor.

4.1.2.1

Proiectarea schemei conceptuale de nivel nalt

Dei nu este obligatoriu, aceast faz se poate menine independent de SGBD i produce un model de date de nivel nalt, care va fi implementat dup transpunerea lui ntr-un model de date specific. Chiar dac proiectanii pot porni direct cu scheme conceptuale specifice unui anumit SGBD (care se mai numesc i scheme logice), este totui recomandabil s se realizeze mai nti schema conceptual de nivel nalt independent de SGBD, deoarece o astfel de schema conceptual este o descriere stabil i inavuabil a bazei de date, iar alegerea unui SGBD i deciziile ulterioare de proiectare se pot schimba fr ca aceasta s se schimbe. Pentru proiectarea schemei conceptuale se identific elementele eseniale ale acesteia: tipurile de entiti i atributele lor precum i asocierile dintre aceste tipuri. Se pot defini, dac este necesar, subtipuri, prin specializri ale tipurilor de baz, sau supertipuri, prin generalizri ale tipurilor deja definite. Acest proiect conceptual de nivel nalt este realizat pe baza cerinelor definite n prima etap de proiectare i se reprezint, n general printr-o diagram Entitate-Asociere (extins). Exist mai multe aspecte privind modul de abordare a proiectrii conceptuale. Un prim aspect se refer la modul de proiectare a schemei conceptuale a bazei de date: proiectare prin integrarea cerinelor i proiectare prin integrarea schemelor externe. n proiectarea prin integrarea cerinelor (care se mai numete i proiectare centralizat) se realizeaz mai nti integrarea (combinarea) tuturor cerinelor de proiectare ntr-un singur set de cerine, pe baza cruia se proiecteaz schema conceptual a bazei de date. Din aceast schema conceptual (unic) proiectat se deduc schemele externe (vederile) corespunztoare diferitelor grupuri de utilizatori i aplicaii. n proiectarea prin integrarea vederilor (schemelor) externe se proiecteaz cte o schem corespunztoare fiecrui grup de utilizatori i aplicaii, pe baza cerinelor acestora, dup care se combin aceste scheme ntr-o singur schem conceptual global, pentru ntreaga baz de date. Fiind dat un set de cerine, pentru un singur utilizator sau pentru mai muli utilizatori ai bazei de date, proiectarea schemei conceptuale care s satisfac aceste cerine se poate aborda ntr-o varietate de strategii, dintre care cele mai relevante sunt proiectarea ascendent (bottom-up) i proiectarea descendent (top-down). n proiectare ascendent a bazelor de date se pornete de la o schem conceptual universal care conine toate atributele, care sunt apoi grupate pentru a forma tipuri de entiti i asocierile dintre acestea. Proiectul poate fi rafinat prin grupri ulterioare i creare de supertipuri i subtipuri ale tipurilor existente. n proiectarea descendent a bazelor de date se pornete de la o schem conceptual dezvoltat n modelul Entitate-Asociere (extins) n care sunt cuprinse aspectele de baz (tipuri de entiti i asocieri ale acestora). Dezvoltarea i rafinarea acestui model se face prin adugarea de noi atribute i constrngeri, crearea unor subtipuri (prin specializare) i asocierea acestora cu tipurile de baz. Aadar, n aceast faz de proiectare se obine schema conceptual de nivel nalt a bazei de date, care este independent de orice model de date specific (ierarhic, reea, relaional, etc.), i de orice sistem de gestiune care poate fi folosit pentru realizarea bazei de date.

EXEMPLU DE PROIECTARE A SCHEMEI CONCEPTUALE DE NIVEL NALT A UNEI BAZE DE DATE

Entiti. Tipurile de entiti puternice (normale) care se pot defini pentru modelarea activittii unei ntreprinderi sunt cele descrise anterior (SECTII, ANGAJATI, PROIECTE), la care se mai pot adauga alte cteva tipuri, ca de exemplu: PRODUSE,COMPONENTE,FURNIZORI,CLIENTI, cu semnificaie evident.:
SECTII(Nume,Buget) ANGAJATI(Nume,Prenume,DataNasterii,Adresa,Functie,Salariu) PROIECTE(Denumire,Termen,Buget) PRODUSE(Denumire,Descriere) COMPONENTE(Denumire,Descriere) FURNIZORI(Nume,Prenume,Adresa) CLIENTI(Nume,Prenume,Adresa)

La aceste mulimi de entiti se adaug mulimea de entiti slabe:

DEPENDENTI(Nume,Prenume,DataNasterii,GradRudenie)

Pentru tipul ANGAJATI se definete o specializare disjunct parial, cu subtipurile INGINERI i SECRETARE. Aceste subtipuri se afl n asociere 1:1 cu tipul de baz ANGAJATI, motenesc atributele acestuia i fiecare mai conine atribute specifice:
INGINERI(Specialitatea) SECRETARE(VitezaRedactare)

Asocieri. Asocierile dintre mulimile de entiti se stabilesc n funcie de modul n care se desfoar activitatea modelat. De exemplu, dac n ntreprinderea respectiv activitatea este organizat pe secii i fiecare angajat lucreaz ntr-una (i numai una) dintre secii, atunci ntre mulimile de entiti SECTII-ANGAJATI exist o asociere 1:N. Asocierea ANGAJATI-PROIECTE este o asociere M:N dac se consider c la un proiect lucreaz mai muli angajai i fiecare angajat poate lucra la mai multe proiecte. Un produs este compus din mai multe componente i fiecare component poate fi inclus n mai multe produse, deci asocierea COMPONENTE-PRODUSE este este M:N. O component poate fi achiziionat de la mai muli furniori, iar un furnizor poate oferi mai multe componente, deci asocierea FURNIZORI-COMPONENTE este M:N. Pentru aceast asociere se stabilete c trebuie s conin i o referin la angajatul care se ocup de acea achiziie i atunci se poate considera c mulimile de entiti FURNIZORI-COMPONENTE-ANGAJATI se afl toate ntr-o asociere ternar, M:N:P. La fel, mulimile de entiti PRODUSE-CLIENTI-ANGAJATI se afl toate ntr-o asociere M:N:P. SECTII
1 ACTIVITATI N ANGAJATI N 1 N DEPENDENTI INGINERI SECRETARE FURNIZORI PROIECTE M N ACHIZITII COMPONENTE COMPOZITII M P VANZARI M M N

PRODUSE

N CLIENTI

Diagrama E-A a bazei de date a unei ntreprinderi. O mulime de entiti slabe se afl, de regul, n asociere N:1 cu mulimea de entiti puternice de care depinde. In exemplul dat, ntre mulimea DEPENDENTI i mulimea de entiti ANGAJATI exist o asociere N:1. O mulime de entiti de un subtip dat este, de regul, n asociere 1:1 cu mulimea de entiti de supertipul acesteia. Pentru exemplul de mai sus, un angajat poate fi un (singur) inginer; iar un inginer este chiar un angajat, deci asocierea ntre mulimile de entiti ANGAJATI i INGINERI exist o asociere cu raportul de cardinalitate 1:1. La fel, ntre mulimile de entiti ANGAJATI i SECRETARE exist o asociere 1:1.

Schema conceptual a unei baze de date relaionale poate fi dezvoltat independent de un anumit SGBD, urmnd ca ulterior s se adauge diferite trsturi specifice SGBD-ului folosit. De obicei ns, fiecare SGBD pune la dispoziie un numr de instrumente mai mult sau mai puin prietenoase de proiectare a relaiilor i a asocierilor, astfel nct n mod frecvent, proiectul conceptual se dezvolt de la nceput n cadrul sistemului SGBD n care se va realiza baza de date. De exemplu, Microsoft Access ofer o interfa vizual de proiectare a relaiilor i a asocierilor deosebit de uor de utilizat. La fel, sistemele SQL Server sau Oracle9i ofer instrumente grafice pentru proiectarea vizual a relaiilor.

4.1.2.2

Proiectarea tranzaciilor

Atunci cnd se proiecteaz o baz de date, se cunosc n mare parte i ce tipuri de aplicaii se vor executa. Un aspect important n proiectarea bazelor de date este specificarea caracteristicilor funcionale ale acestor aplicaii ct mai devreme n cursul procesului de proiectare, astfel nct schema bazei de date s includ toate informaiile necesare cu privire la aceste aplicaii. n plus, cunoaterea importanei relative a diferitelor tranzacii executate de aplicaiile bazei de date, precum i a frecvenei de invocare a acestora, permite luarea unor decizii n etapa de proiectare fizic a bazei de date. Dup implementarea sistemului de baze de date vor mai fi identificate i implementate noi tranzacii. Totui, cele mai importante tranzacii sunt cel mai adesea cunoscute nainte de implementarea sistemului.

4.1.3

ALEGEREA UNUI SGBD

Alegerea unui SGBD pentru implementarea unei baze de date se face innd seama de mai muli factori: tehnici, economici i administrativi. Factorii tehnici trebuie s asigure alegerea unui SGBD adecvat sarcinii de realizare a sistemului informatic al ntreprinderii. Se iau n consideraie: Modelul de date (ierarhic, reea, relaional, obiect-orientat, obiect-relaional) care se potrivete cel mai bine cu structura informaiilor stocate i prelucrate. Capacitatea de stocare a datelor. Posibilitile de control al concurenei i de refacere a datelor. Limbajele i interfeele de programare disponibile. De asemenea, nainte de achiziionarea unui anumit SGBD trebuie s se cunoasc configuraia hardware-software necesar, precum i alte cerine de dezvoltare a programelor de aplicaii (compilatoare, drivere, etc.). Factorii economici i administrativi care trebuie s fie analizai la alegerea unui SGBD sunt: Costul de achiziie a software-ului, care include costul de baz, la care se adaug diferite opiuni (opiuni de salvare-refacere, documentaie, limbaje i interfee de programare, drivere, etc.). Costul de ntreinere, pentru a obine serviciul furnizorului de meninere la zi a versiunii SGBD. Costul de pregtire a personalului se refer la cursurile care se organizeaz pentru persoanele care se ocup cu ntreinerea i operarea sistemului. Cunotinele de programare a personalului ntr-un anumit SGBD; dac majoritatea personalului din organizaia respectiv este foarte bun cunosctor al unui anumit SGBD, atunci acesta poate fi favorizat, deoarece se pot reduce astfel costurile de pregtire. Beneficiile achiziionrii unui anumit SGBD nu sunt uor de apreciat sau de msurat, dar analiza raportului cost-performane poate da o imagine a rezultatelor obinute.

4.1.4

PROIECTAREA LOGIC A BAZELOR DE DATE

n faza de proiectare logic a unei baze de date se realizeaz schema conceptual global i schemele conceptuale (vederile) externe pentru sistemul SGBD ales, pornind de la schema conceptual i schemele externe de nivel nalt independente de SGBD, proiectate n faza precedent. Aceast faz de proiectare logic poate fi realizat n dou subfaze: Transpunerea schemei conceptuale n modelul de date al sistemului SGBD ales, dar independent de sistemul de gestiune propriu-zis. n cazul modelului relaional, transpunerea se face prin corespondena dintre elementele schemei conceptuale de nivel nalt reprezentat prin diagrama Entitate-Asociere (tipuri de entiti, atribute, asocieri) i elementele modelului relaional (relaii, atribute, referine). Se obine un proiect logic dependent de modelul de date, dar independent de sistem. n aceast subfaz se face i analiza normalizrii relaiilor, normalizarea fiecrei relaii pn la nivelul adecvat i documentarea tuturor dependenelor de date care nu sunt determinate de chei ale relaiilor (necesar pentru proiectarea procedurilor de verificare i impunere a dependenelor respective).

Rafinarea schemei conceptuale i a schemelor externe obinute anterior, astfel nct s se utilizeze unele (sau ct mai multe) din facilitile oferite de sistemul SGBD ales (modul de generare a cheilor primare, definirea constrngerilor, etc.).

Rezultatul acestei faze de proiectare l constituie, aadar, schema conceptual i schemele externe ale bazei de date, dependente de sistemul SGBD ales i de modelul de date al acestuia. Pentru transpunerea modelului Entitate-Asociere (reprezentat prin diagrama E-A) n model relaional se parcurg n principal dou etape, rezultatul fiind schema conceptual a bazei de date relaionale: Proiectarea relaiilor corespunztoare mulimilor de entiti din diagrama E-A. Proiectarea asocierilor; asocierile se pot reprezenta prin chei strine sau prin relaii de asociere; acestea sunt relaii suplimentare care se adaug n schema conceptual a bazei de date relaionale pentru a reprezenta, n general, asocierile M:N; uneori se folosesc relaii de asociere i pentru reprezentarea asocierilor 1:1 sau a asocierilor 1:N.

4.1.4.1

Proiectarea relaiilor

n figura 2.4 este dat schema conceptual a bazei de date relaionale corespunztoare diagramei E-A din figura 2.3, dezvoltat n MS Access. n MS Access relaiile i asocierile ntre ele sunt reprezentate vizual n diagrama de asocieri (Relationships), care este corespondentul relaional al diagramei E-A. Mulimile de entiti puternice (normale) din diagrama E-A devin relaii, cu atributele date de atributele entitilor. Numele fiecrei relaii trebuie s fie unic ntr-o baz de date. Numele unui atribut trebuie s fie unic n cadrul unei relaii, dar pot exista atribute cu acelai nume n relaii diferite, care sunt complet diferite n cadrul bazei de date, posibil diferite i din punct de vedere semantic. De exemplu atributul Nume al unui angajat este diferit de atributul Nume al unei secii. n relaiile corespunztoare mulimilor de entiti puternice cheia primar se definete fie ca o cheie natural (combinaie de atribute care definesc n mod unic un tuplu al relaiei), fie ca o cheie primar artificial. n exemplul prezentat, n relaiile care corespund mulimilor de entiti puternice (ANGAJATI,SECTII, PROIECTE,COMPONENTE,PRODUSE,FURNIZORI,CLIENTI), s-a adugat cte o cheie primar artificial (IdAngajat,IdSectie,IdProiect,etc.). Mulimile de entiti slabe din diagrama E-A devin, de regul, relaii aflate n asociere N:1 cu relaia corespunztoare mulimii de entiti de care acestea depind. Pentru realizarea acestei asocieri, n relaia dependent se adaug o cheie strin care refer cheia primar a relaiei referite (puternice). Cheia primar a relaiei dependente poate fi o combinaie format din atributul cheie strin i alte atribute care asigur posibilitatea de identificare unic a unui tuplu sau poate fi o cheie artificial. Cheia primar a relaiei DEPENDENTI este compus din atributul cheie strin IdAngajat, care refer cheia primar a relaiei ANGAJATI i atributele Nume i Prenume (ale persoanei dependente):
DEPENDENTI(IdAngajat,Nume,Prenume,DataNasterii,GradRudenie)

O alt modalitate de modelare a mulimilor de entiti slabe este aceea de a defini o relaie separat care conine atributele mulimii entitilor slabe i nc o relaie, pentru asocierea acesteia cu relaia corespunztoare mulimii entitilor puternice de care acestea depind. Pentru exemplul dat, se poate defini o relaie care descrie mulimea persoanelor dependente DEPENDENTI(IdDependent,Nume,Prenume,Data-Nasterii), iar asocierea cu relaia ANGAJATI se poate reprezenta printr-o relaie special, numit relaie de asociere (aa cum se va explica ntr-un paragraf urmtor): AD(IdDependent,IdAngajat,GradRudenie). Relaia AD conine atributele IdAngajat i IdDependent, care sunt i chei strine ce refer cheile primare cu acelai nume din relaiile ANGAJATI, respectiv DEPENDENTI i formeaz mpreun cheia primar. Mulimile de entiti care sunt subtipuri ale unui tip de entitate dat devin relaii aflate n asociere 1:1 cu relaia corespunztoare mulimii de entiti de tipul respectiv (supertip). Pentru realizarea acestei asocieri n relaia corespunztoare subtipului de entitate se definete o cheie strin care refer cheia primar din relaia corespunztoare supertipului de entitate; aceast cheie strin este n acelai timp i cheie primar n relaia corespunztoare subtipului de entitate.

Diagrama logica a bazei de date INTREPRINDERE n MS Access. n exemplul prezentat, asocierile ANGAJATI-INGINERI i ANGAJATI-SECRETARE sunt asocieri 1:1. n relaia INGINERI atributul IdAngajat este cheie strin care refer cheia primar cu acelai nume din relaia ANGAJATI i este n acelai timp i cheie primar; la fel, n relaia SECRETARE atributul IdAngajat este cheie strin care refer cheia primar cu acelai nume din relaia ANGAJATI i este n acelai timp i cheie primar.

4.1.4.2

Proiectarea asocierilor

Asocierea binar N:1 dintre dou mulimi de entiti puternice din diagrama E-A se realizeaz n modelul relaional prin intermediul unei chei strine n prima relaie (cea cu multiplicitatea N a asocierii) care refer cheia primar (sau o cheie candidat) din relaia referit (cea cu multiplicitatea 1 a asocierii). De exemplu, asocierea N:1 ntre relaiile ANGAJATI-SECTII se realizeaz prin cheia strin IdSecie adugat relaiei ANGAJATI, care refer cheia primar cu acelai nume a relaiei SECTII. Astfel de atribute (pentru definirea cheilor strine) nu exist n modelul E-A i ele trebuie s fie adugate n modelul relaional pentru definirea asocierii N:1, aa cum n modelul ierarhic pentru o astfel de asociere se adaug link-uri (pointeri) ntre noduri. Asocierea binar N:1 poate apare i ca asociere ntre o relaie corespunztoare unei mulimi de entiti slabe i relaia corespunztoare mulimii de entiti puternice de care aceasta depinde, aa cum a fost prezentat mai sus. Asocierea binar M:N dintre dou mulimi de entiti din diagrama E-A se realizeaz n modelul relaional prin intermediul unei noi relaii, numit relaie de asociere. Aceast nou relaie se afl n asociere M:1, respectiv N:1 cu fiecare din cele dou relaii date prin intermediul a dou chei strine care refer cheile primare (sau cheile candidate) din relaiile date. De exemplu, pentru a reprezenta asocierea M:N dintre relaiile COMPONENTE-PRODUSE se adaug o nou relaie numit COMPOZITII, care conine cheile strine IdComponenta i IdProdus, ce refer cheile primare cu acelai nume din relaiile COMPONENTE, respectiv PRODUSE. O relaie de asociere poate s conin i alte atribute n afara cheilor strine, atribute care caracterizeaz asocierea dintre relaiile date. De exemplu, n relaia COMPOZITII atributul NrComponente, care reprezint numrul de componente de un anumit tip coninute de un produs, caracterizeaz asocierea respectiv. Cheia primar a unei relaii de asociere binar poate fi o cheie artificial sau poate fi compus din cheile strine, eventual mpreun cu alte atribute ale relaiei. n exemplul dat, cheia primar a relaiei COMPOZITII este compus din cheile strine IdComponenta i IdProdus.

Asocierea M:N dintre relaiile ANGAJATI-PROIECTE se realizeaz prin introducerea relaiei de asociere ACTIVITATI, care conine dou chei strine, IdAngajat i IdProiect, care refer cheile primare cu acelai nume din relaiile corespunztoare. Cheia primar a relaiei ACTIVITATI este compus din cheile strine IdAngajat i IdProiect. Asocierea binar 1:1 ntre dou mulimi de entiti puternice se poate transpune n modelul relaional n dou moduri: fie prin intermediul unei chei strine (ca un caz particular al unei asocieri N:1), fie printr-o relaie de asociere (ca un caz particular al unei asocieri M:N). Ca exemplu, vom considera relaiile SOT, SOTIE, corespunztoare a dou mulimi de entiti puternice aflate n asociere 1:1:
SOT(IdSot,Nume,Prenume,DataNasterii,Adresa) SOTIE(IdSotie,Nume,Prenume,DataNasterii,Adresa)

Asocierea 1:1 ntre aceste relaii se poate realiza prin intermediul unei chei strine care se introduce n prima relaie, referind a doua relaie:
SOT(IdSot,Nume,Prenume,DataNasterii,Adresa,IdSotie) SOTIE(IdSotie,Nume,Prenume,DataNasterii,Adresa)

La fel de bine se poate defini o cheie strin n cea de-a doua relaie, referind prima relaie. O abordare alternativ pentru realizarea asocierii 1:1 ntre dou relaii corespunztoare unor mulimi de entiti puternice este aceea de a crea o nou relaie (relaie de asociere) n care se definesc dou chei strine care refer cheile primare din relaiile pe care le asociaz. Pentru exemplul de mai sus se va defini relaia de asociere CASATORIE care conine cheile strine IdSot i IdSotie, ce refer relaiile SOT, respectiv SOTIE. Cheia primar a acestei relaii poate fi combinaia celor dou chei strine sau se poate introduce un nou atribut de identificare (IdCasatorie):
CASATORII(IdCasatorie,IdSot,IdSotie,DataCasatoriei)

Asocierea binar 1:1 dintre o mulime de entiti de subtip i mulimea de entiti supertip din diagrama Entitate-Asociere este tot o asociere binar cu raportul de cardinalitate1:1 ntre relaiile corespunztoare n modelul relaional. Aa cum a fost prezentat mai sus, acest tip de asociere se realizeaz prin definirea n relaia corespunztoare subtipului de entiti a unei chei strine care refer cheia primar din relaia corespunztoare supertipului de entiti; aceast cheie strin este n acelai timp i cheie primar n relaia corespunztoare subtipului de entiti. Asocierea multipl M:N:P:. dintre mai mult de dou mulimi de entiti din diagrama E-A se realizeaz n mod asemntor cu asocierea binar, prin intermediul unei noi relaii care se afl n asociere M:1, N:1, P:1, etc, cu fiecare din relaiile date. Aceast asociere este realizat prin intermediul mai multor chei strine, fiecare cheie strin referind cheia primar (sau o cheie candidat) dintr-una din relaiile date. Cheia primar a unei relaii de asociere multipl se definete n mod asemntor cu cheia primar a unei relaii de asociere binar i poate fi o cheie artificial sau poate fi compus din toate cheile strine, eventual mpreun cu alte atribute ale relaiei, care caracterizeaz asocierea respectiv. De exemplu, relaia ACHIZITII realizeaz asocierea ntre relaiile COMPONENTE, FURNIZORI, ANGAJATI. Ea conine trei chei strine (IdComponenta, IdFurnizor, IdAchizitor) care refer relaiile COMPONENTE, FURNIZORI, respectiv ANGAJATI. Cheia primar a relaiei de asociere ACHIZITII nu se poate compune numai din cheile strine, deoarece pot exista dou sau mai multe tupluri cu aceleai valori ale cheilor strine: un achizitor (IdAchizitor) poate cumpra acelai tip de component (IdComponenta) de la acelai furnizor (IdFurnizor), dar la date diferite. De aceea, cheia primar se definete fie ca o combinaie a cheilor strine cu alte atribute ale relaiei, fie ca o cheie artificial (cheia artificial IdAchizitie). Aa cum se poate vedea n figura 2.8, schema conceptual a bazei de date relaionale rezultate conine att relaiile corespunztoare mulimilor de entiti din modelul E-A, ct i relaiile de asociere introduse pentru a reprezenta asocierile binare M:N sau asocierile multiple M:N:P. Se poate concluziona c, dei exist unele detalii de definire a diferitelor categorii de asocieri, n modelul relaional toate asocierile se realizeaz prin intermediul cheilor strine.

4.1.4.3

Proiectarea relaiilor normalizate n prima form normal

O relaie este normalizat n prima form normal (FN1) dac fiecare atribut ia numai valori atomice i scalare din domeniul su de definiie. O situaie frecvent ntlnit n proiectarea bazelor de date este aceea n care un atribut al unui tip de entitate poate lua mai multe valori pentru fiecare entitate.

De exemplu, n mulimea de entiti PERSOANE(Nume,Prenume, Adresa,NrTelefon) atributul NrTelefon poate lua mai multe valori (numrul telefonului de acas, al telefonului de la birou, al telefonului mobil, etc). Relaia corespunztoare unei astfel de mulimi de entiti, n care un atribut poate avea valori multiple (un vector de valori) este o relaie nenormalizat, care nu este admis de sistemele de gestiune a bazelor de date relaionale. Transformarea unei relaii nenormalizate n relaie normalizat n prima forma normal (FN1), n care atributele iau numai valori scalare, se poate face n dou modaliti. n prima modalitate se nlocuiete atributul care ar putea avea valori multiple cu cte un atribut pentru fiecare din posibilitile existente. n cea de-a doua modalitate, se nlocuiete atributul care ar putea avea valori multiple cu o nou relaie care refer relaia iniial printr-o cheie strin. Cheia primar a relaiei nou introduse este format din cheia strin i atributul extras din relaia iniial. De exemplu, n relaia:
PERSOANE(IdPersoana,Nume,Prenume,Adresa,NrTelefon)

atributul NrTelefon poate lua mai multe valori (telefon de acas, telefon la birou, telefon mobil), deci este o relaie nenormalizat. Aceast relaie se poate normaliza prin nlocuirea atributului NrTelefon cu trei atribute, cte unul pentru fiecare valoare posibil:
PERSOANE(IdPersoana,Nume,Prenume,Adresa, TelefonAcasa,TelefonBirou,TelefonMobil)

Relaia rezultat dup aceast modificare este normalizat, dar soluia este neeconomic, dat fiind c este alocat spaiu pentru memorarea numrului maxim de valori posibile (n exemplul dat sunt maxim trei valori) pentru toate tuplurile, dei este posibil ca n multe situaii s nu fie completate dect una sau dou valori, iar n rest s fie valori de NULL. O soluie mai eficient este de a nlocui relaia dat cu relaiile:
PERSOANE(IdPersoana,Nume,Prenume,Adresa) TELEFOANE(IdPersoana,NrTelefon)

aflate n asociere 1:N prin cheia strin IdPersoana din relaia TELEFOANE, care refer cheia primar cu acelai nume din relaia PERSOANE.

4.1.5

PROIECTAREA FIZIC A BAZELOR DE DATE

Proiectarea fizic a bazei de date este procesul de alegere a structurilor de memorare i de acces a fiierelor bazei de date, pentru a obine performane ct mai bune, pentru ct mai multe din aplicaiile proiectate. Fiecare SGBD ofer o varietate de opiuni de organizare a fiierelor i a modului de acces la datele stocate: indexuri, gruparea nregistrrilor corelate n aceleai blocuri pe disc (clustering), tabele de dispersie (hashing), etc. Dup alegerea sistemului SGBD, n faza de proiectare fizic a bazei de date se aleg structurile fiierelor bazei de date dintre cele oferite de sistemul de gestiune respectiv, cele mai potrivite cu cerinele de proiectare a sistemului de baze de date. Ca parametri generali de alegere a opiunilor proiectului fizic al unei baze de date relaionale se pot enumera: Timpul de rspuns. Acesta este intervalul de timp dintre lansarea n execuie a unei tranzacii i primirea rspunsului la acea tranzacie. Cea mai mare pondere n timpul de rspuns o are execuia operaiilor n sistemul SGBD, dar exist i factori care nu se afl sub controlul acestuia (viteza de operare a procesorului, dimensiunea memoriei principale, planificarea sarcinilor de ctre sistemul de operare, timpii de comunicaie, etc.). Utilizarea spaiului de memorare. Aceasta este dimensiunea spaiului pe disc utilizat de fiierele bazei de date i de structurile de acces la date. Capacitatea tranzacional (transaction throughput). Acesta este numrul mediu de tranzacii care pot fi prelucrate pe minut de ctre sistemul de baze de date, msurat n momentele de vrf ale ncrcrii. Acesta este un parametru critic n multe aplicaii, n particular n acele aplicaii n care exist un numr mare de utilizatori care acceseaz concurent baza de date (aplicaii bancare, rezervri de bilete, etc.).

4.1.6

IMPLEMENTAREA BAZELOR DE DATE

n faza de implementare a bazelor de date relaionale se creeaz obiectele principale ale bazei de date (tabele, vederi, indexuri), pe baza proiectului logic i a proiectului fizic, folosind limbajul de descriere a datelor (LDD) oferit de sistemul SGBD ales. De asemenea, n faza de implementare se proiecteaz i se implementeaz i procedurile care asigur verificarea i forarea tuturor constrngerilor explicite (aseriuni, dependene de date care nu sunt determinate de chei ale relaiilor), a cror previziune i documentare a fost realizat n faza de proiectare logic a bazei de date.

Baza de date poate fi apoi populat cu date obinute prin conversia unor date existente sub form de fiiere sau introduse direct n tabele. Este esenial ca n faza de populare a bazei de date s fie verificate i impuse toate constrngerile prevzute, deci s fie implementate i verificate toate triggerele, procedurile stocate sau funciile din programele de aplicaii de verificare a constrngerilor explicite. Tot n aceast faz programatorii de aplicaii implementeaz, pe baza specificaiilor conceptuale ale tranzaciilor, programele de aplicaii, n diferite tehnologii de programare disponibile (limbaje procedurale de extensie a limbajului SQL, limbajul SQL integrat, interfee i biblioteci de programare, etc.). Dup crearea i popularea bazei de date i implementarea programelor de aplicaii se poate trece la etapa de operare a sistemului de baze de date, n paralel cu monitorizarea i ntreinerea acestuia.

4.2

LIMBAJE, INTERFETE SI BIBLIOTECI DE PROGRAMARE A APLICAIILOR DE BAZE DE DATE

Aplicaiile de baze de date sunt, n general, mult mai complexe dect alte categorii de aplicaii, deoarece trebuie s realizeze, pe de o parte interfaa cu sistemele de gestiune a bazelor de date, pentru introducerea i extragerea datelor, iar pe de alt parte, interfaa cu utilizatorii, astfel nct acetia s poat efectua diferite operaii. Pe lng aceste funcii de interfaare, programele de aplicaii de baze de date trebuie s implementeze i algoritmii de calcul necesari. Interfeele cu utilizatorii sunt, n general, interfee grafice, cunoscute sub numele de formulare (forms). Prin intermediul controalelor (ferestre cu diferite funcionaliti) din cadrul formularelor, utilizatorii sunt ghidai s introduc numai datele strict necesare, de cele mai multe ori prin selectarea lor din mai multe valori prezentate (i valide), astfel nct s se limiteze posibilitatea introducerii unor date eronate. Rezultatele operaiilor cerute de utilizatori sunt afiate, de asemenea n formulare i pot fi tiprite la dorin, sub form de rapoarte. De exemplu, o aplicaie de gestiune a stocurilor ofer o interfa grafic utilizatorilor, prin intermediul creia acetia pot s introduc n baza de date diferite informaii (cantiti de marfuri intrate sau ieite, etc.); programul calculeaz diferii indicatori de gestiune (nivelul stocurilor, dinamica stocurilor, etc.) i afieaz sau tiprete rezultatele calculate. Interfeele grafice cu utilizatorii se pot realiza prin tehnologii software de uz general, dar multe sisteme de dezvoltare a bazelor de date ofer suport pentru dezvoltarea acestora. De exemplu, Microsoft Access permite dezvoltarea vizual a aplicaiilor, inclusiv formularele de interfa; sistemul de dezvoltare Oracle conine utilitarul Oracle Forms care permite crearea interfeelor grafice cu utilizatorii, etc. Sistemele de gestiune a bazelor de date relaionale prelucreaz instruciuni (comenzi) SQL. Limbajul SQL (n oricare din standardele definite pn n prezent) este un limbaj neprocedural, care permite definirea datelor i operaii de manipulare a acestora, dar nu prevede instruciuni de control al ordinii de execuie a operaiilor. De aceea, pentru realizarea aplicaiilor de baze de date au fost dezvoltate o multitudine de limbaje i biblioteci de programare: limbaje procedurale de extensie a limbajului SQL, limbajul SQL integrat, biblioteci de funcii sau de clase pentru comunicarea cu bazele de date. Un limbaj procedural (procedural language) este o extensie a limbajului SQL i permite combinarea instruciunilor SQL cu instruciuni de control al ordinii de execuie. Astfel de limbaje sunt folosite n principal n cadrul sistemelor de gestiune, pentru stocarea unor proceduri de calcul, dar exist i posibilitatea ca programele de aplicaii s transmit sistemului SGBD blocuri (loturi) de instruciuni ntr-un limbaj procedural. Transmiterea unui bloc de instruciuni n locul transmiterii individuale a fiecrei instruciuni SQL, asigur performane de execuie a aplicaiilor mai ridicate, datorit reducerii traficului n reea. Majoritatea sistemelor de gestiune sunt prevzute cu cel puin un limbaj procedural, cele mai cunoscute fiind: PL/SQL pentru sistemele de gestiune Oracle, Transact-SQL pentru sistemele de gestiune Microsoft SQL Server, PL/PGSQL i PL/Pearl pentru sistemul de gestiune PostgreSQL, etc. Pentru dezvoltarea programelor de aplicaii de baze de date se pot aborda dou tehnologii diferite: Limbajul SQL integrat ntr-un limbaj de nivel nalt. Interfee de programare a aplicaiilor.

n limbajul SQL integrat (Embeded SQL), instruciunile limbajului SQL sunt incluse direct n codul programului surs scris ntr-un limbaj gazd de nivel nalt (Ada, PL/1, Pascal, Fortran, Cobol, C). Controlul fluxului de operaii este realizat prin instruciunile limbajului gazd, iar operaiile cu baza de date sunt realizate prin instruciuni SQL. Interfeele de programare a aplicaiilor (Application Programming Interface - API) sunt dezvoltate ca biblioteci de funcii sau de clase, iar programele de aplicaie folosesc apelul funciilor prevzute de interfaa respectiv pentru a comunica cu serverul bazei de date. Interfeele de programare a aplicaiilor permit dezvoltarea aplicaiilor de baze de date prin apeluri de funcii (call-level interface CLI) ntr-o manier flexibil, uor de dezvoltat i de ntreinut. Interfeele separ

programul de aplicaie de biblioteca de acces la baza de date, iar aceast separare ofer modularitate, stabilitate i independen mai ridicat a aplicaiilor. Fiecare dintre aceste limbaje i biblioteci reprezint n sine o topic extins, fiind subiectul multor cri de specialitate, pe lng manualele de referin, manualele de programare, manualele de dezvoltare, etc. Prezentarea lor succint ntr-un singur capitol nu nlocuiete necesitatea consultrii unor astfel de documentaii atunci cnd se programeaz efectiv, ci are ca scop formarea unor cunotine generale despre problematica programrii aplicaiilor de baze de date. n seciunile care urmeaz este abordat descrierea comparat a posibilitilor de programare oferite de diferite limbaje i biblioteci i este urmrit modul n care acestea reflect caracteristicile bazelor de date relaionale.

4.2.1

LIMBAJE PROCEDURALE DE EXTENSIE A LIMBAJULUI SQL

Un limbaj procedural (procedural languages) combin instruciuni SQL cu instruciuni pentru controlul ordinii de execuie, asigurnd extinderea posibilitilor sistemelor de gestiune a bazelor de date. Limbajele procedurale permit definirea unor variabile locale, instructiuni de control al ordinii de execuie (bucle while, instruciuni condiionale if, etc.), precum si suport de creare a cursoarelor, a procedurilor stocate, a funciilor definite de utilizator i a declanatorilor (triggere). Un cursor (cursor) este o structur care permit memorarea (folosind un buffer n memorie) a unei mulimi de linii returnate ca rezultat de o instruciune de interogare. Programele de aplicaii nu pot prelucra deodat toate liniile rezultatului i folosesc cursoare pentru extragerea individual a unei linii (sau a unui grup de linii) din mulimea de linii rezultat. n fiecare moment, ntr-un cursor exist o poziie curent (linie curent) n mulimea de linii rezultat. La fiecare operaie de extragere, se citesc una sau mai multe linii relativ la poziia curent a cursorului, iar aceast poziie se actualizeaz conform modului de parcurgere (nainte sau napoi). Cursoarele permit salvarea, folosirea repetat sau derularea de mai multe ori a liniilor pe care le conin. De asemenea, cursoarele ofer mai multe posibiliti de control al accesului concurent a mai multor utilizatori la tabelele unei baze de date. n standardul SQL2 sunt prevzute instruciunile principale de definire i de operare a cursoarelor: DECLARE CURSOR, OPEN, FETCH i CLOSE. Instruciunea de definire a unui cursor SQL2 are sintaxa:
DECLARE nume_cursor [INSENSITIVE][SCROLL] CURSOR FOR instructiune_select [FOR {READ ONLY|UPDATE [OF col1[,...n]]}];

O astfel de declaraie creeaz cursorul cu numele nume_cursor pentru mulimea de linii rezultat returnat de instruciunea instructiune_select i seteaz atributele de comportare (behavior attributes) ale cursorului: atributul de senzitivitate i atributul de actualizare. Instruciunea OPEN nume_cursor, specificat n standardul SQL2, permite deschiderea unui cursor (care a fost declarat cu numele nume_cursor printr-o instruciune DECLARE CURSOR); deschiderea cursorului nseamn popularea cursorului cu datele din tabelele la care se refer instruciunea SELECT a cursorului. Instruciunea de extragere a liniilor dintr-un cursor are sintaxa:
FETCH [FROM] nume_cursor INTO lista_variabile;

i definete operaia de extragere a unei linii (din poziia curent) din cursorul cu numele cursor_name n variabilele din lista lista_variabile. Instruciunea CLOSE nume_cursor, specificat n standardul SQL2, permite nchiderea unui cursor (care a fost declarat cu numele nume_cursor printr-o instruciune DECLARE CURSOR); nchiderea cursorului nseamn eliberarea buferului de memorie ocupat de cursorul respectiv. Cursoarele se pot crea att la nivelul limbajului SQL2 sau al extensiilor procedurale ale acestuia, ct i prin intermediul limbajului SQL integrat (Embedded SQL) sau a bibliotecilor i interfeelor de programare a aplicaiilor de baze de date (ca, de exemplu, ODBC, JDBC). Cursoarele pot fi memorate n server, iar clientul primete cte o linie (sau un grup de linii) de la server la fiecare instruciune de extragere, sau pot fi memorate n client i sunt folosite direct n programul respectiv. Cursoarele create prin intermediul unui limbaj de extensie SQL sunt cursoare la server i pot fi definite n funciile i procedurile stocate din server. n interfeele de programare se pot defini att cursoare la server ct i cursoare la client. Aceste aspecte vor fi detaliate pentru fiecare limbaj sau interfa n parte. n general, se consider c este mai avantajos s fie folosite cursoare la server dect cursoare la client, deoarece memorarea n client necesit ca ntreaga mulime de tupluri s fie transferat dintr-o dat de la server la client, chiar dac ulterior, din diferite cauze, clientul nu va folosi dect o parte din tuplurile pe care le-a primit prin reea i le-a memorat.

10

O procedur stocat (stored procedure) este o procedur care implementeaz o parte din algoritmii de calcul ai aplicaiilor i care este memorat n baza de date la fel ca i alte obiecte ale bazei de date. Procedurile stocate sunt compilate i optimizate de sistemul de gestiune o singur dat, atunci cnd sunt folosite prima oar i rmn memorate n server pentru oricte apeluri ulterioare. Apelul unei proceduri stocate de ctre un client (aplicaie) produce execuia tuturor instruciunilor procedurii i returnarea rezultatului (dac exist), eliminnd cerina ca acel client s transmit individual fiecare instruciune necesar pentru rezolvarea sarcinii de calcul respective. n felul acesta se reduce, pe de o parte, comunicaia ntre aplicaie i serverul bazei de date i, pe de alt parte, chiar timpul de execuie a sarcinii respective, dat fiind c procedura stocat este deja compilat i optimizat. Exist ns i pericolul ca, dac foarte multe aplicaii i desfoar operaiile de prelucrare pe server prin intermediul procedurilor stocate, serverul s fie congestionat i s nu mai asigure performane satisfctoare nici uneia din aplicaii. Cu alte cuvinte, utilizarea intens a procedurilor stocate poate duce la scderea scalabilitii sistemului de baze de date. Bineneles, o analiz atent a modului de distribuire a operaiilor de prelucrare ntre execuia la serverul de baze de date (n proceduri stocate) i execuia la client, n programele de aplicaii sau n alte niveluri intermediare de execuie distribuit (middleware) poate asigura att perfomane ridicate de execuie ct i scalabilitatea sistemelor de baze de date. O funcie definit de utilizator (user-defined function) este o funcie memorat n baza de date, la fel ca o procedur stocat; diferena ntre acestea este c o funcie returneaz ntotdeauna o valoare i poate fi folosit direct n expresii, pe ct vreme o procedur stocat poate s nu returneze nici o valoare. Un trigger este o procedur stocat cu o funcionare special, care este executat automat atunci cnd se efectueaz o operaie de actualizare a unei relaii. Triggerele sunt asociate cu comenzi de inserare (INSERT), tergere (DELETE) sau actualizare (UPDATE) a tuplurilor dintr-o anumit relaie i au ca utilizare principal extinderea capacitii sistemului de gestiune de meninere a integritii datelor relaionale. Prin triggere se pot specifica i impune procedural constrngerile explicite, cum sunt dependenele de date (dependene funcionale, multivalorice, sau de jonciune) care nu sunt determinate de chei ale relaiilor. De asemenea, triggerele mai sunt folosite i pentru generarea automat a unor valori care rezult din valori ale altor atribute, precum i pentru jurnalizarea transparent a evenimentelor sau culegerea de date statistice n legtur cu accesarea relaiilor. Standardul SQL2 nu prevede comenzi pentru crearea triggerelor, dar ele pot fi create folosind instruciuni ale limbajelor procedurale de extensie a limbajului SQL. n general, triggerele definite n diferite limbaje procedurale sunt neportabile. Limbajele procedurale de extensie a limbajului SQL, dei au aceeai utilizare general n programarea bazelor de date, sunt specifice fiecrui SGBD i nu sunt tocmai compatibile ntre ele. n continuare se vor prezenta pe scurt caracteristicile limbajelor Transact-SQL i PL/SQL. Detalii privind aceste limbaje se gsesc, bineneles, n documentaia sistemelor de gestiune care le utilizeaz.

4.2.1.1

LIMBAJUL TRANSACT SQL

Programele Transact-SQL pot fi executate ca proceduri memorate n cadrul bazei de date sau ca loturi (batchs) de instruciuni transmise sistemului prin intermediul unei aplicaii sau a unui program utilitar de acces interactiv la baza de date. Programele utilitare de acces interactiv din distribuia SQL Server sunt isql sau osql (la nivel de linie de comand) i SQL Query Analyzer (care ofer i o interfa grafic). De asemenea, numeroase operaii de definire a tabelelor i a altor caracteristici ale bazelor de date se pot face din consola de administrare (Enterprise Manager) a sistemului SQL Server. Loturi de prelucrare. Un lot (batch) const dintr-o secven de instruciuni Transact-SQL terminat cu comanda GO. Exist mai multe reguli de grupare a instruciunilor n loturi. De exemplu: orice instruciune CREATE trebuie s fie prima n lot; de aceea nu pot fi grupate n acelai lot instruciunile CREATE TABLE, CREATE VIEW, CREATE TRIGGER, CREATE RULE; etc. Sistemul de gestiune SQL Server compileaz lotul de instruciuni i, dac este corect din punct de vedere sintactic, ncepe execuia lui; dac exist erori de compilare, lotul nu este executat deloc. Erorile aprute n cursul execuiei unui lot pot opri numai execuia instruciunii eronate (de exemplu, n cazul erorilor de nerespectare a unor constrngeri) sau pot opri execuia instruciunii care a provocat eroarea i a tuturor instruciunilor care urmeaz dup aceasta. n acest din urm caz vor fi efectuate i operaii legate de gestiunea tranzaciilor, dac este cazul (rularea napoi - rollback- a operaiilor efectuate nainte de apariia erorii). Variabile locale. n limbajul Transact-SQL pot fi folosite variabile locale pentru memorarea unor valori care pot fi testate sau modificate (ca n orice alt limbaj) i, n plus, asigur transferul datelor ctre i de la tabelele bazei de date. Variabilele locale au ca domeniu de definiie lotul, procedura sau blocul n care au fost declarate.

11

O variabil local se declar folosind instruciunea DECLARE care specific un identificator (un nume care trebuie s nceap cu caracterul @) i tipul variabilei. Sintaxa de declarare arat astfel:
DECLARE @nume_variabila tip_date

Limbajul Transact-SQL suport toate tipurile de date prevzute n standardul SQL2 i, n plus, permite definirea de ctre utilizator a unor noi tipuri de date. Iniializarea variabilelor locale se poate face printr-o comand SELECT, cu urmtoarea sintax:
SELECT @nume_variabila = expresie

De exemplu, declararea variabilei locale cu numele @contor, de tip ntreg (int) i iniializarea acesteia cu valoarea 1 se face astfel:
DECLARE @contor int SELECT @contor = 1

Instruciuni de control al ordinii de execuie. Ordinea de execuie a instruciunilor unui lot sau a unei proceduri stocate este controlat prin urmtoarele instruciuni de control: BEGIN...END GOTO IF...ELSE RETURN WAITFOR WHILE BREAK CONTINUE

Instruciuni SQL. Limbajul Transact-SQL suport toate instruciunile SQL, cu unele modificri de sintax, astfel nct s poat fi folosite n combinaie cu variabilele locale ale programului. De exemplu, form modificat a instruciunii SELECT, prin care se asigneaz variabile locale cu valori ale unor atribute selectate, este:
SELECT @var1 = col1, @var2 = col2, ... @varn = coln FROM lista_tabele WHERE conditie

O astfel de instruciune este util pentru interogrile care returneaz o singur linie, deoarece variabilele locale sunt setate cu valorile coloanelor primei linii a rezultatului, iar valorile din celelalte linii se pierd (nemaifiind loc unde s fie memorate).
DECLARE @id_angajat int, @nume char(20, @prenume char(20) SELECT @nume = Nume, @prenume = Prenume FROM ANGAJATI WHERE IdSAngajat = @id_angajat

Atunci cnd o interogare returneaz o mulime de linii se poate folosi un cursor. De asemenea, variabilele locale pot fi folosite n construcia condiiei din clauza WHERE a instruciunii SELECT, n orice loc unde poate fi folosit o variabil de coloan sau o constant.

4.2.2

INTERFETE SI BIBLIOTECI DE PROGRAMARE A APLICATIILOR DE BAZE DE DATE

Dei nu sunt prevzute n standardul SQL, interfeele de programare a aplicaiilor de baze de date s-au dezvoltat i diversificat deosebit de mult i reprezint n momentul de fa cea mai folosit tehnologie de realizare a acestor aplicaii. Multe sisteme de gestiune a bazelor de date prezint biblioteci de programare care ofer o interfa compus din funcii i macrodefiniii ce permit unei aplicaii s interacioneze cu serverul bazei de date. n general, funciile prevzute n astfel de interfee permit conectarea la server, transmiterea ctre server a unor instruciuni SQL i preluarea rezultatelor returnate de server. Cele mai multe biblioteci sunt dezvoltate pentru limbajul C (de exemplu, biblioteca C pentru sistemul Microsoft SQL Server - DB-Library for C), dar exist biblioteci i pentru alte limbaje (C++, Perl, PHP, etc). Pe lng aceste biblioteci specifice diferitelor sisteme SGBD, s-au dezvoltat i bibiloteci care ofer interfee cu un grad ridicat de generalitate, care pot fi folosite pentru mai multe tipuri de sisteme SGBD. Cele mai cunoscute sunt interfeele ODBC (Open DataBase Connectivity) sau JDBC (Java DataBase Connectivity), care vor fi prezentate n ultimele seciuni ale acestui capitol.

12

4.2.2.1

INTERFAA ODBC

Bibliotecile de programare a aplicaiilor specifice fiecrui SGBD prezint dezavantajul dependenei codului dezvoltat fa de sistemul folosit la un moment dat; dac se schimb sistemul SGBD, atunci se schimb ntreaga interfa i o mare parte din programele de aplicaii trebuie s fie rescrise. Tehnologia ODBC (Open Database Connectivity) ofer o interfa de programare a aplicaiilor (Application Programming Interface API) prin apel de funcii (call-level interface - CLI), independent de sistemul SGBD folosit. Aceast independen se obine prin intermediul unor drivere, care sunt specifice fiecrui SGBD, n timp ce funciile prevzute n interfa, care pot fi apelate de aplicaii, sunt aceleai, definite de standardul ODBC. Pentru a folosi interfaa ODBC, trebuie s fie instalat driverul pentru sistemul SGBD necesar. Unele drivere ODBC se instaleaz atunci cnd se instaleaz unele pachete de programe. De exemplu, driverele ODBC pentru baze de date Access, FoxPro se instalez o dat cu pachetul Microsoft Office. Alte drivere ODBC se pot instala separat, dac exist pachetul de instalare respectiv. Administratorul de drivere ncarc driverul specific sistemului de gestiune folosit de aplicaie. Interfaa ODBC

Aplicaie Administrator de drivere

Driver Driver Driver

Sursa de date

Sursa de date

Sursa de date

SGBD i Baza de date

SGBD i Baza de date

SGBD i Baza de date

Arhitectura ODBC. Administratorul de drivere, precum i driverele specifice diferitelor sisteme de gestiune de baze de date sunt, n general, furnizate ca biblioteci dinamice care sunt legate (link) n programul de aplicaie. Pentru orice tip de SGBD pentru care este instalat un driver ODBC se poate defini o surs de date folosind administratorul de surse de date (ODBC Data Source Administrator) care atribuie un nume de surs de date (i alte opiuni, depinznd de driverul instalat) unei baze de date. Un program de aplicaie care utilizeaz interfaa ODBC apeleaz funcii ODBC care sunt implementate n driver. Driverul transform apelurile de funcii ODBC n comenzi SQL (sau ntr-un limbaj procedural de extensie a limbajului SQL, implementat de sistemul de gestiune respectiv) pe care le transmite sistemului de gestiune, preia rezultatele i le returneaz programului de aplicaie. Acest tehnologie, care ofer i avantajul unui standard la care au participat majoritatea productorilor de sisteme de gestiune a bazelor de date, a fost extrem de bine primit de programatorii de aplicaii de baze de date i s-a dezvoltat foarte rapid. Drivere ODBC sunt disponibile pentru majoritatea sistemelor de gestiune a bazelor de date i sunt produse de furnizorii de SGBD-uri sau de alte firme productoare de software. Interfaa ODBC poate fi folosit direct n programarea aplicaiilor, sau poate fi accesat prin intermediul altor interfee, de nivel mai ridicat, care nglobeaz funciile ODBC, oferind modaliti de programare obiect-orientate: RDO (Remote Data Objects), DAO (Data Access Objects), clase MFC (Microsoft Foundation Class) pentru baze de date.

4.2.2.2

INTERFAA JDBC

Ca i interfaa ODBC, interfaa JDBC este o interfa de programare a aplicaiilor de baze de date independent de platform i de sistemul SGBD. Interfaa JDBC const din clase n limbajul Java i permite interaciunea cu baze de date relaionale, precum i cu alte surse de date n format tabelar.

13

Prima versiune a specificaiilor JDBC 1.0 API este coninut n biblioteca java.sql (care face parte din sistemul de dezvoltare standard Java - J2SDK). Noi funcionaliti au fost adugate n specificaiile JDBC 2.0 API, i JDBC 2.1 API, dintre care o parte sunt coninute n versiunile recente ale bibliotecii java.sql, iar alt parte n biblioteca de extensie javax.sql. Ca i interfaa ODBC, interfaa JDBC este o interfa la nivel de apeluri de funcii (call-level interface CLI) independent de sistemul de gestiune, prin care programele de aplicaie Java transmit ctre baza de date instruciuni SQL ca iruri de caractere. Interfaa JDBC, care s-a dezvoltat pe baza interfeei ODBC, permite accesul direct la bazele de date relaionale din programe Java, din care apelul funciilor ODBC este destul de dificil i produce scderea nivelului de securitate oferit de tehnologia Java.

14

5. NORMALIZAREA RELAIILOR
La proiectarea bazelor de date relaionale se stabilete mulimea relaiilor, prin selectarea tipurilor relevante de entiti din realitatea modelat i a asocierilor dintre acestea. Modul n care se pot stabili relaiile unei baze de date nu este unic i de aceea este necesar s existe criterii de evaluare a calitii relaiilor, astfel nct acestea s asigure att integritatea datelor ct i performane de interogare ct mai bune. Criteriul de evaluare a relaiilor se bazeaz pe conceptul de dependene de date. Dependenele de date (data dependencies) reprezint constrngeri care se impun valorilor atributelor unei relaii i care determin proprietile relaiei n raport cu operaiile de inserare, tergere i actualizare a tuplurilor. Pe baza dependenelor de date se pot stabili reguli de definire a relaiilor, astfel nct acestea s prezinte anumite proprieti, proprieti care caracterizeaz formele normale ale relaiilor (sau gradele de normalizare ale acestora). O form normal a unei relaii (normal form) presupune anumite condiii pe care trebuie s le ndeplineasc valorile atributelor i dependenele de date definite pe acea relaie. Iniial, E.F. Codd a propus trei forme normale, numite prima form (FN1), a doua form (FN2) i a treia form normal (FN3). Ulterior, a fost introdus o definiie mai complet a celei de-a treia forme, care a primit numele de forma normal Boyce-Codd (FNBC). Toate aceste forme normale se refer la condiiile pe care trebuie s le ndeplineasc dependenele funcionale ntre atributele unei relaii. Forme normale superioare, cum sunt a patra form normal (FN4) i a cincea form normal (FN5) impun condiii dependenelor multivalorice, respectiv dependenelor de jonciune ntre atributele unei relaii. Formele normale ale relaiilor formeaz o colecie ordonat (FN1, FN2, FN3, FNBC, FN4, FN5), i ele impun condiii din ce n ce mai restrictive asupra dependenelor de date admise, minimiznd astfel redundana i anomaliile de actualizare a relaiilor. Ordonarea formelor normale de la FN1 la FN5 nseamn c orice relaie aflat n FN2 este, de asemenea, n FN1, orice relaie n FN3 este n FN1 i FN2, etc. Normalizarea relaiilor (normalization) const n descompunerea lor, astfel nct relaiile rezultate s ndeplineasc condiii din ce n ce mai restrictive n ceea ce privete dependenele de date, adic s corespund unor forme normale ct mai avansate. Prin normalizare se elimin (sau se micoreaz) redundana datelor memorate n relaii i anomaliile care provin din aceast redundan. Totui, dup normalizare, o parte din interogri vor necesita jonciuni ntre relaiile rezultate prin descompunere, jonciuni care nu erau necesare dac relaia nu ar fi fost descompus i care conduc la creterea duratei de execuie a acestor operaii de interogare. De aceea, n practica proiectrii bazelor de date, normalizarea relaiilor nu se face ntotdeauna pn n forma normal cea mai nalt. Proiectanii pot pstra relaiile ntr-o form de normalizare mai sczut (de obicei n forma FN3 sau FNBC) cu condiia ca aceste situaii s fie bine cunoscute i documentate, pentru a se trata n mod corespunztor operaiile n care ar putea s apar anomalii de actualizare a relaiilor.

5.1

REDUNDANA DATELOR I ANOMALIILE DE ACTUALIZARE A RELAIILOR

Problemele legate de redundana datelor memorate n relaii vor fi studiate pe un exemplu. Fie relaia AP(IdAngajat,Nume,Prenume,Adresa,IdProiect,Ore). Fiecare tuplu al relaiei conine informaii despre un angajat i numrul de ore aferente fiecruia dintre proiectele la care acesta lucreaz. Semnificaia atributelor este destul de clar. Atributul IdAngajat este numrul de identificare (unic) al unui angajat; Nume, Prenume i Adresa sunt date ale angajatului. Atributul IdProiect este identificatorul (numrul) unui proiect la care lucreaz angajatul; se poate considera c este o cheie strin care refer cheia primar cu acelai nume dintr-o alt relaie, care descrie proiectele instituiei, dar acest lucru este mai puin important n acest moment. Atributul Ore reprezint numrul de ore lucrate de angajat la proiectul respectiv. Dac se admite c un angajat lucreaz la mai multe proiecte, atunci cheia primar a relaiei AP este PK = {IdAngajat,IdProiect}. O stare a relaiei AP este dat n figura 5.1, a. Se observ c datele despre fiecare angajat (Nume, Prenume, Adresa) se repet n fiecare tuplu corespunztor fiecrui proiect la care acesta lucreaz, ceea ce reprezint un grad ridicat de redundan a datelor. Aceast redundan are ca efect att creterea spaiului de memorare a relaiei, ct i anomalii de actualizare a relaiei. Anomaliile de actualizare a relaiei apar la inserarea, tergerea sau actualizarea tuplurilor relaiei. Anomalii de inserare. n relaia AP nu se pot introduce date despre un angajat (identificatorul angajatului, numele, prenumele, adresa) dac nu exist cel puin un proiect la care acesta s lucreze. ntr-adevr, nu se poate introduce un tuplu cu valoare NULL a atributului IdProiect, deoarece acest atribut face parte din cheia primar a relaiei.

O alt anomalie de inserare n relaia AP este aceea c se poate introduce un nou tuplu care conine alte valori ale atributelor Nume, Prenume sau Adresa, pentru aceeai valoare a identificatorului IdAngajat. De exemplu, se poate introduce tuplul (1,Dragomir,Eugen,Bucuresti,P3,110). Acest tuplu este acceptat de SGBD, deoarece are cheia primar (1,P3), care nu mai exist n relaia AP. Dar n acest moment starea relaiei AP nu este consistent din punct de vedere semantic deoarece exist doi angajati (Ionescu Ion i Dragomir Eugen) care au acelai numr de identificare (IdAngajat = 1). AP
IdAngajat 1 2 3 1 2 Nume Ionescu Popescu Marin Ionescu Popescu Prenume Ion Petre Mihai Ion Petre a A IdAngajat 1 2 3 Nume Ionescu Popescu Marin Prenume Ion Petre Mihai Adresa Bucuresti Craiova Ploieti P IdAngajat 1 2 3 1 2 IdProiect P1 P1 P2 P2 P2 Ore 100 200 120 150 50 Adresa Bucuresti Craiova Ploieti Bucuresti Craiova IdProiect P1 P1 P2 P2 P2 Ore 100 200 120 150 50

b
Fig. 5.1. a - Relaia AP; b - descompunerea relaiei AP n relaiile A i P.

Anomalii de tergere. Dac se terg toate tuplurile referitoare la un anumit proiect din relaia AP, atunci se pot pierde toate datele referitoare la acei angajai care lucreaz doar la proiectul respectiv. De exemplu, dac se terg tuplurile referitoare la proiectul P2 (1,Ionescu,Ion,Bucuresti,P2,150), (2,Popescu,Petre,Craiova,P2,50), (3,Marin,Mihai,Ploieti,P2,120), atunci se pierd toate informaiile despre angajatul Marin Mihai (identificatorul angajatului, numele, prenumele, adresa). Anomalii de actualizare. Dac se modific valoarea unuia din atributele care au valori redundante (Nume,Prenume sau Adresa) ntr-un tuplu al relaiei AP, starea relaiei poate deveni inconsistent. De exemplu, dac n tuplul (1, Ionescu,Ion,Bucuresti,P2,150) se modific atributul Nume la valoarea Gheorghiu, atunci n relaie vor exista tuplurile: (1,Ionescu,Ion, Bucuresti,P1,100) i (1,Gheorghiu,Ion,Bucuresti,P2,150), adic doi angajati cu nume diferite (Ionescu i Gheorghiu) au acelai numr de identificare (1). De asemenea, pot s apar numeroase alte situaii de inconsisten atunci cnd se fac actualizri ntr-o astfel de relaie care prezint date redundante. Dac se dorete pstrarea consistenei relaiei AP, trebuie s fie luate msuri speciale, care constau n realizarea unor proceduri care s verifice datele la fiecare operaie de actualizare a relaiei i s interzic operaiile care produc inconsisten. Anomaliile descrise mai sus se pot elimina dac relaia AP se descompune n dou relaii echivalente: relaia A(IdAngajat,Nume,Prenume,Adresa), cu cheia primar IdAngajat i relaia P(IdAngajat,IdProiect,Ore), cu cheia primar {IdAngajat,IdProiect}, iar atributul IdAngajat este o cheie strin care refer cheia primar cu acelai nume din relaia A (fig. 5.1, b). Aceste relaii nu mai prezint redundan i nici anomalii la actualizarea lor (se poate verifica uor acest lucru). De exemplu, nu se admite inserarea tuplulului (1,Dragomir,Eugen,Bucureti) n relaia A cu starea din figura 5.1, deoarece sistemul de gestiune refuz introducerea unui nou tuplu cu aceeai valoare (1) a cheii primare (IdAngajat). Relaiile A i P sunt mai bune din punct de vedere al volumului de date memorate i sunt, de fapt, relaii cu un grad de normalizare mai ridicat, aa cum se va demonstra n seciunile urmtoare. n schimb, interogrile asupra acestor dou relaii A, P sunt mai costisitoare (ca timp de execuie) fa de interogrile similare executate numai n relaia AP. Fie, de exemplu, interogarea Care este numrul de ore pe care le lucreaz angajatul cu numele Ionescu la proiectul P1 ?. Expresiile de algebr relaional pentru realizarea acestei interogri n relaia AP i respectiv, n relaiile A i P sunt:

Q1 = Ore Nume Q2 = Ore Nume

='Ionescu' AND IdProiect ='P1'(AP) ='Ionescu' AND IdProiect ='P1'(A><P)

Pentru realizarea interogrii Q2 este necesar o operaie de jonciune ntre cele dou relaii A i P n care a fost descompus relaia iniial AP, operaie care, n general, este mai costisitoare ca timp de execuie dect operaia de restricie aplicat unei singure relaii. Cum se poate ti care este cea mai bun alegere a relaiilor? Rspunsul la aceast ntrebare nu este foarte simplu, deoarece necesit numeroase informaii privind exploatarea ulterioar a bazei de date (ce spaiu de memorare a relaiilor va fi disponibil, ce interogri se vor efectua asupra relaiilor, n ce situaii este important s se obin o vitez de execuie mare, etc.). Principial, o relaie trebuie s corespund unui singur tip de entitate (sau asociere) precis definit i atributele acesteia s corespund numai acelui tip de entitate i s nu fie combinate cu atribute ale altor tipuri de entiti. Aceast cerin corespunde unei definiii semantice simple, concise i clare a relaiei. n exemplul de mai sus, relaia A corespunde tipului de entitate angajat i are ca atribute numai pe acelea care se refer la acest tip de entitate. La fel, relaia P corespunde asocierii M:N ntre tipul de entitate angajat i tipul de entitate proiect(care nu apare explicit n acest exemplu) i atributele acesteia se refer numai la acest aspect (numrul de ore lucrate de un angajat la un anumit proiect). Definiia semantic a acestor relaii este simpl i concis: A este relaia care conine date despre angajaii instituiei; P este relaia care conine numrul de ore lucrate de angajai la proiecte. n schimb, relaia iniial AP conine atribute amestecate despre angajai i proiectele la care acetia lucreaz, iar definiia ei semantic nu mai este att de simpl i clar: AP este o relaie care conine date despre angajaii instituiei i cte ore lucreaz la fiecare proiect. O abordare mai precis a problemei definirii relaiilor bazelor de date se poate face pe baza analizei dependenelor de date i a normalizrii relaiilor.

5.2

DEPENDENE FUNCIONALE

O dependen funcional - DF - (functional dependency) n relaia cu schema R = {A1,A2,...An} ntre dou mulimi de atribute X i Y (care sunt submulimi ale lui R) exist dac i numai dac, n orice stare a relaiei R, fiecrei valori a atributului (simplu sau compus) X i corespunde o singur valoare a atributului (simplu sau compus) Y. O dependen funcional este deci o constrngere ntre dou submulimi de atribute X i Y ale unei relaii i se noteaz XY. Ca exprimare, se mai spune c exist o dependen funcional de la X la Y, sau c atributul Y este dependent funcional de X. Noiunea de dependen funcional este o extindere a noiunilor de superchei i chei ale relaiilor: att supercheile (i, implicit cheile) relaiilor ct i dependenele funcionale sunt constrngeri pe care trebuie s le respecte valorile atributelor relaiilor. Dup cum s-a definit n Capitolul 2, o submulime K a unei mulimi de atribute R (care este schema relaiei cu acelai nume) este supercheie a relaiei R dac nu exist dou tupluri diferite n relaia R care s aib aceleai valori ale atributelor din mulimea K. Aceasta nseamn c, dac t1[K]=t2[K], atunci t1[R]=t2[R], adic t1 i t2 sunt identice i reprezint un singur tuplu n relaia R. Dependena funcional XY este satisfcut de relaia R atunci cnd, pentru orice pereche de tupluri t1 i t2, t1[X] = t2[X] implic t1[Y] = t2[Y]. Aadar, fiind dat o dependen funcional XY n relaia cu schema R, atributul X este o supercheie a relaiei dac atributul determinat (Y) este chiar mulimea R. O dependen funcional XY impune condiia ca unei valori (x) a atributului determinant X s i corespund o singur valoare (y) a atributului determinat Y. Adic, toate tuplurile care au valoarea (x) a atributului X, trebuie s aib aceeai valoare (y) a atributului Y. Dat fiind c, n cazul unei superchei, atributul determinat este chiar mulimea R a atributelor relaiei, i c ntr-o relaie nu pot exista dou sau mai multe tupluri identice, nseamn c nu pot exista dou sau mai multe tupluri cu aceeai valoare (k) a supercheii; aceast condiie este cunoscut ca fiind condiia de unicitate a supercheii. Dat fiind c oricare valoare a supercheii este unic ntr-o relaie, valorile atributelor determinate de aceasta sunt absolut necesare i unice i nu produc redundana datelor. n schimb, fiecare pereche de valori (x,y) ale atributelor X i Y ale dependenei funcionale XY poate s apar de mai multe ori n aceeai relaie, indicnd faptul c valoarea y este determinat n mod unic de valoarea x, dar acest lucru se repet de mai multe ori n relaie, deci reprezint o redundan a datelor.

Aceeai proprietate, de a determina funcional mulimea de atribute ale relaiei R, o are i orice cheie CK (primar sau secundar) a relaiei date (CKR), dat fiind c o cheie este o supercheie cu proprietatea de ireductibilitate. Fiind dat o relaie i o mulime de dependene funcionale care trebuie s fie satisfcute de orice stare a relaiei, o parte din dependenele funcionale pot fi determinate de chei ale relaiei (i acestea sunt constrngeri implicite, care nu produc redundana datelor i nici anomalii de actualizare a relaiei i sunt impuse automat de sistemul de gestiune), iar alt parte pot fi determinate de alte atribute care nu sunt chei ale relaiei (i acestea sunt constrngeri explicite care produc redundana datelor i anomalii de actualizare a relaiei, nu sunt impuse de sistemul de gestiune i necesit proceduri speciale pentru verificarea i impunerea lor). Aceast diferen de comportare a dependenelor funcionale n funcie de tipul atributului determinant (cheie sau non-cheie) face ca analiza lor s necesite cunoaterea cheilor relaiei. Cheile relaiilor se pot preciza explicit (i atunci ele implic dependenele funcionale corespunztoare) sau pot fi deduse din mulimea dependenelor funcionale stabilite de proiectant, folosind algoritmi de gsire a cheilor din mulimea dependenelor funcionale. Un astfel de algoritm va fi prezentat ntr-o seciune urmtoare. Tipuri de dependene funcionale i atribute. Dependenele funcionale pot fi pariale sau totale. O dependen funcional XY este parial (partial dependency) dac exist o submulime proprie Z a mulimii X (adic Z X) care determin funcional pe Y (ZY). O dependen funcional XY este total (full dependency), dac nu exist nici o submulime proprie Z a lui X care s determine funcional pe Y. Din aceast definiie rezult c, dac atributul X este simplu, dependena funcional XY este total. Dependena funcional XY (unde X R, Y R) este satisfcut de orice relaie R dac Y X. O astfel de dependen funcional se numete dependen funcional trivial. Dac atributul (simplu sau compus) CK este o cheie candidat a relaiei R, atunci, conform proprietii de ireductibilitate a cheii candidate, dependena CKR este total, adic nu exist o submulime proprie CK a lui CK care s prezinte proprietatea CKR. Atributele care aparin unei chei se numesc atribute prime, iar celelalte se numesc atribute neprime. Exemple de dependene funcionale. Se consider relaia AP definit mai sus, n care se pot stabili urmtoarele dependene funcionale, pe baza semnificaiei atributelor acesteia:
a) b) c) d) IdAngajatNume IdAngajatPrenume IdAngajatAdresa {IdAngajat,IdProiect}Ore

Aceste dependene funcionale specific faptul c identificatorul angajatului determin n mod unic numele, prenumele i adresa acestuia (dependenele a, b i c) i c numrul de identificare al angajatului i identificatorul proiectului determin n mod unic numrul de ore pe care le lucreaz respectivul angajat la acel proiect (dependena d). Cheia primar a relaiei {IdAngajat, IdProiect} poate fi definit explicit, sau poate fi dedus din dependenele funcionale de mai sus.

5.2.1 MULIMI DE DEPENDENE FUNCIONALE

n mod obinuit, proiectantul bazei de date specific acele dependene funcionale ntre atribute care sunt evidente din punct de vedere semantic. n afara acestor dependene funcionale, mai exist un numr destul de mare de dependene funcionale care se menin pentru orice stare a relaiei, i care se pot deduce din mulimea celor specificate, folosind regulile de deducere (inferen - inference rules) ale lui Armstrong. Aceste reguli sunt urmtoarele: 1) Reflexivitatea (reflexivity): dac Y X, atunci XY. Prin aceast regul se deduc numai dependene funcionale triviale, care nu aduc informaii suplimentare, dar care sunt utile n combinaie cu alte reguli de inferen. Urmtoarele dependene funcionale se deduc prin reflexivitate n relaia AP:
e) {IdAngajat,IdProiect}IdAngajat f) {IdAngajat,IdProiect}IdProiect

2) Augmentarea (augmentation): dac XY, atunci (X Z)(Y Z). Urmtoarele dependenele funcionale (g i h) sunt deduse prin augmentare, pornind de la dependenele funcionale (a) i respectiv (b), augmentate cu mulimea Z = {Nume} (i tinnd seama de faptul c Nume Nume = Nume):
g) {IdAngajat,Nume}Nume

h) {IdAngajat,Prenume}Prenume

3) Tranzitivitatea (transitivity): dac XY i YZ, atunci XZ. De exemplu, din dependenele (a) i (e) rezult:
i) {IdAngajat,IdProiect}Nume

Armstrong a demonstrat aceste trei reguli (demonstraia este foarte simpl i se bazeaz pe definiia dependenelor funcionale, [Arm74]) precum i faptul c ele sunt suficiente pentru calculul tuturor dependenelor funcionale pe care le implic o mulime dat de dependene funcionale. n afara acestor trei reguli de baz se mai pot folosi i alte reguli, care se pot deduce din acestea, i anume: 4) Proiecia (projection): dac XY Z, atunci XY i XZ. 5) Reuniunea (union): dac XY i XZ, atunci X(Y Z). 6) Pseudo-tranzitivitatea (pseudo-transitivity): dac XY i (W Y)Z, atunci (W X)Z. Reprezentarea grafic a dependenelor funcionale se poate face ca n figura 5.2 pentru relaia AP. Notaiile folosite sunt uor de neles.
Nume IdAngajat IdProiect Prenume Adresa Ore

Fig. 5. 2. Dependenele funcionale ale relaiei AP. nchiderea unei mulimi de dependene funcionale (closure of a set of functional dependencies). Fiind dat o mulime F de dependene funcionale, mulimea tuturor dependenelor funcionale care sunt implicate de F se numete nchiderea mulimii F i se noteaz F+. Ca exprimare, se mai spune c dependenele funcionale din F+ reprezint consecina logic a dependenelor funcionale din F. Mulimea tuturor dependenelor funcionale F+ se poate deduce prin aplicarea repetat a regulilor de inferen ale lui Armstrong asupra dependenelor funcionale din F. De multe ori este necesar s se verifice dac o anumit dependen funcional XY poate fi dedus dintr-o mulime dat F de dependene funcionale. Pentru aceasta se poate afla nchiderea F+ a mulimii F i se testeaz dac (XY)F+. Aceast metod este, ns, destul de laborioas, deoarece mulimea F+ este o mulime de dimensiune mare, chiar pentru mulimi F cu un numr mic de elemente. Exista si o metoda mai rapida de a afla dac o anumit dependen funcional XY poate fi dedus dintr-o mulime dat F de dependene funcionale, care se bazeaz pe noiunea de nchidere (X+) a unui atribut X n raport cu o mulime F de dependene funcionale. Mulimi echivalente de dependene funcionale (equivalent sets of functional dependencies). Dou mulimi de dependene funcionale E i F sunt echivalente dac nchiderile lor sunt egale (E+ = F+; acest lucru nseamn c: DF E DF F+ i DF F DF E+). Mulime minim de dependene funcionale (minimal set of functional dependencies). O mulime de dependene funcionale G este minim dac satisface urmtoarele condiii: (a) membrul drept al oricrei dependene funcionale din G este un atribut simplu; adic, pentru orice dependen funcional XY din G, Y este un atribut simplu; (b) orice dependen funcional din G este total; (c) mulimea G este ireductibil, adic, dac se exclude o dependen funcional din G, mulimea rezultat H nu este echivalent cu G (adic H+ G+). Se poate observa c mulimea dependenelor FAP definite pentru relaia AP este o mulime minim de dependene funcionale, deoarece satisface cele trei condiii impuse. Acoperirea minim a unei mulimi F de dependene funcionale (minimal cover of a set F of functional dependencies) este o mulime minim de dependene funcionale G care este echivalent cu F, adic G+ = F+. S-a demonstrat c pot exista mai multe acoperiri minime ale unei mulimi de dependene funcionale i c ntotdeauna se poate gsi cel puin una dintre acestea folosind algoritmul de mai jos [Elm00].

5.2.1.1 Dependenele funcionale i cheile relaiilor

Aa cum s-a mai artat, n orice relaie pot exista dou categorii de dependene funcionale: Dependene funcionale determinate de cheile relaiei; astfel de dependene funcionale nu produc redundana datelor i nici anomalii de actualizare a relaiei. Dependene funcionale n care atributul determinant nu este o cheie a relaiei; astfel de dependene funcionale produc redundana datelor i anomalii de actualizare a relaiei.

Constrngerile de cheie (primar sau secundar) sunt constrngeri implicite, coninute n definiia relaiei (constrngerile PRIMARY KEY sau UNIQUE din comanda CREATE TABLE) i sunt verificate i impuse automat de sistemul de gestiune; proiectantul bazei de date nu trebuie s prevad nimic suplimentar pentru ca aceste constrngeri s fie satisfcute de orice stare a relaiei. n schimb, dependenele funcionale n care atributul determinant nu este o cheie a relaiei sunt constrngeri explicite, care nu sunt verificate i nici impuse de sistemul de gestiune. Verificarea i impunerea acestor dependene funcionale se poate face numai procedural, prin triggere, proceduri stocate, sau funcii incluse n programele de aplicaie. De exemplu, n relaia A, singurele dependene funcionale sunt cele determinate de cheia primar a relaiei IdAngajat: IdAngajatNume, IdAngajatPrenume, IdAngajatAdresa. La fel, n relaia P, dependena funcional {IdAngajat,IdProiect}Ore este determinat de cheia primar a relaiei. Aceste dependene sunt evidente, rezultate din semnificaia atributelor definite iniial pentru relaia AP (din care provin relaiile A i P), dar pot fi i deduse i prin proiecia mulimii dependenelor funcionale ale relaiei AP, modalitate care va fi prezentat ulterior. Toate aceste dependene funcionale sunt verificate i impuse automat de ctre SGBD la fiecare operaie de actualizare a acestor relaii i nu necesit nici o procedur special. n relaia AP, pe lng dependena {IdAngajat,IdProiect}Ore care este determinat de cheia primar (i este deci verificat automat de sistemul de gestiune), mai exist dependenele: IdAngajatNume,IdAngajatPrenume, IdAngajatAdresa, care nu sunt determinate de o cheie a relaiei (IdAngajat nu este cheie n relaia AP). Pentru astfel de dependene funcionale trebuie s se prevad proceduri care s verifice i s impun respectarea constrngerilor respective. Pentru relaia AP, este necesar ca la orice operaie de actualizare a relaiei s se verifice valorile care urmeaz s fie introduse (sau modificate) i s nu se admit doi sau mai muli angajai cu acelai numr de identificare dar cu nume, prenume sau adres diferite, ceea ce nseamn impunerea dependenelor funcionale care nu sunt determinate de cheia relaiei (IdAngajatNume, IdAngajatPrenume, IdAngajatAdresa). Astfel de proceduri de verificare vor fi prezentate ntr-o seciune urmtoare.

5.2.2 DESCOMPUNEREA RELAIILOR

O descompunere D a schemei de relaie R (relation schema decomposition) este format din submulimi ale lui R (D = {R1,R2,...Rk}, unde R1 R, R2 R, ...Rk R, i R = R1 R2... Rk). Relaiile cu schemele R1,R2,...Rk sunt proiecii ale relaiei R pe submulimile de atribute corespunztoare i reprezint descompunerea relaiei R. Descompunerea unei relaii, efectuat n scopul normalizrii, nu poate fi fcut oricum, ci trebuie s fie respectate anumite condiii de conservare a semnificaiei atributelor i a dependenelor dintre ele, aa cum erau definite n relaia iniial. n aceast seciune i n cele care urmeaz se va exprima n mod frecvent o schem de relaie ca mulime a atributelor sale, ceea ce permite notaii i definiii mai simple. Din punct de vedere semantic, descompunerea relaiilor urmrete o separare a coninutului de informaie din relaia dat, astfel nct fiecare dintre relaiile rezultate s reprezinte un singur tip de entitate sau o asociere ntre dou tipuri de entiti. Dintre toate descompunerile posibile, numai o parte au proprietatea c pot reconstitui prin jonciune natural relaia iniial R. Ca terminologie, se poate considera strict descompunerea unei scheme de relaie ca descompunere a unei mulimi de atribute (R) n submulimi ale acesteia (R1,R2,...Rk), sau se poate considera descompunerea relaiei R prin proiecia relaiei R pe submulimile de atribute corespunztoare. Ambele expresii pot fi considerate corecte deoarece, chiar dac exist o diferen de nuan ntre ele, este clar la ce se refer i nu pot s apar confuzii. O situaie asemntoare se poate observa i la alte noiuni legate de normalizare. De exemplu, se poate folosi expresia de normalizare a schemei unei relaii, prin descompunerea schemei de relaie date, sau normalizarea relaiei, prin descompunerea relaiei date. Fiind dat o relaie cu schema R i mulimea F a dependenelor funcionale ale acesteia, o descompunere D a relaiei R se numete descompunere reversibil dac are proprietile de jonciune fr pierdere de informaie i de conservare a dependenelor funcionale.

5.2.1.2 Proprietatea de jonciune fr pierdere de informaie

Fie r extensiunea (starea) unei relaii cu schema R (adic r(R) este valoarea la un moment dat a relaiei cu schema R) i Ri(r) proiecia acestei relaii pe mulimea de atribute Ri R. Descompunerea D = {R1,R2,...Ri,..Rk} are proprietatea de jonciune fr pierdere de informaie - lossless join) dac r = R1(r)>< R2(r)...>< Ri(r)..>< Rk(r). Proprietatea de jonciune fr pierdere de informaie (sau de conservare a informaiei) a unei descompuneri se refer la posibilitatea de a obine aceeai valoare a relaiei prin jonciunea relaiilor rezultate din acea descompunere. Acest lucru nseamn c, dac prin jonciunea proieciilor relaiei date iniial se obine o relaie identic cu aceasta, descompunerea are proprietatea de jonciune fr pierdere de informaie. Lipsa acestei proprieti se manifest n mod paradoxal prin apariia unor tupluri noi n relaia obinut prin jonciunea relaiilor R1,R2,...Ri,...Rk, tupluri care nu existau n relaia R. Aceste tupluri parazite apar ca o pierdere de informaie din relaia R i provin din pierderea unor constrngeri care existau n R i care sau pierdut prin descompunerea D = {R1,R2,..Ri,..Rk}. Teorema lui Ullman. Descompunerea D = {R1,R2} a unei relaii R este o descompunere fr pierdere de informaie la jonciune n raport cu mulimea F a dependenelor funcionale, dac i numai dac este ndeplinit una din condiiile: (a)((R1 R2)(R1 R2)) F+, sau (b) ((R1 R2)(R2 R1)) F+. Aceast teorem ofer o modalitate de descompunere a unei relaii n dou relaii fr pierdere de informaie la jonciune. Din teorema lui Ullman se vede c o descompunere a unei relaii n dou relaii este fr pierdere de informaie la jonciune dac atributul comun al celor dou relaii rezultate (atributul R1 R2, pe care se va executa jonciunea natural) determin funcional una din diferenele dintre mulimile atributelor celor dou relaii, (R1 R2) sau (R2 R1). Din condiiile impuse n teorema lui Ullman, se poate deduce cu uurin c, dac intersecia atributelor celor dou relaii rezultate este sau conine o cheie a uneia dintre aceste relaii, atunci descompunerea este fr pierdere de informaie la jonciune. ntr-adevr, dac (R1 R2) este o supercheie n R1, atunci acest atribut determin funcional orice submulime de atribute din R1, inclusiv submulimea de atribute (R1 R2) adic (R1 R2)(R1 R2). n mod asemntor se raioneaz n situaia n care (R1 R2) este o supercheie n R2. Reciproc, dac descompunerea unei relaii R n dou scheme de relaie R1 i R2 respect teorema lui Ullman, atunci atributul comun al celor dou relaii rezultate (adic intersecia R1 R2) este supercheie fie n relaia R1, fie n relaia R2. Demonstraia este foarte simpl. Dac (R1 R2)(R1 R2), atunci, prin augmentare cu (R1 R2) se obine (R1 R2)((R1 R2)(R1 R2)), rezult (R1 R2)R1 i deci (R1 R2) este supercheie n relaia R1. Un raionament asemntor se poate face pentru cazul n care (R1 R2)(R2 R1) i rezult c atributul comun este supercheie n relaia R2. Revenind la exemplele prezentate n seciunile precedente, se va analiza dac descompunerile efectuate (n mod intuitiv) prezint proprietatea de jonciune fr pierderi de informaie. Pentru analiza descompunerii relaiei AP n relaiile A i P se calculeaz:
A P = {IdAngajat}, A P = {Nume,Prenume,Adresa} P A = {IdProiect,Ore}

Din dependenele funcionale IdAngajatNume,IdAngajatPrenume,IdAngajat Adresa se poate deduce dependena funcional IdAngajat{Nume,Prenume,Adresa} prin regula de reuniune a dependenelor funcionale. Rezult c ((A P)(A P)) F+, deci aceast descompunere ndeplinete prima condiie din teorema lui Ullman i este o descompunere fr pierdere de informaie la jonciune.

5.2.1.3 Proprietatea de conservare a dependenelor funcionale

Informal, descompunerea unei relaii cu schema R n relaiile cu schemele R1,R2,...Rk prezint proprietatea de conservare a dependenelor funcionale definite de mulimea F (dependency-preservation) dac oricare din dependenele din F se regsete sau poate fi dedus din dependenele funcionale ale relaiilor R1,R2,...Rk. Conservarea dependenelor funcionale este necesar pentru ca verificarea i impunerea constrngerilor definite de dependenele funcionale respective s poat fi efectuat la nivelul unei singure relaii. Dac una sau mai multe dependene funcionale se pierd prin descompunerea unei relaii, atunci constrngerile (definite de dependenele funcionale respective) pot fi impuse numai dac se calculeaz jonciunea natural a relaiilor rezultate. O astfel de modalitate de verificare este posibil, dar ineficient

(operaia de jonciune fiind o operaie costisitoare ca timp de execuie), i de aceea, n proiectarea bazelor de date se folosesc, pe ct posibil, descompuneri care conserv dependenele funcionale. nainte de a da o definiie formal a proprietii de conservare a dependenelor funcionale, se va defini proiecia unei mulimi de dependene funcionale pe o relaie. Proiecia unei mulimi de dependene funcionale. Fiind dat mulimea dependenelor funcionale F pe relaia cu schema R, i o descompunere D = {R1,R2,..Ri,...Rk} a lui R, proiecia lui F pe Ri (unde 1 i k), notat Ri(F), este o mulime de dependene funcionale XY din F+, astfel nct X Ri i Y Ri. Aceast definiie semnific faptul c o dependen funcional aparine proieciei lui F pe Ri dac att atributele din partea stng ct i atributele din partea dreapt ale dependenei funcionale date aparin relaiei Ri. De asemenea se observ c dependenele funcionale ale proieciei lui F pe Ri pot s aparin nu neaprat lui F, ci nchiderii lui F (adic mulimii F+). Pe baza acestor observaii, se poate da definiia proprietii de conservare a dependenelor funcionale. Conservarea dependenelor funcionale. O descompunere D = {R1,R2, ...Ri,...Rk} a unei relaii cu schema R prezint proprietatea de conservare a dependenelor funcionale definite de mulimea F, dac reuniunea proieciilor lui F pe relaiile Ri (unde 1 i k) este echivalent cu F, adic: ((R1(F)) (R2(F)) ... (Rk(F)))+ = F+ . Ca exemplu de descompunere cu conservarea dependenelor funcionale, se analizeaz descompunerea prezentat la nceputul acestui capitol, a relaiei AP = {IdAngajat,Nume,Prenume,Adresa,IdProiect, Ore} n relaiile A = {IdAngajat,Nume,Prenume,Adresa} i P = {IdAngajat,IdProiect, Ore}. Mulimea FAP a dependenelor funcionale definite pe AP este:
FAP = {IdAngajatNume,IdAngajatPrenume, IdAngajatAdresa,{IdAngajat,IdProiect}Ore}

Proiecia mulimii FAP pe relaia A este: deoarece toate atributele implicate de aceste dependene funcionale aparin relaiei A: IdAngajat A,Nume A,Prenume A,Adresa A. Proiecia mulimii FAP pe relaia P este:
P(FAP)={{IdAngajat,IdProiect}Ore} A(FAP)={IdAngajatNume,IdAngajatPrenume,IdAngajatAdresa}

deoarece toate atributele implicate de aceast dependen funcional aparin relaiei P: IdAngajat
P,IdProiect P,Ore P.

Dat fiind c A(FAP) P(FAP) = FAP, rezult c aceast descompunere conserv dependenele funcionale date. Nu ntotdeauna este posibil efectuarea unei descompuneri cu conservarea tuturor dependenelor funcionale. Dac, prin descompunerea unei relaii, se pierd una sau mai multe dependene funcionale, constrngerile impuse de acestea nu mai pot fi verificate la nivelul nici uneia din relaiile rezultate. n aceast situaie, procedurile de verificare i impunere a respectrii unor astfel de dependene funcionale trebuie s efectueze mai nti jonciunea relaiilor, pentru a obine o relaie n care s se poat verifica acele dependene. Un astfel de exemplu va fi prezentat n seciunea 5.2.6, dedicat formei normale Boyce-Codd. Cele dou proprieti ale unei descompuneri, conservarea informaiei i conservarea dependenelor funcionale sunt independente. Este posibil ca o descompunere s fie fr pierdere de informaie, dar s nu conserve dependenele funcionale, sau invers.

5.2.3 PRIMA FORMA NORMAL A RELAIILOR (FN1)

O relaie este normalizat n prima form normal (FN1) dac fiecare atribut ia numai valori atomice i scalare din domeniul su de definiie. Caracterul de atomicitate se refer la faptul c valoarea unui atribut are semnificaie numai n ansamblul ei i nu permite descompunerea n componente care s poat fi manevrate separat. Chiar dac tipul de date peste care este definit domeniul unui atribut este reprezentat prin mai multe componente, acestea nu au semnificaie luate individual. Valoarea scalar a unui atribut se refer la faptul c un atribut nu poate avea dect o valoare (din domeniul de definiie pe care este definit) pentru fiecare tuplu. Sistemele SGBD relaionale nu admit relaii care s nu fie cel puin n prima form normal, dar proiectarea relaiilor normalizate n prima form normal este simpl i ntotdeauna posibil, i a fost deja prezentat n Capitolul 2.

5.2.4 A DOUA FORM NORMAL A RELAIILOR (FN2)

O relaie este normalizat n a doua form normal (FN2) n raport cu o mulime de dependene funcionale F, dac este n FN1 i dac n F+ nu exist nici o dependen funcional parial a unui atribut neprim fa de o cheie a relaiei. Din aceast definiie rezult c, dac orice cheie a unei relaii este format dintr-un singur atribut, relaia este n FN2. Acest lucru este evident, deoarece orice dependen funcional fa de un atribut simplu este o dependen funcional total. De asemenea, este evident faptul c o relaie compus din dou atribute este n FN2, deoarece, fie cheia este format din ambele atribute i atunci nu exist atribute neprime, fie cheia este format dintr-unul din atribute iar dependena funcional a celuilalt atribut (care este atribut neprim) fa de cheie este total. Ca exemplu de normalizare n FN2, se va relua relaia AP prezentat la nceputul acestui capitol (fig. 5.4). Schema relaiei este: AP(IdAngajat,Nume, Prenume,Adresa,IdProiect,Ore), iar mulimea dependenelor funcionale FAP stabilite pe baza semnificaiei atributelor este cea specificat deja, adic:
FAP = {IdAngajatNume,IdAngajatPrenume, IdAngajatAdresa,{IdAngajat,IdProiect}Ore} Nume IdAngajat Ore IdProiect a Nume IdAngajat Prenume Adresa b c Ore PK IdAngajat IdProiect Prenume Adresa

PK

Fig. 5.4. a - Dependene funcionale n relaia AP (AP nu este n FN2); b, c -descompunerea relaiei AP n relaiile A i P. Cheia primar este {IdAngajat,IdProiect} i se poate deduce din mulimea dependenelor funcionale. Aceast relaie este n FN1, deoarece toate atributele iau valori atomice i scalare. Atributele prime sunt IdAngajat, IdProiect iar atributele neprime sunt Nume,Prenume,Adresa,Ore. Pentru a verifica dac relaia este n FN2 trebuie s fie testat tipul dependenei funcionale (total sau parial) a fiecrui atribut neprim fa de cheia primar (care este singura cheie a relaiei n acest exemplu). Se va testa pentru nceput tipul dependenei funcionale a atributului Nume fa de cheia primar a relaiei, adic {IdAngajat,IdProiect}Nume. Aceast dependen exist n virtutea proprietii cheii primare. De altfel, ea se poate deduce din dependenele funcionale ale relaiei, prin aplicarea regulilor de inferen ale lui Armstrong. Conform proprietii de reflexivitate, exist dependena funcional {IdAngajat,IdProiect}IdAngajat, i aplicnd regula de tranzitivitate ntre aceast dependen funcional i dependena funcional IdAngajatNume, rezult {IdAngajat,IdProiect}Nume. Dependena funcional {IdAngajat,IdProiect}Nume este parial, datorit faptului c submulimea {IdAngajat} a atributului compus cheie primar determin funcional atributul Nume: IdAngajatNume. Rezult c relaia AP nu este n FN2. Redundana datelor i anomaliile de actualizare pe care acestea le produc au fost descrise la nceputul capitolului. Tot n aceast parte s-a artat c relaia AP se poate descompune n relaiile A(IdAngajat,Nume,Prenume,Adresa) i P(IdAngajat,IdProiect,Ore), care nu mai prezint redundan a datelor i anomalii de actualizare a tuplurilor. Pentru a determina proprietile acestei descompuneri se studiaz cele dou relaii rezultate A i P. Mulimea dependenelor funcionale din relaia A este FA=A(FAP)={IdAngajatNume, IdAngajatPrenume,IdAngajatAdresa}, din care se deduce cheia primar IdAngajat. n toate dependenele funcionale din FA atributele neprime Nume,Prenume,Adresa sunt total dependente fa de cheia primar a relaiei, deci relaia A este n FN2.

Mulimea dependenelor funcionale din relaia P este FP = P(FAP) = {{IdAngajat,IdProiect} Ore}, din care se deduce cheia primar {IdAngajat,IdProiect}. n dependena funcional din FP atributul neprim Ore este total dependent fa de cheia primar a relaiei, deci relaia P este n FN2. n secinile anterioare s-a demonstrat c descompunerea relaiei AP n relaiile A i P are proprietatea de conservare a informaiei (seciunea 5.2.2.1) i proprietatea de conservare a dependenelor funcionale (seciunea 5.2.2.2), aadar aceast descompunere este o descompunere reversibil n relaii FN2.

5.2.5 A TREIA FORM NORMAL A RELAIILOR (FN3)

O relaie este normalizat n a treia form normal (FN3) n raport cu o mulime de dependene funcionale F dac este n FN2 i dac n F+ nu exist nici o dependen funcional netrivial a unui atribut neprim fa de alt atribut neprim al relaiei. Orice relaie format din dou atribute este n FN3 deoarece ea se afl n FN2 (s-a demonstrat n seciunea precedent), i nu poate exista nici un atribut neprim care s determine funcional un alt atribut neprim, deoarece o relaie cu dou atribute nu poate avea dect cel mult un atribut neprim. Ca exemplu de normalizare a unei relaii n a treia form normal, se consider schema relaiei AFS(IdAngajat,Nume,Prenume,Adresa,Func-tie,Salariu), cu mulimea dependenelor funcionale FAFS = {IdAngajat Nume, IdAngajatPrenume, IdAngajatFunctie, FunctieSalariu} (fig. 5.5). Cheia primar a relaiei este atributul IdAngajat, i ea poate fi dedus din mulimea FAFS a dependenelor funcionale. Se consider c fiecare atribut ia numai valori atomice i scalare, deci relaia este n FN1. Primele patru dependene funcionale sunt dependenele funcionale totale ale unor atribute neprime fa de cheia primar a relaiei, deci relaia este n FN2. Dependena funcional (FunctieSalariu) semnific faptul c n instituia respectiv toi salariaii cu aceeai funcie au acelai salariu (adic funcia determin salariul, ceea ce este plauzibil). Aceast dependen funcional a atributului neprim Salariu fa de alt atribut neprim (Functie), arat c relaia nu este n a treia form normal (FN3).
Nume Nume Prenume Prenume IdAngajat Adresa Functie Functie b Salariu a Functie c Salariu IdAngajat Adresa

Fig. 5.5. a- Dependenele funcionale ale relaiei AFS (AFS nu este n FN3); b, c - descompunerea relaiei AFS n relaiei AF i FS. Chiar dac relaia AFS este n FN2, n aceasta nc mai exist redundan a datelor, deoarece valoarea salariului corespunztor unei funcii se nregistreaz de mai multe ori, pentru fiecare salariat care deine acea funcie. Aceast redundan provoac anomalii de inserare, tergere i actualizare a tuplurilor. De exemplu, nu se poate nregistra valoarea salariului corespunztor unei anumite funcii, dac nu se nregistreaz cel puin un salariat cu acea funcie. Aceasta este anomalia de inserare. Ca anomalie de tergere, se poate observa c, dac se terg tuplurile corespunztoare tuturor salariailor care dein o anumit funcie, atunci se pierde informaia referitoare la salariul corespunztor funciei respective. Anomalii de actualizare apar atunci cnd se actualizeaz valoarea salariului unui angajat: dac se modific salariul fr s se modifice corespunztor i funcia, atunci pot exista n relaie dou sau mai multe tupluri care au aceeai valoare a atributului Functie, dar valori diferite ale atributului Salariu, deci nu este respectat dependena funcional FunctieSalariu. Astfel de redundane i anomaliile de actualizare pe care le provoac se pot elimina dac se descompune relaia n dou (sau mai multe) relaii, care s nu conin date redundante. Relaia AFS se poate descompune n relaiile AF(IdAngajat,Nume, Prenume,Adresa,Functie) i FS(Functie,Salariu). Se poate verifica uor c fiecare din aceste relaii se afl n FN3.

10

Dependenele funcionale ale relaiei AF reprezint proiecia dependenelor funcionale date iniial (FAFS) pe relaia AF: FAF = AF(FAFS)= {IdAngajatNume,IdAngajatPrenume,IdAngajatFunctie}. Cheia primar a relaiei AF este IdAngajat, i se poate deduce uor din dependenele funcionale ale relaiei AF (FAF). Se observ c toate dependenele funcionale ale relaiei AF determinate de cheia primar sunt totale i c nu exist nici o dependen a unui atribut neprim fa de alt atribut neprim, deci relaia AF este n FN3. Dependenele funcionale ale relaiei FS reprezint proiecia dependenelor funcionale date iniial (FAFS), pe relaia FS: FFS = FS(FAFS)={FunctieSalariu}. Cheia primar a relaiei este atributul Functie i se deduce cu uurin din mulimea FFS a dependenelor funcionale ale acestei relaii. Singura dependen funcional a relaiei FS este o dependen funcional total determinat de cheia primar a relaiei, deci relaia FS este n FN3. Pentru verificarea proprietii de jonciune fr pierdere de informaie se calculeaz AF FS = {Functie} i FS AF = {Salariu}. Deoarece dependena funcional (FunctieSalariu) FAFS, rezult (conform teoremei lui Ullman) c descompunerea relaiei AFS n relaiile AF i FS este o descompunere fr pierdere de informaie la jonciune. Pentru verificarea conservrii dependenelor funcionale, se calculeaz mai nti reuniunea dependenelor funcionale ale relaiilor AF i FS:
FAF FFS = {IdAngajatNume,IdAngajatPrenume, IdAngajatFunctie,FunctieSalariu}

Se observ c FAFS = FAF FFS, deci descompunerea realizat conserv dependenele funcionale stabilite iniial. Aadar, descompunerea relaiei AFS n relaiile AF i FS are att proprietatea de conservare a informaiei ct i proprietatea de conservare a dependenelor funcionale, deci este o descompunere reversibil. S-a demonstrat c orice schem de relaie poate fi descompus reversibil n scheme de relaii FN3 i exist un astfel de algoritm de descompunere.

5.2.6 FORMA NORMAL BOYCE-CODD (FNBC)

O relaie cu schema R este n forma normal Boyce-Codd (FNBC) n raport cu o mulime F de dependene funcionale dac este n FN1 i dac, pentru orice dependen funcional netrivial XY din F+, X este o cheie a relaiei R. Se poate observa asemnarea dintre formele normale FN3 i FNBC, ambele impunnd condiia ca atributul care determin funcional alte atribute s fie o cheie a relaiei. Forma normal Boyce-Codd este mai restrictiv dect FN3, deoarece n FNBC se impune aceast condiie tuturor atributelor, prime sau neprime, pe ct vreme n FN3 condiia se impune numai atributelor neprime. Este evident faptul c o relaie n FNBC este, de asemenea n FN3, dar o relaie n FN3 poate s fie sau nu n FNBC. Orice relaie format din dou atribute este n FNBC. Explicaia este similar cu explicaia dat pentru faptul c orice relaie format din dou atribute este n FN2 sau n FN3.

5.2.7 ALGORITMI DE DESCOMPUNERE A RELAIILOR

n general, scopul normalizrii este acela de a obine relaii ntr-o form de normalizare ct mai avansat, care elimin toate sau majoritatea anomaliilor de actualizare. Orice relaie se poate descompune n relaii FN2, FN3 sau FNBC fr pierdere de informaie la jonciune cu ajutorul unui algoritm care este prezentat i demonstrat n continuare. Dei acest algoritm nu garanteaz conservarea dependenelor funcionale, n multe situaii este posibil ca s se obin o descompunere care s prezinte i aceast proprietate. O descompunere care s asigure att conservarea informaiei ct i a dependenelor funcionale nu poate garanta dect obinerea unor relaii n FN3 i un astfel de algoritm (prezentat in manual). n multe situaii, cu acest algoritm se pot obine chiar relaii FNBC, dar forma normal garantat este doar FN3.

5.2.8 VERIFICAREA I IMPUNEREA CONSTRNGERILOR EXPLICITE

Analiza normalizrii relaiilor trebuie s fie realizat pentru orice proiect de baze de date, pentru a asigura funcionarea corect a acesteia. Dup ce se decide forma normal cea mai potrivita a unei relaii, este necesar s se prevad procedurile de verificare a tuturor constrngerilor explicite rmase. Dac relaia se pstreaz ntr-o form de normalizare mai redus, atunci trebuie s se prevad proceduri de verificare i impunere a dependenelor de date care nu sunt determinate de cheile relaiei (constrngeri explicite). Dac prin descopmunerea unei relaii se pierde o dependen funcional, aceasta poate fi impus explicit printr-o procedur stocat sau o funcie n programul de aplicaie, care execut jonciunea ntre relaiile rezultate i impune constrngerea respectiv.

11

5.3

DEPENDENE MULTIVALORICE

O dependen multivaloric - DMV- (multivalued dependency) XY specificat pe o relaie cu schema R = {X,Y,Z} stabilete urmtoarele constrngeri pe care trebuie s le respecte orice stare r a relaiei R: dac exist dou tupluri t1 i t2 n r astfel ca t1[X] = t2[X]= x, atunci vor exista i tuplurile t3 i t4 cu urmtoarele proprieti: t3[X] = t4[X] = t1[X] = t2[X] = x; t3[Y] = t1[Y] = y1 i t4[Y] = t2[Y] = y2 ; t3[Z] = t2[Z] = z2 i t4[Z] = t1[Z] = z1 . Datorit simetriei egalitilor de mai sus, se poate spune c, dac ntr-o relaie R exist dependena multivaloric XY, atunci exist i dependena XZ, unde Z = R(XY). Definiia de mai sus arat c, fiind dat o valoare particular a atributului X, mulimea de valori ale lui Y determinate de aceast valoare a lui X este complet determinat numai de X i nu depinde de valorile atributelor rmase (Z) ale relaiei. De aici rezult c, atunci cnd dou tupluri au valori distincte ale atributului Y dar aceeai valoare a atributului X, aceste valori ale lui Y trebuie s fie repetate pentru orice valoare distinct a lui Z care apare pentru aceast valoare a lui X. O relaie cu schema R este n a patra form normal (FN4) n raport cu o mulime F de dependene funcionale i multivalorice dac este n FN1 i dac, pentru orice dependen multivaloric netrivial XY din F+, X este cheie a relaiei R. Se poate observa asemnarea acestei definiii cu definiia FNBC: pentru FNBC se impun restricii dependenelor funcionale, iar pentru FN4 se impun restricii dependenelor multivalorice. Dar, dat fiind c o dependen funcional este un caz particular al unei dependene multivalorice, dac o schem de relaie respect condiia de FN4, atunci nseamn c ea respect i condiia de FNBC. Restriciile impuse se pot rezuma la faptul c ntr-o relaie nu trebuie s existe dect dependene determinate de chei ale relaiei.

5.4

DEPENDENE DE JONCIUNE I A CINCEA FORM NORMAL

Teorema lui Ullman, ca i generalizarea acesteia pentru dependenele multivalorice, precizeaz condiiile de descompunere fr pierdere de informaie la jonciune a unei relaii R n dou relaii R1 i R2. Exist totui situaii n care nu se poate efectua descompunerea fr pierdere de informaie la jonciune a unei relaii n dou relaii, dar se poate efectua n trei sau mai multe relaii. Astfel de cazuri sunt studiate pe baza dependenelor de jonciune i a celei de-a cincea forme normale (FN5). Este de reinut c astfel de cazuri sunt foarte rare i, n acelai timp, foarte dificil de studiat. Dependen de jonciune (join dependency). Fie o relaie cu schema R i R1,R2,...Rk submulimi de atribute ale mulimii R, unde R1 R2 ... Rk = R. Se spune c exist o dependen de jonciune pe R, notat *(R1,R2,...Rk), dac i numai dac orice stare r a relaiei R este egal cu jonciunea proieciilor relaiei pe submulimile R1,R2,..Rk, adic r = R1(r)>< R2(r)...>< Rk(r). Cu alte cuvinte, *(R1,R2,...Rk) este o dependen de jonciune pe R dac i numai dac descompunerea lui R n proieciile pe R1,R2,...Rk este fr pierdere de informaie. Se poate spune c relaia R este k-decompozabil fr pierdere de informaie dac exist o dependen de jonciune *(R1,R2,...Rk). Cazul k = 1 reprezint o dependen de jonciune trivial, deoarece o astfel de descompunere este posibil pentru orice schem de relaie i nu reprezint nici o constrngere asupra relaiei. Cazul k = 2 al unei dependene de jonciune este o dependen multivaloric. ntr-adevr, s-a demonstrat c o relaie n care exist o dependen multivaloric se poate descompune fr pierdere de informaie n dou relaii, deci o dependen multivaloric ndeplinete condiia de dependen de jonciune cu k = 2. Cu alte cuvinte, o dependen multivaloric XY n relaia R reprezint o dependen de jonciune *(XY,XZ), unde Z = R(X Y). Pentru cazul k > 2 dependenele de jonciune nu mai sunt echivalente cu dependenele multivalorice i, din nefericire, dependenele de jonciune sunt mult mai dificil de identificat i nici nu exist reguli de deducere (inferen) care s genereze toate dependenele de jonciune pornind de la o mulime dat. Datorit acestor aspecte, analiza dependenelor de jonciune are un pronunat caracter intuitiv. Aa cum o dependen multivaloric permite reprezentarea n aceeai relaie a dou asocieri independente, o dependen de jonciune permite reprezentarea n aceeai relaie a unui numr de k asocieri independente (k > 2).

12

A cincea form normal (FN5). O relaie cu schema R este n a cincea form normal (FN5) n raport cu o mulime F de dependene funcionale, multivalorice sau de jonciune dac este n FN1 i dac, pentru orice dependen de jonciune *(R1,R2,... Ri,...Rk) din F+, Ri (unde 1 i k) este o cheie a relaiei R. Avnd n vedere faptul c o dependen multivaloric este un caz special de dependen de jonciune, iar o dependen funcional este un caz special de dependen multivaloric, se poate afirma c o relaie care este n FN5, este implicit n FN4, deci i n FNBC, .a.m.d. Se poate observa c orice relaie poate fi transformat n relaii FN5 printr-o descompunere fr pierdere de informaie.

5.5

DECIZII DE NORMALIZARE A RELAIILOR

La proiectarea unei baze de date, proiectantul definete schemele relaiilor i constrngerile de integritate care trebuie s fie satisfcute de orice stare a relaiilor (constrngeri de domeniu, constrngeri de tuplu, constrngeri de integritate referenial, dependene de date, aseriuni). Normalizarea relaiilor are ca scop transformarea relaiilor definite iniial n alte relaii, astfel nct toate (sau majoritatea) dependenele de date impuse s fie pstrate, dar ele s fie determinate de chei ale relaiilor nou obinute. Acest deziderat al operaiei de normalizare provine din faptul c dependenele fa de cheile relaiei sunt constrngeri implicite care nu produc redundan a datelor, nici anomalii de actualizare i sunt verificate automat de SGBD atunci cnd relaia este actualizat, n timp ce dependenele care nu sunt determinate de chei sunt constrngeri explicite, care produc redundana datelor i anomalii de actualizare. Aceste din urm dependene (care nu sunt determinate de cheile relaiei) nu sunt verificate automat de SGBD i, pentru evitarea unora din anomaliile produse, sunt necesare proceduri speciale de calcul (triggere, proceduri stocate sau funcii n programele de aplicaii). Normalizarea relaiilor se realizeaz prin descompunerea acestora i la fiecare pas de descompunere trebuie s se verifice conservarea informaiei i conservarea dependenelor de date. Descompunerile care nu conserv informaia sunt inacceptabile, dar se pot admite descompuneri care nu conserv dependenele de date. Dac se efectueaz o descompunere care nu conserv dependenele funcionale, atunci pentru fiecare dependen pierdut trebuie s se prevad proceduri care s verifice i s impun constrngerile prevzute de aceasta. Dac o relaie se pstreaz ntr-o form de normalizare mai redus, atunci trebuie s se prevad proceduri de verificare a dependenelor de date care nu sunt determinate de chei ale relaiei. Normalizarea relaiilor asigur un proiect al bazei de date mai concis i mai portabil i, de aceea, ca regul general, se consider c a normaliza este avantajos, chiar dac normalizarea n sine nu este o garanie c s-a realizat cel mai bun model al realitii modelate. Mai mult, cu ct nivelul de normalizare crete, cu att se obin mai multe relaii cu grad mai mic (cu numr mai mic de atribute) i pentru realizarea fiecrei interogri sunt necesare mai multe operaii de jonciune, ceea ce face ca timpul de execuie a interogrilor s creasc. n general, se recomand ca relaiile asupra crora se efectueaz operaii de actualizare frecvente s fie normalizate ntr-o form normal ct mai avansat, iar relaiile asupra crora se efectueaz interogri frecvente pot fi pstrate ntr-o form de normalizare mai redus. O astfel de soluie, de a pstra (sau de a aduce) unele relaii ntr-o form de normalizare mai redus se numete denormalizare, i se efectueaz cu scopul de a obine performane ct mai ridicate la execuia unor interogri. Proiectarea bazelor de date pornind de la diagrama Entitate-Asociere conduce, n general, la relaii normalizate, deoarece: Relaiile corespunztoare mulimilor de entiti sunt, de regul, relaii normalizate, dat fiind c toate atributele descriu tipul de entitate respectiv. Relaiile de asociere binar, care conin dou chei strine care refer cheile primare din cele dou relaii pe care le asociaz, rezult, de asemenea, ca relaii normalizate. Relaiile care modeleaz asocierile multiple pot s rezulte nenormalizate, aa cum s-a putut observa din ultimele dou seciuni (5.3 i 5.4), i necesit operaii de normalizare suplimentare.

Aspectele teoretice i exemplele prezentate n acest capitol au scopul de a convinge proiectanii i programatorii din domeniul bazelor de date c este practic imposibil s se obin o funcionare corect a unui sistem de baze de date fr ca s se fac analiza normalizrii relaiilor. Fr analiza normalizrii poate exista oricnd redundan a datelor care, mai devreme sau mai trziu, se va manifesta ca o inconsisten a datelor, a crei cauz este greu de identificat i de localizat.

13

6. GESTIUNEA TRANZACIILOR I REFACEREA BAZELOR DE DATE

n mod obinuit, un sistem SGBD deservete mai muli utilizatori, care acceseaz concurent datele din tabele. Accesul concurent al utilizatorilor este asigurat prin capacitatea de multiprogramare a sistemului de operare al calculatorului gazd, care permite execuia concurent a mai multor procese. Execuia concurent a mai multor procese poate avea loc att ntr-un sistem uniprocesor, prin partajarea (mprirea) timpului de execuie al procesorului ntre mai multe procese, ct i ntr-un sistem multiprocesor n care mai multe procese pot fi executate n mod real simultan, pe mai multe procesoare ale sistemului. Indiferent de numrul de procesoare ale sistemului, accesul concurent al mai multor utilizatori la datele memorate n tabelele unei baze de date necesit tehnici de meninere a consistenei (corectitudinii) i a siguranei datelor memorate. Meninerea consistenei i a siguranei bazelor de date n situaia n care mai muli utilizatori le acceseaz concurent i n condiiile n care pot s apar erori de funcionare (defecte) ale sistemului de calcul se bazeaz pe conceptul de tranzacie care va fi prezentat n seciunea urmtoare.

6.1

TRANZACII

O tranzacie (transaction) este o unitate logic de prelucrare indivizibil (atomic) a datelor unei baze de date prin care se asigur consistena acesteia. n principiu, orice execuie a unui program care acceseaz o baz de date poate fi considerat o tranzacie, dac baza de date este ntr-o stare consistent att nainte ct i dup execuie. O tranzacie trebuie s asigure consistena bazei de date indiferent dac a fost executat individual sau concurent cu alte tranzacii precum i n condiiile n care au aprut defecte ale sistemului hardware n cursul execuiei tranzaciei. Se va studia problema consistenei bazelor de date pe exemplul unui sistem de rezervare a locurilor la curse aeriene. Un numr mare de ageni de vnzri vor accesa relaiile care memoreaz datele de rezervare i vnzare a biletelor de avion. De exemplu, vor exista relaiile:
CURSE(IdCursa,AeroportPlecare,AeroportSosire,Data, NrLocuriLibere) PASAGERI(IdPasager,Nume,Prenume,Adresa, NrCreditCard) REZERVARI(IdRezervare,IdPasager,IdCursa) FACTURI(IdFactura,IdPasager,DataFacturarii,Pret)

Cheile primare i strine au fost marcate conform conveniilor care au mai fost folosite i n seciunile precedente, iar semnificaia atributelor acestor relaii este destul de clar exprimat chiar prin numele lor. Detalii ca: tipul locului rezervat (turist, business, etc), reduceri de plat a biletului (bilet copil, etc.), mai multe rezervri fcute de acelai client, intervalul de timp dintre rezervare i cumprarea biletului, posibilitatea ca o rezervare s fie anulat, etc., au fost ignorate, dat fiind c nu modific fondul problemei de consisten a bazei de date. Atunci cnd un agent de vnzri rezerv un loc la o curs i vinde biletul corespunztor, se efectueaz mai multe operaii: 1. 2. Se insereaz o linie nou n tabelul PASAGERI, care conine datele pasagerului. Dac exist locuri libere la cursa dorit, atunci se face propriu-zis rezervarea, prin inserarea unei linii noi n tabelul REZERVARI, linie care conine numrul de identificare al pasagerului, numrul de identificare al cursei i (eventual) numrul locului rezervat; altfel, rezervarea este imposibil. La achitarea biletului se insereaz o linie n tabelul FACTURI. Acest nregistrare este folosit pentru a tipri o factur, care va fi folosit pentru plata n numerar sau va fi trimis companiei de cri de credit. Se emite (tiprete) biletul (pornind de la datele din rezervare i factura corespunztoare).

3.

4.

Dac sistemul se defecteaz dup ce s-a executat pasul 2, s-a fcut o rezervare, dar biletul nu a fost facturat i nici emis. Mai ru, dac defeciunea are loc dup ce s-a executat pasul 3, atunci clientului i se trimite factura, dar el nu a primit biletul. Astfel de situaii sunt, bineneles, inacceptabile. Chiar dac nu se defecteaz sistemul, pot s apar probleme dac baza de date este accesat concurent de mai muli utilizatori. De exemplu, dac doi ageni de vnzri atribuie acelai loc la doi pasageri diferii, atunci vor fi probleme la mbarcarea pasagerilor. Dac toate aciunile aferente unei rezervri ar fi grupate ca o operaie indivizibil (atomic), o parte din problemele artate mai sus ar disprea.

O operaie indivizibil de acces la baza de date este numit tranzacie i ea fie execut cu succes toate aciunile i se termin cu o validare a modificrilor efectuate asupra bazei de date (commit), fie nu poate efectua (din diferite motive) toate aciunile i este abandonat i anulat (abort, rollback). n cazul n care o tranzacie a efectuat cu succes toate aciunile i este validat, n momentul validrii toate modificrile efectute asupra bazei de date devin permanente (durabile), vor fi vizibile altor tranzacii i nu mai pot fi anulate. Pn n momentul validrii, modificrile efectuate de tranzacie au un caracter provizoriu, nu sunt vizibile altor tranzacii i pot fi oricnd revocate (anulate). n cazul abandonrii unei tranzacii, execuia acesteia este oprit i efectele tuturor aciunilor executate pn n momentul abandonrii sunt anulate, astfel nct baza de date este adus n starea de dinaintea lansrii tranzaciei.

6.1.1

ANOMALII DE EXECUIE CONCURENTA A TRANZACIILOR

Pentru studierea controlului concurenei i al refacerii datelor se vor aborda operaiile asupra bazei de date la nivel de articol de date (data item) i bloc de memorare pe disc. La acest nivel, operaiile de acces la baza de date care pot s apar n cursul unei tranzacii sunt: read(X): citete articolul X din baza de date ntr-o variabil a programului; pentru simplificarea notaiilor se va considera c variabila n care se citete articolul X este notat, de asemenea, cu X. write(X): scrie variabila de program X n articolul X al bazei de date. Unitatea de transfer a datelor ntre discul magnetic i memoria principal a sistemului este un bloc, care corespunde unui sector de pe disc. n general, un articol de date este un cmp care memoreaz valoarea unui atribut dintr-o nregistrare (tuplu), dar poate fi o ntreag nregistrare sau chiar un bloc ntreg. Tranzaciile lansate de diferii utilizatori se pot executa concurent i este posibil s actualizeze aceleai articole ale bazei de date. Dac execuia concurent a tranzaciilor este necontrolat, este posibil ca baza de date s ajung ntr-o stare inconsistent (incorect), chiar dac fiecare tranzacie n parte este un program corect, a fost executat corect i nu au aprut defecte de funcionare ale sistemului. Actualizare pierdut (lost update). n figura 6.1, a este prezentat una din cele cteva situaii posibile de inconsisten a datelor memorate atunci cnd dou sau mai multe tranzacii sunt executate concurent, dar ntrun mod necontrolat. Cele dou tranzacii T1 i T2 actualizeaz acelai articol (X) al bazei de date i se execut concurent prin partajarea (i ntreeserea) timpului de execuie al procesorului.
Timp T1 read(X) X=XN read(X) X=X+M write(X) read(Y) write(X) Y=Y+N write(Y) read(Y) abort T2 T1 read(X) X=XN write(X) read(X) X=X+M write(X) T2

a b Fig. 6.1. Inconsistena datelor provenit din execuia concurent necontrolat a dou tranzacii: a - actualizare pierdut; b - citire improprie. Pentru modul de ntreesere n timp a celor dou tranzacii prezentate n figura 6.1, a valoarea memorat n articolul X n baza de date este X+M, n locul valorii corecte XN+M (X fiind valoarea iniial a articolului, nainte de lansarea tranzaciilor). Actualizarea efectuat de tranzacia T1 a fost pierdut, dat fiind c tranzacia T2 folosete valoarea iniial a articolului X, nainte ca valoarea calculat de T1(XN) s fie memorat n baza de date. Acest tip de funcionare concurent incorect se numete actualizare pierdut. Citire improprie (dirty read). n figura 6.1, b este exemplificat o alt situaie de inconsisten a datelor, cunoscut sub denumirea de citire improprie - dirty read, sau dependen nevalidat - uncommited dependence sau actualizare temporar - temporary update. Aceast anomalie poate s apar atunci cnd una din tranzacii este abandonat, iar alt tranzacie concurent a utilizat articolele modificate, nainte de readucerea acestora la valoarea iniial. n acest exemplu tranzacia T1 a modificat articolul X, dup care a fost abandonat dintr-o cauz oarecare, dar tranzacia T2 a citit i a utilizat articolul modificat X, nainte ca acesta s fie readus la valoarea sa iniial. Rezultatul celor dou tranzacii este valoarea X N + M, n locul valorii corecte, X + M.

Citire irepetabil (nonrepetable read). O alt problem de inconsisten a datelor, cunoscut sub numele de citire irepetabil (nonrepetable read, sau analiz inconsistent - inconsistent analysis), poate s apar dac o tranzacie T citete un articol de dou ori, iar ntre cele dou citiri, o alt tranzacie (T) a modificat chiar acel articol. n aceast situaie tranzacia T primete dou valori diferite ale aceluiai articol. Citire fantom (phantom read). Asemntoare problemei citirii irepetabile este problema citirii fantom, care apare atunci cnd o tranzacie prelucreaz un set de linii rezultat al unei interogri; dac n timpul acestei prelucrri o alt tranzacie a inserat sau a ters o linie care satisface condiia interogrii respective, atunci pot s apar sau s dispar linii din mulimea de linii rezultat, comportare asemntoare cu aparia sau dispariia fantomelor. Diferena dintre citirea fantom i citirea irepetabil este aceea c citirea fantom apare dac tranzaciile concurente modific numrul de linii utilizate de tranzacia curent (prin instruciuni INSERT sau DELETE), pe ct vreme citirea irepetabil apare dac tranzaciile concurente modific valorile din liniile existente i prelucrate de tranzacia curent (prin instruciuni UPDATE). Astfel de anomalii, care pot s apar la execuia concurent necontrolat a dou sau mai mai multor tranzacii, evideniaz necesitatea controlului concurenei n bazele de date. Consistena datelor memorate n baza de date trebuie s fie asigurat chiar n condiiile n care o tranzacie nu poate fi terminat cu succes, datorit apariiei unei erori de funcionare.

6.1.2

PROPRIETILE TRANZACIILOR

Cele mai importante proprieti ale tranzaciilor sunt identificate n literatur prin acronimul ACID: atomicitate, consisten, izolare, durabilitate. Atomicitatea (atomicity) este proprietatea unei tranzacii de a reprezenta o unitate de execuie indivizibil, adic de a executa totul sau nimic. Dac o tranzacie este ntrerupt dintr-o cauz oarecare, atunci sistemul SGBD va asigura, dup eliminarea cauzei care a ntrerupt executarea tranzaciei, fie completarea i validarea tranzaciei, fie abandonarea tranzaciei i anularea tuturor efectelor aciunilor efectuate de tranzacie pn n momentul ntreruperii. Consistena (consistency) unei tranzacii nseamn proprietatea acesteia de a efectua modificri corecte ale bazei de date. Cu alte cuvinte, o tranzacie transform baza de date dintr-o stare consistent n alt stare consistent. n strile intermediare prin care trece o baz de date n cursul unei tranzacii, este posibil s existe unele inconsistene, dar starea final n care ajunge baza de date dup execuia unei tranzacii trebuie s fie consistent. Starea unei baze de date este consistent dac respect toate constrngerile de integritate implicite sau explicite. Sistemul SGBD nu verific consistena bazei de date dup fiecare operaie (tranzacie), ci este sarcina proiectanilor aplicaiilor de baze de date ca operaiile prevzute n tranzacii s produc o stare consistent a bazei de date. Izolarea (isolation) este proprietatea unei tranzacii de a face vizibile modificrile efectuate numai dup ce a fost validat (committed). Dac n acest timp sunt executate alte tranzacii concurente, acestea nu vd modificrile pariale efectuate de tranzacia respectiv pn n momentul validrii tranzaciei. Proprietatea de izolare a tranzaciilor este important deoarece elimin fenomenul de abandonare n cascad a tranzaciilor. Dac rezultatele pariale ale unei tranzacii sunt vizibile altor tranzacii nainte de validarea acesteia i dac se ntmpl ca aceast tranzacie s fie abandonat i anulat (rollback), atunci toate tranzaciile care au accesat rezultatele pariale ale acesteia vor trebui s fie anulate; aceste operaii de anulare pot produce, la rndul lor alte anulri, .a.m.d. Acest fenomen de anulare n cascad creeaz un efect de domino. Izolarea este impus prin metode de control al concurenei, pe diferite niveluri de izolare. Durabilitarea (durability, sau permanena - permanency) este proprietatea prin care, dup validarea unei tranzacii, modificrile efectuate de aceasta n baza de date nu vor mai fi pierdute datorit unor defectri ulterioare a sistemului. Proprietatea de durabilitate este asigurat prin metode de refacere (recovery) ale sistemului SGBD.

6.1.3

STRILE TRANZACIILOR

Dac operaiile de acces la baza de date ale unei tranzacii sunt numai operaii de citire, acea tranzacie se numete tranzacie de citire (read-only transaction) i controlul concurenei unor astfel de tranzacii este mult mai simplu. n cele ce urmeaz se va studia cazul general, al tranzaciilor de citire i scriere (read-write transactions) care efectueaz att regsiri de date (prin operaii de citire) ct i actualizri (prin operaii de scriere), i care necesit tehnici de control al concurenei mult mai complexe. Operaiile efectuate de o tranzacie i nregistrate de administratorul de refacere (recovery manager), pentru a asigura cele patru proprieti importante ale tranzaciilor (ACID), sunt urmtoarele:

1. 2. 3.

begin: aceast operaie marcheaz nceputul execuiei unei tranzacii. read sau write: sunt operaii de citire sau scriere a articolelor n baza de date, executate n cadrul unei tranzacii. end: aceast operaie marcheaz terminarea operaiilor de scriere sau citire din baza de date, ceea ce nseamn c tranzacia se poate termina; totui, este posibil s fie necesare unele operaii de verificare nainte de validarea (commit) tranzaciei. commit: aceast operaie semnaleaz terminarea cu succes a tranzaciei, validarea tuturor modificrilor efectuate n baza de date i vizibilitatea modificrilor efectuate pentru alte tranzacii; din acest moment, modificrile efectuate nu mai pot fi anulate, nici pierdute printr-o defectare ulterioar a sistemului (bineneles, dac mecanismul de refacere al SGBD-ului funcioneaz corect). rollback (sau abort): aceast operaie semnaleaz faptul c tranzacia a fost abandonat i c orice efect pe care tranzacia l-a avut asupra bazei de date trebuie s fie anulat (printr-o rulare napoi a operaiilor). undo: aceast operaie este similar operaiei rollback, dar se aplic unei singure operaii, nu unei ntregi tranzacii. redo: aceast operaie specific faptul c unele operaii ale unei tranzacii trebuie s fie executate din nou pentru a se putea valida ntreaga tranzacie.

4.

5.

6. 7.

Ultimele dou operaii sunt necesare numai n anumite tehnici de refacere. n figura 6.2 este reprezentat diagrama de stare a unei tranzacii folosind limbajul UML, unde fiecare stare are o denumire i fiecare operaie provoac o anumit tranziie ntre stri. n starea ACTIVA se ajunge ca urmare a lansrii unei tranzacii prin operaia begin, iar execuia corect a operaiilor read sau write nu modific aceast stare. Atunci cnd o tranzacie se termin, ea trece n starea PARTIAL VALIDATA n care se efectueaz operaii de verificare impuse de tehnicile (protocoalele) de control al concurenei i de refacere. Dac ambele verificri sunt ndeplinite cu succes, atunci tranzacia este validat (prin execuia unei operaii commit) i trecut n starea VALIDATA; dac una sau ambele condiii nu sunt ndeplinite, tranzacia este trecut n starea ABANDONAT prin execuia operaiei abort. Starea TERMINAT este consecina imediat a atingerii uneia din strile VALIDAT sau ABANDONAT i nu necesit nici o alt operaie pentru efectuarea acestei tranziii. n cursul strii ACTIV, orice tranzacie poate fi abandonat (i trecut n starea ABANDONAT prin execuia unei operaii abort), dac diferite verificri efectuate nu sunt ndeplinite.
read, write begin end PARTIAL VALIDAT abort commit

ACTIV

VALIDAT

abort

ABANDONAT

TERMINAT

Fig. 6.2. Diagrama de stare a unei tranzacii. Pentru refacerea bazei de date n condiiile n care unele tranzacii sunt abandonate sau n care pot aprea defecte de funcionare, sistemul SGBD menine un fiier jurnal, n care memoreaz operaiile efectuate de tranzacii. Fiierul jurnal este memorat pe disc i nu este afectat de diferite erori de execuie, cu excepia unei defectri catastrofice a discului. n plus, fiierul jurnal este salvat periodic pe un suport auxiliar (band magnetic), ca o msur de prevedere pentru astfel de defecte catastrofice. n fiierul jurnal (log file) se nregistreaz operaiile efectuate de fiecare tranzacie, identificat printrun identificator unic (T) generat de sistem. Prima nregistrare referitoare la o tranzacie cu identificatorul T este nregistrarea de start a tranzaciei: [begin,T]. La fiecare operaie write(X) executat de o tranzacie T, n fiierul jurnal se memoreaz o nregistrare de tipul [write,T,X,vechea_valoare,noua_valoare], dac pentru refacerea datelor se

folosesc operaii undo, sau o nregistrare de tipul [write,T,X,noua_ valoare], dac se folosesc operaii redo. Sistemele care nu evit abandonarea n cascad a tranzaciilor nregistreaz n fiierul jurnal i operaiile de citire read(X), printr-o nregistrare de tipul [read,T,X,valoare]. Pentru fiecare tranzacie T, n fiierul jurnal se mai memoreaz starea de terminare: validat (printr-o nregistrare [commit,T] ) sau anulat (printr-o nregistrare[rollback,T]). Dup executarea validrii i nregistrarea ei n fiierul jurnal, efectul tranzaciei este permanent memorat n baza de date. Dac sistemul se defecteaz, la reluarea execuiei dup ndeprtarea defectului, sistemul SGBD va aduce baza de date ntr-o stare consistent prin examinarea fiierului jurnal. Dat fiind c fiierul jurnal conine o nregistrare pentru fiecare operaie de scriere care a modificat valoarea unui articol al bazei de date, este posibil de a anula efectul tuturor operaiilor de scriere efectuate de o tranzacie care a fost lansat dar nu a fost validat, parcurgnd napoi fiierul jurnal i nlocuind valoarea existent a articolului modificat cu vechea valoare, memorat n fiierul jurnal. n cazul abandonrii n cascad, trebuie s fie abandonate i tranzaciile care au citit valori modificate de tranzaciile abandonate.

6.1.4

PLANIFICAREA TRANZACIILOR

O planificare (schedule, sau istorie - history) S a n tranzacii T1,T2,...Ti,...Tn este o ordonare a operaiilor tranzaciilor astfel nct, pentru orice tranzacie Ti care particip n S, operaiile lui Ti n S respect ordinea iniial din Ti. n acelai timp, alte operaii (ale altor tranzacii Tj, unde j i) pot fi ntreesute cu operaii ale tranzaciei Ti. Pentru definirea planificrilor se vor reprezenta operaiile de read, write, commit i abort ale tranzaciilor componente, notate prescurtat cu r, w, c, a, avnd ca subscript identificatorul tranzaciei i ca parametru articolul pe care l-a citit sau scris. De exemplu, planificrile S1 i S2 din figura. 6.1 se pot descrie astfel: S1: r1(X); r2(X); w1(X); r1(Y); w2(X); c2; w1(Y); c1; S2: r1(X); w1(X); r2(X); w2(X); c2; r1(Y); a1; Dou operaii dintr-o planificare sunt conflictuale (conflicting operations) dac aparin unor tranzacii diferite, acceseaz acelai articol i cel puin una dintre operaii este operaie de scriere. De exemplu, n planificarea S1, operaii conflictuale sunt perechile: (r1(X), w2(X)), ( r2(X), w1(X)) i (w1(X), w2(X)). O planificare S a n tranzacii T1,T2,...Ti,...Tn se numete complet dac ndeplinete urmtoarele condiii: 1. 2. 3. Operaiile din S sunt exact toate operaiile celor n tranzacii, inclusiv operaiile de validare sau abandonare, ca operaii finale executate de fiecare dintre cele n tranzacii ale planificrii. Pentru oricare pereche de operaii dintr-o tranzacie Ti, ordinea lor de apariie n S este aceeai cu ordinea de apariie n Ti. Pentru fiecare dou operaii conflictuale, una dintre ele trebuie s fie executat naintea celeilalte.

Aceste condiii permit ca dou operaii care nu sunt conflictuale s poat fi executate oricum n planificarea respectiv, fr s fie necesar s se precizeze care operaie are loc mai nti. O astfel de ordine a operaiilor tranzaciilor unei planificri se numete ordine parial. Totui, ntr-o planificare, trebuie s fie specificat o ordine total (adic s fie precizat care operaie se execut mai nti) pentru orice pereche de operaii conflictuale (condiia 3) i pentru orice pereche de operaii care aparin aceleiai tranzacii (condiia 2).

6.1.5

SERIALIZABILITATEA PLANIFICRILOR

Dac doi utilizatori ai unei baze de date lanseaz (aproape) simultan dou tranzacii T1 i T2 i nu este permis nici o ntreesere ntre operaiile celor dou tranzacii, atunci sunt posibile dou moduri de ordonare a operaiilor celor dou tranzacii: Se execut mai nti toate operaiile tranzaciei T1, urmate de execuia tuturor operaiilor tranzaciei T2. Se execut mai nti toate operaiile tranzaciei T2, urmate de execuia tuturor operaiilor tranzaciei T1.

Astfel de planificri, care nu ntrees operaiile tranzaciilor, ci le execut consecutiv, se numesc planificri seriale. Planificri seriale (serial schedules). O planificare S se numete serial dac pentru orice tranzacie T participant n planificare, toate operaiile lui T se execut consecutiv n S; altfel, planificarea se numete neserial. n figurile 6.3, a i b sunt prezentate cele dou planificri seriale posibile, SA i SB ale celor dou tranzacii T1 i T2 din figura 6.1, a. Cu notaia prescurtat a planificrilor prezentat mai sus, cele dou planificri seriale se pot descrie astfel: SA: r1(X); w1(X); r1(Y); w1(Y); c1; r2(X); w2(X); c2; SB: r2(X); w2(X); c2; r1(X); w1(X); r1(Y); w1(Y); c1; Dac tranzaciile unei planificri seriale sunt independente ntre ele i fiecare tranzacie este corect, atunci planificarea respectiv este corect.
Timp

T1
read(X) X=XN write(X) read(Y) Y=Y+N write(Y)

T2

T1

T2
read(X) X=X+M write(X)

read(X) X=XN write(X) read(Y) Y=Y+N write(Y) b

read(X) X=X+M write(X) a Timp

T1
read(X) X=XN write(X)

T2

T1
read(X) X=XN write(X) read(Y)

T2

read (X) X=X+M write(X) read(Y) Y=Y+N write(Y) c

read (X) X=X+M Y=Y+N write(Y) write(X) d

Fig. 6.3. a, b - Planificri seriale ale tranzaciilor T1 i T2; c, d - Planificri serializabile echivalente cu planificarea serial a. Problema planificrilor seriale este aceea c nu permit ntreeserea operaiilor i concurena tranzaciilor. Dac o tranzacie a unei planificri seriale ateapt un timp oarecare (posibil foarte mare, n cazul execuiei interactive cu operatori umani) rezultatul unei operaii de intrare-ieire, atunci toate operaiile care urmeaz, precum i toate celelalte tranzacii concurente, ateapt, irosind timpul procesorului. De aceea, n general, planificrile seriale nu se pot folosi n cazul sistemelor de baze de date cu utilizatori multipli, i se realizeaz planificri care admit concurena, asigurnd n aceelai timp consistena bazei de date. Astfel de planificri sunt planificrile serializabile. Planificri serializabile (serializable schedules). O planificare a n tranzacii se numte serializabil dac este echivalent cu o planificare serial a celor n tranzacii. Aceast definiie este un alt mod de a spune c o planificare serializabil este o planificare corect, dat fiind c orice planificare serial este corect.

Se pune problema de a defini ce nseamn dou planificri echivalente. Aparent, s-ar putea considera c dou planificri sunt echivalente dac execuia lor produce aceeai stare final a bazei de date. Acest echivalen, numit echivalen privind rezultatul (result equivalence), nu este suficient, dat fiind c dou planificri pot produce n mod accidental aceeai stare final a bazei de date. O definiie mai precis a echivalenei a dou planificri, numit echivalena privind conflictele (conflict equivalence, sau echivalena de ordonare -order equivalence) este urmtoarea: Planificri echivalente din punct de vedere al conflictelor (conflict-equivalent schedules). Dou planificri sunt echivalente din punct de vedere al conflictelor dac oricare pereche de operaii conflictuale se execut n aceeai ordine n cele dou planificri. Dac dou operaii conflictuale se execut n ordine diferit n dou planificri, rezultatele operaiilor efectuate asupra datelor memorate pot fi diferite. n figurile 6.3, c i d sunt prezentate dou planificri echivalente cu planificarea serial SA a celor dou tranzacii T1 i T2; notaia prescurtat a acestor planificri este urmtoarea: SC: r1(X); w1(X); r2(X); w2(X); c2; r1(Y); w1(Y); c1; SD: r1(X); w1(X); r1(Y); r2(X); w1(Y); c1; w2(X); c2; Echivalena a dou planificri se stabilete verificnd ordinea de execuie a operaiilor conflictuale. Se observ c perechile de operaii conflictuale (r1(X), w2(X)), ( w1(X), r2(X)) i (w1(X), w2(X)) se execut exact n aceast ordine n planificrile SA, SC i SD, ceea ce nseamn c planificrile SC i SD sunt echivalente cu planificarea serial SA i sunt, deci, serializabile. Serializabilitatea unei planificri poate fi testat, dar aceast operaie este deosebit de complicat, cu un cost de execuie a algoritmului de testare foarte ridicat i de aceea nu se practic n mod curent. Metodele practice de asigurare a serializabilitii planificrilor i, prin aceasta, a consistenei bazelor de date, se bazeaz pe controlul concurenei tranzaciilor.

6.2

TEHNICI DE CONTROL AL CONCURENEI

Controlul execuiei concurente a mai multor tranzacii este necesar pentru a asigura proprietile de atomicitate, izolare i durabilitate a tranzaciilor i, prin aceasta, consistena datelor memorate. Controlul concurenei se poate realiza prin protocoale (set de reguli) impuse tranzaciilor astfel nct, dac acestea sunt respectate de fiecare tranzacie, orice planificare n care astfel de tranzacii particip este serializabil i, deci, corect. Cele mai utilizate tehnici de control al concurenei sunt cele bazate pe blocarea datelor prin intermediul zvoarelor (locks) i cele bazate pe mrci de timp (timestamps). Protocoalele de control al concurenei sunt implementate de sistemele de gestiune a bazelor de date astfel nct programatorii de aplicaii nu opereaz n mod explicit cu zvoare sau mrci de timp, ci stabilesc opiunile prin care sistemul SGBD adopt anumite tehnici de control al concurenei. Descrierea n continuare a algoritmilor i a operaiilor de execuie a tranzaciilor este o descriere de principiu, prezentat cu scopul nelegerii mecanismelor de baz ale controlului concurenei.

6.2.1 CONTROLUL CONCURENEI PRIN BLOCARE

Controlul concurenei tranzaciilor prin blocare (concurrency control using locking technique) se realizeaz folosind zvoare. Un zvor (lock) este o variabil asociat cu un articol al unei baze de date care descrie starea acelui articol n raport cu operaiile care se pot aplica acelui articol. Pentru un articol X, zvorul care controleaz accesul la acel articol va fi notat L(X). n sistemele de gestiune a bazelor de date se pot utiliza dou tipuri de zvoare, zvoare binare i zvoare cu stri multiple. Un zvor binar (binary lock) poate avea dou stri: liber (sau neblocat - free, unlocked) i ocupat (sau blocat - busy, locked) sau, mai simplu, strile 1 i 0. Asupra unui zvor L(X)se pot executa dou operaii: operaia de blocare, lock(X) i operaia de eliberare, unlock(X). Dac zvorul articolului X este deja blocat (L(X)=0), atunci operaia de blocare lock pune n ateptare tranzacia pn cnd zvorul se elibereaz. Dac zvorul este liber (L(X)=1), atunci tranzacia achiziioneaz zvorul, trecndu-l n starea ocupat, dup care execut operaiile necesare asupra articolului X. Dup terminarea operaiilor asupra acelui articol, tranzacia elibereaz zvorul, prin execuia operaiei unlock. Dac zvorul a fost ocupat, tranzacia ateapt pn ce acesta este eliberat (de o alt tranzacie, care i-a terminat operaiile de acces la acel articol), dup care execut aceeai secven de operaii: blocarea zvorului, execuia operaiilor care acceseaz articolul respectiv i eliberarea zvorului.

Pentru ca, n orice moment de timp, cel mult o tranzacie s dein un anumit zvor, trebuie ca operaia de blocare s fie executat ca operaie indivizibil. Acest cerin este implementat prin instruciuni speciale ale procesorului (de tip TestAndSet(TS)). Se pot preciza urmtoarele reguli (protocolul) pe care trebuie s le urmeze fiecare tranzacie care folosete zvoare binare: 1. O tranzacie T trebuie s lanseze o operaie de blocare a zvorului asignat articolului X (lock(X)), nainte de a efectua orice operaie de citire (read(X)) sau de scriere (write(X)) a articolului X. O tranzacie T trebuie s elibereze zvorul unui articol X (prin operaia unlock(X)) dup ce a efectuat toate operaiile de citire (read(X)) sau de scriere (write(X)) a articolului X. O tranzacie T nu poate cere un zvor pe care l deine deja. O tranzacie T nu poate elibera un zvor pe care nu l deine.

2. 3. 4.

ntre operaia de blocare (lock(X)) lansat de o tranzacie T i operaia de eliberare (unlock(X)) a unui zvor L(X), tranzacia T deine zvorul respectiv. n cazul zvoarelor binare, cel mult o tranzacie poate deine un zvor la un moment dat, i nici o alt tranzacie nu poate accesa articolul respectiv. Se poate spune c zvoarele binare realizeaz un mecanism de excludere mutual, prin care accesul unei tranzacii la un articol (tranzacia care deine zvorul acelui articol) exclude accesul altor tranzacii la acel articol. Dei este foarte general i relativ simplu de utilizat, tehnica zvoarelor binare este prea restrictiv i limiteaz n mod nejustificat concurena n execuia tranzaciilor. De exemplu, mai multe tranzacii pot efectua operaii de citire n mod concurent, fr ca acest lucru s afecteze consistena bazei de date, dar acest lucru este interzis n tehnica zvoarelor binare. De aceea, multe sisteme de gestiune a bazelor de date utilizeaz zvoare cu stri multiple.

6.2.2

CONTROLUL CONCURENEI BAZAT PE MRCI DE TIMP

O marc de timp (timestamp) este un identificator unic al unei tranzacii, creat de sistemul de gestiune a bazei de date, care se bazeaz pe timpul de start al tranzaciei. O marc de timp se poate crea fie folosind valoarea curent a ceasului sistemului de operare, fie folosind un numrtor care este incrementat la fiecare asignare a unei noi mrci, n ordinea de lansare a tranzaciilor. n orice caz, o tranzacie T va avea o marc de timp unic, notat TS(T). Pentru fiecare articol X al bazei de date se definesc dou mrci de timp: read_TS(X) - marca de timp de citire a articolului X; aceasta este cea mai mare marc de timp dintre toate mrcile de timp ale tranzaciilor care au citit articolul X. write_TS(X) - marca de timp de scriere a articolului X; aceasta este cea mai mare marc de timp dintre toate mrcile de timp ale tranzaciilor care au scris n articolul X. Serializabilitatea planificrilor se obine dac se impun anumite condiii ordinii de accesare a articolelor de mai multe tranzacii concurente, n funcie de mrcile de timp ale acestora.

6.3

TEHNICI DE REFACERE A BAZELOR DE DATE

Refacerea unei baze de date dup producerea unui defect (database recovery) nseamn aducerea bazei de date ntr-o stare precedent corect, din care, eventual, se poate reconstrui o nou stare corect i ct mai apropiat de momentul apariiei defectului. Pentru operaiile de refacere se folosete fiierul jurnal, i (sau) o copie de rezerv a bazei de date (database backup) stocat n general pe band magnetic. Dac baza de date nu este distrus fizic, dar a devenit inconsistent datorit unui defect necatastrofic, atunci strategia de refacere const n a anula modificrile care au produs inconsistena (prin operaii undo) sau, uneori, de a executa din nou anumite modificri care s-au pierdut (prin operaii redo). n acest caz nu este necesar copia de rezerv, ci se folosete starea actual a bazei de date i fiierul jurnal. Dac baza de date a fost puternic distrus, datorit unei defectri serioase a discului, atunci se restaureaz starea bazei de date din copia de rezerv, dup care se reconstruiete o stare ct mai actual prin reaplicarea tuturor tranzaciilor validate existente n fiierul jurnal, dac acesta nu a fost deteriorat, sau din ultima copie salvat a fiierului jurnal.

6.4

CONTROLUL TRANZACIILOR

Tehnicile de gestiune a tranzaciilor i de refacere a datelor prezentate n seciunile precedente sunt incluse n componentele sistemelor de gestiune a bazelor de date (administratorul de tranzacii i administratorul de refacere) ntr-o form specific fiecrui SGBD, cu diferite grade de complexitate.

Aplicaiile de baze de date au un control destul de limitat asupra opiunilor de gestiune a tranzaciilor prin intermediul unor comenzi care se bazeaz pe standardul SQL2. n standardul SQL2 sunt prevzute urmtoarele comenzi de specificare a tranzaciilor: SET TRANSACTION optiuni COMMIT [WORK] ROLLBACK [WORK] Comanda SET TRANSACTION stabilete proprietile tranzaciilor i admite urmtoarele opiuni de setare a modului de gestiune a tranzaciilor: Nivelul de izolare a tranzaciilor (ISOLATION LEVEL) cu valorile posibile: READ UNCOMMITTED, READ COMMITTED, REPETABLE READS, SERIALIZABLE. Modul de acces la articole - cu valorile posibile READ ONLY, READ WRITE. Modul de refacere a datelor (SET CONSTRAINTS), cu valorile posibile DEFERRED (refacere amnat) i IMMEDIATE (refacere imediat). Nivelul de izolare reprezint gradul pn la care o tranzacie trebuie s fie izolat de celelalte tranzacii. Izolarea total a tranzaciilor, n care starea bazei de date este consistent n permanen, iar n tranzacii nu apar nici un fel de anomalii, este obinut pe nivelul cel mai nalt de izolare, denumit SERIALIZABLE, care corespunde planificrilor serializabile (echivalente cu planificri seriale ale tranzaciilor). Acest nivel de izolare total micoreaz gradul de concuren a tranzaciilor, i, ori de cte ori este posibil, se admit niveluri de izolare mai sczute, care admit unele anomalii (controlabile) de execuie a tranzaciilor i asigur un grad de concuren mai ridicat. Nivelurile de izolare determin modul n care sistemul de gestiune a bazei de date introduce diferitele mecanisme de control al concurenei (cel mai frecvent zvoare cu stri multiple). De exemplu, pe nivelul READ COMMITTED, sunt prevzute zvoare partajate pentru toate articolele citite, ceea ce mpiedic apariia citirilor improprii, dar aceste zvoare sunt eliberate nainte de terminarea tranzaciei i, de aceea, pot rezulta citiri nerepetabile i citiri fantom (Tabelul 6.1). Tabelul 6.1. Nivelurile de izolare a tranzaciilor n standardul SQL2
Nivelul de izolare READ UNCOMMITTED READ COMMITTED REPETABLE READS SERIALIZABLE Citire improprie DA NU NU NU Citire nerepetabil DA DA NU NU Citire fantom DA DA DA NU

Pe orice nivel de izolare, inclusiv pe cel mai slab (READ UNCOMMITTED), se folosesc mecanisme de control al concurenei tranzaciilor care previn pierderea actualizrilor. Astfel de anomalii sunt foarte grave, baza de date nu reflect operaiile care s-au efectuat asupra datelor i nici nu exist vreo posibilitate de refacere a acestor pierderi. De aceea nu este prevzut nici un nivel de izolare care s permit pierderea actualizrii datelor. Pe toate nivelurile de izolare, cu excepia nivelului SERIALIZABLE, pot s apar diferite anomalii, dar aceste anomalii sunt anomalii de citire, care pot fi gestionate de tranzacii, i nu anomalii memorate permanent n baza de date. De exemplu, dac se tie c o tranzacie va fi executat pe nivelul de izolare READ COMMITTED, atunci se poate scrie codul tranzaciei astfel nct aceasta s nu citeasc datele din tabele dect o singur dat i s le memoreze local pentru o alt utilizare, n loc s citeasc de mai multe ori din tabele. Cu ct nivelul de izolare a tranzaciilor este mai sczut, cu att pot s apar mai multe anomalii de actualizare, dar crete gradul de concuren a execuiei i scade probabilitatea de apariie a impasului. De aceea, pentru proiectarea unor tranzacii eficiente se recomand utilizarea unor niveluri de izolare ct mai sczute, att ct este posibil pentru ca tranzaciile respective s se execute totui corect. O tranzacie se poate termina fie prin validare (cu comanda COMMIT), fie prin anulare (cu comanda ROLLBACK). Comanda COMMIT garanteaz c toate modificrile efectuate de tranzacia respectiv au devenit permanente. Comanda ROLLBACK termin o tranzacie i anuleaz (ruleaz napoi) toate modificrile executate pn n acel punct de acea tranzacie; aceast comand se trimite atunci cnd apare o anumit condiie (posibil o eroare), care face imposibil continuarea cu succes a tuturor operaiilor tranzaciei. Instruciunile COMMIT i ROLLBACK elibereaz resursele ocupate de tranzacie, cum ar fi zvoarele articolelor. n general, sistemele SGBD implementeaz protocoalele i funciile de control al concurenei i gestioneaz automat execuia tranzaciilor i refacerea datelor, pentru a asigura consistena i integritatea datelor memorate. Tranzaciile sunt administrate la nivelul conexiunii unei aplicaii client cu serverul bazei de date: atunci cnd o tranzacie a fost nceput pe o conexiune, toate instruciunile urmtoare executate pe acea conexiune fac parte din acea tranzacie, pn ce aceasta se termin. Programatorii de aplicaii au responsabilitatea s stabileasc punctele de nceput i de sfrit ale tranzaciilor i s prevad n fiecare tranzacie secvenele de modificri ale datelor astfel nct acestea s lase baza de date ntr-o stare consistent, care s respecte toate constrngerile, implicite i explicite. De asemenea, se

pot selecta prin program diferite opiuni de control (nivel de izolare, mod de acces, etc.). Aceste operaii se pot realiza prin intermediul unor comenzi care sunt variante ale comenzilor SQL de baz i care se transmit SGBDului, fie prin instruciuni ale unui limbaj procedural de extensie a limbajului SQL, fie prin funcii ale interfeelor de programare (cum sunt interfeele ODBC, JDBC) (exemple in manual). Tranzaciile sunt corecte dac las baza de date ntr-o stare consistent i sunt cu att mai eficiente cu ct sunt mai scurte (ca timp de execuie i ca numr de articole ale bazei de date accesate). Respectarea acestor cerine are o influen pozitiv asupra performanelor bazelor de date att prin limitarea frecvenei de apariie a impasului (n cazul folosirii zvoarelor), ct i din punct de vedere al eficienei operaiilor de anulare i de blocare a resurselor. Ori de cte ori se poate nlocui o tranzacie complex, cu numr de operaii i timp de execuie ridicate, cu mai multe tranzacii scurte, este indicat s se fac aceast transformare. De asemenea, pentru meninerea tranzaciilor ct mai scurte posibil, se recomand ca o tranzacie s nu fie pornit pn ce nu au fost pregtite toate datele (citirea datelor de intrare, parcurgerea, analiza i prelucrarea acestora).

10