CAPITOLUL 1

BAZE DE DATE ŞI SISTEME DE GESTIUNE A BAZELOR DE DATE
1.1. COLEC II DE DATE Dic ionarul explicativ al limbii române precizează că no iunea aferentă termenului de dată poate avea atât semnifica ie temporală, cât şi semnifica ie referitoare la „fiecare din numerele, mărimile, rela iile etc. care servesc pntru rezolvarea unei probleme sau care sunt ob inute în urma unei cercetări şi urmează să fie supuse unei prelucrări”. Un ansamblu de date înrudite pot configura o informa ie complexă. Datele de acelaşi tip sau aceeaşi structură informa ională pot fi clasificate în fişe şi/sau tabele şi pot fi prelucrate ulterior. De-a lungul timpurilor, eviden ele datelor au găsit felurite suporturi de stocare, de la memorarea mintală, răbojul de lemn, suporturi de piele sau papirus, registre de hârtie, suportul magnetic al dischetei etc. Data poate fi asimilată în bună măsură cu cuanta de informa ie. Ea poate fi concomitent obiect de prelucrare, sursă de fundamentare a modelelor şi proceselor, mijloc de tezaurizare informa ională. Pe de-o parte, datele pot fi generatoare de informa ii, pe de altă parte, au proprietă i care permit procesarea, rafinarea acestora ca sursă de noi informa ii. Indiferent de domeniul vie ii sociale abordate, datele concură la luarea deciziilor. 1.2. SISTEME DE FIŞIERE - SISTEME DE GESTIUNE A BAZELOR DE DATE Anii ’60 şi lupta pentru suprema ia spa ială a impus introducerea unor standarde de eviden e a datelor a căror destina ie ini ială au fost misiunile Apolo. Volumul enorm de date trebuia actualizat aproape continuu şi astfel s-au conturat concepte aferente sistemelor de gestiune a bazelor de date, prescurtat SGBD. Sistemele bazate pe fişiere presupun că fiecărui fişier i se alocă un nume specific, în care se introduc date de acelaşi tip, cum ar fi de exemplu: situa ia facturilor furnizor (un singur furnizor sau diferi i), situa ia stocurilor din magaziile specializate sau din magazia centrală, situa ia clien ilor etc. Fiecare fişier este stocat şi poate fi modificat de unul sau mai mul i utilizatori (mai mult sau mai pu in autoriza i) putând apărea dublări de fişiere rezultate după fiecare nouă prelucrare, dublări de date etc. Dacă, însă, re eaua centrală la care sunt cuplate terminalele a fost dezvoltată pe parcurs există şi cazul în care unele aplica ii software să nu fie compatibile între ele şi, deja, problema se complică în sensul că prin incompatibilitate prelucrarea unor informa ii poate fi complet suprimată. Fără îndoială că sistemele bazate pe fişiere prezintă avantaje de lucru atunci când sunt monitorizate de un număr limitat de utilizatori: - nu este necesară prelucrarea a două sau mai multe fişiere de date aferente unor activită i diferite, dar înrudite în unele limite (ex:intrări de marfă/ieşiri de marfă); - nu este necesară conlucrarea în re ea sau lucrul în simultan pe acelaşi fişier în loca ii diferite ale re elei etc.
1

Defini ia generală a bazelor de date este dată de Thomas Connolly [1]: Bazele de date sunt o colec ia partajată de date, între care există rela ii logice (şi o descriere a acestor date), proiectată pentru a satisface nacasită ile informa ionale ale unei organiza ii sau ale unui grup. Există însă o diferen ă între date şi informa ii, bine sesizată de Robert Dollinger [8] astfel: „Datele sunt fapte culese din lumea reală pe bază de observa ii şi măsurători. Informa ia este rezultatul interpretării datelor de către un anumit subiect şi conferă acestuia capacitatea de a lua decizii”. În func ie de gradul de detaliere, datele pot fi: - date elementare; - date compuse. Astfel, datele elementare sunt entită i indivizibile, cuante de informa ie, atât la nivel informa ional, cât şi la nivel de prelucrare. Datele compuse sunt mul imi de date elementare, care ajută la caracterizarea entită ilor (ansamblelor) informa ionale şi care pot fi descompuse în date elementare. Prelucrarea datelor se poate realiza atât la nivelul datelor elementare, cât şi la nivelul datelor compuse. Colec iile de date sunt mul imi de date ce privesc, deci, un domeniu, un proces, o activitate sau un obiect. Sub aspect informatizat ele sunt organizate şi dispuse sistematizat pe un suport de memorie externă. Sub aspectul evolu iei categoriilor de receptare şi memorare informatizată a datelor, Robert Dollinger [8] identifică patru etape distincte de abordare a acestora. Prima etapă este aferentă trecerii de la sistemele de prelucrare manuală la computer. Principalul tip de organizare a datelor este fişierul. Sistemul bazat pe fişiere (Figura 1.1.) reprezintă o colec ie de programe-aplica ie, care efectuează servicii pentru utilizatorii finali, cum ar fi producerea de rapoarte. Fiecare program defineşte şi gestionează propriile date. Un fişier este un set de înregistrări care con in date între care există rela ii logice. Dacă informa ia este stocată în diverse loca ii spre prelucrare, datele pot fi dublate, triplate, iar multiplicarea datelor va fi existentă în fişiere, care, cel mai probabil nu vor fi actualizate periodic. Accesul la o înregistrare dintr-un fişier se face pe principiul accesului secven ial sau prin acces direct, pe baza unei chei de identificare şi de localizare rapidă a înregistrării, pe baza indexării fişierelor. Acest tip de organizare a datelor este caracteristic aplica iilor realizate cu limbaje de programare (Fortran, Pascal, Basic etc.). Dezavantajele rezultate din organizarea datelor în fişiere sunt următoarele: - Redundan ă ridicată (stocarea aceloraşi date în mai multe fişiere); - Dificultă i de acces la date, întrucât aceleaşi date sunt exploatate de mai mul i utilizatori simultan şi în paralel, ceea ce necesită ulterior opera ii suplimentare de sortare, fuziune, ventilare, conciliere etc.; - Izolarea datelor, întrucât nu pot fi scrise aplica ii executabile care să acceseze datele într-o manieră globală; - Actualizarea datelor prin adăugare, modificare, ştergere, care creează conflicte când mai mul i utilizatori doresc să modifice simultan aceleaşi date;
2

Dependen a programelor fa ă de date; Greutatea de a ob ine răspunsuri rapide (on-line) la probleme neprevăzute; Fiecare dată este descrisă independent în toate fişierele în care apare. Dacă, însă, într-un fişier se modifică formatul şi valoarea unei date, modificarea nu se transmite automat ulterior în toate fişierele, astfel că pentru aceeaşi dată pot s apară valori diferite în fişiere diferite, ceea ce este cunoscut sub denumirea de inconsisten ă a datelor. Dacă fişierul este realizat în limbaje diferite, există riscul incompatibilită ii datelor, respectiv nu este posibilă men inerea integrită ii datelor. Deci, toate limitările tratării bazate pe fişiere se bazează pe următorii factori: a) defini ia datelor este incorporată în programele aplica ie, în loc să fie stocată separat şi independent; b) nu există un control al accesului şi manipulării datelor, dincolo de cel impus de către programele aplica ie. A doua etapă se caracterizează prin separarea dintre structura logică de date şi structura fizică. Dacă în prima etapă datele memorate pe benzi magnetice, iar structura datelor servea, de regulă, o singură aplica ie, în această nouă etapă apar noi forme de stocare a datelor (discul magnetic, banda magnetică etc.), ceea ce a creat probleme de compatibilizare, atât hardware, cât şi software, cu alte cuvinte exista riscul alterării datelor şi structurilor de date atât fizic, cât şi logic. Etapa a treia este definită de apari ia fişierelor integrate, prin care datele sunt legate logic între ele, chiar dacă datele fizice sunt rezidente pe diverse sisteme. Această etapă constituie un prim pas spre compatibilizarea accesului la date atât logic, cât şi fizic, ceea ce a constituit nucleul de bază în definirea datelor şi a legăturilor dintre ele, ca sistem paralel de aplica iile sub care rulează acestea. Etapa a patra este etapa bazelor de date propriu-zise şi a dezvoltării sistemelor de gestiune a bazelor de date. Această etapă va fi de fapt subiectul acestei lucrări. Thomas Connolly [1] defineşte baza de date ca fiind „colec ie partajată de date, între care există rela ii logice (şi o descriere a acestor date), proiectată pentru a satisface necesită ile informa ionale ale unei organiza ii”. Noi credem că bazele de date constituie o colec ie de date structurată logic care serveşte ca sursă informa ională unei comunită i ce poate fi închisă sau deschisă. Prin această defini ie răspundem atât domeniilor organiza ionale pentru care INTERNET-ul răspunde no iunii de colectivitate închisă, însă circuitul informa ional de acest tip poate fi extins şi către sfera ştiin ifică, atunci când se pune problema dezvoltării de baze de date achizi ionate din felurite experimente puse în comun pentru o comunitate mai restrânsă sau mai largă de specialişti, cum ar fi spre exemplu cei din domeniul fizicii nucleare. Comunită ile deschise sunt o categorie tipică utilizatorilor constan i ai INTERNET-ului. Pentru aceştia, poate, este mai pu in importantă decizia cât mai curând nevoia de informare pe un domeniu sau altul. Decizia adeseori se rezumă la simpla alegere a unui site pe care este găzduită o bază de date.

