UNIVERSITATEA DIN BACAU

FACULTATEA DE ŞTIINŢE

BAZE DE DATE

Conf. univ.dr. ELENA NECHITA

2010

Prezentarea cursului

Informaţiile din lumea ce ne înconjoară sunt structurate în diverse moduri.

Adesea structura o impunem sau o chiar inventăm noi în procesul de memorare, în

încercarea de a transforma informaţiile cu care suntem bombardaţi în cunoştinţe.

Sistemul de structurare a datelor care intervine cel mai frecvent este tabelul, iar în

cazul volumelor mari vorbim despre baze de date.

Procesul de instruire în societatea noastră tot mai informatizată, în aşa numita

Societate Informaţională, impune tot mai mult structurarea cunoştinţelor acumulate,

capacitatea de a le organiza, clasifica, regăsi şi mai ales completa. Vorbim despre

managementul cunoştinţelor, un capitol important atât al ontologiei, cât şi al

informaticii. Putem spune că disciplina "Baze de Date" se ocupă cu câteva din

mecanismele de gestiune a informaţiilor şi a cunoştinţelor.

Căutările pe World Wide Web, modul în care apelăm la motoarele de căutare

şi modul în care acestea lucrează şi au fost concepute, toate au de a face cu

conceptele şi procedeele de lucru cu Baze de Date. Motoarele de căutare sunt, în

fond, nişte instrumente de căutare a informaţiilor într-o imensă bază de date, care

este actualizată continuu, pe măsură ce apar noi pagini Web. Marile motoare de

căutare, Google sau Yahoo, folosesc adevărate "ferme" de servere pe care menţin

aceste imense baze de date, astfel încât noi să obţinem răspunsul în câteva clipe.

Acest curs are drept scop prezentarea elementelor fundamentale despre

baze de date, a conceptelor cu care se lucrează în acest domeniu şi a modalităţilor

de prelucrare a datelor organizate în baze de date.

Obiectivele cursului

4

Principalele obiective ale cursului sunt:

1. Însuşirea cunoştinţelor de bază referitoare la modul de proiectare şi de

programare a bazelor de date.

2. Familiarizarea cu modelul Entitate/Asociere şi cu modelul relaţional.

3. Studiul algebrei relaţionale, ca suport pentru prelucările realizate în baze de date

relaţionale.

4. Studiul dependenţelor funcţionale şi al formelor normale, în scopul optimizării

stocării datelor în bazele de date.

5. Prezentarea unor noţiuni referitoare la limbajele utilizate în domeniul bazelor de

date.

Sunt necesare cunoştinţe anterioare de matematică, programarea

calculatoarelor, structuri de date şi algoritmi, limbaje de programare (C, C++).

Cerinţe de examinare

Pentru evaluare se vor realiza următoarele activităţi:

1. Însuşirea cunoştinţelor teoretice din suportul de curs.

2. Participarea la orele de laborator. Se vor da două teste, în săptămânile a 7-a şi

a 13-a. Este necesar ca la fiecare să se obţină cel puţin nota 5.

3. Se va realiza un proiect, individual sau în echipă.

4. Examenul va consta într-un test de verificare a cunoştinţelor teoretice.

5. Nota acordată va fi media notelor obţinute la teste, la proiect şi la test.

5

CUPRINS

Prezentarea cursului 3Obiectivele cursului. Cerinţe de examinare 4

1. Introducere în domeniul bazelor de date 71.1 Informaţii. Date. Colecţii de date 71.2 Organizări ale datelor 9

1.2.1 Organizarea datelor în fişiere 91.2.2 Organizarea datelor în baze de date 11

1.3 Conceptul de bază de date 111.4 Sisteme de gestiune a bazelor de date 12

2. Niveluri de reprezentare a unei baze de date 142.1 Modelarea conceptuală 14

2.1.1 Modelul Entitate - Asociere 142.1.2 Diagrama Entitate - Asociere 16

2.2. Modele de date 162.2.1 Modelul ierarhic 162.2.2 Modelul reţea 17

3. Modelul relaţional 193.1 Conceptele modelului relaţional 203.2 Sisteme de gestiune a bazelor de date relaţionale 21

4. Noi funcţionalităţi ale bazelor de date 224.1 Partajarea bazelor de date 224.2 Baze de date distribuite 224.3 Baze de date deductive 244.4 Baze de date multidimensionale 244.5 Baze de date orientate obiecte 244.6 Alte tipuri de baze de date 264.7 Sisteme Client / Server 264.8 Bazele de date şi sistemele informaţionale din organizaţii 27

5. Forme normale. Normalizare 295.1 Dependenţe funcţionale 29

5.1.1 Descompunerea 295.1.2 Asocierile şi proiectarea schemelor 30

5.2 Dependenţe multivaloare 305.3 Forme normale ale bazelor de date 31

5.3.1. Date ne-normalizate 315.3.2 Prima formă normală (FN1) 325.3.3 A doua formă normală (FN2) 325.3.4 A treia formă normală (FN3) 335.3.5 Forma normală Boyce-Codd (FNBC) 345.3.6 A patra formă normală (FN4) 345.3.7 A cincea formă normală (FN5) 355.3.8. Procesul normalizării relaţiilor 36

6. Limbaje utilizate în lucrul cu baze de date 37

6

6.1 Limbajul de definire a datelor pentru modelul relaţional 376.2 Limbajul de manipulare a datelor pentru modelul relaţional 38

6.2.1 Algebra Relaţională 386.2.2 SQL 426.2.3 Calculul Relaţional orientat pe tupluri 426.2.4 Calculul Relaţional orientat pe domenii 43

7. Restricţiile de integritate ale modelului relaţional 447.1 Restricţii de integritate minimale 447.2 Alte restricţii de integritate 457.3 Aspecte privind integritatea 46

8. Depozite de date (Data warehouse) 478.1. Concepte de bază în data warehouse 478.2. Diferenţe înte bazele de date şi depozitele de date 488.3. Arhitectura depozitelor de date 49

9. Baze de cunoştinţe 54

10. Aplicaţii Access 5610.1. Bază de date pentru activităţi şcolare 5610.2. Bază de date pentru o activitate comercială 7410.3. Bază de date pentru gestiunea unui parc auto 8510.4. Bază de date pentru contabilitatea TVA 99

11. Teste 11111.1 Testul 1 11111.2 Testul 2 11311.3 Testul 3 11511.4 Testul 4 11711.5 Testul 5 12011.6 Testul 6 12211.7 Testul 7 124

Bibliografie 125

7

„Order is not sufficient. What is required, is something

much more complex. It is order entering upon novelty; so that the massiveness of order

does not degenerate into mere repetition; and so that the novelty

is always reflected upon a background of system.''

(Alfred North Whitehead)

1. Introducere în domeniul bazelor de date

1.1 Informaţii. Date. Colecţii de date

Informaţiile şi cunoştinţele au o mare importanţă, atât pentru dezvoltarea personalităţii umane, cât şi pentru evoluţia vieţii şi societăţii. Nici societatea şi nici indivizii ei nu pot progresa satisfăcător în lipsă de informaţii. Prin intermediul informaţiilor se asigură transferul cunoştinţelor de la o generaţie la alta, se asigură accesul la cele mai avansate realizări ale omenirii.

Conceptul de informaţie reprezintă o noţiune de maximă generalitate care semnifică o comunicare, o veste, o ştire, un mesaj, un semnal etc. despre evenimente, fapte, stări, obiecte, despre forme de manifestare a realităţii care ne inconjoară. Informaţia reprezintă cantitatea de noutate adusă de un mesaj din lumea reală.

Informaţia, energia şi materia sunt cei mai importanţi factori ai economiei moderne pe lângă pământ, capital şi forţa de muncă. Faţă de materie, informaţia prezintă caracteristici distincte:

Se poate combina aproape nelimitat. Este puternic condensabilă. Se percepe ca o anumită măsură a ordinii, întrucât ea anihilează incertitudinea şi

nedeterminarea. O măsură a ordonării este entropia negativă, tremen care a luat naştere prin analogie cu entropia, care este, în termodinamică, o măsură (exprimabilă matematic) a neordonării.

Calitatea unei informaţii constă în gradul de probabilitate cu care creează utilizatorului certitudinea unei afirmaţii.

Oamenii ajung la informaţii direct, prin intermediul altor oameni sau prin purtători de informaţie, precum ziare, cărţi, imagini, videocasete, CD-uri, discuri sau echipamente de comunicaţie (radio, televizor, fax, telefon sau calculator).

Deci informaţia reprezintă o componentă esenţială a lumii reale, ce face posibilă caracterizarea diferitelor elemente ale naturii (fiinţe, obiecte, stări, fenomene) şi permite comunicarea.

Din punct de vedere conceptual, informaţia reprezintă o reflectare în planul gândirii umane a legăturilor de cauzalitate, privind aspecte din realitatea ce ne înconjoară. Informaţia are deci sens de noutate pentru cel căruia i se adresează, indiferent de forma pe care o ia (ştire, semnal, comunicare). Putem spune deci că informaţia este un mesaj, dar cu precizarea că nu orice mesaj este o informaţie. Dacă mesajul nu transmite o noutate şi nu are suport real, atunci nu prezintă interes pentru receptor şi deci nu are caracter de informaţie.

Informaţia primeşte totdeauna atributul domeniului pe care îl reprezintă. De exemplu, realităţile din domeniul economic se reflectă în informaţii economice.

Procesul de sesizare, înţelegere şi însuşire a informaţiilor dintr-un anumit domeniu reprezintă un proces de informare. Informaţiile dobândite în urma unui proces de informare într-un anumit domeniu formează cunoştinţele despre acel domeniu, iar mulţimea acestora reprezintă baza de cunoştinţe.

Cunoştinţele reprezintă deci o însumare a tuturor informaţiilor dobândite într-un anumit domeniu, sau care se referă la un anumit obiect. În sinteză, putem aprecia

8

cunoştinţele că sunt elemente abstracte şi individuale despre obiectele şi domeniile lumii reale, însuşite şi/sau dobândite.

Aproape orice activitate are şi o latură informaţională. De exemplu, în paralel cu procesul de producere de bunuri şi servicii se desfăşoară şi un proces informaţional, constând din fluxuri de documente prin care se ţine evidenţa activităţii desfăşurate.

Atunci când informaţia este gestionată cu ajutorul tehnicii de calcul, ea devine dată. Data este forma de reprezentare accesibilă a informaţiei prelucrate. Ea reprezintă

suportul formal al informaţiei, care se concretizează în: cifre, litere, simboluri, coduri şi alte însemne. Există o corespondenţă determinată între informaţie, simbol şi dată astfel că, foarte adesea, în practică, termenul de informaţie este utilizat pentru a desemna date, iar expresia „prelucrarea informaţiilor” înlocuieşte expresia „prelucrarea datelor”. Putem considera că datele prelucrate, în măsura în care afectează în sens pozitiv comportamentul receptorilor (oameni sau maşini), au calitatea de informaţii.

În procesul prelucrării şi utilizării informaţiilor, acestea sunt privite din patru puncte de vedere:

Din punct de vedere sintactic, atunci când se urmăreşte aspectul admisibil al acestora, în sensul că informaţiile trebuie să capete anumite forme de reprezentare, ce respectă riguros anumite reguli.

Din punct de vedere semantic, urmărindu-se semnificaţia, înţelesul informaţiei (conţinutul real al informaţiei) ce derivă din datele prelucrate.

Din punct de vedere pragmatic, urmărindu-se utilitatea pentru receptori, efectul asupra acestora (măsura în care acestea satisfac cerinţele utilizatorului).

Din punct de vedere sigmatic, se tratează raportul dintre semne şi obiecte, caz în care se poate vorbi despre cunoştinţe obiective. În locuri publice, semnalizarea şi direcţionarea cu ajutorul indicatoarelor trebuie să fie atât sugestivă, compactă, cât şi independentă de limbă sau cultură. Pictogramele pentru indicarea cabinelor telefonice, zonelor de fumători, ghişeelor de informaţii sau punctelor medicale reprezintă cunoştinţe obiective.

Datele reprezintă aşadar informaţii care fac obiectul prelucrării pe sistemele de calcul şi pot fi:

Elementare (numite şi simple sau scalare) – atunci când sunt indivizibile în raport cu prelucrările la care pot fi supuse.

Compuse (numite şi complexe) – atunci când sunt alcătuite din mai multe date elementare, deci sunt la rândul lor divizibile în date mai simple.

Exemplu. În cazul unei persoane: vârsta, înălţimea, greutatea, codul numeric personal sunt date elementare. Domiciliul (format din oraş, stradă, număr) este o dată compusă.Observaţie. O dată poate fi considerată elementară dintr-un punct de vedere şi compusă din altul, aceasta în funcţie de prelucrările necesare.

Unei date i se atribuie un nume – identificatorul său, prin intermediul căreia ea se distinge de celelalte şi prin care poate fi adresată. O caracteristică de bază a unei date este tipul său. Acesta determină modul în care data respectivă va fi memorată pe suporturi de memorare şi modul în care ea va fi prelucrată (adică operatorii şi funcţiile ce i se pot aplica). În cadrul unui limbaj de programare, de exemplu, există o serie de tipuri de date de bază (elementare), prestabilite de către proiectanţii limbajului şi, de cele mai multe ori, există posibilitatea definirii de noi tipuri, prin combinarea celor elementare. Marea majoritate a limbajelor permit manipularea datelor numerice (întregi şi reale), a caracterelor şi şirurilor de caractere, a tablourilor uni- şi multi-dimensionale.

O colecţie de date reuneşte date despre o anume clasă de obiecte (reale sau conceptuale). Exemplu. Colecţia de date prezentată mai jos reuneşte date cu privire la clasa de obiecte denumită CONTURI:

Cod_cont Denumire_cont101 Capital social104 Prime legate de capital105 Diferenţe din reevaluare106 Rezerve…

933 Costul producţiei în curs de execuţie

9

Fiecare obiect de acest tip are o existenţa proprie şi este bine definit de aceleaşi caracteristici, respectiv codul contului şi denumirea contului. Contul cu codul 101 şi denumirea Capital social constituie o realizare sau o instanţă a obiectului tip CONTURI, pentru care caracteristicile Cod_cont, Denumire_cont iau valorile 101 şi respectiv Capital social.

Alte exemple. Datele referitoare la materialele dintr-un depozit. Datele referitoare la cărţile dintr-o bibliotecă. Datele referitoare la pacienţii unui spital. Datele ce descriu situaţia contabilă a unei firme.

Omogenitatea datelor dintr-o colecţie de date trebuie înţeleasă în sens larg, sub forma unei proprietăţi comune sau a unui obiectiv urmărit.

Noţiunile de informaţie şi dată sunt, prin urmare, diferite. Informaţiile sunt înţelese de o persoană, în timp ce datele sunt modele stocate pe un mediu pasiv, ca de exemplu discul hard al unui calculator. Scopul unui sistem care gestionează o colecţie de date este să reducă distanţa între informaţii şi date – astfel, datele stocate în memoria sau pe discurile unui calculator să fie convertite în informaţii utilizabile la momentul dorit.

1.2 Organizări ale datelor

Organizarea datelor în vederea prelucrării lor cu calculatorul este o activitate tot atât de importantă ca şi cea de realizare a programelor. Datele şi programele se găsesc într-o strânsă corelaţie. Un program, oricât de complex ar fi, nu va furniza rezultate satisfăcătoare dacă structura datelor cu care lucrează nu este bine gândită. Invers, o structură de date bine pusă la punct nu va fi suficientă, dacă programul care o prelucrează nu este corect conceput şi realizat.

Din punct de vedere informatic ne putem referi la două tipuri de organizare a datelor: Organizarea in memoria internă a calculatorului şi Organizarea în memoria externă.

Organizarea în memoria externă a cunoscut, de-a lungul timpului, mai multe stadii: Fişiere şi Baze de date.

1.2.1 Organizarea datelor în fişiere

Un fişier este un ansamblu de înregistrări fizice, omogene din punct de vedere al conţinutului şi al prelucrării. O înregistrare fizică este formată din una sau mai multe înregistrări logice, o înregistrare logică fiind un ansamblu de câmpuri care conţin date referitoare la un obiect, proces sau fenomen din lumea reală.

Exemplu. Fişierul de date STOCURI conţine date privind stocurile de produse. Pentru fiecare produs se memorează: codul, denumirea, unitatea de măsură, preţul de referinţă şi cantitatea aflată în stoc. Iată (schematic reprezentată) o înregistrare logică pentru un produs aflat în stoc:

401 TV PANASONIC BUC 1000 20

Înregistrările privind produsele aflate în stoc sunt memorate pe suporturi tehnice şi formează, împreună, fişierul STOCURI_PRODUSE.

Există două metode de organizare a datelor în fişiere: Organizare secvenţială – înregistrările sunt memorate pe suport tehnic în

ordinea introducerii datelor şi sunt accesate în ordinea în care ele sunt memorate.

Organizarea indexată – la memorarea înregistrărilor pe suport tehnic, Sistemul de Gestiune a Fişierelor creează, separat, un tabel în care, pentru fiecare înregistrare de date, sunt memorate două elemente: cheia de

10

identificare a înregistrarii şi adresa la care înregistrarea este memorată pe suport tehnic.

Exemplu. Tabel cu indecşi

Înregistrări de date

350 A1 A2 401 TV PANASONIC BUC 1000 20401 A2 A1 350 RADIO SAMSUNG BUC 100 30420 A3 A3 420 VIDEO SAMSUNG BUC 900 10… … … … … …

A1 reprezintă adresa (care face referire, în cazul HD, la cilindru, pistă şi sector) la care este memorată înregistrarea cu valoarea din câmpul de indexare (aici codul produsului) cu valoarea 350, ş.a.m.d.

Tabelul cu indecşi permite astfel localizarea rapidă a înregistrărilor pe suportul tehnic. Această metodă presupune existenţa unui atribut ale cărui valori să permită identificarea înregistrărilor. Acest atribut are rolul de cheie de identificare (indexare).

Deci, un fişier de date este bine definit când se precizează identificatorul de fişier, structura înregistrării şi modul de organizare.

Exemplu. Fişierul: STOCURIStructura înregistrării:

CodMat, numericDenMat, TextUM, TextPretRef, NumericCantStoc, Numeric

Organizare: indexatăCheie identificare: CodMat

Limite ale organizării datelor în fişiere Descrierea datelor se afce în fiecare program în care ele sunt utilizate; spunem că

datele sunt dependente de programe. Lipsa unui formalism riguros de definire şi validare a datelor. Performanţe scăzute pentru procesarea datelor, îndeosebi când este necesar să se

facă asocieri între date memorate în fişiere distincte. Menţinerea unei redundanţe ridicate în cadrul colecţiilor de date memorate pe

suporturi tehnice.

Deci abordarea tradiţională asocia fiecărei aplicaţii informatice propriile fişiere. În mod evident, anumite date se regăseau în fişierele asociate mai multor aplicaţii. Schematic, această metodă poate fi reprezentată astfel:

Această abordare ducea la memorarea repetată a unor date şi implicit la un volum mare de memorie externă ocupată.

De exemplu, dacă într-o fabrică se folosesc materiale pentru realizarea unor produse, atunci datele necesar a fi memorate pentru fiecare material sunt (cel puţin) cele menţinate în cazul fişierului STOCURI:

11

Pn

…P1 P2

Cod – un cod asociat fiecărui material, necesar identificării acestuia şi altfel decât prin nume (de exemplu: 5289);

Denumire – denumirea materialului (de exemplu: lemn de brad); Um – unitatea de măsură (de exemplu: mc, aici, metru cub); Preţ – este vorba de preţul unitar (preţul pentru un metru cub de lemn de brad); Cantitate – cantitatea existentă la un moment dat în fabrică.

Aceste date şi altele, specifice, vor fi prelucrate pentru diferite compartimente: aprovizionare (pentru recepţia materialului), gestiune (păstrarea într-o magazie), producţie (consumul materialului respectiv în procesul de producţie), contabilitate (pentru calculaţia costului produselor finite). Deci cel puţin patru programe ar utiliza aceste date şi ar fi prin urmare dezavantajoasă memorarea lor pe un suport fizic (în diferite fişiere) de tot atâtea ori.

Cu toate aceste limite, organizarea datelor în fişiere mai este utilizată şi astăzi, îndeosebi pentru aplicaţii dezvoltate folosind limbajele clasice de programare.

Progresele în domeniul tehnologiilor informaţionale au marcat o creştere considerabilă a capacităţii de memorare a suporturilor tehnice de date şi a vitezei de procesare a datelor. La acestea se adaugă şi posibilitatea stocării şi procesării datelor netradiţionale cum ar fi, de exemplu, imaginea şi sunetul (a se vedea [Tod04]).

1.2.2 Organizarea datelor în baze de date

Limitele organizării datelor în fişiere şi posibilităţile oferite de noile tehnologii informaţionale au dus la promovarea metodei de organizare a datelor în baze de date. Ideea a fost de a colecta toate datele, a le organiza într-un mod convenabil (specific realităţii pe care acele date le modelează) şi a proiecta programe care să consulte şi să actualizeze această colecţie de date. Schematic, această abordare se poate reprezenta astfel:

Prin urmare, o bază de date se defineşte ca fiind un ansamblu de date elementare sau structurate, accesibile unei comunităţi de utilizatori. O definiţie mai apropiată de reprezentarea fizică ar fi cea conform căreia o bază de date este un ansamblu de fişiere intercorelate, care conţin nucleul de date necesare unei aplicaţii informatice complexe.

Astfel, în figura precedentă, legăturile desenate între fişiere reprezintă aceste intercorelări (adică, fişierele corelate modelează o legătură logică între datele pe care le conţin) iar aplicaţiile ce accesează datele pot fi privite ca aparţinând la diferiţi utilizatori sau grupuri de utilizatori, care „văd” baza de date într-un mod propriu (cu alte cuvinte, accesează din toată colecţia de date ceea ce le este necesar).

1.3 Conceptul de bază de date

În lucrarea Bases de données et systèmes relationnels, Dunod Informatique, Paris, 1982, C. Delobel şi M. Adiba definesc baza de date astfel:

Baza de date este un ansamblu structurat de date înregistrate pe suporturi accesibile de către calculator pentru a satisface, chiar simultan, mai mulţi utilizatori, de o manieră selectivă şi în timp oportun.

12

P2

P1 Pn

Bază de date

Într-o bază de date sunt înregistrate date despre obiecte reale sau abstracte, dar şi asocierile (relaţiile) care se pot stabili între acestea. Spunem că între datele unei baze de date există o interdependenţă logică. Considerarea interdependenţelor ce se pot stabili între colecţiile de date memorate într-o bază de date contribuie la asigurarea integrităţii funcţionale a bazei de date.

O bază de date este un model al unui sistem real. Conţinutul unei baze de date (numit uneori şi extensie) reprezintă, la un moment dat, o stare a sistemului care se modelează. Schimbările în baza de date reprezintă evenimente care au loc în mediu şi care schimbă starea sistemului modelat. Este evident că este de dorit să structurăm o bază de date astfel încât aceasta să oglindească sistemul care se doreşte modelat.

Obiective fundamentale ale unei baze de date Centralizarea datelor. Permite controlul centralizat al datelor şi eliminarea repetărilor

(numite redundanţe). O eliminare totală a redundanţelor nu este posibilă, dar controlul asupra lor duce la o utilizare eficientă a spaţiului de memorie externă.

Independenţa între date şi prelucrări. Baza de date, fiind un model al unei realităţi, se schimbă mereu (de exemplu, într-o bancă au loc: numeroase tranzacţii financiare, schimbări de personal, schimbări de parteneri de afaceri etc.). Acest lucru nu trebuie să afecteze programele de prelucrare a datelor şi invers, dacă este necesară operarea de schimbări în anumite programe, datele nu trebuie să fie afectate.

Realizarea de legături între date. Datele ce reprezintă modelul unui sistem nu sunt disparate, între ele există legături logice. Aceste legături vor fi surprinse în baza de date.

Integritatea datelor. Asigură fiabilitatea şi coerenţa bazei de date. Securitatea datelor. Baza de date trebuie să fie protejată împotriva distrugerilor

