Capitolul 1Capitolul 1

Chestiuni introductive privind crearea de aplicaţii cu baze de dateChestiuni introductive privind crearea de aplicaţii cu baze de date

Este un fapt evident acela că majoritatea aplicaţiilor în domeniul economic utilizează date într-o formă sau alta. Aceste date sunt memorate adesea în una sau mai multe baze de date. Mediul Visual Basic poate crea, cu un efort de planificare şi proiectare nu prea mare, programe puternice de gestionare a datelor. Unul din factorii cei mai importanţi ai acestei planificări se referă la modul de organizare a datelor. O baza de date prost structurată poate să conducă la eşec chiar având cel mai bine gândit program, în schimb o bază de date bine proiectată poate uşura mult munca programatorului.

Pentru a crea o structură de date bine organizată, va trebui să ne familiarizăm cu două probleme:

1) Va trebui să învăţăm cum să proiectăm o bază de date. În această etapă va trebui să decidem care date vor trebui incluse în baza de date şi cum vor fi ele organizate;

2) Va trebui să învăţăm modul de implementare a bazei de date proiectate în baza de date efectivă, propriu-zisă.

În acest capitol voi lua ca exemplu proiectarea şi crearea unei baze de date care conţine informaţii cu privire la situaţia la învăţătură a unor studenţi dintr-o anumită serie şi an de studiu (note la diferitele discipline, absenţe, total credite obţinute, calculul mediei etc.). Pe baza ei vor fi exemplificate şi alte noţiuni din această carte.

1.1. Elemente de proiectare a unei baze de date1.1. Elemente de proiectare a unei baze de date

Pentru a proiecta o aplicaţie cu baze de date trebuie stabilite nu doar rutinele-program, pentru o performanţă cât mai bună, ci trebuie acordată de asemenea o foarte mare atenţie organizării fizice şi logice a modului de stocare a datelor. O bună proiectare a bazelor de date asigură următoarele:

timp minim de căutare la localizarea unor înregistrări specifice; memorarea datelor în modul cel mai eficient posibil pentru a împiedica baza de date

să crească exagerat de mult; actualizarea datelor într-un mod cât mai uşor cu putinţă; o suficientă flexibilitate pentru a permite includerea unor noi funcţii cerute de

program.

La proiectarea unei baze de date trebuie avute în vedere mai multe obiective, care vor fi enumerate mai jos. Deşi ar fi ideal să poată fi împlinite toate aceste obiective de proiectare, în unele cazuri ele se exclud reciproc şi ca trebui căutată o soluţie optimă. Cele mai importante obiective în proiectarea unei baze de date sunt:

eliminarea datelor redundante; capacitatea de a localiza foarte rapid anumite înregistrări individuale; posibilitatea de a face îmbunătăţiri uşor de implementat pentru baza de date; păstrarea unei uşoare întreţineri a bazei de date.

Crearea unui proiect bun de baze de date implică următoarele şase etape:

1°. Modelarea aplicaţiei2°. Determinarea datelor necesare pentru aplicaţie;3°. Organizarea datelor în tabele şi stabilirea relaţiilor între acestea;4°. Stabilirea cerinţelor de indexare şi de validare pentru datele respective;5°. Crearea şi memorarea interogărilor necesare pentru aplicaţie;6°. Revederea proiectării.

1

1

În cele ce urmează vom lua în discuţie etapele de mai sus.

1.1.1. Modelarea aplicaţiei1.1.1. Modelarea aplicaţiei

Atunci când modelăm o aplicaţie, primul lucru pe care trebuie să-l facem este să determinăm sarcinile pe care aplicaţia trebuie să le rezolve. De exemplu atunci când ţinem evidenţa studenţilor şi a rezultatelor acestora la învăţătură, se ştie că se doreşte posibilitatea calculului mediei fiecăruia dintre aceştia, a numărului total de credite cumulat de fiecare în parte şi eventual anumite statistici pe ani, grupe, sex sau alte criterii. Determinând sarcinile ce trebuiesc rezolvate de către aplicaţie se creează aşa-numita specificaţie funcţională. Atunci când aplicaţia pe care o creaţi este chiar pentru dumneavoastră, probabil că vă sunt clare toate sarcinile pe care doriţi ca aplicaţia să le efectueze. Totuşi a scrie aceste sarcini într-un document de specificaţii este o idee bună. Acest document vă poate ajuta să nu pierdeţi din vedere nimic din ceea ce doriţi ca programul să rezolve. Dacă însă aplicaţia pe care o creaţi este pentru altcineva, o specificaţie funcţională poate deveni un acord, o înţelegere cu utilizatorul, asupra a ceea ce aplicaţia va trebui să rezolve. Aceste specificări pot constitui jaloane de atins pe parcursul proiectării aplicaţiei.

