Baze de Date On Line

PREFA
Istoria bazelor de date relaionale ncepe n 1970 o dat cu publicarea articolului lui Edgar Frank Codd A Relational Model of Data for Large Shared Data Banks care descrie modelarea datelor sub form de relaii (termen matematic, reprezentarea intuitiv a unei relaii fiind o tabel) i operaiile de baz cu acestea. A durat aproape 10 ani pn la apariia primelor sisteme de gestiune a bazelor de date (SGBD) bazate pe acest model, timp n care s-au dezvoltat algoritmi i metode de a realiza n timp util operaiile cu tabele. O serie de firme prestigioase au investit n cercetri privind modelul relaional al datelor, printre acestea numrndu-se i IBM care a lansat n anii 70 dezvoltarea unui prototip de cercetare numit System R. n cadrul acestui sistem care nu a fost niciodat comercializat ca atare, fiind folosit doar ca instrument de cercetare a fost dezvoltat i un limbaj de cereri prin care utilizatorul interaciona cu datele din baza de date numit SEQUEL (de la Structured English-like Query Language) redenumit apoi din motive comerciale SQL. System R a fost tatl sistemului DB2 pe care IBM l comercializeaz i n momentul actual. Lucrarea de fa i propune s prezinte att fundamentele teoretice ale modelului relaional (capitolele 1-4 i 6) ct i limbajul de cereri SQL care a devenit n timp limbajul standard de comunicare cu un sistem de gestiune (capitolul 5). n exemplele din capitolul dedicat SQL s-au folosit urmtoarele convenii care s asigure o mai mare claritate i lizibilitate: S-a preferat scrierea cu litere mari a cuvintelor cheie i identificatorilor. Fiecare nou clauz a unei cereri a fost scris ncepnd cu o nou linie. S-a folosit indentarea n cazul expresiilor lungi i a subcererilor.
2011
Autorii
BAZE DE DATE ON-LINE
CUPRINS
1. Concepte i problematic ..................................................................9 1.1. Baz de date i Sistem de gestiune a bazelor de date ...............9 1.2. Funciile unui SGBD ...............................................................11 1.3. Categorii de utilizatori .............................................................13 1.4. Nivele de descriere a unei baze de date ..................................13 2. Modelarea datelor ...........................................................................15 2.1. Etapele dezvoltarii unei aplicatii ............................................15 2.2. Modelul entitate-asociere clasic .............................................18 2.3. Modelul entitate-asociere utilizat n instrumente CASE ........25 3. Modelul relaional ...........................................................................27 3.1. Modele de date: ierarhic, reea, relaional ..............................27 3.2. Elementele de baza ale modelului relational ..........................28 3.3. Transformarea diagramelor EA in modelul relational ............30 3.4. Algebra relaional ..................................................................31 3.5. Calcul relational ......................................................................36 4. Proiectarea bazelor de date .............................................................37 4.1. Anomalii care apar n cazul proiectrii incorecte ...................37 4.2. Dependene funcionale ..........................................................38 4.3. Forme normale ........................................................................45 4.4. Descompunerea schemelor de relaie .....................................47 4.5. Dependene multivalorice. Forma normal 4 .........................52 5. Limbajul SQL .................................................................................55 5.1. Interogarea datelor ..................................................................56 5.2. Cereri simple ...........................................................................57 5.3. Cereri cu clauza WHERE .......................................................58 5.4. Metode de join ........................................................................61 5.5. Equi-join si non equi-join .......................................................62 5.6. Joinul unei tabele cu ea insi .................................................63 5.7. Join extern ...............................................................................63 5.8. Join vertical .............................................................................64 5.9. Funcii n SQL .........................................................................65
5.10. 5.11. 5.12. 5.13. 5.14. 5.15. 5.16.
Subcereri SQL ........................................................................74 Crearea i definirea structurilor tabelare ................................77 Constrngeri de integritate .....................................................80 Comanda ALTER TABLE ....................................................83 Comanda INSERT .................................................................85 Comanda DELETE ................................................................86 Comanda UPDATE ...............................................................86
6. Tranzacii i acces concurent ..........................................................88 6.1. Prezentarea problematicii. Terminologie ................................88 6.2. Gestiunea tranzaciilor ............................................................89 6.3. Serializabilitate .......................................................................91 6.4. Asigurarea consistentei la citire ..............................................93 6.5. Protocolul de blocare in doua faze .........................................94
Concepte i problematic
1. CONCEPTE I PROBLEMATIC
n acest moment termenul de baz de date a intrat n limbajul curent fiind folosit uneori i n alte accepiuni dect cea de provenien. n acest capitol sunt definite conceptele de baz de date (BD) i sistem de gestiune a bazelor de date (SGBD) i se face o trecere n revist a elementelor coninute n aceste definiii. Sunt prezentate apoi funciile pe care trebuie s le asigure un SGBD i categoriile de utilizatori ale unui astfel de sistem. Capitolul se incheie cu prezentarea celor trei nivele de descriere ale unei baze de date i a conceptului de independen dateprogram.
1.1. Baz de date i Sistem de gestiune a bazelor de date

Literatura de specialitate conine mai multe definiii pentru conceptele de baz de date i sistem de gestiune a bazelor de date. n continuare sunt prezentate dou definiii apreciate pentru valoarea lor descriptiv. Definiie: O baz de date este un ansamblu structurat de date nregistrat pe suporturi accesibile calculatorului pentru a satisface simultan cerinele mai multor utilizatori ntr-un mod selectiv i n timp util. Definiie: Un sistem de gestiune a bazelor de date este ansamblul de programe care permit utilizatorului s interacioneze cu o baz de date. Aceste definiii conin majoritatea elementelor importante ale problematicii bazelor de date prezentate n capitolele urmatoare:
un ansamblu structurat de date

Nu orice colecie de date este o baz de date. O cerin primordial este aceea a organizrii acestora dup anumite reguli. Regulile i conceptele care permit descrierea structurii unei BD formeaz modelul datelor. n acest moment majoritatea sistemelor de gestiune sunt bazate pe modelul relaional al datelor n care, intuitiv, datele sunt organizate sub form de tabele. Popularitatea acestui model este datorat simplitii sale (din punct de vedere al utilizatorului) i a posibilitii de definire a unor limbaje neprocedurale de descriere i manipulare a datelor. Termenul de relaie (care d denumirea modelului) provine din matematic iar reprezentarea intuitiv a unei relaii este o tabel. n cazul modelului relaional
11
descrierea structurii unei baze de date const n principal din descrierea tabelelor componente: denumire, list de coloane i tipul datelor din acestea.
...nregistrat pe suporturi accesibile calculatorului ...

Dac ansamblul de date nu este nregistrat pe suporturi accesibile calculatorului acesta nu se poate numi baz de date n accepiunea lucrrii de fa. n limbajul curent se ntalnesc expresii ca: "avem aceast informaie n baza noastr de date" i n cazurile n care datele respective sunt de exemplu stocate sub forma unor fie (pe hrtie) sortate alfabetic sau dup alte criterii. n acest caz este vorba despre o extensie a termenului de baz de date. n cazul sistemelor de gestiune a bazelor de date suporturile pe care sunt stocate datele sunt n principal magnetice i optice.
... pentru a satisface simultan cerinele mai multor utilizatori

Funciile unui SGBD relative la accesul utilizatorilor la baza de date sunt urmatoarele: 1. Gestiunea utilizatorilor. Un SGBD trebuie s permit crearea, modificarea i stergerea utilizatorilor. Operaia este efectuat de obicei de administratorul bazei de date. 2. Concurena la date. n cazul accesului simultan al mai multor utilizatori la aceleai date un SGBD trebuie s aiba mecanisme pentru a prentmpina inconsistena datelor. Capitolul 6 prezinta problemele legate de blocarea (acapararea) unor poriuni ale BD de catre o execuie a unui program, rezolvarea problemelor pe care le poate ridica ateptarea circular pentru deblocarea acestor poriuni (deadlock), execuia pailor programelor de actualizare echivalent cu o execuie secvenial a programelor (serializabilitate) i reguli de scriere a programelor de aplicaie pentru rezolvarea problemelor de acces concurent.
... ntr-un mod selectiv ...

Orice SGBD are mecanisme prin care diverilor utilizatori sau categorii de utilizatori li se asociaz drepturi de acces specifice la obiectele bazei de date. n acest mod fiecrui utilizator i se d dreptul de a efectua doar operaiile specifice activitii sale i doar pe acea portiune a bazei de date care este necesar pentru acestea. Mecanismul de drepturi de acces are ca obiective principale: Blocarea accesului unor categorii de utilizatori la date pe care nu trebuie s le acceseze. n acest fel este asigurata una dintre funciunile de baza ale unui SGBD i anume confidenialitatea datelor. Blocarea accesului unor categorii de utilizatori la date de care nu au nevoie n activitatea lor, minimizndu-se astfel riscul distrugerii accidentale a datelor prin operaii necorespunzatoare.
12
... i n timp util ...

n cazul bazelor de date de dimensiuni mari este evident ca orice cautare care s-ar baza pe o parcurgere secvenial a nregistrarilor din tabele ar duce la timpi de rspuns inadecvat de mari. De asemenea, operaii mai complicate prin care se regsesc date stocate n mai multe tabele legate ntre ele prin coloane comune pot duce n lipsa unor algoritmi specifici la timpi de execuie inacceptabili. De aceea orice SGBD are mecanisme prin care minimizeaz timpul de rspuns, mecanisme bazate n special pe indeci i modaliti specifice de organizare fizic a datelor.
1.2. Funciile unui SGBD

O definiie alternativ a conceptului de baz de date este urmtoarea: o baz de date este o colecie de date interconectate. Deci ea reprezint depozitul de date al oricrei aplicaii de gestiune, partea sa static. Operaiile asupra datelor sunt efectuate de sistemul de gestiune a bazelor de date. El este cel care asigur structurarea datelor, accesul concurent al utilizatorilor, selectivitatea accesului i timpi de execuie normali pentru cereri. Dar acestea sunt doar o parte din operaiile pe care acesta trebuie s le asigure. Funciile unui sistem de gestiune a bazelor de date sunt urmatoarele:
Descrierea datelor
Un SGBD trebuie s includ posibilitatea descrierii stucturii obiectelor care formeaz baza de date. n cazul bazelor de date relaionale aceasta const n principal n posibilitatea crerii i modificrii structurii tabelelor i constrngerilor de integritate asociate acestora. Limbajul prin care se realizeaz aceste operaii se numeste Limbaj de Descriere a Datelor (LDD) i n cazul primelor sisteme de gestiune el era implementat sub forma unor module separate. n sistemele relaionale bazate pe SQL aceste operaii au fost incluse n limbaj sub forma comenzilor de tip CREATE (pentru creare) sau ALTER (modificare).
Utilizarea datelor
Aceast funcie include operaiile de lucru cu datele nregistrate ntr-o baz de date. Cele patru categorii de operaii principale sunt urmtoarele:
Inserarea de noi date. Aceasta se concretizeaz prin adugarea de noi linii n tabelele care formeaz baza de date. tergerea de linii din tabele. Actualizarea datelor, nsemnnd modificarea coninutului unor linii existente n tabele. Regsirea datelor dup anumite criterii de cutare
13
Pentru implementarea acestei funcii fiecare SGBD are un Limbaj de Manipulare a Datelor (LMD) care poate fi un modul separat sau inclus n limbajul sistemului cum este n cazul SQL.
Integritatea datelor
Majoritatea sistemelor de gestiune permit definirea unor reguli pe care datele stocate trebuie s verifice numite constrngeri de integritate. n cazul n care o operaie are ca rezultat violarea acestor restricii aceasta este automat rejectat i nu are efect n baza de date. n felul acesta este asigurat o mai mare siguran n ceea ce privete corectitudinea datelor. Definirea de constrngeri de integritate nu previne ns total erorile accidentale de operare: de exemplu introducerea din greeal a unei note de 4 n loc de 5 nu va fi semnalat, ambele valori fiind n intervalul admisibil.
Confidenialitatea datelor
n cazul unui SGBD accesul la date este permis doar utilizatorilor nregistrai i doar n msura drepturilor de acces alocate. Un utilizator este identificat uzual printr-un nume-utilizator i o parol. Fiecrui utilizator i se permite accesul doar la o poriune a bazei de date i doar pentru a efectua anumite tipuri de operaii. n cazul bazelor de date accesate n reea se pot defini de asemenea locaiile de la care utilizatorul poate interaciona cu baza de date. O alt posibilitate de asigurare a confidenialitii este aceea a accesului la datele din baza de date doar prin intermediul unor programe de aplicaie. Utilizatorii acestor programe nu sunt n acelasi timp i utilizatori nregistrai ai SGBD-ului care gestioneaz datele iar poriunea din baza de date la care au acces este cablat n program.
Accesul concurent la date

Exist trei tipuri de probleme pe care un SGBD trebuie s le rezolve pentru a asigura accesul concurent corect al mai multor utilizatori la aceeai baz de date: 1. Faciliti de blocare a unor poriuni ale bazei de date. Aceasta nseamn c o execuie a unui program poate cpta un acces exclusiv la o poriune a bazei de date. 2. Modaliti de evitare sau de eliminare a interblocarii. 3. Execuia serializabil. n cazul mai multor execuii simultane care acceseaz baza de date se consider c efectul lor este corect dac rezultatul final este identic cu execuia lor succesiv.
Sigurana n funcionare
Desi nu este legat direct de cele prezentate pn acum, sigurana n funcionare este o caracteristica esenial pentru un SGBD i conine acele
14
elemente care exclud sau minimizeaz posibilitatea de pierdere a datelor datorat incidentelor software sau hardware. Prncipalele faciliti pe care un sistem de gestiune a bazelor de date trebuie s le asigure din acest punct de vedere sunt urmtoarele: Salvarea datelor. n cazul sistemelor mai vechi aceste faciliti erau suplinite de opiunile de copiere sau arhivare a fiierelor bazei de date oferite de sistemul de operare pe care rula SGBD-ul. Actualmente implementarea operaiilor de salvare este mult mai sofisticat avnd n vedere dificultatea teoretic i practic a efecturii de copii de siguran consistente ale bazei de date n condiiile n care aplicaia ruleaz non-stop i operarea nu poate fi oprit pentru efectuarea salvrii. Restaurarea dup incident. n cazul apariiei de incidente hardware sau software care au ca efect distrugerea bazei de date este necesar efectuarea operaiei de restaurare care s minimizeze volumul de operaii al caror efect se pierde.
1.3. Categorii de utilizatori

n paragrafele precedente a fost folosit frecvent termenul de utilizator. n cele ce urmeaz sunt prezentate categoriile de utilizatori care interacioneaz cu o baz de date. Din punct de vedere al drepturilor de acces, ca i n cazul sistemelor de operare, un SGBD are dou tipuri principale de utilizatori:
Utilizatori privilegiai
Acetia sunt utilizatori care au dreptul de a afectua toate tipurile de operaii puse la dispoziie de sistem. Termenul generic pentru acest tip de utilizatori este cel de administratori ai bazei de date i n general este vorba de una sau mai multe persoane care rspund de buna funcionare a SGBD-ului.
Utilizatori neprivilegiai
Acetia sunt utilizatorii obinuiti ai SGBD-ului i dispun de drepturile de acces care le-au fost alocate de administratorul bazei de date. Majoritatea sistemelor de gestiune permit definirea de categorii generice de utilizatori (numite roluri) iar fiecare utilizator individual are asociat unul sau mai multe roluri, motenind drepturile de acces ale acestora. Este uurat astfel operaia de creare a unui nou utilizator.
1.4. Nivele de descriere pentru o baz de date

O aceeasi baz de date poate fi privit din diverse perspective rezultnd descrieri diferite. Termenul consacrat pentru descrierea structurii unei baze de date
15
este acela de schema. n literatura de specialitate exist o clasificare pe trei nivele a acestor descrieri: fizic, conceptual i extern.
Nivelul fizic
Schema fizic este descrierea bazei de date din perspectiva stocrii sale pe dispozitivele fizice: identificarea discurilor i a cilor unde este stocat, numele fiierelor care formeaz baza de date, structura fizic a acestora, etc.
Nivelul conceptual
Descrierea bazei de date la acest nivel poart numele de schema conceptual (numita uneori i schema logic) a bazei de date. Ea const ntr-o descriere abstract dar exact a structurii acesteia, lasnd la o parte detaliile fizice de implementare.
Nivelul extern
Diferitele categorii de utilizatori ai unei baze de date au nevoie n activitatea lor doar de poriuni specifice ale acesteia. Descrierea acestor poriuni poart numele de scheme externe. O baz de date are deci asociate o singur schem fizic i o singur schem conceptual dar mai multe scheme externe.
Independena datelor
Existena celor trei nivele de descriere permite definirea conceptului de independen ntre datele stocate n baza de date i aplicaiile care utilizeaz aceste date. Conceptul de independen a datelor a aprut o dat cu dezvoltarea sistemelor complexe de aplicaii pentru care cablarea informaiilor structurale n program constituie o bariera n calea dezvoltrii i modificrii acestora. n lumea reala orice operaie de modificare a bazei de date a unei aplicaii se msoar i prin prisma costurilor materiale necesare modificrii programelor care o folosesc. Exist dou tipuri de independen: Independena logic reprezint posibilitatea de schimbare a schemei conceptuale a bazei de date fr modificarea schemelor externe. Condiia este ca modificarea s nu elimine nici unul dintre elementele necesare translaiei de la schema extern la schema conceptual.
Independena fizic reprezint posibilitatea de schimbare a schemei fizice a bazei de date fr modificarea schemei conceptuale i implicit a schemelor externe. Aceasta d posibilitatea reorganizrii fizice a bazei de date fr afectarea aplicaiilor care o folosesc.
2. MODELAREA DATELOR
Proiectarea corect a structurii unei baze de date relaionale este o premis fundamental n scrierea programelor de aplicaie i n funcionarea lor fr anomaliile care pot apare n cazul unei structuri defectuoase. Acest capitol prezint un model de date folosit n proiectarea conceptual de nivel nalt numit modelul entitate asociere (EA) n varianta clasic (cu unele extensii). n capitolul urmtor vor fi prezentate regulile de transformare din modelul entitate-asociere n modelul relaional.
2.1. Etapele dezvoltrii unei aplicaii

Proiectarea structurii bazelor de date relaionale este un domeniu n care cercetrile au evoluat spre elaborarea unor metodologii teoretice i a unor instrumente software care asigur un grad ridicat de normalizare a schemelor de relaie, pstrarea integritii, evitarea anomaliilor datorate unei proiectri nesistematice i eliminarea subiectivismului proiectantului prin nlocuirea lui cu exactitatea metodei. Pan la apariia unor astfel de metodologii se pornea de la o colecie de tabele i de la dependenele funcionale i multivalorice asociate i se ajungea, prin aplicarea unor algoritmi sau metode de normalizare la schema dorit a bazei de date. Aceast abordare de tip bottom-up creeaz ns dificulti n cazul bazelor de date complexe n care numrul de tabele i de dependene este mare. Probabilitatea ca unele interdependene ntre date s nu fie sesizate n procesul de proiectare este n aceste cazuri ridicat rezultnd n exploatare anomalii care duc la reluri ale ciclului analiza cerinelor schema bazei de date programe de aplicaie. Cercetrile n domeniul proiectrii schemei conceptuale s-au concentrat pe gsirea unor metodologii top-down pentru obinerea unei structuri optime a BD. Ele au fost influenate de rezultatele obinute n domenii care folosesc bazele de date: inteligena artificial, proiectarea asistat de calculator, abordarea orientat pe obiecte. Impactul conceptelor de abstractizare i generalizare precum i elaborarea unui model de descriere informal a datelor, i anume modelul entitate-asociere (EA), au dus la gsirea unor ci algoritmizabile de proiectare optim a bazelor de date. Modelul entitate-asociere este n acest moment cel mai popular model de comunicare a structurii bazelor de date datorit intuitivitii i simplitii elementelor sale. mbuntirile sale ulterioare prin folosirea abstractizrilor i generalizrilor au dus la crearea de variante ale modelului, dou dintre acestea fiind descrise n acest capitol. Extensiile modelului EA au aprut i pentru alte necesiti:
Modelarea datelor
17
modelarea cerinelor de secretizare a datelor, documentarea programelor de aplicaie i uurarea comunicrii ntre proiectantul de sistem i utilizatorul obinuit, proiectarea bazelor de date complexe pe poriuni i integrarea ulterioar a acestora (aa numita integrare a vederilor). Avantajul principal al modelului EA este acela al simplitii sale i al caracterului su intuitiv. Rezultatul proiectrii const ntr-o diagram entitateasociere care poate fi apoi translatat n modelul de date folosit de sistemul de gestiune a bazelor de date ales pentru dezvoltarea aplicaiei.
Analiza de sistem
n aceast etap se realizeaz analiza segmentului din lumea real care va fi gestionat de aplicaia respectiv. Rezult o specificaie neformalizat a cerinelor constnd din dou componente:
1. Cerine privind coninutul bazei de date: categoriile de date care vor fi

stocate i interdependenele dintre acestea.
2. Cerine privind prelucrrile efectuate de aplicaie: prelucrrile efectuate

asupra datelor, arborele de meniuri al aplicaiei, machetele formatelor de introducere i prezentare a datelor i ale rapoartelor tiprite de aceasta. n general aceast etap nu poate fi asistat prin programe de tip CASE dar exist reguli care ajut proiectantul n realizarea sa. Activitile desfurate includ: Analiza activitii desfurate la momentul respectiv de beneficiarul aplicaiei sau de o mulime reprezentativ de beneficiari n cazul aplicaiilor de uz general. Analiza coninutului de date i a funcionalitii aplicaiilor software - dac exist - care vor fi nlocuite de noua aplicaie incluznd meniuri, machete ecran i machete de rapoarte. Analiza formularelor tipizate i a altor documente utilizate de beneficiar pentru realizarea activitii respective. Identificarea tuturor interdependenelor dintre datele care vor fi stocate n baza de date i a restriciilor privind valorile pe care le pot lua anumite categorii de date. Identificarea - dac este cazul - a prelucrrilor care se declaneaz automat att n cazul modificrii bazei de date cat i la momente prestabilite de timp (de exemplu sfrit de lun, de an, etc.) Identificarea operaiilor care sunt necesare beneficiarului n activitatea curent dar care n acest moment nu sunt realizate prin intermediul aplicaiilor software folosite precum i a operaiilor care pot fi incluse n mod natural n noua aplicaie.
18
Identificarea bazelor de date existente care pot fi folosite de noua aplicaie direct sau printr-un import iniial de date - evitndu-se n acest fel reintroducerea manual a acestora. Identificarea modalitilor de transfer de date ntre noua aplicaie i alte aplicaii care ruleaz deja la beneficiar i care vor fi folosite i n viitor de ctre acesta. Identificarea necesitilor privind datele i prelucrrile care pot fi n viitor necesare beneficiarului, deci a posibilelor dezvoltri n timp ale aplicaiei.
Aceast etap este efectuat de personal calificat avnd n vedere c rezultatele sale sunt baza de la care se pleac n etapele urmtoare, eventualele erori putnd fi corectate ulterior cu costuri semnificative.
Proiectarea conceptual a bazei de date

