Baze de date

Note de curs

Florin Ostafi, Claudiu Lefter

Cuprins
1. Introducere 1.1 Informaii i date 1.2 Sisteme de gestiune a bazelor de date 1.3 Modele de date 1.4 Limbaje i utilizatori 1.5 Avantaje i dezavantaje ale sistemelor de gestiune a bazelor de date Partea I. Baze de date relaionale 2. Modelul relaional 2.1 Structura modelului relaional 2.2 Constrngeri de integritate 3. Algebra relaional 3.1 Reuniune, intersecie, diferen 3.2 Operaia de redenumire () 3.3 Operatorul de selecie () 3.4 Operatorul de proiecie () 3.5 Operatorul jonciune join 3.6 Interogri n algebra relaional 3.7 Echivalena expresiilor algebrice 3.8 Valori NULL n algebra relaional 3.9 Vederi 4. Calculul relaional 4.1 Calculul relaional pe domenii 4.2 Calculul relaional pe tupluri 5. SQL 5.1 Definirea datelor n SQL 5.2 Interogri n SQL 5.3 Modificarea datelor n SQL 5.4 Alte definiii de date n SQL 5.5 Controlul accesului la baza de date 5.6 Utilizarea SQL n limbajele de programare Partea a II-a. Proiectarea bazelor de date 6. Tehnici de proiectare i modele 6.1. Procesul de proiectare a bazei de date 6.2. Modelul Entitate Relaie (Entity Relantionship model) 7. Proiectarea conceptual 7.1 Extragerea i analiza cerinelor 7.2 Strategii de proiectare 7.3 Calitatea unei scheme conceptuale. 7.4 Metod de abordare a proiectrii conceptual 8. Proiectarea logic 8.1 Analiza performanelor schemei E-R 8.2 Restructurarea schemei E-R 8.3 Translarea n modelul relaional

Capitolul 1. Introducere
1.1 Informaii i date n cadrul fiecrei activiti disponibilitatea informaiei i capacitatea de a o gestiona n mod eficient sunt eseniale. Din acest motiv, fiecare organizaie dispune de un sistem informaional care gestioneaz informaia necesar realizrii funciilor respectivei organizaii. Rspndirea tehnicii de calcul n aproape toate activitile umane genereaz o continu cretere n computerizarea sistemelor informaionale. n sistemele bazate pe tehnic de calcul, informaia este nregistrat sub form de date, care necesit o interpretare pentru a furniza informaii. Nu se poate da o definiie exact a conceptului de dat, precum i a diferenei dintre dat i informaie. Ce putem spune este ca data nu are nicio semnificaie, dar odat interpretat i corelat convenabil, ea furnizeaz informaii ce mbogesc cunoaterea asupra lumii nconjurtoare.
Exemplu irul de caractere Popescu Ion i numrul 123456 scrise pe o foaie de hrtie sunt dou date care nu au nicio semnificaie. Dac hrtia este trimis ca rspuns la ntrebarea Cine este eful departamentului de cercetare i care este numrul su de telefon? atunci datele pot fi interpretate i utilizate pentru mbogirea cunotinelor cu informaia persoana Popescu Ion este eful departamentului de cercetare i numrul su de telefon este 123456.

Avnd introdus noiunea de dat, ne putem ndrepta spre conceptul de baz de date, elementul principal al cursului. Se pot da mai multe definiii ale unei baze de date, cea mai general dintre ele fiind: o baz de date este o colecie de date utilizat pentru a reprezenta informaiile de interes pentru un sistem informaional. 1.2 Sisteme de gestiune a bazelor de date Primele sisteme software dedicate gestiunii datelor au aprut la sfritul anilor 60. n lipsa software-ului specific, gestiunea se realiza cu ajutorul limbajelor tradiionale de programare cum ar fi C i FORTRAN sau, mai recent, prin intermediul limbajelor orientate obiect (C++, Java). Abordarea convenional a gestiunii datelor exploata prezena fiierelor pentru stocarea permanent a datelor. Sistemele de gestiune a bazelor de date bazate pe fiiere au constituit o ncercare de nceput de a computeriza sistemul de ndosariere manual, n scopul de a accesa mai eficient datele stocate. Un fiier este un set de nregistrri, care conin date ntre care exist relaii logice. Structura fizic i stocarea fiierelor de date i a nregistrrilor sunt definite n cadrul aplicaiei. Un fiier permite stocarea i cutarea datelor, dar furnizeaz doar un mecanism simplu de acces i partajare. Astfel, procedurile scrise ntr-un limbaj de programare sunt complet autonome, fiecare definind i utiliznd unul sau mai multe fiiere private. Datele ce prezint interes pentru mai multe programe sunt multiplicate de attea ori cte programe utilizator exist, introducnd n acest fel redundana i inconsistena datelor.

Limitrile sistemelor de gestiune a bazelor de date bazate pe fiiere - separarea i izolarea datelor - dublarea datelor - dependena de date - incompatibilitatea fiierelor - interogarea / proliferarea fix a programelor aplicaie

Separarea i izolarea datelor Atunci cnd datele sunt izolate n fiiere separate, procesul de combinare a datelor devine mai complicat.
Exemplu Fiiere disponibile - fiier cu informaii despre proprietile disponibile pentru nchiriere - fiier cu informaii despre chiriai Cerin: list a tuturor caselor care ndeplinesc preteniile unui potenial chiria Operaii care trebuie efectuate: - se caut chiriaii care prefer tipul cas - se caut proprietile de tip cas care satisfac cerinele chiriailor

Programatorul de aplicaii trebuie s realizeze sincronizarea a dou fiiere, pentru a fi sigur ca datele extrase sunt corecte. Aceast dificultate este amplificat dac se cer date din mai mult de dou fiiere. Dublarea datelor Dup cum am precizat anterior, datele ce prezint interes pentru mai multe aplicaii sunt multiplicate de attea ori cte aplicaii utilizator exist. Dublarea datelor poate duce la alterarea integritii acestora, atunci cnd modificarea datelor redundante se face doar n fiierele accesate de o aplicaie utilizator. Dependena de date Structura fizic i stocarea fiierelor de date i a nregistrrilor sunt definite n codul aplicaiei. Din acest motiv, efectuarea de modificri n structura existent este dificil. Spre exemplu, dac se modific dimensiunea unui cmp din structura unui fiier, programatorul trebuie s identifice toate programele ce acceseaz fiierul respectiv, s le modifice i s le testeze din nou, operaii consumatoare de timp i supuse apariiei erorilor. Formate de fiiere incompatibile Deoarece structura fiierelor este ncorporat n programele aplicaiei, ea este dependent de limbajul n care sunt scrise acestea. Structura unui fiier poate fi diferit n urma generrii lui de ctre limbaje de programare diferite. Incompatibilitatea direct a unor astfel de fiiere face dificil prelucrarea lor simultan. Interogarea / proliferarea fix a programelor aplicaie Sistemele bazate pe fiiere sunt n mare msur dependente de programatorul de aplicaii, neexistnd faciliti pentru realizarea interogrilor neplanificate. Pe de alt parte au proliferat fiierele i programele aplicaie, fapt ce a dus n cele din urm la programe inadecvate sau ineficiente pentru ndeplinirea cerinelor utilizatorilor, cu o documentaie limitat i dificil de ntreinut. 4

Motivul pentru care au fost create bazele de date a fost, n cea mai mare parte, depirea inconvenientelor prezentate anterior. Definiie. Un sistem de gestiune a bazelor de date (SGBD) este un sistem software capabil s gestioneze colecii de date mari, partajate i persistente i s asigure corectitudinea i securitatea datelor. De asemenea, ca orice produs software, un sistem de gestiune a bazelor de date trebuie s fie eficient i s produc rezultatul scontat. Definiie. O baz de date (BD) este o colecie de date gestionate de un sistem de gestiune a bazelor de date. Sistemele de gestiune a bazelor de date i bazele de date au o serie de caracteristici printre care cele enumerate i dezvoltate mai jos: Bazele de date pot fi mari, n sensul c pot conine mii de miliarde de octei i n general depesc memoria principal disponibil. Prin urmare, un SGBD trebuie s gestioneze datele n memoria secundar. Aceast proprietate impune de fapt unui SGBD s poat gestiona datele fr s fie limitat de dimensiunea lor, singura limitare fiind dat de capacitatea dispozitivelor de stocare. Bazele de date sunt partajate, n sensul c diverse aplicaii i utilizatori trebuie s aib posibilitatea de a obine accesul la datele de interes. Accesul partajat la date al mai multor utilizatori ce opereaz simultan este garantat de SGBD prin utilizarea unui mecanism special denumit controlul concurenei. Bazele de date sunt persistente - BD au o durat medie de via ce nu este limitat de o singur execuie a programelor utilizator, pe cnd datele gestionate de un program n memoria principal au o durat de via cuprins ntre nceputul i sfritul execuiei programului, nefiind persistente. SGBD asigur corectitudinea datelor are capacitatea de a conserva coninutul BD (sau cel puin permite reconstituirea acesteia) n cazul unor defeciuni hardware sau erori software. Pentru a ndeplini aceast cerin, SGBD-urile pun la dispoziie funcii specifice de backup i recuperare a datelor. SGBD asigur securitatea datelor fiecare utilizator, recunoscut prin intermediul unui nume de utilizator specific accesului la SGBD, poate efectua numai anumite operaii asupra datelor. Acest lucru se realizeaz cu ajutorul unui mecanism de autorizare. SGBD-urile trebuie s fie eficiente ele trebuie s finalizeze operaiile utiliznd cantitatea adecvat de resurse (timp i spaiu) pentru fiecare utilizator. Aceast caracteristic se bazeaz att pe tehnicile utilizate n implementarea SGBD-ului, ct i pe modul de proiectare a produsului respectiv. SGBD-urile mresc productivitatea capacitatea sistemului cu BD de a conduce la realizarea scopurilor utilizatorilor. Aceast definiie este generic i nu corespunde unei anumite funcii a SGBD-urilor, dat fiind c un SGBD pune la dispoziia utilizatorilor diverse servicii i funcii. Sarcina proiectrii unei BD i a aplicaiilor ce o utilizeaz vizeaz garantarea unei bune productiviti a ntregului sistem. 1.3 Modele de date Un model de date este o combinaie de elemente destinat organizrii datelor. Fiecare model de date pune la dispoziia utilizatorilor mecanisme de structurare, similare constructorilor type din limbajele de programare, care permit definirea unor tipuri noi de date pe baza tipurilor elementare, predefinite. 5

Modelul de date relaional, cel mai rspndit model de date, pune la dispoziie constructorul relaie, oferind astfel posibilitatea organizarea datelor sub forma unei colecii de nregistrri avnd structur fix. O relaie se reprezint sub forma unui tabel, n care liniile coincid cu nregistrrile, iar coloanele corespund cmpurilor nregistrrii; ordinea n care apar liniile i coloanele nu este relevant.
Exemplu Datele referitoare la cursurile universitare i titularii lor, precum i inserarea cursurilor n prospectul diverselor specializri pot fi organizate cu ajutorul a dou relaii (tabele) CURSURI i PROSPECT: CURSURI Curs Baze de date Reele de calculatoare Tehnici de programare PROSPECT Specializare

Titular Popescu Ionescu Anton

Curs An Reele de calculatoare Automatic 4 Baze de date Automatic 3 Tehnici de Calculatoare 3 programare Calculatoare 4 Reele de calculatoare Calculatoare 4 Baze de date

Modelul relaional a fost propus la nceputul anilor 70, iar sistemele reale bazate pe modelul relaional au aprut la nceputul anilor 80. Pe lng modelul relaional au mai fost definite alte trei modele: Modelul de date ierarhic utilizeaz structuri de tip arbore i ierarhie i a fost definit n faza de nceput a dezvoltrii SGBD-urilor (anii 60). Este utilizat i acum n multe sisteme din motive de continuitate. Modelul de date reea cunoscut i sub numele CODASYL (Conference of Data Systems Languages) utilizeaz grafuri pentru organizarea datelor; a fost dezvoltat n anii 70. Modelul de date obiect a aprut n anii 80 i rezolv unele limitri ale modelului relaional; extinde n domeniul bazelor de date paradigma programrii orientate obiect.

Modelele prezentate anterior sunt denumite logice, pentru a sublinia faptul c, dei structurile utilizate sunt abstracte, ele reflect o organizare particular (arbore, graf, tabel, obiect). Alte modele de date, cunoscute sub numele de modele conceptuale, au fost introduse pentru a descrie datele ntr-o manier independent de modelul logic. Spre deosebire de modelele logice, cele conceptuale nu sunt disponibile n SGBD-urile comerciale. Modelele conceptuale sunt utilizate n faza preliminar a proiectrii bazelor de date, pentru o analiz ct mai bun a aplicaiei, fr implicaii de implementare. Un exemplu de model conceptual este modelul Entitate - Relaie, ce va fi prezentat n cadrul acestui curs. 1.3.1 Scheme i instane ntr-o baz de date exist o parte format din caracteristici ale datelor care nu se modific n timp, numit schema bazei de date i o parte care se modific n timp, numit instan (starea) bazei de date, alctuit din valorile actuale din baza de date. 6

Cele dou relaii din exemplul anterior au o structur fix; relaia CURSURI are dou coloane (atribute) care fac referire la cursuri, respectiv titulari. Schema unei relaii conine numele relaiei, urmat de numele atributelor: CURSURI(Curs, Titular) Instana unei relaii este format dintr-o colecie de linii ale relaiei respective, care variaz n timp. n cazul relaiei CURSURI, instana acestei relaii este dat de urmtoarele trei perechi:
Baze de date Reele de calculatoare Tehnici de programare Popescu Ionescu Anton

1.3.2 Nivele de abstractizare n SGBD-uri Arhitectura unui SGBD este mprit pe trei nivele, cunoscute sub numele de nivelul logic, intern i extern; fiecare nivel are asociat o schem. Schema logic reprezint o descriere a ntregii baze de date prin prisma modelului logic adoptat de SGBD (relaional, ierarhic, reea sau obiect) Schema intern descrie implementarea schemei logice prin prisma structurilor de stocare fizic. De exemplu, o relaie poate fi organizat la nivel fizic sub forma unui fiier secvenial sau a unui fiier secvenial cu indici. Schema extern reprezint descrierea unei poriuni a bazei de date prin prisma modelului logic. O schem extern poate oferi o organizare diferit a datelor cu scopul de a reflecta un punct de vedere al unui anumit utilizator sau grup de utilizatori. n acest fel este posibil ca unei singure scheme logice s-i fie asociate diverse scheme externe: fiecare schem extern va furniza o anumit vedere asupra bazei de date. n majoritatea sistemelor, nivelul extern nu apare explicit, dar este posibil definirea unor relaii derivate, numite vederi.
Exemplu Un student de la Automatic este interesat de cursurile oferite n cadrul acestei specializri. Aceast informaie este prezent n relaia AUTOMATIC, derivat din relaia PROSPECT. AUTOMATIC Specializare Curs An Automatic Reele de calculatoare 4 Automatic Baze de date 3

Schemelor externe li se pot asocia mecanisme pentru autorizarea accesului, n sensul c un utilizator poate fi autorizat s manipuleze doar datele descrise prin prisma schemei externe asociat. 1.3.3 Independena datelor Arhitectura multi-nivel descris anterior garanteaz independena datelor, o caracteristic major a SGBD-urilor. Aceast proprietate permite utilizatorilor i programelor s fac referire la date la un nivel nalt de abstractizare, ignornd detaliile de implementare. Independena datelor prezint dou aspecte: independena fizic i cea logic. 7

Independena fizic permite interaciunea cu SGBD-ul independent de aspectele fizice ale datelor. Este posibil modificarea organizrii fiierelor ce implementeaz relaiile sau modificarea alocrii fizice a fiierelor la dispozitivele de stocare fr a influena descrierile de nivel nalt ale datelor i programele ce utilizeaz acele date. Independena logic garanteaz c interaciunea cu nivelul extern al bazei de date este independent de nivelul logic. Spre exemplu, se poate modifica o schem extern fr a fi necesar modificarea schemei logice. De asemenea, se poate modifica nivelul logic, pstrnd intact schema extern de interes pentru un anume utilizator. Este de subliniat faptul c accesul la baza de date se face numai prin intermediul nivelului extern (care poate coincide cu nivelul logic). SGBD-ul este cel care traduce operaiile n termenii nivelelor corespunztoare. 1.4 Limbaje i utilizatori SGBD-urile ofer o gam larg de limbaje pentru gestiunea datelor i implic, pe parcursul ciclului lor de via, un spectru larg de utilizatori. innd cont de distincia dintre scheme i instane putem face o difereniere similar ntre limbajele bazei de date. limbajul de definire al datelor (LDD) utilizat pentru definirea schemelor logice, externe i fizice precum i pentru definirea autorizrilor de acces; limbajul de manipulare al datelor (LMD) utilizat pentru interogarea i modificarea instanelor unei baze de date. Remarc. Unele limbaje (SQL) ofer facilitilor ambelor limbaje (LDD i LMD) ntr-o form integrat. n funcie de modul de exploatare a bazei de date, utilizatorii se pot mpri n: administratorul bazei de date (DBA) persoana responsabil de proiectarea, controlul i administrarea bazei de date. DBA-ul mediaz ntre cerinele diverse, adesea conflictuale, exprimate de utilizatori, asigurnd controlul partajat asupra datelor. n particular, el este responsabil pentru garantarea serviciilor, asigurnd corectitudinea sistemului i gestionnd autorizrile de acces la date. programatorii de aplicaii definesc i creeaz programele ce acceseaz baza de date. Ei utilizeaz LMD sau alte unelte pentru generarea interfeelor cu baza de date. utilizatorii obinuii cei care utilizeaz efectiv baza de date. Acetia pot fi mprii la rndul lor n dou categorii: - utilizatori finali utilizeaz tranzacii (spre exemplu programe ce realizeaz activiti frecvente i predefinite - utilizatori ocazionali capabili s utilizeze limbaje interactive pentru a accesa baza de date, formulnd interogri (sau actualizri) de diferite tipuri. Ei pot fi specialiti n limbajul pe care l utilizeaz i interacioneaz frecvent cu baza de date. Termenul ocazional se refer la faptul c interogrile nu sunt predefinite. 1.5 Avantaje i dezavantaje ale sistemelor de gestiune a bazelor de date Vom ncheia aceast introducere rezumnd caracteristicile eseniale ale bazelor de date i ale sistemelor de gestiune ale bazelor de date i punctnd avantajele i dezavantajele acestora.

SGBD-urile permit datelor s fie considerate drept resurse comune ale organizaiei, disponibile tuturor membrilor autorizai. Baza de date furnizeaz un model standardizat i precis al acelei pri a lumii reale care prezint interes pentru organizaie, model folosit n aplicaiile existente i care, cu extensiile necesare, poate fi folosit n aplicaii viitoare. SGBD-urile ofer posibilitatea unui control centralizat al datelor. Partajarea bazelor de date permite reducerea redundanei i inconsistenei datelor. Independena datelor, caracteristica fundamental a SGBD-urilor, favorizeaz dezvoltarea de aplicaii mai flexibile i mai uor de modificat. Utilizarea SGBD-urilor are i cteva aspecte negative, cum ar fi: SGBD-urile sunt produse scumpe, complexe i foarte diferite de multe alte unelte software. Introducerea lor necesit un efort financiar att direct (costul produsului) ct i indirect (resurse hardware i software, pregtirea personalului etc.). SGBD-urile furnizeaz, n forma standard, un set de servicii care au un anumit cost. n cazurile n care cteva dintre aceste servicii nu sunt neaprat necesare, e dificil extragerea serviciilor necesare la un moment dat i acest fapt poate duce la ineficien.

n concluzie, putem spune c pot exista situaii n care folosirea SGBD-urilor nu este necesar i anume cazurile n care exist un singur utilizator (sau mai muli, dar care nu au nevoie de acces concurent la date). Oricum, dezvoltarea actual a SGBD-urilor a dus la sisteme mai eficiente i mai fezabile, i la arhitecturi din ce n ce mai ieftine, crescnd astfel posibilitatea dezvoltrii aplicaiilor cu SGBD-uri.

Partea I Baze de date relaionale

Capitolul 2. Modelul relaional
Majoritatea sistemelor cu baze de date se bazeaz pe modelul relaional care a fost propus de E.F. Codd n 1970 ntr-o publicaie tiinific, cu scopul de a furniza o baz pentru independena datelor. Adoptarea modelului relaional ca standard nu a fost imediat, acest lucru fiind motivat de nivelul nalt de abstractizare. Dei primele prototipuri de sisteme relaionale au fost create nc din anii 70, primele sisteme relaionale au aprut pe pia n anii 80. 2.1 Structura modelului relaional Conceptele ce stau la baza modelului relaional sunt cele de relaie i tabel, care difer ca i noiuni dar sunt strns legate. Noiunea de relaie este formal, venind din domeniul matematicii, mai exact din domeniul teoriei mulimilor, n timp ce noiunea de tabel este o noiune simpl i intuitiv. Definiie. Fie date mulimile D1 i D2. Produsul cartezian dintre D1 i D2 (notat D1 D2 ) se definete ca fiind mulimea perechilor ordonate (v1 , v2 ) , v1 D1 , v2 D2 . Definiie. O relaie pe mulimile D1 i D2 (numite domeniile relaiei) este o submulime a produsului cartezian D1 D2 . Observaii. Definiiile de mai sus nu specific n clar dac mulimile D1 i D2 sunt finite sau nu. n practic relaiile trebuie s fie finite deoarece bazele de date trebuie stocate n sisteme computerizate de dimensiuni finite. n acelai timp ns este de dorit ca domeniile s aib dimensiuni infinite, astfel nct s putem presupune existena unei valori care nu e prezent n baza de date. Din acest motiv, vom presupune acolo unde este necesar, c bazele de date sunt alctuite din relaii finite, definite pe domenii infinite. Definiiile de mai sus pot fi generalizate. Fie n > 0 mulimi D1 , D2 ,..., Dn , nu neaprat distincte. Produsul cartezian D1 D2 ... Dn este dat de mulimea n-tuplurilor v1 , v2 ,..., vn , unde

vi Di , i = 1, n . O relaie matematic pe domeniile D1 , D2 ,..., Dn este o submulime a produsului

cartezian D1 D2 ... Dn .

Gradul produsului cartezian i al relaiei (dat de numrul componentelor produsului cartezian) este n. Cardinalitatea relaiei este dat de numrul n-tuplurilor. Deoarece o relaie este de fapt o mulime, putem face urmtoarele observaii: ntre n-tupluri nu exist o ordine predefinit; n-tuplurile unei relaii sunt distincte unele de celelalte; din acest motiv, un tabel reprezint o relaie doar dac liniile sale sunt diferite ntre ele. Pe fiecare n-tuplu se definete o relaie de ordine adic fiecare componenta i a fiecrui tuplu corespunde domeniului i. Aceast ordonare ntre domeniile unei relaii reprezint o 10

caracteristic nesatisfctoare a conceptului de relaie (aa cum este definit n matematic) din punctul de vedere al posibilitii organizrii i utilizrii datelor (vezi figura 2.1).
Real Madrid Liverpool Real Madrid Roma Liverpool Milan Roma Milan 3 2 1 0 1 0 2 1

Fig. 2.1 Exemplu de relaie n care semnificaia datelor este dat de poziia lor n cadrul tuplului

Pentru nlturarea acestui inconvenient a fost introdus o notaie non-poziional, prin asocierea de nume domeniilor unei relaii, referite drept atribute. Atributele descriu rolurile jucate de domenii (vezi figura 2.2).
EchipaGazda Real Madrid Liverpool Real Madrid Roma EchipaOaspete GoluriGazde GoluriOaspeti Liverpool 3 1 Milan 2 0 Roma 1 2 Milan 0 1 Fig. 2.2 Relaie cu atribute

Pentru formalizarea conceptelor introduse anterior, definim funcia DOM : X D care asociaz fiecrui atribut A X un domeniu DOM ( A) D .
Definiie. Un tuplu definit pe o mulime de atribute X este o funcie t care asociaz fiecrui atribut A X o valoare din domeniul DOM ( A) . Definiie. O relaie pe o mulime de atribute X este o mulime de tupluri definite pe X . Notaie. Fie t un tuplu definit pe o mulime de atribute X i A X un atribut. Prin t[A] se noteaz valoarea tuplului t n domeniul DOM ( A) .
Exemplu Fie t primul tuplu din relaia prezentat n figura 2.2. n acest caz, putem spune c t[EchipaOaspete]=Liverpool

Aceeai notaie va fi utilizat i n cazul unor mulimi de atribute.

Exemplu t[EchipaOaspete, GoluriOaspeti]=Liverpool,1

O relaie poate fi utilizat pentru organizarea ntr-o manier relevant a datelor necesare unei aplicaii. De obicei, nu este suficient o singur relaie i de aceea bazele de date sunt formate din mai multe relaii, ale cror tupluri conin valori comune atunci cnd acest lucru este necesar pentru stabilirea unor corespondene (vezi figura 2.3).

STUDENTI NrInreg 276545 485745 200768 587614 937653

Nume Ionescu Popescu Georgescu Luca Maftei

Prenume Maria Ana Paul Radu Lucian

DataNastere 25/11/1980 23/04/1981 12/02/1981 10/10/1980 01/12/1980

11

EXAMENE Student Nota 276545 276545 937653 200768 CURSURI Cod Denumire 01 Fizica 03 Chimie 04 Chimie 8 9 9 9

Curs 01 04 01 04

Titular Melinte Mardare Dascalu

Fig. 2.3 Exemplu de baz de date relaional

Definiie. Schema unei relaii este format din numele relaiei R i o mulime de atribute X = { A1 , A2 ,..., An } i se noteaz R(X). Fiecrui atribut i este asociat un domeniu. Definiie. Schema bazei de date este format dintr-o mulime de scheme de relaii: R = { R1 ( X 1 ),R2 ( X 2 ),...,Rn ( X n )} Definiie. Instana unei relaii (pe scurt relaia) avnd schema R(X) este dat de mulimea r a tuplurilor definite pe mulimea de atribute X. Definiie. Instana bazei de date (pe scurt baza de date) avnd schema R = { R1 ( X 1 ),R2 ( X 2 ),...,Rn ( X n )} este mulimea r = { r1 ,r2 ,...,rn } de relaii n care fiecare

ri , i = 1,n este o relaie definit pe schema Ri ( X i ) .

Exemplu Schema bazei de date din figura 2.3 este R = {STUDENTI(NrInreg, Nume, Prenume, DataNastere), EXAMENE(Student, Nota, Curs), CURSURI(Cod, Denumire, Titular)}

Structura modelului relaional este simpl i puternic. n acelai timp ns impune u anumit grad de rigiditate, prin aceea ca informaiile trebuie reprezentate sub forma unor tupluri omogene de date; n particular, putem reprezenta n cadrul unei relaii doar tupluri ce corespund schemei relaiei. n practic exist cazuri n care datele disponibile nu corespund cu exactitate formatului ales.
Exemplu Se consider schema PERSOAN(Nume, Prenume, Adres, Telefon). Pot exista tupluri pentru care valoarea atributului Telefon nu este disponibil

Pentru rezolvarea problemei indisponibilitii valorilor, s-a extins conceptul de relaie n sensul includerii posibilitii ca fiecare atribut al unui tuplu s poat lua fie valori din domeniul asociat, fie o valoare special, denumit valoare null. Valoarea null indic absena 12

informaiei i este o valoare suplimentar, ce nu este coninut de domeniu. La definirea unei relaii se pot specifica acele atribute care accept valori null.

2.2 Constrngeri de integritate

n multe cazuri ne confruntm cu situaii cnd nu orice mulime de tupluri n cadrul unei scheme reprezint informaii corecte pentru aplicaie. Pentru nlturarea unor astfel de situaii (de incorectitudine a informaiilor) a fost introdus conceptul de constrngere de integritate, ca fiind o proprietate ce trebuie satisfcut de toate instanele corecte ale bazei de date. O constrngere poate fi privit ca un predicat ce asociaz valoarea adevrat sau fals fiecrei instane. Se pot defini mai multe constrngeri pentru o baz de date i vom considera corecte (sau legale) acele instane care satisfac toate constrngerile impuse. n funcie de elementele bazei de date ce intervin ntr-o constrngere de integritate, acestea se pot clasifica astfel:

1. constrngeri intra-relaionale - sunt definite pe o singur relaie a bazei de date i pot fi de dou tipuri:
a. constrngeri la nivel de tuplu pot fi evaluate pe fiecare tuplu, independent de celelalte tupluri; b. constrngeri la nivel de domeniu (la nivel de valoare) impun restricii asupra domeniului unui atribut.

2. constrngeri inter-relaionale implic mai multe relaii

Exemplu Fie baza de date din figura urmtoare STUDENTI NrInreg 200768 937653 937653

Nume Georgescu Maftei Luca

Prenume Paul Lucian Radu

DataNastere 12/02/1981 10/10/1980 01/12/1980

EXAMENE Student 200768 937653 937653 276545

Nota 11 4 6 7

Promovat DA DA DA DA

Curs 05 01 04 01

CURSURI Cod Denumire 01 Fizica 03 Chimie 04 Chimie

Titular Melinte Mardare Dascalu

Fig.2.4 Baz de date cu informaii incorecte

13

constrngeri la nivel de tuplu: - n primul tuplu al relaiei EXAMENE avem ca rezultat la un examen nota 11; - n al doilea tuplu al relaiei EXAMENE un student este considerat promovat la examen dei nota sa este 4. constrngeri la nivel de domeniu - pentru atributul Not din relaia EXAMENE, numai valorile cuprinse ntre 1 i 10 sunt permise; - ultimele dou tupluri ale relaiei STUDENTI conin informaii pentru doi studeni diferii dar cu acelai numr de nregistrare, identificarea studenilor fiind astfel ambigu. constrngeri inter-relaionale - al patrulea tuplu al relaiei EXAMENE are, pentru atributul Student, o valoare care nu apare printre numerele de nregistrare din relaia STUDENTI; - primul tuplu al relaiei EXAMENE are, pentru atributul Curs, o valoare care nu apare printre codurile cursurilor din relaia CURSURI.

n continuare vom examina constrngerile pe tuplu, constrngerile de chei (cele mai importante constrngeri intra-relaionale) i constrngerile de referin (cele mai importante constrngeri inter-relaionale). Constrngeri pe tuplu Constrngerile pe tuplu reprezint condiii impuse valorilor fiecrui tuplu, independent de celelalte tupluri. O sintax posibil pentru aceste constrngeri permite definirea unor expresii booleene (folosind conectorii AND, OR i NOT) ale cror atomi compar valorile atributelor implicate n constrngeri sau expresii aritmetice folosind valorile atributelor.

Exemplu Expresia ce descrie prima constrngere de tuplu nclcat n exemplul prezentat n figura 2.4: (Nota 1) AND (Nota 10) Expresia ce descrie a doua constrngere de tuplu violat n exemplul prezentat n figura 2.4: (Promovat = DA) AND (Nota 5)

Definiia permite construirea unor expresii de complexitate ridicat, singura condiie fiind ca aceste expresii s utilizeze valorile unui singur tuplu.
Exemplu Fie dat schema PLAT(Dat, Sum, Deduceri, Net)

14

Se poate defini o constrngere care impune condiia ca suma net s fie egal cu diferena dintre suma total i deduceri: Net = Sum - Deduceri

Constrngeri de chei

O cheie este o mulime de atribute ce ajut la identificarea n mod unic a tuplurilor unei relaii.
Definiie. O mulime de atribute K este o super-cheie a relaiei r dac r nu conine dou tupluri distincte t1 i t2 astfel nct t1[K] = t2[K] . Definiie. O mulime K de atribute este o cheie a relaiei r dac mulimea K este o super-cheie minimal (i.e. nu exist alt super-cheie K a lui r astfel nct K ' K ).
Exemplu Se consider urmtoarea relaie STUDENT NrInreg Nume 284328 Ionescu 296328 Ionescu 587614 Ionescu 934856 Popescu 965536 Popescu

Prenume Maria Ana Lucian Lucian Lucian

DataNastere 29/04/59 29/04/59 01/05/61 01/05/61 05/03/58

Facultate AC TCM Textile AC TCM

Fig.2.5 Exemplu de relaie pentru evidenierea cheilor Mulimea {NrInreg} este super-cheie; este de asemenea i super-cheie minimal, deoarece conine un singur atribut, deci {NrInreg} este o cheie. Mulimea {Nume, Prenume, DataNastere} este o super-cheie; deoarece nici una din submulimi nu este super-cheie, {Nume, Prenume, DataNastere} este o cheie. Mulimea {NrInreg, Facultate} este super-cheie, dar nu este o super-cheie minimal, deoarece submulimea {NrInreg} este ea nsi super-cheie minimal. Deci {NrInreg, Facultate} nu este o cheie. Deoarece nu exist dou tupluri cu aceleai valori pentru atributele Nume i Facultate, putem afirma c mulimea {Nume, Facultate} este o super-cheie. Deoarece exist tupluri avnd aceeai valoare att pentru atributul Nume ct i pentru atributul Facultate, mulimea {Nume, Facultate} este o cheie. Mulimea {Nume, Facultate} identific n mod unic tuplurile acestei relaii. Apare ns ntrebarea: Putem afirma acest lucru n cazul general ? Rspunsul este, n mod evident, c nu, deoarece pot exista studeni cu acelai nume i care au terminat aceeai facultate. Spunem c, n acest caz, mulimea {Nume, Facultate} este, prin ans, cheie a relaiei. Pentru schema STUDENTI (NrInreg, Nume, Prenume, DataNastere, Facultate) se pot stabili dou constrngeri ce impun urmtoarele chei: NrInreg Nume, Prenume, DataNastere Relaia din figura 2.5 satisface ambele constrngeri de chei anterioare.

15

Faptul c pentru orice relaie se poate stabili cel puin o cheie garanteaz accesul la toate datele din baza de date i identificarea lor unic. Mai mult dect att, permite stabilirea unor legturi ntre datele coninute de diverse relaii.
Exemplu Se consider baza de date din figura 2.3. Relaia EXAMENE face referire la studenii din relaia STUDENTI prin intermediul atributului NrInreg i la cursurile din relaia CURSURI prin atributul Cod. NrInreg este cheia relaiei STUDENTI iar Cod este cheia relaiei CURSURI. Se observ faptul c valorile atributelor cheie sunt utilizate pentru referirea coninutului altor relaii.

O cheie primar este cheia prin intermediul creia se realizeaz referine ntre relaii. Alte constrngeri impuse cheii unei relaii vizeaz utilizarea valorilor null pentru atributele ce compun cheia. Mai exact, este interzis utilizarea valorilor null pentru cheile primare, n timp ce ele pot fi admise pentru celelalte chei. n practic pot aprea situaii n care nu exist atribute ale cror valori s fie disponibile pentru o cheie primar. n aceste cazuri se va introduce un atribut suplimentar care va fi generat i asociat fiecrui tuplu n momentul inserrii n relaia corespunztoare.
Constrngeri de referin

O constrngere de referin (sau cheie strin) ntre o mulime de atribute X ale relaiei R1 i alt relaie R2 este satisfcut dac valorile fiecrui tuplu din R1 corespunztoare mulimii X se regsesc printre valorile cheii primare a relaiei R2. Se ntlnesc dou situaii: a) Cheia relaiei R2 este unic i conine un singur atribut B. Constrngerea de referin ntre mulimea X (format din atributul A) i relaia R2 este satisfcut dac
t1 R1 cu t1 [ A] NULL , t2 R2 astfel nct t1 [ A ] = t2 [ B ] .

b) Cheia relaiei R2 este unic i coincide cu o mulime K de atribute. Pentru stabilirea unei constrngeri ntre X i R2 trebuie specificat o anumit ordine pentru ambele mulimi (X i K). Indicnd atributele n ordine, X = A1 A2 ... Ap , K = B1 B2 ...B p , constrngerea este satisfcut dac