Atunci când creaţi programul pentru altcineva, cea mai bună cale de a învăţa ce operaţii trebuiesc efectuate este de a vorbi cu persoana (beneficiarul) în cauză şi a pune întrebări. Ca un prim pas ar trebui aflat dacă ei nu au deja un sistem pe care doresc să-l înlocuiască cu altul mai bun, sau dacă au anumite rapoarte pe care doresc să le obţină. Puneţi apoi o sumedenie de întrebări, până când aţi înţeles scopurile utilizatorului pentru programul pe care vi-l solicită.

1.1.2. Determinarea datelor necesare pentru aplicaţie1.1.2. Determinarea datelor necesare pentru aplicaţie

După determinarea specificaţiilor funcţionale pentru program se poate trece la determinarea datelor de care are nevoie aplicaţia. În cazul aplicaţiei propuse, cu privire la situaţia la învăţătură a unor studenţi, va trebui să cunoaştem datele personale a fiecărui student, dacă acesta este sau nu în regim cu taxă şi dacă şi-a achitat sau nu taxele pentru anul în curs, inclusiv adresa sau telefonul la care acesta poate fi contactat în caz de neplată la timp a taxelor de şcolarizare. Apoi trebuiesc cunoscute disciplinele şi creditele aferente fiecărei discipline, respectiv notele obţinute la aceste discipline, datele examenelor şi numele profesorilor care au dat notele. De asemenea, în cazul cerinţei unor situaţii pe grupe de studiu este necesar un index sau o interogare care să afişeze studenţii pe grupe, şi în cadrul grupelor alfabetic. Se poate astfel observa că modelul aplicaţiei nu dă doar indicii cu privire la datele necesare, ci defineşte de asemenea alte componente ale bazei de date.

1.1.3. Organizarea datelor în tabele şi stabilirea relaţiilor între acestea1.1.3. Organizarea datelor în tabele şi stabilirea relaţiilor între acestea

Unul din aspectele cheie a unei proiectări eficiente a bazelor de date este determinarea modului în care datele vor fi organizate în baza de date. Pentru o bună proiectare, datele trebuiesc organizate într-un mod care să permită o uşoară extragere a informaţiilor şi care să facă baza de date uşor de întreţinut. În cadrul unei baze de date, datele sunt memorate în una sau mai multe tabele. Pentru cele mai multe aplicaţii cu baze de date se poate obţine o organizare eficientă a datelor prin memorarea datelor în mai multe tabele şi prin stabilirea unor relaţii între aceste tabele.

Tabele. Un tabel este o colecţie de informaţii cu privire la un anumit subiect. Stabilind un subiect-cheie pentru fiecare tabelă se poate stabili dacă o anumită dată îşi are locul sau nu în respectivul tabel. De exemplu, dacă instituţia de învăţământ doreşte să ţină o evidenţă atât a studenţilor cât şi a profesorilor, proiectantul bazei de date ar putea fi tentat să introducă datele ambelor categorii de persoane în aceeaşi tabelă – ambele necesitând nume, prenume, adresa, telefon. Totuşi, uitându-ne la datele necesare studenţilor, observăm că pentru aceştia ar fi necesare şi informaţii cu privire la grupa de care aparţin, la forma de învăţământ (cu sau fără

2

taxă) şi la achitarea sau nu a taxei pentru cei în regim cu taxă. Dacă s-ar crea o singură tabelă pentru studenţi şi profesori, multe câmpuri ar rămânea astfel necompletate în dreptul profesorilor. De asemenea ar fi necesar atunci să se adauge un câmp care să facă distincţia între un student şi un profesor. În mod clar această metodă ar conduce la mult spaţiu de memorare ocupat fără nici un rost. De asemenea ar rezulta o procesare mai lentă a tranzacţiilor care vizează numai studenţii sau numai profesorii, deoarece programul va trebui să sară tot timpul peste anumite înregistrări din tabel care nu interesează. Figura 1.1. arată o tabelă de bază de date cu cele două categorii (studenţi şi profesori) combinate. Figura 1.2. arată reducerea numărului de câmpuri într-un tabel doar cu profesorii.

Figura 1.1. Combinarea într-o singură tabelă a studenţilor şi profesorilor duce la risipă mare de spaţiu

1.1.3.1. Normalizarea datelor1.1.3.1. Normalizarea datelor

A normaliza datele înseamnă a elimina datele redundante dintr-o bază de date. Închipuindu-ne normalizarea dusă la extrem, acest lucru ar însemna ca fiecare informaţie să nu apară decât o singură dată într-o baza de date. Practic însă acest lucru nu este întotdeauna posibil şi nici de dorit.