n aceast etap, pornind de la rezultatele analizei de sistem, se realizeaz modelarea cerinelor privind datele folosind un model de nivel nalt. Cel mai popular model folosit este modelul entitate-asociere (EA). Actualmente exist pe pia numeroase instrumente CASE care folosesc diverse variante ale modelului. Motivele pentru care a fost ales sunt urmtoarele: Nu este legat direct de nici unul dintre modelele folosite de sistemele de gestiune a bazelor de date (relaional sau orientat obiect) dar exist algoritmi bine pui la punct de transformare din model EA n celelalte modele de date. Este intuitiv, rezultatul modelrii fiind o diagram care definete att datele stocate n baza de date ct i interdependenele dintre acestea. Poate fi uor de neles de nespecialiti. Aceast caracteristic este foarte important n momentul n care se face punerea de acord cu beneficiarul asupra structurii bazei de date a aplicaiei, evitndu-se n acest fel o proiectare neconform cu realitatea sau cu cerinele exprimate de acesta. Proiectarea se poate face pe poriuni, diagramele pariale rezultate putnd fi apoi integrate pe baza unor algoritmi i metode bine puse la punct.
Transformare n model relaional

n aceast etap entitile i asocierile care formeaz diagrama EA se transform pe baza unor reguli clare n structura relaional a bazei de date. Rezult schema preliminar a acesteia format din tabele (relaii n terminologia relaional), coloanele acestora (atribute ale relaiilor) i constrngerile de integritate care pot fi deduse automat din diagrama incluznd unele interdependene ntre date numite i dependene funcionale. n capitolul 3 este descris o metod de transformare din modelul EA clasic n modelul relaional. n cazul variantei specifice uneltelor CASE transformarea se face automat de ctre acestea.
Modelarea datelor
19
Normalizare
Exist o serie de reguli care descriu ce nseamn o structur corect a unei tabele i care definesc aa numitele forme normale. Pe baza structurii bazei de date i a dependenelor rezultate att din transformarea n model relaional ct i a altor dependene identificate de proiectant n analiza de sistem se poate face o operaie numit normalizare modificnd structura bazei de date astfel nct toate tabelele din aceasta s fie n forma normal dorit. Capitolul 3 conine definiia formelor normale uzuale i descrierea unor algoritmi de normalizare care sunt folosii de uneltele CASE pentru efectuarea automat a operaiei.
Implementarea specific sistemului de gestiune folosit

n aceast etap se realizeaz crearea structurii bazei de date obinut n etapa precedent pe baza facilitilor oferite de sistemul de gestiune a bazelor de date ales. Rezultatul ei este programul de creare scris n limbajul de definiie a datelor acceptat de SGBD-ul utilizat. Iat un exemplu: Schema conceptual: Student(CodStud:Numeric, Nume:ir, DataN:Dat) Program de creare (SQL-Oracle): Create table Student( CodStud Number(5) Primary Key, Nume Varchar(40), DataN Date); Programul conine att definirea tabelelor ct i definirea celorlalte obiecte ale bazei de date i a interdependenelor dintre acestea (de exemplu constrngerile de integritate intra-tabel i inter-tabele). De asemenea aici se fac i toate operaiile privind proiectarea la nivel fizic a bazei de date. n cazul folosirii unor unelte CASE programul de creare poate fi generat i executat automat. Prezentm n continuare elementele care definesc modelul entitate asociere n varianta clasic i cteva elemente despre modelul utilizat n cazul instrumentelor CASE.
2.2.
Modelul entitate-asociere clasic
Acest model a fost introdus de P. P. Chen n 1976 ([Ch 76]). El se constituie ntr-o abordare de tip grafic a proiectrii bazelor de date i a fost adoptat de comunitatea tiinific precum i de productorii de software n domeniu datorit simplitii i expresivitii sale.
Elementele modelului
Modelul entitate-asociere permite reprezentarea informaiilor despre structura bazelor de date folosind trei elemente de construcie: entiti, atribute ale entitilor i asocieri ntre entiti. Definiia lor informal este urmtoarea:
20
Entitile modeleaz clase de obiecte concrete sau abstracte despre care se colecteaz informaii, au existen independent i pot fi identificate n mod unic. Exemple de entiti: Studeni, Orae, Angajai, etc. Ele definesc de obicei persoane, amplasamente, obiecte sau evenimente cu importan informaional. Membrii unei clase care formeaz o astfel de entitate poart numele de instane ale acelei entiti. De remarcat c ntreaga literatur de specialitate definete nti conceptul de mulime de entiti (sau tip de entiti) pentru ca apoi s adopte pentru uurina exprimrii prescurtarea de entitate pentru acest concept. Deci entitatea este un obiect generic care reprezint mulimea tuturor instanelor sale. Entitile sunt de dou categorii: Entiti independente (sau tari) sunt cele care au existen independent de alte entiti, Entiti dependente (sau slabe) sunt formate din instane care i justific ncadrarea n clasa respectiv doar atta timp ct ntr-o alt entitate (tat) exist o anumit instan de care sunt dependente. De exemplu n cazul unei baze de date de personal, fiecare instan a entitii COPII rmne n clasa respectiv (copiii angajailor) att timp ct n entitatea ANGAJAI exist instana reprezentnd pe tatl/mama acelui copil. Element al modelului Entitate Tip Tare Slab Atribut De identificare Nume atribut De Descriere Asociere Asociaz entiti 1-2 Nume atribut Nume asociere Reprezentare Nume entitate Nume entitate
Modelarea datelor
21 Asociaz mai mult de 2 entiti (exemplu: 3 entiti) 3: .... 6:
Fig. 2.1. Convenia de reprezentare a elementelor modelului EA
Atributele modeleaz proprieti atomice distincte ale entitilor. De exemplu entitatea STUDENI poate avea ca atribute Matricola, Nume, Prenume, Vrsta, Anul, Grupa, etc. n procesul de modelare vor fi luate n considerare doar acele proprieti ale entitilor care sunt semnificative pentru aplicaia respectiv. Din acest motiv, la entitatea STUDENI nu vom lua n considerare caracteristici ca Talia sau Culoarea_prului acestea nefiind necesare pentru baza de date a universitii (astfel de atribute ar putea exista de exemplu ntr-o baz de date privind personalul militar). Atributele unei entiti sunt de dou feluri: 1. atributele de identificare (formnd mpreun identificatorul entitii) reprezint acea mulime de atribute care permit distincia ntre instanele aceleiai entiti 2. atributele de descriere (sau descriptori) sunt folosii pentru memorarea caracteristicilor suplimentare ale instanelor. n exemplul de mai sus Matricola este atribut de identificare (deoarece nu pot exista doi studeni cu aceeai matricol ntr-o facultate) pe cnd celelalte atribute sunt descriptori. Asocierile modeleaz interdependenele dintre clasele de obiecte reprezentate prin entiti. De exemplu ntre entitile STUDENI i FACULTI se poate figura o asociere NSCRIS_LA care descrie mprirea studenilor pe faculti. n crearea diagramei nu vor fi luate n consideraie dect interdependenele care sunt necesare aplicaiei respective, n lumea real putnd exista ntre entitile diagramei i alte asocieri care nu sunt semnificative n contextul dat. Figura 2.1. prezint convenia de reprezentare grafic a celor trei tipuri de construcii care particip la formarea unei diagrame EA. Se observ c:
Extensii ale modelului

Modelul entitate-asociere clasic are unele lipsuri n ceea ce privete posibilitatea modelrii caracteristicilor asociate unor subclase de obiecte modelate prin simple entiti. Pentru aceasta, la modelul original au fost adugate dou noi concepte: ierarhia de generalizare i ierarhia de incluziune. Definiie (ierarhia de incluziune): O entitate E1 este o submulime a entitii E (sau este inclus n entitatea E) dac fiecare instan a lui E1 este de asemenea o instan a lui E.
22
Un exemplu de incluziune este definirea n cadrul entitii ANGAJAI a unor subclase modelate prin entitile INGINERI, ECONOMITI i COLABORATORI. n cazul ierarhiei de incluziune entitile fiu pot s nu fie disjuncte dou cte dou. De asemenea reuniunea lor poate s nu acopere n ntregime entitatea tat: exist angajai care nu sunt nici ingineri, nici economiti i nici colaboratori. Definiie (ierarhia de generalizare): O entitate E este generalizarea entitilor E1, E2, ..., En dac orice instan a lui E este de asemenea instan n una i numai una din entitile E1, E2, ..., En. Un exemplu de generalizare este clasarea instanelor entitii ANGAJAI n subclasele BARBAI i FEMEI. Caracteristica ierarhiei de generalizare este c din punct de vedere matematic entitile fiu reprezint o partiie a entitii tat: a. E1 E2 ... En = E i b. Ei Ej = pentru orice i j din intervalul 1..n Ierarhiile de incluziune i generalizare se folosesc doar n cazul n care pentru subclasele unor clase modelate prin entiti este nevoie de stocarea unor informaii suplimentare specifice. Convenia grafic de reprezentare a celor dou tipuri de ierarhii se gsete n fig. 2.2. Element Ierarhie de incluziune Reprezentare
E1
E2
E3
Modelarea datelor
23
Ierarhie de generalizare
Crite riu
E1
E2
Fig. 2.2. Convenia grafic de reprezentare grafic a ierarhiilor
Caracteristici ale elementelor modelului

Aa cum entitile au atribute care specific diversele proprieti ale clasei de obiecte modelate, i asocierile au caracteristici care aduc informaii suplimentare. Acestea sunt urmtoarele:
Gradul asocierii
Este o valoare numeric ntreag i este dat de numrul de entiti care particip la acea asociere. Asocierile de grad 1, 2 i 3 se mai numesc i asocieri unare, binare i respectiv ternare.
Tutor STUDENT
nscris_la
Alocare
FACULTATE
PROIECT
CALCULATOR
Fig. 2.3. Exemple de asocieri de grad 1, 2 i 3
24
Conectivitatea asocierii
Este specific fiecrei ramuri a unei asocieri i poate avea una din urmtoarele dou valori: unu sau multi. Determinarea ei pentru ramura spre o entitate E se face astfel: fixnd arbitrar cte o instan pentru celelalte entiti care particip la asociere se pune ntrebarea: cte instane ale lui E pot fi conectate cu acestea? Dac poate fi cel mult una, conectivitatea ramurii este unu, altfel conectivitatea este multi. Pentru exemplul din figura 2.3. putem avea: asocierea TUTOR de tip unu-unu sau multi-uni, asocierea NSCRIS_LA de tip multi-unu (multi spre STUDENT) sau multi-multi, iar pentru asocierea ternar ALOCARE multi (STUDENT)-unu-unu. Convenia de reprezentare grafica: ramurile 'unu' vor fi reprezentate sub forma de sgeat.
Obligativitatea asocierii
Ca i conectivitatea, aceasta se determin pentru fiecare ramur i poate avea doar una din urmtoarele valori: obligatorie sau opional. Determinarea ei pentru ramura spre o entitate E se face astfel: fixnd arbitrar cte o instan pentru celelalte entiti care particip la asociere se pune ntrebarea: este obligatoriu s existe o instan a lui E asociat cu acestea? Dac rspunsul este 'Da' ramura este obligatorie altfel este opional. Convenia de reprezentare grafic a clasei de apartenen folosit n continuare este urmtoarea: ramurile obligatorii vor fi reprezentate prin linie continu iar cele opionale prin linie ntrerupt. n figura 2.4 este prezentat diagrama anterioar avnd figurat i obligativitatea.
Atributele asocierilor
n unele cazuri o anumit informaie descriptiv nu este asociat cu o clas de obiecte ci cu un ansamblu de clase diferite modelate fiecare prin entiti. n acest caz aceasta va fi modelat ca un atribut al asocierii dintre entitile respective.
Rolul
n cazul n care de la o asociere pornesc mai multe ramuri ctre aceeai entitate, fiecreia dintre acestea i se poate asocia un rol. Acesta arat semnificaiile diferite pe care le are aceeai entitate n cadrul asocierii respective. tutor Tutor STUDENT discipol nscris_la FACULTATE
Modelarea datelor
25 Alocare
PROIECT
CALCULATOR
Fig. 2.4. Reprezentarea obligativitii. Roluri
Criterii de modelare
a. Clasificarea n entiti i atribute Dei definiia noiunilor de entitate, atribut, asociere este destul de simpl, n practica modelrii apar dificulti n clasificarea diverselor informaii ntr-una din aceste categorii. Pentru a putea clasifica corect informaiile, exist cteva reguli care trebuie respectate i pe care le prezentm n continuare. Regula 1. Entitile au informaii descriptive, pe cnd atributele nu posed astfel de informaii. De exemplu dac despre un ORA este necesar stocarea n baza de date a unor informaii ca JUDE, POPULAIE, etc. atunci ORA va fi o entitate. Dac singura informaie necesar este numele su atunci NUME_ORA va fi un atribut al altei entiti. Regula 2. Atributele multivalorice vor fi reclasificate ca entiti. Exemplu: Are_Sediu_n BANCA LOCALITATE
Num e
Regula 3. Atributele unei entiti care au o asociere multi-unu cu o alt entitate vor fi reclasificate ca entiti. Exemplu:
Num e
JUDE
BANCA
LOCALITATE
Regula 4. Atributele vor fi ataate la entitile pe care le descriu n mod nemijlocit. Regula 5. Folosirea identificatorilor compui va fi evitat. n model relaional pentru atributele de acest fel se construiesc de regul structuri de cutare rapid (indeci) care funcioneaz cu att mai lent cu ct complexitatea indecsului crete.
26
b. Identificarea ierarhiilor de generalizare i incluziune. n cazul n care despre anumite subclase ale unei clase de obiecte exist informaii specifice, clasa i subclasele (care la pasul anterior au fost catalogate ca entiti) sunt interconectate ntr-o ierarhie de incluziune sau generalizare, dup cum este cazul. La acest pas se face i o reataare a atributelor pentru evitarea redundanei, astfel: 1. Tatl i fii unei ierarhii au acelai identificator. 2. Descriptorii care apar i la tat i la fii se elimin de la fii. 3. Descriptorii care apar la toi fii unei ierarhii de generalizare i nu apar la tat se mut la tat. c. Identificarea asocierilor n aceasta etap se trateaz informaiile care nu au fost clasificate ca entiti sau atribute ci reprezint interdependene ntre clase de obiecte. Ele sunt modelate ca asocieri ntre entiti. Pentru fiecare asociere se specific gradul, conectivitatea, obligativitatea i dac este cazul i atributele asocierii precum i rolurile ramurilor sale. Se elimin de asemenea asocierile redundante. d. Integrarea vederilor. n cazul proiectrii bazelor de date complexe, activitatea se desfoar uneori de ctre mai multe colective simultan, diagramele rezultate sunt apoi integrate eliminndu-se redundanele i inconsistenele.
2.3.
Modelul entitate-asociere clasic
Modelul clasic are o serie de dezavantaje, mai ales n ceea ce privete lizibilitatea diagramelor complexe. Pentru uneltele CASE care utilizeaz EA s-a ales o variant modificat: Atributele unei entiti sunt nscrise n caseta acesteia. Este marcat tupul lor: # Identificare * NOT NULL o Poate fi NULL Asocierile: Nu exist dect asocieri de grad 1 sau 2 cu conectivitate 1-1 sau 1-M. Toate asocierile de grad mai mare ca 2 sau cele de grad 1 sau 2 cu conectivitate M-M sunt modelate ca entiti intersecie. Etichetarea nu este per asociere ci per capt de asociere (deci 2 etichete pentru fiecare asociere) Entitile: Identificatorul unei entiti poate fi format din atribute i/sau capete de asocieri. Pot exista entiti (de exemplu entiti intersecie) care au identificatorul format numai din capete de asociere. Marcajul este bararea captului respectiv de asociere.
Modelarea datelor
27
Ierarhiile: Ierarhiile se numesc aici Subtipuri-Supertipuri. Entitile fiu sunt figurate ca incluse n caseta entitii tat. Exist n anumite variante doar ierarhiile de generalizare (fr cele de incluziune). Exemplu de diagram:
ALOCARE o NrOre
PentruUn Are Soie PentruUn Are So PeUn Are
STUDENT #* Matr * Nume * Grupa
PROIECT #* IdP * NumeP
nscrisLa Are
CALCULATOR #* NrInv o Tip
FACULT #* CodF * NumeF
28
3. MODELUL RELAIONAL
O problem fundamental a unui SGBD este modul n care datele sunt organizate n vederea stocrii i exploatrii lor de ctre aplicaii.
3.1. Modele de date: ierarhic, reea, relaional

Din punct de vedere istoric, n anii 60 au existat dou modele de organizare a datelor care au fost apoi abandonate din cauza problemelor pe care le generau: Modelul ierarhic, folosit de IBM n sistemul IMS (care nc este unul dintre produsele furnizate de aceast firm), n care organizarea este sub forma arborescent: nodurile conin date i legturi (pointeri) ctre nodurile fiu (vezi http://www-306.ibm.com/software/data/ims/ Modelul reea. n cadrul acestuia nregistrrile sunt structurate sub forma unui graf orientat, fiecare nod putnd avea mai multe nregistrri tat i mai muli fii. Au existat mai multe sisteme de gestiune i limbaje de programare dezvoltate pe baza acestui model (de exemplu limbajul COBOL). Dezavantajul principal al acestor dou modele este c accesul la o nregistrare necesit navigarea prin arbore sau graf pentru a o localiza. Din acest motiv apar o serie de probleme mai ales legate de timpul necesar scrierii de noi programe i a detectrii anomaliilor care pot s apar n proiectarea bazei de date. Modelul relaional al datelor, folosit n acest moment de majoritatea covritoare a sistemelor de gestiune aflate pe pia a fost introdus n anul 1970 prin articolul lui Edgar Frank Codd A Relational Model for Large Shared Databanks. Acest model, n care datele sunt stocate sub form tabelar are o serie de avantaje care au dus la nlturarea celorlalte modele: Datele sunt stocate doar ca valori; nu exist pointeri sau navigare prin date; Face posibil dezvoltarea de limbaje de cereri de nivel nalt n care utilizatorul specific ce date dorete i nu cum se ajunge la rezultat, modul n care este calculat acesta fiind n sarcina sistemului de gestiune (exemplu de astfel de limbaj: SQL) Furnizeaz o baz solid pentru problemele de corectitudine a datelor (redundan, anomalii, etc). Permite tratarea problemelor de independen a datelor (discutate n capitolul 1). Este extensibil, putnd fi utilizat i pentru modelarea i manipularea de date complexe.
30
3.2. Elementele de baz ale modelului relaional

Domeniu
Definiie: Domeniu (eng. Domain) = o mulime de valori avnd asociat un nume. Un domeniu se poate defini fie prin enumerarea elementelor sale fie prin specificarea unor caracteristici definitorii ale acestora. Exemple: Nota = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} sau Nota = {n N* | n 1 i n 10} ir40 = {Mulimea irurilor de maxim 40 de caractere} Numr = {Mulimea numerelor ntregi pozitive din intervalul [0, 100000]} Din teoria mulimilor se cunoate noiunea de produs cartezian al unor mulimi: fiind date n domenii D1, D2, , Dn produsul lor cartezian este: D1 D2 Dn = { (v1, v2, , vn) | vi Di , i = 1, , n} n irul de domenii care particip la un produs cartezian unele se pot gsi n mod repetat: PC = Numr ir40 Numr Numr ir40 ir40
Relaie
Definiie: Relaie (eng. Relation) = o submulime a unui produs cartezian avnd asociat un nume. Termenul de relaie provine de asemenea din matematic. Un exemplu de relaie aparinnd produsului cartezian PC din paragraful urmtor este: Produse = { (101, Produs1, 30, 20, Firma1, Adresa1) , (105, Produs2, 20, 23, Firma1, Adresa2), (124, Produs3, 10, 20, Firma1, Adresa1) } Elementele unei relaii sunt denumite n literatura de specialitate tupluri (engl. tuple). Relaia de mai sus conine doar 3 dintre elementele produsului cartezian din care provine (3 tupluri). O reprezentare intuitiv pentru o relaie este o tabel n care fiecare element al relaiei devine o linie i fiecare coloan corespunde unui domeniu: 10 Produs1 3 20 Firma1 Adresa1 1 0 10 Produs2 20 23 Firma2 Adresa2 5 12 Produs3 1 20 Firma1 Adresa1 4 0 n fapt deci o relaie se reprezint printr-o tabel care conine date, fiecare coloan avnd asociat un anumit tip de date, dat de domeniul din care provine.
Atribut
Deoarece o relaie are o reprezentare tabelar putem vorbi de coloan a unei relaii. n mod obinuit, ntr-o tabel coloanele au un nume.
Modelul relaional
31
Definiie: Atribut (eng. Attribute) = coloan a unei relaii avnd asociat un nume. Pentru relaia Produse putem fixa de exemplu urmtoarele nume de atribute: IdP Codul produsului (nu exist dou produse avnd acelai cod) NumeP numele produsului Qty Cantitate IdF Codul furnizorului (nu exist doi furnizori avnd acelai cod) NumeF Numele furnizorului AdresaF Adresa furnizorului Produse Id NumeP Qty IdF NumeF AdresaF P 101 Produs1 30 20 Firma1 Adresa1 105 Produs2 20 23 Firma2 Adresa2 124 Produs3 10 20 Firma1 Adresa1
Schema unei relaii

