. Comparatie Intre Principalele Modele de Organizare a Datelor

COMPARAȚIE ÎNTRE PRINCIPALELE MODELE DE ORGANIZARE A DATELOR

INTRODUCERE

Menirea acestei teze scrise este aceea de a prezenta pe scurt unele dintre principalele modele de baze de date existente pe piață în acest moment. O privire de ansamblu asupra acestor tipuri de baze de date poate fi remarcate în cadrul acestei lucrări. În afară de privirea de ansamblu mai pot fi observate, în funcție de modelele abordate anumite tendințe existente în domeniul informaticii pentru bazele de date respective cât și câteva particularități ale modelelor aflate în discuție.

O privire mai amănunțită este remarcată în cadrul acestei lucrări de diplomă ca fiind efectuată asupra modelului relațional cât și asupra acelui orientat pe obiecte. Celelalte tipuri de modele nu sunt de neglijat cum ar fi modelul de baze de date WEB deoarece aceste modele pot avea și încep să aibă un impact major asupra vieții cotidiene a societății noastre.

Va fi prezentată o trecere în revistă a celor mai importante tipuri de baze de date și de SGBD-uri existente pe piața la momentul actual cât și punctele tari sau slabe ale acestora.

CAPITOLUL I MODELE DE ORGANIZARE A BAZELOR DE DATE

Acest capitol scoate în evidență câteva dintre cele mai importante modele de baze de date prin care se prezintă o evidențiere a caracteristicilor fiecarui tip de SGBD avut în discuție, cât și o scurtă prezentare a evoluției pe care au avut-o bazele de date.

1.1 Apariția bazelor de date

Pentru prima dată termenul de, bază de date, s-a folosit în iunie 1963, când System Developement Corporation a sponsorizat un simpozion sub titlul Developement and Management of a Computer-Centered Data Base. În Europa sintagma „baze de date”a început să fie populară la începutul anilor 70, și la sfârșitul decadei a fost preluată de marile ziare americane ale vremii.

Primul sistem de gestiune a bazelor de date a fost realizat în 1960. Un pioner în acest domeniu a fost Charles Bachman. Primele sale publicații au arătat că țelul acestuia a fost să facă mai eficient modul de utilizare a acestui nou dispozitiv de stocare și anume bazele de date. Până atunci procesarea datelor se realiza numai cu ajutorul mașinilor cu cartele perforate și a celor cu benzi magnetice. Primele două modele importante de date au fost realizate de CODASYL care a dezvoltat modelul rețea bazat pe ideile lui Bachman, iar North American Rockwell a dezvoltat modelul ierarhic, mai târziu adoptat de IBM.

Un model de date este un model care descrie într-un mod abstract modalitatea în care datele sunt reprezentate într-o firmă, un sistem informațional, sau un sistem de management al bazei de date.

Bazele de date relaționale au fost propuse de E.F.Codd în 1970. El a criticat modelele existente pentru că făceau confuzie, între descrierea abstractă a structurii informațiilor și descrierea fizica a acestora. Pentru un timp modelul relațional a avut doar interes academic. În același timp CODASYL au elaborat soluții practice luând în calcul soluțiile tehnologice existente în acel moment.

Modelul relațional a evoluat pe o latură tot mai teoretică, argumentând pe bună dreptate că partea soft este dezvoltată, iar partea hard a unui sistem va progresa odată cu timpul.

Printre primii implementatori în domeniu a fost Michael Stonebraker: (un specialist recunoscut pentru contribuțiile sale în implementări de baze de date). El a ajutat la crearea multor produse destinate bazelor de date relaționale existente pe piață. Este și fondatorul programelor: Ingres, Iliustra, Cohera și a StreamBase Systems cât și editorul cărții Readings în Database Systems, la Universitatea Berkeley și Sistem R, care este considerat primul SGBD relațional (construit de IBM). Acest proiect, a fost primul care a implementat limbajul bazelor de date SQL, care a devenit încă de atunci un standard în domeniu. A fost primul sistem care a demonstrat că un SGBD relațional , de management poate procesa adecvat tranzacțiile.

Cele menționate mai sus au fost prototipuri, anunțate în anul 1976. Primele produse comerciale în cadrul acestui domeniu, au fost Oracle și IBM. Există mai multe versiuni care merg atât pe handlneld așa zisele calculatoarele de buzunar, cât și pe mainframe-uri care sunt mari sisteme de procesare a datelor. În top se află DB2 Warehouse Edition (DB2 DWE) care rulează (pe Unix , Linux , Windows), care nu a apărut până în 1980. Prima bază de date care a avut succes la microcalculatoare a fost dBASE (dBASE a fost primul SGBD folosit pe scară largă) dezvoltat pentru platforma PC-DOS/MS-DOS (IBM PC-DOS a fost unul din majorele sisteme ce au dominat piața din 1985 până în 1995. MS-DOS a fost comercializat de Microsoft și a fost sistemul de operare dominant în anii ‘80).

În timpul anilor ‘80, atenția s-a îndreptat către bazele de date orientate-obiect, care au avut un mare succes, în domenii în care era necesară gestionarea datelor mai complexe decât cele din cadrul sistemelor relaționale, cum ar fi bazele de date multidimensionale. Câteva dintre aceste idei, au fost adoptate de către producatorii de software pentru baze de date relaționale care au integrat noi caracteristici în produsele

lor.

În anul 2000 apar bazele de date XML pe piață. Modulul intern al acestor tipuri de baze de date depind de XML și folosesc documente XML ca pe o unitate fundamentală de stocare. Bazele de date XML tind să înlocuiască diviziunea dintre dată și document, permițând ca toate datele unei organizații să fie ținute la un loc, chiar dacă ar fi stucturi mici sau mari.

Cu privire la manipularea datelor, putem afirma că necesitățile au fost mereu în creștere, fapt ce a determinat accesarea datelor, tot mai rapid și într-un volum din ce în ce mai mare. Pe măsură ce echipamentele de calcul și dispozitivele de memorare, au început să se dezvolte precum și perfecționarea tehnicilor de organizare și prelucrare a datelor, aceste posibilități devin din ce în ce mai largi, satisfăcând din ce în ce mai bine necesitățile existente pe piață. Apariția de noi posibilități, a stimulat formularea de noi cerințe, cu privire la serviciile pe care le-ar putea oferi o bază de date.

Principalele etape în evoluția instrumentelor software dedicate gestionării datelor pot fi prezentate după cum urmează :

1. Prima etapă referitoare la revoluția tehnicilor de organizare și prelucrare a datelor, are ca principală caracteristică adaptarea tipurilor de organizare a datelor existente, în sistemele de prelucrare manuală la condițiile tehnice impuse de utilizarea calculatoarelor electronice.

Fișierul reprezintă principalul tip de organizare a datelor utilizat în această etapă. Sistemele de prelucrare electronică a datelor, au preluat acest tip de organizare din sistemul manual. Etapa este marcată de utilizarea datelor organizate, în principal, în formă de fișiere secvențiale, acest tip de organizare fiind condiționat de utilizare pe scară largă a benzilor magnetice ca suport extern de memorare a datelor, neexistând o diferențiere clară între structura logică și cea fizică a datelor, acestea fiind de regulă similare. În timp ce structura datelor a fost proiectată pentru a executa câte o singură aplicație, fapt ce determină apariția unei redundanțe mari în memorarea datelor, datele reprezentând același aspect al lumii reale, sunt memorate separat pentru fiecare aplicație care are nevoie de aceste date.

2. Etapa a doua, este marcată de separarea dintre structura logică și cea fizică de date, prin intermediul căreia, se realizează independența fizică a datelor. Încep să fie utilizate, pe scară tot mai largă, fișierele secvențial-indexate și cele în acces direct, având ca suport extern de memorare discul magnetic. Prin separarea structurii de date logice de cea fizică, se asigură independența aplicațiilor atât față de modificările echipamentelor hardware (bandă magnetică, disc magnetic), cât și față de modul de organizare a fișierelor (secvențiale, secvențial-indexate, aleatoare).Fapt ce relevă că se pot schimba dispozitivele de memorare, fără a fi afectate aplicațiile. Schimbarea acestor dispozitive poate afecta, eventual, structura fizică a datelor, dar nu și pe cea logică. Aplicațiile ce sunt dependente doar de structura logică, nu vor fi afectate de această schimbare.

3. Etapa a treia este marcată de apariția fișierelor integrate.

O caracteristică a primelor două etape, constă în faptul că datele sunt organizate în fișiere specifice fiecărei aplicații în parte. Fiecare aplicație operează cu un grup propriu de fișiere, fără a avea nici o legătură cu fișierele utilizate de altă aplicație. Acest mod de organizare prezintă o serie de inconveniente:

redundanța datelor, manifestată prin faptul că aceleași date folosite în aplicații diferite sunt înregistrate în mai multe fișiere, fapt ce duce la utilizarea ineficientă a spațiului de memorare și ridică probleme în cazul unor operații de actualizare.

absența unor legături logice între date din grupuri diferite de fișiere, ceea ce determină în cazul aplicațiilor complexe, creșterea excesivă a timpului de prelucrare, fie creșterea numărului de fișiere.

flexibilitatea redusă a sistemului care se manifestă prin aceea că la apariția unei noi aplicații, este necesară fie crearea unuia sau mai multor fișiere noi, fie reorganizarea celor existente.

Aceste tipuri de inconveniențe pot fi eliminate prin înlocuirea grupurilor de fișiere destinate unor aplicații particulare, cu un sistem complex de elemente de date, unde legăturile logice dintre acestea determină organizarea lor și mai puțin modul de prelucrare din cadrul fiecărei aplicații.

4. Etapa a patra este etapa bazelor de date.

Trecerea la utilizarea fișierelor integrate, a oferit posibilitatea exploatării în comun a acelorași date de către mai multe aplicații, fapt ce a determinat necesitatea realizării independenței aplicațiilor, față de structura logică a datelor. Datorită apariției modelelor externe, la independența fizică a datelor, se mai adaugă și independența logică, fapt ce înseamnă că există posibilitatea modificării datelor în structura logică a bazei de date fără, ca aceasta să afecteze aplicațiile.

În această etapă se concretizează modelul conceptual, ca nivel virtual de organizare a datelor, la care se adaugă modelele externe, asociate fiecărui utilizator.

1.2 Baze de date ierarhice

Modelul ierarhic este primul model utilizat pentru organizarea datelor în baze de date. El se bazează pe structura arborescentă și pe relațiile de tipul : 1-1(unu la unu) și 1-n (unu la multe), reprezentându-se sub forma unui arbore, în care se regăsesc pe un prim nivel –rădăcină (nod părinte), iar pe nivelurile următoare, diferite elemente subordonate (noduri-copil).

Nodul părinte poate avea subordonate mai multe noduri-copil, în timp ce un nod copil nu poate avea decât un singur părinte. Rezultă că relația părinte-copil poate fi de tipul 1-n, iar relația copil părinte poate fi doar de tipul 1-1.

Figura de mai jos prezintă o schemă privită pe ansamblu a modelului ierarhic.

Figura nr.1.1 Modelul ierarhic

Sursa http://www.profc.udec.cl/~gabriel/tutoriales/giswb/vol1/cp4/4-3.gif

Într-o bază de date ierarhică, datele sunt organizate sub forma unei structuri arborescente, ceea ce implică o singură „verigă” superioară în fiecare înregistrare, pentru a descrie cuibul și un câmp de sortare, într-o ordine predefinită pe fiecare nivel identic din listă. Structura ierarhică a fost folosită la scară largă în primele mainframe-uri de management al bazelor de date, cum ar fi Information Management System (IMS), sistemul informativ pentru management realizat de IBM. Această structură permite legături de tipul 1:N (unul la multe) între tipurile de date. Este foarte eficientă pentru a descrie multe relații din lumea adevărată: rețete, tabele, ordonarea paragrafelor/ versurilor, sortarea oricărei informații. De asemenea, această structură este ineficientă pentru anumite operații din cadrul bazelor dru anumite operații din cadrul bazelor de date (navigarea în sus și fișierul de sortare) nu sunt întotdeauna incluse pentru fiecare înregistrare.

Structura arborescentă permite repetarea informațiilor folosind relația părinte/copil orice părinte poate avea mai mulți copii, dar orice copil poate avea numai un părinte. Toate atributele unei înregistrări anume, sunt listate sub forma unei entități. Într-o bază de date, o entitate este echivalentul unei tabele, fiecare înregistrare este reprezentată sub forma unui atribut într-o coloană. Entitățile sunt corelate între ele folosind relația unu la multe .

Acest model asigură organizarea datelor pe orice tip de suport magnetic și reducerea timpului de acces la înregistrări .

Modelul ierarhic prezintă o serie de limite, în special în operațiile de actualizare, când adăugarea unei noi înregistrări, cu excepția celor din colecția de date rădăcină, se poate efectua numai cu specificarea colecțiilor de date superioare, iar ștergerea unei înregistrări duce la eliminarea fizică a tuturor înregistrărilor subordonate .

1.3 Baze de date rețea

Modelul rețea elimină redundanțele specifice modelului ierarhic și se bazează pe structurile rețea și pe relațiile de tipul 1-1,1-n și n-n .

Caracteristica principală a acestui model, este că acceptă ca orice colecție de date să se situeze pe nivelul unu, astfel fiind permis accesul direct la realizările colecțiilor superioare, operație imposibil de realizat în cadrul modelului ierarhic. În plus, prin acest model, este permisă reprezentarea unică a relațiilor în baza de date.

Legăturile fizice pe suport sunt asigurate prin intermediul unor caracteristici care exprimă pointerul (adresa de pe suport), realizării superioare sau a realizării subordonate. Astfel rețeaua este un graf orientat alcătuit din noduri ce sunt conectate prin arce. Nodurile corespund tipurilor de înregistrări, iar arcele pointerilor. Atât modelul ierarhic cât și modelul rețea nu permit realizarea unei independențe logice satisfăcătoare între date și programe, deoarece relațiile dintre date există și sunt diferite în programele de aplicații.

Modelul rețea este un model de baze de date proiectat într-un mod flexibil de reprezentare a obiectelor și a relațiilor dintre ele. Charles Bachman a fost cel care a inventat acest tip de baze de date, care a fost dezvoltat într-un standard, publicat în 1969 de către consorțiul CODASYL. Modelul ierarhic structurează datele sub formă de arbore, ce conține înregistrări, fiecare înregistrare având un părinte și unul sau mai mulți copii. Modelul rețea permite fiecărei înregistrări să aibă mai mulți părinți și copii (înregistrări).

Figura de mai jos prezintă o schemă privită pe ansamblu a modelului rețea.

Figura nr .1.2 Modelul rețea

Sursa http://www.profc.udec.cl/~gabriel/tutoriales/giswb/vol1/cp4/4-3.gif

Modelul rețea este definit de specificațiile CODASYL, care organizează datele folosind două construcții fundamentale : record și set . Record conține câmpuri care pot fi organizate ierarhic. Se definește relația unu la multe, între înregistrări exemplu : o femeie, mulți membri. Navigarea pe o astfel de rețea se poate face astfel : programul menține poziția curentă și navighează de la o înregistrare la alta, urmărind relația în care înregistrarea participantă este dominantă. În general bazele de date rețea implementează setul de relații prin pointeri (un tip de dată a cărei valoare face referire la o altă valoare stocată pe computer folosindu-i adresa ), care acționează direct adresa înregistrării de pe disk. Acest fapt dă bazei de date un excelent atu de aducere a datei, fapt ce ajută atunci când realizăm încărcarea sau reorganizarea bazei de date .

Tipul respectiv de baze de date are un mod flexibil de reprezentare a obiectelor și a relațiilor dintre ele .

Principalul argument în favoarea modelului rețea în comparație cu modelul ierarhic, este acela că permite o modelare mai naturală a relațiilor dintre entități. Deși modelul a fost implementat și folosit la o scară largă, nu a putut să ajungă lider pe piață, din două motive : primul motiv este acela că IBM a ales să rămână la modelul ierarhic pentru produsele lor, iar al doilea motiv a fost acela că acest model în cele din urmă, a fost înlocuit de modelul relațional, care a oferit o interfață mai bună. Până la începutul anilor ‘80, performanțele de care beneficiau și interfețele de navigare de nivel redus, oferite de modelele ierarhice și rețea, nu făceau față la aplicațiile mari, dar de când componenta hard a devenit mai rapidă, a crescut productivitatea și flexibilitatea modelului relațional si a înlocuit modelul rețea în firme.

Interfața oferită de modelul rețea prezintă câteva asemănări cu un model hyperlink, care a devenit din ce în ce mai cunoscut, odată cu dezvoltarea Internetului și a World Whide Web-ului. Totuși modelul rețea ca și modelul relațional presupune că întreaga bază de date, are o schemă (o hartă cu componentele bazei de date și a relațiilor dintre ele) și este foarte ușor de distribuit .

Standardul pentru bazele de date de tip rețea este reprezentat de documentele emise de comisia DBTG (Data Base Task Group) înființată cu ocazia conferinței de normalizare a limbajelor pentru baze de date (Conference on Data System Language-CODASYL) din anul 1971. Raportul original ce a fost eliberat de această comisie, a suferit o serie de modificări, în anii ce au urmat (1973,1976,1977,1978). Propunerea DBTG este o specificare în detaliu a unui sistem de gestiune a bazelor de date, având la bază modelul de date rețea.

Modelele de date tip rețea sunt bazate pe tabele și grafuri corespunzător celor două forme de structurare a datelor folosite: tipul de înregistrare și legăturile explicite. Nodurile grafului corespund tipurilor de entități, reprezentate sub formă de tabele, iar arcele grafului corespund relațiilor între mulțimi de entități și sunt reprezentate sub formă de legături între tabele.

1.4 Baze de date relaționale

Prezumția care stă la baza modelului relațional, este aceea că toate datele sunt reprezentate matematic ca o relație de n domenii. În acest context, există două metode de evaluare pentru fiecare propoziție, de obicei aceasta este adevarata(true) sau falsă(false) (și în particular nici o a treia valoare cum ar fi necunoscut sau neaplicabilă, ambele fiind asociate cu conceptul de NULL). Unii cred că, logic (în principal două valori ) reprezintă o parte importantă a modelului relațional, iar alții cred că un sistem care folosește trei valori logice poate să fie încă considerat relațional .

Acest tip de model s-a focalizat în special pe aplicații de procesare în domeniul afacerilor și mulți cercetători au scos în evidență faptul că, acest tip de baze de date are probleme, în ceea ce privește funcționarea și procesarea unor mari cantități de date. De obicei biologii găsesc că este greu de stocat date de genul secvențelor ADN-ului, deoarece bazele de date relaționale, nu pot face față datelor secvențiale, ele rulând cu date neordonate. Unul din dezavantajele acestui model, este acela că nu suportă date ordonate ierarhic. Acest model de baze de date este foarte avantajos, când vine vorba despre procesarea datelor ordonate după o anumită schemă sau date de o complexitate redusă .

Modelul relațional permite celui care realizează baza de date, să construiască o bază de date consistentă. Consistența este atinsă prin declararea constraint-urilor în designul bazei de date, care de obicei se numește schema logică a bazei de date .

Acest tip de baze de date se poate folosi îndeosebi la construirea sistemelor în noi domenii cum ar fi cel multimedia. Teoria menționează procesul de normalizare (proces de restructurare a bazei de date, proces ce are loc cu scopul eliminării redundanței, a organizării datelor într-un mod mai eficient, astfel reducându-se datele repetitive), în cadrul căruia se poate alege varianta dorită, din cadrul variantelor obținute prin procesul de normalizare.

Modelul relațional a apărut relativ târziu în teoria și practica bazelor de date, fiind necesară atingerea unui anumit nivel de performanță a echipamentelor de calcul, pentru a se conștientiza, faptul că modelul relațional poate constitui nu numai un valoros instrument de studiu în teoria bazelor de date cât și punctul de pornire pentru realizarea unor SGBD-uri competitive din punct de vedere al performanțelor. Amintim că primul model de baze de date bazat pe relații și pe reprezentarea acestora sub formă de tabele a fost propus de către cercetătorul american E.F.Codd. Ideile acestuia au fost publicate, într-o suită de lucrări de referință apărute începând cu anul 1970. Principiile care stau la baza modelului relațional pornesc de la teoria matematică a relațiilor, extinsă în mod logic, pentru a satisface cerințele activității de gestionare a datelor. Numeroase rezultate din teoria relațiilor își găsesc aplicabilitatea practică în cazul diferitelor probleme legate de bazele de date relaționale.

Figura de mai jos prezintă o schemă privită pe ansamblu a modelului relațional.

Figura nr.1.3 Modelul relațional

Sursa http://www.profc.udec.cl/~gabriel/tutoriales/giswb/vol1/cp4/4-3.gif