Figura 1.2. O tabelă separată pentru profesori conţine doar câmpurile care interesează şi este mai eficientă

Observaţi, privind la figura 1.2, că nu am introdus în tabela Studenti nici o informaţie cu privire la vreun anumit examen, data acestuia, disciplina şi profesorul, respectiv nota primită cu acea ocazie. Aceasta deoarece este de preferat ca informaţiile cu privire la examene şi note să fie separate de tabela studenţilor pentru ca diferitele informaţii suplimentare cu privire la adresă, telefon sex, grupă, achitarea taxelor etc. să nu se repete şi aici, ci referirea la un anumit student să se facă prin numărul acestuia de identificare, deci printr-un câmp numit de noi StudId. Similar în tabela cu înregistrările notelor obţinute la diferitele examene se va face referirea la profesorul cu care s-a dat examenul prin numărul de identificare al acestuia,

3

numit în acest exemplu ProfId – aceasta de asemenea pentru a nu încărca tabela notelor cu toate informaţiile suplimentare care există în tabelul Profesori cu privire la un anumit profesor.

Observaţie. Aceste câmpuri de identificare, StudId din tabelul Studenti şi ProfId din tabelul Profesori conţin întotdeauna valori unice, distincte. Ele vor constitui şi chei primare în respectivele tabele. Aceasta înseamnă, spre exemplu, că o anumită valoare a lui StudId poate exista doar pentru o singură înregistrare din tabelul Studenti şi nu poate fi duplicată. Astfel va putea fi distins un anumit student de altul, chiar dacă cei doi ar avea nume identice, şi poate – prin absurd – şi adrese sau orice alte câmpuri identice.

Prin urmare, dacă se plasează toate aceste date cu privire la notele studenţilor într-o singură tabelă, rezultatul ar arăta asemănător ce ceea se poate vedea în figura 1.3. Deja aici citirea tabelei se complică la o simplă privire fugară, deoarece în locul numelor studentului şi al profesorului avem numerele de identificare a acestora, care trebuie să ne facă legătura cu tabelele Studenti şi Profesori pentru a putea afla cine sunt aceştia.

Figura 1.3. Datele nenormalizate conduc la tabele de date mari, ineficiente

Din figura de mai sus rezultă clar faptul că în tabela Note foarte multe date se repetă. Această repetare a unor informaţii are două urmări nedorite:

În primul rând se risipeşte spaţiu, deoarece multe informaţii se repetă de nenumărate ori;

În al doilea rând ar putea fi un factor de pierdere a corectitudinii unor date. Dacă de exemplu se hotărăşte ca unei anumite discipline să i se acorde un număr mai mare sau mai mic de credite decât s-a ştiut iniţial, această modificare va trebui făcută asupra tuturor înregistrărilor care se referă la respectiva disciplină, cu posibilitatea de a greşi şi a lăsa vreuna din înregistrările mai vechi nemodificată.

O metodă mai bună de a organiza datele va fi de a separa disciplinele de note, şi chiar şi datele cu privire la un anumit examen de note. Astfel în tabela Discipline vor apărea doar denumirea disciplinei cu numărul de credite aferent şi un identificator de disciplină (DId), în tabela Examene doar data, identificatorul de disciplină (DId), profesorul cu care s-a dat examenul – cunoscut prin identificatorul de profesor (ProfId) şi un identificator de examen (ExId), iar în tabela Note doar identificatorul de student (StudId), nota şi identificatorul de examen (ExId). Pentru identificatorul DId din tabela Discipline şi pentru identificatorul ExId din tabela Examene rămâne valabilă observaţia enunţată în nota anterioară: Aceste câmpuri vor conţine valori distincte şi unice în tabelele respective şi vor constitui chei primare în acele tabele. Astfel rezultă în locul tabelului din figura 1.3, trei tabele distincte de genul celor din figura 1.4.

Desigur, citirea datelor din aceste trei tabele este acum mult mai abstractă decât înainte, şi pentru ochiul nostru ar putea părea mult prea complicat. Totuşi , bazele de date aşa-numit relaţionale se descurcă foarte bine cu tabele de acest fel. Pentru aceasta ele utilizează chei de date. De exemplu tabela Note din figura 1.4 are un câmp numit ExId, care, după cum o sugerează şi denumirea, va fi un identificator de examen. Acelaşi câmp ExId este conţinut şi în tabela Examene, unde însă ExId este cheie primară. Aceasta înseamnă, după cum am enunţat deja în nota scrisă cu caractere italice mai sus, că o anumită valoare a lui ExId poate exista doar pentru o singură înregistrare din tabela Examene.

4

Fig. 1.4. Normalizarea completă a tabelelor asigură eficienţă maximă.

