Baze Date Economie Lupasc

Universitatea Dunrea de Jos Galai
Baze de date aplicate n economie

Lect. dr. Lupac Adrian
Departamentul pentru nvmnt la Distan i cu Frecven Redus Galai - 2008
CUPRINS
Capitolul I Fundamente ale bazelor de date............................................................3
Ce este baza de date? .........................................................................................................4 Arhitecturi ale sistemelor de baze de date .......................................................................6
Capitolul II Proiectarea i administrarea unei baze de date.................................13

Ciclul de via al sistemelor informaionale...................................................................14 Ciclul de via al unui sistem de baze de date................................................................14 Proiectarea bazelor de date .............................................................................................17
Proiectarea conceptual ...............................................................................................................17 Proiectarea logic ........................................................................................................................17 Proiectarea fizic .........................................................................................................................19
Proiectarea tranzaciilor..................................................................................................19
Capitolul III Sisteme de gestiune a bazelor de date ..............................................24

Evoluia sistemelor de gestiune a bazelor de date .........................................................24 Faciliti oferite de un SGBD ..........................................................................................27 Avantajele i dezavantajele SGBD-urilor ......................................................................29 Componentele unui SGBD...............................................................................................35 Funciile SGBD-ului .........................................................................................................36
Capitolul IV Abordarea relaional a bazelor de date ..........................................43

Regulile lui Codd ..............................................................................................................43 Fundamente ale modelului relaional .............................................................................45 Legturi ntre relaii.........................................................................................................50
Legtura binar 1-1 (unu la unu) .................................................................................................51 Legtura binar 1-n (unu la mai muli)........................................................................................52 Legtura binar n-n (mai muli la mai muli) ..............................................................................53 Legtura dintre trei sau mai multe relaii.....................................................................................55
Algebra relaional operatorii relaionali ...................................................................56 Probleme rezolvate ...........................................................................................................63
Bibliografie ................................................................................................................73
Fundamente ale bazelor de date
Capitolul I Fundamente ale bazelor de date
**************************************************************************************** Obiectivele capitolului Capitolul I 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. Informaii 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.
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.
Fundamente ale bazelor de date 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 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. 4 Baze de date aplicate n economie
Fundamente ale 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 corespunztoare. n bazele de date are loc o integrare a datelor, n sensul c mai multe fiiere sunt privite n ansamblu, eliminnduse 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. 5 Baze de date aplicate n economie
Fundamente ale bazelor de date 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. Atributul 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 1.1.
Date
Software
Elemente auxiliare
Figura 1.1. Arhitectura pe componente a unui sistem de baze de date
Aa cum se observ, componentele specifice arhitecturii din figura 1.1 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. 2. Arhitectura 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 1.2).