Acest model relațional se află la baza majoritații SGBD-urilor comerciale care există și apar la ora actuală. Popularitatea crescândă a modelului relațional și răspândirea tot mai largă a bazelor de date relaționale se datorează faptului că acestea dispun de limbaje de manipulare a datelor de nivel înalt, simple dar foarte puternice. Principala caracteristică a acestor limbaje, numite generic limbaje relaționale, este capacitatea acestora de a permite definirea de relații noi, pe baza unor relații deja existente. Pornind de la aceste limbaje la majoritatea SGBD-urilor relaționale au fost dezvoltate interfețe flexibile care permit exploatarea directă a bazelor de date pentru categorii mult mai largi de utilizatori decât în cazul sistemelor ierarhic sau rețea.

1.5 Baze de date obiectuale

Bazele de date orientate pe obiecte reprezintă rezultatul perfecționării tehnologiei sistemelor informatice, în condițiile în care calculatorul electronic tinde să devină cvasiprezent. Complexitatea structurilor de date depășește structurile clasice de prelucrare, iar cerințele utilizatorilor sunt din ce în ce mai mari. Stocarea unor informații cu o structură complexă (grafică, imagine fotografică, video, sunet, muzică) și într-un volum tot mai mare, necesită sisteme noi în care să se îmbine tehnologii de achiziționare, stocare și prelucrare a noilor tipuri de date neconvenționale, cu metode corespunzătoare de administrare a acestora.

În bazele de date de tip SQL și XBase pentru tabelele neconvenționale s-au creat tabele de tip BLOB (Binary Large OBject), care neavând o organizare internă, nu pot fi administrate ca entități, deci nu este posibilă găsirea și nici accesul la entitățile lor. Una din posibilitățile de rezolvare a acestor aspecte, o reprezintă introducerea în tehnologia sistemelor informatice a conceptelor programării obiectuale .

Bazele de date orientate pe obiecte permit crearea de obiecte complexe din componente mai simple, fiecare având propriile atribute și propriul comportament .

Acest tip de baze de date are un atu și anume viteza de acces a datelor în comparație cu celelalte tipuri de baze de date. Acest aspect este asigurat prin intermediul unei hărți a ierarhiilor și a relațiilor claselor de obiecte, pe care baza de date o stochează. De asemenea pentru gruparea sau porționarea fizică a datelor (tehnica numita clustering) baza de date orientată pe obiect asigură accesarea eficientă a obiectelor necesare la un moment dat unei cereri utilizator, minimizând traficul prin rețea. În plus, este permisă și accesarea tuturor obiectelor ceea ce face ca simultan mai mulți utilizatori și aplicații să aibă fiecare o imagine a modelului obiect original .

Rezolvarea unei probleme cu ajutorul sistemelor orientate pe obiect implică trei aspecte :

un aspect static sau descriptiv prin care sunt identificate proprietățile obiectelor și legăturile dintre ele ;

un aspect dinamic prin care se precizează comportamentul obiectelor și diferitelor stări prin care acestea trec și evenimentele care declanșează schimbările de stare ;

un aspect funcțional prin care se precizează funcțiile realizate de către obiecte prin intermediul metodelor.

Figura de mai jos prezintă o schemă privită pe ansamblu a modelului obiectual.

Figura nr .1.4 Modelul obiectual

Sursa http://www.profc.udec.cl/~gabriel/tutoriales/giswb/vol1/cp4/4-3.gif

Bazele de date orientate obiect au la bază noțiunile de obiect și clasă . Obiectele sunt folosite pentru a reprezenta entități din lumea reală, ele având o identitate. O clasă poate să fie folosită pentru a defini un set de obiecte. Obiectele din aceeași clasă au aceeași structură și aceleași operații numite metode. Clasele sunt organizate ierarhic și constituie schema bazei de date .

1.6 Diferențe între principalele modele de baze de date

Modelul de date ierarhic este, cronologic primul model de date utilizat în construirea SGBD-urilor. Acest tip de model folosește două forme de structurare a datelor, tipuri de înregistrări și legături explicite. Legăturile sunt restricționate astfel încât să se încadreze într-o structură de arbore ordonat, astfel de structuri având proprietatea că sunt linearizabile. Acestea permit folosirea unor structuri fizice de reprezentare foarte eficiente care pot fi înregistrate chiar și pe suporturi de memorare cu acces strict secvențial cum ar fi benzile magnetice. Interogările care presupun exploatarea legăturilor ierarhice pot fi tratate cu mare eficiență. Cât privește datele care nu pot fi încadrate într-o ierarhie atunci putem vorbi de faptul că, modelul ierarhic eșuează atunci când începe modelarea acestora. În ceea ce privește legăturile de tip m: n nu există o soluție satisfăcătoare pentru reprezentarea acestuia iar rezolvarea unei interogări care nu se ”potrivește” structurii ierarhice predefinite este practic imposibilă.

Modelul de date rețea este mai general decât modelul ierarhic, structura legăturilor explicite fiind arbitrară și reprezentată printr-un graf. Există o restricție care se referă la latura legăturilor care trebuie să fie de tip funcțional, ceea ce face ca nici în cadrul modelului rețea, să nu poată fi prezentate direct legăturile de tip m:n. Cât privește soluția larg utilizată pentru reprezentarea legăturilor m:n constă în folosirea tipurilor de legătură. Modelul de date rețea permite reprezentarea unor structuri de date mult mai complexe decât modelul ierarhic și orice interogare poate fi rezolvată eficient, dacă s-au prevăzut pentru aceasta legăturile explicite necesare. Marele avantaj al modelului rețea este acela că pentru aplicațiile mai complexe structurile de reprezentare devin foarte complicate. Acest aspect, menționat anterior se manifestă, în special în cazul unor legături între trei sau mai multe entități, din acest motiv scrierea și mai ales integritatea programelor de aplicații pentru bazele de date de tip rețea este dificilă și costisitoare, fiind acesibilă doar unei categorii restrânse de persoane, având o anumită calificare profesională.

O caracteristică comună modelelor de date ierarhic și rețea este folosirea limbajelor navigaționale pentru formularea interogărilor. Limbajele navigaționale se bazează pe utilizarea conceptului de cursor, care indică poziția curentă în baza de date. Utilizatorul poate modifica poziția cursorului sau poate efectua operații asupra datelor ce se află la poziția curentă. Cu privire la legăturile explicite din cadrul bazei de date, acestea sunt exploatate direct de către limbajele navigaționale, iar rezolvarea interogărilor presupune în special „navigația” cursorului pe lanțurile de legături, ceea ce justifică numele generic al acestei clase de limbaje. În ceea ce privește duplicatele, acestea sunt permise în ambele modele, iar două obiecte similare pot fi distinse având identitate proprie.

O bază de date relațională este o colecție de relații care reprezintă fie câte un tip de entitate, fie o legătură, în general de tip m:n, între două sau mai multe tipuri de entități. În cadrul acestor tipuri de relații, nu sunt permise duplicatele, deci spre deosebire de modelele ierarhic și rețea, în cadrul modelului relațional nu este valabil principiul identității obiectelor. Se mai spune că modelul relațional este orientat pe valoare, distincția dintre două tupluri realizându-se exclusiv pe baza valorilor atributelor componente. În cadrul acestui model nu există, în ceea ce privește relațiile, legături explicite, dar la execuția interogărilor apare necesitatea de a realiza conexiuni între diferitele relații. Acest lucru se poate realiza prin cuplarea dinamică a acestor relații, unde implementarea operațiilor de cuplare este destul de costisitoare din punct de vedere al volumului de calcul și al necesarului de memorie. Din acest motiv realizarea unei implementări eficiente, care să poată concura cu succes implementările corespunzătoare celorlaltor modele, s-a dovedit a fi destul de dificilă. A fost nevoie pentru aceasta atât de dezvoltarea echipamentelor de calcul și de memorare, cât și a tehnicilor de programare și de structurare a datelor .

Simplitatea structurilor bazelor de date relaționale, cât și lipsa legăturilor explicite facilitează formularea interogărilor bazelor de date prin limbaje de nivel înalt cum este algebra relațională sau orice limbaj echivalent, numite generic limbaje relaționale. Caracteristica acestor limbaje este faptul că operează asupra unor relații, iar rezultatele propuse sunt la rândul lor tot relații, neexistând aici noțiunea de cursor, se operează cu relațiile în întregul lor.

Limbajele relaționale sunt deosebit de simple și flexibile unde simplitatea acestor limbaje, a deschis calea spre utilizarea bazelor de date pentru categorii mult mai largi decât în cazul celorlalte modele de date. Popularitatea bazelor de date relaționale se datorează, în mare măsură ușurinței cu care pot fi formulate cele mai diverse tipuri de interogări cu ajutorul limbajelor relaționale. Datorită folosirii unui singur concept pentru reprezentarea asociațiilor în baze de date relaționale, limbajele relaționale prezintă un caracter unitar, cu un set mai restrâns de operatori pentru realizarea accesului la date, decât în cazul celorlalte modele. În ceea ce privește flexibilitatea în cadrul bazelor de date relaționale nu există legături explicite, dar toate legăturile posibile între mulțimile de entități sunt realizabile prin cuplarea dinamică a relațiilor, fapt ce înseamnă că utilizatorul poate formula interogări pe care proiectantul bazei de date nu le-a prevăzut în mod explicit. Descrierea unei baze de date relaționale constă în principal, din descrierea relațiilor (domenii ,atribute), structura bazei fiind deosebit de simplă. Natura interogărilor ce urmează a fi adresate bazei de date realaționale, nu influențează structura acesteia, spre deosebire de modelele ierarhic și rețea unde gama interogărilor probabile determină în cea mai mare parte structura de legături explicite a bazei de date, iar necesitatea de a răspunde unor noi interogări presupune de cele mai multe ori, adăugarea de noi elemente de structură sau modificarea celor existente.

CAPITOLUL II MODELUL RELAȚIONAL

Acest capitol îsi propune sa prezinte modelul relațional de baze de date , evoluția pe care a avut-o acest model, atât caracteristicile și regulile care stau la baza acestui model de baze de date.

2.1 Structurarea

Modelul relațional a fost introdus de E.F.Codd în anul 1970 și a evoluat de atunci, printr-o impresionantă serie de lucrări și publicații. Modelul ne prezintă o mostră riguros definită, concept prin care utilizatorii percep datele. Modelul relațional reprezintă datele sub forma a două tabele dimensionale. Fiecare tabelă reprezintă din lumea reală: o persoană, loc, lucru sau eveniment despre care se colectează informații.

Modelul a fost definit inițial printr-o serie de structuri de date (relații alcătuite din tupluri), operații aplicate asupra structurilor de date (selecție, proiecție, joncțiune) și reguli de integritate care să asigure consistența datelor (chei primare, restricții referențiale) .

Modelarea realității se concretizează în tabele de valori numite relații, avându-se în vedere faptul că :

relația are un nume ;

coloana reprezintă un atribut ;

linia reprezintă un tuplu de valori ale celor „n” atribute din relație ;

ordinea liniilor și coloanelor în cadrul tabelei nu este relevantă pentru conținutul informațional .

Fiecare linie a tabelei reprezintă o entitate sau un fapt al realității, în timp ce o coloană reprezintă o proprietate a acestei entități sau fapt. Entitatea poate să fie nu numai un obiect concret /proces dar și o relație între obiecte cum ar fi contracte de afaceri, structura ierarhică a unei organizații. În plus nu totdeauna este evident care dintre informații sunt entități atribute și care asociații (relații) .

Dintre coloane, o parte au drept scop identificarea liniilor (cheia primară) altele constituie suportul de referință către linii din tabele (coloane de referință sau chei străine).

Modelului relațional îi este asociată teoria normalizării, ce are ca scop prevenirea comportamentului aberant al relațiilor în momentul actualizării lor, eliminarea datelor redundante și înțelegerii legăturilor dintre ele.

Articolele lui Codd au avut un ecou semnificativ în lumea cercetărilor. Firma IBM a inițiat un proiect major, care trebuia să se materializeze în implementarea unui sistem de gestiune a bazelor de date relaționale, numit System/R . Proiectul s-a derulat în laboratorul Santa Teresa din San Jose, California . Prima fază a proiectului a avut loc în anii 1974 și 1975 și s-a concretizat într-un prototip al sistemului de gestiune al bazei de date, prototip ce a fost rescris în 1976-1977, pentru a permite interogarea simultană a mai multor tabele și accesul multiutilizator. IBM a distribuit produsul pe parcursul anilor 1978-1979 la câțiva colaboratori ai săi pentru evaluări, dar în 1979 firma abandonează proiectul, considerându-l nefezabil.

În anul 1977, un grup de ingineri de la Menlo Park, California, a fondat compania Relational Software Inc, cu scopul declarat de a dezvolta un sistem de gestiune al bazelor de date bazat pe limbaj SQL. Produsul denumit Oracle, a fost lansat în 1979 și a reprezentat primul sistem de gestiune al bazelor de date relaționale comercial.

Dincolo de faptul că Oracle precedă cu doi ani primul SGBDR comercial al firmei IBM, orientarea sa a fost extrem de bine gândită, rulând pe microcalculatoarele VAX, sensibil mai ieftine decât mainframe-urile IBM, și deci cu un segment de piață mai mare, fapt ce a garantat succesul. Astăzi firma se numește Oracle Corporation, este liderul produselor software dedicate mediilor de lucru cu baze de date.

Primul sistem de gestiune al bazelor de date relaționale comercializat de IBM a fost SQL/DS (DS-Data System), anunțat în 1981 și comercializat în 1982.

Alte sisteme de gestiune pioniere din domeniul bazelor de date relaționale au fost: INGRES ( Interactive Graphics and retrival System – al Universității Berkeley ); QUERY BY EXEMPLE – Centrul de cercetări T.J.Watson .

Până la jumătatea anilor ’80 sistemele de gestiune a bazelor de date relaționale au stat în umbra celor ierarhice și rețea. Motivul principal l-a constituit viteza mai mică, parametru esențial în sistemele confruntate cu sute sau chiar mii de utilizatori. În a doua parte a anilor ’80, performanțele acestor tipuri de sisteme au fost net ameliorate. Câștigul de viteză, care s-a adăugat atuului principal interogarea ad-hoc prin utilizarea limbajelor din generația a patra (SQL , QBE , Quel) a lărgit continuu segmentul de piață ocupat de SGBDR-uri, acestea fiind estimate în 1997 la circa 60% din totalul pieței .

Practic pentru toate platformele și sistemele de operare există o întreagă gamă de SGBDR-uri deosebit de performante, printre „protagoniști” numărându-se produsele firmelor: Oracle , IBM , Sybase , Infornix , Microsoft .

O adevărată „democratizare” a SGBDR -urilor s-a produs odată cu dezvoltarea explozivă a PC-urilor. Produsele precum DBase, RBase, Clipper, FoxPro, Paradox, Access, s-au vândut în milioane de exemplare. Destinate inițial utilizatorilor de PC-uri cu un bagaj redus de cunoștințe în domeniul bazelor de date, astăzi aceste produse sunt dotate cu seturi puternice de instrucțiuni și funcții, dar prezintă și o interfață de lucru destul de prietenoasă , atu ce oferă o mare dinamică acestui segment al pieței .

Anul 1991 a devenit anul în care, marea majoritate a publicațiilor de specialitate au „încoronat” la categoria SGBD-uri pentru microcalculatoare pe FoxPro 2.0, iar altele precum PC Magazine, InfoWorld, PC Computing l-au desemnat drept „cel mai bun produs program al anului 1991”. Este și motivul pentru care și în 1992 firma Microsoft, care la acea dată nu avea un SGBD de forță la această categorie, a înghițit Fox Software și începând cu versiunea 2.5 , FoxPro poartă sigla gigantului.

Lumea SGBD-urilor micro a suferit schimbări majore atât în „fizionomie”, dar și în modul efectiv de lucru, mai ales pentru cele din clasa XBase. Visual Objects (Computer Associates ), Visual FoxPro, seamănă din ce în ce mai puțin cu ceea ce a fost altă dată un produs XBase, fiind instrumente care înglobează tehnologii recente: client-server, replicare, programare orientată pe obiecte, dezvoltarea rapidă a aplicațiilor (RAD).

Este greu de făcut o ierarhizare, însă piața a consacrat la această categorie produsul Access al firmei Microsoft. Ajuns la versiunea 2003, inclus în suita Office cu același sufix, putem afirma că Access este un produs ieftin. Intuitive și bine integrate Excel și Word, determina ca aria lor de utilizare să fie superioară oricărui alt produs competitor.

Urcând la categoria superioară SGBDR-urilor micro, se cuvine de amintit că piața a cochetat pe la mijlocul anilor ’90 cu sintagma servere de date pentru grupuri de lucru .

Odată cu trecerea timpului SGBD-urile pentru grupuri de lucru au fost asimilate de cele de „categoria grea”: Oracle, DB2, XBase, Informix, SQL Server. Acestea sunt orientate pe gestiunea informatizată a organizațiilor mari și foarte mari, asigurându-se accesul simultan a sute, chiar mii de utilizatori la aceeași bază de date.

În prezent lucrurile s-au modificat în bine, astfel au apărut în locul serverelor de date pentru grupuri de lucru servere de baze de date care reprezintă o componentă esențială a tehnologiei de acum.

Astăzi se fac eforturi în ceea ce privește „mariajul’’ dintre modelul relațional și cel obiectual. Includerea de noi tipuri de date, extensii ale nucleului relațional „tradițional” al bazelor de date către obiecte, suportul pentru Web și comerț electronic sunt doar câteva domenii pe care s-au înscris SGBDR-urile actuale, pentru a-și conserva sau ameliora poziția de pe piață.

O bază de date relațională este o colecție formată din două tabele relaționale. Organizarea datelor în tabele relaționale este cunoscută sub denumirea de privire logică asupra bazei de date. Aceasta este forma în care o bază de date relațională prezintă datele către useri și programator.

Problemele pe care le tratează modelul relațional sunt cele ale consistenței datelor, a independenței programelor și activităților de terminal, de creșterea tipurilor de date și a schimbărilor realizate în consistența acestora, care se prevăd a fi problematice.

Modelul relațional pare a fi superior modelului rețea. Acest model ne oferă posibilitatea de a descrie datele așa cum sunt ele în realitate fără a mai adăuga în compoziție o altă structură pentru a fi reprezentată pe mașină. Oferă o bază pentru un nivel înalt de programare , cu nivel maxim al independenței dintre programe, pe de o parte și reprezentarea mașinilor și a organizațiilor de date pe de altă parte.

Un alt avantaj al modelului relațional este acela că formează o bază sănătoasă pentru tratarea derivabilității, redundanței și consistenței dintre relații.

În final modelul relațional permite o evaluare clară a scopului și a limitărilor logice de reprezentare și formatare a sistemului de date, cât și mijlocul relativ (din punct de vedere logic) a reprezentării competitive de date, într-un singur sistem.

Elementele de date dintr-un banc de date, pot fi stocate în mai multe feluri câteva implicând un concept de ordonare, unele permițând fiecărui element să participe, doar la o singură ordonare, altele permițând fiecărui element să participe la mai multe ordonări. Să considerăm aceste sisteme existente, care permit elementelor de date să fie stocate în cel puțin o singură ordonare , care este îndeaproape asociată cu ordinea determinării adreselor hardware. De exemplu înregistrările dintr-un fișier, care poate fi stocat într-un mod ascendent după un număr serial. Acest tip de sisteme permit programelor de aplicație să asume că ordinea reprezentării înregistrărilor dintr-un asemenea fișier este identic cu ordinea stocării. Aceste aplicații program, care folosesc acest avantaj, cel al ordinii de stocare al fișierelor de obicei nu pot fi operate corect dacă, dintr-un anumit motiv devine necesar de înlocuit ordinea cu alta. Multe din sistemele de formatare a datelor permit utilizatorului printr-o structură arborescentă a fișierelor sau altfel de structură tip rețea de date, să acceseze datele.

Modul în care softwerul bazei de date stochează fizic datele în calculator se numește privire internă . Modul în care se stochează datele efectiv pe disk, diferă de la produs la produs .

O bază de date relațională poate fi definită, într-un mod simplist, ca un ansamblu de relații (tabele), fiecare tabelă fiind la rându-i alcătuită din linii (tupluri), care se stochează pe un suport extern (de obicei disk). La intersecția unei linii cu o coloană se găsește o valoare atomică.

În teoria relațională se folosește termenul de relație, practica a consacrat alt termen tabelă (din engleză table).

Un tuplu sau o linie reprezintă o succesiune de valori de diferite tipuri.

Ansamblul valorilor de același tip corespunde unui atribut al entităților, atribut al cărei valori alcătuiesc una din coloanele unei tabele. Fiecare atribut se identifică printr-un nume și un domeniu .

