Baze de Date

CAPITOLUL I. PROIECTARE (DESIGN) DE DATE CURS 1. Preliminarii

Bazele de date reprezint un instrument indispensabil pentru sistemele informatice. Modelarea bazelor de date constitue un subiect vast care nu poate fi tratat complet ntr-un singur curs. Baza de date reprezint o modalitate de stocare pe un suport extern a unei mulimi de date care modeleaz un proces (sistem) din lumea real, cu posibilitatea regsirii acesteia. De obicei o baz de date este memorat ntr-unul sau mai multe fiiere. Baza de date nsi poate fi privit ca un fel de cutie de umplere electronic - adic un container pentru o colecie de fiiere de date digitale. Bazele de date sunt manipulate cu ajutorul sistemelor de gestiune a bazelor de date.

Acestea, SGBD-urile, sunt responsabile cu crearea, manipularea i ntreinerea unei baze de date. Principala funcie a acestuia este de a permite utilizatorilor (prin intermediul programelor) s acceseze date dintr-o baz de date.

Cel mai rspndit model de baze de date este cel relaional, n care datele sunt memorate n tabele. Pe lng tabele, o baz de date relaional mai poate conine: indeci, proceduri stocate, trigger-e, utilizatori i grupuri de utilizatori, tipuri de date, mecanisme de securitate i de gestiune a tranzaciilor etc.

Cursul propune trecerea n revist a principalelor probleme care apar n proiectarea i implementarea bazelor de date relaionale. Pentru exemplificarea conceptelor se utilizeaz sistemul de gestiune MySql.

1.1. Noiuni folosite n teoria bazelor de date

1. O baz de date :

reprezint un ansamblu structurat de fiiere care grupeaz datele prelucrate n aplicaii informatice ale unei persoane, grup de persoane, instituii etc.

este definit ca o colecie de date aflate n interdependen, mpreun cu descrierea datelor i a relaiilor dintre ele.

2. Organizarea bazei de date se refer la structura bazei de date i reprezint un ansamblu de instrumente pentru descrierea datelor, relaiilor, restriciilor la care sunt supuse.

3. Sistemul de gestiune a bazei de date (SGBD):

este un sistem complex de programe care asigur interfaa ntre o baz de date i utilizatorii acesteia (exemple de programe: ACCESS, Fox Pro, PARADOX, ORACLE, MySQL, SQL Server)

este software-ul bazei de date care asigur:

1) definirea structurii bazei de date;

2) ncrcarea datelor n baza de date;

3) accesul la baza de date (interogare, actualizare);

4) ntreinerea bazei de date (refolosirea spaiilor goale, refacerea bazei de date n cazul unor incidente);

5) reorganizarea bazei de date (restructurarea i modificarea strategiei de acces);

6) securitatea datelor.

4. Cele trei concepte de baz utilizate n organizarea bazei de date sunt:

entitatea

atributul

valoarea

Prin entitate se nelege un obiect concret sau abstract reprezentat prin proprietile sale. O proprietate a unui obiect poate fi exprimat prin perechea (ATRIBUT, VALOARE).

Exemplu: n exemplul Masa x are culoarea alba, atributul este culoare, iar valoarea este reprezentat de cuvntul alb. Alte exemple ar putea fi: (Sex, Feminin), (Nume, POP), (Profesie, Medic), (Salariu, 200$).Observaie: Atributele pot caracteriza o clas de entiti, nu doar o entitate.

5. Data este un model de reprezentare a informaiei, accesibil unui anumit procesor (om, program, calculator) i se definete prin: Identificator; Tip; Valoare.

1.2. Funcionarea unei baze de date

Exploatarea unei baze de date aflate pe un suport specific (magnetic), de ctre un utilizator, prin intermediul unui sistem de calcul, avnd la dispoziie un SGBD, parcurge uzual urmtoarele etape:1.Utilizatorul, aflat la un terminal electronic, pune o "ntrebare" sau lanseaz o cerere de date, referitoare la informaiile din baza de date. ntrebarea se poate pune ntr-un limbaj de cereri specific SGBD-ului cu care se lucreaz (dac utilizatorul este familiarizat cu acest limbaj - de exemplu, SQL, FoxPro, dBase, Oracle) sau utilizatorul poate fi asistat n adresarea cererii de date de ctre SGBD (produsul soft pe care l folosete) printr-un sistem de meniuri, butoane sau ferestre de dialog (obiecte de control).

2.ntrebarea este analizat de ctre calculator, de fapt de SGBD, iar dac este corect, se ncearc (SGBD) s i se dea rspuns prin accesarea informaiilor din baza de date. Rspunsul va fi constituit din mulimea datelor cerute de utilizator, care verific criteriile specificate de acesta.Acest proces de lansare a unei cereri de date care va fi satisfcut prin furnizarea datelor care ndeplinesc proprietile cerute se numete interogarea bazei de date.3.Rspunsul la cererea de date se va afia pe ecran, se va tipri laimprimant sau se va memora ntr-un fiier.n realizarea unei baze de date se urmrete:

micorarea timpului de rspuns la o interogare;

asigurarea costurilor minime de prelucrare i ntreinere ; adaptabilitatea la cerine noi (flexibilitate); sincronizarea n exploatarea simultan a datelor de ctre mai muli utilizatori(accesul concurent); asigurarea proteciei mpotriva accesului neautorizat (confidenialitate); posibilitatea recuperrii datelor n cazul deteriorrilor accidentale (integritate) etc.Exemplu: n figura 1.1 este prezentat o baz de date foarte mic, ce conine un singur fiier, numit VINOTECA; la rndul su, aceasta cuprinde date despre coninutul unei anumite vinoteci. n figura 1.2 este prezentat un exemplu de operaie de consultare din baza de date, mpreun cu datele returnate prin aceast operaie.

Fig. 1.1. Baza de date pentru VINOTECA (fiierul VINOTECA)

Fig. 1.2 Exemplu de consultare

Observaii: n limbajul SQL, fiierul VINOTECA din figura 1.1 este numit tabel, rndurile unei astfel de tabele pot fi considerate ca nregistrri din fiier, iar coloanele pot fi considerate drept cmpuri.1.3 Realizarea unei baze de date

Realizarea unei baze de date presupune parcurgerea etapelor:

1.analiza domeniului (sistemului) pentru care se realizeaz baza de date;

2.proiectarea structurii bazei de date;3.ncrcarea datelor n baza de date;

4.exploatarea i ntreinerea bazei de date. SHAPE \* MERGEFORMAT

Fig. 1 Realizarea unei baze de datea) Analiza sistemuluiAnaliza sistemului presupune stabilirea temei, analiza componentelor sistemului i analiza legturilor (asocierilor) dintre aceste componente. Rezultatul analizei formeaz modelul conceptual al bazei de date.Cele patru etape necesare realizrii unei baze de date vor fi tratate pe parcursul ntregului curs urmrind un exemplu concret i anume o baz de date pentru o agenie imobiliar din ar, denumit AGENIE IMOBILIAR, care faciliteaz tranzacii de vnzare/cumprare ntre vnztor i cumprtor, care gestioneaz documente legate de oferte imobiliare, de ntreinere a nomenclatoarelor specifice domeniului i care ofer o gam larg de rapoarte privind situaia vnzare-cumprare.

Odat stabilit tema proiectului, se trece la etapa urmtoare, i anume la identificarea tuturor tipurilor de informaii, a legturilor dintre informaii i a operaiilor necesare pentru gestionarea lor. Aceast etap va fi detaliat n cursul urmtor.

b) Proiectarea structurii bazei de date

Dac etapa de analiz a modelului conceptual se realizeaz independent de un SGBD, prin etapa de proiectare a structurii bazei de date se trece la luarea n considerare a SGBD-ului cu ajutorul cruia va fi implementat i exploatat baza de date.

Proiectarea structurii bazei de date reprezint transpunerea rezultatelor obinute n urma analizei modelului conceptual n termenii unui model al datelor suportat de un anumit SGBD. Compilatorul limbajului de descriere a datelor permite aducerea schemei bazei de date la nivelul la care s poat fi memorat n baza de date.

Astfel, proiectarea presupune o detaliere, de exemplu, de tip pseudocod a modulelor necesare realizrii bazei de date: module pentru crearea fiierelor, pentru introducerea datelor, pentru prelucrarea i extragerea rezultatelor, pentru tratarea erorilor etc.

c) ncrcarea datelor n baza de date

Este etapa n care se realizeaz popularea masiv cu date a bazei de date, activitate care trebuie s se efectueze cu un minim de efort.

d) Exploatarea i ntreinerea bazei de date

Exploatarea bazei de date de ctre diferii utilizatori finali este realizat n scopul satisfacerii cerinelor de informare ale acestora. SGBD sprijin utilizatorii finali n exploatarea bazei de date, oferind o serie de mecanisme i instrumente cum ar fi limbajele de manipulare a datelor (LMD).