-

3

1.3. ARHITECTURA SISTEMELOR DE GESTIUNE A BAZELOR DE DATE

Principala opera ie dintr-o aplica ie de baze de date este cea de regăsire a datelor, deci de a răspunde la interogări. Într-o bază de date, de asemenea sunt frecvente opera iile următoare: - memorare; - ştergere; - actualizare. Evolu ia conceptuală a deceniului ultim a evoluat spre generalizare către arhitectura client-server, arhitectură care înglobează baza de date, sistemul sau sistemele de gestiune a bazelor de date şi sistemele de aplica ii. Independen a datelor reprezintă un concept fundamental în filosofia bazelor de date şi în administrarea lor. Ea este legată de modul de memorare şi de organizare a datelor şi în ce măsură este transparent şi inteligibil pentru utilizator. Două aspecte sunt principal importante în caracterizarea independen ei datelor, şi anume: 1. Independen a fizică a datelor, care presupune posibilitatea modificării schemei fizice a datelor fără ca aceasta să implice modificarea schemei conceptuale, a schemei logice şi a aplica iilor executabile. Astfel, o modificare a structurii fizice nu va afecta aplica ia şi reciproc, o modificare a aplica iei va lăsa nemodificată structura fizică a datelor; 2. Independen a logică a datelor, presupune că pot fi realizate modificări conceptuale ale datelor, fără ca prin aceasta să fie modificată schema logică sau a programelor de aplica ie. Cerin ele minimale impuse unei baze de date [10], sunt: - furnizarea în timp util a informa iilor solicitate; - asigurarea unor costuri minime în prelucrarea şi între inerea informa iei; - capacitatea de a satisface, cu aceleaşi date, necesită i informa ionale ale unui număr mare de utilizatori; - flexibilitate, în sensul de adaptare la interogări noi, neprevăzute ini ial; - minimizarea redundan ei datelor; - posibilitatea exploatării datelor de mai mul i utilizatori; - asigurarea securită ii datelor prin măsuri de protec ie pe diverse nivele a accesului neautorizat, denumit şi confiden ialitatea accesului; - capacitatea recuperării datelor ca urmare a unor manipulări eronate sau deteriorări accidentale (integritatea datelor); - posibilitatea utilizării eforturilor anterioare şi anticiparea nevoilor viitoare (compatibilitate şi expandabilitate). Avantajele datelor centralizate în baze de date sunt în principal următoarele: A. Reducerea redundan ei datelor; B. Evitarea inconsisten ei datelor prin actualizarea centralizată a întregii baze de date; C. Posibilitatea partajării datelor; D. Încurajarea introducerii standardelor de compatibilizare a bazelor de date cu aplica ii executabile;
4

E. Posibilitatea aplicării restric iilor de securitate pe mai multe nivele; F. Men inerea integrită ii datelor. Arhitectura bazelor de date este, principial, alcătuită din următoarele componente: - baza de date propriu-zisă; - sistemul de gestiune al bazei de date; - un dic ionar al bazei de date, care con ine informa ii despre: - date; - structura datelor; - statistici; - documenta ie; - componente hardware (comune sau specializate); - reglementări administrative destinate bunei func ionări a sistemului; - factorul uman autorizat în diverse limite (utilizatori, administrator, programatori, operatori). Sistemele de gestionare a bazelor de date (SGBD) reprezintă în viziunea lui Thomas Connolly [1] un sistem de programe care permit utilizatorului definirea, creerea şi între inerea bazei de date şi accesul controlat la aceasta. După al i autori [10], un sistem de gestiune a bazelor de date reprezintă un produs software capabil de a asigura interac iunea cu o bază de date, care să permită definirea, consultarea şi actualizarea datelor din baza de date.
1.4. CARACTERISTICILE ŞI OBIECTIVELE SGBD-URILOR

Caracteristicile principale ale Sistemelor de gestiune a datelor sunt următoarele componente: - limbajul de definire a datelor pe baza căruia pot fi specificate tipurile de date şi structurile dintre acestea; - limbajul de manipulare a datelor cu ajutorul căruia utilizatorii autoriza i pot să insereze, să actualizeze, să şteargă şi să extragă date din baza de date. Limbajul de manipulare a datelor poate realiza toate ac iunile de mai sus pe baza interogărilor, fiind deseori denumit şi limbaj de interogare. Limbajele de manipulare a datelor pot fi procedurale sau neprocedurale. Limbajele procedurale tratează bazele de date înregistrare-cu-înregistrare, în schimb limbajele neprocedurale operează asupra unor seturi de înregistrări; - limbaj pentru controlul şi securitatea datelor pe baza căruia se poate asigura men inerea confiden ialită ii şi integrită ii datelor fa ă de utilizatori neautoriza i. De asemenea, acest tip de limbaj poate, până în anumite limite, să salveze informa ii în cazul unor defec iuni etc. Obiectivele principale ale unui sistem de gestiune a bazelor de date sunt: - Independen a fizică legată de suporturile de memorare a datelor şi interac ia cu sistemul/sistemele de gestiune a bazelor de date, fără ca datele să fie alterate;

5

Independen a logică care permite ca un utilizator sau un grup de utilizatori autoriza i să-şi construiască noi entită i şi rela ii conversa ionale, fără ca prin aceasta ceilal i utilizatori să fie afecta i şi fără ca structura logică a datelor să fie alterată; - Manipularea datelor de către neinformaticieni prin punerea la dispozi ie a unui limbaj neprocedural şi a unei interfe e vizuale apropiată de limbajul natural; - Administrarea centralizată a datelor pentru a permite o organizare coerentă şi eficace a informa iei; - Neredundan a datelor. Organizarea nejudicioasă a datelor poate conduce la un grad mai mic sau mai mare de redundan ă a unor date. De asemenea, fiecare aplica ie care accesează baza de date poate conduce la redundare. Cu alte cuvinte, se acceptă un anumit grad de redundare şi este considerat normal. Peste acest grad, baza de date este neeficient exploatată şi incorect structurată. - Coeren a datelor, concept prin care informa ia trebuie să satisfacă simultan constrângeri statice, dinamice, locale sau generale. - Partajabilitatea datelor, prin care este posibil ca aplica iile să utilizeze datele din baza de date în timp şi simultan, fără a afecta aplica iile altor utilizatori, timp în care date din baza de date pot fi adăugate sau modificate. - Securitatea şi confiden ialitatea datelor, prin care datele trebuie protejate de acces neautorizat sau rău inten ionat. SGBD-ul trebuie să asigure securitatea fizică şi logică a informa iei şi să permită doar utilizatorilor autoriza i să efectueze opera ii asupra bazei de date. De regulă, un SGBD trebuie să includă minimal cinci clase de module: - programe de gestiune a bazei de date; - module pentru tratarea limbajului de definire a datelor; - module pentru tratarea limbajului de manipulare a datelor; - module utilitare; - module de control. Participan ii la alcătuirea, configurarea şi utilizarea bazelor de date sunt: a) administratorii de date – sunt responsabili de gestionarea resurselor de date, de planificarea, dezvoltarea şi între inerea standardelor, a politicilor şi a procedurilor bazei de date, precum şi de proiectarea logică a bazei de date. Rolul administratorului de date este de a consilia întreg sistemul uman participant la mediul de date astfel încât informa ia să asigure coeren ă şi suficientă complexitate în luarea deciziilor sau sub aspectul informării. b) Administratorii de baze de date – sunt responsabili cu realizarea fizică a bazei de date, respectiv proiectarea şi implementarea acesteia, securitatea şi controlul integrită ii, între inere şi atingere de performan e optime pentru aplica ii şi utilizatori. Dacă rolul administratorului de baze de date este de natură tehnică, rolul administratorului de date este de natură logică, de coeren ă a informa iei. Adeseori între cei doi administratori nu sunt diferen e vădit stabilite, fiind una şi aceeaşi persoană sau grup de implementare a mediului bazei de date. c) Proiectan ii de baze de date – care pot fi la rândul lor de alte două categorii: c1) proiectan i de baze de date logice – acesta trebuie să cunoască foarte bine necesită ile bazei de date, să fie capabil să identifice datele sub aspectul constrângerilor şi
6