Domeniul poate fi definit ca ansamblul valorilor acceptate pentru un element component al relației, de exemplu : dacă avem o tabelă cu datele generale ale angajaților pentru atributul sex vom avea două valori : bărbătesc si femeiesc .

În cadrul limbajului SQL valoarea NULL reprezintă un semn special care poate apărea în locul unei valori din tabelă. Acest tip poate să apară în interiorul unei tabele, iar poziționarea ei poate să difere de la tabelă la tabelă, neavând un loc anume sau ocupând o anume poziție. Deobicei valoarea NULL este definită prin valorile 0 sau spațiu.

Altă noțiune a modelului relațional este cea căreia, prin traducerea din view (imagine) i s-au asociat multiple titulaturi în literatura de specialitate și practica din țara noastră: imagine, relații virtuale ,tabelă sau relație (tabelă) dinamică.

O relație virtuală stabilește o legătură semantică între relații statice și /sau alte relații dinamice, nefiind definite explicit, prin tupluri proprii, ca o relație de bază (statică), ci printr-o expresie relațională. Conținutul relației virtuale, depinde la un moment dat de conținutul tabelelor de bază din care derivă, pentru a înțelege mai bine diferența, explicație ce se poate rezuma astfel: tabela virtuală este cea pentru care pe disc se menționează numai schema, nu și conținutul.

Tabelele virtuale oferă oricărui utilizator al bazei de date posibilitatea reprezentării datelor în funcție de nevoile sale specifice. De asemenea, rațiunii de securitate și confidențialitate al anumitor informații, pot conduce la izolarea unor date față de utilizatorii neautorizați, lucru deplin posibil prin intermediul imaginilor. Pornind de la aceeași tabelă de bază, se pot creea un mare număr de tabele virtuale în funcție de situație.

Tabelele derivate sunt suportul creației schemelor externe. O dată definită, o tabelă virtuală poate fi privită ca o tabelă de bază oarecare. De asemenea ca și în cazul relațiilor de bază și „imaginile” pot fi actualizate, ceea ce atrage modificarea tabelelor statice din care derivă. În aceste situații apar o serie de probleme. Este clar că modificarea conținutului tabelelor de bază presupune modificarea conținutului tabelei (sau tabelelor) derivate. Actualizarea unei relații dinamice, se face exclusiv de la tabelele de bază din care derivă. Este cea mai restrictivă și în contradicție cu regulile ce definesc un sistem de gestiune al bazelor de date relaționale, asa cum au fost ele definite de Codd. Am menționat mai sus doar una din probleme. Definirea unor proceduri generale de corespondență, pornindu-se de la expresia relațională de creeare a tabelelor derivate, proceduri pe baza cărora SGBD-ul va „traduce” actualizarea tabelei virtuale în modificări a tabelelor de bază, ceea ce reprezintă o a doua problemă . A treia problemă o reprezintă controlul actualizării relației derivate, prin intermediul unui sub-sistem de integritate al bazei de date. Această soluție este considerată ca fiind cea mai eficace pentru păstrarea coerenței și securității întregului ansamblu de relații ce alcătuiesc baza de date, fie ele statice sau dinamice.

Pe de alta parte, nu toate tabelele derivate sunt atât de problematice, astfel încât propagarea modificărilor dintr-o relație virtuală poate fi destul de simplă.

Câteva dintre SGBDR-urile actuale propun un alt mecanism oarecum apropiat de cel al tabelei virtuale, anume cel de clișeu sau imagine concretă. Această noțiune este fondată pe conținutul unei imagini calculate pe baza definiției sale și stocată în baza de date.

O „imagine concretă” reflectă starea bazei de date la un moment „t” când a fost „calculată”, clișeul fiind determinat periodic de către sistem. Actualizarea bazei de date va fi reflectată în clișeu, abia în momentul primului calcul de după acesta. Fireste, la un volum mare al bazei de date timpul de calcul poate fi destul de lung. De aceea se poate institui un mecanism de schimbare în clișeu numai a tuplurilor ce au suferit modificări după calculul precedent. Probleme mai delicate apar la ștergerea unor tupluri în tabelele de bază, deoarece un tuplu din clișeu poate proveni din mai multe relații, iar ștergerea unuia într-o astfel de relație nu trebuie să atragă neapărat ștergerea din clișeu.

O procedură stocată este o secvență de program care face parte integrantă din baza de date. Avantajul utilizării procedurilor stocate decurg din faptul că acestea sunt parte din structura (schema) bazei, fiind păstrate în dicționarul de date. Există mai multe tipuri de proceduri stocate: funcții-utilizator pentru validarea tabelelor, funcții pentru calculul unor valori implicite, proceduri/funcții de validare la nivel de linie sau tabelă, funcții/proceduri de calcul a unor expresii complexe.

Declanșatorul (trigger) este un tip special de procedură stocată care este executat automat când un eveniment predefinit ( inserare, actualizare sau ștergere) modifică o tabelă. Utilitatea declanșatoarelor este evidentă la formularea unor restricții mai complexe decât „suportă” comenzile CREATE/ALTER TABLE, actulizarea automată a unor atribute calculate, jurnalizarea modificărilor suferite de baza de date, păstrarea integrității referențiale.

Există diferențe sensibile între sistemele de gestiune a bazelor de date, în ceea ce privește sintaxa declanșatoarelor, deoarece acestea sunt redactate în extensiile procedurale ale SQL care prezintă diferențieri majore de la un producător la altul.

Astfel dacă în VFP există trei tipuri de declanșatoare, pentru adăugare, pentru modificare, pentru ștergere, în schimb, în Oracle, pentru fiecare din cele trei operațiuni există o primă separare între declanșatoare lansate înaintea operației (actualizării) și cele după operație. La această delimitare se mai adaugă și cea dintre triggere la nivel de linie, ce intră în acțiune la fiecare intrare, modificare, ștergere a unei linii, și cele la nivel de comandă care se execută o singură dată, indiferent de câte linii afectează comanda de actualizare respectivă.

2.2 Regulile modelului relațional

În anul 1985 , Codd a publicat în revista Computerworld un articol în care formulează câteva reguli de fundament care ar trebui respectate de un SGBD pentru a fi declarat relațional. Mai mult autorul s-a angajat cu înverșunare împotriva celor care au folosit abuziv sintagma relațional pentru produsele lor.

Discutabile, ca orice reguli, cele care vor fi menționate mai jos constituie un etalon plauzibil de a caracteriza funcționalitățile unui SGBD și al încadra pe scala relațională:

1. Regula de fundament.

Orice sistem declarat relațional trebuie să fie capabil să administreze întreaga bază de date exclusiv prin funcțiile relaționale.

2. Regula informației.

Toate informațiile sunt reprezentate explicit la nivel logic, într-un singur mod, ca valori în anumite tabele.

3. Regula accesului garantat.

Orice dată elementară (reprezentată printr-o valoare atomică) este accesibilă, fără ambiguitate prin cunoașterea numelui tabelei din care face parte, a denumirii atributului care o reprezintă și a valorii cheii primare a tuplului pe care se găsește.

4. Prelucrarea sistematică a valorilor nule.

Un SGBDR utilizează valorile nule ( diferite de valorile vide, spații sau zero) în vederea reprezentării informațiilor care lipsesc, necunoscute sau inaplicabile. Orice tip de atribut poate avea valoarea NULL .

5. Regula catalogului actualizabil în timp real.

Descrierea unei baze de date relațională este stocată, la nivel logic, într-un catalog (dicționar de date) alcătuit din tabele-sistem ce pot fi consultate de o manieră similară tabelelor de date obișnuite.

6. Regula sub-limbajului de date se referă la existența a cel puțin unui limbaj (ca SQL), de exemplu „dotat” cu o serie de comenzi cu sintaxă bine definită prin care să se realizeze:

definirea (descrierea) datelor;

definirea sub-schemelor („machete”sau tabele virtuale);

manipularea datelor (interactiv sau prin program);

definirea și implementarea restricțiilor de integritate;

autorizarea accesului la date;

gestiunea tranzacțiilor.

Limbajul trebuie să reprezinte o sintaxă liniară și să poată fi utilizat atât interactiv, cât și din cadrul aplicațiilor .

7. Regula actualizării tabelelor virtuale.

Orice tabelă derivată teoretic actualizabilă trebuie să aibă același regim în cadrul SGBD-ului .

8. Inserarea, modificarea și ștergerea pot fi efectuate prin intermediul unui limbaj de nivel înalt orientat pe lucrul simultan cu un ansamlu de linii.

Ca efect o tabelă de bază sau derivată poate fi operantă nu numai în interogări dar și în operațiuni de inserare modificare/ștergere.

9. Indepedența fizică a datelor.

Aplicațiile-program și activitățile de tip „consolă” (interogări directe) rămân neschimbate din punct de vedere logic, la modificarea în structurile de stocare și metodele de acces.

10. Independența logică a datelor.

Această regulă permite modificarea dinamică a modelului logic a bazei de date, cum ar fi ,spre exemplu, o descompunere sau joncționare a tabelei care nu atrage pierderi de informații.

11. Independența mecanismului de integritate al bazei .

Restricțiile de integritate sunt definite printr-un limbaj relațional și stocate în dicționarul de date și nu în aplicațiile ce exploatează baza de date. Dintre aceste restricții ar trebui să fie implementabile măcar două, cea a entității și cea referențială.

12. Regula independenței distribuirii datelor.

Limbajul relațional operează asupra datelor care sunt plasate atât pe calculatorul pe care se derulează activitățile, dar și pe alte calculatoare legate în rețea, de o manieră transparentă pentru utilizator.

13. Regula non-subversiunii.

Dacă un sistem relațional prezintă un limbaj de nivel scăzut (apropiat de ”mașină”), care permite prelucrarea, pe rând, a fiecărei înregistrări ( linii sau tuplu), acest limbaj nu poate fi utilizat pentru a-i încălca restricțiile declarate printr-un alt limbaj, de nivel înalt al SGBD.

Cum găsirea unor SGBD-uri care să îndeplinească toate condițiile de mai sus se dovedește a fi o muncă aproape zadarnică, s-a încercat formularea unor cerințe minimale pentru care un sistem de gestiune a bazelor de date să fie declarat „relațional”. Acestea ar fi:

a. Toate datele bazei sunt organizate în relații.

b. Între tabele nu există pointeri care să fie gestionați de utilizatori.

c. Sunt implementați operatori relaționali: selecție, proiecție și joncțiune.

Un sistem este complet relațional dacă, în plus:

d. Sunt implementați toți operatorii algebrici relaționali.

e. Sunt respectate restricțiile de unicitate a cheii și cea referențială.

Sistemele care îndeplinesc numai condițiile a și c sunt pseudorelaționale, iar dintre cele pseudorelaționale, cele care îndeplinesc condiția c în raport cu funcția de interogare sunt denumite SGBD-uri cu interfață relațională.

Modelul relațional este un model formal de organizare, conceptual al datelor, destinat reprezentării legăturilor dintre date și este bazat pe teoria matematică a relațiilor. Acest model este unul dintre cele mai accesibile pentru utilizatorul unei baze de date, deoarece are aceeași structură fizică cu datele care trebuie prelucrate. În general datele se reprezintă sub forma unor tabele (relații), în care liniile constituie entități, iar coloanele sunt atribute, ce caracterizează aceste entități.

Bazele de date relaționale oferă o flexibilitate redusă pentru structurile de date, în comparație cu bazele de date orientate pe obiecte care oferă o mare flexibilitate, comercianții de baze de date relaționale, modifică produsele lor pentru a le da o mai mare flexibilitate, în general încorporând majoritatea caracteristicilor sistemelor de gestiune a bazelor de date orientate pe obiecte. În ciuda tuturor modificărilor aferente bazelor de date relaționale tot mai există așa numita independence mismatch între programarea orientată pe obiecte și bazele de date relaționale modificate, fapt ce determină să existe în continuare interfețe care oferă o persistență adecvată. Se prevede ca următoarele modificări și update-uri ce se vor face asupra structurării datelor, reprezentării și stocării acestora, vor face ca bazele de date relaționale care acționează prin persistență să fie comparabile cu cele orientate pe obiecte.

Cu privire la partea practică a acestei teze, am ales să realizez construirea unei baze de date a unei biblioteci .

În ceea ce priveste motivația , ca posesor și utilizator al unui permis de intrare în biblioteca județeană “Gh. Asachi” Iași am avut ocazia de a observa interfața destul de veche și obositoare pusă la dispozitia studenților, elevilor, etc pentru accesul bazei de date.

Cu privire la constituția bazei de date aceasta a fost gândită astfel: pe baza cnp-ului se va întocmi un permis de intrare cu care vei avea acces în cadrul acestei biblioteci . Acest permis în afară de termenul de valabilitate va avea înscris pe el și nivelul accesului în cadrul bibliotecii respective și anume 0 va avea acces la sala de lectură , 1 va putea sa ducă cartea acasă iar 2 general, adică va putea să aibă acces peste tot, atât în sala de lectură cât și să poată să ia o carte acasă .

Această bibliotecă mai conține în afară de cărți următoarele: cd-uri, hărți, documente și ziare , toate putând fi disponibile utilizatorilor în funcție de tipul accesului lor la sala de lectură cât și/sau acasă.

Codul acestei baze de date se regăsește în cadrul Anexei numărul 1, cu mențiunea că acest cod a fost realizat în Oracle.

În continuare va urma o prezentare pe scurt a atributelor și a caracteristicilor acestora, atribute prezente în cadrul bazei de date .

Cnp –– cod numeric personal

Nume –– nume utilizator

Prenume –– prenume utilizator

DataNastere –– data naștere utilizator

Adresa –– adresa utiliator

Profesie –– profesie utilizator

NivelStudii –– nivelul de studii al utilizatorului

Locmunca –– locul de muncă al utilizatorului

TelFix –– telefonul fix al utilizatorului

TelMobil –– telefonul mobil al utilizatorului

Email –– emailul utilizatorului

NrPermisIntrare –– numărul permisului atribuit la intrare

TermenVal –– termenul de valabilitate al permisului de

intrare

NivelAcces –– nivelul de acces permis utilizatorului: sala de

lectura, împrumut acasa

DataInscriere –– data de înscriere a utilizatorului

DataImprumut –– data la care a împrumutat o carte sau un CD

DataReturnare –– data la care trebuie să returneze cartea

Penalizari –– penalizări în cazul în care nu returnează la timp (numărul de zile întârziate)

Observații –– observații referitoare la penalizările acordate (reducere de drepturi în urma întârzierii returnării cărții sau a deteriorării cărții)

NrCărțiImp –– numărul de cărți împrumutate de o persoană

CotaCarte –– cota cărtii

ISBN ––ISBN cărtii

DenCarte –– denumire carte

Autori –– autorii cartii

NrExemplare ––numărul de exemplare existente (sala de lectură, împrumut acasa)

CCCarte –– cuvinte cheie carte

Subiect –– subiectul tratat de carte

Accesibilitate –– împrumut, sala de lectură

NrPagini –– numărul de pagini al cărții

StareCarte –– dacă accesibilitatea este împrumut -situația cărții:împrumutata, neîmprumutată

AnScriere –– anul în care a fost scrisă de autor(i)

IdEditura –– cheie surog id editura

DenEditura –– denumirea editurii

AnFab –– an publicatie

TermenImprumut –– perioada de timp pentru imprumut

CotaCD –– cota CD

DenCD –– denumire CD

SubiectCD –– subiectul tratat în CD

TipContinutCD –– audio, video, date,

Capacitate –– capacitatea CD-ului

AutorCD –– autorul CD

AnFabCD –– anul de fabricație al CD-ului

CCCD –– cuvinte cheie CD

CotaHarta –– cota hărții

DenHarta –– denumirea hărții

AnFabHarta –– anul de fabricație al hărții

SubiectHarta –– subiectul tratat de hartă

AnHarta –– perioada la care face referință harta

DimHarta –– dimensiunea hărții

CCHarta –– cuvinte cheie hartă

CotaDoc –– cota documentului

DenDoc –– denumirea documentului

AnDoc –– anul în care a fost scris documentul

NrPagini –– numărul de pagini al documentului

SubiectDoc –– subiectul tratat de document

CCDoc –– cuvinte cheie document

CotaZiar –– cota ziarului

DenZiar –– denumirea ziarului

AnFab –– anul in care a fost editat ziarul

CategZiar –– tip de ziar: politic, economic, de informatică

În cadrul acestei baze de date putem remarca foarte ușor urmatoarele dependențe funcționale ale acesteia:

(Cnp) -> Nume

Prenume

DataNastere

Adresa

Profesie

NivelStudii

LocMunca

TelFix

TelMobil

Email

NrPermisIntrare

TermenValabilitate

NivelAcces

DataInscrierii

(CotaCarte) -> ISBN

DenCarte

NrExemplare

CCCarte

Subiect

Accesibilitate

NrPagini

Autori

StareCarte

IdEditura

DenEditura

AnFab

Cnp

TermenImprumut

AnScriere

(Cnp, CotaCarte, DataImprumut) -> DataReturnare

Penalizari

Observatii

(CotaCD) -> DenCd

TipContinutCD

Capacitate

AutorCD

AnFabCD

SubiectCD

CCCD

Cnp

(Cnp, DataImprumut) -> NrCartiImp

(CotaHarta) -> DenHarta

AnFabHarta

SubiectHarta

DimHarta

AnHarta

CCHarta

Cnp

(CotaZiar) -> DenZiar

CategZiar

AnFab

IdEditura

DenEditura

Cnp

(CotaDoc) -> DenDoc

AnDoc

NrPagini

SubiectDoc

CCDoc

Cnp

În continuare, o reprezentare grafică a bazei de date bibliotecă va fi realizată în graficul din figura 1.

Figura nr.2.1 Graful bazei de date bibliotecă

2.3 Restricții

Există diverse moduri de abordare și clasificare a restricțiilor ce pot fi instituite într-o bază de date după cum urmează:

2.3.1 Restricția de domeniu

După cum știm un atribut este definit de nume și domeniu. Orice valoare pe care poate să o ia atributul, trebuie să se încadreze în domeniul respectiv. Există mai multe moduri de percepție a acestei restricții.

Mulți dintre informaticieni substituie domeniul tipului de atribut: numeric, șir de caractere, dată calendaristică, logic (boolean) și eventual lungimii (numărul maxim de poziții/caractere pe care se poate întinde un atribut). După cum se observă este luat în calcul numai aspectul sintactic al domeniului. De exemplu faptul că indicativul unui județ poate fi una din valorile: B, IS, TM, reprezintă o restricție de comportament sau mai simplu o restricție definită de utilizator .

Cea de-a doua categorie privește domeniul deopotrivă sintactic și semantic. De exemplu domeniul sintactic al atributului JUD (indicativul județului) este un șir de două caractere, obligatoriu litere (sau o literă și un spațiu pentru Bucuresti) și chiar mai restrictiv literele sunt obligatoriu majuscule. Din punct de vedere semantic indicativul poate lua una din valorile : IS, TM , B …

Majoritatea sistemelor de gestiune a bazelor de date permit definirea tuturor elementelor ce caracterizează domeniul atât semantic cât și sintactic, atributului JUD prin declararea tipului și lungimii atributului și prin așa numitele reguli de validare de la nivelul câmpului (fild validation rule) .

2.3.2 Atomicitatea

Conform teoriei bazelor de date relaționale orice atribut al unei tabele oarecare trebuie să fie atomic în sensul imposibilității descompunerii sale în alte atribute. Implicit, toate domeniile unei baze de date sunt atomice (elementare). În aceste condiții se poate afirma faptul că bază de date se află în prima formă normalizată (1FN ) .

Mulți critică aceste tipuri de baze de date relaționale, datorită atomicității atributelor, datorită imposibilității înglobării unor structuri de date mai complexe, specifice unor domenii ca: proiectarea asistată de calculator, baze de date multimedia. Mulți autori dintre care amintesc pe Chirs J. Date și Hugh Darwen se opun ideii de atomicitate formulată de Codd .

Atributele compuse sunt primele vizate de stigmatul neatomicității. În continuare vom prezenta un exemplu în acest sens: Adresa este un atribut compus, fiind alcătuit din Stradă, Număr, Bloc, Scară, Etaj, Apartament, discuția despre atomicitatea adresei pare de prisos iar descompunerea sa imperativă. Trebuie să ne raportăm la obiectivele bazei de date. Fără îndoială că pentru o bază de date mare cum ar fi cea a poliției preluarea separată a fiecarui element constituent al adresei este foarte importantă. Pentru un importator al unui mare en-gros lucrurile stau cu totul diferit. Partenerii de afacere al acestuia sunt persoane juridice, iar adresa interesează numai la nivel general, caz în care atributul Adresa nu mai este considerat a fi non-atomic.