ntreinerea bazei de date reprezint o activitate complex, realizat, n principal, de ctre administratorul bazei de date i care se refer la actualizarea datelor din cadrul bazei de date.

CURS 2. Construirea de diagrame entitate-relaie

Prima etap pentru realizarea unei baze de date const n analiza sistemului. Se cunosc mai multe tehnici de analiz, dar cea mai des ntlnit este tehnica entitate-relaie.Prin tehnica entiate-relaie (denumit i entitate-asociere) se construiete o diagram entiate-relaie (notat E-R) prin parcurgerea urmtorilor pai:

a) identificarea entitilor (componentelor) din sistemul proiectului;

b) identificarea asocierilor (relaiilor) dintre entiti i calificarea lor;

c) identificarea atributelor corespunztoare entitilor;

d) stabilirea atributelor de identificare a entitilor.

a) Identificarea entitilor

Prin entitate se nelege un obiect concret sau abstract reprezentat prin proprietile sale. Prin convenie, entitile sunt substantive, se scriu cu litere mari i se reprezint prin dreptunghiuri. ntr-o diagram nu pot exista dou entiti cu acelai nume, sau o aceeai entitate cu nume diferite.

Pentru baza de date din domeniul imobiliar considerat anterior, se pot pune n eviden urmtoarele entiti:

DATE_PERSOAN entitate care stocheaz date personale ale ofertantului (vnztorului) sau ale clientului (cumprtorului);

CERERI_ OFERTE conine ofertele sau cererile imobiliare propuse de vnztori, respectiv cumprtori;

DESCRIERE_IMOBIL stocheaz informaiile referitoare la imobile; JUDEE entitate ce conine judeele n care sunt amplasate imobilele;

LOCALITI - entitate ce conine localitile n care sunt amplasate imobilele;

STRZI - entitate ce precizeaz strzile n care sunt amplasate imobilele;

FACTURI formularul necesar unei tranzacii de cumprare-vnzare.

Figura urmtoare prezint o prim form a diagramei entitate-asociere (E-R).

Fig. 2.1. Diagrama E-R pentru domeniul imobiliar (prima form)

b) Identificarea asocierilor dintre entiti i calificarea lor

ntre majoritatea componentelor (adic a entitilor) unui sistem economic se

stabilesc legturi (asocieri). Exemplu: Exist o asociere ntre entitile CERERI_OFERTE i FACTURI deoarece facturile reprezint finalizarea unei cereri/oferte. Aceast asociere se reprezint ca n figura de mai jos.

Fig. 2.2. Prezentarea asocierii dintre entitile CERERI_OFERTE i FACTURI

Sunt necesare precizarea ctorva notaii i noiuni utilizate n exemplul de mai sus: legturile (asocierile) se reprezint prin arce neorientate ntre entiti;

fiecrei legturi i se acord un nume plasat la mijlocul arcului i simbolizat printr-un romb (semnificaia legturii);

numerele simbolizate deasupra arcelor se numesc cardinaliti i reprezint tipul legturii;

cardinalitatea asocierilor exprim numrul minim i maxim de realizri ale unei entiti cu cealalt entitate asociat. Exemplu: Cardinalitatea (1,1) ataat entitii CERERI_OFERTA nseamn c o factur poate fi rezultatul tranzacionrii a minim unei cereri/oferte i a unui numr maxim de tot o cerere/ofert. Cardinalitatea (0,1) ataat entitii FACTURI nseamn c o cerere se poate finaliza prin maxim o factur sau prin nici una (0 facturi) . Aceast cardinalitate reiese din analiz:

Fig. 2.3. Determinarea cardinalitii asocierii dintre entitile CERERI_OFERTE i FACTURI

Maximele unei cardinaliti sunt cunoscute i sub denumirea de grad de asociere, iar minimele unei cardinaliti, obligativitatea participrii entitilor la asociere.Tipuri de asocieri (legturi) ntre entiti

Asocierile pot fi de mai multe feluri, iar odat cu asocierea, se impune stabilirea calificrii acesteia. Asocierea dintre entiti se face n funcie de:i) cardinalitatea asocierii;

ii) numrul de entiti distincte care particip la asociere.

i. Dup cardinalitatea asocierii

n funcie de maxima cardinalitii (gradul de asociere), se cunosc trei tipuri de asocieri, care, la rndul lor, sunt de dou tipuri, n funcie de minima cardinalitii (gradul de obligativitate al participrii la asociere): asocieri de tip unu la unu:

asocieri pariale de tip unu la unu asocieri totale de tip unu la unu

asocieri de tip unu la mai muli: asocieri pariale de tip unu la muli asocieri totale de tip unu la muli

asocieri de tip muli la muli:

asocieri pariale de tip muli la muli asocieri totale de tip muli la muli.

ii. Dup numrul de entiti distincte care particip la asociere:

asocieri binare (ntre dou entiti distincte);

asocieri recursive (asocieri ale entitilor cu ele nsele);

asocieri complexe (ntre mai mult de dou entiti distincte).

n continuare se descriu asocierile grupate dup cardinalitatea lor.

Asocieri n funcie de cardinalitatea legturii

1. Asocieri de tip unu la unu sunt asocieri n care maximele cardinalitii au

valoarea 1.

Fig. 2.4. Asociere de tip unu la unu

Exemplu: Asocierea din figura 2.3 este asociere de tip 1 la 1. 2. Asocieri de tip unu la mai muli sunt asocieri n care maxima cardinalitii

unei entiti este unu, iar a celeilalte entiti are valoarea muli.

Fig. 2.5. Asociere de tipul unu la mai muli

Exemplu:

Fig. 2.6. Asociere de unu la mai muli ntre entitile LOCALITI i CERERI_OFERTE3. Asocieri de tipul muli la muli sunt asocieri n care maximele cardinalitii au

valoarea muli.

Fig. 2.7. Asociere de tipul muli la muli

Exemplu:

Fig. 2.8. Asociere de tipul muli la muli ntre entitile DEPOZIT i PRODUSObservaie: Uneori (n cazul utilizrii unor SGBD), asocierea de tip muli la muli se transform n dou asocieri de tipul unul la muli fiind, de regul, mai uor de implementat i de utilizat i anume:

Fig. 2.9. Transformarea unei asocieri de tipul muli la muli (a) n asocieri de tipul unu la muli (b)Exemplu: n cazul exemplului de mai sus (vezi figura 2.8), transformarea asocierii muli la muli n asocieri de tipul unu la muli se poate realiza prin construirea unei noi entiti DEPOZIT_PRODUS astfel:

Fig. 2.10. Transformarea asocierii de tipul muli la muli n asocieri de tipul unu la muliAsocieri pariale i totale

Printr-o asociere parial se nelege o asociere n care nu exist obligativitatea participrii la aceast asociere a tuturor entitilor vizate, ci numai a unora dintre ele sau a nici uneia. Asocierea parial se caracterizeaz prin faptul c minima cardinalitii ataat unei entiti este zero.

Observaii (asupra minimii cardinalitii)

minima cardinalitii zero, are drept rezultat lipsa obligativitii participrii partenerului la aceast asociere;

minima cardinalitii mai mare dect zero, are drept rezultat obligativitatea participrii.

Fig. 2.11 Asocieri pariale ntre entitile E1 i E2

Exemplu: Asocierea dintre entitile CERERI_OFERTE i FACTURI din fig. 2.3 reprezint o asociere parial, deoarece participarea entitii FACTURI nu este obligatorie, minima caracteristicii corespunztoare entitii CERERI_OFERTE fiind 0.

O asociere este total dac toate entitile au obligativitatea s participe la asociere, adic minima cardinalitii este mai mare dect zero.

Fig. 2.12 Asocieri totale ntre entitile E1 i E2

n continuare se dau cteva exemple de asocieri totale, respectiv pariale.Exemplu: Asocieri pariale de tip unu la unu

Exemplu: Asocieri totale de tip unu la unu

Exemplu: Asocieri pariale de tip unu la muli

Exemplu: Asocieri totale de tip unu la muli

Exemplu: Asocieri pariale de tip muli la muli

Exemplu: Asocieri totale de tip muli la muli

Fig. 2.13 Asocieri dup gradul i obiectivitatea lor

n exemplul bazei de date AGENTIE_IMOBILIARA, tipurile de asocieri dintre entiti stabilite n funcie de modul n care se desfoar activitatea modelat sunt:

JUDETE-LOCALITATI 1:n deoarece unui jude i corespund mai multe localiti;

LOCALITATI-STRAZI 1:n - deoarece unei localiti i corespund mai multe strzi;

STRAZI-CERERI_OFERTE 1:n deoarece unei strzi i pot corespunde mai multe oferte/cereri;

FACTURI-CERERI_OFERTE 1:1 deoarece fiecare factur conine doar cte o ofert/cerere;