-

rela iilor dintre acestea. Acesta trebuie să aibe temeinice cunoştin e asupra sursei datelor şi tipurilor principale de utilizare ale acestora, inclusiv a fluxurilor decizionale (acolo unde ele sunt specificate). Practic, proiectantul de baze de date logice va avea două obiective majore: - proiectarea conceptuală a bazei de date pentru a fi cât mai pu in sensibilă la sistemul de gestiune a bazei de date avut la dispozi ie, programele-aplica ie, limbajele de programare etc.; - orientarea spre un anume model de date (rela ional, re ea, ierarhic, orientat spre obiecte). c2) proiectan ii de baze de date fizice – au rolul de a prelua modelul logic şi de al transpune fizic prin: - configurarea setului de tabele şi constrângeri sub aspectul integrită ii datelor; - tipurile de suporturi de stocare şi metodele de acces la date; - măsurile aferente asigurării securită ii datelor. d) programatorii de aplica ii – preiau de la analiştii de sistem documenta ia necesară şi proiectează implementarea programelor de aplica ii inând seama de limitele sistemului de operare şi al resurselor acestuia, astfel încât, utilizatorii finali să aibă acces rapid la informa ie. De regulă programele de aplica ii sunt redactate într-un limbaj de programare [6]. e) Utilizatorii finali – pot fi: - utilizatori conversa ionali (nespecialişti), care interac ionează cu baza de date într-un mod apropiat cu conversa ia curentă. Se caracterizează prin aceea că nu cunosc structura bazei de date şi nici modul efectiv de lucru cu baza de date şi de regulă nici nu îi interesează decât aspectul pur informativ pe care îl poate oferi baza de date şi posibilitatea prelucrării acestora fie pentru luarea unor decizii, fie pentru studii; - utilizatori ini ia i (specialişti), care cunosc structura bazei de date, au cunoştin e de programare, cunosc problemele sistemului de operare, astfel încât resursele consumate să fie minime.

1.5. EVOLU IA SISTEMELOR DE GESTIONARE A BAZELOR DE DATE După unii autori [1] se presupune că momentul despăr irii limbajelor de programare în două ramuri de evolu ia, adică în: - limbaje de programare şi - sisteme de gestiune a bazelor de date Să nu uităm, însă, că eram în anii ’60, în plin război rece, într-o conceren ă covârşitoare cu URSS, care deja făcuse primele ieşiri în spa iul cosmic. Cum însă datele au rămas secrete, până în momentul redactării acestei căr i nu avem informa ii despre evolu ia sistemelor de gestiune a bazelor de date ruseşti, dar avem convingerea că, atâta vreme cât au existat computere şi în zona URSS, au dezvoltate sisteme de gestiune a bazelor de date la fel de competitive. Diferen a rezidă în aceea că sistemul american a dezvoltat standarde de compatibilizare şi uniformizare, astfel că, după apari ia GUAM (Generalized Update
7

Access Method) în anii ’60, la scurt timp s-au elaborat proceduri de utilizare. Astfel, în 1965, cu ocazia Conferin ei pentru Limbajele Sistemelor de Date (CODASYL) s-au pus bazele a ceea ce în 1967 a devenit Grupul Operativ pentru Baze de Date (DBTG), care a avut ca principale preocupări elaborarea standardelor de creare şi manipulare a datelor. DBTG a identificat trei elemente de bază ale SGBD-urilor: - schema de re ea – care reprezintă organizarea logică a bazei de date în care se includ definirea denumirii bazei de date, a tipului fiecărei înregistrări şi a componentelor fiecărui tip de înregistrare şi reprezintă viziunea administratorului bazei de date; - subschema – partea sau por iunea din baza de date aşa cum este percepută de către programul-aplica ie sau de către utilizatorul final (mai mult sau mai pu in instruit); - un limbaj de gestionare a bazelor de date – care să definească caracteristicile şi structura datelor şi care să le manipuleze. Putem spune fără a greşi că prima genera ie de SGBD-uri a fost inaugurată odată cu apari ia GUAM-ului şi în perioada 60-70, denumită şi perioada CODASYL. S-au distins câteva dezavantaje, şi anume [1]: - trebuiau scrise programe complexe pentru a răspunde chiar şi la interogări simple; - existau independen e minime a datelor; - nu exista o bază teoretică unanim acceptată. Odată cu apari ia legilor lui E.F.Codd în 1970, se poate spune că s-a făcut trecerea la o a doua genera ie, a SGBD-urilor rela ionale. Astfel, s-au conturat următoarele: - dezvoltarea limbajului de interogare structurat, SQL, care a devenit limbajul standard pentru SGBD-uri rela ionale; - producerea de SGBD-uri rela ionale la scară comercială. Cea de-a treia genera ie, conturată la începutul anilor ’90, se remarcă prin două direc ii de dezvoltare a conceptelor SGBD, şi anume: - SGBD orientate spre obiecte (Object-Oriented DBMS); - SGBD de obiecte rela ionale (Object-Relational DBMS). Aceste ultime două categorii de SGBD-uri mai sunt denumite şi sisteme avansate şi răspund mai bine conceptului de orientare spre obiecte, putând deservi baze de date distribuite, multimedia, seriilor de achizi ii rezultate din experimentele ştiin ifice etc.. Sintetizând, principalele modele de structurare a datelor sunt: - modele ierarhice; - modele re ea; - modele rela ionale; - modele rela ionale orientate spre obiecte; - modele de obiecte rela ionale. Open Database Connectivity (ODBC) reprezintă o interfa ă standard care permite unei aplica ii să acceseze date din surse diferite: Oracle, MS SQL Server, DB2, Informix, MS Access, dBase etc.. Sistemele de gestiune a bazelor de date au evoluat în denumire transformându-se într-un concept mai larg, servere de date. Aceasta şi datorită capabilită ii de a fi portabile pe Internet. Noua denumire a fost adoptată spre sfârşitul anilor ’90, ca fiind mai ilustrativă, mai puternică şi mai generală decât anterioara. Interfa a ODBC defineşte:
8

o bibliotecă de apeluri de func ii care permit unei aplica ii să se conecteze la o sursă de date, să execute fraze SQL şi să primească rezultatele acestora; - o modalitate standard de conectare la o sursă (BD) de date externă; - o modalitate standard de reprezentare a tipurilor de date. Această interfa ă permite, de asemenea, recep ionarea prin mecanisme standardizate, a erorilor generate de motoarele diferitelor servere de date care gestionează baza de date sursă [15]. Practic, în arhitectura client-server, SGBD-ul este doar o componentă alături de alte proprietă i. Arhitectura client-server este un model de lucru în care mai multe programe autonime comunică prin schimb de mesaje. Sistemele client-server sunt sisteme informatice distribuite. Un client reprezintă un calculator, care prin intermediul unui mesaj formulează o cerere de informa ii sau servicii, către un alt calculator denumit server, care are calitatea suplimentară de „trezorier” şi gestionar al informa iilor de inute. Ac iunea de comunicare client-server se derulează transparent pentru utilizator [16]. Caracteristicile clientului: - prezintă o interfa ă utilizator, de obicei grafică (GUI); - „formulează” interogări (cereri, consultări) sau comenzi către server; - transmite interogările sau comenzile serverului printr-o tehnologie de comunica ie; - analizează datele din rezultatele interogărilor/comenzilor primite de la server. Caracteristicile serverului: - furnizează un serviciu clientului; - răspunde la interogările/comenzile clientului; - ascunde detaliile sistemului client-server, făcând transparent dialogul între client şi server. Orice sistem distribuit este alcătuit din minimun trei componente principale: - interfa a cu utilizatorul (sistem de operare/mediu grafic); - aplica ia (prelucrările sau procesele); - sistemul de gestiune al bazelor de date. Aceasta este o arhitectură pe două straturi. Arhitectura pe trei straturi, cea din zilele noastre (Figura 1.4.), în afară de posturile client şi server de date, există şi serverele de aplica ii, care constituie partea logică a aplica iei şi gestionează prelucrările [16]. 1.6. ASPECTE GENERALE PRIVIND MANAGEMENTUL CALITĂ II ÎN PRODUC IA SOFTWARE [32] Unul dintre criteriile de valoare ale unui produs software este calitatea acestuia. Conceptul de calitate este complex şi face referire atât la func ionalitatea produsului în timp, la rapiditatea şi corectitudinea prelucrărilor, dar şi la uşurin a utilizatorului în în elegerea principalelor func ii ale acestuia. Produsul software supus monitorizării de calitate trebuie să răspundă câtorva criterii principale, şi anume: - calitatea concep iei; - calitatea fabrica iei (monitorizare pe tot parcursul fabrica iei);
9