logice (greşeli la actualizare) şi/sau fizice (deteriorări ale suporţilor fizici, pierderi de date datorate unor accidente naturale (calamităţi, incendii etc.).

Confidenţialitatea datelor. Se referă la caracterul secret al datelor, ce pot fi accesate doar de către cei autorizaţi.

Partajarea datelor. Permite deservirea utilizatorilor care accesează simultan aceleaşi date din bază.

1.4 Sisteme de gestiune a bazelor de date

Sistemul de programe care permite construirea unei baze de date, introducerea informaţiilor în baza de date şi dezvoltarea de aplicaţii se numeşte sistem de gestiune a bazei de date (pe scurt, SGBD). Un SGBD dă utilizatorului posibilitatea să aibă acces la date folosind un limbaj de nivel înalt, adică apropiat de modul obişnuit de exprimare, pentru a obţine informaţii. Nu este necesar ca utilizatorul să cunoască modul în care sunt selectate datele pe care le doreşte, ori modul de memorare al lor. Spunem de aceea că SGBD-ul este o interfaţă între utilizatori şi baza de date, un instrument de asamblare, codificare, aranjare, protecţie şi regăsire a datelor în baza de date.

Principalele funcţii ale unui SGBD Memorarea datelor pe suportul extern (prin intermediul sistemului de gestiune a

fişierelor); Gestiunea datelor şi a legăturilor dintre acestea, în vederea unei regăsiri rapide

prin intermediul sistemului de acces; Introducerea şi extragerea datelor din/spre exterior, în forma cerută de utilizator.

SGBD-ul poate prelucra mai multe cereri, provenind de la mai multe programe de aplicaţii. Totodată, majoritatea SGBD-urilor asigură şi controlul transmisiei datelor la şi de la terminale. SGBD-ul pune la dispoziţia utilizatorilor limbaje distincte pentru:

Descrierea bazei de date: Limbajul de Descriere a Datelor (LDD). Utilizarea (manipularea) bazei de date: Limbajul de Manipulare a Datelor

(LMD).Limbajele de manipulare (interogare) a bazelor de date pot fi:

Declarative – permit utilizatorului să declare de CE informaţii are nevoie. Procedurale – care obligă utilizatorul să descrie CUM obţine informaţiile.

13

Realizarea pe plan mondial a unor reţele de calculatoare care permit conectarea mai multor baze de date a condus la apariţia bazelor de date distribuite şi, implicit, la apariţia SGBD pentru astfel de baze. Bazele de date distribuite reprezintă un salt calitativ superior în acest domeniu, oferind noi perspective pentru realizarea sistemelor informatice. Un sistem de baze de date distribuite este o colecţie de baze de date locale, amplasate geografic în puncte diferite şi legate logic prin relaţii funcţionale, astfel încât apar, la nivel global, ca o singură bază de date.

În funcţie de modul în care exploatează baza de date, utilizatorii pot fi împărţiţi în următoarele clase:

Utilizatorii obişnuiţi, care pot să obţină informaţiile dorite fără să aibă cunoştinţe de programare, prin comenzi cunoscute şi eventual răspunzând la diferitele opţiuni pe care le indică sistemul la un moment dat.

Programatorii de aplicaţii, care realizează programele ce vor fi memorate şi ulterior lansate în execuţie de utilizatori prin invocarea numelui asociat lor.

Administratorul bazei de date, care stabileşte structura iniţială a bazei de date şi modul de memorare a datelor la nivel fizic, acordă utilizatorilor drepturi de acces la bază sau la părţi ale ei, stabileşte condiţiile pentru asigurarea securităţii şi integrităţii datelor, modifică structura bazei atunci când este nevoie, asigură întreţinerea bazei făcând periodic copii şi reconstruind baza de date în cazul în care au apărut erori datorate componentelor soft, hard sau utilizării şi răspunde, în general, de modul de utilizare al bazei de date.

Cele mai multe SGBD-uri conţin şi o colecţie de utilitare folosite în diferite aplicaţii: procesoare pentru limbaje de cereri, editoare de rapoarte, sisteme de reprezentări grafice, posibilităţi de lucru cu tabele, programe statistice, de copiere, generatoare de aplicaţii şi alte posibilităţi de dezvoltare a unor aplicaţii de tip CASE (computer-aided software engineering).

Pentru a facilita munca administratorului de sistem, un SGBD conţine o serie de componente care permit: crearea unei versiuni iniţiale a bazei, salvarea şi reîncărcarea (efectuarea de copii periodice şi posibilitatea refacerii bazei plecând de la aceste copii), reorganizarea (rearanjarea datelor în scopul îmbunătăţirii unor performanţe), statistici şi analize asupra exploatării bazei de date.

Evoluţia tehnologiilor informaţionale face ca în prezent majoritatea SGBD-urilor: Să gestioneze date tradiţionale, dar şi date netradiţionale (video, foto, sunet

etc.). Să permită lucrul în reţea de calculatoare. Sa pună la dispoziţia utilizatorului atât limbaje declarative, cât şi limbaje

procedurale.

Materiale introductive privind domeniul bazelor de date:

Cursuri generale de baze de date:

1. www.cs.washington.edu/education/courses/444/98wi2. www.albany.edu/acc/courses/acc682.fall98/3. www.cs.umbc.edu/461/461.shtml4. www-db.stanford/edu/~ulmann/fcdb.html5. www.developer.com/db/article.php/7190416. www.servicearchitecture.com/database/articles

7. webmonkey.wired.com/webmonkey/backend/databases/tutorial/tutorial1.htmlDespre alegerea sistemului potrivit de baze de date

8. [Bas97]Tipuri de organizare a fişierelor şi metode de căutare în fişiereDescrierea unor SGBD-uri de tipuri diferite

14

2. Niveluri de reprezentare a unei baze de date

Bazele de date pot fi analizate pe diferite nivele: Nivelul conceptual – ce corespunde modelelor semantice de date – este un model „de

nivel înalt”, specific omului şi nu sistemelor de calcul. Nivelul aplicaţie – ce poate fi privit, la rândul său, din două puncte de vedere:

Logic – referitor la organizarea datelor, organizare prin care se implementează o anumită cantitate de informaţie şi

Fizic – referitor la stocarea efectivă a informaţiei (grupare, partiţionare, indexare, etc.)

2.1 Modelarea conceptuală

Nivelul conceptual ne permite să modelăm aplicaţiile în termeni independenţi de orice model de date particular. Este un instrument convenabil care ne permite să structurăm o bază de date astfel încât aceasta să evolueze în timp odată cu mediul modelat, cu necesităţile utilizatorilor şi cu schimbările care apar privind cererile de informaţie. Modelele conceptuale furnizează un mediu pentru dezvoltarea structurii unei baze de date într-o manieră de sus în jos (top-down). Cel mai utilizat model conceptual este Modelul Entitate - Asociere.

2.1.1 Modelul Entitate - Asociere

Modelul entitate-asociere este un instrument pentru analiza acelor aspecte semantice ale unei aplicaţii, care sunt independente de evenimente. Modelul entitate-asociere reduce redundanţa datelor. Aceasta abordare utilizează urmăytoarele notaţii grafice: dreptunghiuri pentru entităţi, romburi pentru asocieri (relaţii) şi cercuri sau elipse pentru atribute. Pentru situaţii complexe, o diagramă entitate-asociere parţială (care nu include detalii depre atribute) poate fi utilizată pentru a prezenta o sinteză a entităţilor şi relaţiilor.

Diagrama entitate-asociere furnizează o metodă eficientă pentru vizualizarea legăturilor între entităţi, pentru o aplicaţie dată. Aceast instrument s-a dovedit util pentru a face tranziţia de la desrierea unei aplicaţii la o schemă formală a bazei de date. Modelul entitate-asociere este astfel realizat fără a fi necesară atenţia asupra proiectării fizice a bazei de date. Diagramele entitate-asociere sunt ulterior transformate într-o schemă conceptuală în unul din modelele în care baza de date se va implementa efectiv.

În continuare sunt prezentate definiţiile unor termeni de bază utilizaţi pentru descrierea conceptelor importante ale modelului entitate-asociere.

Entitate - O entitate este un obiect concret sau abstract care poate fi clar delimitat în mediu.

o Instanţă de entitate -  O instanţă este o apariţie particulară a unei entităti. De exemplu, fiecare persoană în parte poate fi o instanţă a unei entităţi PERSOANE, fiecare maşină în parte poate fi o instanţă a unei entităţi MAŞINI, etc. 

o Tip de entitate – Un grup de entităţi similare poartă numele de clasă de entităţi sau tip de entitate. O clasă de entităţi are proprietăţi comune.

Atribute – Atributele descriu proprietăţile entităţilor şi relaţiilor şi pot fi: o Simple (scalare) – sunt cele mai mici unităţi semantice de date, atomice

(fără structură internă), de exemplu: oraşul. o Compuse – reprezintă grupuri de atribute privite unitar, de exemplu: adresa

(stradă, număr, oraş, cod poştal ).o Multivaluate (liste) - reprezintă valori multiple, de exemplu: note, cursuri,

etc.

» Domeniile – sunt mulţimile de definiţie ale atributelor:

15

mulţimi precizate de valori scalare de acelaşi tip sau mulţimi de valori posibile.

Relaţiile – O relaţie este o legătură între două clase de entitate.De examplu, o relaţie între entităţile PERSOANE şi MAŞINI poate fi cea de „proprietate” (automobilele sunt în proprietatea oamenilor).

o Gradul unei relaţii indică numărul de entităţi implicate în relaţie. o Cardinalitatea unei relaţii indică numărul de instanţe din clasa de entităţi E1

care poate sau trebuie asociată cu instanţe din clasa de entităţi E2: Relaţii 1-1 (One to One relationship) – Pentru fiecare entitate dintr-

o clasă există cel mult o entitate asociată în cealaltă clasă. De exemplu, fiecare persoană are un card de identitate (şi există copii, care încă nu au).

Relaţii 1-n (One to Many relationships) – O entitate din clasa E2 este asociată cu zero sau mai multe entităţi din clasa E1, dar fiecărei entităţi din E1 i se asociază cel mult o entitate în E2.  De exemplu, o femeie poate avea mai mulţi copii dar orice copil are o singură mamă.

Relaţii m-n (Many to Many relationships) – Nu există restricţii asupra numărului de entităţi dintr-o clasă, ce pot fi asociate cu o entitate din cealaltă clasă. De exemplu, relaţia între studenţi şi cursuri. Fiecare student merge la mai multe cursuri şi fiecare curs are mai mulţi studenţi.

Poate fi obligatorie, opţională sau fixată.o Ierarhiile Isa („Is a”) – reprezintă un tip special de relaţie ce permite

moştenirea atributelor. De exemplu, a spune că un camion este un automobil şi un automobil are un fabricant, un model şi un număr de serie implică faptul că un camion are, de asemenea, un fabricant, un model şi un număr de serie.

Cheile – Cheile identifică în mod unic o entitate de alta, într-o clasă de entităţi. o Cheia primară – Identificator utilizat pentru a identifica în mod unic o instanţă

particulară a unei entităţi. Poate fi reprezentată de unul sau mai multe atribute. Trebuie să fie unică în domeniul său (şi nu doar în setul de date

curent). Valorile sale nu se schimbă în timp. Trebuie să aibă totdeauna o valoare. Poate fi creată când nu este evident nici un atribut. Fiecărei instanţe i

se asociază o valoare. o Cheie candidată – Când există mai multe chei primare posibile, fiecare este

o cheie candidată.o Cheie concatenată – Este o cheie realizată din componente care, atunci

când sunt considerate împreună, identifică în mod unic entitatea. Cheile atribute multiple sunt chei concatenate.

o Atribute cheie împrumutate – dacă există o relaţie isa, cheia clasei mai generale este, de asemenea, o cheie pentru subclasă. De exemplu, dacă numărul de serie pentru automobile este cheie, va fi cheie şi pentru camioane.

o Chei secundare – Referă un tabel aflat în relaţie, prin cheia primară a acelui tabel.

» Restricţia de integritate referenţială – Pentru fiecare valoare a unei chei secundare, există o cheie primară cu acea valoare în tabelul referit. De exemplu, dacă un număr de cont se utilizează într-un tabel pentru intrări, atunci numărul de cont trebuie să existe tabelul cu numerele de cont.

Evenimente – Evenimentele schimbă entităţile şi/sau relaţiile.

2.1.2 Diagrama Entitate - Asociere

Simbolurile utilizate în diagrama entitate – asociere includ:

16

Dreptunghiuri – Reprezintă clasele (tipurile) de entitate. Cercuri – reprezintă atributele. Romburi – reprezintă relaţiile. Arce – Au rolul de a conecta entităţile prin relaţii şi, de asemenea, de a conecta

atributele la entităţi. Unele modele de diagramă entitate – asociere utilizează săgeţi sau săgeţi duble pentru a indica diferitele tipuri de relaţii.

Sublinierea – Atributele cheie ale entităţilor sunt subliniate.

Iată un fragment dintr-o diagramă entitate – asociere:

2.2. Modele de date

Principalele clase de modele logice utilizate în gestiunea bazelor de date sunt următoarele:

Modelul ierarhic Modelul reţea Modelul relaţional.

Un alt model care trebuie menţionat este modelul punctual. O bază de date cu un singur fişier (tabel) reprezintă o structură punctuală. O astfel de structură este utilă doar în cazuri extrem de simple, pentru cele mai multe aplicaţii din domeniul economic fiind insuficientă. Multe procesoare de tabele includ facilităţi de baze de date, cum ar fi sortarea, numărarea sau filtrarea datelor care satisfac anumite criterii. Toate facilităţile de baze de date incluse în procesoarele de tabele se referă la structura punctuală.

În cele ce urmează se vor prezenta pe scurt primele două modele, detaliind într-un capitol separat modelul relaţional care este, în prezent, cel mai utilizat.

2.2.1 Modelul ierarhic

Modelul de date ierarhic este o colecţie de structuri arborescente, fiind fondat pe reprezentarea arborescentă a schemei conceptuale a bazei de date, în care nodurile reprezintă clasele de obiecte, iar arcele – legăturile între acestea. Modelul ierarhic este, prin urmare, un “arbore” de înregistrări în care fiecare înregistrare conţine două elemente

rădăcină sau un câmp master (o cheie), care identifică tipul, locaţia sau ordinea înregistrărilor

câmpurile subordonate, ce reprezintă restul datelor dintr-o înregistrare Toate câmpurile au numai un nod părinte, fiecare nod părinte putând avea mai mulţi fii. Operaţiile din bazele de date de tip ierarhic se traduc în procese de parcurgere a arborilor.

Avantaje: viteză şi eficienţă pentru anumite tipuri de aplicaţii. Modelul ierarhic este o alegere bună atunci când datele au o structură naturală de arbore. Astfel de aplicaţii pot fi, de exemplu, inventarele, sistemele de documentare bibliografice, unele sisteme de luare a deciziilor şi de gestionare de tip ierarhic, sistemele de informare şi operare bazate pe lucrul cu meniuri şi altele asemănătoare.

Probleme: modul de definire a datelor este predefinit; fiecare asociere trebuie să fie definită explicit, la crearea bazei de date.

Modelul ierarhic este un caz special al modelului reţea. Cel mai cunoscut SGBD de tip ierarhic este IMS (Information Management System) de la IBM. A fost construit în 1968 în scopul prelucrării datelor din industria aerospaţială. Iniţial a fost un sistem pur ierarhic, dar a căpătat unele trăsături non-ierarhice, ca rezultat al necesităţilor practice.

17

Primesc

Tip de entitate Relaţie Tip de entitate

1 N

Cod Nume Adr. Codf Data Val.

CLIENŢI FACTURI

Exemplu. Structura arborescentă prezentată în continuare se referă la o bază de date a unei

agenţii de vânzări de locuinţe:

JUDETE (NUMER)OFICII (ORAS, ADROF)AGENTI (NUMEA, VANZARI)ANGAJAT (NR_AN, NUMEAN, ADRAN, SALARIU)OFERTE (ADROF, PRET)CLIENTI (NUMEC, ADRC)

şi poate fi descrisă prin următoarea succesiune de instrucţiuni în SGBD IMS:

TREE AGENTIERECORD JUDETE ROOT

NUMER CHAR(20)RECORD OFICII PARENT=JUDETE

ORAS CHAR(20)ADROF CHAR(30)

RECORD AGENTI PARENT=OFICIINUMEA CHAR(20)VANZARI INTEGER

RECORD ANGAJAT PARENT=OFICIINR_AN INTEGERNUMEAN CHAR(20)ADRAN CHAR(30)SALARIU INTEGER

RECORD OFERTE PARENT=OFICIIADROF CHAR(30)PRET INTEGER

RECORD CLIENTI PARENT=AGENTINUMEC CHAR(20)ADRC CHAR(30)

2.2.2 Modelul reţea

Modelul de date reţea este cel mai apropiat de forma de reprezentare a bazelor de date sub forma diagramelor entitate-asociere. Deosebirea constă doar în faptul că toate relaţiile ce apar pot fi numai binare şi de tipul 1-1 sau 1-n. Această restricţie permite reprezentarea grafică a unei baze de tip reţea sub forma unui orientat numit reţea. În acest graf, nodurile corespund entităţilor iar relaţiile sunt reprezentate prin săgeţi de la tată la fiu şi anume: săgeţi simple dacă relaţia este de tip 1-1 şi săgeţi duble dacă relaţia este de tip 1-n. Iată câteva caracteristici ale modelului reţea:

Crează asocieri între date printr-o listă de legături în care înregistrările subordonate (membre) pot fi legate la mai mult de un element (proprietar).  Un element poate fi parte a mai multor asocieri.

Pointer – legătură explicită, păstrând adrese ce conţin locaţia înregistrării asociate.

Complexitate – pentru fiecare mulţime de elemente asociate trebuie păstrată o pereche de pointeri. Utilizănd acest model, este dificil să se structureze, din punct de vedere conceptual, structuri de date complexe.

Viteză – legăturile directe conduc la viteze de lucru mari ale sistemelor care implementează modelul reţea.

Exemplu.SGBD SOCRATE este de tip reţea, fiind totodată şi unul din primele sisteme de

gestiune a bazelor de date. A fost realizat de firma CII în colaborare cu ECA-Automation pentru sisteme de tip IRIS, fiind folosit şi în ţara noastră pe vechile sisteme de tip Felix. Sistemul conţine un limbaj de descriere pentru date (identificarea datelor, a proprietăţilor lor şi

18

eventual a criteriilor de validare), un limbaj de cereri, un macrogenerator (pentru generarea unor macrocomenzi care permit utilizarea produsului şi de către nespecialişti), un modul de metode de acces (care permite utilizarea unor programe de accesare a datelor scrise în diverse limbaje de programare), un editor de texte (pentru gestionarea textelor programelor şi a celor din baza de date), componente pentru asigurarea securităţii şi confidenţialităţii datelor din bază, pentru reorganizarea bazei şi alte programe utilitare. Poate lucra atât autonom, conţinând toate elementele necesare funcţionării sale, cât şi ca metodă de acces, fiind deschis prin interfeţe pentru a putea funcţiona împreună cu alte programe. Poate opera atât programabil cât şi conversaţional. În al doilea caz, poate lucra în regim multiutilizator.

Materiale privind modelarea:

1. http://www.utexas.edu/its/windows/database/datamodeling/rm/rm7.htmlCurs de iniţiere in modelarea datelor la University of Texas at Austin

Despre modelele ierarhic şi reţea:

2. http://unixspace.com/context/databases.html3. www.ittia.com/dbstar/whitepapers/technicalmodel.pdf4. www.staff.brad.ac.uk/ckarazai/Lecture3.pdf

Despre modelul entitate-asociere:

5. www.campus.ncl.ac.uk/databases/design/design.html6. http://databases.about.com/od/Specificproducts7. http://ycmi.med.yale.edu/nadkarni/IntroductiontoEAVSystems.htm8. http://wofford.org/ecs/DataAudVisualization/ermodel/material.htm

19

3. Modelul relaţional

În modelul relaţional, baza de date este reprezentată de un grup de tabele corelate. Modelul relaţional a fost propus în 1970 de către cercetătorul american E.F. Codd, în lucrarea „A relational model of large shared data banks” şi este, în prezent, cel mai popular model. Simplitatea matematică şi uşurinţa vizualizării modelului relaţional au contribuit la succesul acestuia. În plus, modelul relaţional de date nu este legat de un tip anume de structură de date (cum este, de exemplu, modelul ierarhic).

Modelul relaţional se bazează pe teoria matematică a relaţiilor.Formal, o relaţie n-ară R pe domeniile X1, X2, …,Xn este o submulţime a produsului

cartezian X1xX2x … xXn şi se noteazăR(X1,X2, …,Xn).

X1, X2, …,Xn se mai numesc constituenţi.

Exemplu. Fie o întreprindere şi clasa de obiecte „autoturisme fabricate în întreprindere”. Fiecare produs are ca atribute: codul produsului, denumirea produsului şi preţul de referinţă. Să considerăm datele ce caracterizează împreună un anume produs:

1555, OPEL VECTRA, 150001555 reprezintă codul, OPEL VECTRA reprezintă numele iar 15000, preţul. Datele reprezintă valori ale atributelor, valori ce se plasează într-un domeniu de definiţie corespunzător. Domeniul de definiţie se poate preciza implicit sau explicit. În acest caz, atributului „preţ de referinţă” i se atribuie valori în mulţimea numerelor întregi. Dacă preţurile autoturismelor fabricate au valori cuprinse între 10000 şi 30000, atunci domeniul de definiţie se poate preciza ca fiind secvenţa numerelor între 10000 şi 30000.

Este important ca pentru fiecare atribut să se cunoască domeniul de definiţie, deoarece la introducerea datelor în baza de date nu vor fi acceptate decât datele care reprezintă valori plasate în domeniile de definiţie ale atributelor. Validarea datelor la introducere poate fi foarte complexă, având ca obiectiv asigurarea integrităţii datelor.

Ansamblul valorilor afectate atributelor pentru un obiect real sau abstract din domeniul supus studiului formează un tuplu (sau o realizare, sau o înregistrare de date). Tuplurile unei relaţii trebuie să fie unice. Se observă că datele pot fi organizate, în mod eficient, într-un tabel. Dealtfel, organizarea tabelară este foarte mult folosită în practică. Tuplurile vor fi liniile tabelului, în timp ce atributele sunt regăsite pe coloane. Ordinea liniilor şi coloanelor nu prezintă nici o importanţă.

Validarea datelor la nivelul realizării unei relaţii înseamnă, în plus, respectarea regulilor de integritate stabilite la nivel de relaţie.

Exemplu. Pentru relaţia SALARIAT, cu atributele: Maca, Nume, Data_nasterii, Data_angajarii. La nivelul acestei relaţii se poate stabili regula de integritate:

An(Data_angajarii)>=An(Data_nasterii)+18.

Regulile pentru asigurarea integrităţii datelor pot viza şi asocieri ce se stabilesc între realizări ale relaţiilor din baza de date.

Exemplu. O relizare a relaţiei „facturi de la furnizori” se asociază cu o realizare a relaţiei „furnizori”. Nu se pot înregistra datele dintr-o factură, dacă anterior nu s-a inregistrat, în baza de date, furnizorul. Acesta este un exemplu de regulă de integritate referenţială a bazei de date.

Dintre cele trei modele de baze de date prezentate, modelul relaţional se impune prin: simplitate, structuri de date simple, operatori simpli (fără mari diferenţe între sisteme), mecanismul vederilor, o bază teoretică solidă, un număr mic de concepte, aplicarea principiului dualităţii accesului (prin program şi interactiv), independenţa fizică a datelor, independenţa logică a datelor, uşurinţa dezvoltării aplicaţiilor, a instalării şi operării, simplificarea proiectării bazelor de date, integrarea dicţionarelor, posibilitatea dezvoltării bazelor de date distribuite, performanţe şi posibilităţi de extindere.

20

3.1 Conceptele modelului relaţional

Conceptele modelului relaţional sunt prezentate în următoarea sinteză:

Relaţie - Un tabel (bidimensional). Relaţia însăşi corespunde noţiunii noastre obişnuite de tabel. O relaţie este deci o colecţie de tuple (termenul vine de la „t-uplu”, notaţie folosită şi în matematică, adică o succesiune de t elemente), fiecare conţinând valori ale unui număr fix de atribute. Relaţiile mai sunt uneori referite şi ca fişiere, din cauza asemanării lor cu o secvenţă nestructurată de articole. Fiecare tuplu al unei relaţii trebuie să fie unic (deci, nu există duplicate).

Atribut – Este o coloană a tabelului. Alţi termeni utilizaţi în mod obişnuit pentru atribut sunt proprietate şi câmp. Mulţimea valorilor permise pentru fiecare atribut se numeşte domeniul acelui atribut.

Tuplu – Este un rând al tabelului. Un tuplu este o instanţă a unei entităţi sau asocieri.

Cheie – Un singur atribut sau o combinaţie de atribute ale căror valori identifică în mod unic tuplurile relaţiei. Deci, fiecare rând are o valoare diferită pentru atributul cheie. Modelul relaţional cere ca fiecare relaţie să aibă o cheie astfel încât:

o Oricare două tupluri nu pot avea aceiaşi valoare a cheiio Fiecare tuplu trebuie să aibă o valoare pentru atributul cheie (câmpurile cheie

nu pot avea valori nenule).

Există două restricţii ale modelului relaţional care, în practică, sunt uneori nerespectate:1. Nu sunt permise tupluri duplicate. Dacă sunt introduse două tuple cu aceeaşi

valoare pentru fiecare din atribute, ele de fapt sunt considerate a fi acelaşi tuplu. Această restricţie este uneori rezolvată prin asignarea unui număr de linie (sau de tuplu) unic pentru fiecare intrare, ceea ce asigură unicitatea.

2. Nu se presupune nici o ordine a tuplurilor în cadrul relaţiei. În practică, totuşi, se foloseşte desori o metodă de ordonare a tuplurilor.

Exemplu de extensie a unei relaţii:

Atribut saucâmp saucoloană

Numele atributelor sunt parte a schemei COD_CLIENT NUME ADRESĂ CREDIT_LIMITĂ

19283 ELBAC S.A. Şos. Oituz 34 300000000

Tuplu sauÎnregistrare saurând

35231 SUBEX S.A. Şos. Iaşului 12 500000000

34567 MICROSISTEM S.A.

Şos. Alba 23 250000000

Există următoarea distincţie între schema unei relaţii şi extensia unei relaţii.Schema este „cadrul” pentru relaţie. Ea defineşte relaţia, adică:

Numărul atributelor Numele atributelor şi domeniile acestora Atributul cheie primară

Extensia relaţiei este conţinutul relaţiei, adică mulţimea tuplurilor care formează relaţia. Extensia unei relaţii poate varia foarte mult în timp, dar schema este stabilă. Antetele coloanelor din figura de mai sus pot fi privite ca o parte a schemei, iar tuplurile de sub antete, ca fiind extensia.

21

În termeni conceptuali, o relaţie este o structură care păstrează valori ale atributelor unei clase particulare de entităţi, sau ale unei clase particulare de asocieri. Exemplul reprezintă o relaţie ce descrie membrii unei clase de entitate numită CLIENŢI. Relaţiile pot, de asemenea, să descrie asocieri.

Observaţie. A nu se confunda, din cauza omonimiei, relaţia, care este o construcţie la nivel de date a modelului relaţional, cu asocierea (pentru care se foloseşte şi termenul de relaţie), care este o noţiune la nivel conceptual.

În relaţia CLIENŢI, cheia pentru fiecare realizare de entitate este păstrată în atributul COD_CLIENT. Cheile compuse sunt folosite, de obicei, în cazul asocierilor. De exemplu, dacă am crea o relaţie care să reprezinte asocierea dintre studenţi şi cursuri am avea nevoie de o cheie, care ar putea fi combinaţia dintre cheia pentru studenţi şi cheia pentru cursuri.

Următoarele reguli permit (în cele mai multe cazuri) conversia unei diagrame entitate-asociere într-o schemă relaţională:

Este necesară câte o relaţie (tabel) pentru fiecare clasă de entităţi şi fiecare relaţie de tip m-n;

Nu sunt necesare relaţii pentru a reprezenta relataţiile de tip 1-1 sau 1-n; Când se construieşte o relaţie (tabel) pentru reprezentarea unei asocieri m-n,

cheia trebuie să conţină toate atributele cheie ale relaţiilor implicate.

Exemplul din 10.1 reprezintă un model relaţional.

3.2 Sisteme de gestiune a bazelor de date relaţionale

Bazele de date la organizarea cărora se utilizează modelul relaţional se numesc baze de date relaţionale (BDR). SGBD-urile care permit gestiune bazelor de date relaţionale se numesc sisteme de gestiune a bazelor de date relaţionale (SGBDR).

Dintre sistemele de gestiune a bazelor de date relaţionale menţionăm: Visual Fox, Access, Db2, Oracle, Informix. Unele dintre aceste SGBDR-uri au interfeţe proprii pentru interogarea bazelor de date relaţionale, toate implementând limbajul standard SQL. Multe SGBDR-uri fac obiectul unor extinderi, pentru a fi adaptate noilor cerinţe, cum ar fi: orientarea obiect, analiza multidimensională, sisteme expert, sisteme multimedia, sisteme client-server.

Pentru gestiunea bazelor de date de dimensiuni mari (cu înregistrări ce depăşesc ordinul sutelor de mii) se recomandă utilizarea unor sisteme de gestiune a bazelor de date performante, cum ar fi Oracle, SQL Server şi Informix. Având in vedere performanţele oferite pentru gestiunea bazelor de date relaţionale dar şi necesităţile didactice, în cadrul acestui curs vom prezenta aplicaţii realizate în Access.

Materiale privind modelul relaţional:

1. [Fel96]Despre bazele de date relaţionale

2. http://databases.about.com/compute/databases/mbody.htmDespre baze de date în general, cu informaţii despre modelul relaţional

3. http://www.sqlmag.com/Articles/Index.cfm?ArticleID=5113SQL. Despre alegerea cheii primare

4. http://www.acm.org/classics/nov95/Extrase din lucrarea lui Codd privind modelul relaţional

22

4. Noi funcţionalităţi ale bazelor de date

4.1 Partajarea bazelor de date

În condiţiile lucrului în reţea, este posibil să se stocheze baza de date pe un calculator ce are rol de server. Toţi utilizatorii de la posturile de lucru pot accede simultan la baza de date; ei partajează baza de date.

Lucrul în sistem multiutilizator impune rezolvarea unor probleme care vizează: asigurarea integrităţii datelor (îndeosebi în cazul în care doi sau mai mulţi utilizatori

vor să realizeze în acelaşi timp operaţii de actualizare a bazei de date); asigurarea confidenţialităţii datelor; prevederea unor mecanisme de protecţie împotriva unor operaţii neautorizate, care

vizează îndeosebi modificarea structurii unor componente ale bazei de date;Administratorul bazei de date are sarcini privind:

modelarea datelor implementarea bazei de date definirea utilizatorilor şi a drepturilor de acces întreţinerea bazei de date.

Drepturile de acces la nivel de utilizator vizează operaţiile pe care aceştia le pot realiza. Se poate merge până la detalii, precizând chiar tabelele la care un anume utilizator va avea acces.

În practica dezvoltării sistemelor cu baze de date se poate opta pentru dezvoltarea unor interfeţe de acces la baze de date partajate la nivel de utilizator / grup de utilizatori (fiecare interfaţă utilizează, de regulă, numai tabele ale bazei de date ce este stocată pe server).

4.2 Baze de date distribuite

În numeroase situaţii bazele de date sunt dispersate geografic – se spune că sunt distribuite (BDD). O bază de date distribuită permite ca o colecţie arbitrară de relaţii, dintr-o colecţie arbitrară de baze de date, , aflate pe o mare varietate de maşini ce lucrează sub diverse sisteme de operare şi sunt legate prin diferite reţele de comunicaţie, să poată fi utilizate ca şi cum ar fi o singură bază de date pe o singură maşină.

Principalele cerinţe pe care trebuie să le asigure un sistem de baze distribuite sunt: autonomia locală în organizarea şi prelucrarea datelor, posibilitatea de lucru continuu al nodurilor, independent de schimbările în configuraţiile de lucru (adăugări sau eliminări de noduri), independenţa localizării şi fragmentării datelor (transparenţa fizică), posibilităţi de replicare (copiere) şi independenţa copiilor, prelucrarea distribuită a cererilor, administrarea distribuită a tranzacţiilor, independenţa de hardware, de sistem de operare, de reţea şi de SGBD.

Exemplu. Considerăm o bancă ce are filiale în 20 de localităţi. Fiecare agenţie posedă un sistem de calcul propriu şi propria bază de date (bază de date locală). Banca centrală posedă, de asemenea, un sistem de calcul pentru prelucrarea ansamblului datelor de la toate filialele. Tranzacţiile efectuate in conturi pot fi locale sau globale. Să presupunem că de la filiala din Constanţaa băncii se face o depunere de 20 000 lei în contul cu numărul 456 al persoanei X. Dacă persoana X a deschis contul la filiala din Constanţa, tranzacţia este locală. Dacă persoana X are contul deschis la filiala din Bucureşti, tranzacţia este considerată globală. Fiecare filială are acces la baza de date a unei alte filiale pentru realizarea unui set finit de operaţii.

Lucrul în reţele de calculatoare permite distribuirea unei baze de date, din punct de vedere fizic, pe mai multe site-uri. Fiecare site găzduieşte un sistem local de gestiune a bazelor de date. Utilizatorii unui site au acces la baza de date locală şi, în plus, la bazele de date distribuite în celelalte site-uri. Conexiunile între site-uri pot fi stabilite în diverse maniere.

23

Topologiile de racordare (stea, inel, combinate) se prezintă sub formă de grafuri, ale căror noduri corespund site-urilor. Un utilizator particular va folosi baza de date fără să facă referiri concrete şi fără să se preocupe de locul unde aceasta este memorată fizic.

Figura următoare prezintă o posibilă arhitectură pentru baza de date distribuită a unei bănci:

În cazul unei întreprinderi s-ar putea opta pentru soluţia unei baze de date distribuite pe funcţii, ca în figura următoare:

Există mai multe arhitecturi pentru baze de date distribuite: Cu replicare – diversele site-uri stochează o copie a bazei de date. Cu fragmentare – baza de date este fragmentată, iar fiecare fragment este găzduit de

către un site. Fragmentarea poate fi: orizontală, verticală sau mixtă. Cu replicare şi fragmentare.

Sistemele cu baze de date distribuite comportă două subsisteme: Gestionarul de tranzacţii - a cărui funcţie este de a gestiona tranzacţiile relative la

datele site-ului; fiecare tranzacţie poate fi locală (executabilă integral în cadrul site-ului) sau poate să facă parte dintr-o tranzacţie globală (interesând mai multe site-uri);

Coordonatorul tranzacţiilor – al cărui rol este de a coordona executarea diverselor tranzacţii (locale sau globale); el trebuie să execute un protocol da validare a tranzacţiei.

Avantaje. Avantajele repartizării bazelor de date sunt: partajarea datelor şi gestiunea distribuită a acestora; fiabilitatea şi disponibilitatea; prelucrarea accelerată a cererilor.

Principala dificultate în dezvoltarea sistemelor cu baze de date distributive provine din necesitatea de a coordona ansamblul site-urilor. Un sistem cu baza de date distribuită ridică problemele specifice sistemelor multiutilizator, la care se adaugă cele ale distribuirii bazelor de date.

4.3 Baze de date deductive

Centru regional 1

Centru regional 2

Centru regional N…

Centre regionalecu Mainframe

LANAgenţia 1

LANAgenţia M

LANAgenţia 2 …

Gestiunearesurselor materiale

Gestiuneaproducţiei

Contabilitateşi control de gestiune

Gestiunearesurselor umane

şi a salariilor

Infrastructurăpentru

comunicaţie

24

Bazele de date deductive se fundamentează pe cuplarea unei baze de date relaţionale cu un procesor din clasa sistemelor expert. În figura următoare se prezintă o arhitectură simplificată a unei baze de date deductive.

Se vor prezenta detalii în capitolul 9.

4.4 Baze de date multidimensionale

Bazele de date multidimensionale au apărut ca urmare a necesităţilor crescânde de procesare multidimensională a datelor. Aplicaţiile care se bazează pe analiza multidimensională a datelor sunt cunoscute sub numele de OLAP (On Line Analytical Processing). Se face astfel distincţie între:

OLTP (On Line Transactional Processing) - care privilegiază: integritatea şi securitatea datelor şi tratarea cererilor informaţionale simple de către servicii operaţionale (producţie, comercial, resurse umane etc.) şi

OLAP – care privilegiază: analiza şi manipularea datelor folosind cereri complexe, în vederea elaborării strategiei şi sunt destinate îndeosebi conducerii şi controlului de gestiune.

Conceptul de bază este cel de hipercub, ilustrat în figura următoare:

Datele se regăsesc la intersecţia liniilor marcate pe hipercub şi au pentru coordonate atributele ce definesc dimensiunile hipercubului. Hipercubul din figura de mai sus poate fi utilizat, de exemplu, pentru a reprezenta date despre vânzări pe trei dimensiuni:

dimensiunea localitate; dimensiunea produs; dimensiunea timp (lunile anului).

4.5 Baze de date orientate obiecte

Deşi succesul SGBDR-urilor în dezvoltarea aplicaţiilor economice este încă destul de mare, ele prezintă şi anumite limite.

Este vorba, în primul rând, de faptul că pentru orice aplicaţie informatică se delimitează net trei domenii:

interfaţa; datele; prelucrările.

Tehnologia orientată „pe obiecte” reduce cele trei formalisme la unul singur: obiectul.

INTERFAŢA

InterpretorPROLOG

SGBDR

4

25

Aplicarea tehnologiei orientate obiect în domeniul bazelor de date a determinat apariţia bazelor de date orientate pe obiecte. Primele baze de date orientate pe obiecte au apărut la sfârşitul anilor '80, dar nu au atins un nivel de dezvoltare prea ridicat, datorită:

lipsei produselor CASE, care să permită o proiectare corectă; limbajelor de interogare, care erau deficitare; faptului că nu existau standarde acceptate.

O bază de date orientată pe obiecte trebuie să îndeplinească două cerinţe fundamentale: să îndeplinească cerinţele unei baze de date; să fie un sistem care să aibă la bază tehnologia orientată obiect.

Un obiect poate fi definit ca reuniune „într-o aceeaşi capsulă” a unui ansamblu de date şi a prelucrărilor (standard) asociate (următoarea figură). Încapsularea este reuniunea definiţiei statice a unui obiect prin atributele sale şi definirea dinamică a acestui obiect (cu ajutorul regulilor de comportament). Aceste reguli sunt traduse cu ajutorul metodelor, care reprezintă prelucrările asociate obiectelor. Obiectele sunt caracterizate printr-o structură şi o interfaţă. Structura obiectului este reperată printr-un identificator intern unic şi posedă o stare care regrupează în general atribute cu datele de tratat. Interfaţa unui obiect este compusă din selectorul de metode (partea vizibilă a obiectului). Structura este cunoscută numai de către obiect. Un obiect nu poate fi manipulat decât via metodele asociate.

Multe dintre obiectele manipulate posedă în comun aceeaşi structură şi acelaşi comportament. O clasă descrie obiectele care au caracteristici statice şi dinamice comune.

Exemple.

Super-Clasa PersoanaAtribute Nume

AdresaDataNasterii

Metode Nume

Returneaza(Self.Nume) Adresa

Returneaza(Self.Adresa) DataNasterii Returneaza(Self.DataNasterii)

Clasa SalariatAtribute SalariuIncadrare LocMunca ResponsabilMetode SalariuIncadrare

Returneaza(Self.SalariuIncadrare) NumeResponsabil

Returneaza(Self.NumeResponsabil)

Descrierea dinamică(modele de prelucrare)

Descrierea statică(modele de date)

Date

Obiect

26

O clasă (clasă derivată) poate moşteni de la o altă clasă (clasa de bază) atribute şi metode. În exemplul de mai sus, clasa Salariat moşteneşte atributele şi metodele clasei Persoana.

Tehnica moştenirii permite împărţirea eficace a anumitor cunoştinţe despre obiecte pentru a obţine o reprezentare mai bogată în semantică. Datele cele mai generale se grupează în clase care sunt în continuare specializate în subclase ce comportă atribute şi comportamente din ce în ce mai particulare. La nivelul cel mai înalt va exista o superclasă obiect de la care toate celelalte moştenesc (atribute, metode).

Clasa Salariat moşteneşte atributele, selectorii şi metodele superclasei Persoana. Ea posedă în plus atribute şi metode proprii. Realizările clasei Salariat pot fi utilizate ca realizări ale clasei Persoana şi pot poseda proprietăţi suplimentare.

Obiectele definite se integrează în sistem şi prezintă conexiuni cu alte obiecte. Aceste conexiuni sunt materializate prin mesaje pe care obiectele le schimbă între ele. Aplicarea unei metode la un obiect corespunde cu trimiterea unui mesaj. Receptorul mesajului se numeşte Self.

Bazele de date orientate pe obiecte (BDOO) sunt gestionate folosind sisteme de gestiune orientate pe obiecte (SGOO).

Principala caracteristică a BDOO este viteza de acces la date (în comparaţie cu celelalte tipuri de Baze de date). Acest acces este asigurat prin intermediul unei hărţi a ierarhiilor şi relaţiilor claselor de obiecte, pe care BDOO o stochează. De asemenea, permit gruparea sau partiţionarea fizică a datelor, tehnică numită clustering. BDOO asigură accesarea eficientă a obiectelor necesare la un moment dat unei cereri utilizator, minimizând traficul prin reţea.

Domeniile în care este eficientă utilizarea BDOO sunt:- simularea si modelarea diferitelor fenomene şi procese- administrarea documentelor- proiectele CASE (Computer Aided Software Engineering), CAD (Computer Aided

Design), CAM (Computer Aided Manufacturing), CAE (Computer Aided Engineering)- multimedia- ingineria cunoaşterii.

4.6 Alte tipuri de baze de date

Bazele de date textuale gestionează documente electronice. Principalele operaţii asigurate sunt: stocarea, căutarea, modificarea şi asamblarea de documente şi alte informaţii stocate cu titlu de date textuale în aceste baze de date.

Bazele de date multimedia extind aria de gestiune incluzând îndeosebi imagini, sunete, etc.

4.7 Sisteme Client / Server

Sistemele Client/Server se fondează pe partajarea sarcinilor între două entităţi: server şi client. Tehnologia client/server presupune două aplicaţii (următoarea figură):

serverul, care furnizează diverse servicii; clientul, care este beneficiarul serviciilor oferite de server.

Cele mai răspândite aplicaţii client/server sunt cele cu baze de date; soft-ul pentru baza de date este executat pe calculatorul server, iar programul care accesează baza de date pe un calculator client.

4.8 Bazele de date şi sistemele informaţionale din organizaţii

Aplicaţie client Aplicaţie serverCerere

Răspuns

27

Bazele de date constituie componenta centrală a sistemelor informaţionale din întreprinderi, în cadrul reprezentat în figura următoare:

unde notaţiile reprezintă: SIT – sisteme informaţionale tranzacţionale (sisteme informaţionale operaţionale); SLIC - sisteme de lucru bazate pe informaţie şi cunştinţe; SIIO - sisteme informaţionale interorganizaţionale (multe dintre aceste sisteme sunt

de tip tranzacţional); SISE - sisteme informaţionale suport pentru executiv SIM - sisteme informaţionale pentru management, care includ:

o SIAD - sisteme informaţionale de asistare a deciziei şio SIR sistemele imformaţionale de raportare.

Bazele de date sunt alimentate în principal de sistemele operaţionale şi sistemele interorganizaţionale (sisteme de comerţ electronic, sisteme de plăţi electronice etc.) şi sunt accesate de sistemele de management şi de sistemele suport pentru executiv. Ele pot fi, de asemenea, accesate de sistemele de lucru bazate pe informaţie şi cunoştinţe (cum ar fi, spre exemplu, sistemele expert). Structurile funcţionale şi de conducere din întreprinderi impun organizarea de sisteme de baze de date care „comunică” între ele.

În figura următoare prezentăm o viziune (conform J. O’Brien, Les systèmes d’information de gestion, 1995) a principalelor tipuri de baze de date utilizate de către organizaţii şi utilizatori.

Materiale privind funcţionalităţile moderne ale bazelor de date:

SLICSISE

SIT

SIMSIADSIR

BD

SIIO

Post de lucru alutilizatorului Server

de Baze dedate

BD externe

BDdistribuită

Depozite dedate

BDoperaţionaleBD

individuală

28

1. www.extropia.com/tutorials/sql/toc.htmlIntroducere în domeniul bazelor de date, pentru dezvoltatorii de web

2. http://www.service-architecture.com/object-oriented-databases/Articole despre bazele de date orientate obiect şi produse pentru acestea

Despre baze de date multimedia

3. http://sunsite.berkeley.edu/Imaging/Databases/4. [Tod04]

29

5. Forme normale. Normalizare

5.1 Dependenţe funcţionale

Atributul Y este dependent funcţional de atributul X dacă şi numai dacă fiecare valoare a atributului X este asociată cu exact o valoare a atributului Y. Se spune că X este determinant al lui Y, sau că X determină pe Y şi se notează X→Y.

Asocierile 1-1 prezintă două dependenţe funcţionale. De exemplu, între numele unei persoane şi codul său numeric personal există o dependenţă 1-1, cele două atribute determinându-se reciproc.

Asocierile 1-n prezintă o dependenţă funcţională. De exemplu, între numele unui student şi numărul său matricol: un număr matricol se asociază exact unui student; dar mai mulţi studenţi pot avea acelaşi nume, astfel că un nume poate avea mai multe numere matricole asociate.

Asocierile m-n nu prezintă dependenţe funcţionale. De exemplu, între studenţi şi cursuri există o corespondenţă de acest tip: fiecare student poate urma mai multe cursuri şi fiecare curs poate avea mai multi studenţi, fără a se observa vreo corelaţie între valori, în sensul definiţiei dependenţei funcţionale.

Utilizatorul care proiectează o aplicaţie determină dependenţele funcţionale examinând mediul real. Deseori dependenţele înglobează anumite restricţii referitoare la aplicaţia respectivă. Este o problemă de convenţie, de exemplu, ca un student să poată urma mai multe cursuri, dar nu dintre cele care au loc în acelaşi interval de timp. Sau, ca un student să aibă un singur număr matricol şi ca un număr matricol să poată fi asociat unui singur student.

5.1.1 Descompunerea

Termenul descompunere se referă la faptul că informaţia inclusă într-o relaţie poate fi splitată în două sau mai multe relaţii separate, fiecare dintre acestea având mai puţine atribute decât relaţia originală. Cu alte cuvinte, atributele sunt plasate în tabele diferite. Tuplele din noile relaţii vor fi determinate de atributele incluse. Scopurile descompunerii unei relaţii sunt:

Să reducă redundanţa datelor. Să păstreze capacitatea de a recrea relaţia originală, fără a pierde tupluri sau a

adăuga noi tupluri.

Procesul recreării tabelului original se numeşte uniune sau joncţiune (join). A se vedea 6.2.1.

Exemplu. În exemplul de mai jos sunt prezentate tabelele iniţiale, precum şi rezultatul operaţiei join pe atributul Profesie.

Persoane Calităţi Rezultatul operaţiei join

Nume Profesie Profesie Calitate Nume Profesie Calitate

Andrei inginer inginer pragmatism Andrei inginer pragmatism

Carmen profesor profesor tact Carmen profesor tact

Silvia inginer pilot curaj Silvia inginer pragmatism

30

Traian pilot Traian pilot curaj

Este important ca descompunerile ce se realizează într-o bază de date să aibă loc fără pierderi de informaţie, căci în caz contrar, informaţia trebuie restaurată.

5.1.2 Asocierile şi proiectarea schemelor

Eleganţa matematică a modelului relaţional suportă o teorie a proiectării schemelor. Teoria indică, într-o anumită măsură, ce structuri au probleme potenţiale şi ar trebui evitate. Teoria normalizării oferă multe elemente foarte utile în procesul de proiectare a bazelor de date.

După cum am observat deja, asocierile între datele aparţinând la două domenii, fie acestea A şi B, se pot clasifica în trei categorii:

asocieri 1-1 asocieri n-1 asocieri n-m

Vom ilustra fiecare tip de asociere în contextul unui exemplu.

Asocierile 1-1 sunt acelea în care fiecărui element din A i se pune în corespondenţă un unic element din B şi reciproc. De exemplu, fiecare student are un număr matricol şi fiecare număr matricol se asignează unui singur student. Tabelul următor prezintă o astfel de asociere:

Număr matricol Nume student21350 Ionescu Alina21351 Mircea Diana21576 Traian Alexandru21577 Miron Vladimir… …

Vom nota sintetic: Număr matricol (1-1) Nume student

Într-o asociere n-1, fiecărui element din B i se asociază un unic element din A, dar fiecărui element din A i se pot asocia mai multe elemente din B. De exemplu, dacă plecăm de la ipoteza că un student nu poate urma decât o specializare, atunci: un student urmează o specializare, dar o specializare are mai mulţi studenţi. Aceasta este o relaţie n-1 între studenţi şi specializări (sau 1-n între specializări şi studenţi). Tabelul următor prezintă o astfel de asociere:

Număr matricol Specializare21350 Informatică21351 Informatică21576 Biologie21577 Biologie… …

Vom nota sintetic: Număr matricol (n-1) Specializare

Asocierile n-m sunt acelea în care nici unui element nu i se asociază un singur partener. O astfel de relaţie este cea între studenţi şi cursuri. Fiecare student urmează mai multe cursuri, iar fiecare curs are mai mulţi studenţi. Nu există limite în ceea ce priveşte numărul partenerilor de asociere.

Vom nota sintetic: Număr matricol (n-m) Cursuri

31

5.2 Dependenţe multivaloare

Fie R o schemă relaţională, X şi Y submulţimi ale lui R. Spunem că există o dependenţă multivaloare a lui Y de X sau că X determină multivaloare pe Y şi notăm X→→Y dacă, pentru orice valoare a atributelor lui X sunt asociate valori pentru atributele lui Y care nu sunt corelate în nici un fel cu atributele din R-X-Y.

Exemplu. Fie relaţia

ORARCURS PROFESOR ORA LOCATIE STUDENT AN-STUDIU

Algebră Ionescu T. 10 A45 Miron Călin 1Algebră Ionescu T. 10 A45 Matei Ruxandra 1Programare Dinu A. 8 C9 Gruia Alina 2Programare Dinu A. 8 C9 Traian Maria 2Engleză Bontaş E. 16 C22 Miron Călin 1Engleză Bontaş E. 16 C22 Matei Ruxandra 1Engleză Bontaş E. 18 C22 Horia Anca 3

Se manifestă următoarele dependenţe funcţionale: CURS → PROFESOR (fiecare curs are un singur profesor) ORA, LOCATIE → CURS (la o oră dată, într-o anumită sală se poate ţine un singur curs) ORA, PROFESOR → LOCATIE (la o anumită oră, un profesor se poate afla în cel mult o

sală) CURS, STUDENT → AN-STUDIU (fiecare student urmează un curs într-un anumit an de

studiu) ORA, STUDENT → LOCATIE (fiecare student se poate afla în cel mult o sală, la un

moment dat).Au loc dependenţele multivaloare CURS →→ ORA, LOCATIE care semnifică faptul că fiecărui curs i se asociază o mulţime de perechi de ore şi săli care nu depind în nici un fel de celelalte informaţii. În schimb nu au loc, în general, dependenţele multivaloare CURS → ORA sau CURS → LOCATIE.

5.3 Forme normale ale bazelor de date

O formă normală se referă la o clasă de scheme relaţionale care se supun unui set de reguli. O schemă care satisface regulile corespunzătoare unui set se spune că este în forma normală respectivă. De obicei, proiectantul unei baze doreşte ca relaţiile să se afle în cât mai multe forme normale posibil.

5.3.1. Date ne-normalizate

Următorul tabel conţine date ne-normalizate. Coloanele 2, 3 şi 4 conţin liste de valori, iar coloana 5 conţine un atribut compus.

Listă Listă Listă Valori compuse

Legitimaţie Cod Calificări

Categorie Calificări

Profil Nume Vârstă Birou nr.

Oraş Superior

21 113 Sisteme 3 Mareş Ana

29 1 Iaşi Ion

35 113170200

SistemeTaxeAudit

574

IonescuDan

33 2 Bucureşti Damian

50 170 Taxe 3 Mircea Călin

35 2 Bucureşti Damian

32

77 150200

ConsultanţăAudit

58

Traian Raluca

28 1 Iaşi Ion

5.3.2 Prima formă normală (FN1)

O relaţie se prezintă în FN1 dacă valorile fiecărui câmp sunt ne-decompozabile (atomice) şi fiecare tuplu este unic. Atributele care se pot partiţiona în sub-atribute sau grupurile repetitive, care sunt foarte comune în bazele de date, nu sunt permise.

De exemplu, o persoană poate avea mai multe calificări. Dacă acestea sunt listate în acelaşi câmp (ca în tableul de mai sus), atunci relaţia nu se află în prima formă normală. La fel, dacă un câmp este comus, în genul unei adrese, formate din oraş, stradă, număr, cod poştal. Dacă un câmp este considerat structurat sau nu, aceasta depinde în mare măsură de aplicaţie. Dacă prelucrările nu necesită acces după oraş, sau stradă, sau cod poştal atunci este potrivit sa păstrăm aceste date într-un singur câmp, dar dacă este necesar să sortăm după unul din aceste elemente, de exemplu după cod poştal, atunci această abordare nu mai este potrivită.

Utilitatea FN1 este evidentă. Grupurile repetitive „strică” natura tabelară a relatie. Este dificil să se refere un element anume din grupul repetitiv, căci ar trebui specificată o informatie cu privire la poziţia sa în grup. Mai mult, diferite părţi ale atributului se pot comporta foarte diferit din punct de vedere al dependenţelor. Regula FN1 surprinde cerinţa naturală ca fiecare atribut să aibă propriul său nume. Următorul tabel prezintă datele tabelului anterior, structurate în FN1. În toate relaţiile ce vor fi prezentate, cheia primară este subliniată.

Legitimaţie

Cod Calificări

CategorieCalificări

Profil

NumePrenu

meVârstă

Birou nr.

Oraş Superior

21 113 Sisteme 3 Mareş Ana 29 1 Iaşi Ion35 113 Sisteme 5 Ionescu Dan 33 2 Bucureşti Damian35 170 Taxe 7 Ionescu Dan 33 2 Bucureşti Damian35 200 Audit 4 Ionescu Dan 33 2 Bucureşti Damian50 170 Taxe 3 Mircea Călin 35 2 Bucureşti Damian77 150 Consultanţa 5 Traian Raluca 28 1 Iaşi Ion77 200 Audit 8 Traian Raluca 28 1 Iaşi Ion

Informaţiile aflate doar în FN1 prezintă un înalt grad de redundanţă. Pentru a reduce redundanţa vom converti datele la a doua formă normală.

Formele normale mai mari decât FN1 au fost motivate de descoperirea anomaliilor, deci a operaţiilor pe relaţii din care rezultă inconsistenţe sau pierderi nedorite ale adtelor. Înlăturarea anomaliilor necesită trecerea progresivă prin diferite nivele ale formelor normale. Această transformare urmăreşte un ideal: fiecare informaţie care presupune asocieri între date să apară o singură dată în bază şi să nu depindă de prezenţa altor asocieri.

5.3.3 A doua formă normală (FN2)

O relaţie este în FN2 dacă este în FN1 şi toate atributele sale sunt dependente de întreaga cheie (adică, nici unul din atributele non-cheie nu este relaţionat doar cu o parte a cheii). Tehnica de descompunere pentru obţinerea FN2 este foarte simplă: presupune construirea unei relaţii separate care sa inglobeze dependenţele parţiale şi să înlăture atributele dependente din relaţia originală.

Pentru exemplul considerat, în urma eliminării dependenţelor parţiale s-au obţinut următoarele trei relaţii.

Relaţia CADRE:Legitimaţie

NumePrenu

meVârstă

Birou

Oraş Superior

33

nr.

21 Mareş Ana 29 1 Iaşi Ion35 Ionescu Dan 33 2 Bucureşti Damian50 Mircea Călin 35 2 Bucureşti Damian77 Traian Raluca 28 1 Iaşi Ion

Se observă că numele şi prenumele, vârsta şi informaţiile referitoare la grupul din care persona face parte (numărul biroului, orasul, şeful direct) sunt corelate direct cu numărul de legitimaţie (am putea spune că „depind de” numărul de legitimaţie) şi nu depind de calificare.

Relaţia CALIFICĂRI:Cod

CalificăriCategorieCalificări

113 Sisteme170 Taxe200 Audit150 Consultanţa

În acest caz, categoria calificării este determinată de codul calificării şi nu depinde de numerele de legitimaţie ale cadrelor.

Relaţia COMPETENŢE:Legitimatie

Cod Calificări

Competenţe

21 113 335 113 535 170 735 200 450 170 377 150 577 170 8

În acest caz, competenţa este determinată de combinaţia celor două chei (legitimaţie şi cod calificare).

5.3.4 A treia formă normală (FN3)

O relaţie este în FN3 dacă este în FN2 şi nu există nici un fel de dependenţe tranzitive (adică, nici unul din atributele non-cheie nu este dependent de alt atribut, care la rândul său este dependent de cheia relaţiei). Aceasta înseamnă că nu există nici o pereche (sau o pereche de mulţimi de atribute) X şi Y pentru care să apară succesiunea:

Cheie X X Yunde X este o cheie non-candidată.

O altă modalitate de a privi a treia formă normală este dată de faptul că ea rezultă din relaţii ce reprezintă entităţi şi relaţii ce reprezintă asocieri între entităţi. O descompunere corespunzătoare, prin care o schemă se poate converti la a treia formă normală, este aceea prin care acele atribute care nu sunt direct (sau, sunt doar tranzitiv) dependente de cheie sunt plasate într-o relaţie separată. Această descompunere prezintă două caracteristici importante:

Fiecare dependenţă este concretizată printr-o relaţie (deci descompunerea păstrează dependenţele).

Dacă o extensie a relaţiei originale este descompusă, ea poate fi reconstruită prin intermediul unui JOIN, din componente (fără pierderi).

În general, orice schemă poate fi adusă la a treia formă normală, cu păstrarea dependenţelor şi cu operaţii join fără pierderi de date. Pentru exemplul considerat, datele în FN3 se prezintă după cum urmează.

Relaţia CADRE:

34

Legitimaţie

NumePrenu

meVârstă

Birou nr.

Oraş Superior

21 Mareş Ana 29 1 Iaşi Ion35 Ionescu Dan 33 2 Bucureşti Damian50 Mircea Călin 35 2 Bucureşti Damian77 Traian Raluca 28 1 Iaşi Ion

Relaţia BIROURI:Birou nr.

Oraş Superior

1 Iaşi Ion2 Bucureşti Damian

Relaţia CALIFICĂRI:Cod Calificări

CategorieCalificări

113 Sisteme170 Taxe200 Audit150 Consultanţa

Relaţia COMPETENŢE:Legitimatie

Cod Calificări

Competenţe

21 113 335 113 535 170 735 200 450 170 377 150 577 170 8

5.3.5 Forma normală Boyce-Codd (FNBC)

Spunem că o relaţie R cu dependenţele F se află în forma normală Boyce-Codd (FNBC) dacă, oricare ar fi dependenţa X→A cu A atribut neconţinut în X, există o cheie a lui R conţinută în X.

Orice relaţie în forma normală Boyce-Codd este în FN3, dar reciproca nu este adevărată.

Exemplu. Relaţia R cu schema R(A, B, C), cu cheile AC şi BC şi cu dependenţele funcţionale F={AB→C, C→A}. R este în a treia formă normală, dar nu este în forma normală Boyce-Codd deoarece cheile acestei relaţii sunt AC şi BC, iar pentru dependenţa C→A partea stângă nu conţine nici una din cele două chei.

Pentru problema de a determina dacă o relaţie este în FNBC nu există (în general) algoritmi eficienţi de rezolvare.

5.3.6 A patra formă normală (FN4)

Fie R o schemă relaţională şi D o mulţime de dependenţe funcţionale şi multivaloare pe R. Spunem că R este în FN4 dacă, pentru orice dependenţă multivaloare X→→Y cu Y neinclusă în X şi XY inclusă în R, există cheie a lui R inclusă în X.

Cu alte cuvinte, o relaţie R este în FN4 dacă este în FNBC şi orice dependenţă multivaloare este, de fapt, o dependenţă funcţională.

35

Dacă D conţine numai dependenţe funcţionale şi R este în FN4, atunci R este în FNBC.

Exemplu. Fie relaţia ORAR prezentată în 5.2. Singura cheie a relaţiei este formată din atributele STUDENT şi ORA. Dependenţa CURS →→ ORA, LOCATIE nu respectă condiţia din FN4 deoarece CURS nu conţine o cheie. Vom descompune relaţia în:

CURSURICURS ORA LOCATIE

Algebră 10 A45Programare 8 C9Engleză 16 C22

care are cheia ORA, LOCATIE şi este în FN4 şi

ORAR1CURS PROFESOR STUDENT AN-STUDIU

Algebră Ionescu T. Miron Călin 1Algebră Ionescu T. Matei Ruxandra 1Programare Dinu A. Gruia Alina 2Programare Dinu A. Traian Maria 2Engleză Bontaş E. Miron Călin 1Engleză Bontaş E. Matei Ruxandra 1Engleză Bontaş E. Horia Anca 3

care are cheia CURS, STUDENT dar nu este în FN4 deoarece prezintă dependenţaCURS →→ PROFESOR care rezultă din CURS → PROFESOR şi CURS nu conţine o cheie. Descompunem ORAR1 în:

PROFESORICURS PROFESOR

Algebră Ionescu T.Programare Dinu A.Engleză Bontaş E.

şi

STUDENTICURS STUDENT AN-STUDIU

Algebră Miron Călin 1Algebră Matei Ruxandra 1Programare Gruia Alina 2Programare Traian Maria 2Engleză Miron Călin 1Engleză Matei Ruxandra 1Engleză Horia Anca 3

care sunt ambele în FN4.Deci, descompunerea relaţiei ORAR în {CURSURI, PROFESORI, STUDENTI} se află

în FN4 şi este fără pierderi la uniune.

5.3.7 A cincea formă normală (FN5)

Se spune că o relaţie R satisface dependenţa de uniune (join dependency) şi se notează cu

*(X,Y,…,Z)dacă şi numai dacă R este egală cu uniunea proiecţiilor lui R pe X,Y,…,Z, acestea fiind submulţimi ale lui R.

36

O relaţie R este în FN5 (numită şi forma normală proiecţie-uniune) dacă şi numai dacă orice dependenţă de uniune a lui R este o consecinţă a unei chei candidat a lui R.

Orice relaţie care este în FN5 este şi în FN4, deoarece fiecare dependenţă multivaloare poate fi privită ca un caz particular de dependenţă de uniune. Orice relaţie poate fi descompusă fără pierderi la uniune într-o mulţime de relaţii care sunt în FN5.

Pentru a preciza dacă o relaţie este în FN5, este suficient să cunoaştem cheile candidate şi toate dependenţele de uniune din R.

5.3.8. Procesul normalizării relaţiilor

Procesul de normalizare a relaţiilor se poate descrie în felul următor:1. Se proiectează relaţia iniţială, aflată în FN1, pe alte relaţii, pentru a elimina dependenţele

funcţionale care nu sunt complete. Se obţine o mulţime de relaţii în FN2.2. Se proiectează relaţiiile obţinute în pasul 1 pe alte relaţii, pentru a elimina dependenţele

funcţionale tranzitive. Se obţine o mulţime de relaţii în FN3.3. Se proiectează relaţiiile obţinute în pasul 2 pe alte relaţii, pentru a elimina dependenţele

în care partea din stânga nu este o supracheie. Se obţine o mulţime de relaţii în FNBC.4. Se proiectează relaţiiile obţinute în pasul 3 pe alte relaţii, pentru a elimina toate

dependenţele multivaloare care nu sunt şi dependenţe funcţionale. Se obţine o mulţime de relaţii în FN4.

5. Se proiectează relaţiiile obţinute în pasul 4 pe alte relaţii, pentru a elimina orice dependenţă de uniune care nu este implicată de o cheie. Se obţine o mulţime de relaţii în FN5.

De obieci, forma normală FN3 este suficientă, iar alteori chiar FN2 este suficientă.

Materiale privind normalizarea:

1. [Fel96]Dependenţe între date

2. [Bas97]Forme normale şi normalizare

3. http://databases.about.com/od/ specificproducts/a/normalization.htm Despre normalizare

4. http://en.wikipedia.org/wiki/Database_normalizationDefiniţia normalizării în enciclopedia wikipedia

5. http://www.datamodel.org/NormalizationRules.html 5 reguli pentru normalizarea datelor

6. http://www.fmsinc.com/tpapers/datanorm/ Fundamente ale normalizării datelor

37

6. Limbaje utilizate în lucrul cu baze de date

6.1 Limbajul de definire a datelor pentru modelul relaţional

Schema unei baze de date relaţionale este declarată utilizând un limbaj de definire a datelor (LDD). Un LDD relaţional este simplu. Fiecare relaţie trebuie să fie declarată: atributele sale să fie definite, trebuie să fie specificat un domeniu pentru fiecare atribut şi trebuie aleasă o cheie.

O abordare simplă, valabilă pentru multe baze de date relaţionale, este aceea prin care fiecărei relaţii i se asociază un fişier. Sunt posibile şi alte abordări, dar necesită implementări mult mai complexe. Imaginile următoare prezintă modalitatea de definire a atributelor unei noi relaţii în ACCESS, precum şi adăugarea relaţiei la bază.

38

6.2 Limbajul de manipulare a datelor pentru modelul relaţional

Se cunosc foarte multe abordări în ceea ce priveşte limbajele de manipulare a datelor (LMD) organizate relaţional. Cele mai multe dintre acestea sunt interactive, proiectate pentru folosirea conversaţională de către un utilizator care aşteaptă un răspuns imediat.

Există patru sarcini de bază pe care trebuie să le realizeze un limbaj de manipulare a datelor:

Inserarea datelor noi. Ştergerea datelor vechi. Actualizarea datelor. Consultarea datelor.

Aceste funcţii se regăsesc – într-o formă sau alta – în orice limbaj de manipulare a datelor.Complexitatea cea mai mare a operaţiilor unui limbaj de manipulare a datelor se

referă la ultima categorie de prelucrări: consultarea datelor. Inserarea, ştergerea şi actualizarea sunt, de obicei, operaţii clare şi sunt realizate de un utilizator experimentat (sau de un program de aplicaţie), cunoscându-se exact ce trebuie modificat şi unde. Operaţiile de consultare sau cerere de date (query), pe de altă parte, sunt deseori realizate de utilizatori care fie nu ştiu de la început ce caută, fie îşi exprimă cerinţele într-un mod foarte complicat. Din această cauză, limbajele de manipulare a datelor sunt uneori numite limbaje de cereri (query languages).

În cele ce urmează vom prezenta, prin intermediul unor exemple, trei abordări ale limbajului de cereri în modelul relaţional:

Algebra relaţională. Calculul pe tupluri. Calculul pe domenii.

Aceste trei limbaje s-au dovedit a fi echivalente, în sensul că orice cerere ce poate fi exprimată în unul din limbaje poate fi exprimată şi în celelalte două. Diferenţa constă în facilitatea scrierii cererii respective.

6.2.1 Algebra Relaţională

Algebra Relaţională furnizează instrumente pentru exprimarea procedurală a cererilor de date. Constă dintr-o colecţie de operaţii pe relaţii, fiecare operaţie având drept operanzi una sau mai multe relaţii şi producând ca rezultat o altă relaţie.

E.F. Codd a introdus Algebra Relaţională Standard, constituită din: 5 operaţii de bază:

o Reuniunea o Diferenţa o Produsul cartezian o Proiecţia o Selecţia

3 operaţii derivate:o Joncţiunea o Intersecţia o Diviziunea.

Ulterior, la Algebra Relaţională Standard au fost adăugate şi alte operaţii, aşa-numitele operaţii adiţionale sau extensii ale Algebrei Relaţionale Standard, cum ar fi:

o Complementara o Splitareao Închiderea tranzitivă.

În cele ce urmează presupunem că relaţia R are gradul r iar S are gradul s. Reuniunea. Pentru două relaţii R şi S se poate nota: RUS, UNION(R,S), ADD(R,S).

Reuniunea relaţiilor R şi S este mulţimea tuplurilor care se găsesc în cel puţin una din relaţiile R sau S. Această operaţie se poate aplica numai în cazul în care R şi S au aceeaşi schemă. Dacă atributele au nume se cere ca, în plus, cele două liste de nume să coincidă şi rezultatul va avea aceeaşi listă de nume pentru atribute.

39

Diferenţa. Pentru două relaţii R şi S se poate nota: R-S, MINUS(R,S), REMOVE(R,S). Diferenţa relaţiilor R şi S este mulţimea tuplurilor din R care nu sunt în S. Este necesar să fie îndeplinite aceleaşi condiţii ca pentru reuniune.

Produsul cartezian. Pentru două relaţii R şi S se poate nota: R×S, PRODUCT(R,S), TIMES(R,S). Produsul cartezian al relaţiilor R şi S este mulţimea tuplurilor cu r+s componente, în care primele r componente reprezintă un tuplu în R iar ultimele s componente reprezintă un tuplu în S. Dacă atributele au nume, lista numelor atributelor din rezultat este reuniunea disjunctă a celor două liste (folosind calificări sau redenumiri pentru atributele cu aceleaşi nume în cele două relaţii).

Proiecţia. Fie relaţia R de grad r. Proiecţia relaţiei R după atributele c1, c2,…, ck (k<=r) se notează πc1, c2,…, ck(R), PROJECT(R; c1, c2,…, ck) şi este mulţimea tuplurilor de aritate k în care se păstrează doar valorile corespunzătoare atributelor menţionate explicit în proiecţie. Dacă relaţia R are asociate nume pentru atribute, acestea se pot păstra în relaţia rezultată. Se observă că acesastă operaţie corespunde unor „tăieturi verticale” în R.

Selecţia. Fie F o formulă logică formată din operanzi care sunt constante sau nume de componente în tupluri şi operatori aritmetici şi/sau logici. Selecţia relaţiei R în raport cu formula F se notează σF(R), SELECT(R; F) şi reprezintă mulţimea tuplurilor din R pentru care formula F devine adevărată. Relaţia rezultat are pentru atribute aceleaşi nume ca şi relaţia R. Toate constantele care apar în F sunt incluse între apostrofuri.

Operaţiile derivate se pot exprima în funcţie de operaţiile de bază. Utilizarea acestora permite o exprimare mai simplă a cererilor şi, dacă sunt bine implementate, obţinerea unui răspuns mai rapid.

Joncţiunea. Este numită şi uniune sau join. O θ-uniune a relaţiilor R şi S după coloanele i şi j, unde θ este un operator de comparaţie este notată UNION(R,S; iθj), JOIN(R,S; iθj) sau R Xiθj S este constituită din mulţimea tuplurilor produsului cartezian dintre R şi S, pentru care a i-a componentă a lui R se află în relaţia θ cu a j-a componentă a lui S. Dacă R şi S au nume pentru atribute, în loc de i şi j se pot folosi numele atributelor corespunzătoare. Joncţiunea este o operaţie derivată deoarece se poate exprima cu ajutorul operaţiilor de bază prin formula: R Xiθj S= σiθ(r+j) (R×S).Dacă θ este operatorul =, operaţia se numeşte echiuniune sau echijoin. Un caz particular de joncţiune este joncţiunea naturală. Uniunea naturală a relaţiilor R şi S, notată R X S, se aplică dacă cele două relaţii au nume asociate atributelor şi, în acest caz, se selectează din produsul cartezian al relaţiilor R şi S acele tupluri ce conţin valori comune pentru câmpurile cu aceleaşi nume din cele două relaţii şi apoi se elimină valorile din câmpurile lui S comune cu cele din R.

Intersecţia. Intersecţia relaţiilor R şi S, notată R∩S, INTERSECT(R,S), AND(R,S), este constituită din mulţimea tuplurilor care se găsesc în ambele relaţii. Se aplică în condiţiile specificate la reuniune. Intersecţia se poate exprima prin operaţiile de bază cu formula: R∩S=R-(R-S).

Diviziunea. Fie relaţiile R de aritate r şi S de aritate s, cu r >s şi S≠Φ. Diviziunea sau câtul lui R prin S, notat R÷S, este mulţimea tuplurilor a de aritate r-s astfel încât, pentru orice tuplu b al lui S, tuplul ab este în R. Dacă atributele celor două relaţii au nume, atunci lista atributelor lui S trebuie să fie o submulţime a listei atributelor lui R iar rezultatul are ca listă de atribute diferenţa celor două liste. Câtul se poate exprima prin operaţiile de bază cu formula: R÷S= π1, 2,…, r-s(R)- π1, 2,…, r-s(π1, 2,…, r-s(R)×S)-R).