2.3.3 Restricția de unicitate

În ceea ce priveste o relație nu pot să existe două linii identice (două linii ce prezintă aceleași valori pentru toate atributele). Mai mult majoritatea relațiilor reprezintă un atribut, sau o colecție de atribute care diferențiază cu siguranță un tuplu de toate celelalte tupluri ale relației.

Cheia primară a unei relații este un atribut sau grup de atribute care identifică fără ambiguitate fiecare tuplu (linie) a relației (tabelei) .

După cum știm orice cheie primară trebuie să respecte următoarele restricții :

Unicitatea : o cheie identificată de un singur tuplu al relației .

Compoziție minimală : În cazul în care cheia primară este compusă, nici un atribut din cheie nu poate fi eliminat, fără a distruge unicitatea tuplului în cadrul relației. În cazuri limită cheia poate fi alcătuită din toate atributele relației.

Valori non-nule valorile atributului sau ale ansamblului de atribute trebuie întotdeauna să fie specificate, deci nenule. Nici un atribut din cadrul cheiei primare nu poate avea valori nule.

Pot exista și se numesc chei candidate dacă într-o relație există o combinație de mai multe atribute ce conferă unicitate tuplului.

O cheie candidată care nu este identificator primar, este cunoscută sub denumirea de cheie alternativă.

Problema unicității este o problemă discutabilă. Clasicii modelului relațional, Codd și Date, s-au pronunțat împotriva repetării tuplurilor în cadrul unei relații, cerință pe care standardele SQL nu au luat-o în considerare. Există și situații reale în care repetarea liniilor este inevitabilă. David Beech a prezentat într-o lucrare înaintată Consiliului de standardizare a bazelor de date ANSI X3H2, și mai apoi în revista Datamotion ,faptul că la nivel conceptual la care se înregistrează informațiile, nu există nici o valoare prin care rândurile să fie diferențiate. Astfel încât pentru a respecta modelul relațional este necesară introducerea unei coloane suplimentare fără prea mare relevanță, dar care să asigure unicitatea fiecerui tuplu.

Este adevărat că E.F.Codd a propus ulterior consiliului ANSI X3H2 o funcție specială care să măsoare gradul de repetabilitate a valorii unuia sau mai multor atribute, funcție care ar semăna cu funcția COUNT ( ) din SQL folosită împreună cu GROUP BY .

2.3.4 Restricția referențială

O bază de date relațională este alcătuită din relații (tabele) aflate în legătură. Stabilirea legăturii se bazează pe mecanismul cheii străine, și implicit a restricției referențiale. O restricție de integritate referențială apare atunci când o relație face referință la o altă relație. C. J. Date definește restricția de integritate referențială astfel:

Fie D un domeniu primar și R1 o relație ce prezintă un atribut A definit pe D – se poate scrie R1(…..,A:D,….) . În orice moment orice valoare a lui A în R1 trebuie să fie :

ori nulă ,

ori egală cu o valoare a lui V, unde V este cheie primară sau candidată într-un tuplu al unei relații oarecare R2(R1 și R2 nu trebuie să fie distincte ) , cheie primară definită pe același domeniu primar D-R2(V:D, ..) .

2.3.5 Restricții utilizator

Restricțiile utilizator mai sunt denumite și restricții de comportament sau restricții ale organizației. De obicei aceste restricții iau forma unor reguli de validare de atribut la nivel de linie/tabelă sau a unor reguli implementate prin declanșatoare, prin triggere. Spre exemplu se poate institui o regulă care poate interzice emiterea unei noi facturi (o nouă vănzare ) dacă datoriile firmei client sunt mai mari de 3000 lei, iar directorul acesteia nu este membru în partidul de guvernământ sau coaliția de guvernare .

2.3.6 Restricții de integritate

Restricțiile de integritate mai sunt denumite și reguli de integritate ce definesc cerințele care trebuiesc să le satisfacă datele din cadrul unei baze de date pentru a putea fi considerate corecte, coerente în raport cu lumea reală pe care o reflectă.

Se afirmă adesea că modelul relațional este prea simplu pentru a putea exprima semantica datelor. Relațiile bazei de date sunt toate la același nivel iar setul de operatori este relativ sărac, neputând exprima semantica operațională a obiectelor complexe, aspect ce rămâne exclusiv în sarcina programelor de aplicație. Cu toate acestea sistemele relaționale dețin o serie de mecanisme pentru tratatarea aspectelor de ordin semantic.

Restricțiile de integritate reprezintă principalul mod de integrare a semanticii datelor în cadrul modelului relațional al datelor, mecanismele de definire și verificare a acestor restricții reprezentând principalele instrumente pentru controlul semantic al datelor. Avantajele încorporării semanticii datelor în cadrul bazelor de date constau în posibilitatea întreținerii și mai ușoare a aplicațiilor și posibilitatea implementării unor mecanisme fizice mai eficiente.

În teoria sistemelor relaționale, restricțiile de integritate sunt studiate în principal sub aspectul puterii lor de modelare și al posibilităților de verificare eficace a respectărilor lor. Un exemplu semnificativ îl reprezintă dependențele între date și în primul rând dependențele funcționale. Dependențele de date, ca restricții de integritate constituie un raport teoretic solid pentru problema de modelare informatică. În acest sens, dependențele funcționale au permis definirea conceptului de structură relațională optimă stând la baza teroriei optimizării structurii relațioanle a datelor respective, teoria normalizării relațiilor.

2.4 Interogări

Pentru utilizatori, o interogare este o metodă de a regăsi anumite informații dintr-o bază de date, prin intermediul unei aplicații de baze de date. Din punctul de vedere al programatorului aplicației de baze de date, interogarea se exprimă printr-o comandă SQL echivalentă expresiei de algebră relațională corespunzătoare interogării, comanda care se transmite sistemului de gestiune al bazelor de date.

Din punctul de vedere al sistemului de gestiune, o interogare este un program

(în limbaj SQL) pe care îl compilează și apoi îl execută. Ca orice program, o interogare este prelucrată de către sistemul de gestiune al bazei de date în mai multe faze: analiza lexicală, analiza sintactică și analiza semantică pentru validarea interogării urmată de generarea codului. De asemenea, dacă există mai multe soluții pentru aceeași interogare, sistemul de gestiune selectează soluția optimă. Conceptual, subsistemul SGBD de prelucrare a interogărilor este alcătuit din următoarele componente:

compilatorul de interogări, care efectuează analiza lexicală și sintactică a interogărilor; acestea validează din punct de vedere sintactic interogarea, adică verifică existența relațiilor, a indexurilor și a atributelor implicate în interogarea și utilizarea corectă a acestora.

optimizatorul de interogări care efectuează analiza semantică a interogării și selectează alternativa optimă, între mai multe soluții posibile de execuție a interogării.

generatorul de cod care generează programul de execuție al interogărilor conform optimizării efectuate.

componenta de execuție, care execută programul interogării .

Compilarea interogării se realizează la fel ca orice compilare a programelor fără aspecte specifice sistemelor de baze de date. În schimb optimizarea interogărilor , este o operație specifică sistemelor de gestiune și utilizează proprietățile operațiilor relaționale pentru a obține performanțe de execuție a interogărilor cât mai bune.

Optimizarea interogărilor se obține prin modificarea expresiilor care le prezintă, astfel încât expresia echivalentă obținută să aibă un timp de execuție cât mai redus. Timpul de execuție a unei expresii optimizate față de una neoptimizată poate să fie cu câteva ordine de mărime mai mic, astfel încât, optimizarea interogărilor are o mare importanță în exploatarea eficientă a bazelor de date.

Optimizarea interogărilor formulate ca expresie a algebrei relaționale se efectuează pe baza proprietăților operațiilor algebrei relaționale cum ar fi: (comutativitate, asociativitate, proprietatea de divizare a restricțiilor). În plus se mai pot folosi și proprietăți de comutativitate între diferite tipuri de operații.

Comanda fundamentală a standardului SQL care permite interogarea unei baze de date este SELECT. Sintaxa generală a unei comenzi SELECT (ALL/DISTINCT/UNIQUE) lista de selecție:

FROM lista de tabele

WHERE condiție de căutare asupra liniilor

GROUP BY lista de atribute care permit partiționarea

HAVING condiție asupra partițiilor

ORDER BY lista de atribute

Clauzele SELECT și FROM sunt obligatorii și specifică datele care se selectează și relațiile din care se selectează. Restul clauzelor sunt opționale și permit rafinarea selecției.

Strategia pentru scrierea comenzii SELECT este dată de următorul algoritm:

1. Se determină tabelele implicate și se includ în clauza FROM

2. Se determină atributele ce vor fi vizualizate și se includ în clauza SELECT

3. Dacă clauza SELECT include „funcții pe grupuri”, atunci se introduce clauza GROUP BY și se reiau toate atributele citate în clauza SELECT (fără funcții)

4. Se determină condițiile care limitează cercetarea. Condițiile care se referă la grup apar în clauza HAVING, iar cele care se referă la valori individuale apar în clauza WHERE.

5. Dacă este necesară valoarea unui atribut din alte table sau este necesară o funcție pe grupuri în clauza WHERE, atunci se utilizeaza o cerere imbricată.

6. Dacă este necesară fuzionarea rezultatelor din două clause SELECT, se utilizează clauza UNION

7. Cu ajutorul ORDER BY se precizează ordinea în care apar tuplurile rezultatului.

CAPITOLUL III MODELUL OBIECTUAL

Acest capitol va scoate în evidență conceptele generale ale acestui model precum și prezentarea pe scurt a câtotva dintre ele cât și o scurtă comparație cu alt tip de baze de date.

3.1 Orientarea pe obiecte concepte generale

Un sistem de gestiune al bazelor de date orientate pe obiecte poate fi văzut ca un SGBD orientat pe obiecte și pe concepte ca model de date. În cadrul acestei abordări o bază de date este considerată a fi o colecție de obiecte a căror comportament stare și relații sunt stocate ca o entitate fizică. În contrast modelele clasice de baze de date (relaționale, rețea sau ierarhice ), văd datele ca o colecție de înregistrări sau relații, fiecare având o colecție de înregistări sau tupluri stocate într-un fișier. Unul din scopurile modelării orientate pe obiecte este acela de a menține corespondențele între lumea reală și obiectele din cadrul unei baze de date care nu își pierd integritatea sau identitatea și care pot fi usor de identificat și utilizat. Conceptele orientării pe obiecte formează o bază bună pentru model de date necesar aplicațiilor bazelor de date de ultimă generație cum ar fi: CAD/CAE/CASE/CAM, sistemele informatice multimedia.

În prezent sunt multe sisteme de baze de date orientate pe obiecte ce sunt dezvoltate de către: vânzătorii comerciali, laboratoarele de cercetare industrială și universități din toata lumea .

Putem afirma că nu există un singur standard pentru conceptele orientării pe obiecte astfel încât abordarea orientată-obiect este încă în discuție. Din lipsa acestui standard formal există un anumit tip de scepticism în ceea ce privește fezabilitatea și construirea sistemelor de baze de date orientate pe obiecte.

Mulți cred că o cercetare amănunțită și o dezvoltare pe măsură, un standard a modelului de date orientate pe obiecte, va ieși la suprafață iar limbajul bazelor de date orientate pe obiecte va fi dezvoltat și se va construi un limbaj suport pentru dezvoltarea sistemelor de baze de date orientate pe obiect.

Orice model de date orientat pe obiecte are la bază noțiunea de entitate conceptuală care definește un obiect, ce reprezintă o colecție de proprietăți care descriu o anumită entitate.

Putem afirma că nu există un „model orientat pe obiecte” propriu-zis, care să descrie într-un mod coerent atât funcționalitatea cât și structura unei baze de date orientate pe obiecte. Lipsa acestuia s-ar putea datora mai multor motive printre care putem enumera imaturitatea tehnologiei cât si naturalețea dezarmantă a tehnologiei orientată pe obiect.

Oricât de folosit este modelul de date relațional, există unele domenii în care s-a dovedit a fi insuficient de expresiv și cu perfomanțe de execuție reduse cum ar fi: proiectarea asistată de calculator, sisteme de informații geografice, medicina, necesitând găsirea unor modele mai performante cum ar fi modelul orientat -obiect.

În concepția autorilor Bertino si Guerrini originile bazelor de date orientate pe obiecte pot fi găsite în diferite domenii dar și în limbaje de programare persistente, creșterea și popularitatea programului C++ și smalltalk la sfârșitul anilor ‘90. În timpul primelor zile creșterea și dezvoltarea bazelor de date orientate obiect vor fi intreținute de rețelele de comunicații, iar această tehnologie va fi repede găsită în multe aplicații inginerești. Atunci când tehnologia s-a maturizat și a devenit un risc minim pentru alegerea userilor, a devenit mai populară folosirea bazelor de date orientate obiect pe diferite piețe incluzând afacerile financiare si managementul rețelelor de telecomunicații .

Totuși câteva trenduri descendente au împiedicat ca bazele de date orientate obiecte să se extindă și mai tare. Multe organizații deja aveau făcute investiții în baze de date relaționale și nu le era ușor să își schimbe bazele de date. Rata schimbării tehnologiilor se accelerase și Java a devenit și mai tare în câțiva ani. În ciuda stagnării mulți vânzători de baze de date orientate obiect, datorită dimensiunii mici pe care o ocupă pe piață, au răspuns rapid și în forță. De exemplu unul dintre cei mai mari vânzători de baze de date, și-a schimbat poziția și acum a devenit un vânzător de servere de aplicații.

Am putea spune, fără să greșim, că programarea orientată pe obiecte față de programarea structurată, formalizează în special latura descriptivă (statică) asigurând astfel o coerență sporită laturii procedurale (dinamice).

În continuare, în prima fază, ne vom ocupa de rezultatul direct al abstractizării care se remarcă prin definiția structurilor statice. Acestea sunt implementate destul de eterogen în limbajele declarate orientate obiect, unele dintre ele mixând în fapt modul de lucru tradițional cu structurile bazate pe obiecte, în timp ce altele optează ferm împotriva unui astfel de mod de abordare, considerându-se mai „pure” din perspectiva principiilor orientării obiectuale. Formalismul reprezentat în continuare, pentru exemplificare, se sprijină în special pe constructorii limbajului Java.

Limbajul Java este un limbaj orientat-obiect construit în primul rând să producă programe sigure, adică să investigheze cât mai mult căile de propagare a unor erori (exclusiv de proiectare) din faza de programare ( elaborare a codului sursă) în faza de execuție. Compilatorul Java constituie în această privință elementul esențial, bazându-se pe abordare puternic tipizată.

În programarea orientată-obiect datele (atributele sau variabilele) și metodele (comportamentul) sunt integrate în obiecte; astfel datele și metodele sunt legate intim împreună. Obiectele au proprietatea de a ascunde informația (information hiding) adică deși obiectele știu să comunice între ele prin intermediul inferențelor, în mod normal acestea nu cunosc modul de implementare al serviciilor oferite de alte obiecte, detaliile de implementare fiind ascunse.

Modelul obiect este un concept unificator în știința calculatoarelor fiind aplicabil în programare, în proiectarea hardware-lui, a interfețelor, a bazelor de date. Sistemele de baze de date orientate-obiect se bazează pe limbajul de programare orientate-obiect cu capacitate de persistență, în care datele sunt independente de timpul de viață al programelor care le creează sau accesează, prin memorare pe suport magnetic (disc) .

Printre conceptele de bază care stau la fundația unui model orientat pe obiecte putem enumera: obiectul, clasa, tipul, moștenirea, persistența, incapsularea, polimorfismul, identitatea, domeniul.

3.1.1 Obiectul

Din punct de vedere conceptual un obiect reprezintă o unitate identificabilă și cu conținut propriu care se deosebește de ceea ce o înconjoară. Obiectele sunt abstractizări ale unor entități ce aparțin lumii reale și sunt caracterizate prin stare și comportament. În ceea ce privește starea unui obiect, aceasta este exprimată prin valorile atributelor sale, iar colecția de atribute ce desemnează un obiect trebuie să fie suficientă pentru a descrie entitatea adică trebuie să includă acele atribute cunoscute de către utilizatori.

Putem afirma despre comportamentul unui obiect că reprezintă un set de modele sau operații care acționează asupra atributelor sale, urmând să i se asocieze fiecărui obiect un nume care să coincidă, de obicei , cu numele entității reprezentate.

Spre exemplu să considerăm obiectul avion. Atributele unui avion pot fi direcția, altitudinea, viteza de la sol(daca este în mișcare), greutatea și culoarea. Operațiile unui avion pot fi : abilitatea de mișcare, viteza modificabilă și riposte la stimuli, cum ar fi vântul sau temperatura exterioară. Obiectul AVION poate avea atribute pentru AVION-ALTITUDINE, AVION-DIRECȚIE, AVION-VITEZĂ, AVION-POZIȚIE, și AVION-CONSUM DE COMBUSTIBIL. Avionul poate avea deasemenea definite proceduri care să ilustreze operațiile sale: STARE-ALTITUDINE, PREZENTARE-DIRECȚIE, CALCUL-VITEZĂ, PREZENTARE-VITEZĂ, CALCUL-CONSUM DE COMBUSTIBIL etc.

3.1.2 Metode

O metodă reprezintă un program ce manipulează obiectul sau indică starea acestuia la un moment dat , urmând să fie asociată întotdeauna unei clase.

Persistența reprezintă o proprietate a datelor sau obiectelor care implică existența mai îndelungată a acestora față de procesul care le-a creat. Este proprietatea prin care starea bazei de date, asigură execuția unui proces pentru a fi folosit ulterior în alt proces. Referitor la codul aferent metodelor ce face parte integrantă din obiect, acesta este stocat, ca și starea obiectului în cadrul bazei de date, ceea ce semnifică faptul că, odată ce a fost descrisă o metodă devine permanentă, fapt care face ca aplicația să devină mai rapidă, asigurându-i independența față de date. O modificare adusă unei metode devine imediat operantă și persistentă până la o nouă modificare a acestuia.

3.1.3 Persistența

Din perspectiva realizării bazelor de date, o altă apropiere a modelului obiect, persistența este cea care asigură memorarea transparentă pe suport magnetic a obiectelor care alcătuiesc o bază de date orientată pe obiect.

Un utilizator poate salva datele într-un loc existent de pe stația de lucru și să-l reacceseze mai târziu, acest lucru nu este adecvat, pentru lucrul efectiv cu baze de date. Nu există un mod eficace în care un user poate să exploateze modularitatea și să salveze o parte a informației pe locul care lucrează. De exemplu mai degrabă baza de date însăși trebuie să fie persistentă și acele programe experimentale trebuie să fie separate, la dispoziția utilizatorului, un spațiu de lucru diferit. Mult mai important atunci când sherăm baza de date este necesar să nu se realizeze mai multe checkpoint-uri.

3.1.4 Moștenirea

În cadrul unei baze de date orientate pe obiecte, clasele sunt aranjate într-o ierarhie, în cadrul căreia fiecare clasă moștenește toate atributele cât și metodele unei superclase din care face parte clasa respectivă. În ceea ce privește moștenirea, aceasta este un concept puternic, care duce la posibilitatea de reutilizare a codului și deci la creșterea semnificativă a productivității în proiectare. Aplicațiile complexe care se folosesc de obiecte, cum ar fi sistemele de design asistat de calculator, solicită deseori definirea a numeroase și diferite clase. Dacă unele obiecte pot fi tipuri specifice, particulare, a altor obiecte , ar fi normal să folosim aceste avantaje vizibile la relațiile dintre ele și în cadrul definirii claselor.

Mecanismul prin care se realizează definirea unei clase în care derivă variabile de instanță și metode din altă definire de clasă se numește moștenire. Când o clasă moștenește variabilele de instanță și metode din altă clasă, este considerată a fi o subclasă. Pe baza moștenirii, pot fi create ierarhii de clase care reflectă relațiile naturale regăsite în cadrul domeniilor lumii reale.

Prin moștenirea variabilelor de instanță și a metodelor, se pot crea ierarhii în cadrul căreia cantitatea de cod necesară implementării unei aplicații este semnificativ redusă din acest motiv programele orientate pe obiect sunt cunoscute că promovează cod reutilizabil.

Moștenirea permite unei subclase să fie definită pornind de la definiția unei alte clase numită super clasă. Atunci subclasa moștenește atribute și operații de la superclasă și în plus o subclasă poate să aibă câteva specificații proprii , caracteristici nemoștenite. Moștenirea este un puternic mecanism refolosit intens. Folosind acest tip de mecanism când definim două clase, proprietățile lui comune, dacă există, pot fi identificate și clasificate într-o super clasă comună. Definiția acelor clase, prin contrast va specifica doar atributele distincte a acestor clase.