-

calitatea produsului (sau serviciului); calitatea livrării; fiabilitatea în exploatare şi gradul de satisfac ie al utilizatorilor. În bună măsură, aspectele calitative software îmbinate cu cele hardware sunt de maximă importan ă în aplica iile destinate monitorizării vie ii sau în cele care pot fi, în caz de eroare, generatoare de situa ii ce pot pune via a sau mediul în pericol. De asemenea, aplica iile dedicate domeniului financiar, bursier sau bancar, dacă sunt afectate de erori pot afecta pie e de milioane de conturi, cu implica ii indirecte într-o multitudine de domenii economice. Cu alte cuvinte, minimizarea spre zero a apari iei erorilor reprezintă elul oricărui producător de software. Neîndoielnic că, oricât de performant ar fi produsul software, eroarea umană introdusă de un utilizator poate fi la rândul ei, de asemenea, sursă de disfunc ionalită i. Sistemele de gestiune a bazelor de date trebuie deci să aibă prevăzute nivele de securitate şi acces diferen iate, precum şi solu ii de back-up (salvare) a celor mai recente ac iuni, precum şi a istoricului datelor pe cel pu in un suport de memorare. În func ie de importanta aplica iei, se recomandă prevederea salvării automate, periodice a activită ii pe minim trei supor i de memorare, în trei loca ii diferite, dar care să aibă prevăzută posibilitatea de actualizare automată la fiecare nouă salvare. Adeseori sistemele de memorare şi de salvare simultană sunt realizate sau bazate pe tehnologii diferite (magnetic, optic, electrostatic etc.) tocmai pentru a minimiza pierderile fizice. Prevederea de proceduri de elaborare şi uz la toate nivelurile, de la concep ie, fabrica ie, livrare, până la utilizare conduce la ridicarea costurilor produsului software, dar pierderile generate de disfunc ionalită i sunt minimizate. Producătorul de software trebuie să aibă în vedere ca balan a dintre costuri şi prejudiciile produse beneficiarului să nu conducă la anomalii. Astfel, un pre ridicat, justificat de costuri de produc ie şi testare ridicate, poate conduce la îngustarea segmentului de pia ă căruia îi este dedicat, alungarea clientelei tradi ionale, ba chiar şi ieşirea de pe pia ă. Şi aceasta, cu toate că produsul oferit poate fi garantat ca „sigur” ! Producătorul va ine permanent seama de profilul clientului său din segmentul de pia ă intă, de puterea sa de cumpărare şi de performan ele aplica iilor similare realizate de concuren ă. Şi aceasta, fără a face rabat vreun moment de calitatea produsului său.

-

CAPITOLUL 2

MODELAREA CONCEPTUALĂ A SISTEMELOR DE GESTIUNE A BAZELOR DE DATE
2.1. NIVELURILE DE ABSTRACTIZARE A DATELOR

Sub aspectul nivelurilor de abstractizare şi de protec ie a datelor, se disting patru trepte, şi anume:
10

Nivel real

1. Nivelul fizic (intern), este descris de schema fizică a datelor (bit, octet, adresă) şi reprezintă viziunea programatorilor de sistem asupra datelor. Datele există doar la nivel fizic, iar celelalte niveluri sunt niveluri de virtualizare în prezentarea datelor; 2. Nivelul conceptual – este alcătuit din schema conceptuală a datelor (articol, înregistrare, zonă) şi reprezintă, de asemenea, viziunea programatorilor de sistem asupra datelor; 3. Nivelul logic – este dat de una din schemele logice posibile ale datelor şi reprezintă viziunea programatorului de aplica ie asupra datelor; 4. Nivelul virtual (extern) reprezintă viziunea utilizatorului final asupra datelor.

Nivele virtuale

2.2. ORGANIZAREA DATELOR
2.2.1. ORGANIZAREA INTERNĂ A DATELOR

Datele sunt structurate în memoria calculatorului sub următoarele forme: - masiv; - înregistrare. Masivul defineşte o colec ie de date sub un nume comun, caracteristică vectorilor şi matricelor. Spa iul de memorie alocabilă, necesar reprezentării şi prelucrării masivelor trebuie declarată ini ial de administratorul de date. Masivele pot primi date din bazele de date, sau de la aplica iile de interogare şi pot transmite date unor înregistrări, func ii, baze de date. Înregistrarea reprezintă unitatea clasică de organizare, reprezentare şi prelucrare internă a colec iilor de date. Organizarea înregistrărilor se face pe două nivele: - organizare logică – specificând identificatorul de referin ă, mul imea de valori pe care le pot lua datele pe parcursul prelucrării lor, tipul datelor, mărimea fiecăreia, modul de aliniere, cheile de acces etc.; - organizarea fizică – prin trimiterea la codurile de reprezentare internă, adresarea pentru accesarea loca iilor de memorie etc. Câmpul este un element al înregistrării şi reprezintă unitatea de structurare şi de identificare a informa iilor unei înregistrări. Orice câmp se defineşte prin: - nume atribut; - tipul datelor con inute (numerice, alfanumerice, logice etc.); - lungimea datelor (exprimată în număr de caractere); - pozi ia punctului zecimal; - rolul pe care îl are în procesul prelucrării (de identificare, de calcul, de indexare, de legătură).
2.2.2. ORGANIZAREA EXTERNĂ A DATELOR

11

Principala formă de organizare externă a datelor o reprezintă fişierul*). Accesul la date poate fi diferit în func ie de categoria datelor, şi anume: - date propriu-zise, privite ca simple înregistrări ce urmează a fi accesate, prelucrate şi realocate spre memorie; - date complexe, care pot fi date propriu-zise, serii de date şi/sau fişiere de sine stătătoare (fişiere de fişiere). În acest paragraf vom face referire la această ultimă formă. Fişierele componente ale bazei de date sunt definite de următoarele elemente: - con inutul informa ional (fişier de date, fişier-program, fişier de comenzi, fişiertext, fişier multimedia etc.); - modul de organizare al con inutului; - modul de accesare a datelor; - parti ia de memorie externă pe care este depus (localizarea în memoria externă); - specificatorul de identificare atribuit; - atribute de tip read-only, hidden, archive, system; - data la care a fost creat. Din punctul de vedere al actorilor ce participă la mediul unei baze de date (administratori, programatori, utilizatori), accesul la datele con inute de un fişier se realizează prin înregistrări logice de acces. Modul de accesare se realizează prin încărcarea în memoria internă a calculatorului a următoarelor elemente: - se încarcă programul-aplica ie; - se aduc pe rând blocurile de înregistrări fizice în pozi ie de aşteptare, la dispozi ia programului-aplica ie; - fiecare înregistrare fizică este descompusă în înregistrări logice; - înregistrările logice sunt prelucrate pe rând de programul-aplica ie iar rezultatele sunt furnizate la ieşire. 2.3. MODELE DE DATE
2.3.1. NO IUNI GENERALE

Colec iile de date se bazează pe conceptele asociate de: - entitate; - caracteristică; - membru; - atribut. Entitatea reprezintă o componentă unitară ce poate fi individualizată, după aceleaşi descrieri, într-un domeniu. La nivelul fiecărei entită i, se pot crea colec ii de date cu proprietă i similare. Exemple de entită i:
A nu se face confuzia cu sisteme organizate pe fişiere, care reprezintă un cu totul alt concept şi face referire la formele precursoare ale SGBD-urilor.
*)

12

Colec ia Experimente Colec ia Contracte Colec ia Furnizori Colec ia Filme; Colec ia Muzică; Etc. Caracteristica este un concept prin care se definesc proprietă i specifice predominante, care ajută la descrierea colec iilor de date ca entită i. Entitatea este descrisă de lista de caracteristici. Mul imea caracteristicilor care definesc un domeniu formează o familie de caracteristici. Membrul reprezintă un element al unei colec ii de date. Atributele sunt caracteristicile (descrierile) unui membru şi serveşte pentru caracterizarea însuşirilor comune unei categorii. Domeniul reprezintă totalitatea valorilor specifice unui atribut. Tabel 2.1.
ENTITATE EXPERIMENTE MEMBRU FIZICĂ ID_Seria Data Atribute Coordonator Aparat Cost ID_Seria [1,500] Valoare Data [01.01.01-31.12.20] Cost [50000;150000] CONTRACTE CERCETARE Nr_înregistrare Finan ator Data finalizării Responsabil Buget Nr_înregistrare [1,2000] Data finalizării [01.01.01-31.12.20] Buget [25000;1000000] FILME COMEDIE ID Regizor Actor principal An producere Premiu ID [1,30] An producere [01.01.193031.12.2000] MUZICA CLASICĂ ID Compozitor Orchestra Dirijor An înregistrare ID [1,740] An înregistrare [01.01.1900-31.12.2010]