Exemplul 1. Fie relaţiile R şi S, cu schemele şi extensiile prezentate mai jos:

R S

În acest caz, rezultatele aplicării operatorilor: reuniune, diferenţă, produs cartezian,

D E Fb g ad a f

A B Ca b cd a fc b d

40

proiecţie, selecţie şi intersecţie asupra relaţiilor R şi S (cu precizările indicate pentru proiecţie şi selecţie) sunt:

RUS R-S

R×S πA,C(R),

σ B=”b” (R), R∩S

Exemplul 2. Fie relaţiile R şi S, cu schemele şi extensiile următoare:

R S

În acest caz, câtul lui R prin S este:

R÷S R÷S

Exemplul 3. Fie relaţiile R şi S, cu schemele şi extensiile de mai jos:

R S

În acest caz, joncţiunea lui R cu S cu B<D este:

R XB<D S R÷S

a b cc b d

a b cd a fc b db g a

a cd fc d

a b c b g aa b c d a fd a f b g ad a f d a fc b d b g ac b d d a f

d a fa b cc b d

E Fc de f

A B C Da b c da b e fb c e fe d c de d e fa b d e

a be d

D E3 16 2

A B C1 2 34 5 67 8 9

41

Exemplul 4. Fie relaţiile R şi S, cu schemele şi extensiile actuale:

R S

În acest caz, joncţiunea naturală a lui R cu S este: R X S R÷S

Exemplul 5. Fie următoarea schemă:

Relaţia ANGAJATINume câmp Tip CheieMarca Număr DaNume Text 20Prenume Text 20Initiala_tatalui Text 1Data_angajarii Dată

Relaţia CHITANTENume câmp Tip CheieNumar_chitanta Număr DaData DatăTotal NumărAvans NumărNumar_cont Text 9Credit_card NumărTip_card Text 2Marca Număr

Să se scrie o cerere prin care să se obţină un tabel cu următoarele date: Numar_chitanta, Data, Total, Marca, Nume, Prenume

pentru toate chitanţele exprimând plăţi salariale efectuate înainte de luna martie 2005.

În cazul acestei cereri, sunt necesari operatorii: Selecţie, Proiecţie şi Joncţiune. Cererea formulată se poate exprima, în limbajul algebrei relaţionale, prin secvenţa:

A B C D E1 2 3 3 11 2 3 6 24 5 6 6 2

B C Db c db c ea d b

A B Ca b cd b cb b fc a d

A B C Da b c da b c ed b c dd b c ec a d b

42

LIST JOIN(CHITANTE, ANGAJATI )SELECT(Date&<3/1/05)PROJECT(Numar_chitanta, Data, Total_chitanta, Marca, Nume, Prenume)

Materiale privind Algebra Relaţională:

1. www.cs.rochester.edu/users/faculty/nelson/courses/csc_173/relations/algebra.html2. www.cs.sfu.ca/CC/354/zaiane/material/notes/Chapter3/node7.html3. http://cs.wwc.edu/~aabyan/415/RelAlg.html

43

6.2.2 SQL

Unul dintre cele mai puternice limbaje structurate pentru interogarea bazelor de date relaţionale îl constituie SQL (Structured Query Language). Pe lângă manipularea şi regăsirea datelor, limbajul permite efectuarea de operaţii complexe privind actualizarea şi administrarea bazelor de date.

SQL este un limbaj neprocedural sau declarativ, deoarece utilizatorul lui descrie numai informaţiile pe care vrea să le obţină în urma interogării, fără a fi nevoie să stabilească modalităţile de a ajunge la rezultatele dorite. În acelaşi timp, SQL nu poate fi considerat un limbaj de programare sau unul de sistem ci, mai curând, face parte din categoria limbajelor de aplicaţii, fiind orientat pe mulţimi. Foarte frecvent, limbajul SQL este utilizat în administrarea bazelor de date client/server, aplicaţia client fiind aceea care generează instrucţiunile SQL.

Există un anumit grad de standardizare a limbajului SQL, mai multe sisteme de gestiune a bazelor de date recunoscând principalele instrucţiuni ale acestuia (de exemplu: Oracle, Access, Sybase etc.). Pe plan mondial, standardul în domeniu este considerat ANSI (American National Standards Institute) SQL care are în vedere atât aspectele de definire, interogare, manipulare a datelor, procesare a tranzacţiilor, cât şi caracteristicile complexe privind integritatea informaţiilor. Mulţi producători de sisteme de gestiune a bazelor de date furnizează propriile extensii ale limbajului SQL, asigurându-şi astfel exclusivitatea.

Se cunosc în literatura de specialitate trei metode de bază privind implementarea limbajului SQL şi anume:

cea prin apelare directă (Direct Invocation) - constă în introducerea instrucţiunilor SQL de la prompter;

cea modulară (Modul Language) - foloseşte anumite proceduri apelate de programele aplicaţiei;

cea de tip încapsulat (Embedded SQL) - are în vedere instrucţiunile încapsulate în codul de program, fiind de tip static şi dinamic.

În cazul exemplului 5 considerat mai sus, cererea SQL are forma:

SELECT Numar_chitanta, Data, Total_chitanta, CHITANTE.Marca, Nume, Prenume FROM CHITANTE, ANGAJATI WHEREDate&<3/1/05 AND CHITANTE.Marca# ="ANGAJATI.Marca#"

În Access, cererea SQL are forma:

6.2.3 Calculul Relaţional orientat pe tupluri

O expresie de calcul pe tupluri este, în esenţă, o definiţie non-procedurală a unei relaţii, în termenii unei mulţimi de relaţii date. O astfel de expresie este constituită din variabile tuplu, condiţii şi formule bine formate.

În cazul exemplului 5:Cererea în QUEL, limbajul de cereri al SGBD INGRES, are forma:

range of c is CHITANTE range of a is ANGAJATI

retrieve(c.Numar_chitanta, c.Data, c.Total, c.Marca, a.Nume, a.Prenume)

44

wherec.Data < 3/1/05 and c.Marca=”a.Marca”

Cererea în Access are forma:

6.2.4 Calculul Relaţional orientat pe domenii

Calculul pe domenii diferă de calculul pe tupluri prin aceea că variabilele sunt, în acest caz, comenii şi nu relaţii. Şi aici, o expresie de calcul orientată pe domenii este alcătuită din variabile domeniu, condiţii şi formule bine formate.

În cazul exemplului 5, cererea în Borland Paradox are forma:

CHITANTENumar_chitanta

Data Total

Avans

Numar_cont

Credit_card

Tip_card

Marca

=3/1/05

pers

ANGAJATIMarca Nume Prenume Initiala_tatalui Data_angajariipers

Materiale privind limbajele pentru baze de date:

1. www.freewebmasterhelp.com/tutorials/phpmysql/1Tutorial PHP şi MySQL

2. www.w3schools.com/sql/default.aspTutorial SQL

3. www.w3schools.com/sql/default.aspTutorial XML

4. [Nas00]Limbajul Visual Basic pentru Access 2000

45

7. Restricţiile de integritate ale modelului relaţional

Integritatea bazelor de date este dată, în principiu, de corectitudinea informaţiilor conţinute în acestea şi presupune detectarea, corectarea şi prevenirea diferitelor erori neintenţionate privind informaţiile introduse în bazele de date.

Restricţiile de integritate (RI), denumite şi reguli de integritate, definesc cerinţele pe care trebuie să le satisfacă datele din cadrul bazei de date relaţionale pentru a putea fi considerate corecte şi coerente în raport cu sistemul real pe care îl reflectă.

În bazele de date relaţionale, relaţiile sunt toate la acelaşi nivel iar setul de operatori este relativ restrâns, neputând exprima semantica operaţională a obiectelor complexe. Acest aspect ramâne în sarcina programatorilor de aplicaţie. Totuşi, sistemele relaţionale deţin o serie de mecanisme pentru tratatrea aspectelor de ordin semantic.

Restricţiile de integritate ale modelului relaţional sunt de două tipuri:

RI structurale, care se definesc prinegalitatea sau inegalitatea unor valori din cadrul relaţiilor. Din această cattegorie fac parte:

o Restriţiile de unicitate a cheiio Restricţia referenţialăo Restricţia entităţiio Dependenţa între date.

RI de comportament, proprii unei anumite baze de date relaţionale, ce ţin cont de semnificaţia valorilor din cadrul bazei respective. Se pot defini RI de comportament foarte diverse: temporale, de domeniu, etc. De exemplu, faptul că vărsta unei persoane trebuie să se plaseze între anumite limite constituie o restricţie de domeniu.

Utilizarea modelului relaţional nu impune definirea şi verificarea tuturor acestor tipuri de restricţii. Din acest punct de vedere, putem considera că există:

RI minimale – obligatoriu de definit şi de respectat. Din această categorie fac parte restricţia de integritate a cheii, restricţia referenţială, restricţia entităţii.

Alte RI – categorie din care fac parte dependenţele între date, restricţiile de comportament.

7.1 Restricţii de integritate minimale

Cheia unei relaţii R reprezintă un ansamblu minimal de atribute prin care se poate identifica în mod unic orice tuplu din R. Orice relaţie posedă cel puţin o cheie. La limită, cheia este constituită fie dintr-un singur atribut, fie din totalitatea atributelor din schema relaţiei respective.

Când cheia este constiituită dintr-un singur atribut ea poartă numele de cheie simplă iar când este formată din mai multe atribute este denumită cheie compusă.

Exemplu. În relaţia R1 atributul A este cheie, în timp ce în relaţia R2 cheia trebuie formată din atributele A şi B:R1: R2:

A Ba1 b1a2 b3a3 b2a4 b3

Într-o relaţie pot exista mai multe combinaţii de atribute cu proprietatea de identificare unică a tuplurilor. Se spune în acest caz caz că relaţia posedă mai multe chei candidate. În această situaţie, administratorul bazei va alege dintre cheile candidate una care să servească efectiv la identificarea tuplurilor şi care se va numi cheie primară. Restul cheilor candidate se vor numi chei alternate.

A Ba1 b1a1 b2a2 b3a3 b2

46

Cheia unei relaţii trebuie sa fie minimală, în sensul că nici o parte a sa nu trebuie să posede proprietatea de identificare unică a tuplurilor relaţie.

O cheie externă reprezintă un atribut sau un grup de atribute dintr-o relaţie R1 ale cărui/căror valori sunt deinite pe acelaşi/aceleaşi domeniu/domenii ca şi cheia primară a unei alte relaţii R2 şi care are rolul de a modela asocierea între entităţile reprezentate prin relaţiile R1 şi R2. În acest context, R1 este numită relaţie care referă, în timp ce R2 poartă numele de relaţie referită. Exemplu. În relaţia ANGAJATI atributul Marca este cheie primară, în timp ce atributul Cod_departament este cheie externă, servind la modelarea asocierii între angajaţi şi departamente. În relaţia DEPARTAMENTE, cheia Departament este cheie primară.

ANGAJATI: DEPARTAMENTE:Marca Nume Cod_departament

11 N1 122 N2 233 N3 144 N4 355 N5 366 N6 277 N7 1

Modelul relaţional prezintă următoarele restricţii de integritate minimale: Restricţia de unicitate a cheii. Reprezintă restricţia care impune ca într-o relaţie R cu

cheia K, oricare ar fi tuplurile t1 şio t2 să fie satisfăcută inegalitatea t1(K) ≠ t2(K).

Restricţia referenţială (integritatea referirii). Reprezintă restricţia care impune ca într-o relaţie R1 care referă o relaţie R2, valorile cheii externe să figureze printre valorile cheii primare din relaţia R2 sau să fie valori null (nedefinite). R1 şi R2 nu trebuie să fie neapărat distincte. Semnificaţia restricţiei de integritate a referirii este următoarea: o asociere nu poate exista decât între parteneri cunoscuţi, adică deja definiţi. Atunci când, într-o anumită situaţie, asocierea nu este aplicabilă, unul dintre parteneri va fi desemnat prin valoarea null, cu semnificaţia de „partener inexistent”. Exemplul anterior respectă restricţia de integritate a referirii.

Restricţia entităţii (integritatea entităţii). Reprezintă restricţia care impune ca într-o relaţie atributele cheii primare să fie nenule. Unicitatea cheii impune ca, la încărcarea unui tuplu, valoarea cheii să fie cunoscută, pentru a se putea verifica faptul că această valoare nu este deja încărcată. Cu valori de null, cheia îşi pierde rolul de identificator de tuplu.

Restricţia de integritatea a entităţii nu se aplică cheilor externe, ceea ce conferă o anumită supleţe modelului relaţional. Uneori, se consideră drept restricţii de integritate minimale numai ultimele două, restricţia de unicitate a cheii fiind considerată implicită.

7.2 Alte restricţii de integritate

În această categorie intră constrângerile de domeniu. Aceste constrângeri se pot referi la tipul de date al unui atribut, la o listă de valori posibile, la un ordin de mărime, la un format sau o formă, la o condiţie exprimată cu o formulă logică sau la o procedură care este apelată ori de câte ori are loc o modificare pentru domeniul specificat.

Exemple. Pentru relaţia CUMPARATORI (Cod, Nume, Adresa, Debit) se poate impune condiţia ca nici un cumpărător să nu aibă mai mult de 100.000.000 lei datorii. Pentru relaţia MAGAZINE (Numemag, Adresamag, Codmarfa, Marfa, Pret) se poate impune ca noile preţuri să nu crească cu mai mult de 20% faţa de preţurile vechi.

Departament Denumire1 Tehnic2 Personal3 Administrativ

47

7.3 Aspecte privind integritatea

De integritatea datelor este legată şi protecţia datelor împotriva diferitelor evenimente de avarie cum ar fi: căderea sistemului, cauzată de defectarea unor componente hardware sau software, executarea incompletă a unor programe din cauza apariţiei unor erori sau din necesitatea de întrerupere a lor în urma unor interblocări sau prin intervenţia utilizatorilor, programarea eronată a unor activităţi prin strategiile folosite de sistem şi altele.

Pentru reconstituirea bazelor de date în eventualitatea apariţiei unor inconsistenţe în general, majoritatea bazelor de date se copiază periodic pe medii magnetice ce se păstrează în locuri sigure. De asemenea, se ţine o evidenţă a tuturor transformărilor efectuate în baza de date de când s-a efectuat ultima copie. Fişierul care conţine aceste modificări se numeşte jurnal. Fiecare înregistrare din jurnal conţine un identificator al programului care a făcut modificarea, fosta valoare şi noua valoare introdusă pentru un element. Tot în jurnal se mai păstrează diferite momente importante din desfăşurarea programelor (început, sfârşit, terminarea unor operaţii).

Se spune despre o tranzacţie că este comisă dacă au fost terminate toate calculele produse de ea în aria de lucru şi s-a realizat o copie a rezultatelor ei în jurnal. Apariţia unor căderi după ce o tranzacţie a fost comisă nu afectează conţinutul bazei de date, deoarece acestea se pot reconstitui cu ajutorul ultimei copii şi a jurnalului în care se găsesc toate rezultatele tranzacţiilor comise. Modificările tranzacţiilor abandonate sau necomise nu sunt luate în considerare la parcurgerea jurnalului pentru restaurarea bazei de date.

Se defineşte strategia de comitere în două faze astfel: o tranzacţie poate să scrie într-o bază de date numai după ce a fost comisă şi o tranzacţie poate fi comisă numai după ce a înregistrat în jurnal toate schimbările de elemente produse de ea.

Materiale privind dependenţele datelor, integritatea şi securitatea bazelor de date:

1. [Fel96]Despre dependenţe între date

Despre securitatea sistemelor informaţionale, în general

2. www.boran.com/security/IT1x-4.html3. www.computerworld.ro/index.cfm?t=articol&idcwd=26474. www.pcmagazine.ro/pcmag4-8/internet_business.shtml

48

8. Depozite de date (Data warehouse)

Depozitele de date au devenit, la sfârşitul anilor ' 90, una dintre cele mai importante dezvoltări în domeniul sistemelor informaţionale. Industria de data warehouse s-a dezvoltat continuu în termeni de investiţii, produse disponibile şi proiecte elaborate. Se apreciază că aproximativ 90% dintre companiile multinaţionale au implementate depozite de date sau lucrează la dezvoltarea unor astfel de proiecte.

Depozitele de date sunt produsul mediului economic şi al tehnologiilor avansate. Pe de o parte, mediule conomic este tot mai competitiv, global şi complex şi solicită informaţii elaborate pentru sprijinirea deciziilor strategice iar, pe de altă parte, evoluţia tehnologiilor informaţionale oferă soluţii eficiente de gestionare a unor volume mari de date integrate (de ordinul Tera bytes) asigurând niveluri de sinteză / detaliere adecvate. Astfel, evoluţiile hardware performante precum şi sistemele de procesări paralele masive, sistemele de multiprocesare simetrică, sistemele tip baze de date paralele fac posibile încărcarea, întreţinerea şi accesul la baze de date de dimensiuni uriaşe. Aplicaţiile data warehouse sunt în măsură să asigure şi un timp mediu de răspuns extrem de scurt pentru categorii extinse de utilizatori.

Primele domenii care au adoptat tehnologia depozitelor de date au fost telecomunicaţiile, băncile şi comerţul cu amănuntul. Ulterior, depozitele de date au pătruns şi în alte domenii cum ar fi industria farmaceutică, sistemul sanitar, asigurările, transporturile. Studiile statistice arată că telecomunicaţiile şi sistemul bancar se menţin în top întrucât alocă cel puţin 15% din bugetul lor IT pentru proiecte referitoare la depozite de date.