Toate bazele de date avansate cât și limbajele de programare existente exprimă o formă a moștenirii în interiorul tipului respectiv de sistem. Fiecare limbaj prezintă o abordare diferită în exprimarea constraint-urilor pe tipuri specializate de date. Interacțiunile între procedurile care operează cu tipurile de ierarhii trebuie luate în considerare în cadrul acestor tipuri de sisteme.

3.1.5 Polimorfismul

Polimorfismul se referă la faptul că la primirea unui mesaj, stabilirea metodei care se aplică se face în mod dinamic, în funcție de clasa obiectului în cauză, astfel instanțele unor clase diferite pot fi adresate uniform ( primesc aceleași mesaje ), dar manifestă comportamente diferite, fapt ce asigură manipularea simplă și coerența seturilor eterogene de obiecte.

În ceea ce privește polimorfismul parametrizat acesta este un instrument destul de puternic folosit pentru construirea a noi tipuri de date. Există un număr de sarcini relevante pentru programare, care întrece limbajul polimorfic.

Una din discuțiile noi apărute este aceea a construirii unui tip generic de index pentru care fiecare are nevoie de o funcție specială sau o funcție de comparație. În timp ce întotdeauna este posibil să construiești asemenea funcții, de obicei construcția depinde de o informație a dependenței de sistem, despre o structură oarecare avută în vedere. Un astfel de index generic dă un statut anume unui astfel de limbaj ce trebuie să fie predefinit. Există un număr de însărcinări de programare care au nevoie de același form de autoreferință în cadrul acestor limbaje. Am remarcat faptul că nu este posibil a scrie o funcție care memorează o altă funcție în limbaje cum ar fi ML, deși acest lucru este posibil într-un astfel de limbaj cum ar fi LIPS. O problemă similară este aceea că într-un mediu de programare incrementat ar trebui să ne bazăm atât pe funcții cât și pe compilator.

În final vom sublinia necesitatea strictei verificări care este o stare dezirabilă pentru programarea bazei de date .

3.1.6 Identitatea

Identitatea o putem privi ca un mijloc de a distinge un obiect de altul, realizând și asigurarea persistenței datelor totodată.

Oricare din obiectele unei baze de date orientate pe obiecte, au identitate care este independentă de valorile atributelor sale, spre deosebire de modelul relațional, care utilizează unicitatea cheii primare pentru a identifica „obiectul”, tehnologia orientată pe obiecte permițând modificarea valorilor oricărui atribut fără a-i afecta identitatea.

3.2 Analiză și proiectare orientate pe obiecte

Cu privire la acest subcapitol partea principală discutată este alcătuita din câteva generalități în ceea ce privește partea de programare orientată obiect iar partea cheie o constituie maparea modelului relațional pe cel obiectual.

3.2.1 Generalități

Modelarea pe calea bazei orientate obiect, se intemeiază pe posibilitatea definirii tipurilor abstracte de date. Stilul de programare care folosește abstractizarea datelor reprezintă o abordare metodologică care impune ca informația să fie „ascunsă” conștiincios într-un fragment de program. Mai exact programatorul dezvoltă o serie de tipuri abstracte de date, fiecare putând fi privit din două perspective. Din exterior, un client, al unui tip abstract de date poate „vedea” numai o colecție de operații care definesc comportamentul obiectului abstractizat. De cealaltă parte a interfeței, programatorul care a definit respectiva abstracțiune, are în vedere variabilele uitilizate pentru a menține starea internă a obiectului.

În concluzie, prin intermediul unui tip abstract de date este definită o abstracțiune ale cărui detalii interne sunt încapsulate, cunoscute fiind doar programatorului care a definit respectiva abstracțiune. Se mai spune că tipul folosit de către utilizator își găsește implementarea într-o clasă definită intern de către programator.

Pentru a desemna reprezentantul (sau un anumit exemplar) dintr-o clasă se folosește de obicei termenul de instanță sau obiect concret. Obiectul este manipulat de obicei prin intermediul unei variabile de instanță ( instance variable) declarate ca fiind de tipul corespunzător clasei obiectului. De fapt, aceste variabile găzduiesc referințe către obiectele instanțiate din clase.

Fiecare obiect are propriul set de variabile de instanță ale căror valori îi reflectă starea sa internă. Acestea mai apar și sub numele de câmpuri (legate mai mult de activitate de modelare) sau membrii-date (data fields/data members), în opoziție cu membrii-metode care reprezintă operațiile.

O viziune simplă dar completă a unui obiect presupune o combinație de stare și comportament. Starea este descrisă prin intermediul câmpurilor sau a variabilelor de instanță, în timp ce comportamentul este caracterizat prin metode. Deși în programarea orientată -obiect sunt în fapt create noi tipuri de date abstracte, în majoritatea limbajelor de programare este folosit termenul clasă pentru definirea acestora și termenul tip în declararea variabilelor, prin care vor fi manipulate instanțele claselor. Pe lângă membrii-variabile, în definiția claselor apar definite și metodele. În cazul acestora tipul desemnează de fapt tipul (obiectului) returnat iar dacă metodele au ca scop returnarea unei valori ( sau instanțe) de un anumit tip, atunci tipul returnat este înlocuit prin cuvântul cheie void. Blocul de instrucțiuni care formează corpul metodelor este încadrat tot prin marcatori „{ }” și presupune redactarea unei secvențe de instrucțiunui inclusiv structuri de control și declarații de variabile locale, variabile care nu sunt însă membrii ai clasei, și sunt vizibile numai în spațiu de nume local al metodei respective.

Bazele de date obiectuale permit unui număr de posibile alternative de manageriere a obiectelor persistente. În ultimii ani a avut loc o creștere stabilă în dezvoltarea și folosirea bazelor de date relaționale – obiectuale.

Aceste produse tind să câștige putere luată din cadrul tehnologiei prorelaționale, în timp ce oferă un suport mai bun pentru mai multe tipuri de date.

Creând scheme ale bazelor de date, este încă o arie care nu este bine înțeleasă cu bazele de date relaționale, tehnicile comune de normalizare și modelării entităților-relații sunt bine cunoscute. Expansiunea produselor relaționale cu caracteristicile orientării-obiect este un lucru bun și prost în același timp, deoarece aduce atât flexibilitate cât și complicații. Alegerile în ceea ce priveste designul vor fi mai mari fapt ce determină folosirea celui mai bun design, dar pentru o problemă în particular acest lucru poate fi dificil. O parte a acestei probleme este aceea de a mapa un limbaj de modelare particular unei baze de date.

Urgența recentă a instrumentelor designului orientat-obiect și orientat-relațional este că acest tip de tehnologie a bazelor de date comercializate pe piață, a cauzat noi provocări pentru implementarea designului conceptual al bazelor de date. Procesul de design al bazelor de date de obicei implică realizarea unei scheme conceptuale, care utilizează un nivel înalt al limbajului de modelare conceptuală cum ar fi modelul EE ( Extended Entity-Relationship). Designul conceptual este după aceea mapat pe modelul bazei de date respective și este folosit pentru implementarea aplicației. Buna definire a procedurilor de mapare există atât în maparea schemei EER pe designul bazei de date relaționale, puțin lucru a fost făcut pentru a defini schemele orientate-obiect cum ar fi diagrama de clase în UML .

UML-ul (UNIFIED MODELING LANGUAGE ) este un limbaj standard de modelare, care ne prezintă un model grafic de reprezentare al designului software-ului orientat-obiect. UML este integrarea analizelor și metodelor orientate-obiect, în care s-au făcut cercetări în această zonă, încă de la sfârșitul anilor 1980. Tehnologia obiect–relațional, pe de altă parte, extinde noțiunea tradițională a tabelelor relaționale cu noțiunea de tabele obiect, unde tuplurile și tabelele obiect generează identificatoare obiect ca și în cazul instanțelor de clase în sistemele de baze de date orientate-obiect. Relațiile dintre tabele sunt stabilite prin intermediul referințelor obiectului, mai mult modelul obiect-relațional încorporează noțiunea de tipuri definite de useri sau tipuri de date abstracte și mai suportă obiecte largi și tipuri de agregate cum ar fi: seturi array-uri și „nested tables”. Ca rezultat atributele din interiorul unei tabele obiect sau unei tabele relaționale nu mai sunt limitate de valorile atomice. Prezența acestor caracteristici, prezentate mai sus, necesită o nouă privire asupra modului în care sunt folosite conceptele efective de obiect-relațional în implementarea designului conceptual orientat-obiect.

UML-ul a devenit un standard pentru exprimarea designului orientat-obiect. Modelarea software-ului orientat-obiect este complex și UML are capacitatea să exprime diferite relații într-un sistem de software orientat-obiect. Diagramele claselor conceptuale (numite și static view diagrams) a UML-ului descrie tipul obiectului și a relațiiilor dintre obiecte. Deși metodologia UML a fost dezvoltată pentru design software, diagramele claselor conceptuale UML sunt similare cu cele ale diagramelor EER, care sunt folosite pentru designul conceptual al bazei de date. O diagrama UML spre deosebire de o diagramă EER include și conceptul navigabilității. Navigabilitatea este denotată de o linie directă care indică o asociație unidirecțională, navigabilitatea fiind o referință între două clase, care este realizată într-o singură direcție. Majoritatea bazelor de date obiect-relațional „vorbesc” limbajul SQL, care este diferit de JAVA , nu doar în sintaxa dar și în paradigma programelor și tipul de date suportate. O arie de „impedance mismatch” în SQL este orientat-set, de exemplu rezultatele unei interogări este returnată ca un șir de rânduri. În contrast limbajul procedural de mapare cum ar fi JAVA sunt secvențiale în natura lor cu o construcție interactivă ca pentru „for și while” să facă salt peste câteva seturi de date. Această diferență se manifestă de la sine în procesarea în SQL a rezultatelor din QUERY.

Cu toate că paradigma orientării pe obiecte pare extrem de naturală iar tehnicile specifice sunt simple, pentru proiectantul obișnuit cu metodele tradiționale de modelare, trecerea la noua metodologie este destul de dificilă. Aceasta se datorează faptului că proiectarea orientată pe obiecte este o metodologie cu totul nouă, care contrazice în multe privințe deprinderile proiectantului.

Modul clasic de proiectare se bazează pe tehnica top-down, unde se identifică toate componentele majore, se stabilesc corelațiile dintre ele, iar apoi se trece la rafinări succesive, „în cascadă”, a componentelor.

Proiectarea orientată pe obiecte se bazează mai mult pe tehnica bottom-up, unde se identifică mai întâi componentele funcționale pe baza căreia se va construi apoi întregul sistem. Se identifică în colecțiile existente acele obiecte care pot fi reutilizate pentru noul sistem și care la rândul lor vor fi preluate ca atare sau, dacă este cazul, vor fi ajustate. În cadrul acestei tehnici colecțiile care nu există vor fi create pornind de la zero, iar de cele mai multe ori ca subclase ale unor clase deja existente. Odată ce a fost creată ierarhia de clasă potrivită se vor testa componentele specifice și se va întocmi documentația necesară pentru a se putea începe acțiunea de implementare sau comercializare.

Această metodologie modifică în mod substanțial planificarea lucrărilor și etapelor, unde partea cea mai minuțioasă a proiectării se manifestă la începutul proiectului. Dacă există deja biblioteci de obiecte utilizate în alte aplicații, realizarea unui prototip va putea avea loc în câteva zile. Pe baza acestuia se vor stabili aspectele funcționale și de interfață ale aplicației după care se va trece la etapa de identificare a obiectelor, a claselor, a ierarhiei și a modului de comunicare dintre obiecte. Etapa finală a proiectului constă în asamblarea tuturor elementelor menționate anterior.

În ceea ce privește refacerea unor aplicații „clasice” noua tehnologie implică de cele mai multe ori refacerea aproape integrală a aplicațiilor.

Pe de altă parte metodologia orientată pe obiecte poate fi aplicată cu succes în proiectare, chiar dacă nu se urmărește utilizarea unor tehnici de realizare orientate pe obiecte. Avantajul principal constă în faptul că aceasta obligă la o analiză mai atentă a arhitecturii sistemului și, mai departe la un design modular, exprimat prin componentele aflate în interacțiune. Adăugarea sau înlocuirea ulterioară a unor astfel de componente va fi cu siguranță mult mai ușoară.

Rolul sistemelor informaționale

În timp s-au conturat câteva roluri majore ale sistemelor informaționale la nivelul firmelor și anume operațional , de sprijinire a procesului decizional, strategic. Primele două au fost identificate la începutul apariției sistemelor informaționale, de fapt din momentul în care managerii firmelor au conștientizat faptul că informația constituie unul din factorii de bază pentru procesul afacerilor lor. Rolul starategic al proceselor informaționale și-a facut apariția atunci când afacerile și-au schimbat orientarea de la producția de masa către populația destinată satisfacerii cerințelor consumatorilor.

Rolul operational

Prin sistemele informaționale se asigură o eficiență sporită activităților, cresterea productivității muncii, satisfacerea în timp util și cu informații de calitate a cererilor de informare formulate de conducere, precum și a cerințelor clienților. La acest nivel, problemele de planificare, conducere și control se orientează spre o perioada destul de scurtă de timp, vizand informațiile necesare luării deciziilor precum desfasurarea activităților curente ale intreprinderii. Informațiile oferite se referă la: producție, aprovizionare cu materii prime și materiale, desfacere etc.

Rolul in sprijinirea luarii deciziilor

Sistemul informațional trebuie să asigure conducerii informații prin care se pot lua decizii de strategie ale firmei, ce o angajează pe termen lung și decizii care privesc modul de acțiune al firmei în functie de contextul economic actua și al pozitiei concurenților.

O altă perspectivă din care mai poate fi văzut rolul strategic al sistemelor informaționale, în general și al tehnologiilor informationale, în special, este acceea a eliminării barierelor tradiționale care apareau în fața firmelor : timp , geografice , de cost, structurale.

3.2.2 Maparea de la modelul obiectual la modelul relațional

O schemă orientată-obiect definește datele precum și structurile acestora. Clasele obiect pot avea o singură sau mai multe moșteniri. Instanțele obiect din interiorul unei clase obiect pot avea structura internă ca cea a unei clase obiect care sunt compuse din alte clase obiect prin referință .

Compoziția ierarhică organizează elementele astfel încât să fie convenabil aranjate pentru un lucru ce urmează a fi făcut. Metoda obiect conține multe elemente de care nu este nevoie, pentru maparea în cadrul modelului relațional sau pentru integritate. Structura relațională are câteva elemente care nu sunt definite ierarhic. Mai degrabă elementele sunt compuse, după cum are nevoie aplicația de ele, prin intermediul view-uri si querie-urilor.

Pentru a executa o mapare de la schema obiect către schema relațională, am integrat ierarhia obiect într-un model rețea, care este mai general decât ierarhia. Modelul semantic pe care l-am folosit în modelul structural, care descrie sistematic relațiile și nu necesită instanțe separate de stocare ca cele din modelul relațional .

Clasele adiționale pot fi definite în cadrul de lucru argumentând modelul. Stocarea datelor la obiect este realizată creând relații de bază după nevoie. Dacă există relații apropiate ele pot fi argumentate și conectate.

Odată ce relațiile de bază sunt populate, instanțele de legătură pot fi procesate din cadrul modelului și pot fi stocate relațiile de bază. Modelul structural poate reconstrui componente, (clase de obiecte), dar și clase de obiecte potențiale recunoscând ierarhia din interiorul rețelei. Noi clase pot fi create de asemenea conectându-le una cu celelalte și a relațiilor relevante existente. Pentru a mânui moștenirea, orizontal și vertical partiționările sunt suportate. De asemenea mai este suportată și opțiunea în care o parte a ierarhiei moștenite este stocată într-o relație universală, care conține toate atributele din ierarhie dar și un indicator al atributului, tipul și obiectul instanței.

Normalizând nodurile obiect aflate în 3FN folosind relațiile standard din cadrul designului tehnic din cadrul bazei de date, rezultatul este o reprezentare a rețelei respective.

Modelul structural recunoaște mai multe tipuri de relații formalizate într-un „copac” de conexiuni. Un model structural este un graf în care fiecare nod reprezintă o relație unde vârsta reprezintă o conexiune (o relație) între două relații.

Modelul este comparabil cu cel entitate-relație, dar folosește un model relațional ca bază. Conexiunile au nevoie de un model fezabil de legături cum ar fi : l- 1, n-1 .

3.2.2.1 Maparea claselor

Cea mai eficientă formă de mapare este uneori maparea directă a unei clase pe o tabelă relațională. O mapare mai complexă poate să ducă la apariția unor probleme de performanță. Clasele care prezintă o legătură între mai multe tabele vor fi greu de construit și uneori chiar imposibil de updatat. În general dezvoltatorii trebuie să mapeze fiecare clasă pe o singură tabelă, putând fi construite oricând obiecte mai complexe . Două excepții de la această regulă includ crearea unor proiecții obiect pentru a minimaliza traficul în rețea și view-ul obiect pentru deciziile suport. Proiectarea obiectelor pentru tabele cu mai multe coloane pot să fie eficiente pentru maparea proiecției de la o tabelă către “o clasă de proiecție”, scoțând în evidență un rând întreg atunci când este necesar. De exemplu un rând client poate să aibă 50 de coloane dar doar numele și numărul de telefon sunt folosite de cele mai multe ori creând o clasă cu mapare pentru fiecare coloană necesară, dezvoltatorul poate să evite procesarea și transmiterea informațiilor inutile prin rețea. Acest tip de clasă trebuie să conțină cheia primară la un nivel minim .

3.2.2.2 Maparea relațiilor

Relațiile dintre obiecte pot fi mapate pe o cheie străină dintre rânduri, așa cum fiecare mapare este implementată, ea având un impact semnificant asupra performanței și flexibilității aplicației pe ansamblu. Dezvoltatorii au mai multe opțiuni de mapare a relațiilor unui obiect către o tabelă relațională:

1. Tabele distincte: în această abordare relațiile sunt reprezentate ca tabele distincte în cadrul bazei de date. Această abordare oferă o flexibilitate maximă deoarece permite adăugarea și scoaterea relațiilor transparente către alte tabele. Acest tip de abordare pooate fi implementat dacă relația este parcursă frecvent.

2. A doua opțiune este cea mai aleasă pentru relațiile de tip unu la unu și unu la multe. În acest caz pentru o clasă oarecare cheia primară a unei clase aflate în legatură este încorporată în interiorul clasei respective ceea ce duce la o mai bună performanță decât cea de la punctul 1.

3. În acest caz două clase sunt fuzionate între ele acest tip de fuziune crește performanța dar și costul de violare al normalizării.

3.2.2.3 Maparea ierarhiilor

Ca și în cazul relațiilor modul în care instanțele obiect sunt mapate pe o bază de date pot să aibă un profound impact în ceea ce privește performanța .

O clasă părinte poate să fie ori abstractă ori concretă. O clasă abstractă părinte este cea care nu va fi niciodată instanțiată de la sine și în consecință nu are date fizice asociate ei. O clasă concretă părinte, este cea care poate să existe de la sine și tipic va avea o tabelă proprie asociată.

Peter Heinckiens este un specialist atestat în domeniul bazelor de date. El lucrează momentan la Department of Informațion Technology (INTEC) din cadrul Universității Ghent și este implicat în domeniul bazelor de date orientate către obiecte fapt ce a permis să-și ia doctoratul pe baza acestora.

Sistemele de baze de date orientate pe obiecte oferă prea multe dezavantaje în comparație cu sistemele relaționale care au o performanță superioară, când prelucrează relații complexe în absența impedanței.

Dacă vom studia îndeaproape meritele bazelor de date orientate pe obiecte vom vedea mari diferențe între ele și cele relaționale.

Din punct de vedere tehnologic acest aspect al performanței este interesant de observat atunci când ne uităm la performanță, pe ansamblu ei, a întregului sistem. Totodată alegerile programatorului pot diferi în comparație cu alegerile sistemului și aplicației, pe care rulează programul. Programatorul este interesat doar de dezvoltarea softului propriu, iar alegerile sistemului de gestiune al bazelor de date este doar o chestiune de implementare. Acestuia îi pasă doar de persistența datelor. O bază de date orientată pe obiecte, este din perspectiva lui, doar un mod pentru a-și implementa persistența, cu alte cuvinte pentru programator baza de date nu este nici mai mult nici mai puțin decât un aspect al implementării.

Indiferent de obiectul și modul în care datele sunt accesate și stocate în cadrul bazelor de date, chiar dacă sunt printate pe hârtie, sunt scanate și introduse din nou aceste lucruri sunt irelevante pentru utilizatorii obiectului persistent. Singurele aspecte din punct de vedere al obiectului pentru ca acesta să devină persistent este restaurarea la un moment oarecare în viitor.