-

În tabelul 2.1. sunt prezentate câteva exemple de dependen ă entitate → membru → atribut →valoare. Modelarea datelor se bazează pe conceptul matematic de rela ie, care este o matrice cu n coloane şi m rânduri iar elementele matricei sunt dispuse şi între care există coresponden e logice. O altă defini ie importantă este cea a tuplului care este un rând într-o rela ie. Spre deosebire de tuplu, atributul este o coloană a unei rela ii, cu o anumită denumire. Concluzionăm că fiecare entitate este identificată printr-un nume şi fiecare atribut al entită ii, pe care o caracterizează, poartă un nume distinct.
13

Rela iile sau asocierile reprezintă comunicarea între două sau mai multe entită i şi raportul (pozi ia) care există între aceste entită i. O valoare a unei rela ii este o comunicare între valorile entită ilor care le leagă. Cu alte cuvinte rela ia este un concept intim legat de apari ia a două sau mai multe entită i. Una din principalele modalită i de structurare şi vizualizare a datelor (sau a pachetelor de date) este prin folosirea abstractizării , care neglijează aspectele nerelevante şi realizează concentrarea asupra proprietă ilor care sunt semnificative dintrun anume punct de vedere. Criteriul de relevan ă în abstractizare este condus de anumite obiective specifice bazei de date ce urmează a fi administrate. O formă elementară de abstractizare este tipizarea prin care se defineşte un tip pornind de la o clasă de obiecte similare. Tipul permite generalizarea în alcătuirea mul imilor semnificative de obiecte, care au elemente comune, iar deosebirile sunt neglijate. Această categorie de generalizare se numeşte clasificare.

EXPERIMENT

TIP

LABORATOR

BUGET

COST

Fizica nucleară

Fizica Chimia solidului COORDONATOR APARAT

CP I

CP II

CP III

A1

A2

An

Figura 2.5. Ierarhii de generalizare Instan ierea este opusul procesului de clasificare. Specializarea este opusul generalizării. Prin aplicarea pe mai multe nivele a generalizării se ob in ierarhii de generalizare (Figura 2.5.). Agregarea este o formă de abstractizare prin care un obiect este alcătuit din păr ile sale componente (Figura 2.6.).

14

PERSOANA

NUME

TITLU ŞTIIN IFIC

INSTITUT

VECHIME

ETAJ

LABORATOR

NR.

Figura 2.6. Ierarhie de agregare În figura 2.6. se observă că PERSOANA constituie un tip generalizat, căruia i s-au asociat tipurile NUME, TITLU ŞTIIN IFIC, INSTITUT, VECHIME care sunt proprietă i intensionale ale tipului PERSOANA. Să presupunem acum că este cazul unui consor iu de cercetare cu mai multe institute de cercetare din diverse domenii ştiin ifice, că sunt diferite laboratoare experimentale şi ne interesează loca ia unde Traian Vlădu oiu, cercetător ştiin ific debutant, cu o vechime de 5 ani la Laboratorul de Energii înalte, etajul 4 din Institutul Curie a făcut o descoperire importantă sau termenul proiectului se apropie de sfârşit. Numelui Traian Vlădu oiu i se va asocia ETAJ, LABORATOR, NR care constituie proprietă ile extensionale ale instan ierii tipului PERSOANA care caracterizează respectivul cercetător.
2.3.2. MODELUL DE DATE IERARHIC

Modelul de date ierarhic constituie cronologic prima etapă în conturarea conceptelor SGBD. Acest model foloseşte două forme de structurare a datelor: - tipurile de înregistrări, pentru reprezentarea tipurilor de entită i; - legăturile explicite pentru reprezentarea rela iilor între mul imi de entită i care au şi rolul de a preciza conexiunile între tipurile de entită i. Diagrama structurii de date este un arbore de defini ie ierarhic, adică un graf orientat de tip ierarhic (Figura 2.7.).

15

INSTITUT

PERSONAL

DEPARTAMENT

LOCA IA

APARATE

Figura 2.7. Arbore de defini ie ierarhic pentru baza de date a unui institut de cercetare

Schi a unui arbore de defini ie reprezintă forma comprimată, logica de abordare a datelor în mod sugerat, simplificat. Plantarea cu date, care răspund arborelui de defini ie, reprezintă forma extinsă, explicită a bazei de date structurată în tipul ierarhic. Apari ia datelor este structurată în formă de tabele legate logic unele de altele. Descrierea unei baze de date de tip ierarhic utilizând un limbaj de defini ie a datelor presupune trei elemente esen iale, şi anume: - arbore de defini ie ierarhic (prin specificarea nodului rădăcină şi a legăturilor tatăfiu); - tipurile de înregistrări (nodurile arborelui); - câmpurile din cadrul înregistrărilor (tipul şi dimensiunea). În figura 2.8. este ilustrată forma detaliată a bazei de date ierarhice aferente schemei din figura 2.7. .

16

INSTITUT Cod 01 02 Nume FIZICA MATERIALELOR OPTOELECTRONICA Adresa Măgurele Măgurele LOCA IA Nr 3 7 104 Adresa Măgurele Măgurele Elisabeta Laboratoare 38 114 5

PERSONAL Nume Voinea Nanu Micu Niculescu Func ie CP I CP III Strungar laborant Salariu 1700 790 480 340

DEPARTAMENT Nume SEMICOND PIEZO LASER RAZEX Contracte 5 14 25 7 APARAT Denumire Ultrasunete Ultrasunete Moară bile Cuptor Raze X Laser He-Ne Maşina scris Laser He-Ne Tip USIP 11 USIP 11 KX-43 ZK-J-43 UJ-4 Autohton Minolta 8 Autohton Vechime 15 15 3 21 17 5 25 5

Status În func iune În func iune În func iune inactiv inactiv În func iune inactiv În func iune

Figura 2.8. Extensia bazei de date ierarhice aferente unui consor iu de institute de cercetare

Aşa cum se poate observa din figura 2.8. apare fenomenul de redundan ă, întrucât „Laser He-Ne” este utilizat atât de „LASER”, cât şi de departamentul „RAZE X”. De asemenea, pentru aparat „Ultrasunete”, acesta este utilizat şi de departamentul „PIEZO” şi de departamentul „RAZE X”. La o eventuală interogare, de genul „În uzul cui se află aparatul de ultrasunete?” calculatorul va investiga toate modurile arborelui până va identifica toate variantele posibile, ceea ce presupune consum de resurse şi timpi de prelucrare mult mări i decât în mod uzual. Problema se complică în cazul elaborării unei scheme ierarhice distribuite pe mai multe nivele ierarhice. Modelul ierarhic se caracterizează printr-o serie de anomalii legate de opera iile de adăugare, ştergere şi actualizare a datelor. Avantajele modelului ierarhic: - capacitatea de a se implementa eficient pe orice tip de suport de memorare; - simplitatea modelului; - uşurin a de a fi în eles; - număr de operatori de manipulare de date redus. Dezavantajele modelului ierarhic:
17

-

flexibilitate redusă în structurarea datelor, reducându-se la rela ii simple de tip una la mai multe (1→N); limitarea interogărilor; risc de apari ie a redundan ei datelor.

2.3.3. MODELUL DE DATE ÎN RE EA

Modelul de date în re ea func ionează pe rela ii de tip una la mai multe, 1→N. Sub aspect cronologic, aceste sisteme au răspuns favorabil conceptelor CODASYL şi DBTG (Database Task Group). Pentru a permite accesul la informa ie utilizatorii sunt grupa i în jurul programeloraplica ie pentru care sunt compatibili. Accesul la date se face prin acces ini ializat la baza de date (de regulă prin pointeri). O altă formă de acces a fişierelor o reprezintă descărcarea fişierului X din memoria externă în segmentele de alocare activă ale programului-aplica ie în sectorul de date. Două prime dezavantaje se desprind de aici: - accesul la date se face prin cunoaşterea elementelor de alocare a memoriei în baza de date, oarecum mecanicist şi complicat pentru un utilizator obişnuit; - încărcarea SGBD cu segmente de date separate compatibile cu programele de aplica ie, ceea ce conduce la un consum mare de memorie. Sintetizând (Tabelul 2.2.), putem desprinde o primă compara ie între cele două tipuri de modele [1]: Tabel 2.2. Modelul de date ierarhic Modelul de date în re ea - Acceptă direct rela iile de tip 1→1 şi - Acceptă direct rela iile de tip 1→1 şi 1→N la nivel aritmetic (binar sau de 1→N la nivel aritmetic (binar sau de grad mai înalt); grad mai înalt); - Rela iile M→N se acceptă numai prin Acceptă rela ii M→N prin descompunerea şi dublarea datelor în descompunere, ceea ce poate declanşa diverse ierarhii (ceea ce conduce la redundan a datelor; redundan a datelor); - Rela iile recursive se realizează numai prin descompunerea şi dublarea datelor; - Rela iile recursive sunt acceptate prin - Tipurile de înregistrări sunt legate prin descompunere; structura ierarhică; - Tipurile de înregistrări sunt legate prin - Integritatea referen ială este sus inută construirea de tipuri de mul imi; acolo unde un tip de înregistrare-fiu - Integritatea referen ială este sus inută dependentă are o participare totală în prin construirea de tipuri de mul imi; rela ia cu tipul său de înregistrare-tată; - Structura este inflexibilă fa ă de modificarea cerin elor privind datele şi - Prezinta o flexibilitate limitată fa ă de accesul; modificarea cerin elor referitoare la date - Accesul la tipurile de înregistrări se şi la acces;
18