t1 R1 cu t1 [ Ai ] NULL , i = 1, p , t2 R2 astfel nct t1 [ Ai ] = t2 [ Bi ] , i = 1, p .

Exemplu Se consider baza de date din figura urmtoare CADRE CONTRAVENTIE NrInreg Nume Cod Data Cadru Judet NrInmat Prenume 143256 25/10/92 567 IS 02 AAA 567 Dascalescu Eugen 987554 26/10/92 456 IS 02 AAA 456 Ionescu George 987557 26/10/92 456 IS 03 BBB 638 Popescu Dan 630876 15/10/92 456 VS 03 BBB 539856 12/10/92 567 VS 03 BBB

16

AUTOVEHICUL NrInmat Judet 03 BBB IS 01 CCC IS 02 AAA IS 03 BBB VS

Proprietar Maftei Eduard Maftei Eduard Luca Marian Melinte Dan

Adresa Nicolina 30 Nicolina 30 Primaverii 4 Primaverii 17

Fig.2.6 Baz de date cu constrngeri de referin Se definesc urmtoarele constrngeri de referin: - ntre atributul Cadru al relaiei CONTRAVENIE i relaia CADRE; - ntre atributele NrInmat i Judet ale relaiei CONTRAVENIE i relaia AUTOVEHICUL, ordinea atributelor n cheia relaiei AUTOVEHICUL fiind NrInmat, Judet. Se poate observa c baza de date din figura 2.6 respect ambele constrngeri.

n cazul b) discuia despre ordinea atributelor poate prea excesiv, dat fiind c se poate obine o coresponden prin intermediul numelor atributelor. n general, nu ne putem baza pe o astfel de coresponden (prin intermediul numelor atributelor) i va trebui s recurgem la impunerea unei anumite ordini a atributelor.
Exemplu S presupunem c dorim s includem ntr-o relaie numrul de nregistrare i judeele celor dou autovehicule implicate ntr-un accident. O schem posibil ar fi: ACCIDENT(Cod, Judet1, NrInmat1, Judet2, NrInmat2,...) Corespondena implicat de constrngerea de referin cu relaia AUTOVEHICUL nu va putea fi stabilit prin numele atributelor, deoarece cele din relaia ACCIDENT difer de numele atributelor cheii relaiei AUTOVEHICUL. Va trebui s specificm c referina asociaz Judet1 la Judet i NrInmat1 la NrInmat, respectiv Judet2 la Judet i NrInmat2 la NrInmat. Exemplu Baza de date din figura urmtoare nu respect cele dou constrngeri menionate anterior. ACCIDENT Cod Jud1 6207 IS 6974 BC NrInmat1 03 BBB 02 AAA Jud2 BC BC NrInmat2 02 DDD 02 DDD

AUTOVEHICUL NrInmat Judet 01 CCC IS 02 AAA BC 03 BBB IS

Proprietar Maftei Eduard Luca Marian Melinte Dan

Adresa Nicolina 30 Primaverii 4 Primaverii 17

Fig.2.7 Baz de date care nu satisface constrngerile de referin

Observaii n cazul relaiilor cu mai multe chei, se va alege o cheie primar i toate referirile trebuie redirectate spre ea.

17

exist sisteme de gestiune a bazelor de date care nu permit indicarea n mod explicit a unei chei primare. In aceste cazuri, constrngerea de referin trebuie s indice explicit atributele ce formeaz cheia la care se face referire.
Probleme propuse 1. Se consider baza de date din figura urmtoare: PACIENT INTERNARE Pacient A102 A102 S555 B444 S555 Intrare 2/05/2004 2/12/2004 5/10/2004 1/12/2004 5/10/2004 Iesire 9/05/2004 2/01/2005 3/12/2004 1/01/2005 1/112004 Sectie A A B B A

Cod A102 B372 B543 B444 S555

Nume Popescu Popa Ionescu Ionescu Vasile

Prenume Maria Mihai Ioana Radu Ion

MEDIC SECTIE Numar Nume Prenume Sectie 203 Dumitrescu Mihai A Cod Nume Specialist 574 Georgescu Stefan B A Chirurgie 203 461 Barbu Petre B B Pediatrie 574 530 Petrescu George C C Medicala 530 405 Filipescu George A 501 Barbulescu Stefan A Punei n eviden cheile i constrngerile de referin din baza de date prezentat. Precizai dac respectivele constrngeri sunt satisfcute de toate bazele de date care au aceeai schem cu baza de date din figur. Precizai care atribute pot admite valori null. 2. Se consider urmtoare informaii referitoare la managementul mprumuturilor dintr-o bibliotec personal: proprietarul mprumut cri prietenilor, care se nregistreaz prin intermediul numelor (astfel nct s se evite repetiiile); o carte este referit prin titlul su (nu exist dou cri cu acelai titlu); cnd clientul mprumut o carte, se nregistreaz data mprumutului i proprietarul fixeaz data returnrii; Definii o schema relaional pentru reprezentarea informaiilor de mai sus, preciznd domeniile adecvate pentru atribute i o instan sub form tabelar. Precizai cheia sau cheile relaiei. 3. Reprezentai prin intermediul unei relaii sau a mai multora informaiile coninute n mersul trenurilor dintr-o staie: numrul trenului, ora sosirii, ora plecrii, punctul de plecare, destinaia final, tipul de tren i opririle de pe parcurs. 4. Definii o schem a unei baze de date n care se organizeaz informaiile referitoare la o companie care are angajai (fiecare cu codul numeric personal, nume, prenume i data naterii) i subsidiari (fiecare cu cod, ramur i director, care este angajat). Fiecare angajat lucreaz pentru un subsidiar. Indicai cheile i constrngerile de referin ale schemei. Artai o instan a bazei de date i verificai dac se respect constrngerile.

18

Capitolul 3. Algebra relaional

Informaiile de interes pentru aplicaiile de gestiune a datelor se pot reprezenta prin intermediul relaiilor. Limbajele pentru specificarea operaiilor necesare interogrii i actualizrii datelor reprezint o component esenial pentru fiecare model de date. O actualizare poate fi vzut ca o funcie care, pornind de la o baz de date produce o alt baz de date (fr a-i modifica schema). O interogare poate fi privit ca fiind o funcie care returneaz o relaie, plecnd de la o baz de date. n continuare vom vedea mai nti care sunt fundamentele limbajelor de interogare i actualizare i apoi vom studia limbajele ce sunt recunoscute de sistemele de gestiune a bazelor de date comerciale.

Algebra relaional este un limbaj procedural n care funciile pentru extragerea datelor sunt specificate prin descrierea procedurii ce trebuie urmat n sensul obinerii unui rezultat. Algebra relaional se bazeaz pe o colecie de operatori ce sunt aplicai relaiilor, producnd relaii. Pentru formularea unor interogri complexe se vor construi expresii ce implic mai muli operatori. Operatorii algebrici relaionali se mpart n urmtoarele clase: Operatori clasici din teoria mulimilor reuniune, intersecie, diferen; Operatori de redenumire, selecie, proiecie; Operatorul join (jonciune), mpreun cu variantele sale jonciune natural, produs cartezian, theta jonciune i jonciune extern.

3.1 Reuniune, intersecie, diferen

Dup cum am mai precizat anterior, relaiile sunt mulimi de tupluri omogene i de aceea are sens definirea operatorilor clasici de reuniune, intersecie i diferen. n cele ce urmeaz, vom permite aplicarea acestor operatori doar asupra perechilor de relaii definite pe aceleai atribute.
Reuniunea a dou relaii r1(X) i r2(X) este relaia notat r1 r2 care conine tupluri ce aparin fie lui r1 fie lui r2, fie ambelor relaii r1 i r2. Intersecia dintre relaiile r1(X) i r2(X) este relaia notat r1 r2 format din tuplurile comune relaiilor r1 i r2. Diferena dintre relaiile r1(X) i r2(X) este relaia notat r1 r2 care conine tuplurile din r1 care nu se regsesc n r2.

3.2 Operaia de redenumire ()

Limitrile impuse operatorilor standard din teoria mulimilor pot fi restrictive n anumite situaii.
Exemplu S considerm cele dou relaii din figura 3.1

19

TATA_COPIL Tata Copil Adam Dan Adam Marian Radu Cristi Radu Catalin

MAMA_COPIL Mama Copil Eva Dan Eva Lucian Maria Cristi Carmen Catalin

TATA_COPIL MAMA_COPIL ?? Figura 3.1 Reuniune logic, dar incorect Ar avea sens executarea unei reuniuni ntre cele dou relaii cu scopul de a obine toate perechile printe copil din baza de date. Acest lucru nu este ns posibil deoarece atributul denumit de noi din instinct printe are numele tata ntr-o relaie i numele mama n cealalt relaie.

Pentru a rezolva problema prezentat n exemplul anterior se introduce un operator specific algebrei relaionale, al crui scop este de a adapta numele atributelor atunci cnd este necesar aplicarea unui operator din teoria mulimilor. Acest operator este operatorul de redenumire, numele lui indicnd faptul c modific numele atributelor lsnd intact coninutul relaiei.
Exemplu TATA_COPIL Tata Copil Adam Dan Adam Marian Radu Cristi Radu Catalin

ParinteTata (TATA_COPIL)
Parinte Adam Adam Radu Cristi Fig.3.2 Exemplu de redenumire Copil Dan Marian Cristi Iacob

Operatorul de redenumire modific numele atributului Tata din relaia TATA_COPIL n Parinte.

Definiie. Fie r o relaie definit pe mulimea X de atribute i fie Y o alt mulime de atribute avnd aceeai cardinalitate ca i X. Fie secvenele ordonate A1 A2 ... Ak i B1 B2 ...Bk formate din atributele mulimii X respectiv Y. Redenumirea

A1 A2 ... Ak B1 B2 ...Bk ( r )
conine pentru fiecare tuplu t din r un tuplu t definit pe Y astfel nct t' [ Bi ] = t[ Ai ] , i = 1,k . n practic, cele dou secvene A1 A2 ... Ak i B1 B2 ...Bk vor conine doar atributele ce urmeaz a fi redenumite i noile lor nume. 3.3 Operatorul de selecie () Rezultatul unei selecii conine tuplurile relaiei operand ce satisfac condiia asociat relaiei.
\

20

Exemplu Se consider relaia ANGAJAT din figura 3.3. ANGAJAT Nume Prenume Varsta Salariu Ionescu Maria 25 2000 Popescu Lucia 40 3000 Diaconescu Nicu 36 4500 Ionescu Marin 40 3900

Virsta <30 Salariu >4000 ( ANGAJAT )

Nume Prenume Varsta Salariu Ionescu Maria 25 2000 Diaconescu Nicu 36 4500

Fig.3.3 Exemplu de selecie Dup cum se poate observa, sunt selectate tuplurile din relaia ANGAJAT care ndeplinesc condiia: Varsta < 30 sau Salariu > 4000.

Definiii.

Fiind dat o relaie r definit pe o mulime de atribute X, spunem c o formul propoziional F definit pe X este o formul compus din condiii atomice de tipul A B sau A c legate prin conectorii (OR), (AND) i (NOT), n care:
este un operator de comparaie ( = , , < , , > , );

A i B sunt atribute din X compatibile (i.e. conin valori pentru care are sens comparaia); c este o constant compatibil cu domeniul atributului A.

Fiind dat formula propoziional F i tuplul t, se definete valoarea de adevr a lui F pe

t:

A B este adevrat dac i numai dac t[ A] este n relaia cu t[ B ] ; A c este adevrat dac i numai dac t[ A] este n relaia cu c; F1 F2 , F1 F2 i F1 au semnificaia uzual.

O selecie F ( r ) produce o relaie care are aceleai atribute ca relaia r i care conine acele tupluri din r pentru care F este adevrat.

3.4 Operatorul de proiecie ()

Definiie. Fie dat relaia r definit pe mulimea de atribute X i o submulime Y a lui X. Proiecia relaiei r pe Y (notat Y ( r ) ) reprezint mulimea tuplurilor definite pe Y obinute din tuplurile lui r lund n considerare numai valorile corespunztoare atributelor din Y:
Y ( r ) = { t[Y ] / t r }

n general rezultatul unei proiecii conine un numr de tupluri cel mult egal cu numrul de tupluri din operand. n figurile 3.4, 3.5 sunt prezentate situaiile n care numrul de tupluri ale rezultatului este egal, respectiv mai mic dect numrul de tupluri ale operandului. 21

Exemplu ANGAJAT Nume Prenume Ionescu Maria Popescu Lucia Diaconescu Nicu Ionescu Marin

Varsta , Salariu (ANGAJAT)

Varsta 25 40 36 45 Salariu 2000 3000 4500 3900 Varsta 25 40 36 45 Salariu 2000 3000 4500 3900

Fig.3.4 Exemplu de proiecie cu acelai numr de tupluri ca i operandul ANGAJAT Nume Prenume Ionescu Maria Popescu Lucia Diaconescu Maria Ionescu Marin

Departament Vanzari Vanzari Personal Personal

Sef Luca Luca Damian Damian

Departament ,Sef (ANGAJAT)

Departament Vanzari Personal Sef Luca Damian

Fig.3.5 Exemplu de proiecie cu mai puine tupluri dect operandul

Propoziie. Y ( r ) conine acelai numr de tupluri ca i r dac i numai dac Y este o supercheie pentru r. Demonstraie. Fie Y super-cheie pentru r. Rezult c r nu conine perechi de tupluri egale pe Y, deci fiecare tuplu va contribui la rezultatul proieciei. Dac proiecia are acelai numr de tupluri ca i operandul rezult c fiecare tuplu din r a contribuit la proiecie cu valori diferite. Aceasta nseamn c r nu conine perechi de tupluri egale pe Y, deci Y este o super-cheie.

3.5 Operatorul jonciune join

Operatorul jonciune permite realizarea unei conexiuni ntre datele coninute de diverse relaii. Exist dou versiuni principale ale acestui operator, care, oricum, se pot obine una din cealalt. Jonciunea natural ( ) natural join Jonciunea natural coreleaz datele din relaii diferite pe baza valorilor egale asociate atributelor cu acelai nume.
Definiie. Fie r1(X1) i r2(X2) dou relaii. Jonciunea natural r1 r2 este o relaie definit pe X1X2 (reuniunea dintre X1 i X2) astfel nct:

r1 r2 = { t definit pe X 1 X 2 / t1 r1 , t2 r2 , astfel incat t[ X 1 ] = t1 si t[ X 2 ] = t2 }

Pe scurt putem scrie

r1 r2 = { t definit pe X 1 X 2 / t[ X 1 ] r1 si t[ X 2 ] r2 }
Definiia confirm faptul c tuplurile relaiei rezultat provin din combinarea tuplurilor din operanzi avnd valori egale pentru atributele comune. Notm X 1,2 = X 1 X 2 mulimea atributelor comune. Condiiile

t[ X 1 ] = t1 i t[ X 2 ] = t2 implic (deoarece X 1,2 X 1 i

X 1,2 X 2 ) t[ X 1,2 ] = t1 [ X 1,2 ] i t[ X 1,2 ] = t2 [ X 1,2 ] , deci t1 [ X 1,2 ] = t2 [ X 1,2 ] . Fie n gradul
22

jonciunii naturale dintre relaiile r1 i r2, n1 gradul relaiei r1 i n2 gradul relaiei r2; atunci n n1 + n2 .
Exemplu CONTRAVENTIE Cod Data Cadru Judet NrInmat 143256 25/10/92 567 IS 02 AAA 987554 26/10/92 456 IS 02 AAA 987557 26/10/92 456 IS 03 BBB 630876 15/10/92 456 VS 03 BBB 539856 12/10/92 567 VS 03 BBB AUTOVEHICUL NrInmat Judet Proprietar Adresa 03 BBB IS Maftei Eduard Nicolina 30 01 CCC IS Maftei Eduard Nicolina 30 02 AAA IS Luca Marian Primaverii 4 03 BBB VS Melinte Dan Primaverii 17

CONTRAVENTIE AUTOVEHICUL Cod Data Cadru Judet NrInmat 143256 25/10/92 567 IS 02 AAA 987554 26/10/92 456 IS 02 AAA 987557 26/10/92 456 IS 03 BBB 630876 15/10/92 456 VS 03 BBB 539856 12/10/92 567 VS 03 BBB

Proprietar Luca Marian Luca Marian Maftei Eduard Melinte Dan Melinte Dan

Adresa Primaverii 4 Primaverii 4 Nicolina 30 Primaverii 17 Primaverii 17

Fig.3.5 Relaiile CONTRAVENTIE i AUTOVEHICUL i jonciunea lor natural Se observ faptul c jonciunea natural a celor dou relaii s-a obinut prin combinarea fiecrui tuplu din CONTRAVENIE cu exact un tuplu din AUTOVEHICUL: cu cel mult unul deoarece atributele Judet i NrInmat formeaz o cheie a relaiei AUTOVEHICUL; cu cel puin unul datorit constrngerii de referin dintre atributele Judet i NrInmat din CONTRAVENTII i relaia AUTOVEHICUL.

Definiie. Fie r1(X1) i r2(X2) dou relaii. Spunem c jonciunea natural r1 r2 este complet dac t1 r1 , t r1 r2 , astfel incat t[ X 1 ] = t1 i
t2 r2 , t' r1 r2 , astfel incat t'[ X 2 ] = t2 .

Exemplu r1 Angajat Ionescu Balint Baltag r2 Departament productie vanzari

Departament vanzari productie productie r1 r2 Angajat Ionescu Balint Baltag

Sef Manole Burlacu

Departament vanzari productie productie

Sef Burlacu Manole Manole

Fig.3.6 Exemplu de jonciune natural complet

23

Not. Exist posibilitatea ca n cazul unei jonciuni rezultatul s nu conin nici un tuplu. n cealalt extrem se afl situaia cnd fiecare tuplu al unui operand se poate combina cu fiecare tuplu din cel de-al doilea operand. n acest caz cardinalitatea relaiei rezultat este dat de produsul cardinalitilor celor doi operanzi.
Rezumnd cazurile expuse putem spune c jonciunea dintre r1 i r2 conine un numr de tupluri cuprins ntre 0 i r1 r2 . Mai mult dect att:

dac jonciunea este complet atunci | r1 r2 | max(| r1 | ,| r2 |) ; dac X 1 X 2 conine o cheie pentru r2 atunci | r1 r2 | | r1 | ; dac X 1 X 2 este cheie primar pentru r2 i exist constrngeri de referin ntre

X 1 X 2 din r1 i r2 atunci | r1 r2 | = | r1 |
Jonciunea extern outer join Faptul c operatorul de jonciune exclude tuplurile unei relaii ce nu au corespondent n cellalt operand este avantajos n unele situaii i dezavantajos n altele. n acest sens a fost introdus operatorul de jonciune extern, care asigur prezena n relaia rezultat a tuturor tuplurilor unei relaii, acestea fiind completate cu valori NULL atunci cnd nu au corespondent n cealalt relaie. Acest operator are trei variante : jonciune extern la stnga extinde doar tuplurile primului operand; jonciune extern la dreapta extinde doar tuplurile celui de-al doilea operand; jonciune extern complet extinde toate tuplurile.
Exemplu r1 Angajat Ionescu Balint Luca

Departament vanzari productie productie r1 LEFT r2 Angajat Ionescu Balint Luca r1 RIGHT r2 Angajat Balint Luca null r1 FULL r2 Angajat Ionescu Balint Luca null

r2 Departament productie achizitii

Sef Manole Burlacu

Departament vanzari productie productie

Sef null Manole Manole

Departament productie productie achizitii

Sef Manole Manole Burlacu

Departament vanzari productie productie achizitii

Sef null Manole Manole Burlacu

Fig.3.7 Exemple de jonciuni externe

24

Jonciune n-ar, intersecie i produs cartezian

Proprieti ale jonciunii naturale:

comutativitatea - r1 r2 = r2 r1 ; asociativitate - ( r1 r2 ) r3 = r1 ( r2 r3 ) .

innd cont de aceste proprieti putem scrie urmtoarele secvene de jonciuni fr paranteze:
r1 r2 ... rn sau n i = 1 ri - jonciune n-ar.

Pn in acest moment nu s-au fcut nici un fel de precizri asupra mulimilor X1 i X2 de atribute. Cele dou mulimi pot fi egale sau disjuncte. Dac X1 = X2 atunci jonciunea coincide cu intersecia:

r1( X 1 ) r2 ( X 2 ) = r1 ( X 1 ) r2 ( X 2 )
ntr-adevr, din definiie, r1 r2 conine tuplurile t definite pe X 1 X 2 = X 1 astfel nct t[ X 1 ] r1 i t[ X 2 ] r2 . Deoarece X 1 = X 2 rezult c t r1 r2 , care este tocmai definiia interseciei. Dac X 1 X 2 = , rezultatul jonciunii este definit pe reuniunea X 1 X 2 i fiecare tuplu va fi derivat din dou tupluri, cte unul din fiecare operand. Condiia ca tuplurile s aib aceleai valori n atributele comune va fi satisfcut ntotdeauna. n acest caz jonciunea devine produs cartezian.

Theta jonciune i echi jonciune

n general produsul cartezian nu prezint interes deoarece combin tuplurile celor doi operanzi ntr-o manier lipsit de semnificaie (vezi figura 3.8).
Exemplu ANGAJAT Angajat Proiect Ionescu A Balint A Balint B PROIECT Cod Nume A Venus B Marte ANGAJAT PROIECT Angajat Proiect Cod Ionescu A A Balint A A Balint B A Ionescu A B Balint A B Balint B B

Nume Venus Venus Venus Marte Marte Marte

Figura 3.8 Produs cartezian

Din aceast cauz a fost introdu un alt operator, cel de theta jonciune, care este de fapt un produs cartezian urmat de o selecie (vezi figura 3.9):

r1 F r2 = F ( r1 r2 ) ,
unde F este condiia de selecie. 25

Exemplu

d o C = t c e i o r

ANGAJAT Angajat Proiect Ionescu A Balint A Balint B

PROIECT Cod Nume A Venus B Marte

(ANGAJAT PROIECT) Proiect A A B Cod A A B Nume Venus Venus Marte

Angajat Ionescu Balint Balint

Figura 3.9 Produs cartezian urmat de o selecie

Definiie. O theta jonciune n care condiia de selecie F este o conjuncie de atomi de egalitate, fiecare atom implicnd cte un atribut din fiecare operand se numete echi jonciune. A treia relaie din figura 3.9 a fost obinut ca rezultat al unei echi jonciuni.

Din punct de vedere practic, theta i echi jonciunea au o importan deosebit. Aceasta deoarece majoritatea sistemelor de gestiune a bazelor de date nu exploateaz avantajele numelor atributelor n combinarea relaiilor. De fapt, interogrile SQL corespund echi jonciunilor, n timp ce jonciunea natural a devenit disponibil doar n versiunile recente de SQL. Este de notat faptul c jonciunea natural poate fi nlocuit cu succesiunea redenumire, echi jonciune i proiecie.
Exemplu Fie r1(ABC) i r2(BCD) dou relaii. r1 r2 poate fi exprimat cu ajutorul operatorilor mai sus amintii astfel: 1) se redenumesc atributele n scopul obinerii unor relaii cu scheme disjuncte
B',C ' B,C ( r2 ) ;

2) se aplic operatorul de echi jonciune, impunnd condiia de egalitate atributelor redenumite

r1 B = B' C = C' ( B',C ' B,C ( r2 ))

3) se aplic operatorul de proiecie pentru a elimina atributele duplicat

A,B,C ,D ( r1 B = B' C = C ' ( B',C' B,C ( r2 )))

3.6 Interogri n algebra relaional

O interogare poate fi definit ca fiind o funcie care, aplicat asupra unei instane a unei baze de date, produce o relaie. Mai exact, dat o schem R a unei baze de date, o interogare este o funcie care, pentru fiecare instan r a lui R, produce o relaie definit pe o mulime X de atribute. n algebra relaional, interogrile unei scheme R de baze de date sunt formulate cu ajutorul unor expresii, ale cror atomi sunt relaii din R.

Exemple Se consider o baz de date format din relaiile: ANGAJAT (NrInreg, Nume, Varsta, Salariu) SUPERVIZOR (NrSup, NrAng)

26

n figura 3.10 este dat o baz de date definit pe aceast schem. ANGAJAT NrInreg Nume 101 Maria Ionescu 103 Maria Balint 104 Lucia Popescu 105 Nicu Luca 210 Marcel Burlacu 231 Alin Lupu 252 Nicu Luca 301 Andrei Popa 375 Maria Ionescu SUPERVIZOR NrSup NrAng 210 101 210 103 210 104 231 105 301 210 301 231 375 252

Varsta 34 23 38 44 49 50 44 34 50

Salariu 40 35 61 38 60 60 70 70 65

Fig.3.10 Baz de date pentru exemplificarea interogrilor n algebra relaional 1) S se gseasc numerele de nregistrare pentru supervizorii acelor angajai ce ctig mai mult de 40.
NrSup ( SUPERVIZOR NrAng = NrInreg ( Salariu > 40 ( ANGAJAT )))

Rezultatul interogrii se poate observa n figura 3.11.a 2) S se gseasc numele i salariile pentru supervizorii acelor angajai ce ctig mai mult de 40. Fiecare tuplu a rezultatului este construit pe baza a trei tupluri, primul din ANGAJAT (despre angajaii care ctig mai mult de 40), al doilea din SUPERVIZOR (care furnizeaz numrul supervizorului angajatului n chestiune) i al treilea din ANGAJAT (cu informaii privind pe supervizori). Intuitiv, soluia necesit jonciunea relaiei ANGAJAT cu rezultatul expresiei precedente, dar este necesar o precizare. n general, supervizorii i angajaii nu sunt aceiai i astfel cele dou tupluri din ANGAJAT care contribuie la tuplul rezultat sunt diferite. Jonciunea trebuie precedat deci de o redenumire.
NumeSup,SalariuSup ( NrInregSup,NumeSup,SalariuSup,VarstaSup NrInreg ,Nume,Salariu ,Varsta ( ANGAJAT ) NrInregSup = NrSup ( SUPERVIZOR NrAng = NrInreg ( Salariu >40 ( ANGAJAT ))))

Rezultatul interogrii se poate observa n figura 3.11.b. 3) S se gseasc numerele de nregistrare i numele supervizorilor ce au numai subalterni ce ctig mai mult de 40. Vom proceda n felul urmtor: se gsesc toi supervizorii pentru care toi subalternii ctig maxim 40; apoi aplicm operatorul de diferen ntre submulimea supervizorilor i mulimea obinut la pasul anterior.
NrInreg ,Nume ( ANGAJAT NrInreg = NrSup ( NrSup ( SUPERVIZOR ) NrSup ( SUPERVIZOR NrAng = NrInreg ( Salariu 40 ( ANGAJAT )))))

NrSup 210 301 375 a)

Nume Salariu Marcel Burlacu 60 Andrei Popa 70 Maria Ionescu 65 b)

NrInreg Nume 301 Andrei Popa 375 Maria Ionescu c)

Fig. 3.11 Rezultatele interogrilor asupra bazei de date din Fig. 3.10 Probleme propuse. 1) S se gseasc numrul de nregistrare, numele i vrsta pentru supervizorii cu salariu mai mare de 40.

27

2) S se gseasc angajaii ce ctig mai mult dect supervizorii lor, incluznd n rezultat numrul de nregistrare, numele i salariul att pentru angajai ct i pentru supervizori.

3.7 Echivalena expresiilor algebrice

Algebra relaional permite formularea unor expresii echivalente ntre ele, adic expresii ce produc acelai rezultat.

Definiie. Spunem c expresiile E1 i E2 sunt echivalente pentru schema R (cu notaia E1 R E2 )

dac E1 ( r ) = E2 ( r ) , pentru orice instan r n R.

Definiie. Spunem c expresiile E1 i E2 sunt echivalente absolut (cu notaia E1 E2 ) dac sunt echivalente pentru orice schema R.
Distincia ntre cele dou cazuri este dat de faptul c atributele operanzilor nu sunt specificate n expresii (n particular n operaiile de jonciune natural).
Exemplu Echivalen absolut: AB ( A>0 ( R )) A>0 ( AB ( R )) Echivalen: AB ( R1 ) AC ( R2 ) R ABC ( R1 R2 ) n ultimul caz, echivalena este valid doar dac n schema R, intersecia dintre mulimile de atribute ale R1 i R2 este atributul A. Dac ar mai exista alt atribut B comun celor dou mulimi, prima jonciune ar opera pe A, n timp ce a doua ar opera pe A i B.

Echivalena expresiilor n algebra relaional joac un rol important n optimizarea cererilor. Cererile SQL sunt translate n domeniul algebrei relaionale i se evalueaz costul acestor cereri. Costul unei cereri este definit n termenii dimensiunii rezultatului intermediar i final. Cnd sunt n discuie mai multe expresii echivalente va fi selectat cea avnd costul cel mai mic. n acest context se utilizeaz transformri de echivalen, acestea substituind o expresie cu o alta echivalent. Prezint interes acele transformri care reduc dimensiunea relaiilor intermediare sau pregtesc o expresie n vederea aplicrii unor astfel de transformri:

atomizarea seleciilor

F1 F2 ( E ) F1 ( F2 ( E )) .

cascadarea proieciilor o proiecie poate fi transformat ntr-o cascad de proiecii care elimin atribute n diverse faze
X ( E ) X ( XY ( E )) ,

dac E este definit pe o mulime de atribute ce include mulimile X i Y. anticiparea seleciei n raport cu jonciunea
F ( E1 E2 ) E1 F ( E2 ) ,

dac F face referire doar la atribute din E2. anticiparea proieciei n raport cu jonciunea. Fie E1 i E2 dou expresii definite pe X1 i X2. Dac Y2 X 2 i Y2 X 1 X 2 atunci

X 1Y2 ( E1 E2 ) E1 Y2 ( E2 )
28

Combinnd aceast regul cu cascadarea proieciilor, obinem echivalena pentru theta jonciune:

Y ( E1 F E2 ) Y ( Y1 ( E1 ) F Y2 ( E2 )) ,
unde X1 atributele expresiei E1,

X2 - atributele expresiei E2, J1 X 1 , J 2 X 2 - submulimi de atribute implicate n F, Y1 = ( X 1 Y ) J 1 , Y2 = ( X 2 Y ) J 2 .

combinarea seleciei i a produsului cartezian pentru a forma theta jonciunea

F ( E1 E2 ) E1 F E2

distributivitatea seleciei n raport cu reuniunea

F ( E1 E2 ) F ( E1 ) F ( E2 )

distributivitatea seleciei n raport cu diferena

F ( E1 E2 ) F ( E1 ) F ( E2 )

distributivitatea proieciei n raport cu reuniunea

X ( E1 E2 ) X ( E1 ) X ( E2 )

Not. Proiecia nu este distributiv n raport cu diferena

F1 F2 ( R ) F1 ( R ) F2 ( R ) F1 F2 ( R ) F1 ( R ) F2 ( R ) F1 ( R ) F2 ( R ) F1 ( F2 )( R ) F1 ( R ) F2 ( R )

Sunt valabile comutativitatea i asociativitatea tuturor operatorilor binari (excluznd diferena) i distributivitatea jonciunii n raport cu reuniunea:

E ( E1 E2 ) ( E E1 ) ( E E2 )

n final, trebuie s fim contieni c prezena unor rezultate intermediare vide (fr nici un tuplu) face posibil simplificarea expresiilor ntr-un mod natural. Este de subliniat faptul c o jonciune (sau produsul cartezian) n care unul din operatori este o relaie vid, produce un rezultat vid.

3.8 Valori NULL n algebra relaional

n cele discutate anterior am presupus c expresiile algebrice sunt aplicate unor relaii ce nu conin valori NULL. innd cont de importana valorilor NULL n aplicaii, vom vedea care este impactul lor asupra limbajelor de interogare i actualizare a datelor.
Exemplu. S considerm relaia din figura urmtoare PERSOANA Nume Varsta Ionescu 35 Popescu 27 Popa NULL Salariu 500 600 500

Figura 3.12 Relaie cu valori NULL

29

i selecia Varsta > 30 ( PERSOANA ) . Primul tuplu va contribui la rezultatul seleciei, iar al doilea tuplu nu. Ce putem spune despre al treilea tuplu (valoarea NULL avnd semnificaia unei informaii pe care o ignoram)?

n raport cu interogrile prezentate anterior vom utiliza o logic trivalent n locul celei bivalente. n aceast logic o formul poate avea valorile de adevr TRUE (T), FALSE (F) sau UNKNOWN (U). Rezultatul unei condiii atomice va avea valoarea de adevr UNKNOWN dac cel puin un termen al comparaiei are valoarea NULL. Revenind la exemplul nostru, expresia va produce o relaie format din primul tuplu, pentru care valoarea de adevr a expresiei a fost TRUE. Tabelele de adevr n logica trivalent pentru conectorii not, and i or sunt:
not F T U U T F and T U F

T T U F

U U U F

F F F F

or T U F

T T T T

U T U U

F T U F

Este de notat c aceast logic trivalent pentru operatorii algebrici prezint unele dezavantaje.
Exemplu S considerm expresia
Varsta > 30 ( PERSOANA ) Varsta 30 ( PERSOANA ) .

Logic, aceast expresie ar trebui s returneze relaia PERSOANA. Pe de alt parte, dac cele dou subexpresii sunt evaluate separat, al treilea tuplu va produce un rezultat necunoscut pentru fiecare subexpresie, deci i pentru reuniune. Numai prin intermediul unei evaluri globale (abordare care nu este practic n cazul expresiilor complexe) putem ajunge la concluzia c un astfel de tuplu trebuie s apar n rezultat.

Cea mai bun metod practic de a depi astfel de dificulti este de a trata valorile NULL din punct de vedere pur sintactic. n acest sens sunt introduse dou noi condiii atomice de selecie pentru a verifica dac o valoare este specificat sau este NULL:

A is NULL este adevrat pentru tuplul t dac t[A] = NULL i fals n rest; A is NOT NULL este adevrat pentru tuplul t dac t[A] NULL i fals n rest.
Exemplu
Varsta > 30 ( PERSOANA ) . returneaz persoanele cu vrsta peste 30 de ani; Varsta > 30 Varsta IS NULL ( PERSOANA ) - returneaz persoanele care au sau care pot avea

peste 30 de ani

Aceast abordare este utilizat n versiunile recente de SQL care suport logica trivalent.

3.9 Vederi
n cele prezentate anterior am vzut c se pot construi reprezentri diferite ale datelor, reprezentri ce vor fi disponibile utilizatorilor. Acest lucru este posibil n modelul relaional prin intermediul relaiilor derivate, al cror coninut este definit pe baza coninutului altor relaii. ntro baz de date relaional exist relaii de baz, al cror coninut este autonom i stocat n baza de date i relaii derivate. Exist dou tipuri principale de relaii derivate:

vederi materiale - relaii derivate stocate n baza de date;

30

relaii virtuale (numite pur i simplu vederi) relaii definite prin intermediul unor funcii (expresii ale limbajului de interogare) care nu sunt stocate n baza de date, dar pot fi folosite n interogri ca i cum ar exista fizic.

n general, vederile materiale ofer un avantaj cnd numrul cererilor de interogare este mai mare dect operaiile de actualizare ale relaiei pe care se bazeaz vederea. Deoarece nu se pot specifica tehnici generale de pstrare a consistenei ntre relaiile de baz i vederile materiale, majoritatea sistemelor comerciale ofer mecanisme numai pentru relaiile virtuale (vederi). Vederile sunt definite n sistemele relaionale ca fiind expresii ale unui limbaj de interogare.
Exemplu S considerm baza de date format din relaiile
R1 ( ABC ),R2 ( DEF ),R3 ( GH ) ,

i vederea definit ca produsul cartezian urmat de o selecie R = A > D ( R1 R2 ) . Pe baza acestei scheme, interogarea
B = G ( R R3 )

va fi executat prin nlocuirea lui R cu definiia sa:

B = G ( A > D ( R1 R2 ) R3 ) .

Utilizarea vederilor poate fi util din mai multe motive:

un utilizator interesat numai de o poriune din baza de date poate evita contactul cu componentele ce nu prezint interes;
Exemplu ntr-o baz de date cu dou relaii avnd schemele ANGAJAT (NrAngajat, Departament) MANAGER (Departament, NrSupervizor), un utilizator interesat doar de angajai i de supervizorii lor ar putea fi ajutat de existena unei vederi definit astfel: NrAngajat , NrSupervizor ( ANGAJAT MANAGER ) .

expresii extrem de complexe pot fi definite cu ajutorul vederilor, existnd anumite avantaje n cazul subexpresiilor repetitive; vederile permit implementarea unui mecanism de protecie a datelor din baza de date; n cazul restructurrii unei baze de date, este convenabil definirea unor vederi corespunztoare relaiilor ce nu mai exist dup restructurare. n acest caz, aplicaiile deja scrise ce fac referire la versiunea anterioar a schemei pot fi utilizate pe noua schem fr a necesita modificri.
Exemplu Presupunem c schema R( ABC ) este nlocuit de schemele R1 ( AB ),R2 ( BC ) . Putem defini vederea
R = R1 R2

i astfel nu va trebui s modificm aplicaiile ce fac referire la R. Dac B este o cheie pentru R2 atunci prezena vederii este complet transparent.

31

Din punct de vedere al interogrilor, vederile pot fi tratate n aceeai manier ca i relaiile. Nu acelai lucru se ntmpl n cazul operaiilor de actualizare. De fapt nu se poate da o semantic pentru actualizarea vederilor.

Exemplu Fie vederea definit anterior

NrAngajat , NrSupervizor ( ANGAJAT MANAGER ) .

S presupunem c dorim s inserm un tuplu n aceast vedere; de fapt dorim s inserm dou tupluri n relaiile de baz care s genereze noul tuplu din vedere. Acest lucru nu este posibil deoarece tuplul din vedere nu implic atributul Departament, atribut care este utilizat n realizarea legturii dintre cele dou relaii de baz. n general, problema actualizrii vederilor este complex, toate sistemele impunnd limitri severe n ceea ce privete actualizarea vederilor.

Probleme propuse
1. Se consider baza de date alctuit din relaiile urmtoare: FILME (NumarFilm, Titlu, Regizor, An, CostProductie) ARTISTI (NumarActor, Nume, Prenume, Sex, DataNastere, Nationalitate) ROLURI ( NumarFilm, NumarActor, Personaj) a). Realizai o baz de date cu relaiile de mai sus pentru care jonciunile ntre diverse relaii sunt complete. b). Presupunnd c exist dou constrngeri de referin ntre relaia ROLURI i celelalte dou relaii, precizai cazurile posibile de jonciuni incomplete. c). Artai un produs cartezian care implic relaii din baza de date prezentat. d). Realizai o baz de date pentru care una (sau mai multe) dintre jonciuni este (sunt) vid (vide). 2. Se consider baza de date de la exemplul 1. Exprimai urmtoarele interogri n algebra relaional: a). S se gseasc titlurile filmelor n care joac Henry Fonda. b). S se gseasc titlurile filmelor pentru care regizorul este i actor. c). S se gseasc actorii care au interpretat dou personaje n acelai film; precizai titlul filmului, numele i prenumele actorului i numele personajelor interpretate. d). S se gseasc titlurile filmelor n care actorii sunt toi de acelai sex. 3. Se consider baza de date care conine urmtoarele relaii: CURSURI (Numar, Facultate, TitluCurs, Titular) STUDENTI (Numar, Nume, Prenume, Facultate) TITULARI (Numar, Nume, Prenume) EXAMENE (Student, Curs, Nota, Data) PLAN_INVATAMANT (Student, Curs, An) Formulai n algebra relaional interogrile care produc: a). studenii care au obinut nota 10 la cel puin un examen, preciznd pentru fiecare numele, prenumele i data cnd au obinut prima not de 10; b). pentru fiecare curs de la Automatic, studenii care au trecut examenul n ultima sesiune; c). studenii care au trecut toate examenele cerute de planul de nvmnt; d). pentru fiecare curs de la Electronic, studenii care au obinut cea mai mare not;

32

e). numele i prenumele studenilor care au luat examenul la un curs al crui titular are acelai nume ca i studentul. 4. Pentru baza de date cu relaiile: ORASE (Nume, Judet, NumarLocuitori) TRAVERSARI (Oras, Ru) RURI (Ru, Lungime), formulai urmtoarele interogri n algebra relaional: a). gsii numele, judeele i numrul de locuitori pentru oraele care au mai mult de 50000 de locuitori i sunt traversate de Siret sau Mure; b). gsii oraele care sunt traversate de cel puin dou ruri, preciznd numele oraului i numele celui mai lung ru care-l traverseaz.

33

Capitolul 4. Calculul relaional

Calculul relaional este o familie de limbaje de interogare, bazate pe calculul cu predicate de ordinul nti. Aceste limbaje sunt declarative, interogarea fiind specificat prin proprietile rezultatului, contnd mai puin procedura ce trebuie urmat pentru a o obine. Spre deosebire de calculul relaional, algebra relaional este un limbaj procedural, deoarece expresiile specific pas cu pas construirea rezultatului. Exist mai multe versiuni de calcul relaional, dar n cele ce urmeaz vom discuta doar despre dou dintre aceste versiuni i anume:

Calculul relaional pe domenii, care prezint caracteristicile de baz ale acestor limbaje; Calculul relaional pe tupluri, care formeaz bazele multor constructori disponibili pentru interogarea n SQL.

4.1 Calculul relaional pe domenii

Expresiile din calculul relaional au forma { A1 : x1 , ..., Ak : xk | f } , unde

A1 ..., Ak - atribute distincte; x1 ..., xk - variabile ( pentru simplitate le vom considera distincte) f - formul construit pe baza urmtoarelor reguli:
a) exist dou tipuri de formule atomice: - R( A1 : x1 , ..., Ap : x p ) , unde R( A1 , ..., Ap ) este o schem relaional i x1 ..., x p variabile; - xy sau xc , cu x i y variabile, c constant i operator de comparaie ( = , , ,< , ,> ). b) dac f1 i f2 sunt formule, atunci f1 f 2 , f1 f 2 i f1 sunt formule. c) dac f este o formul i x variabil ce apare n f atunci x( f ) i x( f ) sunt formule ( este cuantificatorul existenial iar cuantificatorul universal). Lista de perechi A1 : x1 , ..., Ak : xk se numete list int deoarece definete structura

rezultatului. Rezultatul va consta din relaia definit pe A1 ..., Ak care conine tupluri ale cror valori, substituite cu x1 ..., xk , asigur c formula f este adevrat. Valoarea de adevr a unei formule f se stabilete pe baza urmtoarelor reguli: formula atomic R( A1 : x1 , ..., Ap : x p ) este adevrat pentru acele valori ale lui x1 ..., x p

ce formeaz un tuplu n R; formula atomic xy este adevrat pentru acele valori ale lui x i y astfel nct valoarea lui x se afl n relaia cu valoarea lui y; n acelai mod se definete valoarea de adevr a formulei atomice xc ; semnificaia conectorilor , , este cea uzual; x( f ) este adevrat dac exist cel puin o valoare a lui x pentru care formula f este adevrat; 34

x( f ) este adevrat dac formula f este adevrat pentru toate valorile posibile ale lui x.

Vom exemplifica n continuare modul de exprimare a interogrilor n calculul pe domenii.

Exemple Se consider baza de date cu schema: ANGAJAT (NrInreg, Nume, Varsta, Salariu) SUPERVIZOR (NrSup, NrAng). 4) S se gseasc numerele de nregistrare, numele, vrsta i salariul pentru toi angajaii ce ctig mai mult de 40. n algebra relaional:
Salariu > 40 ( ANGAJAT ) .

n calculul relaional pe domenii:

{ NrInreg : m, Nume : n,Varsta : v,Salariu : s | ANGAJAT( m,n,v,s ) s > 40 }

5) S se gseasc numerele de nregistrare pentru supervizorii acelor angajai ce ctig mai mult de 40. n algebra relaional:
NrSup ( SUPERVIZOR NrAng = NrInreg ( Salariu > 40 ( ANGAJAT )))

n calculul relaional pe domenii:

{ NrSup : n | ANGAJAT( NrInreg : m,Nume : u,Varsta : v,Salariu : s ) SUPERVIZOR( NrSup : n, NrAng : m ) s > 40 }

Variabila m, comun ambelor condiii atomice, realizeaz corespondena ntre tuplurile specificate n jonciune. Se pot utiliza cuantificatori existeniali pentru toate variabilele ce nu apar n lista int, dar acest lucru ar complica formularea cererii. Dac ntr-o expresie este necesar implicarea unor tupluri diferite ale aceleai relaii este suficient impunerea mai multor condiii asupra aceluiai predicat din formul, utiliznd variabile diferite. S considerm interogarea: 6) S se gseasc numele i salariile pentru supervizorii acelor angajai ce ctig mai mult de 40. n algebra relaional:
NumeSup,SalariuSup ( NrInregSup,NumeSup,SalariuSup,VarstaSup NrInreg ,Nume,Salariu ,Varsta ( ANGAJAT )
NrInregSup = NrSup

( SUPERVIZOR NrAng = NrInreg ( Salariu 40 ( ANGAJAT ))))

n calculul relaional pe domenii Vom cere ca, pentru fiecare tuplu din rezultat s existe trei tupluri: un tuplu corespunde unui angajat ce ctig mai mult de 40, al doilea tuplu indic supervizorul su i ultimul furnizeaz informaii detaliate despre supervizor:

35

{ NumeSup : ns, SalariuSup : ss | ANGAJAT( NrInreg : ni, Nume : u,Varsta : v,Salariu : s ) s > 40 SUPERVIZOR( NrSup : n, NrAng : ni ) ANGAJAT( NrInreg : n, Nume : ns,Varsta : q,Salariu : ss )}

4) S se gseasc numerele de nregistrare i numele supervizorilor ce au numai subalterni ce ctig mai mult de 40. n algebra relaional:
NrInreg ,Nume ( ANGAJAT NrInreg = NrSup ( NrSup ( SUPERVIZOR ) NrSup ( SUPERVIZOR NrAng = NrInreg ( Salariu 40 ( ANGAJAT )))))

n calculul relaional pe domenii

{ NrInreg : n,Nume : u | ANGAJAT( NrInreg : n,Nume : u,Varsta : v,Salariu : s ) SUPERVIZOR( NrSup : n,NrAng : m ) m'( n'( v'( s'( ANGAJAT( NrInreg : m',Nume : n',Varsta : v',Salariu : s') SUPERVIZOR( NrSup : n,NrAng : m') s' 40 ))))}

O alternativ la aceast expresie se poate obine prin utilizarea cuantificatorului universal:

{ NrInreg : n,Nume : u | ANGAJAT( NrInreg : n, Nume : u,Varsta : v,Salariu : s ) SUPERVIZOR( NrSup : n, NrAng : m ) m'( n'( v'( s'( ( ANGAJAT( NrInreg : m',Nume : n',Varsta : v',Salariu : s') SUPERVIZOR( NrSup : n, NrAng : m')) s' > 40 ))))}

Aceast expresie selecteaz supervizorul n dac pentru orice tuplu de valori m',n',v',s' corespunztor angajailor lui n, s' > 40 . Observaii. Structura f g corespunde condiiei dac f atunci g deoarece este adevrat n toate cazurile cu excepia cazului cnd f este adevrat i g fals. De notat c legile lui de Morgan
( f g ) = ( f ) ( g ) , ( f g ) = ( f ) ( g ) ,

sunt valabile i pentru cuantificatori:

x( f ) ( x( ( f ))) x( f ) ( x( ( f )))

Dezavantaje ale calculului relaional pe domenii

Dei natura declarativ a calculului relaional pe domenii prezint unele aspecte de interes, exist unele limitri ce au importan din punct de vedere practic. De exemplu, expresia

{ A1 : x1 , A2 : x2 | R( A1 : x1 ) x2 = x2 }
produce ca rezultat o relaie pe A1 i A2 format din tupluri ale cror valori pe A1 apar n relaia R, i valoarea pe A2 poate fi orice valoare din domeniu (deoarece condiia x2 = x2 este ntotdeauna adevrat). n particular, dac domeniul se schimb, spre exemplu de la ntreg ntre 0 i 99 la ntreg ntre 0 i 999, rspunsul interogrii se schimb de asemenea. Dac domeniul este infinit, atunci i rezultatul este infinit, ceea ce este de neacceptat. O observaie similar poate fi fcut i referitor la expresia 36

{ A1 : x1 | R( A1 : x1 )}
al crei rezultat este o relaie ce conine acele valori din domeniul A1 care nu apar n relaia R.
Definiie. O expresie a unui limbaj de interogare este independent de domeniu dac rezultatul su n fiecare instan a bazei de date nu variaz dac se modific domeniul pe care se evalueaz expresia. Definiie. Un limbaj este independent de domeniu dac toate expresiile lui sunt independente de domeniu. Pe baza acestor definiii putem afirma c algebra relaional este independent de domeniu (construind rezultatul pe baza relaiilor din baza de date, fr a face referire la domeniile atributelor), n timp ce calculul relaional pe domenii este dependent de domeniu. Spunem ca dou limbaje de programare sunt echivalente dac pentru orice expresie dintr-un limbaj exist o expresie echivalent n cel de-al doilea limbaj i invers. Algebra relaional i calculul pe domenii nu sunt echivalente, deoarece calculul pe domenii permite formularea unor expresii ce sunt dependente de domeniu. Totui aceast echivalen se poate obine dac limitm calculul pe domenii la o submulime de expresii independente de domeniu. Un alt dezavantaj al calculului relaional pe domenii este dat de numrul mare de variabile cerute ntr-o expresie, de obicei o variabil pentru fiecare atribut. De asemenea, ori de cte ori se impune o operaie de cuantificare, cuantificatorii sunt i ei multiplicai. Singurul limbaj bazat, ntr-o anumit msur, pe calculul pe domenii este QBE (Query by Example). n ncercarea de a depi limitrile calculului pe domenii a fost propus o variant a calculului relaional, n care variabilele reprezint tupluri.

4.2 Calculul relaional pe tupluri

Expresiile din calculul pe tupluri au forma

{T | L | f },
unde

L este lista gamei de valori , n care sunt enumerate variabilele libere din formula f, mpreun cu gamele de variaie corespunztoare; de fapt L este o list de elemente de tipul x(R) , cu x variabil i R relaie; dac x(R) este n lista gamei de valori, atunci x va lua valori numai din R. T este lista int, compus din elemente de tipul Y:x.Z (sau mai simplu x.Z ca abreviere pentru Z:x.Z), cu x variabil i Y, Z secvene de atribute; atributele din Z trebuie s apar n schema relaiei ce constituie gama de valori a lui x; vom scrie x.* ca abreviere pentru X:x.X, unde gama de valori a variabilei x este o relaie definit pe atributele X; f este o formul constituit din: - atomi de tipul x.Ac sau x1 .A1x2 .A2 care compar valoarea lui x corespunztoare atributului A cu constanta c i valoarea lui x1 pe atributul A1 cu cea a lui x2 pe atributul A2; - conectori ( , , ); - cuantificatori: x( R )( f ) - exist un tuplu x n relaia R ce satisface f; x( R )( f ) - orice tuplu x din R satisface f.

Not. n timp ce se introduce variabila x, o declaraie a gamei de valori de forma x(R) specific faptul c x poate lua ca valori numai tupluri din relaia R. De aceea, acest limbaj nu necesit
37

formularea unor condiii atomice ca n calculul pe domenii care s indice c un tuplu aparine unei anumite relaii. n continuare vor fi prezentate cteva exemple de interogri formulate n calculul relaional pe tupluri.
Exemple Se consider baza de date cu schema: ANGAJAT (NrInreg, Nume, Varsta, Salariu) SUPERVIZOR (NrSup, NrAng). 1) S se gseasc numerele de nregistrare, numele, vrsta i salariul pentru toi angajaii ce ctig mai mult de 40.
{ e.* | e( ANGAJAT ) | e.Salariu > 40 }

2) S se gseasc numerele de nregistrare pentru supervizorii acelor angajai ce ctig mai mult de 40.
{ s.NrSup | e( ANGAJAT ),s( SUPERVIZOR )| e.NrInreg = s.NrAng e.Salariu > 40 }

3) S se gseasc numele i salariile pentru supervizorii acelor angajai ce ctig mai mult de 40.
{ NumeS ,SalariuS : e' .( Nume,Salariu ) | e'( ANGAJAT ),e( ANGAJAT ),s( SUPERVIZOR )| e' .NrInreg = s.NrSup s.NrAng = e.NrInreg e.Salariu > 40 }

4) S se gseasc numerele de nregistrare i numele supervizorilor ce au numai subalterni ce ctig mai mult de 40.
{ e.( NrInreg , Nume ) | e( ANGAJAT ),s( SUPERVIZOR ) | e.NrInreg = s.NrSup e'( ANGAJAT )( s'( SUPERVIZOR ) ( ( s.NrSup = s' .NrSup s' .NrAng = e' .NrInreg ) e' .Salariu > 40 ))}

O alternativ la aceast expresie se poate obine prin utilizarea cuantificatorului existenial:

{ e.( NrInreg , Nume ) | e( ANGAJAT ),s( SUPERVIZOR )| e.NrInreg = s.NrSup ( e'( ANGAJAT )( s'( SUPERVIZOR ) ( s.NrSup = s' .NrSup s' .NrAng = e' .NrInreg e' .Salariu 40 )))}

Observaii. Nu orice interogare din algebra relaional sau din calculul relaional pe domenii se poate exprima n calculul relaional pe tupluri. Spre exemplu, interogrile care n algebra relaional necesit operatorul reuniune nu pot fi exprimate prin calculul pe tupluri. Dup cum se va vedea n capitolul urmtor, SQL pune la dispoziie posibilitatea construirii n mod explicit a reuniunii, deoarece aspectele declarative ale SQL se bazeaz pe calculul pe tupluri cu declaraia gamei de valori.

Probleme propuse
5. Se consider baza de date alctuit din relaiile urmtoare: FILME (NumarFilm, Titlu, Regizor, An, CostProductie) ARTISTI (NumarActor, Nume, Prenume, Sex, DataNastere, Nationalitate)

38

ROLURI ( NumarFilm, NumarActor, Personaj) Exprimai urmtoarele interogri n calculul relaional pe domenii i n calculul relaional pe tupluri: a). S se gseasc titlurile filmelor n care joac Henry Fonda. b). S se gseasc titlurile filmelor pentru care regizorul este i actor. c). S se gseasc actorii care au interpretat dou personaje n acelai film; precizai titlul filmului, numele i prenumele actorului i numele personajelor interpretate. d). S se gseasc titlurile filmelor n care actorii sunt toi de acelai sex. 6. Se consider baza de date care conine urmtoarele relaii: CURSURI (Numar, Facultate, TitluCurs, Titular) STUDENTI (Numar, Nume, Prenume, Facultate) TITULARI (Numar, Nume, Prenume) EXAMENE (Student, Curs, Nota, Data) PLAN_INVATAMANT (Student, Curs, An) Formulai n calculul relaional pe domenii i n calculul relaional pe tupluri interogrile care produc: a). studenii care au obinut nota 10 la cel puin un examen, preciznd pentru fiecare numele, prenumele i data cnd au obinut prima not de 10; b). pentru fiecare curs de la Automatic, studenii care au trecut examenul n ultima sesiune; c). studenii care au trecut toate examenele cerute de planul de nvmnt; d). pentru fiecare curs de la Electronic, studenii care au obinut cea mai mare not; e). numele i prenumele studenilor care au luat examenul la un curs al crui titular are acelai nume ca i studentul. 7. Pentru baza de date cu relaiile: ORASE (Nume, Judet, NumarLocuitori) TRAVERSARI (Oras, Ru) RURI (Ru, Lungime), formulai urmtoarele interogri n calculul relaional pe domenii i n calculul relaional pe tupluri: a). gsii numele, judeele i numrul de locuitori pentru oraele care au mai mult de 50000 de locuitori i sunt traversate de Siret sau Mure; b). gsii oraele care sunt traversate de cel puin dou ruri, preciznd numele oraului i numele celui mai lung ru care-l traverseaz.

39

Capitolul 5. SQL
SQL este un acronim pentru Structured Query Language i a fost dezvoltat pentru sistemul de gestiune a bazelor de date System R, creat de IBM Research Laboratory, San Jose, California la sfritul anilor 70. SQL a fost standardizat i a devenit limbajul de referin pentru bazele de date relaionale. SQL nu este numai un limbaj de interogare. El conine proprietile unui limbaj de definire a datelor, LDD (comenzi pentru definirea unei scheme a unei baze de date relaionale) i proprietile unui limbaj de manipulare a datelor, LMD (comenzi pentru modificarea i interogarea unei instane a unei baze de date relaionale). De-a lungul timpului au existat mai multe versiuni de SQL, prima definiie a unui standard pentru SQL fiind promulgat n 1986 de ANSI (the American National Standards Institute). Acest prim standard coninea multe din elementele de baz pentru formularea interogrilor, oferind n acelai timp un suport limitat pentru definirea schemei i manipularea ei. n 1989 a aprut versiunea SQL-89, care adaug la versiunea anterioar definiia integritii de referin. Urmtoarea versiune, compatibil n cea mai mare parte cu versiunea anterioar, dar care coninea un numr mare de caracteristici noi, a fost publicat n 1992, fiind cunoscut sub numele de SQL-2. SQL-3 este cea mai recent versiune de SQL, compatibil n totalitate cu SQL-2, dar nu a fost nc adoptat ca standard.

5.1 Definirea datelor n SQL

n aceast seciune vom ilustra utilizarea SQL pentru definirea schemei unei baze de date. nainte de aceasta se prezint notaiile folosite n sintaxa limbajului. Cuvintele cheie vor fi scrise cu caractere normale iar variabilele cu caractere italice. De asemenea: parantezele unghiulare <***> marcheaz termenii; parantezele ptrate [***] indic faptul c termenii delimitai sunt opionali (pot s nu apar sau s apar doar o singur dat); acoladele {***} indic faptul c termenul din interior poate s nu apar sau poate fi repetat de un numr arbitrar de ori; barele verticale indic faptul c unul dintre termenii delimitai de acestea trebuie s apar. Parantezele rotunde trebuie privite ntotdeauna ca i cuvinte cheie ale SQL.
5.1.1 Domenii elementare

SQL pune la dispoziie ase familii de domenii elementare, care pot fi utilizate pentru definirea domeniilor asociate atributelor schemei.

1) Caracter Domeniul caracter permite reprezentarea caracterelor sau a irurilor de caractere. Lungimea irurilor poate fi fix sau variabil. n cazul irurilor de lungime variabil trebuie specificat lungimea maxim. Pentru fiecare schem este specificat un set de caractere implicit (latin, chirilic, grecesc etc.). n cazul n care este necesar folosirea a mai mult de un set de caractere se specific acest lucru pentru fiecare domeniu. Sintaxa este:

character [varying] [(Lungime)] [character set NumeSetCaracter]

Dac lungimea nu este specificat, domeniul reprezint un singur caracter.
Exemplu - ir de caractere de lungime variabil, cu lungimea maxim de 1000 caractere, setul de caractere grecesc character varying (1000) character set Greek

40

2) Bit
Acest domeniu, introdus in SQL-2, este utilizat pentru atribute ce pot avea doar dou valori: 0 sau 1. Se folosete pentru reprezentarea atributelor de tip flag (specific dac un obiect are sau nu o anumit proprietate). SQL pune la dispoziie de asemenea domeniul ir de bii, lungimea irului fiind specificat ca parametru. irurile de bii sunt utile pentru reprezentarea unui grup de proprieti. Sintaxa este:

bit [varying] [(Lungime)]

Exemplu - ir de bii de lungime variabil, cu lungimea maxim de 100 caractere bit varying (100)

3) Domenii numerice exacte

Aceast familie conine domenii ce permit reprezentarea valorilor exacte, de tip ntreg sau cu parte fracionar. SQL pune la dispoziie patru domenii numerice diferite:
numeric [(Precizie [,Scal])] decimal [(Precizie [,Scal])] integer smallint

Domeniile numeric i decimal reprezint numere n baza 10. Parametrul Precizie specific numrul total de digii, iar parametrul Scal indic numrul de digii folosii pentru partea fracionar.
Exemplu decimal (4) valori ntre -9999 i +9999; numeric (6,3) valori ntre -999,999 i +999,999.

Diferena dintre domeniile numeric i decimal const n faptul c domeniul numeric are exact precizia indicat, n timp ce precizia domeniului decimal trebuie luat drept cerina minim. Dac precizia nu este specificat, sistemul utilizeaz valoarea implicit. Dac scala nu este specificat, se presupune a fi zero. Domeniile integer i smallint pot fi utilizate cnd nu este nevoie de parte fracionar. 4) Domenii numerice aproximative Aceste domenii permit descrierea numerelor reale, prin intermediul reprezentrii n virgul mobil, unde fiecare numr corespunde unei perechi mantis exponent. Mantisa este o valoarea fracionar iar exponentul este un ntreg. Valoarea aproximativ a unui numr real se obine nmulind mantisa cu puterea lui 10 specificat prin exponent.
Exemplu
0.17 E16

0.17 1016 ; 0.17 mantis; 16 exponent; valoare = mantis 10

exponent

SQL pune la dispoziie urmtoarele domenii numerice aproximative: 41

 float [(Precizie)] double precision real

Pentru domeniul float se poate furniza, ca parametru, numrul de digii dedicai pentru reprezentarea mantisei (parametrul Precizie). Domeniul double precision reprezint numere cu o precizie ridicat fa de domeniul real.

5) Dat calendaristic i timp Aceast familie de domenii a fost introdus n SQL-2 cu scopul de a oferi un suport pentru gestiunea informaiilor temporale:
date time [(Precizie)] [with time zone] timestamp [(Precizie)] [with time zone]

Fiecare domeniu poate fi structurat pe cmpuri. Domeniul date pune la dispoziie cmpurile year, month i day, domeniul time cmpurile hour, minute i second iar domeniul timestamp pune la dispoziie toate cmpurile celor dou domenii amintite anterior. Pentru domeniile time i timestamp se poate specifica numrul de poziii zecimale utilizate n reprezentarea fraciunilor de secund (parametrul Precizie). Dac parametrul Precizie este omis, domeniul time va folosi precizie 0 (rezoluie la nivel de secund) iar domeniul timestamp va folosi o precizie de 6 (rezoluie la nivel de microsecund). Dac este specificat opiunea with time zone, va fi posibil accesarea a dou cmpuri suplimentare: timezone_hour i timezone_minute (reprezint diferena dintre timpul local i timpul Greenwich).

6) Intervale temporale Aceast familie de domenii ofer posibilitatea reprezentrii intervalelor de timp (de exemplu durata unei aciuni). Sintaxa acestor domenii este:

Interval PrimaUnitateDeTimp [to UltimaUnitateDeTimp],

unde PrimaUnitateDeTimp i UltimaUnitateDeTimp definesc unitile de msur ce trebuie folosite. Grupul unitilor de msur este mprit n dou grupuri distincte: year i month pe de o parte i unitile de la day la second pe de alt parte. Aceast separare are loc deoarece este imposibil compararea exact a zilelor i a lunilor (deoarece o lun poate avea ntre 28 i 31 zile). Prima unitate de timp poate fi nsoit de precizie, care va reprezenta numrul de digii zecimali utilizai pentru reprezentare. Dac cea mai mic unitate este second, putem specifica numrul de poziii zecimale utilizate (precizia). Dac a doua unitate de timp este i prima (deci singura) atunci primul parametru reprezint numrul de poziii zecimale semnificative, iar cel de-al doilea poate reprezenta numrul de poziii zecimale pentru partea fracionar. Dac precizia nu este specificat, se folosete valoarea implicit 2.
Exemplu interval year(5) to month permite reprezentarea intervalelor pn la 99999 ani i 11 luni interval day(4) to second(6) permite reprezentarea intervalelor pn la 9999zile, 23 ore, 59 minute i 59,999999 secunde (precizie de 1 milionime de secund)

42

5.1.2 Definirea schemei bazei de date SQL permite definirea unei scheme de baze de date ca o colecie de obiecte, fiecare schem conine o mulime de domenii, tabele, indici, aserii, vederi i privilegii i este definit cu ajutorul urmtoarei sintaxe:

create schema [NumeSchem] [[authorization] Autorizare] {DefiniieElementeDinSchem}.

Termenul Autorizare reprezint numele utilizatorului proprietar al schemei; dac este omis se consider c utilizatorul care a executat comanda este proprietarul schemei. Dac NumeSchem este omis va fi adoptat ca nume al schemei numele utilizatorului ce a executat comanda. Dup comanda create schema se pot defini obiectele din schema respectiv. n continuare ne vom ocupa de tabele i domenii, urmnd ca mai trziu s revenim asupra celorlalte obiecte al unei scheme.
5.1.3 Definirea tabelelor

Un tabel SQL este format dintr-o mulime ordonat de atribute i o mulime, posibil vid, de constrngeri. Sintaxa ce permite definirea unui tabel este:

create table NumeTabel (NumeAtribut Domeniu [ValoareImplicit] [Constrngeri] {, NumeAtribut Domeniu [ValoareImplicit] [Constrngeri]} [,AlteConstrngeri] )
Fiecare tabel este definit prin furnizarea numelui su (NumeTabel) i a definiiei atributelor sale; fiecare atribut are la rndul su un nume (NumeAtribut), un domeniu i o posibil mulime de constrngeri ce trebuie satisfcute de valorile atributului. Dup ce au fost definite toate atributele, se pot defini alte constrngeri ce implic mai multe atribute. Iniial tabelul nu conine nregistrri, proprietarul deinnd toate privilegiile asupra tabelului, adic drepturi de a accesa i de a modifica datele din tabel.
Exemplu create table Departament ( NumeDept char(20) primary key, Adresa char(50), Ora char(20) )

5.1.4 Domenii utilizator

La definirea tabelelor, pe lng domeniile predefinite pot fi utilizate i domenii definite explicit de utilizator. Comanda SQL pentru definirea unui domeniu utilizator pe baza unui domeniu predefinit este:

create domain NumeDomeniu as DomeniuElementar [ValoareImplicit] [Constrngeri]

Un domeniu este caracterizat deci de un nume, de un domeniu elementar (predefinit sau un alt domeniu utilizator), de o posibil valoare implicit i de o mulime, posibil vid, de constrngeri (condiii ce trebuie ndeplinite de valorile legale din domeniu). SQL-2 nu dispune de constructori de domeniu de tip structur sau vector. Aceast limitare este dat de conceptul de model relaional de date, model ce impune ca toate atributele s fie definite pe domenii elementare. 43

Declaraia domeniilor asociaz un nume de domeniu cu o mulime de constrngeri. Acest lucru este util atunci cnd trebuie s repetm aceeai definiie de domeniu n mai multe tabele.
5.1.5 Valori implicite de domeniu

Termenul ValoareImplicit din definiia domeniilor i a tabelelor indic valoarea ce va fi considerat pentru atributul asociat n cazul inserrii unei linii ce nu specific o valoare pentru acel atribut. Dac este omis specificarea unei valori implicite, atunci se va utiliza valoarea NULL ca valoare implicit. Sintaxa pentru specificarea unei valori implicite este:

default <ValoareGeneric | user | NULL>,

unde
ValoareGeneric este o valoare compatibil cu domeniul asociat; opiunea user seteaz ca valoare implicit numele de login al utilizatorului ce a executat comanda de actualizare a tabelului.

Dac un atribut are asociat un domeniu cu valoare implicit, dar se specific explicit o alt valoare implicit pentru atribut, atunci va avea ctig de cauz valoarea implicit a atributului.
Exemplu NumrCopii smallint default 0 dac se insereaz o linie i nu se specific valoarea pentru acest atribut, atunci acestui atribut i se va atribui valoarea 0.

5.1.6 Constrngeri intra-relaionale

n timpul definirii att a domeniilor ct i a tabelelor exist posibilitatea de a defini constrngeri. Acestea sunt proprieti ce trebuie verificate de fiecare instan a bazei de date. Constrngerile, dup cum am mai precizat ntr-un capitol anterior, se mpart n constrngeri intra-relaionale (implic o singur relaie) i constrngeri inter-relaionale (iau n considerare mai multe relaii). Cele mai simple constrngeri intra-relaionale sunt: not NULL, unique i primary key.

