Baze de Date ... Lupasc A.

BAZE DE DATE
- Suport de curs
Lect.dr. Adrian LUPAC
CUPRINS
Capitolul I Fundamente ale bazelor de date ........................................................................................ 4
Ce este a!a de date" ...................................................................................................................................... #
Ar$itecturi a%e siste&e%or de a!e de date .................................................................................................... '
Capitolul II Proiectarea i administrarea unei baze de date ............................................................. 10
Cic%u% de (ia)* a% siste&e%or in+or&a)iona%e ............................................................................................... ,,
Cic%u% de (ia)* a% unui siste& de a!e de date ............................................................................................. ,,
Proiectarea a!e%or de date ........................................................................................................................... ,-
Proiectarea conceptual .................................................................................................................................................. 14
Proiectarea logic ............................................................................................................................................................ 14
Proiectarea fizic ........................................................................................................................................................... 15
Proiectarea tran!ac)ii%or .............................................................................................................................. ,.
Capitolul III Sisteme de gestiune a bazelor de date ........................................................................... 17
E(o%u)ia siste&e%or de /estiune a a!e%or de date ...................................................................................... ,'
0aci%it*)i o+erite de un S1BD ....................................................................................................................... 23
A(anta4e%e 5i de!a(anta4e%e S1BD-uri%or .................................................................................................... 2,
Co&ponente%e unui S1BD ........................................................................................................................... 2.
0unc)ii%e S1BD-u%ui ...................................................................................................................................... 2'
Capitolul IV bordarea rela!ional" a bazelor de date ....................................................................... #1
Re/u%i%e %ui Codd .......................................................................................................................................... -,
0unda&ente a%e &ode%u%ui re%a)iona% ......................................................................................................... --
Le/*turi 6ntre re%a)ii ...................................................................................................................................... -'
Legtura binar 1-1 (unu la unu) .................................................................................................................................... 38
Legtura binar 1-n (unu la mai muli) ........................................................................................................................... 39
Legtura binar n-n (mai muli la mai muli) ................................................................................................................. 4
Legtura !intre trei "au mai multe relaii ........................................................................................................................ 41
A%/era re%a)iona%* operatorii re%a)iona%i ................................................................................................. 7-
Pro%e&e re!o%(ate ........................................................................................................................................ #3
$ibliogra%ie ............................................................................................................................................. &7
#aze !e !ate $ %uport !e cur" $ &ur" po"tuni'er"itar $ (nformatic $ )alai - *1
3
+un!amente ale bazelor !e !ate
Capitolul I Fundamente ale bazelor de date
****************************************************************************************
Obiectivele capitolului
Capitolul Fundamente ale bazelor de date prezint evoluia i ascensiunea pn 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 poziionm teoria bazelor de
date n cadrul tehnologiilor informaionale, am prezentat cteva definiii relevante ale
conceptului de baz de date formulate de cercettori i profesori care s-au remarcat cu
preocupri 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 nelegere general a ceea ce reprezint astzi baza de
date.
****************************************************************************************
Tehnologiile informaionale influeneaz continuu i produc modificri substaniale
asupra mijloacelor de lucru din ntreaga lume. nformaii care erau altdat stocate n
depozite pline de dulapuri, pot fi accesate astzi prin intermediul unei singure apsri a
butonului mouse-ului. Astfel, pentru stocarea informaiilor din orice mediu imaginabil n zilele
noastre sunt folosite sistemele de baze de date. De la bazele de date mari, aa cum sunt
sistemele care permit rezervarea on-line a biletelor pentru companiile aeriene i pn la
fiele dintr-o bibliotec, sistemele de baze de date sunt folosite pentru memorarea i
distribuirea datelor de care ncep s depind tot mai mult vieile noastre.
Pn n urm cu civa ani, sistemele mari de baze de date se gseau numai pe
calculatoare de tip mainframe
1
. ns, aa cum era i firesc, proiectarea, achiziionarea sau
ntreinerea unei astfel de maini reprezenta o sarcin costisitoare i dificil de realizat. Odat
cu apariia calculatoarelor din clasa staiilor de lucru, pe care le ntlnim la tot pasul
(biblioteci, laboratoare de informatic, departamente de lucru, etc.) i care sunt puternice i
n acelai timp destul de ieftine, programatorii au posibilitatea de a proiecta rapid i la costuri
reduse produse informatice care s permit ntreinerea i distribuirea datelor.
Cercetarea aferent bazelor de date are aproape 35 de ani de istorie, ani care au
condus n mod inevitabil la cele mai relevante i importante dezvoltri ale ingineriei software.
n mod natural, tehnologiile specifice bazelor de date, arhitecturile i cadrele conceptuale au
fost tot mai bine consolidate n ultimile decade. Mai mult, n ultimii ani, managementul
bazelor de date a evoluat astfel nct bazele de date au devenit o component cheie a
sistemelor informaionale moderne. Acest aspect a provocat un impact adnc precum i
modificri semnificative n modul de lucru al instituiilor i organizaiilor, contribuind ntr-o
1
Mainframe reprezint un tip de calculator de mare putere care este utilizat cel mai adesea pentru gestiunea
bazelor de date de dimensiuni foarte mari, precum i a altor aplicaii asemntoare, care necesit o capacitate
de stocare foarte mare i o interaciune puternic cu un numr mare de utilizatori, concretizat printr-un volum
foarte mare de comunicaii de date.
4
msur relevant la adoptarea celor mai adecvate decizii care s le poat garanta succesul
n afaceri i nu numai. n acest context, este important s menionm anumii factori care au
contribuit la aceast explozie: noile tehnici i instrumente de modelare, cele mai importante,
fiind cele care se bazeaz pe o gndire orientat obiect, apariia procesrii de tipul client-
server, diminuarea semnificativ a preurilor aferente att componentei hardware ct i a
celei software i, nu n ultimul rnd, necesitatea unei administrri eficiente i corecte a
cantitilor tot mai mari de informaii care caracterizeaz activitile fiecrei organizaii din
zilele noastre.
n prezent, bazele de date fac parte tot mai mult din viaa noastr de zi cu zi n aa
msur, nct uneori nici mcar nu mai contientizm c le utilizm. Atunci cnd cumprm
ceva de la un supermarket, probabil c va fi accesat o baz de date. Casierul va trece un
cititor de coduri de bare peste fiecare dintre articolele pe care le achiziionm. Acesta este
conectat la un sistem informatic pentru baze de date, care utilizeaz codul de bare pentru a
identifica preul produsului pe care l-am ales, evident dintr-o baz de date care gestioneaz
produsele. De asemenea, dac stocul pentru un produs scade sub o anumit limit, este
posibil ca sistemul s emit n mod automat o comand ctre un furnizor, pentru a obine un
stoc suplimentar din acel articol.
Atunci cnd vizitai o bibliotec (!dac se mai ntmpl acest lucru.) constatai c
exist o baz de date care conine informaii detaliate despre crile care formeaz fondul de
carte al bibliotecii. Practic, pentru a prentmpina anumite cerine, aceste sisteme se
bazeaz pe un index computerizat care permite cititorului s identifice o carte dup titlu,
autor sau subiectul acesteia.
Ce este baza de date?
Majoritatea bazelor de date iau natere ncepnd cu o list ntr-un editor de texte sau
ntr-o foaie de calcul. La momentul respectiv, suntem tentai s credem c a fost aleas cea
mai bun soluie, att timp ct necesitile informaionale sunt satisfcute, este adevrat, n
contextul unei cantiti reduse de informaii. n timp ns, acest volum crete (spre exemplu,
odat cu creterea activitii unei organizaii, ceea ce face ca soluiile (privite iniial ca fiind
cele mai adecvate) s nu mai fie potrivite. Mai mult, pe msur ce lista devine tot mai mare,
ncep s apar redundane i inconsistene la nivelul datelor gestionate. Datele devin greu de
neles sub forma listei, iar posibilitile de cutare, regsire i extragere a subseturilor de
date pentru revizuire, actualizare sau utilizare devin extrem de limitate. Odat cu apariia
acestor probleme, o idee bun, chiar o necesitate n anumite situaii, ar fi aceea al
transferului acestor date ntr-o baz de date creat cu ajutorul unui sistem de gestiune al
bazelor de date.
n prezent ne este tot mai clar faptul c explozia informaional este de ani buni
trstura definitorie care caracterizeaz activitile fiecrei organizaii sau instituii, indiferent
de domeniul su de activitate. Volumul tot mai nsemnat de informaii nu mai poate fi utilizat
eficient cu ajutorul mijloacelor tradiionale. Practic, constatm c procesul de prelucrare
automat a datelor prin intermediul sistemelor electronice de calcul a devenit o necesitate
pentru majoritatea domeniilor de activitate. n acest context, putem afirma c cea mai
evoluat metod de organizare a datelor n vederea prelucrrii lor automate o ntlnim la
bazele de date.
n literatura de specialitate exist numeroase definiii aferente conceptului de baz de
date. n continuare vom prezenta cteva dintre ele, care, n opinia noastr, acoper cel mai
bine conceptul de baz de date.
,O baz de date conine toate informaiile necesare despre obiectele ce intervin ntr-o
mulime de aplicaii, relaii logice ntre aceste informaii i tehnicile de prelucrare
5
corespunztoare. n bazele de date are loc o integrare a datelor, n sensul c mai multe
fiiere sunt privite n ansamblu, eliminndu-se pe ct posibil acele informaii redundante. De
asemenea, este permis accesul simultan la aceleai date, care se regsesc n acelai loc
sau sunt distribuite spaial, a mai multor persoane de pregtiri diferite, fiecare cu stilul
personal de lucru [Bsc, 1997, p.11].
Referitor la definiia prezentat anterior, putem spune c avem unele reineri n ceea
ce privete utilizarea conceptului de informaie. Astfel, autorul vede baza de date ca un
ansamblu de informaii, prere pe care o mprtim parial i numai n cazul n care se face
referire la baza de date n general, dar nu i la o baz de date relaional. Este cert faptul c
atunci cnd facem referire la baza de date relaional, nu putem vorbi de informaii, ci numai
de date.
,Totodat, putem privi baza de date ca ansambluri unitare de date, structurate,
corelate logic ntre ele i memorate mpreun cu descrierea formal a structurii lor i a
legturilor logice dintre ele, a crui gestionare este realizat de un sistem software unitar i
specializat, numit sistem de gestiune a bazei de date [Georgescu, Georgescu, 2005, p.63].
O definiie complet i explicativ a noiunii de baz de date este oferit n [Velicanu et
al., 2003, p.51]. Astfel, aceasta reprezint un ansamblu de colecii de date:
organizat, pe niveluri de organizare a datelor (conceptual, logic, fizic), aa cum reiese i
din arhitectura pe niveluri a unui sistem de baze de date;
coerent, conform restriciilor de integritate i a legturilor 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 muli utilizatori, concomitent, pot
obine informaiile dorite atunci cnd au nevoie de ele.
Profesorul M. Fotache prezint i analizeaz o definiie academic a bazei de date.
Astfel, n opinia acestuia, baza de date reprezint un ansamblu structurat de fiiere care
grupeaz datele prelucrate n aplicaiile informatice ale unei persoane, grup de persoane,
ntreprinderi, instituii, etc. Din punct de vedere formal, definete baza de date ca ,o colecie
de date aflate n interdependen, mpreun cu descrierea datelor i relaiilor dintre ele sau,
similar, o colecie de date folosit ntr-o organizaie, colecie care este automatizat,
partajat, definit riguros (formalizat) i controlat la nivel central [Fotache, 2005, p.14].
Plecnd de la definiiile prezentate anterior, putem afirma c o baz de date
relaional reprezint o colecie partajat de date, ntre care exist diferite legturi logice
(mpreun cu o descriere a acestora), proiectat pentru a satisface necesitile
informaionale ale fiecrei organizaii. Totodat, putem privi o baz de date ca un instrument
pentru organizarea i colectarea tuturor informaiilor, astfel nct s se satisfac toate
necesitile informaionale ale utilizatorilor ei.
Definiia prezentat anterior trebuie analizat n detaliu pentru a putea fi n msur s
dobndim o mai bun nelegere a conceptului de baz de date. Baza de date reprezint un
depozit de date unic, larg, care este definit o singur dat i este utilizat simultan de diferite
departamente sau utilizatori. Aceast soluie substituie crearea mai multor fiiere separate cu
date de cele mai multe ori considerate a fi redundante i presupune integrarea tuturor datelor
necesare, dublarea lor fiind n acest caz minimal. De aici decurge un prim avantaj
semnificativ: baza de date nu mai este deinut de un singur departament, ci constituie acum
o resurs comun, partajat. Pe de alt parte, baza de date conine nu numai datele
,
operaionale ale unei organizaii sau instituii, ci i o descriere a acestora, ntlnite n
literatur sub denumirea de metadate (date despre date).
Atunci cnd analizm necesitile informaionale ale unei organizaii, avem n vedere
n principal identificarea entitilor, atributelor i relaiilor. Putem privi o entitate ca un obiect
distinct (o persoan, un departament, un concept sau un eveniment) care aparine unei
organizaii i care trebuie reprezentat n baza de date. tributul este o proprietate care
descrie un aspect oarecare al obiectului pe care dorim s-l nregistrm, iar relaia se refer la
o asociaie ntre diferite entiti. Astfel, putem spune c baza de date conine entitile,
atributele, dar i relaiile (legturile) logice dintre ele. n capitolul 4 vom arta cum se
concretizeaz din punct de vedere practic legturile logice dintre relaii, prin introducerea
conceptului de cheie strin.
Arhitecturi ale sistemelor de baze de date
n literatura de specialitate sunt prezentate mai multe tipuri de arhitecturi ale
sistemelor de baze de date. Nou ne-au atras atenia 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 legturilor dintre ele. n funcie de ceea ce se
evideniaz 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-dependenelor dintre ele, aa cum se poate observa
n figura !"!.
D a t e
S o f t w a r e
E l e m e n t e a u x i l i a r e
Figura 1.1. rhitectura pe componente a unui sistem de baze de date
Aa cum se observ, componentele specifice arhitecturii din figura !"! sunt:
a. datele sunt organizate ntr-o baz de date care conine:
colecii de date propriu-zise;
dicionarul de date (structura de date, restriciile de integritate, vederile, etc.);
fiierele anexe, aa cum sunt cele de index.
b. software-ul este aferent realizrii i exploatrii bazei de date i conine:
sistemul de gestiune a bazei de date;
programele de aplicaie 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 funcionarea
ntregului sistem de baze de date:
-
1. un set de proceduri automate (rutine) i manuale;
2. reglementri legale i administrative;
3. mijloace hardware utilizate;
4. persoane implicate pe categorii de utilizatori.
*. rhitectura pe niveluri structureaz un sistem de baze de date pe trei niveluri i ofer o
imagine despre modul de organizare i funcionare al acestuia (figura !"#).
M a n i p u l a r e d a t e
V e d e r i a l e
b a z e i d e d a t e
D e s c r i e r e d a t e
N i v e l u r i d e
o r g a n i z a r e
d a t e
P r o g r a m a t o r
d e a p l i c a t i e
A d m i n i s t r a t o r
b a z a d e d a t e
I n g i n e r
a n a l i s t ! d e
s i s t e m
" o g i c
C o n c e p t u a l
F i z i c
P r o g r a m
a p l i c a t i e 1
S t r u c t u r a e x t e r n a
( l o g i c a )
S G B D
S . O .
S t r u c t u r a
c o n c e p t u a l a
S t r u c t u r a i n t e r n a
( f i z i c a )
#az !e !ate
. . . . . .
. . .
Figura 1.2. rhitectura pe niveluri a unui sistem de baze de date
n arhitectura prezentat n figura !"# sunt redate nivelurile de organizare
(reprezentare) a datelor n baza de date i legturile dintre ele: nivelul conceptual, nivelul
logic i nivelul fizic.
a. nivelul conceptual este dat de viziunea administratorului bazei de date asupra datelor.
Legat de acest nivel, se pot meniona urmtoarele aspecte:
administratorul realizeaz structura conceptual a bazei de date, eventual cu ajutorul
instrumentelor oferite de un $%&'
2
;
structura conceptual se obine utiliznd un anumit model de date pentru baza de
date, precum i o tehnic de proiectare ct mai adecvat;
structura conceptual este o reprezentare n interiorul sistemului a realitii pe care
baza de date o transcrie;
viziunea administratorului asupra bazei de date este independent de aplicaiile care
vor fi dezvoltate (independena logic);
rezultatul nivelului conceptual este schema conceptual;
realizarea schemei corespunde unei activiti de modelare pentru c este vorba
despre o transpunere n termeni abstraci a entitilor lumii reale;
odat definit, schema conceptual trebuie confruntat cu lumea real pentru
identificarea i soluionarea neconcordanelor sau a omisiunilor; datorit caracterului
*
SGBD $ %i"tem !e )e"tiune a #azelor !e .ate
8
su global i unitar, se recomand ca schema conceptual s fie gestionat de o
singur persoan [Georgescu, Georgescu, 2005, p.67].
b. nivelul logic este dat de viziunea programatorului asupra datelor. Legat de acest nivel
se pot prezenta urmtoarele aspecte:
programatorul realizeaz programele de aplicaie pentru descrierea i manipularea
datelor, scrise ntr-un $%&';
programele implementeaz structura extern (logic) a datelor;
structura extern este dedus din structura conceptual;
structura extern reprezint viziunea programatorului asupra bazei de date pentru o
anumit aplicaie;
viziunea programatorului este independent de suportul tehnic de informaie
(independena fizic);
rezultatul nivelului logic este schema extern, ca parte din schema conceptual,
implementat cu ajutorul unui $%&'.
c. nivelul fizic este dat de viziunea analistului (inginerului) de sistem asupra datelor i are
rolul de a descrie modul n care sunt stocate datele n baza de date. Aferent nivelului fizic
putem meniona urmtoarele:
analistul de sistem este cel cruia i revine sarcina de a realiza structura intern
(fizic);
structura intern este dedus din cea extern conform unor tehnici i metode de
alocare pe suport fizic;
structura intern corespunde descrierii datelor pe suportul fizic de informaie;
rezultatul la nivelul fizic este schema intern (fizic) care se definete n termeni de
fiiere i nregistrri;
implementarea schemei interne se face cu ajutorul sistemului de gestiune a fiierelor
(SGF) din cadrul $%&'-ului i/sau din sistemul de operare, prin gestiunea fizic a
perifericelor.
Perspective asupra unei baze de date
Fiecare baz de date o putem privi din diferite perspective, cum ar fi:
perspectiva utilizatorului, care lucreaz cu diferite pri componente ale unei baze
de date, numite vederi. Vederile sunt descrise prin intermediul unor subscheme n
sublimbaje ale limbajului de descriere a datelor (LDD). Totodat, utilizatorii pot
primi rspunsuri la cererile pe care le formuleaz prin intermediul limbajului de
prelucrare a datelor;
perspectiva administratorului bazei de date, care integreaz toate vederile
referitoare la baza de date ntr-un singur model numit schem conceptual.
Practic, aceast schem conceptual constituie nivelul logic al bazei de date;
perspectiva implementatorului bazei de date n foarte multe situaii, el coincide cu
administratorul bazei de date, care privete baza de date ca pe o colecie de fiiere
memorate pe diferite medii externe. Acesta constituie nivelul fizic al bazei de date
i care este practic singurul nivel care exist efectiv.
9
Proiectarea /i a!mini"trarea unei baze !e !ate
Capitolul II Proiectarea #i administrarea unei baze de date
****************************************************************************************
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 (roiectarea )i administrarea unei baze de date urmrete atingerea
urmtoarelor 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 tranzaciilor.
****************************************************************************************
n prezent observm c avalana produselor software o depete net pe cea a
componentelor hardware. ns, din pcate, dac privim evoluia n timp a dezvoltrii
sistemelor software constatm c nu este impresionant. n ultimile decade am observat o
expansiune a aplicaiilor software, de la cele mici i relativ simple i care presupuneau cteva
linii de cod, pn la cele mari, destul de complexe i care presupuneau scrierea a milioane i
milioane de linii de cod. ns, n mod normal, aceste aplicaii necesitau i o ntreinere
constant, care urmrea n primul rnd corectarea erorilor detectate, mbuntirea
funcionalitii prin implementarea altor cerine care veneau din partea utilizatorului. Totodat,
aceast ameliorare avea n vedere i adaptarea acestor aplicaii la platforme multiple, astfel
nct, indiferent de locul n care rula aplicaia, funcionalitatea ei s nu fie afectat.
Toate aceste aspecte specifice ntreinerii au condus la un consum tot mai nsemnat
de resurse, iar rezultatul nu a ntrziat s apar: multe proiecte importante se aflau n
ntrziere, bugetul alocat lor devenea constant insuficient, ntreinerea se face tot mai greu,
iar performanele ntrziau s apar (cam 80-90% din sisteme nu-i atingeau scopul).
Practic, aceast situaie a condus la ceea ce se numea la vremea respectiv ,criza de
software. Printre principalele motive care au stat la baza acestei crize putem aminti: lipsa
specificaiilor complete referitoare la cerine, a unei metodologii adecvate de realizare, dar i
proasta partiionare a proiectrii n componente uor de manevrat. Astfel, ca o soluie care s
permit ieirea din criz i soluionarea problemelor menionate anterior, a fost propus o
nou abordare structurat privind dezvoltarea produselor software, numit ciclu de via al
sistemelor informaionale.
1
Ciclul de via al sistemelor informaionale
Putem privi sistemul informaional ca un ansamblu de fluxuri i circuite informaionale,
organizate ntr-o concepie unitar i care asigur legtura dintre sistemul decizional (de
conducere) i cel operaional (de execuie).
Trebuie menionat faptul c nu trebuie s confundm sistemul informaioanal cu cel
informatic (din pcate, am constatat c exist studii sau preri care le privesc pe cele dou
ca fiind unul i acelai lucru). Astfel, sistemul informatic reprezint un ansamblu structurat de
elemente intercorelate funcional, utilizat pentru culegerea, prelucrarea, transmiterea i
stocarea datelor cu ajutorul mijloacelor automate de prelucrare a datelor. Scopul acestuia
este de a automatiza procesul informaional i de a sta la baza fundamentrii deciziilor. n
plus, sistemul informatic este inclus n cel informaional i i ofer acestuia noi valene, att
sub aspect calitativ, ct i cantitativ. Acest lucru se realizeaz prin implementarea de ctre
sistemul informatic a unor modele matematice i prin utilizarea tehnicii electronice de calcul.
ncepnd cu anii '70, treptat, sistemele de baze de date le-au luat locul celor bazate pe
fiiere, ca parte a infrastructurii sistemelor informaionale din cadrul unei organizaii. n
acelai timp, a avut loc o recunoatere treptat a faptului c datele constituie o resurs
comun, important, vital n anumite situaii, care trebuie tratat cu respect, ca toate
celelalte resurse ale organizaiei. Acest aspect a avut ca rezultat crearea unor departamente
funcionale denumite administrarea datelor i administrarea bazelor de date, care erau
responsabile cu administrarea i controlul datelor.
Astfel, considerm c baza de date este o component de baz a unui sistem
informaional, iar dezvoltarea i utilizarea sa trebuie privite i analizate din perspectiva
cerinelor mai largi ale organizaiei. n acest context, ciclul de via al sistemului informaional
dintr-o organizaie este puternic legat de ciclul de via al sistemului de baze de date care l
susine. De obicei, etapele aferente ciclului de via al unui sistem informaional includ:
planificarea, analiza cerinelor, proiectarea (inclusiv a bazei de date), prototipizarea,
implementarea i ntreinerea.
Ciclul de via al unui sistem de baze de date
Etapele specifice ciclului de via al unei aplicaii de tip baz de date sunt prezentate
n figura #"!. Trebuie menionat c etapele ciclului de via ale unei astfel de aplicaii nu sunt
strict secveniale, ci pot presupune revenirea la o etap anterioar i repetarea lor. Spre
exemplu, dac apar anumite probleme n timpul proiectrii bazei de date, se poate reveni la
etapa anterioar care are drept obiectiv colectarea i analiza cerinelor.
Principalele activiti asociate fiecrei etape din ciclul de via al aplicaiei de tip baz
de date sunt:
planificarea bazei de date presupune planificarea modului n care etapele ciclului de
via pot fi realizate cel mai eficient;
delimitarea granielor sistemului se refer la specificarea scopului i limitelor aplicaiei, a
utilizatorilor si i a domeniilor de aplicaie. nainte de a ncepe proiectarea unei aplicaii
de tip baz de date, este foarte important s definim limitele (graniele) sistemului avut n
vedere i modul n care acesta realizeaz interfaa cu alte pri ale sistemului
informaional al organizaiei. Practic, includerea i delimitarea granielor unui sistem este
o etap important, nu numai pentru utilizatorii i aplicaiile curente, ci i pentru cele din
viitor;
11
P r o i e c t a r e a
P l a n i f i c a r e a
D e l i m i t a r e a g r a n i t e l o r
s i s t e m u l u i
C o l e c t a r e a s i
a n a l i z a c e r i n t e l o r
P r o i e c t a r e a c o n c e p t u a l a
P r o i e c t a r e a l o g i c a
P r o i e c t a r e a f i z i c a
P r o t o t i p i z a r e a m p l e m e n t a r e a
T e s t a r e a
n t r e t i n e r e o p e r a t i o n a l a
A l e g e r e a S G B D - u l u i
P r o i e c t a r e a a p l i c a t i e i
Figura 2.1. *iclul de via al unei aplicaii de tip baz de date
colectarea )i analiza cerinelor are n vedere analiza cerinelor colectate de la utilizatori,
dar i a domeniilor de aplicaie. Mai precis, aceast etap vizeaz procesul de culegere i
analiz a informaiilor aferente organizaiei pentru care se proiecteaz baza de date
respectiv, dar i utilizarea acestora n vederea identificrii cerinelor utilizatorilor privind
noul sistem;
proiectarea bazei de date include proiectarea conceptual, logic i fizic. n sens larg,
principalele scopuri urmrite atunci cnd se dorete proiectarea unei baze de date se
refer la:
1*
reprezentarea datelor i a relaiilor logice dintre acestea, necesare tuturor
domeniilor de aplicaie i principalelor grupuri de utilizatori;
oferirea unui model de date care s permit realizarea tranzaciilor asupra datelor;
specificarea unui proiect minimal i structurat n mod adecvat pentru realizarea
cerinelor stabilite referitoare la performanele noului sistem;
alegerea $%&'-ului este o etap opional i presupune alegerea unui $%&'
adecvat pentru aplicaia realizat. Aceast alegere poate fi fcut n orice moment
anterior proiectrii logice, cu condiia s fie disponibile suficiente informaii
referitoare la cerinele sistemului, cum ar fi performana sau constrngerile de
securitate i integritate;
proiectarea aplicaiei are n vedere proiectarea interfeei cu utilizatorul i a
programelor care utilizeaz i prelucreaz baza de date;
prototipizarea este tot o etap opional i presupune construirea unui prototip de
sistem care s permit proiectantului, dar i utilizatorului, s evalueze modul de
funcionare al noului sistem;
implementarea la ncheierea etapelor de proiectare, ne aflm n situaia de a
implementa baza de date i programele aplicaie. mplementarea bazei de date se
realizeaz prin utilizarea limbajului de definire a datelor (LDD), corespunztor
sistemului de gestiune a bazelor de date ales. nstruciunile limbajului LDD sunt
compilate i utilizate pentru a permite crearea schemei bazei de date. Totodat,
toate vederile specificate de ctre utilizatori sunt definite n aceast etap;
testarea este etapa n care se testeaz aplicaia i se identific eventualele
neconcordane dintre cerinele utilizatorilor i rezultatul furnizat de aceasta;
ntreinerea operaional presupune o monitorizare continu a aplicaiei realizate,
iar dac este nevoie, vor fi ncorporate cerine noi, parcurgnd etapele precedente
ale ciclului de via.
Proiectarea bazelor de date
Connoly i colaboratorii si [Connoly et al., 2002, p.281-282] identific i descriu trei
tipuri de proiectri:
conceptual, care se refer la dezvoltarea unui model informaional independent de orice
considerent privitor la aspectul fizic al datelor;
logic, care vizeaz construirea unui model informaional bazat pe unul din modelele
tradiionale (+-,
3
, relaional, --
4
, -,
5
), dar independent de tipul $%&'-ului ales i de
alte aspecte fizice ale modelului;
fizic urmrete implementarea efectiv a bazei de date pe suportul de stocare, inclusiv
acele aspecte care in de asigurarea i garantarea securitii datelor.
Proiectarea corespunztoare bazei de date este o etap foarte important, mai ales c
trebuie s fie capabil s garanteze buna funcionare a acesteia i a oricrei aplicaii care o
utilizeaz. n lipsa unei proiectri adecvate a bazei de date, aceasta poate prezenta mai
multe deficiene, cum ar fi:
3
E-R Entitate Relaie
4
OO Orientat Obiect
5
OR Obiectual Relaional
13
compromiterea integritii datelor deoarece restriciile de integritate nu pot fi proiectate
sau implementate corect;
datele sunt redundante, iar aplicaiile individuale se ,aglomereaz n ncercarea de a se
asigura sincronizarea datelor;
performanele sunt afectate deoarece este posibil ca pentru finalizarea unei instruciuni
(spre exemplu, instruciunea $elect
6
) s fie necesare interogri suplimentare.
Proiectarea conceptual$
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 dorete a fi
modelat (parte din activitatea unei organizaii). Acest model de date va fi construit prin
utilizarea informaiilor aferente specificaiilor cerinelor utilizatorului. Proiectarea conceptual
a bazei de date este complet independent de detaliile de implementare, cum ar fi
elementele de software ale sistemului $%&' avut n vedere, programele de aplicaie,
platforma hardware sau orice alte consideraii fizice. Totodat, trebuie s menionm c este
important ca pe tot parcursul procesului de realizare a modelului conceptual de date, acesta
s fie permanent testat i validat conform cerinelor utilizatorului. Practic, acest model
constituie o surs important de informaii pentru faza de proiectare logic.
Proiectarea logic$
Aceast faz are ca rezultat crearea unui model de date logic aferent activitilor sau
proceselor pe care dorim s le modelm. Modelul de date conceptual creat n faza
precedent este rafinat i transpus ntr-un model de date logic. Acesta este influenat de
ctre modelul de date avut n vedere pentru baza de date (spre exemplu, modelul de date
relaional pe care l vom detalia n capitolul V).
Spre deosebire de cellalt model, care este independent de toate consideraiile fizice,
modelul logic este creat plecnd de la modelul de date principal al sistemului $%&' int. Cu
alte cuvinte, tim c $%&'-ul este, de exemplu, relaional, ierarhic sau orientat spre obiecte.
ns, se ignor alte aspecte ale $%&'-ului ales i, mai ales, fiecare detaliu fizic, aa cum
sunt structurile de stocare.
Pe parcursul realizrii modelului logic de date, se efectuez testarea i validarea
permanent a acestuia n conformitate cu cerinele utilizatorului. Tehnica de normalizare este
utilizat pentru a testa corectitudinea modelului logic de date. Practic, normalizarea
garanteaz c relaiile derivate din modelul de date nu prezint redundane, care pot cauza
anomalii (la implementare) la actualizarea bazei de date. Altfel spus, normalizarea este
procesul prin care se elimin redundana datelor din baza de date i se construiete un
model de baz de date care susine diverse cerine funcionale i structuri alternative ale
bazei de date.
Normalizarea presupune mprirea unei relaii (care include la momentul respectiv
toate atributele necesare problemei) n mai multe relaii ntre care se definesc diferite legturi
logice. Principalele obiective ale normalizrii sunt [Fotache, 2005, p.41-42]:
minimizarea spaiului necesar stocrii datelor;
minimizarea riscului apariiei de date inconsistente n cadrul bazei de date;
,
$elect este o instruciune specific limbajului $./ Structured Query Language care permite extragerea
datelor din baza de date.
14
minimizarea numrului de anomalii ce pot aprea la actualizare (inserarea datelor, dar
mai ales modificri i tergeri);
ameliorarea structurii bazei de date, reprezentarea diverselor conexiuni dintre
atributele acesteia;
diminuarea nevoii de reorganizare periodic a modelului.
Exist un numr de reguli care se aplic n normalizare. n continuare vom prezenta
doar primele trei reguli care sunt n msur s garanteze definirea unei structuri logice a
bazei de date ntr-o form acceptabil (n care ns redundana nu este eliminat complet):
1. Toate atributele trebuie specificate o singur dat (forma 0 normal);
*. Fiecare atribut trebuie s depind n totalitate de cheia primar a relaiei pe care o descrie
(forma 00 normal). Aceast regul se realizeaz prin repartizarea atributelor ntr-o relaie,
astfel nct fiecare dintre ele va depinde n totalitate de cheia primar.
3. Pentru a putea fi n forma 000 normal, fiecare relaie trebuie s aib o singur cheie
primar.
Totodat, modelul logic de date reprezint o surs important de informaii pentru faza
de proiectare fizic, punnd la dispoziia 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 ntreinere operaional din ciclul de via al unei aplicaii cu baze de date. Dac este
ntreinut i mbuntit adecvat, modelul de date permite efectuarea unor modificri viitoare
n programele aplicaie i reprezentarea corect i eficient a datelor de ctre baza de date.
Proiectarea %izic$
Proiectarea fizic a bazelor de date este a treia faz din procesul de proiectare a unei
baze de date, n care proiectantul stabilete cum va fi ea implementat. Aa cum am vazut
deja, faza precedent presupunea realizarea unei structuri logice, cu alte cuvinte se referea
la definirea relaiilor, atributelor i legturilor dintre ele. Cu toate c aceast structur este
independent de $%&'-ul ales, ea se realizeaz conform unui model de date, aa cum este
cel relaional. n realizarea proiectrii fizice, trebuie iniial identificat sistemul de baze de date
avut n vedere. Prin urmare, proiectarea fizic este croit dup modelul unui anumit $%&'.
ntre proiectarea fizic i cea logic exist o legtur, deoarece pe parcursul proiectrii fizice
sunt luate decizii referitoare la mbuntirea performanelor, care pot ns afecta structura
modelului logic de date.
n cele mai multe situaii, obiectivul principal al proiectrii fizice este de a descrie cum
se intenioneaz realizarea implementrii fizice a proiectului logic al unei baze de date.
Astfel, n cazul modelului relaional, aceasta presupune:
extragerea unui set de tabele relaionale (relaii) i de constrngeri asupra acestora, din
informaiile prezentate n modelul logic de date (modelul global);
identificarea structurilor de stocare specifice i metodelor de acces la date, astfel nct s
se garanteze obinerea unor performane optime cu sistemul respectiv;
proiectarea mijloacelor care s asigure securitatea sistemului.
15
Proiectarea tranzaciilor
n sens larg, putem defini o tranzacie ca o aciune sau o serie de aciuni efectuate de
utilizator sau de un program de aplicaie, care acceseaz sau actualizeaz o baz de date.
De asemenea, n [Georgescu, Georgescu, 2005, p.71] tranzacia este definit ca unitatea
logic de prelucrare asupra unei baze de date care include setul complet de operaii
elementare ce trebuie executat n vederea realizrii unei tranziii, pentru asigurarea
consistenei i siguranei bazei de date. Aceeai autori consider c o tranziie se refer la
trecerea de la o realizare la alta a unei baze de date i poate fi produs de modificarea
coninutului unei tabele a bazei de date, de modificarea structurii acesteia, de adugarea
unei noi tabele, etc.
Tranzaciile reprezint evenimente din lumea real, cum ar fi adugarea unui nou
angajat, nregistrarea unui nou client, nregistrarea unei note obinute de un student la o
disciplin, etc. Aceste tranzacii trebuie aplicate bazei de date, pentru a garanta c datele
coninute n aceasta rmn ,la curent cu situaia din lumea real, dar i pentru a susine
nevoile informaionale ale utilizatorilor.
O tranzacie poate fi format din mai multe operaii, cum ar fi spre exemplu, transferul
banilor dintr-un cont n altul. Totui, din punctul de vedere al utilizatorului, aceste operaii
realizeaz o singur sarcin. Din perspectiva $%&'-ului, o tranzacie transfer baza de date
dintr-o stare n alta. $%&'-ul asigur coerena bazei de date, chiar n cazul unei defeciuni.
Totodat, $%&'-ul garanteaz i faptul c odat tranzacia finalizat, modificrile realizate
sunt stocate permanent n baza de date i nu pot fi pierdute sau anulate. Dac dintr-un motiv
oarecare, tranzacia nu poate fi terminat, $%&'-ul este n msur s garanteze c
modificrile realizate de acesta sunt anulate. n exemplul menionat anterior, cel al
transferului de bani, dac banii sunt debitai ntr-un cont i tranzacia eueaz naintea
creditrii celuilalt cont, $%&'-ul va anula i debitarea. n cazul n care am defini cele dou
operaii (debitarea i creditarea) ca tranzacii separate, atunci, odat debitat primul cont i
ncheiat tranzacia, modificarea nu ar mai putea fi anulat (pentru situaia n care creditarea
nu s-ar realiza).
Trebuie s mai menionm i faptul c proiectarea unei tranzacii se bazeaz pe
informaiile din specificaiile cerinelor utilizatorului. Exist numeroase tehnici de preluare i
generare a specificaiilor cerinelor, care includ i o notaie pentru specificarea tranzaciilor
cerute de ctre utilizatori. Aceste tranzacii pot constitui operaii complexe care, atunci cnd
sunt analizate, se dovedesc a fi compuse, de fapt, din mai multe operaii, fiecare dintre
acestea constituind cte o singur tranzacie.
1,
%i"teme !e ge"tiune a bazelor !e !ate
Capitolul III &isteme de gestiune a bazelor de date
****************************************************************************************
Sistemul de gestiune a bazelor de date constituie n prezent un cadru de baz al sistemelor
informaionale i a modificat fundamental modul de operare al unei organizaii. Astfel, n
cadrul capitolului trei, am definit sistemul de gestiune a bazelor de date, am descris evoluia
n timp a acestora i am prezentat principalele faciliti pe care le ofer. Totodat, am tratat
componentele unui sistem de gestiune a bazelor de date, funciile lui, precum i principalele
avantaje i dezavantaje pe care le aduc introducerea n practic a acestora.
****************************************************************************************
n sens larg putem defini sistemul de gestiune a bazelor de date ($%&') ca un sistem
de programe care permite utilizatorilor definirea, generarea i ntreinerea unei baze de date,
precum i accesul controlat la aceasta. n [Velicanu et al., 2003, p.94] $%&'-ul este definit
ca un ansamblu complex de programe care asigur interfaa ntre o baz de date i utilizatorii
acesteia. Totodat, autorii consider $%&'-ul o component software a unui sistem de baze
de date care este capabil s interacioneze cu toate celelalte componente ale acestuia,
asigurnd legtura i independena ntre elementele sistemului.
Un $%&' ofer utilizatorului posibilitatea de a accesa datele prin intermediul unui
limbaj de nivel nalt, apropiat de modul obinuit de exprimare, pentru a obine informaii,
utilizatorul fcnd abstracie de mijloacele i metodele folosite pentru alegerea datelor
implicate i a modului de memorare a lor. $%&'-ul este practic o interfa ntre utilizatori i
sistemul de operare.
Termenul de baz de date se va referi la datele de prelucrat, la modul de organizare a
acestora pe suportul fizic de memorare, iar termenul de gestiune va semnifica totalitatea
operaiilor ce se aplic asupra datelor din baza de date [Trandafir et al., 2007, p.10].
Evoluia sistemelor de gestiune a bazelor de date
Aa cum se tie, predecesorul $%&'-ului a fost sistemul bazat pe fiiere. Totui, nu a
existat un moment bine definit, n care s nceap tratarea prin baze de date i s nceteze
sistemul bazat pe fiiere. De fapt, sistemul bazat pe fiiere mai exist nc i astzi n
anumite domenii. S-a sugerat c $%&'-ul i are rdcinile n proiectul de aselenizare Apollo
din anul 1960, care a fost iniiat ca rspuns la obiectivul preedintelui J.F. Kennedy de a
trimite un om pe lun pn la sfritul deceniului. n acel moment, nu exista nici un sistem
capabil s trateze i s administreze cantitile vaste de informaii pe care le necesita
proiectul.
1-
Ca rezultat, compania North American Aviation (NAA - acum Rockwell nternational),
primul contractant al proiectului, a dezvoltat un software cunoscut sub denumirea de %1M
(Generalized Update Access Methodh metoda general de acces prin reactualizare).
Sistemul %1M pornea de la ideea c, toate componentele mai mici constituie pri ale unor
componente mai mari i aa mai departe, pn la asamblarea produsului final. Aceast
structur, care seamn cu un copac cu susul n jos, este cunoscut i sub denumirea de
structur ierarhic. La mijlocul anilor 1960, companiile BM i NAA au transformat sistemul
GUAM n ceea ce este cunoscut sub denumirea de 0M$
7
(sistem de gestionare a
informaiilor). Motivul pentru care cei de la BM au restrns sistemul MS la administrarea
ierarhiilor nregistrrilor a fost de a permite utilizarea unor dispozitive de stocare seriale, mai
ales benzi magnetice, ceea ce constituia o cerin de pia n acel moment. Aceast restricie
a fost abandonat ulterior. Cu toate c este unul dintre primele sisteme $%&', MS este nc
cel mai important i este utilizat de majoritatea calculatoarelor de tip mainframe.
La mijlocul anilor 1960, o alt realizare semnificativ a fost apariia sistemului 0'$
8
(depozitul de date integrate), realizat de compania General Electric. Acest proiect a fost
condus de ctre unul dintre pionierii sistemelor de baze de date, Charles Bachrnann.
Aceast realizare a dus la apariia unui nou tip de sistem de baze de date, cunoscut sub
denumirea de sistem $%&' n reea, care a avut un efect profund asupra sistemelor
informaionale din acea generaie. Baza de date n reea a fost realizat, parial, pentru a
rspunde necesitii de reprezentare a unor relaii dintre date mai complexe dect se puteau
modela cu ajutorul structurilor ierarhice i, parial, pentru a impune un standard pentru bazele
de date. Pentru a contribui la stabilirea unor astfel de standarde, la Conferina despre
Limbajele Sistemelor de Date (*-'$2/
9
) din 1965, la care au participat reprezentani ai
guvernului SUA i ai lumii afacerilor i comerului, s-a format Fora Operativ de Prelucrare a
Listelor, redenumit Grupul Operativ pentru Baze de Date ('&3%
10
) n 1967. Termenii de
referin ai grupului DBTG constau n definirea de specificaii standard pentru un mediu care
s permit crearea de baze de date i manipularea datelor. n 1969 a aprut un raport
preliminar, iar n 1971 raportul definitiv. Propunerea grupului DBTG a identificat trei
componente:
schema de reea - organizarea logic a ntregii baze de date, aa cum este vzut de
ctre administratorii bazei de date i include o definire a denumirii bazei de date, a tipului
fiecrei nregistrri i a componentelor fiecrui tip de nregistrare;
subschema - partea din baza de date, aa cum este vzut de ctre utilizator sau de
ctre programul aplicaie;
un limbaj de gestionare a datelor, care s defineasc caracteristicile i structura datelor i
care s le manipuleze.
Pentru standardizare, grupul DBTG a specificat trei limbaje distincte:
un limbaj de definire a datelor (LDD) pentru schem, care permite administratorului bazei
de date s defineasc schema;
un limbaj de descriere a datelor pentru subschem, care permite programelor aplicaie s
defineasc componentele bazei de date de care au nevoie;
un limbaj de manipulare a datelor (LMD), pentru manipularea lor.
-
0cronim pentru Information Management System
8
0cronim pentru Integrated Data Store
9
COnference on DAta SYstems Language
1
Data Base Task Group
18
Cu toate c, formal, raportul nu a fost adoptat de ctre nstitutul Naional American
pentru Standarde 45$0
11
6, ulterior s-a realizat un numr de sisteme conform propunerii
'&3%. Acestea sunt cunoscute acum sub denumirea de sisteme *-'$2/ sau '&3%.
Abordrile de tip *-'$2/ i ierarhice au reprezentat prima generaie de $%&'-uri. Totui,
aceste dou modele prezint cteva dezavantaje fundamentale, printre care cele mai
importante sunt:
trebuie scrise programe complexe pentru a rspunde chiar i la interogri simple, bazate
pe accesul navigaional orientat spre nregistrri;
exist o independen minim de date;
nu exist nici o baz teoretic larg acceptat.
n 1970, E.F. Codd de la Laboratorul de Cercetare BM a publicat un articol de foarte
mare influen despre modelul de date relaional. Acest articol, aprut exact la momentul
potrivit, analizeaz dezavantajele abordrilor prezentate mai sus. De atunci, au fost
implementate multe sisteme $%&' relaionale experimentale, primele produse comerciale
aprnd la sfritul anilor 1970 i nceputul anilor 1980. De remarcat este proiectul $7stem
,, de la Laboratorul de Cercetare BM din San 8ose, realizat la sfritul anilor 1970 [Astrahan
et al", 1976]. Acest proiect a fost ndeplinit pentru a demonstra caracterul practic al modelului
relaional, prin realizarea unei implementri a structurilor de date i a operaiilor acestuia, fapt
care a avut dou consecine majore:
dezvoltarea unui limbaj de interogare structurat, denumit $./, care de atunci a devenit
limbajul standard pentru sistemele $%&' relaionale;
producerea de diverse sisteme $%&' relaionale la scar comercial, n decursul anilor
1980; de exemplu, sistemele '&# i $./9'$ de la BM i -racle de la compania cu
acelai nume .
n prezent, exist cteva sute de sisteme $%&' relaionale, att pentru medii
mainframe, ct i pentru microcalculatoare, cu toate c multe dintre ele extind definiia
modelului relaional. Alte exemple de sisteme $%&' relaionale multiutilizator sunt: *$-
-pen0ngres de la compania Computer Associates i 0nformix de la nformix Software nc.
Cteva exemple de sisteme $%&' relaionale pentru microcalculatoare sunt: Access i
FoxPro ale companiei Microsoft, Paradox i Visual dBase ale companiei Borland i R:Base al
companiei Microrim. Sistemele $%&' relaionale sunt denumite sisteme $%&' din a doua
generaie.
Cu toate acestea, modelul relaional a cunoscut i eecuri - n particular, datorit
capacitilor sale de modelare limitate. De-a lungul timpului, s-au efectuat multe cercetri
care au ncercat s rezolve aceast problem. n 1976, Chen a prezentat modelul +ntitate-
,elaie, care reprezint acum o tehnic de proiectare a bazelor de date larg acceptat. n
1979, nsui Codd a ncercat s rezolve cteva dintre esecurile din lucrarea sa initial, printr-
o versiune extins a modelului relaional, denumit RM/T (1979), urmat mai recent de
RM/V2 (1990). ncercrile de realizare a unui model de date care s reprezinte mai
ndeaproape ,lumea real au primit denumirea nu prea inspirat de modelare semantic a
datelor.
Ca rspuns la complexitatea crescnd a aplicaiilor bazelor de date, au aprut dou
,noi sisteme: sistemele $%&' orientate spre obiecte (--'&M$
!#
) i sistemele $%&' de
obiecte relaionale (-,'&M$
13
). Totui, spre deosebire de modelele anterioare, compoziia
acestora nu este clar, iar aceast evoluie reprezint a treia generaie de sisteme $%&'.
11
0cronim pentru American Nationa Standards Institute
1*
0cronim pentru O!"ect#Oriented DataBase Management System
13
0cronim pentru O!"ect#$eationa DataBase Management System
19
n prezent, datorit facilitilor pe care le ofer, constatm c cea mai mare partea
bazelor de date sunt realizate cu ajutorul unor $%&'-uri relaionale i tot mai puine se
bazeaz pe cele de generaia . Totodat, trebuie remarcat i evideniat interesul tot mai
mare fa de utilizarea n practic a $%&'-urilor orientate obiect.
Faciliti oferite de un SGB
Spre deosebire de un limbaj de programare obinuit, n care declararea datelor este
realizat n acelai 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 obinuit
datele exist efectiv numai pe parcursul rulrii 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 $%&' const n elemente software care interacioneaz cu programele
aplicaie ale utilizatorului i cu baza de date. Printre principalele faciliti care sunt oferite de
un $%&' menionm:
1. permite utilizatorului s defineasc baza de date, de obicei prin intermediul unui limbaj de
definire a datelor (LDD), care permite fiecrui utilizator s specifice tipurile i structurile de
date, n timp ce constrngerile asupra datelor sunt memorate n baza de date;
*. ofer posibilitatea actualizrii datelor n baza de date (adugare, 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. Existena unui limbaj de interogare elimin dificultile sistemelor bazate pe
fiiere, unde utilizatorul este constrns s lucreze cu un set fix de interogri pentru a evita
proliferarea de programe, care creeaz probleme majore privind gestionarea acestora.
Exist dou tipuri de limbaje de manipulare a datelor:
procedurale
neprocedurale
care se pot deosebi n funcie de operaiile de extragere. Principala diferen ntre ele
const n faptul c, de obicei, limbajele procedurale trateaz bazele de date nregistrare
cu nregistrare, n timp ce limbajele neprocedurale opereaz asupra unor seturi de
nregistrri. n consecin, limbajele procedurale specific cum se va obine rezultatul unei
instruciuni /M', iar cele neprocedurale descriu numai ce date vor fi obinute. Cel mai
obinuit tip de limbaj neprocedural este limbajul structurat de interogare (SQL - pronunat
,Es-Q-L sau, uneori, ,Sii-Quel), care reprezint acum att limbajul standard, ct i cel
de facto pentru sistemele $%&' relaionale.
3. ofer accesul controlat la baza de date. De exemplu, poate furniza:
un sistem de securitate, care previne accesarea bazei de date de ctre
utilizatori neautorizai;
un sistem de integritate, care menine concordana datelor stocate;
un sistem de control al concurenei, care permite accesul partajat la baza de
date;
un sistem de control al refacerii, care restaureaz baza de date ntr-o stare
precedent concordant, ca urmare a unei defeciuni la nivel hardware sau
software;
*
un catalog accesibil utilizatorilor, care conine descrieri ale datelor din baza de
date.
Datorit funcionalitilor pe care le ofer, $%&'-urile constituie instrumente extrem de
utile. Totui, deoarece pe utilizatori nu-i intereseaz ct de complex sau de uoar este
pentru sistem o anumit sarcin, s-ar putea argumenta c sistemul $%&' a fcut ca
lucrurile s devin mai complexe, deoarece acum se pot vedea mai multe date dect este
cu adevrat necesar sau dect se dorete. Ca o recunoatere a acestei probleme,
sistemul $%&' prezint o alt facilitate, cunoscut sub denumirea de mecanism de
vizualizare, care permite fiecrui utilizator s-i defineasc propriul mod de vizualizare a
bazei de date. Limbajul LDD permite definirea de moduri de vizualizare, n care acestea
reprezint un subset al bazei de date.
4. ofer un anumit nivel de securitate. Modurile de vizualizare pot fi realizate astfel nct s
nu includ datele ce nu trebuie cunoscute de anumii utilizatori. De exemplu, s-ar putea
crea un mod de vizualizare care s permit unui administrator de filial i departamentului
Contabilitate s afieze toate datele referitoare la personalul unei instituii, inclusiv
detaliile despre salariu. Pe lng acesta, s-ar putea crea un al doilea mod de vizualizare,
care s exclud detaliile despre salariu, ce va fi utilizat de ctre ceilali angajai;
5. pot prezenta o imagine coerent, neschimbat a structurii bazei de date, chiar dac
aceasta este modificat (de exemplu, s-ar putea aduga sau elimina cmpuri, s-ar putea
modifica relaiile, diviza, restructura sau redenumi anumite fiiere). Dac sunt adugate
sau eliminate cmpuri dintr-un fiier, iar acestea nu sunt cerute de ctre modul de
vizualizare, el nu este afectat de ctre modificarea realizat. Prin urmare, modul de
vizualizare contribuie la asigurarea independenei program-date.
Analiza prezentat mai sus este una general. Nivelul real de funcionalitate a unui
$%&' difer de la produs la produs. De exemplu, s-ar putea ca un $%&' pentru un
calculator personal s nu accepte accesul partajat concurent, ns ar prezenta doar un
control limitat al securitii, integritii i refacerii. Totui, produsele $%&' moderne,
multiutilizator, prezint toate funciile de mai sus i nc multe altele. Sistemele moderne sunt
programe extrem de complexe, formate din milioane de linii de cod, cu documentaia
constnd n multe volume. Acesta este un rezultat al necesitii de realizare a unor programe
care s trateze cerine de o natur mai general. Mai mult, n zilele noastre, utilizarea unui
$%&' necesit sisteme care s prezinte un grad de fiabilitate i de disponibilitate de aproape
100%, chiar n cazul unor defeciuni, fie la nivel hardware, fie software. Totodat, toate
$%&'-urile trebuie s evolueze i s se dezvolte permanent, dar necesit i o perfecionare
continu pentru a prentmpina noile cerine ale utilizatorilor. De exemplu, dac unele
aplicaii necesit stocarea de imagini grafice, video, sunete, etc. pentru satisfacerea acestei
piee, $%&'-urile trebuie s se modifice. Cel mai probabil c o nou funcionalitate va fi
mereu necesar, aa nct aceasta nu va putea deveni niciodat static.
Avanta!ele "i dezavanta!ele SGB#urilor
Aa cum vom arta n continuare, utilizarea n practic a sistemelor de gestiune a
bazelor de date beneficiaz de promitoare avantaje poteniale, ns, din pcate, exist i
unele dezavantaje.
Avanta'ele SGB(urilor
*1
)*Controlul redundan+ei datelor
Aa cum am mai menionat, n sistemele tradiionale bazate pe fiiere se fcea risip
de spaiu prin stocarea acelorai informaii n mai multe fiiere. Prin contrast, n tratarea prin
baze de date se ncearc eliminarea redundanei prin integrarea fiierelor, astfel nct s nu
se stocheze mai multe copii ale acelorai date. Totui, n tratarea prin baze de date nu se
elimin n ntregime redundana, ci se controleaz volumul inerent al acesteia n baza de
date. Uneori, pentru modelarea relaiilor, este necesar dublarea unor articole de date cheie.
Alteori, pentru mbuntirea performanelor, este de dorit s se dubleze unele articole de
date.
,*Coeren+a datelor
Prin eliminarea sau controlul redundanei se reduce riscul apariiei incoerenei 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 toi utilizatorii. Dac un articol de date este stocat de mai multe ori, iar sistemul este
,contient de aceasta, el poate garanta c toate copiile articolului respectiv sunt meninute
coerente. Din pcate, multe dintre sistemele $%&' actuale nu garanteaz automat acest tip
de coeren.
-*Mai multe in%orma+ii de la aceea#i cantitate de date
Odat cu integrarea datelor operaionale, ar putea fi posibil ca organizaia respectiv
s extrag informaii suplimentare din aceleai date.
.*Parta'area datelor
n general, fiierele sunt deinute de ctre persoanele sau departamentele care le
utilizeaz. Pe de alt parte, baza de date aparine ntregii organizaii sau instituii i poate fi
partajat de ctre toi utilizatorii autorizai. n acest mod, mai muli utilizatori partajeaz o
cantitate mai mare de date. Mai departe, se pot construi noi aplicaii bazate pe datele
existente n baza de date, n timp ce datele adiionale (care nu sunt stocate n mod curent) se
pot aduga fr a fi necesar definirea repetat a tuturor cerinelor referitoare la acestea.
Noile aplicaii se pot baza i pe funciile oferite de ctre sistemul $%&' (cum ar fi definirea i
manipularea datelor i controlul concurenei i refacerii) n loc de a fi necesar s le furnizeze
ele nsele.
/*Integritatea crescut$ a datelor
ntegritatea bazei de date se refer la validitatea i coerena datelor stocate. De obicei,
integritatea este exprimat n termeni de constrngeri, care reprezint reguli de coeren, pe
care baza de date trebuie s le respecte. Constrngerile se pot aplica articolelor de date
dintr-o singur nregistrare sau relaiilor dintre diferite nregistrri. Spre exemplu, o
constrngere 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 obine 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 ntreasc) constrngerile privind integritatea.
**
0*&ecuritate sporit$
Securitatea se refer la protecia bazei de date fa de utilizatorii neautorizai. Fr
msuri de securitate clare i adecvate, integrarea face ca datele s fie mult mai vulnerabile
dect n cazul sistemelor bazate pe fiiere. Totui, integrarea va permite administratorului
bazei de date s defineasc (iar bazei de date s ntreasc) 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 funcie
de poziia pe care o are n organizaie, un anumit set de date). Accesul la date permis unui
utilizator autorizat poate fi limitat de tipul operaiei efectuate (extragere, inserare,
reactualizare, tergere). De exemplu, administratorul bazei de date are acces la toate datele
din baza de date, un manager de flial ar putea accesa doar datele legate de filiala
respectiv, n timp ce un utilizator de la compartimentul :;nzri ar putea avea acces numai
la datele referitoare la proprieti, dar nu i la datele ,sensibile, cum ar fi detaliile despre
salariile angajailor sau contractele ncheiate.
1*Aplicarea standardelor
Din nou, integrarea permite administratorului bazei de date s defineasc i s aplice
toate standardele necesare. Acestea ar putea include standarde departamentale,
organizaionale, naionale sau internaionale (pentru diferite aspecte, cum ar fi formatul
datelor) care s faciliteze schimbul de date ntre sisteme, conveniile privind denumirile,
standardele de documentare, procedurile de reactualizare i regulile de acces.
2*3conomia de scal$
Combinarea tuturor datelor operaionale ale organizaiei ntr-o singur baz de date i
crearea unui set de aplicaii care s funcioneze pentru aceast unic surs de date pot avea
ca rezultat micorarea costurilor. n acest caz, s-ar putea combina bugetele care ar fi fost
alocate n mod normal fiecrui departament pentru dezvoltarea i ntreinerea propriului
sistem bazat pe fiiere, ceea ce ar putea duce la un total mai sczut al cheltuielilor, avnd ca
rezultat o economie de scal. Bugetul combinat poate fi utilizat pentru achiziionarea unei
configuraii a sistemului mai adecvate cerinelor i necesitilor organizaiei respective.
Aceasta ar putea consta ntr-un calculator cu o configuraie mai bun, cu o putere de calcul
sporit sau ntr-o reea de calculatoare mai mici.
4*3c5ilibrul 6ntre cerin+ele a%late 6n con%lict
Fiecare utilizator sau departament are propriile sale cerine, 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 operaional a
acesteia, care s duc la folosirea optim a resurselor pentru organizaia luat n ansamblu.
Aceste decizii vor realiza performane optime ale aplicaiilor majore, posibil n detrimentul
celor mai puin importante.
)7*8mbun$t$+irea accesibilit$+ii datelor #i capacit$+ii de r$spuns
Ca rezultat al integrrii, datele care depesc graniele unui departament sunt direct
accesibile utilizatorilor finali. Aceasta creeaz un sistem cu o mult mai mare funcionalitate
potenial dect ar putea fi folosit, de exemplu, pentru furnizarea unor servicii mai bune
*3
utilizatorului final sau clienilor organizaiei. Multe $%&'-uri ofer limbaje de interogare sau
generatoare de rapoarte, care permit utilizatorilor s formuleze ntrebri ad-hoc i s obin
aproape imediat afiarea informaiilor cerute la terminal, fr 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 urmtoarei comenzi $./ la un terminal:
$+/+*3<
F,-M proprietate=de=inchiriat
>?+,+ t7pe @ ApartamentA 5' chirieB CDDE
))*Productivitate crescut$
Aa cum am menionat anterior, un $%&' ofer multe dintre funciile standard, pe
care ar trebui s le scrie n mod normal programatorul, n cazul unei aplicaii bazate pe
fiiere. La nivel fundamental, $%&'-ul ofer toate rutinele de nivel jos pentru manevrarea
fiierelor, tipice n programele aplicaie. Furnizarea acestor funcii permite programatorului s
se concentreze mai mult asupra funcionalitii specifice cerute de ctre utilizatori, fr ns a
se preocupa de detaliile de nivel jos privind implementarea. Multe sisteme $%&' furnizeaz
i un mediu din a patra generaie, care const n instrumente de simplificare a dezvoltrii de
aplicaii n domeniul bazelor de date. Aceasta are ca rezultat o productivitate crescut a
programatorului i un timp redus de programare (mpreun cu reducerea corespunztoare a
costurilor).
),*8ntre+inere 6mbun$t$+it$ datorit$ independen+ei datelor
Descrierile datelor i logicii de accesare a lor n cadrul sistemelor bazate pe fiiere
erau ncorporate n fiecare program aplicaie, ceea ce fcea 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
schimbri importante n programele afectate de modificrile produse. Prin contrast, ntr-un
$%&', descrierile datelor sunt separate de aplicaii, ceea ce face ca acestea s fie imune la
modificrile din descrierea datelor. Aceast caracteristic este cunoscut sub denumirea de
independen fa de date (sau independena datelor). Realizarea independenei datelor
simplific substanial ntreinerea aplicaiilor din baza de date.
)-*Concuren+$ 6mbun$t$+it$
Majoritatea sistemelor bazate pe fiiere se confruntau adesea cu o problem
important, cu influene negative asupra ceea ce nseamn gestionarea eficient a
coninutului unui baze de date. Astfel, dac doi sau mai muli utilizatori aveau permisiunea de
a accesa simultan acelai fiier, se ntmpla ca cele dou accesri s se suprapun, ceea ce
avea evident ca rezultat pierderea informaiilor sau chiar alterarea integritii datelor
respective. n ceea ce privete un $%&', una dintre sarcinile importante care-i revin acestuia
se refer la administrarea accesului concurent la baza de date, fapt care are drept
consecin garania evitrii apariiei unor astfel de probleme.
).*8mbun$t$+irea serviciilor de salvare de siguran+$ #i re%acere
Multe sisteme bazate pe fiiere las n sarcina utilizatorului responsabilitatea de a lua
msuri de protecie a datelor, n cazul unor defeciuni ale sistemului de calculatoare sau ale
*4
programului aplicaie. Aceasta ar putea presupune realizarea unei copii de siguran a
datelor la intervale scurte de timp (spre exemplu, n fiecare zi). Apariia unei defeciuni 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, $%&'-urile moderne ofer faciliti de minimizare a pierderilor
(aferente prelucrrilor realizate) ca urmare a unei defeciuni.
ezavanta!e SGB#urilor
Pe lng avantajele menionate anterior, fiecare $%&' comport i un numr de
dezavantaje, iar cele mai importante sunt menionate n continuare.
)*Comple9itatea
Proiectarea funcionalitii unui $%&' optim face ca acesta s devin un element
software extrem de complex. Proiectanii 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 funcionalitate, pentru a putea profita de ea la maximum. Eecul n
nelegerea sistemului poate cauza fundamentarea i luarea unor decizii greite aferente
etapei de proiectare, care, n mod cert, pot conduce la consecine negative importante pentru
fiecare organizaie sau instituie specializat care dispune de un astfel de sistem.
,*Costul
Costul unui $%&' variaz semnificativ, n funcie de mediu i de funcionalitatea pe
care o ofer. De exemplu, un $%&' cu un singur utilizator, pentru un calculator personal,
poate costa numai 100 euro. Cu toate acestea, un $%&' mainframe, multi-utilizator, care
deservete sute de utilizatori, poate fi extrem de scump" Mai exist i cheltuielile periodice
anuale de ntreinere care reprezint, de regul, un procent din preul acestuia. n acest caz,
este clar c vom alege un $%&' pentru gestionarea unei activiti numai n concordan cu
necesitile curente: nu are sens s achiziionm un $%&' scump dac nevoia nu o cere,
ns nu recomandm nici achiziionarea unui $%&' ieftin atunci cnd volumul de date, dar i
cel al prelucrrilor de realizat este mare (mai ales n cazul gestionrii datelor la nivelul
bazelor de date distribuite
14
).
-*Costurile adi+ionale speci%ice componentelor hard$are
Cerinele de stocare pe suport fizic pentru un $%&' i baza de date ar putea necesita
achiziionarea unui spaiu de stocare suplimentar. Mai mult, pentru obinerea performanelor
dorite, ar putea fi necesar cumprarea unui calculator mai performant, poate chiar unul
destinat rulrii $%&'-ului. Astfel, este clar c achiziionarea de componente hardware
adiionale conduce la creterea cheltuielilor.
.*Costul conversiei
n unele cazuri, costul unui $%&' i al componentelor hardware adiionale poate fi
nesemnificativ, comparativ cu costul conversiei aplicaiilor existente, necesare ca acestea s
14
Baza de date distribuit reprezint un set de baze de date aflate pe mai multe calculatoare i care este vzut
de ctre aplicaie ca fiind o singur baz de date (aflat pe un singur calculator) adic baza de date vzut de
ctre aplicaie este fragmentat i mprit pe mai multe calculatoare din reea. O baz de date se spune c
este distribuit dac diferitele componente ale acesteia sunt memorate n staiile i/sau serverul reelei.
*5
poat funciona n noul $%&' i n noua configuraie hardware. Acest cost include i preul
instruirii personalului pentru a putea utiliza noile sisteme i, posibil, angajarea unui personal
specializat, care s ajute la conversia i funcionarea sistemului. Aceste cheltuieli reprezint
unul dintre motivele principale pentru care unele organizaii se ,mpiedic de sistemele
existente i nu pot trece la tehnologia modern specific bazelor de date. Termenul de
sistem motenit este utilizat uneori pentru a se face referire la un sistem mai vechi, de obicei
inferior din punct de vedere al funcionalitii.
Totodat, exist i situaii n care anumite organizaii renun la actualizarea
permanent a componentelor hardware, determinate de conversiile realizate la nivel
software n detrimentul achiziionrii unui produs software nou i care este n concordan cu
necesitile cerute. ns, aceast soluie este una important, cu implicaii directe asupra
cheltuielilor realizate, dar i a modului de lucru specific personalului de care se dispune la un
moment dat.
/*Dimensiunea
Complexitatea i extinderea funcionalitii fac din $%&'-uri elemente software destul
de cuprinztoare, ce ocup mult spaiu pe suportul fizic i necesit o memorie
15
substanial
pentru a funciona eficient i corect.
0*Per%orman+a
De obicei, un sistem bazat pe fiiere este realizat pentru o anumit aplicaie, cum ar fi
facturarea. Ca rezultat, performanele sunt, de regul, foarte bune. Totui, $%&'-ul este
creat pentru a fi mai general, pentru a oferi mai multe funcionaliti, nu una singur.
Rezultatul este c unele aplicaii ar putea s nu mai funcioneze tot att de rapid sau la fel de
eficient.
1*Impactul crescut al unei de%ec+iuni
Centralizarea resurselor mrete vulnerabilitatea sistemului. Din moment ce toi
utilizatorii i toate aplicaiile se bazeaz pe disponibilitate din partea $%&'-ului, eecul
oricrei componente a acestuia poate duce la sistarea tuturor operaiilor.
Componentele unui SGB
Principalele componente ale unui $%&' sunt [Georgescu, Georgescu, 2005, p.75-81]:
motorul $%&' este componenta care asigur interfaa dintre subsistemul de proiectare
i cel de execuie pe de o parte, i datele bazei de date pe de alt parte i are rolul de a
asigura accesul fizic la datele bazei de date. Toate aciunile motorului $%&' sunt
realizate unitar i respect restriciile impuse de legturile dintre date, dar i de regulile de
integritate ale bazei de date definite n dicionarul de date. Principalele responsabiliti ale
motorului $%&' sunt:
realizeaz gestionarea tranzaciilor la nivelul unei baze de date;
permite regsirea datelor pe baza informaiilor de adresare din fiierele de index;
salvarea i restaurarea datelor;
15
Evident, ne referim la memoria ,M (,andom ccess Memor7) a calculatorului pe care se gsete i ruleaz
$%&'-ul respectiv.
*,
blocarea i deblocarea datelor n cazul operaiilor fizice la nivelul memoriei externe;
subsistemul instrumentelor de proiectare dispune de un set de instrumente software
care permit proiectarea i generarea bazei de date i a aplicaiilor care descriu modul de
utilizare a bazei de date. Aceast component permite definirea:
structurii tabelelor din baza de date;
machetelor de interfa cu utilizatorul;
a formatului rapoartelor i cererilor de interogare a bazei de date.
Subsistemul instrumentelor de proiectare poate include:
limbaje de descriere a datelor (LDD)
16
;
limbaje de manevrare a datelor;
limbaje de interogare a datelor din baza de date;
editoare de cod;
generatoare de cod care s permit definirea interfeei cu utilizatorul, a rapoartelor,
meniurilor, etc.;
un sistem de asisten on-line pentru autodocumentarea utilizatorului.
subsistemul de execuie permite execuia aplicaiilor sau cererilor de consultare a bazei
de date, formulate prin utilizarea instrumentelor subsistemului de proiectare, prin
consultarea dicionarului de date i generarea tranzaciilor. Aceasta este componenta
care garanteaz autonomia logic a datelor n baza de date i are rolul de a intermedia
operaiile cu baza de date prin consultarea descrierii organizrii logice a datelor
memorate n structura bazei de date. Practic, fiecare operaie de actualizare sau
consultare a bazei de date se realizeaz prin identificarea formatelor de descriere a
datelor din dicionarul de date i conectarea acestor descrieri din schema intern a bazei
de date
Funciile SGB#ului
n [Velicanu et al., 2003, p.104-107] se arat c ndeplinirea tuturor obiectivelor unui
$%&' se realizeaz prin intermediul unor componente care permit efectuarea unor operaii
specifice. n funcie de natura lor, dar i de scopul urmrit, operaiile pot fi grupate pe
activiti. Activitile accept i ele o grupare pe funcii astfel nct, una sau mai multe
activiti, relativ omogene, vor realiza o funcie anume. |innd cont de complexitatea unui
$%&', de facilitile pe care le pune la dispoziie, de limbajele utilizate, precum i de modul
de implementare al modelului de date, gruparea activitilor pe funcii are un anumit caracter
relativ.
Plecnd de la modelul de date pe care l implementeaz, $%&'-urile se
caracterizeaz printr-un numr de particulariti identificate prin operaii i activiti specifice.
n pofida acestor particulariti, exist cteva funcii general valabile pentru toate tipurile de
$%&'; acestea sunt funcii importante, pe care un sistem software, dac nu le are n
totalitate, nu poate fi considerat $%&'. Astfel, principalele funcii pe care le putem atribui
unui $%&' sunt: descrierea datelor, manipularea datelor, utilizarea i administrarea bazei de
date.
1,
1n limba2 !e !e"crierea a !atelor permite !e"crierea componenei bazei !e !ate3 a "tructurii ace"teia 3 a relaiilor !intre
componentele ei3 precum /i a tuturor !repturilor !e acce" ale utilizatorilor la baza !e !ate.
*-
Descrierea datelor
Prin intermediul funciei de descriere a datelor, fiecare $%&' permite definirea unei
structuri a bazei de date cu ajutorul limbajului de definire a datelor (LDD). Definirea datelor
poate fi realizat la nivel conceptual, logic i fizic. Se descriu atributele din cadrul structurii
bazei de date, legturile dintre entitile acesteia sau dintre atributele aceleiai entiti, se
definesc criteriile de validare a datelor (dac este cazul), metodele care asigur accesarea
datelor, precum i aspectele care se refer la asigurarea integritii datelor. Concretizarea
acestei funcii este schema bazei de date, memorat n cod intern. Memorarea se face ntr-
un fiier, ceea ce permite afiarea i actualizarea structurii bazei de date, n orice moment de
timp.
Aceast funcie a fost mult automatizat n timp, limbajul de descriere a datelor
beneficiind n prezent de puine comenzi. Acest limbaj este specific fiecrui $%&', dar el
mereu realizeaz descrierea lor conform elementelor modelului de date pe care l
implementeaz $%&'-ul respectiv. Astfel se realizeaz definirea i descrierea entitilor i a
caracteristicilor lor, definirea legturilor dintre obiectele identificate (asocierile) i a regulilor
de integritate specifice modelului de date.
Manipularea datelor
Funcia de manipulare a datelor este cea mai complex i realizeaz actualizarea i
regsirea datelor din baza de date, cu ajutorul limbajului de manipulare a datelor
17
.
Manipularea datelor este cea mai folosit funcie n bazele de date, fiind cea mai bine
suportat de sistemul de gestiune a bazelor de date fa de oricare alt sistem de gestionare a
datelor din memoria extern. Practic, un $%&' manipuleaz datele ntr-o manier eficient,
folosind n acest scop diferite tehnici i metode de optimizare a accesului i a alocrii
spaiului din memoria calculatorului.
Menionam n paragraful anterior c limbajul de manipulare a datelor este cel care
asigur realizarea acestei funcii. n ceea ce-l privete, acest limbaj trebuie s respecte
restriciile de integritate a datelor i s implementeze operatorii din modelul de date pe care
se bazeaz $%&'-ul cruia i aparine.
Aceast funcie presupune derularea urmtoarelor activiti:
ncrcarea datelor n baza de date - se realizeaz prin operaii automatizate sau
programate ce asigur i criteriile de validare necesare;
actualizarea bazei de date se refer la operaiile de adugare, modificare i tergere de
nregistrri. La operaiile de adugare i de modificare se pstreaz aceleai criterii de
validare care s-au folosit i la activitatea de ncrcare a datelor. Actualizarea se
realizeaz numai autorizat, prin asigurarea unei protecii corespunztoare a datelor,
pentru a se pstra coerena bazei de date.
prelucrarea datelor presupune realizarea operaiilor de selecie, ordonare, etc. efectuate
asupra entitilor bazei de date. Acestea sunt, de obicei, operaii pregtitoare activitii de
regsire a datelor. Multe din operaiile de prelucrare sunt realizate cu ajutorul operatorilor
din modelul de date pe care l implementeaz $%&'-ul.
regsirea (interogarea) datelor presupune realizarea operaiilor de vizualizare (afiare
pe ecran, imprimare pe hrtie), rsfoire, editarea unor documente de ieire (rapoarte).
Documentele de ieire pot fi intermediare sau finale i se pot obine pe diferii supori
1-
4n literatur 5nt6lnim frec'ent /i Lim!a" de Mane%rare a Dateor
*8
tehnici de informaie (ecran, hrtie, mediu magnetic, mediu optic). Ele pot avea cele mai
diferite forme (punctuale, liste, rapoarte, grafice, imagini, sunet, video, etc) i se pot
obine dup cele mai diferite criterii de regsire.
Func+ia de utilizare
Aceast funcie are rolul de a asigura interfeele necesare care s permit
comunicarea utilizatorilor cu baza de date (cu alte cuvinte, s asigure legtura dintre utilizator
i baza de date). Pentru realizarea acestei funcii, $%&'-ul trebuie s ofere faciliti pentru
mai multe categorii de utilizatori ai bazei de date, i anume: neinformaticieni, specialiti
(informaticieni) i administratorul.
Utilizatorii neinformaticieni reprezint principala categorie a beneficiarilor de informaii
(utilizatori finali i intensivi) din baza de date. $%&'-ul le ofer acestora limbaje
neprocedurale, dar i alte faciliti de interogare (generatoare, utilitare, etc.) a bazei de date
ntr-o form simpl i interactiv. Aceti utilizatori nu trebuie s cunoasc structura bazei de
date i nu trebuie s tie s programeze, $%&'-ul sprijinindu-i n manier interactiv n
utilizarea bazei de date. n acest sens $%&'-ul ofer:
meniuri cu opiuni sugestive;
ferestre de lucru;
abloane pentru diferite forme;
asisteni tip >izard;
autodocumentarea (help-uri, mesaje/ferestre explicative).
Spre deosebire de utilizatorii neinformaticieni, cei speciali)ti n informatic sunt n
msur s creeze structura bazei de date i s realizeze proceduri complexe de exploatare a
acesteia. $%&'-ul ofer acestor utilizatori limbajul de descriere i limbajul de manipulare a
datelor precum i interfee cu limbaje universale. Acestea sunt de complexitate i putere
diferit, de la un $%&' la altul, oferind att elemente neprocedurale ct i procedurale
specialistului n informatic. Cu aceste elemente el poate s descrie schema bazei de date i
s asigure manipularea complex a datelor.
dministratorul bazei de date este un utilizator special i are un rol hotrtor n ceea
ce privete funcionarea optim a ntregului sistem. Datorit importanei acestei categorii de
utilizatori, $%&'-ul are o funcie distinct n acest sens.
Administrarea bazei de date
Funcia de administrare este una destul de complex i din acest motiv se consider
c este doar de competena administratorului bazei de date.
dministratorul, care are o bogat experien de analiz, proiectare i programare,
organizeaz i administreaz baza de date n toate etapele de realizare a acesteia. Astfel, el
organizeaz baza de date conform unei anumite metodologii, realizeaz schema
*9
conceptual a acesteia i coordoneaz proiectarea ei. Pentru toate aceste aspecte, $%&'-ul
ofer o serie de instrumente CASE
18
, precum i o serie de utilitare specializate.
n etapa de exploatare a bazei de date, administratorul ndeplinete mai multe roluri:
de a autoriza accesul la date (creaz conturi de acces, parole, etc.);
de a reface baza de date n caz de incidente (prin jurnalizare, copii de siguran);
de a utiliza eficient spaiul de memorie intern i extern (prin organizare, rutine de
optimizare);
de a realiza o serie de analize statistice din baza de date (numr i tip de utilizatori,
numr de accese, numr de actualizri, etc.).
Pentru fiecare din activitile menionate mai sus, $%&'-ul ofer instrumente i tehnici
de lucru.
n cazul lucrului n reea, cu baze de date distribuite, $%&'-ul are dezvoltate foarte
mult componentele destinate administratorului. Acest lucru este determinat de faptul c baza
de date este, n acest caz, de mare complexitate, datele sunt distribuite pe calculatoarele
reelei, iar utilizatorii sunt de toate tipurile i n numr mare.
18
Instrumentee CAS& (Computer Aided Soft'are &ngineering) "unt aplicaii informatice3 formate !in mai multe
componente3 care a2ut la realizarea unui proiect "oft7are3 5n anumite etape ("au 5n toate etapele) !in ciclul !e 'ia al unei
aplicaii. 8biecti'ul principal al in"trumentelor &0%9 con"t 5n punerea 5n practic a pro!u"elor$program !e proiectare /i
realizarea "oft7are$lui cu a2utorul calculatorului. (n"trumentele oferite !e &0%9 "unt utilizabile !in faza !e !efinire a
cerinelor p6n la 5ntreinerea fizic a pro!u"ului informatic :8prea3 19993 p.1*3;.
3
0bor!area relaional a bazelor !e !ate
Capitolul IV Abordarea rela+ional$ a bazelor de date
****************************************************************************************
Principalul obiectiv al capitolului V este acela de a oferi o viziune general asupra relaionrii
datelor dintr-o baz de date. Astfel, n acest capitol am urmrit:
prezentarea regulilor lui Codd pe care se bazeaz ntreaga abordare relaional;
identificarea i prezentarea fundamentelor specifice modelului relaional;
definirea tipurilor de chei ntlnite la nivelul unei relaii;
definirea tipurilor de legturi dintre relaii; nelegerea mecanismului cheii strine;
prezentarea principalilor operatori ai algebrei relaionale.
****************************************************************************************
Aa cum reiese din literaura de specialitate, au existat n timp mai multe modele de
reprezentare a informaiilor la nivel logic i de operare:
reea;
ierarhic;
relaional.
n cadrul acestui capitol vom analiza detaliat cel mai utilizat model de reprezentare,
utilizat n prezent pe scar larg, i anume modelul relaional.
%egulile lui Codd
Pentru a fi considerat relaional, fiecare sistem de gestiune a bazelor de date trebuie
s respecte nite reguli, ntlnite n literatur sub numele de regulile lui *odd. Modelul de
stocare a datelor sub forma unei baze de date relaionale s-a dezvoltat pornind de la un
articol aprut n anul 1970, , relational Model of 'ata for /arge $hared 'ata &anFs, i care
aparine cercettorului Codd [Codd, 1970, p.377-387]. Astfel, regulile enunate de cercettor
sunt prezentate n continuare:
%& G %estionarea datelor la nivel de relaie"
Toate informaiile din baza de date sunt gestionate numai prin mecanisme relaionale.
Rezult c $%&'-ul trebuie s-i ndeplineac toate funciile utiliznd ca unitate de
informaie mulimea, cu alte cuvinte, s utilizeze diferite limbaje, aa cum este i $./, care
s opereze la un moment dat pe o relaie.
31
%' G ,eprezentarea logic a datelor"
nformaiile bazei de date relaionale 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. nformaiile referitoare la numele tabelelor, al
coloanelor, domeniilor, definiiilor tabelelor virtuale, al restriciilor de integritate trebuie s fie
memorate tot n tabelele de date.
%( G %arantarea accesului la date
Accesarea tuturor informaiilor bazei de date se va realiza prin specificarea numelui tabelei
respective, a valorii cheii primare, precum i a numelui de coloan.
%) G ,egula aferent valorii 51//
Un $%&' trebuie s permit declararea i utilizarea valorii 51//, cu semnificaia unor date
lips sau care nu pot fi aplicate. Valorile 51// (care sunt diferite de irurile de caractere
spaiu sau de cele vide) sunt importante pentru implementarea restriciilor de integritate
(integritatea entitii i integritatea referenial) aferente modelului relaional.
%* G ,egula specific metadatelor
nformaiile 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 aceleai operaii ca i la datele obinuite. Sistemul nu trebuie
s fac diferene ntre descrierea datelor i a metadatelor utiliznd o singur structur, i
anume cea relaional.
%+ G Faciliti ale limbajelor utilizate
Un sistem relaional trebuie s fac posibil utilizarea mai multor limbaje, n diferite moduri.
Trebuie s existe cel puin un limbaj de nivel nalt ale crui instruciuni s poat exprima
oricare din urmtoarele operaii: definirea tabelelor, a tabelelor virtuale, manevrarea datelor,
definirea tuturor restriciilor de integritate, garantarea i autorizarea accesului la date, precum
i prezentarea limitelor tranzaciilor.
%, G ctualizarea bazei de date
Fiecare $%&' trebuie s permit manipularea unei tabele (de baz sau virtual), att n
cazul actualizrii datelor n baza de date, ct i pentru operaii de regsire a acestora. n
cazul unei operaii care va modifica coninutul unei baze de date, trebuie s se lucreze la un
moment dat pe o relaie ntreag.
%- G 0ndependena fizic a datelor
Programele de aplicaie nu trebuie s fie afectate de modificrile realizate n modul de
reprezentare a datelor sau n metodele de acces. O schimbare a structurii fizice a datelor nu
trebuie s blocheze funcionarea programelor de aplicaie.
%. G 0ndependena logic a datelor
Programele de aplicaie nu trebuie s fie afectate de modificrile efectuate asupra relaiilor
care formeaz baza de date.
%/ G ,egula aferent restriciilor de integritate
Toate restriciile de integritate trebuie s poat fi definite prin intermediul limbajului folosit de
$%&' pentru definirea datelor i s fie memorate.
%'& G 'istribuirea geografic a datelor
3*
n cazul n care datele sunt distribuite, programele de aplicaie s fie logic aceleai cu cele
utilizate n cazul n care datele sunt fizic centralizate. Practic, n aceast situaie, utilizatorul
ar trebui s perceap aceste date ca fiind centralizate i nu aparinnd unor staii diferite de
lucru, aflate n zone geografice diferite.
%'' G ctualizarea tabelelor virtuale
n cadrul abordrii relaionale, nu toate atributele sunt actualizabile, ceea ce nseamn c nu
toate tabelele virtuale pot fi actualizate.
%'( G (relucrarea datelor la nivel de baz
Dac $%&'-ul posed un limbaj de baz de nivel sczut orientat pe prelucrarea tuplurilor i
nu pe cea a relaiilor, atunci acest limbaj nu trebuie folosit pentru a se evita restriciile de
integritate sau restriciile introduse prin utilizarea limbajelor relaionale de nivel nalt.
Fundamente ale modelului relaional
nainte de a prezenta principalele aspecte care caracterizeaz modelul relaional,
considerm c este oportun definirea conceptului de baz de date relaional. Dup o
ndelung analiz i sintez a definiiilor formulate de cercettorii consacrai ai domeniului,
dar i profesori de seama care au analizat aceast paradigm, putem afirma pe scurt c o
baz de date relaional reprezint colecii organizate de date )i corelate din punct de vedere
logic. La o simpl analiz a definiiei, observm c ea impune dou direcii de studiu:
1. colecii organizate de date;
*. colecii corelate logic.
n acest context, pe parcursul capitolului, plecnd de la prezentarea aspectelor fundamentale
care caracterizeaz modelul relaional al bazelor de date, vom argumenta definiia prezentat
anterior i implicit cele dou direcii de studiu.
Atunci cnd lum n discuie abordarea relaional a bazelor de date, vom analiza n
principal trei direcii:
structura datelor are n vedere definirea domeniilor i a relaiilor corespunztoare
acestor domenii;
integritatea datelor se refer la definirea restriciilor de integritate care au rolul de a
proteja datele bazei de date; lipsa unor restricii de integritate ar putea avea ca efect
alterarea coninutului bazei de date i obinerea unor rezultate eronate;
prelucrarea datelor se realizeaz prin intermediul operaiilor specifice algebrei
relaionale sau calculului relaional.
Dup cum sugereaz i numele, modelul relaional se bazeaz pe noiunea de relaie
care este definit din punct de vedere matematic ca o submulime a produsului cartezian a
unei liste (finite) de mulimi, numite domenii. Fiecare element al unei relaii poart numele de
tuplu, iar numrul de domenii se numete aritate. ntr-o relaie, fiecare domeniu se identific
printr-un nume, numit atribut, iar mulimea numelor atributelor unei relaii formeaz schema
acesteia. Fie relaia din exemplul C"!:
E0emplul *1'1 $tudent 4cnp, nr=matr, nume, pren, facult, spec6
Astfel, n exemplul anterior am definit relaia $tudent care include atributele:
33
cnp definit pe domeniul cod numeric personal;
nr_matr definit pe domeniul numr_matricol;
nume definit pe domeniul nume;
pren definit pe domeniul prenume;
facult defint pe domeniul facultate;
spec definit pe domeniul specializare;
De asemenea, formulnd altfel, putem spune c n exemplul C"! am definit relaia
$tudent cu schema dat de atributele cnp, nr=matr, nume, pren, facult, spec. n exemplul C"#
sunt prezentate trei tupluri pentru relaia $tudent defint n exemplul C"!"
E0emplul *1(
$tuden
t
4 cnp nr=mat
r
nume pren facul
t
spe
c
6
1701212120139 1234 Popa Dan FSE E
2731210176143 1987 Darie Alina FD AP
1801009129145 4432 Mihnea on FSE FB
n ceea ce privete o relaie, ordinea de apariie a atributelor este absolut
nesemnificativ i acelai lucru l putem spune i despre tupluri.
Aa cum se observ, un tuplu se obine prin atribuirea de valori atributelor relaiei. n
ceea ce privete tuplurile unei relaii (care se mai numesc i realizri) trebuie spus c nu pot
exista dou sau mai multe tupluri identice. Altfel spus, toate tuplurile unei relaii trebuie s
difere cel puin prin valoarea unui atribut: cheia*
*heia reprezint un atribut (sau un grup de atribute) care are rolul de a identifica n
mod unic fiecare tuplu al unei relaii, astfel nct nu pot exista dou tupluri diferite care s
aib valori identice pe domeniul unei chei. n cadrul abordrii relaionale exist patru tipuri de
chei care pot fi identificate:
candidat;
primar;
alternant (n funcie de sursa citat, ntlnim n litaratur i termenul de cheie
alternativ);
strin.
Dintre cele patru tipuri de chei, primele trei se analizeaz la nivelul unei singure relaii,
n timp ce cheia strin apare atunci cnd asociem dou sau mai multe relaii (este cea care
asigur practic legtura logic ntre diferite relaii).
Atunci cnd analizm o relaie, primul pas pe care l facem este acela al identificrii
cheilor candidat. Dintre cheile candidat identificate, se alege una ca fiind cheia primar a
relaiei respective, restul cheilor candidat devenind chei alternante. n general, vom alege ca
i cheie primar, acea cheie candidat care este format din numrul minim de atribute. n
cazul n care am identificat mai multe chei candidat i fiecare dintre ele au acelai numr de
atribute, atunci oricare din cheile candidat pot deveni cheie primar, alegerea fcndu-se n
funcie de opiunea i dorina proiectantului.
34
Dei pot exista mai multe chei candidat, este bine s reinem c fiecare relaie are o
singur cheie primar, care n anumite situaii poate fi format chiar din toate atributele ei.
Pentru a exemplifica tipurile de chei, abordate pn acum doar la nivel teoretic, vom
folosi relaia din exemplul C"!" Aa cum aminteam anterior, iniial trebuie s identificm cheile
candidat ale relaiei $tudent. Cu alte cuvinte, trebuie s identificm acele atribute sau grupuri
de atribute pentru care nu pot exista valori duplicate, indiferent de numrul de tupluri ale
relaiei $tudent (iniial se analizeaz atributele n mod individual i apoi se fac combinaii ntre
ele, pentru a identifica n mod clar toate cheile). Vom ncepe cu atributul nume: n mod cert,
acest atribut nu poate fi considerat cheie deoarece oricnd pot exista doi studeni cu acelai
nume. Acelai lucru putem afirma i despre atributul pren.
Totodat, nici atributele facult i spec nu sunt chei candidat deoarece la o facultate i
la o specializare sunt nscrii mai muli studeni. n exemplul C"H am redat alte tupluri pentru
relaia $tudent i n care se poate observa c avem valori duplicate pe domeniile analizate.
E0emplul *1)
$tudent 4 cnp nr=matr nume pren facult spec 6
1701212120139 1234 Popa Dan FSE E
2731210176143 1987 Darie Dan FD AP
1801009129145 4432 Popa on FSE E
n continuare ne vom opri asupra celor dou atribute rmase, i anume cnp i nr=matr.
Cu siguran, c la ntrebarea ,Sunt atributele cnp i nr=matr chei candidat? am primi un
singur rspuns: ,'. Aa s fie oare? Nu este aa. ar argumentul este dat de exemplul 4.4.
E0emplul *1*
1701212120139 1234 Popa Dan FSE E
2731210176143 1987 Darie Dan FD AP
2731210176143 5634 Darie Dan FSE FB
Aa cum observm, pe domeniul aferent atributului cnp, avem dou valori identice:
este situaia n care o persoan este student la dou faculti diferite (i nu este singura
situaie posibil). Deci, nici atributul cnp nu poate fi cheie candidat. De ce am ajuns s facem
o astfel de greeal i s considerm c cnp poate fi cheie? Probabil c ne-am gndit la
faptul c nu pot existat dou persoane cu acelai CNP. Este adevrat: nu exist dou
persoane cu acelai CNP, ns schema relaiei $tudent nu conine doar atribute despre o
persoan, ceea ce nseamn c trebuia s ne gndim dac pentru un anume CNP putem
identifica cel puin o valoare a unui alt atribut care s se modifice fa de tuplul de la care am
plecat.
n ceea ce privete atributul nr=matr, putem spune c el este cheie candidat. Cum
artm asta? S plecm de la situaie din exemplul 4.5.
E0emplul *1+
$tudent 4 *np nr=matr nume pren facult spec 6
1701212120139 1234 Popa Dan FSE E
? 1234 ? ? ? ?
35
Astfel, considerm c avem un tuplu care reprezint un student cu numrul matricol
!#HC, care este la facultatea F$+, specializarea 0+. Dac vom putea nlocui semnul ntrebrii
aferent unui atribut cu o valoare diferit de cea aflat pe cellalt tuplu (evident, pentru acelai
atribut), atunci cele dou tupluri difer, ceea ce nseamn c putem avea valori duplicate pe
domeniul respectiv de valori. n mod cert, un student cu o anumit matricol (n cazul nostru
1234) nu poate avea alt cod numeric personal, alt nume sau alt prenume. De asemenea, un
student nu poate fi la dou specializri diferite (n aceeai facultate sau n faculti diferite)
avnd aceeai matricol. Asta nseamn c dac pe tuplul doi am avea 1234 ca matricol,
atunci toate celelalte valori ar fi identice cu cele de la primul tuplu, situaie care ar face ca
cele dou tupluri s fie identice i aa cum aminteam n prima parte, o astfel de situaie nu
este permis (acest aspect este reprezentat n exemplul C"I). Deci, atributul nr=matr este
cheie candidat a relaiei $tudent.
E0emplul *1,
1701212120139
1234
Popa Dan FSE E
1701212120139
1234
Popa Dan FSE E
Odat identificat o cheie candidat, procesul nu este finalizat. n continuare va trebui
s cutm i diferite combinaii de atribute care ar putea fi cheie. Singurul lucru clar este
acela c atributul nr=matr nu poate face parte din nici o cheie compus (cheia trebuie s fie
format din numrul minim de atribute care identific n mod unic tuplurile unei relaii). Dac
vom avea n vedere algoritmul descris anterior, vom mai identifica o cheie candidat:
cnpJfacultJspec. De ce toate trei? Dac ne-am gndi la atributele cnpJfacult am vedea c
un student ntr-o facultate, poate fi la mai multe specializri (spre exemplu, la forme diferite
de nvmnt) n timp ce pentru combinaia de atribute cnpJspec ar putea apare valori
duplicate n cazul n care mai multe faculti ar avea o aceeai specializare. ns, n situaia
n care le analizm pe toate trei am ajunge la concluzia c o persoan nu poate face aceeai
specializare de dou ori ntr-o facultate
19
.
Sintetiznd, pentru relaia $tudent am identificat dou chei candidat:
nr=matrE
cnpJfacultJspec"
Dintre cele dou chei candidat, vom alege cheia primar ca fiind nr=matr deoarece are
mai puine atribute dect cealalt cheie, ceea ce nseamn c, n final vom avea:
chei candidat: nr=matr, cnpJfacultJspec;
cheie primar: nr=matr;
cheie alternant: cnpJfacultJspec.
Astfel, n final, relaia noastr ar arta astfel:
19
<ecani"mul !e i!entificare corect /i complet a c=eilor unei relaii "e 'a realiza numai !up parcurgerea /i 5nelegerea
proce"ului !e normalizare a unei baze !e !ate relaionale (la pagina 18 au fo"t prezentate "uccint c6te'a a"pecte !e baz
"pecifice normalizrii). Pentru cei intere"ai " /tie mai multe !e"pre proce"ul !e normalizare /i po"tnormalizare3
recoman!m cartea profe"orului <. +otac=e> (roiectarea !a)eor de date* Normai)are +i postnormai)are, Impement-ri
S.L +i Orace.
3,
E0emplul *1-1 $tudent 4cnp, nr=matr, nume, pren, facult, spec6
Aa cum observm, atributul/atributele care formeaz cheia primar a relaiei vor
apare subliniate.
n mod normal, relaia de mai sus este una nenormalizat i este evident c ea
introduce redundan. Astfel, ar fi mai simplu dac datele referitoare la faculti, respectiv
specializri, le-am gestiona separat, n relaii de sine stttoare. n acest caz, redundana ar
fi n mare msur nlturat, iar procesul de identificare a cheilor ar fi mult simplificat. Astfel,
n exemplul C"K vom descompune relaia n alte trei relaii:
E0emplul *1.
$tudent 4cnp, nr=matr, nume, pren6
Facultate 4facult, profil6
$pecializare 4spec, form=nv6
n relaia Facultate, atributul facult este cheie primar deoarece considerm c nu pot
exista dou faculti cu acelai nume n cadrul unei universiti. De asemenea, atributele
spec i form=nv formeaz cheia primar n relaia $pecializare numai luate mpreun
deoarece o anumit specializare poate apare la diferite forme de nvmnt (spre exemplu,
specializarea Contabilitate i nformatic de Gestiune are studeni i la forma de nvmnt
Li, i la 0fr).
Astfel, prin descompunerea relaiei iniiale n cele trei relaii din exemplul C"K am
argumentat prima parte a definiiei bazei de date relaionale. Aa cum observm, n acest
moment structura noastr este format din trei colecii organizate n care:
$tudent conine doar date de strudeni;
Facultate include ca realizri (tupluri) doar facultile gestionate;
$pecializare care se refer la specializrile fiecrei faculti gestionate.
2egturi 3ntre relaii
Dac analizm cu atenie relaiile din exemplul C"K observm c redundana datelor a
fost nlturat, n sensul c aceleai date nu le mai gestionm de mai multe ori n cadrul unei
relaii, aa cum se ntmpla n exemplul C"M, unde numele unei faculti ar fi aprut de fiecare
dat cnd mai gestionam un student al aceleai facultai (realizarea F$+, ca valoare a
atributului facult ar fi aprut de fiecare dat cnd am fi avut un student al acestei faculti).
ns, n acelai timp, n exemplul C"M erau disponibile informaii complete despre student
(nume, prenume, facultatea la care studiaz, specializarea la care este nmatriculat). Odat
cu descompunerea n mai multe relaii, observm c aceste informaii nu le mai avem: exist
trei relaii n care avem date personale despre studeni (relaia $tudent), date despre faculti
(relaia Facultate), respectiv date despre specializri (relaia $pecializare), fr ns s
putem spune la ce facultate sau specializare este un anume student.
3-
n acest context, pentru a putea oferi aceste informaii, trebuie s asociem relaiile
modelului din exemplul C"K. Astfel, abordarea relaional propune patru tipuri de legturi ntre
relaii.
"eg$tura binar$ )() unu la unu!
Definiie. Atunci cnd asociem dou relaii fiu, legtura dintre ele se realizeaz prin
migrarea cheilor primare din fiecare relaie, sub forma cheii strine n relaiile
corespunztoare.
-bs" n cadrul unei asocieri binare, fiecare dintre cele dou relaii poate fi att relaie fiu, ct
i relaie printe.
Definiie. Spunem despre o relaie c este fiu atunci cnd unui tuplu din relaia
respectiv i corespunde un singur tuplu n relaia cu care s-a asociat.
Definiie. O relaie este considerat printe atunci cnd unui tuplu din relaia respectiv
i pot corespunde mai multe tupluri n relaia cu care s-a asociat.
Definiie. Cheia strin reprezint un atribut (sau un grup de atribute) care
ndeplinete rolul de cheie primar n cadrul relaiei din care a migrat. Practic, cheia strin
este cea care permite crearea legturilor logice dintre relaii. Ca valori ale atributelor care
formeaz cheia strin putem avea fie valori care se regsesc pe domeniul cheii primare n
relaia din care provine cheia strin, fie valoarea 51// (n literatura de specialitate, aceast
constrngere este numit restricie referenial).
E0emplul *1/: Fie urmtoarele dou relaii:
*lient ( cnp nume pre
n
localitate )
1701212120139 Popa Dan Galai
2711010120121 Darie Alina Brila
1721209145123 Preda Marin Galai
Legitimaie ( nr_leg valabilitate )
12121 2
23456 2
187654 3
Prin intermediul relaiilor *lient i /egitimaie ncercm s modelm situaia accesului
ntr-un supermarket pe baza unei legitimaii. Pentru a realiza legtura dintre relaiile asociate,
va trebui s identificm mai nti tipul relaiilor (fiu sau printe). Astfel, pe baza definiiilor
prezentate anterior, observm c ambele relaii sunt fiu deoarece fiecare client, la un
moment dat, nu poate avea dect o singur legitimaie care s-i permit accesul n
supermarket. Cu alte cuvinte, pentru exemplul C"N, Popa Dan nu poate avea dect o singur
legitimaie, ceea ce nseamn c unui tuplu din relaia *lient nu-i poate corespunde dect un
singur tuplu n relaia /egitimaie. Analiznd n acelai mod, este evident c o legitimaie nu
poate corespunde mai multor clieni.
Astfel, deoarece ambele relaii sunt fiu, tipul de legtur dintre cele dou este 1-1.
Conform definiiei enunate, atributul cnp va migra din relaia *lient (unde este cheie primar)
n relaia /egitimaie, unde va ndeplini rolul de cheie strin. n acelai mod, atributul nr=leg
va migra din relaia /egitimaie n relaia *lient, iar modelul va arta ca n exemplul C"!D.
E0emplul *1'&:
38
*lient ( cnp nume pren localitat
e
nr=leg )
1701212120139 Popa Dan Galai 23456
2711010120121 Darie Alina Brila 12121
1721209145123 Preda Marin Galai 187654
/egitimai
e
( nr=leg valabilitat
e
cnp )
12121 2 2711010120121
23456 2 1701212120139
187654 3 1721209145123
Dup migrarea cheii primare sub forma cheii strine, putem spune c am realizat
legtura ntre relaiile asociate, astfel nct s putem spune despre un client ce numr de
legitimaie are, sau plecnd de la numrul legitimaiei, s putem identifica fr ambiguitate
care este deintorul acesteia.
"eg$tura binar$ )(n unu la mai mul+i!
Definiie. Atunci cnd asociem dou relaii, dintre care una este relaie fiu, iar cealalt
este printe, legtura dintre ele se realizeaz prin migrarea cheii primare din relaia printe,
sub forma cheii strine n relaiile fiu.
Pentru exemplificare, vom pleca de la relaiile $tudent i $pecializare din exemplul
C"K.
E0emplul *1'':
$tudent 4 nr=matr cnp nume pren
6
1111 1701212120139 Popa Dan
2222 2711010120121 Darie Alina
3333 1721209145123 Preda Marin
Specializare ( cod_spe
c
spec form_nv
)
61 CG Z
51 FB Z
52 FB FR
Pentru a avea o eviden clar a apartenenei unui student la o specializare, va trebui
s realizm legtura dintre cele dou relaii. Ca i n cazul primului tip de legtur, i de
aceast dat vom pleca de la identificarea tipurilor de relaii, rspunznd pe rnd la
ntrebarea: ,1nui tuplu din relaia O c;te tupluri n relaia 2 i pot corespunde, unde X i Y
sunt cele dou relaii pe care le asociem.
a. dentificarea tipului pentru relaia $tudent: ntrebarea la care trebuie s rspundem este:
,1n student la c;te specializri poate fiP. La aceast ntrebare, o parte din cititori ar
putea spune c un student poate fi la una sau mai multe specializri, n timp ce alii
consider c un student nu poate fi dect la o singur specializare. Rspunsul corect este
cel de-al doilea deoarece un student, care are asociat o anumit matricol, nu poate fi la
39
mai multe specializri. Este clar c o persoan, cu un anume cod numeric personal,
poate fi la mai multe specializri, caz n care numrul matricol este altul. Altfel spus,
studentul Popa Dan cu matricola 1111 nu poate aparine dect unei singure specializri.
Concluzionnd vom afirma despre $tudent c este relaie fiu.
b. dentificarea tipului pentru relaia $pecializare n acest caz, rspunsul la ntrebarea: ,/a
o specializare c;i studeni pot fi nmatriculaiP este ,mai muli, ceea ce nseamn c
unui tuplu din relaia $pecializare i corespund mai multe tupluri din relaia $tudent. n
acest caz, $pecializare este relaie printe.
Plecnd de la analiza fcut anterior, am stabilit c relaia $tudent este fiu n timp ce
relaia $pecializare este printe: legtura dintre cele dou se va realiza prin migrarea cheii
primare din relaia printe (cod=spec din $pecializare) sub form de cheie strin n relaia
$tudent, iar modelul va arta ca n exemplul C"!#.
E0emplul *1'(:
$tudent 4 nr=matr cnp nume pre
n
cod=spec )
1111 1701212120139 Popa Dan 61
2222 2711010120121 Darie Alina 52
3333 1721209145123 Preda Marin 61
Specializare ( cod_spe
c
spec form_nv
)
61 CG Z
51 FB Z
52 FB FR
n exemplul C"!# observm c, dup crearea legturii, suntem n msur s
identificm specializarea la care este nmatriculat fiecare student. Astfel, atunci cnd vom
dori s aflm care este specializarea i forma de nvmnt a studentului Preda Marin, se va
realiza o interogare a datelor din relaia $pecializare i se va identifica acel tuplu care are ca
valoare a atributului cod=spec, valoarea aferent cheii strine din relaia $tudent, adic 61.
Dup parcurgerea secvenial a tuplurilor din $pecializare vom vedea c studentul este la
specializarea *0%, forma de nvmnt L0.
"eg$tura binar$ n(n mai mul+i la mai mul+i!
Definiie. Atunci cnd asociem dou relaii printe, legtura dintre ele se realizeaz
prin generarea unei noi relaii care va avea ca i cheie primar, cheile primare ale relaiilor
asociate. Aceast nou relaie poate include i alte atribute (n afara celor care formeaz
cheia primar) care reies din contextul problemei modelate.
Fie relaiile Factur i (rodus din exemplul 4.13:
E0emplul *1'):
Factur
4 serie=fact nr=fact val=fac

t
data=fact )
DX 1111 100 10.10.2008
4
VR 2222 200 10.10.2008
DF 3333 300 12.10.2008
Produs ( cod_produ
s
den_prod um stoc )
11 Telefon Nokia Buc 0
22 TV Samsung Buc 2
33 Laptop Asus Buc 2
Considerm c relaia Factur permite gestionarea facturilor primite de un comerciant,
n timp ce n relaia (rodus sunt gestionate produsele comercializate. Odat ce am
considerat atributul cod=produs ca fiind cheia primar a relaiei (rodus vom presupune c nu
vor exista dou produse care s aib acelai cod, garantndu-se astfel (prin semantica
specificat) unicitatea valorilor pe domeniul atributului cod=produs. Totodat, atributul stoc
are rolul de a gestiona cantitatea aferent unui produs care se gsete la un moment dat n
stocul comerciantului.
Plecnd de la cele dou relaii, dorim s punem n eviden care este coninutul
fiecrei facturi (produsele i cantitile coninute de fiecare factur). niial, vom identifica tipul
relaiilor pentru a putea realiza legtura dintre ele. Astfel, relaia Factur este printe
deoarece considerm c o factur poate conine unul sau mai multe produse. Totodat, si
relaia (rodus este tot printe deoarece un produs poate fi achiziionat prin intermediul mai
multor facturi. Deci, ambele relaii sunt de tipul printe; asta nseamn c se va crea o nou
relaie, care va avea cheia primar format din cheile primare ale celor dou relaii asociate.
E0emplul *1'*:
provizionar
e
4 serie=fac
t
nr=fac
t
cod=produ
s
cant=aprov )
DX 1111 11 10
DX 1111 33 15
DF 3333 11 5
Aa cum se observ, legtura de tipul mai muli la mai muli a fost pus n eviden
prin noua relaie generat: provizionare. n cadrul acesteia, pe primele dou tupluri am pus
n eviden faptul c o factur (DX 1111) poate conine mai multe produse (conine produsele
cu codul 11 i 33) n timp ce un produs (cel cu codul 11) poate fi achiziionat prin intermediul
mai multor facturi (se gsete att pe factura DX 1111 ct i pe DF 3333).
n cadrul relaiei provizionare observm un nou atribut, care nu se regsea la nivelul
relaiilor pe care le-am asociat. Acest atribut apare n cadrul acestei noi relaii deoarece o
realizare a acestuia are loc numai atunci cnd asociem cte un tuplu din fiecare relaie (nu
putem avea o cantitate aprovizionat dac exist produsul, dar nu exist factura i, n acelai
timp, nici dac exist factura i nu exist produsul).
"eg$tura dintre trei sau mai multe rela+ii
Atunci cnd asociem mai mult de dou relaii, legtura dintre ele se realizeaz prin
definirea unei noi relaii, care va avea cheia primar format din cheile primare ale tuturor
relaiilor, mpreun cu alte atribute care reies din contextul problemei modelate. Practic, este
41
un caz particular al legturii binare mai muli la mai muli, fr ns s mai necesite n
prealabil identificarea tipului fiecrei relaii.
Revenind la exemplul C"K, vom asocia cele trei relaii cu scopul de a putea preciza cu
claritate facultatea i specializarea la care este nmatriculat fiecare student.
E0emplul *1'+
$tudent 4 nr=matr nume pren )
111 Preda Marin
222 Darie Alina
333 onescu Ctlin
Facultate ( facult profil )
Stiine Economice Economic
Drept Administrativ
Specializare ( cod=spec Spec form_nv
751 FB Z
752 FB FR
662 AP FR
n urma asocierii celor trei relaii, se va genera o nou relaie care se va identifica prin
intermediul atributelor nr=matr, facult i cod=spec, aa cum se observ n exemplul C"!I.
E0emplul *1',
$tudi
u
4 nr=mat
r
facult cod_spec )
111 Stiine Economice 751
222 Drept 662
333 Stiine Economice 751
Cu ajutorul acestei noi relaii, putem spune despre (reda Marin c este student la
facultatea de Qtiine +conomice, la specializarea F&, forma de nvmnt 0F,.
Abia n acest moment putem spune c am argumentat pe deplin definiia bazei de
date relaionale: am creat diferite colecii de date organizate, dup care am stabilit legturile
logice dintre acestea pentru a avea o viziune complet asupra ntregului volum de date care
formeaz respectiva baz de date. n acest fel, utilizatorul va putea, prin intermediul
comenzilor de interogare specifice SGBD-ului utilizat, s acceseze i s utilizeze n acelai
timp toate datele gestionate n baza de date.
4*
Algebra relaional 4 operatorii relaionali
Algebra relaional se refer la diferii operatori care au ca operanzi relaiile, fiind
conceput de cercettorul E.F. Codd. n funcie de aritatea operatorului, rezultatul aplicrii
acestuia la una sau la dou relaii va fi tot o relaie. n prezentarea operaiilor, vom pleca de
la presupunerea c fiecare relaie are un numr finit de tupluri distincte i sunt descrise prin
intermediul unei mulimi finite de atribute [Riccardo, 2001, p.54].
Aceste operaii specifice algebrei relaionale sunt folosite pentru formalizarea
limbajului de cereri al sistemului de gestiune al bazelor de date relaionale. Ele sunt
implementate n funciile de manevrare a datelor aferent sistemului de gestiune i sunt
disponibile utilizatorului cu ajutorul comenzilor limbajului de manevrare a datelor sau a
limbajului de interogare ale sistemului de gestiune [Georgescu, Georgescu, 2005, p.93].
Cererile specifice algebrei relaionale se pot exprima prin cinci operaii asupra
relaiilor, ntlnite n literatur sub numele de operaii de baz, i anume: reuniunea,
diferena, produsul cartezian, proiecia i selecia. Dintre aceste cinci operaii, primele trei
presupun existena a dou relaii n timp ce urmtoarele se aplic pentru o singur relaie.
1. %euniunea. Reuniunea a dou relaii i &
20
, notat # 0 , este o relaie care va avea
schema identic cu a relaiilor reunite i care va include ca tupluri, toate tuplurile celor dou
relaii, considerate o singur dat.
E0emplul *1'-
$tud
!
4 nr=mat
r
nume pren )
111 Preda Marin
222 Darie Alina
333 onescu Ctlin
$tud
#
4 nr=mat
r
nume pren )
CCC Manea -ana
333 onescu Ctlin
RRR 'ragomi
r
lina
= Stud2 Stud1 4 nr=mat
r
5ume pren )
111 Preda Marin
222 Darie Alina
333 onescu Ctlin
CCC Manea -ana
RRR 'ragomi
r
lina
*
Relaiile A i B trebuie s aib aceeai schem definit pe aceleai domenii.
43
2. iferena. Diferena a dou relaii i &
21
, notat & S , este o relaie care va avea schema
identic cu a relaiilor iniiale i ca realizri toate tuplurile primei relaii care nu se regsesc n
cea de-a doua relaie.
Astfel, dac realizm diferena relaiilor $tud! i $tud# din exemplul C"!M, rezultatul
este urmtorul:
= Stud2 \ Stud1 4 nr=mat
r
nume pren )
111 Preda Marin
222 Darie Alina
3. Produsul cartezian. Fie relaiile (cu aritatea a) i & (cu aritatea b)
22
. Produsul cartezian
al celor dou relaii, notat B A este o relaie care are aritatea a+b i care va conine toate
tuplurile rezultate prin concatenarea unui tuplu din cu fiecare tuplu din &. Trebuie menionat
faptul c atunci cnd schemele celor dou relaii includ i atribute comune, atunci n schema
produsului cartezian, cele dou atribute vor apare de dou ori, ns cu nume diferite (o relaie
nu poate avea dou atribute cu acelai nume).
E0emplul *1'.
$tudent 4 nr=matr nume pren )
111 Preda Marin
222 Darie Alina
333 onescu Ctlin
'isciplin
4 cod=dis
c
denumire tip=disc )
$+! &aze de
date
curs
SE2 Baze de date laborator
$+H *ontabilitate $eminar
Aa cum se observ, aritatea ambelor relaii este 3, ceea ce nseamn c dup
realizarea produsului cartezian asupra celor dou relaii, aritatea va fi 6 (relaia rezultat n
urma operaiei
'isciplin $tudent
va avea ase atribute), aa cum se observ mai jos:
Discipin - Student
4 nr=mat
r
nume pren
cod=dis
c
denumire tip=disc )
111 Preda Marin $+! 0nformatic curs
111 Preda Marin SE2 nformatic laborator
111 Preda Marin $+H
*ontabilitat
e
seminar
222 Darie Alina $+! 0nformatic curs
222 Darie Alina SE2 nformatic laborator
222 Darie Alina $+H
*ontabilitat
e
seminar
333 onescu Ctlin $+! 0nformatic curs
333 onescu Ctlin SE2 nformatic laborator
333 onescu Ctlin $+H *ontabilitat seminar
*1
**
Schemele relaiilor A i B sunt diferite, dar pot exista atribute comune.
44
e
4. Proiecia. Proiecia se aplic unei singure relaii de aritate a, se noteaz cu
i se
realizeaz dup un numr de atribute, a
!
, a
#
, ., a
n
, care trebuie s fie incluse n schema
relaiei . Noua relaie va avea schema dat de atributele dup care se realizeaz proiecia,
Totodat, relaia obinut dup realizarea proieciei va avea acelai numr de tupluri ca
relaia iniial.
E0emplul *1'/ Fie relaia $tudent:
$tuden
t
4 nr=mat
r
cnp nume pren
6
1111 1701212120139 Popa Dan
2222 2711010120121 Darie Alina
3333 1721209145123 Preda Marin
Plecnd de la aceast relaie, dorim s realizm proiecia dup atributele nr=matr,
nume i pren" Astfel, vom obine urmtoarea relaie:
= 4$tudent6
pren nume, nr=matr,
4 nr=mat
r
nume pren
6
1111 Popa Dan
2222 Darie Alina
3333 Preda Marin
5. Selecia. Selecia se definete pentru o singur relaie de aritate a, se noteaz cu i
se realizeaz pe baza unei condiii logice. Noua relaie va avea aceeai schem ca relaia
iniial i va conine doar acele tupluri care respect condiia dup care se realizeaz
selecia.
E0emplul *1(& Fie relaia $tudent:
$tuden
t
4 nr=mat
r
nume pren media )
1111 Popa Dan 7.00
2222 Darie Alina 8.00
3333 Preda Marin 9.00
Plecnd de la relaia de mai sus, dac dorim s realizm o selecie a studenilor cu
media mai mare sau egal cu opt, vom ajunge la urmtoare relaie:
=
>=
) (
8
Student
media
4 nr=mat
r
nume pren media )
2222 Darie Alina 8.00
3333 Preda Marin 9.00
45
Pe lng operaiile amintite anterior, se mai pot utiliza i alte operaii, numite operaii
derivate i care se bazeaz pe operaiile de baz. Utilizarea n practic a operaiilor derivate
ofer o flexibilitate sporit a cererilor de interogare a bazei de date i faciliteaz, n cele mai
multe situaii, obinerea unor rspunsuri mai rapide. Dintre operaiile derivate utilizate mai
frecvent amintim:
6. 5ntersecia. ntersecia a dou relaii i &
23
, notat & , este o relaie care va avea
schema identic cu a relaiilor intersectate, iar ca realizri doar tuplurile comune celor dou
relaii.
E0emplul *1('
$tud
!
4 nr=mat
r
nume pren )
111 Preda Marin
222 Darie Alina
333 onescu Ctlin
$tud
#
4 nr=mat
r
nume pren )
CCC Manea -ana
333 onescu Ctlin
RRR 'ragomi
r
lina
= $tud# $tud! 4 nr=mat
r
nume pren )
333 onescu Ctlin
7. 6niunea. Uniunea se definete pentru dou relaii i & (de aritate a, respectiv b), o
condiie logic ntre dou valori ale unor atribute ce aparin celor dou relaii
24
i se noteaz
& T O T
c
. Rezultatul uniunii va fi o relaie de aritate aJb, cu schema dat de reuniunea
atributelor celor dou relaii i care va conine toate tuplurile aferente produsului cartezian
dintre i & care respect condiia menionat. Cu alte cuvinte, uniunea a dou relaii se
realizeaz n doi pai:
a. realizarea produsului cartezian dintre relaii;
b. selecia tuplurilor conform condiiei logice.
n cazul n care condiia c este de egalitate, atunci operaia se numete echiuniune. n
plus, dac vom realiza o proiecie dup atributele primei operaii, operaia se numete semi-
uniune-st;nga, iar dac se face dup atributele relaiei din dreapta (a doua relaie) se va
numi semi-uniune-dreapta. n continuare vom exemplifica uniunea i echiuniunea.
E0emplul *1(( Fie urmtoarele relaii:
prov 4 s=fact nr=fact cod=pro
d
cant=a )
*3
*4
n cazul uniunii, cele dou atribute trebuie s fie cte unul din fiecare relaie.
4,
DX 1122 P1 20
DX 1122 P2 10
JZ 2233 P3 15
*omand
4 cod=cm
d
cand=c )
C1 20
C2 12
C3 10
n cadrul relaiei prov se presupune c avem situaia aprovizionrilor, n relaia
*omand avem o eviden a produselor comandate, iar semantica atributelor este
urmtoarea:
s=fact reprezint seria unei facturi;
nr=fact reprezint numrul facturii;
cod=prod codul produsului achiziionat prin intermediul unei facturi;
cant=a se refer la cantitatea aferent unui produs care se gsete pe o factur;
cod=cmd codul unei comenzi (se presupune c dou comenzi diferite vor avea
coduri diferite);
cant=c reprezint cantitatea comandat prin intermediul unei comenzi.
Pentru a realiza uniunea celor dou relaii, aminteam anterior c primul pas care
trebuie fcut este realizarea produsului cartezian.
prov X Comand= 4 s=fac
t
nr=fac
t
cod=pro
d
cant=
a
cod=cm
d
cant=c )
DX 1122 P1 20 C1 20
DX 1122 P1 20 C2 12
DX 1122 P1 20 C3 10
DX 1122 P2 10 C1 20
DX 1122 P2 10 C2 12
DX 1122 P2 10 C3 10
JZ 2233 P3 15 C1 20
JZ 2233 P3 15 C2 12
JZ 2233 P3 15 C3 10
Dup realizarea produsului cartezian, vom face selecia tuplurilor pe baza condiiei
cant=a U@ cant=c.
4-
prov
c c a n t
a c a n t
/
?
?
@ @
< =
Comand=
4 s=fac
t
nr=fac
t
cod=pro
d
cant=
a
cod=cm
d
cant=c )
DX 1122 P1 20 C1 20
DX 1122 P2 10 C1 20
DX 1122 P2 10 C2 12
DX 1122 P2 10 C3 10
JZ 2233 P3 15 C1 20
n cazul n care condiia este cant=a@cant=c, atunci vom avea o echiuniune a celor
dou relaii, aa cum se observ n exemplul C"#H:
E0emplul *1(): Echiuniunea relaiilor prov i *omand.
prov
c c a n t
a c a n t
/
?
?
@ @
=
Comand=
4 s=fac
t
nr=fac
t
cod=pro
d
cant=
a
cod=cm
d
cant=c )
DX 1122 P1 20 C1 20
DX 1122 P2 10 C3 10
8. 6niunea natural. Uniunea natural a relaiilor i &, notat | A X B | se poate realiza
numai n cazul n care cele dou relaii au un set de atribute comune. Astfel, uniunea
natural se obine prin selectarea din produsul cartezian al celor dou relaii a tuplurilor ce
conin valori comune pentru atributele cu acelai nume. Schema relaiei va fi dat de
reuniunea atributelor celor dou relaii (ceea ce nseamn c atributele comune vor apare o
singur dat).
E0emplul *1(): Fie urmtoarele relaii:
$tuden
t
4 nr=matr nume pren )
111 Popa Dan
222 Darie Alin
333 Moga Dana
'isc 4 den=dis
c
nr=mat
r
not )
Finane 333 9
Birotic 222 10
Birotic 333 8
a" Se realizeaz produsul cartezian al celor dou relaii:
$tudent X Disc =
4 s"nr=mat
r
num
e
pren den=dis
c
d"nr=mat
r
not )
111 Popa Dan Finane 333 9
111 Popa Dan Birotic 222 10
48
111 Popa Dan Birotic 333 8
222 Darie Alin Finane 333 9
222 Darie Alin Birotic 222 10
333 Moga Dana Finane 333 9
333 Moga Dana Birotic 222 10
b. La acest pas va trebui s determinm condiia dup care se va realiza selecia. Aa cum
observm, atributul comun celor dou relaii este nr=matr, ceea ce nseamn c uniunea
natural se va face pe baza condiiei $tudent"nr=matr = 'isc"nr=matr.
c. Dup identificarea condiiei, ea se va aplica asupra produsului cartezian realizat la punctul
a:

=
=
'isc6 O Student
matr nr Disc matr nr Student
(
? . ? .
4 s"nr=mat
r
num
e
pren den=dis
c
d"nr=mat
r
not )
333 Moga Dana Finane 333 9
d. n final, se realizeaz o proiecie asupra relaiei obinute la punctul c dup mulimea
atributelor celor dou relaii, considerate o singur dat. Dup realizarea proieciei, vom
obine:
| Student X Disc |=
4nr=mat
r
num
e
pren den=dis
c
not )
222 Darie Alin Birotic 10
333 Moga Dana Finane 9
333 Moga Dana Birotic 8
9. 6niunea e0tern. Uniunea extern (outer join) va include toate tuplurile uniunii naturale, la
care se adaug cte un tuplu pentru acele tupluri dintr-o relaie care nu au corespondent n
cealalt relaie. Tuplurile adugate au valoarea 51// pentru toate atributele ce nu apar n
relaia din care provin. Uniunea extern se noteaz astfel: T T &, unde i & sunt cele
dou relaii.
Plecnd de la relaiile $tudent i 'isc din exemplul C"#H i de la uniunea natural
$tudent | X | 'isc, vom avea urmtoarea uniune extern:
E0emplul *1(*
Student T T Disc
=
4nr=mat
r
num
e
pren den=dis
c
not )
111 Popa Dan 51// 51/
/
49
Aa cum se observ, n relaia $tudent exist un singur tuplu care nu are
corespondent n relaia 'isc: n acest caz, tuplul va fi adugat n relaia aferent uniunii
externe, iar valorile aferente atributelor din relaia 'isc pentru care nu exist corespondent
vor primi valoarea 51//. n ceea ce privete relaia 'isc, nu exist nici un tuplu care s nu
aib corespondent n relaia $tudent (altfel spus, valorile 222 i 333, ca realizri ale
atributului nr=matr n relaia 'isc, se regsesc n relaia $tudent pe domeniul de valori al
atributului nr=matr).
De asemenea, exist dou operaii derivate din uniunea extern i anume uniune
extern st;nga 4left outer join6 i uniune extern dreapta (right outer join). n ceea ce privete
uniunea extern stnga, relaia va conine toate tuplurile uniunii naturale la care se vor
aduga cele ale primei relaii (considerat relaia din stnga) care nu au corespondent n
relaia din dreapta. n dreptul acestor valori se va trece valoarea 51// (exemplul #"#R). n
mod similar se realizeaz uniunea extern stnga, numai c n acest caz vor fi adugate
uniunii naturale doar tuplurile relaiei din dreapta (exemplul #"#I).
E0emplul *1(+
Student T Disc
=
4nr=mat
r
num
e
pren den=dis
c
not )
111 Popa Dan 51// 51/
/
E0emplul *1(,
Student T Disc
=
4nr=mat
r
num
e
pren den=dis
c
not )
n exemplul C"#I, uniunea extern dreapta este identic cu uniunea natural deoarece
nu exist tupluri n relaia din dreapta (relaia 'isc n cazul nostru) care s nu aib
corespondent n cealalt relaie.
Probleme rezolvate
'1 7ai multe societi comercializeaz pe baz de factur diferite produse1
Folosind abordarea relaionl8 s se pun 3n eviden emitentul "i coninutul fiecrei
facturi1
Pentru a soluiona problema propus anterior, va trebui s parcurgem urmtoarele
etape:
a) identificarea atributelor care reies din contextul problemei;
5
b) definirea relaiilor pe baza atributelor identificate la punctul a6;
c) crearea legturilor dintre relaiile identificate la punctul b6.
a) Pentru a avea garania unei rezolvri corecte a unei probleme, va trebui ca nainte
de a identifica atributele s rspundem la urmtoarea ntrebare: ,(entru problema dat,
avem nevoie de atribute pentru cine, sau pentru ceP Astfel, pentru problema noastr, dac
ncercm s rspundem la aceast ntrebare, vom constata c va trebui s identificm
atribute despre societi, produse i facturi. Cu alte cuvinte, aceste colecii pe care le-am
identificat acum vor reprezenta relaiile pe care le vom defini la punctul b6.
Dup ce am identificat aceste colecii, va trebui s descriem minim dou atribute care
caracterizeaz fiecare din aceste colecii de date. Este important ca atunci cnd identificm
atributele, s avem n vedere c fiecare relaie are n mod obligatoriu o cheie primar, ceea
ce nseamn c va trebui s ne gndim nc de la acest pas care va fi atributul sau atributele
care vor avea rolul de a identifica n mod unic fiecare tuplu al relaiilor de la punctul b6. Astfel,
n cazul nostru, putem considera c referitor la o societate ne va interesa codul unic de
identificare al acesteia (care este unic pentru toate societile descrise) i denumirea ei. n
ceea ce privete produsul, dac ne gndim la un atribut care s identifice unic fiecare
produs, atunci acesta poate fi cod=produs, pentru care introducem o semantic suplimentar
i spunem c nu pot exista dou produse care s aib acelai cod. De asemenea, tot
referitor la un produs considerm c ne mai intereseaz denumirea acestuia, unitatea de
msur i eventual cantitatea care exist n stoc la un moment dat.
n ceea ce privete factura, tim cu toii c aceasta se identific printr-o serie i un
numr i c fiecare factur are o valoare i o dat a emiterii. Referitor la seria i numrul
facturii, trebuie s precizm faptul c, numai luate mpreun, cele dou atribute vor putea
identifica unic fiecare factur
25
.
Totodat, dac analizm cu atenie cerina problemei, vom constata c mai avem
nevoie de un atribut, astfel nct s putem evidenia coninutul fiecrei facturi. Practic, prin
coninutul fiecrei facturi nelegem c trebuie s punem n eviden produsele care se
gsesc pe fiecare factur primit de societile gestionate i cantitile aferente; cu alte
cuvinte, atributul de care vom avea nevoie se va referi la cantitatea aprovizionat dintr-un
produs pe o factur.
Astfel sintetiznd cele menionate anterior, la punctul a6 vom avea urmtoarele
atribute (pentru claritate, n dreptul fiecrui atribut vom meniona i semantica
corespunztoare):
cui codul unic de identificare al fiecrei societi;
den=s denumirea societii;
cod=prod codul fiecrui produs; se presupune c nu exist dou produse gestionate
care s aib acelai cod;
den=prod denumirea produsului gestionat;
um unitatea de msur specific fiecrui produs;
cant cantitatea (aferent unui produs) care se gsete n stoc la un moment dat;
serie seria unei facturi;
nr numrul facturii;
val valoarea unei facturi;
*5
Aceast regul este ntlnit n literatur sub numele de regula entitii i menioneaz faptul c toate
atributele care formeaz cheia primar trebuie s primeasc valori.
51
data data emiterii facturii;
cant=aprov cantitatea aferent unui produs aprovizionat prin intermediul unei facturi.
Referitor la acest atribut, menionm faptul c vom avea o realizare a acestuia numai atunci
cnd este emis o factur pe care se gsete un produs gestionat. Altfel spus, ca s
dispunem de o realizare a acestui atribut va trebui s existe att factura ct i produsul.
b) Dup identificarea atributelor, va trebui s definim relaiile din cadrul crora ele vor
face parte. Astfel, vom avea urmtoarele relaii (pentru fiecare relaie, vom descrie i trei
tupluri care s ne ajute la identificarea corect a cheilor primare ale relaiilor):
Societate 4 cui den=s )
R111111 Rione SRL
R222222 Selena SRL
R333333 Select SRL
Produs 4 cod=pro
d
den=prod um cant )
11 Telefon Nokia B 2
22 Telefon Samsung B 3
33 Laptop Dell B 0
Factur 4 seri
e
nr val data )
DX 111
1
200
0
10.11.2008
DX 222
2
850
0
10.11.2008
JW 111
1
650
0
11.11.2008
c) La acest pas va trebui s soluionm dou cerine. Prima se refer la punerea n eviden
a emitentului fiecrei facturi. Pentru aceasta, vom asocia relaiile $ocietate i Factur. Aa
cum am menionat n subcapitolul n care am descris legturile dintre relaii, pentru a
identifica tipul legturii va trebui s vedem rolul fiecrei relaii n cadrul modelului: fiu sau
printe. Analiznd cele dou relaii, observm c $ocietate este relaie printe deoarece
fiecare societate poate primi una sau mai multe facturi, n timp ce Factur este relaie fiu
deoarece o factur nu poate fi emis dect unei singure societi (reamintim c o relaie este
considerat fiu atunci cnd unui tuplu din acea relaie i va corespunde un singur tuplu n
relaia cu care s-a asociat i este printe atunci cnd i vor corespunde mai multe tupluri).
Astfel, legtura este de tipul !-n (unu la mai muli), ceea ce nseamn c atributele
care formeaz cheia primar n relaia printe vor migra sub forma cheii strine n relaia fiu:
atributul cui din relaia $ocietate va migra sub forma cheii strine n relaia Factur.
A doua cerin este cea prin care ni se cere s punem n eviden coninutul fiecrei
facturi. n acest caz, vom asocia relaiile Factur i (rodus. Aa cum am procedat anterior, i
n acest caz va trebui s identificm iniial tipul relaiilor pentru a determina tipul legturii.
Astfel, legtura este de tipul n-n (mai muli la mai muli) deoarece ambele relaii sunt printe:
fiecare factur poate conine unul sau mai multe produse, n timp ce un produs poate fi
5*
aprovizionat prin intermediul uneia sau a mai multor facturi. Conform regulii menionate,
legtura se va realiza prin generarea unei noi relaii care va avea cheia primar format din
cheile primare ale celor dou relaii asociate. De asemenea, aceast nou relaie va include
i atributul cant=aprov care ne va permite s punem n eviden cantitatea aprovizionat
dintr-un produs pe o factur.
Dup crearea acestor legturi, modelul relaional va artat astfel:
Societate 4 cui den=s )
R111111 Rione SRL
R222222 Selena SRL
R333333 Select SRL
Produs 4 cod=pro
d
den=prod um cant )
11 Telefon Nokia B 2
22 Telefon Samsung B 3
33 Laptop Dell B 0
Factur 4 seri
e
nr val data cui )
DX 111
1
200
0
10.11.2008 R222222
DX 222
2
850
0
10.11.2008 R333333
JW 111
1
650
0
11.11.2008 R222222
Coninut_factur 4 seri
e
nr cod_pro
d
cant=aprov )
DX 111
1
11 10
DX 111
1
33 15
JW 111
1
11 20
Astfel, prin intermediul atributului cheie strin cui din relaia Factur putem s punem
n eviden care este emitentul fiecrei facturi (ce societate a emis o factur). Spre exemplu,
dac dorim s aflm cine a emis factura DX 2222, vom identifica n cadrul relaiei Factur
care este tuplul care are ca realizare a atributelor serie i nr valorile DX (pentru serie),
respectiv 2222 (pentru nr). Apoi, dup identificarea tuplului, vom prelua valoarea cheii strine
(n cazul nostru, R333333) i vom cuta aceast valoare pe domeniul de valori aferent
atributului care este cheie primar n relaia din care a migrat. Pentru exemplul nostru, vom
merge n relaia $ocietate i pe domeniul cheii primare vom cuta acel tuplu pentru care
valoarea atributului cui este R333333. n acest fel vom constata c factura DX 2222 este
emis de $elect $,/.
Coninutul fiecrei facturi este evideniat prin intermediul relaiei *oninut=factur. n
acest fel constatm c produsul 3elefon 5oFia este achiziionat prin intermediul a dou
53
facturi (DX 1111 i JW 1111), iar cantitatea aprovizionat este de 10, respectiv 20 uniti.
Totodat, prin intermediul acestei noi relaii am pus n eviden faptul c o factur poate
conine mai multe produse (factura cu seria i numrul DX 1111 conine produsele cu
codurile 11 i 33), dar i faptul c un produs se poate gsi pe mai multe facturi (produsul cu
codul 11 se gsete att pe factura cu seria i numrul DX 1111 ct i pe JW 1111), ceea ce
argumenteaz legtura de tipul mai muli la mai muli.
De asemenea, n cadrul relaiei Factur se argumenteaz i regula entitii. Astfel,
putem observa c n cazul n care unul din cele dou atribute care formeaz cheia primar
nu are valoare, atunci exist posibilitatea ca pe domeniul de valori respectiv s avem valori
duplicate, ceea ce nseamn c nu mai poate ndeplini rolul de cheie primar a relaiei. Spre
exemplu, dac vom da valori numai atributului serie, atunci vom ajunge n situaia n care
avem dou valori duplicate pe domeniul respectiv de valori, ceea ce nu ar fi permis. Deci,
trebuie s nu omitem s dm valori tuturor atributelor care formeaz cheia primar a unei
relaii.
(1 Fie descrierea studenilor unei faculti care studiaz diferite discipline 3n
funcie de specializarea fiecruia1 S se pun 3n eviden specializarea de care
aparine fiecare student8 precum "i disciplinele studiate de ace"tia1
a) Pentru problema menionat anterior, va trebui s identificm atribute despre student,
specializare i disciplin. Dei poate am fi tentai s credem c am avea nevoie i de atribute
despre facultate, nu este aa, deoarece, n cazul n care am avea relaia facultate, aceasta ar
avea un singur tuplu i nu se justific generarea unei relaii care s aib o singur realizare.
Astfel, pentru problema dat, am putea identifica urmtoarele atribute:
nr=matr numrul matricol al studentului;
nume numele studentului;
pren prenumele unui student;
cod=spec codul unei specializri care aparine unei faculti; vom presupune c nu
exist dou faculti care s aib acelai cod;
den=spec denumirea specializrii;
cod=disc codul disciplinei; ca i n cazul codului specializrii, i aici vom presupune
c dou discipline diferite au coduri diferite, indiferent de forma disciplinei (curs, seminar,
laborator sau proiect);
den=disc denumirea disciplinei studiate;
tip=disc tipul unei discipline;
semestru semestrul n care este studiat o disciplin; n funcie de specializare, o
disciplin poate fi studiat n semestre diferite de studenii acesteia.
b) Relaiile pe care le identificm sunt urmtoarele:
Student 4 nr=mat
r
nume pren )
111 Popa Alin
222 Marin Daniel
54
a
333 Mihnea oana
Specializare 4 cod=spe
c
den=spec )
76 Contabilitate i nformatic de
Gestiune
75 Finane Bnci
70 nformatic Economic
Disciplin 4 cod=dis
c
den=disc tip=disc )
D11 Baze de date Curs
D12 Baze de date Laborator
D21 Contabilitate financiar Seminar
c) Pentru a evidenia specializarea de care aparine fiecare student, vom asocia
relaiile $tudent i $pecializare. Relaia $tudent este o relaie fiu deoarece un student cu o
anumit matricol nu poate fi nmatriculat la mai multe specializri, n timp ce relaia
$pecializare este una printe ntruct, n mod evident, fiecare specializare va avea mai muli
studeni. Astfel, legtura dintre cele dou relaii este de tipul unu-la-mai-muli, ceea ce
nseamn c va migra cheia primar din relaia $pecializare sub forma cheii strine n relaia
$tudent. Astfel, prin intermediul atributului cod=spec din relaia $tudent putem s aflm la ce
specializare este nmatriculat fiecare student.
Dac dorim s determinm disciplinele studiate de fiecare student, vom asocia relaiile
$tudent i 'isciplin. Cele dou relaii sunt printe deoarece un student studiaz una sau
mai multe discipline, iar fiecare disciplin este studiat de nici un student (pot exista
discipline opionale care nu se aleg din pachetul de opionale) sau de mai muli studeni,
ceea ce nseamn c vom avea o legtur mai-muli-la-mai-muli. Aa cum tim deja, n
aceast situaie se va genera o nou relaie. Astfel, dup crearea legturilor, modelul
relaional este urmtorul:
Student 4 nr=matr nume pren cod=spec )
111 Popa Alin 76
222 Marin Daniela 75
333 Mihnea oana 76

c h e i a s t r a i n a
Specializare 4 cod=spe
c
den=spec )
76 Contabilitate i nformatic de
Gestiune
75 Finane Bnci
70 nformatic Economic
Disciplin 4 cod=dis
c
den=disc tip=disc )
55
D11 Baze de date Curs
D12 Baze de date Laborator
D21 Contabilitate financiar Seminar
Studiu 4 nr=mat
r
cod=dis
c
semestru )
111 D11 3
111 D12 3
333 D21 2
Astfel, relaia $tudiu este cea care ne permite s identificm disciplinele studiate de
fiecare student, dar i perioada n care acestea sunt parcurse, astfel:
prin intermediul atributului nr=matr identificm studentul;
cu ajutorul atributului cod=disc vedem disciplina studiat de un student;
atributul semestru ne arat perioada n care un student studiaz o anumit disciplin.
5,
#ibliografie
;ibliogra%ie
1. [Bsc, 1997] Bsc, O., &aze de date, Editura All, Bucureti, 1997.
*. [Connoly et al., 2002] Connoly, T., Begg, C., Strachan, A., 'atabase $7stems G
practical pproach to 'esign, 0mplementation and Management, Second Edition, Addison
Wesley Limited, 2002.
3. [Date, 1994] Date, J., n introduction to 'atabase $7stems, ed. Addison Wesley, 1994.
4. [Date, 2004] Date, J., n introduction to database s7stems, ediia a V-a, Pearson
Addison Wesley, 2004.
5. [Diaz, 2000] Diaz, O., dvanced database technolog7 and design, ed. Piattini, 2000.
,. [Fotache, 2005] Fotache, M., (roiectarea bazelor de date" 5ormalizare )i
postnormalizare" 0mplementri $./ )i -racle, Editura Polirom, ai, 2005.
-. [Garsia-Molina et al., 2002] Garcia-Molina, H., Ullman, H., Widom, J., 'atabase $7stems"
3he complete &ooF, Prentice Hall, Upper Saddle Riner, 2002.
8. [Georgescu, Georgescu, 2005] Georgescu, C., Georgescu, M., &aze de date relaionale
)i multidimensionale, Editura Didactic i Pedagogic R.A., Bucureti, 2005.
9. [Lungu, Bodea, 1995] Lungu, ., Bodea, C., &aze de date G organizare, proiectare )i
implementare, Editura All, Bucureti, 1995.
1. [Popa et al., 1994] Popa, Ghe., Stanciu, A., vancenco, V., Mare, V., $%&', Editura All,
Bucureti, 1994.
11. [Popescu, 2001] Popescu, ., Modelarea bazelor de date, Editura Tehnic, Bucureti,
2001.
1*. [Trandafir et al., 2007] Trandafir, R., Nistorescu, M., Mierlu-Mazilu, ., &aze de date
relaionale, Bucureti, 2007.
13. [Velicanu et al., 2000] Velicanu, M., Bodea, C., Lungu, ., oni, ., Bdescu, G., $isteme
de gestiune a bazelor de date, Editura Petrion, Bucureti, 2000.
14. [Velicanu et al., 2003] Velicanu, M., Lungu, ., Muntean, M., onescu, S., $isteme de baze
de date G teorie )i practic, Editura Petrion, Bucureti, 2003.
15. http://vega.unitbv.ro/~cataron/Courses/BD/BD_Cap_2.pdf .
5-

Baze de Date ... Lupasc A.

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Baze de Date ... Lupasc A.

Încărcat de

Drepturi de autor:

Formate disponibile

BAZE DE DATE

4 serie=fact nr=fact val=fac

S-ar putea să vă placă și