face prin parcurgerea întregii ierarhii de la nodul generator spre nivelele inferioare ale ierarhiei (denumită şi traversare prin preordonare).

- Accesul la tipurile de înregistrări se face pe baza parcurgerii structurii, pentru care există instruc iuni specifice de accesare rapidă spre grupul de înregistrări- intă fa ă de modul generator al structurii.

Avantaje: A1. Controlul redundan ei datelor; A2. Coeren a datelor; A3. Mai multe informa ii de la aceiaşi cantitate de date; A4. Partajarea datelor; A5. Integritate crescută a datelor; A6. Securitate crescută; A7. Aplicarea standardelor; A8. Economia de scală; A9. Echilibrul între cerin ele aflate în conflict; A10. Îmbunătă irea accesibilită ii datelor şi a capacită ii de răspuns; A11. Productivitate crescută; A12. Capacitatea de între inere crescută, prin independen a de date; A13. Concuren a îmbunătă ită; A14. Îmbunătă irea serviciilor de salvare de siguran ă şi refacere. Dezavantaje: D1. Complexitatea; D2. Dimensiunea; D3. Costul sistemelor SGBD; D4. Costurile adi ionale pentru elemente de hardware; D5. Costul conversiei; D6. Performan a; D7. Impactul crescut al unei defec iuni.
2.3.4. MODELUL RELA IONAL

Se consideră că naşterea bazelor de date rela ionale s-a petrecut în 1969, avându-l ca şi ini iator pe Edgar F. Codd, matematician cercetător la IBM. În lucrarea „A Relational Model of Data for Large Shared Databanks”, (Communications of the ACM, iunie 1970, p.377-387), el a fundamentat matematic această nouă abordare pornind de la teoria mul imilor şi logica predicatelor (generând şi noul termen de „rela ional” provenit din teoria mul imilor). Principiile lui Codd (reguli ce stau la baza modelării rela ionale) sunt: a) orice rela ie trebuie să aibă un atribut de identificare şi, dacă nu există, el trebuie creat; b) orice atribut (caracteristică) trebuie să fie atomic (nedecompozabil);
19

c) orice tuplu al unei rela ii trebuie să con ină o singură valoare pentru un atribut; d) orice atribut trebuie să depindă direct şi în întregime de identificator; e) un atribut trebuie să apară o singură dată în cadrul unei rela ii. Un alt tip de baze de date sunt cele opera ionale, care sunt destinate prelucrării online a tranzac iilor (on-line transaction processing – OLTP), în care actualizarea modificărilor de date se face în fiecare moment. Dezvoltarea unor asemenea baze de date implică hardware foarte fiabil şi necesită prelucrări rapide, iar din punct de vedere al software-ului acesta este supravegheat prin departamente specializate întrucât actualizarea on-line este esen ială. Exemple de baze de date on-line se găsesc în tranzac ii de tip bursier, în clinici medicale, farmacii, re ele de magazine en-detail, sec ii de produc ie etc. . Cele enumerate se caracterizează printr-o permanentă dinamică a stării informa iei. Bazele de date analitice sunt destinate în mod special pentru stocarea şi urmărirea seriilor cronologice, precum şi pentru construirea de scenarii şi prognoze. Aceste procese sunt cunoscute şi sub denumirea de prelucrare analitică on-line (on-line analytical processing – OLAP). Se caracterizează prin stocarea de date statistice, respectiv date ale căror valori se modifică rar (sau niciodată). Astfel de baze de date sunt utile laboratoarelor de cercetare ştiin ifică, companiilor de analiză, consultan ă sau marketing, departamentelor de studii statistice etc.. Michael J. Hernandez [11] face o sinteză a avantajelor bazelor de date rela ionale, astfel: - Integritate încorporată multi-nivel – prin care datele sunt structurate în tabele caracterizate unic prin tuplu (înregistrare în linie) şi prin câmp, astfel că înregistrarea este unic determinată; - Interdependen a logică şi fizică în raport cu aplica iile de baze de date în care datele nu pot fi alterate fizic sau logic de eventualele modificări ale structurii logice ale unui utilizator sau în cazul unui up-grade ale SGBD-ului structura va rămâne cea ini ială. - Consecven ă şi acurate e garantate ale datelor – această caracteristică poate fi asigurată de impunerea unor nivele de acces şi securitate în ceea ce priveşte manipularea datelor; - Regăsire facilă a datelor – asigurată de proprietă ile de căutare criterială şi a modalită ilor de vizualizare după cerin ele de interogare furnizate de utilizator.
2.3.5. MODELUL ORIENTAT OBIECT

Aplica iile recente, din diverse domenii au făcut ca bazele de date rela ionale să devină uneori improprii. Ca şi în limbajele de programare, s-a dezvoltat şi-n sfera bazelor de date conceptul de baze de date orientate obiect şi sisteme de gestiune a bazelor de date orientate obiect. Enumerăm aplica ii pentru care orientarea obiect este proprie, astfel: - proiectarea asistată de calculator (CAD); - fabricarea asistată de calculator (CAM); - ingineria programării asistată de calculator (CASE);
20

sisteme informa ionale de birou (OIS); sisteme multimedia; editarea digitală; sisteme informa ionale cartografice (GIS); aplica ii cu obiecte complexe intercorelate şi cu date procedurale. Principalele elemente cu care se operează în manipularea bazelor de date orientate obiect sunt: - obiectul; - starea; - comportamentul. Conceptul „orientat spre obiecte” leagă întrucâtva datele care descriu obiectul de sistemul de gestiune a datelor, care trebuie să fie compatibil şi să admită că obiectul este o unitate de observare care încapsulează atât datele care-l descriu, precum şi instruc iunile care operează asupra datelor. Limbajele de programare, componente ale SGBD-urilor orientate spre obiecte respectă tehnicile de regrupare a datelor, a fişierelor şi a entită ilor de prelucrare (programe, subprograme) pe baza anumitor criterii. Un obiect constituie un modul de program care descrie caracteristicile şi comportamentul conceptual şi fizic care intervine în etapele de implementare. Obiectul este alcătuit din: - date, care descriu starea, caracteristicile entită ii; - metode, care descriu comportamentul. Un obiect emite şi primeşte mesaje care au următoarea topică: [<destinatar>].metoda[<argument>] Un SGBD orientat obiect trebuie să ofere mecanisme pentru următoarele opera ii: a) încapsularea; b) moştenirea; c) polimorfismul metodelor. Identificatorul unui obiect poate fi independent de valoarea asociată lui. El nu trebuie să fie gestionat direct de programator şi nu trebuie confundat cu diferitele nume pe care utilizatorul le poate folosi pentru a numi obiectul respectiv. Identitatea unui obiect este în general implantată printr-un identificator intern unic care este independent de valoarea sau de adresa în memorie a obiectului. Identitatea obiectului reprezintă o cheie internă, un obiect putând fi accesat după următoarea topică: Q = (id, v) unde Q – obiectul; id – identificator; v – valoarea. Concluzionăm că un obiect este o entitate unic identificabilă. Obiectele pot con ine alte obiecte. Într-un SGBD orientat obiect, fiecare obiect are un identificator unic pentru întregul sistem, care este independent de valorile atributelor sale şi invizibil pentru utilizatori.
21

-