Not Null. Aceast constrngere indic faptul c valoarea NULL nu este admis ca valoare pentru atributul afectat de constrngere. n acest caz valoarea atributului trebuie s fie specificat la inserare. Este posibil inserarea unei linii fr a specifica valoarea unui atribut cu constrngere not NULL doar dac pentru atributul respectiv s-a definit o valoare implicit diferit de valoarea NULL. Specificarea acestei constrngeri se face prin adugarea cuvintelor cheie not NULL la definirea atributului.
Exemplu Nume character(20) not NULL

Unique. O constrngere de tip unique se aplic unui atribut (sau unei mulimi de atribute) dintrun tabel i impune ca atributul, respectiv mulimea de atribute s formeze o (super) cheie. Se impune astfel ca linii diferite s nu conin aceleai valori. Excepie face valoarea NULL, care poate aprea n diverse linii fr a nclca constrngerea. Aceasta se datoreaz faptului c fiecare valoare NULL reprezint o valoare necunoscut diferit de ce a altei valori NULL.
44

Exist dou moduri de definire a acestei constrngeri. Prima variant se utilizeaz doar n cazul n care constrngerea implic un singur atribut i const n adugarea cuvntului cheie unique la definirea atributului.
Exemplu NrInreg numeric(4) unique

A doua variant se aplic n cazul n care constrngerea implic mai multe atribute i const n utilizarea clauzei unique (Atribut{, Atribut}) dup definirea atributelor.
Exemplu Nume character(20) not NULL, Prenume character(20) not NULL, Unique (Nume, Prenume)

Primary key. Aceast constrngere poate fi specificat o singur dat pentru un tabel i poate fi definit pe un singur atribut sau pe o mulime de atribute. Definiia unei astfel de constrngeri implic definirea implicit a unor constrngeri not NULL pentru atributul (atributele) cheii primare.
Exemplu Nume character(20), Prenume character(20), Dept character(15), Salariu numeric(9) default 0, primary key (Nume, Prenume)

5.1.7 Constrngeri inter-relaionale

Dup cum am mai precizat ntr-o seciune anterioar, cele mai importante constrngeri inter-relaionale sunt constrngerile de integritate referenial. Construcia utilizat de SQL pentru definirea acestora este constrngerea de tip foreign key. Aceast constrngere impune ca pentru fiecare linie dintr-un tabel (numit tabel intern), valoarea corespunztoare unui atribut, diferit de NULL, s se regseasc printre valorile unui atribut din liniile unui alt tabel (numit tabel extern). Singura cerin impus de sintax este ca atributul referit din tabelul extern s fie subiectul unei constrngeri unique. Aceast cerin este satisfcut dac atributul n cauz formeaz o cheie primar pentru tabelul extern. Constrngerile de referin pot fi definite n dou moduri. n cazul n care n constrngere este implicat un singur atribut se utilizeaz construcia sintactic references, care indic tabelul extern i atributul asociat.
Exemplu Create table Angajati ( NrInreg Nume Prenume Dept numeric(6) primary key, character(20) not NULL, character(20) not NULL, character(15) references Departament (NumeDept), Salariu numeric(9) default 0, Oras character(15), unique (Nume, Prenume) )

45

Dac legtura se face ntre o mulime de atribute se va utiliza construcia foreign key, plasat dup definirea tuturor atributelor. Aceast construcie listeaz mai nti atributele constrnse din tabelul intern, urmate de numele tabelului extern i de numele atributelor referite.

Exemplu Create table Angajati ( NrInreg Nume Prenume Dept numeric(6) primary key, character(20) not NULL, character(20) not NULL, character(15) references Departament (NumeDept), Salariu numeric(9) default 0, Oras character(15), unique (Nume, Prenume), foreign key (Nume, Prenume) references DatePersonale (Nume, Prenume) )

n cazul constrngerilor discutate pn acum sistemul va rejecta (genernd un mesaj de eroare) orice operaie de actualizare ce violeaz constrngerea. Pentru constrngerea de referin SQL permite utilizatorului selecia aciunii ce va fi executat n cazul violrii constrngerii. Vom ilustra acest aspect considernd exemplul anterior. S considerm constrngerea de tip cheie extern asupra atributului Dept n tabelul ANGAJATI. Constrngerea poate fi violat opernd att asupra liniilor din tabelul intern ANGAJATI ct i asupra liniilor din tabelul extern DEPARTAMENT. Exist doar dou ci de a nclca constrngerea prin modificarea coninutului tabelului intern: prin inserarea unei linii invalide sau prin modificarea atributului Dept. n aceste cazuri nu este oferit un suport special, operaiile fiind pur i simplu rejectate. Pe de alt parte, se ofer opiuni variate de reacie la nclcarea constrngerii de referin determinat de modificarea tabelului extern. Aceast diferen fa de cazul anterior este dat de importana tabelului extern care, din punctul de vedere al aplicaiei, reprezint tabelul principal (master). Tabelul intern (slave) trebuie s se adapteze la schimbrile produse n tabelul extern. Operaiile asupra tabelului extern care pot produce violri ale constrngerii de referin sunt modificarea valorilor atributelor referite i tergerea de nregistrri (n exemplul anterior modificarea atributului NumeDept respectiv tergerea de nregistrri din tabelul DEPARTAMENT). Tipul reaciei la astfel de nclcri ale constrngerii difer n funcie de comanda ce a generat violarea constrngerii. n cazul operaiilor de actualizare este posibil reacia n unul din modurile urmtoare: cascade: noua valoare pentru atributul din tabelul extern va fi atribuit tuturor liniilor corespunztoare din tabelul intern; set NULL: valoarea NULL este asignat atributului din tabelul intern n locul valorii modificate din tabelul extern; set default: atributului din tabelul intern i va fi asignat valoarea implicit n locul valorii modificate n tabelul extern; no action: operaia de actualizare este rejectat. Opiunile disponibile n cazul nclcrii constrngerii de referin prin tergerea de nregistrri din tabelul extern sunt:

46

 cascade: vor fi terse toate liniile din tabelul intern corespunztoare liniei terse din tabelul extern; set NULL: se asigneaz valoarea NULL atributului din tabelul intern n locul valorii terse din tabelul extern; set default: atributul din tabelul intern va primi valoarea implicit n locul valorii terse din tabelul extern; no action: operaia de tergere este rejectat.

Specificarea modului de reacie n cazul violrii unei constrngeri de referin se face imediat dup definirea constrngerii prin sintaxa:

on <delete | update> <cascade | set NULL | set default | no action>

Exemplu Create table Angajati ( NrInreg numeric(6), Nume character(20) not NULL, Prenume character(20) not NULL, Dept character(15) Salariu numeric(9) default 0, Oras character(15), primary key (Nr Inreg), foreign key (Dept) references Departament (NumeDept) on delete set NULL on update cascade, unique (Nume, Prenume) )

5.1.8 Actualizarea schemei unei relaii

Comenzile definite n SQL pentru manipularea schemelor unei baze de date sunt alter i
drop.

Comanda alter. Aceast comand permite modificarea domeniilor i schemelor de tabele i poate avea o varietate de forme:

alter domain NumeDomeniu <set default ValoareImplicit | drop default | add constraint DefiniieConstrngere | drop constraint NumeConstrngere> alter table NumeTabel <alter column NumeAtribut <set default ValoareImplicit | drop default> | add constraint DefiniieConstrngere | drop constraint NumeConstrngere | add column DefiniieAtribut | drop column NumeAtribut> Prin utilizarea celor dou comenzi se pot opera urmtoarele modificri asupra domeniilor i tabelelor: adugare / eliminare constrngeri; modificare valoare implicit;
47

 adugare / eliminare atribute din schema unui tabel.

Not. n momentul definirii unei noi constrngeri, datele din tabel trebuie s satisfac acea constrngere. n caz contrar definiia constrngerii nu va fi validat.
Comanda drop. Aceast comand permite eliminarea datelor de tip schem, domeniu, tabel, vedere sau aserie (constrngere ce nu este asociat unui anumit tabel). Sintaxa comenzii drop este:

drop <schema | domain | table | view | assertion> NumeComponent [<restrict | cascade>]

Opiunea restrict specific faptul c aceast component nu va fi validat n situaia n care componenta nu este vid sau este referit n definiia altei componente. Astfel o schem nu va fi eliminat dac ea conine tabele sau alte componente; un domeniu nu va fi eliminat dac apare n definiia unui tabel .a.m.d. Aceast opiune este implicit. Folosind opiunea cascade componenta este eliminat mpreun cu toate componentele dependente. Eliminarea unei scheme care nu este vid va conduce la eliminarea tuturor obiectelor care intr n componena sa. tergerea unui tabel folosind aceast opiune implic tergerea tuturor liniilor din tabel. Opiunea cascade trebuie utilizat cu mare atenie deoarece n cazul n care exist dependene care nu au fost luate n calcul, rezultatul poate fi diferit de cel scontat. Multe din sistemele comerciale ofer posibilitatea testrii rezultatului comenzii drop cu opiunea cascade nainte de execuia efectiv a comenzii.

5.2 Interogri n SQL

Cererile de interogare exprimate n SQL prezint un aspect declarativ deoarece sunt specificate proprietile rezultatului i nu modul de obinere (SQL urmrete principiile calculului relaional). Cererile SQL sunt pasate pentru execuie optimizatorului de cereri. Optimizatorul de cereri este o component a sistemului de gestiune a bazelor de date care analizeaz cererea, selecteaz o strategie de execuie i formuleaz o cerere echivalent n limbajul procedural intern al sistemului de gestiune a bazelor de date.
5.2.1 Interogri simple

Interogarea unei baze de date poate fi exprimat n SQL prin intermediul instruciunii select, care are sintaxa:

select ExprAtribut [[as] Alias ] {, ExprAtribut [[as] Alias]} from NumeTabel [[as] Alias ] {, NumeTabel [[as] Alias]} [where Conditie]
O cerere SQL va lua n considerare doar liniile ce aparin produsului cartezian al tabelelor listate n clauza from i va stabili liniile ce satisfac condiia exprimat n clauza where. Rezultatul execuiei unei cereri SQL este un tabel, avnd cte o linie pentru fiecare linie selectat de clauza where i ale crui coloane rezult din evaluarea expresiilor ExprAtribut ce apar n clauza select (lista int). Fiecare coloan poate fi redenumit cu ajutorul unui Alias ce urmeaz imediat dup expresie. Tabelele pot fi de asemenea redenumite prin intermediul unui Alias.
Exemplu Se consider o baz de date care conine tabelele ANGAJATI (Nume, Prenume, Dept, Birou, Salariu), DEPARTAMENT (Dept, Adresa, Oras),

48

cu precizarea ca salariul nregistrat este anual. ANGAJATI Nume Ionescu Popescu Popa Dumitrescu Ionescu Manole Luca Vasile

Prenume Maria Ion Stefan Vasile Ion Radu Doru Alina

Dept Birou Salariu Administratie 10 45 Productie 20 36 Administratie 20 40 Distributie 16 45 Planificare 14 80 Planificare 7 73 Administratie 75 40 Productie 20 46

DEPARTAMENT Dept Adresa Administratie Independentei Productie Primaverii Distributie Central Planificare Nicolina Cercetare Trandafirului

Oras Iasi Bucuresti Focsani Iasi Cluj

Fig. 5.1 Coninutul tabelelor ANGAJATI i DEPARTAMENT Interogarea 1: S se gseasc salariile angajailor cu numele Ionescu. select Salariu as SalariuAnual from Angajati where Nume = Ionescu Rezultatul acestei interogri se poate observa n figura 5.2 Salariu 45 80 Fig. 5.2. Rezultatul interogrii 1

Lista int. Lista int specific elementele schemei tabelelor rezultat. Caracterul special * poate s apar n lista int i reprezint selecia tuturor atributelor tabelelor precizate n clauza from.
Exemplu Interogarea 2: S se gseasc toate informaiile referitoare la angajatul cu numele Ionescu. select * from Angajati where Nume = Ionescu Rezultatul acestei interogri se poate observa n figura 5.3 Nume Prenume Dept Birou Salariu Ionescu Maria Administratie 10 45 Ionescu Ion Planificare 14 80 Fig. 5.3 Rezultatul interogrii 2

49

Lista int poate conine expresii ce utilizeaz valorile atributelor din fiecare linie selectat.
Exemplu Interogarea 3: Gsii salariul lunar al angajailor cu numele Popescu. Rezultatul este prezentat n figura 5.4. select Salariu/12 as SalariuLunar from Angajati where Nume = Popescu SalariuLunar 3.00 Fig. 5.4 Rezultatul interogrii 3

Clauza from. Dac o interogare implic nregistrri din mai multe tabele, argumentul din clauza from va reprezenta o list de tabele. Condiiile din clauza where sunt aplicate n acest caz produsului cartezian al acestor tabele; se poate specifica o jonciune prin indicarea explicit a comparaiilor ntre atribute din tabele diferite.
Exemplu Interogarea 4: S se gseasc numele angajailor i oraele n care acetia lucreaz. select Angajati.Nume, Angajati.Prenume, Departament.Oras from Angajati, Departament where Angajati.Dept = Departament.Dept Rezultatul este prezentat n figura 5.5.

Nume Ionescu Popescu Popa Dumitrescu Ionescu Manole Luca Vasile

Prenume Maria Ion Stefan Vasile Ion Radu Doru Alina

Oras Iasi Bucuresti Iasi Focsani Iasi Iasi Iasi Bucuresti

Fig. 5.5 Rezultatul interogrii 4

n interogarea precedent s-a folosit operatorul punct (.) pentru identificarea tabelului din care se extrag atributele. Folosirea acestei construcii este necesar n cazul n care tabelele din clauza from au atribute cu acelai nume, pentru a distinge ntre referinele la atribute omonime. n cazul n care nu exist posibilitatea apariiei unei ambiguiti se poate specifica atributul fr a preciza tabelul cruia i aparine. ntr-o interogare se pot utiliza alias-uri pentru tabele cu scopul de a scurta referina la acestea.

50

Exemplu Interogarea 4 se poate exprima astfel select a.Nume, a.Prenume, d.Oras from Angajati a, Departament d where a.Dept = d.Dept

Clauza where. Condiia din clauza where este o expresie boolean format prin combinarea predicatelor simple cu operatorii and, or i not. Fiecare predicat simplu utilizeaz operatorii de comparaie (=, >, >=, <, <=, <>) i are, ntr-un membru, o expresie format din valori ale atributelor dintr-o linie i n cellalt membru o valoarea constant sau o alt expresie. Prioritar este operatorul not, dar nu se introduce o preceden ntre and, i or. Dac ntr-o expresie se folosesc ambii operatori and i or este indicat specificarea precedenei prin utilizarea parantezelor.
Exemplu Interogarea 5: S se gseasc prenumele angajailor cu numele Ionescu care lucreaz n departamentele Administratie sau Productie. select Prenume from Angajati where Nume = Ionescu and (Dept = Administratie or Dept = Productie) Rezultatul este prezentat n figura 5.6. Prenume Maria Fig. 5.6 Rezultatul interogrii 5

Pentru compararea irurilor de caractere SQL pune la dispoziie operatorul like. Acest operator compar un ir cu alt ir, specificat parial cu ajutorul caracterelor speciale _ i %. Caracterul _ substituie un caracter oarecare iar % substituie un ir oarecare de caractere, posibil vid.
Exemplu Comparaia like ab%ba_ va fi satisfcut de toate irurile de caractere ce ncep cu secvena ab i au n componen perechea ba nainte de ultimul caracter.

Gestiunea valorilor NULL. Pentru selecia atributelor avnd valori NULL SQL prevede predicatul is NULL care este adevrat doar dac atributul are valoarea NULL. Predicatul is not NULL este adevrat n caz contrar celui prezentat anterior. Sintaxa este:

Atribut is [not] NULL

Duplicate. O diferen major ntre SQL i algebra, respectiv calculul relaional const n gestiunea nregistrrilor duplicat. n algebra relaional i n calculul relaional un tabel este vzut ca o relaie matematic, mai exact ca o mulime de tupluri distincte ntre ele. n SQL un tabel poate avea mai multe linii ce conin aceleai valori pentru toate atributele (duplicate). Dac se dorete emularea comportrii din algebra relaional n SQL ar trebui eliminate toate duplicatele la fiecare execuie a unei operaii de proiecie. Deoarece operaia de eliminare a duplicatelor este consumatoare de timp i adesea nu este necesar, executarea acestei operaii este lsat la latitudinea persoanei ce implementeaz interogarea.

51

Eliminarea duplicatelor este specificat prin cuvntul cheie distinct, plasat imediat dup

select:

select [<distinct | [all]>]

Opiunea all indic faptul c vor fi pstrate toate nregistrrile din rezultat (deci inclusiv duplicatele) i este opiunea implicit.
Exemplu Se consider tabelul PERSOANA (Cod, Nume, Prenume, Oras) prezentat n figura urmtoare: PERSOANA Cod Nume IS001122 Ionescu BC012345 Popescu IS123456 Ionescu SV342345 Ionescu

Prenume Maria Ion Vasile Radu

Oras Iasi Bucuresti Iasi Suceava

Fig. 5.7 Coninutul tabelei PERSOANA Interogarea 6: S se gseasc oraele n care locuiesc persoanele cu numele Ionescu. select Oras from Persoana where Nume = Ionescu Interogarea 7: S se gseasc oraele n care locuiesc persoanele cu numele Ionescu, fiecare ora aprnd o singur dat. select distinct Oras from Persoana where Nume = Ionescu Prin executarea celor dou interogri se obin rezultatele din figura 5.8 Oras Iasi Iasi Suceava Oras Iasi Suceava

Fig. 5.8 Rezultatele interogrilor 6 i 7

Jonciuni. SQL-2 introduce o sintax alternativ pentru specificarea jonciunilor, fiind astfel posibil realizarea unei distincii ntre condiiile ce reprezint condiii de jonciune i cele ce reprezint selecii de linii. Sintaxa propus este:

select ExprAtribut [[as] Alias] {, ExprAtribut [[as] Alias]} from NumeTabel [[as] Alias] {[TipJonctiune] join NumeTabel [[as] Alias] on CondJonctiune} [where AlteConditii]

52

n acest fel, condiia de jonciune este mutat din clauza where n clauza from. Parametrul TipJonctiune specific tipul jonciunii: inner, left sau full. Inner join corespunde theta-jonciunii din algebra relaional.
Exemplu Interogarea 4 se poate rescrie sub forma select Nume, Prenume, Oras from Angajati a inner join Departament d on a.Dept = d.Dept

n cazul unei jonciuni, liniile dintr-un tabel ce nu au linii corespondente n cellalt tabel vor fi eliminate din rezultat. Pentru a fora apariia unor astfel de linii n rezultat se poate apela la jonciunea extern, cu cele trei variante: left join furnizeaz acelai rezultat ca i inner join, dar include liniile tabelului ce apare n stnga jonciunii pentru care nu exist linii corespondente n tabelul din dreapta; right join pstreaz liniile tabelului din dreapta ce nu au corespondent n tabelul din stnga; full join furnizeaz acelai rezultat ca i inner join, suplimentat cu liniile excluse din ambele tabele.
Exemplu Se consider o baz de date care conine tabelele SOFERI (Nume, Prenume, ID) i AUTOVEHICULE (NrInreg, Marca, Model, ID) prezentate n figura 5.9. SOFERI Nume Ionescu Popescu Popa

Prenume Maria Ion Stefan

ID VR 001Y PZ 111B AP 222C

AUTOVEHICULE NrInreg Marca IS01AAA BMW SV02BBB BMW IS02CCC Lancia IS01EFD BMW

Model 323 Z3 Delta 316

ID VR 001Y VR 001Y PZ 111B MI 222C

Fig. 5.9 Coninutul tabelelor SOFERI i AUTOVEHICULE Interogarea 8: S se gseasc oferii ce dein autovehicule, incluznd i oferii fr autovehicule. select Nume, Prenume, Soferi.ID, NrInreg, Marca, Model from Soferi left join Autovehicule on (Soferi.ID = Autovehicule.ID) Rezultatele sunt prezentate n figura 5.10 Nume Prenume ID Ionescu Maria VR 001Y Ionescu Maria VR 001Y Popescu Ion PZ 111B Popa Stefan AP 222C

NrInreg IS01AAA SV02BBB IS02CCC NULL

Marca BMW BMW Lancia NULL

Model 323 Z3 Delta NULL

Fig. 5.10 Rezultatul interogrii 8

53

Interogarea 9: S se gseasc toi oferii i toate mainile mpreun cu posibilele relaii ntre ele. select Nume, Prenume, Soferi.ID, NrInreg, Marca, Model from Soferi full join Autovehicule on (Soferi.ID = Autovehicule.ID) Rezultatele sunt prezentate n figura 5.11 Nume Ionescu Ionescu Popescu Popa NULL Prenume Maria Maria Ion Stefan NULL ID VR 001Y VR 001Y PZ 111B AP 222C NULL NrInreg IS01AAA SV02BBB IS02CCC NULL IS01EFD Marca BMW BMW Lancia NULL BMW Model 323 Z3 Delta NULL 316

Fig. 5.11 Rezultatul interogrii 9

Unele implementri de SQL specific jonciunea extern prin adugarea unui caracter special sau a unei secvene de caractere (* sau (+)) la atributele implicate n condiia de jonciune.
Exemplu Interogarea 8 se poate exprima sub forma select Nume, Prenume, Soferi.ID, NrInreg, Marca, Model from Soferi , Autovehicule where Soferi.ID * = Autovehicule.ID

SQL-2 ofer posibilitatea realizrii jonciunii naturale (jonciune pe baza atributelor cu acelai nume) a dou tabele prin utilizarea cuvntului cheie natural n faa tipului jonciunii.
Exemplu Interogarea 9 se poate exprima sub forma select Nume, Prenume, Soferi.ID, NrInreg, Marca, Model from Soferi natural full join Autovehicule

n mod normal, jonciunea natural nu este disponibil n sistemele comerciale. Motivele acestei excluderi sunt : - comportarea unei interogri se poate modifica n mod semnificativ ca rezultat al unei mici modificri a schemei; - jonciunea natural impune analizarea complet a schemelor tabelelor implicate, cu scopul de a nelege condiia de jonciune.

Utilizarea variabilelor. Am vzut mai nainte cum se pot asocia nume alternative, numite aliasuri, tabelelor din clauza from i avantajele folosirii acestora. Prin folosirea alias-urilor se poate referi un tabel de mai multe ori, ntr-un mod similar operatorului de redenumire din algebra relaional. De fiecare dat cnd este introdus un alias, se declar o variabil de tip tabel care are ca valoare coninutul tabelului pentru care se introduce alias-ul. Cnd un tabel apare doar o singur dat n interogare, nu este nici o diferen n a

54

interpreta alias-ul ca pseudonim sau ca o nou variabil. Cnd tabelul apare de mai multe ori este esenial s privim alias-ul ca o nou variabil.

Exemplu Interogarea 10: Se consider baza de date din figura 5.1. S se gseasc toi angajaii ce au acelai nume (dar prenume diferite) cu un angajat care lucreaz n departamentul Producie. select a1.Nume, a1.Prenume from Angajati a1, Angajati a2 where a1.Nume = a2.Nume and a1.Prenume <> a2.Prenume and a2.Dept = Productie

Utilizarea alias-urilor de tabel are importan din urmtoarele puncte de vedere: se evit necesitatea scrierii ntregului nume al tabelului ori de cte ori este cerut acest lucru; se poate face referire de mai multe ori la acelai tabel; introducerea unui alias are semnificaia declarrii unei variabile de tip tabel, ce are acelai coninut cu tabelul al crui alias este; se pot specifica cererile imbricate.
Ordonarea. n general, rezultatul unei interogri conine linii, aranjate ntr-o ordine oarecare. Dac se dorete impunerea unei ordonri dup un anumit criteriu asupra liniilor returnate de o interogare se va utiliza clauza order by. Sintaxa este:

order by Atribut [asc | desc] {, Atribut [asc | desc]}

Exemplu Se consider baza de date din figura 5.9. Interogarea 11: Extragei coninutul tabelului AUTOVEHICULE n ordine descendent dup Marc i Model. select * from Autovehicule order by Marca desc, Model desc Rezultatul este prezentat n figura urmtoare NrInreg IS02CCC SV02BBB IS01AAA IS01EFD Marca Lancia BMW BMW BMW Model Delta Z3 323 316 ID PZ 111B VR 001Y VR 001Y MI 222C

Fig. 5.12 Rezultatul interogrii 11

55

5.2.2 Interogri agregate

Operatorii agregai constituie una din cele mai importante extensii ale SQL n comparaie cu algebra relaional. n algebra relaional toate condiiile sunt evaluate pentru un singur tuplu la un moment dat. Adesea apare necesitatea evalurii unor proprieti ce depind de o mulime de tupluri (de exemplu aflarea numrului de angajai ce lucreaz n departamentul Producie). Operatorii agregai sunt:
count. Operatorul count are urmtoarea sintax:

count ( < * | [distinct | all] ListaAtribute>)

Opiunea * returneaz numrul de linii din rezultat. Opiunea distinct returneaz numrul valorilor distincte pentru lista de atribute din rezultat. Opiunea all returneaz numrul liniilor ce conin valori diferite de NULL pentru lista de atribute. Dac se specific un atribut fr un distinct sau all se consider opiunea implicit all.
Exemplu Se consider baza de date din figura 5.1 Interogarea 12: S se gseasc numrul angajailor din departamentul Productie. select count (*) from Angajati where Dept = Productie Interogarea 13: S se gseasc numrul valorilor distincte pentru atributul Salariu pentru toi angajaii din tabela ANGAJAI. select count (distinct Salariu) from Angajati Interogarea 14: S se gseasc numrul de linii din tabelul ANGAJATI care au valori diferite de NULL pentru atributul Salariu. select count (all Salariu) from Angajati

sum, max, min, avg. Aceti operatori au urmtoarea sintax:

<sum | max | min | avg> ([distinct | all] ExprAtribut)

Aceti operatori se aplic liniilor selectate de clauza where a interogrii i au urmtoarele semnificaii: - sum returneaz suma valorilor deinute de expresia atribut; - max i min returneaz valoarea maxim, respectiv minim; - avg returneaz media valorilor expresiei atribut. Expresia atribut ExprAtribut poate fi un atribut sau o expresie. Operatorii sum i avg accept ca argument expresii ce reprezint valori numerice sau intervale de timp. Funciile min si max necesit definirea unei ordini n expresia atribut, fiind aplicabile i asupra irurilor de caractere i momentelor de timp. 56

Cuvintele cheie distinct i all au semnificaiile discutate deja la operatorul count.

Exemplu Interogarea 15: S se gseasc salariul maxim, mediu i minim pentru toi angajaii din tabela ANGAJAI. select max(Salariu), avg(Salariu), min(Salariu) from Angajati Interogarea 16: S se gseasc salariul maxim pentru angajaii care lucreaz ntr-un departament din Iasi. select max(Salariu) from Angajati a, Departament d where a.Dept = d.Dept and Oras = Iasi

5.2.3 Interogri group by

Funciile agregat prezentate opereaz pe toate liniile returnate de interogare. n cazul n care se dorete utilizarea funciilor agregat pe o submulime a liniilor selectate SQL pune la dispoziie clauza group by. Aceast clauz specific modul n care va fi mprit tabelul n submulime de linii. Clauza accept ca argument o mulime X de atribute, iar interogarea va opera separat pe fiecare mulime de linii ce posed aceleai valori pentru X. Pentru a nelege mai bine semnificaia clauzei group by s analizm urmtorul exemplu:
Exemplu Se consider tabela ANGAJAI din figura 5.1 Interogarea 17: S se gseasc suma salariilor angajailor din acelai departament. select Dept, sum(Salariu) from Angajati group by Dept ntr-o prim faz interogarea este executat fr a ine cont de clauza group by. De fapt se execut interogarea select Dept, Salariu from Angajati Rezultatul acestei interogri este prezentat n figura 5.13. Dept Salariu Administratie 45 Productie 36 Administratie 40 Distributie 45 Planificare 80 Planificare 73 Administratie 40 Productie 46 Fig. 5.13 Proiecia pe atributele Dept i Salariu a tabelei ANGAJAI Tabelul rezultat este apoi mprit n mulimi ce au aceeai valoare pentru atributele listate n clauza group by. Rezultatul acestei grupri este dat n figura 5.14.

57

Dept Salariu Administratie 45 Administratie 40 Administratie 40 Productie 36 Productie 46 Distributie 45 Planificare 80 Planificare 73 Fig. 5.14 Regrupare n acord cu valorile atributului Dept Odat stabilite grupurile de linii, funcia agregat se aplic fiecrui grup n parte. Rezultatul final al interogrii este tabelul din figura 5.15. Dept Salariu Administratie 125 Productie 82 Distributie 45 Planificare 153 Fig. 5.15 Rezultatul final al interogrii

Sintaxa SQL impune restricia ca, ori de cte ori este utilizat clauza group by, atributele ce pot aprea n clauza select s fie o submulime a atributelor din clauza group by. Motivul acestei restricii va fi prezentat prin urmtorul exemplu.
Exemplu Se consider tabelul ANGAJATI din figura 5.1. Fie interogarea select Birou from Angajati group by Dept Aceast interogare este incorect, deoarece pentru aceeai valoare a atributului Dept, atributul Birou deine mai multe valori. Dup ce liniile au fost grupate dup atributul Dept, fiecare grup trebuie s corespund unei singure linii n tabelul returnat de interogare. Interogarea corect este select Birou from Angajati group by Dept, Birou

Pentru a lua n considerare doar grupurile de linii ce satisfac anumite condiii trebuie utilizat clauza having. Dac aceste condiii pot fi verificate la nivel de linie, atunci este suficient utilizarea predicatelor corespunztoare ca argument al clauzei where. Clauza having conine condiii ce trebuie aplicate la terminarea execuiei interogrii ce utilizeaz clauza group by. Fiecare submulime de linii va participa la formarea rezultatului doar dac satisface condiia din clauza having. Sintaxa permite ca n clauza having s apar expresii booleene, formate din predicate simple i operatori booleeni. Predicatele simple pot fi: comparaii ntre rezultatul evalurii unei funcii agregat i o expresie generic comparaii ntre atribute ce formeaz clauza group by i o expresie generic. Se recomand ca n clauza having s apar doar predicatele ce implic o funcie agregat i restul predicatelor s fie incluse n contextul clauzei where. 58

Exemplu Se consider tabelul ANGAJATI din figura 5.1. Interogarea 18: S se gseasc departamentele n care salariul mediu al angajailor din biroul 20 este mai mare ca 25. select Dept from Angajati where Birou = 20 group by Dept having avg(Salariu) > 25

Forma complet a unei instruciuni select este

InterogareSQL ::= select ListaTinta from ListaTabele [where Conditie] [group by ListaAtributeGrupare] [having ConditieAgregata] [order by ListaAtributeOrdonare]

5.2.4 Interogri cu operatori din teoria mulimilor

SQL pune la dispoziie operatori din teoria mulimilor, cum ar fi operatorii de reuniune (union), intersecie (intersect) i diferen (except sau minus). Este de notat c orice interogare ce utilizeaz operatorii de intersecie i diferen poate fi exprimat cu ajutorul interogrilor imbricate. Sintaxa pentru utilizarea operatorilor din teoria mulimilor este:

InterogareSQL {<union | intersect | except> [all] InterogareSQL}

Operatorii din teoria mulimilor presupun eliminarea duplicatelor ca opiunea implicit. Dac se dorete utilizarea acestor operatori cu meninerea duplicatelor este suficient specificarea opiunii all.

Observaie. SQL nu impune ca schemele pe care se execut operaiile s fie identice (spre deosebire de algebra relaional), ci doar ca atributele s aib domenii compatibile. Corespondena ntre atribute nu se bazeaz pe nume, ci pe poziia atributelor. Dac atributele au nume diferite, rezultatul va prelua numele de atribute din primul operand.
Exemple Se consider tabelul ANGAJATI din figura 5.1. a) S se gseasc numele i prenumele tuturor angajailor. select Prenume as NumeAngajat from Angajati union select Nume from Angajati b) S se gseasc numele de angajai care sunt i prenume select Prenume as NumeAngajat from Angajati intersect select Nume

59

from Angajati c) S se gseasc numele de angajai care nu sunt i prenume select Prenume as NumeAngajat from Angajati except select Nume from Angajati NumeAngajat Ionescu Popescu Popa Dumitrescu Manole Luca Vasile Maria Ion Stefan Radu Doru Alina a) NumeAngajat Vasile NumeAngajat Ionescu Popescu Popa Dumitrescu Manole Luca

b)

c)

Fig 5.16 Rezultatul interogrilor a), b) i c)

5.2.5 Interogri imbricate Pn acum toate interogrile formulate conineau n clauza where o condiie compus, n care fiecare predicat reprezint o comparaie ntre dou valori. Se pot defini predicate cu structur complex, n care o expresie valoric poate fi comparat cu rezultatul execuiei unei interogri SQL. Interogarea utilizat n comparaie se definete n interiorul predicatului din clauza where i se numete interogare imbricat. n general, primul operand al unei comparaii de genul celei amintite anterior este un atribut, n timp ce n cellalt membru avem o mulime de valori (rezultatul interogrii). Pentru a rezolva aceast problem a eterogenitii termenilor comparaiei, SQL pune la dispoziie cuvintele cheie any i all pentru a extinde operatorii de comparaie. Cuvntul cheie any specific faptul c linia este valid dac valoarea atributului se afl n relaie cu cel puin o valoare returnat de interogarea imbricat. Cuvntul cheie all specific faptul c linia este valid dac valoarea atributului se afl n relaie cu toate valorile returnate de interogare. Sintaxa cere ca domeniul elementelor returnate de interogarea imbricat s fie compatibil cu atributul cu care se face comparaia.
Exemplu Se consider tabelele ANGAJATI i DEPARTAMENT prezentate n figura 5.1. Interogarea 19: S se gseasc angajaii ce lucreaz ntr-un departament din Iai. select Nume, Prenume from Angajati where Dept = any (select Dept from Departament where Oras = Iasi) Observaie. Aceast interogare poate fi rezolvat prin realizarea unei jonciuni ntre cele dou tabele.

60

Interogarea 20: S se gseasc departamentele n care nu lucreaz nici un angajat cu numele Ionescu. select Dept from Departament where Dept <> all (select Dept from Angajati where Nume = Ionescu) Aceast interogare poate fi exprimat cu ajutorul operatorului diferen: select Dept from Departament except select Dept from Angajati where Nume = Ionescu

SQL pune la dispoziie doi operatori pentru a reprezenta apartenena la o mulime i negaia sa: in i not in. Aceti operatori sunt echivaleni cu = any, respectiv <> all. S mai facem observaia c funciile agregat max i min pot fi utilizate n interogrile imbricate.
Exemplu Se consider tabelele ANGAJATI i DEPARTAMENT prezentate n figura 5.1. Interogarea 21: S se gseasc departamentele n care lucreaz angajaii ce ctig cel mai mare salariu. select Dept from Angajati where Salariu = any (select max(Salariu) from Angajati) sau select Dept from Angajati where Salariu >= all (select Salariu from Angajati) Observaii. Dei cele dou interogri sunt echivalente, este indicat folosirea funciilor agregat deoarece sunt mai concludente i se execut mai eficient. n cazul primei interogri nu exist nici o diferena dac n loc de operatorul any se folosete operatorul all (deoarece interogarea intern are ca rezultat o singur linie).