n terminologia relaional structura unei relaiei este denumit i schema relaiei. Definiie: Schema unei relaii (eng. Relation scheme) = numele relaiei urmat de lista atributelor sale i (eventual) de domeniul din care acestea provin. Exist mai multe modaliti prin care se poate specifica schema unei relaii. n exemplele urmtoare prezentm cteva dintre acestea cu referire la relaia Produse:
Produse(IdP, NumeP, Qty, IdF, NumeF, AdresaF) Produse(IdP: Numr, NumeP: ir40, Qty: Numr, IdF: Numr, NumeF: ir40, AdresaF: ir40) Produse = IdP, NumeP, Qty, IdF, NumeF, AdresaF
n cazul prezentrii unora dintre elementele de teorie a bazelor de date relaionale se folosesc i notaii de forma: R = ABCDE, cu semnificaia: schema relaiei R conine 5 atribute notate cu A, B, C, D i respectiv E.
Cheia unei relaii

O relaie fiind o mulime (de tupluri) nu poate conine elemente duplicat spre deosebire de exemplu de un tabel Excel unde putem avea dubluri. Rezult c tuplurile pot fi deosebite ntre ele prin valorile aflate pe una sau mai multe coloane din relaie. Definiie: Cheia unei relaii (eng. Relation key) este o mulime minimal de atribute ale cror valori identific n mod unic un tuplu al relaiei respective. Cheia unei relaii este o caracteristic a schemei acesteia i nu este determinat prin inspectarea valorilor aflate la un moment dat n relaie.
32
n tabela Produse cele trei linii existente pot fi identificate unic de valorile de pe 3 atribute (IdP, NumeP i Qty) dar numai IdP este cheie: O relaie poate avea mai multe chei. S ne imaginm o relaie Studeni coninnd date despre studenii romni ai unei faculti: Studeni (IdStud, NrMatricol, Nume, CNP, SerieCI, NumrCI) n acest caz avem mai multe chei: { IdStud }, { NrMatricol }, { CNP } i {SerieCI, NumrCI}. Observaie: Orice relaie are cel puin o cheie: deoarece ntr-o relaie nu pot exista dou elemente identice, rezult c mulimea tuturor atributelor relaiei este cheie sau conine cel puin o cheie.
Valori nule
Uneori, unele elemente ale unei relaii (celule ale tabelei) nu au nici o valoare concret. Se spune c n acel loc exist o valoare nul. Definiie: Valoare nul (eng. Null value) = o valoare diferit de oricare alta i care modeleaz o informaie necunoscut sau o informaie inaplicabil(=n poziia respectiv nu trebuie s existe o valoare nenul).
3.3. Transformarea diagramelor EA n modelul relaional

Procesul de transformare are un algoritm foarte precis i este din aceast cauz pasul care se preteaz cel mai bine pentru crearea de instrumente software care s-l asiste.
Transformarea entitilor
Fiecare entitate a diagramei se transform ntr-o schem de relaie avnd: Numele relaiei = Numele entitii Atributele relaiei = Atributele entitii Cheia relaiei = Identificatorul entitii
Transformarea asocierilor unare i binare 1-1 i 1-M

Fiecare asociere din aceast categorie va avea ca rezultat mbogirea mulimii de atribute descriptive ale uneia dintre cele dou scheme rezultate la pasul anterior din entitile asociate, cu cheia celeilalte scheme. Aceste atribute care se adaug sunt chei strine (externe) deoarece ele sunt cheie dar n alt schem de relaie. n cazul asocierilor multi-unu, se adaug identificatorul entitii unu n schema rezultat din entitatea multi n cazul asocierilor unu-unu, se adaug identificatorul unei entiti n schema rezultat din transformarea celeilalte.
Modelul relaional
33
Transformarea asocierilor unare i binare M-M i a celor cu grad mai mare ca doi
Fiecare asociere binar multi-multi i fiecare asociere cu grad mai mare ca doi se transform ntr-o schem de relaie astfel: Nume relaie = Nume asociere Atribute relaie = Reuniunea identificatorilor entitilor asociate la care se adaug atributele proprii ale asocierii Cheia relaiei = Conform tabelului urmtor Grad Cheia relaiei provenite din asociere Unare multi (E) - multi (E) Cheie(E) + Redenumire(Cheie(E)) Binare multi (E1) - multi (E2) Cheie(E1) + Cheie(E2) Ternare unu (E1) - unu (E2) - unu (E3) Cheie(E1)+Cheie(E2) sau Cheie(E1)+Cheie(E3) sau Cheie(E2)+Cheie(E3) sau unu (E1) - unu (E2) - multi (E3) Cheie(E1)+Cheie(E3) sau Cheie(E2)+Cheie(E3) sau unu (E1) - multi (E2) - multi (E3) Cheie(E2)+Cheie(E3) multi (E1) - multi (E2) - multi (E3) Cheie(E2)+Cheie(E3)+ Cheie(E1) Pentru asocierile de grad mai mare ca 3 se procedeaz analog. Conectivitate
3.4. Algebra relaional

nc din primul su articol n care introduce modelul relaional, E.F. Codd propune i un set de operatori pentru lucrul cu relaii. Cum o relaie este o mulime de tupluri o parte dintre aceti operatori provin direct din teoria mulimilor. Ceilali operatori, introdui n aceast algebr pentru relaii (numit n literatura de specialitate algebra relaional) sunt specifici acesteia i au la baz operaii uzuale cu tabele acestea fiind reprezentri intuitive pentru relaii. Dup apariia primelor sisteme de gestiune a bazelor de date relaionale s-a constatat ns c aceast algebr nu nglobeaz o serie de situaii care apar n practic: n cazul execuiei unei cereri SQL pot s apar tabele rezultat n care exist linii duplicat. n plus, n cazul n care pe o tabel din baza de date nu a fost definit o cheie primar, putem s avem n aceasta mai multe linii identice. Problema liniilor duplicat intr n contradicie cu definiia unei relaii n care nu putem avea dou tupluri identice. Din acest motiv n acest subcapitol prezentm urmtoarele variante de operatori: Operatori ai algebrei relaionale clasice n care pornind de la una sau mai multe relaii obinem o relaie.
34

Operatori ai algebrei pe multiseturi care lucreaz pe aa numitele multiseturi (n englez bags) care sunt asemntoare relaiilor dar n care putem avea elemente duplicat. Operatori care lucreaz att pe relaii ct i pe multiseturi. Ei sunt o extensie a algebrei relaionale i pe multiseturi i provin din necesitatea de a putea rescrie orice cerere SQL n termeni ai algebrei extinse.
Algebra relaional clasic

Exist mai muli operatori n cadrul acestei algebre, unii dintre ei fiind derivai (se pot rescrie n funcie de ali operatori). Putem mpari aceti operatori n dou categorii: Operatori derivai din teoria mulimilor. Operatori specifici algebrei relaionale
Operatori derivai din teoria mulimilor

Reuniunea: Fiind date dou relaii R i S, reuniunea lor, notata R S este o relaie care conine tuplurile care sunt fie n R, fie n S fie n ambele relaii. n rezultatul reuniunii nu apar tupluri duplicat. Pentru ca aceast operaie s poat fi executat cele dou relaii care se reunesc trebuie s aib scheme compatibile. Exemplu:
A 1 2 1
B 1 1 3
C 2 3 2
A 4 2 1 5
B 1 1 3 1
C 2 3 2 7
Relaia R
Relaia S
A B C 1 1 2 2 1 3 1 3 2 4 1 2 5 1 7 Relaia R S
Diferena: Fiind date dou relaii R i S, diferena lor, notat R - S este o relaie care conine tuplurile care sunt n R i nu sunt n S. i n cazul diferenei cele dou relaii care se reunesc trebuie s aib scheme compatibile. Exemplu:
A 1 2 1
B 1 1 3
C 2 3 2
Relaia R
A B C 4 1 2 2 1 3 1 3 2 5 1 7 Relaia S
A B C 1 1 2
Relaia R - S
Modelul relaional
35
Intersecia: Fiind date dou relaii R i S, intersecia lor, notat R S este o relaie care conine tuplurile care sunt i n R i n S. De asemenea cele dou relaii care se reunesc trebuie s aib scheme compatibile.
A 1 2 1
B 1 1 3
C 2 3 2
Relaia R
A B C 4 1 2 2 1 3 1 3 2 5 1 7 Relaia S
A B C 2 1 3 1 3 2 Relaia R S
Produsul cartezian: Fiind date dou relaii R i S, produsul lor cartezian, notat R S este o relaie ale crei tupluri sunt formate prin concatenarea fiecrei linii a relaiei R cu fiecare linie a relaiei S. Rezult de aici urmtoarele: Numrul de atribute (coloane) ale lui R S este egal cu suma numerelor de atribute ale lui R i S Numrul de tupluri (linii) ale lui R S este egal cu produsul numerelor de tupluri ale lui R i S Dac n R i S avem atribute (coloane) cu acelai nume, n produsul cartezian R S vom avea atribute care au acelai nume. Pentru a le deosebi se prefixeaz numele atributului cu cel al relaiei din care provine (ex.: R.A i S.A, ca n exemplul urmtor)
Operatori specifici algebrei relaionale

Proiecia: Fiind dat o relaie R i o mulime de atribute ale acesteia X=A1, A2, An, proiecia lui R pe mulimea de atribute X este o relaie care se obine din R lund doar coloanele din X (n aceasta ordine) i eliminnd eventualele tupluri duplicat. Notaia pentru selecie este urmtoarea:
X(R) sau A1, A2, An (R)

Exemplu: din relaia R de mai jos dorim s calculm B, C, E (R)
A 1 2 2 2 1 1
B 1 1 7 3 3 3
Relaia R
C 2 2 4 9 7 9
D 1 1 4 2 4 2
E 3 3 1 1 1 1
B 1 7 3 3
C 2 4 9 7
E 3 1 1 1
Rezultatul proieciei B, C, E (R) Observm c s-au eliminat dou linii duplicat din rezultat (cele provenite din liniile 2 i 6).
36
Selecia (numita uneori restricia): Fiind dat o relaie R i o expresie logic F (o condiie), selecia lui R n raport cu F este o relaie care se obine din R lund doar liniile care verific expresia logic F. Notaia pentru selecie este urmtoarea: F(R) Exemplu: din relaia R de mai sus dorim s calculm B+1 > A+C(R) obinem :
A 2
B 7
C 4
D 4
E 1
Joinul general (numit i theta-join sau -join): fiind date dou relaii R i S, joinul lor (notat RFS) se obine din produsul cartezian al relaiilor R i S urmat de o selecie dup condiia F (numit i condiie de join). Denumirea de theta-join este folosit din motive istorice, simbolul fiind folosit iniial pentru a desemna o condiie. Rezult c: RFS = F(R S) Join natural: Joinul natural pentru dou relaii R i S (notat R S )se obine fcnd joinul celor dou relaii dup condiia coloanele cu aceeai semnificaie au valori egale i eliminnd prin proiecie coloanele duplicat (cele dup care s-a fcut joinul). Exemplu:
A 1 2 1
B 1 1 3
C 2 3 2
Relaia R
A D E 4 1 2 2 1 3 1 3 2 5 1 7 Relaia S
A B C D E 1 1 2 3 2 1 3 2 3 2 2 1 3 1 3 Relaia R S
Join extern: n cazul n care o linie a unei tabele, oricare ar fi concatenarea ei cu o alt linie din cealalt tabel, nu ndeplinete condiia de join, linia respectiv nu are corespondent n rezultat. n unele cazuri se dorete ns ca aceste linii s apar n rezultat, cu valori nule pe coloanele din cealalt tabel. Aceast operaie poart numele de join extern (n englez outer join). Cum la un join particip dou tabele, pot exista trei tipuri de join extern:
Join extern stnga (left outer join), n care n rezultat apar toate liniile tabelei din stnga operatorului. Join extern dreapta (right outer join), n care n rezultat apar toate liniile tabelei din dreapta operatorului.
Modelul relaional
37
Join extern complet (full outer join), n care n rezultat apar toate liniile tabelei din stnga i din dreapta operatorului.
Operatori folosii pentru multiseturi

Aa cum am spus anterior, n practica bazelor de date ntr-o tabel sau un rezultat al unei cereri de regsire de date pot s apar linii duplicat. n acest caz nu mai putem vorbi de relaii (care nu permit tupluri duplicat) ci de multiseturi (eng. bags). Prezentm pe scurt efectul unora dintre operatorii de mai sus aplicai multiseturilor: Reuniunea: Efectul este asemntor cu al reuniunii din algebra relaional dar din rezultatul final nu se elimin duplicatele. Intersecia, diferena, produsul cartezian, selecia, joinul, joinul natural, joinul extern: acelai mod de calcul ca i n cazul relaiilor dar: Multiseturile opernd pot s conin linii duplicat Din rezultat nu se elimin liniile duplicat Observaie: n cazul acestor operaii nu pot aprea linii duplicat dect dac operanzii conin linii duplicat. Proiecia: Acelai mod de calcul ca i n cazul relaiilor dar la final nu eliminm liniile duplicat.
Operatori pentru relaii i multiseturi

Redenumirea: Exist constructorul care permite redenumirea atributelor n rezultatul unei expresii relaionale sau pe multiseturi: Putem redenumi ntr-un rezultat un atribut prin construcia: Nume_vechi Nume_nou Exemplu:
BNume, CPrenume, EDataN (R)

Eliminare duplicate: Acest operator se poate aplica doar pe multiseturi: fiind dat un multiset R, (R) este un multiset fr duplicate (deci o relaie) Grupare: Acest operator se poate aplica att relaiilor cat i multiseturilor. Forma operatorului de grupare este urmtoarea:
Lista_atribute_i_funcii_statistice(R)
Atributele din list sunt criterii de grupare. Ele apar n rezultatul returnat de operator Funciile statistice din list (ex.: MIN, MAX, SUM, AVG, COUNT) se calculeaz la nivelul fiecrui grup i de asemenea apar n rezultatul operatorului Sortare: Efectul este sortarea relaiei sau multisetului R n funcie de atributele din list. Forma operatorului de sortare este urmtoarea:
38
Proiecie extins: Acest operator este analog proieciei obinuite dar permite atribute (coloane) calculate pentru rezultatul unei expresii pe relaii sau multiseturi. Forma sa este urmtoarea: Exemplu:
Lista_atribute(R)
Expresie-1, Expresie-2, Expresie-n (R) Nume, Medie*2Dublu (STUD)
3.5. Calcul relaional

Pe lng algebra relaional, cererile de regsire a informaiei ntr-o baz de date relaional pot fi exprimate i prin calcul relaional pe tupluri (CRT) sau calcul relaional pe domenii (CRD). n acest paragraf sunt prezentate pe scurt aceste dou modaliti de exprimare a cererilor.
Calcul relaional pe tupluri

n calculul relaional pe tupluri o cerere se exprim printr-o expresie de forma: { t | (t) } unde t este o variabil tuplu iar o formul. Semnificaia expresiei este mulimea tuturor tuplurilor t care verific formula . Exemple: Expresia {t | R(t) S(t) } este echivalent reuniunii a dou relaii din algebra relaional. Analog {t | R(t) S(t) } reprezint intersecia a dou relaii. Expresia pentru proiecia lui R pe atributele i1, i2, , ik se poate scrie astfel: { t(k) | ( u)(R(u) t[1] = u[i1] t[2] = u[i2] t[k] = u[ik]) } Formula ( s)(R(s)) spune c relaia R este nevid Din pcate unele din expresiile scrise n calculul relaional pe tupluri duc la rezultate infinite. De exemplu: dac R este o relaie finit expresia {t | R(t) } este de asemenea finit dar expresia {t | R(t) } este infinit (exist o infinitate de tupluri care nu aparin lui R). Pentru a evita astfel de rezultate s-au introdus aa numitele expresii sigure. Acestea dau garania unui rezultat finit. Exemple de expresii care nu sunt sigure:
{t | R(t) } sau {t | R(t) S(t) } Calcul relaional pe domenii