Încapsularea reprezintă faptul că un obiect este caracterizat printr-o structură de date şi o interfa ă, respectiv setul de opera ii care pot fi utilizate pentru manipularea sa. Structura este identificată printr-un identificator unic şi de o stare care permite regruparea atributelor ce con in datele. Aceste atribute pot con ine: - valori atomice; - obiecte (accesate prin identificatorii acestora). Interfa a unui obiect este compusă din selectorii metodelor şi reprezintă partea vizibilă a obiectului. Structura este recunoscută doar de obiectul însuşi (nefiind accesibilă din exterior), deci un obiect nu poate fi manipulat decât prin metodele asociate lui. Conceptul de ascundere a informa iilor semnifică aceea că aspectele externe ale unui obiect sunt separate de detaliile sale interne, care sunt ascunse de lumea exterioară. Principiul încapsulării nu permite ca structura obiectului şi metodele sale să poată fi accesate sau modificate direct din exterior. Limbajele de programare orientate obiect promovează o arhitectură modulară în care obiectele nu cunosc implementarea altor obiecte, ci doar interfe ele lor. Cu alte cuvinte, încapsularea reprezintă înmănuncherea metodelor şi variabilelor de instan ă într-o clasă sau obiect astfel încât accesul la variabilele de instan ă să fie permis doar prin intermediul metodelor obiectului. Metodele definesc comportamentul obiectului. Mesajele sunt mijloace prin care comunică obiectele. Un mesaj reperezintă o cerere a unui obiect emitent către alt obiect receptor, prin care receptorul este solicitat să execute una dintre metodele sale. Emitentul şi receptorul pot reprezenta unul şi acelaşi obiect. Obiectele care au aceleaşi atribute şi răspund la aceleaşi mesaje pot fi grupate împreună, alcătuind o clasă. O clasă este un obiect care are atribute şi metode proprii definite o singură dată pentru toate obiectele con inute de acesta. Clasa se caracterizează prin atributele clasei şi, respectiv metodele clasei. Opera ia prin care este creat un obiect, după schema precizată de o clasă, se numeşte instan iere, iar obiectul creat după planul oferit de o clasă este o instan ă a acelei clase. Modelul teoretic al unei clase a unui ansamblu de obiecte este ilustrat mai jos: Class Proprietate Attributes ID_proprietate Adresa Proprietar Vizitator Methods Descriere Return (imobil.tip) Contractare Return (imobil.tranzac ie)
22

...................................................................... Class induce numele clasei. Attributes dă o listă de atribute sau variabile de instan ă. Methods dă lista selectorilor şi metoda asociată fiecăruia. Cuplul selectormetodă mai este denumit şi dic ionarul metodelor. Când se generează un obiect nou, acesta posedă valorile corespunzătoare atributelor sale, iar lista atributelor sale şi dic ionarul metodelor sunt furnizate de către clasă. Ansamblul instan elor unei clase alcătuieşte o colec ie care poartă, în general, acelaşi nume cu al clasei şi poartă denumirea de extensia clasei. Clasele şi obiectele grupate şi stocate într-o formă fizică alcătuiesc module. Modulele formează arhitectura fizică a sistemului de gestiune a bazei de date (Figura 2.10.). Conceptul de modularizare reprezintă posibilitatea divizării ansamblului de date şi gestiune a datelor într-un număr de subansamble (module) care pot fi compilate separat, dar care sunt cuplate între ele. Modularizarea respectă câteva reguli generale, şi anume: 1. structura fiecărui modul trebuie să fie suficient de simplă pentru a putea fi complet în eleasă; 2. implementarea unui modul trebuie să depindă doar de interfe ele altor module; 3. detaliile sistemului, care se presupune că vor suferi modificări independente, vor fi plasate în module diferite; 4. singurele legături între module vor fi acelea a căror modificare este improbabilă; 5. orice structură de date este încapsulată într-un modul; ea poate fi accesată direct din interiorul modulului, dar nu poate fi accesată din afara modulului decât prin intermediul obiectelor şi claselor con inute în acel modul. Moştenirea permite ca o clasă să fie definită ca un caz special al unei clase mult mai generale. Clasele derivate sunt subclase, iar clasele generatoare, cu caracteristicimai generale sunt superclase. Procesul de formare a unei superclase este numit generalizare, în timp ce formarea unei subclase este numită specializare.

23

IMOBILIZĂRI CLASA-CONT

CORPORALE VALOARE_LEGALĂ TIP_LEGAL_FOLOS GRUPA_CONT

NECORPORALE

FINANCIARE

CATEGORII COD_CATEGORIE NUME_CATEGORIE

MIJLOACE FIXE NR_INVENTAR LOC_FOLOSIN Ă DENUMIRE_MF DATA PIF DURATA_NORMATĂ VAL_INVENTAR VAL_AMORTIZATĂ

Figura 2.10. Exemplu de ierarhie între clasele unei baze de date [14] În figura 2.11. este prezentată o ilustrare a ierarhizării notării studen ilor unui an de studiu, care în afară de disciplinele comune pot opta în a audia şi a fi examina i şi la alte două cursuri, la alegere, cursul de electronică şi respectiv de electrotehnică. Notele ob inute vor participa la calculul mediei generale din obiectul general „STUDENT”.

24

STUDENT Nume Data_naşterii Grupa Note media Înscriere Examinare Calcul_media absolvire

STUDENT_ELECTRONICĂ Calificativ_electronică Proba_electronică Afişare_calificativ

STUDENT_ELECTROTEHNICĂ Calificativ_electrotehnică Proba_electrotehnică Afişare_calificativ

Figura 2.11. Exemplu de ierarhie a studen ilor

Persisten a reprezintă permanen a unui obiect. Acest concept men ine o distinc ie între obiectele create doar pe durata execu iei şi cele destinate pentru memoria permanentă. Popa şi colaboratorii [14] identifică următoarele coresponden e cu conceptele folosite în modelul rela ional: Model orientat obiect Identificator de obiect Variabilă de instan ă (atribut) Instan ă de clasă = obiect Definirea de clasă Ierarhia de clasă Model rela ional Cheie primară Atribut (câmp) Tuplu (înregistrare) Schema tabelului Schema bazei de date

Connolly [1] face o clasificare a avantajelor şi dezavantajelor sistemelor de gestiune a bazelor de date orientate obiect: Avantaje SGBDOO Dezavantaje SGBDOO
25

Capacită i de modelare îmbunătă ite Extensibilitate Înlăturarea nepotrivirii de impedan ă Limbaj de interogare mai expresiv Suport pentru evolu ia schemei Suport pentru tranzac ii de lungă durată Aplicabilitate pentru aplica ii de baze de date avansate Performan e îmbunătă ite

Lipsa unui model de date universal Lipsa de experien ă Lipsa de standarde Optimizarea interogării compromite încapsularea Zăvorârea la nivelul obiectului poate influen a performan ele Complexitatea Lipsa de suport pentru vederi Lipsa de suport pentru securitate

Cu toate că aparent dezvoltarea de baze de date orientate obiect pare a fi anevoioasă şi de durată mai mare decât aplica iile tradi ionale, în realitate atât durata, cât şi costurile destinate dezvoltării orientate obiect sunt mult mai reduse. Preluările bazate pe proprietă ile de moştenire, încapsulare şi polimorfism iau în considera ie structuri de proiectare anterior realizate, astfel că ra ionamentele de proiectare se alipesc ca într-un puzzle, obiecte vechi şi noi alcătuind noi ansambluri de date. Sub aspectul arhitecturii bazelor de date orientate obiect trebuie îndeplinite câteva condi ii de bază: - nivele de abstractizare bine definite; - clase cu interfe e bine definite şi a căror modificare aduce schimbări minime asupra celorlalte clase; - modificarea modului de implementare a unei clase nu creează repercursiuni majore asupra interfe ei sau implementării celorlalte clase; - arhitectură cât mai simplă, bazată pe abstrac ii şi mecanisme uzuale. Etapele dezvoltării unei baze de date orientate obiect trebuie să parcurgă următorii paşi: A. Analiza, care cuprinde: a) Identificarea obiectelor; b) Identificarea ac iunilor efectuate de fiecare obiect; c) Identificarea interac iunilor dintre aceste obiecte. B. Abstractizarea: a) Stabilirea claselor a căror instan iere (definire) sunt acele obiecte; b) Elaborarea ierarhiei de clase. C. Implementarea: a) Împăr irea pe module (clase, familii de clase) a ierarhiei de clase; b) Elaborarea claselor de bază; c) Elaborarea claselor derivate; testarea pe module; d) Asamblarea modulelor care alcătuiesc noua bază. D. Testarea de sistem a func ionalită ii bazei E. Scrierea de documenta ie Sub aspectul avantajelor aduse de structurarea orientată obiect a datelor se pot men iona şi alte avantaje, cum ar fi: - uşurin a proiectării şi reutilizării codului; astfel odată testatăcorectitudinea func ionării unor obiecte într-o aplica ie, acestea pot fi utilizate şi în alte aplica ii.
26

-

-

