###Title###

Capitolul I - Fundamente ale bazelor de date

###Content###
Capitolul I - Fundamente ale bazelor de date - prezintă evoluția și ascensiunea
până în prezent a domeniului bazelor de date și realizează o descriere succintă
a aspectelor de bază care caracterizează domeniul. În acest context, am
încercat să poziționăm teoria bazelor de date în cadrul tehnologiilor
informaționale, am prezentat câteva definiții relevante ale conceptului de bază
de date formulate de cercetători și profesori care s-au remarcat cu preocupări
însemnate în cadrul domeniului și au fost identificate și analizate principalele
arhitecturi specifice sistemelor de baze de date. Totodată, principalul scop avut
în vedere este de a oferi o viziune clară și o înțelegere generală a ceea ce
reprezintă astăzi baza de date.
Tehnologiile informaționale influențează continuu și produc modificări
substanțiale asupra mijloacelor de lucru din întreaga lume. Informații care erau
altădată stocate în depozite pline de dulapuri, pot fi accesate astăzi prin
intermediul unei singure apăsări a butonului mouse-ului. Astfel, pentru stocarea
informațiilor din orice mediu imaginabil în zilele noastre sunt folosite sistemele
de baze de date. De la bazele de date mari, așa cum sunt sistemele care permit
rezervarea on-line a biletelor pentru companiile aeriene și până la fișele dintr-o
bibliotecă, sistemele de baze de date sunt folosite pentru memorarea și
distribuirea datelor de care încep să depindă tot mai mult viețile noastre.
Până în urmă cu câțiva ani, sistemele mari de baze de date se găseau numai pe
calculatoare de tip mainframe . Însă, așa cum era și firesc, proiectarea,
achiziționarea sau întreținerea unei astfel de mașini reprezenta o sarcină
costisitoare și dificil de realizat. Odată cu apariția calculatoarelor din clasa
stațiilor de lucru, pe care le întâlnim la tot pasul (biblioteci, laboratoare de
informatică, departamente de lucru, etc.) și care sunt puternice și în același
timp destul de ieftine, programatorii au posibilitatea de a proiecta rapid și la
costuri reduse produse informatice care să permită între ținerea și distribuirea
datelor.
###End###

