Sunteți pe pagina 1din 7

Cap. 3 MODELUL DE DATE RELAIONAL Sistemele relaionale se bazeaz pe un formalism sau o teorie numit modelul de date relaional.

Adeseori, modelul relaional este descris ca avnd urmtoarele trei caracteristici: Caracteristica structural: datele din baza de date sunt percepute de utilizator sub form de tabele i numai tabele. Caracteristica de asigurare a integritii: aceste tabele satisfac anumite restricii de integritate. Caracteristica de asigurare a manipulrii: operatorii pui la dispoziie utilizatorilor ca s manipuleze aceste tabele de exemplu, n scopul consultrii datelor deriv tabele din alte tabele. Dintre aceti operatori, trei sunt deosebii de importani, i anume: selecia (restricia), proiecia i uniunea. O baz de date relaional simpl, cum este cea pentru departamente i angajai, este prezentat n Figura 3.1. Dup cum se poate observa, baza de date este ntr-adevr perceput sub form de tabele. n Figura 3.2 sunt prezentate cteva exemple de operaii de restricie, proiecie i uniune efectuate n baza de date din Figura 3.1 mai jos sunt prezentate (n mare) definiiile acestor operaii: Operaia de restricie permite extragerea anumitor rnduri din tabel. Restricia este numit i selecie; preferm termenul de restricie deoarece operatorul nu este identic cu operaia SELECT din limbajul SQL. Operaia de proiecie permite extragerea coloanelor specificate din tabel. Operaia de uniune permite combinarea a dou tabele ntr-una singur, pe baza valorilor comune din cadrul unei colane comune. DEPT DEPT# D1 D2 D3 ANG ANG# E1 E2 E3 E4 NUMEA Lopez Cheng Finzi Saito DEPT# D1 D1 D2 D2 SALARIU 40K 42K 30K 35K NUMED Marketing Dezvoltare Cercetare BUGET 10M 12M 5M

Figura 3.1 Baza de date pentru departamente i angajai

Restricia tabelei DEPT unde BUGET > 8M Rezultat: DEPT# D1 D2 NUMED Marketing Dezvoltare BUGET 10M 12M

Proiecia tabelei DEPT dup DEPT#, BUGET

DEPT# D1 D2 D3

BUGET 10M 12M 5M

Uniunea tabelelor DEPT i ANG dup DEPT# Rezultat: DEPT# D1 D1 D2 D2 NUMED Marketing Marketing Dezvoltare Dezvoltare BUGET 10M 10M 12M 12M ANG# E1 E2 E3 E4 NUMEA Lopez Cheng Finzi Saito SALARIU 40K 42K 30K 35K

