Capitolul 1:Modelul rela!

ional
Modelul rela!ional reprezint" datele sub forma unor structuri bidimensionale, asem"n"toare tabelelor. Apari!ia sa s-a datorat nevoii de a u#ura concep!ia, accesarea #i procesarea datelor. Modelele de date existente anterior (ierarhic #i re!ea) erau extrem de complexe #i necesitau personal extrem de specializat pentru a concepe #i a naviga n baza de date. De asemenea, datorit" faptului c" performan!ele acestor tipuri de baze de date erau dependente de proiectarea #i designul lor, pentru a asigura o performan!" corespunz"toare trebuia investit foarte mult efort n activitatea de proiectare. Aceste motive f"ceau ca disponibilitatea de personal adecvat s" fie foarte limitat". n plus, datorit" complexit"!ii lor, sistemele care foloseau aceste modele erau foarte greu de instalat. n sfr#it, dar nu n ultimul rnd, modelele ierarhice #i re!ea necesitau ca programatorul aplica!iei s" cunoasc" implementarea fizic" a bazei de date (leg"turile existente ntre nregistr"ri) #i cuno#tin!e despre limbajul de manipulare a datelor corespunz"tor. Modelul rela!ional este o solu!ie pentru rezolvarea acestor probleme. De#i sistemul software necesar unui model rela!ional este foarte complex, nv"!area limbajului de definire a datelor #i a celui de manipulare a datelor necesit" mult mai pu!in timp #i efort dect cele corespunz"toare modelelor ierarhic #i re!ea. De asemenea, proiectarea unui sistem care folose#te modelul rela!ional este flexibil", astfel nct modific"rile sunt destul de u#or de implementat, reducndu-se astfel efortul corespunz"tor fazei de proiectare a bazei de date. n plus, simplitatea modelului rela!ional #i a limbajului sau de manipulare a datelor permite utilizatorilor s" execute propriile lor manipul"ri. Conceptele teoretice care formeaz" baza modelului rela!ional au ap"rut la nceputul anilor 70, n principal datorit" lui Edgar F. Codd. Acest model difer" de modelele precedente prin aceea c" nu se bazeaz" pe dependen!ele de secven!" #i cale. Modelele existente anterior permiteau accesul la date prin c"i specificate de o schem". Cum programele asociate depindeau de c"ile diferitelor nregistr"ri din baza de date, dac", datorit" unei schimb"ri de design, calea de acces pentru o nregistrare se schimba, era necesar" #i modificarea programului de acces la datele respective, pentru a lua n considerare aceast" schimbare. Pe de alt" parte, modelul rela!ional nu folose#te c"ile de acces n structura sa logic" sau n limbajul sau de manipulare a datelor. De asemenea, n modelele ierarhic #i re!ea datele puteau fi accesate n mai mult de o secven!", iar programele de aplica!ie utilizau secven!a respectiv" a datelor. Evident, dac" secven!a datelor era schimbat", programul trebuia schimbat pentru a lua n considerare noua secven!". Modelul rela!ional nu utilizeaz" o anumit" secven!" n structura sa logic" sau n limbajul s"u de manipulare. Aceast" independen!" sporit" a datelor permite o tranzi!ie mai u#oar" la noi rela!ii ntre date. Modelul rela!ional nu este orientat spre sistemul de calcul, adic" modelul nu include regulile, structurile #i opera!iile referitoare la implementarea fizic" a unui sistem de baze de date. De fapt, unul dintre principalele obiective ale sistemului rela!ional este separarea clar" ntre aspectele fizice #i cele logice ale unei baze de date. Spre deosebire de modelele men!ionate anterior, utilizatorul poate ob!ine date specifice din modelul rela!ional folosind un limbaj ne-procedural care i permite s" descrie datele cerute n loc de naviga!ia folosit". n acela#i timp, modelul rela!ional #i opera!iile folosite de c"tre acesta au la baz" o riguroas" fundamentare matematic"; s-au creat algebra rela!ional" #i calculul rela!ional. Totu#i, pe lng" avantajele clare ale rigurozit"!ii matematice, matematizarea excesiv" a modelului #i a limbajului de manipulare creeaz" o problem" datorit" faptului c" n afara mediului academic doar un procent mic de utilizatori au preg"tirea necesar" pentru a le n!elege. Din fericire, folosirea modelului rela!ional nu necesit" neap"rat n!elegerea n profunzime a matematicii pe care este bazat. Opera!iile de manipulare a datelor pot fi privite ca o serie de opera!ii de proiec!ie, filtrare, reuniune, intersec!ie, etc. asupra datelor din tabele. 12

De#i are la rndul lui imperfec!iuni, modelul rela!ional a devenit n ultima vreme principalul model de baze de date #i a fost adoptat de majoritatea produc"torilor de software din acest domeniu. Principalele sale avantaje sunt simplitatea, fundamentarea matematic" riguroas" #i independen!a datelor, adic" separarea aspectelor logice ale acestora de cele fizice. 1.1. Concepte de baz" ale modelului rela!ional n general, definirea unui model de date presupune precizarea #i identificarea urm"toarelor elemente: Structurile de date folosite Operatorii care ac!ioneaz" asupra structurilor de date Restric!iile care trebuie impuse pentru men!inerea corectitudinii datelor, numite #i restric!ii de integritate. Aceast" sec!iune prezint" pe larg fiecare dintre aceste componente ale modelului rela!ional. n modelul rela!ional datele sunt reprezentate ca structuri bidimensionale, numite rela!ii. O rela!ie este alc"tuit" dintr-un num"r fix de elemente numite atribute, fiecare dintre acestea putnd lua valori ntr-o mul!ime finit", numit" domeniu. Num"rul de atribute al unei rela!ii se nume#te aritatea rela!iei. rela!ie (atribut_1, atribut_2, ..., atribut_n) De exemplu datele despre angaja!ii unei firme se pot reprezenta ca o rela!ie de aritate 7, dup" cum urmeaz": salariat (cod_salariat, nume, prenume, adresa, dat"_na#tere, sex, cod_departament) Elementele unei rela!ii se numesc tupluri sau nregistr"ri. De obicei rela!iile sunt reprezentate sub forma unor tabele, n care fiecare rnd reprezint" un tuplu #i fiecare coloan" reprezint" valorile tuplurilor corespunz"toare unui anumit atribut. salariat cod_ nume salariat S1 Ion S2 Popescu S3 Ionescu S4 Costache prenume Cosmin Vasile Gina Viorel Adresa Str. Jiului Nr.3 Str. Valea Alb" Nr.4 Str. Cri#ana Nr. 11 dat"_na#tere 01/01/1970 15/11/1956 28/02/1976 12/02/1975 sex M M F M cod_ departament D1 D1 D2 D1