Pentru a nelege mecanismul rezolvrii interogrilor ce conin interogri imbricate se pleac de la presupunerea c interogarea imbricat se execut naintea analizei liniilor din interogarea extern. Rezultatul interogrii poate fi salvat ntr-o variabil temporar i predicatul interogrii externe poate fi evaluat cu ajutorul rezultatului temporar. Uneori interogarea imbricat face referire la contextul interogrii n care este imbricat; acest lucru are loc prin intermediul unei variabile definit n interogarea extern i utilizat n cea intern. Un astfel de mecanism este cunoscut sub numele de transferul legturilor dintr-un 61

context n altul. n acest caz, noua interpretare pentru interogrile imbricate este urmtoarea: pentru fiecare linie din interogarea extern se evalueaz mai nti interogarea imbricat i apoi se evalueaz predicatul din interogarea extern. Exist o restricie privind vizibilitatea variabilelor SQL. O variabil poate fi utilizat doar n interiorul interogrii n care este definit sau n interogarea imbricat din interogarea n care este definit. Dac o interogare conine interogri imbricate pe acelai nivel, variabilele declarate n clauza from a unei interogri nu pot fi utilizate n contextul celeilalte interogri. Vom exemplifica semnificaia interogrilor imbricate complexe mpreun cu descrierea unui operatorului logic exists. Acest operator accept ca parametru o interogare imbricat i returneaz valoarea adevrat doar dac interogarea nu produce un rezultat vid.
Exemplu Se consider relaia PERSOANA din figura 5.7. Interogarea 22: S se gseasc persoanele care au acelai nume i prenume, dar coduri diferite. select * from Persoana P where exists (select * from Persoana P1 where P1.Nume = P.Nume and P1.Prenume = P.Prenume and P1.Cod <> P.Cod ) n acest caz nu se poate executa interogarea imbricat naintea evalurii interogrii externe, dat fiind c interogarea imbricat nu este definit pn cnd nu se asigneaz o valoare variabilei P. Este necesar n schimb s se evalueze interogarea imbricat pentru fiecare linie produs n cadrul interogrii externe. n exemplul prezentat vor fi examinate mai nti liniile variabilei P una cte una. Pentru fiecare din aceste linii va fi executat interogarea imbricat. Aceast interogare poate fi formulat realiznd o jonciune a tabelei PERSOANA cu ea nsi.

O alt cale de a formula interogarea din exemplul anterior este prin folosirea constructorului de tuplu, reprezentat de o pereche de paranteze rotunde care marcheaz lista de atribute.
Exemplu Se consider relaia PERSOANA din figura 5.7. Interogarea 23: S se gseasc toate persoanele ce nu au omonime. select * from Persoana P where (Nume, Prenume) not in (select Nume, Prenume from Persoana P1 where P1.Cod <> P.Cod )

Sistemele comerciale nu rezolv ntotdeauna interogrile imbricate prin scanarea tabelului extern i producerea unei interogri pentru fiecare linie din relaie. n schimb ncearc s proceseze ct mai multe interogri ntr-o manier orientat pe mulimi, cu scopul de a manevra cantiti mari de date prin ct mai puine operaii posibile.

62

5.3 Modificarea datelor n SQL

Limbajele de manipulare a datelor includ instruciuni pentru interogarea i modificarea bazei de date. Pentru modificarea coninutului unei baze de date SQL pune la dispoziie instruciunile insert, delete i update.
5.3.1 Inserri n baza de date

Sintaxa instruciunii insert este:

insert into NumeTabel [(ListaAtribute)] <values (ListaValori) | InterogareSQL>

Prima variant permite inserarea unei singure linii n tabele. Argumentul clauzei values reprezint valorile atributelor pentru linia inserat.
Exemplu insert into Departament (Dept, Oras) values (Producie, Suceava)

A doua variant permite adugarea unei mulimi de linii, care sunt extrase mai nti din baza de date.
Exemplu insert into DepartamenteIasi (select Dept, Adresa from Departament where Oras = Iasi) Comanda anterioar insereaz n tabelul DepartamenteIasi liniile din tabelul Departament care au Iasi ca valoare a atributului Oras.

Dac valorile pentru anumite atribute nu sunt specificate n momentul inserrii, se vor asigna valori implicite sau valori NULL n cazul n care nu sunt definite valori implicite. Corespondena ntre atributele tabelului i valorile ce urmeaz a fi inserate este dictat de ordinea n care termenii apar n definiia tabelului. Astfel primul element din ListaValori (n cazul primei variante) sau primul element din lista int (n cazul celei de-a doua variante) trebuie s corespund primului element ce apare n ListaAtribute (sau n definiia tabelului dac ListaAtribute este omis) i aa mai departe pentru celelalte atribute.

5.3.2 tergerea nregistrrilor

Sintaxa instruciunii delete este:

delete from NumeTabel [where Conditie]

Dac nu se specific clauza where se vor terge toate nregistrrile din tabel. n cazul n care instruciunea delete conine clauza where se vor terge doar acele nregistrri ce satisfac condiia precizat. Condiia poate conine i interogri imbricate ce fac referire la coninutul altor tabele. n cazul n care exist constrngeri de referin cu opiunea cascade n care tabelul este referit tergerea unor linii din tabel poate duce la tergerea unor linii aparinnd altor tabele.
Exemplu delete from Departament where Dept not in (select Dept from Angajati) Comanda de mai sus terge departamentele fr angajai.

63

Este de notat diferena dintre comanda delete i comanda drop definit n seciunea 5.1.8. O comand de genul

delete from Departament terge toate liniile din tabelul DEPARTAMENT, i posibil toate liniile tabelelor care sunt legate prin constrngeri de referin de acesta, dac opiunea cascade este precizat ca eveniment la tergere. Schema bazei de date rmne neschimbat, comanda modificnd doar instana bazei de date. Comanda drop table Departament cascade
are acelai efect ca i comanda anterioar, dar n acest caz schema bazei de date se modific, tabelul DEPARTAMENT fiind ters, la fel ca i vederile sau tabelele care se refer la el n definiiile lor. Comanda

drop table Departament restrict

eueaz dac exist linii n tabelul DEPARTAMENT.

5.3.3 Actualizarea nregistrrilor

Sintaxa instruciunii update este

update NumeTabel set Atribut = <Expresie | InterogareSQL | NULL | default> {, Atribut = <Expresie | InterogareSQL | NULL | default>} [where Conditie]
Instruciunea update face posibil actualizarea unuia sau a mai multor atribute din liniile tabelului NumeTabel ce satisfac o posibil Conditie. Dac nu apare clauza where se vor actualiza toate liniile din tabel. Noua valoare ce va fi asignat unui atribut poate fi: rezultatul evalurii unei expresii, definit pe atributele din tabel; rezultatul unei interogri SQL; valoarea NULL; valoarea implicit a domeniului de definiie.
Exemplu Comanda update Angajati set Salariu = Salariu * 1.1 where Dept = Administratie produce o cretere cu 10% a salariilor angajailor din departamentul Administratie. Natura SQL, care este orientat pe operaiile cu mulimi, trebuie luat n considerare cnd se scriu comenzi de actualizare. S presupunem c se dorete modificarea salariilor angajailor astfel: creterea salariilor sub 30 mii cu 10% i a salariilor peste 30 mii cu 15%. O cale de a face actualizarea este execuia urmtoarelor comenzi: update Angajati set Salariu = Salariu * 1.1 where Salariu <= 30 update Angajati set Salariu = Salariu * 1.15 where Salariu > 30

64

S presupunem c avem un angajat care ctig 28 mii, deci satisface condiia din prima comanda de actualizare i atributul Salariu va fi setat la 30.8 mii. n acest moment, linia satisface de asemenea i condiia celei de-a doua actualizri, deci salariul va fi modificat din nou. Creterea pentru salariatul respectiv va fi de 26.5%. Aceast problem particular poate fi rezolvat prin inversarea celor dou operaii de actualizare. n situaiile mai complexe soluia ar putea s necesite introducerea unor actualizri intermediare sau utilizarea unui limbaj de programare de nalt nivel care folosete cursori. Aceast tehnic va fi prezentat n lucrrile de laborator.

5.4 Alte definiii de date n SQL

Avnd descrise n acest moment interogrile n SQL se poate completa prezentarea componentelor unei scheme a unei baze de date cu clauza check, a aseriilor i a primitivelor pentru definirea vederilor.

5.4.1 Constrngerea de integritate de tip check

Pentru specificarea altor constrngeri dect cele discutate pn acum, SQL-2 a introdus constrngerea check, care are urmtoarea sintax:

check (Condiie)
Condiiile ce pot fi utilizate sunt cele ce pot aprea n clauza where a unei interogri SQL. Condiia impus trebuie verificat ntotdeauna pentru a menine corectitudinea bazei de date. n acest fel pot fi specificate toate constrngerile pe tuplu discutate anterior, deoarece condiia din constrngerea check poate face referire la alte atribute. Pentru exemplificarea acestei construcii vom redefini schema tabelului ANGAJATI din seciunea 5.1.7:
Exemplu create table Angajati (NrInreg character(6) check ( NrInreg is not NULL and 1 = (select count(*) from Angajati a where NrInreg = a.NrInreg)), Nume character(20) not NULL check ( Nume is not NULL), Prenume character(20) check ( Prenume is not NULL and 1 = (select count(*) from Angajati a where Prenume = a.Prenume and Nume = a.Nume)), Dept character(15) check (Dept in (select Dept from Departament)))

Observaii constrngerile predefinite permit o reprezentare compact i mai uor de citit; prin utilizarea clauzei check se pierde posibilitatea specificrii unei reacii n cazul nclcrii constrngerii; cnd se utilizeaz constrngeri predefinite, sistemul le recunoate imediat i le poate verifica mult mai eficient.

65

5.4.2 Aserii

Aseriile reprezint constrngeri ce nu sunt asociate unei anumite linii sau unui anumit tabel n particular i fac parte din schema bazei de date. Aseriile permit definirea tuturor constrngerilor prezentate i, n plus, permit definirea unor constrngeri care nu pot fi exprimate altfel (de exemplu constrngeri ntre mai multe tabele, constrngeri ce impun ca un tabel s aib o anumit cardinalitate). Aseriile au un nume i pot fi terse cu ajutorul comenzii drop. Sintaxa ce permite definiia aseriilor este:

create assertion NumeAsertie check (Conditie)

Exemplu create assertion CelPutinUnAngajat check ( 1<= (select count(*) from Angajati)) Aceast constrngere impune ca tabelul ANGAJATI sa aib cel puin o nregistrare.

Constrngerile de integritate check sau aserie pot fi imediate sau ntrziate. Constrngerile imediate sunt verificate dup fiecare modificare a bazei de date, n timp ce constrngerile ntrziate sunt verificate la sfritul unei secvene de modificri a bazei de date, numit tranzacie. nclcarea unei constrngeri imediate de o instruciune reface starea bazei de date din momentul anterior execuiei instruciunii. Dac o constrngere ntrziat este nclcat se va reface starea bazei de date din momentul anterior nceperii tranzaciei. n interiorul unui program se poate seta tipul unei constrngeri la imediat sau ntrziat cu ajutorul comenzilor set constraints [NumeConstrangere] immediate sau set constraints [NumeConstrangere] deferred.

5.4.3 Vederi

n capitolul 3 vederile au fost introduse ca fiind tabele virtuale al cror coninut depinde de coninutul altor tabele din baza de date. n SQL vederile sunt definite prin asocierea unui nume i a unei liste de atribute cu rezultatul execuiei unei interogri. O vedere se definete folosind comanda:

create view NumeVedere [(ListaAtribute)] as InterogareSQL [with [<local | cascaded>] check option]
Interogarea SQL i schema vederii trebuie s aib acelai numr de atribute.
Exemplu S se defineasc vederea AngajatiAdmin care va conine toi angajaii din departamentul Administraie i care au salariul mai mare ca 10. create view AngajatiAdmin (NrInreg, Nume, Prenume, Salariu) as select NrInreg, Nume, Prenume, Salariu from Angajati where Dept = Administratie and Salariu > 10

n cazul anumitor vederi se pot efectua operaii de actualizare, dar aceste operaii trebuie translate n instruciuni de modificare a tabelelor ce stau la baza vederii. Nu ntotdeauna se pot 66

gsi soluii de modificare a tabelelor de baz, mai ales n situaiile n care vederea se definete pe baza unei jonciuni ntre mai multe tabele. n general sistemele comerciale permit modificarea unei vederi doar dac este definit pe un singur tabel; alte sisteme cer ca atributele vederii s conin mcar o cheie primar a tabelului de baz. Clauza check option specific faptul c operaiile de actualizare se pot face numai asupra liniilor ce aparin vederii i dup actualizare liniile continu s aparin vederii. Cnd o vedere este definit pe baza altor vederi, opiunile local sau cascaded specific dac tergerea liniilor se face la nivel local sau trebuie propagat la toate vederile de care depinde vederea n cauz. Opiunea implicit este cascaded.
Exemplu S se defineasc vederea AngajatiAdmin1, bazat pe vederea AngajatiAdmin, care va conine toi angajaii din departamentul Administraie i care au salariul ntre 10 i 50. create view AngajatiAdmin1 as select * from AngajatiAdmin where Salariu < 50 with check option ncercarea de a da valoarea 8 atributului Salariu nu va fi acceptat de definiia curent a vederii, dar ar fi fost validat dac check option ar fi fost definit ca local. ncercarea de a modifica valoarea atributului Salariu pentru o linie din vedere la valoarea 60 nu ar fi validat nici cu opiunea local.

Vederile pot fi utilizate n SQL pentru formularea unor interogri care altfel ar fi imposibil de exprimat. n general, vederile pot fi considerate ca fiind unelte ce mresc posibilitatea crerii interogrilor imbricate.
Exemplu Interogarea 24: S se gseasc departamentul cu cel mai mare buget alocat salariilor. create view BugetSalarii (Dept, SalariuTotal) as select Dept, sum(Salariu) from Angajati group by Dept select Dept from BugetSalarii where SalariuTotal = (select max(SalariuTotal) from BugetSalarii)

5.5 Controlul accesului la baza de date

Mecanismele de protecie a datelor reprezint un aspect important al aplicaiilor moderne ce lucreaz cu baze de date. n acest sens, administratorul bazei de date are posibilitatea de a alege i de a implementa politici adecvate de control al accesului la baza de date. SQL a fost proiectat astfel nct fiecare utilizator poate fi identificat n dou moduri: ca utilizator al sistemului de operare i ca utilizator al bazei de date.
5.5.1 Resurse i privilegii Resursele protejate de sistem sunt n general tabelele, dar pot fi protejate i alte componente, cum ar fi atributele unor tabele, vederi sau domenii.

67

Ca regul general, utilizatorul care creeaz o resurs este proprietarul ei i este autorizat s efectueze orice operaie asupra acelei resurse. Din cauza acestei limitri, SQL pune la dispoziie mecanisme de organizare ce permit administratorului s specifice acele resurse la care utilizatorii au acces i cele la care nu au acces. Prin intermediul acestor mecanisme utilizatorii dispun de privilegii de acces la resursele sistemului. Fiecare privilegiu de acces este caracterizat de:
resursa la care face referire; utilizatorul ce acord privilegiul; utilizatorul ce primete privilegiul; operaia permis asupra resursei; posibilitatea acordrii privilegiului altor utilizatori.

n momentul crerii unei resurse, sistemul acord, n mod automat, toate privilegiile asupra resursei creatorului su. Exist un utilizator predefinit, _system, asociat administratorului bazei de date, ce deine toate privilegiile asupra tuturor resurselor. Tipurile de privilegii disponibile sunt: 1) insert permite inserarea unui obiect nou n resurs (aplicabil numai tabelelor i vederilor); 2) update permite modificarea valorii unui obiect (poate fi utilizat cu tabele, vederi i atribute); 3) delete permite eliminarea unui obiect din resurs (doar tabele sau vederi); 4) select permite utilizatorului s citeasc resursa cu scopul de a o utiliza n interogri (tabele, vederi sau atribute); 5) references permite crearea unei referine ctre o resurs n contextul definirii unui tabel. Poate fi asociat cu tabele sau atribute. Acordarea acestui privilegiu asupra unei resurse poate conduce la limitarea posibilitii de modificare a resursei. S considerm c utilizatorul Paul este proprietarul tabelului DEPARTAMENT, iar utilizatorul tefan deine privilegiul de referin. tefan are posibilitatea s defineasc o constrngere de tip foreign key pe tabelul su ANGAJATI, referind resursa indicat de privilegiu (de exemplu cheia tabelului DEPARTAMENT). Dac tefan adopt o politic no action la definirea constrngerii, Paul va fi pus n situaia de a nu putea terge sau modifica linii din tabelul su dac aceste operaii au ca efect nclcarea constrngerii. 6) usage se aplic domeniilor i permite utilizarea lor, spre exemplu, pentru definirea schemei unui tabel. Privilegiul de a efectua operaiile de drop sau alter nu poate fi acordat. Acest tip de privilegiu este deinut doar de proprietarul resursei. Privilegiile se acord sau se revoc cu ajutorul instruciunilor grant i revoke.

5.5.2 Comenzi pentru acordarea i revocarea privilegiilor

Sintaxa comenzii de acordare de privilegii este:

grant Privilegii on Resurs to Utilizatori [with grant option]

Aceast instruciune permite acordarea de Privilegii asupra Resursei ctre Utilizatori.

68

Exemplu grant select on Departament to Stefan

Clauza with grant option indic posibilitatea propagrii privilegiului ctre ali utilizatori. Se pot utiliza cuvintele cheie all privileges pentru acordarea tuturor privilegiilor.
Exemplu grant all privileges on Departament to Stefan, Paul

Sintaxa comenzii de revocare de privilegii este:

revoke Privilegii on Resurs from Utilizatori [restrict | cascade]

Printre privilegiile ce pot fi revocate unui utilizator se gsete i privilegiul grant option, ce deriv din utilizarea opiunii with grant option. Revocarea privilegiilor poate fi fcut doar de utilizator care, ntr-o prim faz, a acordat aceste privilegii. Opiunea restrict mpiedic execuia instruciunii revoke dac retragerea privilegiului are ca efect o retragere n lan de privilegii. O astfel de comportare poate aprea n situaia n care utilizatorul a primit privilegiul cu opiunea with grant option i a propagat privilegiul ctre ali utilizatori. Opiunea cascade n schimb va avea ca rezultat revocarea tuturor privilegiilor din lan i n plus va elimina toate obiectele din baza de date ce au fost construite pe baza acestor privilegii.

5.6 Utilizarea SQL n limbajele de programare

Accesul la informaiile coninute n baza de date se face cel mai adesea prin intermediul aplicaiilor integrate ntr-un sistem informaional, n timp ce utilizarea direct a interpretorului SQL este rezervat experilor. Utilizarea aplicaiilor dedicate pentru a accesa informaiile dintr-o baz de date este justificat de o serie de factori: accesul la informaii este cerut adesea de o aplicaie i nu direct de utilizator; pentru utilizatori accesul trebuie s fie simplu i predictibil. Din acest motiv este util reducerea complexitii accesului la baza de date prin construirea unei aplicaii cu o interfa simpl; prezentarea datelor oferite de ctre sistem poate fi nepotrivit pentru cererile utilizatorilor, n timp ce o aplicaie special nu este restricionat i poate pune la dispoziie o reprezentare adecvat a cerinelor. Exist numeroase unelte ce pot fi folosite pentru crearea aplicaiilor de baze de date. O pia n plin dezvoltarea este aceea a limbajelor de generaia a patra (4GLs), unelte de dezvoltare sofisticate care fac posibil dezvoltarea de aplicaii de management al bazelor de date cu minimum de efort. Mai mult, exist numeroase produse care nu sunt legate de o baz de date n particular, ci sunt capabile de a manageria dialogul cu sistemele relaionale prin intermediul standardului SQL. Aceste produse ofer posibilitatea definirii efective a schemelor bazelor de date i construirii unor interfee complexe. O alt metod de a scrie aplicaii este aceea a utilizrii limbajelor de programare de nivel nalt. Analiza se va concentra pe aceast metod deoarece are nc o importan considerabil i datorit lipsei unei abordri unitare pentru limbajele de generaia a patra.
5.6.1 Probleme de integrare

Pentru a utiliza instruciuni SQL n interiorul unui limbaj procedural, instruciunile SQL trebuie ncapsulate. Din punct de vedere al implementrii este necesar punerea la dispoziie a 69

unui compilator de limbaj de nivel nalt cu un preprocesor. Acest preprocesor este capabil s detecteze apelurile ctre serviciile sistemelor de gestiune a bazelor de date i s le introduc ntrun mediu de execuie a interogrilor, care include i un optimizator al acestor interogri. Aceast soluie ofer avantajele portabilitii i abstractizrii care caracterizeaz deja limbajele standard cum ar fi SQL. La execuie, programul ncepe un dialog cu baza de date, trimind interogarea direct ctre sistem. O problem care apare const n faptul c limbajele de programare acceseaz elementele unui tablou prin scanare linie cu linie, utiliznd pentru aceasta o abordarea orientat pe tuplu. Spre deosebire de acestea, SQL e un limbaj orientat pe mulime, care acioneaz asupra ntregului tabel. De asemenea, rezultatul unei interogri SQL este un tabel. Exist dou posibiliti de a rezolva aceast problem. Prima const n utilizarea limbajelor de programare care au disponibile construcii de date puternice. Aceast soluie a devenit mai interesant odat cu dezvoltarea limbajelor de programare orientate obiect, care sunt caracterizate de mecanisme puternice de definire a tipurilor de date. Dezavantajele ar fi c multe aplicaii sunt construite pe limbaje ce nu au aceast capabilitate. De asemenea, o alt dificultate care apare este lipsa unor standarde acceptate de toate sistemele. O a doua strategie, mult mai utilizat, este standardizat i nu necesit extensii complicate ale limbajelor de programare existente. Aceast soluie se bazeaz pe cursori.

5.6.2 Cursori Cursorul este un mecanism care permite accesarea liniilor unui tabel una cte una. Cursorul se definete utiliznd o interogare. Sintaxa pentru definirea unui cursor este:

declare NumeCursor [scroll] cursor for InterogareSQL [for <read only | update [of Atribut {, Atribut}]>]
Comanda declare cursor definete un cursor asociat cu o interogare particular a bazei de date. Opiunea scroll specific dac permitem cursorului s pointeze la oricare din liniile rezultatului interogrii. Opiunea for update indic posibilitatea folosirii cursorului pentru o actualizare a atributelor specificate. Un cursor se deschide prin intermediul comenzii:

open NumeCursor
Cnd se aplic aceast comand de deschidere a cursorului, se execut interogarea iar rezultatul interogrii poate fi accesat prin intermediul comenzii fetch:

fetch [Positie from] NumeCursor into ListaVariabile

Comanda fetch preia o linie din cursor i ntoarce valorile acesteia n variabile ale programului din ListaVariabile. ListaVariabile trebuie s includ cte o variabil pentru fiecare element din lista int a interogrii, astfel nct fiecare element din ListaVariabile s fie compatibil din punct de vedere al tipului cu domeniile elementelor din lista int. Un concept important este acela de linie curent, care reprezint ultima linie utilizat ntr-o operaie fetch. Parametrul Pozitie este utilizat pentru setarea liniei curente. Acest parametru poate lua una din valorile urmtoare: next linia urmtoare devine linie curent; first prima linie a rezultatului interogrii devine linie curent; last - ultima linie a rezultatului interogrii devine linie curent; 70

 absolute Expresie linia de pe poziia i a rezultatului interogrii devine linie curent, unde i este rezultatul evalurii expresiei, care trebuie s fie de tip integer; relative Expresie - linia de pe poziia i, plecnd de la linia curent, a rezultatului interogrii devine linie curent; i are semnificaia de mai sus. Aceste valori ale parametrului Pozitie pot fi folosite doar dac este activat opiunea scroll. n caz contrar, valoarea implicit a parametrului este next.

Comenzile update i delete permit modificarea bazei de date prin intermediul cursorilor. Spre exemplu, sintaxa comenzii update este este:

update NumeTabel set Atribut = <Expresie | NULL | default> {, Atribut = <Expresie | NULL | default>} where current of NumeCursor
Singura modificare cerut de sintaxa comenzilor update i delete const n posibilitatea utilizrii n clauza where a cuvintelor cheie current of NumeCursor, care indic linia curent (cea care trebuie actualizat sau tears). Comenzile de modificare pot fi folosite doar n cazul n care cursorul permite accesul la o linie curent a tabelului i nu sunt aplicabile cnd interogarea asociat cursorului necesit o jonciune ntre diferite tabele. Comanda close nchide cursorul i comunic sistemului c rezultatul interogrii nu mai este necesar. n acest moment spaiul de memorie necesar memorrii rezultatului interogrii este dealocat. Sintaxa aceste comenzi este:

close NumeCursor
Exemplu declare CursorAngajati scroll cursor for select Nume, Prenume, Salariu from Angajati where Salariu < 100 and Salariu > 40 Cursorul CursorAngajati este alocat unei interogri ce permite obinerea datelor referitoare la angajaii care ctig ntre 40 i 100.

S considerm n continuare un exemplu simplu de program n C care utilizeaz cursori. Comenzile SQL sunt precedate de caracterul $ iar variabilele programului sunt precedate de caracterul :. Se utilizeaz i o variabil predefinit, sqlcode, care conine valoarea 0 dac ultima comand a fost executat cu succes i o valoare diferit de 0 dac apare o eroare; scopul este de a detecta dac asupra liniilor cursorului a fost executat comanda fetch.
Exemplu void AfiseazSalariiDepartament (char NumeDept[ ]) { char Nume[20], Prenume[20]; long int Salariu; $ declare DeptAng cursor for select Nume, Prenume, Salariu from Angajati where Dept = :NumeDept;

71

$ open DeptAng $ fetch DeptAng into :Nume, :Prenume, :Salariu; printf (Departament %s\n, NumeDept); while (sqlcode == 0) { printf (Numele Angajatului: %s %s, Nume, Prenume); printf (Salariu: %d\n, Salariu); $ fetch DeptAng into :Nume, :Prenume, :Salariu; } $ close cursor DeptAng; }

n cazul n care rezultatul interogrii const ntr-un singur tuplu (interogri scalare) nu mai este necesar definirea unui cursor pentru interfaarea cu limbajul de programare. Se poate stabili direct cror variabile din program li se atribuie valorile rezultatului interogrii prin utilizarea clauzei into. Sintaxa instruciunii select se extinde n modul urmtor:

InterogareSQL ::= select ListaTinta [into ListaVariabile] from ListaTabele [where Conditie] [group by ListaAtributeGrupare] [having ConditieAgregata] [order by ListaAtributeOrdonare]
Exemplu $ select Nume, Prenume into :NumeAng, : PrenumeAng from Angajati where ID = :IDAng

5.6.3 SQL Dinamic

n practic exist numeroase situaii n care este necesar s se permit utilizatorului s formuleze interogri arbitrare asupra bazei de date. Dac interogrile au o structur predefinit i partea care variaz este reprezentat doar de parametrii interogrii atunci se pot construi aplicaii folosind cursori, dup cum s-a vzut n seciunea anterioar. Exist cazuri n care interogrile trebuie s fie mai flexibile. Aceste interogri difer nu doar prin parametrii folosii ci i prin structur i mulimea de tabele luat n considerare. Mecanismele prezentate n seciunea anterioar nu mai funcioneaz n acest context. Aceast familie de mecanisme este cunoscut sub numele de SQL static. Exist i o familie alternativ de comenzi cunoscut sub numele de SQL dinamic. Aceste comenzi fac posibil alctuirea unui program ce execut comenzi SQL construite cnd programul ruleaz; ele necesit un suport special din partea sistemului. Problema principal care apare este aceea a transferului parametrilor ntre comenzile SQL i program. Deoarece o astfel de comand este arbitrar, programul nu are nici o cale de a recunoate, n momentul compilrii, care sunt parametrii de intrare i de ieire ai comenzii. Aceast informaie este necesar programului pentru a putea organiza intern interogarea. Utilizarea SQL dinamic modific modul de interaciune cu sistemul. n SQL static, comenzile pot fi procesate de ctre compilator, care analizeaz structura comenzii i construiete o translaie spre limbajul intern al sistemului. n SQL dinamic nu este necesar translaia i optimizarea comenzilor de fiecare dat, acestea putnd fi executate imediat. Acest fapt aduce 72

avantaje considerabile din punct de vedere al performanei. Spre exemplu, dac o comand este ndeplinit n mod repetat, cu aceast soluie translaia se face doar o dat, pe cnd interaciunea cu maina la fiecare execuie separat a comenzii poate necesita propria faz de translaie. SQL dinamic permite dou tipuri de interaciuni. Interogarea poate fi ndeplinit imediat, aceasta nsemnnd c execuia interogrii se face imediat dup analiz, sau gestiunea interogrii are loc n dou faze, analiz i execuie.

Comanda de execuie imediat. Comanda execute immediate necesit execuia unei instruciuni SQL fie directe, fie coninut ntr-o variabil de tip ir de caractere. Sintaxa este: execute immediate InterogareSQL
Aceast metod poate fi folosit doar pentru instruciunile care nu necesit parametri de intrare sau ieire.
Exemplu execute immediate delete from Departament where Dept = Administratie ; ntr-un program n C se poate scrie: SQLString = delete from Departament where Dept = Administratie ; ... $ execute immediate :SQLString

n schimb, cnd o instruciune este executat de mai multe ori sau cnd programul trebuie s realizeze un schimb de parametri de intrare/ieire cu interogarea, se poate distinge ntre cele dou faze.

Faza de pregtire. Comanda prepare analizeaz i optimizeaz instruciunea SQL i o transform ntr-un limbaj procedural intern al sistemului de gestiune a bazelor de date. Sintaxa este: prepare NumeComanda from InstructiuneSQL
Instruciunea SQL poate conine parametri de intrare.
Exemplu prepare :InstructiuneSQL from select Oras from Departament where Dept = ? n acest caz, translaia interogrii corespunde variabilei InstructiuneSQl , cu un parametru de intrare care corespunde numelui departamentului care trebuie selectat de ctre interogare

n momentul n care o instruciune SQl pregtit nu mai este necesar se poate dealoca memoria utiliznd comanda deallocate prepare, care are sintaxa:

deallocate prepare NumeComanda

De exemplu, pentru a dealoca instruciunea anterioar se folosete comanda

deallocate prepare :InstructiuneSQL Faza de execuie. Pentru a executa o instruciune pregtit cu comanda prepare, se folosete comanda execute, cu urmtoarea sintax:
73

execute NumeComanda [into ListaTinta] [using ListaParametri]

Lista int conine lista parametrilor n care trebuie scris rezultatul execuiei instruciunii (aceast parte este opional n cazul n care comanda SQL nu are parametri de ieire). Lista de parametri specific ce valori trebuie luate de parametrii variabili din list (aceast parte se omite de asemenea dac n comanda SQL nu exist parametri de intrare).
Exemplu execute :InstructiuneSQL into :oras using :departament Dac presupunem c irul Producie este atribuit variabilei departament, efectul comenzii este executarea interogrii: select Oras from Departament where Dept = Productie iar rezultatul se memoreaz n variabila oras.

Utilizarea cursorilor n SQL dinamic. Utilizarea cursorilor n SQL dinamic este similar cu folosirea acestora n SQL static. Exist doar dou diferene. Prima este c identificatorul interogrii este atribuit cursorului n locul interogrii nsi. Cea de-a doua const n faptul c acele comenzi pentru utilizarea cursorilor permit specificarea clauzelor into i using, care la rndul lor permit specificarea eventualilor parametri de intrare sau ieire.

Exemplu prepare :InstructiuneSQL from :SQLString declare CursorPrg cursor from :InstructiuneSQL open CursorPrg using :VariabilaPrg

5.6.4 Proceduri

Standardul SQL permite definirea procedurilor, cunoscute sub numele de proceduri stocate deoarece sunt uzual stocate n baza de date drept componente ale schemei. Odat ce o procedur este definit, ea este tratat ca o comand SQL predefinit.
Exemplu S considerm urmtoarea procedur SQL, care actualizeaz numele oraului n care se gsete un departament. procedure AtribuieOras (:Dep char(20), :Oras char(20)) update Departament set Oras = :Oras where Dept = :Dept;

Procedura este apelat dnd valori parametrilor. Urmtorul exemplu arat cum se face apelul procedurii de mai sus n interiorul unui program n C, folosind dou variabile, NumeDept i NumeOras.
Exemplu $ AtribuieOras (:NumeDept, :NumeOras);

Standardul SQL-2 este limitat la definirea procedurilor formate dintr-o singur comanda SQL. Multe sisteme au nlturat aceast limitare. Exist sisteme care permit doar secvene de comenzi n interiorul unei proceduri, i sisteme care permit utilizarea structurilor de control, a 74

declaraiilor de variabile locale i a apelului programelor externe. SQL-3 extinde aceste aspecte i pune la dispoziie o sintax bogat pentru definirea procedurilor. Urmtorul exemplu arat o procedur ne-standard compus dintr-o secven de dou instruciuni SQL.
Exemplu procedure SchimbaToateOrasele (:OrasNou char(20), :OrasVechi char(20)) begin update Departament set Oras = :OrasNou where Oras = :OrasVechi; update Angajati set Oras = :OrasNou where Oras = :OrasVechi; end; Procedura d atributului Oras valoarea variabilei :OrasNou, pentru toate liniile tabelelor Departament i Angajati n care atributul Oras este egal cu valoarea variabilei :OrasVechi.

Una din extensiile uzuale puse la dispoziie de sistemele actuale este structura de control if-then-else.
Exemplu procedure SchimbaOras (:NumeDept char(20), :OrasNou char(20)) begin if not exists (select * from Departament where Dept = :NumeDept) insert into EroareDept values (:NumeDept) else update Departament set Oras = :OrasNou where Dept = :NumeDept; end if; end; Procedura d atributului Oras n care se gsete departamentul :NumeDept valoarea variabilei :OrasNou; dac departamentul nu exist, se introduce o linie n tabelul EroareDept.

Dup cum am indicat mai sus, exist sisteme comerciale care ofer extensii procedurale puternice ale SQL. Exist de asemenea posibilitatea de a scrie ntreaga aplicaie n aceste extensii ale SQL. Urmtorul program este scris n PL/SQL, extensia furnizat de sistemul relaional ORACLE SERVER.
Exemplu procedure Debit (ContClient char(5), Retragere integer) is SumaVeche integer; SumaNoua integer; SumaMinima integer; begin select Suma, Limita into SumaVeche, SumaMinima from ContBanca where NumarCont = ContClient for update of Suma; SumaNoua := SumaVeche Retragere; if SumaNoua > Limita then