Figura 3.2 Operaiile de restricie, proiecie i uniune (exemple) Dintre exemplele din Figura 3.2, singurul care necesit explicaii suplimentare este cel de uniune. Uniunea necesit ca cele dou tabele s aib o coloan comun, aa cum se ntmpl n cazul tabelelor DEPT i ANG (ambele au o coloan pentru DEPT#), astfel nct pot fi unite pe baza valorilor comune din aceasta. Mai exact, un anumit rnd
2

din tabela DEPT va fi unit cu un anumit rnd din tabela ANG (pentru a produce un rnd din tabela rezultat) dac i numai dac cele dou rnduri au o valoare comun pentru DEPT#. De exemplu, rndurile DEPT i ANG: DEPT# D1 ANG# E1 NUMED Marketing NUMEA Lopez BUGET 10M DEPT# D1 SALARIU 40K

sunt unite pentru a produce rndul rezultat: DEPT# NUMED D1 Marketing BUGET 10m ANG# E1 NUMEA Lopez SALARIU 40k

deoarece au aceeai valoare, D1, n coloana comun. Observm c valoarea comun apare n rndul rezultat o singur dat, nu de dou ori. Rezultatul general al operaiei de uniune conine toate rndurile posibile care pot fi obinute n acest mod i nici un alt rnd suplimentar. Observm, n particular, c din moment ce nici un rnd din tabela ANG nu are valoarea D3 n coloana DEPT# (adic nici un angajat nu este atribuit acestui departament), n rezultat nu apare nici un rnd pentru valoarea D3, dei exist n tabela DEPT un rnd care conine valoarea D3. Un aspect prezentat clar n Figura 3.2 este c rezultatul fiecreia dintre cele trei operaii este o alt tabel (cu alte cuvinte, operatorii sunt cu adevrat de tipul celor care deriv tabele din tabele, aa cum am artat mai sus). Aceasta este proprietatea de nchidere a sistemelor relaionale i este foarte important. n esen, deoarece rezultatul oricrei ieiri este acelai tip de obiect ca intrarea toate sunt tabele ieirea unei operaii poate deveni intrare pentru alt operaie. Astfel, este posibil, de exemplu, s se efectueze o proiecie a unei uniuni, o uniune a dou restricii, o restricie a unei proiecii etc. Cu alte cuvinte, se pot scrie expresii relaionale imbricate adic, expresii relaionale n care operanzii nii sunt reprezentai prin expresii relaionale, nu neaprat prin simple nume de tabele. Exist nc dou aspecte care trebuie evideniate n legtur cu exemplul de baz de date din Figura 3.1: Sistemele relaionale necesit doar ca baza de date s fie perceput de utilizator sub forma unor tabele. Tabela reprezint structura logic dintr-un sistem relaional, nu structura fizic. De fapt, la nivel fizic, sistemul este liber s stocheze datele dup cum i place - folosind fiiere secveniale, indexri, dispersri, nlnuiri de pointeri etc. doar cu condiia s poat realiza corespondena dintre aceast reprezentare stocat i tabelele de la nivelul logic. Putem exprima acelai lucru i prin faptul c tabelele reprezint o abstractizare a modului n care datele sunt stocate fizic o abstractizare n care numeroase detalii la nivel de stocare sunt ascunse fa de utilizator. Bazele de date relaionale respect un principiu foarte interesant, numit principiul informaiei: ntregul coninut informaional al bazei de date este reprezentat numai ntrun singur mod i anume, ca valori explicite ale coloanelor poziionate pe rndurile unor tabele. Aceast metod de reprezentare este singura disponibil (la nivel logic,

desigur) ntr-un sistem relaional. n particular, nu exist pointeri, care s conecteze o tabel cu alta. De exemplu, n Figura 3.1 exist o legtur ntre rndul D1 din tabela DEPT i rndul E1 din tabela ANG, deoarece angajatul E1 lucreaz n departamentul D1. Dar aceast legtur este reprezentat nu printr-un pointer, ci prin apariia valorii D1 n poziia DEPT# din rndul ANG pentru valoarea E1. prin contrast, n sistemele nonrelaionale, astfel de informaii sunt reprezentate, de obicei, printr-un tip oarecare de pointer, care este vizibil explicit pentru utilizator. Vom considera din nou baza de date pentru departamente i angajati, din Figura 3.1. practic, ar putea fi necesar ca aceast baz de date s satisfac orice numr de restricii de integritate de exemplu, salariile angajailor ar putea fi cuprinse ntre 25K i 95K, bugetele departamentelor ar putea fi cuprinse ntre 1M i 15M, .a.m.d. Dar, cteva dintre aceste restricii prezint o importan pragmatic att de mare nct se bucur de o nomenclatur special. Mai exact: 1. Fiecare rnd din tabela DEPT trebuie s includ o valoare DEPT# unic; de asemenea, fiecare rnd din tabela ANG trebuie s cuprind o valoare ANG# unic. Spunem c cele dou coloane, DEPT# i ANG#, din tabelele DEPT, respectiv ANG, sunt chei primare pentru tabelele respective. 2. Fiecare valoare DEPT# din tabela ANG trebuie s existe ca valoare DEPT# n tabela DEPT, pentru a reflecta faptul c fiecare angajat trebuie atribuit unui departament existent. Spunem c n tabela ANG, coloana DEPT# este o cheie strin, care se refer la cheia primar a tabelei DEPT. Sistemele relaionale se bazeaz pe modelul relaional. La rndul su, modelul relaional este o teorie abstract despre date, care se bazeaz pe anumite aspecte matematice (n principal, teoria mulimilor i logica predicatelor). Principiile modelului relaional au fost stabilite iniial n perioada 1969-70, de ctre E.F. Codd, pe atunci cercettor la IBM. La sfritul anului 1968, Codd un matematician prin formaie a descoperit c matematica ar putea fi utilizat pentru a insera o serie de principii solide i riguroase ntr-un domeniu (gestiunea bazelor de date) care, nainte de acel moment, era mult prea deficitar n aceast privin. Ideile lui Codd au fost expuse pe larg prima dat n cadrul unui articol, devenit acum clasic, intitulat A Relational Model of Data for Large Shared Data Banks. De atunci, aceste idei acum aproape universal acceptate au avut o influen larg n aproape fiecare aspect al tehnologiei bazelor de date, ca i n alte domenii, cum ar fi inteligena artificial, prelucrarea n limbaj natural i proiectarea sistemelor hardware. n modelul relaional, aa cum a fost formulat iniial de ctre Codd, erau utilizai anumii termeni cum ar fi cel de relaie, tuplu, atribut. Termenul de tuplu corespunde aproximativ noiunii de rnd, tot aa cum termenul de relaie corespunde aproximativ noii de tabel. n acelai context, modelul relaional nu utilizeaz termenul de cmp; n schimb folosete termenul de atribut, care putem spune c ar corespunde aproximativ noiunii de coloan dintr-o tabel. Tupluri Vom ncepe prin a defini termenul de tuplu. Considerm o mulime nevid de simboluri, notat cu U, ale crei elemente se vor numi nume de atribute.