CERERI_OFERTE-DESCRIERE_IMOBIL 1:1 fiecrui imobil i se face o singur descriere; FACTURI- DATE_PERSOANA 1:1 o factur este ncheiat de o singur persoan;

DATE_PERSOANA -CERERI 1:n o persoan poate lansa mai multe cereri sau oferte de imobil.

c) Identificarea atributelor entitilor i a asocierilor dintre entiti

Atributele unei entiti reprezint proprieti ale acestora. Atributele sunt substantive, iar pentru fiecare atribut i se va preciza tipul fizic (integer, float, char, string etc.)

Exemplu: Entitatea LOCALITI are urmtoarele atribute: codul localitii, notat cod_loc, simbolul de identificare al judeului simbol_jude i denumirea localitii nume_loc.

d) Stabilirea atributelor de identificare a entitilor

Un atribut de identificare (numit cheie primar), reprezint un atribut care se caracterizeaz prin unicitatea valorii sale pentru fiecare instan a entitii.

n cadrul diagramei entitate-asociere, un atribut de identificare se marcheaz prin subliniere sau prin marcarea cu simbolul # plasat la sfritul numelui acestuia.

Fig. 2.14. Notaii uzuale pentru atributele de identificare

Exemplu: Ca atribut de identificare putem considera codul numeric personal cnp pentru entitatea DATE_PERSOAN.

Pentru ca un atribut s fie atribut de identificare, acesta trebuie s satisfac unele cerine:

ofer o identificare unic n cadrul entitii;

este uor de utilizat; este scurt (de cele mai multe ori, atributul de identificare apare i n alte entiti, drept cheie extern).

Pentru o entitate pot exista mai multe atribute de identificare, numite atribute (chei) candidate. Dac exist mai muli candidai cheie, se va selecta unul, preferndu-se acela cu valori mai scurte i mai puin volatile.

Exemplu: n urma analizrii celor 4 etape necesare construirii diagramei entitate-asociere:

identificarea entitilor domeniului sau a sistemului economic;

identificarea asocierilor dintre entiti;

identificarea atributelor aferente entitilor i a asocierilor dintre acestea;

stabilirea atributelor de identificare a entitilor,

se poate prezenta forma complet a diagramei asociate domeniului ales n exemplu.

Fig. 2.15. Diagrama E-R pentru domeniul imobiliar (a doua form)

n cazul n care se dorete o diagram care s conin i atributele fiecrei entiti nsoite de precizarea atributelor de identificare (adic a cheilor primare), pentru a nu ncrca imaginea, diagrama proiectului se poate fragmenta pe mici domenii, dup cum este cazul entitii CERERI_OFERTE, prezentat n figura 2.16. (S-au considerat un numr relativ mic de atribute).

Fig. 2.16. Reprezentarea atributelor aferente entitii CERERI_OFERTE (detaliu dintr-o diagram E-R)

n reprezentarea atributelor aferente entitii CERERI_OFERTE semnificaia atributelor este urmtoarea: cheia primar a entitii id_co reprezint numrul de ordine al cererii sau ofertei de imobil lansat de o anumit persoan, atributul tipul specific dac este vorba de o cerere sau de o ofert, prin cnp se precizeaz codul numeric personal al clientului, data_inreg reprezint data la care s-a nregistrat oferta/cererea, apoi urmeaz cteva date legate de imobil: codul localitii cod loc, codul strzii id_strada, numrul imobilului nr_imobil, preul minim, respectiv preul maxim al imobilului pret_min, pret_max. Ultimul atribut, tip_solutionare precizeaz dac cererea/oferta respectiv a fost soluionat; pentru o cerere/oferta nou introdus, acest atribut se va completa cu explicaia de nesoluionat. Astfel, diagrama bazei de date AGENIE IMOBILIAR conine 7 entiti a cror asociere a fost prezentat n figura 2.15.

Fig. 2.17. Baza de date AGENIE IMOBILIAR- entiti i atribute

CURS 3. Proiectarea modelului relaional

Proiectarea corect a bazelor de date este crucial pentru obinerea unei aplicaii de nalt performan.

Modelul relaional este cel mai utilizat dintre modelele de date existente (modele ierarhice, modele reea, modele orientate pe obiect). Fa de modelele ierarhic i reea, modelul relaional prezint cteva avantaje:

propune structuri de date uor de utilizat;

amelioreaz independena logic i fizic;

pune la dispoziia utilizatorilor limbaje neprocedurale;

optimizeaz accesul la date;

mbuntete confidenialitatea datelor.

Din punct de vedere istoric, trebuie menionat c modelul relaional s-a conturat n dou articole publicate de ctre F.E. Codd n 1969 i 1970, matematician la centrul de cercetri (California) I.B.M. Codd a propus o structur de date tabelar, independent de tipul de echipamente i de software-ul de sistem pe care este implementat. Dei puternic matematizat, modelul relaional este relativ uor de neles.

Dac, teoretic, modelul s-a consacrat n anii 1970, produsele software care s gestioneze baze de date au devenit populare abia n anii 80. Cele mai utilizate sisteme de gestiune a bazelor de date relaionale (SGBDR) dedicate uzului individual sunt: ACCESS, PARADOX, Visual Fox Pro. Pentru aplicaiile complexe din bnci i instituii de mari dimensiuni se folosesc SGBDR-urile de categorie grea, ORACLE, DB2 IBM, Informix IBM, SyBase (SyBase), SQL Server (MicroSoft);sunt mult mai robuste, fiabile, dar i costisitoare. n ultimul timp i-au fcut apariia aa-zisele SGBD-uri (aproape) gratuite: PostgreSQL, MySQL, mSQL, FireBird etc. (Acestea ruleaz de obicei pe sisteme de operare Linux).

Modelul relaional are la baz teoria matematic a relaiilor i poate fi privit ca o mulime de tabele obinute prin metoda normalizrii, eliminndu-se astfel anomaliile de actualizare.

Conceptele modelului relaional sunt:

1. structura relaional a datelor;

2. operatorii modelului relaional;

3. restriciile de integritate ale modelului relaional.

3.1 Structura relaional a datelor

O baz de date relaional (BDR) reprezint un ansamblu de relaii, prin care se reprezint datele i legturile dintre ele.

n cadrul bazei de date relaionale, datele sunt organizate sub forma unor tablouri bidimensionale (tabele) de date, numite relaii. Asocierile dintre relaii se reprezint prin atributele de legtur. n cazul legturilor de tip unu la muli, aceste atribute figureaz ntr-una dintre relaiile implicate n asociere. n cazul legturilor de tip muli la muli, atributele sunt situate ntr-o relaie distinct, construit special pentru explicarea legturilor ntre relaii.

Prezentarea structurii relaionale a datelor impune definirea noiunilor de:

domeniu;

relaie;

atribut;

schem a unei relaii.

Conceptele utilizate pentru a descrie formal, uzual sau fizic elementele de baz ale organizrii datelor sunt date n urmtorul tabel:

Fig. 3.1. Concepte uzuale folosite n exprimarea formal, uzual i fizic

Domeniul

Domeniul reprezint o mulime de valori, notat prin litere mari D1,D2 etc., caracterizat printr-un nume.

Modalitile de definire a unui domeniu sunt:

explicit: prin enumerarea tuturor valorilor aparinnd domeniului;

implicit: prin precizarea proprietilor pe care le au valorile din cadrul domeniului. Exemplu: D1: {Da, Nu} reprezint un domeniu definit explicit. D2: {x| x este de dat calendaristic} sau D3: {s| s este numr decimal} reprezint domenii definite implicit, unde prin numr decimal se nelege un numr zecimal pentru care se precizeaz numrul de cifre componente.

Printr-un tuplu se nelege o succesiune de valori de diferite tipuri. Un tuplu se noteaz enumernd valorile sale , unde V1 este o valoare din domeniul D1, V2D2 etc.

Exemplu: Considerm c tuplul referitor la persoana x din entitatea CERERI_OFERTE conine trei valori diferite ce desemneaz:

codul numeric personal (cnp): 1701205230023;

data nregistrrii ofertei (data_nreg): 2006-07-03;

tipul soluionrii (tip_soluionare): Nu.

Se formeaz tuplul .

Relaia

Relaia R este un subansamblu al produsului cartezian dintre mai multe domenii D1, D2, ..., Dn, reprezentat sub forma unei tabele de date (tabelul bidimensional) i deci, o mulime de tupluri.

Exemplu: Considerm c:

D1 cuprinde valori referitoare la tipul soluionrii tranzaciei: Da, dac tranzacia a fost soluionat, Nu, n caz contrar;

D2 cuprinde valori ale datei calendaristice;

D3 conine valori care exprim cnp-ul persoanei.

De asemenea considerm c se cunosc datele a doi ofertani i c fiecare pune n vnzare doar cte un imobil. Atunci definim relaia R prin tuplurile care descriu aceste informaii ale ofertelor celor dou persoane:

R: {, }.

sau

R:

D3

D2

D1