75

update ContBanca set Suma = SumaNoua where NumarCont = ContClient; else insert into LimitaDepasita values (ContClient, Retragere, sysdate); end if; end Debit; Procedura permite retragerea sumei Retragere din contul cu codul ContClient, dac n cont sunt suficieni bani. Se utilizeaz variabilele locale (SumaVeche, SumaNoua, SumaMinima) i o structur de control if-then-else.

76

Partea a II-a Proiectarea bazelor de date

Capitolul 6. Tehnici de proiectare i modele

n capitolele precedente s-au analizat modele de baze de date i limbaje, presupunnd n cele mai multe cazuri c exist o baz de date cu care utilizatorii pot interaciona. n acest capitol se va pune problema proiectrii unei baze de date conform cerinelor utilizatorilor. Proiectarea unei baze de date presupune definirea structurii, caracteristicilor i coninutului acesteia. Utilizarea unor tehnici corespunztoare este esenial pentru crearea unui produs de calitate bun.

6.1. Procesul de proiectare a bazei de date

6.1.1. Ciclul de via al informaiilor din sistem

Proiectarea bazei de date este doar una din activitile dezvoltrii unui sistem informaional n interiorul unei organizaii. n figura 1 este prezentat ciclul de via a unui sistem informaional.

Figura 1. Ciclul de via al unui sistem informaional

Studiul de fezabilitate servete definirii ct mai precise a costurilor diferitelor soluii posibile i stabilirii prioritilor n crearea componentelor sistemului. Extragerea i analiza cerinelor const n definirea i studiul proprietilor i funcionalitii sistemului informaional. Aceast etap presupune interaciunea cu clienii pentru

77

extragerea cerinelor. Rezultatul este o descriere (informal) complet a datelor care intervin i a operaiilor care acioneaz asupra datelor respective. Se stabilesc de asemenea necesitile hardware i software ale sistemului.
Proiectarea se mparte n general n dou taskuri: proiectarea bazei de date i proiectarea operaional. La nceput se stabilesc structura i organizarea datelor, iar apoi se definesc caracteristicile programelor. Cei doi pai sunt complementari i se pot parcurge simultan sau consecutiv. Descrierea datelor i a programelor rezultate din aceast etap este formal i se refer la modele specifice. Implementarea const n crearea sistemului informaional n concordan cu structura i caracteristicile precizate n etapa de proiectare. Se construiete baza de date i se scrie codul programelor. Validarea i testarea constau n verificarea funcionrii i a calitii sistemului informaional. Testele trebuie s conin, pe ct posibil, toate condiiile de operare posibile. Operarea este activitatea n care sistemul informaional funcioneaz ndeplinind scopurile pentru care a fost creat. Presupunnd ca nu exist erori majore sau c nu este schimbat funcionalitatea sistemului, aceast activitate const doar n managementul i ntreinerea sistemului.

n practic aceste etape nu sunt n general secveniale, deoarece n timpul uneia dintre activitile menionate este necesar revenirea la o etap anterioar. Mai mult, cteodat este necesar introducerea unei noi activiti prototipizarea care const n utilizarea unor unelte software specifice pentru crearea rapid a unei versiuni simplificate a sistemului informaional cu ajutorul creia se testeaz funcionalitatea acestuia. Prototipul poate fi prezentat clienilor pentru a verifica dac au fost extrase i modelate corect cerinele acestora.

6.1.2. Metodologii pentru proiectarea bazelor de date

O abordare structurat a proiectrii bazelor de date const n parcurgerea urmtoarelor etape:

descompunerea activitii de proiectare n pai succesivi, independeni unul de altul; o serie de strategii care trebuie urmate i cteva criterii care permit o alegere n cazul n care exist mai multe soluii; cteva modele de referin pentru a descrie intrrile i ieirile diferitelor faze.

Proprietile care trebuie garantate de o anumit metodologie sunt:

generalitatea privitoare la aplicaiile i sistemele pe care ruleaz ( i astfel posibilitatea utilizrii independent de o aplicaie specific i de un sistem disponibil); calitatea produsului, care presupune acuratee i eficien; uurina utilizrii att a strategiei ct i a modelelor de referin.

Metodologiile din domeniul proiectrii bazelor de date se mpart n trei faze (vezi figura 2).

78

Figura 2. Fazele proiectrii bazelor de date

Proiectarea conceptual. Scopul acestei faze este de a reprezenta cerinele informale ale aplicaiei n termenii descrierii complete i formale dar independent de criteriul folosit pentru reprezentare n sistemul de management al bazei de date. Rezultatul acestei faze este schema conceptual i se refer la un model de date conceptual (care permite descrierea organizrii datelor la un nivel nalt de abstractizare fr a lua n considerare aspectele de implementare). n aceast faz, proiectantul trebuie s ncerce s reprezinte coninutul bazei de date fr a lua n considerare mijloacele prin care informaiile respective vor fi implementate n sistem sau eficiena programelor ce utilizeaz aceste informaii. Proiectarea logic reprezint translarea schemei conceptuale ntr-un model de date disponibil pentru sistemul de gestiune al bazei de date. Rezultatul acestei faze, numit schem logic, se refer la un model de date logic (care permite reprezentarea datelor ntr-o form independent nc de detaliile fizice dei sistemul de gestiune al bazei de date folosit pentru implementare poate fi unul ce suport acest model de date). n aceast faz proiectantul trebuie s ia n considerare criterii de optimizare. Se utilizeaz frecvent tehnici formale pentru verificarea calitii schemei logice. n cazul unui model de date relaional, tehnica folosit este aceea a normalizrii.

79

Proiectarea fizic. n aceast faz, schema logic se completeaz cu detalii de implementare fizic (organizarea fiierelor i indeci) puse la dispoziie de SGBD. Rezultatul acestei faze se numete schema fizic i se refer la un model de date fizic. Acest model depinde de sistemul de management al bazei de date i ia n considerare criteriile pentru organizarea fizic a datelor.

S precizm ce fel de cerine ale aplicaiei sunt utilizate n cele trei faze ale proiectrii bazelor de date. Se poate face o distincie ntre cerinele de date care constau n coninutul bazei de date i cerinele operaionale care constau n utilizarea bazei de date de clieni sau programatori. n proiectarea conceptual, cerinele de date furnizeaz majoritatea informaiilor, n timp ce cerinele operaionale se folosesc doar pentru a verifica dac schema conceptual este complet. n proiectarea logic pe de alt parte, schema conceptual, care este furnizat ca intrare, rezum cerinele de date; n schimb, cerinele operaionale se folosesc pentru a obine schema logic. n proiectarea fizic schema logic i cerinele operaionale se folosesc pentru optimizarea performanelor sistemului. n aceast faz trebuie luate n considerare caracteristicile SGBD-ului utilizat. Rezultatul procesului de proiectare a bazei de date nu este dat doar de schema fizic, ci i de schema conceptual i cea logic. Schema conceptual furnizeaz o reprezentare de nivel nalt a bazei de date care poate fi extrem de folositoare pentru documentare. Schema logic furnizeaz o descriere a coninutului bazei de date i, lsnd la o parte aspectele de implementare, este util pentru realizarea interogrilor i modificrilor bazei de date.

6.2. Modelul Entitate Relaie (Entity Relantionship model)

Modelul Entitate Relaie (ER) este un model de date conceptual ce pune la dispoziie o serie de construcii capabile s descrie datele necesare unei aplicaii ntr-o manier uor de neles i independent de criteriile de gestiune i organizare a datelor din sistem. Construciile modelului E-R definesc scheme ce descriu modul de organizare i dicteaz care apariii de date (valori pe care baza de date le poate stoca la diferite momente de timp) sunt legale. Construciile modelului E-R sunt prezentate n figura 3. Construciile de baz ale modelului E-R vor fi prezentate n continuare.
Entiti reprezint clase de obiecte ce au proprieti comune i existen autonom. Notaia grafic pentru entitate se poate observa n figura 4. ORA, DEPARTAMENT, ANGAJAT, VNZRI sunt exemple de entiti ntr-o aplicaie pentru o organizaie comercial. O apariie a unei entiti este un obiect al clasei reprezentate de entitatea respectiv. Spre exemplu, oraele Iai i Bucureti sunt apariii ale entitii ORAS.

Observaie. O apariie a unei entiti nu este o valoare ce identific un obiect (de exemplu numele unui angajat) ci este chiar obiectul nsui. O consecin a acestui fapt este aceea c o apariie a unei entiti are o existen (i o identitate) independent de proprietile asociate (n cazul unui angajat, angajatul exist indiferent dac are un nume, un prenume, o vrst etc.). n acest sens modelul entitate relaie este diferit de modelul relaional, unde nu este posibil reprezentarea unui obiect fr a-i cunoate proprietile.

ntr-o schem, fiecare entitate are un nume unic. 80

Entitate

Relaie

Atribut simplu

Atribut compus

Cardinalitatea unei relaii

m1,M1

m2,M2

Cardinalitatea unui atribut

m,M

Identificatori interni

Identificator extern

Generalizare

Submulime Figura 3. Construcii ale modelului entitate-relaie

Figura 4. Exemple de entiti

Relaii reprezint legturi logice ntre dou sau mai multe entiti. REZIDEN este un exemplu de relaie care poate exista ntre entitile ORA i ANGAJAT.

81

O apariie a unei relaii este un n-tuplu format din apariii ale entitilor, cte o apariie pentru fiecare entitate implicat. n figura 5 este prezentat un exemplu coninnd apariii ale relaiei EXAMEN ntre entitile STUDENT i CURS.

Figura 5. Exemple de apariii ale relaiei EXAMEN ntr-o schem entitate relaie, fiecare relaie are un nume unic i este reprezentat grafic prin simbolul coninnd numele relaiei.

Figura 6. Exemple de relaii Dup cum se poate observa n figura 6, ntre aceleai entiti pot exista mai multe relaii. Pentru numele relaiilor este indicat folosirea substantivelor n locul verbelor, pentru a evita sugerarea unei direcii. Un aspect important al relaiilor const n aceea c mulimea apariiilor unei relaii este o relaie matematic ntre mulimile de apariii ale entitilor implicate (este o submulime a produsului cartezian al celor dou mulimi de apariii ale entitilor implicate). Astfel este asigurat faptul c nici un n-tuplu nu va aprea de dou ori pentru apariiile unei relaii. Acest aspect are consecine importante: spre exemplu, relaia EXAMEN din figura 6 nu are capacitatea de a raporta faptul c un student oarecare d un examen de mai multe ori (deoarece aceasta ar trebui s produc perechi identice).n acest caz, examenul trebuie reprezentat de o entitate legat de entitile STUDENT i CURS prin intermediul a dou relaii binare. Sunt posibile relaiile recursive care reprezint relaii ntre o entitate i ea nsi.

82

Figura 7. Exemple de relaii recursive n figura 7 relaia recursiv COLEG a entitii ANGAJAT conecteaz perechi de oameni care lucreaz mpreun. Spre deosebire de prima relaie, relaia SUCCESIUNE a entitii SUVERAN nu este simetric. n acest caz, este necesar s se asocieze identificatori liniilor din relaia recursiv. Exist relaii care implic mai mult de dou entiti. n exemplul din figura 8 o apariie a relaiei FURNIZEAZ descrie faptul c o anumit firm furnizeaz un anumit produs unui departament.

Figura 8. Exemplu de relaie ce implic mai multe entiti

Atribute descriu proprietile elementare ale entitilor sau relaiilor. Spre exemplu, Nume, Salariu, Vrst sunt atribute pentru entitatea ANGAJAT iar Dat, Not sunt atribute pentru relaia EXAMEN (vezi figura 9). Un atribut asociaz fiecrei apariii a unei entiti (sau relaie) o valoare aparinnd unei mulimi denumite domeniul atributului. Domeniul conine valori admisibile pentru atribut. De exemplu domeniul pentru atributul Nume poate fi orice ir de caractere de lungime 20, iar domeniul pentru atributul Vrst poate fi orice numr ntre 18 i 60. Domeniile nu sunt reprezentate grafic, ele fiind de obicei descrise n documentaia asociat. Atributele pot fi simple sau compuse.

Un atribut compus este o mulime de atribute ale aceleai entiti sau relaii ale cror nelesuri sau utilizri sunt strns conectate. Spre exemplu, atributele Strada, NumrCas, CodPotal ale entitii PERSOAN pot fi grupate pentru a forma atributul compus Adres. n figura 11 este prezentat un exemplu de schem Entitate-Relaie cu toate componentele discutate pn n acest moment.

83

Figura 9. Schem E-R cu relaii, entiti i atribute

Figura 10. Exemplu de entitate cu un atribut compus

Figura 11. Exemplu de schem Entitate-Relaie

84

Cardinalitatea unei relaii este specificat pentru fiecare entitate participant la relaie i descrie numrul minim, respectiv maxim de apariii ale relaiei la care poate participa o apariie a entitii. ntr-o schem E-R cardinalitile minime i maxime ale participrilor entitilor n relaii sunt specificate n paranteze, ca n figura 12.

Figura 12. Cardinalitatea unei relaii ntr-un model E-R n principiu este posibil s atribuim orice valoare ntreag mai mare ca 0 cardinalitii unei relaii, singura cerin fiind ca valoarea minim a cardinalitii s fie mai mic dect cea maxim. n majoritatea cazurilor este suficient utilizarea a trei valori: 0, 1 sau N (N este o valoare ntreag mai mare ca 1): cardinalitatea minim 0 participarea la relaie este opional; cardinalitatea minim 1 participarea la relaie este obligatorie; cardinalitatea maxim 1 fiecare apariie a entitii este asociat cel mult unei singure apariii a relaiei; cardinalitatea maxim N fiecare apariie a entitii este asociat unui numr arbitrar de apariii ale relaiei. n funcie de cardinalitile maxime ale entitilor implicate ntr-o relaie, relaiile se mpart n: relaii unu-la-unu - definesc o coresponden unu la unu ntre entiti (v. figura 13a o comand are o singur factur)

Figura 13. Exemple de cardinaliti ale relaiilor relaii unu-la-mai-muli - cardinalitatea maxim a unei entiti este 1, iar cardinalitatea maxim a celeilalte entiti este N (v. figura 13b o persoan poate fi rezident ntr-un singur ora, n timp ce fiecare ora poate avea mai muli rezideni)

85

 relaii mai muli-la-mai muli - cardinalitile maxime sunt N pentru ambele entiti (v. figura 13c).

n ceea ce privete cardinalitatea minim, s precizm faptul c este rar cazul n care participarea este obligatorie pentru toate entitile implicate. Aceasta se ntmpl deoarece atunci cnd se adaug o nou apariie a entitii, adesea apariiile corespunztoare ale altor entiti legate de aceasta nu sunt cunoscute nc sau nu exist. Spre exemplu, s considerm schema din figura 13a. Cnd se primete o nou comand, nu exist nc o factur i deci nu este posibil construirea unei apariii pentru relaia ONORARE care conine noua comand. n relaiile n-are, entitile implicate au aproape ntotdeauna cardinalitatea maxim egal cu N. Cnd o entitate este implicat ntr-o relaie n-ar cu cardinalitatea maxim egal cu 1, nseamn c una din apariiile sale poate fi legat de o singur apariie a relaiei, i deci la un singur n-tuplu al apariiilor unei alte entiti implicate n relaie. Aceast nseamn de fapt ca este posibil nlocuirea relaie n-are cu n relaii binare unu-la-mai muli care leag astfel o entitate cu altele.
Cardinalitatea atributelor descrie numrul minim, respectiv maxim de valori ale atributelor asociate fiecrei apariii a unei entiti sau relaii. n general, cardinalitatea unui atribut este (1,1) i este omis pe schem. n acest caz atributul este o funcie ce asociaz o singur valoare fiecrei apariii a entitii (relaiei).Valoarea unor atribute poate fi null sau pot exista valori diferite ale atributului asociate unei apariii a entitii. Aceste situaii pot fi reprezentate prin alocarea cardinalitii minime egal cu 0 (n primul caz) respectiv cu cardinalitatea egal cu N (n al doilea caz).

Figura 14. Exemplu de atribute cu cardinalitate n figura 14 este prezentat un exemplu de atribute cu cardinalitate. O persoan are un nume i doar unul, poate avea sau nu permis de conducere (dac are, este unic) i poate avea mai multe maini, la fel de bine ca nici una. ntr-un mod similar participrii unei apariii a unei entiti ntr-o relaie, putem spune c un atribut cu cardinalitatea minim egal cu zero este opional pentru entitatea asociat (sau relaia asociat) i este obligatoriu n cazul n care cardinalitatea minim este unu. De asemenea, spunem c un atribut este multivaloare dac are cardinalitatea maxim N. Atributele multivaloare trebuie folosite cu precauie deoarece ele reprezint situaii care pot fi modelate, cteodat, prin entiti adiionale legate prin relaii unu-la-unu sau mai muli-la-mai muli cu entitile la care se refer. Spre exemplu s presupunem c avem atributul multivaloare Calificri pentru entitatea PERSOAN din figura 14 (o persoan poate avea mai multe calificri). Calificarea este, de asemenea, un concept ce poate fi atribuit mai multor persoane; din acest motiv, este natural modelarea acestui concept cu ajutorul unei entiti CALIFICARE legat de PERSOAN cu o relaie mai muli-la-mai muli.
Identificatori sunt specifici fiecrei entiti din schem i descriu conceptele (atributele i/sau entitile) schemei ce permit identificarea unic a apariiilor acelei entiti. Identificatorii se clasific n:

86

identificator intern format din unul sau mai multe atribute ale entitii. Este cunoscut sub numele de cheie. Spre exemplu, entitatea AUTOMOBIL cu atributele Model, Nrnmat, Culoare are ca identificator intern atributul Nrnmat, presupunnd ca nu exist dou automobile cu acelai numr de nmatriculare. Pentru entitatea PERSOAN cu atributele DatNatere, Nume, Prenume i Adres, un identificator intern poate fi format din mulimea atributelor Nume, Prenume i DatNatere. n figura 15 se pot observa notaiile pentru identificatorii interni. Se poate observa diferena ntre un identificator intern format dintr-un singur atribut (figura 15a) i un identificator intern format din mai multe atribute (figura 15b).

Figura 15. Exemple de identificatori interni

identificator extern. Exist cazuri cnd atribute ale unei entiti nu sunt suficiente pentru a identifica n mod unic apariiile entitii. S considerm entitatea STUDENT din figura 16. Schema descrie studenii nscrii la diverse universiti, doi studeni din universiti diferite putnd avea acelai numr de nregistrare. n acest caz, pentru a putea identifica un student n mod unic avem nevoie att de numrul su de nregistrare, ct i de universitatea de care acesta aparine. Un identificator corect pentru entitatea student este format din atributul Nrnreg i entitatea UNIVERSITATE. Un astfel de identificator se numete identificator extern. Se observ c identificarea este posibil prin relaia obligatorie unu-la-mai muli dintre entitile UNIVERSITATE i STUDENT, care asociaz fiecare student cu o singur universitate. Astfel, o entitate E poate fi identificat prin alte entiti doar dac fiecare astfel de entitate este implicat ntr-o relaie n care E particip cu cardinalitatea (1,1)

Figura 16. Exemplu de identificator extern Observaii. un identificator poate implica unul sau mai multe atribute, cu condiia ca fiecare dintre ele s aib cardinalitate (1,1); un identificator extern poate implica una sau mai multe entiti, cu condiia ca fiecare dintre ele s fie ntr-o relaie n care entitatea de identificat particip cu cardinalitatea (1,1); un identificator extern poate implica o entitate care este la rndul su identificat extern, atta timp ct nu se genereaz cicluri;

87

fiecare entitate trebuie s aib un identificator (intern sau extern) dar poate avea mai mult de unul. Dac exist mai mult de un identificator atunci atributele i entitile implicate ntr-o identificare pot fi opionale (cardinalitatea minim egal cu zero).

n acest moment schema din figura 11 poate fi reexaminat, introducnd cardinaliti i identificatori. Schema rezultat este prezentat n figura 17.

Figura 17. Schema din figura 11 completat cu identificatori i cardinaliti Se poate observa c numele unui ora identific o filial a companiei. Aceasta nseamn c exist doar o filial n oraul respectiv. Un departament este identificat de nume i de filiala a crei parte este (putem deduce din cardinalitate c o filial are mai multe departamente dar fiecare departament aparine unei singure filiale. Un departament are cel puin un numr de telefon. Un angajat (identificat printr-un cod) poate aparine unui singur departament (dar exist posibilitatea s nu aparin nici unui departament cazul n care este nou angajat spre exemplu) i poate conduce cel mult un departament. n plus, fiecare departament are un singur manager i unul sau mai muli angajai. Mai muli angajai (dar cel puin unul) pot lucra la un proiect (identificat prin numele su) i fiecare angajat lucreaz n general la mai multe proiecte (existnd posibilitatea s nu lucreze la nici unul). De asemenea, data livrrii proiectului poate s nu fie precizat.
Generalizri reprezint legturi logice ntre o entitate printe E i una sau mai multe entiti copii, E1, ..., En; entitatea E este mai general, n sensul c E1, ..., En sunt cazuri particulare ale lui E. n aceast situaie spunem c E este o generalizare a lui E1, ..., En, iar E1, ..., En sunt particularizri ale entitii E. Spre exemplu, PERSOAN este o generalizare pentru BRBAT i FEMEIE.

Proprieti. fiecare apariie a unei entiti copil este apariie a entitii printe; fiecare proprietate a entitii printe (atribut, identificator, relaie, generalizare) este de asemenea o proprietate a entitii copil. Spre exemplu, dac entitatea PERSOAN are atributele Nume i Vrst, atunci entitile BRBAT i FEMEIE au de asemenea aceste atribute. Mai mult, identificatorul pentru PERSOAN este de asemenea un
88

identificator valid pentru entitile BRBAT i FEMEIE. Aceast proprietate se numete motenire. Generalizarea se reprezint grafic ca n figura 18. Se observ c pentru entitile copii nu se reprezint proprietile motenite.

Figura 18. Exemplu de generalizare Generalizrile pot fi clasificate n modul urmtor: o generalizare este total dac fiecare apariie a entitii printe este de asemenea o apariie a unei entiti copil; n caz contrar este generalizare parial. o generalizare este exclusiv dac fiecare apariie a entitii printe este cel mult o apariie a unei entiti copil; n caz contrar generalizarea este suprapus.

Exemple. Generalizarea PERSOAN pentru BRBAT i FEMEIE este total (persoanele pot fi numai brbai sau femei) i exclusiv (o persoan este fie brbat fie femeie). Generalizarea VEHICUL pentru AUTOMOBIL i BICICLET este parial (exist i alte tipuri de vehicule) i exclusiv. Generalizarea PERSOAN pentru STUDENT i ANGAJAT este parial i suprapus (exist studeni care sunt i angajai). Generalizarea suprapus poate fi transformat uor ntr-o generalizare exclusiv prin adugare uneia sau mai multor entiti copil pentru reprezentarea entitilor ca sunt intersecia ntre entitile ce se suprapun. n ultimul exemplu prezentat se poate aduga entitatea STUDENTANGAJAT pentru a obine o generalizare exclusiv. Generalizrile totale se reprezint n mod obinuit cu o sgeat plin, ca n figura 19. n general, o entitate poate fi implicat n mai multe generalizri diferite. Exist generalizri cu mai multe nivele, cunoscute sub numele de ierarhii. De asemenea, o generalizare poate avea un singur entitate copil, cunoscut sub numele de submulime. n figura 19 este prezentat o ierarhie. Relaia dintre entitile MANAGER PROIECT i ANALIST este un exemplu de submulime.

89

Figura 19. Exemplu de ierarhie a generalizrilor ntre entiti

Observaii finale asupra modelului E-R

Modelul E-R este realizat pe baza a dou construcii de baz: entitate i relaie; o entitate poate participa n mai multe relaii sau n nici una; o relaie implic dou sau mai multe entiti; participarea unei entiti ntr-o relaie are o cardinalitate minim i una maxim; Modelul E-R mai are construciile atribut i generalizare; un atribut are un nume i o cardinalitate minim i una maxim i aparine unui concept de baz (entitate sau relaie); atributele compuse sunt specializri ale atributelor i sunt formate din unul sau mai multe atribute; o generalizare are o entitate printe i una (cazul submulimilor) sau mai multe entiti copil; o entitate poate fi printe sau copil n mai multe generalizri (de asemenea n nici una); Este esenial folosirea de nume diferite n cazul construciilor de baz pentru a evita ambiguitile. Dou atribute pot avea acelai nume dac aparin unor construcii de baz diferite Exist anumite restricii n folosirea unor construcii. Spre exemplu o ierarhie a unei generalizri nu poate conine cicluri. De asemenea cardinalitatea minim trebuie s fie mai mic dect cea maxim. Schemele E-R furnizeaz o reprezentare abstract a datelor unei aplicaii i pot fi utilizate nu numai pentru proiectarea bazelor de date: se pot folosi pentru documentaii deoarece pot fi nelese uor de ctre nespecialiti; 90

pot fi utilizate pentru descrierea datelor dintr-un sistem informaional existent deja (spre exemplu pentru integrarea cu alte baze de date); se mai pot folosi de asemenea n cazul modificrii cerinelor clienilor.

6.3 Documentaia pentru schemele E-R

O schem E-R este adeseori insuficient pentru a descrie toate aspectele unei aplicaii n detaliu. n primul rnd ntr-o schem E-R sunt precizate doar numele conceptelor, acest fapt fiind insuficient pentru a explica semnificaia acestora. Spre exemplu, n figura 17, nu este clar dac entitatea PROIECT se refer la un proiect intern al companiei sau la un proiect extern la care compania respectiv este parte. Mai mult, dac schema este complex, se poate ntmpla s nu poat fi reprezentate toate proprietile conceptelor care apar ntr-un mod inteligibil. n schema din figura 17 ar fi greu de introdus i alte atribute pentru ANGAJAT fr a reduce accesibilitatea schemei. Pe de alt parte, este imposibil reprezentarea unor proprieti ale datelor prin intermediul schemelor E-R. n exemplul din figura 17 s presupunem c un angajat poate fi manager doar n departamentul de care aparine. Aceast proprietate nu poate fi exprimat direct n schem deoarece se refer la dou concepte independente (management i membru) descrie prin dou relaii i nu exist construcii care s permit corelarea a dou relaii. Un alt exemplu care nu se poate implementa direct pe schema E-R ar fi acela n care se impune ca un angajat s nu poat avea un salariu mai mare dect managerul departamentului de care aparine. Ambele proprieti menionate sunt de tipul constrngere de integritate. Modelul E-R nu furnizeaz mijloace potrivite pentru reprezentarea constrngerilor complexe impuse datelor. Din motivele precizate mai sus, o schem E-R trebuie nsoit de o documentaie care s faciliteze interpretarea schemei i descrierea proprietilor care nu pot fi exprimate direct prin construciile puse la dispoziie de modelul E-R.
Reguli de operare

Regulile de operare reprezint una din uneltele utilizate de analiti pentru a descrie proprietile unei aplicaii care nu pot fi exprimate direct cu ajutorul modelului conceptual. Aceast abordare permite specificarea regulilor unei aplicaii. Spre exemplu, faptul c un angajat nu poate ctiga mai mult dect managerul su este o regul de operare. n particular, o regul de operare poate fi: descrierea unui concept relevant al aplicaiei sau mai degrab o definire precis a entitilor, atributelor sau relaiilor unui model E-R; o constrngere de integritate aplicat datelor aplicaiei; o derivare, sau mai precis un concept care poate obinut pe baza unei deducii sau a unui calcul matematic din alte concepte ale schemei (spre exemplu un atribut Cost care poate fi obinut ca sum a atributelor Net i Taxe); Pentru regulile din prima categorie precizat anterior nu este posibil definirea unei sintaxe exacte i de aceea se folosesc propoziii exprimate n limbaj natural. Aceste reguli sunt formulate n termenii vocabularului. Regulile ce descriu constrngeri de integritate i derivri folosesc definiii formale.

91

Constrngerile de integritate pot fi exprimate sub forma aseriilor care sunt declaraii ce trebuie satisfcute ntotdeauna de baza de date. Pentru claritate, unele declaraii trebuie s fie atomice. O notaie de tipul if <condiie> then <aciune> nu este potrivit pentru a exprima o regul. O structur mai potrivit pentru a exprima o regul de operare sub forma unei aserii poate fi:

<concept> trebuie/nu trebuie <expresie a conceptelor>

unde conceptele pot corespunde fie unui concept a schemei E-R la care se refer fie unui concept derivat. Spre exemplu, pentru a exprima constrngerile pentru schema din figura 17, se utilizeaz urmtoarele reguli de operare: (RO1) managerul departamentului trebuie s aparin departamentului; (RO2) un angajat nu trebuie s aib salariul mai mare dect managerul departamentului cruia i aparine; (RO3) un departament din filial Iai trebuie manageriat de un angajat cu mai mult de 10 ani vechime n companie
Regulile de operare care descriu derivri pot fi exprimate prin specificarea operaiilor (matematice sau de alt fel) care permit obinerea conceptelor derivate. O structur posibil este urmtoarea:

<concept> este obinut prin <operaii asupra conceptelor>

Dac n exemplul tratat pn acum entitatea DEPARTAMENT are un atribut NumrDeAngajai, se poate introduce o regul de forma: (RO4) numrul angajailor dintr-un departament este obinut prin numrarea angajailor care aparin departamentului respectiv; n momentul n care schema conceptual este translat ntr-o baz de date (fazele logice i fizice ale proiectrii) se pot implementa prin diferite metode reguli de operare ne-descriptive pentru a garanta consistena datelor astfel nct acestea s respecte proprietile impuse. Se pot aborda urmtoarele ci:

utilizarea SQL pentru definirea schemei logice a bazei de date prin intermediul constrngerilor predefinite sau a aseriilor; utilizarea declanatorilor sau a regulilor active; utilizarea manipulrilor SQL potrivite invocate din interiorul unui program.

Tehnici de realizare a documentaiei

Documentaia pentru conceptele variate reprezentate ntr-o schem pot fi organizate uor sub forma unui dicionar de date. Acesta este format din dou tabele:

primul tabel descrie entitile din schem: numele lor, definiii informale n limbaj natural, lista tuturor atributelor (cu o descriere a acestora) i identificatorii posibili; al doilea tabel descrie relaiile: numele lor, descriere informal, lista atributelor (cu descrieri posibile) i lista entitilor implicate mpreun cu cardinalitile de participare la relaie. 92

Un exemplu de dicionar de date pentru schema din figura 17 este prezentat n figura 20. Este de notat faptul c dicionarul de date poate fi utilizat i pentru documentarea unor constrngeri impuse datelor i altor forme de reguli de operare. Se mai poate alctui un tabel n care se listeaz regulile organizate dup tip. Unele reguli pot fi exprimate n formele precizate n seciunea anterioar. S reamintim faptul c este important reprezentarea tuturor regulilor care descriu constrngeri ce nu sunt exprimate n schem, dar poate fi de asemenea folositoare reprezentarea regulilor deja reprezentate n schem. Un exemplu de documentaie de acest tip referitoare la schema din figura 17 este prezentat n figura 21.

Entitate ANGAJAT
PROIECT DEPARTAMENT FILIAL

Descriere Angajai care lucreaz n companie Proiectele companiei la care lucreaz angajaii Departamentele filialei companiei Filiala companiei ntr-un ora

Atribute CNP, Nume, Prenume, Vrst Nume, Buget, DatLivrare Telefon, Nume
Ora, Adres (Numr, Strad, CodPotal)

Identificator CNP
Nume Nume, FILIAL Ora

Relaie MANAGEMENT
MEMBRU PARTICIPARE COMPOZIIE

Descriere Asociaz un manager cu un departament Asociaz un angajat cu un departament Asociaz angajaii cu proiectele Asociaz un departament cu o filial

Entiti implicate Angajat (0,1) Departament (1,1) Angajat (0,1) Departament (1,N) Angajat (0,N) Proiect (1,N) Departament (1,1) Filial (1,N)

Atribute

DatStart DatStart

Figura 20. Dicionarul de date pentru schema din figura 17 Constrngeri (RO1) managerul departamentului trebuie s aparin departamentului; (RO2) un angajat nu trebuie s aib salariul mai mare dect managerul departamentului cruia i aparine; (RO3) un departament din filial Iai trebuie manageriat de un angajat cu mai mult de 10 ani vechime n companie (RO4) un angajat care nu aparine unui departament nu trebuie s participe la nici un proiect. Derivri (RO5) bugetul unui proiect este obinut prin nmulirea sumei salariilor angajailor ce lucreaz la el cu 3 Figura 21. Reguli de operare pentru schema din figura 17

Probleme propuse.
1. Se consider schema E-R din figura 22. 93

a) Corectai schema, lund n considerare proprietile fundamentale ale generalizrilor. b) Schema reprezint doar femeile care muncesc; modificai schema astfel nct s reprezinte toi muncitorii, brbai i femei. c) Atributul Jude poate fi privit ca o sub-proprietate a atributului ar; restructurai schema n acest sens. 2. Adugai cardinalitile minime i maxime i identificatorii pentru schema obinut dup rezolvarea problemei 1; specificai dac exist constrngeri de integritate pe schem care nu pot fi exprimate prin modelul entitate-relaie. 3. Reprezentai urmtoarele informaii printr-o schem entitate-relaie: o companie produce CD-uri cu un cod i un titlu; pe fiecare CD au fost nregistrai unul sau mai muli cntrei, fiecare avnd un nume i o adres i civa dintre acetia i un nume de scen. 4. Completai schema din problema 3 cu informaii care vi se par c lipsesc. 5. Creai o schem E-R pentru a reprezenta urmtoarele concepte, utiliznd, dac este cazul, construcii de tip generalizare. Indicai atributele entitilor implicate i tipul generalizrilor, rezolvnd eventualele suprapuneri. Angajaii unei companii se mpart n manageri, programatori, analiti, efi de proiect i secretare. Exist analiti care sunt de asemenea programatori. efii de proiect trebuie s fie manageri. Fiecare angajat are un cod, nume i prenume. Fiecare categorie de angajai are un salariu de baz. Fiecare angajat (n afar de manageri) are fixat un numr de ore de munc.

Figura 22. Schema E-R pentru problema 1.

94

Capitolul 7. Proiectarea conceptual

Proiectarea conceptual a bazelor de date const n construirea unei scheme EntitateRelaie care furnizeaz o descriere optim a cerinelor clienilor. Construcia schemei este un proces iterativ, aceasta suferind o serie de transformri i corecii. n acest capitol se vor descrie strategii pentru dezvoltarea unei scheme conceptuale.