Practic, fiecare înregistrare a tabelei Examene va conţine un examen distinct, caracterizat printr-o anumită dată, un anumit profesor (referit prin ProfId) şi o anumită disciplină (referită prin identificatorul de disciplină DId).

Spunem că cele două tabele Note şi Examene sunt în relaţie prin intermediul câmpului ExId. Observaţi însă că în tabelul Note câmpul ExId nu va fi cheie primară, ci aici se va numi cheie străină, deoarece este în legătură cu câmpul ExId din tabela Examene şi acel câmp este un câmp cheie. Totuşi, în tabela Note, acelaşi identificator de examen ExId se poate repeta de câte ori este necesar.

De asemenea în tabela Examene mai apar câmpurile DId şi ProfId, care se regăsesc şi în tabelele Discipline şi respectiv Profesori, tabele în care sunt în mod evident chei primare. Ele vor fi însă chei străine pentru tabelul Examene, în care pot apărea de câte ori este nevoie. Astfel nu vor fi restricţii în ce priveşte posibilitatea ca un anumit profesor să predea mai multe discipline sau o anumită disciplină să fie predată de mai mulţi profesori – desigur la diverşi elevi.

În concluzie: Într-o bază de date relaţională, fiecare tabelă are o cheie primară ce reprezintă un câmp (sau o combinaţie de câmpuri) prin ale cărui (cărei) valori se identifică fără ambiguitate fiecare linie a tabelei. Unele tabele au şi o cheie străină, ce reprezintă un câmp, care este cheie primară într-o altă tabelă. Valorile cheii străine dintr-o tabelă nu pot fi decât valori ale cheii primare din tabela corespondentă. Această regulă se numeşte restricţie referenţială.

Microsoft Access oferă o reprezentare vizuală foarte sugestivă a relaţiilor dintre tabelele unei baze de date. Modul de obţinere a acestei reprezentări este arătat la finalul unui paragraf viitor, şi anume 1.2.1. În cazul exemplului discutat mai sus relaţiile sunt reprezentate în Microsoft Access ca în figura 1.5.

5

Figura 1.5. Reprezentarea relaţiilor între tabelele unei baze de date în Microsoft Access

Câmpurile îngroşate reprezintă chei primare în tabelele respective, iar simbolurile legăturilor (cifra 1 şi simbolul ) indică faptul că, spre exemplu, unei singure înregistrări din tabelul Studenti, îi pot corespunde mai multe înregistrări din tabelul Note.

Să încercăm acum să „citim” prima înregistrare din tabela Note în varianta ultimă din figura 1.4. Studentul cu numărul de identificare 15 – deci POPA LAURENTIU (vezi figura 1.2.) a obţinut nota 7 la examenul cu numărul de identificare 3 – adică cel din data de 29.06.2003 (vezi tabela Examene din figura 1.4.) la disciplina cu numărul de identificare 4 (adică Limba straina 1 dacă se urmăreşte tabelul Discipline) cu profesorul având numărul de identificare 14 – deci NEGRU RADU, rezultat din tabela Profesori. Comparaţi acum ceea ce aţi citit cu informaţiile extrase din tabela Note din figura 1.3. Desigur ele sunt identice şi la fel vor fi şi următoarele înregistrări.

1.1.3.2. Reguli pentru organizarea tabelelor1.1.3.2. Reguli pentru organizarea tabelelor

Practic nu există reguli absolute care să delimiteze care date în care tabele trebuiesc introduse, dar, cu toate acestea am putea enumera câteva reguli generale care ar trebui urmărite pentru a proiecta o bază de date bine structurată. Acestea ar fi:

Orice tabel trebuie să aibă o temă, de exemplu „Informaţii despre abonaţi” sau „Tranzacţii ale clienţilor”. Încercaţi să vă limitaţi la o singură temă pe tabel.

Spargeţi tabela în două tabele similare în cazul în care un număr de înregistrări au câmpuri lăsate necompletate în mod intenţionat (ca şi despărţirea tabelei Profesori de tabela Studenti).

Mutaţi într-o altă tabelă a informaţiilor care se repetă într-un număr de înregistrări şi stabiliţi o relaţie între acele tabele.

Dacă există o listă cu informaţii de referinţă, pe care vreţi să o păstraţi (cum ar fi disciplinele şi numărul de credite aferente fiecăreia), puneţi-le în propriul tabel.

Unde este posibil, folosiţi numere de identificare, ele ajutându-vă să legaţi tabele între ele şi să evitaţi greşelile de dactilografie datorate introducerii unor şiruri lungi de date (cum sunt numele).

Nu stocaţi informaţii într-un tabel dacă acestea pot fi calculate din datele altor tabele.