26618052700232006-05-27Da

17012052300232006-07-03Nu

Fig. 3.2. Variante de prezentare a unei relaii R

Observaia 1. ntr-o relaie, tuplurile trebuie s fie distincte.

Observaia 2. Cardinalul relaiei este numrul tuplurilor dintr-o relaie.

Gradul relaiei este numrul valorilor dintr-un tuplu.

Atributul

Atributul reprezint coloana unei tabele de date, caracterizat printr-un nume.

Exemplu:

cnp: D3data_nreg:D2tip_

soluionare:D1

26618052700232006-05-27Da

17012052300232006-07-03Nu

R:

Fig. 3.3. Relaia R reprezentat cu ajutorul atributelor

Atributele sunt utile atunci cnd ntr-o relaie un domeniu apare de mai multe ori. Prin numele dat fiecrei coloane (atribut), se difereniaz coloanele care conin valori ale aceluiai domeniu, eliminnd dependena fa de ordine.

Schema unei relaii

Schema unei relaii este numele relaiei urmat de lista de atribute, pentru fiecare atribut precizndu-se domeniul asociat.

Astfel, pentru o relaie R cu atributele A1, A2, ... , An i domeniile D1, D2, ... ,Dm,

cu m n, schema relaiei R poate fi prezentat astfel:

R(A1: D1, A2:D2, ... , An: Dm)

sau

R:

A1:D1...An:Dm

Fig. 3.4. Reprezentarea schemei relaiei RCa o concluzie, dintre caracteristicile modelului relaional menionm:

- nu exist tupluri identice;

- ordinea liniilor i a coloanelor este arbitrar;

- articolele unui domeniu sunt omogene;

- fiecare coloan definete un domeniu distinct i nu se poate repeta n cadrul aceleiai relaii.

CURS 4. Operatorii modelului relaional

3.2 Operatorii modelului relaional

Modelul relaional ofer dou colecii de operatori pe relaii:

algebra relaional;

calcul relaional:

calcul relaional orientat pe tuplu;

calcul relaional orientat pe domeniu.

n acest curs va fi tratat doar cazul algebrei relaionale.

Algebra relaional este o colecie de operaii pe relaii, fiecare operaie avnd drept operanzi una sau mai multe relaii, rezultatul fiind o alt relaie.

Exist mai multe criterii de grupare a operaiilor:

operaii de baz:

reuniunea;

diferena;

produsul cartezian etc.

operaii derivate:

intersecia;

diviziunea etc.

sau

operaii tradiionale pe mulimi (reuniune, intersecie, diviziune, produs cartezian)

operaii relaionale speciale (selecia, proiecia, jonciunea, etc.)

Reuniunea

Reuniunea reprezint o operaie a algebrei relaionale definit pe dou relaii: R1 i R2, ambele cu aceeai schem, n urma creia se construiete o nou relaie R3, cu aceeai schem ca i R1 i R2 i avnd drept extensie tuplurile din R1 i R2, luate mpreun o singur dat.

Notaii: R1U R2

OR (R1, R2)

APPEND (R1, R2)

UNION (R1, R2)

Reprezentarea grafic

Fig. 4.1. Reprezentarea grafic a operaiei de reuniune a dou relaii

Exemplu: Deoarece aplicaia AGENTIE IMOBILIARA luat ca exemplu n acest curs nu conine dou relaii cu aceeai structur, pentru a putea exemplifica operaia de reuniune se vor construi dou relaii ARHIVA_OFERTE i ARHIVA_CERERI populate cu informaiile aferente ofertelor respectiv cererilor soluionate (s-au ales doar patru atribute: id-ul ofertei sau a cererii, tipul operaiei(ofert sau cerere), cnp-ul clientului, tipul soluionrii). Pentru a afla care sunt toate ofertele i cererile soluionate, se realizeaz operaia de reuniune.

Fig. 4.2. Reuniunea relaiilor ARHIVA_OFERTE i ARHIVA_CERERI

Diferena

Diferena reprezint o operaie a algebrei relaionale definit pe dou relaii R1 i R2, ambele cu o aceeai schem, n urma creia se construiete o nou relaie R3, cu schema identic cu R1 i R2, avnd drept extensie acele tupluri ale relaiei R1 care nu se regsesc n relaia R2.

Notaii: R1 R2

REMOVE (R1, R2)

MINUS (R1, R2)

Reprezentarea grafic:

Fig. 4.3. Reprezentarea grafic a operaiei de diferen a dou relaii

Exemplu: Presupunnd c exist clieni care au nregistrri n ambele tabele (adic au oferit imobil spre vnzare, dar i au achiziionat un alt imobil n acelai timp), pentru a afla care au fost doar ofertanii de imobile, se aplic diferena dintre relaiile ARHIVA_OFERTE i ARHIVA_CERERI.

Fig. 4.4. Diferena relaiilor ARHIVA_OFERTE i ARHIVA_CERERI

Produsul cartezian

Produsul cartezian reprezint o operaie a algebrei relaionale definit pe dou relaii R1 i R2, n urma creia se construiete o nou relaie R3, a crei schem se obine prin concatenarea schemelor relaiilor R1 i R2, avnd ca extensie toate combinaiile tuplurilor din R1 cu cele din R2 (operaie laborioas).

Notaie: R1xR2 PRODUCT (R1, R2)

TIMES (R1, R2)

Reprezentarea grafic:

Fig. 4.5. Reprezentarea grafic a produsului cartezian

Exemplu: Operaia de produs cartezian va fi exemplificat pe un exemplu independent de aplicaia AGENIA IMOBILIAR considerat. Astfel:

Fig. 4.6. Produsul cartezian dintre relaiile LOCALIT i TARIFE

Proiecia

Proiecia reprezint o operaie a algebrei relaionale definit asupra unei relaii R, n urma creia se construiete o nou relaie P, n care se gsesc acele atribute din R specificate explicit n cadrul operaiei.