7.1 Extragerea i analiza cerinelor

Prin extragerea cerinelor se nelege identificarea complet a problemelor pe care aplicaia trebuie s le rezolve i a caracteristicilor aplicaiei. Cerinele sunt transformate n specificaii care n general sunt exprimate n limbaj natural i din acest motiv pot fi ambigue i dezorganizate. Analiza cerinelor presupune clarificarea i organizarea specificaiilor cerinelor. Cerinele pot proveni din mai multe surse, cum ar fi: Utilizatori ai aplicaiei. n acest caz, informaia este obinut prin interviuri sau prin intermediul unor documente specifice scrise special pentru acest scop. Documentaie existent referitoare la problema de rezolvat: reguli interne, proceduri de operare etc. Sunt necesare colectarea i selecia. Responsabilitatea revine proiectantului. Posibile aplicaii anterioare care trebuie s fie nlocuite sau cu care noua aplicaie trebuie s interacioneze.

Exemplu Se cere proiectarea unei baze de date pentru o companie ce organizeaz cursuri de instruire i pentru care s-au colectat specificaiile prezentate n figura 1. Datele au fost extrase prin interviuri cu angajaii companiei.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Dorim crearea unei baze de date pentru o companie care face cursuri de instruire Pentru aceasta trebuie s stocm date despre instruii i instructori. Pentru fiecare participant la curs (n jur de 5000), identificai prin cod, vrem s stocm codul numeric personal, numele, vrsta, sexul, locul naterii, numele angajatorului, adresa i numrul de telefon, angajatorii anteriori (i perioada angajrii), cursurile urmate (exist circa 200 de cursuri) i aprecierea final la fiecare curs. Avem nevoie de asemenea s reprezentm seminariile la care fiecare participant este ateptat n prezent i, pentru fiecare zi, locurile i orele la care clasele sunt ocupate. Fiecare curs are un cod i un titlu i fiecare curs poate fi organizat de oricte ori. Fiecrei organizri a unui curs particular i spunem ediie a cursului. Pentru fiecare ediie vom reprezenta data de start, data de sfrit i numrul participanilor. Dac un instruit este dintr-o profesie liberal trebuie cunoscut domeniul de expertiz i dac este necesar titlul su. Pentru oricine care lucreaz la companie, vom stoca nivelul i poziia deinut. Pentru fiecare instructor (circa 300) vom preciza numele, vrsta, locul naterii, ediia cursului predat, cursurile predate n trecut i cursurile pe care un titular este calificat s le in. Se stocheaz numerele de telefon ale tuturor instructorilor. Un instructor poate fi angajat permanent al companiei de training sau poate fi angajat temporar.

Figura 1. Exemplu de cerine exprimate n limbaj natural Este evident c cerinele au ambiguiti. Spre exemplu exist participani sau instruii, titulari sau instructori, cursuri sau seminarii. 95

Vom stabili cteva reguli pentru scrierea specificaiilor mai precis i fr ambiguiti: Se alege un nivel potrivit de abstractizare. Se evit termenii prea generali sau prea specifici. n cazul nostru, termenul perioad (linia 5), titlu (linia 14) i apreciere (linia 6) pot fi specificai mai precis (dat start i dat sfrit, titlu profesional i not). Se standardizeaz structura propoziiei. Spre exemplu pentru <concept> pstrm <proprieti>. Se evit frazele complexe (angajat este preferat lui oricine care lucreaz pentru o companie linia 15) Se identific sinonimele i omonimele (ex.: titular i instructor, participant curs i instruit, respectiv loc care nseamn locul de natere ct i locul unde se in orele). Pentru sinonime se folosete un singur termen ir pentru omonime se caut ali termeni. Se marcheaz explicit referinele. Absena referinelor dintre termeni duce la concepte ambigue (ex.: la linia 5 adresa i numrul de telefon se refer la angajat sau angajator?) Se construiete un vocabular. Pentru fiecare termen, vocabularul conine o scurt descriere, sinonime posibile i referine la ali termeni coninui de vocabular cu care este n legtur logic. Un exemplu de vocabular este cel prezentat n figura 2.

Termen Instruit

Instructor Curs Companie

Descriere Participant la curs. Poate fi angajat sau s aib o profesie liberal. Titular curs. Poate fi angajat temporar. Curs oferit. Poate avea mai multe ediii Compania unde este angjat participantul sau unde a fost angajat.

Sinonime Participant

Legturi Curs, Companie

Titular Seminar

Curs Instructor, Instruit Instruit

Figura 2. Exemplu de vocabular n acest moment se pot rescrie specificaiile folosind cele menionate mai sus i se ncearc gruparea cerinelor ca n figura 3. Dup specificarea datelor trebuie specificate operaiile care trebuie executate asupra acestor date. n cazul nostru operaiile ar putea fi: Operaia 1: se insereaz un nou instruit incluznd datele despre el (se realizeaz de aproximativ 40 de ori pe zi) Operaia 2: se atribuie un instruit unei ediii a unui curs (de 50 de ori pe zi) Operaia 3: se insereaz un nou instructor, incluznd toate datele i cursurile pe care acesta este calificat s le predea (de dou ori pe zi) Operaia 4: se atribuie un instructor calificat pentru o ediie a unui curs (de 15 ori pe zi) Operaia 5. se afieaz toate informaiile despre o ediie anterioar a cursului: titlu, orar, numr de instruii (de 10 ori pe zi) Operaia 6: afieaz toate cursurile disponibile, cu informaii despre instructorii calificai s le in (de 20 de ori pe zi) Operaia 7: pentru fiecare instructor, se gsesc instruiii pentru toate cursurile pe care le ine sau le-a inut(de 5 ori pe sptmn) 96

Operaia 8: se realizeaz o analiz statistic a tuturor instruiilor cu toate informaiile despre ei, despre ediiile cursurilor pe care le-au urmat i notele obinute (de 10 ori pe lun)

Cerine generale Se dorete crearea unei baze de date pentru o companie care deruleaz cursuri de instruire. Se dorete pstrarea datelor pentru instruii i instructori. Cerine referitoare la instruii Pentru fiecare instruit (n jur de 5000), identificat de un cod, se va pstra codul numeric personal, nume, vrst, sex, oraul de natere, angajatorul curent, angajatorul precedent (cu data de start i data de sfrit a perioadei n care a fost angajat), ediiile cursurilor pe care instruitul le urmeaz n prezent i cele pe care le-a urmat mpreun cu nota obinut. Cerine referitoare la angajatorii instruiilor Pentru fiecare angajator a unui instruit se va pstra numele, adresa i numrul de telefon Cerine referitoare la cursuri Pentru fiecare curs (n jur de 200) trebuie stocat numele i codul. Fiecare organizare a unui curs anume se numete ediie a cursului. Pentru fiecare ediie se va stoca data de start, data de sfrit i numrul participanilor. Pentru ediia curent se vor pstra datele, slile de clas, i momentele n care clasa este ocupat. Cerine referitoare la tipuri specifice de instruii Pentru un instruit care practic o profesie liberal (liber profesionist), se va pstra domeniul de expertiz i eventual titlul profesional. Pentru un instruit care este angajat, se vor pstra nivelul i poziia ocupat. Cerine referitoare la instructori Pentru fiecare instructor (n jur de 300), se vor pstra numele, vrsta, ora de natere toate numerele de telefon, ediiile cursurilor predate n prezent i n trecut, i cursurile pe care calificat s le predea. Instructorii pot fi angajai permaneni ai companiei de training sau pot fi angajai temporar

7.2 Strategii de proiectare

Pentru dezvoltarea unei scheme conceptuale pe baza specificaiilor impuse se pot aplica strategii de proiectare din alte domenii, strategii ce vor fi descrise n continuare.
Strategia top-down (se sus n jos)

Schema conceptual este obinut printr-o serie de rafinri succesive ale schemei iniiale ce descrie toate cerinele prin intermediul ctorva concepte abstracte. Procedura este descris n figura 4. Fiecare nivel reprezentat conine o schem ce descrie informaii diverse la diferite grade de detaliu. Trecerea de la un nivel la altul se face cu ajutorul unor transformri numite primitive de transformare de sus n jos (v. figura 5). Primitivele opereaz pe un singur concept al schemei i l transform ntr-o structur de complexitate mai ridicat, capabil s descrie conceptul iniial n detaliu. 97

Transformarea T1 se aplic atunci cnd o entitate descrie dou concepte logice diferite legate unele de altele. Spre exemplu n aplicaia descris n seciunea anterioar se poate ncepe cu entitatea CURS. Acest concept pare prea abstract, putnd face deosebirea ntre TIPCURS (care are un cod i un titlu) i EDIIECURS (care are o dat de start i una de sfrit). Aceste dou entiti pot fi legate prin relaia TIP. Transformarea T2 este aplicat atunci cnd o entitate este alctuit din sub-entiti. n aplicaia noastr aceast transformare are loc atunci cnd ne dm seama c printre cei instruii se poate distinge ntre ANGAJAT i LIBERPROFESIONIST. Transformarea T3 se aplic atunci cnd o relaie descrie dou sau mai multe concepte diferite legnd aceleai entiti. Spre exemplu, n relaia PREDARE ntre instructori i cursuri, PREDARECURENT poate fi separat de PREDAREANTERIOAR.

Figura 4. Strategia top-down

98

Transformare T1 De la o entitate la dou entiti i relaia dintre ele

Concept iniial

Rezultat

T2 De la o entitate la o generalizare

T3 De la o relaie la relaii multiple

T4 De la o relaie la o entitate cu relaii T5 Adugarea atributelor la o entitate T6 Adugarea atributelor la o relaie

Figura 5. Primitive de transformare top-down

Transformarea T4 se aplic atunci cnd o relaie descrie un concept cu existen autonom. Spre exemplu, dac relaia CONTRACT ntre o entitate CONSULTANT i o entitate COMPANIE are multe atribute, atunci ea este mai bine reprezentat printr-o entitate legat de altele prin intermediul unor relaii binare. Transformarea T5 se aplic pentru adugarea unor proprieti (atribute) entitilor. Aceast se ntmpl spre exemplu atunci cnd rafinm entitatea INSTRUIT prin adugarea atributelor CNP, Nume, Vrst, Sex i OraDeNatere. Transformarea T6 se aplic atunci cnd se adaug proprieti la o relaie, ntr-o manier similar transformrii T5.
Avantajul acestei strategii este acela c proiectantul poate ncepe cu o reprezentare complet a cerinelor, chiar dac lipsesc unele detalii. Dezavantajul ar fi c este necesar o viziune global asupra tuturor conceptelor, ceea ce este dificil de realizat n cazul aplicaiilor complexe.

99

Strategia bottom-up (de jos n sus)

n aceast strategie specificaiile iniiale sunt descompuse n componente pn cnd fiecare component descrie un fragment elementar al specificaiilor (v. figura 6). n acest punct, componentele sunt reprezentate prin scheme conceptuale simple. Aceste scheme vor fi combinate pentru a se obine schema final. i n acest caz se utilizeaz transformri elementare (primitive de transformare de sus n jos figura 7). Aceste primitive introduc n schem concepte noi care nu au fost prezente pn n acel moment, capabile s descrie aspecte ale aplicaiei care nu au fost luate n considerare. Transformarea T1 se aplic atunci cnd se identific n specificaii o clas de obiecte cu proprieti comune. n aplicaia descris anterior se poate identifica entitatea CLAS (ce pstreaz o anumit clas la un anumit moment). Transformarea T2 se aplic atunci cnd se identific n specificaii o legtur logic ntre dou entiti. n aplicaia noastr se poate identifica relaia CALIFICARE ntre entitile INSTRUCTOR i CURS. Transformarea T3 se aplic atunci cnd se identific n specificaii o generalizare ntre entiti. Spre exemplu, entitatea INSTRUCTOR este o generalizare a entitilor PERMANENT i TEMPORAR. Transformarea T4 se aplic atunci cnd se identific n specificaii o entitate care poate fi privit ca o agregare a unor serii de atribute. Spre exemplu se identific entitatea INSTRUIT cu proprietile CNP, Nume, Vrst, Sex i OraDeNatere. Transformarea T4 se aplic atunci cnd o relaie poate fi privit ca o agregare a unor atribute.

Figura 6. Strategia bottom-up

100

Transformare T1 Generarea unei entiti

Concept iniial

Rezultat

T2 Generarea unei relaii

T3 Generarea unei generalizri

T4 Agregarea unor atribute pe o entitate T5 Agregarea unor atribute pe o relaie

Figura 7. Primitive de transformare bottom-up Avantajul acestei strategii este acela c permite descompunerea problemei n componente simple care pot fi uor identificate i astfel procesul de proiectare poate fi atribuit mai multor proiectani dac este necesar. Dezavantajul ar fi c este necesar integrarea mai multor scheme conceptuale.
Strategia inside-out (din interior spre exterior)

Aceast strategie poate fi privit ca o particularizare a strategiei de jos n sus. Se ncepe cu cteva concepte importante i apoi pe baza acestora, proiectarea se extinde radial. Cu alte cuvinte se reprezint mai nti conceptele cele mai apropiate de conceptele iniiale i apoi procesul de proiectare se mut spre conceptele mai deprtate prin intermediul navigrii prin specificaii. Avantajul acestei strategii const n eliminarea pailor de integrare din strategia de jos n sus. Pe de alt parte este necesar examinarea, din timp n timp, a tuturor specificaiilor cutnd concepte ce nu au fost reprezentate nc. Un exemplu al dezvoltrii din interior spre exterior se poate observa n figura 8, care se refer la exemplul din figura 17 a capitolului 6. Ariile indicate prezint o dezvoltare cronologic posibil a schemei.

101

Figura 8. Exemplu de strategie inside-out

Strategia mixt

Se poate adopta o strategie mixt care combin avantajele strategiilor top-down, bottomup i inside-out. Proiectanii descompun cerinele n componente conform strategiei bottom-up, dar nu se dezvolt componentele separat. n acelai timp se definete o schem cadru care conine, la nivel abstract, principalele componente ale aplicaiei. Schema cadru furnizeaz o viziune sintetic asupra procesului de proiectare i uureaz integrarea schemelor dezvoltate separat. Spre exemplu, pentru exemplul prezentat n seciunile anterioare o schem cadru posibil este prezentat n figura 9.

Figura 9. Schema cadru pentru procesul de instruire ntr-o companie Din acest punct se pot examina separat conceptele principale prin rafinri graduale (urmnd paii strategiei top-down) sau se pot extinde componentele cu concepte care nu au fost nc reprezentate (conform strategiei bottom-up).

7.3 Calitatea unei scheme conceptuale.

Proprietile utilizate pentru a stabili calitatea unei scheme sunt:

Corectitudinea schemei. O schem conceptual este corect dac utilizeaz corect construciile puse la dispoziie de modelul conceptual. Se pot defini dou tipuri de erori:
102

erorile sintactice marcheaz utilizarea ilegal a unei construcii (ex.: generalizarea dintre relaii n detrimentul entitilor). erorile semantice marcheaz utilizarea unei construcii care nu-i urmrete definiia (ex.: utilizarea unei relaii pentru a descrie faptul c o entitate este o specializare a altei entiti).

Caracterul complet al schemei. O schem conceptual este complet dac include concepte ce reprezint toate cerinele de date i care permit execuia tuturor operaiilor incluse n cerinele operaionale. Accesibilitatea schemei. O schem conceptual este accesibil cnd reprezint cerinele ntr-un mod natural i uor de neles. Minimalitatea schemei. O schem este minimal cnd toate specificaiile datelor sunt reprezentate doar o singur dat n schem. O schem nu este minimal cnd apar redundanele concepte derivate din altele. O surs tipic de redundane este prezena ciclurilor determinate de prezena relaiilor i/sau generalizrilor. Cteodat redundanele sunt necesare din motive de proiectare, aceste situaii fiind precizate n documentaie.

7.4 Metod de abordare a proiectrii conceptual

n practic se aplic foarte rar o singur strategie de proiectare conceptual. Independent de strategia aleas, apare necesitatea modificrii schemei utiliznd transformri top-down (prin care se rafineaz conceptele deja prezentate) i transformri bottom-up (prin care se adaug concepte noi). Etapele ce trebuie parcurse pentru realizarea unei scheme conceptuale sunt:
1. Analiza cerinelor

Construirea unui vocabular Analiza cerinelor i eliminarea ambiguitilor Gruparea cerinelor Identificarea celor mai relevante concepte i reprezentarea lor ntr-o schem cadru Descompunerea cerinelor cu referire la conceptele prezentate n schema cadru

2. Etapa de baz

3. Descompunerea (folosit dac este potrivit sau necesar)

4. Etapa iterativ (se repet pentru toate schemele pn cnd fiecare specificaie este reprezentat)

Rafinarea conceptelor pe baza cerinelor Adugarea de concepte noi care descriu pri ale cerinelor nereprezentate nc Integrarea sub-schemelor ntr-o schem general innd cont de schema cadru Verificarea corectitudinii i realizarea restructurrilor necesare 103

5. Integrarea

6. Analiza calitii

Verificarea caracterului complet al schemei i realizarea restructurrilor necesare Verificarea minimalitii, listarea redundanelor i dac este necesar realizarea restructurrilor necesare Verificarea accesibilitii i realizarea restructurrilor necesare dac este necesar

7.5 Exemplu de proiectare conceptual

Se consider exemplul unui proces de instruire din cadrul unei companii despre care am mai discutat i n seciunile anterioare. Am indicat o schem cadru posibil n figura 9. Din acest punct se poate decide analizarea separat a specificaiilor pentru instruii, cursuri i instructori i de a aplica o strategie inside-out pentru fiecare. Ne vom referi nti la instruii. Se pot identifica dou tipuri: angajai i liber profesioniti. Aceste entiti se reprezint ca specializri ale entitii INSTRUIT; generalizarea este total. Este necesar reprezentarea angajatorilor instruiilor. Aceasta se poate face introducnd entitatea ANGAJATOR care este legat printr-o relaie de ANGAJAT. Este necesar de asemenea distincia ntre conceptele angajare actual i anterioar. Decidem s divizm relaia n dou relaii: ANGAJAREANTERIOAR i ANGAJAREACTUAL. Prima are o dat de start i una de sfrit i este legat de entitatea INSTRUIT (deoarece i liber profesionitii se poate s fi fost angajai). A doua relaie are doar dat de start i este legat de entitatea ANGAJAT. Adugnd atribute entitilor i relaiilor, cardinaliti pentru relaii i identificatori ai entitilor se obine schema din figura 10.

Figura 10. Rafinarea unei poriuni a schemei cadru Se observ c entitatea INSTRUIT are doi identificatori (Cod i CNP). Atributul TitluProfesional este opional.

104

Pentru instructori se disting cazurile n care acetia sunt fie angajai permaneni ai companiei, fie angajai temporar. Se realizeaz astfel o generalizare total, cu entitatea printe INSTRUCTOR. Se adaug atributele precizate n specificaii: Nume, Vrst, OraDeNatere i Telefon. Se observ cu nu se poate stabili un identificator pe baza acestor atribute. Din acest motiv, se decide folosirea CNP-ului instructorului chiar dac nu este cerut n specificaii. Schema rezultat este prezentat n figura 11.

Figura 11. Rafinarea unei alte poriuni a schemei cadru n ceea ce privete entitatea CURS, exist dou concepte distincte legate: un concept abstract al cursului (cu nume i cod) i ediia cursului (cu dat de start, dat de sfrit i numrul de instruii). Vom reprezenta aceste concepte cu dou entiti distincte legate prin relaia TIP. Clasele unui curs se pot descrie printr-o entitate legat de ediiile cursurilor prin relaia COMPOZIIE. Se adaug apoi atribute, cardinaliti i identificatori. O clas este identificat prin sal, timp i dat. Pentru ediiile unui curs, presupunem c dou ediii ale aceluiai curs nu pot ncepe n aceeai zi i astfel un identificator pentru entitatea EDIIECURS este format din atributul DatStart i entitatea CURS. Schema rezultat este prezentat n figura 12.

Figura 12. Rafinarea unei alte pri a schemei cadru Schema final este obinut prin integrarea schemelor obinute pn n acest punct. ntre schemele referitoare la instructori i cursuri. n schema cadru aceste pri sunt legate prin relaia PREDARE. Aceast relaie trebuie rafinat. Se identific trei legturi diferite ntre instructori i cursuri: predare curent, predare anterioar i calificare. Aceste legturi se reprezint prin intermediul a trei relaii: primele dou leag entitile INSTRUCTOR i EDIIECURS, iar a treia leag INSTRUCTOR de CURS. n aceste moment se poate face integrarea. innd cont de schema cadru, trebuie clarificat relaia ntre cursuri i instruii. Apar dou cazuri: prezen curent i i prezen anterioar. Deci definim dou relaii ntre entitile INSTRUIT i EDIIECURS. Pentru o prezen anterioar intereseaz nota final. Se obine n final schema din figura 13.

105

Schema final E-R pentru o companie de instruire n acest moment se ncepe verificarea schemei obinute. Se verific dac schema este complet prin ntoarcerea la specificaii i verificarea dac toate datele sunt reprezentate i toate operaiile pot fi efectuate. Spre exemplu, s considerm operaia 7, n care se cer instruiii pentru toate cursurile inute de un instructor. Datele pentru aceast operaie se gsesc pe schem n felul urmtor: se pleac de la entitatea INSTRUCTOR, se trece prin relaiile PREDARECURENT i entitatea EDIIECURS, relaiile PREZENCURENT i PREDAREANTERIOAR, PREZENANTERIOAR i apoi se ajunge la entitatea INSTRUIT. Cu privire la minimalitate, s notm c exist o redundan n schem: atributul NrParticipani al entitii EDIIECURS se poate obine prin numrarea numrului de instane ale entitii INSTRUIT care sunt legate de ediia respectiv. Se va discuta despre eliminarea sau meninerea acestei redundane n capitolul urmtor, referitor la proiectarea logic. Trebuie menionat n final c schema trebuie s aib o documentaie potrivit. Este important descrierea restriciilor posibile care nu sunt exprimate n schem, sub forma regulilor de operare. Un exemplu ar fi precizarea c un instructor pred un curs doar dac este calificat s o fac.

Probleme propuse
1. Se dorete crearea unei baze de date prin care s se gestioneze mprumuturile dintr-o bibliotec. Specificaiile obinute prin interviu sunt urmtoarele:
Un cititor care utilizeaz biblioteca are un card pe care este memorat un cod, numele i adresa. Utilizatorul face o cerere pentru mprumutul unor cri catalogate n bibliotec. Fiecare carte are un titlu i o list a autorilor i pot exista mai multe exemplare pentru fiecare carte. Fiecare carte din bibliotec este identificat printr-un cod. Urmnd cererea, se consult o arhiv a crilor disponibile (aceasta conine care nu sunt mprumutate n prezent). Dac este disponibil cartea, se caut cartea pe rafturi. Odat ce cartea este gsit este dat cititorului. Textul este apoi clasificat ca fiind mprumutat. Dup ce cartea este citit, este returnat, pus napoi pe raft i re-clasificat ca disponibil. Pentru fiecare mprumut se nregistreaz orele i datele lurii i returnrii crii.

106

S se analizeze specificaiile, s se filtreze ambiguitile i s se grupeze dup tip. S se acorde o atenie deosebit diferenei dintre conceptul de carte i de copie a unei cri. Identificai legturile logice dintre grupurile de specificaii obinute. 2. S se reprezinte specificaiile din exerciiul precedent folosind o schem entitate-relaie. 3. S se realizeze o schem entitate-relaie care descrie datele unei aplicaii referitoare la un lan de trguri auto. Intereseaz:

trgurile, cu nume (identificator), adres i numr de telefon automobilele, cu numr de nregistrare (identificator), model (ir de caractere) i proprietar clienii (proprietarii de automobile) cu cod numeric personal, nume, prenume i telefon; n plus fiecare client poate fi proprietarul mai multor automobile service-ul realizat la trg, cu numr (unic pentru un trg anume) dat de start i de sfrit, componentele nlocuite (cu cantiti) i numrul orelor de munc piesele de schimb disponibile cu cod, nume i cost pe bucat

Precizai cardinalitile relaiilor i (cel puin) un identificator pentru fiecare entitate

107

Capitolul 8. Proiectarea logic

Scopul proiectrii logice este de a construi o schem logic ce reprezint corect i eficient toate informaiile descrise ntr-o schem entitate-relaie. Translatarea din schema conceptual n cea logic nu este un proces simplu deoarece, n primul rnd, nu toate construciile modelului E-R pot fi translatate natural ntr-un model relaional. Spre exemplu, dac o entitate poate fi reprezentat simplu printr-o relaie, pentru o generalizare exist mai multe variante. n al doilea rnd, scopul proiectrii conceptuale este de reprezenta datele la un nivel nalt de abstractizare, fr a ine cont de detaliile de implementare. Proiectarea logic trebuie s ia n considerare performanele impuse produsului final. Din acest motiv, proiectarea logic presupune parcurgerea urmtoarelor etape:

Restructurarea schemei E-R faz independent de modelul logic ales i care se bazeaz pe criterii de optimizare a schemei i de simplificare a urmtoarei etape; Translarea n modelul logic care ine cont de un anumit model logic (modelul relaional spre exemplu) i poate include alte optimizri, bazate pe caracteristicile modelului logic.

La intrarea primei etape exist schema conceptual i estimarea ncrcrii bazei de date (cantitatea de date i cerinele operaionale). Rezultatul acestei etape este schema E-R restructurat, care nu mai este o schem E-R propriu-zis deoarece utilizeaz aspecte de implementare pentru reprezentarea datelor. Aceast schem i modelul logic ales formeaz intrarea celei de-a doua etape, care va produce schema logic a bazei de date, mpreun cu constrngerile de integritate aferente i documentaia.

Figura 1. Proiectarea logic a unei baze de date

8.1 Analiza performanelor schemei E-R O schem E-R poate fi modificat astfel nct s se optimizeze unii indicatori de performan:
108

costul unei operaii evaluat n funcie de numrul de apariii ale entitilor i relaiilor ce sunt parcurse pentru a executa o operaie asupra unei baze de date; cerina de stocare evaluat n funcie de numrul de octei necesari stocrii datelor descrise de schem. Pentru a evalua aceti indicatori avem nevoie de urmtoarele informaii:

volumul de date numrul de apariii ale fiecrei entiti i relaii din schem; dimensiunea fiecrui atribut. caracteristicile operaiilor: tipul operaiei (interactiv sau batch); frecvena operaiei (numrul mediu de execuii ntr-un anumit interval de timp); datele implicate (entiti i/sau relaii).

S lum ca exemplu schema din figura urmtoare:

Figura 2. Exemplu de schem E-R Operaiile tipice pentru aceast schem pot fi: operaia 1: atribuie un angajat unui proiect; operaia 2: gsete datele pentru un angajat, pentru departamentul n care lucreaz acesta i pentru proiectele n care este implicat; operaia 3: gsete datele pentru toi angajaii unui anumit departament; operaia 4: pentru fiecare filial, gsete departamentele, cu numele managerilor i lista angajailor din fiecare departament. Volumul datelor i caracteristicile generale ale operaiilor pot fi descrise prin utilizarea unor tabele, ca n figura urmtoare:

109

Tabelul volumelor
Concept Filial Departament Angajat Proiect Compoziie Membru Management Participare Tip E E E E R R R R Volum 10 80 2000 500 80 1900 80 6000

Tabelul operaiilor
Operaie Op 1 Op 2 Op 3 Op 4 Tip I I I B Frecven 50/zi 100/zi 10/zi 2/sptmn

Figura 3. Exemplu de tabele ale volumelor i operaiilor n tabelul volumelor se prezint toate conceptele schemei (entiti i relaii) cu volumul lor estimat. n tabelul operaiilor se nscriu, pentru fiecare operaie, frecvena ateptat i un simbol care arat dac operaia este interactiv (I) sau batch (B). n tabelul volumelor, numrul apariiilor unei relaii depinde de doi parametri: volumul entitilor implicate n relaie de cte ori o apariie a acestor entiti particip, n medie, ntr-o apariie a relaiei; acest parametru depinde de cardinalitile relaiei. Spre exemplu, numrul de apariii ale relaiei COMPOZIIE este egal cu numrul departamentelor, deoarece cardinalitatea relaiei indic faptul c fiecare departament aparine doar unei filiale. Numrul de apariii ale relaiei MEMBRU este mai mic dect numrul angajailor, deoarece exist angajai care nu aparin nici unui departament. Dac un angajat este implicat n medie n trei proiecte avem 6000 de apariii ale relaiei PARTICIPARE (i deci 6000/500=12 angajai n medie pentru fiecare proiect). Pentru fiecare operaie se pot descrie datele implicate prin intermediul schemei de navigare care const n fragmente ale schemei E-R relevante pentru operaie. Pe aceast schem este util desenarea cilor logice care trebuie urmate pentru a accesa informaiile cerute. Un exemplu de schem de navigare este prezentat n figura 4, referitoare la operaia 2.

Figura 4. Exemplu de schem de navigare Acum se poate estima costul unei operaii prin numrarea accesrilor apariiilor entitilor i relaiilor necesare efecturii unei operaii. Ca exemplu ne vom referi tot la operaia 2. innd cont de schema de navigare trebuie s accesm nti o apariie a entitii ANGAJAT pentru a accesa o apariie a relaiei MEMBRU i, prin intermediul acesteia, a unei apariii a entitii DEPARTAMENT. Pentru a obine datele referitoare la un proiect la care angajatul lucreaz trebuie s accesm n medie trei apariii ale relaiei 110

PARTICIPARE (deoarece am presupus c un angajat lucreaz n medie la trei proiecte). Apoi, prin aceast relaie accesm n medie trei apariii ale entitii PROIECT. Aceste informaii pot fi sumate n tabelul accesrilor din figura 5. n ultima coloan a acestui tabel se menioneaz tipul accesului (R pentru citire, W pentru scriere)
Tabelul accesrilor
Concept Angajat Membru Departament Participare Proiect Tip Entitate Relaie Entitate Relaie Entitate Accesri 1 1 1 3 3 Tip R R R R R

Figura 5. Tabelul accesrilor pentru operaia 2

8.2 Restructurarea schemei E-R

Etapele restructurrii unei scheme E- R sunt precizate n figura 6.

Figura 6. Etapele restructurrii schemei E-R

analiza redundanelor - decide tergerea sau pstrarea unor redundane din schema E-R; eliminarea generalizrilor - nlocuiete toate generalizrile cu alte construcii; partiionarea/combinarea entitilor i relaiilor decide dac este convenabil partiionarea unui concept n mai multe sau unirea mai multor concepte separate n unul singur; selecia identificatorilor primari alege un identificator pentru acele entiti care au mai mult de un identificator.

Analiza redundanelor ntr-o schem conceptual o redundan corespunde unei informaii ce poate fi derivat din alte date. Cele mai frecvente exemple sunt:

111

atribute ale cror valori pot fi derivate, pentru fiecare apariie a unei entiti/relaii, din valorile altor atribute pentru aceeai apariie. n exemplul de mai jos, fiecare atribut poate fi dedus din celelalte dou prin operaii aritmetice

atribute ce pot fi derivate din alte atribute aparinnd altor entiti/relaii, de obicei prin intermediul funciilor agregat. n exemplul urmtor, atributul ValoareTotala a entitii ACHIZITIE poate fi calculat din valorile atributului Pret a entitii PRODUS prin sumarea preurilor produselor achiziionate, dup cum se specific n relaia COMPUNERE.

atribute ce pot fi derivate din operaii de numrare a apariiilor. n exemplul de mai jos, atributul NumarLocuitori poate fi obinut prin numrarea apariiilor relaiei REZIDEN n care apare un anumit ora.

relaii ce pot fi derivate din alte relaii n prezena ciclurilor. Relaia INVATARE dintre studeni i profesori poate fi derivat din relaiile PREZEN i ATRIBUIRE. Prezena ciclurilor nu genereaz n mod automat redundane. Spre exemplu, dac se nlocuiete relaia INVATARE cu relaia SUPERVIZARE reprezentnd legtura dintre studeni i supervizori, atunci schema nu mai este redundant.

Prezena informaiilor derivate ntr-o baz de date prezint un avantaj i totodat dezavantaje. Avantajul este reducerea numrului de accesri necesare obinerii informaiilor derivate. Dezavantajele ar fi: creterea cererii de stocare; necesitatea efecturii de operaii suplimentare pentru actualizarea informaiilor derivate.

112

Decizia meninerii sau eliminrii unei redundane poate fi luat prin compararea costului operaiilor ce implic informaia redundant i capacitatea de stocare necesar n cazul prezenei, respectiv absenei redundanei.
Exemplu

S considerm exemplul referitor la persoane i orae

pentru care se definesc urmtoarele operaii: operaia 1: adaug o persoan nou cu oraul de reziden al acesteia; operaia 2: afieaz toate datele referitoare la ora (inclusiv numrul de locuitori). Presupunem de asemenea c ncrcarea bazei de date este dat n tabelele de mai jos. Volumul relaiei REZIDEN este egal cu volumul entitii PERSOANA deoarece cardinalitile indic faptul c fiecare persoan are rezidena ntr-un singur ora.
Tabelul volumelor
Concept Ora Persoan Reziden Tip E E R Volum 200 1000000 1000000

Tabelul operaiilor
Operaie Op 1 Op 2 Tip I I Frecven 500/zi 2/zi

1. S facem o evaluare a performanelor n cazul prezenei redundanei (atributul NumarLocuitori). Presupunem c pentru stocarea numrului de locuitori dintr-un ora sunt necesari 4 octei. Astfel, datele redundante necesit 4 x 200 = 800 octei (nesemnificativ). S estimm acum costul operaiilor. Pentru operaia 1: 1 operaie de scriere n entitatea PERSOAN (adugare persoan); 1 operaie de scriere n relaia REZIDEN (adugare pereche persoan-ora); 1 operaie de citire din entitatea ORA (gsire ora); 1 operaie de scriere n entitatea ORA ( actualizare numr de locuitori).
Tabelul accesrilor (n prezena redundanelor) Operaia 1
Concept Persoana Reziden Ora Ora Tip E R E E Accesri 1 1 1 1 Tip W W R W

Operaia 1 necesit 3 x 500 = 1500 accesri n scriere / zi 1 x 500 = 500 accesri n citire / zi Pentru operaia 2: 1 operaie de citire din entitatea ORA
Tabelul accesrilor (n prezena redundanelor) Operaia 2
Concept Ora Tip E Accesri 1 Tip R

Operaia 2 necesit 1 x 2 = 2 accesri n scriere / zi (neglijabil) 113

Presupunnd c accesul n scriere cost de dou ori mai mult dect accesul n citire, numrul de accesri / zi n prezena redundanelor este 2 x 1500 + 500 = 3500. 2. S facem o evaluare a performanelor n cazul absenei redundanei. Vom evalua costul operaiilor. Pentru operaia 1: 1 operaie de scriere n PERSOANA; 1 operaie de scriere n REZIDEN.
Tabelul accesrilor (n absena redundanelor) Operaia 1
Concept Persoana Reziden Tip E R Accesri 1 1 Tip W W

