MODELUL DE DATE RELATIONAL

MODELUL DE DATE RELAŢIONAL

Sistemele relationale se bazeaza pe un formalism sau o teorie numita modelul de date relational. Adeseori, modelul relational este descris ca având urmatoarele trei caracteristici:

Caracteristica structurala: datele din baza de date sunt percepute de utilizator sub forma de tabele si numai tabele.

Caracteristica de asigurare a integritatii: aceste tabele satisfac anumite restrictii de integritate.

Caracteristica de asigurare a manipularii: operatorii pusi la dispozitie utilizatorilor ca sa manipuleze aceste tabele - de exemplu, în scopul consultarii datelor - deriva tabele din alte tabele. Dintre acesti operatori, trei sunt deosebiti de importanti, si anume: selectia (restrictia), proi 545j94f ectia si uniunea.

O baza de date relationala simpla, cum este cea pentru departamente si angajati, este prezentata în Figura 3.1. Dupa cum se poate observa, baza de date este într-adevar "perceputa sub forma de tabele". În Figura 3.2 sunt prezentate câteva exemple de operatii de restrictie, proiectie si uniune efectuate în baza de date din Figura 3.1. Mai jos sunt prezentate (în mare) definitiile acestor operatii:

Operatia de restrictie permite extragerea anumitor rânduri din tabela. Restrictia este numita si selectie; preferam termenul de restrictie deoarece operatorul nu este identic cu operatia SELECT din limbajul SQL.

Operatia de proiectie permite extragerea coloanelor specificate din tabela.

Operatia de uniune permite combinarea a doua tabele într-una singura, pe baza valorilor comune din cadrul unei coloane comune.

Figura 3.1 Baza de date pentru departamente si angajati

Figura 3.2 Operatiile de restrictie, proiectie si uniune (exemple)