Adeseori, din motive de performanţă, se ocolesc unele din aceste reguli. De exemplu, dacă pentru a obţine vânzările totale pentru un anumit vânzător este necesară însumarea mai

6

multor mii de înregistrări, poate se merită a include un câmp de Vanzari totale în tabela Vanzatori, câmp care să fie actualizat de câte ori se face o vânzare. În acest fel, atunci când sunt generate rapoarte, aplicaţia nu va trebui să efectueze un număr mare de calcule şi procesul de raportare va fi mult mai rapid.

Un alt motiv pentru a devia de la aceste reguli este evitarea deschiderii unui număr prea mare de tabele în acelaşi timp. Aceasta deoarece fiecare tabelă deschisă utilizează resurse preţioase şi de asemenea spaţiu de memorare, încât aplicaţia ar putea pierde considerabil din viteză.

Pe de altă parte, devierea de la aceste reguli de structurare a tabelelor conduce la două probleme majore:

– creşterea mărimii bazei de date din cauza datelor redundante;– posibilitatea de a avea la un moment dat date incorecte din cauză că s-a modificat

conţinutul anumitor câmpuri şi, dintr-un motiv sau altul, nu toate înregistrările afectate au fost actualizate.

În concluzie va trebui căutat un optim între performanţa aplicaţiei şi eficienţa stocării datelor în tabele.

1.1.4. Utilizarea indecşilor1.1.4. Utilizarea indecşilor

Atunci când se introduc date într-un tabel, înregistrările sunt stocate în general în ordinea în care ele sunt introduse. Aceasta este ordinea fizică a datelor. De obicei însă utilizatorii doresc să proceseze datele într-o ordine diferită de cea în care au fost introduse înregistrările în tabele. Aceasta presupune definirea unei aşa-numite ordini logice. Această ordine logică va fi de asemenea utilă atunci când se va dori căutarea într-un tabel a unei anumite înregistrări.

Indexarea este metoda cel mai des utilizată de a ordona tabelele de date. Un index este de asemenea o tabelă, care conţine o valoare cheie (derivată de obicei din valorile a unul sau mai multe câmpuri) pentru fiecare înregistrare din tabela de date; indexul însuşi este memorat într-o ordine logică specifică şi conţine pointeri (indicatori de adrese) care spun motorului de baze de date unde este localizată înregistrarea curentă.

Indecşii sunt setaţi la proiectarea tabelei cu scopul de a mări viteza şi de a garanta unicitatea unei înregistrări. Cartea de telefoane de exemplu este o listă indexată după nume. Atunci când căutaţi numărul de telefon al unei persoane îl puteţi găsi rapid uitându-vă doar la câteva pagini, dacă ştiţi care este numele persoanei. Dacă numerele de telefon ar fi date în cartea de telefon în ordinea în care au fost ele atribuite abonaţilor, o astfel de carte nu ar folosi nimănui, fiind aproape imposibil de a găsi numărul unei anumite persoane.

O tabelă poate avea mai mulţi indecşi diferiţi asociaţi, pentru a asigura pentru anumite situaţii ordonarea datelor într-un fel sau în altul. De exemplu tabela studenţilor ar putea fi utilă în ordine alfabetică a acestora sau poate în ordinea grupelor şi eventual alfabetic în cadrul fiecărei grupe sau, poate, descrescător după media rezultată în urma introducerii notelor de examen. Fiecare index arată aceleaşi date într-o ordine diferită, pentru un scop diferit.

Observaţii. 1. Chiar dacă este de dorit să putem avea vederi diferite asupra datelor în toate

ordonările posibile, trebuie avut în vedere că pentru baze de date mari a menţine o varietate foarte mare de indecşi poate prejudicia performanţa aplicaţiei, deoarece toţi indicii trebuie actualizaţi ori de câte ori datele se modifică. Şi în această problemă programatorul aplicaţiei va trebui să aleagă o variantă optimă de compromis.

2. Se pot însă crea diferite vederi a informaţiilor dintr-un tabel şi prin sortarea înregistrărilor sau prin specificarea unei ordini dorite utilizând clauza ORDER BY a unei comenzi SQL (Structured Query Language). Chiar dacă indecşii nu sunt utilizaţi direct de un motor SQL, prezenţa lor măresc viteze procesului de sortare atunci când există o clauză ORDER BY.

7

Indexul poate fi un câmp sau o combinaţie de câmpuri, iar câmpurile ar putea necesita valori unice sau nu. Dacă un index necesită o valoare unică, el este denumit index unic.