Un proiect de data warehouse reprezintă o investiţie majoră. Costurile tipice pentru dezvoltarea unui depozit de date într-un interval de 3-6 luni se situează între 0,8 şi 2 milioane USD. Ponderea echipamentelor se situează între 1/2 şi 2/3 din costul total. Uneori, investiţiile în depozite de date nu se finalizează cu succes (politici organizaţionale defectuoase, insuficiente fonduri sau insuficientă susţinere din partea conducerii.

8.1. Concepte de bază în data warehouse

Depozitele de date au fost definite în foarte multe moduri, astfel încât o definiţie riguroasă este greu de formulat.

În sens larg, un depozit de date (data warehouse) reprezintă un sistem de baze de date: ce acoperă un orizont temporal mai mare (fundamentală este perspectiva pe termen lung); ce conţine date interne şi externe; optimizat pentru a răspunde interogărilor complexe.

Datele din sistemele sursă sunt extrase, curăţate, transformate şi stocate în depozite speciale în scopul sprijinirii proceselor decizionale, furnizând o platformă solidă de consolidare a datelor istorice pentru analiză.

Caracteristicile majore ale depozitelor de date sunt următoarele: Orientarea pe subiecte. Un depozit de date este organizat în sensul unor subiecte

majore cum ar fi: clienţi, furnizori, producţie, vânzări. Mai curând decât a concentra procesarea operaţiilor şi tranzacţiilor tipice într-o organizaţie, un depozit de date se focalizează pe modelarea şi analiza datelor pentru luarea deciziilor. Se oferă o viziune simplă şi concisă relativă la un subiect particular, excluzând datele care nu sunt utile în procesul de decizie.

Integrarea. Un depozit de date este, în mod uzual, construit prin integrarea a multiple surse eterogene: baze de date relaţionale, fişiere, înregistrări privind tranzacţii online. Tehnicile de curăţare (data cleaning) şi de integrare sunt aplicate pentru a asigura concordanţa în convenţiile de atribuire a numelor, de codificare a structurilor şi atribuire a valorilor.

Caracterul istoric. Datele sunt stocate pentru a furniza informaţii în perspectivă istorică (de la 5 până la 10 ani în urmă). Astfel, decidenţii pot consulta valorile succesive ale aceloraşi date, pentru a determina evoluţia în timp şi a calcula tendinţele anumitor indicatori.

Persistenţa datelor. Datele dintr-un depozit sunt permanente şi nu pot fi modificate. O actualizare a depozitului de date, ca urmare a modificărilor efectuate în datele sursă, înseamnă adăugare de date noi, fără a modifica sau şterge datele existente. Un depozit de date este întotdeauna memorat separat, din punct de vedere fizic, de datele transformate din

49

alte aplicaţii. Datorită acestei separări, un depozit de date nu necesită mecanisme de procesare a concurenţei. În mod uzual, solicită numai două operaţiuni: încărcarea iniţială a datelor şi accesul la date.

Sintagma data warehousing desemnează procesul de construire şi utilizare a depozitelor de date (data warehouse). Construirea necesită integrarea, curăţarea şi consolidarea datelor. Utilizarea necesită o colecţie de tehnologii de asistare a deciziilor. Acestea permit specialiştilor (manageri, analişti, executivi) să obţină rapid şi convenabil datele necesare şi să ia decizii bazate pe informaţiile din depozit.

8.2. Diferenţe înte bazele de date şi depozitele de date

Atât bazele de date cât şi depozitele de date conţin mari cantităţi de date structurate care pot fi accesate rapid datorită structurilor de acces optimizate şi se bazează, în majoritatea cazurilor, pe tehnologii relaţioanle. Totuşi ele nu au fost proiectate pornind de la aceleaşi obiective şi se diferenţiază prin numeroase aspecte.

Sistemele de gestiune ale bazelor de adte sunt adecavte aplicaţiilor curente de gestiune şi servesc la crearea şi întreţinerea sistemelor de date operaţionale. Aceste sisteme sunt cunoscute sub denumirea de sisteme OLTP (OnLine Transaction Processing) şi au ca obiectiv execuţia online a tranzacţiilor şi proceselor de interogare. Ele încorporează toate operaţiile zilnice dintr-o organizaţie, cum ar fi: aprovizionări, stocuri, producţie, decontări, plăţi, contabilitate.

Sistemele depozite de date, pe de altă parte, servesc specialiştii în domeniul analizei datelor şi luării deciziilor şi sunt cunoscute sub numele de sisteme OLAP (OnLine Analytical Processing).

Deosebirile majore între OLTP şi OLAP sunt sintetizate în tabelul următor şi iau în considerare următoarele trăsături: utilizatorii şi orientarea sistemului, caracterul datelor conţinute, nivelul de sinteză, unitatea de lucru, schemele de acces, numărul de înregistrări accesate, mărimea bazelor de adte, sistemul de evaluare.

Nr.Crt.

Trăsături OLTP OLAP

1 Destinaţia Procese operaţionale Procese informaţionale2 Orientarea sistemului Tranzacţii Analize3 Utilizatori Funcţionari, administratori

BD, profesionişti în BD4 Funcţii Operaţii zilnice Cerinţe informaţionale pe

termen lung, asistarea deciziei

5 Instrumente folosite în proiectare

Diagrame E-A Star / snowflake

6 Caracterul datelor Curente, noutate garantată Istorice, precizie menţinută în timp

7 Nivelul de sinteză Primitive, detaliere ridicată Sintetizare, consolidare8 Unitatea de lucru Scurtă, tranzacţii simple Interogări complexe9 Scheme de acces Read, Write Aproape totdeauna Read10 Focalizare Culegere date Furnizare informaţii11 Număr de înregistrări

accesateZeci Milioane

12 Număr de utilizatori Mii Sute13 Mărimea bazelor de date 100 MB - GB 100 Gb - TB14 Priorităţi Performanţe ridicate,

disponibilitatea ridicatăFlexibilitate ridicată, autonomie utilizatori finali

15 Sistem de evaluare Tranzacţii culese Interogări culese, timp de răspuns

Un sistem OLTP este orientat pe client (customer oriented) şi este utilizat pentru

procesarea tranzacţiilor şi a interogărilor. Un sistem OLAP este orientat spre piaţă (market oriented) şi este utilizat de manageri, analişti şi specialişti.

50

Există şi conceptul de magazine de date (Operational Data Stores – ODS), care se referă la o colecţie de date proiectate pentru sprijinirea controlului operaţional. La prim avedere nu par deosebite de depozitele de date, dar – deşi ambele tehnologii sprijină decidenţii – sunt diferite deoarece au scopul de a acoperi anumite tipuri de cerinţe informaţionale. Magazinele de date conţin date orientate pe subiecte din întreprinderile mari şi, spre deosebire de depozitele de date, conţin date volatile şi detaliate.

8.3. Arhitectura depozitelor de date

Arhitectura simplificată a unui depozit de date este prezentată în figura următoare.

În depozitul de date întâlnim mai multe tipuri de date care corespund diferitelor cerinţe informaţionale ale utilizatorilor:

Date detaliate Date uşor agregate Date puternic agregate Metadate.

Metadatele descriu datele conţinute în depozitul de date şi modul în care ele sunt obţinute şi stocate. Prin metadate se precizeză structura datelor, provenienţa lor, regulile de transformare, de agregare şi de calcul. Metadatele joacă un rol esenţial în alimentarea depozitului cu date. Ele sunt utilizate în toate etapele de încărcare adatelor şi sunt consultate şi actualizate pe parcursul întregului ciclu de viaţă ale depozitului.

Agregarea datelor se referă la realizarea de: totaluri precalculate, subtotaluri, valori medii, etc., ce se preconizează că vor fi cerute şi folosite de către utilizatori. Aceste agregări, deşi determină o creştere a redundanţei datelor, sunt necesare deoarece în acest fel se poate asigura un timp de răspuns cât mai redus. Sunt stocate în depozitul de date împreună cu datele importante din surse interne şi externe.

Data Mining reprezintă un proces de prelucrare bazat pe modele performante de selectare şi agregare a datelor din depozitele de date. Cele două scopuri principale ale procesului de data mining sunt, din punct de vedere practic:

Predicţia – implică utilizarea unor câmputi sau variabile din baza de date, în scopul estimării unor valori viitoare sau necunoscute, pentru alte variabile de interes şi

Descrierea – se orientează către găsirea unor modele ce descriu datele, interpretabile din perspectiva utilizatorului.

Baze de date operaţionale

Achiziţie(extragere)

DEPOZIT DE DATE (DATE AGREGATE

+ METADATE)

ŞTERGERE

ARHIVARE

AGREGARE

Prelucrare(data mining)

Instrumentepentru

Accesare şi

Utilizare

51

Procesul, numit şi Knowledge Data Discovery (KDD), este realizat prin intermediul următoarelor sarcini:

Clasificarea – este vorba de o funcţie care mapează (clasifică) un element de dată în una sau mai multe clase predefinite.

Regresia – o funcţie asociază un element de dată unei variabile cu rol de predicţie. Partiţionarea (clustering) – este o funcţie descriptivă prin care se urmăreşte

identificarea unui număr (finit) de categorii sau mulţimi care descriu datele. Strâns legată de această funcţie este funcţia de estimare a densităţilor de probabilitate ale variabilelor aleatoare constituite de câmpurile de date.

Sumarizarea – implică metode pentru găsirea unei descrieri compacte a unei submulţimi de date.

Modelarea dependenţelor – constă din găsirea unor modele care descriu în mod compact diferite dependenţe între subseturi de date. Modelele de dependenţă există la două nivele: structural (ce variabile sunt dependente unele de altele) şi cantitativ (specifică măsuri ale acestor dependenţe utilizând o scară numerică).

Detectarea schimbărilor şi deviaţiilor – se focalizează pe descoperirea celor mai semnificative schimbări ale datelor, utilizând valori anterior măsurate.

Cele mai populare metode de data-mining utilizează:o Reguli şi arbori de decizie o Regresie neliniară şi metode de clasificare o Metode bazate pe exemple o Modele Probabilistice de dependenţă o Modele de învăţare relaţională

Există două metode de data mining:

Data mining direct, care presupune:o O abordare top-downo Să ştim (cu aproximaţie) ce căutăm sau ce vrem să prezicemo Un model predictiv, care să permită evaluarea alternativeloro Modelul este văzut ca o cutie neagră, căci ne interesează numai predicţia şi nu

cum se realizaeză aceasta o Scopul construirii unui model predictiv este de a aplica cunoştinţele dobândite în

trecut, pentru viitor. o Exemplu: Să se găsească răspunsul la întrebarea: „Ce clienţi se presupune că

vor cumpăra un anumit tip de maşină?” Data mining indirect, care presupune:

o O abordare bottom-upo Să găsim modele în colecţiile de date şi să lăsăm utilizatorii să determine dacă

acestea sunt sau nu importanteo Vrem să ştim cum lucrează un model şi cum oferă răspunsulo Este necesară interacţiunea umană pentru că numai oamenii pot determina ce

semnificaţie (dacă există una) au modeleleo Este utilizat deseori în procesul de explorare a datelor

Literatura de specialitate face referire la trei soluţii practice de organizare a depozitelor de date:

Depozit la nivelul întreprinderii - Enterprise Warehouse. Colectează toate informaţiile despre subiecte care privesc întreaga organizaţie şi furnizează un volum extins de date.

Depozite la nivelul unei unităţi de gestiune (filială, departament, serviciu), cunoscute sub numele de data marts. Un data mart conţine un subset al volumului de date din organizaţie, specific unui grup de utilizatori. Domeniul este limitat la subiecte specifice. De exemplu, un data mart pentru marketing limitează subiectele la clienţi, articole, vânzări. Datele implementate în data mart sunt, de obicei, agregate. Un data mart poate fi considerat un subansamblu al unui depozit de date, mai uşor de construit şi mai puţin scump.

52

Depozite virtuale – Virtual Warehouse. Un depozit virtual este un set de viziuni asupra bazelor de date operaţionale. Este uşor de construit dar necesită capacităţi suplimentare pe serverele de baze de date.

Din punct de vedere al modelelor de date specifice data warehouse, cele mai populare sunt:

Reprezentarea stea (Star Schema). Este cel mai comun model de date, în care depozitul conţine un tabel central voluminos (tabel de fapte) care cuprinde cea mai mare parte a datelor fără redundanţe şi un set de tabele însoţitoare (tabele-dimensiune) pentru fiecare dimensiune. Graful asociat seamănă cu o stea în care tabelele-dimensiune apar radial, în jurul tabelului de fapte central, ca în figura următoare.

TimpTabel-dimensiune 1Cheie-timpZiZi-din-săptămânăLunăTrimestruAn

În acest exemplu, vânzările sunt considerate cu patru dimensiuni: timp, articol, ramură şi zonă.

Schema fulg de zăpadă (Snowflake). Este o variantă a modelului stea, unde anumite tabele sunt normalizate, astfel încăt apar tabele suplimentare. Rezultă o schemă de o formă grafică similară unui fulg de zăpadă. Diferenţa majoră între stea şi fulg de zăpadă este că tabelele dimensiune din acest ultim model pot fi păstrate în formă normalizată, ceea ce determină o redundanţă redusă. Asemenea tabele sunt uşor de întreţinut şi se economiseşte spaţiu de stocare, deoarece dimensiunile unui tabel mare pot creşte foarte mult. Un exemplu este schema anterioară, unde tabelele-dimensiune 3 şi 4 se modifică astfel:

ArticolTabel-dimensiune 3Cheie-articolNume-articolMarcaTipTip-furnizor

RamurăTabel-dimensiune 2Cheie-ramurăNume-ramurăTip-ramură

VânzăriTabel de fapteCheie-timpCheie-articolCheie-ramurăCheie-zonăVânzări-leiCantitate-vândută

ZonăTabel-dimensiune 4Cheie-zonăStradăLocalitateJudeţCod-poştalŢara

ArticolTabel-dimensiune 3Cheie-articolNume-articolMarcaTipCheie-furnizor

FurnizorTabel-dimensiune 3-1Cheie-furnizorTip-furnizor

ZonăTabel-dimensiune 4Cheie-zonăStardăCheie-oraş

OraşTabel-dimensiune 4-1Cheie-oraşOraşJudeţRegiune

53

Constelaţie de fapte – aplicaţiile complexe pot solicita tabele multiple de fapte, care partajează tabelele-dimensiune. Acest gen de schemă poate fi văzut ca o colecţie de stele, de unde denumirea de constelaţie de fapte (fact constellation).

Când se justifică un proiect de data warehouse? Există mai multe situaţii în care un depozit de date este oportun pentru rezolvarea unor probleme:

Insuficienta partajare a informaţiilor (de exemplu, când servicii sau departamente cu aceiaşi clienţi nu comunică între ele).

Grupuri diferite produc rapoarte contradictorii (datorită folosirii inconsistente a unor termeni).

Procesul de creare a rapoartelor este foarte anevoios (necesită mult timp pentru a fi produse şi nu rămâne timp pentru analiza efectivă a datelor).

Rapoartele nu sunt dinamice şi nu favorizează stilul de interogare ad-hoc (nu se pot obţine rapoarte concludente în situaţii speciale).

Rapoartele care necesită date istorice sunt dificil de realizat (astfel de date nu sunt stocate în sistemele operaţionale, iar încorporarea datelor vechi în rapoarte poate fi dificilă din cauza nepotrivirii structurilor).

Majoritatea firmelor producătoare de software pentru baze de date s-au orientat către implementarea unui modul specific depozitelor de date. În topul preferinţelor se află: SQL Analysis Manager produs de Microsoft Corporation şi Oracle Warehouse Builder produs de Oracle. Aceste două instrumente beneficiază de experienţa şi puterea finaciară a companiilor producătoare şi au reuşit să se impună pe piaţă ca soluţii viabile. Industria depozitelor de date este însă în continuă expansiune.

Instrumentele data-mining vor continua să se maturizeze şi din ce în ce mai multe organizaţii vor adopta acest gen de tehnologie. Iniţiativele data mining provin cel ami adesea din zona departamentelor de marketing şi de vânzări cu amănuntul şi se pretează foarte bine în organizaţiile care deţin baze de date cu volume foarte mari. Datorită faptului că aceste instrumente dau cele mai bune rezultate cu date la un nivel ridicat de detaliere, evoluţia instrumentelor data mining va coincide de fapt cu dezvoltarea depozitelor de date cu dimensiuni de ordinul TB. Proiectele de data mining vor accentua şi ami mult importanţa calităţii datelor din depozitele de date.

Tehnologiile data warehouse continuă să fie influenţate de poularitatea soluţiilor bazate pe Intranet şi Internet. Ca urmare, din ce în ce mai multe instrumente de acces la date vor putea suporta facilităţile oferite de web. Unele organizaţii au început deja să folosească infrastructura Internetului pentru a oferi utilizatorilor posibilitatea de a utiliza depozitul de adte de la distanţă, însă în acest caz este trebuie avută în vedere problema securităţii acestui mediu.

Exemplul 1. NAWQA – Water Quality Data Warehouse este un depozit unde se colectează date despre calităţile chimice, biologice şi fizice ale apei din 42 de bazine din SUA. Se măsoară zilnic: concentraţiile în apă, sedimente şi ţesuturi organice pentru aproximativ 600 de constituenţi chimici. De asemenea, se păstrează date privind nivelul apelor în aceste bazine hidrografice.

Exemplul 2. Departamentul SUA pentru Sănătate şi Servicii Umane a dezvoltat depozitul de date geospaţiale HRSA (Health Resources and Services Administration). Acest depozit şi aplicaţiile sale asociate furnizează informaţii despre programele HRSA, resurse despre sănătate şi date demografice foarte utile pentru planificare şi domeniului politic. Acest depozit conţine date despre granturi, burse şi împrumuturi, destinate serviciilor subsumate, precum şi programe demonstrative. Fiind sursa centrală de informaţii utilizată pentru raportările activităţilor HRSA, oferă un instrument de raportare pentru generarea şi utilizarea tabelelor. Un instrument de tip hartă este disponibil pentru cei ce vor să plaseze date într-un context geografic. Datele depozitului sunt actualizate cu regularitate şi se adugă noi surse de informaţii. În continuare este prezentată secţiune de arii ale site-ului (http://datawarehouse.hrsa.gov/).

What's New Data Refresh Dates

Program Information   Grants Information

54

Health SystemsInteractive Maps Map ToolReporting

Report ToolMetadata

Data SourcesData Dictionary Spatial Metadata

Data AccessPCSA

Help ResourcesTechnical Support Map Tool HelpReport Tool HelpGrant Activity ListingList of Data Sources Resources

Materiale privind depozitele de date şi data mining:

1. www.dwinfocenter.org The Datawarehousing Information Center: acest site este o colecţie de eseuri ale

practicienilor depozitelor de date. Prezintă definiţii, argumente pro şi contra dezvoltării depozitelor de date, evaluări ale unor instrumente software pentru depozite de date, informaţii despre afaceri inteligente, politici pentru decizie şi ale domeniului depozitelor de date.

2. datawarehouse.ittoolbox.comInstrumente pentru lucrul cu depozite de date.

3. freedatawarehouse.comConcepte şi elemente practice.

4. www.infogoal.com/dmc/dmcdwh.htmInformaţii despre: Data Warehouse, Data Mart, Data Mining, Decision Support

Resources.

5. www.datawarehousingonline.comResurse, tehnologii şi soluţii.

6. http://dbvis.inf-uni-konstanz.de/~keim/PDF/Vis04Tutorial.pdfArticolul Information Visualization and Visual Data Mining, autori: Grinstein G.,

Keim D.A., Ward M., 2004. Prezintă istoria domeniilor vizualizare de date şi data mining, tehnici şi sisteme de vizualizare, exemple de aplicabilitate în chimie.

7. www.nag.co.ukThe Numerical algorithms Group Ltd, Oxford. Oferă componente şi tehnologii data

mining şi vizualizare, pentru mai mult de 10000 de organizaţii din întreaga lume. Software şi servicii de dezvoltare de aplicaţii (în bio-informatică, e-business, detecţia fraudelor, analiză web).

55

9. Baze de cunoştinţe

Bazele de cunoştinţe sunt întâlnite în literatura de specialitate sub diferite denumiri cum ar fi: baze de date logice, baze de date inferenţiale, sisteme expert, sisteme deductive, prelucrare recurentă, baze de date inteligente. Prin aceste sisteme se încearcă o cât mai apropiată funcţionare a bazelor de date de sistemul obişnuit de operare cu date.

Astfel, în aceste sisteme diferitele tupluri ale relaţiilor sunt interpretate ca axiome iar cererile sunt interpretate ca teoreme, răspunsul la cerere fiind interpretat ca o demonstraţie. Această interpretare permite:

uniformitate de reprezentare - bazele de date, axiomele, cererile şi constrângerile de identitate sunt reprezentate toate la fel;

uniformitate de operare – răspunsul la cereri optimizaea cererilor, proiectarea bazelor de date, demonstrarea corectitudinii programelor sunt privite la fel;

modelare semantică – prin evenimente, tipuri de ierarhii şi combinaţii de entităţi; aplicaţii extinse.

Bazele de cunoştinţe permit interpretarea unor cereri formulate în limbaj natural. Printre altele, conţin copii ale unor tabele din catalogul bazei de date, tabele ce conţin valorile datelor utilizate frecvent, o mulţime de reguli de transformare a frazelor (unele permiţând substituirea automată a unor sub-expresii) şi un lexicon conţinând un tabel care defineşte cuvinte din limba naturală ce pot fi utilizate în cereri sau cuvinte generale.

Baza de cunoştinţe este iniţiată prin construirea lexiconului şi a altor părţi componente şi se completează în timp cu noi cunoştinţe sau elemente, de către utilizatori sau automat, pe baza informaţiilor obţinute în exploatare.

În bazele de cunoştinţe sunt aplicate rezultatele din calculul propoziţiilor şi calculul predicatelor. Pe baza transformărilor logice se urmăreşte demonstrarea unor aserţiuni ţinând seama de axiomele logicii matematice şi de informaţiile conţinute în sistem.

Prin axiomă deductivă sau regulă de inferenţă se înţelege o regulă care permite deducerea unor fapte plecând de la o mulţime de fapte date. Pentru a demonstra o aserţiune de forma:

f1, f2, …,fn├ gunde f1, f2, …,fn sunt premisele iar g este concluzia, de obicei se foloseşte metoda reducerii la absurd, demostrând că formula:

f1 & f2 & …& fn & not geste falsă. Pentru aceasta se transformă formula precedentă într-o formulă echivalentă normal conjunctivă, de forma:

u1 & u2 & …& um

în care fiecare ui, i=1,…,m este o disjuncţie de atomi, eventual precedaţi de negaţie. Se derivează în continuare alţi termeni, aplicând legea rezoluţiei în forma:

╞ ((f g) & (not g h) (f h)Dacă printre termenii derivaţi apare mulţimea vidă (înţeleasă ca fals şi notată []) atunci aserţiunea iniţială este adevărată, altfel (când nu mai pot fi generaţi alţi termeni) aserţiunea este considerată falsă.

Exemplu. Pentru a demonstra aserţiunea:A (B C), NOT D OR A, B ├ D C

Unde A, B, C şi D sunt formule, se pleacă de la formulele:A (B C)NOT D OR A BNOT(D C)care, aduse la forma normală conjunctivă, conduc la:

(1) NOT A OR NOT B OR C(2) NOT D OR A(3) B(4) D(5) NOT C

Aplicând rezoluţia pentru formulele (1) şi (2) în raport cu A se obţine(6) NOT D OR NOT B OR C

Aplicând din nou rezoluţia pentru formulele (6) şi (3) în raport cu B se obţine(7) NOT D OR C

Aplicând din nou rezoluţia pentru formulele (7) şi (4) în raport cu D se obţine(8) C

şi din (8) şi (5) unde rezoluţia se aplică în raport cu C se obţine clauza vidă, ceea ce demonstrează că aserţiunea iniţială este adevărată.

Cererile pentru baza de cunoştinţe pot fi exprimate sub următoarea formă generală:A1 AND A2 AND …AND Am B1 OR B2 OR …OR Bn (*)

unde A1, A2, …, Am şi B1, B2, …, Bn sunt de forma r(x1, x2, …,xt) cu r predicat având argumentele x1, x2, …,xt.

Dacă toate argumentele sunt constante, predicatul reprezintă o axiomă de bază şi este o propoziţie adevărată. În termenii bazelor de date, (x1, x2, …,xt) este unul din tuplurile existente în baza de date. În acest sens, predicatul r afirmă ceva în concordanţă cu înţelesul pe care îl are relaţia R.

Pentru m>0 şi n=1, (*) devine clauza:A1 AND A2 AND …AND Am B

care poate fi privită ca o axiomă deductivă. Această axiomă deductivă dă o definiţie parţială a predicatului din partea dreaptă a implicaţiei, în funcţie de predicatele din partea stângă. Poate fi privită şi ca o constrângere de integritate.

Vederile unei baze de date pot fi privite ca modele teoretice. În aceste modele, domeniile de bază conţin valori sau constante ce pot să descrie anumite obiecte ale lumii reale, acestea formând contextul (ce poate fi privit ca un „univers”). Relaţiile de bază reprezintă o mulţime de predicate sau formule deschise (cu variabile) ce urmează să fie interpretate în acel context. Fiecare tuplu al unei relaţii reprezintă o particularizare a predicatului corespunzător (adică o formulă închisă, fără variabile) care are valoarea adevărat pentru universul respectiv. Constrângerile (restricţiile) de integritate sunt tot formule închise, interpretabile în contextul respectiv. Prin urmare, tuplurile şi constrângerile de integritate pot fi privite ca formând mulţimea axiomelor ce definesc o anumită teorie logică. Baza de date poate fi privită ca mulţimea tuturor teoremelor ce se pot demonstra pornind de la axiome. Evaluarea cererilor se face analog cu demonstrarea teoremelor.

Ca axiome ale unei baze de date pot fi considerate următoarele:1. Axiomele de bază – corespund tuplurilor relaţiilor de bază, ele definind aşa-numita

bază de date extinsă (extensional database).2. Câte o axiomă de completitudine pentru fiecare relaţie, prin care se afirmă că nu

există alte tupluri decât cele care apar efectiv în relaţia respectivă. Aceasta se mai numeşte presupunerea de închidere (Closed World Assumption), prin care se consideră false aserţiunile pentru tuplurile ce nu apar în relaţie.

3. Axioma numelui unic – prin care se afirmă că fiecare constantă se distinge de toate celelalte constante (are nume unic).

4. Axioma închiderii domeniului – prin care se afirmă că nu există alte constante în afară de cele existente în domeniul bazei de date.

5. O mulţime de axiome standard, prin care se defineşte predicatul „=”.Un sistem deductiv de baze de date este un SGBD care permite construirea

vederilor cu demonstrare teoretică şi care este capabil, în particular, să deducă fapte suplimentare din baza de date existentă aplicând axiome deductive sau reguli de inferenţă. Axiomele deductive împreună cu constrângerile de integritate formează ceea ce se numeşte conţinutul intern al bazei de date (intensional database) şi aceasta, împreună cu extinderea bazei de date (care conţine informaţiile) formează baza de date deductivă (deductive database).

Materiale privind bazele de cunoştinţe:

1. [Fel96]2. http://www.kddresearch.org/Groups/Data-Mining/

Despre descoperirea cunoştinţelor şi Data Mining, la Departmentul de Calculatoare şi Ştiinţele Informaţiei, Kansas State University, Laboratorul Knowledge Discovery in DataBases

3. http://www.kmining.comDespre inteligenţă în afaceri, Knowledge Discovery şi Data Mining

10. Aplicaţii Access

Acest capitol conţine patru aplicaţii Access comentate, în scopul prezentării celor mai utile informaţii privind realizarea bazelor de date relaţionale.

10.1. Bază de date pentru activităţi şcolare

Să presupunem că, într-un oraş, activităţile facultative ale elevilor se desfăşoară într-un sediu special organizat, după un orar care se stabileşte la începutul fiecărui an şcolar. Se doreşte crearea unei baze de date pentru gestionarea informaţiilor relative la această activitate: elevi, profesori, orar. Pentru simplificarea aplicaţiei, vom considera că două cursuri cu acelaşi obiect (de exemplu, două cursuri de pictură) susţinute la momente temporare distincte (de acelaşi profesor sau de profesori diferiţi) sunt de fapt cursuri distincte, motiv pentru care cursurile vor fi identificate printr-un cod.

Analiza problemei conduce la identificarea imediată a entităţilor: ELEVI, CURSURI, PROFESORI. Cunoscând elementele ce trebuie memorate pentru fiecare entitate în parte şi constatând relaţiile între entităţi, construim modelul conceptual al bazei de date, care se poate reprezenta astfel:

ELEVInr matricolnume si prenumeclasascoala

Cu specificaţia anterioară relativă la cursuri, observăm că relaţia dintre entităţile PROFESORI şi CURSURI este de tip 1-n ("unu la mai mulţi") (un profesor poate susţine mai multe cursuri dar un curs este realizat de un singur profesor), în timp ce relaţia între entităţile ELEVI şi PROFESORI este de tip m-n ("mai mulţi la mai mulţi"). Într-adevăr, un elev poate urma mai multe cursuri iar un curs are, desigur, mai mulţi elevi. Acest tip de relaţie se transformă, pentru a putea fi modelată logic, în două relaţii de tip 1-n. Vom realiza aceasta prin introducerea unei entităţi suplimentare, numită REPARTIŢII, care va permite şi notarea fiecărui elev, la sfârşitul anului şcolar, la toate cursurile la care acesta participă. Ideea acestei modelări este de a surprinde interacţiunea elev – curs şi elementele ei specifice. Fiecare elev (identificat prin numărul său matricol, stocat în nr matricol) urmează un curs (identificat printr-un cod păstrat în cod curs) şi primeşte o notă (stocată în câmpul apreciere). Astfel, modelul logic (relaţional) al datelor este reprezentat de următoarea colecţie de tabele:

ELEVI (nr matricol, nume şi prenume, clasa, şcoala) CURSURI (cod curs, denumire curs, ziua, ora începerii, evenimente) PROFESORI (cod profesor, specializarea, norma de bază, cod curs) REPARTIŢIE (cod, nr matricol, cod curs, apreciere).

În reprezentarea de mai sus, atributele subliniate cu linie continuă caracterizează în mod unic realizările de entitate (un număr matricol este specific unui elev şi numai unuia, aceeaşi proprietate este valabilă pentru codul unui profesor, fiecare curs are un cod unic iar

CURSURIcod cursdenumire cursziua ora inceperiievenimente

PROFESORIcod profesorspecializareanorma de baza

URMEAZĂ

SUSŢIN

fiecare linie a tabelului repartiţie este identificată printr-un număr, păstrat în câmpul cod). Un atribut cu această proprietate (de identificare a realizărilor unei entităţi) se numeşte cheie primară. De exemplu, atributul cod curs realizează diferenţierea a două cursuri (în baza noastră de date, două cursuri cu aceeaşi denumire – Pictură – sunt susţinute de profesori diferiţi, în zile diferite din săptămână; este evident că nu ar putea fi identificate prin denumire).

Câmpurile subliniate cu linie punctată au un rol de legătură, şi anume, modelează relaţiile între entităţile identificate în faza de analiză. Aceste câmpuri se numesc chei secundare sau externe (cod curs pentru tabela profesori, nr matricol şi cod curs pentru tabela repartiţie). În timp ce cheile primare au valori unice, cheile secundare pot avea valori duplicate (se va observa, studiind baza de date oferită ca exemplu, că numărul matricol 101 apare în trei linii ale tabelei repartiţie, iar cursul cu codul 3 în patru linii).

Vom studia în continuare procedeele prin care transpunem acest model într-o bază de date Access şi cum putem folosi această bază de date.

În fereastra Microsoft Access optăm pentru crearea unei baze de date goale (Blank Access database) şi tastăm OK. Apare caseta File New Database, în care introducem numele dorit (în cazul nostru, instruire). În zona de lucru a aplicaţiei apare fereastra Database, aceasta fiind fereastra principală a noii baze de date, prin intermediul căreia putem accesa toate obiectele ei. Se observă că în zona din stânga ferestrei obiectele sunt grupate pe tipuri (tablouri, cereri, etc.), iar în zona din dreapta se regăsesc instrumente de lucru şi obiectele de tipul curent. Astfel, în imaginea de mai jos nu figurează tabele (acestea vor fi primele obiecte create), dar se pot observa instrumentele prin intermediul cărora putem accesa diferitele modalităţi de creare a tabelelor. Se observă că eticheta fiecărui grup de obiecte este precedată de o imagine semnificativă. Imediat sub bara de titlu a ferestrei se pot observa butoane de manevră a obiectelor de tipul curent (de exemplu, pentru tabele, Open, Design, New şi Delete permit deschiderea în mod tabel, deschiderea în mod proiectare, crearea unui tabel nou şi respectiv ştergerea unui tabel) şi butoanele pentru diferite afişări ale pictogramelor obiectelor (Large Icons, Small, List şi Detail).

Crearea tabelelorPrin realizarea unui dublu clic pe opţiunea Create table in design view se deschide

fereastra Table, în cadrul căreia se definesc:

numele câmpului (Field Name), ce poate fi format din mai multe cuvinte, trebuie să fie sugestiv (să sugereze conţinutul câmpului pe care îl numeşte). De exemplu, "nr matricol" este numele câmpului care va conţine numărul matricol al unui elev.

tipul câmpului (Data Type). Un tip de dată defineşte atât mulţimea valorilor pe care le poate lua data respectivă, cât şi tipul operaţiilor ce se pot aplica asupra ei. Un clic pe săgeata derulantă deschide lista opţiunilor (Text, Memo, Number, Date/Time, etc.).

descrierea (Description), acest element fiind opţional (o descriere a câmpului respectiv, de exemplu pentru "nr matricol" s-a precizat că reprezintă un cod intern, necesar identificării elevilor în cadrul activităţii de instruire suplimentară).

Crearea relaţiilor între tabeleExistă două tipuri de relaţii între tabelele unei baze de date:

relaţii permanente, ce se stabilesc după definirea tabelelor. Aceste relaţii fac parte din structura bazei de date (deci se memorează în ea) şi se realizează prin corespondenţele chei primare – chei secundare.

relaţii temporare, ce se stabilesc între tabele atunci când se realizează anumite interogări; acestea nu se păstrează în bază.Am observat deja care este tipul relaţiilor între tabelele PROFESORI şi CURSURI (1-

n), iar relaţia de tip m-n între tabelele ELEVI şi CURSURI a fost descompusă în două relaţii de tip 1-n, cu ajutorul tabelei REPARTIŢIE: Relaţia ELEVI – REPARTIŢIE este de tip 1-n (un elev participă la mai multe cursuri şi va primi o notă pentru fiecare) şi la fel este relaţia CURSURI – REPARTIŢIE (un curs se regăseşte în tabela REPARTIŢIE de un număr de ori egal cu numărul elevilor care-l urmează). În afara acestor tipuri de relaţii, în Access se mai pot modela relaţiile de tip 1-1 ("unu la unu"), de exemplu între persoane şi mulţimea codurilor numerice personale.

Un clic pe butonul Relationships: de pe bara de instrumente Database deschide fereastra Relationships şi caseta Show Table, de unde utilizatorul aduce în fereastră tabelele bazei de date (după care o închide). O relaţie între două tabele se realizează prin punctarea cheii principale a tabelei ce constituie partea stângă a relaţiei) şi tragere până la cheia secundară (externă) a tabelei ce constituie partea dreaptă a relaţiei. Această manevră deschide fereastra de dialog Editare Relaţii:

Se observă în această fereastră (în cazul de faţă, pentru editarea relaţiei ELEVI – REPARTIŢIE) cele două tabele relaţionate, cheile primară şi secundară. Bifarea proprietăţii Enforce Referential Integrity) activează un mecanism al sistemului de gestiune Access, prin care nu este permisă introducerea datelor în tabele REPARTIŢIE, înaintea celor din tabela ELEVI. Cu alte cuvinte, un elev cu numărul matricol 300 nu poate figura în tabela REPARTIŢIE, înainte de a fi fost introdus în ELEVI. Această ordine de introducere este naturală, nu putem repartiza elevii la cursuri înainte de a-i "înscrie". Situaţia se prezintă la fel şi în cazul relaţiei CURSURI – REPARTIŢIE: trebuie să memorăm mai întâi datele despre un curs şi apoi să repartizăm elevi la acest curs. Se observă că acest mecanism este unul de păstrare a integrităţii referenţiale a bazei (după cum indică şi numele proprietăţii), astfel este prevenită introducerea greşită a datelor şi sunt eliminate multe incoerenţe.

Iată fereastra Relaţii pentru baza de date instruire:

Introducerea datelor în tabeleSe poate realiza în mai multe moduri, dar pentru început putem realiza următorii paşi:

în fereastra Database selectăm fişierul dorit, activăm butonul Open şi în fereastra care apare (gen foaie de date, ca în Excel) introducem datele. De fapt, această modalitate permite şi vizualizarea şi modificarea datelor, la orice moment în exploatarea bazei de date. În fereastra de mai jos se pot observa: articolul curent, indicat prin săgeata neagră şi în bara de stare,

butoanele de deplasare printre liniile tabelului (un articol înaintea celui curent: , articolul

următor: , primul articol: , ultimul articol: , articolul gol: , care apare totdeauna marcat cu *) şi cursorul de defilare, pentru cazul în care sunt multe câmpuri şi este necesară

deplasarea stânga-dreapta (evident, ar apărea şi un cursor vertical dacă fereastra nu ar conţine decât o parte din liniile tabelului).

FormulareÎn cadrul aplicaţiei noastre, este creat un formular cu numele CURSURI, pentru

introducerea datelor în altă formă decât cea tabelară. Avantajul este o interfaţă deosebită, care permite posibilitatea afişării unor indicaţii pentru cel care introduce datele (această activitate fiind semnificativă, în cazul bazelor de date mari).

În acest formular, se observă trei zone: antetul; zona de detaliu – care conţine numele câmpurilor şi datele; subsolul.

Atât antetul cât şi subsolul nu se modifică pe măsură ce introducem sau edităm înregistrări, conţinând, de regulă, informaţii explicative cu privire la scopul formularului şi la datele pe care acesta le prezintă.

Crearea formularului CURSURI

Antet

Zonădedetaliu

Subsol

Efectuăm clic pe Formulare în fereastra Bază de date şi selectăm opţiunea Creare formular utilizând Expertul. În continuare se selectează tabela cursuri şi acţionăm butonul OK:

Urmează acum selectarea câmpurilor pe care le dorim în formular. Pentru selectarea tuturor

câmpurilor (situaţia cea mai comună), realizăm clic pe butonul .

La pasul următor se selectează modul de aşezare a datelor în formular. Posibilităţile sunt: Columnar (datele unei înregistrări sunt prezentate pe coloane), Tabular ( câmpurile sunt ordonate ca în figura de mai jos şi în formular apar mai multe linii din tabel), Datasheet (ca în Excel), Justified (o aşezare a câmpurilor unei înregistrări între marginile formularului) PivotTable (vizualizarea datelor detaliate sau rezumate prin aranjarea câmpurilor în filtru, rând, coloană şi arii detaliu) şi PivotChart (afişarea date vizuală prin selectarea unui tip de

diagramă şi aranjarea câmpurilor în filtru, serie, categorie şi arii date). Un formular PivotTable efectuează calculele alese, ca sume (implicit pentru câmpurile numerice) şi numărări (implicit pentru câmpuri text), bazat pe modul în care sunt aranjate datele. De exemplu, un formular PivotTable poate afişa valorile unui câmp orizontal sau vertical şi apoi calculează totalul rândului sau coloanei. De asemenea, un formular PivotTable poate folosi valorile unui câmp drept titluri de rând sau de coloane, calculând cantităţile individuale la intersecţia titlului fiecărui rând cu fiecare coloană, iar apoi calculând subtotaluri şi totaluri generale. De exemplu, pentru a analiza produsele vândute de fiecare angajat: se pot lista numele angajaţilor ca titlurile coloanelor în partea superioară a formularului PivotTable, produsele ca titlurile rândurilor în partea de jos a formularului PivotTable, iar suma vânzărilor calculată după produse pentru fiecare angajat la intersecţia fiecărui rând cu fiecare coloană. Formularul PivotChart permite reprezentarea grafică a datelor, folosind tipurile oferite de Excel: coloană, bară, structură inelară, radială, etc.

În următoarea fereastră se selectează stilul formularului (stilul implică un fundal, un tip de font pentru date, culori, aşezare etc.):

Ultimul pas se referă la alegerea unui nume pentru formular şi dialogul se încheie cu clic pe Finish.

Un alt formular (cu numele elevi) este proiectat asemănător; la activarea sa (de exemplu, cu dublu clic) va afişa, în forma proiectată, conţinutul curent al tabelei ELEVI. Iată cum se reflectă corecţia efectuată în câmpul şcoala, pentru elevul cu numărul matricol 303 (schimbarea valorii câmpului din 26 în 28):

Vom observa în continuare cum arată acest formular în mod proiectare (această vedere se poate obţine selectând formularul în fereastra Database şi apoi realizând clic pe butonul Proiect):

Fiecare componentă a formularului (Antet, Detaliere, Subsol) are proprietăţi care se pot seta

prin deschiderea meniului contextual aferent (clic dreapta pe şi selectarea opţiunii Proprietăţi, care deschide meniul prezentat în continuare).

Cu ajutorul instrumentelor barei Toolbox, care se afişează automat în mod proiectare, formularului i se pot adăuga elemente grafice, numite controale:

Acestea au funcţii numeroase şi complexe, dar eticheta este controlul cel mai simplu de utilizat. Etichetele afişează textul indicat – astfel au fost create antetul şi subsolul formularului cursuri.

Să realizăm un subsol şi pentru formularul elevi. Pentru aceasta, urmăm etapele de mai jos:

modificăm zona Subsol Formular, plasând cursorul pe linia inferioară, până când devine de forma: apoi tragem până mărim zona după dorinţă;

acţionăm butonul Label (al treilea de pe bara de mai sus) şi ducem cursorul în zona creată. Forma cursorului se schimbă, devenind un simbol A precedat de o cruce. Punctul unde plasăm mijlocul crucii devine colţul din stânga sus al zonei destinate etichetei;

mişcăm cursorul spre dreapta şi în jos, până obţinem dimensiunea dorită a etichetei şi eliberăm butonul mouse-ului;

în interiorul zonei etichetei edităm textul dorit şi, dacă dorim, putem modifica proprietăţile etichetei (culoare de fond, mărimea caracterelor etc.) selectând din meniul rapid (obţinut cu clic dreapta) eticheta Proprietăţi, ca în imaginea următoare:

Aici, pentru eticheta adăugată în formular s-a modificat culoarea de fundal.

Interogarea bazei de dateScopul principal al unei baze de date este acela de a furniza utilizatorilor ei

informaţiile de care aceştia au nevoie. Interogarea bazei (în engleză, termenul "query" desemnează interogarea, cererea, chestionarea) înseamnă adresarea unei solicitări de informaţie, pe care sistemul de gestiune a bazei de date trebuie să o rezolve şi să returneze utilizatorului răspunsul dorit. În Access, interogările pot fi:

simple – pot fi formulate pentru o singură tabelă şi se realizează: prin vizualizarea datelor conţinute în tabele (de exemplu, dorim să vedem oferta

de cursuri suplimentare şi studiem tabelul CURSURI); prin vizualizarea (parţială sau integrală) a conţinutului tabelelor, cu ajutorul

formularelor sau rapoartelor (de exemplu, dorim să cunoaştem care sunt elevii din clasele a 8-a, participanţi la cursuri suplimentare);

complexe – comportă în general mai multe tabele şi/sau cereri, ale căror date sunt extrase prin precizarea unor criterii.

Ca în orice soft complex, aşa cum este şi SGBD-ul Access, o anumită sarcină se poate rezolva în mai multe moduri. Şi pentru realizarea cererilor de interogare există mai multe modalităţi, dar vom prezenta în continuare proiectarea în modul Vizualizare Proiect.

în fereastra Database, clic pe Interogări şi apoi pe Creare interogare în modul Vizualizare proiect;

pe ecran apar fereastra Interogare de selectare şi caseta de dialog Afişare Tabel:o din caseta Afişare Tabel se selectează tabelele şi/sau cererile din care dorim să

extragem date, după care închidem caseta;o fereastra Interogare de selectare are două zone: cea superioară, în care vedem

tabelele şi/sau cererile selectate, împreună cu legăturile dintre ele şi cea inferioară, numită grilă de proiectare sau grilă QBE (Query By Example – cerere prin exemplificare), în care se va proiecta efectiv cererea.

Câmpurile din structura unei cereri sunt de două feluri: Preluate. Trecerea unui câmp din tabel/cerere în linia Câmp a grilei QBE se face prin

tragere de mouse. Trecerea tuturor câmpurilor în grilă se realizează fie cu dublu clic în bara de titlu a listei de câmpuri, clic în lista de câmpuri (pe oricare din ele) şi apoi deplasarea în grila de proiectare, fie prin deplasarea caracterului * (aflat în capul listei de câmpuri) în grilă. Această ultimă modalitate permite definirea ulterioară a unor criterii de selecţie sau de sortare.

Calculate. Pentru crearea unui câmp calculat, se selectează coloana în care dorim să apară valoarea calculată şi din meniul View se alege opţiunea Totals, care va introduce în grila QBE linia Total; se selectează (în celula aflată la intersecţia liniei Total cu coloana aleasă) Expresie din lista derulantă şi în prima linie (Câmp) se introduce formula de calcul. De exemplu, pentru a calcula un punctaj egal cu de zece ori nota obţinută la curs, formula va fi următoarea:

punctaj:[apreciere]*10

Iată şi rezultatul execuţiei cererii (se execută prin dublu clic pe pictograma sa), aşa cum a fost proiectată până în momentul de faţă:

Sortarea datelorOrdonarea datelor într-o cerere se poate realiza crescător sau descrescător, după

mai multe câmpuri numite chei de sortare. Se realizează clic în celula din grilă aflată la intersecţia coloanei câmpului de sortare cu linia Sort şi se alege între Ascending (crescător) şi Descending (descrescător). Iată grila QBE a unei cereri de interogare prin care se vizualizează elevii înscrişi la cursurile facultative, în ordinea claselor. În cadrul unei clase, elevii apar în ordine alfabetică. Prima cheie este de tip numeric iar a doua de tip text.

Rezultatul execuţiei cererii este următorul:

Se observă că ordinea câmpurilor de sortare (în cazul în care sunt mai multe) influenţează rezultatul obţinut.

Selecţia datelorPentru a selecta dintre date pe acelea care ne interesează la un moment dat se

utilizează criterii de selecţie. Acestea pot fi:

Simple. Se plasează la intersecţia coloanei câmpului pentru care formulăm criteriul cu linia Criterii din grila QBE. Principalele criterii simple sunt:o apartenenţa la un interval de valori – se formulează cu ajutorul cuvântului

rezervat BETWEEN. De exemplu, dacă ne interesează elevii cu note între 7 şi 9 criteriul pentru câmpul apreciere va fi: BETWEEN 7 AND 9;

o apartenenţa la o listă de valori – este de forma: IN (valoare1, valoare2, …). Dacă dorim să vedem datele elevilor din clasele 5, 7 şi 8, criteriul pentru câmpul clasa va fi: IN (5, 7, 8);

o utilizarea operatorilor de comparaţie: <,>,<=,>=,= şi <>(diferit). Dacă dorim să selectăm elevii cu punctaj mai mare sau cel puţin egal cu 80, criteriul pentru câmpul punctaj va fi: >=80;

o utilizarea negaţiei – se realizează cu ajutorul operatorului NOT. Dacă ne interesează toţi elevii care nu învaţă la şcoala 19, atunci criteriul pentru câmpul şcoala va fi NOT "19, Al.I.Cuza" (valoarea negată apare între ghilimele deoarece câmpul este de tip text);

o după o dată relativă la data curentă – se realizează cu ajutorul funcţiei DATE( ).

Compuse. Se constituie din criterii simple, legate între ele prin operatorii logici AND (conjuncţia) şi OR (disjuncţia). În acest sens, grila QBE utilizează mai multe linii Criterii, iar regulile pentru construcţia criteriilor compuse sunt următoarele:o criteriile simple aflate pe aceeaşi linie Criterii sunt implicit conectate prin AND

(deci vor fi satisfăcute simultan);o dacă selecţia valorilor unui câmp se face după mai multe criterii simple conectate

prin OR, acestea se vor specifica pe aceeaşi linie. Exemplu:

o dacă selecţia se face după mai multe criterii simple aplicate unor câmpuri diferite, criteriile fiind conectate prin OR, acestea se vor specifica pe linii diferite. Exemplu:

Operaţii predefiniteAccess permite realizarea unor operaţii de calcul predefinite, care se pot realiza

asupra unui întreg tabel sau asupra unui grup de înregistrări. Sunt disponibile următoarele operaţii predefinite:

SUMĂ – calculează suma valorilor unui câmp; MEDIE – calculează media aritmetică a valorilor unui câmp; MIN – returnează valoarea minimă; MAX – returnează valoarea maximă; CONTOR – numără valorile dintr-un câmp; STDEV (de la Standard deviation) – calculează abaterea medie pătratică sau

varianţa valorilor unui câmp (reprezintă o măsură a abaterii valorilor de la media lor); VAR – varianţa statistică a valorilor luate de un anumit câmp; PRIM - întoarce prima valoare din câmp; ULTIM – întoarce ultima valoare din câmp.

Pentru realizarea unei operaţii de acest gen asupra tuturor înregistrărilor tabelei se realizează următorii paşi (vom exemplifica pentru a calcula media notelor elevilor):

se creează o cerere care conţine doar câmpurile asupra cărora vor acţiona operaţiile de calcul;

se acţionează View, Totals, efectul fiind introducerea în grila QBE a liniei TOTALS, care va conţine pentru toate câmpurile operaţia Goup By în capul unei liste derulante;

se alege din lista derulantă operaţia dorită; se execută cererea prin Query, Run şi se observă rezultatul.

Iată cererea în mod proiectare şi imaginea execuţiei acesteia:

Pentru realizarea unei operaţii predefinite asupra unui grup de înregistrări, cel puţin un câmp din cerere trebuie să conţină operaţia Group By, pentru a se preciza gruparea. Dacă sunt prezente mai multe criterii de grupare, ordinea de evaluare este de la stânga la dreapta. Iată o cerere care determină mediile elevilor, grupaţi după cele 4 cursuri. În grila de proiectare se observă gruparea înregistrărilor după câmpul cod curs:

Iată şi rezultatul execuţiei cererii, pe setul de date utilizat până acum:

Se observă formatul general al câmpului AvgOfapreciere (afişarea tuturor zecimalelor semnificative), iar pentru ultima valoare rotunjirea ultimei poziţii.

RapoarteRapoartele (Reports) sau situaţiile finale constituie prezentări ale datelor pe suport de

hârtie. Aceste rapoarte au fost folosite totdeauna, constituindu-se în documente oficiale, purtătoare ale semnăturilor persoanelor autorizate. Realizarea unui raport implică prezentarea datelor dorite într-un format cât mai convenabil, conform cu necesităţile de informare (de exemplu pot conţine totaluri, subtotaluri, grafice, diagrame). În general, datele care apar în rapoarte sunt preluate din tabele sau din cereri. Mai ales dacă datele provin din mai multe tabele se preferă realizarea mai întâi a unei cereri şi apoi a raportului corespunzător. În afară de datele propriu-zise, situaţiile finale mai conţin:

controale; zone de text; cadre (pentru imagini şi grafice); etichete (pentru realizarea unui format cât mai atrăgător).Pentru a crea un raport putem folosi instrumente wizard sau proiectarea directă, dar o

metodă convenabilă este (ca şi în cazul formularelor) îmbinarea acestor două facilităţi, astfel: în fereastra Database se activează Rapoarte, apoi Creare raport utilizând Expertul; se selectează numele tabelei sau cererii care furnizează datele raportului; se trece în mod proiectare (cu clic pe Design View) şi se modifică raportul conform

dorinţei proiectantului, adăugându-se text, controale, etc.Spre exemplificare, să construim un raport care să prezinte situaţia elevilor înscrişi la

cursurile suplimentare în anul curent. Elevii să fie grupaţi pe şcoli şi pentru fiecare să se precizeze clasa şi cursul pe care îl frecventează.

Observăm că datele cerute în raport se află în trei tabele: ELEVI (numele, clasa, şcoala), REPARTIŢIE (corespondenţa elev-curs) şi CURSURI (denumirea cursului). Construim mai întâi o cerere care să adune aceste date. Iată structura sa, în mod proiectare:

Utilizând metoda descrisă anterior, construim o situaţie finală cu ajutorul instrumentului wizard, după care o modificăm astfel încât să se plaseze frumos pe o pagină A4, adăugăm un titlu, un subsol şi linii separatoare între grupurile de elevi aparţinând aceleiaşi şcoli. Forma Vizualizare Proiect a raportului este următoarea:

Zona de început a situaţiei imprimate corespunde imaginii de mai jos:

ultimele date sunt:

iar sfârşitul listei conţine ziua, data şi numărul paginii curente (din totalul de pagini).

Se observă că structura situaţiei finale include: antetul general, antetul de pagină, antetul de grup (în cazul de mai sus, cel referitor la şcoală), rândul de detaliu, subsolul de pagină şi subsolul de raport. După crearea unei situaţii finale, rezultatul poate fi vizualizat (înainte de imprimare), ceea ce permite verificarea datelor şi a aspectului general al raportului.

Ca şi în cazul celorlalte obiecte, cititorul care studiază aplicaţia Access va descoperi numeroase posibilităţi de a realiza un raport.

10.2. Bază de date pentru o activitate comercială

În cadrul acestei aplicaţii vom simula activitatea comercială a unei firme. Vom descrie furnizorii şi produsele achiziţionate de firmă, personalul firmei, clienţii si comenzile pe care aceştia le emit, precum şi modul de transport al produselor către clienţi. Vom presupune că un produs, identificat prin codul său, Produs_id, este cumpărat de la un singur furnizor, pentru a putea relaţiona tabelele Furnizori şi Produse printr-o legătură de tip 1-n. Tot pentru simplitate, vom considera că fiecare client emite câte o comandă pentru fiecare produs, astfel că tabelele Clienţi şi Comanda au o relaţie 1-n, iar tabelele Comanda şi Produs_comanda au o relaţie 1-1.

Aplicaţia este constituită din 8 tabele, având următoarele câmpuri:

1. Agenţi (Agent_id, Nume_agent, Prenume_agent, Funcţie, Născut, Angajat, Adresă, Oraş, JudeT, Cod_poştal, Tel_acasă, notes)

2. Categorie (Categorie_id, Categorie_nume, Descriere)3. Clienţi (Client_id, Denumire_client, Persoana_contact, Funcţie_contact, Adresa, Oraş,

Judeţ, Cod_poştal, Telefon, Max_comanda, Min_comanda, Discount)4. Comanda (Comanda_id, Client_id, Transportator_id, Număr_comandă, Data_comandă,

Client_nume, Client_adresa, Client_oraş, Client_cod_poştal, Discount, Data_livrării, notes, Agent_id)

5. Furnizori (Furnizor_id, Denumire_furnizor, Persoana_contact, Funcţie_contact, Adresa, Oraş, Judeţ, Cos_postal, Telefon)

6. Produs_comanda (Comandă_id, Produs_id, Pret_unitar, Cantitate)7. Produse (Produs_id, Furnizor_id, Categorie_id, Nume_produs, Unitate_măsură,

Preţ_unitar)8. Transportatori (Transportator_id, Denumire_transportator).

Acest model logic al aplicaţiei evidenţiază atât cheile primare (subliniate cu linie continuă), cât şi cheile externe (subliniate cu linie punctată).

Crearea tabelelor se poate realiza în trei moduri: utilizând fereastra de proiectare (Creare tabel în modul Vizualizare proiect). Este

modalitatea recomandată, pe care o vom explica în continuare. utilizând instrumentul Wizard (Creare tabel utilizând Expertul). Se creează tabele prin

alegerea unor câmpuri standard. prin introducerea datelor (Creare tabel prin introducere date). Această modalitate nu

poate fi aplicată aplicaţiilor complexe, dar este utilă în cazul aplicaţiilor foarte simple, în care avem nevoie de rapiditate în crearea tabelelor.

Dacă selectăm opţiunea Creare tabel în modul Vizualizare proiect, se deschide o fereastră în care se precizează structura tabelului: numele câmpurilor, tipul şi proprietăţile acestora.

Tipurile de bază din Access sunt următoarele: Text. Un câmp de acest tip conţine cel mult 255 caractere (implicit, lungimea este de

50). De tip text sunt definite câmpurile care conţin nume de persoane, denumiri, adrese etc.

Memo. Pot conţine cel mult 64000 caractere (cu comentarii, explicaţii). Câmpurile de tip Text şi Memo sunt numite alfanumerice (pot conţine caractere şi/sau numere). Iată exemple de valori alfanumerice (le vom delimita cu " "): "Dragoş", "Mircea cel Bătrân", "Oţel laminat OL 50", "X4532A", "345990".

Număr. Este tipul numeric, cu mai multe subtipuri disponibile, determinate de dimensiunea câmpului:o Octet – valori întregi, pozitive, reprezentate pe un octet;o Întreg - valori întregi, pozitive şi negative, pe doi octeţi;o Întreg lung – valori întregi, pozitive şi negative, pe patru octeţi;o Simplă precizie – valori reale, cu cel mult 7 zecimale, pozitive şi negative, pe

patru octeţi;o Dublă precizie - valori reale, cu cel mult 15 zecimale, pozitive şi negative, pe opt

octeţi;o ID reproducere – identificator global unic, pe 16 octeţi;o Zecimal - valori întregi, pozitive şi negative, pe 16 octeţi.

Dată/Oră. Este un tip special creat pentru date calendaristice sau de tip oră, întrucât aceste valori se întâlnesc adesea în documente, înregistrări. Permite, de asemenea, diferite formate de afişare, de exemplu: Sunday, August 11, 2003 şi 8/11/03 reprezintă data de 11 august 2003, duminică iar 5:00:00 PM şi 17:00 reprezintă ora 3 după amiază.

Monedă. Acest format fix, cu patru zecimale, permite lucrul cu valori monetare. AutoNumerotare. Câmpurile de acest tip sunt completate în mod automat pentru

fiecare înregistrare adăugată într-o tabelă, fie crescător, fie cu valori aleatoare (întâmplătoare), după cum alege utilizatorul.

Da/Nu. Conţin de fapt valori logice, reprezentate prin –1 (pentru Yes, True – adevărat) şi prin 0 (pentru No, False – fals).

Observaţie. Câmpurile de tip: Număr, AutoNumerotare, Da/Nu şi Monedă sunt de tip numeric, deci conţin numere reprezentând: cantităţi, coduri, sume de bani, valori logice de adevăr. Iată exemple de valori numerice: 23.90, 6785, 1. Vom vedea că o dată numerică poate fi afişată în formate diferite.

Obiect OLE. Reprezintă obiecte mari, de tipul imaginilor, desenelor, fişierelor audio. Hyperlink. Conţine un text ce este o adresă a unei pagini Web. Expert căutare. Creează câmpuri care permit alegerea de valori din cadrul unor

structuri (tabele, liste), deci permit legarea informaţiilor.

Iată fereastra de proiectare a tabelului Agenţi:

Observăm cheia primară Agent_id şi proprietăţile câmpului Nume_agent. După realizarea tuturor tabelelor, relaţiile se construiesc astfel: se acţionează butonul Relationships de pe bara Database, în fereastra Afişare Tabel se includ toate tabelele deja create, prin selectarea lor şi apoi punctarea repetată a butonului Adăugare:

Apoi se realizează fiecare relaţie (asociere), prin glisare a mouse-ului de la tabelul care conţine cheia primară, către tabelul care conţine cheia externă. La fiecare relaţie, va apărea câte o fereastră de editare, unde se punctează opţiunea Impunere integritate referenţială, pentru a proteja baza de date la erori cum ar fi următoarea: există produse dintr-o categorie care nu este încă definită.

Imaginea finală a ferestrei Relaţii este prezentată în continuare.

Introducerea articolelor în tabele se realizează astfel: în fereastra Bază de date se efectuează dublu-clic pe numele tabelului (de exemplu, Furnizori) şi se introduc valorile câmpurilor din fereastra care se deschide. În imaginea următoare, se observă cum tabelul Furnizori are 15 articole. La fel se introduc articole în toate tabelele, în ordinea indicată de relaţiile deja definite. Dacă se produc erori din punctul de vedere al integrităţii referenţiale, acestea sunt semnalate printr-un mesaj care cere corectarea câmpului respectiv.

O metodă alternativă pentru introducerea de articole într-un tabel este realizarea unui formular, care să ofere o altă prezentare a câmpurilor. Un formular creat în modul Vizualizare proiect este individualizat, deoarece permite intervenţia programatorului la un nivel înalt. În continuare vom prezenta crearea în acest mod a formularului pentru introducerea comenzilor.

În fereastra Bază de date se selectează opţiunea Formulare şi apoi Creare formular în modul Vizualizare proiect. După apariţia ferestrei de editare a formularului, prin clic dreapta pe titlul ferestrei deschidem un meniu contextual din care alegem ultima opţiune: Proprietăţi.

Fereastra Formular permite alegerea tabelului în care vom introduce date, prin clic de eticheta Date şi derularea listei de opţiuni posibile pentru Sursă înregistrări. Alegem tabelul Comanda şi observăm că apare o nouă fereastră care conţine lista câmpurilor acestuia:

Prin tragerea câmpurilor din această fereastră (cu ajutorul mouse-ului) până în zona Detaliu a formularului, fixăm poziţiile lor pe grilă.

Fiecare element al formularului este alcătuit dintr-un text explicativ, respectiv numele câmpului şi o zonă de introducere a valorii câmpului respectiv. În figura de mai jos este selectat elementul corespunzător numărului comenzii. Deplasarea relativă a componentelor se realizează prin tragere de colţul stânga-sus, evidenţiat. Deplasarea integrală se face prin tragere de margine.

Pentru a obţine o aliniere, se pot selecta mai multe elemente, prin menţinerea apăsată a tastei Shift şi tragere de mouse. Apoi se deschide meniul contextual ataşat prin clic dreapta pe unul dintre elementele selectate. Din acesta alegem opţiunea Align, Stânga. Prin clic dreapta pe grilă putem alege opţiunea Proprietăţi, care permite selectarea din eticheta Format a unei culori a grilei (opţiunea Culoare fundal).

Din acelaşi meniu putem îmbogăţi formularul prin adăugarea unui antet/subsol ale paginii sau ale întregului formular (Page Header/Footer, Form Header/Footer).

Întroducerea datei şi a orei curente se face prin alegerea din meniul Insert a opţiunii Date and Time.

Introducerea numărului curent de pagină se face din acelaşi meniu, opţiunea Page numbers.

La subsolul formularului, introducem menţiunea de responsabilitate, sub forma unei etichete care conţine numele persoanei care a realizat formularul.

Imaginea următoare prezintă formularul, în modul proiectare.

Acest formular, folosit la introducerea datelor, are următorul aspect:

Să presupunem acum că patronatul doreşte o situaţie a angajaţilor, în care să se specifice, grupat pe funcţii:

- numele complet al agenţilor,- data angajării,- oraşul de domiciliu şi- numărul lor de telefon.

Pentru a rezolva această cerinţă, se va edita o interogare: în fereastra Bază de date se selectează Interogări şi se alege opţiunea Creare interogare în modul Vizualizare proiect. Se adaugă apoi tabela Agenţi, iar în grilă se introduc câmpurile preluate:

- Nume_agent- Prenume_agent- Functie- Angajat- Oras- Tel_acasa.

Pentru a realiza cererea, pe rândul Sortare se selectează Ascendentă la câmpurile Functie şi Angajat. Interogarea se salvează cu numele Agenti Query şi se execută prin dublu clic pe numele său în fereastra Bază de date.

Iată rezultatul execuţiei interogării Agenti Query:

Rapoartele sunt situaţii finale, care nu mai permit intervenţii ale operatorului. Să presupunem că se doreşte realizarea unui raport care să conţină agenţii firmei, grupaţi după oraşele de reşedinţă. În fereastra Bază de date se selectează Rapoarte şi se alege opţiunea Creare raport utilizând Expertul. În prima fereastră de dialog se aleg câmpurile care se includ

în raport, prin transfer din stânga în dreapta cu ajutorul butoanelor şi . Primul buton transferă câmpul curent, iar cel de-al doilea transferă toate câmpurile în viitorul raport.

Urmează adăugarea nivelurilor de grupare a articolelor, în cazul nostru este necesară

gruparea după câmpul Oraş, care se alege prin clic pe butonul .

Pentru o aşezare plăcută a articolelor în raport, se alege o sortare a agenţilor din fiecare grup, crescătoare după câmpul Nume_agent.

Dintre modurile de prezentare, alegem Block, stilul Comun:

În final, alegem numele raportului: Agenţi. Observăm că aplicaţia poate manevra obiecte diferite (tabel şi raport) cu acelaşi nume.

După salvare, executăm raportul prin dublu-clic pe numele său din fereastra Bază de date. Imaginea următoare prezintă o parte din raportul Agenţi.

10.3. Bază de date pentru gestiunea unui parc auto

Această aplicaţie propune realizarea unei baze de date conţinând informaţii despre maşinile dintr-un garaj. Pentru fiecare maşină se vor memora informaţii cum ar fi:

- tipul maşinii;- destinaţia: transport de persoane sau marfă;- firma producătoare;- data fabricaţiei;- capacitatea cilindrică;- număr km. parcurşi;- consumul specific;- data achiziţionării.;

Aplicaţia va fi dotată cu facilităţi referitoare la validarea datelor introduse. Când numărul opţiunilor (pentru valorile unei anumite date) este mic, se vor pune la dispoziţia utilizatorilor opţiunile din care aceştia să aleagă. Vor fi prevăzute principalele operaţii efectuate asupra datelor în bazele de date:

- adăugarea de noi date;- modificarea datelor existente;- ştergerea datelor;- afişarea datelor pe ecran şi la imprimantă.

Tipul datelor necesar a fi stocate sugerează „un inventar al garajului” la un moment dat. Maşinile garajului au între ele elemente comune (de exemplu: pot fi de aceeaşi marcă şi tip sau culoare), după cum la momentul executării „inventarului” unele maşini pot fi plecate în cursă. De asemenea, pot apărea maşini noi în garaj. Există date ce evoluează datorită unor „tranzacţii” neevidenţiate (km parcurşi). Modelul informatic al unui garaj real este mai complex decât cel sugerat aici. În această abordare, nu considerăm modificarea tabelelor, adică nu vom modela situaţii de genul:

- apariţia unor maşini noi;- casarea unor maşini;- plecarea în cursă a unor maşini;- vopsirea (în altă culoare) a unor maşini;- schimbarea numărului de circulaţie.

Singurul câmp care se modifică natural, ca urmare a efectuării curselor şi nu ca urmare a unor greşeli sau evenimente excepţionale, este „numărul de km parcurşi”. Formula de actualizare a acestui câmp este:

n

i 1

icursa] km[nr initiali] kmnr [parcursi] km[numar

Tabelul următor prezintă datele ce vor trebui memorate:

Câmp Entitate EvolutivTipul maşinii BDestinaţie: transport de persoane sau marfă BFirma producătoare AData fabricaţiei CCapacitatea cilindrică BNumăr km. parcurşi D DaConsumul specific BData achiziţionării C

De aici rezultă primele patru entităţi: firma producătoare de maşini; tipul (marca) maşinii; maşina propriu-zisă; cursa;

Vom observa că, la modul general, asimilând cursa cu un convoi auto omogen, o cursă poate avea mai multe maşini şi mai mulţi şoferi.

Cerinţele problemei specifică validarea datelor introduse. Validarea este un instrument informatic ce împiedică apariţia unor greşeli de introducere simple cât şi a unor

inconsistenţe greu de verificat fără instrumente informatice (exemplu: coduri unice atribuite repetat). Bazele de date relaţionale s-au îndepărtat puternic de modelul „validării batch”, care se aplică post-factum pe loturi de date, deoarece au introdus integritatea referenţială bazată pe chei unice, chei străine şi verificări simple (numerice, logice) înglobate direct în baza de date şi nu în program. Validările bazate pe integritatea referenţială sunt însă adeseori completate cu validări-program pe formularele de introducere.

În cele ce urmează, vom înţelege garajul ca o unitate (agent economic) ce dispune de maşini cu care efectuează curse. Aceste curse determină tranzacţii, stocate fiecare din ele în baza de date. Ca urmare a curselor, se modifică numărul de km. parcurşi de fiecare maşină. Iată cum arată fereastra Relationships a bazei de date.

Cu excepţia colţului din stânga-jos, unde sunt specificate două interogări necesare pentru calculul numărului de km. parcurşi, toate celelalte sunt tabele, având relaţii între ele.

În plus fată de tabele definite deja, în procesul de analiză s-au considerat necesare şi: şoferi; culori (ale maşinilor); tip transport; date (adică tranzacţiile curselor).Cursele sunt cele care determină tranzacţiile. Şoferii fac parte integrantă din

„resursele principale ale curselor”, împreună cu maşinile. Culorile nu apar la fel de importante, însă în proiectare unei baze de date amănuntele sunt semnificative. Am disociat tip transport de marca maşinii, deoarece reprezintă o caracteristică comună mai multor maşini, ca şi culorile maşinilor (pot fi mai multe astfel de caracteristici comune: cauciucuri, tip carburant, ulei, practic lista poate fi mare, dar ne vom limita la acestea două). Datele (tranzacţiile curselor) construiesc numărul de km. parcurşi ai fiecărei maşini.

Relaţiile sunt toate de tipul 1 - n, având fiecare coduri interne ale bazei de date cu cheie unică pe partea 1 a relaţiilor (reprezentată cu bold). Tabelul Date are cheie unică pe toate cele 3 câmpuri concatenate, pentru asigurarea unei normalizări suficiente şi protecţie la duplicate incorecte. Acest lucru se realizează astfel: după definirea numelui câmpurilor, a tipului şi descrierii lor, se selectează cu butonul Shift ţinut apăsat toate câmpurile tabelului şi

se efectuează clic pe butonul Primary Key din bara de instrumente Table Design. Selecţia câmpurilor se face prin tragere de mouse, în faţa numelui câmpurilor, pe zona gri. Rezultatul este prezentat în imaginea următoare.

Următoarea imagine prezintă fereastra Bază de date a aplicaţiei, cu obiectele de tip tabel.

Paşii necesari realizării aplicaţiei sunt următorii:1. Proiectarea „pe hârtie” a structurilor de date, conform modelului „entitate-relaţie”;2. Crearea în access a tabelelor (câmpuri, indecşi, chei unice, validări interne), adică a

celor 8 tabele din structura anterioară;3. Legarea tabelelor, prin relaţii, asigurând integrităţile referenţiale cu cheia străină

(secundară);4. Proiectarea părţii vizuale a formularelor (fără elemente de programare VBA access);5. Adăugarea de cod de validare vba pe câmpurile de introducere date ale formelor;6. Legarea (după o logica simplă) a formularelor între ele, prin cod vba;7. Crearea rapoartelor şi conectarea prin diverse controale;8. Crearea de interogări înglobate pentru aflarea numărului de km parcurşi.

S-au folosit controale vizuale: câmpuri text/numerice/date calendaristice, combo, liste, butoane, control-tab. S-au folosit atât forme simple, cât şi mai complexe (tab-uri, master-detail), pentru care Access oferă suport puternic şi accesibil. S-au folosit controalele de navigare implicite ale Access. Toate cheile unice sunt pe câmpuri de tip Autonumerotare (secvenţe). Următoarea imagine prezintă fereastra Bază de date a aplicaţiei, cu obiectele de tip formular.

Formularul Startup se autolansează. Codul Visual Basic este următorul

Option Compare Database

Private Sub Detail_Click()

End Sub

Private Sub Form_Open(Cancel As Integer) DoCmd.SelectObject acForm, "Startup", True DoCmd.Minimize DoCmd.Hourglass FalseEnd Sub

Private Sub Start_Click()On Error GoTo Err_Start_Click Dim stDocName As String Dim stLinkCriteria As String stDocName = "Curse" DoCmd.Close DoCmd.OpenForm stDocName, , , stLinkCriteriaExit_Start_Click: Exit SubErr_Start_Click: MsgBox Err.Description Resume Exit_Start_ClickEnd Sub

Imaginea formularului care se deschide automat la lansarea aplicaţiei este următoarea:

După clic pe butonul , acest formular lansează formularul Curse, care este practic cel mai complex formular al aplicaţiei. În continuare sunt oferite trei imagini ale acestui formular, pentru a prezenta respectiv: resursele cursei, resursele pentru toate cursele şi distanţa totală parcursă.

Schema obiectelor este următoarea:

Observaţii:- săgeţile groase deschid prin dublu clic (pe grid) opţiunile respective;- săgeţile groase punctate deschid prin clic opţiunile respective.

Codul formularului Curse este următorul:

Option Compare Database

Private Sub AddSofer_Click()On Error GoTo Err_AddSofer_Click DoCmd.GoToRecord , , acNewRecExit_AddSofer_Click: Exit SubErr_AddSofer_Click: MsgBox Err.Description Resume Exit_AddSofer_ClickEnd Sub

Private Sub Data_Sfarsit_Exit(Cancel As Integer) On Error GoTo Err_Data_Sfarsit_Exit If IsNull(Me![Data Sfarsit]) Then MsgBox "Completati Data Sfarsit" Cancel = -1 Else If Not IsNull(Me![Data Start]) Then If Me![Data Start] > Me![Data Sfarsit] Then MsgBox "Data de sfarsit nu poate fi inaintea datei de start" Cancel = -1 End If End If End If

Formular

Curse

Formular

Curse

Resursele Cursei

Resursele Cursei Grid R/W

(soferi,masini)

Grid R/W(soferi,masini) Forma Soferi

Forma Soferi

Forma MasiniForma Masini

Buton soferi

Buton masini

Buton Adaugare

Buton Listare

Resursele tururor curselor

Resursele tururor curselor

Distanta Parcursa Totala

Distanta Parcursa Totala

Buton Preview

Buton Stergere

Raport: CurseRaport: Curse

Grid R/O(soferi,masini-total)

Grid R/O(soferi,masini-total)

Grid R/O(distante pe masini)

Grid R/O(distante pe masini)

Cod Cursa

Data Start

Data Sfarsit

Distanta (km)

Note

Exit_Data_Sfarsit_Exit: Exit SubErr_Data_Sfarsit_Exit: MsgBox Err.Description Resume Exit_Data_Sfarsit_ExitEnd Sub

Private Sub Data_Start_Exit(Cancel As Integer) On Error GoTo Err_Data_Start_Exit If IsNull(Me![Data Start]) Then MsgBox "Completati Data Start" Cancel = -1 Else If Not IsNull(Me![Data Sfarsit]) Then If Me![Data Start] > Me![Data Sfarsit] Then MsgBox "Data de sfarsit nu poate fi inaintea datei de start" Cancel = -1 End If End If End IfExit_Data_Start_Exit: Exit SubErr_Data_Start_Exit: MsgBox Err.Description Resume Exit_Data_Start_ExitEnd Sub

Private Sub DeleteBtn_Click()On Error GoTo Err_DeleteBtn_Click DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70 DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70Exit_DeleteBtn_Click: Exit SubErr_DeleteBtn_Click: MsgBox Err.Description Resume Exit_DeleteBtn_ClickEnd Sub

Private Sub Distanta_Exit(Cancel As Integer) On Error GoTo Err_Distanta_Exit If IsNull(Me![Distanta]) Or Me![Distanta] = 0 Then MsgBox "Distanta cursei trebuie sa fie mai mare ca zero" Cancel = -1 End If DoCmd.Requery DoCmd.DoMenuItem acFormBar, acRecordsMenu, 5, , acMenuVer70 [Note].SetFocusExit_Distanta_Exit: Exit SubErr_Distanta_Exit: MsgBox Err.Description Resume Exit_Distanta_ExitEnd Sub

Private Sub Open_Soferi_Click()On Error GoTo Err_Open_Soferi_Click Dim stDocName As String Dim stLinkCriteria As String stDocName = "Soferi" DoCmd.OpenForm stDocName, , , stLinkCriteria

Exit_Open_Soferi_Click: Exit SubErr_Open_Soferi_Click: MsgBox Err.Description Resume Exit_Open_Soferi_ClickEnd SubPrivate Sub Open_Masini_Click()On Error GoTo Err_Open_Masini_Click Dim stDocName As String Dim stLinkCriteria As String stDocName = "Masini" DoCmd.OpenForm stDocName, , , stLinkCriteriaExit_Open_Masini_Click: Exit SubErr_Open_Masini_Click: MsgBox Err.Description Resume Exit_Open_Masini_ClickEnd Sub

Private Sub TabCtl10_Change()On Error GoTo Err_TabCtl10_Change DoCmd.Requery DoCmd.DoMenuItem acFormBar, acRecordsMenu, 5, , acMenuVer70Exit_TabCtl10_Change: Exit SubErr_TabCtl10_Change: MsgBox Err.Description Resume Exit_TabCtl10_ChangeEnd Sub

Private Sub PreviewBtn_Click() On Error GoTo Err_PreviewBtn_Click Dim stDocName As String stDocName = "Curse" DoCmd.OpenReport stDocName, acPreviewExit_PreviewBtn_Click: Exit SubErr_PreviewBtn_Click: MsgBox Err.Description Resume Exit_PreviewBtn_ClickEnd Sub

Private Sub PrintBtn_Click() On Error GoTo Err_PrintBtn_Click Dim stDocName As String stDocName = "Curse" DoCmd.OpenReport stDocName, acNormalExit_PrintBtn_Click: Exit SubErr_PrintBtn_Click: MsgBox Err.Description Resume Exit_PrintBtn_ClickEnd Sub

Formularul Maşini permite vizualizarea datelor şi introducerea de noi articole în baza de date.

Butonul acţionat cu dublu clic deschide forma de editare/adăugare item listă. Butonul

permite vizualizarea unui raport asupra maşinilor. Butonul permite tipărirea

acestui raport, iar butonul permite ştergerea unui maşini din baza noastră de date.

Formularul Tip_Transport este mai simplu:

Codul VBA al acestui formular este următorul:

Option Compare Database

Private Sub Form_Load() If Me.OpenArgs = "GotoNew" And Not IsNull([Cod Tip Transport]) Then DoCmd.DoMenuItem acFormBar, 3, 0, , acMenuVer70

End IfEnd Sub

Private Sub SaveBtn_Click()On Error GoTo Err_SaveBtn_Click DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70Exit_SaveBtn_Click: Exit SubErr_SaveBtn_Click: MsgBox Err.Description Resume Exit_SaveBtn_ClickEnd Sub

Private Sub DelBtn_Click()On Error GoTo Err_DelBtn_Click DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70 DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70Exit_DelBtn_Click: Exit SubErr_DelBtn_Click: MsgBox Err.Description Resume Exit_DelBtn_ClickEnd Sub

Private Sub ExitBtn_Click()On Error GoTo Err_ExitBtn_Click DoCmd.CloseExit_ExitBtn_Click: Exit SubErr_ExitBtn_Click: MsgBox Err.Description Resume Exit_ExitBtn_ClickEnd Sub

Dintre rapoartele ce se pot realiza în cadrul aceastei aplicaţii, prezentăm Curse şi Tip maşină:

Interogările Distanţe şi Distante Query sunt prezentate în continuare.

Fereastra interogării Distanţe presupune adăugarea tabelelor Date şi Curse, iar în grila QBE a câmpurilor Cod Identificare Masina, Cod Cursa din tabela Date şi a câmpului Distanţa din tabelul Curse.

Comanda SQL corespunzătoare interogării este:

SELECT DISTINCT Date.[Cod Identificare Masina], Date.[Cod Cursa], Curse.DistantaFROM Curse INNER JOIN [Date] ON Curse.[Cod Cursa]=Date.[Cod Cursa];

Această comandă este vizibilă dacă din meniul View se alege opţiunea SQL View.

Interogarea Distante Query necesită adăugarea tabelelor Masini şi Distante, iar în grilă se includ câmpurile Cod Identificare Masina, Număr Maşină, Nr Km Iniţiali din tabela Maşini şi câmpul calculat Distanţe Parcurse, aflat pe baza valorilor câmpului Distanţa din tabela Distanţe. În plus, se afişează articolele sortate ascendent după primul câmp al interogării.

Comanda SQL aferentă acestei interogări este:

SELECT DISTINCTROW Masini.[Cod Identificare Masina], Masini.[Numar Masina], Masini.[Nr Km Initiali], Sum(Distante.Distanta) AS [Distante Parcurse]FROM Masini LEFT JOIN Distante ON Masini.[Cod Identificare Masina] = Distante.[Cod Identificare Masina]GROUP BY Masini.[Cod Identificare Masina], Masini.[Numar Masina], Masini.[Nr Km Initiali]ORDER BY Masini.[Cod Identificare Masina];

Funcţiile aplicaţiei

Aplicaţia „Garaj” asigură gestiunea operativă a principalelor resurse ale unui garaj (privit ca un agent economic), care efectuează curse cu maşini şi şoferi. Fiecare cursă este memorată individual:

- data start a cursei;- data sfârşit a cursei;- distanţa cursei;- note despre cursă;- maşini în cursă (pot fi mai multe într-o cursă);- şoferi în cursă (pot fi mai mulţi într-o cursă).

Se pot adăuga resurse (maşini, şoferi) la garaj. Se pot şterge doar cele complet nefolosite. Pot exista mai multe maşini de acelaşi tip în garaj. Cursele determina tranzacţiile curselor:

Tranzacţie=(cod cursă, cod maşină, cod şofer).Aplicaţia este scrisă în Microsoft Access 2000, constând dintr-un fişier Garaj_lg.mdb

(conform paradigmei Access, acesta conţine tabele, relaţiile între tabele, formulare, rapoarte, interogări, codul VBA). Pentru introducerea datelor se folosesc formulare cu funcţii de validare (care ghidează utilizatorul).

Funcţiile aplicaţiei sunt cele generale ale unei aplicaţii de baze de date, dar şi specifice. Pe scurt, aplicaţia Garaj memorează utilizarea în curse a resurselor (maşini, şoferi) pentru o anumită perioadă de timp, furnizând un punct de vedere raţional asupra gradului de utilizare a acestor resurse, cât şi asupra distanţelor parcurse sau planificarea consumului de carburant pentru curse. Funcţia principală este aceea că oferă managementului garajului

suport atât pentru deciziile operative, cât şi pentru planificare şi pentru control, având în centrul atenţiei cursele auto.

Toate intrările/ieşirile sunt conforme cu schema:

Utilizator Aplicaţie Microsoft Access Sistem de operare PC hard disc PC monitor PC imprimantă

Elementele vizuale (formulare şi rapoarte) ale aplicaţiei au fost deja prezentate. Formularul autoexecutabil Startup determină lansarea formularului Curse (ecranul principal al aplicaţiei). Gridul Resursele cursei este manevrabil cu instrumente implicite (tastele Insert, Delete, Escape) la nivel de rând, pe care se face şi validarea. Dublu clic pe câmpurile Maşini, Şoferi ale grid-ului din Resursele cursei lansează formularele Maşini/Şoferi (ceea ce se poate face şi cu butoanele respective).

În aplicaţie, simbolul este alăturat unei liste ce ramifică programul spre forme de introducere date (sau editare).

Posibilităţi de modernizare/dezvoltare a aplicaţieiAvând în vedere că este vorba de o aplicaţie simplă, posibilităţile de

modernizare/dezvoltare sunt vaste: adăugarea de validări suplimentare atât pe baza de date propriu-zisă, cât şi pe

formulare; adăugarea ca tranzacţii noi a celor determinate de cumpărarea/vânzarea unor maşini

din garaj; adăugarea ca tranzacţii a consumului efectiv de combustibil (curse, maşini); adăugarea diagramelor de planificare a resurselor garajului; adăugarea unor rapoarte de consum de combustibil; crearea unei aplicaţii mono-formular (formularele multiple pot fi obositoare); adăugarea suportului tranzacţional multi-user; trecerea la modelul client/server.

10.4. Bază de date pentru contabilitatea TVA

Aplicaţia Access prezentată în acest paragraf a fost realizată în scopul automatizării contabilităţii TVA din cadrul unei societăti comerciale, pe care să o numim, fictiv, SC ADES SA. Aplicaţia urmăreşte eficientizarea activităţii contabile, a intrărilor şi a ieşirilor de mărfuri cu documentele aferente acestei activităţi.

Societatea comercială ADES SRL are ca obiect principal de activitate comerţul cu ridicata al mărfurilor alimentare. Se doreşte, ca în baza evidenţelor corespunzătoare facturilor de intrări şi ieşiri să se realizeze rapoartele jurnal de cumpărare şi vânzare pentru luna decembrie 2004; din acestea se extrag situaţiile referitoare la TVA-ul deductibil şi TVA-ul colectat, din care să rezulte TVA-ul de plată sau TVA-ul de recuperat de la bugetul de stat.

Nivelul (modelul) conceptual

Nivelul conceptual este nivelul central care reflectă datele structurate astfel încât acestea să poată fi preluate şi prelucrate cu ajutorul unui SGBD.

Schema conceptuală stă la baza modelului conceptual care va permite definirea proprietăţilor elementare ale obiectelor care interesează în cadrul SC ADES SA, gruparea acestora, în funcţie de criterii de omogenitate stabilite, în scopul descrierii obiectelor lumii reale şi a relaţiilor dintre ele. Sunt definite regulile de care trebuie să se ţină seama în manevrarea datelor existente. Pe baza regulilor de gestiune se stabilesc cardinalităţi sau conectivităţi între realizările atributelor din entităţi şi cele ale proprietăţilor din asocieri (corespondenţe). Acestea exprimă maniera de participare a valorilor atributelor din entităţi la fiecare apariţie de valori din asocieri. Putem vorbi despre o conectivitate minimă (0 sau 1) şi una maximă (1 sau n). Vom utiliza modelul entitate – asociere.

În urma analizei problemei rezultă următoarele entităţi, care sunt modelate de tabele:

t_soc, t_furn, t_fact_furn, t_fact_furn_prod, t_client, t_fact_client, t_fact_client_prod.

Identificarea corespondenţelor între aceste entităţi este următoarea:

t_furn cu t_fact_furn - un furnizor poate emite de la 1 la n facturi, rezulta o corespondenţă EMITE;

t_fact_furn cu t_fact_furn_prod - este o relaţie de la 1 la n, unei facturi îi corespund una sau mai multe înregistrări din tabela t_fact_furn_prod, rezultă deci o corespondenţă LINIE FACTURA - PRODUSE FURNIZOR;

t_client cu t_fact_client, se emite factura către clienţi, este o relaţie de 1 la n, corespondenţa este RECEPTIE;

t_fact_client cu t_fact_client_prod, relaţia este de 1 la n, corespondenţa este LINIE FACTURA - PRODUSE CLIENT.

Stabilirea cardinalităţilor

Corespondenţa EMITEa) dinspre entitatea furnizor (1, n)