Fie U={A1, A2, , An}. Pentru fiecare nume de atribut Ai se asociaz un tip Ti ,i=1,2, , n, unde Ti nu sunt neaprat distincte. Un tuplu t este o mulime de triplete ordonate, de forma <Ai, Ti, vi>, unde Ai este numele unui atribut, Ti este numele unui tip iar vi este o valoare de tipul Ti. Valoarea n reprezint gradul sau aritatea lui t. Tripletul ordonat < Ai, Ti, vi> este o component a lui t. Perechea ordonat < Ai, Ti> este un atribut al lui t i este identificat n mod unic de ctre numele atributului Ai (numele atributelor Ai i Aj sunt aceleai numai dac i=j). Valoarea vi este valoarea atributului Ai al lui t. Tipul Ti este tipul atributului corespunztor. Mulimea complet de atribute este antetul lui t. Mai jos este prezentat un exemplu de tuplu: MAJOR_C# : C# C2 MINOR_C : C# C4 CANT : CANT 7

Aici numele atributelor sunt MAJOR_C#, MINOR_C# i CANT; numele tipurilor corespunztoare sunt C#, C# i Cant; valorile corespunztoare sunt C2, C4, i 7. Gradul acestui tuplu este trei. Antetul s este: MAJOR_C# : C# MINOR_C : C# CANT : CANT Observaie n contextele lipsite de formalism, se obinuiete s se omit numele din antetul tuplului, indicnd doar numele atributelor. Prin urmare, mai puin formal, am putea reprezenta tuplul anterior astfel: MAJOR_C# MINOR_C CANT

Proprietile tuplurilor: Fiecare tuplu conine exact o valoare (de tipul adecvat) pentru fiecare dintre atributele sale. Nu exist o ordonare de la stnga la dreapta a componentelor tuplului. Aceast proprietate se datoreaz faptului c tuplul este definit ca o mulime de componente iar n matematic, mulimile nu au o ordine a elementelor. Fiecare submulime a unui tuplu este un tuplu (iar fiecare submulime a unui antet este un antet). Dou tupluri t1 i t2 sunt egale (adic expresia t1=t2 este adevrat) dac i numai dac au aceleai atribute A1, A2, , An i, pentru toi indicii i (i=1,2, , n), valoarea vi1 a lui Ai din t1 este egal cu valoarea vi2 a lui Ai din t2. Tuplurile t1 i t2 sunt duplicate dac i numai dac sunt egale. Relaii O relaie s zicem r - este format dintr-un antet i un cuprins.