Cele mai obişnuite tipuri de indecşi sunt cei cu expresii cheie singulare, adică cei bazaţi pe valoarea unui singur câmp din tabel. Exemple de astfel de indecşi sunt identificatorul de student (StudId) sau numele studentului (Nume) sau grupa (Grupa) etc. pentru tabela Studenti. Atunci când există mai multe înregistrări cu aceeaşi valoare a cheii de indexare, aşa cum ar putea fi cazul cu numele studentului sau cum este sigur cazul cu indexarea după grupă, înregistrările multiple sunt prezentate în ordinea fizică în cadrul ordinii impuse de indexul cheie singular. Figura 1.6 arată cum va arăta tabela Studenti (cu ordinea fizică dată în figura 1.2) în urma indexării după câmpul Grupa.

Figura 1.6. Tabela Studenti indexată după câmpul Grupa

Totuşi, nu de puţine ori ar putea fi necesară o ordine mai exactă. Acest lucru se poate face utilizând expresii cu chei de indexare multiple. După cum şi numele o spune, indexul cheie multiplă se bazează pe valorile din două sau mai multe câmpuri ale unui tabel. Un exemplu ar fi să indexăm tabelul Studenti după grupă şi în cadrul grupei alfabetic după nume (şi poate chiar la nume identice alfabetic după prenume). Dacă totuşi există înregistrări care să aibă aceiaşi valoare cheie pentru două sau mai multe înregistrări, acestea vor apărea ca şi în cazul indecşilor cu chei singulare în ordinea fizică a înregistrărilor. În figura 1.7 se poate vedea tabela Studenti indexată cu o cheie multiplă după Grupa, Nume şi Prenume.

Figura 1.7. Tabela Studenti cu index cheie multiplă după câmpul Grupa, Nume şi Prenume

1.1.5. Utilizarea interogărilor1.1.5. Utilizarea interogărilor

Atunci când normalizaţi datele, de obicei plasaţi informaţiile înrudite în mai multe tabele relaţionale. La accesarea datelor însă, veţi dori să vedeţi informaţiile din toate tabelele într-un singur loc, denumit tabelă virtuală (view). Această tabelă practic nu există ca atare, dar în baza de date este memorată descrierea ei. Această descriere precizează că datele view-ului provin dintr-o porţiune a unei tabele, din mai multe tabele ori din mai multe porţiuni ale mai multor tabele. Pentru a reuşi acest lucru este necesară crearea de seturi de înregistrări, care să consolideze informaţiile legate prin relaţii şi aflate în două sau mai multe tabele.

Un set de înregistrări se creează din mai multe tabele utilizând o comandă SQL care specifică numele câmpurilor dorite, locaţia câmpurilor şi relaţia dintre tabele. Comanda SQL

8

se poate însă memora ca o interogare (Query) în baza de date. (A se vedea capitolul cu privire la comenzile SQL).

1.2. 1.2. Crearea unei baze de date Crearea unei baze de date utilizând Microsoft Accessutilizând Microsoft Access

Microsoft Access are o interfaţă vizuală de proiectare foarte facilă, pentru a defini tabele, indecşi, interogări şi relaţii între tabele. Este evident instrumentul cel mai performant de lucru cu bazele de date, mult superior lui Visual Data Manager, care are încă unele lipsuri mari (de exemplu pentru operaţia simplă de modificare a tipului unui câmp dintr-o structură existentă a unui tabel trebuie recurs la artificii destul de complicate).

Foarte pe scurt va fi prezentată în continuare crearea bazei de date Catalog.mdb şi a uneia din tabelele acesteia, de exemplu tabela Studenti.

Crearea unui fişier nou de tip bază de date se face selectând File | New | Blank Database şi alegând apoi folderul şi tastând numele (Catalog) pentru noul fişier .mdb care va fi creat. La clic pe butonul Create va apare fereastra, în cazul de faţă Catalog : Database, fereastră ce va conţine toate obiectele bazei de date care – după dorinţă – se vor adăuga pe parcurs, ca: tabele (Tables), interogări (Queries), formulare (Forms), rapoarte (Reports) etc. (vezi figura 1.8).

Figura 1.8. Fereastra Database a bazei de date Catalog.mdb

Acum utilizatorul are posibilitatea să creeze noile tabele ale bazei de date alegând una din cele trei variante afişate în fereastra din figura 1.8:

Create table in Design view – varianta pe care o vom utiliza efectiv mai jos; Create table by using the wizard – varianta care ne conduce la alegerea unei

structuri de tabel cu ajutorul unui vrăjitor, utilizând modele de structuri tabelare pentru cele mai diverse aplicaţii economice, de afaceri, etc.;

Create table by entering data – o variantă simplistă şi cu facilităţi reduse de a defini un tabel prin introducerea liniilor de date în acesta şi denumirea coloanelor cap de tabel, care vor deveni numele câmpurilor respective.