- un furnizor emite cel puţin o factură (cardinalitate 1)- un furnizor poate emite mai multe facturi (cardinalitate n)

b) dinspre entitatea factură (1, 1)- factura este emisă de cel puţin şi de cel mult un furnizor (cardinalitate 1, 1)

Corespondenţa LINIE FACTURA PRODUSE FURNIZORa) dinspre entitatea factura (1, n)

- factura conţine cel puţin un produs (cardinalitate 1)- factura poate conţine mai multe produse (cardinalitate n)

b) dinspre entitatea produse (1, n)- un produs este inclus în cel puţin o factură (cardinalitate 1)- un produs poate fi inclus în mai multe facturi (cardinalitate n)

Corespondenţa RECEPTIEa) dinspre entitatea client (1, n)

- un client primeşte cel puţin o factură (cardinalitate 1)- un client poate primi mai multe facturi (cardinalitate n)

b) dinspre entitatea factura (1, 1)- factura este recepţionată de cel puţin şi de cel mult un client (cardinalitate 1,1)

Corespondenţa LINIE FACTURA - PRODUSE CLIENTa) dinspre entitatea factură (1, n)

- factura conţine cel puţin un produs (cardinalitate 1)- factura poate conţine mai multe produse (cardinalitate n)

b) dinspre entitatea produse (1, n)- un produs este inclus în cel puţin o factură (cardinalitate 1)- un produs poate fi inclus în mai multe facturi (cardinalitate n).