Dintre exemplele din Figura 3.2, singurul care necesita explicatii suplimentare este cel de uniune. Uniunea necesita ca cele doua tabele sa aiba o coloana comuna, asa cum se întâmpla în cazul tabelelor DEPT si ANG (ambele au o coloana pentru DEPT#), astfel încât pot fi unite pe baza valorilor comune din aceasta. Mai exact, un anumit rând din tabela DEPT va fi unit cu un anumit rând din tabela ANG (pentru a produce un rând din tabela rezultata) daca si numai daca cele doua rânduri au o valoare comuna pentru DEPT#. De exemplu, rândurile DEPT si ANG:

sunt unite pentru a produce rândul rezultat:

deoarece au aceeasi valoare, D1, în coloana comuna. Observam ca valoarea comuna apare în rândul rezultat o singura data, nu de doua ori. Rezultatul general al operatiei de uniune contine toate rândurile posibile care pot fi obtinute în acest mod si nici un alt rând suplimentar. Observam, în particular, ca din moment ce nici un rând din tabela ANG nu are valoarea D3 în coloana DEPT# (adica nici un angajat nu este atribuit acestui departament), în rezultat nu apare nici un rând pentru valoarea D3, desi exista în tabela DEPT un rând care contine valoarea D3.

Un aspect prezentat clar în Figura 3.2 este ca rezultatul fiecareia dintre cele trei operatii este o alta tabela (cu alte cuvinte, operatorii sunt cu adevarat de tipul celor care "deriva tabele din tabele", asa cum am aratat mai sus). Aceasta este proprietatea de închidere a sistemelor relationale si este foarte importanta. În esenta, deoarece rezultatul oricarei iesiri este acelasi tip de obiect ca intrarea - toate sunt tabele - iesirea unei operatii poate deveni intrare pentru alta operatie. Astfel, este posibil, de exemplu, sa se efectueze o proiectie a unei uniuni, o uniune a doua restrictii, o restrictie a unei proiectii etc. Cu alte cuvinte, se pot scrie expresii relationale imbricate - adica, expresii relationale în care operanzii însisi sunt reprezentati prin expresii relationale, nu neaparat prin simple nume de tabele.

Exista înca doua aspecte care trebuie evidentiate în legatura cu exemplul de baza de date din Figura 3.1:

Sistemele relationale necesita doar ca baza de date sa fie perceputa de utilizator sub forma unor tabele. Tabela reprezinta structura logica dintr-un sistem relational, nu structura fizica. De fapt, la nivel fizic, sistemul este liber sa stocheze datele dupa cum îi place - folosind fisiere secventiale, indexari, dispersari, înlantuiri de pointeri etc. - doar cu conditia sa poata realiza corespondenta dintre aceasta reprezentare stocata si tabelele de la nivelul logic. Putem exprima acelasi lucru si prin faptul ca tabelele reprezinta o abstractizare a modului în care datele sunt stocate fizic - o abstractizare în care numeroase detalii la nivel de stocare sunt ascunse fata de utilizator.

Bazele de date relationale respecta un principiu foarte interesant, numit principiul informatiei: întregul continut informational al bazei de date este reprezentat numai într-un singur mod - si anume, ca valori explicite ale coloanelor pozitionate pe rândurile unor tabele. Aceasta metoda de reprezentare este singura disponibila (la nivel logic, desigur) într-un sistem relational. În particular, nu exista pointeri, care sa conecteze o tabela cu alta. De exemplu, în Figura 3.1 exista o legatura între rândul D1 din tabela DEPT si rândul E1 din tabela ANG, deoarece angajatul E1 lucreaza în departamentul D1. Dar aceasta legatura este reprezentata nu printr-un pointer, ci prin aparitia valorii D1 în pozitia DEPT# din rândul ANG pentru valoarea E1. prin contrast, în sistemele nonrelationale, astfel de informatii 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 si angajati, din Figura 3.1. practic, ar putea fi necesar ca aceasta baza de date sa satisfaca orice numar de restrictii de integritate - de exemplu, salariile angajatilor ar putea fi cuprinse între 25K si 95K, bugetele departamentelor ar putea fi cuprinse între 1M si 15M, s.a.m.d. Dar, câteva dintre aceste restrictii prezinta o importanta pragmatica atât de mare încât se bucura de o nomenclatura speciala. Mai exact:

Fiecare rând din tabela DEPT trebuie sa includa o valoare DEPT# unica; de asemenea, fiecare rând din tabela ANG trebuie sa cuprinda o valoare ANG# unica. Spunem ca cele doua coloane, DEPT# si ANG#, din tabelele DEPT, respectiv ANG, sunt chei primare pentru tabelele respective.

Fiecare valoare DEPT# din tabela ANG trebuie sa existe ca valoare DEPT# în tabela DEPT, pentru a reflecta faptul ca fiecare angajat trebuie atribuit unui departament existent. Spunem ca în tabela ANG, coloana DEPT# este o cheie straina, care se refera la cheia primara a tabelei DEPT.

Sistemele relationale se bazeaza pe modelul relational. La rândul sau, modelul relational este o teorie abstracta despre date, care se bazeaza pe anumite aspecte matematice (în principal, teoria multimilor si logica predicatelor).

Principiile modelului relational au fost stabilite initial în perioada 1969-70, de catre E.F. Codd, pe atunci cercetator la IBM. La sfârsitul anului 1968, Codd - un matematician prin formatie - a descoperit ca matematica ar putea fi utilizata pentru a insera o serie de principii solide si riguroase într-un domeniu (gestiunea bazelor de date) care, înainte de acel moment, era mult prea deficitar în aceasta privinta. Ideile lui Codd au fost expuse pe larg prima data î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 influenta larga în aproape fiecare aspect al tehnologiei bazelor de date, ca si în alte domenii, cum ar fi inteligenta artificiala, prelucrarea în limbaj natural si proiectarea sistemelor hardware.

În modelul relational, asa cum a fost formulat initial de catre Codd, erau utilizati anumiti termeni cum ar fi cel de relatie, tuplu, atribut. Termenul de tuplu corespunde aproximativ notiunii de rând, tot asa cum termenul de relatie corespunde aproximativ notiunii de tabela. În acelasi context, modelul relational nu utilizeaza termenul de câmp; în schimb foloseste termenul de atribut, care putem spune ca ar corespunde aproximativ notiunii de coloana dintr-o tabela.

Tupluri

Vom începe prin a defini termenul de tuplu. Consideram o multime nevida de simboluri, notata cu U, ale carei elemente se vor numi nume de atribute.

Fie U=. Pentru fiecare nume de atribut A_i se asociaza un tip T_i ,i=1,2, ., n, unde T_i nu sunt neaparat distincte. Un tuplu t este o multime de triplete ordonate, de forma <A_i, T_i, v_i>, unde A_i este numele unui atribut, T_i este numele unui tip iar v_i este o valoare de tipul T_i.

Valoarea n reprezinta gradul sau aritatea lui t.

Tripletul ordonat < A_i, T_i, v_i> este o componenta a lui t.

Perechea ordonata < A_i, T_i> este un atribut al lui t si este identificata în mod unic de catre numele atributului A_i (numele atributelor A_i si A_j sunt aceleasi numai daca i=j). Valoarea v_i este valoarea atributului A_i al lui t. Tipul T_i este tipul atributului corespunzator.

Multimea completa de atribute este antetul lui t.

Mai jos este prezentat un exemplu de tuplu:

Aici numele atributelor sunt MAJOR_C#, MINOR_C# si CANT; numele tipurilor corespunzatoare sunt C#, C# si Cant; valorile corespunzatoare sunt 'C2', 'C4', si 7. Gradul acestui tuplu este trei. Antetul sa este:

Observatie - În contextele lipsite de formalism, se obisnuieste sa se omita numele tipurilor din antetul tuplului, indicând doar numele atributelor. Prin urmare, mai putin formal, am putea reprezenta tuplul anterior astfel:

Proprietatile tuplurilor:

Fiecare tuplu contine exact o valoare (de tipul adecvat) pentru fiecare dintre atributele sale.

Nu exista o ordonare de la stânga la dreapta a componentelor tuplului. Aceasta proprietate se datoreaza faptului ca tuplul este definit ca o multime de componente iar în matematica, multimile nu au o ordine a elementelor.

Fiecare submultime a unui tuplu este un tuplu (iar fiecare submultime a unui antet este un antet).

Doua tupluri t₁ si t₂ sunt egale (adica expresia t₁=t₂ este adevarata) daca si numai daca au aceleasi atribute A₁, A₂, ., A_n si, pentru toti indicii i (i=1,2, ., n), valoarea v_i¹ a lui A_i din t₁ este egala cu valoarea v_i² a lui Ai din t₂.

Tuplurile t1 si t2 sunt duplicate daca si numai daca sunt egale.

Relatii

O relatie - sa zicem r - este formata dintr-un antet si un cuprins.

Antetul relatiei r este antetul unui tuplu, asa cum a fost definit anterior. Relatia are aceleasi atribute (si prin urmare, aceleasi nume si tipuri de atribute) si acelasi grad ca si acest antet.

Cuprinsul relatiei r este o multime de tupluri, toate având acelasi antet; cardinalitatea multimii de tupluri este cardinalitatea relatiei r (în general, cardinalitatea unei multimi reprezinta numarul de elemente ale acesteia).

Mai jos este prezentat un exemplu de relatie :

În contextele lipsite de formalism, se obisnuieste sa se omita numele tipurilor din antetul relatiei, indicând doar numele atributelor. Prin urmare, am putea reprezenta relatia anterioara astfel:

Proprietatile relatiilor:

Fiecare tuplu contine exact o valoare (de tipul adecvat) pentru fiecare atribut.

Nu exista ordonare a atributelor de la stânga la dreapta.

Nu exista o ordonare a tuplurilor de jos în sus.

Nu exista tupluri duplicat.

Relatii si tabele

În acest subparagraf vom prezenta o lista a câtorva dintre deosebirile principale dintre obiectul formal reprezentat de o relatie si obiectul neformal reprezentat de o tabela, care constituie o imagine neformala, pe hârtie, a acestui obiect formal.

Fiecare atribut din antetul unei relatii presupune un nume al tipului, dar aceste nume de tipuri sunt omise din imaginile sub forma de tabela.

Fiecare componenta a fiecarui tuplu din cuprinsul unei relatii presupune un nume si un tip al atributului, dar acestea sunt omise din imaginile sub forma de tabela.

Coloanele unei tabele au o ordine de la stânga la dreapta, dar atributele unei relatii nu.

Rândurile unei tabele au o ordine de sus în jos, dar tuplurile unei relatii nu.

O tabela poate contine rânduri duplicat, dar o relatie nu contine tupluri duplicat.

Tabelele sunt considerate ca având cel putin o coloana, în timp ce nu este obligatoriu ca relatiile sa aiba cel putin un atribut.

Tabelele - cel putin în limbajul SQL -pot cuprinde null-uri, în timp ce relatiile nu.

Din toate cele de mai sus, rezulta ca, pentru a putea accepta faptul ca o imagine de forma unei tabele poate fi privita ca reprezentând o relatie, trebuie sa cadem de acord privind modul de "citire" a unei stfel de imagini; cu alte cuvinte, trebuie sa acceptam anumite reguli de interpretare a cestor imagini. Mai exact, trebuie sa acceptam ca, pentru fiecare coloana exista un tip aflat la baza; ca fiecare valoare a unui atribut este o valoare de tipul adecvat; ca ordonarile rândurilor si ale coloanelor nu sunt relevante si ca nu sunt permise rânduri duplicat.

Acum putem vedea ca tabela si relatia nu sunt chiar acelasi lucru (desi, adeseori, este comod sa pretindem ca ar fi). În schimb, relatia este ceea ce arata definitia sa, adica un tip de obiect abstract, în timp ce tabela este o imagine concreta, de regula pe hârtie, a unui astfel de obiect abstract. Ele nu sunt acelasi lucru.

Un avantaj major al modelului relational consta în aceea ca obiectul da de baza abstract - relatia - are o reprezentare atât de simpla pe hârtie. Aceasta reprezentare simpla este cea care face ca sistemele relationale sa fie usor de utilizat si de înteles si cea care face ca întelegerea modului de comportare a sistemelor relationale sa fie simpla.