Deși este adevărat faptul că bazele de date orientate pe obiecte oferă o performanță superioară câștigată atunci cand procesează relații complexe, pentru multe aplicații (multe programe software administrative) este adecvat și lucrul cu sistemele relaționale. În special când ne uităm la uriașul avantaj tehnologic prin care au trecut sistemele în ultimii ani. Putem afirma că arhitecturile oferite de memoriile de 64-bit pot de asemenea să ofere performanțe serioase, deoarece pot fi verificate mari partiții de baze de date în memorie.

Problema principală al dezvoltatorului de astfel de aplicații, este confruntarea cu așa numita impedance mismatch. Consecințele cele mai des observate sunt acelea că bazele de date relaționale dictează structurile de date programatorului, ba chiar mai mult putem afirma că influențează intreaga abordare a programatorului. Principalul avantaj pe care îl oferă bazele de date obiectuale este acela că în cadrul acestor tipuri de baze de date nu întâlnim impedance mismatch.

Din punctul de vedere al programatorului, nu avem nevoie de un sistem de gestiune al bazelor de date orientate pe obiecte, ci avem nevoie de un program care să-l rezolve impedance mismatch. Acest lucru poate fi obținut realizând un program cadru care să ofere un aspect orientat pe obiecte al bazei de date.

3.3 Principalele sisteme de gestiune a bazelor de date orientate pe obiecte

În pofida faptului că modelul relațional este unul din modelele cele mai utilizate la ora actuală, acesta nu permite: descrierea structurilor de date complexe (date in format multimedia, documente electronice, grafice), descrierea unor tipuri de date-utilizator, partajarea /reutilizarea structurilor de date, declararea prelucrărilor aferente structurilor de date (datele sunt descrise separat de prelucrări).

Modelul orientat-obiect a apărut ca răspuns la astfel de cerințe încă de la sfârșitul anilor’60, odată cu limbajele de programare ca Simula67, Smalltalk, urmând ca orientarea pe obiect să fie adoptată și de alte limbaje cum ar fi:C++, Pascal, Ada. Sistemele de gestiune a bazelor de date (Ontos, O2, GemStone, Versant, Jasmine) au adoptat și ele orientarea pe obiecte. În esență, modelul orientat-obiecte permite modelarea directă a realității prin intermediul obiectelor definite ca entități cu identitate proprie și caracterizate prin comportament și stare.

3.3.1 GemStone

GemStone a fost proiectat de către ServioLogic Corporation din Alamada pentru a satisface nevoile existente pe piață pentru un astfel de sistem comercial. Abordarea principală a fost aceea de a examina limbajul Smalltalk și a identifica numărul de cerințe existente, pentru a realiza din acest limbaj, un sistem de baze de date. În ceea ce privește rezultatul acesta a fost apariția pe piață a limbajului OPAL care manipulează sisteme și date persistente controlate de către un sistem de stocare pe bază de disc .

Soluția GemStone oferă dezvoltatorilor de aplicații un sistem de baze de date, bazat pe subsistemul de tip Smalltalk, decât unul din cele traditionale orientate pe înregistrări cum ar fi cel relațional sau ierarhic. Acest model permite procesarea de informații de tipul : documentelor, imaginilor și sunetelor care nu sunt foarte ușor de procesat de către sistemele de baze de date tradiționale. Modelul de date orientat –obiect GemStone este exact ca și modelul Smalltalk-80; cele trei mari idei principale ale sistemului orientat-obiect GemStone sunt: obiectele, mesajele și clasele. Clasele în cadrul sistemului sunt structurate într-o ierarhie de clase, unde fiecare subclasă ierarhică moștenește comportamentul și structura de la supraclasa sa. De exemplu când un mesaj este primit de către un obiect acesta consultă clasa respectivă ( și superclasa) pentru a găsi metoda corectă de execuție. O caracteristică principală pentru care sistemul GemStone a fost realizat, era aceea de a crește puterea de manipulare a datelor dintr-o componentă a bazei de date cu scopul de a micșora timpul de procesare al aplicațiilor cum ar fi sistemele de informare de tip office, documentațiile din cadrul unui sistem complex, mecanizat (mașini, avioane), designul asistat de calculator și inteligența artificială.

Există două componente principale ușor de remarcat la arhitectura sistemului de gestiune orientat pe obiecte GemStone. Prima este cea în care serverul Gem procesează acele situații în care comportamentele obiectelor specificate în GemStone DML sunt executate, cea de-a doua caracteristică Stone monitorizează alocarea de noi identificatoare de obiecte și le aduce în fața managementului obiectelor persistente, controlul concurenței, autorizarea , tranzacțiile și operațiile de recuperare.

Procesul Stone rezidă normal din serverul mașină în timp ce Gem poate să rezide atât din server cât și din calculatorul clientului. În cadrul sistemului GemStone schemele de control ale concurenței sunt implementate și indiferent de cea care se utilizează, cea optimistă sau cea pesimistă se ajunge la o soluție adecvată prin utilizarea acestora.

Acest tip de sistem menționat mai sus oferă posibilitatea realizării unui sharing de obiecte dând fiecărui utilizator o listă de dicționare cunoscută sub numele de SymbolList. Această listă este privată pentru fiecare utilizator, dar dicționarul folosit de către aceasta poate fi sherat. O altă caracteristică include accesul asociativ rapid, limbaje uniforme, sisteme de management de stocare primar și secundar, server centralizat și securitate.

3.3.2 O2

Sistemele de date orientate pe obiecte O2 au fost dezvoltate la GIP Altair în LeChasnay, Franța, ca un prototip de cercetare iar în momentul de față este un produs comercial disponibil pe piață. Acest proiect a fost fondat de INRIA Seimens-Nixdorf, Bull, CRNS, și Universitatea din Paris. Scopul acestui proiect O2 a fost acela de a dezvolta un sistem de management al bazelor de date orientate pe obiecte de nouă generație specific aplicațiilor de tip CAD/CAM , sistemelor geografice de tip urban, sistemelor informatice editoriale, cât și în cadrul acelor sisteme tradiționale de afaceri și de procesare a tranzacțiilor . O2 a fost implementat în limbajul C și rulează pe stațiile de lucru de tip SUN sub SUN OS 4.0.

Paradigma orientării pe obiecte poate să reprezinte structurile de date de o complexitate arbitrară. Câteodată este convenabil să putem specifica caracteristicile adiționale a structurilor de date, de exemplu: este necesar să interzicem sharing-ul unui obiect către mai multe obiecte. Acest lucru este realizat în programul de gestiune al bazelor de date O2 prin valori. În ceea ce privește valorile programului O2 acestea nu pot fi puse la shared. În cadrul programului de gestiune al bazelor de date O2 nu pot fi exprimate restricțiile către un obiect pus la sharing.

Nucleul sistemului de gestiune O2 este O2 Engine care stochează obiecte de tip multimedia și structurate, manevrează cu managementul discurilor, a distribuției cu managementul tranzacțiilor, concurența, recuperarea datelor, securitatea cât și administrarea datelor. Motorul O2 suportă obiecte complexe cu identități, clase tipuri încapsulate, metode, moșteniri multiple, suprascrieri și îmbinări ale metodelor. Acest sistem de gestiune al bazelor de date orientat pe obiecte este compus din trei mari straturi: o schemă manager, un obiect manager, și managerul de disc O2 care este o extensie a sistemului de stocare (Wisconsin Storage System ).

Motorul O2 poate suporta două tipuri de interfețe, cea din limbajul C căt și cea a limbajului C++ și a mediului O2 . Mediul O2 include un limbaj de tip query denumit O2 query care este o extensie a limbajului SQL, care manevrează date complexe și valori ale obiectelor cât și un generator de interfață orientat pe user (user-interface generator), care suportă o creație de grafică simplă dar cu o calitate ridicată, o interfață bazată pe lucrul ferestrelor predefinite ușor costumizabile cât și un obiect dar și un limbaj de programare orientat pe obiecte de generația a patra (4GL), C O2 care permite unui utilizator să realizeze atât programarea cât și manipularea bazelor de date dar și un mediu de programare grafic, ce include o schemă și un browser al bazei de date.

O caracteristică importantă care face acest tip de sistem să facă un pas înapoi a fost acela că inițial O2 a fost dezvoltat pentru a fi implementat în cadrul limbajelor de programare existente.

3.3.3 Ontos

Sistemul de baze de date orientate pe obiecte Ontos a fost creat de către Ontologic of Billercia, este un produs comercial disponibil pe piață, bazat pe faptul că acesta face din C++ un limbaj de programare pentru bazele de date.

Ontos a înlocuit pe piață un produs mai vechi de la Ontologic VBase care utiliza modelul orientat pe obiecte, cu limbajele COP și TDL. Limbajele non–standard cât și problemele de preformanță ale VBase au influențat pe Ontologic să scoată pe piață produsul Ontos. Acest sistem de gestiune al bazelor de date orientate pe obiecte a fost implementat absolut pe limbajul C++ și rulează sub UNIX .

Acest sistem de gestiune al bazelor date, Ontos se bazează în principal pe puterea și portabilitatea limbajului C++. Deasemenea este adevărat faptul că majoritatea sistemelor baze de date ce se bazează pe limbajul C++, în cadrul acestora tranzacțiile sunt definite static în momentul compilării fapt ce duce la nealocarea unei flexibilități în timpul rulajului programului. Limbjul C++ îi dă sistemului Ontos alte caracteristici cum ar fi: încapsularea și ascunderea datelor cât și ierarhii multiple. De exemplu programul Ontos permite itemilor să fie stocați în baza de date și să fie accesați și manipulați în cadrul limbajului C++ printr-un program de aplicație. Cu alte cuvinte obiectele din cadrul unei baze de date, pot fi activate ( transferarea unui obiect din baza de stocare secundară în memoria virtuală C++) și poate fi dezactivate (mutate înapoi în baza date ).

În ceea ce privește Ontos, toate tranzacțiile sunt înseriate, existând posibilitatea utilizării schemelor de control concurențiale atât cele optimiste cât și cele pesimiste. În cazul unei situații pesimiste, conflictele de accesare sunt verificate în timp ce tranzacția este inițializată, acest fapt duce la reducerea concurenței, dar asigură comiterea tranzacțiilor în eventualitatea eliminării lucrului. Programul Ontos permite verificarea tranzacțiilor înainte ca acestea să fie comise.

Acest sistem de gestiune orientat pe obiecte are la bază arhitectura de tip client/server pentru interacțiunile de date, caz în care partea de server verifică datele stocate, iar partea de client oferă interfața utilizatorului pentru procesare și supraveghează maparea de date din cadrul aplicației de procesare virtuală din cadrul spațiului de memorie. Atât partea de client cât și cea de server pot să comunice între ele printr-o rețea de calculatoare.

O caracteristică principală a programului Ontos este aceea că facilitează două tipuri extrem de diferite de referințe-obiect, direct referința C++ și referințele abstracte. Referințele abstracte permit menținerea referinței când abstractizarea obiectelor este mutată în cadrul memoriei principale în timp ce referința directă este responsabilitatea utilizatorului. O altă caracteristică a limbajului Ontos este aceea că utilizatorii pot alege între conveniență și siguranță pe de o parte și performanță pe de altă parte. Utilizatorul poate accesa acele legături dintre siguranță și performanță deoarece acest program nu oprește utilizatorul să încalce regulile de exemplu substituind referințele abstracte sigure, cu referințele directe.

Programul Ontos este unul din primelele sisteme de managemt al bazelor de date orientate pe obiecte „persistent”. Mecanismul programului Ontos permite unui singur obiect să existe în unul sau mai multe versiuni. Acest mecanism al versiunilor colectează toate obiectele ce au aceiași versiune înt-un obiect configurat. Pentru a creea o nouă configurare plecând de la legăturile existente trebuie ca acestea sa fie bine realizate iar obiectul să nu fie copiat.

Deși sistemul Ontos are o mare bază de instalare și este printre cele mai folosite sisteme de gestiune al bazelor de date orientate pe obiecte, care au la bază sistemul C++, primele versiuni ale acestui program au avut multe regrese. Aceste versiuni aveau puține scripturi sau chair deloc pentru date de tip multimedia, pentru obiecte compuse, pentru evaluarea dinamică a schemei sau securității. Aceste limitări au fost îmbunătățite cu versiunile precursoare celei dintâi .

3.4 Strategii

Pentru dezvoltarea unui sistem de gestiune al bazelor de date orientate pe obiect se poate aborda una din următoarele strategii:

extinderea unui limbaj de programare obiect-orientat cu capacitate de administrare a obiectelor persistente. Sistemul GemStone este un astfel de SGBDOO, dezvoltat prin extinderea limbajelor C++ și Java;

extinderea unui limbaj de programare relațional cu capacitate de orientare spre obiecte. Un astfel de limbaj este limbajul ODL (Object Query Language) (sau Object SQL), specificat prin standardul propus de consorțiul Object Database Management Group, din care fac parte principalii producători de sisteme de baze de date orientate pe obiecte ;

dezvoltarea unui limbaj obiect-orientat pentru baze de date complet nou, care să asigure crearea și interogarea obiectelor persistente. Există și astfel de produse, ca de exemplu sistemul SIM (Semantic Information Manager) .

Cu toate că primele SGBD-uri orientate pe obiect au apărut pe piață „de curând” tehnologia bazelor de date orientate pe obiecte se găsește într-o fază mai degrabă imatură. Imaturitatea tehnologiei bazelor de date orientate pe obiecte s-ar traduce printr-o serie de limitări care justifică reținerile potențialilor utilizatori:

deoarece nu a fost acumulată suficientă experiență în domeniu, fiecare pas este unul de învățare și pionerat chiar și pentru producătorii de astfel de sisteme;

măsura în care sistemele orientate pe obiect sunt scalabile nu a fost încă suficient de testată, astfel încât comportarea acestora la volume foarte mari de date în condițiile unei accesări concurente intense, este dificil de prevăzut;

nu există o ofertă semnificativă de facilități de dezvoltare evaluate, cum ar fi generatoarele de aplicații;

limbajele de interogare sunt deficitare datorită faptului că o mare parte din cod este incapsulată în obiecte, interogarea ad-hoc a bazei de date devine mai dificilă.

Cu privire la un mecanism de tip view face dificil ca obiectul desemnat pentru o anumită aplicație să fie reutilizat într-un mod eficient de o altă aplicație, menținând în același timp încapsularea pentru paradigma orientării obiect. Deasemenea adaugarea de view-uri noi unui sistem de baze de date orientat obiect, este încă o problemă în curs de rezolvare în cadrul laboratoarelor de specialitate.

Vânzătorii de baze de date orientate pe obiecte recunosc nevoia integrării acestor produse cu modelul relațional și cu bazele de date ale acestui model. Ba chiar mai mult putem afirma că vânzătorii de baze de date orientate pe obiecte își extind rapid suita de instrumente, oferite la achiziția unei astfel de soluții .

Mai multe componente ale unui sistem de baze de date orientate pe obiecte trebuie să fie proiectate cu atenție și să permită o semantică orientată obiect. În al doilea rand indexarea controlului concurenței, optimizarea query, automatizarea și managementul directoarelor obiect , sunt principalele componente ale unui sistem de baze de date orientat pe obiecte care prezintă performanțe satisfăcătoare cât și o arhitectură pe măsură. Acestea cu excepția managementului directoarelor de obiecte sunt deasemenea importante componente ale unui sistem de baze de date convențional, în schimb tehnica și arhitectura folosită în sistemele convenționale sunt inadecvate sau improprii pentru sistemele de baze de date orientate pe obiect.

Sistemele de baze de date orientate pe obiect pot fi remarcate mai ușor datorită persistenței pe care o dețin și a complexității de baze de date. Asemenea sisteme de baze de date pot satisface modelarea datelor și a cerințelor de performanță private din mai multe puncte de vedere pentru astfel de aplicații. Unele dintre aceste aplicații utilizează mari cantități de date pe care le procesează printr-un număr mare de obiecte aflate în legătură, mai precis se încarcă toate obiectele necesare în memoria virtuală după care se execută operațiile necesare pentru acest tip de date. Aceste procesări prezintă o paradigmă cea a sistemelor de baze de date convenționale care constă în livrarea unui obiect la timp pentru acea aplicație. Unele sisteme de baze de date orientate pe obiecte prezintă un design ce permite ca întreaga putere a sistemului de baze de date să ducă obiectele în memorie. De asemenea prezintă o stabilitate și o performanță ridicată față de celelalte aplicații aflate pe piață .

Într-un mod tradițional sistemele de management al bazelor de date relaționale au fost dezvoltate pentru a face față necesităților tradiționale pentru afacerile existente. Tipurile de date necesare pentru aceste aplicații împreună cu operațiile ce trebuiesc executate asupra acestor date, se completau de minune într-un pachet oferit de sistemele relaționale de baze de date. Odată cu introducerea pe piață a aplicațiilor de baze de date din noua generație necesitățile de stocare a datelor și manipularea acestora nu sunt bine suportate de aceste aplicații, existând o nevoie pentru abilitatea de a face față datelor complexe cum ar fi : imagine, voce și documente de tip text.

Designul claselor și al obiectelor din cadrul unui sistem de gestiune al bazelor de date orientate pe obiecte , reprezintă un design al entităților din lumea reală ceea ce dă un sentiment mai bun pentru mașină asupra problemei în locul unor tabele aplatizate din cadrul sistemelor de gestiune al bazelor de date relaționale.

Un avantaj major al conceptului orientării pe obiecte este acela că obiectul poate fi refolosit în cadrul diferitelor programe. Pot fi construite programe mult mai repede decât dacă am încerca să le construim de la zero. Un software–obiectual poate fi construit astfel încât să reprezinte o gamă largă de entități, de la un model abstract către un obiect specific.

În ceea ce privește avantajele sistemelor de gestiune al bazelor de date orientate pe obiecte acestea pot fi enumerate și clasificate în mare măsură astfel:

dețin un model de date puternic și realist

manevrează obiecte complexe

deține moșteniri de ierarhii printre seturi de entități

asociază comportamentele obiectelor cu definirea și schema de nivel a acestora

detine legături implicite de-a lungul agregatelor de ierarhii, bazate pe entitățile obiect

un limbaj query mai expresiv

un suport mai bun pentru modul de lucru comparat.

O reprezentare mai pe scurt a modelului orientat pe obiecte, a bazei de date bibliotecă se va realiza mai jos, cu ajutorul câtorva figuri sugestive .

Figura nr.3.1 Diagrama cazurilor de utilizare pentru aplicația Bibliotecă

Figura nr. 3 .2 Diagrama de clase a aplicației Bibliotecă

Figura nr. 3.3 Diagrama de clase-entități

În ceea ce privește baza de date bibliotecă aceasta ar arăta transformată și integrată pe o platformă orientate-obiect și anume Argo UML ca cea din figura 3.1.

A doua figură cu numărul 3.2. prezintă clasele-model, din cadrul bazei de date bibliotecă, iar figura nr 3.3 reprezintă diagrama de clase entități care va reda clasele așa cum vor fi ele implementate cu ajutorul unui limbaj orientat obiect, cât și modul cum va fi asigurată persistența.

Partea practică implementată în Java conține urmatoarele cuburi de date prezentate succinct cu ajutorul unei figure suggestive ca cea demai jos .

Figura nr. 3.4 Pachetele de date în Java

Pachetul de date gestbibliotecă.bussiness.model conține implementate clasele din cadrul acestei baze de date bibliotecă. Acestea sunt prezentate succinct în figura 3.5.

Figura nr 3.5 Clasele bazei de date

Foarte importante sunt entitățile deoatece acesate îmreună cu calasele din cadrul bazei de date sunt utilizate la realizarea persistenței care este extrem de importantă într-o bază de date orientată pe obiecte.

Figura nr 3.6 Entitățile bazei de date

Pin persistență și anume prin DAO se stabilește legătura dintre baza de date și interfața utilizator. Toate operațiile la care este supusă baza de date se realizează prin intermediul persistenței.

În acesată figută se declară tipul clasei care este public , cât și caracteristicile acesteia : private string autor ,private by ordinecopertă. Această clasa conține metode cum ar fi : metoda setautor care este de tip public seaplica pentru toate și care î-mi returnează autorul . Metoda setordinecoperta î-mi seletează autorii după ordinea de pe copertă.

CAPITOLUL IV TENDINȚE ÎN BAZE DE DATE

Acest capitol își propune să enumere și să prezinte pe scurt câteva din tendințele actuale pe care evoluează actualmente bazele de date.

4.1 Baze de date XML