Antetul relaiei r este antetul unui tuplu, aa cum a fost definit anterior. Relaia are aceleai atribute (i prin urmare, aceleai nume i tipuri de atribute) i acelai grad ca i acest antet. Cuprinsul relaiei r este o mulime de tupluri, toate avnd acelai antet; cardinalitatea mulimii de tupluri este cardinalitatea relaiei r (n general, cardinalitatea unei mulimi reprezint numrul de elemente ale acesteia). Mai jos este prezentat un exemplu de relaie : MAJOR_C# : C# C1 C1 C2 C2 C3 C4 MINOR_C : C# C2 C3 C3 C4 C5 C6 CANT : CANT 5 3 2 7 4 8

n contextele lipsite de formalism, se obinuiete s se omit numele tipurilor din antetul relaiei, indicnd doar numele atributelor. Prin urmare, am putea reprezenta relaia anterioar astfel: MAJOR_C# MINOR_C CANT C1 C2 5 C1 C3 3 C2 C3 2 C2 C4 7 C3 C5 4 C4 C6 8 Proprietile relaiilor: Fiecare tuplu conine exact o valoare (de tipul adecvat) pentru fiecare atribut. Nu exist ordonare a atributelor de la stnga la dreapta. Nu exist o ordonare a tuplurilor de jos n sus. Nu exist tupluri duplicat. Relaii i tabele n acest subparagraf vom prezenta o list a ctorva dintre deosebirile principale dintre obiectul formal reprezentat de o relaie i obiectul neformal reprezentat de o tabel, care constituie o imagine neformal, pe hrtie, a acestui obiect formal. Fiecare atribut din antetul unei relaii presupune un nume al tipului, dar aceste nume de tipuri sunt omise din imaginile sub form de tabel. Fiecare component a fiecrui tuplu din cuprinsul unei relaii presupune un nume i un tip al atributului, dar acestea sunt omise din imaginile sub form de tabel. Coloanele unei tabele au o ordine de la stnga la dreapta, dar atributele unei relaii nu. Rndurile unei tabele au o ordine de sus n jos, dar tuplurile unei relaii nu.

O tabel poate conine rnduri duplicat, dar o relaie nu conine tupluri duplicat. Tabelele sunt considerate ca avnd cel puin o coloan, n timp ce nu este obligatoriu ca relaiile s aib cel puin un atribut. Tabelele cel puin n limbajul SQL pot cuprinde null-uri, n timp ce relaiile nu. Din toate cele de mai sus, rezult c, pentru a putea accepta faptul c o imagine de forma unei tabele poate fi privit ca reprezentnd o relaie, trebuie s cdem de acord privind modul de citire a unei stfel de imagini; cu alte cuvinte, trebuie s acceptm anumite reguli de interpretare a cestor imagini. Mai exact, trebuie s acceptm c, pentru fiecare coloan exist un tip aflat la baz; c fiecare valoare a unui atribut este o valoare de tipul adecvat; c ordonrile rndurilor i ale coloanelor nu sunt relevante i c nu sunt permise rnduri duplicat. Acum putem vedea c tabela i relaia nu sunt chiar acelai lucru (dei, adeseori, este comod s pretindem c ar fi). n schimb, relaia este ceea ce arat definiia sa, adic un tip de obiect abstract, n timp ce tabela este o imagine concret, de regul pe hrtie, a unui astfel de obiect abstract. Ele nu sunt acelai lucru. Un avantaj major al modelului relaional const n aceea c obiectul d de baz abstract relaia are o reprezentare att de simpl pe hrtie. Aceast reprezentare simpl este cea care face ca sistemele relaionale s fie uor de utilizat i de neles i cea care face ca nelegerea modului de comportare a sistemelor relaionale s fie simpl.