###Title###
Ce este baza de date?
###Content###
Majoritatea bazelor de date iau naștere începând cu o listă într-un editor de
texte sau într-o foaie de calcul. La momentul respectiv, suntem tentați să
credem că a fost aleasă cea mai bună soluție, atât timp cât necesitățile
informaționale sunt satisfăcute, este adevărat, în contextul unei cantități reduse
de informații. În timp însă, acest volum crește (spre exemplu, odată cu creșterea
activității unei organizații, ceea ce face ca soluțiile (privite inițial ca fiind cele
mai adecvate) să nu mai fie potrivite. Mai mult, pe măsură ce lista devine tot
mai mare, încep să apară redundanțe și inconsistențe la nivelul datelor
gestionate. Datele devin greu de înțeles sub forma listei, iar posibilitățile de
căutare, regăsire și extragere a subseturilor de date pentru revizuire,
actualizare sau utilizare devin extrem de limitate. Odată cu apari ția acestor
probleme, o idee bună, chiar o necesitate în anumite situații, ar fi aceea al
transferului acestor date într-o bază de date creată cu ajutoru l unui sistem de
gestiune al bazelor de date.
O definiție completă și explicativă a noțiunii de bază de date este oferită în
[Velicanu et al., 2003, p.51]. Astfel, aceasta reprezintă un ansamblu de colec ții
de date:
• organizat, pe niveluri de organizare a datelor (conceptual, logic, fizic), a șa
cum reiese și din arhitectura pe niveluri a unui sistem de baze de date;
• coerent, conform restricțiilor de integritate și a legăturilor dintre date, care
rezultă din modelul logic aferent;
• structurat, conform unui model de date pentru bazele de date;
• cu redundanță minimă și controlată, care este asigurată prin modelul de
date implementat și prin tehnicile de proiectare ale bazei de date;
• accesibil mai multor utilizatori în timp real, adică mai mulți utilizatori,
concomitent, pot obține informațiile dorite atunci când au nevoie de ele.
###End###

###Title###
Arhitecturi ale sistemelor de baze de date
###Content###
În literatura de specialitate sunt prezentate mai multe tipuri de arhitecturi ale
sistemelor de baze de date. Nouă ne-au atras atenția cele prezentate în
[Velicanu et al., 2003, p.13]. Astfel, conform autorilor, rolul unei arhitecturi este
de a realiza o reprezentare grafică a elementelor sistemului, precum și a
legăturilor dintre ele. În funcție de ceea ce se evidențiază grafic, se folosesc
două tipuri de arhitecturi:
1. arhitectura pe componente - oferă o imagine asupra elementelor
care formează un sistem de baze de date, dar și a inter-dependențelor
dintre ele, așa cum se poate observa în figura 1.1.
Așa cum se observă, componentele specifice arhitecturii din figura 1.1
sunt:
a. datele - sunt organizate într-o bază de date care conține:
 • colecții de date propriu-zise;
• dicționarul de date (structura de date, restricțiile de integritate, vederile,
etc.);
• fișierele anexe, așa cum sunt cele de index.
b. software-ul - este aferent realizării și exploatării bazei de date și
conține:
• sistemul de gestiune a bazei de date;
• programele de aplicație dezvoltate, în cea mai mare parte, într-un sistem
de gestiune a bazelor de date.
c. elementele auxiliare - sunt componentele care contribuie la realizarea
și funcționarea întregului sistem de baze de date:
1. un set de proceduri automate (rutine) și manuale;
2. reglementări legale și administrative;
3. mijloace hardware utilizate;
4. persoane implicate pe categorii de utilizatori.
###End###

###Title###
Capitolul II - Proiectarea și administrarea unei baze de date
###Content###
Proiectarea și administrarea sistemelor de baze de date reprezintă o sarcină
dificilă și importantă în cadrul ciclului de viață al unui sistem informatic care
are drept scop gestionarea și utilizarea unui anume volum de date stocate prin
intermediul acestora. În acest context, capitolul II - Proiectarea și
administrarea unei baze de date - urmărește atingerea următoarelor obiective:
• identificarea și definirea principalelor caracteristici ale ciclului de via ță al
unui sistem de baze de date;
• detalierea procesului de proiectare a unei baze de date;
• prezentarea tipurilor de proiectare: conceptuală, logică și fizică;
• definirea și proiectarea tranzacțiilor.
###End###

###Title###
Ciclul de viață al sistemelor informaționale
###Content###
Putem privi sistemul informațional ca un ansamblu de fluxuri și circuite
informaționale, organizate într-o concepție unitară și care asigură legătura
dintre sistemul decizional (de conducere) și cel operațional (de execuție).
Trebuie menționat faptul că nu trebuie să confundăm sistemul informațioanal cu
cel informatic (din păcate, am constatat că există studii sau păreri care le
privesc pe cele două ca fiind unul și același lucru). Astfel, sistemul informatic
reprezintă un ansamblu structurat de elemente intercorelate funcțional, utilizat
pentru culegerea, prelucrarea, transmiterea și stocarea datelor cu ajutorul
mijloacelor automate de prelucrare a datelor. Scopul acestuia este de a
automatiza procesul informațional și de a sta la baza fundamentării deciziilor. În
plus, sistemul informatic este inclus în cel informațional și îi oferă acestuia noi
valențe, atât sub aspect calitativ, cât și cantitativ. Acest lucru se realizează prin
implementarea de către sistemul informatic a unor modele matematice și prin
utilizarea tehnicii electronice de calcul.
Începând cu anii '70, treptat, sistemele de baze de date le-au luat locul celor
bazate pe fișiere, ca parte a infrastructurii sistemelor informa ționale din cadrul
unei organizații. În același timp, a avut loc o recunoaștere treptată a faptului că
datele constituie o resursă comună, importantă, vitală în anumite situa ții, care
trebuie tratată cu respect, ca toate celelalte resurse ale organizației. Acest
aspect a avut ca rezultat crearea unor departamente funcționale denumite
administrarea datelor și administrarea bazelor de date, care erau responsabile
cu administrarea și controlul datelor.
Astfel, considerăm că baza de date este o componentă de bază a unui sistem
informațional, iar dezvoltarea și utilizarea sa trebuie privite și analizate din
perspectiva cerințelor mai largi ale organizației. În acest context, ciclul de via ță
al sistemului informațional dintr-o organizație este puternic legat de ciclul de
viață al sistemului de baze de date care îl susține. De obicei, etapele aferente
ciclului de viață al unui sistem informațional includ: planificarea, analiza
cerințelor, proiectarea (inclusiv a bazei de date), prototipizarea, implementarea
și întreținerea.
###End###

###Title###
Proiectarea bazelor de date
###Content###
Proiectarea corespunzătoare bazei de date este o etapă foarte important ă, mai
ales că trebuie să fie capabilă să garanteze buna funcționare a acesteia și a
oricărei aplicații care o utilizează. În lipsa unei proiectări adecvate a bazei de
date, aceasta poate prezenta mai multe deficiențe, cum ar fi:
• compromiterea integrității datelor deoarece restricțiile de integritate nu
pot fi proiectate sau implementate corect;
• datele sunt redundante, iar aplicațiile individuale se „aglomerează” în
încercarea de a se asigura sincronizarea datelor;
• performanțele sunt afectate deoarece este posibil ca pentru finalizarea
unei instrucțiuni (spre exemplu, instrucțiunea Select ) să fie necesare interogări
suplimentare.
###End###

###Title###
Proiectarea conceptuală
###Content###
Proiectarea conceptuală este prima fază din procesul de proiectare a unei baze
de date și presupune crearea unui model de date conceptual pentru partea care
se dorește a fi modelată (parte din activitatea unei organizații). Acest model de
date va fi construit prin utilizarea informațiilor aferente specifica țiilor cerin țelor
utilizatorului. Proiectarea conceptuală a bazei de date este complet
independentă de detaliile de implementare, cum ar fi elementele de software
ale sistemului SGBD avut în vedere, programele de aplicație, platforma
hardware sau orice alte considerații fizice. Totodată, trebuie să menționăm că
este important ca pe tot parcursul procesului de realizare a modelului
conceptual de date, acesta să fie permanent testa t și validat conform cerințelor
utilizatorului. Practic, acest model constituie o sursă importantă de informa ții
pentru faza de proiectare logică.
###End###

###Title###
Proiectarea logică
###Content###
Această fază are ca rezultat crearea unui model de date logic aferent
activităților sau proceselor pe care dorim să le modelăm. Modelul de date
conceptual creat în faza precedentă este rafinat și transpus într-un model de
date logic. Acesta este influențat de către modelul de date avut în vedere
pentru baza de date
Pe parcursul realizării modelului logic de date, se efectueză testarea și
validarea permanentă a acestuia în conformitate cu cerin țele utilizatorului.
Tehnica de normalizare este utilizată pentru a testa corectitudinea modelului
logic de date. Practic, normalizarea garantează că relațiile derivate din modelul
de date nu prezintă redundanțe, care pot cauza anomalii (la implementare) la
actualizarea bazei de date. Altfel spus, normalizarea este procesul prin care se
elimină redundanța datelor din baza de date și se construiește un model de bază
de date care susține diverse cerințe funcționale și structuri alternative ale bazei
de date.
Normalizarea presupune împărțirea unei relații (care include la momentul
respectiv toate atributele necesare problemei) în mai multe relații între care se
definesc diferite legături logice. Principalele obiective ale normaliz ării sunt
[Fotache, 2005, p.41-42]:
• minimizarea spațiului necesar stocării datelor;
• minimizarea riscului apariției de date inconsistente în cadrul bazei de date;
• minimizarea numărului de anomalii ce pot apărea la actualizare (inserarea
datelor, dar mai ales modificări și ștergeri);
• ameliorarea structurii bazei de date, reprezentarea diverselor conexiuni
dintre atributele acesteia;
• diminuarea nevoii de reorganizare periodică a modelului.
Există un număr de reguli care se aplică în normalizare. În continuare vom
prezenta doar primele trei reguli care sunt în măsură să garanteze definirea unei
structuri logice a bazei de date într-o form ă acceptabilă (în care îns ă
redundanța nu este eliminată complet):
1. Toate atributele trebuie specificate o singură dată (forma I normal ă);
2. Fiecare atribut trebuie să depindă în totalitate de cheia primară a rela ției pe
care o descrie (forma II normală). Această regulă se realizează prin repartizarea
atributelor într-o relație, astfel încât fiecare dintre ele va depinde în totalitate
de cheia primară.
3. Pentru a putea fi în forma III normală, fiecare relație trebuie să aibă o
singură cheie primară.
Totodată, modelul logic de date reprezintă o sursă importantă de informa ții
pentru faza de proiectare fizică, punând la dispoziția proiectantului bazei de
date logice un mecanism care să-i permită realizarea negocierilor, care sunt
foarte importante pentru a face ca proiectarea bazei de date să fie eficient ă.
Totodată, acest model are un rol important în etapa de întreținere operațională
din ciclul de viață al unei aplicații cu baze de date. Dacă este întreținut și
îmbunătățit adecvat, modelul de date permite efectuarea unor modificări
viitoare în programele aplicație și reprezentarea corectă și eficientă a datelor
de către baza de date.
###End###

###Title###
Proiectarea fizică
###Content###
Proiectarea fizică a bazelor de date este a treia fază din procesul de proiectare
a unei baze de date, în care proiectantul stabilește cum va fi ea implementată.
Așa cum am vazut deja, faza precedentă presupunea realizarea unei structuri
logice, cu alte cuvinte se referea la definirea relațiilor, atributelor și legăturilor
dintre ele. Cu toate că această structură este independentă de SGBD-ul ales, ea
se realizează conform unui model de date, așa cum este cel relațional. În
realizarea proiectării fizice, trebuie inițial identificat sistemul de baze de date
avut în vedere. Prin urmare, proiectarea fizică este croită după modelul unui
anumit SGBD. Între proiectarea fizică și cea logică există o legătură, deoarece
pe parcursul proiectării fizice sunt luate decizii referitoare la îmbun ăt ățirea
performanțelor, care pot însă afecta structura modelului logic de date.
În cele mai multe situații, obiectivul principal al proiectării fizice este de a
descrie cum se intenționează realizarea implementării fizice a proiectului logic
al unei baze de date. Astfel, în cazul modelului relațional, aceasta presupune:
• extragerea unui set de tabele relaționale (relații) și de constrângeri asupra
acestora, din informațiile prezentate în modelul logic de date (modelul global);
• identificarea structurilor de stocare specifice și metodelor de acc es la
date, astfel încât să se garanteze obținerea unor performanțe optime cu
sistemul respectiv;
• proiectarea mijloacelor care să asigure securitatea sistemului.
###End###

###Title###
Proiectarea tranzacțiilor
###Content###
Tranzacțiile reprezintă evenimente din lumea reală, cum ar fi adăugarea unui
nou angajat, înregistrarea unui nou client, înregistrarea unei note obținute de
un student la o disciplină, etc. Aceste tranzacții trebuie aplicate bazei de date,
pentru a garanta că datele conținute în aceasta rămân „la curent” cu situația
din lumea reală, dar și pentru a susține nevoile informaționale ale utilizatorilor.
O tranzacție poate fi formată din mai multe operații, cum ar fi spre exemplu,
transferul banilor dintr-un cont în altul. Totu și, din punctul de vedere al
utilizatorului, aceste operații realizează o singură sarcină. Din perspectiva
SGBD-ului, o tranzacție transferă baza de date dintr-o stare în alta. SGBD-ul
asigură coerența bazei de date, chiar în cazul unei defecțiuni. Totodată, SGBD-ul
garantează și faptul că odată tranzacția finalizată, modificările realizate sunt
stocate permanent în baza de date și nu pot fi pierdute sau anulate. Dacă dintr-
un motiv oarecare, tranzacția nu poate fi terminată, SGBD-ul este în măsură să
garanteze că modificările realizate de acesta sunt anulate. În exemplul
menționat anterior, cel al transferului de bani, dacă banii sunt debita ți într-un
cont și tranzacția eșuează înaintea creditării celuilalt cont, SGBD-ul va anula și
debitarea. În cazul în care am defini cele două operații (debitarea și creditarea)
###End###

###Title###
Capitolul III - Sisteme de gestiune a bazelor de date
###Content###
Sistemul de gestiune a bazelor de date constituie în prezent un cadru de bază al
sistemelor informaționale și a modificat fundamental modul de operare al unei
organizații. Astfel, în cadrul capitolului trei, am definit sistemul de gestiune a
bazelor de date, am descris evoluția în timp a acestora și am prezentat
principalele facilități pe care le oferă. Totodată, am tratat componentele unui
sistem de gestiune a bazelor de date, funcțiile lui, precum și principalele
avantaje și dezavantaje pe care le aduc introducerea în practică a acestora.
###End###

###Title###
Facilități oferite de un SGBD
###Content###
Spre deosebire de un limbaj de programare obișnuit, în care declararea datelor
este realizată în același loc cu prelucrarea lor, bazele de date dispun de limbaje
separate pentru declarare și prelucrare. Această separare se justifică prin
faptul că într-un program obișnuit datele există efectiv numai pe parcursul
rulării lui, în timp ce într-o bază de date, în general, ele sunt definite o singur ă
dată și nu sunt necesare redefiniri ulterioare pentru fiecare prelucrare realizată.
Practic, un SGBD constă în elemente software care interac ționează cu
programele aplicație ale utilizatorului și cu baza de date. Printre principalele
facilități care sunt oferite de un SGBD menționăm:
1. permite utilizatorului să definească baza de date, de obicei prin intermediul
unui limbaj de definire a datelor (LDD), care permite fiecărui utilizator s ă
specifice tipurile și structurile de date, în timp ce constrângerile asupra datelor
sunt memorate în baza de date;
2. oferă posibilitatea actualizării datelor în baza de date (adăugare,
modificare, ștergere), dar și a extragerii lor prin intermediul limbajului de
manipulare a datelor (LMD). Faptul că există un depozit central al tuturor
datelor și descrierilor acestora permite limbajului de manevrare să ofere o
facilitate de interogare generală a acestor date, denumită limbaj de interogare.
Existența unui limbaj de interogare elimină dificultățile sistemelor bazate pe
fișiere, unde utilizatorul este constrâns să lucreze cu un set fix de interog ări
pentru a evita proliferarea de programe, care creează probleme majore privind
gestionarea acestora.
###End###

###Title###
Avantajele SGBD-urilor
###Content###
I. Controlul redundanței datelor

Așa cum am mai menționat, în sistemele tradiționale bazate pe fi șiere se făcea

risipă de spațiu prin stocarea acelorași informații în mai multe fi șiere. Prin
contrast, în tratarea prin baze de date se încearcă eliminarea redundanței prin
integrarea fișierelor, astfel încât să nu se stocheze mai multe copii ale acelorași
date. Totuși, în tratarea prin baze de date nu se elimină în întregime redundanța,
ci se controlează volumul inerent al acesteia în baza de date. Uneori, pentru
modelarea relațiilor, este necesară dublarea unor articole de date cheie. Alteori,
pentru îmbunătățirea performanțelor, este de dorit să se dubleze unele articole
de date.
2. Coerența datelor
Prin eliminarea sau controlul redundanței se reduce riscul apari ției incoeren ței
datelor. Dacă un articol de date este stocat o singură dată în baza de date, orice
reactualizare a valorii sale trebuie realizată tot o singură dată, iar noua valoare
este disponibilă imediat, pentru toți utilizatorii. Dacă un articol de date este
stocat de mai multe ori, iar sistemul este „conștient” de aceasta, el poate
garanta că toate copiile articolului respectiv sunt menținute coerente. Din
3. Mai multe informații de la aceeași cantitate de date
Odată cu integrarea datelor operaționale, ar putea fi posibil ca organizația
respectivă să extragă informații suplimentare din aceleași date.
4. Partajarea datelor
În general, fișierele sunt deținute de către persoanele sau departamentele care
le utilizează. Pe de altă parte, baza de date aparține întregii organizații sau
instituții și poate fi partajată de către toți utilizatorii autorizați. În acest mod,
mai mulți utilizatori partajează o cantitate mai mare de date. Mai departe, se
pot construi noi aplicații bazate pe datele existente în baza de date, în timp ce
datele adiționale (care nu sunt stocate în mod curent) se pot adăuga fără a fi
necesară definirea repetată a tuturor cerințelor referitoare la acestea. Noile
aplicații se pot baza și pe funcțiile oferite de către sistemul SGBD (cum ar fi
definirea și manipularea datelor și controlul concurenței și refacerii) în loc de a
fi necesar să le furnizeze ele însele.
5.Integritatea crescută a datelor
Integritatea bazei de date se referă la validitatea și coerența datelor stocate.
De obicei, integritatea este exprimată în termeni de constrângeri, care
reprezintă reguli de coerență, pe care baza de date trebuie să le respecte.
Constrângerile se pot aplica articolelor de date dintr-o singur ă înregistrare sau
relațiilor dintre diferite înregistrări. Spre exemplu, o constrângere privind
integritatea ar putea stabili că salariul unui angajat nu poate fi mai mare de o
mie de euro sau că nota pe care o obține un student la o disciplină nu poate fi
mai mică de patru. Din nou, integrarea permite administratorului bazei de date
să definească (iar bazei de date să întărească) constrângerile privind
integritatea.
6.Securitate sporită
Securitatea se referă la protecția bazei de date față de utilizatorii neautorizați.
Fără măsuri de securitate clare și adecvate, integrarea face ca datele să fie
mult mai vulnerabile decât în cazul sistemelor bazate pe fișiere. Totuși,
integrarea va permite administratorului bazei de date să definească (iar bazei
de date să întărească) securitatea acesteia. Aceasta se poate realiza prin
atribuirea unor nume de utilizatori și parole, care să permită identificarea
persoanelor autorizate să utilizeze baza de date (fiecare persoana poate
accesa, în funcție de poziția pe care o are în organizație, un anumit set de date).
Accesul la date permis unui utilizator autorizat poate fi limitat de tipul opera ției
efectuate (extragere, inserare, reactualizare, ștergere). De exemplu,
administratorul bazei de date are acces la toate datele din baza de date, un
manager de fIlială ar putea accesa doar datele legate de filiala respectiv ă, în
timp ce un utilizator de la compartimentul Vânzări ar putea avea acces numai la
datele referitoare la proprietăți, dar nu și la datele „sensibile”, cum ar fi detaliile
despre salariile angajaților sau contractele încheiate.
7. Aplicarea standardelor
Din nou, integrarea permite administratorului bazei de date să definească și să
aplice toate standardele necesare. Acestea ar putea include standarde
departamentale, organizaționale, naționale sau internaționale (pentru diferite
aspecte, cum ar fi formatul datelor) care să faciliteze schimbul de date între
sisteme, convențiile privind denumirile, standardele de documentare,
procedurile de reactualizare și regulile de acces.
8. Economia de scală
Combinarea tuturor datelor operaționale ale organizației într-o singură bază de
date și crearea unui set de aplicații care să funcționeze pentru această unică
sursă de date pot avea ca rezultat micșorarea costurilor. În acest caz, s-ar
putea combina bugetele care ar fi fost alocate în mod normal fiec ărui
departament pentru dezvoltarea și întreținerea propriului sistem bazat pe
fișiere, ceea ce ar putea duce la un total mai scăzut al cheltuielilor, având ca
rezultat o economie de scală. Bugetul combinat poate fi utilizat pentru
achiziționarea unei configurații a sistemului mai adecvate cerințelor și
necesităților organizației respective. Aceasta ar putea consta într-un calculator
cu o configurație mai bună, cu o putere de calcul sporită sau într-o rețea de
calculatoare mai mici.
9. Echilibrul între cerințele aflate în conflict
J
Fiecare utilizator sau departament are propriile sale cerințe, care ar putea intra
în conflict cu ale altora. Din moment ce baza de date se afl ă sub controlul
administratorului bazei de date, acesta poate lua decizii privind proiectarea și
utilizarea operațională a acesteia, care să ducă la folosirea optimă a resurselor
pentru organizația luată în ansamblu. Aceste decizii vor realiza performan țe
optime ale aplicațiilor majore, posibil în detrimentul celor mai puțin importante.
10. Îmbunătățirea accesibilității datelor și capacității de răspuns
Ca rezultat al integrării, datele care depășesc granițele unui departament sunt
direct accesibile utilizatorilor finali. Aceasta creează un sistem cu o mult mai
mare funcționalitate potențială decât ar putea fi folosită, de exemplu, pentru
furnizarea unor servicii mai bune utilizatorului final sau clien ților organizației.
Multe SGBD-uri oferă limbaje de interogare sau generatoare de rapoarte, care
permit utilizatorilor să formuleze întrebări ad- hoc și să obțină aproape imediat
afișarea informațiilor cerute la terminal, fără a fi nevoie de un programator care
să scrie un program de extragere a acestora din baza de date. De exemplu, un
manager de filială ar putea lista toate apartamentele cu o chirie lunar ă de peste
400 euro, prin simpla scriere a următoarei comenzi SQL la un terminal:
SELECT*
FROM proprietate_de_inchiriat
WHERE type = 'Apartament' AND chirie> 400;
11. Productivitate crescută
Așa cum am menționat anterior, un SGBD oferă multe dintre funcțiile standard,
pe care ar trebui să le scrie în mod normal programatorul, în cazul unei aplica ții
bazate pe fișiere. La nivel fundamental, SGBD-ul oferă toate rutinele de nivel jos
pentru manevrarea fișierelor, tipice în programele aplicație. Furnizarea acestor
funcții permite programatorului să se concentreze mai mult asupra
funcționalității specifice cerute de către utilizatori, fără însă a se preocupa de
detaliile de nivel jos privind implementarea. Multe sisteme SGBD furnizeaz ă și
un mediu din a patra generație, care constă în instrumente de simplificare a
dezvoltării de aplicații în domeniul bazelor de date. Aceasta are ca rezultat o
productivitate crescută a programatorului și un timp redus de programare
(împreună cu reducerea corespunzătoare a costurilor).
12. Întreținere îmbunătățită datorită independenței datelor
Descrierile datelor și logicii de accesare a lor în cadrul sistemelor bazate pe
fișiere erau încorporate în fiecare program aplicație, ceea ce făcea ca acestea
să depindă de date. O modificare în structura datelor (de exemplu, atribuirea a
50 de caractere în loc de 40 pentru adresă sau schimbarea modului de stocare
a datelor pe suport fizic) poate necesita schimbări importante în programele
afectate de modificările produse. Prin contrast, într- un SGBD, descri erile
datelor sunt separate de aplicații, ceea ce face ca acestea să fie imune la
modificările din descrierea datelor. Această caracteristică este cunoscut ă sub
denumirea de independență față de date (sau independența datelor). Realizarea
independenței datelor simplifică substanțial întreținerea aplicațiilor din baza de
date.
13. Concurență îmbunătățită
Majoritatea sistemelor bazate pe fișiere se confruntau adesea cu o problemă
importantă, cu influențe negative asupra ceea ce înseamnă gestionarea
eficientă a conținutului unui baze de date. Astfel, dacă doi sau mai mulți
utilizatori aveau permisiunea de a accesa simultan același fi șier, se întâmpla ca
cele două accesări să se suprapună, ceea ce avea evident ca rezultat pierderea
informațiilor sau chiar alterarea integrității datelor respective. În ceea ce
privește un SGBD, una dintre sarcinile importante care-i revin acestuia se referă
la administrarea accesului concurent la baza de date, fapt care are drept
consecință garanția evitării apariției unor astfel de probleme.
14. Îmbunătățirea serviciilor de salvare de siguranță și refacere
Multe sisteme bazate pe fișiere lasă în sarcina utilizatorului responsabilitatea
de a lua măsuri de protecție a datelor, în cazul unor defecțiuni ale sistemului de
calculatoare sau ale programului aplicație.
Aceasta ar putea presupune realizarea unei copii de siguranță a datelor la
intervale scurte de timp (spre exemplu, în fiecare zi). Apari ția unei defecțiuni la
un moment dat, va avea drept consecință preluarea ultimei copii de siguranță,
precum și reluarea muncii realizate în intervalul de timp scurs de la ultima
salvare realizată. Spre deosebire de acestea, SGBD-urile moderne oferă facilit ăți
de minimizare a pierderilor (aferente prelucrărilor realizate) ca urmare a unei
defecțiuni.
###End###

###Title###
Dezavantaje SGBD-urilor
###Content###
1. Complexitatea
Proiectarea funcționalității unui SGBD optim face ca acesta să devină un
element software extrem de complex. Proiectanții și dezvoltatorii bazelor de
date, administratorii de date și de baze de date, precum și utilizatorii finali
trebuie să cunoască (uneori, chiar în detaliu) această func ționalitate, pentru a
putea profita de ea la maximum. Eșecul în înțelegerea sistemului poate cauza
fundamentarea și luarea unor decizii greșite aferente etapei de proiectare, care,
în mod cert, pot conduce la consecințe negative importante pentru fiecare
organizație sau instituție specializată care dispune de un astfel de sistem.
2. Costul
Costul unui SGBD variază semnificativ, în funcție de mediu și de funcționalitatea
pe care o oferă. De exemplu, un SGBD cu un singur utilizator, pentru un
calculator personal, poate costa numai 100 euro. Cu toate acestea, un SGBD
mainframe, multi-utilizator, care deservește sute de utilizatori, poate fi extrem
de scump. Mai există și cheltuielile periodice anuale de întreținere care
reprezintă, de regulă, un procent din prețul acestuia. În acest caz, este clar că
vom alege un SGBD pentru gestionarea unei activități numai în concordanță cu
necesitățile curente: nu are sens să achiziționăm un SGBD scump dacă nevoia
nu o cere, însă nu recomandăm nici achiziționarea unui SGBD ieftin atunci când
volumul de date, dar și cel al prelucrărilor de realizat este mare (mai ales în
cazul gestionării datelor la nivelul bazelor de date distribuite ).
3. Costurile adiționale specifice componentelor hardware
Cerințele de stocare pe suport fizic pentru un SGBD și baza de date ar putea
necesita achiziționarea unui spațiu de stocare suplimentar. Mai mult, pentru
obținerea performanțelor dorite, ar putea fi necesară cumpărarea unui
calculator mai performant, poate chiar unul destinat rulării SGBD-ului. Astfel,
este clar că achiziționarea de componente hardware adiționale conduce la
creșterea cheltuielilor.
4. Costul conversiei
În unele cazuri, costul unui SGBD și al componentelor hardware adi ționale
poate fi nesemnificativ, comparativ cu costul conversiei aplicațiilor existente,
necesare ca acestea să poată funcționa în noul SGBD și în noua configurație
hardware. Acest cost include și prețul instruirii personalului pentru a putea
utiliza noile sisteme și, posibil, angajarea unui personal specializat, care să
ajute la conversia și funcționarea sistemului. Aceste cheltuieli reprezintă unul
dintre motivele principale pentru care unele organizații se „împiedică” de
sistemele existente și nu pot trece la tehnologia modernă specifică bazelor de
date. Termenul de sistem moștenit este utilizat uneori pentru a se face referire
la un sistem mai vechi, de obicei inferior din punct de vedere al funcționalității.
Totodată, există și situații în care anumite organizații renunță la actualizarea
permanentă a componentelor hardware, determinate de conversiile realizate la
nivel software în detrimentul achiziționării unui produs software nou și care
este în concordanță cu necesitățile cerute. Însă, această soluție este una
importantă, cu implicații directe asupra cheltuielilor realizate, dar și a modului
de lucru specific personalului de care se dispune la un moment dat.
5. Dimensiunea
Complexitatea și extinderea funcționalității fac din SGBD-uri elemente software
destul de cuprinzătoare, ce ocupă mult spațiu pe suportul fizic și necesită o
memorie substanțială pentru a funcționa eficient și corect.
6. Performanța
De obicei, un sistem bazat pe fișiere este realizat pentru o anumită aplicație,
cum ar fi facturarea. Ca rezultat, performanțele sunt, de regulă, foarte bune.
Totuși, SGBD-ul este creat pentru a fi mai general, pentru a oferi mai multe
funcționalități, nu una singură. Rezultatul este că unele aplicații ar putea să nu
mai funcționeze tot atât de rapid sau la fel de eficient.
7.Impactul crescut al unei defecțiuni
Centralizarea resurselor mărește vulnerabilitatea sistemului. Din moment ce
toți utilizatorii și toate aplicațiile se bazează pe disponibilitate din partea SGBD-
ului, eșecul oricărei componente a acestuia poate duce la sistarea tuturor
operațiilor.
###End###

###Title###
Regulile lui Codd
###Content###
Pentru a fi considerat relațional, fiecare sistem de gestiune a bazelor de date
trebuie să respecte niște reguli, întâlnite în literatură sub numele de regulile lui
Codd. Modelul de stocare a datelor sub forma unei baze de date rela ționale s-a
dezvoltat pornind de la un articol apărut în anul 1970, „A relational Model of
Data for Large Shared Data Banks”, și care aparține cercetătorului Codd [Codd,
1970, p.377-387]. Astfel, regulile enunțate de cercetător sunt prezentate în
continuare:
Abordarea relațională a bazelor de date R0 - Gestionarea datelor la nivel de
relație.
Toate informațiile din baza de date sunt gestionate numai prin mecanisme
relaționale. Rezultă că SGBD-ul trebuie să-și îndeplineacă toate funcțiile
utilizând ca unitate de informație mulțimea, cu alte cuvinte, să utilizeze diferite
limbaje, așa cum este și SQL, care să opereze la un moment dat pe o relație.
R1 - Reprezentarea logică a datelor.
Informațiile bazei de date relaționale vor fi reprezentate în mod explicit la nivel
logic într-un singur mod și anume ca valori în tabelele de date. Rezultă că toate
datele ar trebui să fie memorate și prelucrate în manieră identică. Informațiile
referitoare la numele tabelelor, al coloanelor, domeniilor, definițiilor tabelelor
virtuale, al restricțiilor de integritate trebuie să fie memorate tot în tabelele de
date.
R2 - Garantarea accesului la date
Accesarea tuturor informațiilor bazei de date se va realiza prin specificarea
numelui tabelei respective, a valorii cheii primare, precum și a numelui de
coloană.
R3 - Regula aferentă valorii NULL
Un SGBD trebuie să permită declararea și utilizarea valorii NULL, cu
semnificația unor date lipsă sau care nu pot fi aplicate. Valorile NULL (care sunt
diferite de șirurile de caractere spațiu sau de cele vide) sunt importante pentru
implementarea restricțiilor de integritate (integritatea entității și integritatea
referențială) aferente modelului relațional.
R4 - Regula specifică metadatelor
Informațiile referitoare la descrierea bazei de date - metadatele - trebuie
specificate la nivel logic în manieră identică cu descrierea datelor propriu- zise.
Practic, utilizatorul va aplica asupra descrierii bazei de date acelea și operații
ca și la datele obișnuite. Sistemul nu trebuie să facă diferențe între descrierea
datelor și a metadatelor utilizând o singură structură, și anume cea relațională.
R5 - Facilități ale limbajelor utilizate
Un sistem relațional trebuie să facă posibilă utilizarea mai multor limbaje, în
diferite moduri. Trebuie să existe cel puțin un limbaj de nivel înalt ale cărui
instrucțiuni să poată exprima oricare din următoarele operații: definirea
tabelelor, a tabelelor virtuale, manevrarea datelor, definirea tuturor restric țiilor
de integritate, garantarea și autorizarea accesului la date, precum și
prezentarea limitelor tranzacțiilor.
R6 - Actualizarea bazei de date
Fiecare SGBD trebuie să permită manipularea unei tabele (de baz ă sau virtual ă),
atât în cazul actualizării datelor în baza de date, cât și pentru operații de
regăsire a acestora. În cazul unei operații care va modifica conținutul unei baze
de date, trebuie să se lucreze la un moment dat pe o relație întreagă.
R7 - Independența fizică a datelor
Programele de aplicație nu trebuie să fie afectate de modificările realizate în
modul de reprezentare a datelor sau în metodele de acces. O schimbare a
structurii fizice a datelor nu trebuie să blocheze funcționarea programelor de
aplicație.
R8 - Independența logică a datelor
Programele de aplicație nu trebuie să fie afectate de modificările efectuate
asupra relațiilor care formează baza de date.
R9 - Regula aferentă restricțiilor de integritate
Toate restricțiile de integritate trebuie să poată fi definite prin intermediul
limbajului folosit de SGBD pentru definirea datelor și să fie memorate.
R10 - Distribuirea geografică a datelor
În cazul în care datele sunt distribuite, programele de aplicație să fie logic
aceleași cu cele utilizate în cazul în care datele sunt fizic centralizate. Practic,
în această situație, utilizatorul ar trebui să perceapă aceste date ca fiind
centralizate și nu aparținând unor stații diferite de lucru, aflate în zone
geografice diferite.
R11 - Actualizarea tabelelor virtuale
În cadrul abordării relaționale, nu toate atributele sunt actualizabile, ceea ce
înseamnă că nu toate tabelele virtuale pot fi actualizate.
R12 - Prelucrarea datelor la nivel de bază
Dacă SGBD-ul posedă un limbaj de bază de nivel scăzut orientat pe prelucrarea
tuplurilor și nu pe cea a relațiilor, atunci acest limbaj nu trebuie folosit pentru a
se evita restricțiile de integritate sau restricțiile introduse prin utilizarea
limbajelor relaționale de nivel înalt.
###End###