Este dificil de găsit evaluări detaliate a produselor bazelor de date-obiect pentru sistemele din lumea reală. Pe bună dreptate acest lucru se întâmplă deoarece multe companii văd această tehnologie ca și un domeniu competitiv și de aceea nu divulgă informații despre descoperirile făcute în acest domeniu atât cele pozitive cât si cele negative. Folosirea limbajului XML pentru a manageria datele corporate cu o bază de date obiect arată că această tehnologie este bine „ înfiptă” pentru acest tip de aplicație. Aplicațiile de management al documentelor își au locul în categoria aplicațiilor complexe, în particular în aria documentelor structurate folosind SGML sau mai recent XML ca un format de reprezentație al documentelor reprezintă un atu.

Există două mari abordări în ceea ce privește modelul obiect în XML. Prima calificată generic consideră toate informațiile din document cum ar fi tag-urile, atributele sau conținutul text ca fiind obiecte ale unei clase definite, interconectate între ele cu legături care reprezintă structura XML pentru instanțe, existând doar o singură clasă pentru tag-urile din XML sau orice tip de document.

O altă abordare , descrie o nouă clasă pentru fiecare nou tip de informație, această abordare este specifică în special documentelor XML valide, făcând legătura semantică cu structura documentului prin intermediul DTD. Dar maparea documentelor bine formate reprezintă o altă problemă deoarece orice document potențial are nevoie de un nou model .

În ultimul timp s-a vorbit foarte mult despre faptul că internetul va ajunge să aibă un impact major și chiar să poată schimba economia mondială. Companiile vor începe să se unească între ele pentru a forma parteneriate în domeniul comerțului prin intermediul rețelei. Se vor înființa companii virtuale și modele de afaceri, care pot fi create pe baza acceselor la informații folosind computerele din lumea întreagă.

În ceea ce privește folosirea XML-ului în cadrul comerțului electronic, acest lucru duce la folosirea documentelor de tip form și mesajelor, fapt ce va implica interconectarea acestora în cadrul afacerilor. XML este un ingredient cheie care va accelera modul de lucru într-o rețea economică și a modelelor noi de afaceri de pe internet.

Principalele caracteristici ale XML-ului sunt:

o platformă de aplicație cu un format de date independente

o cale de validare a structurilor de date.

o sintaxă care poate fi înțeleasă de oameni cât și de calculator

un mod de incrementare și de dezvoltare a aplicațiilor de tip web folosite în cadrul comerțului electronic.

Pentru a întelege mai bine beneficiile XML-ului este necesar să-l comparăm cu un model care este foarte folosit la ora actuală și anume HTML-ul. HTML este un limbaj de afișare ce deține facilități limitate pentru distingerea dintre structura de conținut stil și relații. Pentru ca aplicațiile de comerț electronic existente pe piață să funcționeze, multe tag-uri și extensii ale HTML au fost dezvoltate.

Limbajul XML face ca procesarea informațiilor de către calculatoare, să fie mult mai rapidă. XML și XSL vor ușura serviciile web fapt ce va influența documentele XML și XSL în cadrul browser-ului cât și transformarea acestora în HTML.

4.2 Baze de date multidimensionale

Bazele de date multidimensionale au apărut ca urmare a cerințelor de analiză și procesare multidimensională a datelor .

Bazele de date multidimensionale sunt agregate ce reprezintă un client software (este un sistem de calculatoare care accesează un serviciu de pe un alt calculator printr-o rețea) care folosește un web feed (este un format de date pe care userii le folosesc și care își updatează frecvent conținutul ) de date care combină date ce provin din mai multe surse, baze de date ce oferă rețea, ierarhie și alte tipuri de date dificile pentru SQL (cel mai cunoscut limbaj de programare care este folosit pentru a creea , modifica și manipula date), sau baze de date care oferă un grad ridicat de flexibilitate în ceea ce privește dimensiunile, unitățile și a relațiilor dintre unități, indiferent de tipul datelor. Aceste tipuri de baze de date sunt utile în mod special pentru aplicațiile de marketing și vânzare care implică scurtarea timpului. Un volum mare de vânzări și datele de la inventar pot fi stocate și folosite în logistică și în planificare. De exemplu datele pot fi gata organizate pe regiune, produs sau perioada de timp. În timp ce majoritatea vânzătorilor de astfel de soluții au recunoscut și implementat cel puțin o variantă parțială, de cele mai multe ori marea lor majoritate folosesc o bază de date de tip stea . Totuși bazele de date stea nu iau în calcul datele împrăștiate, deoarece irosesc spațiul gol. Strategia bazei de date în ceea ce privește managementul datelor împrăștiate din cadrul blocurilor de entităti de date, îmbunătățeste performanțele bazei de date pe ansamblu .

Cubul de date este prezentarea conceptuală a unei baze de date care poate să fie implementată în mai multe feluri: top-down, bottom-up și array. Bazele de date multidimensionale pentru seriile de timp, este de preferat a se realiza în baze de date relaționale . Pe de altă parte dimensionalitatea devine problematică atunci cănd lucrăm cu mai mult de patru dimensiuni , deoarece există aproape întotdeauna rezultate la datele împrăștiate sau datele goale. Înlăturarea datelor împrăștiate sau goale reprezintă un risc și poate să strice contextul sau în special coordonatele vectoriale ale datelor .

Cercetările din acest domeniu al fizicii quantice și termodinamicii au produs o apropiere față de folosirea unei mici porțiuni de cod de soft pentru a reprezenta o coordonată sau o serie de coordonate. Un calculator poate atunci să identifice proprietățile fiecărei coordonate din șirul de biți rezultați. Aceasta aplicație nu a fost implementată nici unei versiuni comerciale a bazelor de date multidimensionale.

Este un domeniu activ de dezvoltare a bazelor de date, în care setul de caractere dezirabile este cam vag, dar mai bine definit decât setul de soluții știute sau propuse. Definind și implementând o bază de date care permite oamenilor de la fiecare nivel dintr-o organizație să definească tabele și tipuri de date , într-un mod util pentru ei , dar să aibă la bază un singur cod și o infrastructură consistentă rămâne încă o problemă de rezolvat în zilele noastre .

Aplicațiile care se bazează pe analiza multidimensională sunt cunoscute sub denumirea de OLAP(On Line Analytical Processing ). Acest tip de aplicații asigură analiza și manipularea datelor, folosind cereri complexe în vederea elaborării de strategii.

OLAP realizează analize manageriale (este acronimul din engleză pentru instrument de prelucrare analitică) în timp real a informațiilor dintr-un sistem.
În esență, acest instrument va permite analiza globală a activității și/sau a performanțelor firmei folosind modele economice multidimensionale: cuburi de date etc.
Avantajul cheie al utilizatorului este viteza cu care se obțin aceste date și faptul că nu mai necesită nici o prelucrare ulterioară, putând fi folosite direct în procesul decizional.

Siveco România a organizat în stațiunea Neptun un seminar în care a prezentat câteva dintre soluțiile software ale companiei, printre care instrumentul de analiză Siveco Business Analizer, Componenta de Management al Producției din cadrul pachetului integrat Siveco Applications, sistemul de management al documentelor Sivadoc și platforma de eLearning AeL Enterprise.

După Nicolae Fildan datorită spectrului larg la care se referă BI este greu de selectat o definiție reprezentativă sau unanim acceptabilă. BI este un concept generic care grupează sub aceeași umbrelă instrumente din domeniul afacerii și al informațicii, utilizate în vederea transformării datelor în informații, a informațiilor în decizii și a deciziilor în acțiuni. Aplicațiile informatice utilizate în BI sunt diverse și se referă la sisteme suport pentru luarea deciziei, raportări și interogări, procesare analitică online a datelor (OLAP – On Line Analitical Processing), analize statistice, previzionări, sortarea datelor în vederea identificării de șabloane și relații (data mining) etc. Sunt sisteme informatice inteligente. Soluțiile actuale de tip BI pot fi considerate ca o etapă importantă de integrare a domeniului afacerii cu cel al informaticii. Utilizarea tehnologiilor înalte din cadrul Tehnologiei Informației (exemplu: inteligența artificială, sisteme expert etc) și din management (Business Process Reenginering, Business Process Management, Business Performance Management etc.) va face posibilă o simbioză între cele două domenii. Cert este că implementarea unei soluții de tip BI este o mare provocare atât pentru specialiștii din domeniul managementului cât și pentru cei din domeniul informatic. Este necesar ca ei să facă o echipă comună care trebuie să-și propună și să lupte pentru finalizarea cu succes a implementării.

Bit Software a devenit Microsoft Gold Certified Partner în noul program Microsoft Partner Program cu două competențe dovedite: ISV și Business Intelligence.
  Prin certificarea ca partener gold, Bit Software demonstrează că are competențe recunoscute în dezvoltarea de soluții bazate pe tehnologie Microsoft, precum și competențe dovedite în implementarea de soluții care includ Business Intelligence și OnLine Analytical Processing (OLAP). 

În cadrul modelului relațional problema esențială tratată este cea a dependenței datelor , a independenței programelor și a activităților din terminale datorată creșterii tipurilor de date precum și a schimbărilor ce au loc la nivelul reprezentării datelor cât și cel al consistenței lor.

Modelul relațional pare să fie superior celui rețea. El ne oferă un mod de a descrie datele cât mai natural cu putiință fără a impune o structură adițională .

4.3 Baze de date Web

Internetul și în special www-ul prezintă o abordare promițătoare pentru a face cunoscute toate tipurile de date și informațiile disponibile pe internet cât și cele care rulează pe rețele private. De asemenea transformarea informațiilor private în informații publice, prezentate ca pagini statice care sunt redactate cu ajutorul limbajului HTML, nu sunt potrivite pentru pachetele mari de date, care sunt conținute de sistemele de gestiune a bazelor de date. Potențial vor fi procesate de două ori același volum mare de date, fapt ce face să fie dificil de utilizat update-urile pentru aceste tipuri de date, menționând faptul că facilitățile de date sunt limitate. O altă limitare a standardului www este acela că acest tip de tehnologie nu permite combinarea rezultatelor parțiale de la diferite servere într-o singură pagină rezultat.

Aceste tipuri de restricții prezentate mai sus sunt din ce în ce mai evidente pentru dezvoltatorii de aplicații cât și pentru utilizatorii care devin din ce în ce mai specializați la dezvoltarea și utilizarea soft-urilor pentru www. Din fericire câteva tehnologii care pot fi suportate la o scară largă sunt adresate unor astfel de probleme.

Java este un limbaj de programare orientat-obiect care a fost special creat pentru a fi utilizat în cadrul unei rețele. Limbajul Java poate fi folosit atât singur cât și împreună cu www-ul. Programele mici de tip Java, așa numitele Applets (merișoare) sunt transferate sub forma unor coduri de biți de la serverul Web catre HTTP. Aceste „merișoare” sunt executate de o mașină virtuală care rulează în interiorul browserului. Modelul executat asigură un grad ridicat de securitate chiar și pentru “merișoarele” care sunt copiate de pe Internet.

Serverele WEB sunt folosite din ce în ce mai mult pentru a transmite un conținut dinamic decât un conținut static cum ar fi paginile HTML. Pentru a genera pagini WEB dinamice serverele trebuie să execute un script care de obicei se conectează la un sistem de gestiune al bazelor de date.

În mai puțin de zece ani de la debutul sau în timpul anilor ‘90 WEB-ul a modificat dinamic viețile noastre. De la compararea prețurilor și a cumpărăturilor online la verificarea stocului în timp real, la managerierea codului propriu bancar, WEB-ul este utilizat din ce în ce mai mult ca un mijloc de a realiza lucrurile uzuale. Personalizarea update-urilor zilnice și metodele de căutare sunt motivele principale care stau la baza generării dinamice ale paginilor WEB.

Pentru a genera un conținut dinamic serverele WEB trebuie să execute un program printr-un mecanism de script . Scriptul de obicei , se conectează la un sistem de gestiune al bazelor de date, execută un query, scoate rezultatele și le formatează în HTML pentru a se reântoarce la utilizator. Scrierea de cod pentru o bază de date WEB este similară cu orice alt proiect de implementare fără a exista diferențe notabile . Din acest motiv deși este necesar să pornim la lucru cu un design inițial, funcționalitatea întregului sistem poate sta în joc , cel mai probabil vor exista mai multe revizii până la sfârșitul proiectului.

Relevanța conceptului de baze de date în legătură cu problema manevrabilității, este acela că aceste informații au dus la un volum mare de cercetări adresat acestor probleme.

Nu putem afirma faptul că tehnologia bazelor de date este mecanismul magic care va rezolva problemele de management ale informațiilor existente pe net, alte tehnologii cum ar fi Inteligența Artificială și Hypertext/Hypermedia sunt la fel de importante.

Modelul structural pentru aplicație Web definește conținutul datelor structurate care sunt folosite de aplicație. Ar trebui să fie independente de modelul logic și fizic folosit pentru stocarea datelor, cum ar putea fi multiplele sisteme de gestiune a bazelor de date.

Datele structurate ar trebui să conțină o schemă conceptuală care să descrie conținutul informațional al resurselor de date indiferent de structura lor de stocare. Modelul conceptual reprezintă mai buna descriere a conținutului informațional a Web-ului, acest tip de înțelegere poate să influențeze în bine procesele de: menținere, folosire, interoperabilitate cu sursele de date externe.

Modelul de date conceptual pentru Web ar trebui să fie specific cu adaptările modelelor conceptuale de date, cum sunt folosite deja în alte discipline cum ar fi design-ul bazei de date.

World-Wide Web-ul prezintă un acces transparent către documentele distribuite, folosind o arhitectură strictă client/server.

În timp ce majoritatea datelor publicate pe WEB sunt semi-structurate (HTML documente) sau nestructurate (fișiere text, imagini), WEB-ul oferă deasemenea accesul la date structurate pe centre (baze de date relationale). Motivul pentru care WEB-ul „nu este prietenos cu bazele de date” este acela că a fost dezvoltat pentru lucru deschis cu sursele de date. Protocoalele web și motoarele de căutare au fost dezvoltate pentru a ușura lucrul, cât și căutarea în mediul respectiv. Este foarte important de menționat faptul că mecanismul de interogare a informațiilor și mecanismele de căutare nu pot fi aplicate din cauza diferențelor datorate naturii lor și a presupunerilor fundamentale asupra datelor. Pentru a vorbi de problemele de scalabilitate și a limbajului suport pentru bazele de date de tip WEB, trebuie să vorbim de un sistem care poate să descrie , să localizeze și să acceseze datele din cadrul unor baze de date accesibile pe internet. Ideea principală este aceea de a încorpora un acces simplu către bazele de date accesbile pe WEB ca și suportul pentru scalabilitate și extensibilitate într-o arhitectură flexibilă cu accesul la informații în masă.

Pentru a reduce timpul de acces la informațiile de pe rețea informații existente în cadrul bazelor de date, spațiul dedicat lor este organizat pe tipuri de informații. Fiecare grup de informații formează o coaliție de reprezentare a domeniului respectiv (o partiție a spațiului informațional) a sursei de informații aflată în legătură. De asemenea se asigură tehnologia necesară pentru formularea de query-uri pentru o zonă specifică de interes.

Elementul cheie care reprezintă o provocare în scrierea de aplicații web care accesează un sistem de gestiune al bazelor de date este acela de a înțelege atât limbajul HTML cât și cel SQL . În formele lor simple limbajele SQL și HTML pot fi ușor de întrebuințat, ele putând fi foarte complexe și tendențioase în scrierea în ordinea în care se utilizează, a funcțiilor avansate. Din fericire există editoare de text HTML și SQL, aceste instrumente putând ajuta la reducerea complexității atunci când generăm un cod HTML și SQL. De când am dorit ca dezvoltatorii de aplicații să poată continua să utilizeze limbajele existente HTML și SQL și a instrumentelor de dezvoltare de tip SQL, am realizat un macro limbaj simplu care include direct atât secțiuni din cod HTML și SQL ce îmbină aceste limbaje împreună printr-un mecanism substanțial de variabile cu un limbaj de încrucișare.

Atunci când dezvoltăm o multitudine de aplicații cheia stă în partiționare care este o diviziune a muncii între client pe de o parte și a serverului de aplicații pe de altă parte. Serverele de aplicație facilitează partiționarea permițând componentelor de aplicație să fie mutate la nivelul arhitectural și a platformei fizice unde pot să fie întrebuințate cel mai eficient. Un server de aplicație suportă definirea aplicațiilor logice , câteva servere au propriile instrumente de aplicație .

Având în vedere flexibilitatea sistemelor de gestiune a bazelor de date relaționale moderne este tentant să punem cantități semnificative de aplicații logice direct în cadrul bazei de date sub forma unor proceduri stocate. Cu excepția constrenturilor de integritate în general aceasta este o idee rea. Pentru majoritatea aplicațiilor , serverul de baze de date , memoria cât și spațiul de stocare sunt cele mai importante resurse. Noile servere de aplicații sunt îndreptate către componenta web.

În ceea ce privește principiile programării CGI (Common Gateway Interface) acestea rezidă din construirea unui document HTML corespunzător unei linii hypertext în același moment când dăm click pe acea linie. Documentul este trimis clientului și conținutul acestuia nu este stocat într-un fișier. Acest procedeu este efectuat pentru a ajuta linile de execuție.

Clientul indică numele fișierului, forma sa de URL, nu pentru a primi conținutul, pentru a cere execuția sa pe server. Următorul execută programul indicat (scriptul respectiv) și se reintoarce la client la ieșirea standard din program (înafara de rezultatul obținut pe ecran în program la cel puțin o linie de comandă, este alcatuită dintr-un cod HTML și din textul afișat). Acesata este ieșirea standard care alcătuiește un document HTML. Programele lansate pornind de la liniile de cod executate sunt apelete prin intermediul scripturilor CGI. Rezultatul care va fi afișat navigatorului nu va conține indicatoare de tip HTML.

Toate limbajele capabile să dețină o iesire standard pot fi utilizate pentru a scrie scripturi CGI. Intr-un madiu Unix vom putea utiliza limbaje ca C, Perl, Fortran. În mediile de tip Windows vom utilize Visual Bazic, Visual C++, etc.

Proasta utilizare a acestor norme de programare CGI scrise rău pot să reprezinte un pericol pentru securitatea site-ului.

Utilizand un sript CGI pentru a executa cerințe (programe în limbaj SQL) în comparațive cu o bază de domenii, cere multe resurse de sistem , fiecare cerință provoacă la nivel de server HTTP un apel către un program extern.

SGBD-urile sunt lansate printr-o comandă CGI primită de la serverul Web. Cererea CGI lansează un program specific de recuperare a adresei din crere, care conțin toate inforamațiile despre cerere și interoghează baza de date. Rezultatul cererii este recuperarea și fuzionarea cu o pagina HTML specifică. Produsul acestei fuzionări este comunicat unui server web care ține drept client. Acest lucru se remarcă prin dezvoltarea de pagini HTML în care programatorul insereaza comenzi specifice destinate interogării SGBD-urilor. În general există două tipuri de comenzi: una destinată specificațiilor cererii SOL, cealaltă specifică formatării rezultatelor. Aceste comenzi pot forma câteodată un minilimbaj de programare care permite tratamente complexe și elaborarea de pagini rezultat.

Singura soluție pentru a publica domeniile non HTML pe Web sunt scrierea scripturilor CGI. Când un server HTTP primește o comandă CGI el creează un nou process și lansează programul indicat de URL-ul respectiv. Parametrii care sunt prezentați în cadrul URL-ului sunt comunicați programului prin intermediul variabilelor de mediu și a intrărilor standard .

CGI prezintă un număr mare de inconveniente . Fiecare cerere CGI crează un nou process pe server .Dacă multe cereri sunt tratate simultan întregul program este executat de mai multe ori în diferite contexte, deasemenea resursele disponibile serverului se diminueaza și odată cu ele și performanțele.

O prezentare a modului cum un client interacționează cu un server web este prezentat în figura nr. 4.1.

Fig nr. 4.1 Baze de date web

Sursa : Inițil aceastăfotografie a fost publicată în Jurnal Internet Professionnel , nr 9 , mai 1997.

În afara de interacțiunea simplă mai putem putem prezenta un caz de interacține a unu client cu un server web care foloșește scripturi CGI , aspect preyentat în figura 4.2.

Fig nr 4.2 Baze de date ce folosesc scripturi CGI

Definiția unei platforme de tip server-web s-a schimbat dramatic în ultimul timp .Multe afaceri așteaptă să crească comerțul electronic în raport cu procentajul de vânzări din cadrul firmei respective. De exemplu JOHN Chambers, CEO, of Cisco Sistem afirmă faptul că , comerțul electronic al companiei sale cât și sistemul de intranet pe care îl deține această companie, duce la o economie de resurse care în bani se poate exprima la circa 250 mil dolari în fiecare an. Site-ul lor web realizează aproximativ 40% din vânzări din cadrul acetei firme. Această creștere este facilitată de o varietate de standarde cum ar fi : HTTP și JAVA. Aceste standarde sunt implementate în cadrul serverelor și se manifestă ca un punct de reper pentru implementarea de noi instrumente și tehnologii.