Vederi ale bazei de date
Manipulare date
Descriere date
Niveluri de organizare date
Programator de aplicatie
Program aplicatie 1
...
Structura externa (logica)
...
Logic
Administrator baza de date
SGBD S.O.
Structura conceptuala
...
Conceptual
Inginer (analist) de sistem
Baz de date
Structura interna (fizica)
Fizic
Figura 1.2. Arhitectura pe niveluri a unui sistem de baze de date
n arhitectura prezentat n figura 1.2 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 SGBD2; 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 su global i unitar, se recomand ca schema conceptual s fie gestionat de o singur persoan [Georgescu, Georgescu, 2005, p.67].
SGBD Sistem de Gestiune a Bazelor de Date
Fundamente ale bazelor de date 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 SGBD; 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 SGBD.
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 SGBD-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. Baze de date aplicate n economie 9
Fundamente ale bazelor de date ntrebri recapitulative 1. Ce reprezint o baz de date? 2. Menionai factorii care au permis domeniului bazelor de date s devin o component cheie a sistemelor informaionale moderne. 3. Identificai principalele motive care determin trecerea de la o organizare a datelor sub forma foilor de calcul Excel la cea sub forma bazei de date. 4. Definii conceptul de entitate. 5. Definii conceptul de atribut. 6. Care sunt componentele specifice arhitecturii pe componente? 7. Prezentai rolul nivelului conceptual aferent arhitecturii pe niveluri. 8. Prezentai rolul nivelului logic aferent arhitecturii pe niveluri. 9. Prezentai rolul nivelului fizic aferent arhitecturii pe niveluri. 10. Cror viziuni corespund cele trei niveluri ale arhitecturii pe niveluri? Teste gril 1. Printre factorii care au contribuit la adoptarea n mas a sistemelor de baze de date se numr: a. necesitatea unei administrri mai eficiente a unei cantiti mai mari de informaii; b. creterea semnificativ hardware i software; a preurilor aferente componentelor
c. apariia tehnicilor bazate pe gandirea orientat-obiect; d. dezvoltarea prelucrrilor bazate pe tehnologia client-server. 2. Referitor la o baz de date relaional, putem afirma c va conine: a. colecii organizate de date ntre care pot exista diferite legturi; b. colecii organizate de date ntre care pot exista legturi, iar dac exist, ele sunt legturi logice; c. colecii organizate de date fr legturi logice; d. colecii organizate de date ntre care exist legturi logice. 3. Componenta software specific arhitecturii pe componente a unui sistem de baze de date poate conine: a. dicionarul de date; b. sistemul de gestiune al bazei de date; c. datele; d. fiierele anex.
10
Fundamente ale bazelor de date 4. Elementele auxiliare specifice arhitecturii pe componente se refer la: a. realizarea i funcionarea ntregului sistem de baze de date; b. programe de aplicaii dezvoltate ntr-un sistem de gestiune a bazelor de date; c. realizarea i exploatarea bazei de date; d. structura datelor, restriciile de integritate i vederile unei baze de date. 5. Nivelul conceptual specific arhitecturii pe niveluri se refer la: a. viziunea administratorului bazei de date asupra datelor; b. viziunea programatorului asupra datelor; c. viziunea utilizatorului asupra modului de proiectare a bazei de date; d. viziunea administratorului, al programatorului i al utilizatorului asupra modului de proiectare a bazei de date. 6. n cadrul arhitecturii pe niveluri, la nivel logic: a. programatorul realizeaz programele de aplicaie descrierea i manipularea datelor, scrise ntr-un SGBD; pentru
b. viziunea programatorului este independent de suportul tehnic de informaie; c. viziunea administratorului asupra bazei de date este independent de aplicaiile care vor fi dezvoltate; d. implementarea schemei interne se face cu ajutorul sistemului de gestiune a fiierelor din cadrul SGBD-ului i/sau din sistemul de operare, prin gestiunea fizic a perifericelor. 7. Independena logic se refer la faptul c: a. viziunea programatorului asupra bazei de date este independent de aplicaiile care vor fi dezvoltate; b. viziunea administratorului asupra bazei de date este independent de aplicaiile care vor fi dezvoltate; c. viziunea utilizatorului final asupra bazei de date este independent de aplicaiile care vor fi dezvoltate; d. viziunea programatorului i al administratorului asupra bazei de date este independent de aplicaiile care vor fi dezvoltate. 8. Independena fizic se refer la faptul c: a. viziunea administratorului bazei de date este independent de suportul tehnic de informaie; b. viziunea programatorului i al administratorului bazei de date este independent de suportul tehnic de informaie; c. viziunea programatorului este independent de suportul tehnic de informaie; d. independena fizic se realizeaz indiferent de programatorului, utilizatorului sau a administratorului. Baze de date aplicate n economie viziunea
11
Fundamente ale bazelor de date 9. Nivelul fizic aferent arhitecturii pe niveluri se refer la: a. viziunea analistului de sistem asupra datelor i descrie modul n care ele sunt stocate n baza de date; b. viziunea inginerului de sistem asupra datelor, dar nu descrie modul n care sunt stocate datele n baza de date; c. viziunea inginerului de sistem asupra datelor i descrie modul n care sunt stocate datele n baza de date; d. viziunea administratorului bazei de date asupra datelor. 10. Independena logic este specific: a. nivelului logic; b. nivelului conceptual; c. nivelului fizic; d. independena logic este specific nivelului conceptual sau nivelului logic, n funcie de modul de proiectare al bazei de date.
12
Proiectarea i administrarea unei baze de date
Capitolul II Proiectarea i administrarea unei baze de date
**************************************************************************************** Obiectivele capitolului Proiectarea i administrarea sistemelor de baze de date reprezint o sarcin dificil i important n cadrul ciclului de via al unui sistem informatic care are drept scop gestionarea i utilizarea unui anume volum de date stocate prin intermediul acestora. n acest context, capitolul II Proiectarea i administrarea unei baze de date 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 Baze de date aplicate n economie 13
Proiectarea i administrarea unei baze de date soluionarea problemelor menionate anterior, a fost propus o nou abordare structurat privind dezvoltarea produselor software, numit ciclu de via al sistemelor informaionale.
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 2.1. 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.
14
Proiectarea i administrarea unei baze de date
Planificarea bazei de date
Delimitarea granitelor sistemului
Colectarea si analiza cerintelor
Proiectarea bazei de date Proiectarea conceptuala Alegerea SGBD-ului Proiectarea logica Proiectarea aplicatiei
Proiectarea fizica
Prototipizarea
Implementarea
Testarea
ntretinere operationala
Figura 2.1. Ciclul de via al unei aplicaii de tip baz de date
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 15 Baze de date aplicate n economie
Proiectarea i administrarea unei baze de date unui sistem este o etap important, nu numai pentru utilizatorii i aplicaiile curente, ci i pentru cele din viitor; 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: 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 SGBD-ului este o etap opional i presupune alegerea unui SGBD 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. Implementarea bazei de date se realizeaz prin utilizarea limbajului de definire a datelor (LDD), corespunztor sistemului de gestiune a bazelor de date ales. Instruciunile 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.
16
Proiectarea i administrarea unei baze de date 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 (E-R3, relaional, OO4, OR5), dar independent de tipul SGBD-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: 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 Select 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 SGBD 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
E-R Entitate Relaie OO Orientat Obiect 5 OR Obiectual Relaional 6 Select este o instruciune specific limbajului SQL Structured Query Language care permite extragerea datelor din baza de date.
4 3
17
Proiectarea i administrarea unei baze 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 IV). 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 SGBD int. Cu alte cuvinte, tim c SGBD-ul este, de exemplu, relaional, ierarhic sau orientat spre obiecte. ns, se ignor alte aspecte ale SGBD-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; 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 I normal); 2. Fiecare atribut trebuie s depind n totalitate de cheia primar a relaiei pe care o descrie (forma II 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 III 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 18 Baze de date aplicate n economie
Proiectarea i administrarea unei baze de date 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 fizic 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 SGBD-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 SGBD. 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.
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. Baze de date aplicate n economie 19
Proiectarea i administrarea unei baze de date 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 SGBD-ului, o tranzacie transfer baza de date dintr-o stare n alta. SGBD-ul asigur coerena bazei de date, chiar n cazul unei defeciuni. Totodat, SGBD-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, SGBD-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, SGBD-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.
20
Proiectarea i administrarea unei baze de date ntrebri recapitulative 1. Ce reprezint sistemul informaional? 2. Identificai i prezentai pe scurt principalele scopuri ale proiectrii unei baze de date. 3. Ce reprezint ntreinerea operaional? 4. Care sunt principalele tipuri de proiecri n viziunea cercettorului Connoly i a colaboratorilor si? 5. Proiectarea conceptual. 6. Proiectarea logic. 7. Proiectarea fizic. 8. Proiectarea tranzaciilor. 9. Ce reprezint tranzacia? 10. Ce reprezint tranziia? Teste gril 1. Rolul sistemului informaional este de a asigura legtura dintre: a. sistemul decizional i cel operaional; b. sistemul operaional i cel informatic; c. sistemul de conducere i cel de execuie; d. toate sistemele organizaiei. 2. Etapele ciclului de via al unui sistem de baze de date: a. nu pot fi mereu secveniale; b. sunt mereu secveniale; c. depinde de maniera de proiectare a sistemului informatic: n funcie de aceasta, etapele ciclului de via se pot derula secvenial sau nu; d. se poate reveni la o etap anterioar numai dup parcurgerea tuturor etapelor. 3. Proiectarea bazei de date se refer i la: a. alegerea SGBD-ului; b. prototipizare; c. testare; d. ntreinere operaional.
21
Proiectarea i administrarea unei baze de date 4. ntreinerea operaional se refer la: a. monitorizarea i testarea continu a aplicaiei; b. monitorizarea continu a aplicaiei i ncorporarea unor noi cerine, atunci cnd este cazul; c. monitorizarea continu a aplicaiei i ncorporarea permanent a unor noi cerine; d. monitorizarea continu a aplicaiei, fr ns a se mai putea aduga funcionaliti suplimentare aferente noilor cerine. 5. Prototipizarea este: a. o etap obligatorie specific proiectrii bazei de date care permite numai proiectantului s evalueze modul de funcionare a aplicaiei; b. o etap opional specific proiectrii bazei de date care permite numai proiectantului s evalueze modul de funcionare a aplicaiei; c. o etap obligatorie specific proiectrii bazei de date care permite proiectantului i utilizatorului s evalueze modul de funcionare a aplicaiei; d. o etap opional specific proiectrii bazei de date care permite proiectantului i utilizatorului s evalueze modul de funcionare a aplicaiei. 6. Proiectarea bazei de date se refer i la: a. oferirea unui model de date care s permit realizarea tranzaciilor; b. oferirea unui model de date care s permit realizarea tuturor tranziiilor necesare; c. oferirea unui model de date care s permit realizarea tranzaciilor i a tranziiilor asupra datelor; d. proiectarea bazei de date nu se refer la oferirea unui model de date. 7. Proiectarea conceptual se refer la: a. construirea unui model informaional dependent de fiecare considerent privitor la aspectul fizic al datelor; b. construirea unui model informaional independent de fiecare considerent privitor la aspectul fizic al datelor; c. construirea unui model informaional independent bazat pe unul din modelele tradiionale; d. implementarea efectiv a bazei de date.
22
Proiectarea i administrarea unei baze de date 8. Proiectarea incorect a bazei de date poate conduce la urmtoarele deficiene: a. lipsa performanelor dorite; b. neredundana datelor; c. afectarea integritii datelor; d. imposibilitatea proiecrii corecte a restriciilor de integritate asupra datelor. 9. Realizarea unui model de date logic este specific: a. proiectrii conceptuale; b. proiectrii fizice; c. proiectrii logice; d. proiectrii tranzaciilor. 10. Tranzacia se refer la: a. aciuni care numai acceseaz baza de date; b. aciuni care numai actualizeaz baza de date; c. aciuni care acceseaz sau actualizeaz baza de date; d. trecerea de la o realizare la alta a bazei de date.
23
Sisteme de gestiune a bazelor de date
Capitolul III Sisteme de gestiune a bazelor de date
**************************************************************************************** Obiectivele capitolului 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 (SGBD) 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] SGBD-ul este definit ca un ansamblu complex de programe care asigur interfaa ntre o baz de date i utilizatorii acesteia. Totodat, autorii consider SGBD-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 SGBD 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. SGBD-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 SGBD-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 SGBD-ul i are rdcinile n proiectul de aselenizare Apollo din 24 Baze de date aplicate n economie
Sisteme de gestiune a bazelor de date 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. Ca rezultat, compania North American Aviation (NAA - acum Rockwell International), primul contractant al proiectului, a dezvoltat un software cunoscut sub denumirea de GUAM (Generalized Update Access Methodh metoda general de acces prin reactualizare). Sistemul GUAM 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 IBM i NAA au transformat sistemul GUAM n ceea ce este cunoscut sub denumirea de IMS7 (sistem de gestionare a informaiilor). Motivul pentru care cei de la IBM au restrns sistemul IMS 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 SGBD, IMS 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 IDS8 (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 SGBD 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 (CODASYL9) 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 (DBTG10) 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.
7 8
Acronim pentru Information Management System Acronim pentru Integrated Data Store 9 COnference on DAta SYstems Language 10 Data Base Task Group
25
Sisteme de gestiune a bazelor de date 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.
Cu toate c, formal, raportul nu a fost adoptat de ctre Institutul Naional American pentru Standarde (ANSI11), ulterior s-a realizat un numr de sisteme conform propunerii DBTG. Acestea sunt cunoscute acum sub denumirea de sisteme CODASYL sau DBTG. Abordrile de tip CODASYL i ierarhice au reprezentat prima generaie de SGBD-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 IBM 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 SGBD relaionale experimentale, primele produse comerciale aprnd la sfritul anilor 1970 i nceputul anilor 1980. De remarcat este proiectul System R, de la Laboratorul de Cercetare IBM din San Jose, 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 SQL, care de atunci a devenit limbajul standard pentru sistemele SGBD relaionale; producerea de diverse sisteme SGBD relaionale la scar comercial, n decursul anilor 1980; de exemplu, sistemele DB2 i SQL/DS de la IBM i Oracle de la compania cu acelai nume .
n prezent, exist cteva sute de sisteme SGBD relaionale, att pentru medii mainframe, ct i pentru microcalculatoare, cu toate c multe dintre ele extind definiia modelului relaional. Alte exemple de sisteme SGBD relaionale multiutilizator sunt: CS-OpenIngres de la compania Computer Associates i Informix de la Informix Software Inc. Cteva exemple de sisteme SGBD relaionale pentru microcalculatoare sunt: Access i FoxPro ale companiei Microsoft, Paradox i Visual dBase ale companiei Borland i R:Base al companiei Microrim. Sistemele SGBD relaionale sunt denumite sisteme SGBD din a doua generaie. Cu toate acestea, modelul relaional a cunoscut i eecuri - n particular, datorit capacitilor sale de modelare limitate. De-a lungul
11
Acronim pentru American National Standards Institute
26
Sisteme de gestiune a bazelor de date timpului, s-au efectuat multe cercetri care au ncercat s rezolve aceast problem. n 1976, Chen a prezentat modelul Entitate-Relaie, 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 SGBD orientate spre obiecte (OODBMS12) i sistemele SGBD de obiecte relaionale (ORDBMS13). Totui, spre deosebire de modelele anterioare, compoziia acestora nu este clar, iar aceast evoluie reprezint a treia generaie de sisteme SGBD. n prezent, datorit facilitilor pe care le ofer, constatm c cea mai mare partea bazelor de date sunt realizate cu ajutorul unor SGBD-uri relaionale i tot mai puine se bazeaz pe cele de generaia I. Totodat, trebuie remarcat i evideniat interesul tot mai mare fa de utilizarea n practic a SGBD-urilor orientate obiect.
Faciliti oferite de un SGBD 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 SGBD const n elemente software care interacioneaz cu programele aplicaie ale utilizatorului i cu baza de date. Printre principalele faciliti care sunt oferite de un SGBD 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; 2. 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.
12 13
Acronim pentru Object-Oriented DataBase Management System Acronim pentru Object-Relational DataBase Management System
27
Sisteme de gestiune a bazelor de date 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 LMD, 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 SGBD 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, SGBD-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 SGBD 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 SGBD prezint o alt facilitate, cunoscut sub denumirea de mecanism de vizualizare, care permite fiecrui utilizator si 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 28 Baze de date aplicate n economie
Sisteme de gestiune a bazelor de date 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 SGBD difer de la produs la produs. De exemplu, s-ar putea ca un SGBD pentru un calculator personal s nu accepte accesul partajat concurent, ns ar prezenta doar un control limitat al securitii, integritii i refacerii. Totui, produsele SGBD 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 SGBD 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 SGBD-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, SGBD-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.
Avantajele i dezavantajele SGBD-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. Avantajele SGBD-urilor 1.Controlul redundanei 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. 2.Coerena 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 Baze de date aplicate n economie 29
Sisteme de gestiune a bazelor de date aceasta, el poate garanta c toate copiile articolului respectiv sunt meninute coerente. Din pcate, multe dintre sistemele SGBD actuale nu garanteaz automat acest tip de coeren. 3.Mai multe informaii de la aceeai cantitate de date Odat cu integrarea datelor operaionale, ar putea fi posibil ca organizaia respectiv s extrag informaii suplimentare din aceleai date. 4.Partajarea 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 SGBD (cum ar fi definirea i manipularea datelor i controlul concurenei i refacerii) n loc de a fi necesar s le furnizeze ele nsele. 5.Integritatea crescut a datelor Integritatea bazei de date se refer la validitatea i 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. 6.Securitate 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 fIlial ar putea accesa doar datele legate de filiala respectiv, n timp ce un utilizator de la compartimentul Vnzri ar putea avea acces numai la datele referitoare la proprieti, dar nu 30 Baze de date aplicate n economie
Sisteme de gestiune a bazelor de date i la datele sensibile, cum ar fi detaliile despre salariile angajailor sau contractele ncheiate. 7.Aplicarea standardelor Din nou, integrarea permite administratorului bazei de date s defineasc i s aplice toate standardele necesare. Acestea ar putea include standarde departamentale, 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. 8.Economia 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. 9.Echilibrul ntre cerinele aflate n conflict 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. 10.mbuntirea accesibilitii datelor i capacitii de rspuns 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 utilizatorului final sau clienilor organizaiei. Multe SGBD-uri ofer limbaje de interogare sau generatoare de rapoarte, care permit utilizatorilor s formuleze ntrebri adhoc 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 SQL la un terminal:
31
Sisteme de gestiune a bazelor de date SELECT* FROM proprietate_de_inchiriat WHERE type = 'Apartament' AND chirie> 400; 11.Productivitate crescut Aa cum am menionat anterior, un SGBD 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, SGBD-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 SGBD 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). 12.ntreinere mbuntit datorit independenei 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, ntrun SGBD, 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. 13.Concuren mbuntit 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 SGBD, 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. 14.mbuntirea serviciilor de salvare de siguran i refacere 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 programului aplicaie. 32 Baze de date aplicate n economie
Sisteme de gestiune a bazelor de date 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, SGBD-urile moderne ofer faciliti de minimizare a pierderilor (aferente prelucrrilor realizate) ca urmare a unei defeciuni. Dezavantaje SGBD-urilor Pe lng avantajele menionate anterior, fiecare SGBD comport i un numr de dezavantaje, iar cele mai importante sunt menionate n continuare. 1.Complexitatea Proiectarea funcionalitii unui SGBD 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. 2.Costul Costul unui SGBD variaz semnificativ, n funcie de mediu i de funcionalitatea pe care o ofer. De exemplu, un SGBD cu un singur utilizator, pentru un calculator personal, poate costa numai 100 euro. Cu toate acestea, un SGBD mainframe, multi-utilizator, care 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 SGBD pentru gestionarea unei activiti numai n concordan cu necesitile curente: nu are sens s achiziionm un SGBD scump dac nevoia nu o cere, ns nu recomandm nici achiziionarea unui SGBD 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 distribuite14). 3.Costurile adiionale specifice componentelor hardware Cerinele de stocare pe suport fizic pentru un SGBD 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 SGBD-ului. Astfel,
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.
33
Sisteme de gestiune a bazelor de date este clar c achiziionarea de componente hardware adiionale conduce la creterea cheltuielilor. 4.Costul conversiei n unele cazuri, costul unui SGBD i al componentelor hardware adiionale poate fi nesemnificativ, comparativ cu costul conversiei aplicaiilor existente, necesare ca acestea s poat funciona n noul SGBD 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. 5.Dimensiunea Complexitatea i extinderea funcionalitii fac din SGBD-uri elemente software destul de cuprinztoare, ce ocup mult spaiu pe suportul fizic i necesit o memorie15 substanial pentru a funciona eficient i corect. 6.Performana 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, SGBD-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. 7.Impactul crescut al unei defeciuni Centralizarea resurselor mrete vulnerabilitatea sistemului. Din moment ce toi utilizatorii i toate aplicaiile se bazeaz pe disponibilitate din partea SGBD-ului, eecul oricrei componente a acestuia poate duce la sistarea tuturor operaiilor.
15
Evident, ne referim la memoria RAM (Random Access Memory) a calculatorului pe care se gsete i ruleaz SGBD-ul respectiv.
34
Sisteme de gestiune a bazelor de date Componentele unui SGBD Principalele componente ale unui SGBD sunt [Georgescu, Georgescu, 2005, p.75-81]: motorul SGBD 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 SGBD 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 SGBD 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; 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 utilizatorului. asisten on-line pentru autodocumentarea
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
Un limbaj de descrierea a datelor permite descrierea componenei bazei de date, a structurii acesteia , a relaiilor dintre componentele ei, precum i a tuturor drepturilor de acces ale utilizatorilor la baza de date.
16
35
Sisteme de gestiune a bazelor de date formatelor de descriere a datelor din dicionarul de date i conectarea acestor descrieri din schema intern a bazei de date
Funciile SGBD-ului n [Velicanu et al., 2003, p.104-107] se arat c ndeplinirea tuturor obiectivelor unui SGBD 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 SGBD, 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, SGBD-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 SGBD; acestea sunt funcii importante, pe care un sistem software, dac nu le are n totalitate, nu poate fi considerat SGBD. Astfel, principalele funcii pe care le putem atribui unui SGBD sunt: descrierea datelor, manipularea datelor, utilizarea i administrarea bazei de date. Descrierea datelor Prin intermediul funciei de descriere a datelor, fiecare SGBD 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 SGBD, dar el mereu realizeaz descrierea lor conform elementelor modelului de date pe care l implementeaz SGBD-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 datelor17.
17
n literatur ntlnim frecvent i Limbaj de Manevrare a Datelor
36
Sisteme de gestiune a bazelor de date 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 SGBD 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 SGBD-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 SGBD-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 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. Funcia 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, SGBD-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. SGBD-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, SGBD-ul sprijinindu-i n manier interactiv n utilizarea bazei de date. n acest sens SGBD-ul ofer: Baze de date aplicate n economie 37
Sisteme de gestiune a bazelor de date meniuri cu opiuni sugestive; ferestre de lucru; abloane pentru diferite forme; asisteni tip Wizard; autodocumentarea (help-uri, mesaje/ferestre explicative).
Spre deosebire de utilizatorii neinformaticieni, cei specialiti n informatic sunt n msur s creeze structura bazei de date i s realizeze proceduri complexe de exploatare a acesteia. SGBD-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 SGBD 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. Administratorul 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, SGBD-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. Administratorul, 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 conceptual a acesteia i coordoneaz proiectarea ei. Pentru toate aceste aspecte, SGBD-ul ofer o serie de instrumente CASE18, 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.).
Instrumentele CASE (Computer Aided Software Engineering) sunt aplicaii informatice, formate din mai multe componente, care ajut la realizarea unui proiect software, n anumite etape (sau n toate etapele) din ciclul de via al unei aplicaii. Obiectivul principal al instrumentelor CASE const n punerea n practic a produselorprogram de proiectare i realizarea softwarelui cu ajutorul calculatorului. Instrumentele oferite de CASE sunt utilizabile din faza de definire a cerinelor pn la ntreinerea fizic a produsului informatic [Oprea, 1999, p.123].
18
38
Sisteme de gestiune a bazelor de date Pentru fiecare din activitile menionate mai sus, SGBD-ul ofer instrumente i tehnici de lucru. n cazul lucrului n reea, cu baze de date distribuite, SGBD-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.
39
Sisteme de gestiune a bazelor de date ntrebri recapitulative 1. Ce este SGBD-ul? 2. Care este diferena dintre limbajele procedurle i cele neprocedurale? 3. Ce reprezint coerena datelor? 4. Ce reprezint partajarea datelor? 5. Cum se poate realiza securitatea datelor la nivelul unui SGBD? 6. La ce se refer costul conversiei? 7. Prezentai pe scurt componentele unui SGBD. 8. Ce este motorul SGBD? 9. Prezentai principale caracteristici ale subsistemului instrumentelor de proiectare. 10. Prezentai principale caracteristici ale subsistemului de execuie. Teste gril 1. SGBD-ul reprezint o interfa ntre: a. sistemul de operare i alt SGBD; b. dou sau mai multe SGBD-uri, dac ele se gsesc pe platforme diferite; c. utilizatori i sistemul de operare; d. dou sisteme de operare care ruleaz pe platforme diferite. 2. SGBD-urile relaionale sunt denumite SGBD-uri din: a. I-a generaie; b. a II-a generaie; c. a III-a generaie; d. a IV-a generaie. 3. Un SGBD permite: a. doar actualizarea datelor din baza de date; b. doar extragerea datelor prin intermediul limbajului de descriere a datelor; c. doar extragerea datelor manipulare a datelor; prin intermediul limbajului de
d. actualizarea datelor i extragerea lor prin intermediul limbajului de manipulare a datelor.
40
Sisteme de gestiune a bazelor de date 4. Principala deosebire ntre limbajele procedurale i cele neprocedurale const n faptul c: a. limbajele procedurale trateaz datele unei baze de date nregistrare cu nregistrare, n timp ce cele neprocedurale lucreaz cu seturi de nregistrri; b. limbajele neprocedurale trateaz datele unei baze de date nregistrare cu nregistrare, n timp ce cele procedurale lucreaz cu seturi de nregistrri; c. limbajele neprocedurale se bazeaz pe limbajele de descriere a datelor, n timp ce cele procedurale lucreaz cu limbajele de manipulare a datelor; d. limbajele procedurale se bazeaz pe limbajele de descriere a datelor, n timp ce cele neprocedurale lucreaz cu limbajele de manipulare a datelor; 5. Costul conversiei, ca dezavantaj al SGBD-ului, se refer la: a. conversia unui SGBD ntr-un sistem bazat pe fiiere; b. conversia componentelor hardware n unele mai performante; c. conversia aplicaiilor existente la un moment dat ntr-o organizaie; d. conversia unei componente hardware n una software. 6. Motorul SGBD este componenta care: a. permite proiectarea i generarea bazei de date i a aplicaiilor care descriu modul de utilizare a bazei de date; b. are rolul de a asigura accesul fizic la datele bazei de date; c. permite execuia aplicaiilor sau cererilor de consultare a bazei de date; d. permite definirea structurii tabelelor din baza de date. 7. Subsistemul instrumentelor de proiectare nu poate include: a. limbaje de descriere a datelor; b. limbaje de manevrare a datelor; c. limbaje de programare; d. limbaje de interogare a datelor. 8. Subsistemul instrumentelor de proiectare nu permite definirea: a. structurii tabelelor din baza de date; b. machetelor de interfa cu utilizatorul; c. accesului fizic la datele bazei de date; d. formatului rapoartelor i cererilor de interogare a bazei de date.
41
Sisteme de gestiune a bazelor de date 9. n etapa de exploatare a bazei de date, administratorul: a. poate autoriza accesul la datele bazei de date; b. poate permite modificarea structurii logice a bazei de date; c. poate crea conturi de acces la baza de date; d. nu poate reface baza de date n cazul unor incidente. 10. Subsistemul de execuie al SGBD-ului este componenta care: a. permite proiectarea i generarea bazei de date i a aplicaiilor care descriu modul de utilizare a bazei de date; b. are rolul de a asigura accesul fizic la datele bazei de date; c. permite execuia aplicaiilor sau cererilor de consultare a bazei de date; d. permite definirea structurii tabelelor din baza de date.
42
Abordarea relaional a bazelor de date
Capitolul IV Abordarea relaional a bazelor de date
**************************************************************************************** Obiectivele capitolului Principalul obiectiv al capitolului IV 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 relaional; i prezentarea fundamentelor specifice modelului
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.
Regulile 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 Codd. Modelul de stocare a datelor sub forma unei baze de date relaionale s-a dezvoltat pornind de la un articol aprut n anul 1970, A relational Model of Data for Large Shared Data Banks, i care aparine cercettorului Codd [Codd, 1970, p.377-387]. Astfel, regulile enunate de cercettor sunt prezentate n continuare:
43
Abordarea relaional a bazelor de date R0 Gestionarea datelor la nivel de relaie. Toate informaiile din baza de date sunt gestionate numai prin mecanisme relaionale. Rezult c SGBD-ul trebuie s-i ndeplineac toate funciile utiliznd ca unitate de informaie mulimea, cu alte cuvinte, s utilizeze diferite limbaje, aa cum este i SQL, care s opereze la un moment dat pe o relaie. R1 Reprezentarea logic a datelor. Informaiile 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. Informaiile referitoare la numele tabelelor, al coloanelor, domeniilor, definiiilor tabelelor virtuale, al restriciilor de integritate trebuie s fie memorate tot n tabelele de date. R2 Garantarea 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. R3 Regula aferent valorii NULL Un SGBD trebuie s permit declararea i utilizarea valorii NULL, cu semnificaia unor date lips sau care nu pot fi aplicate. Valorile NULL (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. R4 Regula specific metadatelor Informaiile referitoare la descrierea bazei de date metadatele trebuie specificate la nivel logic n manier identic cu descrierea datelor propriuzise. 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. R5 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. R6 Actualizarea bazei de date Fiecare SGBD 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.
44
Abordarea relaional a bazelor de date R7 Independena 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. R8 Independena logic a datelor Programele de aplicaie nu trebuie s fie afectate de modificrile efectuate asupra relaiilor care formeaz baza de date. R9 Regula aferent restriciilor de integritate Toate restriciile de integritate trebuie s poat fi definite prin intermediul limbajului folosit de SGBD pentru definirea datelor i s fie memorate. R10 Distribuirea geografic a datelor n cazul n care datele sunt distribuite, programele de 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. R11 Actualizarea tabelelor virtuale n cadrul abordrii relaionale, nu toate atributele sunt actualizabile, ceea ce nseamn c nu toate tabelele virtuale pot fi actualizate. R12 Prelucrarea datelor la nivel de baz Dac SGBD-ul posed un limbaj de baz de nivel 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; 2. 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: Baze de date aplicate n economie 45
Abordarea relaional a bazelor de date 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 4.1: Exemplul 4.1. Student (cnp, nr_matr, nume, pren, facult, spec) Astfel, n exemplul anterior am definit relaia Student care include atributele: 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 4.1 am definit relaia Student cu schema dat de atributele cnp, nr_matr, nume, pren, facult, spec. n exemplul 4.2 sunt prezentate trei tupluri pentru relaia Student defint n exemplul 4.1. Exemplul 4.2 Student ( cnp nr_matr nume pren facult spec ) 1701212120139 1234 Popa Dan FSE IE 2731210176143 1987 Darie Alina FD AP 1801009129145 4432 Mihnea Ion 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. 46 Baze de date aplicate n economie
Abordarea relaional a bazelor de date Cheia 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. 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 4.1. Aa cum aminteam anterior, iniial trebuie s identificm cheile candidat ale relaiei Student. 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 Student (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 4.3 am redat alte tupluri pentru relaia Student i n care se poate observa c avem valori duplicate pe domeniile analizate. Exemplul 4.3 Student ( cnp 1701212120139 2731210176143 1801009129145 nr_matr 1234 1987 4432 nume Popa Darie Popa pren Dan Dan Ion facult FSE FD FSE spec ) IE AP IE
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 Baze de date aplicate n economie 47
Abordarea relaional a bazelor de date nr_matr chei candidat? am primi un singur rspuns: DA. Aa s fie oare? Nu este aa. Iar argumentul este dat de exemplul 4.4. Exemplul 4.4 Student ( cnp 1701212120139 2731210176143 2731210176143 nr_matr 1234 1987 5634 nume Popa Darie Darie pren Dan Dan Dan facult FSE FD FSE spec ) IE AP 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 Student 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. Exemplul 4.5 Student ( Cnp 1701212120139 ? nr_matr 1234 1234 nume Popa ? pren Dan ? facult FSE ? spec ) IE ?
Astfel, considerm c avem un tuplu care reprezint un student cu numrul matricol 1234, care este la facultatea FSE, specializarea IE. 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 4.6). Deci, atributul nr_matr este cheie candidat a relaiei Student. Exemplul 4.6 Student ( cnp 1701212120139 1701212120139 nr_matr 1234 1234 nume Popa Popa pren Dan Dan facult FSE FSE spec ) IE IE
48
Abordarea relaional a bazelor de date 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: cnp+facult+spec. De ce toate trei? Dac ne-am gndi la atributele cnp+facult 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 cnp+spec 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 facultate19. Sintetiznd, pentru relaia Student am identificat dou chei candidat: nr_matr; cnp+facult+spec.
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, cnp+facult+spec; cheie primar: nr_matr; cheie alternant: cnp+facult+spec. Astfel, n final, relaia noastr ar arta astfel: Exemplul 4.7. Student (cnp, nr_matr, nume, pren, facult, spec) 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 4.8 vom descompune relaia n alte trei relaii:
Mecanismul de identificare corect i complet a cheilor unei relaii se va realiza numai dup parcurgerea i nelegerea procesului de normalizare a unei baze de date relaionale (la pagina 18 au fost prezentate succint cteva aspecte de baz specifice normalizrii). Pentru cei interesai s tie mai multe despre procesul de normalizare i postnormalizare, recomandm cartea profesorului M. Fotache: Proiectarea bazelor de date: Normalizare i postnormalizare. Implementri SQL i Oracle.
19
49
Abordarea relaional a bazelor de date Exemplul 4.8 Student (cnp, nr_matr, nume, pren) Facultate (facult, profil) Specializare (spec, form_nv) 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 Specializare numai luate mpreun deoarece o anumit specializare poate apare la diferite forme de nvmnt (spre exemplu, specializarea Contabilitate i Informatic de Gestiune are studeni i la forma de nvmnt Zi, i la Ifr). Astfel, prin descompunerea relaiei iniiale n cele trei relaii din exemplul 4.8 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: Student conine doar date de strudeni; Facultate include ca realizri (tupluri) doar facultile gestionate; Specializare care se refer la specializrile fiecrei faculti gestionate.
Legturi ntre relaii Dac analizm cu atenie relaiile din exemplul 4.8 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 4.7, unde numele unei faculti ar fi aprut de fiecare dat cnd mai gestionam un student al aceleai facultai (realizarea FSE, 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 4.7 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 Student), date despre faculti (relaia Facultate), respectiv date despre specializri (relaia Specializare), fr ns s putem spune la ce facultate sau specializare este un anume student. n acest context, pentru a putea oferi aceste informaii, trebuie s asociem relaiile modelului din exemplul 4.8. Astfel, abordarea relaional propune patru tipuri de legturi ntre relaii.
50
Abordarea relaional a bazelor de date Legtura binar 1-1 (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. Obs. 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 NULL (n literatura de specialitate, aceast constrngere este numit restricie referenial). Exemplul 4.9: Fie urmtoarele dou relaii: Client ( cnp
1701212120139 2711010120121 1721209145123
nume
Popa Darie Preda
pren localitate )
Dan Alina Marin Galai Brila Galai
Legitimaie
( nr_leg
12121 23456 187654
valabilitate )
2 2 3
Prin intermediul relaiilor Client i Legitimaie 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 4.9, Popa Dan nu poate avea dect o singur legitimaie, ceea ce nseamn c unui tuplu din relaia Client nu-i poate corespunde dect un singur tuplu n relaia Legitimaie. 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 Client (unde este cheie primar) n relaia Legitimaie, unde va ndeplini rolul de cheie strin. n acelai mod, atributul nr_leg va migra din relaia Legitimaie n relaia Client, iar modelul va arta ca n exemplul 4.10. Baze de date aplicate n economie 51
Abordarea relaional a bazelor de date Exemplul 4.10: Client ( cnp

1701212120139 2711010120121 1721209145123
nume
Popa Darie Preda
pren
Dan Alina Marin
localitate nr_leg )
Galai Brila Galai 23456 12121 187654
Legitimaie
( nr_leg
12121 23456 187654
valabilitate
2 2 3
cnp )
2711010120121 1701212120139 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.
Legtura binar 1-n (unu la mai muli) 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 Student i Specializare din exemplul 4.8. Exemplul 4.11: Student ( nr_matr
1111 2222 3333
cnp
1701212120139 2711010120121 1721209145123
nume
Popa Darie Preda
pren )
Dan Alina Marin
Specializare ( cod_spec
61 51 52
spec
CIG FB FB
form_nv )
ZI ZI IFR
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: Unui tuplu din relaia X cte tupluri n relaia Y i pot corespunde, unde X i Y sunt cele dou relaii pe care le asociem. a. Identificarea tipului pentru relaia Student: ntrebarea la care trebuie s rspundem este: Un student la cte specializri poate fi?. 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 52 Baze de date aplicate n economie
Abordarea relaional a bazelor de date poate fi la 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 Student c este relaie fiu. b. Identificarea tipului pentru relaia Specializare n acest caz, rspunsul la ntrebarea: La o specializare ci studeni pot fi nmatriculai? este mai muli, ceea ce nseamn c unui tuplu din relaia Specializare i corespund mai multe tupluri din relaia Student. n acest caz, Specializare este relaie printe. Plecnd de la analiza fcut anterior, am stabilit c relaia Student este fiu n timp ce relaia Specializare este printe: legtura dintre cele dou se va realiza prin migrarea cheii primare din relaia printe (cod_spec din Specializare) sub form de cheie strin n relaia Student, iar modelul va arta ca n exemplul 4.12. Exemplul 4.12: Student ( nr_matr
1111 2222 3333
cnp
1701212120139 2711010120121 1721209145123
nume
Popa Darie Preda
pren cod_spec )
Dan Alina Marin 61 52 61
Specializare ( cod_spec
61 51 52
spec
CIG FB FB
form_nv )
ZI ZI IFR
n exemplul 4.12 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 Specializare i se va identifica acel tuplu care are ca valoare a atributului cod_spec, valoarea aferent cheii strine din relaia Student, adic 61. Dup parcurgerea secvenial a tuplurilor din Specializare vom vedea c studentul este la specializarea CIG, forma de nvmnt ZI.
Legtura binar n-n (mai muli la mai muli) 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 Produs din exemplul 4.13:
53
Abordarea relaional a bazelor de date Exemplul 4.13: Factur ( serie_fact

DX VR DF
nr_fact
1111 2222 3333
val_fact data_fact )
100 200 300 10.10.2008 10.10.2008 12.10.2008
Produs
( cod_produs
11 22 33
den_prod
Telefon Nokia TV Samsung Laptop Asus
um
Buc Buc Buc
stoc )
0 2 2
Considerm c relaia Factur permite gestionarea facturilor primite de un comerciant, n timp ce n relaia Produs sunt gestionate produsele comercializate. Odat ce am considerat atributul cod_produs ca fiind cheia primar a relaiei Produs 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). Iniial, 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 Produs 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. Exemplul 4.14: Aprovizionare ( serie_fact nr_fact cod_produs cant_aprov )
DX DX DF 1111 1111 3333 11 33 11 10 15 5
Aa cum se observ, legtura de tipul mai muli la mai muli a fost pus n eviden prin noua relaie generat: Aprovizionare. 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 Aprovizionare 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). 54 Baze de date aplicate n economie
Abordarea relaional a bazelor de date Legtura dintre trei sau mai multe relaii 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 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 4.8, vom asocia cele trei relaii cu scopul de a putea preciza cu claritate facultatea i specializarea la care este nmatriculat fiecare student. Exemplul 4.15 Student ( nr_matr
111 222 333
nume
Preda Darie Ionescu
pren )
Marin Alina Ctlin
Facultate
( facult
tiine Economice Drept
profil )
Economic Administrativ
Specializare
( cod_spec
751 752 662
Spec
FB FB AP
form_nv
ZI IFR IFR
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 4.16. Exemplul 4.16 Studiu ( nr_matr
111 222 333
facult
tiine Economice Drept tiine Economice
cod_spec )
751 662 751
Cu ajutorul acestei noi relaii, putem spune despre Preda Marin c este student la facultatea de tiine Economice, la specializarea FB, forma de nvmnt IFR. 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 Baze de date aplicate n economie 55
Abordarea relaional a bazelor de date interogare specifice SGBD-ului utilizat, s acceseze i s utilizeze n acelai timp toate datele gestionate n baza de date.
Algebra relaional 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. Reuniunea. Reuniunea a dou relaii A i B20, notat A B , 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. Exemplul 4.17 Stud1 ( nr_matr 111 222 333 nume Preda Darie Ionescu pren ) Marin Alina Ctlin
pren ) Stud2 ( nr_matr nume 444 Manea Oana 333 Ionescu Ctlin 555 Dragomir Alina
Stud1 Stud2 =
pren ) ( nr_matr Nume 111 Preda Marin 222 Darie Alina 333 Ionescu Ctlin 444 Manea Oana 555 Dragomir Alina
20
Relaiile A i B trebuie s aib aceeai schem definit pe aceleai domenii.
56
Abordarea relaional a bazelor de date 2. Diferena. Diferena a dou relaii A i B21, notat A \ B , 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 Stud1 i Stud2 din exemplul 4.17, rezultatul este urmtorul:
Stud1 \ Stud2 =
( nr_matr nume pren ) 111 Preda Marin 222 Darie Alina
3. Produsul cartezian. Fie relaiile A (cu aritatea a) i B (cu aritatea b)22. Produsul cartezian al celor dou relaii, notat A B este o relaie care are aritatea a+b i care va conine toate tuplurile rezultate prin concatenarea unui tuplu din A cu fiecare tuplu din B. 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). Exemplul 4.18 Student ( nr_matr 111 222 333 nume Preda Darie Ionescu pren ) Marin Alina Ctlin
tip_disc ) Disciplin ( cod_disc denumire SE1 Baze de date curs SE2 Baze de date laborator SE3 Contabilitate Seminar 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 Student Disciplin va avea ase atribute), aa cum se observ mai jos:
Student Disciplin
( nr_matr 111 111 111 222 222 222 333 333 333
nume Preda Preda Preda Darie Darie Darie Ionescu Ionescu Ionescu
pren Marin Marin Marin Alina Alina Alina Ctlin Ctlin Ctlin
cod_disc SE1 SE2 SE3 SE1 SE2 SE3 SE1 SE2 SE3
denumire Informatic Informatic Contabilitate Informatic Informatic Contabilitate Informatic Informatic Contabilitate
tip_disc ) curs laborator seminar curs laborator seminar curs laborator seminar
21 22
Relaiile A i B trebuie s aib aceeai schem definit pe aceleai domenii. Schemele relaiilor A i B sunt diferite, dar pot exista atribute comune.
57
Abordarea relaional a bazelor de date 4. Proiecia. Proiecia se aplic unei singure relaii A de aritate a, se noteaz cu i se realizeaz dup un numr de atribute, a1, a2, , an, care trebuie s fie incluse n schema relaiei A. 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. Exemplul 4.19 Fie relaia Student: Student ( nr_matr cnp nume pren ) 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:
nr_matr, nume, pren (Student) =
( nr_matr nume pren )