Se recomandă în general prima din variantele de mai sus ca fiind cea mai flexibilă şi performantă modalitate de a defini o tabelă.

Alegând cu un dublu clic de mouse prima din cele trei variante, va apare o fereastră Table pentru definirea structurii noii tabele, ca cea din figura 1.9, în care se introduc pe rând numele câmpurilor, se alege din lista derulantă (Data Type) tipul dorit (Text, Memo, Number, Date/Time etc.) şi se dă o eventuală descriere a câmpului (un comentariu) în rubrica Description. În partea de jos a ferestrei Table, pagina General vor putea fi setate proprietăţi suplimentare cu privire la câmpul respectiv, proprietăţi care depind de tipul câmpului ales.

9

Figura 1.9. Fereastra Table pentru definirea structurii unei tabele

Observaţii.1. Pentru datele de tip Text proprietatea FieldSize indică lungimea în număr de

caractere a câmpului.2. Pentru datele numerice Number, proprietatea FieldSize oferă o listă de subtipuri

numerice, ca Long Integer (valoarea implicită), Byte, Integer, Single, Double etc. din care se poate alege cea care corespunde cel mai bine tipului de date care va fi stocat în respectivul câmp.

3. Valoarea implicită cu care se iniţializează un câmp la adăugarea unei noi înregistrări este specificată de proprietatea DefaultValue.

4. Dacă proprietatea Required are valoarea Yes, atunci trebuie să se dea o valoare pentru câmpul respectiv. Câmpul nu poate rămâne necompletat în varianta că mai târziu o valoare va fi oricum precizată.

5. Câmpurile de tip Text şi Memo pot avea ca valoare şiruri de lungime 0 (vid) dacă proprietatea AllowZeroLength are valoarea Yes.

6. Proprietatea ValidationRule permite precizarea unei condiţii de validare a câmpului respectiv, (de exemplu: >0 în dreptul unui câmp numeric).

7. Dacă eventuala regulă precizată de proprietatea ValidationRule nu este îndeplinită, atunci se poate afişa un mesaj de eroare precizat prin proprietatea ValidationText.

8. Cu proprietatea Format se poate specifica un format de afişare a valorii câmpului, format care poate fi în general ales dintr-o listă derulantă care este diferită de la un tip de date la altul.

9. Pentru tipurile de date Text sau Date/Time proprietatea InputMask oferă posibilitatea de a preciza un şablon de introducere a datelor, ca de exemplu un anumit şablon pentru introducerea numerelor de telefon (care, având de multe ori zerouri în faţă, trebuiesc declarate de tip Text şi nu Number!) sau pentru introducerea datelor calendaristice.

10. Proprietatea Caption precizează un şir de caractere care se ataşează câmpului şi care va apărea ca şi cap de coloană în locul numelui acestuia, atunci când se va deschide tabela (cu meniul Open din fereastra Database).

11. Proprietatea Indexed se referă la crearea unui index sau nu pe baza valorilor câmpului respectiv, şi permite alegerea uneia din următoarele trei variante:

- No – nu se indexează după respectivul câmp;- Yes (Duplicates OK) – se indexează după câmpul respectiv, care poate

avea valori identice în două sau mai multe înregistrări;- Yes (No Duplicates) – se indexează după câmpul respectiv, nefiind permise

valori identice în două sau mai multe înregistrări.După definirea structurii tabelei prin completarea câmpurilor în fereastra Table şi a

proprietăţilor acestora, se închide fereastra Table cu butonul de închidere. Va apare o fereastră cu întrebarea: Do you want to save changes to the design of Table1?, la care desigur că se va

10

răspunde cu Yes pentru a salva structura definită anterior, urmând a da apoi numele tabelei, respectiv Studenti. Dacă pentru tabela respectivă nu s-a definit nici o cheie primară, va apare mesajul din figura 1.10:

Figura 1.10. Mesajul cu privire la lipsa definirii unei chei primare

La întrebarea din mesaj se poate alege Yes, caz în care se va crea un câmp nou cu numele ID de tip Autonumber (număr cu autoincrementare de la o înregistrare la alta), care va fi considerat cheie primară, sau No, caz în care se salvează structura tabelei aşa cum era, fără nici o cheie primară. Dacă se alege răspunsul Cancel se revine în fereastra de definire a structurii Table fără a se efectua nici o salvare.

În cazul că s-a ales unul din răspunsurile Yes sau No, structura tabelei a fost creată şi în fereastra Database a apărut tabela Studenti (vezi figura 1.11).

Figura 1.11. Fereastra Database în care s-a creat tabela Studenti

Dacă după ce s-a salvat tabela sub numele Studenti se constată că s-a greşit sau s-a uitat ceva la definirea structurii tabelei, se selectează tabela Studenti din fereastra 1.11 şi se