Prin operaie de proiecie se trece de la o relaie de grad n (are n coloane) la o relaie de grad mai mic, p (p2, operaia de splitare a relaiei R produce relaiile R1 i R2 reprezentate prin tabelele:

R1

A1:D1A2:D2

Galben3

R2

A1:D1A2:D2

Rou1

Rou2

Figura 4.25. Rezultatul operaiei de splitare a relaiei R din figura 4.24 (a) pe baza condiiei A2>2

nchiderea tranzitivnchiderea tranzitiv este o operaie (adiional) a algebrei relaionale, definit asupra unei relaii R, a crei schem conine dou atribute A1 i A2 cu acelai domeniu asociat, operaie care const n adugarea la relaia R a tuplurilor care se obin succesiv prin tranzitivitate: dac n R exist tuplurile: i se va aduga la R tuplul .

Notaie:

R+

CLOSE(R)Exemplu:

Fig. 4.26. nchiderea tranzitiv a relaiei R

CURS 5. Restricii de integritate ale modelului relaional

3.3 Restricii de integritate ale modelului relaional

Restriciile de integritate ale modelului relaional reprezint cerine pe care trebuie s le ndeplineasc datele din cadrul bazei de date pentru a putea fi considerate corecte i coerente n raport cu lumea real pe care o reflect. Dac o baz de date nu respect aceste cerine, ea nu poate fi utilizat cu un maxim de eficien.

Restriciile sunt de dou tipuri:

restricii de integritate structurale, care se definesc prin egalitatea sau inegalitatea unor valori din cadrul relaiilor:

restricia de unicitate a cheilor;

restricia entitii;

dependenele ntre ele;

restricii de integritate de comportament care in cont de semnificaia valorilor din cadrul bazei de date.

Utilizarea modelului relaional nu impune definirea i verificarea tuturor acestor

tipuri de restricii de integritate. Din acest punct de vedere exist restricii de integritate minimale. Acestea sunt obligatoriu de definit i de respectat cnd se lucreaz cu modelul relaional. Dintre restriciile minimale fac parte:

restricia de unicitate a cheii;

restricia referenial;

restricia entitii.

Alte restriciii de integritate ar fi

dependenele;

restricii de comportament.

Restricii de integritate minimale

Restriciile de integritate minimale sunt definite n raport cu noiunea de cheie a unei relaii. Cheia identific un tuplu n cadrul unei relaii fr a face apel la toate valorile din tuplu.

Cheia unei relaii reprezint ansamblul minimal de atribute prin care se poate identifica n mod unic orice tuplu al relaiei.

Oricare relaie posed cel puin o cheie:

cheie simpl, cnd cheia este construit dintr-un singur atribut;

cheie compus, cnd cheia este construit din mai multe atribute.

Exemplul 1:

Fig. 5.1. Chei simple i chei compuse

Determinarea cheii unei relaii necesit cunoaterea tuturor extensiilor posibile, nu numai a aceleia din momentul n care se stabilete cheia. Astfel, presupunnd c R1 i R2 sunt versiuni ale aceleiai relaii R la momente de timp diferite: t1, respectiv t2, alegerea la momentul t1 drept cheie atributul A a relaiei R2 se dovedete a fi greit, ntruct atributul A nu face posibil identificarea unic a tuplurilor i la momentul t2. Cheia relaiei R2 este reprezentat, prin urmare, de perechea de atribute (A,B). Exemplul 2:

Fig. 5.2. Chei simple i chei compuse n cadrul relaiilor JUDEE, respectiv STRZI

Observaie: Cheia relaiei JUDEE este simbol_jude, deoarece fiecare jude are o codificare unic a denumirii sale, deci fiecrui jude i corespunde un singur simbol. Cheia relaiei STRZI este compus din atributele cod_loc i id_strada. Dac s-ar alege drept cheie primar doar atributul id_strada, acesta nu ar identifica n mod unic numele unei strzi dintr-o localitate, id-ul strzii respective putndu-se regsi i n alte localiti ale aceluiai jude sau a altui jude. La fel, dac s-ar alege drept cheie primar atributul cod_loc, acesta nu ar mai identifica n mod unic un tuplu, deoarece ntr-o localitate exist mai multe strzi.

O relaie poate avea mai multe combinaii de atribute, cu proprietatea de identificare unic a tuplurilor. Se spune n acest caz c relaia posed mai muli candidai cheie (chei candidate).

Definiia 1. Se numete cheie primar, cheia aleas dintre cheile candidate care s serveasc n mod efectiv la identificarea tuplurilor.

Cheia primar nu poate fi reactualizat. Cheia primar a unei relaii nu este altceva dect atributul de identificare a unei entiti, prin urmare se reprezint fie prin subliniere, fie urmate de semnul #.

Definiia 2. Se numete cheie extern atributul/grupul de atribute dintr-o relaie R1 a crui/cror valori sunt definite pe acelai domeniu/aceleai domenii ca i cheia primar a unei alte relaii R2 i care are rolul de a modela asocierea ntre entitile reprezentate prin relaiile R1 i R2. n acest caz, R1 se numete relaie care refer, iar R2 se numete relaie referit.

Exemplul 1:

Fig. 5.3. Reprezentarea legturii dintre relaiile DATE_PERSOANA i JUDETE cu ajutorul cheii externe simbol_judet din cadrul relaiei DATE_PERSOANAObservaia1: n exemplul de mai sus, relaia DATE_PERSOANA are drept cheie primar atributul cnp, iar ca i cheie extern atributul simbol_judet, iar relaia JUDETE are drept cheie primar cheia simbol_judet. Relaia DATE_PERSOANA este relaia care refer, iar JUDETE este relaia referit.

Observaia2: ntre cele dou relaii (entiti) avem urmtoarea asociere:

Fig. 5.4. Asocierea dintre entitile DATE_PERSOANA i JUDETE

Exemplul 2:

Fig. 5.5. Reprezentarea legturii ntre relaiile JUDETE i LOCALITATI cu ajutorul cheilor externe simbol_judet i cod_localitate

Restricia de unicitate a cheii

Restricia de unicitate a cheii impune ca ntr-o relaie s nu existe dou linii identice (linii care s nu conin aceleai valori pentru toate atributele). Altfel spus, restricia de unicitate a cheii impune ca ntr-o relaie s nu existe dou tupluri cu o aceeai valoare pentru atributul cheie.

Exemplele 1 i 2 respect restricia de unicitate a cheii.

Restricia referenial

Restricia referenial impune ca ntr-o relaie R1 care refer o relaie R2, valorile cheii externe s figureze printre valorile cheii primare din R2 sau s fie valori null (nedefinite). R1 i R2 nu trebuie s fie neaprat distincte.

Exemplele 1 i 2 prezint un mecanism de legare a relaiilor i respect restricia referenial a cheii.

Restricia entitiiRestricia entitii impune ca ntr-o relaie atributele cheii primare s fie nenule. (Atributele cheie s nu conin valori nule). Dac exist valori null, cheia i poate pierde rolul de identificator de tuplu. Astfel, la ncrcarea unui tuplu, valoarea cheii trebuie s fie cunoscut, pentru a se putea verifica faptul c aceast valoare nu exist deja ncrcat.

Exemplele 1 i 2 respect restricia entitii.

Relaia REZ din figura 4.17 ncalc restricia entitii deoarece exist chei primare ce conin valori nule, dup cum este cazul judeului Braov.

Alte restricii de integritate

n categoria restricii de integritate intr urmtoarele tipuri de restricii:

a) restricii referitoare la dependena datelor:

dependen funcional;

dependen multivaloare;

b) restricii de comportament:

restricii de domeniu;

restricii temporale.

Restriciile referitoare la dependena datelor, reprezint modul n care datele depind unele de altele.

Dependenele funcionaleDependenele funcionale reprezint dependena ntre date prin care se poate identifica un atribut/grup de atribute prin intermediul altui atribut/grup de atribute.

Dac X i Y sunt dou subansamble de atribute ale atributelor relaiei R, spunem c ntre X i Y exist o dependen funcional, notat , dac i numai dac:(i) fiecare valoare a lui X poate fi asociat unei singure valori din Y, i

(ii) dou valori distincte ale lui X nu pot fi asociate dect aceleiai valori ale lui Y.

X se numete determinantul (sursa) dependenei, iar Y se numete determinatul (destinaia) dependenei.Exemple: Urmtoarele atribute se afl n dependen funcional:

cod_potallocalitate, deoarece unui cod potal i corespunde o singur localitate (sensul dependenei este foarte important, deoarece, viceversa ar nsemna: o localitate are un singur cod_potal);

nr_facturdata_factur, deoarece cunoaterea numrului facturii determin cu exactitate data facturii.Dou atribute nu sunt n dependen funcional, notat X Y, atunci cnd cunoaterea unei valori a primului atribut fie nu permite cunoaterea nici uneia dintre valorile celui de al doilea atribut, fie permite cunoaterea mai multor valori ale celui de al doilea atribut.Exemplu: Urmtorul atribut nu se afl n dependen funcional: cnpnr_factur, deoarece pentru o persoan se pot ntocmi mai multe facturi (aferente fiecrei vnzri).n cadrul modelului relaional, o dependen funcional este reprezentat printr-o sgeat ce pornete din surs i se termin n destinaie.

Fig. 5.6. Reprezentarea dependenei funcionale ntre atributele nr_factura i data_facturii

Dependenele multivaloareDependenele multivaloare reprezint dependena n care un atribut/ grup de atribute poate reprezenta/ identifica mai multe valori pentru o singur valoare a unui alt atribut/ grup de atribute.

Dac X,Y i Z sunt trei subansambluri de atribute ale atributelor relaiei R, spunem c ntre X i Y exist o dependen multivaloare, notat sau , dac i numai dac:(i) la fiecare valoare a lui X poate fi asociat una sau mai multe valori ale lui Y, i

(ii) aceast asociere nu depinde de apariiile lui Z.

Altfel spus, dac i (x,y,z), (x,y,z) sunt dou tupluri din R, atunci i (x,y,z), (x,y,z) sunt tupluri din R.Exemplu: n relaia OFERTE (alctuit din atributele: id_tip_oferte, cnp i simbol_judet) valorile atributului id_tip_oferte au urmtoarea semnificaie: 01 desemneaz imobil de tip apartament, iar 02, imobil de tip cas. Astfel, urmtoarea relaie conine dependene multivaloare:

deoarece

Fig. 5.7. Relaia OFERTE n care exist dependen multivaloare

CURS 6. Prelucrarea/evaluarea i optimizarea cerinelor

Regulile lui Codd

Prin sistem de gestiune a bazelor de date relaionale (SGBDR) se nelege un SGBD care utilizeaz drept concepie de organizare a datelor modelul relaional.

Definirea unui SGBDR impune o detaliere a caracteristicilor pe care trebuie s le prezinte un SGBD pentru a putea fi considerat relaional. n acest sens, Codd a formulat (n 1985) 13 reguli, care exprim cerinele pe care trebuie s le satisfac un SGBD. Aceste reguli sunt deosebit de utile n evaluarea unui SGBDR.

R0: Regula privind gestionarea datelor la nivel de relaie.

sistemul trebuie s gestioneze BD numai prin mecanisme relaionale.

R1: Regula privind reprezentarea logic a datelor.

ntr-o baz de date relaionat, informaia este reprezentat la nivel logic sub forma unor tabele (relaii);

acest lucru nseamn c toate datele trebuie s fie memorate i prelucrate n acelai mod.

R2: Regula privind reprezentarea logic a datelor orice data din baza de date relaionat trebuie s poat fi accesat prin specificarea:

numelui relaiei;

valorii cheii primare;

numele atributului.

R3: Regula privind valorile nule

sistemul trebuie s permit declararea i manipularea sistematic a valorilor NULL (semnific lipsa unor date);

valorile NULL difer de irurile de caractere spaiu, irurile vide de caractere.