1111 2222 3333 Popa Dan Darie Alina Preda Marin
5. Selecia. Selecia se definete pentru o singur relaie A 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. Exemplul 4.20 Fie relaia Student:
Student ( nr_matr 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:
media >=8 ( Student ) =
( nr_matr nume
2222 3333
pren
media )
8.00 9.00
Darie Alina Preda Marin
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 58 Baze de date aplicate n economie
Abordarea relaional a bazelor de date unor rspunsuri mai rapide. Dintre operaiile derivate utilizate mai frecvent amintim: 6. Intersecia. Intersecia a dou relaii A i B23, notat A B , este o relaie care va avea schema identic cu a relaiilor intersectate, iar ca realizri doar tuplurile comune celor dou relaii. Exemplul 4.21
Stud1 ( nr_matr 111 222 333
nume Preda Darie Ionescu
pren ) Marin Alina Ctlin
pren ) Stud2 ( nr_matr nume 444 Manea Oana 333 Ionescu Ctlin 555 Dragomir Alina
Stud1 Stud2 =
pren ) ( nr_matr nume 333 Ionescu Ctlin
7. Uniunea. Uniunea se definete pentru dou relaii A i B (de aritate a, respectiv b), o condiie logic ntre dou valori ale unor atribute ce aparin celor dou relaii24 i se noteaz A | X | B . Rezultatul uniunii va fi o relaie de
c
aritate a+b, cu schema dat de reuniunea atributelor celor dou relaii i care va conine toate tuplurile aferente produsului cartezian dintre A i B 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-stnga, iar dac se face dup atributele relaiei din dreapta (a doua relaie) se va numi semi-uniunedreapta. n continuare vom exemplifica uniunea i echiuniunea.
23 24
Relaiile A i B trebuie s aib aceeai schem definit pe aceleai domenii. n cazul uniunii, cele dou atribute trebuie s fie cte unul din fiecare relaie.
59
Abordarea relaional a bazelor de date Exemplul 4.22 Fie urmtoarele relaii:
Aprov
( s_fact DX DX JZ
nr_fact 1122 1122 2233
cod_prod cant_a ) P1 20 P2 10 P3 15
Comand ( cod_cmd cand_c ) C1 20 C2 12 C3 10

n cadrul relaiei Aprov se presupune c avem situaia aprovizionrilor, n relaia Comand 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.
Aprov X Comand= ( s_fact nr_fact cod_prod cant_a cod_cmd 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 <= cant_c.
Aprov
cant _ a <= cant _ c
| X | Comand= ( s_fact nr_fact cod_prod cant_a cod_cmd cant_c )

DX DX DX DX JZ 1122 1122 1122 1122 2233 P1 P2 P2 P2 P3 20 10 10 10 15 C1 C1 C2 C3 C1 20 20 12 10 20
60
Abordarea relaional a bazelor de date 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 4.23: Exemplul 4.23: Echiuniunea relaiilor Aprov i Comand.
Aprov | X | Comand=
cant _ a = cant _ c
( s_fact DX DX
nr_fact 1122 1122
cod_prod P1 P2
cant_a 20 10
cod_cmd C1 C3
cant_c ) 20 10
8. Uniunea natural. Uniunea natural a relaiilor A i B, 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). Exemplul 4.23: Fie urmtoarele relaii:
Student
( nr_matr 111 222 333
nume Popa Darie Moga
pren ) Dan Alin Dana
Disc
( den_disc nr_matr not ) Finane 333 9 Birotic 222 10 Birotic 333 8
a. Se realizeaz produsul cartezian al celor dou relaii:

Student X Disc = ( s.nr_matr nume
111 111 111 222 222 222 333 333 333
Popa Popa Popa Darie Darie Darie Moga Moga Moga
pren den_disc d.nr_matr not ) Dan Finane 333 9 Dan Birotic 222 10 Dan Birotic 333 8 Alin Finane 333 9 Alin Birotic 222 10 Alin Birotic 333 8 Dana Finane 333 9 Dana Birotic 222 10 Dana Birotic 333 8
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 Student.nr_matr = Disc.nr_matr. c. Dup identificarea condiiei, ea se va aplica asupra produsului cartezian realizat la punctul a:
Baze de date aplicate n economie 61
Student .nr _ matr = Disc.nr _ matr ( Student X Disc) =

( s.nr_matr 222 333 333 nume Darie Moga Moga pren Alin Dana Dana den_disc Birotic Finane Birotic d.nr_matr 222 333 333 not ) 10 9 8
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 |= (nr_matr nume
222 333 333 Darie Moga Moga pren Alin Dana Dana den_disc Birotic Finane Birotic not ) 10 9 8
9. Uniunea extern. 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 NULL pentru toate atributele ce nu apar n relaia din care provin. Uniunea extern se noteaz astfel: A | | B, unde A i B sunt cele dou relaii. Plecnd de la relaiile Student i Disc din exemplul 4.23 i de la uniunea natural Student | X | Disc, vom avea urmtoarea uniune extern: Exemplul 4.24 Student | | Disc = (nr_matr 111 222 333 333
nume pren den_disc not ) Popa Dan NULL NULL Darie Alin Birotic 10 Moga Dana Finane 9 Moga Dana Birotic 8
Aa cum se observ, n relaia Student exist un singur tuplu care nu are corespondent n relaia Disc: n acest caz, tuplul va fi adugat n relaia aferent uniunii externe, iar valorile aferente atributelor din relaia Disc pentru care nu exist corespondent vor primi valoarea NULL. n ceea ce privete relaia Disc, nu exist nici un tuplu care s nu aib corespondent n relaia Student (altfel spus, valorile 222 i 333, ca realizri ale atributului nr_matr n relaia Disc, se regsesc n relaia Student pe domeniul de valori al atributului nr_matr). De asemenea, exist dou operaii derivate din uniunea extern i anume uniune extern stnga (left outer join) 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 NULL (exemplul 2.25). n mod similar se realizeaz uniunea extern stnga, numai c n acest caz 62 Baze de date aplicate n economie

vor fi adugate uniunii naturale doar tuplurile relaiei din dreapta (exemplul 2.26). Exemplul 4.25 Student | Disc = (nr_matr 111 222 333 333 Exemplul 4.26 Student | Disc = (nr_matr 222 333 333
nume pren den_disc not ) Popa Dan NULL NULL Darie Alin Birotic 10 Moga Dana Finane 9 Moga Dana Birotic 8
nume pren den_disc not ) Darie Alin Birotic 10 Moga Dana Finane 9 Moga Dana Birotic 8
n exemplul 4.26, uniunea extern dreapta este identic cu uniunea natural deoarece nu exist tupluri n relaia din dreapta (relaia Disc n cazul nostru) care s nu aib corespondent n cealalt relaie.
Probleme rezolvate 1. Mai multe societi comercializeaz pe baz de factur diferite produse. Folosind abordarea relaionl, s se pun n eviden emitentul i coninutul fiecrei facturi. Pentru a soluiona problema propus anterior, va trebui s parcurgem urmtoarele etape: a) identificarea atributelor care reies din contextul problemei; b) definirea relaiilor pe baza atributelor identificate la punctul a); c) crearea legturilor dintre relaiile identificate la punctul b). a) Pentru a avea garania unei rezolvri corecte a unei probleme, va trebui ca nainte de a identifica atributele s rspundem la urmtoarea ntrebare: Pentru problema dat, avem nevoie de atribute pentru cine, sau pentru ce? 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 b). 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
63

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 b). 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 printro 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 factur25. 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 a) 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; 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.
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.
25
64

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
den_s ) ( cui R111111 Rione SRL R222222 Selena SRL R333333 Select SRL
Produs ( cod_prod um cant ) den_prod 11 Telefon Nokia B 2 22 Telefon Samsung B 3 33 Laptop Dell B 0
data ) Factur ( serie val nr DX 1111 2000 10.11.2008 DX 2222 8500 10.11.2008 JW 1111 6500 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 Societate 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 Societate 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 1-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 Societate 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 Produs. 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 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.
65

Dup crearea acestor legturi, modelul relaional va artat astfel: Societate
den_s ) ( cui R111111 Rione SRL R222222 Selena SRL R333333 Select SRL
Produs ( cod_prod um cant ) den_prod 11 Telefon Nokia B 2 22 Telefon Samsung B 3 33 Laptop Dell B 0 Factur ( serie val cui ) nr data DX 1111 2000 10.11.2008 R222222 DX 2222 8500 10.11.2008 R333333 JW 1111 6500 11.11.2008 R222222 cod_prod cant_aprov ) Coninut_factur ( serie nr DX 1111 11 10 DX 1111 33 15 JW 1111 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 Societate 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 Select SRL. Coninutul fiecrei facturi este evideniat prin intermediul relaiei Coninut_factur. n acest fel constatm c produsul Telefon Nokia este achiziionat prin intermediul a dou 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 66 Baze de date aplicate n economie

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. 2. Fie descrierea studenilor unei faculti care studiaz diferite discipline n funcie de specializarea fiecruia. S se pun n eviden specializarea de care aparine fiecare student, precum i disciplinele studiate de acetia. 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 ( nr_matr nume pren ) 111 Popa Alin 222 Marin Daniela 333 Mihnea Ioana Specializare ( cod_spec den_spec ) 76 Contabilitate i Informatic de Gestiune 75 Finane Bnci 70 Informatic Economic Baze de date aplicate n economie
67

Disciplin ( cod_disc tip_disc ) den_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 Student i Specializare. Relaia Student este o relaie fiu deoarece un student cu o anumit matricol nu poate fi nmatriculat la mai multe specializri, n timp ce relaia Specializare 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 Specializare sub forma cheii strine n relaia Student. Astfel, prin intermediul atributului cod_spec din relaia Student putem s aflm la ce specializare este nmatriculat fiecare student. Dac dorim s determinm disciplinele studiate de fiecare student, vom asocia relaiile Student i Disciplin. 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:
cheia straina
pren cod_spec ) Student ( nr_matr nume 111 Popa Alin 76 222 Marin Daniela 75 333 Mihnea Ioana 76
Specializare ( cod_spec 76 75 70
den_spec ) Contabilitate i Informatic de Gestiune Finane Bnci Informatic Economic
tip_disc ) Disciplin ( cod_disc den_disc D11 Baze de date Curs D12 Baze de date Laborator D21 Contabilitate financiar Seminar
Studiu ( nr_matr cod_disc semestru ) 111 D11 3 111 D12 3 333 D21 2
68

Astfel, relaia Studiu 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.
69

ntrebri recapitulative 1. La ce se refer regula reprezentrii logice a datelor? 2. Ce reprezint baza de date relaional? 3. Ce reprezint cheia primar? 4. Ce reprezint cheia strin? 5. Ce este relaia fiu? Dar cea printe? 6. Ce reprezint legtura logic? 7. La ce se refer legtura de tipul unu-la-unu? 8. La ce se refer legtura de tipul unu-la-mai-muli? 9. La ce se refer legtura de tipul mai-muli-la-mai-muli? 10. Cum se realizeaz legtura dintre trei sau mai multe relaii? Teste gril 1. Cte chei poate avea o relaie? a. una primar, una strin si una alternant; b. mai multe candidat, una primar i cel puin una strin; c. una sau mai multe candidat, una primar i nici una, una, sau mai multe alternante; d. una sau mai multe candidat, una primar, nici una, una, sau mai multe alternante i cel puin una strin. 2. O baz de date relaional se refer la: a. colecii organizate de date; b. colecii corelate din punct de vedere logic; c. colecii organizate i corelate din punct de vedere logic; d. colecii organizate i corelate fizic pe suportul de stocare. 3. Regula lui Codd specific reprezentrii fizice a datelor se refer la faptul c: a. programele de aplicaie pot fi afectate de modificrile realizate asupra relaiilor bazei de date; b. programele de aplicaie nu pot fi afectate de modificrile realizate asupra relaiilor bazei de date; c. programele de aplicaie pot fi afectate de modificrile realizate n modul de reprezentare a datelor sau n metodele de acces; d. programele de aplicaie nu pot fi afectate de modificrile realizate n modul de reprezentare a datelor sau n metodele de acces.
70

4. Cheia candidat reprezint: a. un singur atribut care poate fi cheie primar sau cheie alternant; b. un atribut (grup de atribute) care poate deveni fie cheie primar, fie cheie alternant; c. un atribut (grup de atribute) care poate deveni fie cheie primar, fie cheie strin; d. un atribut (grup de atribute) care poate deveni fie cheie alternant, fie cheie strin; 5. Cheia primar reprezint un atribut sau un grup de atribute care: a. identific unic fiecare tuplu al unei relaii; b. identific unic fiecare tuplu, n funcie de relaia n care migreaz; c. identific n mod unic toate celelalte atribute ale relaiei din care face parte; d. nu poate migra niciodat din relaia din care face parte. 6. Un tuplu se obine prin atribuirea de valori: a. atributelor cheie; b. atributelor unei relaii; c. cheii strine; d. pentru acele atributute care au valoarea NULL. 7. O relaie este printe dac: a. unui tuplu din acea relaie nu-i corespunde nici un tuplu n relaia cu care s-a asociat; b. unui tuplu din relaia respectiv i corespunde un singur tuplu n relaia cu care s-a asociat; c. unui tuplu din relaia respectiv i corespund mai multe tupluri n relaia cu care s-a asociat; d. se asociaz cu nc dou relaii. 8. Fiecare relaie: a. are o singur cheie primar; b. are mai multe chei primare; c. are o singur cheie primar, ns atunci cnd este nevoie, se poate identifica cel mult nc una; d. nu conteaz cte chei primare are o relaie.
71

9. Legtura de tipul unu-la-mai-muli se realizeaz atunci cnd: a. unui tuplu din fiecare relaie i corespunde cel mult un tuplu din cealalt relaie; b. unui tuplu din prima relaie i corespund mai multe tupluri n cea de-a doua relaie, n timp ce unui tuplu din a doua relaie i corespunde un singur tuplu din prima; c. unui tuplu din fiecare relaie i corespund mai multe tupluri din cealalt relaie; d. se asociaz cel puin trei relaii. 10. Operaia proiecie din algebra relaional: a. se aplic unei singure relaii i se realizeaz dup diferite atribute ale relaiei; b. se aplic unei singure relaii i se realizeaz dup diferite tupluri ale relaiei; c. presupune existena a dou relaii cu aritate diferit i pe baza unei condiii logice; d. presupune existena a dou relaii cu scheme diferite, dar care pot avea i atribute comune.
72
Bibliografie
Bibliografie
1. [Bsc, 1997] Bsc, O., Baze de date, Editura All, Bucureti, 1997. 2. [Connoly et al., 2002] Connoly, T., Begg, C., Strachan, A., Database Systems A practical Approach to Design, Implementation and Management, Second Edition, Addison Wesley Limited, 2002. 3. [Date, 1994] Date, J., An introduction to Database Systems, ed. Addison Wesley, 1994. 4. [Date, 2004] Date, J., An introduction to database systems, ediia a VIII-a, Pearson Addison Wesley, 2004. 5. [Diaz, 2000] Diaz, O., Advanced database technology and design, ed. Piattini, 2000. 6. [Fotache, 2005] Fotache, M., Proiectarea bazelor de date. Normalizare i postnormalizare. Implementri SQL i Oracle, Editura Polirom, Iai, 2005. 7. [Garsia-Molina et al., 2002] Garcia-Molina, H., Ullman, H., Widom, J., Database Systems. The complete Book, Prentice Hall, Upper Saddle Riner, 2002. 8. [Georgescu, Georgescu, 2005] Georgescu, C., Georgescu, M., Baze de date relaionale i multidimensionale, Editura Didactic i Pedagogic R.A., Bucureti, 2005. 9. [Gerald, 1999] Gerald, P., Database Management Systems, ed. Mc Graw Hill, 1999. 10. [Harrington, 2002] Harrington, J.L., Relational Database Design Clearly Explained, ediia a II-a, Morgan Kaufman, Amsterdam, 2002. 11. [Hoffer et al., 2002] Hoffer, J.A., Prescott, M.B., McFadden, F.R., Modern Database Management, Prentice-Hall, 2002. 12. [Lungu, Bodea, 1995] Lungu, I., Bodea, C., Baze de date organizare, proiectare i implementare, Editura All, Bucureti, 1995. 13. [Popa et al., 1994] Popa, Ghe., Stanciu, A., Ivancenco, V., Mare, V., SGBD, Editura All, Bucureti, 1994. 14. [Popescu, 2001] Popescu, I., Modelarea bazelor de date, Editura Tehnic, Bucureti, 2001. 15. [Ramakrishnan, Gehrke, 2000] Ramakrishnan, R., Gehrke, J., Database Management Systems, ed. Mc Graw Hill, 2000. 16. [Riccardo, 2001] Riccardo, G., Principles of Database Systems with Internet and Java Application, ed. Addison Wesley, 2001. 17. [Riordan, 1999] Riordan, R., Designing Relational Database Systems, Microsoft Press, 1999. 18. [Silbershartz, Korth, 1997] Silbershartz, A., Korth, H., Database system concepts, ed. Addison Wesley, 1997. 19. [Simsion, 2001] Simsion, G., Data Modeling Essentials. Analysis, Design and Innovation, ediia a II-a, Addison Wesley, 2001.
73
Bibliografie 20. [Trandafir et al., 2007] Trandafir, R., Nistorescu, M., Mierlu-Mazilu, I., Baze de date relaionale, Bucureti, 2007.
21. [Velicanu et al., 2000] Velicanu, M., Bodea, C., Lungu, I., Ioni, I., Bdescu, G., Sisteme de gestiune a bazelor de date, Editura Petrion, Bucureti, 2000. 22. [Velicanu et al., 2003] Velicanu, M., Lungu, I., Muntean, M., Ionescu, S., Sisteme de baze de date teorie i practic, Editura Petrion, Bucureti, 2003. 23. http://vega.unitbv.ro/~cataron/Courses/BD/BD_Cap_2.pdf.
74

Baze Date Economie Lupasc

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Baze Date Economie Lupasc

Uploaded by

Copyright:

Available Formats

Universitatea Dunrea de Jos Galai

Baze de date aplicate n economie

Departamentul pentru nvmnt la Distan i cu Frecven Redus Galai - 2008

Capitolul II Proiectarea i administrarea unei baze de date.................................13

Capitolul III Sisteme de gestiune a bazelor de date ..............................................24

Capitolul IV Abordarea relaional a bazelor de date ..........................................43

Algebra relaional operatorii relaionali ...................................................................56 Probleme rezolvate ...........................................................................................................63

Fundamente ale bazelor de date

Capitolul I Fundamente ale bazelor de date

Baze de date aplicate n economie

Baze de date aplicate n economie

Fundamente ale bazelor de date

Figura 1.1. Arhitectura pe componente a unui sistem de baze de date

Baze de date aplicate n economie

Fundamente ale bazelor de date

Niveluri de organizare date

Structura externa (logica)

Administrator baza de date

Inginer (analist) de sistem

Structura interna (fizica)

Figura 1.2. Arhitectura pe niveluri a unui sistem de baze de date

SGBD Sistem de Gestiune a Bazelor de Date

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

Proiectarea i administrarea unei baze de date

Capitolul II Proiectarea i administrarea unei baze de date

Baze de date aplicate n economie

Proiectarea i administrarea unei baze de date

Planificarea bazei de date

Delimitarea granitelor sistemului

Colectarea si analiza cerintelor

Figura 2.1. Ciclul de via al unei aplicaii de tip baz de date

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

Sisteme de gestiune a bazelor de date

Capitolul III Sisteme de gestiune a bazelor de date

Baze de date aplicate n economie

Acronim pentru American National Standards Institute

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

n literatur ntlnim frecvent i Limbaj de Manevrare a Datelor

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

d. actualizarea datelor i extragerea lor prin intermediul limbajului de manipulare a datelor.

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

Abordarea relaional a bazelor de date

Capitolul IV Abordarea relaional a bazelor de date

definirea tipurilor de chei ntlnite la nivelul unei relaii;

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie

Baze de date aplicate n economie