Rela!iile ce constituie o baz" de date trebuie s" satisfac" mai multe condi!ii, dup" cum urmeaz": 1. Fiecare atribut trebuie s" poarte un nume, care este unic n cadrul rela!iei. Modelul rela!ional nu permite ca dou" atribute din cadrul aceleia#i rela!ii s" poarte acela#i nume. Pe de alt" parte, este posibil ca dou" atribute din dou" rela!ii diferite s" poarte acela#i nume. 2. Fiecare atribut poate avea doar valori atomice, deci care nu se pot descompune din punct de vedere logic. S" presupunem, de exemplu, c" un produc"tor de automobile atribuie fiec"rui automobil fabricat un cod de identificare, care se ob!ine prin concatenarea mai multor coduri, reprezentnd marca automobilului, culoarea, fabrica unde este produs, seria #i num"rul de fabrica!ie, etc. Atunci, definirea acestui cod de identificare ca atribut al unei rela!ii ar nc"lca 13

aceast" regul", deoarece fiecare valoare a atributului s-ar putea descompune n mai multe valori cu semnifica!ie logic". 3. Fiecare tuplu este unic. Nu sunt permise tupluri identice (duplicat). n plus, unicitatea unui tuplu nu este limitat" la datele existente: fiecare tuplu trebuie s" fie unic tot timpul. Aceasta nseamn" c" ntr-o rela!ie exist" ntotdeauna unul sau mai multe atribute care asigur" c" tuplul va r"mne unic tot timpul. Un atribut sau set de atribute care identific" n mod unic un tuplu se nume#te cheie candidat" sau mai simplu cheie. Pentru fiecare rela!ie se alege din mul!imea cheilor candidate o cheie care se nume#te cheie primar" a rela!iei. Eventualele alte chei candidate, diferite de cheia primar", se numesc chei alternative. Cnd mai mult de un singur atribut este necesar pentru a crea o cheie, se spune c" avem o cheie compus". n cazul unei chei compuse, atributele care fac parte din cheie sunt alese astfel nct nici unul s" nu fie n plus, adic" nici un atribut nu poate fi #ters din cheia candidat" astfel nct partea din cheia candidat" care r"mne s" identifice nc" n mod unic tuplurile; de aceea, se spune c" o cheie trebuie sa fie minimal". Uneori, n unele tupluri dintr-o rela!ie, un atribut poate fi necunoscut sau neaplicabil. Pentru a reprezenta un astfel de atribut se folose#te o valoare conven!ional", notat" cu Null. Ca regul" general", nici unul dintre atributele care alc"tuiesc cheia primar" nu poate avea valoarea Null pentru nici unul din tuplurile rela!iei. Exemplu: Pentru rela!ia salariat definit" mai sus, o cheie candidat" este cod_salariat. Dac" se presupune c" nume, prenume #i dat!_na"tere identific" n mod unic salariatul, atunci combina!ia acestor trei atribute este o alt" cheie candidat", care, datorit" faptului c" este alc"tuit" din mai multe atribute, se nume#te #i cheie compus". Dac" cheia cod_salariat este aleas" cheie primar", atunci combina!ia celor trei atribute (nume, prenume #i dat!_na"tere) devine cheie alternativ". n alegerea cheilor candidate s-a !inut cont de principiul minimalit"!ii n sensul c" din cheia compus" nume, prenume #i dat!_na"tere nu poate fi #ters nici un atribut #i nici nu mai trebuie ad"ugat altul, aceste trei atribute identificnd n mod unic tuplurile. De exemplu, combina!ia (nume, prenume, dat!_na"tere, cod_departament) nu este o cheie a rela!iei salariat pentru c" #i n absen!a atributului cod_departament, un salariat este identificat n mod unic de primele trei atribute. Observ"m c" tuplul identificat prin valoarea cheii primare egal" cu S2 are atributul adresa necunoscut, adic" acesta are valoarea Null. Prin urmare, atributul adresa nu poate fi cheie primar" #i nici nu poate intra n componen!a unei chei compuse care este #i cheie primar". Se nume#te cheie str"in" un atribut sau o mul!ime de atribute ale unei rela!ii R1 care exist" #i ntr-o alt" rela!ie R2, nu neap"rat distinct" de R1, #i care formeaz" cheia primar" a rela!iei R2. n cazul acesta, cheia str"in" din R1 se spune c" face referin!" la cheia primar" din R2. Valorile pe care le ia cheia str"in", dac" nu sunt nule, trebuie s" se g"seasc" printre valorile cheii primare la care face referin!". Exemplu: Dac" mai definim o rela!ie de aritate 3, dup" cum urmeaz": departament (cod_departament, denumire, localitate) cod_departament D1 denumire Analiz" financiar" localitate Bucure#ti 14

D2 D3 D4

Depozit Contabilitate Magazin

Pite#ti Constan!a Pite#ti

pentru eviden!a departamentelor din firm", atributul cod_departament din rela!ia salariat devine cheie str"in" care face referin!" la cheia primar" a rela!iei departament. Valoarea cheii str"ine cod_departament din rela!ia salariat trebuie ori s" fie ori Null, ori s" coincid" cu o valoare a cheii primare la care face referin!". Prin urmare, dac" atributul cod_departament din rela!ia salariat ar fi avut pentru un anumit tuplu valoarea D5, valoare ce nu se reg"se#te printre valorile cheii primare cod_departament din rela!ia departament, atunci s-ar fi nc"lcat o regul" de integritate. Exist" posibilitatea ca o cheie str"in" s" fac" referin!" la cheia primar" a propriei rela!ii. Pentru a ilustra acest lucru, s" ad"ug"m la rela!ia salariat un nou atribut cod_manager, reprezentnd codul superiorului ierarhic al salariatului (facem presupunerea c" un angajat poate avea cel mult un superior ierarhic). cod_ salariat S1 S2 S3 S4 nume Ion Popescu Ionescu Costache prenume Cosmin Vasile Gina Viorel ..... ..... ..... ..... ..... cod_manager S1 S1 S2

Deci salariatul cu codul S1 este superiorul ierarhic al salaria!ilor cu codurile S2 #i S3, salariatul cu codul S2 este superiorul ierarhic al salariatului cu codul S4, iar S1 nu are un superior ierarhic. 4. Naviga!ia n cadrul modelului rela!ional se face prin intermediul valorii pe care o ia un atribut. Aceasta nseamn" c" limbajul de interogare va prelua ca parametri de intrare doar numele unor atribute #i valorile posibile ale acestora, corespunz"toare cerin!ei utilizatorului, #i va returna tuplurile care satisfac aceast" cerin!". Spre deosebire de alte modele, nu exist" leg"turi ntre tupluri #i deci nu exist" dependen!" de calea urmat". 5. Tuplurile pot fi prezentate utilizatorului n orice ordine. Deci acesta nu trebuie s" fac" nici o presupunere n privin!a ordinii tuplurilor. 6. Atributele pot fi prezentate n orice ordine, deci utilizatorul nu trebuie s" fac" nici o presupunere n privin!a ordinii acestora. Cu alte cuvinte, n modelul rela!ional nu exist" dependen!" de secven!". De exemplu, de#i rela!iile Salariat (cod_salariat, nume, prenume, adresa, dat"_na#tere, sex, cod_departament) #i Salariat (cod_salariat, nume, prenume, cod_departament, dat"_na#tere, sex, adresa) par diferite, ele sunt echivalente func!ional pentru c" au atribute identice, chiar dac" sunt n alt" ordine. 7. Rela!iile pot fi manipulate pentru a furniza utilizatorului diferite vederi asupra datelor, rezultatul fiind noi rela!ii. Cu alte cuvinte, rezultatul manipul"rii rela!iilor sunt noi rela!ii. n plus, rela!iile produse ca rezultat al comenzilor limbajului de interogare a datelor satisfac toate regulile la care sunt supuse rela!iile ini!iale. 15