valorile NULL sunt deosebit de importante n implementarea restriciilor de integritate:

integritatea entitilor;

integritatea referenial.

R4: Regula privind metadatele

utilizatorii autorizai trebuie s poat aplica asupra descrierii bazei de date aceleai operaii ca i asupra datelor obinuite.

R5: Regula privind facilitile limbajelor de utilizare:

trebuie s existe cel puin un limbaj care s exprime oricare din urmtoarele operaii:

definirea relaiilor;

sa vizualizeze datele;

s regseasc informaia;

s poat reactualiza informaia;

s verifice i s corecteze datele de intrare, etc.

n general, toate implementrile SQL respect aceast regul.

R6: Regula privind actualizarea tabelelor virtuale:

toate tabelele/relaiile virtuale trebuie s poat fi actualizate.

nu toate tabelele virtuale sunt teoretic actualizate.

Exemplu: Fie tabela de baz PROD, cu urmtoarea schem PROD(Denp:D1, Cant:D2, Pret:D3), cu ajutorul tabelei PROD este definit o tabel virtual DISP, cu schema: DISP (Denp:D1, Cant:D2, Pret:D3, Val:D4). Valorile atributului Val se calculeaz astfel:

Val=Cant*Pret.Presupunem c se dorete schimbarea preului unitar la un anumit produs, aceast schimbare trebuie efectuat n tabela de baz PROD, atributul Pret din tabela virtual DISP, fiind actualizabil, ntruct actualizarea se poate propaga spre tabela de baz.

Presupunem c se dorete schimbarea valorii Val la un anumit produs:

modificarea de la tabela virtual spre tabela de baz nu mai este posibil, atributul Val nu este actualizabil, deoarece schimbarea valorii Val se poate datora schimbrii cantitii Cant i/sau a preului unitar Pret.

astfel trebuie s existe un mecanism prin care s se poat determina dac anumite vizualizri pot fi modificate sau nu.

majoritatea implementrilor SQL ndeplinesc aceast cerin.

R7: Regula privind inserrile, modificrile i tergerile din baza de date.

un SGBDR nu trebuie s oblige utilizatorul s caute ntr-o relaie, tuplu cu tuplu, pentru a regsi informaia dorit;

aceast regul exprim cerina ca n operaiile prin care se schimb coninutul bazei de date s se lucreze la un moment dat pe o ntreag relaie.

R8: Regula privind independena fizic a datelor o schimbare a structurii fizice a datelor nu trebuie s blocheze funcionarea programelor de aplicaii;

ntr-un SGBDR trebuie s se separe aspectul fizic al datelor (stocare sau acces la date) de aspectul logic al datelor.

R9: Regula privind independena logic a datelor.

o schimbare a relaiilor bazei de date nu trebuie s afecteze programele de aplicaie.

R10: Regula privind restriciile de integritate

restriciile de integritate trebuie s fie definite ntr-un limbaj relaional, nu n programul de aplicaie.

R11: Regula privind distribuirea geografic a datelor distribuirea datelor pe mai multe calculatoare dintr-o reea de comunicaii de date, nu trebuie s afecteze programele de aplicaie.

R12: Regula privind prelucrarea datelor la nivelul de baz dac sistemul posed un limbaj de baz orientat pe prelucrarea de tupluri i nu pe prelucrarea relaiilor, acest limbaj nu trebuie s fie utilizat pentru a evita restriciile de integritate (se introduc inconsistene).

Clasificarea regulilor lui Codd

n funcie de tipul de cerine pe care le exprim, regulile sunt grupate n 5 categorii:

1. Reguli de baz: R0 i R12;

2. Reguli structurale: R1 i R6;

3. Reguli privind integritatea datelor: R3 i R10;

4. Reguli privind manipularea datelor: R2, R4, R5, R7;

5. Reguli privind independena datelor: R8, R9, R11.

Evaluarea/prelucrarea cerinelor i optimizarea

n SGBDR interfaa cu utilizatorul este de tip neprocedural. Utilizatorul definete datele pe care dorete s le vizualizeze fr a da algoritmi de acces. Sistemul trebuie s converteasc cererea utilizatorului ntr-o cerere optimal.

Evaluarea unei cereri se efectueaz n trei etape:

1. Analiza cererii ce const n studierea sintactic i semantic a cererii pentru a verifica corectitudinea sa i a simplifica criteriului de cutare.

2. Ordonarea presupune:

descompunerea cererii ntr-o mulime de operaii elementare i

determinarea ordinii optimale a acestor aplicaii.

3. Execuia n paralel i/sau secvenial a operaiilor elementare pentru a obine rezultatul cererii. Presupunem c utilizatorul transmite sistemului de gestiune o cerere exprimat prin ordine SQL. Pentru a rspunde cererii, SGBD-ul trebuie s neleag cererea utilizatorului. Cererea trebuie s fie corect sintactic, datele trebuie s fie disponibile utilizatorului i trebuie localizate analiznd diferite drumuri de acces la ele. Ideea general este concretizat n schema de mai jos:

adic optimizarea cererilor de date se realizeaz prin parcurgerea urmtoarelor etape:

1. exprimarea cererilor sub forma unei expresii algebrice relaionale;

2. aplicarea unor transformri algebrice asupra expresiilor obinute n etapa precedent, n scopul executrii mai eficiente a lor;

3. planul de execuie;

4. optimizarea.

Un plan de execuie implic o secven de pai pentru evaluarea cererii (n mod obinuit, fiecare pas din planul de execuie corespunde unei operaii relaionale) precum i metoda care va fi folosit pentru evaluarea operaiei. De obicei, pentru o operaie relaional dat, exist mai multe metode ce pot fi folosite pentru evaluarea acesteia.

Dou planuri de execuie diferite care au ntotdeauna acelai rezultat se numesc echivalente. Planuri de execuie echivalente pot avea diferite costuri. Scopul optimizrii cererilor este de a gsi, printre diversele planuri de execuie echivalente, pe acela de cost minim. ntr-un sistem centralizat, costul evalurii unei cereri este suma a dou componente, costul I/O (transferuri de date) i costul CPU (verificare de condiii, operaii join etc.).

Strategiile de optimizare pot fi de dou tipuri:

1. Strategii generale de optimizare (independente de modul de memorare al datelor);

2. Strategii specifice anumitor SGBDR (in cont de modul de memorare al datelor).

Strategiile generale de optimizare a cererilor de date sunt:

Regula de optimizare 1. Seleciile se execut ct mai devreme posibil. Motivaia acestei reguli este c seleciile reduc substanial dimensiunea relaiilor. Regula de optimizare 2.Produsele carteziene se nlocuiesc cu join-uri, ori de cte ori este posibil. Un produs cartezian ntre dou relaii este de obicei mult mai scump (ca i cost) dect un join ntre cele dou relaii, deoarece primul genereaz concatenarea tuplurilor n mod exhaustiv i poate genera un rezultat foarte mare. Aceast transformare se poate realiza folosind legtura dintre produs cartezian, join i selecie.

Regula de optimizare 3.Dac sunt mai multe join-uri atunci cel care se execut primul este cel mai restrictiv. Un join este mai restrictiv dect altul dac produce o relaie mai mic. Se poate determina care join este mai restrictiv pe baza factorului de selectivitate sau cu ajutorul informaiilor statistice.

Regula de optimizare 4.Proieciile se execut la nceput pentru a ndeprta atributele nefolositoare. Dac un atribut al unei relaii nu este folosit n operaiile ulterioare atunci trebuie ndeprtat. n felul acesta se va folosi o relaie mai mic n operaiile ulterioare. CURS 7. Tehnica normalizrii relaiilor

La proiectarea structurii unei baze de date relaionale trebuie stabilite (dup cum s-a vzut n cursurile anterioare) n primul rnd tabelele n care vor fi memorate datele i asocierile dintre tabele. Acestea sunt stabilite ntr-o form iniial, dup care, prin rafinare succesiv se ajunge la forma definitiv. Acestei structuri iniiale i sunt aplicate un set de reguli care reprezint paii de obinere a unei baze de date normalizate. Dac o baz de date nu este normalizat ea nu poate fi utilizat cu un maxim de eficien. Algoritmul de normalizare a bazelor de date relaionale precum i paii acestuia au fost descrii de ctre E. F. Codd n 1972.

Normalizarea este procesul reversibil de transformare a unei relaii n relaii de structur mai simpl. (Procesul este reversibil n sensul c nici o informaie nu este pierdut n timpul transformrii). Scopul normalizrii este de a suprima redundanele logice i de a evita anomaliile la reactualizare.Exemplu: Pentru a evidenia cteva exemple de redundane i anomalii, se va considera cazul relaiei iniiale OFERTANTI. Pentru a nu ncrca relaia, se vor considera valori ale atributelor prescurtate.

Fig.7.1. Relaia OFERTANTI