alege din meniul contextual al acesteia Design View (sau se dă clic pe butonul ).Astfel se deschide din nou fereastra Table, în care se pot insera sau şterge linii (cu

comenzile Insert Rows sau Delete Rows din meniul contextual atunci se selectează o anumită linie), se pot redenumi câmpuri sau modifica proprietăţile acestora, se pot adăuga proprietăţi de indexare, reguli de validare etc. ca şi la crearea structurii unei tabele noi, respectiv se poate alege ca un anumit câmp să devină cheie primară de indexare (selectând linia cu câmpul

respectiv şi dând un clic pe butonul Primary Key din bara de unelte standard Microsoft Access atunci când este deschisă o tabelă în modul Design view). În final, structura tabelei Studenti în fereastra Design view ar arăta ca în figura 1.12.

11

Figura 1.12. Structura tabelei Studenti în modul Design view

Pentru setări suplimentare a indecşilor în ceea ce priveşte ordinea, eventual descrescătoare, de indexare, respectiv setarea unor indecşi după câmpuri multiple, va trebui,

tot din modul Design view, selectat butonul Indexes . Pe ecran va apare fereastra Indexes, în care se specifică numele indexului, unul sau mai multe câmpuri care intră în componenţa respectivului index şi ordinea de sortare crescătoare (este implicită) sau descrescătoare. Figura 1.13 arată fereastra Indexes în cazul tabelei Studenti.

Figura 1.13. Fereastra Indexes pentru tabela Studenti

Observaţi în figura 1.13 că NumPre este numele unui index câmp multiplu, în care indexarea se va face în primul rând crescător după nume, iar la nume identice după prenume.

După efectuarea tuturor modificărilor se închide fereastra Table şi apare o fereastră cu mesajul: Do you want to save changes to the design of table ′Studenti′ ?, la care, pentru a salva toate modificările, se răspunde cu Yes.

Pentru a introduce date în tabelele create se dă dublu clic pe tabela dorită din fereastra Databases (sau se alege opţiunea Open din meniul contextual care apare la un clic dreapta de

mouse pe tabele selectată, sau se alege butonul ) – a se vedea figura 1.11. În fereastra apărută se introduc datele dorite, ca în figura 1.14.

Figura 1.14. Datele introduse în tabela Studenti

12

Observaţie. În general, datele vor fi introduse prin program şi nu în modul prezentat mai sus. S-a dat şi varianta aceasta doar ca exemplu didactic.

În ceea ce priveşte crearea relaţiilor, Microsoft Access oferă o reprezentare vizuală foarte sugestivă a relaţiilor dintre tabelele unei baze de date. Această reprezentare permite utilizatorului să tragă o linie între câmpurile relaţionale din tabele sau interogări. Astfel, din mediul Access dacă alegem opţiunea Relationships... din meniul Tools sau dăm clic pe icon-ul corespunzător din bara de unelte standard, obţinem o fereastră intitulată Relationships. Cu un simplu clic dreapta oriunde în această fereastră putem adăuga, prin intermediul opţiunii Show Tables, câte o tabelă a bazei de date. Apoi, cu metoda drag-and-drop se „trasează” practic relaţiile dintre tabele, unind câmpurile care fac legătura între două tabele. Butonul de mouse se eliberează când indicatorul mouse-ului va deveni un mic dreptunghi fixat pe câmpul destinaţie. În caseta de dialog Relationships care apare se cere definirea legăturii pe care vrem să o realizăm. Tot aici, de obicei, se bifează opţiunea Enforce Referential Integrity, care are rolul de a ne împiedica să facem greşeli la introducerea datelor.

În cazul exemplului discutat mai sus, relaţiile sunt reprezentate în Microsoft Access ca în figura 1.5 de la paragraful 1.1.3.1.

Câmpurile îngroşate reprezintă chei primare în tabelele respective, iar simbolurile legăturilor (cifra 1 şi simbolul ) indică faptul că, spre exemplu, unei singure înregistrări din tabelul Studenti, îi pot corespunde mai multe înregistrări din tabelul Note.

1.3. 1.3. Modificări asupra unei baze de date Modificări asupra unei baze de date

Oricât de bine ar fi proiectată şi implementată o bază de date, nu e exclus ca la un moment dat să fie necesară modificarea structurii bazei de date şi a tabelelor ei componente pentru a gestiona şi alte date. Modificările pot însemna noi tabele sau indecşi în cadrul tabelelor, sau schimbări în proprietăţile tabelelor, câmpurilor sau indecşilor. Câteodată s-ar putea dori ştergerea unei tabele, unor câmpuri sau indecşi.

13