1.2. Constrngeri de integritate Pentru asigurarea integrit"!ii datelor, o baz" de date trebuie s" satisfac" un num"r de constrngeri, numite constrngeri de integritate. Constrngerile de integritate ale modelului rela!ional se pot mp"r!i n dou" clase: constrngeri structurale, care trebuie satisf"cute de orice baz" de date care folose#te modelul rela!ional #i constrngeri de comportament, care sunt specifice fiec"rei baze de date particulare. Constrngerile de integritate structurale exprim" propriet"!i fundamentale, inerente modelului rela!ional #i sunt n general specificate la definirea bazei de date, ca parte a schemei bazei de date. n modelul rela!ional exist" dou" tipuri de constrngeri structurale: de entitate #i de referin!". Ele au fost men!ionate mai nainte, cnd am vorbit despre propriet"!ile sistemului rela!ional, f"r" ns" a le men!iona explicit numele. 1. Integritatea entit"!ii: O cheie primar" nu poate con!ine atribute ce pot avea valoarea Null. n plus, prin ns"#i defini!ia unei chei primare, ea trebuie s" fie unic" #i minimal". 2. Integritatea referirii: Valoarea unei chei str"ine trebuie ori s" fie ori Null, ori s" coincid" cu o valoare a cheii primare la care face referin!". Aceste dou" tipuri de constrngeri pot fi impuse n Oracle prin simpla lor ad"ugare la defini!ia tabelelor respective, vezi sec!iunea 6.1.3. Constrngerile de integritate de comportament sunt specifice unei anumite baze de date #i !in cont de semnifica!ia valorilor atributelor din baza respectiv". De exemplu, constrngerile de domeniu restric!ioneaz" valorile unui atribut la o anumit" mul!ime, iar constrngerile sintactice se pot referi la tipul datelor, lungimea atributelor, etc. Constrngerile de comportament pot exprima leg"turi ntre valorile unor atribute diferite, de exemplu valoarea unui atribut este dependent" de valoarea altui atribut sau set de atribute sau o expresie format" din valorile mai multor atribute trebuie s" se ncadreze n anumite limite, etc. Constrngerile de comportament pot fi impuse n Oracle fie prin ad"ugarea lor la defini!ia tabelelor (vezi sec!iunea 6.1.3), fie prin definirea unor secven!e de program, numite declan#atori (triggers) care sunt ata#ate tabelelor #i care intr" n ac!iune la nc"lcarea acestor constrngeri, mpiedicnd opera!iile care ar duce la nc"lcarea integrit"!ii (vezi sec!iunea 9.16). 1.3. Operatorii sistemului rela!ional n afara rela!iilor #i a propriet"!ilor acestora, modelul rela!ional este definit #i prin setul de opera!ii care se pot efectua asupra acestor rela!ii. Exist" dou" moduri de descriere matematic" a acestor operatori, #i anume algebra rela!ional" #i calculul rela!ional, vezi [3] [Basca97]. Algebra rela!ional", introdus" de c"tre Codd, este format" dintr-o mul!ime de opt operatori, ce ac!ioneaz" asupra rela!iilor #i genereaz" tot o rela!ie. Operatorii algebrei rela!ionale sunt fie operatorii tradi!ionali pe mul!imi (UNION, INTERSECT, DIFFERENCE, PRODUCT), fie operatori rela!ionali speciali (PROJECT, SELECT, JOIN, DIVISION). Cum ie#irea generat" de fiecare dintre ace#ti operatori este tot o rela!ie, este posibil" combinarea #i compunerea lor. Cinci dintre operatori (PROJECT, SELECT, DIFFERENCE, PRODUCT, UNION) sunt operatorii primitivi ai limbajului, iar ceilal!i trei (JOIN, DIVISION, INTERSECT) sunt operatori deriva!i, putnd fi defini!i n func!ie de primii. Unii dintre operatori se aplic" unei singure rela!ii (operatori unari), iar al!ii opereaz" asupra a dou" rela!ii (operatori binari). 16