Nivelul logic sau modelul relaţional al datelor

Modelul logic al datelor este reprezentat de următoarea colecţie de tabele:

t_soc (id-soc, denumire, CUI, judet, localit, strada, cod_postal, sector, telefon, administrator, banca, cont_bancar)

t_furnizor (id-furn, cui, denumire, sediu, telefon) t_fact_furn (id-fact, id_furn, nr_fact, data, cota_tva) t_fact_furn_prod (id-fact, nr_crt, explicatie, cant, pret_fara_tva) t_client (id-client, cui, denumire, sediu, telefon) t_fact_client (id-fact, id_client, nr_fact, data, cota_tva) t_fact_client_prod (id-fact, nr_crt, explicatie, cant, pret_fara_tva)

În reprezentarea de mai sus, atributele subliniate cu linie continuă caracterizează în mod unic realizările de entitate (un identificator de societate este specific unei societăţi şi numai uneia, aceeaşi proprietate este valabilă pentru identificatorul unui furnizor, fiecare furnizor are un identificator de furnizor).

Câmpurile subliniate cu linie punctată au un rol de legătură, modelează relaţiile între entităţile identificate în faza de analiză. Aceste câmpuri sunt cheile secundare sau externe (de exemplu, id_furn pentru tabela t_fact_furn, id_client pentru tabela t_fact_client).

Nivelul intern sau modelul fizic al datelor

Nivelul intern (modelul fizic) este cel ce corespunde structurii în care sunt stocate datele în interiorul calculatorului. Sunt specificate tabelele (fişierele) care le conţin (nume, organizare, localizare, etc.), componentele fiecărui fişier (lungime, câmpuri), căile de acces la componentele tabelelor (indecşi, relaţii, legături între tabele).

Relaţii între tabele

Pentru eficientizarea bazei de date este necesară separarea datelor în mai multe tabele, fiecare având o temă bine definită. Prin această separare se evită redundanţa. Tabelele astfel rezultate se relaţionează, adică se leagă prin relaţii.

În figura următoare se poate observa fereastra de relaţii a bazei de date.

Primul pas în stabilirea relaţiilor între tabelele bazei de date constă în alegerea tipului de relaţie folosit: în această aplicaţie, toate cele patru relaţii sunt de tipul 1 - n. Urmează realizarea acestor relaţii: se deschide fereastra Relaţii şi se adaugă toate tabelele; apoi se trage cu ajutorul mouse-ului câmpul din prima tabelă către câmpul corespondent din cea de-a doua tabelă; la deschiderea ferestrei Editare relaţii se bifează opţiunile Impunere integritate referenţială, Actualizare în cascadă câmpuri corelate, Ştergere în cascadă câmpuri corelate.

Formulare Formularele acestei aplicaţii oferă o interfaţă atractivă pentru vizualizarea sau

introducerea datelor din tabele. Prin faptul că urmăresc introducerea sau modificarea datelor din tabele, după anumite reguli stricte, impuse de programator, permit eliminarea erorilor provocate de utilizatori la manevrarea datelor.

În cadrul acestei aplicaţii formularele îndeplinesc funcţii de: introducere a datelor, formularele fiind create pentru fiecare tabel, în scopul introducerii

datelor în altă formă decât cea tabelară, creându-se o interfaţă deosebită; afişare a datelor într-o formă dorită de utilizator, în scopul consultării acestora; editare a datelor, datele afişate în cadrul formularelor pot fi modificate sau şterse.

Aplicaţia conţine următoarele formulare :

1. Formularul principal, în care sunt evidenţiate funcţiile acestei aplicaţii:

2. Formularul cu datele de identificare ale societăţii:

3. Formularul cu datele despre furnizorii de produse:

4. Formularul ce conţine facturile emise de furnizorii societăţii ADES SA, cu produsele achiziţionate de la aceştia:

5. Formularul cu datele de identificare ale clienţilor:

6. Formularul ce conţine facturile emise clienţilor de către SC ADES SA, cu produsele vândute acestora:

7. Subformular ce conţine facturile emise de furnizori cu produsele aferente achiziţionate de SC ADES SA :

8. Subformular ce conţine facturile emise clienţilor de societate:

Interogări

Interogările sunt realizate pentru extragerea datelor şi afişarea organizată a acestora în diferite modalităţi necesare utilizatorilor. Interogările realizate în cadrul acestei aplicaţii sunt complexe, utilizându-se mai multe tabele, din care datele sunt extrase prin precizarea unor criterii.

Pentru realizarea interogărilor s-a ales lucrul în modul Proiectare:- în fereastra Bază de date, clic pe Interogări şi apoi pe Nou;- apare caseta de dialog Interogare nouă, în care se alege Vizualizare proiect;- din caseta AfişareTabel am selectat tabelele şi/sau cererile din care am extras

date.Fereastra Interogare de selectare are două zone: cea superioară, în care vedem tabelele şi/sau cererile selectate, împreună cu legăturile dintre ele şi cea inferioară, numită grila de proiectare, în care s-a proiectat efectiv cererea.

Dintre interogările construite, vom prezenta modul de realizare pentru q_fact_client_prod, care afişează produsele facturate clienţilor şi valorile TVA aferente acestora. În caseta Afişare Tabel se aleg cele două tabele care vor participa la interogare: t_fact_client_prod şi t_fact_client. În grilă se completează, pe coloane, câmpurile pe care le dorim afişate, mai întâi cele preluate din tabele, iar ultimele două sunt câmpuri calculate cu formulele: val_fara_tva = [pret_fara_tva] * [cant] şi val_tva = [cant] * [pret_fara_tva] * [cota_tva] / 100.

La execuţia cererii, se obţin următoarele date:

Ce-a de a doua interogare pe care o vom prezenta foloseşte date din 2 tabele şi două interogări anterioare, pentru a răspunde la întrebarea: Care este valoarea fără TVA şi valoarea TVA pe fiecare factură? Interogarea q_jv_19 calculează, pentru fiecare factură, valoarea fără TVA şi valoarea TVA, dacă valoarea din câmpul cota_tva este 19, iar interogarea q_jv_9 calculează pentru fiecare factură valoarea fără TVA şi valoarea TVA, dacă valoarea din câmpul cota_tva este 9. După includerea în fereastră a celor patru obiecte care vor participa la interogare, se trece la completarea grilei. Câmpurile preluate se aleg din tabele sau din interogări, iar singurul câmp calculat se obţine prin adunarea bazei de impozitare cu valoarea TVA.

Rapoarte

Rapoartele sau situaţiile finale permit extragerea datelor din tabele, constituind prezentări ale datelor pe suport de hârtie.

Raportul este un obiect al bazei de date asemănător cu interogarea - din punct de vedere al structurii. Diferenţa faţă de interogări constă în aceea că raportul nu este destinat afişării pe ecran, ci tipăririi la o imprimantă. Din acest motiv, raportul nu poate fi deschis şi afişat pe ecran (precum tabelele, formularele şi interogările). Este posibilă numai o previzualizate a modului cum va arata raportul tipărit.

Rapoartele acestei aplicaţii sunt următoarele: 1. Decontul privind taxa pe valoarea adăugată, este un document contabil, o

declaraţie financiară, ce se întocmeşte de societate în cadrul compartimentului financiar-contabil pentru fiecare lună. Documentul prezentat reflectă activitatea de vânzare-cumpărare a societăţii pentru luna decembrie 2004, valoarea facturilor emise de furnizori către SC ADES SA, precum şi valoarea facturilor emise de SC ADES SA către clienţi, cu procentul taxei pe valoare adăugată.