Redundana logic: Tripletul (N1, Str. Victoriei, nr.22/12, Baia Mare, Maramures, Nr1) apare de dou ori.

Anomalii la inserare: Dac o persoan ofer spre vnzare mai multe imobile, pentru nregistrarea ofertei trebuie rescris codul numeric personal nc o dat, deci cheia devine duplicat.

Anomalii de tergere: tergerea unei persoane din baza de date atrage dup sine pierderea informaiilor despre oferta respectiv.

Anomalii la modificare: Dac se modific numele strzii Victoriei din localitatea Baia Mare n strada Independenei, modificarea trebuie efectuat pentru fiecare ofert din Baia Mare amplasat pe strada Victoriei. Dac ar exista 25 de oferte n aceast localitate pe strada Victoriei, costul modificrii ar fi mare pentru a modifica toate nregistrrile. Aceast redundan este eliminat dac atributul adresa este mprit n alte trei atribute: simbol_judet, cod_loc, id_strada. Valorile acestea vor fi codul judeului, localitii, respectiv a strzii preluate din relaiile deja existente JUDETE, LOCALITATI, respectiv STRAZI. n acest caz, modificarea se face doar o singur dat, n tabela STRAZI.

Normalizarea

Codd a definit iniial 3 forme normale, notate prin FN1, FN2 i FN3. ntruct ntr-o prim formulare, definiia FN3 ridic ceva probleme, Codd i Boyce au elaborat o nou variant, cunoscut sub numele de Boyce-Codd Normal Form (BCNF). Astfel BCNF este reprezentat separat n majoritatea lucrrilor. R. Fagin a tratat cazul FN4 i FN5.

O relaie este ntr-o form normal dac satisface o mulime de constrngeri specificat n figura 7.2. De exemplu, se spune c o relaie se afl n a doua form normal FN2 dac i numai dac se afl n FN1.

Fig.7.2. Formele normale ale relaiilor dintr-o BDR

Normalizarea bazei de date relaionale poate fi imaginat ca un proces prin care pornindu-se de la relaia iniial/universal R se realizeaz descompunerea succesiv a acesteia n subrelaii, aplicnd operatorul de proiecie. Relaia R poate fi ulterior reconstruit din cele n relaii obinute n urma normalizrii, prin operaii de jonciune.

7.1 Prima form normal (FN1)

FN1 este strns legat de noiunea de atomicitate a atributelor unei relaii. Astfel, aducerea unei relaii n FN1 presupune introducerea noiunilor de:

atribut simplu;

atribut compus;

grupuri repetitive de atribute.

Atributul simplu- Atribut compus

Prin atribut simplu (atribut atomic) se nelege un atribut care nu mai poate fi descompus n alte atribute, n caz contrar, atributul este compus (atribut neatomic). Exemplu: Urmtoarele exemple de atribute pot fi considerate simple sau compuse n funcie de circumstane i de obiectivele bazei de date.

Data calendaristic este un atribut n care apar cmpurile: zi, lun, an;

Adresa este un atribut n care apar cmpurile: strada, nr, bloc, scara, etaj, apartament, localitate, jude;

Data operaiunii bancare este un atribut n care apar cmpurile data, ora;

Buletin/carte identitate este un atribut n care apar cmpurile: seria, nr.

Aceste atribute pot fi atomice sau neatomice. Astfel adresa clienilor ageniei imobiliare intereseaz la nivel global, pe cnd pentru adresa ofertei sau a cererii de imobile este vital pentru prelucrarea separat a fiecrui cmp considerat.

Analog, atributul nume reprezint un atribut simplu al acestei baze de date, deoarece numele clientului intereseaz la nivel global.

Grupuri repetitive de atribute

Un grup repetitiv este un atribut (grup de atribute) dintr-o relaie care apare cu valori multiple pentru o singur apariie a cheii primare a relaiei nenormalizate. Exemplu: Fie relaia nenormalizat (primar) FACTURI. Dorim s stabilim o structur de tabele care s permit stocarea informaiilor coninute n document (factur) i obinerea unor situaii sintetice privind evidena sumelor facturate pe produse, pe clinei, pe anumite perioade de timp.

Fig. 7.3. Relaia FACTURI nenormalizat

n cazul n care o factur conine mai multe produse, relaia de mai sus va avea grupurile repetitive: cod_produs, denumire_produs, cantitate, pret_unitar, valoare, valoare_tva.Aducerea unei relaii universale la FN1

FN1 este tratat n general cu superficialitate, deoarece principala cerin atomicitatea valorilor este uor de ndeplinit (cel puin la prima vedere).

Dintre toate formele normale, doar FN1 are caracter de obligativitate. Se spune c o baz de date este normalizat daca toate relaiile se afl mcar n FN1.

O relaie este n FN1 dac domeniile pe care sunt definite atributele relaiei sunt constituite numai din valori atomice. Un tuplu nu trebuie s conin atribute sau grupuri de atribute repetitive.

Aducerea relaiilor n FN1 presupune eliminarea atributelor compuse i a celor repetitive.

Se cunosc trei soluii pentru determinarea grupurilor repetitive:

eliminarea grupurilor repetitive pe orizontal (n relaia R iniial, n locul atributelor compuse se trec componentele acestora, ca atribute simple);

eliminarea grupurilor repetitive prin adugarea de tupluri;

eliminarea grupurilor repetitive prin construirea de noi relaii.

Primele dou metode genereaz relaii stufoase prin duplicarea forat a unor atribute, respectiv tupluri, crendu-se astfel redundane masive cu multiple anomalii de actualizare.

Metoda a treia presupune eliminarea grupurilor repetitive prin construirea de noi relaii, ceea ce genereaz o structur ce ofer cel mai mic volum de redundan.

Etapele de aducere a unei relaii n FN1 sunt:

I. se construiete cte o relaie pentru fiecare grup repetitiv;

II. n schema fiecrei noi relaii obinute la pasul 1 se introduce i cheia primar a relaiei R nenormalizate;

III. cheia primar a fiecrei noi relaii va fi compus din atributele chei ale relaiei R, plus unul sau mai multe atribute proprii. Exemplu: Deoarece o factur poate avea unul sau mai multe produse nscrise pe aceasta, informaiile legate de produse vor fi separate ntr-o alt tabel. Aplicnd etapele de aducere la FN1, se obin dou relaii:

Fig. 7.4. Relaia FACTURI adus n forma normal FN1Observaia1: Cmpul adresa_client curpinde informaii despre judeul, localitatea, strada i numrul domicililului clientului. Dac se consider c este de interes o eviden a sumelor factorizate pe judee sau localiti, se vor pune n locul cmpului adresa_client trei cmpuri distincte: judet_client, localitate_client, adresa_client, uurnd n acest fel interogrile. Observaia2: ntre tabela FACTURI i tabela LINII_FACTURI exist o relaie de unu la muli, adic unui numr unic de factur i pot corespunde unul sau mai multe produse care sunt memorate ca nregistrri n tabele LINII_FACTURI. Cheia primar n aceast tabel este o cheie compus, format din dou cmpuri: nr_factura i cod_produs. ns eliminarea grupurilor repetitive, adic aducerea unei relaii la FN1, nu rezolv complet problema normalizrii.7.2. A doua form normal (FN2)

FN2 este strns legat de noiunea de dependen funcional. Noiunea de dependen funcional a fost prezentat n cursul 5: Restricii de integritate ale modelului relaional.

O relaie se afl n a doua form normal FN2 dac:

1. se afl n forma normal FN1 i

2. fiecare atribut care nu este cheie este dependent de ntreaga cheie primar.

Etapele de aducere a unei relaii de la FN1 la FN2 sunt:

I. Se identific posibila cheie primar a relaiei aflate n FN1;

II. Se identific toate dependenele dintre atributele relaiei, cu excepia acelora n care sursa este un atribut component al cheii primare;

III. Se identific toate dependenele care au ca surs un atribut sau subansamblu de atribute din cheia primar;

IV. Pentru fiecare atribut (sau subansamblu) al cheii de la pasul III se creeaz o relaie care va avea cheia primar atributul (subansamblul) respectiv, iar celelalte atribute vor fi cele care apar ca destinaie n dependenele de la etapa III.

Exemplu: Relaia care conine date redundane (de exemplu, modificarea denumirii unui produs atrage dup sine modificarea n fiecare tuplu n care apare acest produs) este relaia LINII_FACTURI. Se observ ca nu exist nici o dependen funcional ntre atributele necomponente ale cheii. n schimb, toate atributele care nu intr n alctuirea cheii compuse sunt dependente de aceasta, iar DF dintre atributul component al cheii primare sunt: cod_produs --> denumire_produs, cod_produs --> unitate_de_masura. Ca urmare se formeaz nc dou relaii.

Fig. 7.5. Relaia FACTURI n a doua forma normal FN2

Chiar dac au fost eliminate o parte din redundane, mai rmn i alte redundane ce se vor elimina aplicnd alte forme normale.