Operaia 1 necesit 2 x 500 = 1000 accesri n scriere / zi Pentru operaia 2: 1 operaie de citire din ORA (neglijabil) n medie 5000 de operaii de citire din REZIDEN pentru a determina numrul de locuitori (5000 = 1000000 persoane / 200 orae)
Tabelul accesrilor (n absenaredundanelor) Operaia 2
Concept Ora Reziden Tip E R Accesri 1 5000 Tip R R

Operaia 2 necesit 2 x 5000 = 10000 accesri n citire / zi Numrul de accesri / zi n absena redundanelor este de 2 x 1000 + 10000 = 12000. Se observ c n al doilea caz sunt necesare 8500 accesri / zi n plus pentru a salva mai puin de un kilo-octet. Putem trage concluzia c este mai convenabil s meninem redundana n cazul acestei probleme.

Eliminarea generalizrilor

Deoarece modelul relaional nu permite reprezentarea direct a generalizrilor din modelul E-R apare necesitatea transformrii acestor construcii n alte construcii ce pot fi translate cu uurin. Exist trei posibiliti de reprezentare a unei generalizri cu ajutorul entitilor i relaiilor. Pentru nelegerea acestor moduri de transformare s considerm schema din figura 7.

Figura 7. Exemplu de schema cu generalizare

1. nglobarea entitilor copil n entitatea printe

114

Entitile E1 i E2 sunt eliminate i proprietile acestora sunt adugate proprietii printe E0. Se adaug entitii printe atributul Atype pentru a distinge tipul (E1 sau E2) unei apariii a lui E0. A11 i A21 pot avea valoarea NULL pentru unele apariii ale entitii E0. Relaia R2 va avea cardinalitatea minim 0 pentru E0 deoarece apariiile lui E2 formeaz o submulime a apariiilor entitii E0.

2. nglobarea entitii printe n entitile copil

Entitatea printe E0 este eliminat i, prin proprietatea de motenire, atributele sale, identificatorii i relaiile n care era implicat sunt adugate entitilor copil E1 i E2. Relaiile R11 i R12 reprezint restricia relaiei R1 pe apariiile entitii E1, respectiv E2.

3. Substituirea unei generalizri cu relaii

Generalizarea este transformat n dou relaii una la unu ce leag printele de copiii E1 i E2. Nu exist transfer de atribute sau relaii i entitile E1 i E2 sunt identificate extern prin entitatea E0. n noua schem apar constrngeri n plus: nici o apariie a lui E0 nu poate participa 115

n ambele relaii RG1 i RG2.; mai mult, dac generalizarea este complet, fiecare apariie a lui E0 trebuie s participe n exact una din relaiile RG1 i RG2. Pentru a alege una din cele trei variante trebuie avute n vedere urmtoarele aspecte:

Prima opiune este convenabil atunci cnd operaiile implic apariii i atribute ale E0, E1 i E2 ntr-un mod asemntor. n acest caz, dei se stocheaz valori NULL, alegerea asigur mai puine accesri n comparaie cu celelalte variante n care apariiile i atributele sunt distribuite celorlalte entiti. A doua opiune este posibil doar dac generalizarea este total, altfel apariiile lui E0 care nu sunt apariii nici ale lui E1 nici ale lui E2 nu vor putea fi reprezentate. Aceast metod este util cnd exist operaii care se refer doar la apariiile lui E1 sau ale lui E2 i astfel se face distincia ntre aceste entiti. Nu mai exist n principiu atribute ce pot lua valori NULL. Numrul de accesri este mai redus n comparaie cu a treia metod, deoarece nu este necesar accesarea lui E0 pentru a accesa atribute ale E1 i E2 . A treia metod este util atunci cnd generalizarea nu este total i operaiile se refer fie la apariiile i atributele lui E1(E2) fie ale lui E0 i astfel se face distincia ntre entitile printe i copil. Stocarea este mai mic n raport cu prima metod datorit absenei valorilor NULL dar crete numrul accesrilor pentru a pstra consistena apariiilor.

Opiunile prezentate nu sunt singurele posibile. O variant ar fi cea din figura 8. n acest caz, pe baza consideraiilor anterioare, s-a decis nglobarea E0 i E1 i lsarea separat a lui E2. Atributul Atype este adugat pentru a distinge apariiile lui E0 de cele ale E1.

Figura 8. Restructurare posibil a schemei din figura 7

Partiionarea / combinarea entitilor i relaiilor

Creterea eficienei accesului la datele dintr-o baz de date se poate realiza conform urmtorului principiu: operaiile de acces sunt reduse prin separarea atributelor aceluiai concept (entitate sau relaie) ce sunt accesate de operaii diferite, respectiv prin combinarea atributelor aparinnd unor concepte diferite ce sunt accesate de aceleai operaii.

116

Partiionarea entitilor Un exemplu de partiionare a entitilor este prezentat n figura 9: entitatea ANGAJAT este substituit prin dou entiti legate printr-o relaie 1:1. Una din entiti descrie informaii despre statutul unui angajat, iar cealalt descrie informaii personale ale unui angajat. Acest tip de restructurare este util doar dac operaiile ce implic frecvent entitatea original necesit, pentru un angajat, ori numai informaii personale, ori numai informaii legate de angajare.

Figura 9. Exemplu de partiionare a entitilor Acest exemplu este un exemplu de partiionare vertical, n sensul c un concept este divizat innd cont de atributele sale. Avantajul partiionrii verticale este generarea unor noi entiti cu numr mai mic de atribute dect entitatea original. Prin urmare, noile entiti pot fi translate n structuri fizice din care se poate extrage un volum mare de date printr-un singur acces. Este posibil de asemenea i partiionarea orizontal, n care divizarea se face n raport cu apariiile entitii. De exemplu, pot exista operaii asociate analitilor i operaii asociate angajailor din departamentul vnzri. n acest caz se dovedete util partiionarea entitii ANGAJAT n dou entiti distincte, ANALIST i VNZARE, avnd aceleai atribute ca entitatea original. Partiionarea orizontal are ca efect secundar introducerea de duplicate pentru relaiile n care particip entitatea original. Acest fenomen poate avea un impact negativ asupra performanelor bazei de date.

tergerea atributelor multi-valoare Acest tip de restructurare este necesar deoarece modelul relaional nu permite reprezentarea direct a atributelor multi-valoare. Un exemplu este prezentat n figura 10.

Figura 10. Exemplu de tergere a atributelor multi-valoare 117

Entitatea AGENTIE este separat n dou entiti: una avnd acelai nume i aceleai atribute cu entitatea original, n afar de atributul multi-valoare (Telefon) i o entitate TELEFON cu atributul Numar. Entitile sunt legate de o relaie 1:N. Evident, dac atributul este opional, atunci cardinalitatea minim pentru entitatea TELEFON trebuie s fie 0.

Combinarea entitilor
Combinarea entitilor este operaia invers partiionrii. Un exemplu de combinare a entitilor este ilustrat n figura 11. Entitile PERSOANA i APARTAMENT aflate n relaia PROPRIETAR sunt combinate ntr-o singur entitate ce deine atributele ambelor entiti. Aceast restructurare poate fi sugerat de faptul c majoritatea operaiilor frecvente asupra entitii PERSOANA necesit informaii n legtur cu apartamentul deinut de persoana respectiv. Prin urmare se dorete evitarea accesrilor necesare extragerii datelor prin intermediul relaiei PROPRIETAR. Dezavantajul acestei restructurri const n posibilitatea apariiei valorilor NULL n noua entitate PERSOANA deoarece cardinalitatea entitii originale PERSOANA indic faptul c exist persoane ce nu dein un apartament.

Figura 11. Exemplu de combinare a entitilor Operaia de combinare se efectueaz n general asupra relaiilor 1:1 i mai rar asupra relaiilor 1:N sau N:N. Motivul const n apariia redundanelor n atributele non-cheie ale entitii avnd cardinalitatea N.

Alte tipuri de partiionare i combinare

Operaiile de partiionare i combinare pot fi aplicate i relaiilor din urmtoarele motive: pentru a separa apariiile unei relaii ce sunt ntotdeauna accesate separat; pentru a uni dou (sau mai multe) relaii ntre aceleai entiti ntr-o singur relaie, atunci cnd apariiile lor sunt accesate ntotdeauna mpreun. Un exemplu de partiionare a unei relaii este prezentat n figura 12, n care se face distincie ntre juctorii prezeni ai unei echipe de fotbal i cei din trecut.

118

Figura 12. Exemplu de partiionare a unei relaii

Selecia identificatorilor primari

n cazul n care exist entiti ce dein mai muli identificatori apare necesitatea stabilirii acelor atribute ce formeaz identificatorul primar. Identificatorul primar va avea drept corespondent n modelul relaional o cheie primar. Criteriile de alegere a unui identificator primar sunt: Atributele ce pot deine valori NULL nu pot forma un identificator primar. Este indicat ca un identificator primar s conin un atribut sau ct mai puine atribute. Avantajele acestei alegeri ar fi: - indeci de dimensiune redus (un index este o structur auxiliar pentru acces rapid la date); - spaiu redus pentru crearea legturilor logice ntre relaii; - sunt facilitate operaiile de jonciune. Un identificator intern este de preferat unuia extern, care poate implica mai multe entiti i aceasta din cauz c identificatorii externi sunt translai n chei ce conin identificatorii tuturor entitilor implicate n identificatorul extern. Este de preferat un identificator ce este utilizat de majoritatea operaiilor pentru a accesa apariiile entitii. n acest fel operaiile vor fi executate eficient, fiind avantajate de indecii construii automat de sistemul de gestiune a bazei de date. Dac n aceast etap nu exist nici un identificator care s satisfac criteriile anterioare, se va introduce un atribut suplimentar n entitate, atribut ce va fi utilizat exclusiv pentru identificarea apariiilor entitii.

8.3 Translarea n modelul relaional

Translarea n modelul relaional este a doua etap a proiectrii logice. Plecnd de la o schem E-R se construiete schema relaional echivalent (echivalent din punct de vedere al capacitii de a reprezenta informaii echivalente). innd cont de faza de restructurare a schemei E-R, translarea va pleca de la o schem E-R simplificat, ce nu conine generalizri sau atribute multi-valoare i are numai identificatori primari.

119

Entiti i relaii N:N

Se consider schema din figura 13.

Figura 13. Schem E-R cu o relaie N:N Translarea n modelul relaional se face urmnd paii: Fiecare entitate va fi translat ntr-o relaie M-R(a modelului relaional) cu acelai nume i avnd aceleai atribute ca i entitatea; cheia fiecrei relaii este dat de identificatorul entitii corespunztoare. Fiecare relaie E-R dintre entiti va avea drept corespondent o relaie M-R cu acelai nume i cu atribute atributele relaiei E-R i identificatorii entitilor implicate; cheia relaiei M-R va conine identificatorii entitilor. Dac entitile sau relaiile E-R au atribute opionale, atributele corespunztoare din modelul relaional pot avea valoarea NULL. Se obine referitor la exemplul din figura 13:

ANGAJAT(Numar, Nume, Salariu) PROIECT( Cod, Nume, Buget) PARTICIPARE(Numar, Cod, DataStart)
n cazul n care se dorete mrirea claritii schemei obinute se pot opera redenumiri de atribute:

PARTICIPARE(Angajat, Proiect, DataStart)

Domeniul atributului Angajat este o mulime de numere de nregistrare pentru angajai, iar domeniul pentru atributul Proiect este o mulime de coduri de proiecte. De asemenea trebuie impuse constrngeri de referin ntre aceste atribute i relaiile ANGAJAT, respectiv PROIECT. Operaia de redenumire este esenial n cazul relaiilor recursive. S considerm schema din figura 14.

Figura 14. Schem E-R cu relaie recursiv Prin translare se obine: 120

PRODUS(Cod, Nume, Pret) COMPUNERE(Componenta, Subcomponenta, Cantitate)

Atributele Componenta i Subcomponenta au ca domeniu mulimea de coduri ale produselor. Trebuie impuse constrngeri de referin ntre Componenta i PRODUS i Subcomponent i PRODUS. Translarea relaiilor E-R ce implic mai mult de dou entiti este similar cazului relaiilor E-R ntre dou entiti (relaii binare). Ca exemplu este dat schema din figura 15. Schema este translat n:

FURNIZOR(IDFurnizor, NumeFurnizor) PRODUS(Cod, Tip) DEPARTAMENT(Nume, Telefon) LIVRARE(Furnizor, Produs, Departament, Cantitate)

Figura 15. Schem E-R cu o relaie ternar Se impun constrngeri de referin ntre atributele Furnizor, Produs i Departament ale relaiei M-R LIVRARE i relaiile M-R FURNIZOR, PRODUS i DEPARTAMENT. Pentru acest ultim tip de translare trebuie verificat dac identificatorii entitilor, luai mpreun, nu formeaz o cheie, sau mai degrab o super-cheie redundant pentru relaia M-R care reprezint relaia E-R din schem. Aceasta se poate ntmpla, spre exemplu, dac exist un singur furnizor care livreaz un produs dat unui departament dat. Este de notat faptul c rmne valid cardinalitatea deoarece acest furnizor poate livra mai multe produse acestui departament sau altor departamente. n acest caz, cheia relaiei M-R LIVRARE trebuie s fie format doar din atributele Produs i Departament, deoarece, fiind dat un produs i un departament, furnizorul este determinat n mod unic.

Relaii 1:N

Se consider schema din figura 16.

Figura 16. Schem E-R cu o relaie 1:N Utiliznd regula de translare a relaiilor N:N se obine: 121

JUCATOR(Nume, DataNastere, Pozitie) ECHIPA(Nume, Oras, CuloriEchipa) CONTRACT(NumeJucator, DataNastereJucator, Echipa, Salariu)
Cheia relaiei CONTRACT este format numai din identificatorul entitii JUCATOR deoarece cardinalitile indic faptul c fiecare juctor are contract la o singur echip. Se observ c relaiile JUCATOR i CONTRACT au aceeai cheie. Acest lucru indic posibilitatea combinrii celor dou relaii n una singur, fr s existe pericolul introducerii de redundane. Aceast combinare este posibil datorit corespondenei 1:1 ntre instanele celor dou relaii. Astfel, pentru schema din figura 16 se prefer translarea:

JUCATOR(Nume, DataNastere, Pozitie, Echipa, Salariu) ECHIPA(Nume, Oras, CuloriEchipa) Trebuie impus o constrngere de referin ntre atributul Echipa i relaia ECHIPA. S considerm cazul n care entitatea JUCATOR particip opional la relaia CONTRACT (pot exista juctori care nu au contract cu nici o echip). Ambele translri prezentate anterior sunt valide. Ce-a de-a doua prezint dezavantajul c pot exista valori NULL n relaia JUCATOR pentru atributele Echipa i Salariu.
Regul: entitatea ce particip la o relaie E-R cu cardinalitatea maxim 1 este translat ntr-o relaie M-R ce include identificatorii celorlalte entiti implicate n relaia E-R i posibilele atribute ale relaiei E-R. Astfel nu mai este nevoie de o relaie M-R separat pentru relaia din schema E-R.
Ca exemplu, s presupunem c entitatea PRODUS particip n relaia din figura 15 cu cardinalitile minim i maxim 1. Aceasta nseamn c pentru fiecare produs exist un singur furnizor care livreaz produsul respectiv i un singur departament deservit. Schema este translatat sub forma:

FURNIZOR(IDFurnizor, NumeFurnizor) DEPARTAMENT(Nume, Telefon) PRODUS(Cod, Tip, Furnizor, Departament, Cantitate)

Se impun constrngeri de referin ntre atributul Furnizor al relaie PRODUS i relaia FURNIZOR i ntre atributul Departament al relaiei PRODUS i relaia DEPARTAMENT.

Entiti cu identificatori externi

S considerm exemplul din figura 17.

Figura 17. Schem E-R cu identificator extern Schema relaional este:

STUDENT(NrInregistrare, Universitate, Nume, AnInregistrare) UNIVERSITATE(Nume, Oras, Adresa)

122

Exist o constrngere de referin ntre atributul Universitate i relaia UNIVERSITATE. Este de notat faptul c, prin reprezentarea identificatorului extern, a fost reprezentat i relaia dintre entiti. Acest tip de translare este valid indiferent de cardinalitatea cu care particip celelalte entiti la relaie.
Relaii 1:1

Pentru relaiile 1:1 exist mai multe posibiliti de translare. S considerm relaia din figura 18, cu participare obligatorie din partea celor dou entiti implicate.

Figura 18. Schem E-R cu o relaie 1:1 Exist dou posibiliti valide de translare:

SEF(Numar, Nume, Salariu, Departament, DataStart) DEPARTAMENT(Nume, Telefon, Filiala)

cu constrngere de referin ntre atributul Departament al relaiei SEF i relaia DEPARTAMENT, sau

SEF(Numar, Nume, Salariu) DEPARTAMENT(Nume, Telefon, Filiala, Sef, DataStart)

cu constrngere de referin ntre atributul Sef al relaiei DEPARTAMENT i relaia SEF. Pe lng aceste dou soluii, exist posibilitatea obinerii unei singure relaii, incluznd toate atributele din schema E-R. Motivul pentru care aceast soluie va fi eliminat este urmtorul: dac dup faza de restructurare (care precede faza de translare) schema E-R conine dou entiti legate printr-o relaie 1.1, este de dorit ca n faza de translare cele dou concepte s rmn separate. S considerm cazul unei relaii 1:1 cu participarea opional a uneia dintre entiti, ca n schema din figura 19.

Figura 19. Schema E-R cu o relaie 1:1 cu participare opional Soluia adoptat este:

ANGAJAT(Numar, Nume, Salariu)

123

DEPARTAMENT(Nume, Telefon, Filiala, Sef, DataStart)

cu constrngere de referin ntre atributul Sef al relaiei DEPARTAMENT i relaia ANGAJAT. Aceast opiune este preferabil uneia n care relaia E-R este reprezentat n relaia M-R ANGAJAT prin numele departamentului manageriat, deoarece, pentru acest atribut, ar putea exista valori NULL. S considerm cazul n care ambele entiti au participri opionale. S presupunem c n schema din figura 19 pot exista departamente fr ef (cardinalitatea minim a entitii DEPARTAMENT este 0). n acest caz se obine prin translare: ANGAJAT(Numar, Nume, Salariu) DEPARTAMENT(Nume, Telefon, Filiala) MANAGEMENT(Sef, Departament, DataStart) Se observ c se poate lua drept cheie a relaiei MANAGEMENT atributul Departament. Se impun constrngeri de referin ntre atributele Sef i Departament ale relaiei MANAGEMENT i relaiile ANGAJAT i DEPARTAMENT. Aceast soluie are avantajul c atributele ce implementeaz relaia din schema E-R nu pot avea valori NULL. Dezavantajul soluiei const n relaia nou introdus. Aceast soluie este recomandat n cazul n care numrul de apariii ale relaiei este mic n comparaie cu numrul de apariii ale entitilor implicate n relaie.

Exemplu de translare a unei scheme complexe cu obinerea unui numr minim de relaii

S considerm schema E-R din figura 20.

Figura 20. Schem entitate relaie ntr-o prim faz se transleaz fiecare entitate ntr-o relaie din modelul relaional. Translarea entitilor cu identificatori interni este imediat: 124

E3(A31, A32) E4(A41, A42) E5(A51, A52) E6(A61, A62, A63)

Al doilea pas const n translarea entitilor cu identificatori externi. Se obin urmtoarele relaii M-R:

E1(A11, A51, A12) E2(A21, A11, A51, A22)

Este de notat modul n care E2 preia atributul A11 din E1 i tranzitiv, atributul A51 din E5 care, mpreun, identific E1. Trebuie impuse constrngeri de referin adecvate (de exemplu ntre atributul A51 din E1 i relaia E5). n al treilea pas se transleaz relaiile din schema E-R. Relaiile R1 i R6 au fost deja translate datorit identificatorilor externi ai entitilor E1, respectiv E2. Presupunem c vrem s obinem un numr minim de relaii M-R n schema final. Astfel:

Pentru a transla R3, vom introduce, cu redenumiri adecvate, atributele care identific E6 printre cele ale lui E5, precum i atributul AR3 al lui R3. Astfel introducem A61R3, A62R3 i AR3 n E5. Similar, pentru R4, introducem A61R4 i A62R4 n E5. Similar, pentru R5, introducem A61R5, A62R5 i AR5 n E5.

Se obine

E5(A51, A52, A61R3, A62R3, AR3, A61R4, A62R4, A61R5, A62R5, AR5)
Cheia relaiei M-R E5 este format doar din A51 deoarece entitatea E5 particip cu cardinalitatea maxim 1 la relaiile E-R R3, R4 i R5. Redenumirea atributelor entitii E6 este obligatorie pentru a face distincia ntre utilizri ale acelorai atribute n reprezentarea unor relaii diferite (spre exemplu A61R3 care reprezint R3 i A61R4 care reprezint R4). n final se transleaz singura relaie N:N, i anume R2:

R2(A21, A11, A51, A31, A41, AR21, AR22)

Schema relaional care se obine n final este:

E1(A11, A51, A12) E2(A21, A11, A51, A22) E3(A31, A32) E4(A41, A42) E5(A51, A52, A61R3, A62R3, AR3, A61R4, A62R4, A61R5, A62R5, AR5) E6(A61, A62, A63) R2(A21, A11, A51, A31, A41, AR21, AR22)

Tabel rezumat pentru translarea din modelul entitate-relaie n modelul relaional

n figura 21 sunt prezentate, pe scurt, posibiliti de translare din modelul E-R n modelul relaional Simbolurile X i Y indic o cardinalitate permis. Asteriscul indic posibilitatea prezenei valorilor NULL iar linia de subliniere ntrerupt marcheaz o cheie alternativ celei marcate prin linie continu. 125

Tip
Relaie binar N:N

Schema iniial

Translare posibil

Relaie ternar N:N

Relaie 1:N cu participare obligatorie

Relaie 1:N cu participare opional

sau

Relaie cu identificatori externi Relaie 1:1 cu participare obligatorie pentru ambele entiti Relaie 1:1 cu participare opional pentru o entitate

sau

126

sau Relaie 1:1 cu participare opional pentru ambele entiti

sau Figura 21. Translri din modelul E-R n modelul relaional

Documentarea schemelor logice

Rezultatul proiectrii logice nu const doar n schema bazei de date ci presupune i o documentaie asociat. O parte a documentaiei obinute n faza proiectrii conceptuale poate fi motenit de schema logic. n particular, dac numele conceptelor din schema E-R sunt refolosite pentru construirea schemei relaionale, regulile de operare definite anterior pot fi folosite pentru documentarea acesteia din urm. Documentaia schemei relaionale trebuie completat cu constrngerile de referin. Pentru aceasta se adopt o notaie grafic simpl att pentru relaii ct i pentru constrngerile dintre acestea. Un exemplu referitor la schema din figura 13 este dat n figura 22. Cheile relaiilor se scriu ngroat, sgeile descriu constrngerile de referin iar asteriscul asociat indic posibilitatea ca atributul respectiv s aib valori NULL.

Figura 22. Reprezentarea grafic a translrii schemei din figura 13. n acest mod se pot pstra informaii despre relaiile din modelul E-R, permindu-se reconstrucia informaiilor reprezentate prin relaia original. n exemplul din figura 22, proiectele n care angajaii sunt implicai pot fi regsite prin intermediul relaiei PARTICIPARE. n figura 23 este prezentat un alt exemplu referitor la schema din figura 16.

Figura 23. Reprezentarea grafic a translrii schemei din figura 16. 127

Este de remarcat faptul c aceast metod permite de asemenea reprezentarea explicit a relaiilor din schema iniial E-R crora, n schema relaional echivalent, nu le corespunde nici o relaie (spre exemplu relaia CONTRACT din modelul E-R din figura 16). n figura 24 este reprezentat schema relaional corespunztoare exemplului anterior de translare a unei scheme complexe cu obinerea unui numr minim de relaii (figura 20). n acest mod se pot identifica uor legturile logice dintre diferitele relaii care apar.

Figura 24. Reprezentarea grafic a schemei relaionale corespunztoare schemei E-R din figura 20

8.4 Exemplu de proiectare logic S considerm exemplul din capitolul anterior (proiectarea conceptual) referitor la o companie de instruire. Schema conceptual este prezentat n figura 25.

Figura 25. Schema E-R pentru o companie de instruire 128

Operaiile care au loc asupra datelor descrise prin schema anterioar sunt: Operaia 1: se insereaz un nou instruit incluznd datele despre el; Operaia 2: se atribuie un instruit unei ediii a unui curs; Operaia 3: se insereaz un nou instructor, incluznd toate datele i cursurile pe care acesta este calificat s le predea; Operaia 4: se atribuie un instructor calificat pentru o ediie a unui curs; Operaia 5. se afieaz toate informaiile despre o ediie anterioar a cursului: titlu, orar, numr de instruii; Operaia 6: afieaz toate cursurile disponibile, cu informaii despre instructorii calificai s le in; Operaia 7: pentru fiecare instructor, se gsesc instruiii pentru toate cursurile pe care le ine sau le-a inut; Operaia 8: se realizeaz o analiz statistic a tuturor instruiilor cu toate informaiile despre ei, despre ediiile cursurilor pe care le-au urmat i notele obinute.

Faza de restructurare

ncrcarea bazei de date este prezentat n figura 26.

Tabelul volumelor
Concept Clas EdiieCurs Curs Instructor Temporar Permanent Instruit Angajat LiberProfesionist Angajator PrezenAnterioar PrezenCurent Compoziie Tip PredareAnterioar PredareCurent Calificare AngajareActual AngajareAnterioar Tip E E E E E E E E E E R R R R R R R R R Volum 8000 1000 200 300 250 50 5000 4000 1000 8000 10000 500 8000 1000 900 100 500 4000 10000

Tabelul operaiilor
Operaie Op 1 Op 2 Op 3 Op 4 Op 5 Op 6 Op 7 Op 8 Tip I I I I I I I B Frecven 40/zi 50/zi 2/zi 15/zi 10/zi 20/zi 5/zi 10/lun

Figura 26. Tabelele volumelor i operaiilor pentru schema din figura 25

Analiza redundanelor. n schem exist doar o dat redundant i anume atributul NrParticipani n EDIIECURS, care poate fi derivat din relaiile PREZENCURENT i PREZENANTERIOAR. Cererea de stocare este de 4 x 1000 = 4000 octei, presupunnd c sunt necesari patru octei pentru ca fiecare apariie a entitii EDIIECURS s stocheze numrul de participani. Operaiile care implic aceast informaie sunt 2, 5 i 8. Ultima operaie poate fi lsat deoparte deoarece este o operaie cu o frecven mic, care se execut n modul batch. Vom evalua costul operaiilor 2 i 5 n prezena i n absena redundanei. Se poate deduce din tabelul volumelor c fiecare ediie a unui curs are, n medie, 8 clase i 10 participani. Pornind de la aceste date se poate obine uor tabelul accesrilor prezentat n figura 27.
129

Accesri n prezena redundanei Operaia 2 Concept Tip Accesri Tip Instruit E 1 R PrezenCurent R 1 W EdiieCurs E 1 R EdiieCurs E 1 W
Operaia 5 Tip Accesri E 1 R 1 E 1 R 8 E 8

Accesri n absena redundanei Operaia 2 Concept Tip Accesri Tip Instruit E 1 R PrezenCurent R 1 W

Concept EdiieCurs Tip Curs Compoziie Clas

Tip R R R R R

Operaia 5 Concept Tip Accesri EdiieCurs E 1 Tip R 1 Curs E 1 Compoziie R 8 Clas E 8 PrezenAnterioar R 10

Tip R R R R R R

Figura 27. Tabelele accesrilor pentru schema din figura 25 Se obine: n prezena redundanei: pentru operaia 2 avem 2 x 50 = 100 accesri n citire / zi i tot attea accesri n scriere / zi, n timp ce, pentru operaia 5, avem 19 x 10 = 190 accesri n citire / zi dintr-un total de 490 accesri / zi (s-a considerat c accesul n scriere cost de dou ori mai mult dect accesul n citire); n absena redundanei: pentru operaia 2 avem 50 de accesri n citire / zi i tot attea n scriere, n timp ce pentru operaia 5 avem 29 x 10 = 290 accesri n citire / zi, dintrun total de 440 accesri / zi (s-a considerat c accesul n scriere cost de dou ori mai mult dect accesul n citire). Se observ c n prezena redundanei, apar dezavantaje att n ceea ce privete cererea de stocare ct i timpul de acces. Din acest motiv se va renuna la atributul NrParticipani al entitii EDIIECURS.

Eliminarea generalizrilor. n schem exist dou generalizri: una referitoare la instructori i una referitoare la instruii. n ceea ce privete instructorii, s remarcm c operaiile relevante (3,4,6 i 7) nu fac distincia ntre instructorii temporari i cei angajai permanent de companie. Mai mult, entitile corespunztoare nu au atribute specifice acestora. Din aceste motive, vom terge entitile copil ale generalizrii i vom aduga atributul Tip entitii INSTRUCTOR. Acest atribut are domeniul format din simbolurile T (pentru temporar) i P (pentru permanent). n ceea ce privete instruiii, s observm c i n acest caz, operaiile relevante (1, 2 i 8) nu fac o diferena major ntre diversele tipuri de apariii. Entitile copil au ambele atribute specifice. Se pot lsa entitile ANGAJAT i LIBERPROFESIONIST adugnd dou relaii 1:1 ntre aceste entiti i entitatea INSTRUIT. n acest fel se evit atribute cu posibile valori NULL pentru entitatea printe i se poate reduce dimensiunea relaiilor. Rezultatul eliminrii generalizrilor se poate vedea n figura 28. Partiionarea / combinarea conceptelor. Din analiza datelor i operaiilor se pot identifica mai multe restructurri poteniale. Prima se refer la entitatea EDIIECURS. Operaia 5 i relaiile PREDAREANTERIOAR i PREZENANTERIOAR se refer doar la ediiile anterioare ale cursului. Astfel, pentru a face operaia anterioar mai eficient, se poate descompune entitatea orizontal pentru a distinge ntre ediiile curente i cele anterioare ale cursului.
130

Dezavantajul acestei alegeri este acela c relaiile COMPOZIIE i TIP se vor duplica. Pe de alt parte, operaiile 7 i 8 nu fac o distincie major ntre ediiile curente i anterioare ale unui curs i ar putea fi mai costisitoare dac necesit vizitarea a dou entiti distincte. Din aceste motive, nu vom partiiona entitatea EDIIECURS. Dou restructurri posibile ar putea avea loc prin combinarea relaiilor PREDAREANTERIOAR I PREDARECURENT i respectiv a relaiilor PREZENANTERIOAR I PREZENCURENT. n ambele cazuri avem de-a face cu dou concepte similare ntre care cteva operaii (7 i 8) nu fac diferena. Combinarea acestor relaii mai poate duce la un avantaj i anume c nu mai este necesar transferul apariiilor de la o relaie la alta la sfritul unei ediii a unui curs. Un dezavantaj ar fi acela c atributul Not, care nu apare la o ediie curent a cursului va avea valori NULL. Din tabelul de volume se observ c numrul de apariii ale relaiei PREZENCURENT este de 500. Presupunnd c avem nevoie de 4 octei pentru a stoca notele, cererea de stocare va fi de doar aproximativ 2 Koctei. Decidem deci s combinm cele dou perechi de relaii dup cum se poate vedea n figura 28. Trebuie adugat o constrngere care nu poate fi reprezentat direct pe schem i anume aceea ca un instructor s nu poat preda mai mult de o ediie a unui curs n aceeai perioad. Similar, un participant nu poate fi prezent la mai mult de o ediie a unui curs la un anumit moment. n final, este necesar eliminarea atributului multi-valoare Telefon din entitatea INSTRUCTOR. Pentru aceasta se introduce o nou entitate TELEFON legat printr-o relaie 1:N de entitatea INSTRUCTOR (din care se elimin atributul respectiv). Selecia identificatorilor primari. Doar entitatea INSTRUIT are doi identificatori: CNP-ul i codul intern. Este preferabil s se aleag al doilea identificator deoarece CNP-ul poate necesita civa octei pentru stocare n timp ce codul, care trebuie s disting ntre 5000 de apariii (vezi tabelul volumelor) nu necesit mai mult de doi octei. Entitatea EDIIECURS este identificat prin atributul DatStart i prin entitatea CURS. ntr-o reprezentare relaional, acest identificator trebuie utilizat pentru a implementa dou relaii (PREZEN i PREDARE). Se poate observa c fiecare curs are un cod i c numrul mediu de ediii pentru un curs este 5. Aceasta nseamn c este convenabil s adugm un atribut Cod cu domeniul small integer pentru a identifica o ediie a unui curs, n locul identificatorului extern. Schema rezultat n urma restructurrii poate fi observat n figura 28.

Figura 28. Schema E-R din figura 25 dup faza de restructurare 131

Translarea n modelul relaional

Folosind tehnicile de translare prezentate anterior, schema din figura 28 poate fi translat n urmtoarea schem relaional: EDIIECURS(Cod, DatStart, DatSfrit, Curs, Instructor) CLAS(Timp, Sal, Dat, Ediie) INSTRUCTOR(CNP, Nume, Vrst, OraDeNatere, Tip) TELEFON(Numr, Instructor) CURS(Cod, Nume) CALIFICARE(Curs, Instructor) INSTRUIT(Cod, CNP, Nume, Vrst, OraDeNatere, Sex) PREZEN(Instruit, Ediie, Note*) ANGAJATOR(Nume, Adres, Telefon) ANGAJAREANTERIOAR(Instruit, Angajator, DatStart, DatSfrit) LIBERPROFESIONIST(Instruit, Expertiz, TitluProfesional*) ANGAJAT(Instruit, Nivel, Poziie, Angajator, DatStart) Schema logic va fi completat cu o documentaie care va descrie, printre altele, toate constrngerile de referin care exist ntre relaii. Aceasta se poate face utiliznd notaiile grafice prezentate anterior.

132

Bibliografie 1. Database Systems - concepts, languages & architectures, P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone, Ed. McGraw - Hill, 2000 2. Database Systems - the complete book, H. Garcia-Molina, J.D. Ullman, J. Widom, Ed. Prentice Hall, 2002 3. Baze de date - proiectare, implementare, gestionare, T. Connolly, C. Begg, A. Strachan, Ed. Teora, 2001 4. Baze de date , O. Bsc, Ed. All, 1997 5. PL/SQL , T. Luers, T. Atwood, J. Gennick, Ed. Teora, 2001 6. Sisteme de gestiune a bazelor de date aplicaii Oracle, I. Lungu, M. Velicanu, C. Bodea, C. Ioni, Ed. All, 1998