Cotele de impozitare prevăzute de lege se aplică la baza de impozitare şi astfel se determină T.V.A. Aceste cote de impozitare se regăsesc în această aplicaţie şi sunt:

- 19% pentru operaţiunile referitoare la vânzarea-cumpărarea de bunuri şi prestări de servicii;

- 9% pentru o serie de produse de strictă necesitate cum sunt: carnea de animale şi păsări, vândute în stare proaspătă, preparate şi conserve, peşte şi produse din peşte, etc. sau diverse formulare tipizate.

Exemplu de calcul a T.V.A. :În data de 08.12.2004 SC Ades SA vinde către SC Bio Sim SRL 100 de kg.

grâu Dobrogea la preţul unitar de 7000 lei, conform facturii nr. 2584151.100 kg. x 7000 lei / kg = 700000 lei, care este valoarea facturii fără T.V.A700000 x 19% = 133000 lei, care este valoarea T.V.A700000 + 133000 = 833000 lei, care este valoarea totală a facturii (inclusiv T.V.A).Cu ocazia vânzării produselor, întreprinderea furnizoare percepe (facturează şi

încasează) şi TVA de 19% sau 9% asupra livrărilor. Aceasta suma reprezintă ceea ce numim TVA colectată. Cum fiecare întreprindere în calitatea ei de client, în momentul aprovizionării a plătit la rându-i furnizorului său TVA, această TVA deductibilă se va scădea din TVA colectată, rezultând TVA de plată la buget. Daca TVA colectată este mai mică decât TVA deductibilă, diferenţa reprezintă TVA de recuperat. Raportul Decont vizualizat în modul proiect are următoarea imagine.

În partea de antet se observă valori preluate, dar în partea de detaliere se apelează funcţia complexă DLookUp, care afişează valoarea câmpului care este primul său argument din tabela al cărei nume este al doilea său argument. Raportul aşa cum ar apărea la imprimată este prezentat în imaginea care urmează.

Din decontul SC ADES SA aferent lunii decembrie 2004 rezultă următoarele:Valoarea totală a facturilor recepţionate de la furnizori cu cota de 19% este de 74.256.000 lei din care:

- 62.400.000 lei este valoarea fără TVA ,- 11.856.000 fiind valoarea TVA de 19%.

Valoarea totală a facturilor emise clienţilor cu cota de 19% şi 9% este de 89.301.120 lei din care:

Vânzări de produse cu cota de 19% :- 71.500.000 lei este valoarea fără TVA, - 13.585.000 fiind valoarea TVA de 19%.

Vânzări de produse cu cota de 9% :- 3.868.000 lei este valoarea fără TVA,- 348.120 lei fiind valoarea TVA de 9%.

Din valoarea totală a TVA aferentă vânzărilor de 13.933.12 lei minus valoarea totală a TVA aferentă cumpărărilor de 11.856.000 lei obţinem TVA-ul de plată către bugetul de stat de 2.077.120 lei datorită faptului că societatea a înregistrat venituri din vânzarea mărfurilor.

2. Jurnalul pentru cumpărări este un document contabil în care sunt reflectate achiziţiile de produse, cumpărările efectuate de SC Ades SA. Jurnalul de cumpărări al societăţii este:

Acest raport este obţinut prin execuţia raportului rpt_jc:

3. Jurnalul pentru vânzări este un document contabil care reflectă vânzările de bunuri către clienţi. Jurnalul de vânzări al SC Ades SA se prezintă astfel:

11. Teste

Testele prezentate în acest capitol oferă posibilitatea autoevaluării, conţinând subiecte similare celor propuse la examenele de baze de date sau de licenţă (pentru specializările profilului Economic). Fiecare din testele 11.1 – 11.5 conţine câte 9 itemi, pentru fiecare acordându-se câte 1 punct (1 punct se acordă din oficiu). Între cele 5 variante de răspuns, una singură este corectă. Testele 11.6 şi 11.7 sunt mai complexe şi conţin câte 8 itemi pentru care răspunsul trebuie dezvoltat, precum şi o aplicaţie care necesită parcurgerea tuturor etapelor de realizare a unei baze de date, fiind potrivite abordării în colectiv.

11.1 Testul 1

1. Indicele de calitate a informaţiei ce exprimă „necesitatea de a se dispune de cât mai multe informaţii (dacă este posibil, de toate informaţiile) referitoare la un sistem economic analizat” se numeşte:

a. Precizieb. Oportunitatec. Completitudined. Conciziee. Actualitate

2. Precizaţi care dintre variante indică alegerea corectă a cheilor candidate şi cea mai bună alegere a cheii primare, pentru relaţia

Curs (Cod-curs, Denumire-curs, Sala, Ora, Profesor)Cheia primară este cea subliniată.

a. Cod-curs , Salab. Cod-curs , Orac. Cod-curs, Profesord. Cod-curs , Denumire-curse. Cod-curs, Denumire-curs

3. Fie relaţia Personal, ce conţine informaţii despre angajaţii unei fabrici de confecţii:

Marca Nume Prenume

Sectia Profesie Salariu23 Barbu Andreea 1 Inginer confecţii 700000067 Barbu Codrin Mihai 2 Economist 700000055 Constantinescu Adela 1 Designer 600000031 Manoliu Cristian 2 Economist 600000020 Parincea Maria Monica 3 Matematician 600000011 Semenov Alexandru 1 Inginer maşini 5000000

şi următoarea frază SELECT:SELECT Nume, Prenume, Salariu

FROM PersonalWHERE Sectia=1;

Această interogare returnează:

a. Lista conţinând numele, prenumele şi salariul tuturor angajaţilorb. Lista conţinând marca şi profesia angajaţilor secţiei 1c. Lista conţinând numele, prenumele şi salariul angajaţilor secţiei 1d. Totalul salariilor angajaţilore. Toate informaţiile conţinute în tabela de date

4. Obiectele Microsoft ACCESS care permit accesul la date prin intermediul browserelor Internet sunt:

a. Tabelele

b. Formularelec. Cererile de interogared. Paginile Web e. Modulele

5. Formatul corespunzător datei numerice $4,107.85 este:a. General Numberb. Currencyc. Fixedd. Standarde. Percent

6. Operaţia care s-a realizat în cadrul schemei de mai jos este:

Sursă Destinaţie CostIaşi Bacău 100000

Sursă Destinaţie CostIaşi Bacău 100000Iaşi Bucureşti 300000Iaşi Paşcani 40000Iaşi Vaslui 120000Iaşi Cluj-Napoca 400000

a. Proiecţiab. Intersecţiac. Joncţiunead. Diviziuneae. Selecţia

7. Indicaţi tipul relaţiei reprezentate conceptual prin diagrama de mai jos:

a. 1 - 1b. 1 - nc. n - 1d. m - ne. 1 – 3

8. Redundanţa datelor este nulă dacă:a. Datele apar o singură dată în sistemb. Nu se realizează validări ale datelorc. Ansamblul datelor reflectă fidel realitatea pe care o modeleazăd. Nu se admit date de intrare în format electronice. Datele nu se arhivează

9. Conceptul de partajare a datelor într-o bază de date se referă la:a. Salvarea din timp în timp a unor copii coerente ale bazei de dateb. Identificarea utilizatorilor bazei de date prin nume sau codc. Autentificarea utilizatorilor prin paroled. Înlănţuirea tranzacţiilor solicitate simultan pe aceeaşi bază de date şi deservirea

ulterioară a acestora

Sursă Destinaţie CostBucureşti Bacău 250000Galaţi Bacău 200000Constanţa Bacău 300000Iaşi Bacău 100000

CURSURI GRUPE

e. Gestiunea unui jurnal de tranzacţii.

11.2 Testul 2

1. Atributul se defineşte ca fiind:a. O proprietate a unei entităţi sau a unei asocierib. Corespondentul unui obiect din lumea realăc. O instanţiere a unei entităţid. O legătură logică între două realizări de entitatee. O colecţie de instanţe de entitate de acelaşi tip

2. Formularul de analiză (utilizat în faza de analiză a sistemului informaţional existent) care conţine: volumul şi periodicitatea documentelor, timpul estimat pentru completarea acestora, tipul lor (de intrare sau de ieşire), forma documentelor (tipizate sau nu) precum şi necesitatea documentelor se numeşte:

a. Grilă informaţionalăb. Lista purtătorilor de informaţiec. Flux informaţionald. Lista procedurilor existentee. Chestionar de opinie

3. Categoria de personal care se ocupă cu asigurarea securităţii datelor şi a cererilor de informaţie precum şi refacerea bazei de date în cazuri de incoerenţă sau deteriorări accidentale se referă la:

a. Analişti de sistemb. Programatoric. Ingineri de sistemd. Administratore. Operatori

4. Fie relaţia

Contracte (Cod-contract, Tip, Client, Data)care stochează date despre contractele încheiate de firma de leasing „X” cu clienţii săi şi interogarea:

SELECT COUNT(*) AS var_1FROM ContracteWHERE Data BETWEEN #01/01/03# AND #06/30/03#;

Această interogare are ca rezultat:

a. Lista clienţilor firmei Xb. Lista contractelor cu cea mai mare valoarec. Lista contractelor încheiate între 1 ianuarie 2003 şi 30 iunie 2003d. Numărul clienţilor care au încheiat contracte cu firma X între 1 ianuarie 2003 şi 30

iunie 2003e. Valoarea totală a contractelor încheiate între 1 ianuarie 2003 şi 30 iunie 2003

5. Care din următoarele afirmaţii este falsă?a. Datorită utilizării pe scară largă a calculatoarelor şi a echipamentelor electronice

cuplate la acestea, majoritatea sistemelor informaţionale au o componentă informatică.

b. Sistemul informaţional asigură legătura între sistemul de conducere şi sistemul de execuţie.

c. Sistemul informaţional are un rol de interfaţă între unitatea economică şi mediul exterior.

d. Un sistem informaţional se creează şi se dezvoltă odată cu activitatea pe care o reflectă, iar delimitarea lui se realizează prin acte normative.

e. Sistemul informaţional este un subsistem al celui informatic

6. O regulă de validare are următorul rol:a. Realizează iniţializarea câmpurilor unei tabeleb. Testează, conform unui criteriu furnizat, valorile introduse într-un câmpc. Stabileşte obligativitatea introducerii unei valori într-un câmpd. Realizează eliminarea unui indexe. Stabileşte tipul unui câmp

7. Să se precizeze prin ce operaţie a algebrei relaţionale se poate obţine lista cu localităţile de domiciliu ale studenţilor:

LocalitateIaşiBacăuConstanţa

pornind de la următoarea relaţie STUDENT:

Nume_student Secţie LocalitateTraian Marius CIG IaşiIonescu Maria Biologie BacăuDobre Raluca CIG IaşiPopovici Ioana Matematică ConstanţaFilipescu Alexandru Biologie ConstanţaIordan Mihai CIG Bacău

a. Reuniune.b. Proiecţie.c. Selecţie.d. Diviziune.e. Intersecţie.

8. Dacă un câmp are definiţia NOT NULL, atunci:a. Poate rămâne necompletatb. Poate primi numai valori numerice, nenulec. Este obligatorie introducerea unei valori pentru acestad. Poate primi numai valoarea 0e. Nu poate fi modificat

9. Relaţia CORESPONDENŢI, cu structura şi conţinutul:

Ţara JurnaliştiFranţa Marin Gabriel, Iurea VictorItalia Pricop Adrian, Dan IrinaSpania Manoliu Alexandru

se află în forma normală:

a. FN1b. FN2c. FN3d. FN4e. Nici una dintre acestea.

11.3 Testul 3

1. Operaţiile de: selectare, codificare, conversie de suport, validare sunt specifice, într-un sistem informatic, fazei de:

a. Culegere şi pregătire a datelorb. Pelucrare a datelorc. Memorare a datelord. Ahivare a datelore. Comunicare / raportare

2. SGBD Micrososft ACCESS este de tip:a. Ierarhicb. Reţeac. Relaţionald. Funcţionale. Soft pentru gestiunea unui depozit de date

3. Fie relaţiaCATALOG(nr_matricol, nume, an, nota)

care conţine date despre studenţii secţiei Informatică (numărul matricol, numele, anul de studiu şi nota la un concurs de baze de date) şi următoarea frază SQL ACCESS:

SELECT nume, notaFROM CatalogWHERE an in (2,3) AND nota BETWEEN 8 AND 10ORDER BY 2;

Această interogare realizează:a. Lista studenţilor cu note mai mari decât 8, din anii 2 şi 3.b. Lista studenţilor din anii 2 şi 3 şi nota lor la concurs, ordonată descrescător după

notă.c. Lista numelor şi notelor studenţilor din anii 2 şi 3, cu note între 8 şi 10, sortată

alfabetic (crescător) după nume.d. Lista numelor şi notelor studenţilor cu note între 8 şi 10.e. Afişarea mediei notelor obţinute la concurs de studenţii din anii 2 şi 3

4. Funcţia totalizatoare COUNT, folosită într-o interogare de selecţie SQL ACCESS, returnează:

a. Numărul de înregistrări care respectă condiţiile stabilite prin clauza WHEREb. Suma tuturor valorilor dintr-un câmp precizatc. Valoarea medie a unui câmp numeric precizatd. Valoarea cea mai mică dintr-un câmp precizate. Valoarea cea mai mare dintr-un câmp precizat

5. Care dintre următoarele elemente nu reprezintă obiecte ale unei baze de date ACCESS:

a. Tabeleb. Fişiere de parametric. Formulared. Rapoartee. Cereri de interogare

6. Având în vedere că un furnizor poate avea mai mulţi clienţi şi un client se poate aproviziona de la mai mulţi furnizori, relaţia între entităţile FURNIZORI şi CLIENŢI este de tip:

a. 1-1b. 1-nc. n-1d. m-ne. nici unul din tipurile a,b,c,d

7. Una sau mai multe colecţii de date aflate în interdependenţă, împreună cu descrierea datelor şi a relaţiilor dintre acestea reprezintă:

a. un fişierb. un serverc. o structură arborescentăd. o bază de datee. o arhivă electronică

8. Pentru o bază de date, care dintre următoarele afirmaţii este falsă?a. Datele sunt independente de prelucrărib. Totdeauna, redundanţa datelor este nulăc. Redundanţa datelor este controlatăd. Este asigurată confidenţialitatea datelore. Pot fi utilizate tehnici de prelucrare pentru îmbunătăţirea timpului de optimizare.

9. O comandă Macro reprezintă:a. Un obiect care conţine proceduri definite de utilizator, scrise în Visual Basicb. Un obiect care conţine o definiţie structurată a uneia sau mai multor acţiuni pe

care ACCESS le realizează ca răspuns la un anumit evenimentc. Un obiect care permite vizualizarea informaţiilor obţinute prin prelucrarea datelor

din una sau mai multe tabele şi/sau cereri de interogare.d. Un obiect care include un fişier HTML şi alte fişiere suport, în vederea furnizării

accesului la date prin intermediul browser-elor Internete. Un obiect în care sunt stocate date primare.

11.4 Testul 4

1. Fie asocierea

de tip 1-n, unde relaţiile au intensia:CLIENT(CodClient, Nume, Localitate) şi FACTURA(NrFactura, Data, ValoareFacturata, CodClient)

iar extensia relaţiei CLIENT este:

10 Microsistem Bacău20 InfoData Bacău30 Flamingo Computers Iaşi

Precizaţi care dintre următoarele tupluri poate fi adăugat în tabela FACTURA, astfel încât pentru atributul CodClient să fie satisfăcută proprietatea de integritate referenţială:

a. 100 12/07/04 3000 40b. 200 08/08/04 500 80c. 500 03/23/05 1000 50d. 101 06/25/04 1000 10e. 400 01/10/05 700 40

2. Să se precizeze care dintre următoarele colecţii de date se prezintă în a treia formă normală.

a. PRODUSE1CodProducător Ţara CaracteristiciGr11 Grecia Varietatea1; Recolta2Sp20 Spania Varietatea1; Recolta2Ro30 România Varietatea2; Recolta1

b. PRODUSE2CodProducător Ţara ConţinutZahăr ProducătorGr11 Grecia z1000 AlexisSp20 Spania z0800 JoseRo30 România z0450 TudorGr12 Grecia z1000 AlexisSp22 Spania z0800 Jose

c. PRODUSE3CodProducător Ţara ConţinutZahăr ProducătorGr11 Grecia z1000 AlexisSp20 Spania z0800 JoseRo30 România z0450 TudorGr12 Grecia z1000 AlexisSp22 Spania z0800 Jose

TIPConţinutZahăr Producătorz1000 Alexisz0800 Josez0450 Tudor

CLIENT FACTURA

d. PRODUSE4Ţara CantitateaImportatăGrecia 1000000; 95000Spania 50000; 70000; 20000

e. PRODUSE5CodProducător NrLot Data CantitateGr11 N0001 09-04 10000Gr11 N0001 12-04 10000Gr11 N0001 01-05 10000Gr11 N0002 11-04 20000Sp20 N0005 02-05 25000

3. Precizaţi care dintre următoarele funcţii (ce pot fi incluse în clauza Group By, pentru gruparea tuplurilor) furnizează valoarea medie pentru atributul specificat?

a. Countb. StDevc. Maxd. Mine. Avg

4. Care următoarele linii ale grilei Query Design permite inhibarea afişării realizărilor unui câmp?

a. Tableb. Sortc. Criteriad. Showe. Or

5. Proiectarea logică a unui sistem informatic trebuie să se realizeze avându-se în vedere:

a. O soluţie hardware viitoareb. O tehnologie existentăc. Funcţie de cunoştinţele actuale ale programatorilord. Independent de echipamente şi softwaree. În conformitate cu un sistem deja existent

6. Care dintre următoarele aspecte este esenţial pentru elegerea unui atribut drept cheie primară a unei tabele?

a. Valorile atributului să fie de tip numericb. Valorile atributului să fie de tip caracterc. Valorile atributului să fie uniced. Tabela să conţină cel puţin două înregistrărie. Tabela să fie deja indexată după atributul respectiv

7. Care dintre atributele de mai jos este adecvat pentru a deveni cheia primară a entităţii CLIENŢI?

a. Numeb. Cod fiscalc. Telefond. Adresae. Banca

8. Câte niveluri de imbricare a formularelor sunt admise în Access?a. Cel mult douăb. Maximum treic. Maximum şapte

d. Nu sunt admise imbricări ale formularelore. Oricâte se doreşte.

9. Dată tabela

PRODUSECodProdus DenumireProdus Gestiune

A201 Carton Canson 1A205 Vopsea acrilică 1A700 Creion B3 2X309 Pânză pictură 3B285 Cărbune desen 2

alegeţi varianta care conduce la obţinerea relaţiei

MAGAZIIGestiune

123

a. SELECTION (PRODUSE; Gestiune<=3)b. PROJECT (PRODUSE; Gestiune)c. PROJECT (PRODUSE; Cod Produs, Gestiune)d. SELECTION (PRODUSE, DenumireProdus=”Creion B3”)e. Nici una dintre variantele de mai sus.

11.5 Testul 5

1. Fie relaţiile

STUDENŢINumeStudent NumărMatricolIonescu Mihai 101Popa Angela 103Zaharia Florin 107

şi

NOTE1NumărMatricol NotaProgramare

101 9103 8107 10

Relaţia

LISTANumeStudent NumărMatricol NotaProgramareIonescu Mihai 101 9Popa Angela 103 8Zaharia Florin 107 10

este rezultatul unei operaţii:a. UNION (STUDENŢI, NOTE1)b. MINUS (STUDENŢI, NOTE1)c. SELECTION (STUDENŢI, NotaProgramare>=7)d. PROJECT (STUDENŢI, NotaProgramare)e. JOIN (STUDENŢI, NOTE1; STUDENŢÎ.NumărMatricol=NOTE1. NumărMatricol)

2. Dată relaţia CARTE(Autor, Titlu, ISBN, Preţ), precizaţi care dintre următoarele fraze SELECT va furniza titlurile cărţilor cu preţul între 50000 şi 200000:

a. SELECT DISTINCTROW [Titlu], Preţ FROM CARTEWHERE Preţ<=200000;

b. SELECT Titlu FROM CARTEWHERE Preţ>=50000;

c. SELECT DISTINCT Autor FROM CARTE;d. SELECT Titlu FROM CARTE

WHERE Preţ IN (50000, 100000, 200000);e. SELECT Titlu FROM CARTE

WHERE Preţ BETWEEN 50000 AND 200000;

3. Pentru tabela PRODUSE creată cu comandaCREATE TABLE PRODUSE (CodProdus TEXT(4), DenProdus TEXT(15), Um TEXT(4), Preţ NUMBER, Calitatea NUMBER CONSTRAINT CodProdus PRIMARY KEY(CodProdus));precizaţi care dintre următoarele comenzi de inserare este corectă:

a. INSERT INTO PRODUSE VALUES ("129”, "AGENDA”, "BUC”, 50000, 1);b. INSERT INTO PRODUSE VALUES (129, AGENDA, "BUC”, 50000, 1);c. INSERT INTO PRODUSE VALUES ("129”, "AGENDA”, 50000, "BUC”, 1);d. INSERT INTO PRODUSE VALUES ("129”, "AGENDA”, "BUC”, "50000", "1");e. INSERT INTO PRODUSE VALUES (129, "AGENDA”, BUC, 50000, 1);

4. Într-o bază de date, alegerea arhitecturii de stocare a datelor nu trebuie să fie influenţată de:

a. Cantitatea de date ce urmează a fi memoratăb. Numărul de utilizatori ce vor accesa datelec. Numărul de tranzacţii pe unitate de timpd. Limbajul de programare cunoscut de către managerul unităţii beneficiaree. Resursele financiare disponibile

5. Dacă într-o bază de date s-ar proceda la ştergerea unor date care fac parte din tupluri în care se găsesc şi alte date care mai sunt încă necesare, această manevră ar reprezenta:

a. O anomalie de modificareb. O anomalie de adăugarec. O anomalie de ştergered. O violare a integrităţii entităţiie. O violare a integrităţii referirii

6. Un obiect Access care conţine o definiţie structurată a uneia sau mai multor acţiuni pe care Access le realizează ca răspuns la un anumit eveniment este:

a. O cerere de interogareb. Un raportc. Un formulard. O comandă macroe. Un modul

7. O valoare care este atribuită automat unui câmp, atunci când utilizatorul nu introduce nici o valoare în câmp, se numeşte:

a. Etichetă (Caption)b. Regulă de validare (Validation Rule)c. Text de validare (Validation Text)d. Valoare iniţială (Default Value)e. Câmp memo

8. Dacă U este o mulţime de atribute şi se manifestă dependenţa X→Y, atunci regula de inferenţă:

{X→Y, ZU}╞ XZ→YZse numeşte:

a. Reflexivitatea dependenţelor funcţionaleb. Amplificarea dependenţelor funcţionalec. Tranzitivitatea dependenţelor funcţionaled. Complementarea dependenţelor multivaloaree. Tranzitivitatea dependenţelor multivaloare

9. Structura care conţine informaţii şi metode de prelucrare a acestora se numeşte:a. Dicţionarb. Obiectc. Clasăd. Ierarhiee. Mesaj.

11.6 Testul 6

1. Precizaţi ordinea corectă a etapelor ce trebuie urmate în proiectarea unei baze de date:

a. alegerea SGBD-uluib. încărcarea datelorc. proiectarea schemei interned. proiectarea schemei externee. proiectarea schemei conceptualef. analiza structuralăg. analiza cerinţelor informaţionaleh. analiza temporalăi. integrarea modelelorj. exploatarea şi întreţinerea

2. Restricţiile de integritate de comportament:a. se definesc prin egalitatea sau inegalitatea unor valori din cadrul relaţiilorb. sunt proprii unei anumite baze de date relaţionalec. sunt obligatoriu de definit.

Precizaţi o restricţie de comportament pentru o bază de date în care figurează relaţia:

PENSIONAR(Nume, Prenume, Vârsta, Adresa)

3. Fie relaţia OLIMPIADA, ce conţine informaţii despre elevii participanţi la un concurs de informatică organizat la Bacău:

Legiti-maţie

Numele Prenumele

Clasa Liceul Punctajul23 Barbu Andreea 9 „Ferdinand I” Bacău 6867 Barbu Codrin Mihai 9 „Gh.Vrânceanu” Bacău 7055 Constantinescu Adela 10 „N. Comăneci” Oneşti 6131 Manoliu Cristian 9 „H. Coandă” Bacău 8420 Parincea Maria Monica 10 „Letea” Bacău 5011 Semenov Alexandru 9 „G. Apostu” Bacău 37

Să se scrie o frază SELECT ce permite afişarea numelor şi punctajului elevilor din clasa a 9-a, care au obţinut cel puţin 50 de puncte, în ordinea descrescătoare a punctajului. Câte tupluri conţine rezultatul? Să se scrie numerele de legitimaţie corespunzătoare acestor tupluri.

4. Transformaţi relaţia de mai jos (de tip ) în două relaţii de tip 1-n:

5. Care sunt caracteristicile SGBD Access? Ce instrumente de ajutor oferă? Ce tipuri de obiecte pot fi incluse într-o bază de date Access?

CITITORIREVISTE

Maria

Ştefan

Ionuţ

CD Forum

AI Journal

PC Magazine

6. Ce este un depozit de date? Indicaţi câteva elemente specifice unui depozit de date.

7. Cum se realizează protecţia unei baze dae date la nivel utilizator?

8. Cum pot fi accesate bazele de date Access pe Internet?

9. Aplicaţie. Catedra de Informatică organizează un simpozion cu participare internaţională. Pentru aceasta, responsabilul cu activitatea ştiinţifică decide implementarea unei baze de date relaţionale. Se doreşte ca, utilizând datele incluse în baza de date, să se obţină următoarele informaţii:

- Lista secţiunilor simpozionului (codul şi denumirea)- Lista lucrărilor şţiinţifice prezentate pe secţiuni- Lista lucrărilor ştiinţifice pe Institute de Învăţământ Superior, în numele cărora s-au

înscris lucrările la simpozion- Lista autorilor (nume, prenume, adresa profesională şi adresa personală) care vor

susţine lucrări pe secţiuni.Se cere să se elaboreze modelul relaţional al bazei de date.

11.7 Testul 7

1. Ce înseamnă modelarea datelor şi de ce este necesară?

2. În ce constă optimizarea unei baze de date?

3. Ce înseamnă replicarea unei baze de date?

4. Ce înseamnă normalizarea datelor şi care este scopul normalizării?

5. Care sunt implicaţiile accesului concurent la o bază de date?

6. Care sunt caracteristicile bazelor de date distribuite?

7. Ce este o bază de cunoştinţe?

8. Care sunt problemele actuale ale dezvoltării de aplicaţii cu baze de date?

9. Aplicaţie. Se propune realizarea informatizării bibliotecii unei Instituţii de Învăţământ Superior, folosind o bază de date relatională. Se fac următoarele precizări:

- În bibliotecă se află exemplare ale unor lucrări de mare interes; fiecare exemplar are un cod de identificare unică;

- Fiecare lucrare are un titlu, un număr ISBN, o editură în care apare şi unul sau mai mulţi autori;

- Exemplarele pot fi imprumutate de catre cadrele didactice, doctoranzi sau studenţi;- Exemplarele se împrumută în baza unui bon de împrumut, în care se pot trece mai

multe cărţi imprumutate;- În momentul împrumutului se precizează data de împrumut şi data returnării cărţilor.

Cititorilor le sunt utile următoarele informaţii:- Lista lucrărilor existente în bibliotecă;- Lista exemplarelor existente în bibliotecă pentru fiecare lucrare;- Lista cititorilor care nu au returnat la termen exemplarele împrumutate;- Lista lucrărilor existente în bibliotecă pe o anumită temă.

Se cere să se elaboreze modelul relaţional al bazei de date.

BIBLIOGRAFIE

1. [Bas97] Bâscă O. – Baze de date, Editura All, Bucureşti, 1997

2. [Bro98] Browne A., Balter A. – Bazele Access 95, Editura Teora, 1998

3. [Dim99] Dima G., Dima M. – FoxPro 2.5, 2.6 sub DOS, Editura Teora, 1999

4. [Ede02] Edelhauer, E. Ionică, A. – Sistemele de Gestiune a Bazelor de date Access, FoxPro. Manual de utilizare, Editura Universitas, Petroşani, 2002

5. [Fel96] Felea, V. – Baze de date relaţionale. Dependenţe, Editura Universităţii Al. I. Cuza, Iaşi, 1996

6. [Flo99] Florescu V., Stanciu V., Cozgarea G., Cozgarea A. – Baze de date, Editura Economică, Bucureşti, 1999

7. [Gro96] Grommes, B., Hampe K. – Secretele sistemului FoxPro 2.5 pentru DOS, Editura Teora, 1996

8. [Lue99] Luers, T. – Bazele Oracle 7, Editura Teora, 1999

9. [Lun95] Lungu I., Bodea C., Bădesc G., Ioniţă C. – Baze de date. Organizare, proiectare şi implementare, Editura All, Bucureşti, 1995

10. [Lun96] Lungu I., Muşat N., Velicaru M. – Sistemul FoxPro 2.6. Prezentare şi aplicaţii, Editura All, 1996

11. [Nas00] Năstase P., Mihai F., Cosăcescu L., Bărbulescu B., Stanciu A., Şova R.A., Covrig L. – Baze de date. Microsoft Access 2000, Editura Teora, Bucureşti, 2000

12. [Opr02] Oprea D., Airinei D., Fotache M. – Sisteme informaţionale pentru afaceri, Editura Polirom, 2002

13. [Tod02] Todoroi D., Micuşa D., Clocotici V., Linga I., Ţapcov V., Drucioc N., Calcatin A., Morari M. – Data Bases and Communication Tools. MS Access 2000, Editura ASEM, Chişinău, 2002

14. [Tod04] Todoroi D., Micuşa D., Spătaru S., Andronatiev V., Todoroi Z., Donici S. – Databases and Multimedia Communications (Teaching Aids), Series IEEE-2000, Chişinău, 2004