CURS 8. A treia form normal

7.3. A treia form normal (FN3)

O relaie este n forma normal trei FN3 dac:

1. se gsete n FN2 i

2. fiecare atribut care nu este cheie (nu particip la o cheie) depinde direct de cheia primar.

A treia regul de normalizare cere ca toate cmpurile din tabele s fie independente ntre ele.

Etapele de aducere a unei relaii de la FN2 la FN3 sunt:

I. Se identific toate atributele ce nu fac parte din cheia primara i sunt surse ale unor dependene funcionale;

II. Pentru aceste atribute, se construiete cte o relaie n care cheia primar va fi atributul respectiv, iar celelalte atribute, destinaiile din DF considerate;

III. Din relaia de la care s-a pornit se elimin atributele destinaie din DF identificat la pasul I, pstrndu-se atributele surse.Exemplu: n relaia FACTURI se observ c atributul nume_client determin n mod unic atributele adresa_client, banca_client i nr_cont_client. Deci pentru atributul nume_client se construiete o relaie CLIENTI n care cheia primar va fi acest atribut, iar celelalte atribute vor fi adresa_client, banca_client i nr_cont_client. Cmpurile valoare i valoare_tva depind de cmpurile cantitate, pret_unitar, i de un procent fix de TVA. Fiind cmpuri ce se pot calcula n orice moment ele vor fi eliminate din tabel LINII FACTURI deoarece constituie informaie memorat redundant.

Fig. 8.1. Relaia FACTURI n a treia forma normal FN3

Observaia 1: Aceast a treia form normal mai poate suferi o serie de rafinri pentru a putea obine o structur performant de tabele ale bazei de date. De exemplu se observ c nume_client este un cmp n care este nscris un text destul de lung format dintr-o succesiune de litere, semne speciale (punct, virgul, cratim), spaii, numere. Ordonarea i regsirea informaiilor dup astfel de cmpuri este lent i mai greoaie dect dup cmpuri numerice. Din acest motiv se poate introduce un nou atribut cod_client care s fie numeric i care s fie cheia primar de identificare pentru fiecare client.

Observaia 2: O alt observaie care poate fi fcut n legtur cu tabelele aflate n cea de a treia form normal este aceea c total_valoare_factura este un cmp care ar trebui s conin informaii sintetice obinute prin nsumarea valorii tuturor ofertelor aflate pe o factur. Este de preferat ca astfel de cmpuri s fie calculate n rapoarte sau interogri i s nu fie memorate n tabelele bazei de date.

Verificarea aplicrii corecte a procesului de normalizare se realizeaz astfel nct uniunea acestor relaii s produc relaia iniial, cu alte cuvinte, descompunerea este fr pierderi.

Celelalte forme normale se ntlnesc mai rar n practic. Aceste forme nu sunt respectate, n general, pentru c beneficiile de eficien pe care le aduc nu compenseaz costul i munca de care este nevoie pentru a le crea.

LMD

LMD

LDD

LMD, LDD

1. Analiza

3. ncrcarea datelor

2. Proiectarea

Baza de date

4. ntreinerea

4. Exploatarea

DATE_ PERSOANA

CERERI_ OFERTE

DESCRIERE_IMOBIL

STRAZI

JUDETE

LOCALITATI

FACTURI

CERERI_OFERTE

sunt finalizate

prin

FACTURI

(1,1)

(0,1)

CERERI_OFERTE

1

2

3

FACTURI

F1

F2

A

(...,1)

E1

E2

(...,1)

E1

E2

A

(...,1)

(...,n)

E1

E2

A

(...,n)

(...,1)

LOCALITATI

L1

L2

L3

CERERI_OFERTE

1

2

3

A

B

(0,n)

(1,1)

LOCALITATI

CERERI_OFERTE

i corespunde

A

(...,n)

E1

E2

(...,n)

DEPOZIT

D1

D2

D3

PRODUS

P1

P2

P3

DEPOZIT

PRODUS

nmagazi

neaz

(0,n)

(0,n)

Din

E1

E2

(...,n)

(...,n)

n

E1

E

E2

(...,1)

(...,n)

(...,n)

(...,1)

A

A1

A2

a)

b)

DEPOZIT

D1

D2

D3

D4

....

PRODUS

P1

P2

P3

P4

...

DEPOZIT_

PRODUS

D1-P1

D1-P3

D2-P2

D3-P2

....

(1,n)

asociaz

asociaz

(0,n)

(0,n)

(1,n)

E1

E2

E1

E2

A

A

a)

b)

(0,)

(,)

(,)

(0,)

E1

E2

A

a)

(1,)

(1,)

E1

E2

(1,)

(n,)

E1

E2

(n,)

(n,)

E1

E2

(n,)

(1,)

b)

c)

d)

A

A

A

CERERI_OFERTE

1

2

3

FACTURI

F1

F2

CERERI_OFERTE

1

2

3

DESCRIERE_IMOBIL

I1

I2

I3

LOCALITATI

L1

L2

L3

CERERI_OFERTE

1

2

3

CLASE

C1

C2

C3

ELEVI

E1

E2

E3

E4

DEPOZIT

D1

D2

D3

D4

PRODUS

P1

P2

P3

CURSURI

C1

C2

C3

STUDENTI

S1

S2

S3

S4

E

a

(a)

E

a#

(b)

(0,n)

STRAZI

LOCALITATI

JUDETE

DATE_PERSOANA

FACTURI

CERERI_ OFERTE

DESCRIERE _IMOBIL

are asociat

finisate

conin

conin

(1,1)

(1,1)

(0,n)

are asociat

se regsete

(1,1)

(1,n)

(1,n)

(1,1)

(1,1)

(1,1)

(0,1)

(1,1)

incheie

(1,1)

(0,1)

CERERI_OFERTE

tipul

data_inreg

cod_loc

id_strada

nr_imobil

pret_max

tip_solutionare

cnp

pret_min

id_co#

DATE_PERSOANA

cnp#

numele

adresa

nr_telefon

email

banca_client

nr_cont_client

STRZI

id_strada#

cod_loc#

nume_str_

LOCALITATI

cod_loc#

simbol_judet#

nume_loc

JUDETE

simbol_judet#

nume_judet

CERERI-OFERTE

id_co #

tip

cnp

data_inreg

tip_solutionare

cod_loc

id_strada

nr_imobil

pret_min

pret_max

DESCRIERE_IMOB IL

id_co#

tip_imobil

etaj

nr_camere

suprafata

garaj

centrala_termica

termopane

FACTURI

nr_factura#

id_oferta

data_factura

cnp

pret

TVA

total

FormalUzualFizicRelaieTablouFiierTupluLinienregistrareAtributColoanCampDomeniuTip de datTip de dat

R1

R3

R2

idtipulcnptip_solutionare210cerere2820506300898Da1316cerere1881106300897Da

idtipulcnptip_solutionare1066oferta2660805270023Da1210oferta1881106300897Da220cerere2820506300898Da1316cerere1881106300897Da

ARHIVA_CERERI:

ARHIVA_OFERTE:

REZ:

idtipulcnptip_solutionare1066oferta2660805270023Da1210oferta1881106300897Da

R1

R3

R2

-

idcnptip_solutionare02212820506300898Da12101881106300897Da31612690125270032Da

idcnptip_solutionare20662660805270023Da

ARHIVA_CERERI:

ARHIVA_OFERTE:

REZ:

idcnptip_solutionare12101881106300897Da20662660805270023Da

-

R1

R3

R2

EMBED Equation.3

LOCALIT:

TARIFE:

TRANSPORT:

Localit:D1Jude:D1Transport:D3Tarif: D4Baia MareMaramureautobus11 000BraovBraovautobuz11 000Baia MareMaramuretroleibuz10 000BraovBraovtroleibuz10 000

Transport: D3Tarif: D4autobuz11 000troleibuz10 000

Localit:D1Jude:D1Baia MareMaramureBraovBraov

EMBED Equation.3

Ai,Aj,...,Am

P

R

REZ:

numelenr_telefonPop Ana-Sas Ioan0362/409209

numele,

nr_telefon

cnpnumeleadresanr_telefonemail1701205230032Pop AnaStr. Viilor, nr.55/4, Oradea, Bihor-

pa@yahoo.it

2660805270023Sas IoanStr. Victoriei, nr.22/12, Baia Mare, Maramures0362/409209-

DATE_PERSOANA:

atribut, operator de comparaie, valoare

S

R

condiie

id_ co#tipulcnp data_ inregCod_locId_ stradaNr_ imobiletajPret_minPret_ maxId_confort12oferta26608052700232006-05-27CJ14712022P45470012

id_ co#tipulcnp data_ inregCod_locId_ stradaNr_ imobiletajPret_minPret_ maxId_confort12oferta26608052700232006-05-27CJ14712022P4547001313oferta17012052300232006-07-03BV23012052230350012

OFERTE VECHI:

data_nreg