Calculul rela!ional reprezint" o adaptare a calculului predicatelor la domeniul bazelor de date rela!ionale. Ideea de baz" este de a identifica o rela!ie cu un predicat. Pe baza unor predicate ini!iale, prin aplicarea unor operatori ai calculului cu predicate (conjunc!ia, disjunc!ia, nega!ia, cuantificatorul existen!ial #i cel universal) se pot defini noi predicate, adic" noi rela!ii. Algebra rela!ional" #i calculul rela!ional sunt echivalente unul cu cel"lalt, n sensul c" orice rela!ie care poate fi definit" n algebra rela!ional" poate fi definit" #i n calculul rela!ional #i reciproc. 1.3.1 Algebra rela!ional" #i limbajul SQL n prezent, limbajul dominant folosit pentru interogarea bazelor de date rela!ionale este SQL (Structured Query Language), care este un limbaj bazat pe opera!iile algebrei rela!ionale. Cu alte cuvinte, orice operator al algebrei rela!ionale poate fi descris folosind comanda SELECT a limbajului SQL cu diverse clauze. n ceea ce urmeaz" vom defini operatorii algebrei rela!ionale #i vom exemplifica modul de implementare a acestor operatori n SQL. Pentru o explica!ie a sintaxei comenzii SELECT din limbajul SQL vezi sec!iunea 8.1. Not": Comanda SELECT din limbajul SQL nu reprezint" acela#i lucru #i nu trebuie confundat" cu operatorul SELECT din algebra rela!ional". Operatorul PROJECT (proiec!ia) Acesta este un operator unar care are ca parametri un atribut sau mai multe atribute ale unei rela!ii #i care elimin" din rela!ie toate celelalte atribute, producnd o submul!ime pe vertical" a acesteia. Datorit" faptului c" suprimarea unor atribute poate avea ca efect apari!ia unor tupluri duplicate, acestea vor fi eliminate din rela!ia rezultat" deoarece, prin defini!ie, o rela!ie nu poate con!ine tupluri cu valori identice. Nota!iile folosite de obicei pentru acest operator sunt !X(R) #i PROJECT(R, X) unde R reprezint" rela!ia, iar X este atributul sau mul!imea de atribute care constituie parametrii proiec!iei. Exemplu R A B x1 y1 x1 y1 x1 y2 x2 y2 C z1 z2 z2 z1 C z1 z2 z2 z1 A x1 x1 x1 x2 !C,A(R) C z1 z2 z1 A x1 x1 x2

Proiec!ie

Eliminare duplicate

n SQL, proiec!ia f"r" dubluri se ob!ine folosind comanda SELECT cu specifica!ia DISTINCT: SELECT DISTINCT C, A FROM R; n cazul folosirii comenzii SELECT f"r" clauza DISTINCT se va ob!ine proiec!ia cu dubluri: SELECT C, A FROM R; Operatorul SELECT (selec!ia)

17

Acesta este un operator unar care este utilizat pentru extragerea tuturor tuplurilor dintr-o rela!ie care satisfac o condi!ie specificat", producnd astfel o submul!ime pe orizontal" a rela!iei. Condi!ia este o formul" logic" ce poate con!ine nume de atribute, constante, operatori logici (AND, NOT, OR), operatori de compara!ie (<, =, >, <=, >=, !=). Spre deosebire de alte limbaje de programare, cum ar fi Pascal, limbajul SQL acord" operatorilor de compara!ie o prioritate mai mare dect operatorilor logici, reducndu-se astfel num"rul de paranteze necesare pentru expresii complexe. Nota!iile folosite de obicei pentru acest operator sunt "C(R) sau SELECT(R, C), unde R reprezint" rela!ia, iar C este condi!ia care trebuie satisf"cut" de tuplurile selectate. Exemplu R A B x1 y1 x1 y1 x1 y2 x2 y2 C z1 z2 z2 z1 "A=x1 OR B=y1(R) A x1 x1 x1 B y1 y1 y2 C z1 z2 z2

n SQL, selec!ia se ob!ine folosind comanda SELECT cu clauza WHERE: SELECT * FROM R WHERE A = x1 OR B = y1; Combinarea selec!iei cu proiec!ia f"r" dubluri se face n modul urm"tor: SELECT DISTINCT C, A FROM R WHERE A = x1 OR B = y1; R A x1 x1 x1 x2 B y1 y1 y2 y2 C z1 z2 z2 z1 A x1 x1 x1 B y1 y1 y2 C z1 z2 z2 C z1 z2 A x1 x1

selec!ie

proiec!ie cu eliminarea duplicatelor

Combinarea selec!iei cu proiec!ia cu dubluri se face n modul urm"tor: SELECT C, A FROM R WHERE A = x1 OR B = y1; R A x1 x1 x1 x2 B y1 y1 y2 y2 C z1 z2 z2 z1 A x1 x1 x1 B y1 y1 y2 C z1 z2 z2 C z1 z2 z2 A x1 x1 x1

selec!ie

proiec!ie f"r" eliminarea duplicatelor

PRODUCT (produsul cartezian) 18

Acesta este un operator binar. Produsul cartezian a dou" rela!ii R #i S este mul!imea tuturor tuplurilor care se ob!in prin concatenarea unui tuplu din R cu un tuplu din S. Prin urmare, dac" aritatea rela!iei R este m, iar aritatea rela!iei S este n, atunci produsul cartezian dintre R #i S va avea aritatea m + n. Nota!iile folosite de obicei pentru acest operator sunt R # S, PRODUCT(R, S), TIMES(R, S). Exemplu R A B x1 y1 x2 y1 x3 y2 C z1 z2 z1 S D z1 z2 E u1 u2 R#S A x1 x1 x2 x2 x3 x3 B y1 y1 y1 y1 y2 y2 C z1 z1 z2 z2 z1 z1 D z1 z2 z1 z2 z1 z2 E u1 u2 u1 u2 u1 u2

Produsul cartezian poate fi exprimat n SQL printr-o comand" SELECT pe mai multe tabele f"r" clauza WHERE: SELECT * FROM R, S; Compatibilitate la reuniune Dou" rela!ii R #i S se numesc compatibile la reuniune dac" ele con!in acela#i num"r de atribute (au aceea#i aritate) #i atributele cu acela#i num"r de ordine din fiecare rela!ie au acela#i domeniu din care pot lua valori. Operatorii UNION, INTERSECT, DIFFERENCE, prezenta!i n continuare, sunt operatori binari ce nu pot fi aplica!i dect asupra rela!iilor compatibile la reuniune. UNION (reuniunea) Reuniunea a dou" rela!ii R #i S este mul!imea tuplurilor apar!innd fie lui R, fie lui S. Reuniunea celor dou" mul!imi va cuprinde fiecare tuplu o singur" dat", chiar dac" el face parte din amndou" mul!imile. Reuniunea se poate aplica doar rela!iilor compatibile la reuniune. Nota!iile folosite de obicei pentru acest operator sunt R $ S sau UNION(R, S). Reuniunea este o opera!ie binar" comutativ", adic" R $ S = S $ R. Exemplu R A B x1 y1 x2 y1 x3 y1 S C x1 x1 D y1 y2 R$S A x1 x2 x3 x1 B y1 y1 y1 y2

n SQL reuniunea se poate exprima folosind operatorul UNION: SELECT A, B FROM R UNION SELECT C, D FROM S; 19

DIFFERENCE (diferen!a) Diferen!a a dou" rela!ii R #i S este mul!imea tuplurilor care apar!in lui R, dar nu apar!in lui S. Diferen!a este o opera!ie binar" ne-comutativ", adic" R S % S R, care se poate aplica doar rela!iilor compatibile la reuniune. Nota!iile folosite de obicei pentru acest operator sunt R - S, DIFFERENCE(R, S), MINUS(R, S). Exemplu R A B x1 y1 x2 y1 x3 y1 S C x1 x1 D y1 y2 RS A x2 x3 B y1 y1

n SQL diferen!a se poate exprima folosind operatorul MINUS: SELECT A, B FROM R MINUS SELECT C, D FROM S; n plus, diferen!a poate fi simulat" #i prin operatorul NOT EXISTS. De exemplu, comanda SQL de mai sus este echivalent" cu urm"toarea: SELECT A, B FROM R WHERE NOT EXISTS (SELECT * FROM S WHERE R.A = S.C AND R.B = S.D); Not": Pentru simplitate, n comanda SQL de mai sus am presupus c" nici un atribut din rela!iile R sau S nu poate avea valoarea Null. Dac", de exemplu, atributul A din rela!ia S #i atributul C din rela!ia S pot avea valoarea Null, atunci expresia R.A = S.C trebuie nlocuit" cu R.A = S.C OR (R.A IS NULL AND S.C IS NULL). Acest lucru se datoreaz" faptului c" n SQL, expresia NULL = NULL are valoarea False. INTERSECT (intersec!ia) Intersec!ia a dou" rela!ii R #i S este mul!imea tuplurilor care apar!in att lui R ct #i lui S. Intersec!ia este o opera!ie binar" comutativ" care se poate aplica doar rela!iilor compatibile la reuniune. Nota!iile folosite de obicei pentru acest operator sunt R & S, INTERSECT(R, S), AND(R, S). Intersec!ia este un operator derivat, putnd fi exprimat cu ajutorul reuniunii #i diferen!ei: R & S = R (R S) sau R & S = S (S R) Exemplu R A B x1 y1 x2 y1 x3 y1 S C x1 x1 D y1 y2 R&S A x1 B y1

20

n SQL diferen!a se poate exprima folosind operatorul INTERSECT: SELECT A, B FROM R INTERSECT SELECT C, D FROM S; n plus, intersec!ia poate fi simulat" #i prin operatorul EXISTS. De exemplu, comanda SQL de mai sus este echivalent" cu urm"toarea: SELECT A, B FROM R WHERE EXISTS (SELECT * FROM S WHERE R.A = S.C AND R.B = S.D); n cazul cnd operatorii UNION, DIFFERENCE sau INTERSECT se aplic" unor rela!ii care sunt ob!inute prin selec!ie din aceea#i rela!ie, atunci ace#tia pot fi simula!i prin aplicarea operatorilor logici corespunz"tori (OR, AND NOT, AND) asupra condi!iilor de selec!ie. De exemplu, urm"toarele comenzi sunt echivalente: SELECT A, B FROM R WHERE A = x1 MINUS SELECT A, B FROM R WHERE B = y1; SELECT A, B FROM R WHERE A = x1 AND NOT B = y1; DIVISION (diviziunea) Diviziunea este o opera!ie binar" care se aplic" asupra a dou" rela!ii R #i S, astfel nct mul!imea atributelor lui R include mul!imea atributelor lui S. Dac" R este o rela!ie cu aritatea m, iar S o rela!ie cu aritatea n, unde m > n, atunci diviziunea lui R la S este mul!imea tuplurilor de dimensiune m n la care, ad"ugnd orice tuplu din S, se ob!ine un tuplu din R. Nota!iile utilizate cel mai frecvent sunt R S, DIVISION(R, S), DIVIDE(R, S). Exemplu R A B x1 y1 x1 y2 x1 y1 x2 y1 x2 y2 C z1 z1 z2 z2 z2 S C z1 z2 RS A x1 B y1

21

Diviziunea este o opera!ie derivat" care se exprim" cu ajutorul diferen!ei, produsului cartezian #i proiec!iei: R S = R1 R2, unde R1 = !X(R), R2 = !X((R1 # S) R), iar X este mul!imea atributelor lui R care nu exist" n S. Pentru exemplul de mai sus: R1 A x1 x1 x2 x2 B y1 y2 y1 y2 R1 # S A x1 x1 x2 x2 x1 x1 x2 x2 R1 R2 A x1 B y1 y2 y1 y2 y1 y2 y1 y2 B y1 C z1 z1 z1 z1 z2 z2 z2 z2 (R1 # S) - R A x2 x2 x1 B y1 y2 y2 C z1 z1 z2

R2

A x2 x2 x1

B y1 y2 y2

Operatorul DIVISION este legat de cuantificatorul universal (') care nu exist" n SQL, dar care poate fi simulat cu ajutorul cuantificatorului existen!ial ((), care exist" n SQL, utiliznd rela!ia: ' x P(x) ) NOT ( x NOT P(x). Pentru a ilustra exprimarea operatorul DIVISION n cele dou" moduri (folosind cuantificatorul universal #i cuantificatorul existen!ial), s" consider"m rela!iile student_curs #i curs_fundamental de mai jos: curs_student cod_student Curs S1 matematica S1 Fizica S1 Mecanica S2 matematica S2 informatica S3 Fizica S4 matematica S4 Fizica curs_student curs_fundamental curs S1 S4 Atunci rela!ia curs_student curs_fundamental poate fi definit" prin urm"toarea ntrebare: care sunt studen!ii care urmeaz" toate cursurile fundamentale? Alternativ, aceast" rela!ie poate fi definit" prin ntrebarea: care sunt studen!ii pentru care nu exist" curs fundamental care s" nu fie urmat de c"tre ace#tia? Utiliznd a doua formulare, rezult" c" operatorul DIVISION poate fi simulat n SQL prin doi operatori NOT EXISTS: SELECT DISTINCT cod_student FROM curs_student cs1 22 curs_fundamental curs matematica fizica

WHERE NOT EXISTS (SELECT * FROM curs_fundamental cf WHERE NOT EXISTS (SELECT * FROM curs_student cs2 WHERE cf.curs = cs2.curs AND cs1.cod_student = cs2.cod_student)); JOIN (compunerea, jonc!iunea) Operatorul de compunere permite reg"sirea informa!iei din mai multe rela!ii corelate. Compunerea este o opera!ie binar" care are ca rezultat o nou" rela!ie n care fiecare tuplu este o combina!ie a unui tuplu din prima rela!ie cu un tuplu din a doua rela!ie. Operatorul JOIN este un operator derivat, putnd fi simulat printr-o combina!ie de produs cartezian, selec!ie #i proiec!ie. n general, se construie#te un produs cartezian, se elimin" tupluri prin selec!ie #i se elimin" atribute prin proiec!ie. Dup" modalit"!ile n care se face selec!ia #i proiec!ia, se disting mai multe tipuri de compunere: THETA-JOIN, NATURAL-JOIN, SEMI-JOIN, OUTER-JOIN. Fiecare dintre acestea vor fi prezentate n continuare. THETA-JOIN Operatorul THETA-JOIN combin" perechile de tupluri din dou" rela!ii, cu condi!ia ca ntre valorile atributelor specificate s" existe o anumit" leg"tur", adic" s" satisfac" o anumit" condi!ie specificat" explicit n cadrul opera!iei. n cadrul condi!iei operatorului THETA-JOIN se poate folosi orice operator de compara!ie (>, >=, <, <=, <>, =). n cazul n care este folosit operatorul de compara!ie =, tipul de compunere se nume#te EQUI-JOIN. Operatorul THETA-JOIN se reprezint" de obicei cu ajutorul simbolului sub care se scrie condi!ia, R S sau prin JOIN(R, S, condi!ie).
condi!ie

Exemplu R A B x1 x2 x3 y1 y2 y3

C 1 3 5

S D 2 4

E z1 z2

A x1 x1 x2

B y1 y1 y2

C 1 1 3

D 2 4 4

E z1 z2 z2

C<D

Urm"torul exemplu ilustreaz" realizarea operatorului THETA-JOIN n SQL: SELECT * FROM R, S WHERE R.C < S.D; NATURAL-JOIN (Compunerea natural") Compunerea natural" este o opera!ie binar" comutativ" care combin" tupluri din dou" rela!ii, R #i S, cu condi!ia ca atributele comune s" aib" valori identice. n cazul compunerii naturale atributele specificate trebuie s" aib" acela#i nume. Practic diferen!a dintre NATURAL-JOIN #i EQUI-JOIN const" n faptul c" n primul caz numele atributelor sunt identice iar n cel de al doilea caz acestea sunt diferite. De obicei, compunerea natural" se noteaz" prin R S sau JOIN(R, S).

23

Pentru dou" rela!ii R #i S, compunerea natural" pe un set de atribute comune X const" n efectuarea succesiv" a urm"toarelor opera!ii: 1. Se calculeaz" produsul cartezian R # S. 2. Se selecteaz" din R # S acele tupluri ob!inute pentru care valorile atributelor X din tuplul R sunt identice cu valorile atributelor X din tuplul S. 3. Deoarece n rela!ia astfel ob!inut" atributele X apar de dou" ori (o dat" provenind din R #i o dat" din S), se elimin" una dintre apari!iile acestor atribute. Exemplu nr_lucr"tor 1 2 3 4 5 lucr!tor cod_sec!ie S1 S1 S2 S1 S1 nr_atelier 1 2 1 2 1 atelier cod_sec!ie nr_atelier S1 1 S1 2 S2 1 S2 2 denumire Proiectare Informatica Mecanica Electrotehnica

lucr!tor atelier nr_lucr"tor cod_sec!ie nr_atelier 1 S1 1 2 S1 2 3 S2 1 4 S1 2 5 S1 1

denumire Proiectare Informatica Mecanica Informatica Proiectare

n exemplul de mai sus, {cod_sec#ie, nr_atelier} este cheie primar" n tabelul atelier #i cheie str"in" n tabelul lucr!tor. Urm"torul exemplu ilustreaz" realizarea compunerii naturale n SQL: SELECT lucr"tor.nr_lucr"tor, lucr"tor.cod_sec!ie, lucr"tor.nr_atelier, atelier.denumire FROM lucr"tor, atelier WHERE lucr"tor.cod_sec!ie = atelier.cod_sec!ie AND lucr"tor.nr_atelier = atelier.nr_atelier; SEMI-JOIN (semi-compunerea) Opera!ia de semi-compunere aplicat" asupra a dou" rela!ii R #i S genereaz" o rela!ie care con!ine toate tuplurile din R corelate cu oricare din tuplurile din S. Opera!ia nu este comutativ" #i se noteaz" de obicei prin SEMI-JOIN(R, S). Exemplu R A B x1 y1 x2 y1 x3 y2 x4 y2 C z1 z1 z1 z2 S B y1 y2 y2 C z1 z2 z2 D u1 u2 u3 SEMIJOIN(R, S) A x1 x2 x4 B y1 y1 y2 C z1 z1 z2

Urm"torul exemplu ilustreaz" realizarea compunerii naturale n SQL: SELECT DISTINCT R.A, R.B, R.C 24

FROM R, S WHERE R.B = S.B AND R.C = S.C OUTER-JOIN (compunere extern") Opera!ia de compunere extern" este o extindere a compunerii naturale. n cazul aplic"rii operatorului NATURAL-JOIN se pot pierde tupluri atunci cnd exist" un tuplu ntr-una din rela!ii care nu este corelat cu nici un tuplu din cealalt" rela!ie. Operatorul OUTER-JOIN elimin" acest inconvenient. Practic, la aplicarea operatorului OUTER-JOIN, se realizeaz" compunerea natural" a celor dou" rela!ii, la care se adaug" tuplurile din S care nu sunt con!inute n compunere, completate cu valori Null pentru atributele r"mase din R. Operatorul se noteaz" cu OUTERJOIN(R, S). Exist" #i alte variante ale acestui operator, de exemplu o alt" variant" adaug" la tuplurile ob!inute din compunerea natural" a lui R #i S att tuplurile din R care nu sunt con!inute n compunere ct #i tuplurile din S care nu sunt con!inute n compunere, completnd restul cu Null. n mod evident, aceast" variant" a operatorului se poate ob!ine cu u#urin!" din varianta prezentat" de noi. Operatorul OUTER-JOIN, n varianta prezentat" de noi, este ne-comutativ. Exemplu: student nr_stud 1 2 3 4 5 facultate cod_facul nume_facult t F1 Matematica F2 Fizica F3 Informatica F4 Mecanica

nume Popescu Ionescu Ionescu Costache Matache

Prenume Ion Vasile Viorel Ion Mihai

cod_facult F1 F1 F2 F2 F1

localitate Bucure#ti Bucure#ti Pite#ti Ploie#ti

OUTERJOIN (student, facultate) nr_stud nume Prenume cod_facult 1 Popescu Ion F1 2 Ionescu Vasile F1 3 Ionescu Viorel F2 4 Costache Ion F2 5 Matache Mihai F1 Null Null Null F3 Null Null Null F4

nume_facult Matematica Matematica Fizica Fizica Matematica Informatica Mecanica

localitate Bucure#ti Bucure#ti Bucure#ti Bucure#ti Bucure#ti Ploie#ti Ploie#ti

n versiunea SQL folosit" de Oracle, operatorul OUTER JOIN este specificat prin sufixul (+) ad"ugat la cmpul dup" care se face compunerea, corespunz"tor tuplului ale c"rui atribute pot fi completate cu Null: SELECT student.nume_stud, student.nume, student.prenume, facultate.cod_facult, facultate.nume_facult, facultate.localitate FROM student, facultate WHERE student.cod_facult (+) = facultate.cod_facult;

1.4 Tabele, rnduri, coloane

25

Modelul rela!ional este bazat pe matematica rela!ional" #i acest lucru se reflect" n terminologia pe care am prezentat-o pn" acum. Pe de alt" parte, folosirea acestui model n economie, unde conceptele matematice sunt foarte pu!in sau deloc utilizate #i n!elese, a necesitat o nou" terminologie. A#a c", odat" cu preluarea modelului rela!ional de c"tre economie are loc o transformare a terminologiei rela!ionale ntr-una care poate fi u#or n!eleas" de cei f"r" o preg"tire special" n domeniu. Pentru cei care nu sunt exper!i n procesarea datelor, rela!iile devin tabele, tuplurile devin rnduri #i atributele devin coloane. Acesta este #i terminologia pe care o vom folosi n continuare n aceast" carte. 1.5. Sisteme de Gestiune a Bazelor de Date Rela!ionale (SGBDR). n principiu, un sistem de gestiune a bazelor de date rela!ionale (SGBDR) este un SGBD care utilizeaz" drept concep!ie de organizare a datelor modelul rela!ional. n mod evident ns", aceast" defini!ie este mult prea general" pentru a putea fi folosit" n practic", deoarece modul de implementare a modelului rela!ional difer" de la un produc"tor la altul. n 1985, Codd a publicat un set de 13 reguli n raport cu care un SGBD poate fi apreciat ca rela!ional. Trebuie remarcat c" nici un SGBD comercializat n prezent nu satisface n totalitate regulile lui Codd, dar aceasta nu mpiedic" etichetarea acestora drept rela!ionale. Cu alte cuvinte, regulile lui Codd nu trebuie folosite pentru a aprecia dac" un sistem este sau nu rela!ional, ci m"sura n care acesta este rela!ional, adic" num"rul regulilor lui Codd respectate de c"tre acesta. 1.5.1. Regulile lui Codd Regula 1. Regula reprezent"rii logice a datelor: ntr-o baz" de date rela!ional", toate datele sunt reprezentate la nivel logic ntr-un singur mod, #i anume sub form" de valori atomice n tabele. Deci toate datele trebuie memorate sub form" de tabele, iar valoarea corespunz"toare intersec!iei dintre un rnd #i o coloan" trebuie s" fie atomic", adic" s" nu mai poat" fi descompus" din punct de vedere logic. A#a cum am discutat mai nainte, un exemplu de nc"lcare a acestei reguli este stocarea ca o singur" coloan" a unui cod al automobilului, ob!inut prin concatenarea mai multor coduri, reprezentnd marca automobilului, culoarea, fabrica unde este produs, seria #i num"rul de fabrica!ie, etc. Uneori aceast" regul" este nc"lcat" n practic", dar acest lucru este de cele mai multe ori semnul unui design de calitate slab", crend probleme de integritate a bazei de date. Aceast" regul" este cea mai important" dintre cele definite de Codd, iar un SGBD care nu respect" aceast" regul" nu poate fi n nici un caz considerat rela!ional. Regula 2. Regula accesului la date: Toate datele individuale din tabele trebuie s" fie accesibile prin furnizarea numelui tabelului, numelui coloanei #i valorii cheii primare. Conform modelului rela!ional, ntr-un tabel nu pot exista rnduri identice, iar fiecare rnd poate fi identificat prin valoarea cheii primare. n consecin!", orice dat" individual" poate fi identificat" folosind numele tabelului, al coloanei #i valoarea cheii primare. Oracle nu respect" aceast" regul" deoarece permite existen!a a mai multe rnduri identice n acela#i tabel. Totu#i, acest lucru poate fi evitat, de exemplu prin definirea unei chei primare, care elimin" implicit #i posibilitatea existen!ei rndurilor identice. Pe de alt" parte, aceast" regul" este nc"lcat" n Oracle #i de existen!a identificatorului de rnd, ROWID, care poate fi folosit pentru accesarea rndului respectiv. Regula 3. Regula reprezent"rii valorilor necunoscute: 26

Un sistem rela!ional trebuie s" permit" declararea #i manipularea sistematic" a valorilor Null, cu semnifica!ia unor valori necunoscute sau inaplicabile. Aceast" regul", implic", de exemplu, c" un SGBDR trebuie s" fac" diferen!a ntre valoarea numeric" 0 #i Null sau ntre #irul de caractere spa!iu #i valoarea Null. Valoarea Null trebuie s" reprezinte absen!a informa!iei respective #i are un rol important n implementarea restric!iilor de integritate structural" (integritatea entit"!ii #i integritatea referirii). Oracle respect" aceast" regul", limbajul SQL permi!nd declararea #i manipularea valorilor Null. Regula 4. Regula dic!ionarului de date: Descrierea bazei de date (dic!ionarul de date) trebuie s" fie reprezentat" la nivel logic tot sub form" de tabele, astfel nct asupra acesteia s" se poat" aplica acelea#i opera!ii ca #i asupra datelor propriu-zise. Cu alte cuvinte, dic!ionarul de date trebuie s" fie organizat la nivel logic #i accesat la fel ca orice tabel din baza de date. Aceast" regul" este respectat" de c"tre Oracle, dic!ionarul de date constnd din tabele #i tabele virtuale (vederi) care pot fi interogate la fel ca oricare alte tabele sau vederi, folosind comanda SELECT. Regula 5. Regula limbajului de acces: ntr-un sistem rela!ional trebuie s" existe cel pu!in un limbaj de accesare a datelor, care s" asigure urm"toarele opera!ii: definirea tabelelor de baz" #i a tabelelor virtuale (vederilor), manipularea #i interogarea datelor (att interactiv ct #i prin program), definirea restric!iilor de integritate, autorizarea accesului la date, delimitarea tranzac!iilor. Limbajul SQL folosit de c"tre Oracle permite definirea tabelelor (comenzile CREATE TABLE, ALTER TABLE, DROP TABLE), a vederilor (comenzile CREATE VIEW, ALTER VIEW, DROP VIEW), manipularea (comenzile INSERT, UPDATE, DELETE) #i interogarea acestora (comanda SELECT), definirea restric!iilor de integritate (clauza CONSTRAINT folosit" la definirea tabelelor), autorizarea accesului la date (printr-un set de privilegii de sistem #i la nivel de obiect), delimitarea tranzac!iilor (opera!iile COMMIT #i ROLLBACK). Regula 6. Regula de actualizare a tabelelor virtuale (vederilor). Un SGBD trebuie s" poat" determina dac" o vedere poate s" fie actualizat" sau nu. Un tabel virtual (vedere) este un tabel logic, n sensul c" el organizeaz" datele sub forma unor rnduri #i coloane, ca orice alt tabel, dar n schimb el nu stocheaz" datele, fiind construit pe baza unor interog"ri asupra unuia sau mai multor tabele de baz". De exemplu s" consider"m tabelul : salariu(cod_salariat, salariu_brut, zile_totale, zile_lucrate). Pe baza acestui tabel se poate defini vederea salariu_r(cod_salariat, salariu_brut, salariu_realizat) unde salariu_realizat este definit ca salariu_realizat = salariu_brut*zile_totale/zile_lucrate. S" presupunem acum c" se dore#te actualizarea coloanei salariu_brut din vedere. Acest lucru este posibil, datorit" faptului c" actualizarea se propag" napoi la coloana din tabelul de baz", producndu-se #i actualizarea acesteia. Pe de alt" parte, nu este posibil" actualizarea coloanei 27

salariu_realizat, datorit" faptului c" schimbarea valorii acesteia s-ar putea produce datorit" schimb"rii valorilor mai multor coloane (salariu_brut, zile_totale sau zile_lucrate), SGBD-ul ne#tiind care din aceste coloane trebuie actualizat" n tabelul de baz". Oracle respect" aceast" regul", existnd un set de reguli care determin" dac" o coloan" a unei vederi poate sau nu s" fie actualizat". Regula 7. Regula manipul"rii datelor: Un sistem rela!ional trebuie s" ofere posibilitatea proces"rii tabelelor (de baz" sau virtuale) nu numai n opera!iile de interogare a datelor ct #i n cele de inserare, actualizare #i #tergere. Aceasta nseamn" c" opera!iile de manipulare a datelor (inserare, actualizare #i #tergere) trebuie s" se poat" efectua asupra oric"rei mul!imi de rnduri dintr-un tabel, pornind de la ntregul tabel #i terminnd cu un singur rnd sau cu nici unul. Deci, un SGBD rela!ional nu oblig" utilizatorul s" caute ntr-un tabel rnd cu rnd pentru a reg"si, modifica sau #terge informa!ia dorit", deoarece opera!iile prin care se manipuleaz" con!inutul bazei de date lucreaz" la nivel de mul!ime de rnduri. Limbajul SQL asigur" aceast" facilitate prin instruc!iunile: INSERT cu subinterogare, UPDATE #i DELETE (vezi sec!iunile 8.2, 8.3 #i 8.4). Regula 8. Regula independen!ei fizice a datelor: Programele de aplica!ie nu trebuie s" depind" de modul de stocare #i accesare fizic" a datelor. Deci un SGBD rela!ional trebuie s" separe complet aspectele de ordin fizic ale datelor (modul de stocare #i modul de acces la date) de cele de ordin logic. Cu alte cuvinte, programele de aplica!ie nu trebuie s" depind" de stocarea fizic" a datelor. De exemplu, dac" un fi#ier care con!ine un tabel de date este mutat pe o alt" unitate de disc sau i este schimbat numele, aceasta nu trebuie s" aib" vreun efect asupra aplica!iilor care folosesc acel tabel, utilizatorilor fiindu-le transparent" aceast" schimbare. n mare, Oracle respect" aceast" regul", de#i stocarea fizic" a datelor trebuie luat" n considera!ie la proiectarea bazei de date. Regula 9. Regula independen!ei logice a datelor: Programele de aplica!ie nu trebuie s" fie afectate de nici o restructurare logic" a tabelelor bazei de date care conserv" datele. Deci orice modificare efectuat" asupra unui tabel care conserv" datele din acesta (de exemplu, dac" un tabel trebuie divizat n dou", din ra!iuni de cre#tere a performan!elor) nu trebuie s" afecteze func!ionarea programelor de aplica!ie. Aceast" regul" este respectat" de c"tre Oracle prin posibilitatea definirii vederilor: dac" un tabel este divizat n dou", atunci se poate crea o vedere care al"tur" cele dou" tabele, astfel nct aceast" mp"r!ire nu va avea nici un efect asupra aplica!iei. Regula 10. Regula independen!ei datelor din punctul de vedere al integrit"!ii: Regulile de integritate a bazei de date trebuie s" fie definite n limbajul utilizat de sistem pentru definirea datelor #i nu n cadrul aplica!iilor individuale; n plus, aceste reguli de integritate trebuie stocate n dic!ionarul de date. Cu alte cuvinte, restric!iile de integritate trebuie impuse la definirea tabelelor bazei de date #i nu n cadrul aplica!iilor care folosesc aceste tabele. n general, Oracle respect" aceast" regul", la definirea tabelelor (n cadrul comenzii CREATE TABLE) putndu-se defini att restric!iile de integritate structural" (NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY) ct #i unele restric!ii de comportament (CHECK). Informa!ii despre aceste restric!ii sunt stocate n dic!ionarul bazei de date. Regula 11. Regula independen!ei datelor din punctul de vedere al distribuirii: 28

Programele de aplica!ie nu trebuie s" fie afectate de distribuirea pe mai multe calculatoare a bazei de date. Cu alte cuvinte, baza de date trebuie s" mearg" corect indiferent dac" se g"se#te pe un singur calculator sau este distribuit" n mai multe noduri ale unei re!ele. Aceast" regul" este o extensie a regulii 8, privind independen!a programelor de aplica!ie fa!" de modul de stocare fizic" a datelor. Aceast" regul" este n general respectat" de Oracle, existnd totu#i restric!ii privind accesarea unor obiecte aflate n alt nod al re!elei. n plus, n Oracle exist" posibilitatea replic"rii locale a tabelelor aflate n alte noduri ale re!elei, evitndu-se astfel transmiterea n mod repetat a informa!iilor prin re!ea. Regula 12. Regula privind prelucrarea datelor de c"tre un limbaj de nivel inferior. Orice limbaj nerela!ional folosit pentru accesarea datelor trebuie s" respecte acelea#i condi!ii de integritate ca #i limbajul rela!ional de acces. De exemplu, dac" sistemul posed" un limbaj de nivel inferior, prin care se acceseaz" datele la nivel de rnd #i nu, potrivit sistemului rela!ional, la nivelul mul!imilor de rnduri, acest limbaj nu poate fi folosit pentru evitarea restric!iilor de integritate (integritatea entit"!ii, integritatea referen!ial", restric!ii de comportament) pe care trebuie s" le respecte limbajul procedural de acces la date. Aceast" regul" este respectat" de c"tre Oracle prin faptul c" singurul limbaj de accesare a datelor este SQL, care este un limbaj rela!ional. Dac" un SGBD ndepline#te principiile sistemului rela!ional (folose#te ca structuri de date tabele conforme cu modelul rela!ional, suport" cele dou" reguli de integritate structural" #i opera!iile rela!ionale) #i respect" aceste 12 reguli, atunci el poate fi numit rela!ional. Codd rezum" aceste lucruri prin regula zero: Regula 0. Regula de baz": Un SGBD Rela!ional trebuie s" fie capabil s" gestioneze baza de date exclusiv pe baza caracteristicilor sale rela!ionale. Aceasta nseamn" c" sistemul trebuie s"-#i ndeplineasc" toate func!iile prin manipul"ri n care unitatea de procesare s" fie tabelul (mul!imea de rnduri), asupra c"ruia s" se efectueze opera!iile specifice modelului rela!ional. Trebuie spus c" regula 0 nu este respectat" n totalitate de nici un SGBD existent pe pia!", inclusiv Oracle, implementarea acestora folosind att caracteristici rela!ionale ct #i nerela!ionale. Se obi#nuie#te ca, n conformitate cu tipul de cerin!e pe care le exprim", regulile s" fie grupate n cinci categorii, #i anume: 1. 2. 3. 4. 5. reguli de baz": Regula 0 #i Regula 12; reguli structurale: Regula 1 #i Regula 6; reguli privind integritatea datelor: Regula 3 #i Regula 10; reguli privind manipularea datelor: Regula 2, Regula 4, Regula 5 #i Regula 7; reguli privind independen!a datelor: Regula 8, Regula 9 #i Regula 11.

Trebuie spus c" nici unul dintre SGBD-urile existente n prezent nu satisface n totalitate toate cele 13 reguli ale lui Codd. De aceea, n practic" nu sunt utilizate regulile lui Codd, fiind formulate n schimb un set de cerin!e minimale pe care trebuie s" le satisfac" un sistem SGBD pentru a putea fi considerat rela!ional. Un SGBD este denumit minimal rela!ional, dac" satisface urm"toarele condi!ii: 29

1. Toate datele din cadrul bazei de date sunt reprezentate prin valori n tabele. 2. Nu exist" pointeri ntre tabele observabili de c"tre utilizator. 3. Sistemul suport" operatorii rela!ionali de proiec!ie, selec!ie #i compunere natural", f"r" limit"ri impuse de considerente interne. Un SGBD este denumit complet rela!ional dac" este minimal rela!ional #i satisface n plus urm"toarele condi!ii: 4. Sistemul suport" toate opera!iile de baz" ale algebrei rela!ionale, f"r" limit"ri impuse de considerente interne. 5. Sistemul suport" restric!iile de integritate de baz" ale modelului rela!ional (integritatea entit"!ii #i integritatea referen!ial") SGDB-ul Oracle este complet rela!ional #i chiar se apropie destul de mult de un SGBD rela!ional ideal, definit prin regulile lui Codd.

30