Acest avantaj poate fi valorificat prin construirea de biblioteci de obiecte şi apelarea lor la alcătuirea de noi aplica ii; grad înalt de abstractizare; astfel proiectantul şi utilizatorii pot ob ine o imagine de ansamblu, urmărind comportarea obiectelor şi interac iunile dintre ele, fără a cunoaşte detaliile care au concurat la construc ia obiectului; siguran a datelor; dat fiind faptul că obiectele au un comportament de „cutii negre” fără a se putea accesa decât prin metodele lor, se asigură confiden ialitatea aspectelor constructive şi se diminuează frecven a apari iei erorilor legate de manipularea greşită a tipurilor de date etc..

CAPITOLUL 3

SISTEME DE GESTIUNE A BAZELOR DE DATE RELA IONALE
3.1. PROIECTAREA BAZELOR DE DATE RELA IONALE Modelele tradi ionale de proiectare a bazelor de date incorporează următoarele faze: a) analiza cerin elor; b) modelarea datelor; c) normalizarea. Proiectarea bazei de date rela ionale presupune şapte faze (Figura 3.1.), şi anume: Faza I: Definirea următoarelor: a) declara ia de inten ie (mission statement) a bazei de date; b) obiectivele misiunii (mission objectives) ale bazei de date. Declara ia de inten ie stabileşte scopul şi finalitatea bazei de date şi destina ia bazei de date. Obiectivele misiunii statuează sarcinile generale pe care utilizatorii le pot îndeplini folosind datele din baza de date. Faza a II-a: Analiza bazei de date curente (dacă există), respectiv analiza bazei de date moştenite (legacy database) sau analiza bazei de date pe suport de hârtie (paper-based database). În primul caz, datele sunt preluate şi reimplementate într-un nou format adaptat necesită ilor actuale ale solicitantului. În cel de-al doilea caz este vorba de trecerea de la baza de date inută pe fişe în format electronic. Faza a III-a: Crearea structurilor de date în care se definesc tabelele şi câmpurile, se stabilesc cheile şi se definesc specifica iile pentru fiecare câmp. Se elimină informa iile nerelevante sau câmpurile multiplicate. Faza a IV-a:
27

Stabilirea rela iilor între tabele. Faza a V-a: Determinarea şi definirea regulilor de desfăşurare a activită ii, stabilirea constrângerilor asupra datelor. Cu această ocazie se stabilesc tabelele de validare în vederea stabilirii unor reguli de coeren ă (ex: Data comenzii va fi anterioară datei facturării sau a datei livrării unui produs). Faza a VI-a: Determinarea şi definirea vederilor, a modalită ilor de apari ie a datelor aşa cum vor fi acestea percepute de utilizatorii finali. Faza a VII-a: Trecerea în revistă a structurii finale a bazei de date, pentru verificarea integrită ii datelor. Testele de relevan ă a structurilor con in patru sub-etape: - examinarea fiecărui tabel pentru a verifica dacă îndeplineşte criteriile de proiectare adecvate; - examinarea şi verificarea tuturor specifica iilor de câmp; - testarea validită ii fiecărei rela ii; - examinarea şi confirmarea regulilor de desfăşurare a activită ii. 3.2. CARACTERISTICILE MODELULUI RELA IONAL
Tabele

Chei Chei candidate Cheie primară Cheie externă Câmp Vederi Rela ii
3.3. TIPURI DE RELA II

a) b) c) d)

Tipuri de rela ii: 1→1; 1→N; M→N; Rela ii cu autoreferire de tip: 1→1; 1→N; M→N.

28

3.4. NORMALIZAREA TABELELOR Normalizarea este un proces de descompunere reversibilă a unui tabel ini ial în tabele simplificate fără ca informa ia în ansamblul său să sufere alterări.

CAPITOLUL 4

BAZE DE DATE MICROSOFT ACCESS
4.1. CONSIDERA II GENERALE În contextul general al sistemelor de gestiune a bazelor de date, Access este un sistem de gestiune a bazelor de date rela ionale pentru Microsoft Office sub Windows. Privit din punct de vedere conceptual, Access poate fi considerat ca făcând parte din cadrul sistemelor de gestiune a bazelor de date de nivel mediu. Explica ia ierarhizării pe acest nivel constă în faptul că sistemul Access combină atât caracteristicile sistemelor de gestiune a bazelor de date simple, care nu utilizează modelul rela ional de organizare a bazelor de date, fiind axate numai pe opera ii de stocare şi căutare a datelor, cât şi caracteristicile sistemelor de gestiune a bazelor de date complexe, care stochează, prelucrează şi transmit un volum mare de date [22]. Access implică utilizarea atât a modulelor rela ionale, cât şi a celor orientate obiect, permi ând modelarea rela ională a datelor şi orientarea spre obiecte cărora li se asociază evenimente şi proprietă i [22]. Realizând o diferen iere clară între no iunea de bază de date şi cea de tabel (tabelul este componentă a bazei de date), Access asigură redundan ă minimă şi controlată tabelelor componente, cu protejarea integrită ii şi accesibilită ii datelor [23]. De asemenea, se oferă posibilitatea de a defini, consulta, actualiza şi partaja datele între diferi i utilizatori. Toate componentele bazei de date sunt stocate într-un fişier cu extensia .mdb. Se men in astfel avantajele sistemelor de gestiune a bazelor de date, asigurându-se interfa a între baza de date şi utilizator [23]. Sistemul Access are la bază un sistem rela ional definit ca „un ansamblu format din structura rela ională a datelor şi mul imea operatorilor rela ionali” [23]. Schema generală a bazei de date Access este alcătuită din colec ii de tabele care pot fi manipulate prin intermediul interogărilor. În acest sens pot fi utilizate trei tipuri de limbaje de exploatare a bazei de date [24]: 1. SQL – care reprezintă baza logică a interogărilor; 2. QBE – reprezintă baza grafică a interogărilor; 3. VBA (Visual Basic for Applications) – reprezintă baza aplica iilor complexe utilizate pentru conceperea procedurilor utilizator. Toate aceste trei limbaje permit scrierea de aplica ii complexe menite să asigure comunicarea cu sistemul de gestiune a bazelor de date prin scrierea de comenzi într-unul din limbajele de manipulare a datelor.

29

Sistemul Access permite exportul de date şi de structuri de tabele, definirea de interogări, crearea de formulare, rapoarte şi module, definirea şi utilizarea de macrouri etc. De asemenea, Access oferă asisten ă utilizatorului prin intermediul meniului Help şi a ferestrelor de dialog contextuale. Sistemul cuprinde o serie de componente Wizard destinate dezvoltării de aplica ii şi definirii pas cu pas a obiectelor tip. Microsoft Access permite scrierea direct în baza de date FoxPro, dBase, Paradox etc. [23]. În situa ia în care un program nu poate citi direct acest format, transferul de date se poate realiza prin exploatarea acestora în fişiere format text [25]. Datele externe pot fi manipulate prin import direct sau prin crearea de legături cu baza de date externă, datele rămânând în fişierele lor originale. Importul de date se poate realiza şi pentru datele de tip text, dacă acestea au fost formatate în mod corespunzător. Fiecare rând dintr-un fişier text este tratat drept înregistrare, caracterele trebuind să fie în mod obligatoriu delimitate prin virgulă sau tabulatori. Access implementează principalele func ii ale sistemelor de gestiune a bazelor de date, respectiv descrierea, manipularea şi confiden ialitatea datelor, lucrul în regim utilizator, import-export de date şi integritatea datelor [22]. Descrierea datelor presupune detalierea structurii tabelelor şi a rela iilor existente între acestea. Detalierea structurii tabelelor implică stabilirea atributelor (nume de câmpuri), a tipului de date folosite (pot fi diferite de la un câmp la altul), precum şi a caracteristicilor (proprietă ilor) fiecărui câmp. Se conferă fiecărei caracteristici a câmpurilor anumi i parametri, în func ie de tipul de dată folosit. Aici intervine limbajul de descriere a datelor. Utilizarea (manipularea) datelor presupune efectuarea de opera ii care au drept scop adăugarea, modificarea, ştergerea sau interogarea datelor. Pentru realizarea unor astfel de opera ii în mod facil se poate utiliza limbajul de manipulare a datelor VBA (Visual Basic for Applications), limbaj care va fi prezentat într-unul din paragrafele următoare. Confiden ialitatea datelor şi lucrul în regim utilizator se referă la facilitatea pe care o oferă Access în sensul de atribuire de parole şi drepturi de acces. Importul şi exportul de date este posibil de realizat atât între baze de date Access, cât şi între baze de date Access şi alte aplica ii. Integritatea datelor presupune definirea de restric ii relative la valorile admisibile a datelor care urmează a fi stocate în baza de date, astfel încât se permite men inerea integrită ii bazei de date, căutare şi localizare rapidă şi facilă a datelor, validări de mare complexitate etc.
BIBLIOGRAFIE: ANCA GHEORGHIU, CORINA MARIA BICHIS – BAZE DE DATE, ED.VICTOR, BUCUREŞTI, 2004

30