n calculul relaional pe domenii nu avem variabile tuplu ci variabile de domeniu, ele constituind elementele care formeaz tuplurile. Exemplele de mai sus se pot rescrie astfel:
Modelul relaional
xn) }
39
Reuniunea a dou relaii R i S: {x1x2xn | R(x1x2xn) S(x1x2 Intersecia a dou relaii R i S: {x1x2xn | R(x1x2xn) S(x1x2 Selecia dup condiia valoarea pe prima coloan este mai mare dect
xn) } 100:
{x1x2xn | R(x1x2xn) x1 > 100 } Toate expresiile de mai sus sunt sigure. Analog cu CRT, expresiile: {x1x2xn | R(x1x2xn) } i {x1x2xn | R(x1x2xn) S(x1x2xn) } nu sunt sigure. n literatura de specialitate exist demonstraia faptului c expresiile sigure din CRT i CRD sunt echivalente cu expresii din algebra relaional i reciproc.
4. PROIECTAREA BAZELOR DE DATE

O categorie de probleme care pot s apar n dezvoltarea unei aplicaii coninnd o baz de date este cea a proiectrii incorecte a schemelor de relaie. n acest caz pot s apar o serie de anomalii care pot complica procesul de programare. Testarea corectitudinii unei scheme de relaie poate fi fcut cu ajutorul dependenelor funcionale (sau de alt tip) ataate acelei scheme. Acestea modeleaz corelaii care exist ntre datele din lumea real stocate n baza de date i, aa cum am menionat anterior, n cadrul teoriei bazelor de date relaionale, ele reprezint criterii de corectitudine ale datelor ncrcate n baza de date. n cazul n care o relaie nu are o schem corespunztoare ea trebuie nlocuit cu dou sau mai multe relaii (operaia este numit i descompunerea unei scheme de relaie), fiecare relaie rezultat avnd o schem corect aflat n forma normal dorit. n cadrul acestui capitol vom prezenta elementele de proiectare a structurii unei baze de date subliniate mai sus.
4.1. Anomalii care apar n cazul proiectrii incorecte

Exemplificarea anomaliilor rezultate din proiectarea defectuoas a schemei unei relaii va fi fcut folosind tabela Produse din paragraful 3.1:
Produse
IdP 101 105 124 NumeP Produs1 Produs2 Produs3 Qty 30 20 10 IdF 20 23 20 NumeF Firma1 Firma2 Firma1 AdresaF Adresa1 Adresa2 Adresa1
1. Redundana: Redundana reprezint stocarea n mod nejustificat a unei aceleiai informaii de mai multe ori n baza de date. Observm de exemplu c pentru fiecare produs este stocat numele i adresa furnizorului, dei ele sunt unic determinate de codul acestuia. 2. Anomalia de actualizare: n cazul actualizrii unei informaii redundante, se poate ntmpla ca operaia s modifice unele apariii ale acesteia iar altele s rmn cu vechea valoare.
Proiectarea bazelor de date
41
3. Anomalia de inserare: Nu putem insera date despre un furnizor (numele i adresa sa) dect dac exist n stoc un produs furnizat de acesta. 4. Anomalia de tergere: La tergerea din relaie a ultimului produs al
unui furnizor se pierd automat i datele despre acesta. Aceste anomalii apar deoarece ntr-o aceeai tabel au fost stocate date despre dou clase diferite de obiecte. n cazul proiectrii cu ajutorul modelului entitateasociere diagrama corect este urmtoarea:
Id Nume Adresa
F
FURNIZOR
Id P
Nume P
Qt y
furnizeaz R
PRODUSE
Prin transformarea acestei diagrame se obin urmtoarele scheme de relaie: Furnizor(IdF, NumeF, AdresaF) Produse(IdP, NumeP, Qty, IdF) Rezult c informaia din relaia Produse trebuie stocat de fapt n dou relaii. Procesul de spargere a unei tabele care are o structur incorect n dou sau mai multe tabele se numeste descompunerea schemei de relaie. Pentru detectarea relaiilor care trebuiesc descompuse exist o serie de reguli de corectitudine, numite i forme normale. Definirea acestor forme normale se bazeaz pe noiunea de dependen (funcional sau multivaloric) prezentat n continuare.
4.2. Dependene funcionale

Notaii
n paragrafele urmtoare vom folosi urmtoarea convenie de notare, ntalnit n multe lucrri din literatura de specialitate a domeniului: R, S, T, : scheme de relaii, r, s, : insante ale relaiilor R respectiv S, A, B, C, D, (litere mari de la nceputul alfabetului): atribute ale unei relaii, X, Y, Z, W, U, (litere mari de la sfritul alfabetului): mulimi de atribute dintr-o schema de relaie,
42
X R: Mulimea de atribute X este inclus n mulimea atributelor relaiei R. Y X: Mulimea de atribute Y este inclus n mulimea de atribute X A X: Atributul A aparine mulimii de atribute X
t, t1, t2, tupluri ale unei relaii, t[X]: valorile atributelor din X aflate n tuplul t, F, G, : mulimi de dependene funcionale ataate unei scheme de relaie
n paragrafele urmtoare termenul generic de relaie semnific att schema relaiei (descrierea structurii acesteia) ct i o instan a acesteia (coninutul de date de la un moment dat al relaiei).
Definiia dependenelor funcionale

Definiie: Fie: R o schema de relaie X, Y R doua mulimi de atribute ale acesteia. Spunem c X determina funcional pe Y (sau Y este determinat funcional de X) dac i numai dac oricare ar fi dou tupluri t1 i t2 din orice instan a lui R atunci: t1[X] = t2[X] t1[Y] = t2[Y]. sau, n cuvinte, dac dou tupluri au aceleai valori pe atributele X atunci ele au aceleai valori i pe atributele Y. Notaia pentru dependene funcionale este o sgeat de la stanga spre dreapta: X Y Exemplu: n relaia Produse din paragraful anterior putem scrie urmtoarele dependene funcionale: IdP NumeP, Qty, IdF, NumeF, AdresaF, IdF NumeF, AdresaF Aceste dependene arat c: dac dou produse au acelai IdP, este vorba de fapt de acelai produs dac dou produse au acelai IdF (Id furnizor) atunci i valorile pentru numele i adresa acestuia trebuie s fie aceleai. Observaie: Dependenele funcionale nu se determina din inspectarea coninutului de la un moment dat al relaiei ci din semnificaia atributelor acesteia. n exemplul prezentat, a doua dependen funcional arat c dac la dou produse apare acelai Id furnizor atunci numele i adresa furnizorului sunt de asemenea aceleai (deoarece nu pot s existe doi furnizori diferii cu acelai Id).
Axiome i reguli
Pornind de la o mulime de dependene funcionale ataate unei scheme de relaie se pot deduce alte dependene funcionale valide. Exist o multitudine de reguli de inferen. Pentru a se putea face o prezentare formal a acestora, trei
43
dintre ele au fost alese ca axiome iar restul se pot deduce pornind de la ele. Cele trei axiome (numite n literatur i Axiomele lui Armstrong) sunt urmtoarele: A1. Reflexivitate: Fie R o schem de relaie i X R. Dac Y X atunci: X Y Toate dependenele funcionale care rezult din aceast axiom sunt numite i dependene triviale. Ele nu spun nimic n plus fa de setul de dependene iniial dar sunt dependene funcionale valide. A2. Augmentare: Fie R o schem de relaie i X, Y, Z R. Dac X Y atunci i XZ YZ A3. Tranzitivitate: Fie R o schem de relaie i X, Y, Z R. Dac X Y i Y Z atunci i X Z Pe baza acestor axiome se pot demonstra o serie de reguli de inferen pentru dependene funcionale dintre care cele mai importante sunt urmtoarele: R1. Descompunere: Fie R o schem de relaie i X, Y, Z R. Dac X Y i Z Y atunci i X Z Regula descompunerii ne permite s rescriem un set de dependene funcionale astfel nct s obinem doar dependene care au n partea dreapt doar un singur atribut. Sa presupunem c avem o dependen funcional de forma: X A1A2A3An Atunci ea poate fi nlocuit cu urmtoarele n dependene funcionale: X A1, X A2, X A3, . . ., X An R2. Reuniune: Fie R o schem de relaie i X, Y, Z R. Daca X Y i X Z atunci i X YZ Rezult i faptul c din cele n reguli obinute prin descompunere se poate obine dependena iniial, deci nlocuirea acesteia nu duce la pierderea vreunei corelaii existente. R3. Pseudotranzitivitate: Fie R o schem de relaie i X, Y, Z, W R. Dac X Y i YZ W atunci i XZ W
nchiderea unei mulimi de DF

Pornind de la un set de dependene funcionale F i utiliznd axiomele i regulile obinem o multitudine de alte dependene, triviale sau nu. Mulimea tuturor dependenelor funcionale care se pot deduce din F se numete nchiderea mulimii de dependene F, notat cu F+. Definiia formal a acestei nchideri este urmtoarea: F+ = {X Y | F X Y } Unde prin am notat faptul c dependena respectiv se poate deduce din F folosind axiomele i regulile. Mulimea F+ conine foarte multe dependene, inclusiv dependene triviale ca:
44
ABC A, ABC B, ABC C, ABC AB, ABC AC, ABC BC sau ABC ABC Ea nu se calculeaz, algoritmii care au nevoie de ea ocolind ntr-un fel sau altul calculul acesteia. Introducerea acestei noiuni s-a fcut pentru a explica, n cazul descompunerii unei scheme de relaie, care sunt dependenele motenite de elementele descompunerii de la relaia iniial (paragraful 4.3) i pentru a putea defini formal alte noiuni: Acoperirea unei mulimi de DF: Fie R o schem de relaie i F, G dou mulimi de dependene pentru R. Se spune c F acoper pe G dac i numai dac G F+. Echivalena a dou mulimi de dependene: Fie R o schem de relaie i F, G dou mulimi de dependene pentru R. Se spune c F e echivalent cu G dac i numai dac F acoper pe G i G acoper pe F (deci G F+ i F G+ , deci F+ = G+) Forma canonic a unei mulimi de DF: Din definiiile de mai sus rezult c o mulime de dependene poate fi nlocuit cu alt echivalen coninnd alte dependene. n cazul n care aceast mulime ndeplinete condiiile urmtoare se spune c este n form canonic: Orice dependen are n partea dreapt un singur atribut. Acest lucru se poate obine aplicnd regula descompunerii prezentat anterior. Mulimea de dependene este minimal, nici una dintre dependene neputnd s fie dedus din celelalte (altfel spus nu exist dependene redundante). Exemplu: Fie R = ABCDE o schem de relaie i F mulimea de dependene funcionale asociat, cu F = { AB CDE, C DE }: Aplicm regula de descompunere. Obinem: F = { AB C, AB D, AB E, C D, C E } Mulimea nu este ns minimal deoarece AB D i AB E se pot deduce prin tranzitivitate din AB C mpreun cu C D, C E. Rezult c forma canonic a lui F este: F = { AB C, C D, C E }
Chei i superchei
n acest moment putem s dm o definiie echivalent a cheii pe baza dependenelor funcionale: Definiie: Fie R o schem de relaie, F mulimea de dependene funcionale asociat i X R. Atunci X este cheie pentru R dac i numai dac: F X R (deci X R se poate deduce din F) i X este minimal (oricare ar fi Y X, Y X atunci (F Y R) - deci orice submulime strict a lui X nu mai ndeplinete condiia anterioar).
45
Deci o cheie determin funcional toate atributele relaiei i este minimal: nici o submulime strict a sa nu determina funcional pe R. Se observ faptul c aceasta definiie este echivalent cu cea din capitolul 3. n cazul n care doar prima condiie este ndeplinit mulimea X se numete supercheie. Observaie: Faptul c o supercheie nu este constrns de minimalitate nu nseamn ns c ea nu poate fi minimal. Rezult c orice cheie este n acelai timp i supercheie, reciproca nefiind ns adevrat. Exemplu: Fie R = ABCDE i F = { AB C, C D, C E }. Atunci AB este cheie pentru R: Din AB C, C D i C E obinem prin tranzitivitate AB D i AB E Din AB C, AB D i AB E obinem prin reuniune AB CDE Din AB CDE obinem (augmentare cu AB) AB ABCDE, deci AB R Rezult c AB este supercheie pentru R. n paragrafele urmtoare vom vedea cum se poate demonstra i faptul c AB este minimal, deci este nu numai supercheie ci chiar cheie pentru R.
Proiecia unei mulimi de DF

Aa cum s-a menionat n paragraful 4.2.4. nchiderea unei mulimi de dependene funcionale F+ a fost introdus i pentru a putea defini setul de dependene funcionale motenite de o schem de relaie obinut prin descompunerea unei scheme incorect proiectat. S lum cazul relaiei anterioare coninnd produsele dintr-un depozit: Produse = IdP, NumeP, Qty, IdF, NumeF, AdresaF avnd asociat mulimea de dependene: F = { IdPNumeP, IdPQty, IdP IdF, IdFNumeF, IdFAdresaF } Prin spargerea acestei relaii n dou obinem relaiile: Produse = IdP, NumeP, Qty, IdF Furnizori= IdF, NumeF, AdresaF Atributele relaiei iniiale se regsesc fie doar ntr-una dintre schemele rezultate fie n amndou. Se pune ns i problema: ce dependene motenesc cele dou relaii de la relaia iniiala? Soluia este de a defini proiecia unei mulimi de dependene pe o mulime de atribute. Definiie. Fie o relaie R, o mulime asociat de dependene funcionale F i o submulime de atribute S R . Proiecia mulimii de dependene F pe S, notat cu S(F) este mulimea dependenelor din F+ care au i partea stng i pe cea dreapt incluse n S. Formal putem scrie: S(F) = {X Y F+ | X, Y S } Pentru exemplul de mai sus proieciile sunt urmtoarele:
46

FPRODUSE = PRODUSE(F) = { IdPNumeP, IdPQty, IdP IdF} FFURNIZORI = FURNIZORI (F) = { IdFNumeF, IdFAdresaF }
Observaie: Atunci cnd descompunem o schem se poate ntmpla ca unele dintre dependenele schemei iniiale s se piard. Exemplu: Fie R = ABCD i F = { AB, BC, CD, DA }. n cazul n care descompunem R n R1 = AB i R2 = CD atunci: FR1 = R2(F) ={ AB, BA } FR2 = R1(F) = { CD, DC } A doua dependen din fiecare mulime nu este n F dar este n F+ (obinut prin tranzitivitate). Observm ns c dependenele BC i DA nu mai pot fi obinute nici din FR1 nici din FR2 nici din reuniunea lor. n subcapitolul 4.4. va fi prezentat o metod prin care se poate testa dac prin descompunere dependenele iniiale sunt pstrate sau nu.
nchiderea unei mulimi de atribute

Fie R o schem de relaie, F mulimea de dependene asociat i X R. Se poate defini nchiderea mulimii de atribute X n raport cu F (notat X+ ) astfel: X+ = { A | X A F+ } X+ conine deci toate atributele care apar n partea dreapt a unei dependene din F sau care se poate deduce din F folosind regulile i axiomele. Algoritm de calcul pentru X+ Intrare: R o schem de relaie, F mulimea de dependene asociat i X R Ieire: X+ Metoda: se procedeaz iterativ astfel: Se pornete cu X( 0 ) = X Pentru i 1, X( i ) = X( i 1) { A | ( ) Y A F cu Y X( i 1) } Oprirea se face atunci cnd X( i ) = X( i 1) Exemplu: Fie R = ABCDE i F = { A B, A C, D E }. Pentru a calcula (AD)+ procedm astfel: X( 0 ) = {A, D} Din A B, A C i D E rezult c X( 1 ) = X( 0 ) { B, C, E } = { A, D } { B, C , E} = ABCDE Oprire deoarece X( 1 ) = R deci oricte iteraii am face nu mai pot s apar noi atribute. Rezult c (AD)+ = ABCDE Scopul introducerii acestei noiuni este i cel de a putea ocoli n ali algoritmi i definiii calculul lui F+ . Avem urmtorul rezultat teoretic:
47
Propoziie: Fie R o schem de relaie, F mulimea de dependene asociat i X, Y R. Atunci X Y se poare deduce din F dac i numai dac Y X+
O alt definiie a cheii

Pe baza propoziiei anterioare se poate da o alt definiie pentru cheia sau supercheia unei relaii, bazat nu pe F+ ca n paragraful 4.2.5 ci pe nchiderea unei mulimi de atribute. Definiie: Fie R o schem de relaie, F mulimea de dependene funcionale asociat i X R. Atunci X este cheie pentru R dac i numai dac X + = R i X este minimal (oricare ar fi Y X, Y X atunci Y+ R - deci orice submulime strict a lui X nu mai ndeplinete condiia anterioar). Dac numai prima condiie este ndeplinit atunci X este supercheie pentru R Echivalena acestei definiii cu cea anterioar este evident: X+ = R nseamn cf. propoziiei c X R minimalitatea este de asemenea definit echivalent: (F Y R) este echivalent cu ( Y+ = R) adic Y+ R Folosind aceast definiie se poate defini o euristic de gsire a cheilor unei relaii:
Euristica de gsire a cheilor unei relaii

Pentru gsirea cheilor unei relaii pornim de la observaia c atributele care nu sunt n partea dreapt a nici unei dependene nu pot s apar n procesul de nchidere a unei mulimi de atribute i deci ele aparin oricrei chei a relaiei. Intrare: R o schem de relaie i F mulimea de dependene funcionale asociat (F n form canonic). Ieire: Cheia unic sau cheile alternative ale lui R Metoda: 1. Se pornete de la mulimea de atribute X R care nu apar n partea dreapt a nici unei dependene 2. Se calculeaz X+. Daca X+ = R atunci X este cheia unic minimal a relaiei R i calculul se oprete aici. Paii urmtori se efectueaz doar dac X+ R 3. Se adaug la X cte un atribut din R - X+ obinndu-se o mulime de chei candidat. 4. Se calculeaz X+ pentru fiecare dintre candidate. Daca se obin toate atributele lui R atunci acel X este o cheie a lui R. 5. Se repet paii 3 i 4 pornind de la acele mulimi candidat X care nu sunt gsite ca i chei la pasul anterior. ntre mulimile candidat nu lum niciodat n considerare pe cele care conin o cheie gsit anterior. 6. Procesul se oprete cnd nu se mai pot face augmentari. Exemplu: Fie R = ABCDE i F = { A B, B A , A C, D E }. Mulimea atributelor care nu apar n partea dreapt a nici unei dependene este X = D.
48
BAZE DE DATE ON-LINE Calculm (D)+. Obinem (D)+ = DE. Rezult c D nu este cheie unic
pentru R Calculm mulimea de candidate: augmentm D cu atribute din R D + = ABCDE DE = ABC. Obinem AD, BD i CD Calculm nchiderile lor. Obinem (AD)+ = R, (BD)+ = R i (CD)+ = CDE R. Rezult c AD i BD sunt chei ale lui R dar CD nu e cheie. Calculam o nou mulime de candidate pornind de la CD. Putem augmenta CD cu atribute din R (CD)+ = ABCDE CDE = AB. Nici una dintre augmentri nu este ns posibil pentru c att ACD cat i BCD conin o cheie gsit anterior (AD respectiv BD). Procesul se oprete. Singurele chei ale lui R rmn AD i BD.
4.3. Forme normale

Exist cteva seturi de condiii care ne arat c o schem de relaie este corect proiectat n sensul c ea nu permite apariia anomaliilor prezentate la nceputul capitolului. Dac schema ndeplinete cerinele unui anumit set de condiii se spune c este n form normal asociat acelui set. n continuare sunt prezentate formele normale Boyce-Codd i forma normal3. n finalul acestui capitol va fi prezentat i forma normal 4 care se definete n funcie de alt tip de dependene, i anume dependenele multivalorice.
Forma normal Boyce-Codd (FNBC)

Definiie: R o schem de relaie i F mulimea de dependene funcionale asociat. Se spune c R este n forma normal Boyce-Codd dac i numai dac oricare ar fi o dependen netrivial X Y din F atunci X este supercheie pentru R Rezult c o schem de relaie este n FNBC dac i numai dac fiecare dependen din F are n partea stng o supercheie. Nu este necesar ca F s fie n forma canonic dar nu trebuie s conin dependene triviale (obinute din prima axiom - de reflexivitate, de tipul AB A sau AB AB) Exemple: 1. Relaia R = ABCDE avnd F = { A B, B A , A C, D E } nu este n forma normal Boyce-Codd deoarece are cheile AD i BD dar nici o dependen nu are n partea stng o supercheie a lui R 2. Relaia Produse = IdP, NumeP, Qty, IdF avnd asociat mulimea de dependene funcionale FPRODUSE = PRODUSE(F) = { IdPNumeP, IdPQty, IdP IdF} este n forma normal Boyce-Codd: cheia unica a relaiei este IdP i toate dependenele au n partea stng o supercheie (aa cum s-a menionat orice cheie este n acelai timp i supercheie) 3. Relaia Produse = IdP, NumeP, Qty, IdF, NumeF, AdresaF avnd dependenele:
49
F = { IdPNumeP, IdPQty, IdP IdF, IdFNumeF, IdFAdresaF } nu este n forma normal Boyce-Codd: cheia unica este IdP dar exist dependene care nu au n partea stng o supercheie: IdFNumeF, IdFAdresaF
Forma normal 3 (FN3)

Pentru definiia formei normale 3 este necesar definirea noiunii de atribut prim: Definiie. R o schem de relaie i F mulimea de dependene funcionale asociat. Un atribut A R se numete atribut prim dac el aparine unei chei a lui R. Exemplu: R = ABCDE avnd F = { A B, B A , A C, D E }. Cum cheile relaiei sunt AD i BD rezult c n R sunt trei atribute prime: A, B i D. Definiie. R o schem de relaie i F mulimea de dependene funcionale asociat. Se spune c R este n forma normal 3 dac i numai dac oricare ar fi o dependen netrivial X A din F atunci X este supercheie pentru R sau A este atribut prim. De remarcat c dac n F avem dependene care conin mai multe atribute n partea dreapt putem aplica regula de descompunere pentru a obine dependene care n partea dreapt au cate un singur atribut. Observaie: Condiia de FNBC este inclus n definiia FN3. Din acest motiv orice relaie care este n FNBC este implicit i n FN3. Reciproca nu este adevrat.
FN3 FNBC
Rezult de asemenea c dac o schem de relaie nu este n FN3 ea nu poate fi nici n FNBC. Exemple: 1. Relaia R = ABCD avnd F = { AB C, AB D, D A } are cheia unic AB. Relaia este n FN3 deoarece primele dou dependene au n partea stng o supercheie (AB) iar a treia dependen are n partea dreapta atributul prim A. Relaia nu este n FNBC deoarece a treia dependen violeaz definiia pentru aceast form normal (nu are n partea stng o supercheie.
50
2. Relaia R = ABCDE avnd F = { A B, B A , A C, D E } are cheile AD i BD. Rezult c: R nu este n FN3 deoarece dependenele 3 i 4 nu au nici supercheie n partea stng nici atribut prim n partea dreapt R nu e n FNBC deoarece nu e n FN3 3. Relaia R = ABCD avnd F = { A B, B C, C D, D A } are cheile A, B, C i D. Rezult c: R este n FNBC deoarece n partea stng a dependenelor sunt numai superchei R este n FN3 deoarece este n FNBC
4.4. Descompunerea schemelor de relaii

Aa cum s-a menionat anterior, n cazul n care o relaie din baza de date nu este ntr-o form normal bun (FNBC, FN3) pot s apar diverse anomalii. Soluia este nlocuirea relaiei respective cu dou sau mai multe relaii care s conin aceleai informaii dar care, fiecare n parte, este n forma normal dorit de proiectant.
Definiia descompunerii unei scheme de relaie

Procesul prin care se sparge o relaie n mai multe relaii se numete descompunerea unei scheme de relaie. Formal putem defini acest concept astfel: Definiie: Fie R o schem de relaie, R = A1 A2 Am . Se spune c = (R1, R2, , Rn) este o descompunere a lui R dac i numai dac R = R1 R2 Rn Schemele R1, R2, , Rn conin deci atribute din R, fiecare atribut Ai al schemei iniiale trebuind s se regseasc n cel puin una dintre ele. Nu este necesar ca schemele s fie disjuncte (n practic ele au aproape ntotdeauna atribute comune). n exemplele de mai jos sunt prezentate cteva descompuneri valide ale unor scheme de relaii (unele ns incorecte din punct de vedere al pstrrii datelor i/sau dependenelor iniiale): Exemplul 1: Fie relaia R = ABCDE avnd F = { A B, B A , A C, D E }. Putem avea descompuneri ca: 1 = (ABC, DE), 2 = (ABCD, DE), 3 = (AB, CD, DE) Exemplul 2. Fie relaia Produse = IdP, NumeP, Qty, IdF, NumeF, AdresaF avnd dependenele funcionale: F = { IdPNumeP, IdPQty, IdP IdF, IdFNumeF, IdFAdresaF } Putem avea o multitudine de descompuneri printre care: 1 = ( (IdP, NumeP, Qty, IdF); (NumeF, AdresaF) ) 2 = ( (IdP, NumeP, Qty, IdF); (IdF, NumeF, AdresaF) ) 3 = ( (IdP, NumeP); (Qty, IdF); (NumeF, AdresaF) )
51
Descompunerea acioneaz deci la nivelul schemei relaiei. Ce se ntmpl ns cu coninutul acesteia n cazul unei descompuneri? Fiecare relaie rezultat va moteni o parte dintre datele relaiei descompuse i anume proiecia acesteia pe mulimea de atribute a relaiei rezultat din descompunere. S considerm o instan r a relaiei de schema R (instana unei relaii este o ncrcare cu date corecte a acesteia). Atunci instanele pentru relaiile din descompunerea sunt: ri = Ri (r)
Descompuneri cu join fr pierderi

Condiia pentru a nu se pierde date prin descompunere este ca relaia iniial s poat fi reconstruit exact prin joinul natural al relaiilor rezultate, fr tupluri n minus sau n plus. Formal, definiia este urmtoarea: Definiie: Fie R o schem de relaie, F mulimea de dependene funcionale asociat i o descompunere = (R1, R2, , Rn) a lui R. Se spune c este o descompunere cu join fr pierderi n raport cu F (prescurtat j.f.p.) dac i numai dac pentru orice instan r a lui R care satisface dependenele F avem c: r1 r2 rn = r unde ri = Ri (r) Faptul c o descompunere are sau nu aceast proprietate se poate testa pornind doar de la lista atributelor relaiei iniiale, lista atributelor relaiilor din descompunere i a mulimii de dependene funcionale asociat folosind urmtorul algoritm
Algoritm de testare a proprietii de j.f.p. pentru o descompunere

Intrare: Schema de relaie R = A1 A2 Am , mulimea de dependene funcionale F i o descompunere = (R1, R2, , Rn) Ieire: Verdictul dac are sau nu proprietatea j.f.p. Metoda: Se construiete o tabel avnd n linii i m coloane. Liniile sunt etichetate cu elementele descompunerii iar coloanele cu atributele relaiei R. Elementul (i,j) al tabelei va fi egal cu aj dac Aj Ri sau bij altfel. Se parcurg dependenele X Y din F. Daca dou (sau mai multe) linii din tabel au aceiai simboli pe coloanele X aceste linii se egaleaz i pe coloanele din Y astfel: Dac pe o coloan din Y apare un aj atunci toate elementele de pe acea coloan din liniile respective devin aj
52
Dac pe o coloan din Y nu apare nici un a j atunci se alege unul dintre elementele de tip bij i toate elementele de pe acea coloan din liniile respective devin egale cu acel bij Procesul se oprete: Fie cnd s-a obinut o linie n tabela care conine doar a-uri, caz n care descompunerea are proprietatea j.f.p. Fie cnd la o parcurgere a dependenelor nu mai apar schimbri n tabel i nu s-a obinut o linie doar cu a-uri. n acest caz descompunerea nu are proprietatea j.f.p.
n literatura de specialitate se poate gsi demonstraia faptului c acest algoritm determin corect dac o descompunere are proprietatea j.f.p. sau nu. Exemplu: Fie R = ABCDE, F = { C E (1), A C (2), B D (3), D E (4), E B (5) } (cu dependene numerotate ntre paranteze) i = (BCE, AB, ACD) A BCE AB ACD b11 a1 a1 B a2 a2 b32 a2 (5) C a3 b23 a3 (2) a3 D b14 b24 b14 (3) a4 E a5 b25 a5 (4) b35 a5 (1)
Prima trecere: Din C E b35 devine a5 Din A C b23 devine a3 Din B D b24 devine b14 Din D E b25 devine a5 Din E B b32 devine a2 Am obinut nc o linie doar cu a-uri. Descompunerea are proprietatea de j.f.p. Observaie: n cazul n care descompunerea are doar dou elemente se poate testa dac are proprietatea de join fr pierderi i astfel: Fie R o schem de relaie, F mulimea de dependene funcionale asociat i = (R1, R2) o descompunere a sa. Atunci are proprietatea de join fr pierderi dac una din dependenele urmtoare se poate deduce din F: (R1 R2) (R1 R2) sau (R1 R2) (R2 R1)
53
Pentru a testa dac dependena se poate deduce din F este suficient s calculm nchiderea lui (R1 R2). Daca ea conine fie pe (R1 R2) fie pe (R2 R1) atunci descompunerea este cu join fr pierderi. Exemplu: R= ABCDE, F = { A B, A C, A D, D E } i = (ABCD, DE). Avem R1 = ABCD, R2 = DE, (R1 R2) = ABCD DE = ABC (R2 R1) = DE ABCD = E (R1 R2) = D Cele dou dependene sunt: (R1 R2) (R1 R2) devine D ABC (R1 R2) (R2 R1) devine D E Ultima este chiar o dependen din F deci se poate deduce din F deci are proprietatea de join fr pierderi.
Descompuneri care pstreaz dependenele

O a doua problem n cazul descompunerii unei scheme de relaie R avnd dependenele F n mai multe relaii R1, R2, , Rn este aceea a pstrrii corelaiilor ntre date, corelaii date de dependenele funcionale din F. Fiecare relaie Ri va moteni o mulime de dependene dat de proiecia mulimii de dependene funcionale F pe Ri Fi = Ri(F) Exemplu: Fie relaia Produse = IdP, NumeP, Qty, IdF, NumeF, AdresaF avnd dependenele funcionale: F = { IdPNumeP, IdPQty, IdP IdF, IdFNumeF, IdFAdresaF } n cazul descompunerii 2 = (R1, R2) unde: R1 = (IdP, NumeP, Qty, IdF) R2 = (IdF, NumeF, AdresaF) cele dou relaii motenesc urmtoarele dependene: FR1 = R1(F) = { IdPNumeP, IdPQty, IdP IdF} FR2 = R2 (F) = { IdFNumeF, IdFAdresaF } Dup cum se observ toate dependenele relaiei iniiale sunt pstrate fie n FR1 fie n FR2. Exist ns i cazuri n care unele dependene din F nu mai pot fi regsite n mulimile de dependene asociate schemelor din descompunere i nu se pot deduce din acestea. n primul caz se spune c descompunerea pstreaz dependenele iar n al doilea c descompunerea nu pstreaz dependenele. O definiie formal a acestui concept este urmtoarea: Definiie: Fie R o schema de relaie, F mulimea de dependene funcionale asociat, o descompunere = (R1, R2, , Rn) a lui R i Fi = Ri(F) mulimile de dependene funcionale ale elementelor descompunerii. Se spune c pstreaz dependenele din F dac i numai dac orice dependena din F poate fi dedus din i=1..n (Fi ).
54
Rezult c o descompunere pstreaz dependenele dac i numai dac: F ( i=1..n (Fi ) )+ Din pcate att proiecia unei mulimi de dependene ct i incluziunea de mai sus implic un calcul de nchidere a unei mulimi de dependene (F i respectiv reuniunea mulimilor Fi). Exist i n acest caz un algoritm pentru a testa dac o dependen este sau nu pstrat dup descompunere fr a fi necesar efectiv calculul mulimilor Fi
Algoritm de testare a pstrrii dependenelor

Intrare: o schem de relaie R, mulimea de dependene funcionale asociat F i o descompunere = (R1, R2, , Rn) Ieire: verdictul dac pstreaz sau nu dependenele Metoda: Pentru fiecare dependen X Y din F se procedeaz astfel: Se pornete cu o mulime de atribute Z = X Se parcurg repetat elementele descompunerii . Pentru fiecare Ri se calculeaz o nou valoare a lui Z astfel: Z = Z ((Z Ri)+ Ri ) Procesul se oprete n momentul cnd Z rmne neschimbat la o parcurgere a elementelor Ri. Daca Y Z atunci dependena X Y este pstrat, altfel nu e pstrat. Dac toate dependenele din F sunt pstrate nseamn c pstreaz dependenele din F.
Algoritmi de descompunere
Algoritmii de testare al pstrrii dependenelor i a joinului fr pierderi pot fi aplicai atunci cnd descompunerea unei scheme de relaie se face de mn, pe baza experienei pe care o are proiectantul bazei de date. Exist ns i nite algoritmi simpli care, pornind de la o schem de relaie i mulimea de dependene funcionale asociat ne duc direct la o descompunere care este n FN3 sau FNBC i n plus au proprietatea de join fr pierderi (deci nu se pierd date prin descompunere) i/sau de pstrare a dependenelor. Algoritm de descompunere n FN3 cu pstrarea dependenelor Fie R o schem de relaie i F mulimea de dependene funcionale asociat, cu F = { X1 Y1, X2 Y2, Xn Yn } Atunci descompunerea = (X1Y1, X2Y2, XnYn) este o descompunere n FN3 cu pstrarea dependenelor. Se observ din definiia de mai sus a descompunerii c:
55
Toate dependenele sunt pstrate: dependena Xi Yi este n proiecia lui F pe XiYi Pentru a minimiza numrul de elemente din descompunere se aplic regula reuniunii: dac avem mai multe dependene care au aceeai parte stng le reunim ntr-una singur. Dac n descompunere exist dou elemente XiYi i XjYj astfel nct XiYi XjYj atunci XiYi se elimin.
n literatura de specialitate exist demonstraia faptului c fiecare schem din descompunere este n FN3. Exemplul 1: R = ABCDE, F = { A B, A C, A D, D E }. Rescriem prin reuniune mulimea de dependene funcionale: F = { A BCD, D E }. Rezult din algoritm descompunerea = (ABCD, DE) Algoritm de descompunere n FN3 cu pstrarea dependenelor i join fr pierderi Dac la descompunerea obinut prin algoritmul anterior adugm o cheie a relaiei (ca element al descompunerii) vom obine o descompunere care are att proprietatea de join fr pierderi cat i pe cea a pstrrii dependenelor. Observaie: Dac vreunul dintre elementele de forma XiYi conin deja o cheie a lui R atunci nu este necesar adugarea unui element suplimentar n descompunere. Algoritm de descompunere n FNBC cu join fr pierderi Fie R o schem de relaie i F mulimea de dependene funcionale asociat, F n form canonic: F = { X1 A1, X2 A2, Xn An }. Putem calcula descompunerea n FNBC cu join fr pierderi iterativ: Iniial = (R) La fiecare pas se alege o schem T care conine o dependen de forma XA care violeaz condiiile de FNBC. Schema respectiv este nlocuit n prin T1 i T2 unde T1 = XA i T2 = T {A} Procesul se oprete cnd n nu mai exist elemente care nu sunt n FNBC
4.5. Dependene multivalorice. Forma normal 4

Exist situaii n care, dei o relaie este n forma normal Boyce Codd, instanele sale conin date redundante. Acest fapt se datoreaz unei proiectri defectuoase n care n aceeai relaie sunt stocate date care aparin mai multor entiti i a cel puin dou asocieri multi-multi.
56
Sa lum exemplul tabelei urmtoare unde au fost stocate date referitoare la entitile PERSOANA, ADRESA i FACULTATE precum i asocierile dintre ele (multi-multi o persoan poate avea mai multe adrese i poate absolvi mai multe faculti): Nume Vasile Vasile Vasile Vasile Mariana Mariana Mariana Mariana Mariana Mariana Strada Viitorului Viitorului Dreapta Dreapta Revolutiei Revolutiei Revolutiei Calea Vitan Calea Vitan Calea Vitan Localitate Ploiesti Ploiesti Bucuresti Bucuresti Timisoara Timisoara Timisoara Bucuresti Bucuresti Bucuresti Facultate Automatica Comert Automatica Comert Constructii Drept Master ASE Constructii Drept Master ASE AnAbsolvire 2000 2004 2000 2004 1998 2003 2006 1998 2003 2006
Putem observa c nu exist nici o dependen funcional netrivial valid pentru aceasta relaie, deci nu exist dependene care s violeze condiiile FNBC. Ca urmare relaia este n FNBC avnd ca singur cheie posibil mulimea tuturor atributelor relaiei: din axioma de reflexivitate (A1) putem obine dependena: Nume,Strada,Localitate,Facultate,AnAbsolvire Nume,Strada,Localitate,Facultate,AnAbsolvire Dei relaia este n FNBC adresa i facultatea absolvit de un angajat sunt prezente repetat n relaie: adresa pentru fiecare facultate absolvit iar facultatea pentru fiecare adres a angajatului. Exemplul de mai sus sugereaz faptul c seturile de atribute {Strada, Localitate} i {Facultate, AnAbsolvire} sunt independente unele de altele, n sensul c fiecare adres apare cu fiecare facultate absolvit de un angajat i reciproc. Astfel de situaii sunt modelate cu un nou tip de dependene numite dependene multivalorice.
Dependene multivalorice (DMV)

Definitie: Fie o relaie R i dou mulimi de atribute X i Y incluse n R. Se spune c X multidetermin Y sau c exist dependena multivaloric X Y dac i numai dac ori de cate ori avem dou tupluri ale relaiei t1 i t2 cu t1[X] = t2[X] atunci exist n relaie un tuplu t3 pentru care: t3[X] = t1[X] = t2[X] t3[Y] = t1[Y] i t3[R-X-Y] = t2[R-X-Y]

X AAA AAA AAA Y BBB DDD BBB RXY CCC EEE EEE
57
t1 t2 t3
O consecin interesant a acestei definiii este c, dac inversm tuplurile t1 i t2, rezult c exist i un tuplu t4 pentru care t4[X] = t1[X] = t2[X] t4[Y] = t2[Y] i t4[R-X-Y] = t1[R-X-Y] Tot din aceast definiie rezult c dac n R exist dependena multivaloric X Y atunci exist i dependena X R X Y. Consecin important: orice dependen funcional este n acelai timp i o dependen multivaloric (se demonstreaz folosind definiia) ns reciproca nu este adevarat: exist dependene multivalorice pentru care n schema relaiei nu avem o dependen funcional corespunzatoare.
Forma normala 4
Pentru a prentampina redundanele prezentate la nceputul paragrafului este bine ca schemele de relaie s fie ntr-o form normal superioar FNBC. Aceast form care consider i dependenele multivalorice se numete forma normal 4 (FN4). Definiia ei este similar cu cea pentru FNBC dar condiia se pune pentru dependenele multivalorice ale relaiei respective: Definitie: O schem de relaie R este n forma normal 4 dac orice dependen multivaloric netrivial X Y are n partea stang o supercheie Dependenele multivalorice triviale sunt de dou feluri: 1. Dependene n care partea dreapt este inclus n partea stang: X Y unde Y X 2. Dependene de tipul X Y pentru care X Y = R Condiia de FN4 spune deci c orice DMV care nu intr n una din categoriile de mai sus are n partea stang o supercheie. Observatie importanta: Cheile relaiei (care definesc i supercheile sale) se determin doar pe baza dependenelor funcionale ale acesteia. Relatia dintre formele normale FN3, FNBC i FN4 este una de includere, n aceast ordine. Orice relaie n FN4 este n acelai timp i n FNBC i FN3:
58
FN3 FNBC
FN4
5. LIMBAJUL SQL
SQL este unul dintre cele mai folosite limbaje n dezvoltarea de aplicaii software, putnd fi folosit pentru manipularea datelor, dar i pentru crearea i administrarea obiectelor n baza de date. Limbajul are la baz conceptul bazelor de date relaionale, care a fost introdus pentru prima data de E.F. Codd n anii 70 i modeleaz bazele de date sub forma de tabele i relaii ntre acestea. IBM a fost prima companie care a preluat i dezvoltat acest concept, punnd la punct primul limbaj SQL (SEQUEL2) n anul 1976, ulterior dezvoltnd DB2 i SQL/DS. Inspirat din Algebra Relationala, modelul bazelor de date relaionale poate fi asemnat de utilizatori ca o colecie de tabele bidimensionale definite de urmtoarele concepte : - tabele - coloane - rnduri - cmpuri - operatori - relaii Modificarea datelor este realizat prin operaiile relaionale efectuate pe tabele, iar operatorii acioneaz asupra tabelelor pentru a produce noi relaii. Operatorii relaionali pot fi definii astfel : o Restricie - este o operaie care preia i afieaz toate rndurile din una sau mai multe tabele, sau doar rndurile care ndeplinesc una sau mai multe condiii (submulime orizontal). o Proiecie - este operaia care afieaz selectiv anumite coloane din una sau mai multe tabele (submulime vertical) o Produs - este rezultatul obinut prin concatenarea rndurilor a dou mulimi de date, conform condiiilor specificate. o Join - este rezultatul obinut prin concatenarea coloanelor din una sau mai multe tabele, conform condiiilor specificate. o Reuniune - este rezultatul obinut prin afiarea rndurilor comune i necomune din una sau mai multe tabele, conform condiiilor specificate. o Intersecie - este rezultatul obinut prin afiarea rndurilor comune din una sau mai multe tabele, conform condiiilor specificate.
60
BAZE DE DATE ON-LINE o Diferena - este rezultatul obinut prin afiarea rndurilor care aparin
numai unei singure tabele, conform condiiilor specificate. Controlul asupra bazelor de date este gestionat de ctre SGBD(Sistemul de Gestiune a Bazei de Date) i respect anumite reguli : - o baz de date relaional apare ca o colecie de tabele, definit de ctre utilizator; - utilizatorul nu controleaz felul cum este organizat fizic informaia; - controlul asupra fiierelor de date este gestionat exclusiv de ctre sistem; - utilizatorul poate defini anumii parametri de sistem pentru optimizarea aplicaiilor, sau pentru diferite setri; - accesul la baza de date este gestionat exclusiv de sistem, prin executarea de comenzi specifice; - rularea aplicaiilor, att pe server, ct i pe maina client, este gestionat exclusiv de ctre sistem. Structura unei tabele trebuie s respecte anumite reguli : - s nu existe duplicare de rnduri i coloane; - nu trebuie respectat o anumit ordine a rndurilor i coloanelor; - tipurile de coloane trebuie definite n concordan cu tipurile de date; - relaiile ntre tabele se fac pe coloane de acelai tip; - valorile sunt atomice(nedecompozabile).
5.1. Interogarea datelor

Cererile de interogare SQL folosesc n exclusivitate comanda SELECT, fiind utilizate att pentru interogarea obiectelor create de utilizator, ct i a celor sistem. Sintaxa comenzii este urmtoarea : SELECT [DISTINCT,ALL] [schema.table.]expresion expr_alias FROM [schema.table@dblink] table_alias [WHERE condition] [START WITH condition][CONNECT BY condition] [UNION,UNION ALL,INTERSECT,MINUS][SELECT command] [GROUP BY expresion][ HAVING condition] [ORDER BY expresion(position)] [ASC,DESC] [FOR UPDATE OF schema.table.column] [NOWAIT]; Parametrii comenzii au urmtoarea semnificaie( cei din paranteze sunt opionali): DISTINCT - returneaz numai o nregistrare, n cazul n care comanda gsete rnduri duplicate; ALL returneaz toate nregistrrile simple i duplicate ( selecteaz de asemenea toate coloanele tabelelor din clauza FROM);
Limbajul SQL
61
schema.table reprezint shema de identificare a tabelei(view-lui) specificat prin user.table_name; expresion reprezint un nume de coloan sau o expresie care poate folosi funcii sistem; expr_alias este un nume alocat unei expresii care va fi folosit n formatarea coloanei ( apare n antetul listei); dblink reprezint numele complet sau parial de identificare a unei baze de date (database.domain@connection_qualifier); table_alias este un nume alocat unei tabele(view) care poate fi folosit n cereri corelate; WHERE condition reprezint o clauz (nlnuire de condiii), care trebuie s fie ndeplinit n criteriul de selecie a nregistrrilor; START WITH condition stabilete criteriul de selecie pentru prima nregistrare; CONNECT BY condition stabilete o ierarhie de selecie a nregistrrilor; GROUP BY expresion stabilete criteriile de grupare a nregistrrilor(numele coloanelor folosite n criteriul de grupare); HAVING conditionrestricioneaz nregistrrile din grup la anumite condiii; UNION,UNION ALL,INTERSECT,MINUS combin rndurile selectate de mai multe comenzi SELECT prin aplicarea anumitor restricii; ORDER BY expresion(position) ordoneaz nregistrrile selectate dup coloanele din expresie, sau n ordinea coloanelor specificate prin poziie; FOR UPDATE OF face o blocare (lock) a nregistrrilor n vederea modificrii anumitor coloane; NOWAIT returneaz controlul userului, dac comanda ateapt eliberarea unei nregistrri blocat de un alt user.
5.2. Cereri simple

Sunt cereri care ntorc toate coloanele, sau anumite coloane i pot conine condiii de filtrare pe clauza where. De exemplu, cererea urmtoare returneaz toate coloanele i toate nregistrrile coninute de tabela angajati: SQL>SELECT * FROM angajati ;
ID_ANG NUME FUNCTIE ID_SEF DATA_ANG SAL COM ID_DEP
--------- ----------------7369 POPA ION 7499 TACHE IONUT
-------------TEHNICIAN PROGRAMATOR
--------- ------------7902 17-DEC-80 7698 20-FEB-81
-------- --------800 1450 300
-------20 30
Interogrile pot s returneaze calcule pe anumite coloane, ca n exemplul urmtor:
62

SQL>SELECT id_ang ecuson, nume, salariu*12+nvl(comision,0) venit_anual FROM angajati;
ECUSON --------7369 7499 NUME ----------------POPA ION TACHE IONUT VENIT_ANUAL ------------------9600 17700
5.3. Cereri cu clauza WHERE

Clauza WHERE poate compara valori de coloan, valori literale, expresii aritmetice (sau funcii ) i poate avea patru tipuri de parametri : - nume de coloan - operator de comparaie - operator de negaie - list de valori Operatorii de comparaie pot fi de dou feluri: * operatori logici Operator -------= > >= < <= * operatori SQL Operator -------BETWEEN..AND... IN( list ) LIKE IS NULL Semnificaie ---------------------------------ntre dou valori(inclusiv) compar cu o list de valori compar cu un model de tip caracter este o valoare nul Semnificaie ---------------egal cu mai mare dect mai mare sau egal mai mic dect mai mic sau egal
Operatorii de negaie pot fi de dou feluri: * operatori logici
Limbajul SQL
Operator -----------------!= ^= <> NOT NUMECOL = NOT NUMECOL > * operatori SQL Operator -------NOT BETWEEN NOT IN NOT LIKE IS NOT NULL Semnificaie ----------------------------------nu se afl ntre dou valori date nu se afl ntr-o list dat de valori diferit de un ir nu este o valoare nul Semnificaie -----------------------------diferit de(VAX,UNIX,PC) diferit de(IBM) diferit de(toate OS) diferit de mai mic sau egal
63
Dac vrem s facem o list cu toi angajaii, care au un anumit job, putem folosi urmtoarea cerere: SQL>SELECT id_dep depart, functie, nume, salariu, data_ang FROM angajati; WHERE functie=DIRECTOR ORDER BY id_dep;
DEPART FUNCTIE ---------------------10 DIRECTOR 20 DIRECTOR 30 DIRECTOR NUME SALARIU DATA_ANG --------------------------------------AVRAM CALIN 2450 09-JUN-81 STOICA DAN 2975 02-APR-81 NEGRU GELU 2850 01-MAY-81
Urmtoarea cerere face o list cu toate persoanele care s-au angajat ntr-o anumit perioad de timp: SQL>SELECT id_dep depart,functie, nume,data_ang FROM angajati WHERE data_ang BETWEEN 1-MAY-1981 AND 31-DEC-1981 ORDER BY data_ang; DEPART ------30 20 10 FUNCTIE --------------------DIRECTOR PROGRAMATOR TEHNICIAN NUME -------------------NEGRU GELU TANASE DOREL IONESCU VICTOR DATA_ANG ---------------01-MAY-81 08-SEP-81 03-DEC-81
64
Angajaii, care au ecusoane ntr-o list, pot fi listai cu urmtoarea cerere: SQL>SELECT id_ang ecuson, nume,functie, salariu+nvl(comision,0) venit FROM angajati WHERE id_ang IN (7499,7902,7876) ORDER BY nume; ECUSON -----------7876 7902 7499 NUME ----------------ADAM SORIN FLORESCU AUREL TACHE IONUT FUNCTIE ---------------TEHNICIAN ANALIST PROGRAMATOR VENIT --------1100 3000 1750
Folosind operatorul LIKE asociat cu doua simboluri, este posibil s selectm rndurile care se potrivesc cu un ir sau subir de caractere. Cele dou simboluri sunt : Simbol Semnificaie --------------------------------------------------% orice secven de mai multe caractere un singur caracter Lista persoanelor angajate n luna decembrie 1980 se obine cu urmtoarea cerere: SQL>SELECT id_ang ecuson, nume, functie, data_ang FROM angajati WHERE data_ang LIKE %DEC-1980; ECUSON ---------7369 7902 NUME FUNCTIE ----------------------------------POPA ION TEHNICIAN FLORESCU AUREL ANALIST DATA_ANG ----------------17-DEC-80 03-DEC-80
Dac se compar o coloan, sau expresie cu NULL, atunci operatorul de comparaie trebuie s fie IS sau IS NOT NULL. Dac se folosete orice alt operator, rezultatul va fi ntotdeauna FALSE (de exemplu expresia COMM != NULL este ntotdeauna fals). Operatorii AND i OR pot fi utilizai pentru a compune expresii logice cu condiii multiple. Predicatul AND este adevrat, numai dac ambele condiii sunt TRUE, iar predicatul OR este adevrat dac cel puin una din condiii este TRUE. Se pot combina AND sau OR n acceai expresie logic n clauza WHERE, iar n acest caz, operatorii AND sunt evaluai primii i apoi operatorii OR (deci operatorii AND au o preceden mai mare decat OR). n exemplul urmtor, vor fi selectai toi directorii care au salariul peste 1500 $ i toi tehnicienii(fr condiia de salariu):
Limbajul SQL
SQL>SELECT id_ang ecuson,nume,functie,salariu,id_dep depart FROM angajati WHERE salariu > 1500 AND functie = 'DIRECTOR' OR functie = 'TEHNICIAN ORDER BY functie; ECUSON -----7566 7698 7782 7369 7876 NUME ----------------STOICA DAN NEGRU GELU AVRAM CALIN POPA ION ADAM SORIN FUNCTIE SALARIU ------------------- --------DIRECTOR 2975 DIRECTOR 2850 DIRECTOR 2450 TEHNICIAN 800 TEHNICIAN 1100 DEPART --------20 30 10 20 20
65
Dac operatorii au preceden egal, atunci ei se evalueaz de la stanga la dreapta. Precedena operatorilor logici este urmtoarea: 1. Operatorii de comparaie i operatorii SQL au precedena egal: =, >= , <>, BETWEEN...AND, IN, LIKE, IS NULL. 2. NOT 3. AND 4. OR Pentru a fi siguri de ordinea de execuie a dou operaii, se recomand folosirea parantezelor rotunde.
5.4. Metode de JOIN

Pentru extragerea datelor din mai multe tabele din baza de date, cererea SELECT folosete una sau mai multe metode de JOIN. Sintaxa pentru un join simplu este urmtoarea: SELECT [DISTINCT,ALL] [table].column expr_alias FROM [schema.table1] table1_alias, [schema.table2] table2_alias, WHERE table1_alias.colum= table2_alias.colum ORDER BY expresion(position)] [ASC,DESC]; Parametrii comenzii au urmtoarea semnificaie( cei dintre paranteze sunt opionali): DISTINCT - returneaz numai o nregistrare n cazul n care comanda gasete rnduri duplicate ALL returneaz toate nregistrrile simple i duplicate ( selecteaz de asemenea toate coloanele tabelelor din clauza FROM)
66
schema.table reprezint shema de identificare a tabelei(view-lui) specificat prin user.table_name expr_alias este un nume alocat unei expresei care va fi folosit n formatarea coloanei ( apare n antetul listei) table_alias este un nume alocat unei tabele(view) care va fi folosit n cereri corelate WHERE condition reprezint o clauz (nlnuire de condiii) care trebuie s fie ndeplinit n criteriul de selecie a nregistrrilor ORDER BY expresion(position) ordoneaz nregistrrile selectate dup coloanele din expresie, sau n ordinea coloanelor specificate prin poziie.
5.5. Equi-join i Non Equi-join

Dac n condiia de join, apar numai egaliti, avem de-a face cu un equi-join. Pentru a putea s realizm un join pe mai multe tablele, este obligatoriu ca ele s conin coloane de acelai tip cu date comune sau corelate. S lum un exemplu simplu pentru a arta cum funcioneaz un join. Pentru a lista angajaii dintr-un departament, folosim tabela angajati, ns n aceast tabel gsim asociat fiecrui angajat un id_dep, iar denumirea departamentului respectiv o gsim n tabela departamente, deci se impune un join ntre cele dou tabele, pentru ca n list s apar i denumirea departamentului. SQL>SELECT a.id_dep ,b.den_dep departament,a.nume,a.functie FROM angajati a, departamente b WHERE a.id_dep=b.id_dep and a.id_dep=10; ID_DEP DEPARTAMENT NUME -----------------------------------------10 MARKETING AVRAM CALIN 10 MARKETING COSTESCU GEORGE 10 MARKETING MILESCU SILVIU FUNCTIE ----------------DIRECTOR PRESEDINTE TEHNICIAN
Se observ c au fost folosite alias-uri pentru tabele, pentru a nu crea ambiguitate cnd referim coloane cu aceeai denumire. Cnd dou sau mai multe tabele nu au coloane comune i trebuie totui relaionate, avem un non equi-join. Sunt situaii cnd trebuie s folosim i equi-join i non equi-join ntr-o cerere . n exemplul anterior, dac dorim s listm numele angajailor, gradul de salarizare i denumirea departamentului 20 din care fac parte, va trebui s facem join dup trei tabele: SQL>SELECT c.den_dep,a.nume, a.salariu, b.grad
Limbajul SQL
FROM angajati a, grila_salar b, departamente c WHERE a.salariu BETWEEN b.nivel_inf AND b.nivel_sup AND a.id_dep=c.id_dep AND a.id_dep=20; DEN_DEP -----------------------------CONTABILITATE CONTABILITATE NUME SALARIU ---------------------------POPA ION 800 ADAM SORIN 1100 GRAD -------1 2
67
5.6. Joinul unei tabele cu ea nsi

Sunt situaii cnd avem nevoie s extragem date corelate din aceeai tabel. De exemplu, dac dorim s afim care sunt efii angajailor, trebuie s extragem din tabel angajati i numele efului (id_sef). SQL>SELECT a.nume nume_ang, a.functie functie_ang, b.nume nume_sef, b.functie functie_sef FROM angajati a, angajati b WHERE a.id_sef=b.id_ang AND a.id_dep=10;
NUME_ANG ----------------MILESCU SILVIU AVRAM CALIN FUNCTIE_ANG NUME_SEF -----------------------------------------TEHNICIAN AVRAM CALIN DIRECTOR COSTESCU GEORGE FUNCTIE_SEF ------------------DIRECTOR PRESEDINTE
5.7. Join extern

Folosind equi-join putem selecta toate nregistrrile care ndeplinesc condiiile din clauza WHERE. Apar situaii cnd cererea trebuie s selecteze i nregistrri care nu ndeplinesc toate condiiile din clauz. Un exemplu ar fi s construim structura organizatoric a firmei selectnd toate departamentele i angajaii care fac parte din fiecare departament. Exist, n tabela departamente, departamentul 40 care nu are niciun angajat i folosind equi-join acesta nu apare n list. Pentru a depi situaia, se folosete un join extern (+), aa cum se vede n exemplul urmtor. SQL>SELECT a.id_dep,a.den_dep,b.nume,b.functie FROM departamente a, angajati b WHERE a.id_dep=b.id_dep(+);
68

NUME FUNCTIE ------------------------------------------AVRAM CALIN DIRECTOR COSTESCU GEORGE PRESEDINTE POPA ION TEHNICIAN STOICA DAN DIRECTOR NEGRU GELU DIRECTOR
ID_DEP DEN_DEP --------- -----------------------------10 MARKETING 10 MARKETING 20 CONTABILITATE 20 CONTABILITATE 30 PROIECTARE 40 VANZARI
5.8. Join vertical

Join-ul vertical este folosit pentru concatenarea rezultatelor mai multor cereri SELECT i folosete operatorii UNION (reuniune), INTERSECT (intersecie), MINUS (diferen). n acest caz, join-ul se face dup coloane de acelai tip, nu dup rnduri, de aceea se mai numete i vertical. S dm cteva exemple, pentru a arta modul de utilizare a acestor operatori n construcia unei cereri de interogare. Dac dorim lista angajailor din departamentele 10 si 30, se poate utiliza cererea urmtoare: SQL> SELECT id_dep,nume,functie,salariu FROM angajati WHERE id_dep=10 UNION SELECT id_dep,nume,functie,salariu FROM angajati WHERE id_dep=30; Trebuie reinut c reuniunea se poate face pe coloane declarate de acelai tip (number, varchar, date), chiar dac au semnificaii diferite. S construim o cerere care reunete pe aceeai coloan salariile angajailor din departamentul 10 i cu comisioanele celor din departamentul 30. SQL>SELECT id_dep, nume, functie, 'are salariu' salar_com, salariu sal_com FROM angajati WHERE id_dep=10 UNION SELECT id_dep, nume, functie, 'are comision ', comision FROM angajati WHERE id_dep=30; ID_DEP NUME ---------------------10 AVRAM CALIN 10 COSTESCU GEORGE FUNCTIE SALAR_COM SAL_COM ----------------------------- --------DIRECTOR are salariu = 2450 PRESEDINTE are salariu = 5000
Limbajul SQL
10 30 MILESCU SILVIU IONESCU VICTOR TEHNICIAN TEHNICIAN are salariu = are comision =
69 1300 500
Folosind operatorul UNION ALL se selecteaz i nregistrrile duplicate: SQL>SELECT functie FROM angajati WHERE id_dep=10 UNION ALL SELECT functie FROM angajati WHERE id_dep=20; Operatorul INTERSECT este folosit pentru a selecta nregistrrile comune. Dac dorim s aflm care sunt funciile angajailor care au primit acelai comision i care se regsesc n toate departamentele, scriem urmtoarea cerere: SQL> SELECT functie, comision FROM angajati where id_dep=10 INTERSECT SELECT functie,comision FROM angajati where id_dep=20 INTERSECT SELECT functie,comision FROM angajati where id_dep=30 Pentru a afla care sunt funciile din departamentul 10, care nu se regsesc n departamentul 30, folosim operatorul MINUS : SQL> SELECT functie FROM angajati WHERE id_dep = 10 MINUS SELECT functie FROM angajati WHERE id_dep = 30; FUNCTIE ------------------PRESEDINTE
5.9. Funcii n SQL

Funcia poate fi vazut ca un operator de manipulare a datelor, care ntoarce un rezultat. Funciile accept unul sau mai multe argumente (constant , variabil sau o referire de coloan ) i ntorc o valoare. Sintaxa pentru funcie este urmtoarea: function_name(arg1, arg2,...) Rolul lor este de a face mai puternice cererile SQL i se pot folosi pentru: - efectuarea calculelor numerice - prelucrare de iruri de caractere - prelucrarea datei calendaristice - schimbarea formatului datelor pentru afiare
70

- conversia tipurilor de date n funcie de specificul lor, se pot mpri n urmtoarele tipuri: * * * * * * Funcii numerice Funcii pentru iruri Funcii pentru data calendaristic Funcii de conversie Funcii diverse ( care accept orice tip de argumente) Funcii de grup
Funcii numerice
Aceste funcii accept la intrare valori numerice i returneaz tot o valoare numeric. ABS (n) returneaz valoarea absolut a lui n SQL> SELECT abs(-12) FROM dual; -- returneaz valoarea 12 CEIL (n) returneaz cel mai mic ntreg >= n SQL> SELECT ceil(14.7) FROM dual; -- returneaz valoarea 15 COS (n) returneaz cosinus (n) unde n este n radiani SQL> SELECT cos(180 * 3.14/180) FROM dual; -- returneaz -1 COSH (n) returneaz cosinus hiperbolic SQL> SELECT cosh(0) FROM dual; -- returneaz valoarea 1 EXP (n) returneaz e la puterea n (e=2.7182..) SQL> SELECT exp(4) FROM dual; -- returneaz valoarea 54.5981 FLOOR (n) returneaz cel mai mare ntreg <= n SQL> SELECT floor(11.6) FROM dual; -- returneaz valoarea 11 LN (n) returneaz logaritmul natural al lui n (n>0) SQL> SELECT ln(95) FROM dual; -- returneaz valoarea 4.5538 LOG (m,n) returneaz logaritmul n baza m al lui n SQL> SELECT log(10,100) FROM dual; -- returneaz valoarea 2 MOD (m,n) returneaz restul mpririi lui m la n SQL> SELECT mod(14,5) FROM dual; -- returneaz valoarea 4 POWER (m,n) returneaz m la puterea n SQL> SELECT power(3,2) FROM dual; -- returneaz valoarea 9 ROUND (n[,m]) returneaz n rotunjit la : m zecimale dac m>0 0 zecimale dac m este omis m cifre nainte de virgul dac m<0 SQL> SELECT round(15.193, 1) FROM dual; -- returneaz 15.2 SQL> SELECT round(15.193) FROM dual; -- returneaz 15 SQL> SELECT round(15.193, -1) FROM dual; -- returneaz 20 SIGN (n) returneaz -1 dac n<0, 0 dac n=0 i 1 dac n>0 SQL> SELECT sign(-17.5) FROM dual; -- returneaz valoarea -1 SIN (n) returneaz sinus (n), unde n este n radiani SQL> SELECT sin(30 * 3.14/180) FROM dual; -- returneaz 0.5
Limbajul SQL
SINH (n) returneaz cosinus hiperbolic SQL> SELECT sinh(1) FROM dual; -- returneaz valoarea 1.1752 SQRT (n) returneaz rdcina ptrat a lui n, unde n>0 SQL> SELECT sqrt(26) FROM dual; -- returneaz valoarea 5.099 TAN (n) returneaz tangenta lui n , unde n este n radiani SQL> SELECT tan(135 * 3.14/180) FROM dual; -- returneaz -1 TAN (n) returneaz tangenta hiberbolic a lui n , unde n este n radiani SQL> SELECT tanh( 0.5) FROM dual; -- returneaz 0.4621 TRUNC (n[,m]) returneaz n trunchiat la : m zecimale dac m>0 0 zecimale dac m este omis m cifre nainte de virgula, dac m<0 SQL> SELECT trunc(15.193, 1) FROM dual; -- returneaz 15.1 SQL> SELECT trunc(15.193) FROM dual; -- returneaz 15 SQL> SELECT trunc(15.193, -1) FROM dual; -- returneaz 10
71
Funcii pentru iruri

Aceste funcii accept la intrare valori alfanumerice i returneaz o valoare numeric, sau tot o valoare alfanumeric. Cele care returneaz valori de tip VARCHAR2, pot avea lungimea maxim 2000 caractere, iar cele de tip CHAR pot avea lungimea maxim de 255 caractere. CHR (n) returneaz caracterul care are reprezentarea binar n SQL> SELECT chr( 75) FROM dual; -- returneaz valoarea K CONCAT (char1,char2) returneaz concatenarea lui char1 cu char2 SQL> SELECT concat(concat(nume, este ),functie) nume_functie FROM angajati WHERE id_ang=7839; NUME_FUNCTIE -------------------------------------------------------COSTESCU GEORGE este PRESEDINTE INITCAP (char) returneaz char cu majuscule SQL> SELECT initcap(popescu mihai) FROM dual; -- returneaz Popescu Mihai REPLACE (string,string1,[string2]) nlocuiete n string caracterele din string1 cu caracterele din string2 SQL> SELECT replace(JACK si JUE,J,BL) FROM dual; -- returneaz valoarea BLACK si BLUE RPAD (char1,n,[char2]) adaug la dreapta lui char1 caracterele char2 pn la lungimea n SQL> SELECT rpad(nume,20,'*') completare_nume FROM angajati WHERE id_dep=10; COMPLETARE_NUME ----------------------------------
72 AVRAM CALIN* * * * ***** COSTESCU GEORGE***** MILESCU SILVIU* * * * * *
RTRIM (char[,set]) terge din char ultimele caractere dac sunt n set SQL> SELECT rtrim('Popescu','scu') FROM dual; -- returneaz Pope SUBSTR (char,m[,n]) returneaz n caractere din char, ncepnd cu poziia m SQL> SELECT substr (Popescu ,2,3) FROM dual; -- returneaz ope INSTR (char1,char2[,n[,m]]) returneaz poziia lui char2, ncepnd cu poziia n la a m-a apariie SQL> SELECT instr(Protopopescu,op,3,2) FROM dual; --returneaz 7 LENGTH (char) returneaz lungimea lui char ca numr de caractere SQL> SELECT length(analyst) FROM dual; - returneaz 7
Funcii pentru dat calendaristic

Datele calendaristice pot fi stocate n urmtorul format intern: Secol / An / Luna / Ziua / Ora / Minut / Secunda Formatul implicit de afiare sau intrare pentru o dat calendaristic este DDMON-YY. Plaja datei calendaristice este ntre 1-JAN-4712 i.e.n i 31-DEC4712 e.n. Toate funciile de tip dat calendaristic ntorc o valoare de tip DATE cu excepia lui MONTHS_BETWEEN, care ntoarce o valoare numeric. ADD_MONTHS (date,n) returneaz o dat prin adaugarea a n luni la date; SQL>SELECT nume,data_ang,add_months(data_ang,3) data_mod FROM angajati WHERE id_dep=10; NUME DATA_ANG ----------------------------------------AVRAM CALIN 09-JUN-81 COSTESCU GEORGE 17-NOV-81 DATA_MOD ----------------09-SEP-81 17-FEB-82
LAST_DAY (date) returneaz data ultimei zile din luna cuprins n date; SQL>SELECT nume,data_ang,last_day(data_ang) ultima_zi FROM angajati WHERE id_dep=10; NUME DATA_ANG ----------------------------------------AVRAM CALIN 09-JUN-81 COSTESCU GEORGE 17-NOV-81 ULTIMA_ZI ----------------30-JUN-81 30-NOV-81
Limbajul SQL
73
MONTHS_BETWEEN(date1,date2) returneaz numrul de luni (i fraciuni de lun ) cuprinse ntre date1 i date2. Dac date1>date2 rezultatul va fi pozitiv, altfel va fi negativ. SQL>SELECTnume,data_ang,sysdate, months_between(sysdate,data_ang) luni_vechime FROM angajati WHERE id_dep=10; NUME SYSDATE DATA_ANG LUNI_VECHIME ------------------------------ -------------- ---------------------AVRAM CALIN 18-NOV-06 09-JUN-81 305.30665 COSTESCU GEORGE 18-NOV-06 17-NOV-81 300.04858 ROUND(date,fmt) returneaz data prin rotunjirea lui date la formatul fmt; SQL>SELECT round(to_date(17-NOV-2010), YEAR) rot_an FROM dual; ROT_AN --------------01-JAN-2010 TRUNC(date,fmt) returneaz data prin trunchierea lui date la formatul fmt; SQL>SELECT trunc(to_date(17-NOV-2010), YEAR) trunc_an FROM dual; TRUNC_AN -------------01-JAN-2010 SYSDATE returneaz data curent(data sistem) n diferite formate; SQL>SELECT to_date(sysdate,DD-MM-YYYY hh:MI:SS AM) data_crt FROM dual; DATA_CRT --------------18-APR-2011
74
BAZE DE DATE ON-LINE Funcii de conversie

Aceste funcii fac conversia unui tip de dat n alt tip de dat.
TO_CHAR(date[,fmt[,nlsparams]]) face conversia unei date de tip DATE n format VARCHAR2; SQL> SELECT nume, to_char(data_ang, 'Month DD, YYYY') data_ang FROM angajati WHERE to_char(data_ang,'YYYY') LIKE '1987'; NUME ----------------SAVESCU OVIDIU ADAM SORIN DATA_ANG -----------------April 19, 1987 May 23, 1987
TO_DATE(char[,fmt[,nlsparams]]) face conversia unei variabile de tip CHAR sau VARCHAR2 n format DATE; SQL> SELECT to_date(15112010 ,DD-MON- YYYY) data FROM dual; DATA ----------15-NOV-2010 TO_NUMBER(char[,fmt[,nlsparams]]) face conversia unei variabile de tip CHAR sau VARCHAR2 n format NUMBER; Pentru calculul primei n funcie de anul angajrii, folosim comanda: SQL> SELECT nume, functie, salariu, salariu+to_number(to_char(data_ang,'yyyy'))/10 prima FROM angajati WHERE to_number(to_char(data_ang ,'YYYY'))=1987; NUME FUNCTIE SALARIU ----------------------------------- -----------SAVESCU OVIDIU ANALIST 3000 ADAM SORIN TEHNICIAN 1100 PRIMA ---------3198.7 1298.7
Formatul pentru numere poate fi : Format Semnificaie Exemple ----------- ----------------------------------------------------- -------------------------
Limbajul SQL
9 0 $ . , MI PR EEEE V B
75
numere(nr.de 9 determin lungimea de afiare) 999999 1234 afieaz zerourile de la nceput 099999 001234 semnul dolar $999999 $1234 punct zecimal 99999.99 1234.00 virgula 999,999 1,234 semnele minus la dreapta(valori negative) 999999MI 1234paranteze pentru numere negative 999999PR <112> notaie tiinific 99.999EEEE 1.23E+03 nmulire cu 10 (n=numr de 9 dup V) 9999V99 123400 afieaz valori zero ca blancuri nu 0 B9999.99 1234.00
Funcii diverse
Aceste funcii accept orice tip de argumente. GREATEST(expr1 [,expr2]...) returneaz cea mai mare valoare din lista de argumente; SQL> SELECT greatest(12,34,77,89) from dual; GREATEST(12,34,77,89) -------------------------------89 LEAST(expr1 [,expr2]...) returneaz cea mai mica valoare din lista de argumente; DECODE(expr,search1,result1,...default) - expr este comparat cu fiecare valoare search i ntoarce rezult dac expr este egal cu valoarea search, iar dac nu gsete nicio egalitate, ntoarce valoarea default; Funcia DECODE este considerat cea mai puternic funcie SQL, deoarece are efectul unui case sau a unei construcii if-then-else. Tipurile de parametri pot fi : * expression poate fi orice tip de dat * search este de acelai tip ca expression * result este valoarea ntoars i poate fi orice tip de dat * default este de acelai tip ca expression n exemplul urmtor, se calculeaz prima n raport de funcia angajatului: SQL> SELECT nume,functie,salariu, decode(functie,'DIRECTOR',salariu*1.25,'ANALIST', salariu*1.15,salariu/4) prima FROM angajati WHERE id_dep=20
76 ORDER BY functie;
NUME FUNCTIE SALARIU PRIMA ---------------------------------- ------------- --------SAVESCU OVIDIU ANALIST 3000 3450 FLORESCU AUREL ANALIST 3000 3450 STOICA DAN DIRECTOR 2975 3718.75 NVL(expr1 ,expr2) returneaz expr2 dac expr1 este null SQL>SELECT nume,data_ang,comision,nvl(comision,0) nvl_com FROM angajati WHERE id_dep=30 ORDER BY nume; NUME ----------------------------IONESCU VICTOR MARINESCU MIHAI DATA_ANG COMISION ---------------- ---------------03-DEC-1981 22-FEB-1981 500 NVL_COM --------------0 500
Funcii de grup
Aceste funcii returneaz rezultate bazate pe grupuri de nregistrri, nu pe o singur nregistrare, ca cele prezentate la punctele anterioare. Gruparea se face folosind clauza GROUP BY ntr-o cerere SELECT i n acest caz toate elementele listei trebuie cuprinse n clauza de grupare. Funciile de grup pot fi apelate i n clauza HAVING, dar nu pot fi apelate n clauza WHERE. Se poate folosi operatorul DISTINCT pentru a sorta numai elementele distincte din lista, dar se poate folosi i operatorul ALL pentru a considera i nregistrrile duplicate. AVG([DISTINCT/ALL] expr) returneaz valoarea medie a lui expr, ignornd valorile nule; Pentru a afla valoarea medie a salariului i comisionului pe toate departamentele, folosim urmtoarea cerere: SQL> SELECT avg(salariu),avg(comision) FROM angajati; AVG(SALARIU) AVG(COMISION) -------------------------------------------2062.5 550 Dac dorim s aflm valorile medii pe fiecare departament, trebuie s folosim obligatoriu clauza GROUP BY: SQL>SELECT id_dep,avg(salariu),avg(comision) FROM angajati GROUP BY id_dep;
Limbajul SQL
ID_DEP AVG(SALARIU) AVG(COMISION) ----------------------------------------10 2916.6667 30 1541.6667 550
77
COUNT(* | [DISTINCT/ALL] expr) returneaz numrul de nregistrri ntoarse de interogare. Dac se fosete *, se numr toate nregistrrile, inclusiv cele nule, iar dac se folosete expr, se numr numai nregistrrile not null; Pentru a afla numrul angajailor care au primit comision pe fiecare departament, folosim urmtoarea cerere: SQL> SELECT id_dep,count(*),count(comision), count(all comision),count(distinct comision) FROM angajati GROUP BY id_dep;
ID_DEP COUNT(*) COUNT(COMISION) COUNT(ALLCOMISION) COUNT(DISTINCTCOMISION)
-----------------------------------10 3 0 20 5 0 30 6 4
--------------0 0 4
-----------------0 0 4
MAX([DISTINCT/ALL] expr) returneaz valoarea maxima pentru expresie; Pentru a afla salariul maxim pe fiecare departament, folosim cererea: SQL> SELECT a.id_dep,b.den_dep,max(salariu) FROM angajati a,departamente b WHERE a.id_dep=b.id_dep GROUP BY a.id_dep,b.den_dep; ID_DEP DEN_DEP -----------------------------------10 MARKETING 20 CONTABILITATE MAX(SALARIU) ----------------------5000 3000
MIN([DISTINCT/ALL] expr) - returneaz valoarea minim pentru expresie Pentru a afla care este venitul minim pe fiecare departament, folosim cererea: SQL> SELECT id_dep, min(salariu + nvl(comision,0)) venit_minim
78 FROM angajati GROUP BY id_dep; ID_DEP VENIT_MINIM -------------------------10 1300 20 800 30 950
Trebuie menionat c operatorii DISTINCT i ALL nu au niciun efect pentru funciile MIN i MAX. SUM([DISTINCT/ALL] expr) returneaz suma valorilor pentru expresie Pentru a calcula suma salariilor i comisioanelor pe fiecare departament, folosim cererea: SQL> SELECT id_dep,sum(salariu), sum(distinct salariu), sum(comision) FROM angajati GROUP BY id_dep;
ID_DEP SUM(SALARIU) SUM(DISTINCTSALARIU) SUM(COMISION) -------------------------------------- ------------10 8750 8750 20 10875 7875 30 9250 8000 2200
5.10. Subcereri SQL

Subcererile sunt cereri SQL incluse n clauzele SELECT, FROM, WHERE, HAVING sau ORDER BY ale altei cereri numite i cerere principal. Rezultatele ntoarse de o subcerere sunt folosite de o alt subcerere sau de cererea principal n situaii cum ar fi: - crearea de tabele sau view-uri. - inserarea, modificarea i tergerea nregistrrilor din tabele.
- n furnizarea valorilor pentru condiii puse n comenzile SELECT, UPDATE, DELETE, INSERT i CREATE TABLE.
Din punct de vedere al rolului pe care l au ntr-o cerere SQL i a modului de a face construcia comenzii, subcererile pot fi mprite n : * Subcereri ascunse * Subcereri corelate * Subcereri pe tabela temporar * Subcereri pe clauza HAVING
Limbajul SQL
* Subcereri pe clauza SELECT * Subcereri pe clauza ORDER BY Sintaxa unei subcereri este: SELECT expr 1,... expr n FROM table 1 WHERE (expr 1,...expr k) IN [NOT IN] ( SELECT expr 1, ...expr k FROM table 2 WHERE table 2.expr x = table 1.expr y [AND,OR] .. );
79
Subcereri ascunse
Subcererile ascunse pot fi mprite n mai multe categorii, n funcie de numrul de coloane sau linii pe care le returneaz: * Subcereri care ntorc o valoare * Subcereri care ntorc o coloan * Subcereri care ntorc o linie * Subcereri care ntorc mai multe linii Dac vrem s aflm salariile angajailor, care au funcii similare funciilor aferente departamentului 20, folosim urmtoarea cerere : SQL>SELECT nume,functie,salariu FROM angajati WHERE functie IN (SELECT DISTINCT functie FROM angajati WHERE id_dep=20); NUME ----------------SAVESCU OVIDIU STOICA DAN FUNCTIE SALARIU -----------------------ANALIST 3000 DIRECTOR 2975
Subcereri corelate
Subcererile corelate se execut o dat pentru fiecare linie candidat, prelucrat de cererea principal i la execuie folosesc cel puin o valoare dintr-o coloan din cererea principal. O subcerere corelat se join-eaz cu cererea exterioar prin folosirea unei coloane a cererii exterioare, n clauza predicatului cererii interioare. n cazul unei subcereri ascunse, cererea SELECT din subcerere ruleaz prima i se execut o singur dat, ntorcnd valori ce vor fi folosite de cererea principal. Pentru o cerere corelat, subcererea se execut de mai multe ori, cte o dat pentru fiecare linie prelucrat de cererea principal, deci cererea interioar este condus de cererea exterioar.
80

Paii de execuie ai unei subcereri corelate sunt: - se obine linia candidat prin procesarea cererii exterioare; - se execut cererea interioar corelat cu valoarea liniei candidat; - se folosesc valorile rezultate din cererea interioar pentru a prelucra linia candidat; - se repet pn nu mai rmne nicio linie candidat.
Trebuie specificat c, dei subcererea corelat se execut repetat, aceasta nu nseamn c subcererile corelate sunt mai puin eficiente dect subcererile ascunse.
Dac vrem s aflm persoanele care au salariul peste valoarea medie salariului pe departamentul din care fac parte, folosim cererea urmtoare: SQL> SELECT a.id_dep,a.nume,a.functie,a.salariu FROM angajati a WHERE a.salariu > (SELECT avg(salariu) salariu_mediu FROM angajati b WHERE b.id_dep=a.id_dep ) ORDER By id_dep; ID_DEP NUME ---------------------10 COSTESCU GEORGE 20 STOICA DAN 30 NEGRU GELU FUNCTIE SALARIU --------------------------PRESEDINTE 5000 DIRECTOR 2975 DIRECTOR 2850
Cererea principal proceseaz fiecare linie din tabela angajai i pstreaz toi angajaii care au salariul peste salariul mediu pe departamentul respectiv returnat de subcerere, care se coreleaz cu cererea principal prin condiia din clauza WHERE. n acest caz, se folosete un join pe aceeai tabel. Cnd folosim subcereri, trebuie respectate cteva reguli, cum ar fi: - cererea interioar trebuie s fie inclus ntre paranteze i trebuie s fie n partea dreapt a condiiei; - expresiile din lista de expresii a subcererii trebuie s fie n aceeai ordine ca cele din lista din clauza WHERE a cererii principale( avnd acelai tip i numr de expresii ); - subcererile nu pot fi ordonate, deci nu conin clauza ORDER BY; - clauza ORDER BY apare la sfritul cererii principale; - subcererile sunt executate de la cea mai adnc imbricare pna la nivelul principal de imbricare(cu excepia cererilor corelate); - subcererile pot folosi funcii de grup i clauza GROUP BY ; - subcererile pot fi nlnuite cu predicate multiple AND sau OR n aceeai cerere extern; - n subcereri se pot folosi operatori de mulimi; - subcererile pot fi imbricate pn la nivelul 255.
Limbajul SQL Subcereri pe clauza HAVING

Aceste subcereri sunt prinse n clauza HAVING ntr-o construcie ca cea de mai jos : SELECT expr 1,... expr n FROM table 1 WHERE conditions HAVING expr, (operator) ( SELECT expr 1, ...expr k FROM table 2 WHERE conditions ) GROUP BY expresion; Trebuie reinut c o clauz HAVING se folosete ntotdeauna mpreun cu clauza GROUP BY i ntr-o clauz HAVING se pot folosi funcii de grup. Pentru a afla ce departamente au cei mai muli angajai pe aceeai funcie, folosim urmtoarea cerere: SQL>SELECT d.den_dep, a.functie,count(a.id_ang) nr_ang FROM angajati a, departamente d WHERE a.id_dep = d.id_dep HAVING count(a.id_ang) = (SELECT max(count(id_ang)) FROM angajati GROUP BY id_dep, functie) GROUP BY d.den_dep, a.functie; DEN_DEP -----------------------------PROIECTARE FUNCTIE NR_ANG -------------------------------PROGRAMATOR 4
81
5.11. Crearea i definirea stucturilor tabelare

Comenzile pentru crearea i definirea de structuri tabelare sunt comenzi de definire a datelor (Data Definition Language DDL) i permit crearea dar i relaionarea lor intr-o baz de date. Structura unei tabele este dat de urmatoarele specificaii de definire: * definirea coloanelor * definirea constrngerilor de integritate * definirea tablespace-lui unde se creeaz * definirea parametrilor
82
BAZE DE DATE ON-LINE Crearea unei tabele
Sintaxa comenzii de creare este urmatoarea (parametrii din paranteze sunt optionali): CREATE TABLE [schema.] table_name [table_constraint] column datatype [ DEFAULT expr ][ column_constraints] [ table_constraints ][ TABLESPACE tablespace] [ storage parameters ] [ ENABLE/DISABLE clause] [ AS subquery ] unde : schema este schema unde se creeaz tabela (specific userul i baza de date) table_name este numele tabelei column este numele coloanei datatype reprezinta tipul coloanei DEFAULT expr specific valoarea implicit a coloanei column_constraints defineste constrngerile de integritate pentru coloana table_constraints - definete constrngerile de integritate la nivel de tabela tablespace specifica n ce tablespace al bazei de date se creeaz tabela storage parameters definete parametrii de creare i pot fi: PCTFREE procentaj de spaiu rezervat pentru update PCTUSED procentaj minim folosit pentru un bloc de date INITRANS numarul initial de tranzactii pentru fiecare bloc(1-255) MAXTRANS- numarul maxim de tranzacii concurente (1-255) CLUSTER specific daca tabela face parte dintr-un cluster ENABLE/DISABLE clause activare/dezactivare de constrngeri AS subquery inserare de date dintr-o alta tabela obtinute printr-o interogare Tipurile de date care pot fi asociate coloanelor unei tabele pot fi : * tipuri numerice * tipuri alfanumerice * tipuri pentru data calendaristic i timp * tipuri compuse ( matrice sau tabela) Cateva dintre cele mai uzuale tipuri sunt: NUMBER numr real de dimensiune variabil (maxim 38 cifre) NUMBER(n) numr intreg de n cifre NUMBER(n,m) numr real de n cifre din care m zecimale CHAR(n) ir de caractere de lungime fix n ( 1- 2000 ) NCHAR(n) analog cu CHAR dar poate stoca iruri de caractere nationale VARCHAR2(n) sir de caractere de lungime variabil n ( 1- 4000) NVARCHAR2(n) analog cu VARCHAR dar poate stoca iruri de caractere LONG sir de caractere de maxim 2 la puterea 31 octeti
Limbajul SQL
LONG RAW similar cu LONG dar conine date binare ROWID poate stoca identificatorul unei linii din tabel DATE data calendaristic TIMESTAMP(n) extensie pentru tipul DATE i conine i fraciuni de secunda pe n zecimale
83
Cnd se creeaz o tabela trebuie respectate anumite reguli, cum ar fi : - userul trebuie s aib drept de creare de tabele ( privilegiul CREATE TABLE); - numele tabelei trebuie s fie unic n contul n care se creeaz i nu este case sensitive; - numele trebuie s aib maxim 30 caractere continue, sa inceap cu o litera i s nu fie cuvant rezervat ; - o tabela poate fi creat oricnd dar nu poate fi alterat cnd este accesat de un alt user; - la creare nu este necesar sa se specifice dimensiunea tabelei dar trebuie estimat ce spaiu va ocupa n tablespace; - structurile tabelelor pot fi modificate i ulterior (prin adaugare sau tergere de coloane, constrngeri, indeci, e.t.c.); - dac dimensiunea iniial este insuficient i se aloca automat mai mult spaiu n limita tablespace-lui ( care la randul lui poate fi extins cu un nou data_file); - clauza DEFAULT poate conine constante numerice, ir de caractere , functii (inclusiv sysdate i user) dar nu poate contine numele unei alte coloane sau pseudocoloane); - valoarea DEFAULT este luat n considerare n cazul inserrii unei linii n care nu se specific nimic n legtura cu coloana respectiv. S crem o tabela pentru evidena admiterii la facultate : SQL>CREATE TABLE studenti (facultate char(30) DEFAULT 'Automatica si Calculatoare', catedra char(20), cnp number(13), nume varchar2(30), data_nastere date, an_univ number(4) DEFAULT 2011, media_admitere number(5,2) , discip_oblig varchar2(20) DEFAULT 'Matematica', discip_opt varchar2(20) DEFAULT 'Fizica' , operator DEFAULT user, data_op DEFAULT sysdate );
84
n cazul inserrii unei linii, valorile campurilor operator i data operare nu trebuie specificate deoarece sunt preluate cu funciile de sistem user i sysdate.
5.12. Constrngeri de integritate

Constrngerile de integritate sunt anumite reguli care trebuie respectate la nivel de tabela sau n relaiile cu alte tabele. Aceste reguli sunt verificate automat n cazul operaiilor de inserare, tergere si modificare i n cazul n care nu se valideaz se genereaz o eroare i tranzacia nu se efectueaz. Constrngerile de integritate pot fi : * NOT NULL inregistrarile nu pot conine valori nule * UNIQUE definete o cheie unic pe una sau mai multe coloane ( nu pot fi mai multe inregistrri cu aceleai valori pe coloanele respective) * PRIMARY KEY definete o cheie primar la nivel de coloan sau tabela ( nu pot fi mai multe inregistrri cu aceeai cheie primar). * FOREIGN KEY defineste o cheie extern ( tabela se relaioneaz cu alt tabela pe o cheie unic sau cheie primar) * CHECK foreaz o condiie pe coloan Trebuie specificate cateva caracteristici ale constrngerilor de integritate : - fiecare constrngere va avea un nume dat de user sau generat de sistem; - constrngerile pot fi activate sau dezactivate cu comanda ALTER TABLE; - constrngerile pot fi adugate sau sterse si ulterior crerii tabelei; - informaiile legate de constrngeri se pastreaz n dicionarul de date.
Constrngerea NOT NULL

Se aplica numai la nivel de coloane i verific dac inregistrrile au valori nule pe coloanele respective, forand un cod de eroare care anuleaz tranzacia. Cnd se creeaz constrngeri pe o cheie primar se creeaz automat i o costrangere NOT NULL pe coloanele respective ( o cheie primar nu trebuie s conin valori nule pe coloanele care o definesc). Sintaxa la nivel de coloana este : column [ CONSTRAINT constraint_name ] NOT NULL S crem o tabel pentru tipuri de funcii: SQL>CREATE TABLE functii ( cod_functie number(2) CONSTRAINT NL NOT NULL,
Limbajul SQL
den_functie varchar2(20) NOT NULL, data_vigoare date );
85
Funcionalitatea coloanelor cod_functie i den_functie este aceeai (nu accept valori nule) dar consructia constrngerii pentru cod_functie permite activarea sau dezactivarea lui NL.
Constrngerea UNIQUE
Se folosete cnd vrem ca o coloan sau perechi de coloane s nu conin valori duplicate. Verificarea se face numai pentru inregistrari cu valori nenule deoarece constrngerea permite inserarea de valori nule n coloanele respective. n mod automat se creeaz i un index pe coloanele definite chei unice, ceea ce duce la marirea vitezei de interogare pe tabel. Sintaxa la nivel de coloan este: column [ CONSTRAINT constraint_name ] UNIQUE iar la nivel de tabela este: [, CONSTRAINT constraint_name ] UNIQUE (col1, col 2,..) Sa cream tabela funcii definind unicitate pe anumite coloane: SQL>CREATE TABLE functii ( cod_functie number(2) CONSTRAINT UK_FUN UNIQUE, den_functie varchar2(20) UNIQUE, data_vigoare date ) ; Putem s facem i urmatoarea construcie la nivel de tabel: SQL>CREATE TABLE functii ( cod_functie number(2), den_functie varchar2(20), data_vigoare date, CONSTRAINT UK_FUN UNIQUE (cod_functie,den_functie) ); n prima consructie putem insera oricate inregistrari cu valori nule pe coloanele definite unice dar n construcia a doua nu putem sa inseram inregistrari cu una din coloane nul i cealalt sa nu respecte unicitatea.
Constrngerea PRIMARY KEY

Se folosete pentru definirea cheii primare la nivel de coloana (cnd cheia conine o singur coloan) sau la nivel de tabel ( cnd cheia este compus pe mai multe coloane). O tabel poate avea o singur cheie primar i nu accepta valori nule pentru nicio coloan care o definesc. Cnd se creeaza o cheie primar se creeaz n mod automat i un index pentru a scurta timpul de rspuns n cazul unei interogri.
86
Sintaxa la nivel de coloan este column [ CONSTRAINT constraint_name ] PRIMARY KEY iar la nivel de tabel [, CONSTRAINT constraint_name ] PRIMARY KEY (col1, col 2,..) Dac vrem s crem un nomenclator de funcii n care fiecare funcie sa aib cod unic folosim urmatoarea construcie: SQL>CREATE TABLE functii ( cod_functie number(2) CONSTRAINT PK PRIMARY KEY, den_functie varchar2(20), data_vigoare date ); Dac dorim ca un cod de funcie s poat fi utilizat de mai multe ori trebuie s definim cheia pe mai multe coloane, de exemplu pe codul funciei i data la care intr n vigoare codificarea. SQL>CREATE TABLE functii ( cod_functie number(2) , den_functie varchar2(20), data_vigoare date, CONSTRAINT PK_FUN PRIMARY KEY (cod_functie,data_vigoare));
Constrngerea FOREIGN KEY

Acest tip de constrngere se foloseste pentru relaionarea unei tabele cu una sau mai multe tabele, verificnd dac valorile coninute n coloanele definite de FOREIGN KEY ( cheie strain sau cheie extern) sunt cuprinse n valorile coloanelor altei tabele care trebuie s fie definite UNIQUE sau PRIMARY KEY. Mai exact, o relaionare pe cheie extern se poate face numai pe o cheie primar sau unic . Sintaxa la nivel de coloan este: column [ CONSTRAINT constraint_name ] REFERENCES table(column) [ ON DELETE CASCADE|ON DELETE SET NULL ] iar la nivel de tabel este: column [ CONSTRAINT constraint_name ] FOREIGN KEY ( col1, col2, ...) REFERENCES table(col1, col2, ..) [ ON DELETE CASCADE|ON DELETE SET NULL ]
Limbajul SQL
87
Pentru a se putea face relaionarea trebuie ca tabela funcii s aib cheie primar sau unic pe coloana den_functie iar tabela departamente sa aib cheie primar sau unic pe coloana id_dep. Se observ c tabela este relaionat cu ea insi dup coloanele id_sef si id_ang. O constructie la nivel de tabel arat astfel: SQL>CREATE TABLE angajati ( id_ang number(4) PRIMARY KEY, nume varchar2(30), functie varchar2(20) REFERENCES functii(den_functie), id_sef number(4) REFERENCES angajati(id_ang), data_ang date, salariu number(7,2), comision number(7,2), id_dep number(2) , CONSTRAINT FK_ANG FOREIGN KEY (id_dep) REFERENCES departamente(id_dep) ); Cnd se face relaionarea intre doua tabele trebuie avute n vedere urmatoarele reguli de functionare : - inserarea unei linii intr-o tabel relaionat (pe care am definit FOREIGN KEY) nu se poate face dac nu exist decat o singur linie; - n tabela de referin ( n care am definit PRIMARY KEY sau UNIQUE) corespunzator coloanelor de relaionare; - tergerea unei linii din tabela de referin nu se poate face atta timp cat exist linii relaionate pe linia respectiv n tabela relaionat; - regulile de mai sus sunt valabile i n cazul relaionrii pe coloane. Pentru a putea sa tergem totui linii n tabela de referin, chiar daca sunt relaionate din alte tabele, se poate folosi optiunea ON DELETE CASCADE i n acest caz atunci cnd se terge o linie n tabel de referin se vor terge toate liniile din tabelele relaionate care sunt n relaie cu linia respectiv. n cazul unei tabele relaionat cu ea insi, cnd se terge o linie care este referit, toate coloanele devin nule n liniile relaionate. De exemplu, n tabela angajai, dac se folosete opiunea ON DELETE CASCADE, cnd se terge o linie aferent unui ef, la toi angajaii care au eful respectiv se va face nul coloana id_sef. Cnd se folosete opiunea ON DELETE SET NULL, atunci cnd se terge o linie din tabela de referina toate coloanele de relaie din tabela relaionat vor deveni nule, deci nu vor fi terse liniile relaionate.
88
5.13. Comanda ALTER TABLE

Este una dintre cele mai folosite comenzi deoarece, de multe ori, structura unei tabele trebuie modificat pentru adugarea sau tergerea de coloane, modificarea dimensiunilor coloanelor, renunarea la anumite constrngeri de integritate sau adaugarea altora noi, e.t.c. Sintaxa comenzii este urmtoarea : ALTER TABLE [schema.] table_name ADD( column datatype ) [DEFAULT expr] ( column_constraints ) ( table_constraints ) MODIFY( column datatype ) [DEFAULT expr] ( column_constraints ) DROP drop_clause ENABLE enable_clause DISABLE disable_clause ALLOCATE EXTENT SIZE integer [K,M] DATAFILE filename INSTANCE integer [ storage parameters ] unde : schema este schema unde este creat tabela (specific userul i baza de date) table_name este numele tabelei column este numele coloanei datatype reprezint tipul coloanei DEFAULT expr specific valoarea implicita a coloanei column_constraints definete constrngerile de integritate pentru coloana table_constraints - defineste constrngerile de integritate la nivel de tabela tablespace specifica n ce tablespace al bazei de date se creeaz tabela drop_clause definete o constrngere care va fi tears enable_clause definete o constrngere care va fi activat disable_clause definete o constrngere care va fi dezactivat storage parameters definete parametrii care vor fi modificai si pot fi: PCTFREE procentaj de spaiu rezervat pentru update PCTUSED procentaj minim folosit pentru un bloc de date INITRANS numarul initial de tranzacii pentru fiecare bloc(1-255) MAXTRANS- numarul maxim de tranzacii concurente (1-255) CLUSTER specific daca tabela face parte dintr-un cluster Adugarea unei noi coloane intr-o tabel: SQL>ALTER TABLE departamente ADD ( interfon number(3) NOT NULL);
Limbajul SQL
Stergerea unei coloane dintr-o tabel: SQL>ALTER TABLE departamente DROP COLUMN interfon;
89
Modificarea dimensiunii unei coloane (pentru descreterea dimensiunilor tabela trebuie sa fie goal sau coloanele de modificat s conin valori nule): SQL> ALTER TABLE departamente MODIFY ( telefon varchar2(12) ); Adugarea unei noi constrngeri: SQL>ALTER TABLE departamente ADD CONSTRAINT UK_DEN UNIQUE (den_dep); Stergerea unei constrngeri: SQL>ALTER TABLE departamente DROP CONSTRAINT UK_DEN; Dezactivarea unei constrngeri: SQL>ALTER TABLE departamente DISABLE CONSTRAINT UK_DEN; Marcarea unei coloane ca neutilizabil: SQL>ALTER TABLE departamente SET UNUSED (interfon);
5.14. Comanda INSERT

Aceast comand este folosit pentru inserarea de linii ntr-o tabel i are urmtoarea sintax: INSERT INTO [schema.] table_name[view_name][@dblink] [column 1, column 2, ....] VALUES (expr1, expr2. ....) subquery unde : schema este schema unde este creat tabela (specifica userul si baza de date) table_name este numele tabelei view_name este numele unui view creat pe tabela column este numele coloanei expr reprezint valoarea aferent coloanei subquery este o subcerere care returneaz linii cu date din una sau mai multe tabele
90
S facem o inserare complet (toate coloanele au valori nenule) n tabela intrari_gestiune. n acest caz nu trebuie s specificm numele coloanelor dar valorile trebuie specificate n clauza VALUES n ordinea de creare a coloanelor n tabel. SQL> INSERT INTO intrari_gestiune VALUES(999,'12-DEC-2010',33,2,1,124.50); Dac facem inserri numai n anumite coloane comanda arat astfel: SQL>INSERT INTO iesiri_gestiune (NR_DOC_OUT,DATA_DOC_OUT,COD_PRODUS, CANT_OUT,COD_UM) VALUES(777,'15-DEC-2010',333,10,2);
5.15. Comanda DELETE

Este folosit pentru stergerea liniilor dintr-o tabel sau view i are urmtoarea sintax: DELETE FROM [schema.] table_name[view_name][@dblink] WHERE condition (column1,column2, ..) IN [ NOT IN] subquery unde : schema este schema unde este creat tabela (specific userul i baza de date) table_name este numele tabelei condition condiia care trebuie indeplinit pentru liniile terse column este numele coloanei subquery este o subcerere care returneaz linii cu date din una sau mai multe tabele Pentru a terge toate liniile din tabel de stocuri folosim comanda: SQL>DELETE FROM stocuri_gestiune; Pentru a sterge toate stocurile calculate n luna noiembrie folosim comanda: SQL>DELETE FROM stocuri_gestiune WHERE data_stoc LIKE '%NOV%';
Limbajul SQL
91
5.16. Comanda UPDATE

Este folosit pentru actualizarea datelor n baza de date i are urmtoarea sintax: UPDATE [schema.] table_name[view_name][@dblink] SET column=expr column=subquery (column1,column2,...) IN [NOT IN] subquery WHERE condition unde : schema este schema unde este creat tabela (specifica userul i baza de date) table_name este numele tabelei column este numele coloanei condition condiia care trebuie indeplinit pentru modificarea liniilor subquery este o subcerere care returneaz linii cu date din una sau mai multe tabele n absena clauzei WHERE toate liniile vor fi actualizate, aa cum se vede n exemplul urmtor n care toate preurile unitare vor fi indexate cu 10%. SQL>UPDATE intrari_gestiune SET pret_unitar=pret_unitar*1.1; Dac dorim actualizarea preurilor numai pentru anumite produse, vom folosi comanda urmtoare: SQL>UPDATE intrari_gestiune SET pret_unitar=pret_unitar*1.1 WHERE cod_produs IN (11,12); Cnd se face actualizarea datelor ntr-o tabel se verifica automat i constrngerile de integritate definite pe tabela respectiv, altfel comanda genereaz un cod de eroare i tranzacia eueaz. Situaiile n care pot aprea erori sunt: - noile valori fac duplicare de cheie primar sau unic; - actualizarea valorii cu o valoare nul cnd coloana este NOT NULL; - valorile noi nu respect o constrngere CHECK; - valorile noi nu respect o constrngere FOREIGN KEY; - valorile vechi erau referite de alte tabele printr-o constrngere FOREIGN KEY;
- subcererea returneaz mai multe nregistrri.
6. TRANZACII I ACCES CONCURENT

Aa cum s-a exemplificat n primul capitol, atunci cnd mai multe programe opereaz simultan pe aceleasi date pot s apar situaii n care coninutul bazei de date devine inconsistent: dac paii aceluiai program de rezervare de locuri rulat de la dou agenii de voiaj diferite sunt ca n tabelul de mai jos, dei se rezerv dou locuri numarul de locuri disponibile scade cu doar o unitate: Moment de timp Agentia 1 Agentia 2 A n BD t1 READ A 10 t2 READ A 10 t3 A=A1 10 t4 A=A-1 10 t5 WRITE A 9 t6 WRITE A 9 n cazul accesului la aceleai date se spune c execuiile programelor respective sunt concurente sau c exist un acces concurent la date. Scopul acestui capitol este de a studia modalitile de evitare a inconsistenelor precum i a problemelor ridicate de mecanismele folosite pentru aceasta.
6.1. Prezentarea problematicii. Terminologie

a. Tranzacie Noiunea de tranzacie va fi rafinat n paragrafele urmtoare. Definiia urmtoare este doar una de lucru pentru nelegerea celorlali termeni din acest paragraf. Definiie: O tranzacie este o singur execuie a unui program. n exemplul anterior exist dou tranzacii, T1 i T2, care sunt dou execuii ale aceluiai program. n general pot fi 2 sau mai multe tranzacii care ruleaz simultan i fiecare poate fi execuia unui alt program. b. Articol (al unei baze de date) Definiie: Un articol este o poriune a bazei de date care se poate citi sau scrie sau bloca/debloca printr-o singur operaie de READ, WRITE, LOCK respectiv UNLOCK. n exemplul anterior am folosit articolele simbolice (articolul era A). n cazurile reale un articol poate fi: O ntreag tabel
Tranzacii i acces concurent
93
Orice alt poriune a bazei de date care ndeplinete condiia din definiie n concordan cu facilitile puse la dispoziie de SGBD-ul respectiv. De exemplu sistemul Oracle blocheaz automat orice linie afectat de o comanda de tip UPDATE, INSERT i DELETE pn cnd tranzacia care a efectuat operaia fie comite modificrile (le face permanente n baza de date) fie le revoc. n acest caz articolele sunt deci linii ale tabelei actualizate. c. Planificare Definiie: O planificare reprezint ordinea n care sunt executai de SGBD paii elementari ai unui set de tranzacii. Tabela de la inceputul acestui capitol este o vizualizare a unei planificari. Planificarea este deci o lista de pai pentru un set de tranzacii care se execut concurent i arat c SGBD-ul execut aceti pai n exact acea ordine. n acest capitol vom reprezenta doar paii care semnific o interaciune a tranzaciei cu datele din baza de date: READ (citirea unui articol), WRITE (scrierea unui articol), LOCK (n diversele sale forme blocarea unui articol) i UNLOCK (deblocarea unui articol). Pentru cazurile n care operaiile de scriere nu devin permanente n baza de date dect dup comitere putem avea i pai de tip COMMIT (comiterea modificrilor efectuate de o tranzacie) sau ROLLBACK (revocarea modificrilor efectuate de o tranzacie). d. Planificare serial Definiie: O planificare n care paii fiecarei tranzacii sunt succesivi, fr s fie intercalai pai ai altor tranzacii se numete planificare serial. e. Blocarea articolelor Definiie: Blocarea unui articol de catre o tranzacie semnific faptul c acea tranzacie obine din partea sistemului (SGBD) anumite drepturi speciale de acces care mpiedic alte tranzacii s efectueze anumite operaii asupra acelui articol. Exist dou categorii de blocri: Blocri exclusive: celelalte tranzacii nu pot s execute operaii asupra articolului blocat. Aceste blocri sunt denumite n literatura de specialitate i Exclusive Locks sau Write Locks. Blocri partajate: celelalte tranzacii pot s execute doar anumite tipuri de operaii asupra articolului blocat. Aceste blocri sunt denumite n literatura de specialitate i Shared Locks sau Read Locks.
O linie (sau o multime de linii) dintr-o tabel O celul dintr-o tabel (valoarea pe o linie i o coloan a tabelei)
6.2. Gestiunea tranzaciilor

n paragraful anterior tranzacia era definit ca o execuie a unui program. n fapt un program care interacioneaz cu o baz de date conine de obicei nu o singura tranzacie ci o succesiune de tranzacii care nu se intersecteaz, fiecare
94
dintre ele fiind finalizata fie prin comiterea modificrilor efectuate (ele devin definitive n baza de date) fie prin revocarea lor (modificrile sunt anulate). Dup terminarea unei tranzacii celelalte operaii asupra bazei de date aparin tranzaciilor urmatoare. Cum singurele operaii care sunt importante din punct de vedere al interaciunii dintre program i sistemul de gestiune sunt cele de citire/scriere i cele conexe (blocare, deblocare, comitere i revocare) putem defini o tranzacie i ca o succesiune de operaii de acest tip.
ACID
Pentru ca o tranzacie s fie bine definit ea trebuie s indeplineasca nite criterii de corectitudine care au fost sintetizate prin abrevierea ACID. Aceasta semnific: A Atomicitate C Consisten I Izolare D Durabilitate. Atomicitate O tranzacie trebuie s fie atomic n sensul c fie toate modificrile efectuate de ea n baza de date sunt comise fie sunt toate revocate. Exemplu: Sa luam o tranzacier care este o succesiune de actualizari n SQL care insereaz, actualizeaz i sterg linii din dou tabele STUD i SPEC:
INSERT INTO STUD UPDATE SPEC DELETE FROM STUD
Aceste modificri trebuie ori comise ori revocate impreuna. Faptul c de exemplu doar inserarea i stergerea sunt comise i nu i actualizarea este o ncalcare a acestei reguli. Sistemul de gestiune este cel care trebuie s pun la dispoziie mecanismele prin care s se asigura atomicitatea tranzaciilor inclusiv n cazul unor incidente hardware i software care pot interveni n timpul execuiei unei tranzacii. Consistena O tranzacie care ncepe s lucreze pe o baza de date consistent trebuie s o lase la final tot ntr-o stare consistent. n acest sens o tranzacie nu poate ncalca restriciile existente la nivelul bazei de date. n cele mai multe cazuri aceste restricii sunt modelate sub forma constrngerilor de integritate (NOT NULL, PRIMARY KEY, etc). Dac o tranzacie conine o operaie care violeaz o constrngere de integritate atunci toate modificrile efectuate de tranzacie vor fi revocate. Mecanismele de pstrare a consistenei trebuie asigurate de SGBD.
95
Izolare O tranzacie trebuie s se comporte ca i cnd operaiile efectuate de ea sunt izolate, independente de operaiile efectuate de alt tranzacie. Nici o alt tranzacie nu trebuie s citeasca date intermediare scrise de tranzacia respectiv. De exemplu dac o tranzacie contine succesiunea de operaii:
READ (A) A = A + 1 WRITE (A) READ (B) B = B - 1 WRITE (B) -- citeste valoarea veche a lui A: 5 -- scrie valoarea noua a lui A:6 -- citeste valoarea veche a lui B:10 -- scrie valoarea noua a lui B:9
Atunci nici o alt tranzacie nu poate citi pentru A i B dou valori dintre care una este actualizat i cealalt nu (adica 6 pentru A i 10 pentru B). Inconsistenele prezentate n paragraful anterior erau datorate nclcrii acestui criteriu de corectitudine. Din punct de vedere al modului de asigurare a izolarii tranzaciilor tot sistemul de gestiune trebuie s asigure mecanismele necesare. Izolarea este obiectul controlului accesului concurent, prezentat n paragrafele urmatoare. Durabilitate O dat comise cu succes modificrile efectuate de o tranzacie ele vor persista i nu mai pot fi revocate. Inclusiv n cazul unui incident hardware i software efectele tranzaciilor comise sunt regsite la recuperarea dup incident. Din acest punct de vedere fiecare sistem de gestiune trebuie s conina mecanisme prin care efectele tuturor tranzaciilor comise s fie nregistrate i n jurnalele sistemului pentru a fi restaurate n caz de incident.
6.3. Serializabilitate
Aa cum s-a specificat planificrile seriale nu duc la inconsistene. n practic ns n cazul unor sisteme ncrcate planificrile conin pai intercalai ai diverselor tranzacii. Rezultatul va fi totusi corect dac efectul execuiei planificrii respective este acelai cu al uneia dintre planificrile seriale posibile ale acelorasi tranzacii. O astfel de planificare se numeste planificare serializabil.
Planificri serializabile
Definiie: O planificare este serializabil dac produce aceleai efecte n baza de date cu o planificare serial. Exemplu: O planificare serializabil i planificarea serial echivalent:
96
Planificare serializabil:
T1 READ A READ B READ C READ D WRITE A WRITE C READ A WRITE A T2 T3
Planificare serial echivalent (se putea i T1, T2, T3):

T1 T2 T3 READ C READ D WRITE C READ A READ B WRITE A READ A WRITE A
Planificri conflict-serializabile
Exista i o alt abordare a serializabilitii bazat pe conflictele care pot s apar ntre paii a dou tranzacii dintr-o planificare. Definiie: ntre dou operaii aparinnd unei planificri exist un conflict dac: Aparin unor tranzacii diferite Sunt pe acelai obiect Una dintre operaii este o scriere Cele dou operaii sunt succesive n sensul c ntre ele nu exist o operaie cu care vreuna dintre ele este n conflict. Rezult c exista 3 tipuri de situaii conflictuale: Fiind date dou tranzacii T1 i T2 pot exista conflicte de tipurile R1-W2, W1-W2 i W1-R2. Definiie: Doua planificri sunt conflict-echivalente dac: Conin aceleai operaii ale acelorai tranzacii Fiecare pereche de operaii conflictuale apare n aceeai ordine n cele dou planificri. Aceasta definiie nu spune c nu pot s apar anomalii n execuia celor dou planificari ci c apar aceleai anomalii n ambele. Definiie: O planificare este conflict-serializabil dac este conflictechivalent cu o planificare serial. Observaie: Reformulnd putem spune c o planificare este conflictserializabil dac poate fi transformat ntr-o planificare serial prin interschimbri ale operaiilor consecutive care nu sunt n conflict din dou tranzacii.
Planificari v-serializabile (view-serializability)

Exista de asemenea o a treia abordare (mai slaba) a serializabilitii:
97
Definiie: Doua planificri S1 i S2 sunt v-echivalente dac pentru orice articol A: 1. Dac Ti citete valoarea iniiala a lui A n S1 atunci ea face acelai lucru i n S2. 2. Dac Ti citete o valoare a lui A scrisa de Tj n S1, atunci face acelai lucru i n S2. 3. Daca Ti scrie valoarea final a lui A n S1 atunci ea face acelai lucru i n S2 Definiie: O Planificare este v-serializabil dac este v-echivalent cu o planificare serial. Incluziunea ntre diverse tipuri de planificari este urmatoarea:
Serializabile v-serializabile ConflictPlanificari Seriale serializabile Fara rollback n cascada
6.4. Asigurarea consistentei la citire

Pentru exemplificarea consistenei la citire vom considera cazul sistemului de gestiune Oracle. Acesta implementeaz mecanisme care i permit fiecrui utilizator (uman sau aplicaie care utilizeaz baza de date) s aib n orice moment o viziune consistent a datelor.
Consistena la citire i blocri implicite

n mod curent pe aceeai baz de date opereaz simultan mai muli utilizatori care pot efectua dou tipuri de operaii: Operaii de citire. n aceast categorie intr n principal regsirile de date prin cereri SELECT.
98
Operaii de scriere. n aceast categorie sunt operaiile de INSERT, UPDATE, i DELETE.
Execuia simultan a unei operaii de scriere cu o alt operaie (de citire sau de scriere) poate duce la inconsistene n utilizarea bazei de date. O astfel de situaie este evitat n Oracle prin mecanismele de consisten la citire: Aceleai date pot fi citite simultan de orici utilizatori, Aceleai date nu pot fi modificate simultan de doi utilizatori. n momentul n care unul din ei modific o valoare, sistemul efectueaz o blocare implicit a liniei care o conine blocnd accesul pentru scriere al altor utilizatori. Aceleai date pot fi modificate la un moment dat de un utilizator i citite de orici alii, Modificrile fcute de un utilizator n coninutul tabelelor nu sunt vizibile pentru ceilali utilizatori pn n momentul n care se execut implicit sau explicit nscrierea lor permanent n baza de date (pn la comitere). Pn la comiterea modificrilor, operaiile de citire efectuate de ali utilizatori returneaz coninutul de date anterior modificrii lor, Pn nu au fost comise, modificrile pot fi revocate, anulndu-se efectul cererilor care le-au efectuat, n momentul comiterii sau revocrii modificrilor se ridic toate blocrile aferente acestora, n acest fel operaiile de citire i modificare a datelor se pot executa simultan fr s interfereze unele cu celelalte. De asemenea sunt prevenite inconsistenele care pot apare la modificarea simultan a acelorai date.
6.5. Protocolul de blocare n dou faze

Pentru a putea asigura serializabilitatea tranzaciilor sistemele de gestiune pun la dispoziie posibilitatea de blocare a articolelor. Dac o tranzacie blocheaz un articol, celelalte tranzacii care vor i ele s aib acces la acel articol pot fi puse n ateptare pn la deblocarea acestuia. Dac blocrile i deblocrile sunt fcute ntro anumit ordine se poate determina serializabilitatea planificrilor construite din tranzaciile respective.
Protocolul de blocare n dou faze

Definiie: O tranzacie respect protocolul de blocare n dou faze dac toate blocrile preced toate deblocrile Acest protocol garanteaz serializabilitatea: dac toate tranzaciile respect cerinele protocolului se poate demonstra c orice planificare a lor e serializabil. De asemenea se poate demonstra c dac o tranzacie nu respect protocolul pot exista execuii neserializabile ale acelei tranzacii n conjuncie cu alte tranzacii: Pentru o tranzacie care conine secvena:
99
UNLOCK A LOCK B putem avea o planificare care o combin cu o alt tranzacie T2 astfel: T1 T2 UNLOCK A LOCK A LOCK B UNLOCK A UNLOCK B LOCK B Aceasta planificare are are un graf de preceden care conine un ciclu, ceea ce nseamn c nu e serializabila. Graful se construiete avnd ca noduri tranzaciile i arce de la tranzacia care face UNLOCK pe un articol ctre cea care face urmatorul LOCK pe acel articol. Protocolul de blocare n 2 faze implica ns uneori operaii de roll-back n cascad:
T1 LOCK A LOCK B READ A WRITE A UNLOCK A T2
LOCK A READ A WRITE A UNLOCK A READ B WRITE B ROLLBACK
n momentul Rollback pentru T1 este necesar Rollback i pentru T2 deoarece T2 a citit date scrise de T1, date care prin operaia de Rollback se pierd. O astfel de planificare se numeste planificare cu rollback n cascada (eng.: cascading aborts) Exist pentru a evita i astfel de cazuri varianta protocolului de blocare strict n 2 faze care implica eliberarea tuturor articolelor blocate la sfritul tranzaciei. n acest caz tranzacia T2 din exemplul anterior pornete abia dup terminarea complet a tranzaciei T1.
100

Baze de Date On Line

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Baze de Date On Line

Încărcat de

Drepturi de autor:

Formate disponibile

PREFA

BAZE DE DATE ON-LINE

BAZE DE DATE ON-LINE

5.10. 5.11. 5.12. 5.13. 5.14. 5.15. 5.16.

1.1. Baz de date i Sistem de gestiune a bazelor de date

un ansamblu structurat de date

...nregistrat pe suporturi accesibile calculatorului ...

... pentru a satisface simultan cerinele mai multor utilizatori

... ntr-un mod selectiv ...

BAZE DE DATE ON-LINE

... i n timp util ...

1.2. Funciile unui SGBD

Accesul concurent la date

BAZE DE DATE ON-LINE

1.3. Categorii de utilizatori

1.4. Nivele de descriere pentru o baz de date

2.1. Etapele dezvoltrii unei aplicaii

1. Cerine privind coninutul bazei de date: categoriile de date care vor fi

2. Cerine privind prelucrrile efectuate de aplicaie: prelucrrile efectuate

BAZE DE DATE ON-LINE

Proiectarea conceptual a bazei de date

Transformare n model relaional

Implementarea specific sistemului de gestiune folosit

Modelul entitate-asociere clasic

BAZE DE DATE ON-LINE

21 Asociaz mai mult de 2 entiti (exemplu: 3 entiti) 3: .... 6:

Fig. 2.1. Convenia de reprezentare a elementelor modelului EA

Extensii ale modelului

BAZE DE DATE ON-LINE

Fig. 2.2. Convenia grafic de reprezentare grafic a ierarhiilor

Caracteristici ale elementelor modelului

Fig. 2.3. Exemple de asocieri de grad 1, 2 i 3

BAZE DE DATE ON-LINE

Fig. 2.4. Reprezentarea obligativitii. Roluri

BAZE DE DATE ON-LINE

Modelul entitate-asociere clasic

STUDENT #* Matr * Nume * Grupa

PROIECT #* IdP * NumeP

CALCULATOR #* NrInv o Tip

FACULT #* CodF * NumeF

BAZE DE DATE ON-LINE

3.1. Modele de date: ierarhic, reea, relaional

BAZE DE DATE ON-LINE

3.2. Elementele de baz ale modelului relaional

Schema unei relaii

Cheia unei relaii

BAZE DE DATE ON-LINE

3.3. Transformarea diagramelor EA n modelul relaional

Transformarea asocierilor unare i binare 1-1 i 1-M

3.4. Algebra relaional

BAZE DE DATE ON-LINE

Algebra relaional clasic

Operatori derivai din teoria mulimilor

Operatori specifici algebrei relaionale

X(R) sau A1, A2, An (R)

BAZE DE DATE ON-LINE

Operatori folosii pentru multiseturi

Operatori pentru relaii i multiseturi

BNume, CPrenume, EDataN (R)

BAZE DE DATE ON-LINE

Expresie-1, Expresie-2, Expresie-n (R) Nume, Medie*2Dublu (STUD)

3.5. Calcul relaional

Calcul relaional pe tupluri

72 AVRAM CALIN* * * * * COSTESCU GEORGE* MILESCU SILVIU* * * * * *