Concluzii

Ceea ce am remarcat adesea în cadrul lucrului efectuat pentru acesată lucrare este faptul că la ora actuală, pe piață există mai multe tipuri de baze de date. Folosirea unui anumit tip de SGBD diferă de la o firmă la alta, în funcție de nevoile interne și specificul fiecăreia. Nu există un model ideal de baze de date care să se plieze cu un procent maxim de 100% pe toate tipurile de afaceri de aici și nevoia de a folosi și implementa mai multe modele de SGBD-uri. Momentan cel mai folosit model de baze de date este modelul relațional, dar în practică se mai întalnesc implementate și alte modele cum ar fi cel obiectual, modelul rețea etc. Unii specialiști afirmau că modelul relațional nu este perfect și se remarcă în cadrul lui mai multe impedimente în ceea ce privește implementarea. Aceste impedimente sunt datorate în mare parte reguleleor care stau la baza acestui model. Cu privire la modelul obiectual acesta scapă de problemele care se ivesc la modelul relațional datorită conceptului nou pe care îl conține și anume persistența. Trebuie să specificăm faptul că in practică mai ușor este de implementat modelul de baze de date teleționale, care necesită resurse mai puțin pretențioase față de modelul de baze ed dete orientat pe obiecte. Trebuie să remarcam faptul că piața actuală, la noi în țară, este în decurs de dezvoltare, iar dacă investițiile în afaceri vor crește în urmatorii ani pot aparea creșteri în ceea ce privește utilizarea pe scară din ce în ce mai largă și a altor modele decat cel relațional. Desigur aceste tipuri de modele vor fi în continuare dependente de mărimea și necesitățile firmelor care le vor implementa.

ANEXA 1

create table persoane(

cnp number(13)

constraint pk_persoane primary key

constraint nn_persoane_cnp not null

,numepren varchar(60)

constraint nn_persoane_numepren not null

constraint ck_persoane_numepren check

(numepren=ltrim(initcap(numepren)))

,adresa varchar(40)

constraint nn_persoane_adresa not null

,datanastere date

,profesie varchar(30)

,nivelstudiu varchar(20)

,locmunca varchar(20)

,telfix number(10)

,telmobil number(10)

,email varchar(40)

);

create table permis(

nrpermisintrare number(6)

constraint pk_permis primary key

constraint nn_permis_nrpermisintrare not null

,datainscrierii date default sysdate

constraint nn_permis_datainscrierii not null

,termenvalabilitate number(2)

constraint nn_permis_termenvalabilitate not null

,stare number(1)

constraint nn_permis_stare not null

constraint ck_permis_stare check

(stare=0 or stare=1)

,nivelacces number(1)

constraint nn_permis_nivelacces not null

constraint ck_permis_nivelacces check

(nivelacces between 0 and 2)

,cnp number(13)

constraint nn_permis_cnp not null

constraint fk_permis_persoane references persoane(cnp)

);

–nivelacces 0-sala de lectura 1-acasa 2-general

–stare 0-blocat 1-activ

create table blocaj(

nrpermisintrare number(6)

constraint nn_blocaj_nrpermisintrare not null

constraint fk_blocaj_permis references permis(nrpermisintrare)

,idbloc number(6)

constraint nn_blocaj_idbloc not null

,nrzilebloc number(3)

constraint ck_blocat_nrzile check

(nrzilebloc>=0 and nrzilebloc<=365)

,motiv varchar(60)

,databloc date default sysdate

,constraint pk_blocaj primary key(nrpermisintrare,idbloc)

);

create table imprumuturi(

idimprumut number(8)

constraint pk_imprumuturi primary key

constraint nn_imprumuturi_idimprumut not null

,tipimprumut number(1)

constraint nn_imprumuturi_tipimprumut not null

constraint ck_imprumuturi_tipimprumut check

(tipimprumut between 0 and 2)

,dataimprumut date default sysdate

constraint nn_imprumuturi_dataimprumut not null

,nrcartiimp number(1)

constraint ck_imprumuturi_nrcartiimp check

(nrcartiimp between 0 and 4)

,nrcdimp number(1)

constraint ck_imprumuturi_nrcdimp check

(nrcdimp between 0 and 4)

,nrpermisintrare number(6)

constraint nn_imprumuturi_nrpermisintrare not null

constraint fk_imprumuturi_permis references permis(nrpermisintrare)

);

create table editura(

ideditura number(6)

constraint pk_editura primary key

constraint nn_editura_ideditura not null

,deneditura varchar(20)

constraint ck_editura_deneditura check

(deneditura=ltrim(initcap(deneditura)))

,anfab number(4)

);

create table titluri(

isbn varchar(13)

constraint pk_titluri primary key

constraint nn_titluri_isbn not null

,dencarte varchar(40)

constraint nn_titluri_dencarte not null

constraint ck_titluri_dencarte check

(dencarte=ltrim(initcap(dencarte)))

,nrexemplare number(2)

constraint ck_titluri_nrexemplare check (nrexemplare > 0)

,nrexempdisp number(2)

constraint ck_titluri_nrexempdisp check (nrexempdisp >= 0)

,nrvolume number(2)

constraint ck_titluri_nrvolume check (nrvolume>0)

,accesibilitate number(1)

constraint ck_titluri_accesibilitate check

(accesibilitate between 0 and 2)

,nrpag number(5)

,anscriere number(4)

,termenimpcarte number(2)

constraint ck_titluri_termenimpcarte check

(termenimpcarte=20 or termenimpcarte=30)

,ideditura number(6)

constraint nn_titluri_ideditura not null

constraint fk_titluri_editura references editura(ideditura)

);

create table exemplare(

cotacarte varchar(20)

constraint pk_exemplare primary key

constraint nn_exemplare_cotacarte not null

,starecarte varchar(12)

constraint ck_exemplare_starecarte check

(starecarte in ('disponibila','imprumutata'))

,isbn varchar(13)

constraint nn_exemplare_isbn not null

constraint fk_exemplare_titluri references titluri(isbn)

);

create table autori(

isbn varchar(13)

constraint nn_autori_isbn not null

constraint fk_autori_titluri references titluri(isbn)

,ordinecoperta number(2)

constraint nn_autori_ordinecoperta not null

,autor varchar(40)

constraint ck_autori_autor check

(autor=ltrim(initcap(autor)))

,constraint pk_autori primary key (isbn,ordinecoperta)

);

create table cd(

cotacd varchar(20)

constraint pk_cd primary key

constraint nn_cd_cotacd not null

,dencd varchar(40)

constraint nn_cd_dencd not null

constraint ck_cd_dencd check

(dencd=ltrim(initcap(dencd)))

,tipcontinutcd varchar(20)

,capacitate number(4) default 700

,autorcd varchar(40)

constraint ck_cd_autorcd check

(autorcd=ltrim(initcap(autorcd)))

,anfabcd number(4)

,termenimpcd number(1)

constraint ck_cd_termenimpcd check

(termenimpcd=5 or termenimpcd=7)

);

create table harti(

cotaharta varchar(20)

constraint pk_harti primary key

constraint nn_harti_cotaharta not null

,denharta varchar(40)

,anharta number(4)

,anfabharta number(4)

,dimharta varchar(11)

);

create table documente(

cotadoc varchar(20)

constraint pk_documente primary key

constraint nn_documente_cotadoc not null

,dendoc varchar(40)

,andoc number(4)

,nrpagdoc number(5)

);

create table ziare(

cotaziar varchar(20)

constraint pk_ziare primary key

constraint nn_ziare_cotaziar not null

,denziar varchar(40)

,ideditura number(6)

constraint fk_ziare_editura references editura(ideditura)

constraint nn_ziare_ideditura not null

);

create table returnarecarti(

cotacarte varchar(20)

constraint fk_returnarecarti_exemplare references exemplare(cotacarte)

constraint nn_returnarecarti_cotacarte not null

,idimprumut number(8)

constraint fk_returnarecarti_imprumuturi references imprumuturi(idimprumut)

constraint nn_returnarecarti_idimprumut not null

,datareturnare date default sysdate+20

constraint nn_returnarecarti_dataret not null

,dataretefectiva date

,starereturnare varchar(11)

constraint ck_returnarecarti_stareret check

(starereturnare in('uzata','pierduta','ok'))

,observatii varchar(20)

,penalizari varchar(20)

,constraint pk_returnarecarti primary key(cotacarte,idimprumut)

);

create table returnarecd(

cotacd varchar(20)

constraint fk_returnarecd_cd references cd(cotacd)

constraint nn_returnarecd_cotacd not null

,idimprumut number(8)

constraint fk_returnarecd_imprumuturi references imprumuturi(idimprumut)

constraint nn_returnarecd_idimprumut not null

,datareturnare date default sysdate+5

constraint nn_returnarecd_datareturnare not null

,dataretefectiva date

,starereturnare varchar(11)

constraint ck_returnarecd_starereturnare check

(starereturnare in('uzata','pierduta','ok'))

,observatii varchar(20)

,penalizari varchar(20)

,constraint pk_returnarecd primary key(cotacd,idimprumut)

);

create table returnareharti(

cotaharta varchar(20)

constraint fk_returnareharti_harti references harti(cotaharta)

constraint nn_returnareharta_cotaharta not null

,idimprumut number(8)

constraint fk_returnareharta_imprumuturi references imprumuturi(idimprumut)

constraint nn_returnareharta_idimprumut not null

,datareturnare date default sysdate

constraint nn_returnareharta_dataret not null

,dataretefectiva date

,starereturnare varchar(11)

constraint ck_returnareharta_stareret check

(starereturnare in('uzata','pierduta','ok'))

,observatii varchar(20)

,penalizari varchar(20)

,constraint pk_returnareharti primary key(cotaharta,idimprumut)

);

create table returnaredoc(

cotadoc varchar(20)

constraint fk_returnaredoc_documente references documente(cotadoc)

constraint nn_returnaredoc_cotadoc not null

,idimprumut number(8)

constraint fk_returnaredoc_imprumuturi references imprumuturi(idimprumut)

constraint nn_returnaredoc_idimprumut not null

,datareturnare date default sysdate

constraint nn_returnaredoc_datareturnare not null

,dataretefectiva date

,starereturnare varchar(11)

constraint ck_returnaredoc_starereturnare check

(starereturnare in('uzata','pierduta','ok'))

,observatii varchar(20)

,penalizari varchar(20)

,constraint pk_returnaredoc primary key(cotadoc,idimprumut)

);

create table returnareziare(

cotaziar varchar(20)

constraint fk_returnareziare_ziare references ziare(cotaziar)

constraint nn_returnareziare_cotaziar not null

,idimprumut number(8)

constraint fk_returnareziare_imprumuturi references imprumuturi(idimprumut)

constraint nn_returnareziare_idimprumut not null

,datareturnare date default sysdate

constraint nn_returnareziare_dataret not null

,dataretefectiva date

,starereturnare varchar(11)

constraint ck_returnarezaire_stareret check

(starereturnare in('uzata','pierduta','ok'))

,observatii varchar(20)

,penalizari varchar(20)

,constraint pk_returnareziare primary key(cotaziar,idimprumut)

);

create table cuvintecheie(

cc varchar(40)

constraint pk_cuvintecheie primary key

constraint nn_cuvintecheie_cc not null

);

create table titluricc(

isbn varchar(13)

constraint nn_titluricc_isbn not null

constraint fk_titluricc_autori references titluri(isbn)

,cuvantcheie varchar(40)

constraint nn_titluricc_cuvantcheie not null

constraint fk_titluricc_cuvintecheie references cuvintecheie(cc)

,relevanta number(2)

,constraint pk_titluricc primary key (isbn,cuvantcheie)

);

create table cdcc(

cotacd varchar(20)

constraint nn_cdcc_cotacd not null

constraint fk_cdcc_cd references cd(cotacd)

,cuvantcheie varchar(40)

constraint nn_cdcc_cuvantcheie not null

constraint fk_cdcc_cuvintecheie references cuvintecheie(cc)

,relevanta number(2)

,constraint pk_cdcc primary key (cotacd,cuvantcheie)

);

create table harticc(

cotaharta varchar(20)

constraint nn_hartacc_cotaharta not null

constraint fk_hartacc_harti references harti(cotaharta)

,cuvantcheie varchar(40)

constraint nn_hartacc_cuvantcheie not null

constraint fk_hartacc_cuvintecheie references cuvintecheie(cc)

,relevanta number(2)

,constraint pk_hartacc primary key (cotaharta,cuvantcheie)

);

create table doccc(

cotadoc varchar(20)

constraint nn_doccc_cotadoc not null

constraint fk_doccc_documente references documente(cotadoc)

,cuvantcheie varchar(40)

constraint nn_doccc_cuvantcheie not null

constraint fk_doccc_cuvintecheie references cuvintecheie(cc)

,relevanta number(2)

,constraint pk_doccc primary key (cotadoc,cuvantcheie)

);

create table ziarecc(

cotaziar varchar(20)

constraint nn_ziarecc_cotaziar not null

constraint fk_ziarecc_ziare references ziare(cotaziar)

,cuvantcheie varchar(40)

constraint nn_zairecc_cuvantcheie not null

constraint fk_ziarecc_cuvintecheie references cuvintecheie(cc)

,relevanta number(2)

,constraint pk_ziarecc primary key (cotaziar,cuvantcheie)

);

create table incluziuni(

idincluziune number(6)

constraint pk_incluziuni primary key

constraint nn_incluziuni_idincluziune not null

,cccopil varchar(40)

constraint nn_incluziuni_cccopil not null

constraint fk_incluziuni_cccopil references cuvintecheie(cc)

,ccparinte varchar(40)

constraint nn_incluziuni_ccparinte not null

constraint fk_incluziuni_ccparinte references cuvintecheie(cc)

);

create table echivalente(

idechivalenta number(6)

constraint pk_echivalente primary key

constraint nn_echivalente_idechivalenta not null

,cc1 varchar(40)

constraint nn_echivalente_cc1 not null

constraint fk_echivalente_cuvintecheie references cuvintecheie(cc)

,cc2 varchar(40)

constraint nn_echivalente_cc2 not null

constraint fk_echivalente_cuvintech references cuvintecheie(cc)

);

create table imprumuturi_arhiva(

idimprumut number(8)

constraint nn_imprumuturia_idimprumut not null

,tipimprumut varchar(15)

constraint nn_imprumuturia_tipimprumut not null

constraint ck_imprumuturia_tipimprumut check

(tipimprumut in ('sala de lectura','acasa'))

,dataimprumut date default sysdate

constraint nn_imprumuturia_dataimprumut not null

,nrcartiimp number(1)

constraint ck_imprumuturia_nrcartiimp check

(nrcartiimp between 0 and 4)

,nrcdimp number(1)

constraint ck_imprumuturia_nrcdimp check

(nrcdimp between 0 and 4)

,nrpermisintrare number(6)

constraint nn_imprumuturia_nrp not null

constraint fk_imprumuturia_permis references permis(nrpermisintrare)

,dataarhivare date default sysdate

constraint nn_imprumuturi_arhiva not null

,constraint pk_imprumuturi_arhiva primary key(idimprumut,dataarhivare)

);

Bibliografie

Cărți: 1. Codd, E. F. "A relational model of data for large shared data banks".

Communications of the ACM,vol. 13, nr.6, (1970), pp. 377–387;

2. Date, C. J., Darwen, H , Foundation for Future Database Systems: The Third

Manifesto, 2nd edition, Adisson-Wesly. (2000).pp.69-78;

3. Date, C. J. ,Introduction to Database Systems. 8th edition, Addison-Wesley,

(2003);

4. Robert Dollinger –Baze de Date și Gestiunea Tranzacțiilor ,Editura

Albastră, 1998, p 12;

5. Maria Filip, Luminița Fînaru, Dinu Airinei , Ana Grama , Florin

Dumitriu , Marin Fotache , Alexandru Țugui – Medii de Programare ,

Editura Sedcom Libris, Iași , 2003, pp.169-170;

6. Marin Fotache – SQL Dialectele DB2 Oracle Visual FoxPro, Editura

Polirom, 2001, pp. 11-16;

7. [Pascu&Pascu94],pp.22-27.Vezi și[Lungu s.a 95],pp.133-135;

8. Arthur M. Keller ,Paul Turner , Persistence Software , Migrating to Object

Data Management, Standford University,Pacific Grove, CA. September 1986,

pp 2-6;

9. [Date86],p.89;

10. Ion Lungu , Constanța Bodea, Georgeta Bădescu,Cristina Ioniță- Baze de

Date Organizare , Proiectare și Implementare, All Educational , pp.124-125;

11. Felicia Ionescu- Baze de date relaționale și aplicații, Editura Tehnică ,

2004, pp.105-109;

12. Akmal B.Caudhri,Roberto Zicari -Succeeding with Object Database A

Practical Look at Today’s Implementation with Java and XML, Wiley

Computer Publishing JohnWiley & Sons, pp.176-178;

13. Preluat din : Ion Lungu , Constanța Bodea, Georgeta Bădescu,Cristina

Ioniță- Baze de Date Organizare , Proiectare și Implementare, All

Educational , pp.228-229;

14. Grupul BDASEIG-Baze de Date Fundamente Teoretice și

Practice,Editura Infomega,2002,p 42;

15.Iamad Saleh , Fabrice Papy, Les Bases de donnes pour l’internet et

l’intranet, Editura Hermas Science Publication , an 1999, pp.65-70 ;

Dumitru Oprea, Gabriela Meșniță , F.Dumitriu, Analiza sistemelor

informationale , Editura Al.I.Cuya , an 2006 pp.230-296

Reviste: 1.Pc World România ,iunie 1993, pp. 33-34;

Articole : 1. Beech,D.-“New Life for SQL ”, Datamotion , 1 februarie 1989;

2. Mansour Zand ,Val Collins , Dale Caviness , University of Nebraska

and Omaha , A Survey of Current Object –Oriented Databases . ACM

DATA BASE , February 1995, Vol. 26 , Nr. 1 ,p 14;

3. Malcom P. Atkinson, O. Peter Buneman, Types and Persistance in

Database Programming Languages , Glasgow University,Pennsilvania

University, ACM Computing Surveys , Vol. 19, Nr. 2,Iunie 1987 pp.

181-182;

4. Shailesh Agarwal, Christopher Keene , Arthur M.Keller , Architecting

Object for High Performance with Relational Database , Stanford

University, pp. 3-5;

5.Peter Heinckiens , Ghislain Hoffman, Object persistence : the

application programmer’s perspective, Ghent University, pp1-3 ;

6.Preluat din : Won Kim Reserch Directions in Object –Oriented

Database Systems , West Balcones Center Drive Austin ,

Texas,pp 10-11;

7. Bart Meltzer , Robert Glushko, XML and Electronic Commerce:

Enabling the Network Economy, SIGMOND Record ,decembrie 1998,

Vol 27, Nr. 4, pag 21-24;

8. Ralf Kramer , Database on the WEB: Tehnologies for Federation

Architectures and Case Studies , Germany , pp. 503-506 ;

9. Alexandros Labrinidis , Nick Roussopoulos , Generating dynamic

content at database-backed web servers: cgi-bin vs mod-perl,

Maryland University, Colledge Park , SIGMOND Records, martie

2000 , Vol . 29, Nr.1, pp.26-30;

10. Daniela Florescu, Alon Levy , Alberto Mendelzon , Database

Techniqus for the World-Whide Web : A Survey, SIGMOND

Record, Septembrie 1998 , Vol 27, Nr. 3, pp 59-61;

11. Stefano Ceri , Piero Fraternali , Stefano Parabolschi , Design

Principles for Data-Intensive Web Sites, SIGMON Record , martie

1999,Vol 28, Nr 1, pp. 84-88;

12. Athman Bouguettaya , Boualem Benatallah , Lily Hendra, James

Beard , Kevin Smith , Mourad Ouzzani , World Whide Database-

Integrating the Web , CORBA and Database, Queensland University

of Technology, SIGMOD Record , pp.594-596;

13. Jurnal Internet Professionnel , nr 9 , mai 1997.

Site-uri Web: 1. http://en.wikipedia.org/wiki/Relational_model;

2. http://www.profc.udec.cl/~gabriel/tutoriales/giswb/vol1/cp4/4-3.gif;

3. http://unixspace.com/context/databases.html;

4. http://infolab.stanford.edu/pub/Keller/1995/high-perf.ps;

5. http://infolab.stanford edu/pub/Peter /2001/high-perf.ps,

6. http://www.fzi.de/kramer.html.