Baze de Date

Gabriela Vrlan, Baze de date, Note de curs I
Anul II, semestrul
GABRIELA VRLAN Cristina Gabriela Zamfir Maria Cristina Enache
BAZE DE DATE - suport de curs -
Editura Universitar Danubius Galai 2009
Copyright 2009 Universitatea Danubius. Toate drepturile rezervate
Gabriela Vrlan, Baze de date, Note de curs
Anul II, semestrul I
Cuprins Capitolul 1 Fiiere i baze de date ...........................................................................................3 1.1. Fiiere concepte de baz ............................................................................................3 1.2. Tipuri de fiiere. Structuri i tipuri de index .................................................................6 1.3. Concepte specifice unei baze de date............................................................................8 1.4. Tipuri de relaii dintre tabelele unei baze de date ........................................................10 1.5. Sisteme de gestiune a bazelor de date .........................................................................12 1.6. Arhitectura ANSI-SPARC pe trei niveluri ..................................................................15 Capitolul 2 Proiectarea bazelor de date .................................................................................17 2.1. Modele de date...........................................................................................................18 Capitolul 3 Baze de date relaionale ......................................................................................23 3.1. Concepte de baz .......................................................................................................23 3.2. Integritatea relaional................................................................................................24 3.3. Regulile lui Codd .......................................................................................................25 3.4. Normalizarea .............................................................................................................26 3.4.1. Redundana datelor i anomaliile de actualizare a relaiilor..................................28 3.4.2. Dependenele funcionale ....................................................................................30 3.4.3. Prima form normal (FN1) ................................................................................32 3.4.4. A doua form normal (FN2) ..............................................................................32 3.4.5. A treia form normal (FN3) ...............................................................................33 3.4.6 Forma nrmal Boyce-Codd (FNBC ......................................................................35 Capitolul 4 Baze de date distribuite ......................................................................................36 4.1. Concepte specifice bazelor de date distribuite ............................................................37 4.2. Avantajele i dezavantajele sistemelor bazelor de date distribuite...............................40 4.3. Funciile unui sistem de gestiune a bazelor de baze distribuite ...................................42 4.4. Arhitectura unui SGBDD ...........................................................................................42 4.5. Proiectarea bazelor de date distribuite ........................................................................45 4.5.1. Reguli de proiectare a bazelor de date distribuite .................................................53 Capitolul 5. Realizarea aplicaiilor cu baze de date n Microsoft Access 2003 .......................58 5.1. Lucrul cu baze de date Access....................................................................................60 5.2. Crearea structurii tabelelor bazei de date ....................................................................64 5.2.1. Proprietatea DataType .........................................................................................65 5.2.2. Proprietile cmpului Field Properties ................................................................70 5.3. Crearea relaiilor ntre tabele ......................................................................................73 5.4. Definirea integritii refereniale ................................................................................76 5.5. Interogri ...................................................................................................................78 5.5.1. Interogri prin selecie .........................................................................................80 5.5.2. Interogri parametrice .........................................................................................89 5.5.3. Interogri ncruciate ...........................................................................................90 5.5.4. Interogri de aciune ............................................................................................91 Capitolul 6. Accesarea i prelucrarea datelor din baze de date externe ..................................96 6.1. Conversia unei liste Excel ntr-o baz de date Access.................................................96 6.2. Accesarea datelor externe n Excel ........................................................................... 100 Bibliografie ........................................................................................................................ 107
Capitolul 1 Fiiere i baze de date Una din caracteristicile sistemelor informatice economice este aceea ca elementul de baz este reprezentat de existena unei baze de date, care conine date specifice domeniului analizat, iar una din caracteristicile prelucrrii automate a datelor este c n acest domeniu se opereaz cu volume mari de date care sunt uniform structurate. Aceste date pot fi organizate n fiiere, baze de date i/sau fiiere i baze de date. Dup cum bine se tie, capacitatea de stocare primar a calculatorului, respectiv, memoria principal (intern), nu este adecvat pentru stocarea unor volume mari de informaii. Se cunoate c atunci cnd se lanseazs n execuie un program, sau se acceseaz anumite informaii stocate pe supori de memorie externi, acestea sunt ncrcate n memoria principal tocmai datorit faptului c timpii de acces sunt mult mai mici dect n cazul memoriei secundare (externe). Cu toate acestea exist i dezavantaje: capacitatea de stocare a memoriei principale este destul de mic, iar atunci cnd sistemul de calcul este nchis toat cantitatea de informaii existent n memoria principal este tears este o memorie volatil pe cnd informaiile stocate n memoria secundar persist i dup ntreruperea alimentrii este o memorie nevolatil. Pe parcursul evoluiei metodelor de stocare a datelor s-au ntlnit mai multe metode, fiecare avnd anumite caracteristice care pentru momentul respectiv al evoluie prezentau faciliti importante n acest domeniu, dar care comparativ cu evoluia actual sunt depite. Cu toate c sistemele bazate pe fiiere nu mai sunt de actualitate, se va aborda aceast organizare din mai multe motive [Connolly & alt, 2001]: Cunoscnd dificultile inerente sistemelor bazate pe fiiere, se va putea evita apariia acestora n sistemele bazate pe fiiere. Dac se dorete transformarea unui sisteme bazat pe fiiere ntr-un sistem bazat pe baze de date, cunoaterea modului de funcionare a sistemului bazat pe fiiere este extrem de util. 1.1. Fiiere concepte de baz Un fiier reprezint un ansamblu organizat de date relativ omogen din punct de vedere al naturii i al criteriilor de prelucrare, memorate pe suporturi de memorie externe (disc, band magnetic, dischet etc.) de unde pot fi utilizate n procesul de prelucrare. Un sistem bazat pe fiiere reprezint [Connolly & alt, 2001]: O colecie de programe de aplicaie, care efectueaz servicii pentru utilizatorii finali, cum ar fi rapoarte. Fiecare program definete i gestioneaz propriile date, i el a fost realizat ...ca rspuns la necesitile industriei privind accesul mai eficient la date. mbinnd cerinele generale privitoare la prelucrarea datelor cu proprietile fizice ale suportului utilizat, fiierul este o structur de organizare care prezint ntotdeauna un dublu aspect:
Unul logic funcional legat de organizarea datelor pe care le conine; elementul de baz al unui fiier, privit din acest aspect, este articolul. Astfel, un fiier reprezint o mulime organizat de articole. Unul fizic legat de organizarea suportului de memorie extern care conine fiierul elementul de baz din acest aspect este nregistrarea fizic, denumit i bloc sau pagin. Deci, din punct de vedere fizic, un fiier este o mulime organizat de nregistrri fizice.
Folosind noiunea de articol putem preciza c fiierul, din punct de vedere logic, este o mulime organizat de articole, iar fiecare articol este o mulime de cmpuri. De regul, articolul corespunde unei nregistrri logice, iar cmpul unui atribut. Fiecare cmp reprezint o valoare dat asociat unei proprieti. Dup natura lor cmpurile pot fi: alfabetice, numerice, alfanumerice, imagini, sunete etc. Caracteristicile de baz ale unei nregistrri logice sunt: lungimea, care poate fi fix sau variabil; formatul, care poate fi fix sau variabil. nregistrarea fizic reprezint unitatea de transfer ntre memoria secundar suporii de memorie externi de stocare i memoria principal, i invers, printr-o singur operaie de intrare/ieire (este de fapt cantitatea de informaie transferat). Ea depinde de suportul de memorie extern pe care este nregistrat fiierul i poate conine una sau mai multe nregistrri logice. Acum se poate da o alt definiie noiunii de fiier, respectiv: un fiier este un set de nregistrri, care conin date ntre care exist anumite relaii logice. Zona din memoria calculatorului n care sunt pregtite nregistrrile fizice ce urmeaz a fi transmise spre un periferic de stocare, sau n care se memoreaz nregistrrile fizice citite de pe un suport extern de memorie, este denumit zon tampon buffer. n cazul celor mai multe limbaje de programare utilizatorii nu au acces direct la nregistrrile fizice, ci numai la nregistrrile logice, n zone de memorie distincte, numite zone articol. Vor exista attea zone tampon, cte fiiere sunt deschise la un moment dat. Legat de limbajele de programare trebuie amintit marea dependen dintre program i datele stocate ntr-un sistem bazat pe fiiere, datorit faptului c structura fizic i stocarea fiierelor de date i nregistrrile sunt definite n codul surs al aplicaiei. Acesta lucru se traduce prin aceea c orice modificare n structura fiierului trebuia s fie fcut n toate codurile surs din aplicaia n care erau utilizate. De exemplu, fiierul cu numele TERTI.DBF este alctuit din mai multe articole, cu urmtoarea structur (atribute): cod unic, denumire, adresa, localitate, jude, telefon, fax, persoan contact, banca, cont bancar, tip. Fie O = {oi | i = 1, 2,n i n>1} unde oi reprezint elementele mulimii O, care sunt caracterizate printr-o mulime de atribute P = {p1, p2,, pm | m N*}. Dac, valoarea asociat atributului pk, pentru nregistrarea oi, atunci un fiier este o mulime F de forma: F = { (oi, pk, vik) | i = 1, 2, ...n, k = 1, 2,...m}, unde Vk = { vik | i = 1, 2, ...ni, ni < n} U {}, unde reprezint valoarea atribuit lui pk atunci cnd nu se cunoate pe moment valoarea acestuia pentru nregistrarea oi. Conform exemplului mai sus menionat, O reprezint mulimea terilor, iar P = {cod unic, denumire, adresa, localitate, judet, telefon, fax, persoana contact, banca, cont bancar, tip}.
Operaiile de baz care se pot efectua asupra fiierelor sunt: crearea prin care nregistrrile logice sunt transpuse pe suportul de memorie extern; actualizarea reprezint operaii de adugare, modificri i tergeri de nregistrri din cadrul fiierului; consultarea operaia prin care sunt regsite i afiate / listate anumite nregistrri. Ordinea n care sunt stocate (aranjarea fizic a datelor dintr-un fiier) i accesate nregistrrile dintr-un fiier depinde de organizarea fiierului. Prin organizarea fiierului se nelege punerea n coresponden a numrului de control a nregistrrilor din fiier cu adresele acestora n unitatea de memorie, n scopul regsirii nregistrrilor. n funcie de modul de organizare a fiierului se face i prelucrarea acestuia. Cele trei tipuri de baz de organizare a fiierelor sunt: Secvenial. Aceste tipuri de fiiere se mai numesc fiiere pile sau fiiere heap. Spunem c un fiier este de organizare secvenial n cazul n care articolele lui sunt nregistrate pe suportul de memorie unul dup altul, pe msura obinerii lor, fr a fi respectat o anumit regul de ordonare dup valorile cmpurilor (nregistrrile noi sunt adugate la sfritul fiierului). Fiierele secveniale corespund oricrui tip de suport de memorie i reprezint cea mai simpl form de organizare. Accesul la nregistrrile fiierului se realizeaz numai n mod secvenial (prin parcurgerea fiecrei nregistrri pn se ajunge la cea cutat). Un alt dezavantaj este dat de neutilizarea eficient a spaiului de memorie extern: n momentul n care o nregistrare este tears din fiier, spaiul care a fost alocat nu poate fi reutilizat i prin urmare performanele de acces la date se deterioreaz pe masur ce au loc actualizri n fiier. Acest dezavantaj se poate elimina prin reorganizarea la un anumit interval de timp a fiierului, n scopul recuperrii spaiului neutilizat al nregistrrilor terse. Indexat secvenial. Se introduce modul de acces aleator ntr-un fiier de organizare secvenial. Modul de acces aleator presupune o coresponden ntre articol i nregistrarea fizic care l conine. Aceast coresponden se realizeaz prin intermediul unei funcii definit tabelar. Acest tip de organizare se caracterizeaz prin faptul c fiecrui fiier i se asociaz la creare, un fiier numit fiier indexat secvenial, n care se nscrie corespondena dintre valoarea cheii de articol i adresa de pe suport a articolului respectiv. Un element al tabelului de index denumit index, este format din valoarea unei cheii i din adresa zonei de memorie. Valorile cheilor de articol sunt organizate n tabelul de index n ordine cresctoare: I = { (ki, pi) | i = 1, 2,n} unde ki reprezint valoarea cheii i pi zona de pe suport (este un pointer). Aceast organizare reprezint un compromis ntre un fiier secvenial pur i un fiier selectiv pur, prin faptul c nregistrrile pot fi prelucrate secvenial sau accesate individual (aleator). Crearea i consultarea se face fie prin acces secvenial, fie prin acces aleator. Operaiile de actualizare: adugarea unei nregistrri se face numai prin acces direct; modificarea se poate efectua fie n acces secvenial sau n acces aleator. Selectiv. La baza acestui tip de organizare st acelai principiu ca la organizarea indexat secvenial, respectiv realizarea unei corespondene ntre articolul fiierului i zona de pe suport pe care aceasta o ocup. Tehnica de realizare a corespondenei difer: n locul unei corespondene definit printr-un fiier se introduce o coresponden definit printr-o funcie dat explicit (funcie hash). nlocuirea unei funcii definit tabelar printr-o funcie dat explicit s-a fcut din motive de vitez. Calculul valorii unei funcii n scopul determinrii adresei de memorie, se face mult mai rapid dect cutarea ntr-un fiier care nu este n memoria principal ci pe suportul de memorie extern. Fiecrui articol i se asociaz o valoare de identificare astfel nct oricare ar fi dou articole ale unui fiier, valorile lor de identificare sunt diferite. Totalitatea valorilor de
identificare ale articolelor unui fiier de organizare selectiv formeaz mulimea valorilor unei alte variabile denumit cheie simbolic. Spre deosebire de cheia de articol, cheia simbolic nu reprezint o zon din corpul articolului ci o zon din memorie, independent de fiier, ale crei valori ns, identific articolele unui fiier. Valorile cheii simbolice se definesc la crearea fiierului pentru fiecare articol al acestuia. Mai mult, se realizeaz i corespondena ntre fiecare valoare a cheii simbolice i valoarea cheii reale care reprezint numrul casetei (suportul alocat unui fiier de sistemul de operare) n care se nregistreaz articolul respectiv. Dup cum s-a explicat la principalele tipuri de organizare a fiierelor, exist mai multe metode de acces, prin intermediul crora se pot stoca i regsi nregistrrile dintr-un fiier. Astfel, cele mai utilizate metode de acces sunt: secvenial presupune parcurgerea tuturor articolelor unul dup altul, ncepnd cu primul articol i terminnd cu cel cutat; indexat presupune existena unui tabel index asociat fiecrui fiier, n care se nscrie la crearea fiierului, corespondena dintre valoarea cheii de articol i adresa de pe suport a articolului respectiv. Un element al tabelului index, denumit index, este format din valoarea unei chei i din adresa unei zone de suport. Valorile cheilor trebuie s fie unice; indexat-secvenial este o metod de acces care mbin proprietile celor dou metode descrise mai nainte; dup ce valoarea cheii de articol a fost regsit ntr-un anumit domeniu de articole, cautarea se face secvenial pn se regasete articolul cerut; aleator presupune c fiecare articol poate fi tratat individual fr a mai parcurge articolele care l preced. Un asemenea mod presupune o coresponden bine definit ntre articol i nregistrarea fizic corespunztoare. Pentru a avea acces la datele dintr-un fiier sunt necesare efectuarea unor operaii: accesul la fiier, utilizatorul comunic sistemului de operare numele fiierului. Acesta l caut i dac l gsete l deschide; citirea / scrierea datelor n fiier; nchiderea fiierul. 1.2. Tipuri de fiiere. Structuri i tipuri de index Fiecare tip de fiier servete unui anumit scop n procesul prelucrrii. Un fiier are un nume format din maximum 8 caractere, un punct separator i o extensie format din maximum 3 caractere. Un nume de fiier poate conine litere, numere, ns nu poate s conin caractere speciale sau spaii. De asemenea, numele fiierului nu poate ncepe cu un numr, i singurul caracter special permis este underscor-ul (_). Numele fiierului este stabilit n momentul n care acesta se creeaz, la fel extensia sa. Regsirea datelor ntr-un fiier trebuie s se fac ntr-un mod rapid i eficient. Una din tehnicile care permite accesul eficient la datele dintr-un fiier este utilizarea indexurilor. Un index este un fiier adiional (deci, o structur de date) care permite localizarea mai rapid a anumitor nregistrri dintr-un fiier, n general cu scopul de a rspunde mai rapid la anumite interogri.
Atunci cnd accesul la datele din fiier se face n mod indexat, fiierul de baz are ataat un fiier index, care este stocat pe acelai suport cu fiierul. Cu ajutorul lor accesul la nregistrrile de date se realizeaz pe baza cmpurilor index. Un index elimin necesitatea de a parcurge serial sau secvenial fiierul, de fiecare dat [Connolly & alt, 2001]. Un index este construit n mod frecvent dup un singur cmp al fiierului numit i cmp index, ce asociaz la fiecare valoare a cmpului index o list de pointeri ctre toate blocurile ce conin nregistrarea cu valoarea specificat. Drept comparaie, putem folosi o carte, care la sfrit listeaz termenii importani aranjai n ordine alfabetic. La fiecare termen din aceast list este furnizat o succesiune a numrului paginilor la care termenul apare i este explicat. Fiierul care conine nregistrrile logice (articolele) se numete fiier de date, iar fiierul care conine nregistrrile indexurilor se numete fiier index. Dac n fiierul de date cmpul index este un cmp cheie al fiierului de date pentru fiecare nregistrare din fiier valoarea acestui cmp este unic atunci indexul se numete indexul primar (este un fiier ordonat cu nregistrri de lungime fix) i care are dou cmpuri: primul cmp al indexului este de acelai tip cu un cmp cheie ordonat al fiierului de date, al doilea cmp este un pointer ctre un bloc (o adres a blocului). Cmpul cheie de ordonare se mai numete i cheie primar a fiierului de date. De exemplu fiierul TERTI.DBF, a crui structur este format din urmtoarele cmpuri: cod unic, denumire, adresa, localitate etc., are drept cheie primar (cheie de ordonare) cmpul (cmp index) cod unic (figura nr. 1.1.).
Fig. 1.1. Corespondena dintre fiierul de baz i fiierul index n situaia n care cmpul index nu este un cmp cheie primar al fiierului deci pot exista mai multe nregistrri n fiierul de baz care au aceeai valoare pentru cmpul n cauz indexul se numete index de comasare sau index de grup. Un astfel de cmp identific un grup de nregistrri. n aceast situaie se poate crea un index ce faciliteaz gsirea nregistrrilor ce aparin unui cmp index (au aceeai valoare pentru cmpul din fiierul de date).
Fig. 1.2. Corespondena dintre fiierul de baz i indexul de grup Un index de grup este deci un fiier ordonat dup dou cmpuri: primul cmp conine aceeai informaie cu cea a cmpului non cheie de ordonare, al doilea cmp conine un pointer ctre un bloc de date. n acest mod fiierul index conine cte o nregistrare pentru fiecare valoare distinct a cmpului de ordonare. De exemplu, fiierul TERTI.DBF se dorete a fi ordonat dup valoarea cmpului localitate (figura nr. 1.2.). Deci cmpul de grupare este localitate. Index secundar. Metoda de indexare secundar se aplic fiierelor neordonate, indiferent dac valorile cmpului dup care se face indexarea n fiierul de date, sunt sau nu distincte. Indexul secundar este un fiier ordonat dup dou cmpuri ca i la ali indexi, n care primul cmp este identic cu cel al fiierului de date, iar al doilea cmp este un pointer. Cmpul pentru care indexul este construit se numete i cmp de indexare. Deci orice cmp al unui fiier poate fi cmp de indexare secundar. Un astfel de cmp este numit i cheie secundar a fiierului. n acest caz pointerii din fiierul index sunt pointerii blocurilor, i nu pointerii nregistrrilor. Dup detectarea blocului, acesta este transferat n buffer-ul alocat fiierului i se identific nregistrarea prin cutare secvenial. Indexurile secundare mbuntesc performanele interogrilor care utilizeaz alte atribute dect cheia primar. Totui, mbuntirea interogrilor trebuie echilibrat fa de suprasarcina presupus de ntreinerea indexurilor n timp ce este reactualizat fiierul de baz [Connolly & alt, 2001]. Deci, se poate spune c un fiier de baz poate avea cel mult un index primar sau un index de grup i poate avea mai mui indexi secundari.
1.3. Concepte specifice unei baze de date Utilizarea calculatoarelor personale n procesul de prelucrare a datelor a avut o evoluie strns legat de tot ce reprezint lumea IT1. Dac la nceput pentru stocarea datelor era suficient un fiier, sau mai multe, n care erau memorate datele referitoare la activitatea economicofinanciar a unei ntreprinderi, pe msur ce aceast activitatea s-a mrit iar domeniile informatizate au crescut s-a simit necesitatea unor noi metode de stocare a informaiilor. Astfel multe dintre datele stocate n diverse fiiere aveau legturi unele cu altele, multe informaii erau redundante, iar volumul de date memorate de suporturi de memorie externe a crescut simitor. Din acest motiv, precum i din alte considerente legate de: o gestiune mai corect a acestor informaii, obinerea unor rezultate referitoare la anumite interogri asupra datelor din mai multe fiiere, a reducerii cheltuielilor cu ntreinerea acestui volum de date etc., s-a impus organizarea acestora n baze de date. O baz de date reprezint o colecie de date organizate sub form de tabele (n terminologia bazelor de date, un fiier se numete tabel), date ntre care exist anumite legturi (numite
1
IT Information Technology
relaii logice), i care permite cutarea rapid i regsirea informaiilor utiliznd calculatorul. Corespondena terminologiei utilizat de un fiier, i o tabel este ilustrat n tabelul urmtor: Fiier Articol Cmp Exemple de baze de date: studenii unei faculti; cartea de telefon; crile dintr-o bibliotec; angajaii unei societi etc. Baza de date conine nu numai datele organizaiei, ci i o descriere a acestora, descriere care mai este cunoscut i sub denumirea de catalog de sistem (alte denumiri utilizate sunt: dicionar de date, meta-date). Acest mod de organizare, cunoscut sub denumirea de colecie autodescris de nregistrri integrate [Connolly & alt, 2001], face ca sistemul de organizare sub forma bazelor de date s asigure independena dintre programe i date, care lipsea la sistemul bazat pe fiiere. Acest avantaj se traduce prin faptul c orice modificare n structura bazei de date nu va mai trebui s se efectueze i n codul surs al programului care trateaz baza de date respectiv. Atunci cnd se vorbete despre o baz de date trebuie identificate entitile, atributele i relaiile dintre ele. O entitate reprezint un obiect distinct caretrebuie reprezentat n baza de date (un student, o carte, un produs etc.). Un atribut este o proprietate care descrie o caracteristic oarecare al obiectului care se dorete a fi nregistrat n baza de date, iar o relaie este o legtur, o asociaie, ntre mai multe entiti. Tipurile de baze de date cele mai cunoscute sunt: relaionale; ierarhice; orientate obiect; distribuite; n reea etc. Bazele de date relaionale: au aceeai structur fizic cu datele ce trebuie prelucrate; de cele mai multe ori acestea se prezint sub form de tabele (numite relaii) cu linii i coloane (liniile constituind obiectele iar coloanele, atributele ce caracterizeaz obiectele). Modelul relaional i datoreaz numele i metodele, noiunii matematice de relaie. Se numete relaie peste mulimile M1, M2,..., Mn o submulime a produsului cartezian M1, M2,..., Mn. Fie deci relaia REL definit peste aceste mulimi. Se spune despre elementele M1, M2,..., Mn c sunt n relaia REL. Numrul mulimilor ce intr n relaie se numete gradul relaiei, iar numrul n se numete cardinalul relaiei. n continuare se va explica pe scurt cteva concepte fundamentale pe care trebuie s le tie orice utilizator atunci cnd dorete s realizeze i s lucreze cu o baz de date. Mai putem spune c orice baz de date este o colecie de nregistrri, unde prin nregistrare nelegem totalitatea informaiilor utile despre un anumit lucru. De exemplu, ntr-o bibliotec fiecare nregistrare este reprezentat de o carte.
Tabel Rnd Coloan
n general o baz de date const din unul sau mai multe tabele, unde fiecare tabel conine mai multe rnduri (numite adesea nregistrri sau articole record), care la rndul lor conin mai multe coloane (care mai sunt denumite i atribute sau cmpuri field). Fiecare nregistrare dintr-o tabel este identic ca structur, sau altfel spus toate nregistrrile au aceeai structur a cmpurilor. Se mai poate spune c intersecia dintre o singur coloan i un rnd formeaz un cmp. Fiecare cmp din cadrul unei nregistrri conine cte o informaie referitoare la nregistrarea respectiv, deci cmpurile conin valori. Valorile cmpurilor sunt n general diferite pentru fiecare nregistrare. Cmpul curent este cmpul activ dintr-o singur nregistrare. nregistrarea curent este o singur nregistrare ntr-un set de mai multe nregistrri supuse ateniei dintr-o tabel a bazei de date. De exemplu, o baz de date referitoare la evidena facturilor are mai multe tabele. ntr-una din tabelele bazei de date, numit EVID_FACTURI, sunt stocate informaiile referitoare la terii organizaiei respective, denumit TERTI.DBF i care are urmtoarea structur: cod unic, denumire, adresa, localitate, jude, telefon, fax, persoan contact, banca, cont bancar, tip. Aceste concepte sunt ilustrate n figura nr. 1.3.
Fig. 1.3. Structura unei tabele dintr-o baz de date
1.4. Tipuri de relaii dintre tabelele unei baze de date ntre tabelele unei baze de date se stabilesc anumite relaii. Relaia este o asociere care este stabilit ntre cmpurile (coloane) comune din dou tabele ale bazei de date. Relaia dintre dou tabele ale unei baze de date nu este una bidirecional, de egalitate, ci este o relaie unidirecional, de subordonare. Una dintre tabele va fi denumit tabel primar (printe) i va avea subordonat pe cea de-a doua tabel, numit tabel secundar (copil). Deplasarea indicatorului tabelei printe va determina poziionarea corespunztoare a indicatorului pentru tabela copil, dar invers aceast determinare nu se realizeaz. Modul de lucru cu bazele de date relaionale presupune: crearea tabelelor componente ale bazei de date; deschiderea acestor tabele; stabilirea relaiilor dintre tabele; accesarea datelor din toate tabelele simultan, fr a mai fi necesar coordonarea acestora.
Pentru stabilirea unei relaii ntre dou tabele este nevoie de o cheie, cheie care s fie regsit n ambele tabele (este de fapt un cmp care trebuie s se regseasc n structura ambelor tabele i care n mod normal au acelai nume n ambele tabele). Aceast cheie trebuie s aib valori unice ntr-una dintre tabelele implicate n relaie. n tabela n care valoarea cheii este unic (tabela printe), ea este numit cheie principal sau primar, iar n cea de-a doua tabel (tabela copil), ea este numit cheie relativ, sau cheie strin. Exist trei tipuri de relaii care se pot stabili ntre tabelele unei baze de date, i acestea sunt: relaia unulaunu (one-to-one relationship). ntr-o astfel de relaie, fiecare articol dintr-o tabel a bazei de date este legat cu un articol i numai cu unul din cealalt tabel. Aceast relaie este folosit mai rar n practica de zi cu zi.
TERI ADRESE
relaia unulamuli (one-to-many relationship) este cea mai utilizat relaie. ntr-o astfel de relaie, fiecare articol dintr-o tabel (tabela printe) poate fi asociat cu mai multe articole dintr-o alt tabel, dar cea de-a doua tabel (tabela copil) nu poate avea asociat dect un articol n prima tabel. Iat cteva exemple de astfel de relaii: o baz de date care are n componena sa urmtoarele tabele: furnizori i facturi: fiecare furnizor poate emite mai multe facturi; o baz de date cu filialele unei societi i salariai: fiecare unitate poate avea mai muli salariai.
FURNIZORI Factura 1
Factura 2
Factura n
relaia muli-la-muli (many-to-many relationship). O relaie mulilamuli exist atunci cnd unul sau mai multe articole dintr-o tabel pot fi asociate cu mai multe articole dintr-o alt tabel i invers. Relaiile de acest tip sunt mai dificile, i n general pentru a implementa o astfel de relaie trebuie creat o a treia tabel care s conin cte un articol pentru fiecare combinaie dintre cele dou tabele. Cheia primar a celei de-a treia tabele este alctuit din cheile primare (pentru tabela respectiv ele sunt chei strine) din ambele tabele.
Furnizor 1 Piesa 1
Furnizor 2
Piesa 2
Furnizor 3
Piesa 3
Am exemplificat aceast relaie cu o baz de date format din dou tabele: furnizori i piese. Un furnizor poate deine mai multe piese, i o aceeai pies poate fi cumprat de la mai muli furnizori.
Atunci cnd se proiecteaz o aplicaie cu baze de date trebuie s se aib n permanen n vedere pstrarea integritii ei. n acest scop se folosesc mai multe metode, dar dintre cele mai folosite amintim: Determinarea unui domeniu pentru valorile permise a fi introduse n cmpurile tabelelor bazei de date. Orice ncercare de a aduga date ntr-un cmp care nu se ncadreaz n acest domeniu este ignorat. Verificarea introducerii unor valori corecte ntr-o tabel a unei baze de date mai poart denumirea i de testarea validitii. Integritatea referenial se refer la verificarea relaiilor dintre datele coninute ntr-o tabel cu date referite ntr-o alt tabel. Relaiile de integritate referenial ajut la asigurarea c informaia dintr-o tabel este egal cu informaia din tabela cu care intr n aceast relaie. O factur nu poate fi adugat n baza de date pentru un ter care nu exist n baza de date. De exemplu, s presupunem c avem dou tabele, una conine informaii despre furnizori, iar cealalt conine informaii despre facturile primite de la furnizori. Cele dou tabele sunt asociate prin intermediul cmpului ce conine codul unic al furnizorului. Integritatea referenial pune ntrebri de genul: ce se ntmpl dac se dorete tergerea unui furnizor, din tabela Terti, pentru care exist facturi n tabela Facturi ? ce se ntmpl dac se ncearc introducerea unei facturi de la un furnizor care nu exist n tabela Terti ? mai sunt o mulime de alte situaii care pot aprea. Pentru rezolvarea acestor situaii exist dou modaliti de impunere a integritii refereniale n bazele de date relaionale i anume: integritatea referenial declarativ, care este stabilit atunci cnd este definit baza de date (structura ei), de tipul nu se poate introduce o factur n tabela de facturi, dac n tabela de furnizori nu exist furnizorul respectiv; un program care se execut atunci cnd apare un anumit eveniment, cum ar fi actualizarea datele dintr-o tabel, numit i trigger (declanator). Integritatea referenial declarativ este preferabil scrierii de programe care trateaz evenimentul. 1.5. Sisteme de gestiune a bazelor de date Pentru a putea separa datele n mai multe tabele i a evidenia relaiile care exist ntre aceste date, stocate n diferite tabele, se utilizeaz un alt concept i anume cel de SGBD - Sistem de Gestiune a Bazelor de Date, care reprezint un sistem de programe care permite utilizatorului definirea, crearea i ntreinerea bazei de date i accesul controlat la acesta. Baza de date se descrie independent de programele care folosesc datele. Descrierea acestora vizeaz deopotriv structurile de date, legturile ntre acestea i regulile care trebuie s asigure coerena datelor (acestea vor fi descrise n alt capitol sub denumirea de reguli de integritate sau constrngeri de integritate). Funciile pe care un sistem de gestiune a bazelor de date trebuie s le pun la dispoziia utilizatorului sunt: gestionarea tranzaciilor; controlul concurenei; controlul refacerii.
Aceste funcii au scopul de a garanta c baza de date este fiabil i rmne ntr-o stare coerent, atunci cnd aceasta este accesat de mai muli utilizatori i n cazul detectrii componentelor hardware i software. n 1982, Edgar F. Codd [Codd, 1982] a enunat opt obiective pe care un SGBD trebuie s le furnizeze utilizatorilor, i anume:
1.
2.
3.
4.
5.
6.
7. 8.
Stocarea, regsirea i reactualizarea datelor un sistem de gestiune a bazelor de date trebuie s pun la dispoziia utilizatorului funciile care permit stocarea, regsirea i reactualizarea datelor din baza de date. Aceasta este funcia fundamental a unui SGBD. Un catalog accesibil utilizatorului un SGBD trebuie s asigure un catalog accesibil utilizatorilor, care s conin descrierile articolelor de date. Un catalog de sistem este un depozit de informaii care descrie datele din baza de date, el coninnd date despre date sau meta-date. Volumul de date coninut i modul n care sunt utilizate informaiile variaz de la un sistem la alt sistem. Gestionarea tranzaciilor un SGBD trebuie s furnizeze un mecanism care s garanteze c sunt efectuate toate reactualizrile corespunztoare unei anumite tranzacii sau c nu se efectueaz nici una. O tranzacie reprezint o aciune sau o serie de aciuni, realizate de ctre un singur utilizator sau de un program de aplicaie, prin care se acceseaz sau se modific coninutul bazei de date. Dac tranzacia eueaz n timpul execuiei, din diferite motive, atunci baza de date va fi ntr-o stare incoerent, deci unele modificri au fost efectuate, iar alte nu. n consecin, pentru a aduce din nou baza de date ntr-o stare coerent, modificrile efectuate trebuie anulate. Controlul concurenei un SGBD trebuie s furnizeze un mecanism care s garanteze c baza de date este corect reactualizat, atunci cnd mai muli utilizatori efectueaz simultan astfel de operaii. Obiectivul acestui serviciu este acela de a planifica tranzaciile, astfel nct s se evite orice interferene. Aceast funcie este necesar pentru a proteja baza de date fa de incoerena i pierderea datelor. Controlul refacerii (reconstituire) un SGBD trebuie s asigure un mecanism de reconstituire a bazei de date, n cazul n care aceasta este deteriorat dintr-un motiv oarecare. Refacerea bazei de date reprezint procesul de restaurare a bazei de date ntr-o stare corect, ca urmare a unei defeciuni. Aceast funcie este necesar pentru a proteja baza de date fa de incoerena i pierderea datelor. Servicii de autorizare un SGBD trebuie s furnizeze un mecanism care s garanteze c numai utilizatorii autorizai pot accesa baza de date. Cu alte cuvinte, SGBD trebuie s garanteze c baza de date este sigur. n acest context, intervine termenul de securitate care se refer la protejarea bazei de date fa de accesul neautorizat, fie intenionat, fie neintenionat. Suport pentru comunicarea datelor un SGBD trebuie s poat fi integrat unui software de comunicaie. Servicii de integritate un SGBD trebuie s furnizeze mijloace care s asigure c att datele din baza de date, ct i modificrile acestora respect anumite reguli. Acest serviciu poate fi privit ca un alt tip de protecie a bazei de date. De regul, integritatea se exprim prin termeni de constrngeri, care reprezint regulile de coeren pe care baza de date nu are voie s le ncalce.
Orice SGBD asigur anumite faciliti, i anume: Pentru definirea bazei de date pune la dispoziia utilizatorilor un limbaj, numit limbaj de definire a datelor (DDL - Data Definition Language). Acesta permite utilizatorilor specificarea tipurilor de date i a structurilor, n timp ce constrngerile asupra datelor sunt stocate n baza de date.
Pentru adugarea, actualizarea i tergerea datelor din baza de date SGBD-ul pune la dispoziia utilizatorilor un limbaj, numit limbaj de manipulare a datelor (DML - Data Manipulation Language). La rndul su, acesta ofer o facilitate de interogare general a datelor din baza de date, denumit limbaj de interogare. Existena acestui limbaj de interogare elimin dezavantajele sistemelor bazate pe fiiere, unde utilizatorul era constrns s lucreze cu un set fix de interogri. Cel mai cunoscut limbaj de interogare este SQL (SQL Structured Query Language). Permite fiecrui utilizator s-i defineasc modalitile proprii de vitualizare a bazei de date prin intermediul unei faciliti, cunoscut sub denumirea de mecanism de vizualizare. Limbajul DDL permite definirea de modaliti de vizualizare, n care acestea reprezint un subset al bazei de date.
Componentele unui SGBD sunt [Connolly & alt, 2001]: Hardware. Elementele hardware sunt reprezentate de la un singur calculator personal pn la o reea de calculatoare. Cerinele hardware depind de cerinele firmei i de SGBD-ul utilizat. Software. Aceast component cuprinde totalitatea programelor sistemului SGBD i programele de aplicaie, mpreun cu sistemul de operare, iar dac SGBD-ul este utilizat ntr-o reea de calculatoare trebuie inclus i software-ul de reea. Date. Din punct de vedere al utilizatorului aceasta este componenta cea mai important. Datele acioneaz ca o punte ntre componentele hardware i cele umane. Baza de date conine att datele operaionale, ct i meta-datele (date despre date). Structura bazei de date este denumit schem. Proceduri. Procedurile se refer la instruciunile i regulile care guverneaz proiectarea i utilizarea bazei de date. Persoane. Aceast component este reprezentat de persoanele care asigur analiza, proiectarea, implementarea i mentenana bazei de date. Astfel, aceast component cuprinde patru tipuri de persoane: administratorii de date i baze de date, proiectanii de baze de date, programatorii de aplicaii i utilizatorii finali. Software-ul SGBD evolueaz n permanen. De-a lungul anilor s-a trecut de la bazele de date ierarhice la cele normalizate, de la centralizare la distribuire, fiecare dintre aceste etape implicnd concepte suplimentare de descriere, stocare i regsire a datelor. Dac structurile de date pot s par naturale unui specialist, nu acelai lucru trebuie presupus i pentru utilizatorul obinuit. n realizarea unui sistem de baze de date, distribuit sau nu, este esenial caracterul prietenos pe care acesta trebuie s l prezinte utilizatorului final. De-a lungul evoluiei SGBD se disting trei generaii, respectiv: 1. Prima generaie este reprezentat de modelul de date n reea (IDS Integrated Data Store, depozit de date integrate) i modelul de date ierarhic (IMS Information Management System, sistem de gestionare a informaiilor). Propunerile pentru standardizarea acestor tipuri de SGBD au fost stabilite la Conferina despre Limbajele Sistemelor de Date (CODASYL - COnference on DAta SYstems Languages) din 1965. Acestea sunt cunoscute acum sub denumirea de sisteme CODASYL sau DBTG (Data Base Task Group), grupul operativ pentru baze de date. 2. A doua generaie. n 1970, E.F. Codd de la Laboratorul de Cercetare IBM a publicat un articol de foarte mare influen despre modelul de date relaional, dat care reprezint apariia celei de-a doua generaii de SGBD. Primele produse comerciale de SGBD-uri relaionale au aprut la sfritul anilor 1970 i nceputul anilor 1980. Un alt moment important n evoluia SGBD este reprezentat de anul 1976, cnd Chen a prezentat modelul entitate-relaie, care este o tehnic de proiectare a bazelor de date.
3.
A treia generaie este reprezentat de SGBD orientate obiect (OODBMS Object Oriented DataBase Management System) i SGBD obiectual relaionale (ORDBMS Object Relational DataBase Management System). 1.6. Arhitectura ANSI-SPARC pe trei niveluri
Cea mai cunoscut arhitectur utilizat n priectarea bazelor de date este arhitectura ANSISPARC pe trei niveluri (ANSI American National Standards Institute i SPARC Standards Planning and Requirements Committee), elaborat de Institutul Naional American pentru Standarde i Comitetul de Planificare i Cerine privind Standardele n 1975. Obiectivul arhitecturii cu trei niveluri este separarea vederii fiecrui utilizator asupra bazei de date de modul n care ea este reprezentat fizic.
Fig. 1.4. Arhitectura ANSI-SPARC pe trei niveluri Cele trei niveluri descrise n figura 1.4.: 1. Nivelul extern reprezint modul n care utilizatorii percep datele. Acest nivel descrie acea parte a bazei de date care este reprezentativ pentru fiecare utilizator. Vederea extern include numai acele entiti, atribute i relaii de care este interesat utilizatorul. Aceleai date pot fi reprezentate diferit n funcie de cerinele utilizatorilor. 2. Nivelul intern este modul n care SGBD i sistemul de operare percep datele i el este plasat n locul n care sunt stocate efectiv datele (n general, pe suporturi de memorie externe). Acest nivel descrie cum sunt stocate datele n baza de date. 3. Nivelul conceptual realizeaz transpunerea i independena care se dorete a fi ntre nivelul extern i cel intern. Acest nivel descrie ce date sunt stocate n baza de date i relaiile dintre acestea. El reprezint: - toate entitile, atributele i relaiile dintre ele; constrngerile asupra datelor; - informaiile semantice despre date; - informaiile privind securitatea i integritatea. Acest nivel este independent de mediul de stocare a bazei de date. n general sunt utilizare SGBDR - Sistem de Gestiune a Bazelor de Date Relaionale.
Dac este s se fac o retrospectiv a tehnologiilor utilizate n acest domeniu al stocrii datelor, exist patru tehnologii fundamentale pentru gestionarea datelor (figura 1.5.): sisteme de fiiere; sisteme de gestiune a bazelor de date relaionale (RDBMS - Relational DataBase Management System); sisteme de gestiune a bazelor de date orientate obiect (OODBMS - Object-Oriented DataBase Management Systems); sisteme de gestiune a bazelor de date obiectual-relaionale (ORDBMS - ObjectRelational DataBase Management System). Fiecare are calitile sale care-l fac potrivit pentru o anumit clas de probleme.
Fig. 1.5. Tehnologii fundamentale utilizate pentru gestiunea datelor
Capitolul 2 Proiectarea bazelor de date Proiectarea unei baze de date presupune parcurgerea anumitor pai. n funie de modalitatea i de corectitudinea parcurgerii etapelor respective, baza de date va fi una corect sau mai puin corect din punct de veder funcional. Cele trei proiecii ale unei baze de date sunt: proiecia conceptual, logic i fizic. nainte de a ncepe proiectarea logic i fizic a unei baze de date, se face proiectarea conceptual. n urma acestui proces rezult un model conceptual care trebuie s evidenieze fiecare vedere a utilizatorului final. Astfel, proiectarea i dezvoltarea unei baze de date cuprinde mai multe etape, iar fiecare etap poate avea la rndul ei, una sau mai multe subetape [Connolly & alt, 2001]: Construirea modelului conceptual al datelor pentru fiecare vedere a utilizatorului. Acest etap cuprinde mai multe subetape: Identificarea tipurilor de entiti. Identificarea tipurilor de relaii. Identificarea i asocierea atributelor cu tipurile de entiti sau relaii. Determinarea atributelor cheie candidat i a cheilor primare. Specializarea / generalizarea tipurilor de entiti (opional). Trasarea diagramei Entitate-Relaie. Revizuirea modelului de date concptual mpreun cu utilizatorul. Construirea i validarea modelului logic al datelor pentru fiecare vedere a utilizatorului. Modelul logic se construiete pe baza modelului conceptual care va fi validat (verificat) utiliznd tehnica de normalizare. Construirea i validarea modelului logic global al datelor. Pentru a se obine modelul logic global se vor analiza toate modelele logice ale utilizatorilor n vederea obinerii unui singur model logic. Acesta va trebui s conin fiecare entitate i relaie caracteristic sistemului real. Pentru a obine acest model trebuie s se execute anumite aciuni, printre care se enumer: Revizuirea denumirilor entitilor i a cheilor primare corespunztoare fiecrei entiti. Revizuirea denumirilor relaiilor. Se va revedea aceeai entitate din toate vederile locale ale utilizatorilor n vederea obinerii unei singure entiti care s cuprind toate caracteristicile cerute de utilizatori. Se va revedea aceeai relaie din toate vederile locale ale utilizatorilor n vederea obinerii unei relaii unice. Verificarea entitilor i a relaiilor lips, precum i verificarea cheilor strine. Reactualizarea documentaiei. Validarea modelului logic global al datelor. Verificarea modelului logic global n vederea dezvoltrii viitoare. Realizarea diagramei modelului logic al datelor, diagrama Entitate-Relaie. Verificarea modelului logic global al datelor, mpreun cu utilizatorii. Alegerea SGBD-ului int. Aceast etap presupune alegerea modului n care vor fi reprezentate relaiile de baz identificate n modelul logic global al datelor, n SGBD-ul
ales. De asemenea, se vor proiecta regulile de constrngere, care se impun asupra entitilor, atributelor i a relaiilor existente. Construirea i validarea modelului fizic. n aceast etap se determin organizrile fiierelor i metodele de acces care vor fi utilizate pentru memorarea bazei de date pe suportul extern de memorie.
2.1. Modele de date Un model este o reprezentare a obiectelor i evenimentelor din lumea real precum i asocierile existente ntre ele. Modelul constituie o abstractizare care trebuie s se concentreze asupra aspectelor eseniale ale unei organizaii pentru care se dorete proiectarea unei baze de date, i trebuie s ignore aspectele accidentale. El trebuie s asigure conceptele de baz i notaiile cu ajutorul crora proiectanii bazei de date i utilizatorii finali vor putea manipula datele. Astfel un model are n componena sa trei elemente: Un set de reguli care stau la baza construirii bazei de date - partea structural. Tipurile de operaii care sunt permise asupra datelor - partea de manipulare. Un set de reguli de integritate. Un model de date este [Connolly & alt, 2001]: O colecie integrat de concepte, necesare descrierii datelor, relaiilor dintre date i constrngerilor asupra datelor dintr-o organizaie. Un model este de fapt o reprezentare a segmentului din lumea real i a relaiilor dintre ele pentru care se dorete implemetarea unei baze de date. Scopul unui model de date este de a reprezenta datele asociate segmentului din lumea real i de a fi nelese de utilizatori. Modelele de date sunt clasificate n trei categorii principale: Modele de date bazate pe obiecte. n cadrul acestor modele de date conceptele utilizate sunt cele de entitate, atribut i relaie. O entitate este un obiect distinct din cadrul unei firme i care va fi reprezentat n baza de date; un atribut reprezint o proprietate care descrie a anumit caracteristic a obiectului pe care dorim s-l memorm n baza de date, iar o relaie este o asociere ntre dou sau mai multe entiti. Cel mai cunoscut model de date bazat pe obiecte este modelul Entitate-Relaie, dar n ultima perioada se pune accent i pe modelul orientat obiect. Modele de date bazate pe nregistrri. n acest model o baz de date are un numr de nregistrri cu un format fix (fiecare nregistrare are un numr fix de cmpuri, fiecare cmp avnd la rndul su o lungime fix), care poate fi de tipuri diferite. Cele mai cunoscute modele de date bazate pe nregistrri sunt: modelul relaional, modelul n reea i modelul ierarhic. Modele de date fizice. Modelele fozice descriu modalitatea de stocare a datelor pe suporturi de memorie externe (pe calculator) Cea mai utilizat arhitectur utilizat pentru satisfacerea cerinelor unui SGBD este aa numita arhitectur ANSI-SPARC (American National Standards Institute-Standards Planning and Requirements Committee), prezentat n figura 2.1..
Fig. 2.1. Arhitectura ANSI/SPARC pe trei niveluri Obiectivul principal al acestei arhitecturi pe trei niveluri este acela de a separa vederea fiecrui utilizator asupra bazei de date de modalitatea n care aceasta este reprezentat fizic (pe suportul de memorie extern). Astfel cele trei niveluri sunt: Nivelul extern reprezint modul n care utilizatorii vd (percep) datele din baza de date i de aceea mai poat denumirea de vederea utilizatorului asupra bazei de date. Acest nivel este reprezentat de ctre diferite vederi necesare utilizatorilor, alctuite din anumite entiti, atribute i relaii. Nivelul conceptual realizeaz transpunerea i independena dintre nivelul extern i cel intern, mai este cunoscut i sub denumirea de vedere general a bazei de date. n cadrul acestui nivel sunt descrise CE date sunt memorate n baza de date i relaiile dintre acestea. Nivelul conceptual reprezint: - toate entitile, atributele i relaiile dintre ele; - constrngerile care sunt impuse asupra datelor; - informaii despre securitatea i integritate abazei de date etc. Acest nivel conine structura logic a ntregii bazei de date , aa cum este ea vzut de administratorul bazei de date Nivelul intern reprezint modul n care sistemul de gestiune a bazei de date i sistemul de operare percep datele i este de fapt reprezentarea fizic a bazei de date de pe un anumit sistem de calcul. n cadrul acestui nivel sunt descrise CUM sunt memorate datele n baza de date. Sub acest nivel se gsete nivelul fizic, care poate fi administrat de ctre sistemul de operare, aflat sub comanda sistemului de gestiune a bazei de date (SGBD). Corespunztor fiecrui nivel exist cte o schem. Schema care face descrierea general a bazei de date se numete schema bazei de date, iar cele trei scheme corespunztoare celor trei niveluri ale arhitecturii ANSI-SPARC sunt: Schema extern, corespunde diferitelor vederi ale utilizatorilor. Schema conceptual, descrie toate articolele de date, relaiile care exist ntre acestea precum i constrngerile de integritate. Fiecare baz de date are o singur schem conceptual. Schema intern reprezint o descriere complet a modelului intern, i va conine definiiile articolelor (nregistrrilor) memorate, metodele de reprezentare, cmpurile, indexurile etc. Fiecare baz de date are o singur schem intern. Responsabilul cu transpunerea acestor trei tipuri de scheme este SGBD-ul. Cele 2 tipuri de transpuneri sunt ilustrate n figura 2.1., respectiv transpunerea comceptual/intern i transpunerea extern/conceptual.
Corespunztor celor trei tipuri de scheme, vor exista i trei tipuri de modele de date: Modelul de date extern, care este corespunztor vederii fiecrui utilizator al bazei de date. n literatura de specialitate acest model de date extern se mai numete i Universul Discursului (UoD - Universe of Discourse). Modelul de date conceptual este utilizat pentru a reprezenta o vedere general (logic) a datelor, care este independent de SGBD. Modelul de date intern este folosit pentru a reprezenta schema conceptual astfel nct ea s fie neleas de ctre SGBD. De asemenea, toate metodologiile utilizate n etapa de modelare (numit i etapa de proiectare) a bazelor de date cuprind trei etape principale, i anume: Elaborarea modelului conceptual (proiectarea conceptual) reprezint procesul de construire a unui model al informaiilor utilizate n cadrul unei organizaii, independent de toate consideraiile fizice. Aceast faz este complet independent de detaliile de implementare (elementele software ale SGBD-ului, programe de aplicaii, limbaje de programare, platforma hardware etc.). Revenind la modelarea conceptual, dup cum se observa din figura 2.1. schema conceptual reprezint centrul bazei de date.ea trebuie s suporte toate vederile externe i, la rndul ei, este suportat de schema intern. Schema conceptual trebuie s fie o reprezenatre complet i corect a cerinelor impuse de beneficiarul viitoarei baze de date (firma, organizaia) privind datele pe care trebuie s le conin (figura 2.2.). Modelul care rezult se numete model de date conceptual.
Fig. 2.2. Model conceptual
Elaborarea modelului logic (proiectarea logic). Dac modelul de date conceptual este independent de toate detaliile de implementare, modelul logic presupune cunoaterea modelului de date care st la baza SGBD int. Elaborarea modelului logic reprezint
procesul de construire a unui model al informaiilor utilizate n cadrul unei organizaii, bazat pe un anumit model de date conceptual (figura 2.3.). Elaborarea modelului fizic (proiectarea fizic) reprezint procesul de realizare a unei descrieri a implementrii bazei de date ntr-o capacitate de stocare secundar; descrie structurile de stocare i metodele de acces utilizate pentru realizarea unui acces eficient la date. Modelul rezultat n urma acestei etape este cel care st la baza materializrii bazei de date propriu-zise (figura 2.4).
Fig. 2.3. Model logic
Fig. 2.4. Model fizic
Capitolul 3 Baze de date relaionale Principiile modelului relaional i bazele de date relaionale au fost pentru prima dat prezentate de matematicianul (de la centrul de cercetri al IBM) E. F. Codd, n iunie 1970, cnd a publicat un articol numit "Un model relaional de date pentru bnci de date partajate de dimensiuni mari" (A Relational Model of Data for Large Shared Databanks). n respectivul articol, el a propus modelul relaional pentru sistemele de baze de date. Trebuie spus c i pn atunci fuseser manipulate i prelucrate date economice, cataloage ale bibliotecilor, fiiere de personal ns ntr-un mod mai puin formalizat, neunitar. n modelul relaional toate datele sunt structurate logic n cadrul unor tabele. Fiecare tabel are o denumire i este format din mai multe atribute ale datelor. Fiecare tuplu conine cte o valoare pe atribut. Obiectivele modelului relaional sunt [Connolly & alt, 2001]: S permit un grad nalt de independen de date. Programele de aplicaie nu trebuie s fie afectate de ctre modificrile reprezentrilor datelor interne, n particular de schimbrile organizrii fiierelor, ordinii nregistrrilor i cilor de acces. S furnizeze baze solide pentru tratarea semanticii, coerenei i problemelor de redundan a datelor. n articolul lui Codd se introduce conceptul de relaii normalizate, respectiv relaii care nu conin grupuri ce se repet. S permit expansiunea limbajelor de manipulare a datelor orientate spre seturi. 3.1. Concepte de baz Modelul relaional se bazeaz pe conceptul matematic de relaie, care este reprezentat fizic sub forma unei tabele. n modelul relaional, relaiile sunt utilizate pentru a pstra informaii despre obiectele care vor fi reprezentate n baza de date. O relaie este reprezentat printr-o tabel bidimensional, n care rndurile acestuia corespund nregistrrilor individuale, iar coloanele corespund atributelor. Atributele pot aprea n orice ordine, relaia ramnnd neschimbat. Deci un atribut este o coloan a unei relaii, cu o anumit denumire. Legat de atribut intervine noiunea de domeniu. Un domeniu reprezint mulimea de valori permise pentru unul sau mai multe atribute. Deci fiecare atribut dintr-o baz de date relaional este definit pe un anumit domeniu. Fiecare atribut poate avea domenii diferite, dar pot exista atribute care au acelai domeniu de valori. Gradul unei relaii reprezint numrul de atribute pe care le conine relaia. Astfel o relaie cu un atribut se numete relaie unar i are gradul nti; o relaie cu dou atribute se numete relaie binar, una cu trei atribute se numete relaie ternar, iar una cu n atribute poart denumirea de relaie n-ar. Cardinalitatea unei relaii reprezint numrul de tupluri coninute de aceasta. n comparaie cu gradul unei relaii, cardinalitatea se poate modifica n funcie de numrul de tupluri noi adugate sau terse.
n capitolul 1 s-au utilizat o serie de concepte, iar n continuare pentru a nu se confunda anumite concepte unele cu altele se va ilustra n continuare o terminologie alternativ a termenilor din modelul relaional.
Termeni formali Relaie Tuplu Atribut
Alternativa 1 Tabel Rnd Coloan
Alternativa 2 Fiier nregistrare (articol) Cmp
Tot n capitolul 1 s-au definit tipurile de chei care pot apare ntr-o baz de date. Revenind la bazele de date relaionale vom defini urmtoarele tipuri de chei [Connolly & alt, 2001]: Supercheia este un atribut sau un set de atribute, care identific n mod unic un tuplu din interiorul unei relaii. Cheie candidat este o supercheie pentru care nici o submulime adecvat nu este o supercheie n cadrul relaiei respective. Orice cheie candidat are dou proprieti: unicitate i ireductibilitate. Pentru o relaie pot exista mai multe chei candidat. Cnd o cheie este alctuit din mai multe atribute, cheie se numete cheie compus. Cheie primar este acea cheie candidat care este selectat pentru a identifica n mod unic tuplurile din cadrul unei relaii. Celelalte chei candidat care nu sunt selectate drept chei primare se numesc chei alternative. Cheie strin reprezint un atribut sau mai multe atribute din cadrul unei relaii, care se potrivesc cu cele din cheia candidat a unei alte relaii (posibil chiar a aceleiai relaii). 3.2. Integritatea relaional Pentru modelul relaional exist dou reguli de integritate: integritatea entitilor i integritatea referenial. nainte a de defini cele dou tipuri de integritate trebuie clarificat conceptul de null. Null reprezint valoarea unui atribut, care n mod curent este necunoscut sau nu este aplicabil tuplului respectiv. Altfel spus un null este o valoare logic necunoscut i reprezint o modalitate de tratare a datelor incomplete sau deosebite. n realitate un null semnific absena unei valori. Din acest motiv nu trebuie confundat null-ul cu o valoare numeric egal cu zero sau cu un ir de caractere completat cu spaii (zerourile i spaiile sunt valori). Integritatea entitilor se refer la faptul c ntr-o relaie de baz (este o relaie cu o anumit denumire, corespunztoare unei entiti din schema conceptual, ale crei tupluri sunt stocate fizic n baza de date), nici un atribut al unei chei primare nu poate fi null. Semnificaia acestei afirmaii este aceea c orice cheie primar trebuie n mod obligatoriu s aib memorat o valoare. Integritatea referenial se aplic cheilor strine i are urmtoare semnificaie: dac ntr-o relaie exist o cheie strin, valoarea acesteia trebuie fie s coincid cu valoarea unei chei candidat a unui tuplu n relaia de baz, ori s fie n totalitate null.
n afara acestor integriti, asupra bazei de date se mai impun i nite reguli suplimentare, specificate de ctre utilizatorii sau administratorii bazei de date, i poart denumirea de constrngeri. 3.3. Regulile lui Codd Ideea lui Codd pentru un sistem de administrare a bazelor de date relaionale folosete conceptele matematice de algebr relaional. E. F. Codd a definit regulile fundamentale ale bazelor de date relaionale. Astfel, el a definit 13 reguli cunoscute drept Cele 12 reguli ale lui Codd, care caracterizeaz modelul relaional. Aceste reguli sunt organizate pe urmtoarele cinci domenii de funcionalitate: 1. Reguli fundamentale - regula 0 i regula 12. Acestea sunt reguli utilizate pentru a stabili dac un sistem este relaional. Dac aceste reguli nu sunt ndeplinite, sistemul nu este relaional. 2. Reguli structurale - regula 1 i regula 6. Conceptual fundamental al modelului relaional este cel de relaie. Codd stabilete c un SGBD trebuie s accepte o serie de caracteristici structurale: relaii, domenii, chei primare i strine, iar pentru fiecare relaie din baza de date trebuie s existe o cheie primar. 3. Reguli de integritate- regula 3 i regula 10. acceptarea integritii datelor este un criteriu important de apreciere a unui produs. Cu ct sunt impuse mai multe constrngeri de integritate care pot fi ntreinute de ctre SGBD, dect n cadrul fiecrui program de aplicaie, cu att calitatea datelor este mai bun i garantat. 4. Reguli de manipulare a datelor - regula 2, regula 4, regula 5 i regula 7. Exist 18 caracteristici de manipulare a datelor pe care trebuie s le accepte un SGBD relaional ideal. Acestea definesc caracterul complet al limbajului de interogare. Respectarea acestor reguli are ca efect izolarea utilizatorului i programelor de aplicaie de mecanismele fizice i logice, care implementeaz capacitile de gestionare a datelor. 5. Reguli privind independena de date - regula 8, regula 9 i regula 11. Codd a definit trei reguli care specific independena datelor de programele de aplicaie care le utilizeaz. Respectarea acestor reguli garanteaz protecia utilizatorilor i realizatorilor de programme fa de necesitatea de a schimba aplicaiile, ca urmare a reorganizrii bazei de date. Aceste reguli definite de Codd sunt: Regula 0 - regul fundamental. Un sistem relaional de administrare a bazelor de date trebuie s fie capabil s administreze bazele de date n ntregime prin funciile sale relaionale. Regula 1 - regula informaiei. Toate informaiile dintr-o baz de date relaional (inclusiv numele de tabel i de coloan) sunt reprezentate explicit ca valori n tabele. Aceast regul impune ca toate informaiile coninute n catalogul de sistem s fie memorate ca relaii i gestionate de ctre aceleai funcii operaionale care ar fi utilizate pentru ntreinerea datelor. Regula 2 - acces garantat. Se garanteaz c orice valoare dintr-o baz de date relaional este accesibil din punct de vedere logic, prin folosirea unei combinaii ntre numele tabelei, valoarea cheii primare i numele coloanei. Regula 3 - tratarea sistematic al valorilor null. SGBD asigur un suport sistematic pentru tratamentul valorilor null (date necunoscute sau neaplicabile), diferit de valorile prestabilite i independent de orice domeniu.
Regula 4 - catalog dinamic on-line, bazat pe modelul relaional. Descrierea bazei de date i a componentelor sale este reprezentat la nivel logic sub form de tabele i de aceea, poate fi interogat folosind limbajul bazei de date. Aceast regul specific faptul c exist un singur limbaj de manipulare att a meta-datelor, ct i a datelor. Regula 5 - sublimbajul multilateral al datelor. Trebuie s existe cel puin un limbaj acceptat care s aib o sintax bine definit i s fie multilateral, prin faptul c suport definirea i manipularea datelor, definirea vederilor, regulile de integritate, autorizarea i tranzaciile. Regula 6 - regula actualizrii vederilor. Toate vederile care pot fi actualizate pot fi actualizate i de ctre sistem. Aceast regul trateaz n mod explicit vederile. Regula 7 - operaii de inserare, reactualizare i tergere de nivel nalt. SGBD suport nu numai regsirea datelor la nivel de mulimi, ci i inserri, actualizri i tergeri. Regula 8 - independena fizic a datelor. Programele de aplicaii i cele create pe moment nu sunt afectate din punct de vedere logic de modificarea metodelor de acces fizic sau a structurilor de memorare. Regula 9 - independena logic a datelor. Programele de aplicaii i cele create pe moment nu sunt afectate din punct de vedere logic cnd sunt fcute modificri n structurile tabelelor. Regula 10 - independena integritii. Constrngerile de integritate specifice bazei de date relaionale trebuie s poat fi definite n sublimbajul relaional de date i memorate n catalog, nu pot fi nclcate i nu memorate n programe de aplicaie. Stocarea constrngerilor n catalogul de sistem are avantajul unui control centralizat. Regula 11 - independena distribuiei. Programele de aplicaii i cererile momentane nu sunt afectate din punct de vedere logic la prima distribuire a datelor sau la o distribuire ulterioar. Independena de distribuie semnific faptul c un program de aplicaie care acceseaz SGBD-ul pe un singur calculator trebuie s funcioneze fr modificri i ntr-o reea. Regula 12 - regul de nesubversiune. Nu trebuie s fie posibil s fie nclcate regulile de integritate definite prin limbajul bazei de date prin folosirea limbajelor de nivel inferior. Aceast regul impune ca ntregul acces la baza de date s fie controlat de ctre SGBD, astfel nct s nu fie compromis integritatea bazei de date. 3.4. Normalizarea n proiectarea unui sistem de baze de date se pot utiliza mai multe strategii de abordare dintre care cele mai cunoscute sunt: Proiectare de jos n sus (bottom-up sau ascendent), care ncepe prin definirea atributelor, a asociaiilor dintre atribute, i n final gruparea acestora n entiti. Un astfel de tip de abordare este reprezentat de procesul de normalizare. Normalizarea implic identificarea atributelor necesare i plasarea lor n tabele normalizate, bazate pe dependenele funcionale dintre atribute. Acest tip de proiectare a unui sistem de baze de date este indicat n proiectarea unor baze de date simple, cu un numr relativ mic de atribute.
Proiectare de sus n jos (top-down sau descendent), este indicat n proiectarea unor aplicaii de tip baze de date complexe. Aceasta ncepe cu realizarea unor modele de date, care conin cteva entiti i relaii de nivel nalt, dup care se aplic rafinri succesive de sus n jos, pentru a identifica entitile, relaiile i atributele asociate de nivel jos. Acest tip de abordarea este specific modelului Entitate - Relaie, care ncepe cu identificarea entitilor i relaiilor dintre ele care prezint interes pentru organizaie.
Deci normalizarea reprezint o tratare de jos n sus a proiectrii bazelor de date , care ncepe prin examinarea relaiilor dintre atribute. Normalizarea este deseori efectuat ca o serie de teste asupra unei relaii, pentru a stabili dac aceasta satisface sau violeaz cerinele unei anumite frome normale. La proiectarea bazelor de date relaionale se stabilete mulimea relaiilor, prin selectarea tipurilor relevante de entiti din realitatea modelat i a asocierilor dintre acestea. Modul n care se pot stabili relaiile unei baze de date nu este unic i de aceea este necesar s existe criterii de evaluare a calitii relaiilor, astfel nct acestea s asigure att integritatea datelor ct i performane de interogare ct mai bune. Criteriul de evaluare a relaiilor se bazeaz pe conceptul de dependene de date. Dependenele de date reprezint constrngeri care se impun valorilor atributelor unei relaii i care determin proprietile relaiei n raport cu operaiile de inserare, tergere i actualizare a tuplurilor. Pe baza dependenelor de date se pot stabili reguli de definire a relaiilor, astfel nct acestea s prezinte anumite proprieti, proprieti care caracterizeaz formele normale ale relaiilor (sau gradele de normalizare ale acestora). O form normal a unei relaii presupune anumite condiii pe care trebuie s le ndeplineasc valorile atributelor i dependenele de date definite pe acea relaie. Iniial, E.F. Codd a propus trei forme normale, numite prima form (FN1), a doua form (FN2) i a treia form normal (FN3). Ulterior, a fost introdus o definiie mai complet a celei de-a treia forme, care a primit numele de forma normal Boyce-Codd (FNBC). Toate aceste forme normale se refer la condiiile pe care trebuie s le ndeplineasc dependenele funcionale dintre atributele unei relaii. Forme normale superioare, cum sunt a patra form normal (FN4) i a cincea form normal (FN5) impun condiii dependenelor multivalorice, respectiv dependenelor de jonciune ntre atributele unei relaii. Aceste forme normale ulterioare trateaz situaii care apar foarte rar i se aplic numai cnd baza de date include relaii de tipul unu-la-muli i muli-la-muli, i atunci numai n anumite situaii speciale. Se amintete c o relaie este format dintr-un numr de atribute, iar o schem relaional dintr-un numr de relaii. Procesul de normalizare este o metod formal, care identific relaiile bazndu-se pe cheile primare (sau cheile candidat, n cazul formei FNBC) ale acestora i pe dependenele funcionale dintre atributele lor. Formele normale ale relaiilor formeaz o colecie ordonat (FN1, FN2, FN3, FNBC, FN4, FN5), i ele impun condiii din ce n ce mai restrictive asupra dependenelor de date admise, minimiznd astfel redundana i anomaliile de actualizare a relaiilor. Ordonarea formelor normale de la FN1 la FN5 nseamn c orice relaie aflat n FN2 este, de asemenea, n FN1, orice relaie n FN3 este n FN1 i FN2 etc. Normalizarea relaiilor const n descompunerea lor, astfel nct relaiile rezultate s ndeplineasc condiii din ce n ce mai restrictive n ceea ce privete dependenele de date, adic s corespund unor forme normale ct mai avansate. Prin normalizare se elimin (sau se micoreaz) redundana datelor memorate n relaii i anomaliile care provin din aceast redundan. Totui, dup normalizare, o parte din interogri vor necesita jonciuni ntre relaiile rezultate prin descompunere, jonciuni care nu erau necesare dac relaia nu ar fi fost descompus i care conduc la creterea duratei de execuie a
acestor operaii de interogare. De aceea, n practica proiectrii bazelor de date, normalizarea relaiilor nu se face ntotdeauna pn n forma normal cea mai nalt. Proiectanii pot pstra relaiile ntr-o form de normalizare mai sczut (de obicei n forma FN3 sau FNBC) cu condiia ca aceste situaii s fie bine cunoscute i documentate, pentru a se trata n mod corespunztor operaiile n care ar putea s apar anomalii de actualizare a relaiilor. 3.4.1. Redundana datelor i anomaliile de actualizare a relaiilor Unul din scopurile principale ale proiectrii bazelor de date relaionale este de a grupa atributele n relaii, astfel inct s se minimizeze redundana datelor i, prin aceasta, s se reduc spaiul de stocare necesar relaiilor de baz implementate. Problemele legate de redundana datelor memorate n relaii vor fi studiate pe un exemplu. Fie relaia: AP (IdAngajat, Nume, Prenume, Adresa, IdProiect, Ore) Fiecare tuplu al relaiei conine informaii despre un angajat i numrul de ore aferente fiecruia dintre proiectele la care acesta lucreaz. Semnificaia atributelor este destul de clar. Atributul IdAngajat este numrul de identificare (unic) al unui angajat; Nume, Prenume i Adresa sunt date ale angajatului. Atributul IdProiect este identificatorul (numrul) unui proiect la care lucreaz angajatul; se poate considera c este o cheie strin care refer cheia primar cu acelai nume dintr-o alt relaie, care descrie proiectele instituiei, dar acest lucru este mai puin important n acest moment. Atributul Ore reprezint numrul de ore lucrate de angajat la proiectul respectiv. Dac se admite c un angajat lucreaz la mai multe proiecte, atunci cheia primar a relaiei AP este PK = {IdAngajat, IdProiect}. Se observ c datele despre fiecare angajat (Nume, Prenume, Adresa) se repet n fiecare tuplu corespunztor fiecrui proiect la care acesta lucreaz, ceea ce reprezint un grad ridicat de redundan a datelor. Aceast redundan are ca efect att creterea spaiului de memorare a relaiei, ct i anomalii de actualizare a relaiei. Anomaliile de actualizare a relaiei apar la inserarea, tergerea sau actualizarea tuplurilor relaiei. Anomalii de inserare. n relaia AP nu se pot introduce date despre un angajat (identificatorul angajatului, numele, prenumele, adresa) dac nu exist cel puin un proiect la care acesta s lucreze. ntr-adevr, nu se poate introduce un tuplu cu valoare NULL a atributului IdProiect, deoarece acest atribut face parte din cheia primar a relaiei. O alt anomalie de inserare n relaia AP este aceea c se poate introduce un nou tuplu care conine alte valori ale atributelor Nume, Prenume sau Adresa, pentru aceeai valoare a identificatorului IdAngajat. De exemplu, se poate introduce tuplul (1, Dragomir, Eugen, Bucuresti, P3, 110). Acest tuplu este acceptat de SGBD, deoarece are cheia primar (1, P3), care nu mai exist n relaia AP. Dar n acest moment starea relaiei AP nu este consistent din punct de vedere semantic deoarece exist doi angajati (Ionescu Ion i Dragomir Eugen) care au acelai numr de identificare (IdAngajat = 1). Anomalii de tergere. Dac se terg toate tuplurile referitoare la un anumit proiect din relaia AP, atunci se pot pierde toate datele referitoare la acei angajai care lucreaz doar la proiectul respectiv. De exemplu, dac se terg tuplurile referitoare la proiectul P2 (1, Ionescu, Ion,
Bucuresti, P2, 150), (2, Popes-cu, Petre, Craiova, P2, 50), (3, Marin, Mihai, Ploieti, P2, 120), atunci se pierd toate informaiile despre angajatul Marin Mihai (identificatorul angajatului, numele, prenumele, adresa). Anomalii de actualizare. Dac se modific valoarea unuia din atributele care au valori redundante (Nume,Prenume sau Adresa) ntr-un tuplu al relaiei AP, starea relaiei poate deveni inconsistent. De exemplu, dac n tuplul (1, Ionescu,Ion,Bucuresti,P2,150) se modific atributul Nume la valoarea Gheorghiu, atunci n relaie vor exista tuplurile: (1,Ionescu,Ion, Bucuresti,P1,100) i (1,Gheorghiu,Ion,Bucuresti,P2,150), adic doi angajati cu nume diferite (Ionescu i Gheorghiu) au acelai numr de identificare (1). De asemenea, pot s apar numeroase alte situaii de inconsisten atunci cnd se fac actualizri ntr-o astfel de relaie care prezint date redundante. Dac se dorete pstrarea consistenei relaiei AP, trebuie s fie luate msuri speciale, care constau n realizarea unor proceduri care s verifice datele la fiecare operaie de actualizare a relaiei i s interzic operaiile care produc inconsisten. Anomaliile descrise mai sus se pot elimina dac relaia AP se descompune n dou relaii echivalente: A (IdAngajat, Nume, Prenume, Adresa), cu cheia primar IdAngajat P (IdAngajat, IdProiect, Ore), cu cheia primar {IdAngajat, IdProiect}, iar atributul IdAngajat este o cheie strin care refer cheia primar cu acelai nume din relaia A. Aceste relaii nu mai prezint redundan i nici anomalii la actualizarea lor (se poate verifica uor acest lucru). De exemplu, nu se admite inserarea tuplulului (1, Dragomir, Eugen, Bucureti) n relaia A, deoarece sistemul de gestiune refuz introducerea unui nou tuplu cu aceeai valoare (1) a cheii primare (IdAngajat). Relaiile A i P sunt mai bune din punct de vedere al volumului de date memorate i sunt, de fapt, relaii cu un grad de normalizare mai ridicat, aa cum se va demonstra n seciunile urmtoare. n schimb, interogrile asupra acestor dou relaii A, P sunt mai costisitoare (ca timp de execuie) fa de interogrile similare executate numai n relaia AP. Fie, de exemplu, interogarea Care este numrul de ore pe care le lucreaz angajatul cu numele Ionescu la proiectul P1 ?. Expresiile de algebr relaional pentru realizarea acestei interogri n relaia AP i respectiv, n relaiile A i P sunt: Q1 = Ore Nume ='Ionescu' AND IdProiect ='P1'(AP) Q2 = Ore Nume ='Ionescu' AND IdProiect ='P1'(A><P) Pentru realizarea interogrii Q2 este necesar o operaie de jonciune ntre cele dou relaii A i P n care a fost descompus relaia iniial AP, operaie care, n general, este mai costisitoare ca timp de execuie dect operaia de restricie aplicat unei singure relaii. Cum se poate ti care este cea mai bun alegere a relaiilor? Rspunsul la aceast ntrebare nu este foarte simplu, deoarece necesit numeroase informaii privind exploatarea ulterioar a bazei de date (ce spaiu de memorare a relaiilor va fi disponibil, ce interogri se vor efectua asupra relaiilor, n ce situaii este important s se obin o vitez de execuie mare etc.).
Principial, o relaie trebuie s corespund unui singur tip de entitate (sau asociere) precis definit i atributele acesteia s corespund numai acelui tip de entitate i s nu fie combinate cu atribute ale altor tipuri de entiti. Aceast cerin corespunde unei definiii semantice simple, concise i clare a relaiei. n exemplul de mai sus, relaia A corespunde tipului de entitate angajat i are ca atribute numai pe acelea care se refer la acest tip de entitate. La fel, relaia P corespunde asocierii M:N ntre tipul de entitate angajat i tipul de entitate proiect(care nu apare explicit n acest exemplu) i atributele acesteia se refer numai la acest aspect (numrul de ore lucrate de un angajat la un anumit proiect). Definiia semantic a acestor relaii este simpl i concis: A este relaia care conine date despre angajaii instituiei; P este relaia care conine numrul de ore lucrate de angajai la proiecte. n schimb, relaia iniial AP conine atribute amestecate despre angajai i proiectele la care acetia lucreaz, iar definiia ei semantic nu mai este att de simpl i clar: AP este o relaie care conine date despre angajaii instituiei i cte ore lucreaz la fiecare proiect. O abordare mai precis a problemei definirii relaiilor bazelor de date se poate face pe baza analizei dependenelor de date i a normalizrii relaiilor. 3.4.2. Dependenele funcionale O dependen funcional - DF - n relaia cu schema R = {A1,A2,...An} ntre dou mulimi de atribute X i Y (care sunt submulimi ale lui R) exist dac i numai dac, n orice stare a relaiei R, fiecrei valori a atributului (simplu sau compus) X i corespunde o singur valoare a atributului (simplu sau compus) Y. O dependen funcional este deci o constrngere ntre dou submulimi de atribute X i Y ale unei relaii i se noteaz XY. Ca exprimare, se mai spune c exist o dependen funcional de la X la Y, sau c atributul Y este dependent funcional de X. Noiunea de dependen funcional este o extindere a noiunilor de superchei i chei ale relaiilor: att supercheile (i, implicit cheile) relaiilor ct i dependenele funcionale sunt constrngeri pe care trebuie s le respecte valorile atributelor relaiilor. O submulime K a unei mulimi de atribute R (care este schema relaiei cu acelai nume) este supercheie a relaiei R dac nu exist dou tupluri diferite n relaia R care s aib aceleai valori ale atributelor din mulimea K. Aceasta nseamn c, dac t1[K]=t2[K], atunci t1[R]=t2[R], adic t1 i t2 sunt identice i reprezint un singur tuplu n relaia R. Dependena funcional XY este satisfcut de relaia R atunci cnd, pentru orice pereche de tupluri t1 i t2, t1[X] = t2[X] implic t1[Y] = t2[Y]. Aadar, fiind dat o dependen funcional XY n relaia cu schema R, atributul X este o supercheie a relaiei dac atributul determinat (Y) este chiar mulimea R. O dependen funcional XY impune condiia ca unei valori (x) a atributului determinant X s i corespund o singur valoare (y) a atributului determinat Y. Adic, toate tuplurile care au valoarea (x) a atributului X, trebuie s aib aceeai valoare (y) a atributului Y. Dat fiind c,
n cazul unei superchei, atributul determinat este chiar mulimea R a atributelor relaiei, i c ntr-o relaie nu pot exista dou sau mai multe tupluri identice, nseamn c nu pot exista dou sau mai multe tupluri cu aceeai valoare (k) a supercheii; aceast condiie este cunoscut ca fiind condiia de unicitate a supercheii. Dat fiind c oricare valoare a supercheii este unic ntr-o relaie, valorile atributelor determinate de aceasta sunt absolut necesare i unice i nu produc redundana datelor. n schimb, fiecare pereche de valori (x,y) ale atributelor X i Y ale dependenei funcionale XY poate s apar de mai multe ori n aceeai relaie, indicnd faptul c valoarea y este determinat n mod unic de valoarea x, dar acest lucru se repet de mai multe ori n relaie, deci reprezint o redundan a datelor. Aceeai proprietate, de a determina funcional mulimea de atribute ale relaiei R, o are i orice cheie CK (primar sau secundar) a relaiei date (CKR), dat fiind c o cheie este o supercheie cu proprietatea de ireductibilitate. Fiind dat o relaie i o mulime de dependene funcionale care trebuie s fie satisfcute de orice stare a relaiei, o parte din dependenele funcionale pot fi determinate de chei ale relaiei (i acestea sunt constrngeri implicite, care nu produc redundana datelor i nici anomalii de actualizare a relaiei i sunt impuse automat de sistemul de gestiune), iar alt parte pot fi determinate de alte atribute care nu sunt chei ale relaiei (i acestea sunt constrngeri explicite care produc redundana datelor i anomalii de actualizare a relaiei, nu sunt impuse de sistemul de gestiune i necesit proceduri speciale pentru verificarea i impunerea lor). Aceast diferen de comportare a dependenelor funcionale n funcie de tipul atributului determinant (cheie sau non-cheie) face ca analiza lor s necesite cunoaterea cheilor relaiei. Cheile relaiilor se pot preciza explicit (i atunci ele implic dependenele funcionale corespunztoare) sau pot fi deduse din mulimea dependenelor funcionale stabilite de proiectant, folosind algoritmi de gsire a cheilor din mulimea dependenelor funcionale. Un astfel de algoritm va fi prezentat ntr-o seciune urmtoare. Tipuri de dependene funcionale i atribute. Dependenele funcionale pot fi pariale sau totale. O dependen funcional XY este parial (partial dependency) dac exist o submulime proprie Z a mulimii X (adic Z X) care determin funcional pe Y (ZY). O dependen funcional XY este total (full dependency), dac nu exist nici o submulime proprie Z a lui X care s determine funcional pe Y. Din aceast definiie rezult c, dac atributul X este simplu, dependena funcional XY este total. Dependena funcional XY (unde X R, Y R) este satisfcut de orice relaie R dac Y X. O astfel de dependen funcional se numete dependen funcional trivial. Dac atributul (simplu sau compus) CK este o cheie candidat a relaiei R, atunci, conform proprietii de ireductibilitate a cheii candidate, dependena CKR este total, adic nu exist o submulime proprie CK a lui CK care s prezinte proprietatea CKR. Atributele care aparin unei chei se numesc atribute prime, iar celelalte se numesc atribute neprime.
Exemple de dependene funcionale. Se consider relaia AP definit mai sus, n care se pot stabili urmtoarele dependene funcionale, pe baza semnificaiei atributelor acesteia: a) IdAngajatNume b) IdAngajatPrenume c) IdAngajatAdresa d) {IdAngajat,IdProiect}Ore Aceste dependene funcionale specific faptul c identificatorul angajatului determin n mod unic numele, prenumele i adresa acestuia (dependenele a, b i c) i c numrul de identificare al angajatului i identificatorul proiectului determin n mod unic numrul de ore pe care le lucreaz respectivul angajat la acel proiect (dependena d). Cheia primar a relaiei {IdAngajat, IdProiect} poate fi definit explicit, sau poate fi dedus din dependenele funcionale de mai sus. 3.4.3. Prima form normal (FN1) O relaie este normalizat n prima form normal (FN1) dac fiecare atribut ia numai valori atomice i scalare din domeniul su de definiie. Caracterul de atomicitate se refer la faptul c valoarea unui atribut are semnificaie numai n ansamblul ei i nu permite descompunerea n componente care s poat fi manevrate separat. Chiar dac tipul de date peste care este definit domeniul unui atribut este reprezentat prin mai multe componente, acestea nu au semnificaie luate individual. Valoarea scalar a unui atribut se refer la faptul c un atribut nu poate avea dect o valoare (din domeniul de definiie pe care este definit) pentru fiecare tuplu. Sistemele SGBD relaionale nu admit relaii care s nu fie cel puin n prima form normal, dar proiectarea relaiilor normalizate n prima form normal este simpl i ntotdeauna posibil. 3.4.4. A doua form normal (FN2) O relaie este normalizat n a doua form normal (FN2) n raport cu o mulime de dependene funcionale F, dac este n FN1 i dac n F+ nu exist nici o dependen funcional parial a unui atribut neprim fa de o cheie a relaiei. Din aceast definiie rezult c, dac orice cheie a unei relaii este format dintr-un singur atribut, relaia este n FN2. Acest lucru este evident, deoarece orice dependen funcional fa de un atribut simplu este o dependen funcional total. De asemenea, este evident faptul c o relaie compus din dou atribute este n FN2, deoarece, fie cheia este format din ambele atribute i atunci nu exist atribute neprime, fie cheia este format dintr-unul din atribute iar dependena funcional a celuilalt atribut (care este atribut neprim) fa de cheie este total. Ca exemplu de normalizare n FN2, se va relua relaia AP prezentat la nceputul acestui capitol. Schema relaiei este: AP(IdAngajat, Nume, Prenume, Adresa, IdProiect, Ore), iar mulimea dependenelor funcionale FAP stabilite pe baza semnificaiei atributelor este cea specificat deja, adic:
FAP = {IdAngajatNume,IdAngajatPrenume, IdAngajatAdresa,{IdAngajat,IdProiect}Ore} Cheia primar este {IdAngajat,IdProiect} i se poate deduce din mulimea dependenelor funcionale. Aceast relaie este n FN1, deoarece toate atributele iau valori atomice i scalare. Atributele prime sunt IdAngajat, IdProiect iar atributele neprime sunt Nume,Prenume,Adresa,Ore. Pentru a verifica dac relaia este n FN2 trebuie s fie testat tipul dependenei funcionale (total sau parial) a fiecrui atribut neprim fa de cheia primar (care este singura cheie a relaiei n acest exemplu). Se va testa pentru nceput tipul dependenei funcionale a atributului Nume fa de cheia primar a relaiei, adic {IdAngajat,IdProiect}Nume. Aceast dependen exist n virtutea proprietii cheii primare. De altfel, ea se poate deduce din dependenele funcionale ale relaiei, prin aplicarea regulilor de inferen ale lui Armstrong. Conform proprietii de reflexivitate, exist dependena funcional {IdAngajat,IdProiect}IdAngajat, i aplicnd regula de tranzitivitate ntre aceast dependen funcional i dependena funcional IdAngajatNume, rezult {IdAngajat,IdProiect}Nume. Dependena funcional {IdAngajat,IdProiect}Nume este parial, datorit faptului c submulimea {IdAngajat} a atributului compus cheie primar determin funcional atributul Nume: IdAngajatNume. Rezult c relaia AP nu este n FN2. Redundana datelor i anomaliile de actualizare pe care acestea le produc au fost descrise la nceputul capitolului. Tot n aceast parte s-a artat c relaia AP se poate descompune n relaiile A(IdAngajat,Nume,Prenume,Adresa) i P(IdAngajat,IdProiect,Ore), care nu mai prezint redundan a datelor i anomalii de actualizare a tuplurilor. Pentru a determina proprietile acestei descompuneri se studiaz cele dou relaii rezultate A i P. Mulimea dependenelor funcionale din relaia A este FA=A(FAP)={IdAngajatNume, IdAngajatPrenume,IdAngajatAdresa}, din care se deduce cheia primar IdAngajat. n toate dependenele funcionale din FA atributele neprime Nume,Prenume,Adresa sunt total dependente fa de cheia primar a relaiei, deci relaia A este n FN2. Mulimea dependenelor funcionale din relaia P este FP = P(FAP) = {{IdAngajat,IdProiect} Ore}, din care se deduce cheia primar {IdAngajat,IdProiect}. n dependena funcional din FP atributul neprim Ore este total dependent fa de cheia primar a relaiei, deci relaia P este n FN2. n secinile anterioare s-a demonstrat c descompunerea relaiei AP n relaiile A i P are proprietatea de conservare a informaiei (seciunea 5.2.2.1) i proprietatea de conservare a dependenelor funcionale (seciunea 5.2.2.2), aadar aceast descompunere este o descompunere reversibil n relaii FN2. 3.4.5. A treia form normal (FN3) O relaie este normalizat n a treia form normal (FN3) n raport cu o mulime de dependene funcionale F dac este n FN2 i dac n F+ nu exist nici o dependen funcional netrivial a unui atribut neprim fa de alt atribut neprim al relaiei. Orice relaie format din dou atribute este n FN3 deoarece ea se afl n FN2 (s-a demonstrat n seciunea precedent), i nu poate exista nici un atribut neprim care s determine funcional
un alt atribut neprim, deoarece o relaie cu dou atribute nu poate avea dect cel mult un atribut neprim. Ca exemplu de normalizare a unei relaii n a treia form normal, se consider schema relaiei AFS(IdAngajat,Nume,Prenume,Adresa,Functie,Salariu), cu mulimea dependenelor funcionale FAFS = {IdAngajat Nume, IdAngajatPrenume, IdAngajatFunctie, FunctieSalariu}. Cheia primar a relaiei este atributul IdAngajat, i ea poate fi dedus din mulimea FAFS a dependenelor funcionale. Se consider c fiecare atribut ia numai valori atomice i scalare, deci relaia este n FN1. Primele patru dependene funcionale sunt dependenele funcionale totale ale unor atribute neprime fa de cheia primar a relaiei, deci relaia este n FN2. Dependena funcional (FunctieSalariu) semnific faptul c n instituia respectiv toi salariaii cu aceeai funcie au acelai salariu (adic funcia determin salariul, ceea ce este plauzibil). Aceast dependen funcional a atributului neprim Salariu fa de alt atribut neprim (Functie), arat c relaia nu este n a treia form normal (FN3). Chiar dac relaia AFS este n FN2, n aceasta nc mai exist redundan a datelor, deoarece valoarea salariului corespunztor unei funcii se nregistreaz de mai multe ori, pentru fiecare salariat care deine acea funcie. Aceast redundan provoac anomalii de inserare, tergere i actualizare a tuplurilor. De exemplu, nu se poate nregistra valoarea salariului corespunztor unei anumite funcii, dac nu se nregistreaz cel puin un salariat cu acea funcie. Aceasta este anomalia de inserare. Ca anomalie de tergere, se poate observa c, dac se terg tuplurile corespunztoare tuturor salariailor care dein o anumit funcie, atunci se pierde informaia referitoare la salariul corespunztor funciei respective. Anomalii de actualizare apar atunci cnd se actualizeaz valoarea salariului unui angajat: dac se modific salariul fr s se modifice corespunztor i funcia, atunci pot exista n relaie dou sau mai multe tupluri care au aceeai valoare a atributului Functie, dar valori diferite ale atributului Salariu, deci nu este respectat dependena funcional FunctieSalariu. Astfel de redundane i anomaliile de actualizare pe care le provoac se pot elimina dac se descompune relaia n dou (sau mai multe) relaii, care s nu conin date redundante. Relaia AFS se poate descompune n relaiile AF(IdAngajat,Nume, Prenume,Adresa,Functie) i FS(Functie,Salariu). Se poate verifica uor c fiecare din aceste relaii se afl n FN3. Dependenele funcionale ale relaiei AF reprezint proiecia dependenelor funcionale date iniial (FAFS) pe relaia AF: FAF = AF(FAFS)= {IdAngajatNume,IdAngajatPrenume,IdAngajatFunctie}. Cheia primar a relaiei AF este IdAngajat, i se poate deduce uor din dependenele funcionale ale relaiei AF (FAF). Se observ c toate dependenele funcionale ale relaiei AF determinate de cheia primar sunt totale i c nu exist nici o dependen a unui atribut neprim fa de alt atribut neprim, deci relaia AF este n FN3. Dependenele funcionale ale relaiei FS reprezint proiecia dependenelor funcionale date iniial (FAFS), pe relaia FS: FFS = FS(FAFS)={FunctieSalariu}. Cheia primar a relaiei este atributul Functie i se deduce cu uurin din mulimea FFS a dependenelor funcionale ale acestei relaii. Singura dependen funcional a relaiei FS este o dependen funcional total determinat de cheia primar a relaiei, deci relaia FS este n FN3. Pentru verificarea
proprietii de jonciune fr pierdere de informaie se calculeaz AF FS = {Functie} i FS AF = {Salariu}. Deoarece dependena funcional (FunctieSalariu)FAFS, rezult (conform teoremei lui Ullman) c descompunerea relaiei AFS n relaiile AF i FS este o descompunere fr pierdere de informaie la jonciune. Pentru verificarea conservrii dependenelor funcionale, se calculeaz mai nti reuniunea dependenelor funcionale ale relaiilor AF i FS: FAF FFS = {IdAngajatNume,IdAngajatPrenume, IdAngajatFunctie,FunctieSalariu} Se observ c FAFS = FAF FFS, deci descompunerea realizat conserv dependenele funcionale stabilite iniial. Aadar, descompunerea relaiei AFS n relaiile AF i FS are att proprietatea de conservare a informaiei ct i proprietatea de conservare a dependenelor funcionale, deci este o descompunere reversibil. S-a demonstrat c orice schem de relaie poate fi descompus reversibil n scheme de relaii FN3 i exist un astfel de algoritm de descompunere. 3.4.6 Forma nrmal Boyce-Codd (FNBC O relaie cu schema R este n forma normal Boyce-Codd (FNBC) n raport cu o mulime F de dependene funcionale dac este n FN1 i dac, pentru orice dependen funcional netrivial XY din F+, X este o cheie a relaiei R. Se poate observa asemnarea dintre formele normale FN3 i FNBC, ambele impunnd condiia ca atributul care determin funcional alte atribute s fie o cheie a relaiei. Forma normal Boyce-Codd este mai restrictiv dect FN3, deoarece n FNBC se impune aceast condiie tuturor atributelor, prime sau neprime, pe ct vreme n FN3 condiia se impune numai atributelor neprime. Este evident faptul c o relaie n FNBC este, de asemenea n FN3, dar o relaie n FN3 poate s fie sau nu n FNBC. Orice relaie format din dou atribute este n FNBC. Explicaia este similar cu explicaia dat pentru faptul c orice relaie format din dou atribute este n FN2 sau n FN3.
Capitolul 4 Baze de date distribuite Odat cu dezvoltarea reelelor de calculatoare, care promoveaz un mod de lucru descentralizat, o tendin vdit este utilizarea unor date n comun, accesul la unele date ndeprtate, estimarea unor indicatori din analiza mai multor baze de date diferite, separate una de alta, att logic ct i fizic. Aceast tratare descentralizat constituie o reflectare a structurii organizaionale a multor organizaii, care sunt distribuite logic n secii, departamente, proiecte i aa mai departe i fizic n birouri, fabrici i uzine unde fiecare unitate i ntreine propriile date operaionale [Connolly & alt, 2001]. Exist cteva elemente cheie care au motivat trecerea multor organizaii de la sistemele centralizate de baze de date la cele distribuite. n primul rnd, costurile de comunicaie sunt mai mici n sistemele distribuite, atta timp ct accesul la un calculator local este mai ieftin dect accesul la distan. Pe de alt parte, autonomia local reprezint unul dintre cele mai importante avantaje oferite de sistemele de baze de date distribuite. SBDD-ul (Sistem de Baze de Date Distribuit / DDS Distributed Database Systems) ofer sistemelor informaionale o serie de alte avantaje: permit managerilor locali libertatea de a manipula informaiile astfel nct s rezolve necesitile departamentului pe care l conduc, reduc impactul provocat de eventualele cderi ale echipamentului. De asemenea, prin crearea unor baze de date mai mici, la diferite locaii, se asigur prevenirea pierderii datelor. n luarea deciziei de trecere de la un sistem centralizat de baze de date la un SBDD, organizaiile trebuie s analizeze i dezavantajele prezentate de sistemele distribuite. Dac structura organizaiei i stilul de management sunt centralizate, atunci implementarea unui SBDD nu-i are rostul. Costurile de reciclare a personalului i cele pentru achiziionarea software-ului adecvat pot s fie att de ridicate nct, mai ales pentru organizaiile mici, modificarea sistemului informatic s nu fie justificat din punct de vedere economic. De asemenea, SBDD pot ridica att probleme de sincronizare, de consistent i integritate a datelor, ct i probleme legate de controlul accesului. Sistemele de baze de date distribuite au aprut la grania dintre dou domenii aparent opuse din punct de vedere al procesrii datelor: sisteme de baze de date i reele de calculatoare. Transformarea unui sistem centralizat de baze de date ntr-un sistem distribuit const n scindarea bazei de date centralizate n fragmente corespunztoare i repartizarea acestor fragmente n nodurile reelei. Este important ca principiul fundamental al SBDD s fie respectat: Utilizatorul trebuie s vad un sistem distribuit exact ca pe un sistem nedistribuit. Scindarea bazei de date se realizeaz doar la nivel fizic, la nivel logic ea rmne centralizat. Software-ul SGBD (Sistem de Gestiune a Bazelor de Date) evolueaz n permanen. De-a lungul anilor s-a trecut de la bazele de date ierarhice la cele normalizate, de la centralizare la distribuire, fiecare dintre aceste etape implicnd concepte suplimentare de descriere, stocare i regsire a datelor. Dac structurile de date pot s par naturale unui specialist, nu acelai lucru trebuie presupus i pentru utilizatorul obinuit. n realizarea unui sistem de baze de date, distribuit sau nu, este esenial caracterul prietenos pe care acesta trebuie s l prezinte utilizatorului final.
Realizarea sistemului distribuit implic luarea de decizii n ceea ce privete plasarea datelor i a programelor peste nodurile reelei de calculatoare. n cazul SBDD, distribuia aplicaiei presupune att distribuia software-lui SGBD ct i distribuia programelor de aplicaie care vor rula pe acest software. n ceea ce privete softul SGBD, se presupune c exist o copie a acestuia n fiecare nod al reelei. Din punct de vedere al proiectrii SBDD, ceea ce intereseaz este distribuia programului aplicaie. Dac se consider c reeaua de calculatoare este deja proiectat, realizarea sistemului distribuit de baze de date revine la rezolvarea a dou etape: proiectarea bazelor de date distribuite i procesarea distribuit a cererilor. Majoritatea SBDDurilor actuale satisfac urmtoarele trei cerinei: Fiecare nod al reelei este un calculator care execut att aplicaii program ct i funcii de management a bazelor de date distribuite. Reeaua de calculatoare poate s fie de tip LAN sau WAN. Gestiunea bazelor de date se bazeaz pe modelul relaional. 4.1. Concepte specifice bazelor de date distribuite O baz de date distribuit (BDD Distributed Database / Baz de Date Distribuit) reprezint o colecie intercorelat logic de date partajate (i o descriere a acestora), distribuite din punct de vedere fizic ntr-o reea de calculatoare [Connolly & alt, 2001], sau o baz de date distribuit este definit drept o colecie de mai multe baze de date logic interconectate i care sunt dispersate ntr-o reea de calculatoare. BDD = baze de date + calculatoare + reea de calculatoare Un sistem de baze de date distribuite (SBDD) reprezint o colecie de baze de date logic interconectate dispersate ntr-o reea de calculatoare i administrate de ctre un sistem de gestiune a bazei de date distribuite: SBDD = baze de date + calculatoare + reea de calculatoare + sistem de gestiune a bazei de date distribuite sau SBDD = BDD + SGBDD i n care: sistemul bazei de date gestioneaz datele; reeaua de calculatoare face posibil comunicaia; sistemul de gestiune a baze de date distribuite reprezint software-ul care realizeaz mecanismele i politicile de manipulare a datelor distribuite. n cele mai multe situaii, un sistem de baze de date distribuit const din mai multe sisteme de baze de date i dintre acestea majoritatea sunt sisteme de baze de date relaionale. Un sistem de gestiune a bazelor de date distribuit (SGBDD, DDMS Distributed Database Management System) este sistemul software care permite gestionarea bazei de date distribuite i face ca distribuirea s fie transparent pentru utilizatori [Connolly & alt, 2001], iar Mauricio A. Hernandez definete un SGBDD astfel: o colecie de site-uri interconectate, fiecare pstrnd un sistem de baze de date local. Un sistem de gestiune a bazelor de date distribuite const dintr-un set de noduri (site-uri), conectate ntre ele printr-o reea de comunicaii, n care:
Fiecare nod are (sau nu) bazele sale de date proprii utilizatorilor locali, un sistem de gestiune a bazelor de date propriu i software-ul necesar lucrului cu baza de date. Pentru a avea acces la datele stocate n aceste baze de date, utilizatorii folosesc diferite aplicaii. Aplicaiile sunt clasificate n funcie de necesitile cerute n prelucrarea datelor; astfel vom avea aplicaii locale, caz n care prelucrarea datelor necesit accesul la bazele de date locale i, aplicaii globale, caz n care prelucrarea datelor necesit accesul la bazele de date aflate la distan, n alte noduri. Un SGBDD trebuie s conin cel puin o aplicaie global. Nodurile au posibilitatea s lucreze mpreun (dac este necesar), astfel nct un utilizator din orice nod al reelei poate accesa datele de oriunde din reea ca i cum datele s-ar afla pe nodul su propriu.
De aici rezult c aa numita baz de date distribuit este n esen o baz logic (virtual), ale crei pri se regsesc ntr-o serie de baze de date reale aflate pe diferite noduri ale reelei de calculatoare. Practic ea este imaginea logic a tuturor acestor baze de date reale. n acest fel un sistem de gestiune a bazelor de date distribuite poate fi privit ca o modalitate de conlucrare comun a diferitor SGBD-uri, situate pe diferite noduri locale separate, unde o component software nou pe fiecare nod posed toate funciile lucrului n comun, adic este o continuitate logic a bazei de date locale.
Fig. 4.1. Arhitectura unui sistem de baze de date distribuit De cele mai multe ori se presupune c nodurile sunt desprite fizic i geografic, dup cum este indicat n figura 4.1, cu toate c n realitate este de ajuns ca ele s fie desprite logic. Cu toate acestea este permis ca dou noduri s fie situate pe acelai calculator, mai ales n timpul elaborrii i testrii sistemului. n ultimii ani sensul conceptului de baz de date distribuit s-a schimbat uor. Primele sisteme comerciale distribuite foloseau o distribuire local cu mai multe noduri, amplasate n una i aceeai cldire, unite ntre ele printr-o reea de calculatoare local. ns, din punct de vedere al bazelor de date distribuite, ntre aceste dou modaliti nu exist diferenieri substaniale, deoarece n ambele cazuri este necesar s se soluioneze aceleai probleme tehnice i logice. De aceea situaia prezentat n figura 4.1 poate fi analizat ca o situaie tipic a unui sistem de baze de date distribuite. Sintetiznd cele prezentate, se poate spune c un SGBDD are urmtoarele caracteristici [Connolly & alt, 2001]: Conine o colecie de date partajate corelate logic.
Datele sunt divizate ntr-un numr de fragmente. Fragmentele pot fi reproduse. Fragmentele / reproducerile sunt alocate nodurilor. Nodurile sunt legate printr-o reea de comunicaii. Datele din fiecare nod se afl sub controlul unui SGBD. SGBD-ul din fiecare nod poate trata autonom aplicaiile locale. Fiecare SGBD particip la cel puin o aplicaie global.
i urmtoarele obiective [Velicanu & al, 1998]: Asigurarea unei redundane minime i controlate. Asigurarea unor faciliti de utilizare. Asigurarea securitii datelor. Asigurarea coerenei i integritii datelor. Asigurarea portabilitii datelor. Asigurarea administrrii i controlului datelor. Nu trebuie uitat principul fundamental al unui SGBDD, i anume transparena fa de utilizator, care face ca sistemul distribuit s apar drept un sistem centralizat pentru utilizatorii acestuia. Cu toate c teoria bazelor de date distribuite menioneaz c SGBD-urile aflate pe nodurile reelei pot fi de diferite tipuri, n practic de cele mai multe ori se ntlnesc sisteme cu acelai tip de SGBD. Acestea sunt de preferat din cauza simplificrii problemei de comunicaie i a compatibilitii ntre SGBD-uri. Astfel de sisteme, care utilizeaz acelai tip de SGBD se numesc sisteme omogene (sau unigene). Sistemele omogene sunt cel mai uor de proiectat i gestionat, adugarea unui nou nod n sistemul SGBDD se face uor i de asemenea, au mai multe proprieti fa de sistemele distribuite obinuite din mai multe motive: Compatibilitate n comunicaie de cele mai multe ori SGBD-urile avansate au o variant proprie de comunicare ntre ele, cu toate c exist anumite standarde special elaborate pentru a soluiona aceste probleme, ca de exemplu SQL. n multe cazuri, din interese comerciale i eficacitate n lucru cu baza de date, productorii de SGBD-uri i creeaz un limbaj propriu, derivat de la cel standard, care posed un ir de caracteristici mbuntite. De exemplu, Oracle a elaborat PLSQL, InterBase a elaborat SCSQL, sau Microsoft a elaborat MSSQL (toate aceste variante sunt compatibile cu standardul de baza SQL, sau SQL92). Concept de abordare cu toate c teoria bazelor de date are una i aceeai ideologie n conceptul bazei de date, mecanisme de abordare i lucru, multe SGBD-uri actuale au variante proprii de abordare i lucru cu baze de date. De exemplu, InterBase are drept concept tratarea multiversional a bazei de date, metodologie care n Oracle sau Microsoft SQL Server nu este prezent, sau invers Oracle posed funcii avansate statistice, pe care InterBase nu le posed, ns pot fi incluse prin definirea unui UDF (User Defined Function). Toate aceste diversificaii ngreuneaz cu mult elaborarea unui produs software care ar asigura lucrul sincron distribuit al diferitor SGBD-uri, cu toate c teoria bazelor distribuite accept acest fapt i analizeaz problemele ce pot aprea la proiectarea unei astfel de baze distribuite numai la nivel logic, n practic o pondere destul de mare n reuita proiectului o au i problemele fizice i specifice pe care le are fiecare SGBD n parte.
Al doilea tip de SGBDD-uri sunt sistemele eterogene. ntr-un astfel de sistem nodurile pot utiliza SGBD-uri de tipuri diferite, care nu sunt necesare s se bazeze pe acelai model de date, astfel putem avea SGBD-uri: relaionale, ierarhice, n reea, orientate obiect. Aceste sisteme eterogene apar de obicei atunci cnd este avut n vedere integrarea SGBD-urilor ntrun singur SGBD, sau are loc ntr-o etap ulterioar proiectrii SGBD-urilor de pe nodurile individuale. n acest caz nodul de la care se pot cere date poate avea: Elemente hardware diferite. Deoarece produsele SGBD sunt aceleai, traducerea este direct i presupune modificarea codurilor i lungimii cuvintelor. Produse SGBD diferite. n acest caz traducerea este complicat i presupune transformarea structurilor de date dintr-un model de date n structurile de date echivalente din alt model de date. De exemplu, relaiile din modelul de date relaional sunt transformate n nregistrrile i mulimile caracteristice modelului n reea. De asemenea, este necesar s se traduc limbajul de interogare utilizat (de exemplu, instruciunile SELECT din limbajul SQL sunt transformate n instruciunile FIND i GET utilizate n cadrul reelelor). Elemente hardware i produse SGBD diferite. n acest caz sunt necesare cele dou tipuri de traduceri anterioare, ceea ce face ca prelucrarea s fie destul de complex. Soluia tipic utilizat n cadrul unor sisteme relaionale care fac parte dintr-un SGBDD eterogen const n utilizarea unor pori, care transform limbajul i modelul fiecrui SGBD n limbajul i modelul sistemului relaional.
4.2. Avantajele i dezavantajele sistemelor bazelor de date distribuite Cele trei caracteristici care au influenat sistemele de baze de date distribuite sunt: Sistem distribuit (hardware/software). Astzi, majoritatea sistemelor de calcul sunt conectate prin intermediul reelelor, deci lucreaz ntr-un mediu distribuit. De aici rezult necesitatea existenei unui sistem de baze de date distribuit care s fie capabil s coordoneze activitatea resurselor distribuite. Aplicaie distribuit. Din ce n ce mai multe aplicaii sunt distribuite. De exemplu: sistemul bancar, sistemul de eviden al unei societi cu mai multe puncte de vnzri, etc. Deci se impune necesitatea existenei unui SBDD care s poat suporta astfel de aplicaii. Date distribuite. Majoritatea datelor utilizate sunt distribuite, deci se impune necesitatea existenei unui SBDD capabil s administreze aceste date distribuite. Fa de sistemele tradiionale de gestiune a bazelor de date, SBDD-urile prezint unele avantaje i dezavantaje, printre care se enumer: Avantaje: Structura organizatoric. n cazul n care organizaia i are filialele, birourile dispersate din punct de vedere geografic n mai multe locuri, este natural ca bazele de date utilizate ntr-o astfel de aplicaie s fie distribuite ntre aceste locuri. Astfel, este indicat ca fiecare filial s-i ntrein propria baz de date, asupra creia personalul din cadrul filialei va putea efectua interogri, numite interogri locale. Cu toate acestea, conducerea organizaiei are nevoie, pentru luarea anumitor decizii, s efectueze interogri globale, care presupun accesul la
datele din toate filialele organizaiei, sau numai dintr-un numr oarecare de filiale. Caracterul partajabil i autonomia local. n cazul n care nodurile din cadrul organizaiei utilizeaz un acelai set de date, este indicat ca datele s fie stocate n cel mai apropiat nod la reelei, la care au acces toate celelalte noduri care doresc s efectueze interogri. n acest fel, utilizatorii dein un control local asupra datelor i pot stabili i impune politici locale referitoare la utilizarea acestora. n acest caz este necesar prezena unui administrator general al bazei de date, care s rspund de ntreg sistemul existent. Disponibilitate crescut. Se refer la faptul c dac un nod al reelei cade, din diferite motive (o pan a unui nod, sau al unei linii de comunicaie), celelalte noduri pot fi n continuare utilizate, fr a ntrerupe funcionarea sistemului. Acest lucru este posibil datorit faptului c sistemul are capacitatea de a redirija ctre un alt nod cererile care sunt adresate nodului aflat n pan. Fiabilitate crescut. Datorit faptului c datele pot fi reproduse astfel nct acestea pot exista n mai multe noduri ale reelei, pana unui nod sau a unei linii de comunicaie nu afecteaz accesul la acele date care existau pe nodul respectiv. Performan mbuntit. Viteza de acces la date este mbuntit fa de o baz de date centralizat aflat la distan, datorit faptului c datele sunt amplasate n apropierea nodului cu cea mai mare cerere. Economie. Se refer la costurile necesare construirii, mbuntirii i ntreinerii unui sistem mainframe fa de un sistem distribuit. Dezvoltare modular (extensibilitate). ntr-un SGBD centralizat, dezvoltarea acestuia poate necesita att modificri din punct de vedere hardware, ct i din punct de vedere software. ntr-un SGBD distribuit acest lucru este mult mai uor de realizat prin adugarea unui nou nod, a mai multor staii de lucru i servere i care nu afecteaz celelalte noduri.
Dezavantaje: Complexitatea: se refer la multitudinea de evenimente care au loc n mod simultan atunci cnd se lucreaz cu un sistem de baze de date distribuit. Costul: n general va fi nevoie de un cost iniial pentru a schimba un sistem centralizat ntr-un sistem distribuit i apoi pentru a dezvolta i a menine reeaua de calculatoare. Securitatea: este mult mai dificil meninerea securitii ntr-un mediu distribuit dect ntr-un mediu centralizat. Controlul integritii este mai dificil. Lipsa de experien i de standarde. Standardele care au stat la baza dezvoltrii SGBDD-urilor sunt: X.25 realizat de CCITT, care se conformeaz celor trei straturi inferioare ale arhitecturii ISO/OSI. Majoritatea SGBDD-urilor au fost dezvoltate pe baza acestui standard. RDA (Remote Database Access - ISO, 9579) - standard pentru straturile superioare ale modelului ISO/OSI, care ar putea furniza servicii utile pentru SGBDD. DTP (Distributed Transaction Processing ISO, 10026) cu varianta X/Open DTP. Complexitatea proiectrii bazei de date.
4.3. Funciile unui sistem de gestiune a bazelor de baze distribuite nainte de a trece la modalitile de proiectare efectiv a unui SGBDD, vom trece n revist funciile i diferitele tipuri de arhitecturi SGBDD. n subcapitolul 1.5 s-au enumerat cele opt obiective pe care un SGBD trebuie s le furnizeze utilizatorilor. n afara acestor opt obiective, un SGBD mai trebuie s asigure i urmtoarele dou obiective: 1. Servicii pentru promovarea independenei de date un SGBD trebuie s includ faciliti pentru susinerea independenei programelor fa de structura real a bazei de date. 2. Servicii utilitare - un SGBD trebuie s ofere un set de servicii utilitare. Aceste servicii utilitare ajut personalul de administrare a bazei de date s administreze efectiv baza de date: faciliti de import, faciliti de reorganizare a indexurilor etc. n plus, fa de aceste obiective, un SGBDD trebuie s mai asigure: 1. Servicii de comunicaie extinse un SGBDD trebuie s asigure accesul la nodurile ndeprtate i s permit transferul de interogri i date ntre nodurile care utilizeaz o reea. 2. Un catalog al sistemului extins - un SGBDD trebuie s asigure un catalog extins, care s conin detaliile referitoare la distribuia datelor. 3. Prelucrarea interogrilor extins un SGBDD trebuie s asigure optimizarea interogrilor i accesul la datele ndeprtate. 4. Un control al concurenei extins un SGBDD trebuie s menin coerena datelor reproduse. 5. Servicii de refacere extinse pentru a lua n considerare penele nodurilor individuale i penele legturilor de comunicaie. 4.4. Arhitectura unui SGBDD Pentru implementarea sistemelor de gestiune a bazelor de date sunt utilizate mai multe tipuri de arhitecturi, dintre care cele mai folosite sunt: Teleprocesarea reprezint arhitectura tradiional pentru sistemele multiutilizator la care exist un calculator cu o singur unitate central i un numr de terminale. Arhitectura file server ntr-o astfel de arhitectur procesarea este distribuit n reea. SGBD-ul de pe fiecare calculator trimite serverului de fiiere cererile pentru toate datele necesare, care sunt stocate pe disc. Arhitectura client/server se refer la modul n care interacioneaz componentele software pentru a forma un sistem. n cazul acestei arhitecturi exist un proces client, care necesit cteva resurse i un server, care ofer resurse. n contextul bazelor de date, clientul administreaz interfaa cu utilizatorul i logica aplicaiei, acionnd ca o staie de lucru sofisticat, pe care sunt executate aplicaiile bazei de date. Cu toate c aceast arhitectur poate fi utilizat pentru a oferi SGBDD-uri, totui ea nsi nu constituie un SGBDD. Aceast arhitectur, la rndul ei, este: pe dou niveluri scindeaz funcionalitatea clientului lrgit n dou; pe trei niveluri n cadrul acestei arhitecturi clientul restrns manevreaz numai interfaa cu utilizatorul, n timp ce stratul de mijloc manevreaz logica aplicaiilor (arhitectura ANSI-SPARC cu trei niveluri). Al treilea nivel l constituie serverul bazei de date. Aceast arhitectur este utilizat n
mediul Internet i reelele intranet ale companiilor, unde un browser Web poate fi utilizat drept client. Arhitectura de referin standard pentru un SGBDD (figura 4.2.) este format din: Un set de scheme externe globale, care furnizeaz independena logic de date. O schem conceptual global reprezint o descriere logic a ntregii baze de date, ca i cum nu ar fi distribuit. Aceast schem conine definiiile entitilor, relaiilor, constrngerilor, informaii privind securitatea i integritatea datelor. O schem de fragmentare constituie o descriere a modului n care vor fi partiionate logic datele. O schem de alocare constituie o descriere a locului unde vor fi localizate datele i ine cont de toate reproducerile.
Fig. 4.2. Arhitectura de referin pentru un SGBDD
Un set de scheme locale pentru fiecare SGBD local care se conformeaz arhitecturii ANSI-SPARC cu trei niveluri. Schemele conceptuale i interne locale corespund nivelurilor echivalente din arhitectura ANSI-SPARC cu trei niveluri, iar schemele de transformare locale realizeaz o coresponden ntre fragmentele din schema de alocare i obiectele externe din baza de date local. Schema local are rolul de a realiza legtura dintre imaginea fizic i datele locale i ea depinde de tipul SGBD-ului local. SGBD-ul local implementeaz schema local i are rolul de a descrie i gestiona datele de pe calculatorul local respectiv. La nivel local, toate SGBD-urile utilizate pot fi de acelai tip (cazul sistemelor omogene) sau de tipuri diferite (cazul sistemelor eterogene). Baza de date local conine toate datele alocate conform imaginilor fizice i ea este organizat
dup un model de date acceptat de SGBD-ul local utilizat. Schema de transformare local este independent de SGBD i constituie baza pentru susinerea SGBD-urilor eterogene. n cazul sistemelor distribuite, arhitectura ANSI este conceput binivel: un nivel global i un nivel local.
Fig. 4.3. Arhitectura ANSI pentru sistemele distribuite n aceast arhitectur de SGBDD exist un singur nod la nivel global i mai multe noduri la nivel local. Nodul global al unui SGBDD are rolul de a asigura o tratare de ansamblu a BDD. Aici sunt integrate unitar toate datele din BD locale, iar integrarea se realizeaz cu ajutorul celor trei tipuri de scheme care sunt implementate de SGBDD la nivel global: schema global, schema de fragmentare i schema de alocare. Nivelul local al unui SGBDD reunete toate BD locale distribuite pe calculatoarele din reea. Fiecare din aceste BD este tratat ca fiind centralizat cu ajutorul a trei componente: schema local, SGBD-ul local i BD propriu zis local. n afara unei arhitecturi de referin, un SGBDD mai prezint i o arhitectur a componentelor, care n general este format din patru pri:
Componenta SGBD-ului local (SGBDL) este reprezentat de un SGBD standard, responsabil de controlul datelor locale din fiecare nod care are o baz de date. SGBDurile locale sunt cele care descriu i manipuleaz datele din bazele de date care exist pe staiile locale din nodurile reelei de calculatoare. Ele pot fi de tipuri diferite sau de acelai tip. De asemenea, dac sunt de acelai tip, pot fi acelai produs sau produse diferite (Oracle sau Informix) [Velicanu & al, 1998]. Componenta de comunicaie de date (CD) este reprezentat de totalitatea programelor care permit comunicarea ntre toate nodurile reelei. Catalogul global al sistemului (CGS) are acelai rol ca i catalogul sistemului dintr-un sistem centralizat. n acest catalog se pstreaz informaii specifice naturii distribuite a sistemului (schemele de fragmentare i de alocare). Componenta SGBD-urilor distribuite (SGBDD) reprezint unitatea de control a ntregului sistem. SGBDD-ul este un sistem software complex care asigur gestionarea bazei de date distribuit n mai multe noduri ale reelei de calculatoare. El realizeaz accesarea datelor n urma unor cereri de regsire formulate de diferii utilizatori. De asemenea, SGBDD creeaz i ine la zi un dicionar de date global, care, ca orice dicionar de date, conine informaii, dar, de aceast dat, despre baza de date distribuit. Informaiile pot fi consultate de orice utilizator i se refer la: structura, distribuirea (localizarea), accesibilitatea i modul de utilizare a datelor din BDD.
Fig. 4.4. Arhitectura componentelor unui SGBDD
4.5. Proiectarea bazelor de date distribuite Se tie c un sistem informaional cuprinde totalitatea resurselor care permit colectarea, administrarea, controlul i propagarea informaiilor n ntreaga organizaie. Atunci cnd prelucrarea se efectueaz prin intermediul calculatoarelor, acest sistem va cuprinde urmtoarele componente: Baza de date. Elementele software ale bazei de date. Software de aplicaie. Elementele hardware ale calculatorului. Personalul care utilizeaz i dezvolt sistemul. Dintre aceste componente baza de date constituie componenta fundamental a sistemului informaional, iar dezvoltarea i utilizarea sa trebuie privite din perspectiva cerinelor mai largi ale organizaiei. Prin urmare, ciclul de via al unui sistem informaional al unei organizaii este inerent legat de ciclul de via al sistemului de baze de date care l susine i de asemenea, ciclul de via al aplicaiei de tip baz de date este inerent legat de ciclul de via al sistemului informaional. Etapele principale ale ciclului de via al unei aplicaii de tip baz de date sunt [Connolly & alt, 2001]: Planificarea bazei de date. Definirea sistemului. Colectarea i analiza cerinelor. Proiectarea bazei de date. Alegerea sistemului SGBD (opional). Proiectarea aplicaiei. Realizarea prototipului (opional). Implementarea. Conversia i implementarea datelor. ntreinerea operaional.
Etapa de proiectare a bazei de date reprezint procesul de realizare a unui proiect pentru o baz de date, care va trata toate operaiile i obiectivele organizaiei. Scopurile acestei etape sunt: Reprezentarea datelor i a relaiilor dintre ele, necesare tuturor domeniilor de aplicaie i grupurilor de utilizatori principali. Furnizarea unui model de date care s accepte efectuarea oricrei tranzacii necesare asupra datelor. Specificarea unui proiect minimal, structurat n mod adecvat pentru realizarea cerinelor stabilite privind performanele sistemului, cum ar fi timpul de rspuns. Construirea unei BDD presupune: 1. Proiectarea schemei globale. 2. Proiectarea schemei fizice. 3. Proiectarea fragmentrii. 4. Proiectarea alocrii. Tehnica de abordare a proiectrii globale i fizice a BDD este asemntoare cu cea utilizat n cazul BD centralizate. Specific BDD sunt problemele legate de proiectarea fragmentrii i alocrii datelor. n proiectarea unui SBDD se pot utiliza mai multe tipuri (strategii) de abordri dintre care cele mai cunoscute sunt: Proiectare de jos n sus (bottom-up sau ascendent), care ncepe prin definirea atributelor, a asociaiilor dintre atribute, i n final gruparea acestora n entiti, i se bazeaz pe integrarea schemelor BD existente ntr-o singur schem global [Lungu & al, 1995]. Un astfel de tip de abordare este reprezentat de procesul de normalizare. Normalizarea implic identificarea atributelor necesare i plasarea lor n tabele normalizate, bazate pe dependenele funcionale dintre atribute. Acest tip de proiectare a unui sistem de baze de date este indicat n proiectarea unor baze de date simple, cu un numr relativ mic de atribute. n general se pornete de la bazele de date existente care sunt apoi grupate ntr-un SBDD, fiind strategia utilizat n proiectarea celor mai multe aplicaii reale care necesit utilizarea BDD. Integrarea bazei de date reprezint procesul proiectrii schemei conceptuale globale din bazele de date participante i include: schema de translatare; schema de integrare.
Fig. 4.5. - Strategia de proiectare bottom-up
Proiectare de sus n jos (top-down sau descendent), este indicat n proiectarea unor aplicaii de tip baze de date distribuite complexe. Acesta ncepe cu realizarea unor modele de date, care conin cteva entiti i relaii de nivel nalt, dup care se aplic rafinri succesive de sus n jos, pentru a identifica entitile, relaiile i atributele asociate de nivel jos. Acest tip de abordarea este specific modelului Entitate Relaie, care ncepe cu identificarea entitilor i relaiilor dintre ele care prezint interes pentru organizaie. n cazul BDD ncepe cu proiectarea schemei globale urmat de proiectarea fragmentrii i apoi de alocarea fragmentelor la nodurile reelei. Proiectarea este completat prin realizarea la fiecare nod a structurii fizice a datelor care sunt alocate [Lungu & al, 1995].
Fig. 4.6. Strategia de proiectare top-down La rndul ei etapa de proiectare a bazei de date cuprinde trei faze principale: 1. Proiectarea conceptual reprezint procesul de construire a unui model al informaiilor utilizate n cadrul unei organizaii, independent de toate consideraiile fizice. Aceast faz este complet independent de detaliile de implementare (elementele software ale SGBD-ului, programe de aplicaii, limbaje de programare, platforma hardware etc.). 2. Proiectarea logic reprezint procesul de construire a unui model al informaiilor utilizate n cadrul unei organizaii, bazat pe un anumit model de date, dar independent de un anumit SGBD i de alte consideraii fizice. 3. Proiectarea fizic reprezint procesul de realizare a unei descrieri a implementrii bazei de date ntr-o capacitate de stocare secundar; descrie structurile de stocare i metodele de acces utilizate pentru realizarea unui acces eficient la date. Problema proiectrii bazelor de date distribuite (sau, n ali termeni, cum vor fi plasate bazele de date i aplicaiile n nodurile reelei), prezint fa de bazele de date relaionale o serie de factori suplimentari i anume: fragmentarea bazelor de date, adic descompunerea relaiilor iniiale n subrelaii, denumite fragmente, care apoi sunt distribuite n nodurile reelei utiliznd
o metod de alocarea acestor fragmente, reproducerea, utilizat pentru a se pstra o copie a unui fragment n mai multe noduri diferite ale reelei i transparena distribuiei. Definirea i alocarea fragmentelor trebuie s se bazeze pe modul n care va fi utilizat baza de date, operaie ce presupune analiza celor mai importante aplicaii (i nu a tuturor aplicaiilor ce necesit acces la baza de date) ce utilizeaz baza de date respectiv. De asemenea, este necesar ca proiectarea s se bazeze att pe informaii cantitative, ct i calitative. De exemplu, informaiile cantitative care sunt utilizate n alocarea fragmentelor n nodurile reelei, pot cuprinde informaii referitoare la: Frecvena cu care o aplicaie este rulat. Nodul de la care este rulat o aplicaie. Criteriile privind performanele tranzaciilor i aplicaiilor. Informaiile calitative care sunt utilizate n fragmentare, se pot referi la: Tranzaciile care sunt executate de ctre aplicaie (relaiile, atributele i tuplurile accesate). Tipurile de acces (citire sau scriere) etc. Fragmentarea Definirea fragmentelor n bazele de date distribuite se realizeaz conform unor reguli similare cu cele pentru definirea relaiilor virtuale (view) n bazele de date centralizate. Mai mult dect att, datele replicate pot fi tratate n acelai mod. ntrebrile la care trebuie s se rspund pentru a realiza o fragmentare ct mai bun sunt: de ce s fragmentm?, cum fragmentm, ct de mult fragmentm? i cum putem verifica corectitudinea fragmentrii?. Rspunsurile la aceste ntrebri depind n general de aplicaie. Argumentul esenial n favoarea fragmentrii const n posibilitatea execuiei unor operaii n paralel, pe diverse fragmente. Deci, fragmentarea crete concurena. Exist i argumente mpotriva fragmentrii, i acestea se refer la problemele de control semantic i de integritate a datelor. Operaia de fragmentare const n descompunerea logic a coleciilor globale, dintr-o BDD, n pri disjunctive numite fragmente [Velicanu & al, 1998]. Deoarece elementul de baz constructiv al BDR este relaia (tabela), poate aprea tentaia de a considere c unitatea de distribuie trebuie s fie tot relaia. n realitate, aceste relaii sunt supuse unui proces de fragmentare, din mai multe motive: Unitatea de distribuie relaiile sunt n mod normal prea mari pentru distribuie i din acest motiv se utilizeaz fragmente ale acestora. n plus, majoritatea aplicaiilor lucreaz mai mult cu vederi, dect cu relaii ntregi. n consecin, rezult c pentru distribuirea datelor este mai bine s se utilizeze subseturi ale relaiilor ca unitate de distribuire. Vederi diferite ale datelor o tabel poate fi vizualizat n mod difereniat de utilizatori diferii i de programe de aplicaie diferite. Concurena (paralelismul) fragmentele pot fi accesate de mai muli utilizatori i de mai multe programe de aplicaie n acelai timp. Cu fragmentele ca unitate de distribuire, o tranzacie poate fi mprit n mai multe subinterogri, care opereaz asupra fragmentelor. Aceasta trebuie s aib ca efect mrirea gradului de concuren din
sistem, permindu-se executarea n siguran a tranzaciilor care pot fi executate n paralel. Eficiena datele trebuie stocate n apropierea locului unde acestea sunt cel mai des utilizate; datele care nu sunt utilizate de aplicaiile locale nu trebuie stocate n nodul respectiv al reelei. Securitatea datele care nu sunt necesare pentru aplicaiile locale nu sunt stocate i, n consecin, nu sunt disponibile pentru utilizatorii neautorizai.
Cu toate acestea, fragmentarea prezint dou dezavantaje principale: Performanele atunci cnd o aplicaie utilizeaz date din mai multe fragmente, situate n noduri diferite, performanele acesteia sunt sczute. Integritatea la fel ca i la performane, controlul integritii poate fi mai dificil, atunci cnd datele utilizate fac parte din fragmente diferite, situate n noduri diferite. Al doilea pas n proiectarea bazelor de date distribuite const n alocarea fragmentelor n nodurile reelei. n cazul n care alocarea se realizeaz conform modelului partiionat, procesarea cererilor este dificil dar controlul concurenei este relativ uor de realizat. Alternativa replicrii totale conduce la o procesare uoar a cererilor, dar controlul concurenei este moderat.
Alocarea Pentru amplasarea datelor n nodurile reelei exist patru tipuri de modele i anume: modelul de alocare centralizat, modelul de alocare partiionat i modelul de alocare prin reproducere (sau replicare) cu dou variante: reproducere complet i reproducere selectiv. Alocarea centralizat, numit i prelucrare distribuit, presupune existena unei singure baze de date i a unui singur SGBD, ambele stocate ntr-un singur nod al reelei, iar utilizatorii distribuii de-a lungul reelei. Alocarea partiionat (fragmentat, sau total nereplicat) presupune mprirea (partiionarea) bazei de date n fragmente disjuncte, fiecare fragment fiind atribuit unui nod diferit al reelei. Dac distribuia este corect efectuat atunci caracterul local al referinei este ridicat (datele sunt plasate n nodul n care sunt utilizate cel mai frecvent), iar costurile de comunicaie sczute. Reproducerea complet, numit i modelul de alocare total replicat, const n pstrarea unei copii a bazei de date n cadrul fiecrui nod al reelei. n cadrul acestei strategii de alocare, caracterul local al referinei, fiabilitatea, disponibilitatea i performanele sunt cele mai ridicate; tot ridicate sunt i costurile ocazionate de stocarea datelor, i cele de comunicaie. O soluie frecvent utilizat, pentru a diminua din aceste efecte, este instantaneul (reprezint o copie a datelor la un moment dat). De asemenea, instantaneele sunt uneori utilizate pentru a implementa vederi ntr-o baz de date distribuit, cu scopul de a mbunti timpul necesar efecturii unei operaii de tip baz de date ntr-o vedere. Reproducerea selectiv, numit i modelul de alocare parial replicat, reprezint o combinaie ntre primele trei strategii: centralizat, partiionat i reproducere complet. Baza de date este mprit n fragmente disjuncte, care apoi sunt stocate n mai multe noduri ale reelei, dar nu n toate. Aceasta este metoda cea mai utilizat, datorit flexibilitii sale.
n ceea ce privete bazele de date replicate (total sau parial) s-au dezvoltat dou mecanisme fundamentale de replicare i anume: dinamic, respectiv static. O comparaie a metodelor de alocare a datelor este ilustrat n tabelul urmtor [Connolly & alt, 2001]: Centralizat Caracterul local al referinei Fiabilitatea i disponibilitate Performanele Costurile de stocare Costurile de comunicaie Cel mai sczut Cele mai sczute Partiionat nalt* Reproducere complet Cel mai ridicat Cele mai ridicate Cele mai bune pentru citire Cele mai ridicate Ridicate pentru reactualizare; sczute pentru citire Reproducere selectiv nalt* Sczute pentru articol; ridicate pentru sistem Satisfctoare* Medii Sczute*
Sczute pentru articol; ridicate pentru sistem Nesatisfctoa Satisfctoare* re Cele mai Cele mai sczute sczute Cele mai mari Sczute*
* depinde de calitatea proiectrii Dac considerm un set de fragmente R={R1, R2,...,Rn) i o reea avnd un set de noduri S={S1, S2,...,Sm} pe care ruleaz un set de aplicaii A={A1, A2,...,An), problema alocrii revine la determinarea distribuiei optime a fragmentelor R peste S. Un pas important pentru aflarea soluiei este definirea optimului, care poate fi considerat: Costul minimal funcia de cost const din costul stocrii fiecrui fragment Ri n nodul Sj, costul procesrii lui Ri la nodul Sj, costul actualizrii lui Ri n toate nodurile unde acesta este stocat i costul comunicaiilor de date. Performana strategia de alocare este proiectat astfel nct s menin o anumit performan (de exemplu, minimizarea timpului de rspuns) i maximizarea performanelor la fiecare nod. Problema alocrii poate fi specificat ca o problem de minimizare a costului n care se ncearc gsirea unui set I din S care specific unde vor fi stocate copiile fragmentelor. n literatura de specialitate exist cteva direcii de cercetare n domeniu. Chang a dezvoltat independent o teorie pentru fragmentarea i alocarea bazelor de date. Mai utilizat n implementarea sistemelor distribuite este ns teoria fragmentrii propus de Ceri, Pelagatti i Widerhold. n ceea ce privete problema alocrii, majoritatea modelelor se ocup de alocarea fiierelor simple, fr a lua n considerare aspectele legate de distribuia datelor. zsu i Valduriez au prezentat un model care rezolv, la un nivel minim, problemele specifice alocrii bazelor de date.
n luarea deciziei privind proiectarea bazelor de date distribuite pentru un anumit sistem trebuie, n general, s se rspund urmtoarelor ntrebri: Vor reduce fiierele locale volumul traficului de comunicaii (mesaje, tranzacii etc.) ? Este necesar pentru toate staiile s actualizeze aceleai nregistrri? Dac staiile au nevoie s acceseze nregistrri, ct de des trebuie acestea s fie actualizate? De exemplu, preul mrfurilor de vndut se modific la anumite intervale de timp. Pot fi utilizate fiierele locale pentru a verifica datele de intrare? Fac parte nregistrrile unei tabele, n mod natural, din fragmente care s poat fi pstrate n noduri dispersate? Cine este responsabil de pstrarea integritii nregistrrilor din fiier i de actualizarea acestora? Dac responsabilitatea revine unui departament central, este necesar ca acesta s informeze pe toi deintorii fiierelor distribuite de fiecare dat cnd au fost fcute modificri? Sigurana bazelor de date distribuite este pstrat satisfctor n mod local? Atunci cnd se definesc i se aloc fragmentele n nodurile reelei, trebuie avut n vedere atingerea unor obiective: Caracterul local al referinei, se refer la faptul c este bine ca datele s fie stocate, atunci cnd este posibil, n apropierea locului unde sunt utilizate. Fiabilitate i disponibilitate crescute acest obiectiv este mbuntit prin reproducere. Performane acceptabile. O alocare defectuoas poate duce la subutilizarea resurselor, la apariia unor strangulri etc. Capaciti de stocare i costuri echilibrate. Atingerea acestui obiectiv este strns legat de caracterul local al referinei. Costuri de comunicaie minime se refer la minimizarea costurilor cererilor ndeprtate. Costurile de regsire sunt minime atunci cnd caracterul local al referinei este maxim sau cnd fiecare nod deine propria sa copie a datelor. Replicarea Replicarea (reproducerea sau copierea) reprezint pstrarea mai multor replici identice ale unei relaii (sau fragmente ale unei relaii) n noduri diferite ale reelei, sau replicarea este operaia de stocare a unor poriuni dintr-o baz de date, sub form de copii, pe mai multe calculatoare dintr-o reea [Velicanu & al, 1998]. Replicarea este utilizat pentru a crete numrul de servere de baze de date disponibile clienilor (utilizatorilor), reducnd astfel ncrcarea pe fiecare server, iar motivele replicrii sunt fiabilitatea i eficiena interogrilor. Replicarea datelor are trei forme: Replicare complet n acest caz fiecare replic conine aceleai date cu celelalte copii. Datele replicate total semnific situaia n care SGBDD aloc pentru ntreaga BD mai multe copii pe diversele calculatoare din reea. Replicare parial caz n care unele fragmente ale bazei de date sunt reproduse, n timp ce alte fragmente nu. n aceast situaie datele sunt replicate parial, ceea ce semnific faptul c SGBDD aloc, pentru o parte din date, o singur copie pe un anumit calculator (nu sunt replicate) iar pentru alt parte din date mai multe copii pe mai multe calculatoare (datele sunt replicate). Partiionarea (nereplicat) caz n care nici o dat nu este reprodus.
Unitatea replicrii datelor poate fi la nivelul relaiilor sau al fragmentelor. Existena unor copii multiple poate mri disponibilitatea datelor i timpul de rspuns i poate ajuta la reducerea costului de comunicaie i a costului interogrii. O comparaie a celor trei alternative de replicare este ilustrat n tabelul urmtor: Procesarea interogrilor Administrarea directorilor Controlul concurenei Fiabilitatea Realizarea aplicaiilor Complet Simplu Simplu Moderat Foarte mare Aplicaii posibile Parial Dificil Dificil Dificil Mare Aplicaii reale Partiionarea Dificil Dificil Simplu Sczut Aplicaii posibile
O caracteristic asociat replicrii este transparena: utilizatorii nu trebuie s fie contieni de existena unor replici (copii) ale relaiilor utilizate. O alt problem important n replicarea datelor o reprezint consistena mutual: aceasta implic faptul c toate replicile trebuie s fie unice, indiferent de nodul n care se afl. Aceasta este una din responsabilitile sistemului de gestiune a bazei de date distribuite: s asigure actualizarea tuturor replicilor existente. n acest sens exist anumite soluii: Soluii neaprobate (nesusinute): Replicarea unei copii primare n acest caz unei replici i se atribuie calificativul de copie primar. Toate actualizrile sunt directate ctre aceast copie primar i numai dup ce sunt efectuate toate actualizrile, acestea sunt propagate ctre toate celelalte replici. Transmiterea cu jeton n acest caz numai serverul care conine jetonul (cadrul de control) poate efectua actualizrile i sincroniza deciziile referitoare la transmiterea jetonului. Soluii aprobate (utilizate): Soluia cea mai utilizat o actualizare poate fi executat numai cnd majoritatea replicilor sunt de acord cu acest lucru. Soluie utilizat n mod ponderat fiecrei replici i este atribuit un numr de voturi. Acest numr este necesar atunci cnd se dorete citirea sau scrierea unei replici. Factorii care influeneaz decizia replicrii datelor sunt dai de mrimea bazei de date i frecvena utilizrii datelor. Informaiile necesare replicrii datelor sunt memorate n catalogul bazei de date. Cu toate c replicarea reprezint cheia furnizrii unei disponibiliti crescute, a unei tolerane la defecte i a unei performane ridicate de calcul, ea este nc privit ca un ru necesar din cauza complexitii administrrii. Printre avantajele replicrii se numr: Creterea fiabilitii prin obinerea unor copii independente pentru fiecare replic. mparte ncrcarea muncii peste mai multe servere de baze de date.
Creterea disponibilitii se refer la accesibilitatea unui serviciu sistem. ntr-un sistem cu server nereplicat, dac serverul devine indisponibil, serviciul devine inaccesibil. ntr-un sistem cu server replicat acest avantaj poate fi obinut prin intermediul software-ului i/sau prin existena datelor pe mai multe noduri ale reelei. Astfel, dac un server cade, replicile rmase pot furniza serviciul cerut. Toleran la defecte ntr-un sistem replicat distribuit, eecul unei replici corespunztor prbuirii unui proces poate fi mascat de replicile sale corespondente; permite accesul la baza de date chiar dac din diferite motive un server de baze de date devine indisponibil. Performane mbuntite utilizarea replicrii datelor reprezint cheia furnizrii unei performane ridicate. 4.5.1. Reguli de proiectare a bazelor de date distribuite
La baza acestor reguli se afl principiului fundamental al bazelor de date distribuite, i anume: Pentru utilizator un sistem distribuit trebuie s apar ca i cum ar fi un sistem nedistribuit. Toate problemele legate de particularitile sistemelor distribuite trebuie s fie interne i trebuie s apar numai la un nivel intern, la nivelul elaborrii, dar nu la un nivel extern sau la nivelul utilizatorului. n contextul dat, termenul de utilizator se refer la utilizatorul sau utilizatorii sistemului, care execut operaii de gestiune a datelor. Toate aceste operaii trebuie s fie logic neschimbate, spre deosebire de operaiile de determinare a datelor, care din contr pot fi extinse chiar i de utilizator. De exemplu, utilizatorul nodului S3 poate indica c relaia pstrat poate fi fragmentat pe nodurile S1 i S2. Pentru exemplificare se consider reeaua din figura 4.7:
Fig. 4.7. Arhitectura reelei Principiul fundamental al bazelor de date distribuite duce la un set de reguli ajuttoare i scopuri proprii unei baze de date distribuite, reguli care sunt nrudite cu cele ale lui Edgar F. Codd pentru sistemele relaionale: 1. Autonomie local. ntr-un sistem de baze de date distribuite, nodurile trebuie s fie autonome. Autonomia nseamn c toate operaiile dintr-un anumit nod sunt controlate de ctre nodul respectiv, operaiile locale rmn pur locale, iar datele locale sunt deinute i gestionate local. Autonomia local presupune c operaiile efectuate pe acest nod trebuie s fie controlate de ctre acest nod, adic funcionarea oricrui nod Si nu depinde de succesul funcionrii sau realizrii operaiilor pe un alt nod Sj. Lipsa acestei reguli duce la consecine neplcute: de exemplu, dac un nod Si se defecteaz din
2.
3.
4.
5.
diferite motive, nodul Sj, dependent de Si, nu va putea funciona. Din principiul autonomiei locale reiese i faptul c odat cu prelucrarea datelor local are loc, de asemenea, tot n mod local i controlul integritii i a tuturor restriciilor aplicate bazei de date. n realitate, scopul autonomiei locale nu se atinge complet, din cauz c exist o mulime de situaii n care nodul Si trebuie s-i acorde o parte din controlul datelor altui nod Sj. Din acest motiv scopul atingerii autonomiei locale necesit o formulare mai precis i anume: nodurile trebuie autonomizate pn la nivelul maxim posibil de atins. Independen fa de nodul central. Sub termenul de autonomie local se subnelege c toate nodurile trebuie abordate ca fiind egale. Deci nu trebuie s existe nici o dependen de un nod central, de baz, cu o oarecare deservire centralizat, ca de exemplu prelucrarea centralizat a adresrilor la baza de date sau organizarea centralizat a lucrului cu tranzaciile asupra bazei; nu trebuie s existe servere centrale pentru servicii. Dac autonomia local (prima regul) nu este atins n totalitate, atunci i independena fa de nodul central este foarte important i poate fi tratat ca un scop aparte. Dependena de nodul central este de nedorit din cel puin dou motive: n primul rnd, nodul central poate fi un loc ngust pentru tot sistemul, iar n al doilea caz sistemul devine legat, iar n cazul defectrii nodului central tot sistemul nu mai funcioneaz. Operare continu. Una din principalele prioriti ale sistemului distribuit este acela c el asigur o stabilitate i o accesibilitate sporit. Acest lucru nseamn c nu este nevoie de o oprire planificat a sistemului pentru operaii cum ar fi: adugarea sau eliminarea unui nod din sistem; crearea i tergerea dinamic a fragmentelor dintr-unul sau mai multe noduri. Stabilitatea se refer la faptul c sistemul este n funciune i funcioneaz n orice moment de timp, el nu lucreaz dup principiul tot sau nimic, dar n regim continuu, adic lucrul sistemului continu, cu toate c la un nivel mai sczut, chiar dac unele noduri ale sistemului au ieit din funciune. Accesibilitatea reprezint probabilitatea ca sistemul s fie n funciune i s funcioneze n decursul unei perioade de timp. Independen de amplasare. Principala idee a independenei de amplasare, care se mai numete i transparena amplasrii, este destul de simpl: utilizatorii nu trebuie s cunoasc n ce loc fizic sunt pstrate datele, invers, din punct de vedere logic, utilizatorilor trebuie s li se asigure un astfel de regim de lucru, n care s apar iluzia c toate datele se afl pe nodul su propriu. Asigurarea independenei de amplasare este foarte util, deoarece aceasta simplific mult, la nivel exterior, programul utilizatorului i nsi conceptul i termenii de lucru. n particular, respectarea acestei reguli permite migrarea datelor de la un nod la altul. Independen de fragmentare. Utilizatorul trebuie s aib posibilitatea de a accesa datele, indiferent de modul n care sunt fragmentate relaiile bazei de date. Fragmentarea este utilizat, deoarece ea mrete productivitatea bazei de date distribuite, datorit faptului c datele sunt stocate n acel nod unde ele sunt cel mai des accesate. Astfel, multe operaii vor fi pur i simplu locale, iar fluxul de date n reea se va micora considerabil. Trebuie de precizat ns urmtoarele restricii: Se presupune c tuplurile relaiei date snt independente unul fa de altul, adic nici o relaie nu este determinat de cealalt. Dac apare necesitatea salvrii uneia i aceleiai informaii, atunci vom folosi mecanismul replicrii. Fragmentele nu trebuie s permit pierderea informaiei. Pentru a putea fragmenta relaia, este nevoie de un set de operaii compatibile cu bazele de date cu o structur relaional.
6.
7.
Independena de fragmentare presupune c datele vor fi prezentate pentru utilizator ntro form de combinaii logice. Administratorul de sistem gestioneaz i determin fragmentele crora trebuie s le acorde acces fizic utilizatorului, pentru executarea oricrei interpelri al utilizatorului. Independen de replicare. ntr-o baz de date distribuit exist independena de replicare, dac relaia dat, sau fragmentul dat, poate fi prezentat ca o mulime de copii diferite, sau replici, pstrate pe noduri diferite ale bazei de date distribuite. Astfel, utilizatorul nu trebuie s aib posibilitatea de a accesa direct o anumit replic a unui articol de date i nici nu trebuie s reactualizeze special toate replicile unui articol de date. Replicarea este folositoare, n principal din dou motive. n primul rnd, datorit ei, se atinge o productivitate sporit, aceasta se explic prin faptul c aplicaiile lucreaz cu copiile datelor, pe nodul local i nu fac schimb de informaii cu nodurile ndeprtate. n al doilea rnd, replicarea sporete accesibilitatea datelor, deoarece se poate efectua orice operaie cu datele att timp ct exist mcar o replic a datelor. Principalul neajuns al replicrii const n faptul c actualiznd obiectul relaional analizat, toate replicile acestui obiect trebuie de asemenea actualizate. Acest neajuns se numete problema actualizrii distribuie. Printre altele, trebuie menionat c replicarea ntr-o baz de date distribuit prezint un mod special de tratare a neajunsurilor. ntr-un caz ideal, replicarea, ca i fragmentarea ntr-o baz de date distribuit trebuie s fie nesesizat de utilizator. n ali termeni, ntr-o baz de date distribuit n care este prezent replicarea datelor, trebuie de asemenea s fie prezent i independena de replicare, adic pentru utilizatori, mcar din punct de vedere logic, trebuie s se lucreze ntr-un astfel de regim, ca i cum datele nu snt reproduse de loc. Independena de replicare presupune c administratorul sistemului rspunde de locaia fizic a datelor reproduse i are sub control actualizarea tuturor reproducerilor, la o modificare a datelor reproduse. n ncheiere trebuie s menionm c multe SGBD-uri comerciale propun o form de replicare care nu asigur independena total de replicare. Prelucrarea distribuit a interogrilor. Sistemul trebuie s aib capacitatea de a prelucra interogri care se refer la date aflate n mai multe noduri. De exemplu s analizm interogarea: Ne trebuie informaii despre contractele ncheiate de dealer-i din Galai i s presupunem c utilizatorul se afl n Buzu, iar datele se afl pe nodul din Galai. Presupunem de asemenea, c n conformitate cu interogarea utilizatorului corespund n contracte. Dac sistemul este relaional, atunci adresarea la baz va fi constituit din dou fluxuri informaionale sau traficuri unul cu interogarea adresat nodului din Galai i altul cu ntoarcerea rezultatelor rspuns pentru utilizatorul din Buzu. Acest exemplu arat c de cele mai multe ori, bazele de date relaionale opereaz cu datele de cteva ori mai repede dect alte modele, mcar la prelucrarea datelor la nivel de mulimi. Problema optimizrii este mult mai dureroas i mai important n cazul bazelor de date distribuite, dect n cazul celor centralizate. Principala problem i idee const n faptul c procesarea unei interogri a utilizatorului adresat mai multor noduri, se poate efectua n mai multe moduri, n ce privete deplasarea datelor de la un nod la altul. n acest caz, este foarte important de gsit soluia optim n ceea ce privete gestiunea datelor i prelucrarea interogrilor. De exemplu, o interogare adresat bazei de date ce are ca rezultat uniunea mulimilor Mx aflat pe nodul Si i mulimea My aflat pe nodul Sj, poate fi realizat prin deplasarea relaiei Mx la nodul Sj, deplasarea relaiei My la nodul Si, sau prin deplasarea ambelor relaii pe un alt nod Sk. Uneori strategia optim aleas difer prin timpul de prelucrare
chiar de ordinul orelor fa de unele mai puin optimizate, nemaivorbind de cele neoptimizate. 8. Prelucrarea distribuit a tranzaciilor. Sistemul trebuie s accepte tranzacia ca unitate de refacere. Sistemul trebuie s garanteze c att tranzaciile globale, ct i cele locale se conformeaz regulilor ACID pentru tranzacii, i anume: caracterul atomic, coerena, izolarea i durabilitatea. Exist dou aspecte de baz n prelucrarea tranzaciilor distribuite i anume gestionarea recuperrii i gestionarea paralelismului, crora trebuie s le acordm o atenie deosebit. Prelucrarea tranzaciilor asupra bazelor de date distribuite este mult mai dificil de realizat, datorit faptului c o interogare a unui utilizator poate modifica, aduga, terge noi date de pe diferite noduri ale bazei de date. Aici poate interveni noiunea de agent, care desemneaz o operaie executat asupra datelor de pe un nod al bazei de date distribuite. De exemplu, n cazul cnd se modific, printr-o singur interogare salariile angajailor, de pe toate nodurile, atunci pe toate nodurile, se creeaz aa numiii ageni, nite procese, care duc codul despre operaia n cauz; la o alt interpelare a altui utilizator apar ali ageni pe nodurile respective. La operaia salvrii lucrului COMMIT WORK sau la anularea lui, ROOLBACK WORK, sistemul trebuie s determine corelaia agenilor i a relaiilor dintre ei, sau a conflictelor ce pot aprea, ca de exemplu DEADLOOK. Aplicarea recuperrii presupune c sfritul tranzaciei se ncheie cu succes sau insucces, de tipul totul sau nimic. Pentru a evita insuccesele, care sunt nedorite, se utilizeaz uneori tranzacia multifaz, axat pe generarea automat a tranzaciilor asupra operaiilor respective. n ceea ce privete paralelismul, n bazele de date distribuite, ca i n cazul celor centralizate se aplic blocarea nregistrrilor, care de multe ori este nedorit. O soluie, ntlnit n SGBD-urile moderne este tehnologia multiversiunilor, aplicat de exemplu n SGBD-ul InterBase al Corporaiei Inprise. 9. Independen de hardware. Trebuie s fie posibil ca sistemul SGBDD s poat fi rulat pe o diversitate de platforme hardware. n prezent exist o larg diversificare a calculatoarelor, din punct de vedere al companiei productoare, din care se pot meniona Hewleet Packard, IBM, DELL etc. Deci o condiie necesar a bazelor de date distribuite este compatibilitea ei cu calculatoarele respective. 10. Independen de sistemul de operare. Ca o continuare a regulii precedente, trebuie s fie posibil s se ruleze sistemul SGBDD pe o diversitate de sisteme de operare. n ultimul timp se observ o diversificare larg a sistemelor de operare existente. Din ele putem meniona familia sistemelor de operare Windows (95-98, NT, 2000, XP, 2003), familiile Unix, Novell, Beo etc. n legtur cu aceasta exist o problem real n ceea ce privete compatibilitatea bazei de date, sau a SGBD-ului cu sistemul de operare. Multe sisteme de gestiune a bazelor de date sunt cunoscute ca fiind compatibile cu mai multe sisteme de operare. ns deseori ele apar cu mici modificri sau limitri, de exemplu InterBase ruleaz pe sistemele Windows 95-98, Windows NT, Unix, Linux, FreeBSD, ns pe platformele Unix sau Linux, utilizeaz tehnologia SimpleServer, iar pe platformele Windows 95-98, Windows NT, FreeBSD tehnologia SuperServer, n ceea ce privete prelucrarea interpelrilor. 11. Independen de reea. Exist mai multe tipuri de reele, care n cazul bazei de date distribuite pot lega ntre ele nodurile reelei. De asemenea, exist cazuri cnd unele segmente de reea ce unesc nodurile respective s nu fie de acelai tip (diferite tipuri de reea). Din acest motiv trebuie s fie posibil s se ruleze SGBDD-ul pe o diversitate de reele de comunicaie separate.
12. Independen de baza de date. O baz de date distribuit, cel puin din punct de
vedere teoretic, necesit compatibilitatea cu diferite SGBD-uri, aceasta se explic prin faptul c unele noduri ale bazei de date distribuite pot fi gestionate de un SGBD, iar o alt parte din noduri de un alt SGBD. De multe ori, n practic, este ntlnit cazul cnd exist deja diferite baze de date, gestionate de diferite SGBD-uri, care se cer reformalizate i reunite ntr-o baz de date distribuit. Teoretic, aceste SGBD-uri ar trebui s comunice ntre ele mai ales dac ambele suport standardul SQL, ns n multe cazuri SGBD-urile i dezvolt propriile lor extensii ale limbajului SQL, derivate care snt faciliti necompatibile ntre ele. Cu alte cuvinte, sistemul trebuie s accepte eterogenitatea. Aceste dousprezece reguli nu se afl ntr-o relaie de independen unele fa de altele, i n plus nu toate au acelai grad de nsemntate pentru proiectarea unei baze de date distribuite. Ultimele patru reguli sunt reguli ideale. Cele 12 reguli ale lui Chris J. Date pot fi sintetizate n afirmaia c distribuirea datelor nu trebuie s afecteze n nici un fel utilizatorii. Acest lucru nseamn c pentru toate categoriile de utilizatori ai bazei de date, SGBDD va asigura o transparen total a distribuirii. Detaliile legate de repartizarea i localizarea datelor se rezolv automat de SGBDD, fr nici o intervenie din partea utilizatorilor [Velicanu & al, 1998].
Capitolul 5. Realizarea aplicaiilor cu baze de date n Microsoft Access 2003 Microsoft Access este un sistem de gestiune a bazelor de date relaional SGBDR sau RDBMS2. Un SGBD este un program care faciliteaz memorarea i regsirea informailor structurate pe un support de memorie extern (un SGBD permite colectarea i pstrarea informaiilor despre un anumit subiect, cum ar fi facturile emise i recepionate de o firm sau evidena mijloacelor fixe etc.). Dintre cele mai cunoscute SGBDuri relaionale utilizate n organizaii se enumer: Oracle Microsoft SQL Server IBM DB2 Informix SGBDurile relaionale utilizate pentru PCuri: Microsoft Access Microsoft FoxPro Borland dBase Microsoft Access este produsul Microsoft pentru proiectarea i utilizarea bazelor de date. Access include un mediu de proiectare grafic pentru crearea i modificarea de tabele, formulare, rapoarte, interogri i macroinstruciuni. De exemplu, formularele i rapoartele pot conine i imagini, de exemplu, sigla unei firme. Se pot ncorpora n nregistrri obiecte OLE3, astfel nct un cmp dintr-o nregistrare poate conine sunete, animaie, un document scris ntr-un editor de text, o foaie de calcul sau o imagine. Access permite lucrul cu date existente i importul i exportul de date din/n FoxPro, Paradox, text ASCII, foi de calcul Excel i SQL Server. Instrumentele de tip wizard (asistent) automatizeaz i simplific procesul de creare a formularelor i rapoartelor. Alte faciliti oferite de Access se refer la definirea integritii refereniale, auto-asocierea (self-join, reprezint capacitatea de a cuta date dintr-un cmp n cmpul cheie al aceleiai tabele), precum i expresii i rutine de validare complexe. Caracteristic firmei Microsoft este faptul c pentru a uura munca de proiectare, dezvoltare i exploatare a unei aplicaii cu baze de date, produsul respectiv ncorporeaz ct mai multe caracteristici. De exemplu, Access-ul conine diverse utilitare, dintre care se enumer: Un sistem de baze de date relaional care suport dou limbaje standard de interogare: SQL4 i QBE5. Un limbaj de programare procedural, un subset al limbajului Visual Basic. Un limbaj macro procedural simplificat unic pentru Access.
RDBMS Relational DataBase Management System OLE Object Linking and Embedding, (legarea i nglobarea obiectelor) reprezint o tehnologie orientat obiect care permite realizarea de componente software reutilizabile. 4 SQL Structured Query Language, limbaj structurat de interogare, este limbajul standard pentru bazele de date relaionale. 5 QBE Query By Example, este un limbaj nestandardizat pentru interogarea bazelor de date care utilizeaz n acest scop abloane de interogare.
3 2
Sistemul Microsoft Access
58
Un mediu complet de dezvoltare rapid a aplicaiilor cu instrumente de programare vizual i de dezvoltare a rapoartelor. Diveri asisteni de programare (wizards) i constructori pentru a uura dezvoltarea aplicaiilor.
Pentru cei neiniiai multitudinea acestor elemente poate fi un impediment. Access-ul poate fi personalizat n funcie de utilizarea diferitelor elemente specifice sau din punct de vedere al aplicaiilor. Dezvoltarea unei aplicaii, poate fi privit n mod diferit n funcie de:

Utilizarea bazei de date relaionale, din acest punct de vedere aplicaia poate fi privit ca seturi de date. Existena unui limbaj de programare procedural, din acest punct de vedere aplicaia poate fi privit ca un set de comenzi care sunt executate secvenial. Caracteristica orientat obiect, din acest punct de vedere aplicaia poate fi privit ca obiecte care ncapsuleaz stri i informaii de comportament.
Dei termenul de baz de date se refer n mod n mod normal la o colecie de tabele ntre care exist anumite relaii, o baz de date Access include mult mai mult dect date. n general, n Access o baz de date reprezint o colecie de date creat cu scopul de a stoca informaii despre un anumit subiect. Se poate spune c o baz de date Access permite stocarea, regsirea i manipularea datelor folosind n principal, urmtoarele tipuri de obiecte: Tabela, a crui scop este de stocare a datelor ntr-o anumit structur. Interogri salvate pentru organizarea datelor. Interogrile permit regsirea datelor care ndeplinesc anumite condiii. Formulare pentru interaciunea cu datele de pe ecran. Formularul permite introducerea, afiarea, modificarea sau tergerea datelor. Rapoarte pentru imprimarea rezultatelor. Raportul permite afiarea datelor pe ecran sau la imprimant ntr-o form dorit de utilizator. Programe macro i Visual Basic pentru extinderea funcionalitii aplicaiilor cu baze de date.
Obiect e
Fig. 5.1. Obiectele bazei de date Evid_Facturi Dintre toate aceste obiecte, numai unul tabela este utilizat pentru a memora informaii. Restul tipurilor de obiecte sunt folosite pentru a administra, manipula, analiza, obine, afia, sau publica informaii din tabel, cu alte cuvinte, ele fac posibil ca informaiile memorate n tabele s fie accesibile utilizatorului.
Toate aceste obiecte ale bazei de date sunt memorate ntr-un singur fiier care va avea un nume <nume_fiier> i o extensie .mdb Microsoft DataBase (de exemplu, Evid_Facturi.mdb). n momentul n care se lanseaz n execuie Access-ul, va fi creat un fiier temporar cu numele <nume_fiier> i cu extensia .ldb (de exemplu, Evid_Facturi.ldb). Cu ajutorul produsului Microsoft Access se pot efectua o multitudine de operaii: Se poate crea o baz de date, prin utilizarea lui Database Wizard. Se pot crea tabele, pornind de la zero sau utiliznd o aplicaie expert. Se pot manipula datele existente n mai multe tabele, utiliznd n acest scop interogrile i rapoartele.
Bara de meniuri Bara de instrumente
Suprafaa de fereastr pentru diferite taskuri
Fig. 5.2. Sistemul Microsoft Access 2003 5.1. Lucrul cu baze de date Access Microsoft Access permite efectuarea urmtoarelor operaii asupra bazelor de date: Crearea unei baze de date noi. Salvarea unei baze de date. nchiderea bazei de date. Deschiderea unei baze de date existente. Deschiderea / nchiderea unei aplicaii cu baze de date. Utilizarea funciei Help pentru a primi ajutor n orice moment al crerii, dezvoltrii unei aplicaii cu baze de date. Fiecare dintre operaiile enumerate mai sus pot fi apelate fie din bara de meniuri, fie din bara de instrumente a mediului Microsoft Access. Ceea ce trebuie de reinut este faptul c n orice moment al dezvoltrii unei aplicaii cu baze de date sau al proiectrii bazei de date aferente
unei aplicaii se poate apela la funcia Help n orice situaie. Acest lucru se poate efectua n mai multe modaliti printre care cele mai utilizate sunt: Din bara de meniuri se alege meniul Help. n cazul n care calculatorul este conectat la Internet se poate obine suport online prin accesarea opiunii Microsoft Office Online, sau dac nu se dorete acest lucru se apeleaz opiunea Microsoft Office Access Help sau se apas tasta F1.
Fig. 5.3. Utilizarea funciei Help
Atunci cnd se dorete crearea unei noi baze de date, se va alege din bara de meniuri File | New |Blank database.
Fig. 5.4. Crearea unei baze de date noi Dup alegerea opiunii pe ecran va apare o fereastr prin care se va specifica numele folderului unde va fi salvat baza de date (Save in:), precum i numele bazei de date (File name:).
Fig. 5.5. Specificarea numelui bazei de date Dup crearea bazei de date se vor executa operaiile referitoare la crearea structurii tabelelor cuprinse n baza de date, a relaiilor dintre ele, precum i alte operaii care vor fi descrise ulterior. O alt modalitate de a crea o baz de date este aceea de a utiliza diferite abloane, cu scopul de a uura activitatea de proiectare a structurii unei baze de date. Astfel, Microsoft Access pune la dispoziie mai multe forme predefinite (templates), care pot fi accesate astfel: din bara de meniuri se alege File | New..., i din fereastra de taskuri se va alege Templates | On my computer (figura nr. 5.6.). n continuare se alege pagina Databases pentru a fi afiate toate abloanele disponibile de pe sistemul de calcul (figura nr. 5.7.).
Fig. 5.6. Alegerea unui ablon, drept punct de plecare pentru crearea structurii unei noi baze de date
Fig. 5.7. Alegerea ablonului Order Entry Dup alegerea ablonului, mediul Access cere calea i numele care se atribuie noii baze de date, respectndu-se regulile convenionale, n cazul de fa Ordine_Plata, dup care sunt afiate tabelele bazei de date ablon (figura nr. 5.8.).
Fig. 5.8. Componentele bazei de date Order Entry Fereastra urmtoare va conine n partea stng o list cu tabelele bazei de date, iar n partea dreapt toate cmpurile tabelei selectate. n funcie de noua structur care se dorete pentru fiecare tabel, se vor alege numai acele cmpuri necesare, sau toate. Se procedeaz identic pentru fiecare tabel.
Fig. 5.9. Alegerea cmpurilor pentru fiecare tabela bazei de date Ordine_Plata Urmtoarele operaii care mai sunt de efectuat se refer la stilul care se dorete a fi utilizat pentru afiarea pe ecran a diferitelor informaii, a formatului rapoartelor pe care le va emite sistemul etc.
Fig. 5.10. Alegerea stilului pentru afiarea datelor pe ecran Dup efectuarea tuturor operaiilor, baza de date va fi creat i se va cere introducerea datelor de identificare a organizaiei, dup care baza de date se poate utiliza. 5.2. Crearea structurii tabelelor bazei de date Tabelele sunt cele mai importante obiecte ale unei baze de date. Scopul lor principal este de a memora informaii referitoare la aplicaia creia i aparine. O baz de date Access poate conine mii de tabele, iar numrul de articole din fiecare tabel este limitat mai mult de spaiul disponibil de pe suportul de memorie extern (hard disk-ul). Pentru crearea structurii unei tabele pornind de la nici un ablon, sau o structur a unei alte baze de date, se va alege opiunea Create table in Design view (figura nr. 3.1.), care va determina apariia unei ferestre prin intermediul creia se va putea specifica:
Numele cmpului, conine maximum 64 de caractere, inclusiv spaiile i caracterele speciale, dar fr virgule, semne de exclamare i paranteze drepte. Acesta va fi introdus n coloana Field Name. Numele cmpului este un identificator prin intermediul cruia se poate accesa valoarea cmpului n vederea crerii unor expresii, a utilizrii n cadrul unor instruciuni Visual Basic. Acest nume trebuie s fie unic, el nu mai poate fi atribuit unui alt cmp din alt tabel a bazei de date. Tipul de dat care va putea fi stocat n acest cmp, va fi selectat din coloana Data Type. Tipul datelor va fi ales n funcie de informaiile care vor fi stocate n acest cmp. De exemplu, dac tipul datelor care vor fi stocate va fi de tip caracter se va alege tipul Text. Pentru descrierea mai exact a caracteristicilor fiecrui tip de cmp acestea se pot seta n partea de jos a ferestrei numit Proprietile cmpului (Field Properties), prin intermediul celor dou pagini: General i Lookup.
Fig. 5.11. Stabilirea structurii unei tabele Descrierea cmpului va permite specificarea mai detaliat a scopului cmpului sau informaii despre sursa datelor, care va fi introdus n coloana Description. 5.2.1. Proprietatea DataType Proprietatea DataType este utilizat pentru a specifica tipul datelor memorate ntr-un cmp al tabelei. Fiecare cmp poate memora date de un singur tip, iar setrile permise pentru aceast proprietate sunt explicate n tabelul urmtor: Setarea Text Tipul datei Dimensiunea Este tipul implict. Cmpul poate conine text sau text Poate conine ntre i numere (mai sunt denumite date alfanumerice), i 0 i 255 caractere. care nu necesit efectuarea unor calcule, cum ar fi o adres, un nume, un numr de telefon etc.
Memo
Texte mai mari de 255 caractere sau combinaii de Poate conine text i numere de dimensiuni mari. maximun 65.535 caractere. Number Datele memorate n aceste cmpuri sunt utilizate n 1, 2, 4, sau 8 bytes. calcule matematice. Dac proprietatea FieldSize este Replication ID atunci dimensiunea este de 16 byte. Date/Time Valori de tip dat i timp calendaristic pentru anii 8 byte. cuprini ntre 100 i 9999. Currency Valorile monetare i datele numerice sunt utilizate n 8 bytes. calcule matematice care implic date cu una la patru poziii zecimale. Mai exact pn la 15 cifre n partea stg a separatorului zecimal i 4 cifre n partea drept. AutoNumber De cte ori este adugat un nou articol ntr-o tabel, 4 bytes (dac Access atribuie un numr secvenial unic sau un proprietatea numr aleator. Cmpurile de acest tip nu pot fi FieldSize este actualizate (modificate). Replication ID atunci dimensiunea este de 16 bytes) Yes/No Valorile Yes i No i cmpurile (cmpuri boolene) 1 bit care conin numai una din aceste dou valori (Yes/No, True/False sau On/Off). OLE Object Un obiect (de exemplu, calcul tabelar Microsoft Pn la 1 GB (este Excel, un document Microsoft Word, grafice, limitat de spaiul pe sunete, sau alte date binare) nlnuite (o legtur disponibil ntre un obiect OLE i server-ul OLE, sau ntre un suportul de document surs DDE6 i un document destinatar) memorie extern). sau nglobat (posibilitatea de a include o copie a unui obiect OLE din alt aplicaie. Sursa obiectului, denumit server OLE, poate fi orice aplicaie care suport obiecte nlnuite i incluse. Modificrile efectuate asupra obiectului nglobat nu vor fi reflectate n obiectul original) ntr-o tabel Microsoft Access. Hyperlink Text sau combinaii de text i numere momorate ca Fiecare component text i utilizate ca o adres hyperlink (calea ctre o a celor trei pri a destinaie: un obiect, un document, sau o pagin datelor de tip Web. O adres hyperlink poate fi un URL7 adresa Hyperlink pot ctre un site Internet sau intranet, sau o cale de reea conine pn la UNC8 adresa ctre un fiier dintr-o reea local, 2048 caractere. LAN). O adres hyperlink poate avea maxim 3 pri: Text de afiat textul care apare ntr-un cmp sau
6 7
DDE Dynamic Data Exchange, protocol de schimb dinamic de date implementat de firma Microsoft. URL Uniform Resource Locator, o adres care specific un protocol (HTTP sau FTP) i o locaie a unui obiect, document, pagin Web, sau alt destinaie pe Internet sau ntr-un intranet (de exemplu, http://www.microsoft.com). 8 UNC Universal Naming Convention, o convenie de denumire pentru fiiere care furnizeaz o main independent. Un nume UNC utilizeaz sintaxa \\server\\share\\path\\filename.
Lookup Wizard
control. Adresa calea ctre un fiier (calea UNC) sau o pagin (URL). Subadres o locaie din interiorul fiierului sau paginii. Screentip textul afiat ca un tooltip. Cea mai uoar cale de a insera o adres hyperlink ntr-un cmp sau control este: din meniul Insert se alege opiunea Hyperlink. Creaz un cmp care permite cutarea unei valori memorate ntr-o alt tabel sau o list de valori prin utilizarea unei casete cu list (list box un control care furnizeaz o list de opiuni; este alctuit dintro list i o etichet opional) sau a unei casete combinate (combo box un control utilizat pe un formular care furnizeaz funcionalitatea combinat a unei casete cu liste i a unei casete text. Se poate tasta o valoare sau se poate da click pe control pentru a afia o list din care se poate alege un articol). Cnd se alege aceast opiune se va crea un cmp Lookup (Lookup field un cmp utilizat pe un formular sau raport ntr-o baz de date Access, care afieaz fie o list a valorilor primite de la o tabel sau interogare, sau memoreaz un set de valori statice). Dup completarea wizard-ului, Microsoft Access seteaz tipul datei bazat pe valorile selectate n wizard.
Are aceeai dimensiune ca a cmpului cheie primar utilizat pentru a face verificarea, 4 bytes.
Not: Setarea acestei proprieti poate fi fcut numai n poriunea de sus a ferestrei Design view o fereastr care arat proiectarea acestor obiecte ale bazei de date: tabele, interogri, formulare, rapoarte, macroinstruciuni i pagini de acces la date. n Design view se pot crea noi obiecte ale bazei de date i se pot modifica cele deja existente. Cmpurile de tip Memo, Hyperlink i obiecte OLE nu pot fi indexate. Este indicat a se utiliza tipul de dat Currency pentru un cmp care cere multe calcule utiliznd date cu una sau pn la patru poziii zecimale; aceste tipuri de date utilizeaz un calcul rapid n virgul fix. Cmpurile de tip dat Single sau Double cer calcule n virgul mobil. Not: Dac se modific tipul de date, dup ce s-au introdus date ntr-o tabel, este posibil ca n cazul n care noul tip nu este compatibil cu tipul vechi al datei, s fie pierdute informaii. Dup ce se introduc toate cmpurile tabelei aceasta va fi salvat, prin alegerea din bara de meniuri a meniului File | Save as..., sau prin apsarea butonului de nchidere a ferestrei din bara de titlu a ferestrei din figura nr. 5.11., care va determina apariia urmtoarei ferestre de dialog.
Fig. 5.12. Salvarea structurii unei tabele Baza de date Evid_Facturi va conine urmtoarele tabele, iar structura fiecrei tabele este ilustrat n figurile 5.13. 5.21. Terti Rulaj_terti Produse Plati Sold_terti Localitati Facturi Detalii_facturi Judete
Fig. 5.13. Structura tabelei Terti
Fig. 5.14. Structura tabelei Facturi
ig. 5.15. Structura tabelei Rulaj_terti
Fig. 5.16. Structura tabelei Plati
Fig. 5.17. Structura tabelei Sold_terti
Fig. 5.18. Structura tabelei Produse
Fig. 5.19. Structura tabelei Judee
Fig. 5.20. Structura tabelei Localiti
Fig. 5.21. Structura tabelei Detalii_facturi 5.2.2. Proprietile cmpului Field Properties Fiecrui cmp din cadrul unei tabele i se pot specifica anumite caracteristici de baz, care vor fi utilizate pentru verificarea validitii cmpului, stabilirea cheilor primare i a cheilor strine, a relaiilor care se stabilesc ntre tabela respectiv i celelalte tabele ale bazei de date. Specificarea acestor caracteristici se pot efectua n Field Properties, care conine dou pagini: General i Lookup. Prin intermediul paginii General pot fi setate proprietile cmpului, iar prin intermediul paginii Lookup se poate selecta tipul de control (TextBox, ListBox i ComboBox) care va fi utilizat pentru vizualizarea datelor memorate n cmpul respectiv. Pagina General conine mai multe caracteristici specifice fiecrui tip de dat setat (Data Type), avnd deci una sau mai multe proprieti: File Size, Format, Input Mask, Caption, Default Value, Validation Rule, Validation Text, Required, Allow Zero Length, Indexed, Unicod Compression, IME Mode, IME Sentence Mode, Smart Tags.
Proprietatea FieldSize este specific unui cmp de tip Text, Number sau AutoNumber, ea permite setarea dimensiunii maxime a datei ce este memorat n cmpul respectiv. Tipul de dat Text: cmpurile text pot conine pn la maximum 255 caractere. Valoarea implicit este 50. Tipul de dat AutoNumber permite memorarea automat a unui numr unic pentru fiecare articol care este inserat ntr-o tabel. Pot fi generate dou tipuri de date: Long Integer sau Replication ID. Tipul de dat Number: un cmp de acest tip memoreaz date numerice care pot fi utilizate n calcule matematice; dac se dorete afiarea sau calculul unor valori exprimate n diferite monezi se va utiliza tipul de dat Currency. Tipurile i valorile datelor sunt artate n tabelul de mai jos. Poziii Dimensiunea zecimale memoriei Byte Memoreaz numere a cror valori sunt cuprinse 1 byte n domeniul 0...255. Decimal Memoreaz numere cu valorile cuprinse ntre 28 12 byte 1028 1...1028 1. Integer Memoreaz numere a cror valori sunt cuprinse 2 byte n domeniul 32.768...32.767. Long Este tipul numeric implicit. Memoreaz numere 4 byte Integer a cror valori sunt cuprinse n domeniul 2.147.483.648...2.147.483.647. Single Memoreaz numere cuprinse n domeniul 7 4 byte 3.402.823E38... 1.401.298E-45 Double Pentru numere negative permite memorarea 15 8 byte valorilor cuprinse n domeniul 1.797693134231E308... 4.94065645841247E324 , iar pentru cele pozitive valori cuprinse n domeniul 4.94065645841247E-324 pn la 1.79769313486231E308. Replication Identificator unic global GUID9. Sunt utilizate N/A 16 byte ID pentru a identifica replicri, seturi, tabele, articole, i alte obiecte. Setarea Descrierea Pentru procesarea mai rapid i utilizarea unei zone de memorie ct mai mici este indicat s se utilizeze tipuri de date de dimensiuni ct mai mici posibile. Not: Pentru a modifica mrimea implicit pentru cmpurile de tip Text i Number se alege din bara de meniuri Tools | Options, care va determina apariia ferestrei Options. n pagina Tables/Queries a ferestrei se modific valorile de sub Default field sizes.
GUID Globally Unique IDentifier
Fig. 5.22. Setarea valorilor implicite a tipurilor de date Text i Number De asemenea, trebuie s se in cont de faptul c dac se dorete, ulterior definirii structurii tabelei, modificarea valorii FieldSize aceasta trebuie s se efectueze corect. De exemplu, dac se dorete conversia unui cmp de tip Text care a avut dimensiunea de 150 caractere, la o dimensiune de 50 caractere, anumite informaii se vor pierde, datorit trunchierii datelor. Dac tipul datei este Number i se modific FieldSize atunci dac datele aveau i parte fracionar aceasta poate fi rotunjit sau poate returna valoarea Null. De exemplu, dac se modific de la Single la un cmp de dimensiune Integer, valoarea fracionar va fi rotunjit la cel mai apropiat numr ntreg i valorile mai mari dect 32.767 sau mai mici dect 32.768 vor rezulta n cmpuri null. Celelalte proprieti care pot fi utilizate, n funcie de tipul cmpului, sunt: Numele proprietii Format Tipul de cmp specific
Text, Memo, Number, Data/Time, Currency, AutoNumber, Yes/No i Hyperlink Input Mask Text, Number sau AutoNumber Caption Text, Number sau AutoNumber Default Value Text, Number sau AutoNumber Validation Rule Text, Number sau AutoNumber Validation Text Text, Number sau AutoNumber Required Text, Number sau AutoNumber Allow Zero Text, Number sau AutoNumber Length Indexed Text, Number sau AutoNumber, ea permite setarea dimensiunii maxime a datei ce este memorat n cmpul respectiv. Unicode Text, Number sau AutoNumber Compression IME Mode Text, Number sau AutoNumber
IME Sentence Text, Number sau AutoNumber Mode Smart Tags Text, Number sau AutoNumber Pagina LooKup permite specificarea controlului Display Control care va fi utilizat pentru afiarea datelor memorate n alt tabel, respectiv: TextBox, ListBox i ComboBox. Astfel pentru fiecare factur introdus, n tabela Facturi, codul unic de identificare pentru furnizor, respectiv client, se va prelua din tabela Terti.
Fig. 5.23. Modalitatea utilizrii paginii Lookup 5.3. Crearea relaiilor ntre tabele Dup crearea tabelelor bazei de date trebuie s se explice modalitatea n care datele existente n aceste tabele vor putea fi accesate i utilizate n scopul pentru care au fost create. Primul pas n acest proces este definirea relaiilor. Relaiile dintre tablele unei baze de date se pot crea cu ajutorul diagramei relaiilor, care arat modalitatea n care cmpurile dintr-o tabel sunt legate la cmpurile dintr-o alt tabel. Dup ce sunt definite aceste relaii, se vor putea crea interogri, formulare i rapoarte pentru a afia informaii din una sau mai multe tabele. ntr-o baz de date relaional, relaiile permit prevenirea redundanei datelor. De exemplu pentru proiectarea bazei de date care permite evidena facturilor emise i primite de la teri, sunt necesare informaii despre fiecare factur, tabela Facturi: serie, numr, data emiterii, furnizorul, clientul etc. De asemenea sunt necesare informaii despre fiecare furnizor sau client: cod unic de identificare, denumire, adresa, telefon etc. Dac toate aceste informaii ar fi memorate n tabela Facturi, pentru fiecare furnizor care emite facturi vor exista informaii redundante, referitoare la informaiile despre furnizor. Din acest motiv cea mai bun soluie este de a memora informaiile despre fiecare furnizor i client ntr-o tabel separat, numit Terti. Dup ce sunt create cele dou tabele se va putea
crea un pointer n tabela Facturi care face legtura cu tabela Terti. De asemenea, pentru a fi siguri de sincronizarea datelor, se poate impune o integritate referenial ntre tabelele Facturi i Terti, care va asigura c informaia dintr-o tabel are corespondent n cealalt tabel. De exemplu, pentru fiecare factur emis de un furnizor va trebui s existe informaii despre furnizorul respectiv. Deci nu se vor putea aduga facturi emise de un furnizor care nu exist n baza de date. Tipurile de relaii care se pot stabili ntre dou tabele au fost enumerate n subcapitolul Tipuri de relaii. O relaie se stabilete ntre cmpurile de tip cheie (primar i / sau strin). n mod normal, este indicat ca numele celor dou cmpuri s fie identice n ambele tabele. n majoritatea cazurilor, relaiile asociaz cheia primar dintr-o tabel (tabela printe), care furnizeaz un identificator unic pentru fiecare articol, cu o cheie strin din alt tabel (tabela copil). De exemplu, un furnizor poate fi asociat cu facturile emise prin crearea unei relaii ntre cmpul Cod_unic din tabela Terti (cheie primar) i cmpul Cod_unic din tabela Facturi (cheie strin).
Fig. 5.24. Reprezentarea grafic a relaiei unu-la-muli Cele trei tipuri de relaii care se pot stabili ntre tabele depind de modalitatea n care sunt definite cmpurile respective. ntr-o relaie unu-la-unu, o nregistrare dintr-o tabel poate avea asociat cel mult o nregistrare din tabela cu care intr n relaie i invers. O astfel de relaie este creat n cazul n care fie cele dou cmpuri sunt chei primare sau au impuse constrngeri de unicitate. Acest tip de relaie nu este prea utilizat deoarece cele mai multe informaii legate de acest fel pot fi cuprinse toate ntr-o singur tabel. Relaia de tipul unu-la-unu este utilizat n urmtoarele situaii: Se mparte o tabel care conine multe cmpuri n dou tabele. Se dorete izolarea informaiilor dintr-o tabel din motive de securitate. Memorarea informaiilor care se aplic numai unui subset al tabelei principale. Se memoreaz date care au o durat de via mic i care pot fi terse uor prin simpla tergere a tabelei. ntr-o astfel de relaie, n ambele pri (a cheii primare i a cheii strine) este utilizat simbolul 1.
Fig. 5.25. Relaie de tip unu-la-unu Cea mai utilizat relaie este de tipul unul-la-muli: de exemplu, fiecare factur este emis numai de un furnizor, dar un furnizor poate emite mai multe facturi. Acest tip de relaie se poate crea numai dac unul din cmpurile nrudite este o cheie primar pentru o tabel (reamintim c un cmp cheie primar nu permit valori Null i trebuie s aib ntotdeauna un index unic) sau are o constrngere de unicitate. ntr-o astfel de relaie partea chei primare este reprezentat de simbolul 1, iar partea chei strine din relaie este reprezentat de simbolul infinit. Relaiile de tip muli-la-muli sunt acele relaii n care unei nregistrri dintr-o tabel i corespunde mai multe nregistrri din alt tabel i invers. Pentru a crea o astfel de relaie va trebui s se defineasc o alt tabel, numit tabel de jonciune. Pentru aceast tabel cheia primar va fi alctuit din ambele chei primare ale celor dou tabele implicate n relaie. De exemplu, ntre tabela Facturi i tabela Produse exist o relaie de tipul muli-la-muli. Pentru a implementa aceast legtur se va crea o a treia tabel, numit Detalii_facturi i care va avea drept cheie primar combinaia cmpurilor Serie_doc i Nr_fact (cheia primar a tabelei Facturi), i a cmpului Cod_produs (cheia primar a tabelei Produse). Relaia muli-la-muli care se stabilete ntre dou tabele poate avea i caracteristici, care se vor transpune n tabela de jonciune n atribute. Relaia care exist ntre tabela Facturi i tabela Produse se poate enuna astfel: o factur conine mai multe produse, fiecare produs va avea un pre unitar i o cantitate. Deci, preul unitar i cantitatea vor fi atribute ale relaiei, iar n tabela Detalii_facturi vor fi cmpuri. Structura tabelei Detalii_facturi precum i relaiile care se stabilesc ntre cele trei tabele sunt ilustrate n figura nr. 5.26.
Fig. 5.26. Tabela Detalii_facturii i diagrama relaiilor dintre tabelele Facturi, Detalii_facturi i Produse De asemenea, se poate crea o relaie ntre o tabel i ea nsui. Acest tip de relaie este utilzat in situaia n care este necesar s se fac o referire (Lookup) n cadrul aceleiai tabele. De exemplu, n tabela Terti, se poate defini o relaie ntre cmpurile Cod_unic i Banca, astfel nct se poate determina toi terii care au cont deschis la o aceeai banca. Not: Dac se ncearc tragerea unui cmp care nu este o cheie primar i nu are un index unic ctre un alt cmp care nu este cheie primar i nu are un index unic, va fi creat o relaie nedeterminat. n interogrile care conin astfel de relaii, Microsoft Access va determina afiarea unei linii de jonciune (join, reprezint o relaie de asociere ntre un cmp dintr-o tabel sau interogare i un cmp cu acelai tip de dat din alt tabel sau interogare) implicite ntre tabele, dar integritatea referenial nu va fi impus, i astfel nu se va garanta unicitatea articolelor n fiecare tabel a relaiei. 5.4. Definirea integritii refereniale Integritatea referenial reprezint un set de reguli prin care se asigur c relaiile dintre articolele din tabelele nrudite sunt valide (corecte) i nu pot fi terse sau modificate datele din articolele respective n mod accidental. Integritatea referenial poate fi impus n situaia n care sunt respectate urmtoarele reguli: Nu se poate introduce o valoare ntr-un cmp cheie strin a tabelei copil dac acea valoare nu are un corespondent n tabela printe (nu exist un articol n tabela printe cu cheia primar avnd valoarea respectiv). Cu toate aceste, se pot introduce valori null n cmpul cheie strin. De exemplu, nu se poate introduce o factur emis de un furnizor despre care nu exist date n tabela Terti.
Nu se poate terge o nregistrare din tabela printe (cheia primar) dac exist nregistrri n tabela copil (cheie strin). De exemplu, nu se poate terge o nregistrare din tabela Terti dac exist nregistrri asociate n tabela Facturi. Nu se poate modifica o valoare a cheii primare din tabela printe pentru care exist nregistrri corespunztoare n tabela copil.
Deci integritatea referenial se poate utiliza n situaiile n care sunt ndeplinite urmtoarele condiii: Cmpul corespunztor din tabela printe (primar) este o cheie primar sau are impus o constrngere de unicitate. Cmpurile referite au acelai tip de dat i dimensiune. Exist totui dou excepii: un cmp de tip AutoNumber poate fi legat cu un cmp de tip Number cu proprietatea FieldSize setat la Long Integer, i un cmp de tip AutoNumber cu proprietatea FieldSize setat la Replication ID poate fi legat cu un cmp de tip Number cu proprietatea FieldSize setat la Replication ID. Ambele tabele fac parte din aceeai baz de date. Impunerea relaiilor prin intermediul diagramei de relaii. Atunci cnd se creaz o relaie n diagrama de relaii exist dou opiuni asupra impunerii integritii refereniale: Relaia nu are impus integritatea referenial (cheia strin este inactiv, figura nr. 5.27.).
Fig. 5.27. Stabilirea unei relaii fr impunerea integritii refereniale
Relaia are impus (obligatoriu) integritatea referenial (se creaz o constrngere a cheii strine), caz n care n diagram aceasta este reprezentat ca n figura nr. 5.28.
Fig. 5.28. Stabilirea unei relaii cu impunerea integritii refereniale Opiunile Cascade Update Related Fields.i Cascade Delete Related Fields n situaia relaiilor pentru care este impus integritatea referenial se poate specifica dac se dorete actualizarea n mod automat n cascad (cascade update: se refer la faptul c n situaia n care un articol din tabela printe este modificat vor fi modificate toate articolele din tabela copil sau tabelele nrudite) sau teargerea automat n cascad (cascade delete: cnd un articol din tabela printe este ters vor fi terse toate articolele din tabela / tabelele copil) a tuturor articolelor nrudite. Deci, dac se va selecta csua Cascade Update Related Fields n momentul definirii unei relaii, n orice situaie n care se va modifica cheia primar a unui articol din tabela printe, sistemul va modifica automat la noua valoare toate articolele din tabela copil. Excepie de la aceast regul este situaia n care n tabela printe cheia primar este de tip AutoNumber, datorit faptului c aceast valoare este atribuit n mod automat de sistem pentru fiecare articol din tabel. Dac se va selecta csua Cascade Delete Related Fields n momentul definirii unei relaii, n orice situaie n care se va terge un articol / articole din tabela printe, sistemul va terge automat toate articolele din tabela copil. De exemplu, dac se terge un furnizor din tabela Terti, toate facturile din tabela Facturi vor fi terse (ceea ce nu este indicat). 5.5. Interogri Interogarea const n extragerea datelor dintr-o tabel (tabele), dintr-o interogare anterioar sau din ambele, prelucrarea acestora ntr-o form mai mult sau mai puin complex i furnizarea informaiilor ctre utilizatori. Rezultatele interogrilor pot fi folosite ca atare sau pot constitui surs de nregistrri pentru crearea formularelor i rapoartelor. Principalele operaii care se pot realiza cu ajutorul interogrilor sunt: extragerea din tabele numai a cmpurilor relevante pentru utilizatori;
extragerea nregistrrilor din tabele prin specificarea unor criterii de selecie; regsirea i ordonarea datelor dup anumite criterii; crearea de cmpuri calculate; extragerea datelor din una sau mai multe tabele i realizarea unor informaii sintetice; crearea de tabele, ad ugarea nregistrrilor n tabele, tergerea nregistrrilor din tabele i actualizarea datelor; combinarea i compararea ieirilor prin realizarea mai multor interogri n acelai timp; interogarea i a altor baze de date (FoxPro, SQL Server); pregtirea datelor n vederea afirii lor n formulare sau rapoarte.
n Microsoft Access se pot crea urmtoarele tipuri de interogri: 1. Interogri de selecie extrag informaii din unul sau mai multe tabele i le afieaz sub form de list. Sunt cel mai uor de creat i au avantajul c pot afia un numr redus de date dintr-un tabel de mare capacitate (datele care ndeplinesc condiiile specificate). Ele permit i modificarea rezultatului afiat, modificare ce va fi vzut i n tabelul surs. De asemenea, permit i folosirea de parametri, cum este reuniunea de cmpuri din tabele ntre care nu exist nici o legtur precum i efectuarea de calcule. 2. Interogri parametrice nu sunt un tip special de interogri, o funcie parametru putnd fi folosit pentru toate celelalte interogri prezentate mai sus; ele folosesc n mod repetat o interogare, efectund modificri n criteriile de selecie. 3. Interogri ncruciate centralizeaz n formatul unei foi de calcul tabelar datele din unul sau mai multe tabele. Datele rezultate dup execuia unei astfel de interogri sunt prezentate ntr-un format potrivit pentru analiza datelor i crearea de grafice. 4. Interogri de aciune creeaz un nou tabel n baza de date sau realizeaz modificri majore ale unui tabel existent. n general, toate interogrile de aciune pot fi realizate pe baza unei interogri de selecie. Ele permit adugarea, modificarea sau tergerea de nregistrri ntr-un tabel. Exist patru tipuri de interogri de aciune: interogri de generare a unui nou tabel din datele coninute n setul de rezultate al interogrii; interogri de adugare a noi nregistrri ntr-un tabel; interogri de tergere a unor nregistrri dintr-un tabel; interogri de actualizare a unor nregistrri dintr-un tabel, conform cu o condiie ce trebuie ndeplinit. Aciunile acestora sunt ireversibile asupra datelor din tabelele surs, iar n cazul ultimelor trei dintre ele, trebuie urmrit pstrarea integritii refereniale atunci cnd prin intermediul lor se acioneaz asupra mai multor tabele legate. Interogarea datelor din tabele se realizeaz n dou moduri: n mod grafic prin interfaa Query By Example (QBE) - interogare prin exemplu; prin limbajul SQL sub form de blocuri de cerere. Microsoft Access ofer trei posibiliti pentru definirea interogrii i afiarea rezultatelor acesteia. Design View - fereastr sub forma unei grile de interogare, n care se definete interogarea. Datasheet View - fereastr n care se afieaz rezultatele interogrii. SQL View - fereastr n care Access genereaz automat codul SQL al interogrii QBE. aceeai fereastr este folosit i pentru scrierea direct a unei interogri cu ajutorul instruciunilor SQL. n continuare, se vor detalia tipurile de interogri enumerate mai sus.
5.5.1. Interogri prin selecie Aplicaia 1 Fie o baz de date ce conine tabelele: Produs, Client, Comanda, Continut comanda.. Se vor construi urmtoarele relaii:
Fig. 5.29. Stabilirea relaiilor Crearea unui obiect de tip interogare Iniierea crerii cererii se realizeaz n fereastra Database prin activarea fiei Query (Interogri) i apoi apsarea butonului New, sau selectnd din meniul Insert opiunea Query. Microsoft Access ofer mai multe modaliti de creare a cererilor. Aceste modaliti sunt afiate n fereastra New Query (figura 5.30.) afiat ca urmare a iniierii operaiei de creare a cererii: Design View - proiectarea interogrilor utiliznd interfaa grafic QBE. Simple Query Wizard - utilizarea asistentului pentru cereri simple. Crosstab Query Wizard - utilizarea asistentului pentru cereri ncruciate. Fiind Duplicates Query Wizard- utilizarea asistentului pentru cutarea nregistrrilor duplicat. Find Unmatched Query Wizard - utilizarea asistentului pentru cutarea nregistrrilor care nu au corespondent n dou tabele.
Fig. 5.30. Fereastra New Query

Fig. 5.31. Fereastra Show Table cu lista tabelelor disponibile Pentru crearea unei cereri de selecie se alege opiunea Design View din caseta New Query. Fereastra Show Table (figura 5.31.) ofer posibilitatea precizrii sursei de date pentru construirea cererii. Sursa de date pentru o cerere poate fi reprezentat de: una sau mai multe tabele; una sau mai multe interogri; tabele i interogri. Se vor selecta tabela/tabelele i/sau cererile surs i se va aciona butonul Add pentru a realiza aducerea acestora n fereastra de proiectare a cererii. Dup ce a fost precizat sursa de date se va nchide fereastra Show Table prin acionarea butonului Close. La nevoie se poate redeschide fereastra folosind opiunea Show Table din meniul Query. Dac sunt necesare date din mai multe tabele sau interogri se procedeaz asemntor i pentru celelalte obiecte. n partea superioar a ferestrei Query Design vor fi afiate tabelele sau interogrile, fiecare cu lista cmpurilor coninute (figura 5.32.). n cazul n care tabelele din care se extrag datele pentru interogare au fost puse n relaie anterior, ele apar n fereastra Query Design cu liniile de legtur precizate (1-1 sau l - ). Dac nu, relaia ntre tabele poate fi creat n cadrul interogrii.
Fig. 5.32. Fereastra Select Query Fereastra Select Query (figura 5.32.) este mprit n dou zone: zona superioar, n care se vizualizeaz tabelele/interogrile surs de date precum i relaiile definite ntre acestea; grila Query Design structurat astfel: linia Field: rezervat pentru selectarea unui cmp; linia Table: destinat precizrii sursei de date; linia Sort: permite precizarea sensului sortrii pentru atributul din coloana respectiv; linia Show: permite inhibarea afirii realizrilor cmpului respectiv; linia Criteria: ofer posibilitatea precizrii criteriilor de selecie prin introducerea expresiilor Access corespunztoare; liniile or: permite precizarea mai multor criterii de selecie n cazul expresiilor Access utiliznd operatorul OR. Definirea interogrii de selecie presupune parcurgerea urmtorilor pai: 1. Precizarea cmpurilor ale cror realizri urmeaz s le returneze cererea. Numele acestor cmpuri se vor preciza n grila Query Design n rndul Field utiliznd una din urmtoarele modaliti: selectarea cmpului din cadrul listei Field; executarea unui dublu clik de mouse asupra cmpului dorit din tabela/interogarea aflat n panoul superior; metoda drag-and-drop care presupune selectarea cu mouse-ul a cmpului dorit din panoul superior i tractarea acestuia n linia Field. Dac este necesar s fie aduse n panoul inferior toate cmpurile aparinnd unei tabele se va proceda n unul din urmtoarele moduri: selectarea tuturor cmpurilor din tabela surs (aflat n panoul superior) printr-un dublu clik de mouse pe numele tabelei i se trag cmpurile pe gril; utilizarea asteriscului aparinnd tabelei surs: tragei cu mouse-ul asteriscul n prima coloan Field;. chiar dac n grila de proiectare este completat doar prima coloan Field la execuie interogarea va returna realizrile tuturor atributelor; utilizarea proprietii Output All Fields: se va deschide caseta Query Properties utiliznd butonul Properties &* din bara de instrumente sau executnd dublu click ntr-o zon liber a panoului superior; n linia Output All Fields se va preciza Yes; precizarea valorii Yes pentru proprietatea Output All Fields nu va determina aducerea n grila de proiectare a cmpurilor din tabela surs, dar, n momentul executrii cererii, vor fi cuprinse toatea realizrile tuturor atributelor. n mod implicit, antetul coloanelor tabelului rezultat n urma interogrii este reprezentat de numele cmpului, cu excepia cazului n care la crearea tabelei ai precizat o alt etichet prin intermediul proprietii Caption. Dac dorii afiarea n tabelul rezultat n urma interogrii a unei noi etichete pentru un cmp plasai mouse-ul n linia Field naintea numelui cmpului, tastai eticheta dorit urmat de caracterul :". 2. Se precizeaz criteriul de selecie (n mod implicit se returneaz realizrile tuturor tuplurilor pentru cmpurile specificate) prin introducerea unei expresii Access valide n rndul Criteria (eventual i rndul OR). Introducerea expresiei Access se face prin tastare sau se construiete prin intermediul generatorului de expresii (Expression Builder) a crui fereastr se deschide selectnd opiunea Build a meniului pe care l activai printr-un click dreapta de mouse n rndul Field.
3.
Se precizeaz, dac este necesar, cmpul/cmpurile dup care se dorete o eventual sortare i sensul acesteia n linia Sort.
n figura 5.33. se exemplific o interogare cu date luate din tabelele Produs, Comanda, Continut comanda i Client asociate anterior.
Fig. 5.33. Exemplu de interogare Pentru ca rezultatele interogrii s fie interpretate mai uor, utilizatorul poate s cear ordonarea nregistrrilor n funcie de valorile anumitor cmpuri. Sortarea este posibil pe cmpurile numerice, de tip text i data calendaristic. Se pot specifica sortri pe mai multe cmpuri din cadrul aceleiai interogri.
Fig. 5.34. Sortarea cresctoare a datelor din tabel Aplicaia 2 Fie aceeai baz de date constituit pentru o firm care i comercializeaz produsele pe baza comenzilor primite de la clieni. Firma dispune de un nomenclator al produselor fabricate n
care sunt consemnate denumirea fiecrui produs, unitatea de msur i categoria de calitate aferent. Clienii firmei sunt persoane fizice crora li se solicit numele, adresa, codul potal i numrul de telefon. Comenzile primite sunt numerotate secvenial, pe fiecare consemnndu-se data recepionrii comenzii i termenul de livrare (exprimat n zile) iar, n momentul onorrii comenzii, se completeaz data la care s-a efectuat livrarea. Pe o comand pot fi solicitate unul sau mai multe produse n diferite cantiti.
Fig. 5.35. - Proiectarea unei interogri de selecie n figura de mai sus se prezint modul n care s-a definit interogarea de selecie prin care se realizeaz: afiarea numelui clienilor cu adresa n Galati sau Braila (primul criteriu de selecie), numrului comenzii trimise i data convenit a livrrii care trebuie s fie anterioar datei curente (cel de al doilea criteriu de selecie precizat). Afiarea se realizeaz n ordinea alfabetic dup numele clienilor. Sursa de date a cererii este reprezentat de dou tabele ale bazei de date: Client i respectiv Comanda.
Fig. 5.36. - Utilizarea operatorului OR Pentru a evita repetarea restriciei puse asupra cmpului data_livrarii pe mai multe rnduri (pentru fiecare ora) s-ar fi putut apela la soluia scrierii tuturor localitilor pe acelai rnd i utilizrii operatorului OR (figura 5.36.). Modificarea unei cereri Pentru a modifica o cerere, aceasta trebuie deschis n modul Design. Modificrile se pot realiza insernd noi coloane sau tergnd coloane deja definite.
Inserarea unei noi coloane se efectueaz selectnd coloana naintea creia dorim s introducem noua coloan i alegnd opiunea Column din meniul Insert. tergerea unei coloane din grila de proiectare se realizeaz selectnd coloana i acionnd tasta Delete sau butonul Cut din bara de instrumente sau executnd opiunea Delete Column din meniul Edit. Modificarea unei cereri poate presupune i extinderea sursei de date (utiliznd fereastra Show Table). De asemenea modificarea cererii poate implica i precizarea unor formate de afiare asociate unor coloane pentru ca datele returnate s fie uor de parcurs (pentru precizarea unui anumit format de afiare se va plasa cursorul mouse-ului n coloana dorit i se va executa clik dreapta, selectndu-se din meniul contextual opiunea Properties. Va fi afiat caseta Field Properties n care se va putea specifica numrul de zecimale dorit sau un format de afiare pentru cmpul respectiv. Pe lng modurile de vizualizare Design i Datasheet Access permite utilizatorilor vizualizarea i modificarea codului SQL al interogrilor. Pentru aceasta se va apela din meniul View opiunea SQL View. Utilizarea operatorilor Pentru a construi expresii pe rndul Criteria se utilizeaz operatorii: aritmetici: adunare (+); scdere (-), nmulire (*), mprire (/), ridicare la putere (^), mprirea a dou numere cu returnarea unui ntreg (\), mprirea a dou numere cu returnarea restului mpririi (MOD). de comparaie: <, >, =, <=, >=. Aceti operatori returneaz valorile logice True i False. Excepie reprezint cazul n care unul dintre operatori are valoarea NULL i deci orice comparare va returna valoarea NULL. asociai operatorilor de comparare: IS NULL, IS NOT NULL - o valoare NULL (cmp necompletat) nu este nici TRUE nici FALSE. nregistrrile care au valoarea NULL n cmpurile selectate nu apar ca rezultate ale interogrii; LIKE - se folosete mpreun cu caracterele de nlocuire * " i ?" pentru a stabili dac o valoare ncepe cu unul sau mai multe caractere; caracterul * " poate nlocui orice numr de caractere; caracterul ? " nlocuiete numai un caracter; IN - stabilete dac o valoare este cuprins ntr-o list; BETWEEN - stabilete dac o valoare aparine unui interval specificat. logici: NOT - negaia; AND - pentru conjuncia a dou valori; OR - pentru disjuncia a dou valori; XOR - pentru disjuncia exclusiv a dou valori; Eqv - verific echivalena a dou valori. de concatenare a irurilor de caractere: + i &. de identificare:! i.. Aceste dou caractere sunt utilizate ca separatori, astfel: Combin numele coleciilor de obiecte i numele obiectelor pentru a selecta un anumit obiect sau proprietate a lui: Forms! [Clieni] Identific atribute aparinnd unei tabele: Clieni! [Localitate]
Deosebete numele obiectelor de cele ale proprietilor: TextBox1.FontSize=12 unde: TextBox reprezint un obiect de control iar FontSize reprezint o proprietate (stabilete dimensiunea fontului) constante: constantele utilizate n construirea expresiilor Access pot fi de natur: numeric (ex: 1200,5,0); text ("123", "Toma Ion", 'str. Viilor 15'); dat calendaristic (ex: #12.31.01# ceea ce indic data de 31 decembrie 2001). Identificatorii: sunt nume de obiecte Access (tabele, atribute, formulare, etc.), prin intermediul identificatorilor se pot prelua valori pentru definirea criteriilor de pe formulare create anterior. Funciile: pot fi de natur: Dat calendaristic : Date(), Month(), Year (), etc. Exemple: Date() - returneaz data curent; Month(Date()) returneaz numrul lunii calendaristice curente. Year(Date()) returneaz anul curent. De tip text: Len() - returneaz lungimea unui ir; Trim() - elimin spaiile de la nceputul i de la sfritul unui ir; Left() - returneaz primele n caractere de la nceputul unui ir etc. Matematice i trigonometrice: ABS() - returneaz valoarea absolut a unui numr; INT() - returneaz partea ntreag dintr-o valoare numeric, ROUND() - rotunjete o valoare cu un anumit numr de zecimale; SUM() - calculeaz suma; A VG() calculeaz media etc. Financiare: PV() returneaz valoarea actual a unei anuiti pltite n rate periodice egale; SLN() returneaz valoarea amortizrii unui mijloc fix dup o anumit perioad (amortizare liniar) etc. Funcii diverse: ISNUMERIC(), ISNULL() etc.
Reguli de formare a expresiilor introduse pe cmpul Criteria: datele de tip Text se tasteaz ca atare, iar Access adaug automat ghilimele; pentru datele de tip Number i Currency se tasteaz cifrele i eventual simbolul zecimal, fr simbolul monetar sau separatorul de mii; referirile la numele de cmpuri trebuie incluse ntre paranteze drepte, altfel se adaug automat ghilimele, considerndu-se text; formatul internaional de dat calendaristic este mm/dd/yy. Access adaug automat delimitatorul #; Access adaug automat IS la referirile care implic valoarea NULL. Pe rndul Criteria din grila de interogare se poate introduce un singur criteriu de selecie sub un cmp sau mai multe criterii sub cmpuri diferite. Dac criteriile de selecie se introduc pe un singur rnd Criteria, se extrag nregistrrile care ndeplinesc toate condiiile (operatorul logic AND), iar dac se introduc pe rnduri diferite se includ n rspuns doar nregistrrile care ndeplinesc oricare dintre criteriile menionate (operatorul logic OR). Aplicaia 3 Pentru exemplificare se utilizeaz tabela Client care cuprinde clienii din diferite orae cu sau fr telefon. Se cere: 1. Realizarea unei interogri pentru obinerea unei liste cu persoanele care au numrul de telefon care ncepe cu 7 (figura 5.37.). Sub cmpul telefon pe rndul Criteria se scrie expresia: LIKE " 7* "
2.
3. 4.
Realizarea unei interogri pentru obinerea unei liste cu clieni care au numrul de telefon care nu ncepe cu 7. Sub cmpul telefon pe rndul Criteria se scrie expresia: NOT LIKE " 7* ". Realizarea unei interogri pentru obinerea unei liste cu clieni care nu au telefon. Sub cmpul telefon pe rndul Criteria se scrie expresia: IS NULL. Realizarea unei interogri pentru obinerea unei liste clienii care au numrul de telefon care ncepe cu 7 sau a celor care nu au telefon. Pe rndul Criteria sub cmpul sector se scrie 6, iar sub cmpul telefon se scrie expresia: IS NULL OR LIKE"7*".
Fig. 5.37. - Interogarea abonai cu numrul de telefon care ncepe cu 7 Cmpuri calculate n interogri de selecie Interogrile de selecie pot cuprinde i cmpuri calculate. Aceste cmpuri returneaz, la executarea interogrii, valoarea expresiilor Access asociate lor. Pentru a crea un cmp calculat trebuie avute n vedere urmtoarele criterii: se introduce n celula Field a grilei de interogare un nume de coloan (dac nu se specific se atribuie numele implicit Expr l, Expr2, ...), urmat de semnul " : " i formula de calcul, astfel: stoc_final: [stoc_initial] + [Cant_intrata] - [Cant_iesita]. cmpuri calculate pot fi create i pentru text (concatenarea cmpurilor): Numepren: [Nume] & " " & [ Prenume]. cmpurile calculate pot fi sortate, li se pot aplica criterii de selecie sau se pot totaliza. n cmpurile calculate se poate utiliza funcia IIF cu urmtoarea sintax: IIF (<expresie>, valoare 1, valoare2) unde: <expresie> - este o expresie a crei valoare de adevr este evaluat pentru fiecare nregistrare; valoare 1 - este valoarea returnat dac expresie este adevrat; valoare2 - este valoarea returnat dac expresie este fals. Pentru a aduga un cmp calculat ntr-o interogare se tasteaz numele acestuia ntr-o nou coloan din grila Query Design, se adaug dou puncte i apoi se completeaz expresia dorit. Exemplu: Interogarea din figura 5.38. calculeaz data limit pn la care trebuie onorat fiecare comand.
Fig. 5.38. - Exemplu de cmp calculat ntr-o interogare Expresiile pot fi utilizate ntr-o interogare de selecie fie drept criterii de selecie fie pentru a calcula anumii indicatori. Expresia poate fi tastat n rndul Field al unei coloane (exemplul din figura 5.38.) sau poate fi construit cu ajutorul generatorului de expresii (a crui fereastr se activeaz efectund click dreapta n linia Field i selectnd din mediul contextual opiunea Build). Exemplul din figura 5.39. prezint utilizarea generatorului de expresii pentru a calcula valoarea fiecrui produs de pe o comand.
Fig. 5.39. - Fereastra Expression Builder

5.5.2. Interogri parametrice Interogrile de selecie prezentate pn n acest moment returneaz ntotdeauna nregistrrile din tabelele surs care corespund unei anumite cereri fixe (a se vedea exemplul de interogare de selecie prezentat ntr-un paragraf anterior). De multe ori ns, ar fi util o interogare al crei criteriu de selecie s poat fi precizat la nivel general i particularizat de utilizator n funcie de necesitile sale de informare (precizndu-se concret ce realizri ale atributului sunt cutate) chiar n momentul execuiei cererii. O astfel de interogare se caracterizeaz prin faptul c n grila Design, pe coloana dorit, n linia Criteria, se va preciza ntre paranteze drepte un mesaj ce urmeaz a fi afiat la executarea cererii permind ca utilizatorul s introduc criteriul de selecie dorit. Parametrii pot fi utilizai nu doar n rndul de criterii, ci i n formulele cmpurilor calculate, dac se dorete introducerea unui termen variabil n expresii. Cnd se creeaz i salveaz o interogare este posibil s nu se cunoasc valorile pentru un cmp. n aceast situaie se va crea un parametru pentru interogare (un nume de cmp diferit de numele cmpurilor tabelei sau interogrii, ncadrat de paranteze drepte). La execuia interogrii apare o caset de dialog prin care se cere valoarea pentru cmpul parametru. Exemplu Pentru exemplificare se utilizeaz tabela Client care cuprinde clienii din diferite orae cu sau fr telefon. Interogarea din figura 5.40. caut un client din tabela Client dup cmpul nume.
Fig. 5.40. - Fereastra Select Query /Rezultatul interogrii - Introducerea valorii parametrului 5.5.3. Interogri ncruciate Sunt interogri de tip total, cu deosebirea c n listele obinuite care folosesc denumirea cmpurilor ca titluri de coloane, tabelul ncruciat este un mod de a sintetiza datele ntr-o form specific. Interogrile de tip tabel ncruciat (CrossTab Query) sunt extrem de utile n scopul analizei multidimensionale a datelor permind obinerea unor situaii sintetice asemntoare tabelelor pivot consacrate de procesoarele de tabele (Microsoft Excel, Lotus 123 etc.). Practic, este posibil elaborarea unor tabele n care gruparea i ordonarea datelor se realizeaz att pe linii ct i pe coloane la intersecia crora se pot efectua calcule complexe. Pentru o interogare tabel ncruciat sunt necesare cel puin 3 cmpuri: unul care s furnizeze valorile pentru titlurile de rnd (Row Heading), cu meniunea c se pot alege mai multe cmpuri antet de rnd; unul care s dea valorile pentru titlurile de coloane (Column Heading); un singur cmp poate fi antet de coloan; unul care s fie baz pentru calcularea valorilor sintetice de afiat la punctele de intersecie rnd - coloan; aceste valori se obin, de regul, prin nsumare i numrare utiliznd funciile Sum i Count. Etapele ce trebuie urmate pentru realizarea unei astfel de cereri de interogare sunt urmtoarele (Microsoft Access dispune i de un program wizard ce permite elaborarea asistat a unor astfel de interogri): 1. Elaborarea unei interogri de selecie n modul Design View. Se vor alege tabelele ce conin datele i se vor selecta cmpurile dorite pentru afiare i eventualele cmpuri pentru care se vor impune restricii. 2. Din meniul Query se va selecta opiunea CrossTab Query ce va avea ca efect imediat
3. 4.
afiarea liniilor Total i Crosstab n grila interogrii. Se va specifica modul de agregare a datelor, respectiv funciile totalizatoare n linia Total. n linia CrossTab se va opta pentru Row Heading n cazul cmpurile ce vor fi afiate pe liniile tabelului, Column Heading pentru cmpul ce va fi afiat pe vertical, i Value pentru valorile ce vor fi afiate la intersecia liniilor cu coloanele. Este permis existena mai multor cmpuri ordonate pe orizontal (Row Heading), dar a unui singur cmp Column Heading i a unui singur cmp Value.
Exemplu Pentru exemplificare se utilizeaz tabelele Produs, Comanda i Continut Comanda. Interogarea din figura 5.41. afieaz pe linie produsele din baza de date, pe coloana data comenzii realizate, iar la intersecia liniei cu coloana se calculeaz suma cantitilor vndute din fiecare produs n ziua specificat n capul de tabel.
Fig. 5.41. Interogare Crosstab / Rezultatul interogrii 5.5.4. Interogri de aciune Interogrile de aciune pot avea ca rezultat: a. Crearea de noi tabele (Make Table Query). b. Actualizarea datelor (Update Query). c. Adugarea de noi nregistrri (Append Query). d. tergerea nregistrrilor (Delete Query). Modul de elaborare a unei interogri tip aciune este similar celui prezentat n cazul interogrilor de selecie, presupunnd ca etap suplimentar specificarea explicit prin intermediul meniului Query a tipului de cerere dorit. Modificrile asupra bazei de date sunt efectuate doar n momentul execuiei interogrii.
Este recomandat proiectarea n prealabil a cererii ca o simpl interogare de selecie i verificarea rezultatelor ce vor fi afectate deoarece nu exist posibilitatea revenirii n cazul tergerii sau modificrii eronate a nregistrrilor.
Fig. 5.42. - Alegerea tipului de interogare a. Interogri pentru crearea de noi tabele (Make Table Query) Crearea de noi tabele pe baza nregistrrilor din tabelele deja existente presupune parcurgerea urmtoarelor etape: Elaborarea unei interogri de selecie n modul Design View (vor fi luate n calcul doar cmpurile ce dorim s fac parte din structura noii tabele, iar, n cazul n care sunt necesare i alte cmpuri pentru aplicarea unor criterii, acestea nu vor fi marcate n linia Show a grilei QBE). Apelarea din meniul Query a opiunii Make Table Query i specificarea n casete Make Table a numelui noii tabele (se poate opta pentru crearea noii tabele ntr-o alt baz de date bifnd opiunea Another Database i specificnd numele fiierului). Lansarea n execuie a interogrii. Tabela rezultat va moteni doar tipurile de date i dimensiunile cmpurilor din tabelele surs, nu i cheia primar sau eventualele proprieti la nivel de cmp ori tabel. Exist posibilitatea generrii unor tabele care s conin cmpuri ce nu exist n tabelele surs (cmpuri calculate). b. Interogri pentru modificarea tuplurilor (Update Query) Modificarea tuplurilor ntr-o tabel deja existent presupune parcurgerea urmtoarelor etape: Elaborarea unei interogri de selecie n modul Design View (vor fi luate n calcul doar cmpurile ce dorim s fac parte din structura noii tabele, iar, n cazul n care sunt necesare i alte cmpuri pentru aplicarea unor criterii, acestea nu vor fi marcate n linia Show a grilei QBE). Apelarea din meniul Query a opiunii Update Query Lansarea n execuie a interogrii.
Exemplu Pentru exemplificare se utilizeaz tabela Client. Interogarea din figura 5.43. face referire la tuplurile care au n cmpul nume valoarea Popa. Noua valoare se specific n Update to iar ceea ce se modific n Criteria. n exemplul de mai jos pentru cmpul nume orice nume Popa va deveni Petrescu.
Fig. 5.43. Interogare Update
c. Interogri pentru adugarea tuplurilor (Append Query) Adugarea tuplurilor ntr-o tabel deja existent presupune parcurgerea urmtoarelor etape: Elaborarea unei interogri de selecie n modul Design View (vor fi luate n calcul doar cmpurile ce dorim s fac parte din structura noii tabele, iar, n cazul n care sunt necesare i alte cmpuri pentru aplicarea unor criterii, acestea nu vor fi marcate n linia Show a grilei QBE). Apelarea din meniul Query a opiunii Append Query. Lansarea n execuie a interogrii. Exemplu Pentru exemplificare se utilizeaz tabela Client. Prin alegerea opiunii Append Query se va preciza care este numele tabelei ca n figura 5.44.a iar apoi se vor preciza valorile ce se doresc a fi adugate potrivit cmpurilor selectate. Din tabela Client au fost alese pentru exemplificare cmpurile cod client, nume i prenume iar valorile adugate sunt pentru cod client 222, pentru nume client Ion, pentru prenume Ana.
Fig. 5.44. Interogare Append pentru tabela Client
d. Interogri pentru tergerea tuplurilor (DeleteQuery) tergerea tuplurilor dintr-o tabel deja existent presupune parcurgerea urmtoarelor etape: Elaborarea unei interogri de selecie n modul Design View (vor fi luate n calcul doar cmpurile ce dorim s fac parte din structura noii tabele, iar, n cazul n care sunt necesare i alte cmpuri pentru aplicarea unor criterii, acestea nu vor fi marcate n linia Show a grilei QBE). Apelarea din meniul Query a opiunii Delete Query. Lansarea n execuie a interogrii. Exemplu Pentru exemplificare se utilizeaz tabela Client. Interogarea din figura 5.45.a combin dou tipuri de interogri, realiznd tergerea unui client dup orice valoare a cmpului nume, solicit printr-o fereastr de dialog. (interogare dup parametru). Interogarea din figura 5.45.b face referire la tuplurile care au n cmpul nume valoarea Popa. La lansare n execuie a interogrii vor fi terse toate tuplurile cu acea valoare.
Fig. 5.45. Interogare Delete cu parametru (a) i fr parametru (b)
Capitolul 6. Accesarea i prelucrarea datelor din baze de date externe Avnd n vedere faptul c exist numeroase produse software att pentru prelucrri de tip foi de calcul tabelar, ct i pentru gestiunea volumelor mari de date sub form de baze de date, este important s se asigure compatibilitatea ntre aceste produse, astfel nct anumite informaii organizate cu unul dintre ele s poat fi transferate i prelucrate cu un alt produs. Sistemul de proceduri conceput de firma Microsoft pentru a asigura aceast compatibilitate se numete ODBC Open Data Base Connectivity. Din Excel, se pot deschide fiiere create cu diverse versiuni ale altor sisteme de gestiune a datelor, cum ar fi: Lotus, Quattro Pro, Works, dBase. n acest scop, se va alege tipul corespunztor de fiier n fereastra File | Open. 6.1. Conversia unei liste Excel ntr-o baz de date Access O baz de date simpl creat ntr-o foaie de lucru Excel sub form de tabel n care antetul reprezint nume de cmpuri poate fi automat convertit ntr-o baz de date Access. Odat convertit aceast list n Access, ea poate fi meninut numai n Access (datele) iar modificrile care se vor efectua asupra datelor din baza de date Access nu vor afecta lista Excel. Se tie c o baz de date conine un ansamblu de date structurate ntr-o form specific; structura de memorare i organizare a informaiilor faciliteaz gestiunea lor (operaii de memorare, regsire a datelor etc.). Un tabel Excel poate fi privit ca o baz de date pentru care numele de date sau cmpurile sunt numele coloanelor tabelului iar fiecare set de valori pentru aceste nume (nregistrare) se gsete ntr-o linie a tabelului. Astfel, un tabel Excel implementeaz n mod natural ceea ce este cunoscut sub numele de model relaional de organizare a bazelor de date. n Excel, pentru o structur de acest tip se mai folosete i denumirea de lista. Pentru a executa conversia unei liste Excel trebuie ca pe calculatorul respectiv s fie instalat Microsoft Access, iar n funcie de varianta pachetului Microsoft Office paii car etrebuie urmai sunt diferii. Astfel, n cazul variantei Microsoft Office 2000 opiunea care permite aceast conversie este Data | Convert to MS Access.... Dac comanda Convert to MS Access... nu apare n meniul Data din Excel, acesta trebuie instalat i ncrcat astfel: din meniul Tools se alege opiunea Add-Ins.... Pe ecran va apare o fereastr n care se va bifa opiunea Access Links....
Bibliografie
96
Fig. 6.1. Instalarea Access Links
Pentru a efectua conversia unei liste Excel ntr-o baz de date Acces se va proceda astfel: Se vor selecta celulele din lista Excel care se doresc a fi convertite n Access. n meniul Data, se va alege opiunea Convert to MS Access.... Tabela poate fi introdus ntr-o baz de date nou sau ntr-una existent, dup cum se poate observa din fereastra de dialog de mai jos.
Fig. 6.2. Fereastra pentru conversia n Access a datelor din foile Excel Deci pentru a crea o nou baz de date Access pe baza unei liste Excel, se va alege opiunea New database. Pentru a aduga lista la o baz de date existent se va alege opiunea Existing database, i apoi se va scrie calea complet ctre baza de date, sau se poate apsa butonul Browse, care permite alegerea folder-ului unde se afl stocat baza de date. Dup terminarea operaiilor se va da click pe butonul OK. Access Import Spreadsheet Wizard i Table Analyzer Wizard ne va ajuta pe tot parcursul conversiei listei Excel n baza de date Access.
Not Dup conversie, AccessLinks va plasa un text box la dreapta listei originale care va arat c lista a fost convertit n Access. Datele originale nu se vor modifica.
Un tabel Excel mai poate fi folosit pentru crearea unui formular sau raport Access, folosind opiunile Data | MS Access Form..., respectiv Data | MS Access Report.... Se va deschide automat sistemul Access i se va lansa asistentul specific pentru crearea formularelor, respectiv rapoartelor ntr-o baz de date nou. n cazul variantei Microsoft Office 2003 se va proceda n modul urmtor: 1. Se alege din meniul File opiunea Open. 2. Se va alege calea i fiierul Excel din care se dorete a se extrage datele care se doresc a fi convertite ntr-o tabel Access.
Fig. 6.3. Alegerea fiierului Excel

3.
n prima pagin care va apare se va selecta First Row Contains Column Headings pentru a indica numele coloanelor.
Fig. 6.4. Selectarea opiunii First Row Contains Column Headings

4.
n a doua pagin se va alege numele tabelei n Linked Table Name, i apoi se va apsa butonul Finish.
Fig. 6.5. Atribuirea numelui tabelei n Linked Table Name, Varianta 1 Dup executarea acestor operaii Access creaz i deschide baza de date nou, care va avea numele fiierului Excel din care s-au importat datele.
Fig. 6.6. Crearea bazei de date cu numele Brown Tabela Varianta 1, va fi populat cu toate datele existente n foaia de lucru din Excel.
Fig. 6.7. Coninutul tabelei Varianta 1
6.2. Accesarea datelor externe n Excel Din Excel se pot accesa i prelucra baze de date externe (create cu alte aplicaii sisteme de gestiune a bazelor de date) folosind opiunea Data | Import External Data | Import Data....
Fig. 6.8. Alegerea sursei datelor
Fig. 6.9. Alegerea bazei de date Dup alegerea bazei de date se pot alege tabelele care se doresc a fi importate n Excel.
Fig. 6.10. Alegerea tabelei Customers Dup importul tabelei, datele care sunt coninute pot fi supuse oricrui proces de prelucrere dorit de utilizator. Prelucrrile care se pot realiza sunt de tip interogare, referindu-se n principal la selectarea datelor care ndeplinesc anumite criterii. n acest scop, se va folosi aplicaia MS Query, care se lanseaz automat la activarea opiunilor din Import External Data din meniul Data. Operaiile de creare i modificare a interogrilor, Data | Import External Data | New Database Query..., sunt absolut similare cu cele referitoare la crearea interogrilor n Access; avnd n vedere acest fapt, vom descrie mai jos doar principalele etape de lucru, fr a intra n prea multe detalii legate de proiectarea i execuia interogrilor Access.
Fig. 6.11. Ferestrele de specificare a sursei de date pentru o interogare nou

Astfel, a obine informaii dintr-o baz de date extern revine la crearea unei interogri pentru acea baz de date; n acest scop, se utilizeaz opiunea Create New Query (din Import External Data), care va lansa automat aplicaia MS Query. Primul pas va consta n specificarea sursei externe de date, care poate fi un fiier creat n Access, dBase, FoxPro, chiar Excel, un fiier text sau eventual un fiier creat cu un alt sistem, cu condiia ca s existe un driver de interfaa specific cu sistemul respectiv. Practic, prin intermediul unor ferestre de dialog specifice (vezi figura nr. 6.11.) se selecteaz tipul aplicaiei i fiierul surs de date, printr-un mecanism de tip browse. Interogarea se poate proiecta: Interactiv, cu ajutorului unui asistent alegnd cmpurile care vor aprea n interogare, specificnd cmpurile care fac obiectul interogrii, criteriile dorite, cmpurile de sortare etc. (figurile nr. 6.12., 6.13., 6.14.). n final, se indic dac datele rezultate vor fi afiate (salvate) n Excel (eventual ntr-o nou foaie de lucru) (figurile 6.15, 6.16.) sau vor putea fi salvate i vizualizate (cu posibilitatea de a modifica interogarea) cu MS Query (figurile 6.17., 6.18).
Fig. 6.12. Alegerea cmpurilor utilizate n interogare
Fig. 6.13. Alegerea criteriului de interogare
Fig. 6.14. Alegerea cmpurilor sortate
Fig. 6.15. Salvarea interogrii nt-o nou foaie de lucru Excel
Fig. 6.16. Rezultatul interogrii salvat n nou foaie de lucru Excel
Fig. 6.17. Salvarea interogrii
Fig. 6.18. Vizualizarea interogrii n MS Query Direct n fereastra de proiectare (vezi figura nr. 6.10.), urmnd etapele clasice: Specificarea tabelelor din baza de date care vor constitui sursa interogrii n acest scop se va utiliza fereastra de dialog Add Tables din meniul Table. n cazul mai multor tabele ntre care exist cmpuri de legtur, dac aceste relaii nu au fost definite anterior, ele pot fi specificate n cadrul interogrii printr-o operaie de aducere (tragere) a cmpului din tabela principal peste corespondentul su din tabela relaional.
Fig. 6.19. fereastra de dialog Add Tables

Selectarea cmpurilor de afiat n zona RQBE (zona inferioara a ferestrei de proiectare); Specificarea condiiilor de selectare din meniul Criteria opiunea Add Criteria.
Fig. 6.20. - Crearea unei interogri n suprafaa de proiectare a aplicaiei MS Query Rezultatele selectate pot fi prelucrate suplimentar prin operaii de: sortare dup cmpurile dorite se utilizeaz butoanele de sortare ascendent / descendent sau opiunea Records - Sort; grupare i totalizare liniile cu aceeai valoare pentru un anumit cmp se pot grupa, astfel nct asupra grupurilor obinute s se realizeze calcule statistice simple: Sum, Avg, Count, Min, Max. Opiunea este similara cu "Group By" din Access i se poate activa cu butonul de totalizare (marcat cu simbolul) sau cu opiunea Records | Edit Column, n a crei fereastr de dialog se alege funcia statistic dorit (vezi figura 6.21.). Execuia interogrii proiectate se realizeaz automat, daca opiunea Records | Automatic Query este activ, sau la cerere, cu Records | Query Now, rezultatele afindu-se n zona inferioar a suprafeei de proiectare.
Fig. 6.21. - Fereastra pentru specificarea unei funcii statistice de aplicat asupra unui cmp Odat creat o interogare, ea poate fi oricnd modificat n MS Query - se pot aduga sau elimina cmpuri, schimba criteriile de selecie, cmpurile de sortare. Evident c se va opera asupra interogrii curente (dac este vorba de o interogare anterior creat, ea trebuie nti deschis). Operaiile de baz care se pot realiza cu interogri n aplicaia MS Query sunt cele cunoscute: salvarea se realizeaz cu File | Save / Save As, deschiderea unei interogri existente se face cu File | Open, (nchiderea cu File | Close) iar crearea unei interogri noi cu File | New. Butoanele echivalente acestor operaii sunt similare cu cele deja cunoscute. MS Query creeaz implicit interogrile n format .dqy. Dac din sistemul Excel se dorete execuia unei interogri existente, n vederea prelurii n foaia de lucru a rezultatelor acesteia, se activeaz opiunea Data | Get External Data | Run Database Query. n fereastra deschis (vezi figura 6.22.) se va activa butonul Get Data. Datele astfel preluate pot fi actualizate din Excel prin modificarea interogrii corespunztoare; n acest scop, se poate utiliza opiunea Data | Get External Data | Edit Query, care va deschide interogarea cu aplicaia MS Query, permind realizarea modificrilor dorite.
Fig. 6.22. Fereastra de selectare a interogrii de executat O facilitate special a sistemului Excel o constituie preluarea de informaii din formulare Web (n format HTML). n acest scop, se activeaz opiunea Data | Get External Data | Run Web Query i se selecteaz interogarea web dorit din lista de fiiere *.iqy pus la dispoziie (vezi figura 6.23.).
Fig. 6.23. Selectarea unei interogri web Dup alegerea unei interogri i activarea butonului Get Data, se va accesa formularul web de la adresa URL asociat (de exemplu, pentru interogarea selectat n fereastra de mai sus, pe site-ul Microsoft: http://www.microsoft.com/excel/webquery/samples.htm) i se va executa interogarea. ntr-o fereastr de dialog, se poate opta pentru inserarea rezultatelor n foaia de lucru curent sau ntr-una nou, precum i pentru setarea unor caracteristici suplimentare (butonul Properties) pentru datele care se transfer (uzual, se importa doar tabelele HTML). Anumite interogri necesit specificarea unor parametri suplimentari.
Bibliografie [Connolly 2001] alt, Connolly T., Begg C., Strachan A., Baze de date. Proiectare. Implementare. Gestionare, Editura Teora, Bucureti, 2001 [Codd, 1982] Codd E. F., Relational Database: A Practical Foundation for Productivity, Commun. ACM 25(2): 109-117, 1982 [Doll, 1998] Dollinger R., Baze de date i gestiunea tranzaciilor, Ediia a II-a, Grupul microINFORMATICA, ClujNapoca, 1998 [Florescu &alt, 2002] Florescu V., Nstase P., Berbec F., Baze de date. Fundamente teoretice i practice., Grupul BDASEIG, Editura InfoMega, Bucureti, 2002 [Georgescu &alt, Georgescu C., Georgescu M., Baze de date relaionale 2005] i multidimensionale, Editura Didactic i Pedagogic R.A., Bucureti, 2005 [Lungu & alt, 1995] Lungu I., Sabu Gh., Bodea C., Surcel Tr., Sisteme informatice pentru conducere, Editura Siaj, Bucureti, 1995 [Lungu & alt, 2003] Lungu I., Sabau Gh., Velicanu M., Muntean M., Ionescu S., Posdarie E., Sandu D., Sisteme informatice. Analiz, proiectare i implementare, Editura Economic, Bucureti, 2003
&

Baze de Date

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Baze de Date

Încărcat de

Drepturi de autor:

Formate disponibile

Gabriela Vrlan, Baze de date, Note de curs I

Anul II, semestrul

GABRIELA VRLAN Cristina Gabriela Zamfir Maria Cristina Enache

BAZE DE DATE - suport de curs -

Editura Universitar Danubius Galai 2009

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Tabel Rnd Coloan

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Fig. 1.3. Structura unei tabele dintr-o baz de date

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Fig. 1.5. Tehnologii fundamentale utilizate pentru gestiunea datelor

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Fig. 2.2. Model conceptual

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I

Copyright 2009 Universitatea Danubius. Toate drepturile rezervate

Gabriela Vrlan, Baze de date, Note de curs

Anul II, semestrul I