Este un fapt evident acela ca majoritatea aplicatiilor īn domeniul economic utilizeaza date īntr-o forma 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 si proiectare nu prea mare, programe puternice de gestionare a datelor. Unul din factorii cei mai importanti ai acestei planificari se refera la modul de organizare a datelor. O baza de date prost structurata poate sa conduca la esec chiar avānd cel mai bine gāndit program, īn schimb o baza de date bine proiectata poate usura mult munca programatorului.

Pentru a crea o structura de date bine organizata, va trebui sa ne familiarizam cu doua probleme:

Va trebui sa īnvatam cum sa proiectam o baza de date. Īn aceasta etapa va trebui sa decidem care date vor trebui incluse īn baza de date si cum vor fi ele organizate;

Va trebui sa īnvatam modul de implementare a bazei de date proiectate īn baza de date efectiva, propriu-zisa.

Īn acest capitol voi lua ca exemplu proiectarea si crearea unei baze de date care contine informatii cu privire la situatia la īnvatatura a unor studenti dintr-o anumita serie si an de studiu (note la diferitele discipline, absente, total credite obtinute, calculul mediei etc.). Pe baza ei vor fi exemplificate si alte notiuni din aceasta carte.

Pentru a proiecta o aplicatie cu baze de date trebuie stabilite nu doar rutinele-program, pentru o performanta cāt mai buna, ci trebuie acordata de asemenea o foarte mare atentie organizarii fizice si logice a modului de stocare a datelor. O buna proiectare a bazelor de date asigura urmatoarele:

P      timp minim de cautare la localizarea unor īnregistrari specifice;

P      memorarea datelor īn modul cel mai eficient posibil pentru a īmpiedica baza de date sa creasca exagerat de mult;

P      actualizarea datelor īntr-un mod cāt mai usor cu putinta;

P      o suficienta flexibilitate pentru a permite includerea unor noi functii cerute de program.

La proiectarea unei baze de date trebuie avute īn vedere mai multe obiective, care vor fi enumerate mai jos. Desi ar fi ideal sa poata fi īmplinite toate aceste obiective de proiectare, īn unele cazuri ele se exclud reciproc si ca trebui cautata o solutie optima. Cele mai importante obiective īn proiectarea unei baze de date sunt:

P      eliminarea datelor redundante;

P      capacitatea de a localiza foarte rapid anumite īnregistrari individuale;

P      posibilitatea de a face īmbunatatiri usor de implementat pentru baza de date;

P      pastrarea unei usoare īntretineri a bazei de date.

Crearea unui proiect bun de baze de date implica urmatoarele sase etape

1°. Modelarea aplicatiei

2°. Determinarea datelor necesare pentru aplicatie;

3°. Organizarea datelor īn tabele si stabilirea relatiilor īntre acestea;

4°. Stabilirea cerintelor de indexare si de validare pentru datele respective;

5°. Crearea si memorarea interogarilor necesare pentru aplicatie;

6°. Revederea proiectarii.

Īn cele ce urmeaza vom lua īn discutie etapele de mai sus.

Atunci cānd modelam o aplicatie, primul lucru pe care trebuie sa-l facem este sa determinam sarcinile pe care aplicatia trebuie sa le rezolve. De exemplu atunci cānd tinem evidenta studentilor si a rezultatelor acestora la īnvatatura, se stie ca se doreste posibilitatea calculului mediei fiecaruia dintre acestia, a numarului total de credite cumulat de fiecare īn parte si eventual anumite statistici pe ani, grupe, sex sau alte criterii. Determinānd sarcinile ce trebuiesc rezolvate de catre aplicatie se creeaza asa-numita specificatie functionala. Atunci cānd aplicatia pe care o creati este chiar pentru dumneavoastra, probabil ca va sunt clare toate sarcinile pe care doriti ca aplicatia sa le efectueze. Totusi a scrie aceste sarcini īntr-un document de specificatii este o idee buna. Acest document va poate ajuta sa nu pierdeti din vedere nimic din ceea ce doriti ca programul sa rezolve. Daca īnsa aplicatia pe care o creati este pentru altcineva, o specificatie functionala poate deveni un acord, o īntelegere cu utilizatorul, asupra a ceea ce aplicatia va trebui sa rezolve. Aceste specificari pot constitui jaloane de atins pe parcursul proiectarii aplicatiei.

Atunci cānd creati programul pentru altcineva, cea mai buna cale de a īnvata ce operatii trebuiesc efectuate este de a vorbi cu persoana (beneficiarul) īn cauza si a pune īntrebari. Ca un prim pas ar trebui aflat daca ei nu au deja un sistem pe care doresc sa-l īnlocuiasca cu altul mai bun, sau daca au anumite rapoarte pe care doresc sa le obtina. Puneti apoi o sumedenie de īntrebari, pāna cānd ati īnteles scopurile utilizatorului pentru programul pe care vi-l solicita.

Dupa determinarea specificatiilor functionale pentru program se poate trece la determinarea datelor de care are nevoie aplicatia. Īn cazul aplicatiei propuse, cu privire la situatia la īnvatatura a unor studenti, va trebui sa cunoastem datele personale a fiecarui student, daca acesta este sau nu īn regim cu taxa si daca si-a achitat sau nu taxele pentru anul īn curs, inclusiv adresa sau telefonul la care acesta poate fi contactat īn caz de neplata la timp a taxelor de scolarizare. Apoi trebuiesc cunoscute disciplinele si creditele aferente fiecarei discipline, respectiv notele obtinute la aceste discipline, datele examenelor si numele profesorilor care au dat notele. De asemenea, īn cazul cerintei unor situatii pe grupe de studiu este necesar un index sau o interogare care sa afiseze studentii pe grupe, si īn cadrul grupelor alfabetic. Se poate astfel observa ca modelul aplicatiei nu da doar indicii cu privire la datele necesare, ci defineste de asemenea alte componente ale bazei de date.

Unul din aspectele cheie a unei proiectari eficiente a bazelor de date este determinarea modului īn care datele vor fi organizate īn baza de date. Pentru o buna proiectare, datele trebuiesc organizate īntr-un mod care sa permita o usoara extragere a informatiilor si care sa faca baza de date usor de īntretinut. Īn cadrul unei baze de date, datele sunt memorate īn una sau mai multe tabele. Pentru cele mai multe aplicatii cu baze de date se poate obtine o organizare eficienta a datelor prin memorarea datelor īn mai multe tabele si prin stabilirea unor relatii īntre aceste tabele.

Tabele. Un tabel este o colectie de informatii cu privire la un anumit subiect. Stabilind un subiect-cheie pentru fiecare tabela se poate stabili daca o anumita data īsi are locul sau nu īn respectivul tabel. De exemplu, daca institutia de īnvatamānt doreste sa tina o evidenta atāt a studentilor cāt si a profesorilor, proiectantul bazei de date ar putea fi tentat sa introduca datele ambelor categorii de persoane īn aceeasi tabela - ambele necesitānd nume, prenume, adresa, telefon. Totusi, uitāndu-ne la datele necesare studentilor, observam ca pentru acestia ar fi necesare si informatii cu privire la grupa de care apartin, la forma de īnvatamānt (cu sau fara taxa) si la achitarea sau nu a taxei pentru cei īn regim cu taxa. Daca s-ar crea o singura tabela pentru studenti si profesori, multe cāmpuri ar ramānea astfel necompletate īn dreptul profesorilor. De asemenea ar fi necesar atunci sa se adauge un cāmp care sa faca distinctia īntre un student si un profesor. Īn mod clar aceasta metoda ar conduce la mult spatiu de memorare ocupat fara nici un rost. De asemenea ar rezulta o procesare mai lenta a tranzactiilor care vizeaza numai studentii sau numai profesorii, deoarece programul va trebui sa sara tot timpul peste anumite īnregistrari din tabel care nu intereseaza. Figura 1.1. arata o tabela de baza de date cu cele doua categorii (studenti si profesori) combinate. Figura 1.2. arata reducerea numarului de cāmpuri īntr-un tabel doar cu profesorii.

Figura 1.1. Combinarea īntr-o singura tabela a studentilor si profesorilor duce la risipa mare de spatiu

A normaliza datele īnseamna a elimina datele redundante dintr-o baza de date. Īnchipuindu-ne normalizarea dusa la extrem, acest lucru ar īnsemna ca fiecare informatie sa nu apara decāt o singura data īntr-o baza de date. Practic īnsa acest lucru nu este īntotdeauna posibil si nici de dorit.

Figura 1.2. O tabela separata pentru profesori contine doar cāmpurile care intereseaza si este mai eficienta

Observati, privind la figura 1.2, ca nu am introdus īn tabela Studenti nici o informatie cu privire la vreun anumit examen, data acestuia, disciplina si profesorul, respectiv nota primita cu acea ocazie. Aceasta deoarece este de preferat ca informatiile cu privire la examene si note sa fie separate de tabela studentilor pentru ca diferitele informatii suplimentare cu privire la adresa, telefon sex, grupa, achitarea taxelor etc. sa nu se repete si aici, ci referirea la un anumit student sa se faca prin numarul acestuia de identificare, deci printr-un cāmp numit de noi StudId. Similar īn tabela cu īnregistrarile notelor obtinute la diferitele examene se va face referirea la profesorul cu care s-a dat examenul prin numarul de identificare al acestuia, numit īn acest exemplu ProfId - aceasta de asemenea pentru a nu īncarca tabela notelor cu toate informatiile suplimentare care exista īn tabelul Profesori cu privire la un anumit profesor.

Observatie. Aceste cāmpuri de identificare, StudId din tabelul Studenti si ProfId din tabelul Profesori contin īntotdeauna valori unice, distincte. Ele vor constitui si chei primare īn respectivele tabele. Aceasta īnseamna, spre exemplu, ca o anumita valoare a lui StudId poate exista doar pentru o singura īnregistrare din tabelul Studenti si nu poate fi duplicata. Astfel va putea fi distins un anumit student de altul, chiar daca cei doi ar avea nume identice, si poate - prin absurd - si adrese sau orice alte cāmpuri identice

Prin urmare, daca se plaseaza toate aceste date cu privire la notele studentilor īntr-o singura tabela, rezultatul ar arata asemanator ce ceea se poate vedea īn figura 1.3. Deja aici citirea tabelei se complica la o simpla privire fugara, deoarece īn locul numelor studentului si al profesorului avem numerele de identificare a acestora, care trebuie sa ne faca legatura cu tabelele Studenti si Profesori pentru a putea afla cine sunt acestia.

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

Din figura de mai sus rezulta clar faptul ca īn tabela Note foarte multe date se repeta. Aceasta repetare a unor informatii are doua urmari nedorite:

Īn primul rānd se risipeste spatiu, deoarece multe informatii se repeta de nenumarate ori;

Īn al doilea rānd ar putea fi un factor de pierdere a corectitudinii unor date. Daca de exemplu se hotaraste ca unei anumite discipline sa i se acorde un numar mai mare sau mai mic de credite decāt s-a stiut initial, aceasta modificare va trebui facuta asupra tuturor īnregistrarilor care se refera la respectiva disciplina, cu posibilitatea de a gresi si a lasa vreuna din īnregistrarile mai vechi nemodificata.

O metoda mai buna de a organiza datele va fi de a separa disciplinele de note, si chiar si datele cu privire la un anumit examen de note. Astfel īn tabela Discipline vor aparea doar denumirea disciplinei cu numarul de credite aferent si un identificator de disciplina (DId), īn tabela Examene doar data, identificatorul de disciplina (DId), profesorul cu care s-a dat examenul - cunoscut prin identificatorul de profesor (ProfId) si un identificator de examen (ExId), iar īn tabela Note doar identificatorul de student (StudId), nota si identificatorul de examen (ExId). Pentru identificatorul DId din tabela Discipline si pentru identificatorul ExId din tabela Examene ramāne valabila observatia enuntata īn nota anterioara: Aceste cāmpuri vor contine valori distincte si unice īn tabelele respective si vor constitui chei primare īn acele tabele. Astfel rezulta ī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 abstracta decāt īnainte, si pentru ochiul nostru ar putea parea mult prea complicat. Totusi , bazele de date asa-numit relationale se descurca foarte bine cu tabele de acest fel. Pentru aceasta ele utilizeaza chei de date. De exemplu tabela Note din figura 1.4 are un cāmp numit ExId care, dupa cum o sugereaza si denumirea, va fi un identificator de examen. Acelasi cāmp ExId este continut si īn tabela Examene, unde īnsa ExId este cheie primara. Aceasta īnseamna, dupa cum am enuntat deja īn nota scrisa cu caractere italice mai sus, ca o anumita valoare a lui ExId poate exista doar pentru o singura īnregistrare din tabela Examene

Fig. 1.4. Normalizarea completa a tabelelor asigura eficienta maxima.

Practic, fiecare īnregistrare a tabelei Examene va contine un examen distinct, caracterizat printr-o anumita data, un anumit profesor (referit prin ProfId) si o anumita disciplina (referita prin identificatorul de disciplina DId

Spunem ca cele doua tabele Note si Examene sunt īn relatie prin intermediul cāmpului ExId. Observati īnsa ca īn tabelul Note cāmpul ExId nu va fi cheie primara, ci aici se va numi cheie straina, deoarece este īn legatura cu cāmpul ExId din tabela Examene si acel cāmp este un cāmp cheie. Totusi, īn tabela Note, acelasi identificator de examen ExId se poate repeta de cāte ori este necesar.

De asemenea īn tabela Examene mai apar cāmpurile DId si ProfId, care se regasesc si īn tabelele Discipline si respectiv Profesori, tabele īn care sunt īn mod evident chei primare. Ele vor fi īnsa chei straine pentru tabelul Examene, īn care pot aparea de cāte ori este nevoie. Astfel nu vor fi restrictii īn ce priveste posibilitatea ca un anumit profesor sa predea mai multe discipline sau o anumita disciplina sa fie predata de mai multi profesori - desigur la diversi elevi.

Īn concluzie: Īntr-o baza de date relationala, fiecare tabela are o cheie primara ce reprezinta un cāmp (sau o combinatie de cāmpuri) prin ale carui (carei) valori se identifica fara ambiguitate fiecare linie a tabelei. Unele tabele au si o cheie straina, ce reprezinta un cāmp, care este cheie primara īntr-o alta tabela. Valorile cheii straine dintr-o tabela nu pot fi decāt valori ale cheii primare din tabela corespondenta. Aceasta regula se numeste restrictie referentiala.

Microsoft Access ofera o reprezentare vizuala foarte sugestiva a relatiilor dintre tabelele unei baze de date. Modul de obtinere a acestei reprezentari este aratat la finalul unui paragraf viitor, si anume 1.2.1. Īn cazul exemplului discutat mai sus relatiile sunt reprezentate īn Microsoft Access ca īn figura 1.5.

Figura 1.5. Reprezentarea relatiilor īntre tabelele unei baze de date īn Microsoft Access

Cāmpurile īngrosate reprezinta chei primare īn tabelele respective, iar simbolurile legaturilor (cifra 1 si simbolul ) indica faptul ca, spre exemplu, unei singure īnregistrari din tabelul Studenti, īi pot corespunde mai multe īnregistrari din tabelul Note

Sa īncercam acum sa "citim" prima īnregistrare din tabela Note īn varianta ultima din figura 1.4. Studentul cu numarul de identificare 15 - deci POPA LAURENTIU (vezi figura 1.2.) a obtinut nota 7 la examenul cu numarul de identificare 3 - adica cel din data de 29.06.2003 (vezi tabela Examene din figura 1.4.) la disciplina cu numarul de identificare 4 (adica Limba straina 1 daca se urmareste tabelul Discipline) cu profesorul avānd numarul de identificare 14 - deci NEGRU RADU, rezultat din tabela Profesori. Comparati acum ceea ce ati citit cu informatiile extrase din tabela Note din figura 1.3. Desigur ele sunt identice si la fel vor fi si urmatoarele īnregistrari.

Practic nu exista reguli absolute care sa delimiteze care date īn care tabele trebuiesc introduse, dar, cu toate acestea am putea enumera cāteva reguli generale care ar trebui urmarite pentru a proiecta o baza de date bine structurata. Acestea ar fi:

Orice tabel trebuie sa aiba o tema, de exemplu "Informatii despre abonati" sau "Tranzactii ale clientilor". Īncercati sa va limitati la o singura tema pe tabel.

Spargeti tabela īn doua tabele similare īn cazul īn care un numar de īnregistrari au cāmpuri lasate necompletate īn mod intentionat (ca si despartirea tabelei Profesori de tabela Studenti

Mutati īntr-o alta tabela a informatiilor care se repeta īntr-un numar de īnregistrari si stabiliti o relatie īntre acele tabele.

Daca exista o lista cu informatii de referinta, pe care vreti sa o pastrati (cum ar fi disciplinele si numarul de credite aferente fiecareia), puneti-le īn propriul tabel.

Unde este posibil, folositi numere de identificare, ele ajutāndu-va sa legati tabele īntre ele si sa evitati greselile de dactilografie datorate introducerii unor siruri lungi de date (cum sunt numele).

Nu stocati informatii īntr-un tabel daca acestea pot fi calculate din datele altor tabele.

Adeseori, din motive de performanta, se ocolesc unele din aceste reguli. De exemplu, daca pentru a obtine vānzarile totale pentru un anumit vānzator este necesara īnsumarea mai multor mii de īnregistrari, poate se merita a include un cāmp de Vanzari totale īn tabela Vanzatori, cāmp care sa fie actualizat de cāte ori se face o vānzare. Īn acest fel, atunci cānd sunt generate rapoarte, aplicatia nu va trebui sa efectueze un numar mare de calcule si procesul de raportare va fi mult mai rapid.

Un alt motiv pentru a devia de la aceste reguli este evitarea deschiderii unui numar prea mare de tabele īn acelasi timp. Aceasta deoarece fiecare tabela deschisa utilizeaza resurse pretioase si de asemenea spatiu de memorare, īncāt aplicatia ar putea pierde considerabil din viteza.

Pe de alta parte, devierea de la aceste reguli de structurare a tabelelor conduce la doua probleme majore:

- cresterea marimii bazei de date din cauza datelor redundante;

- posibilitatea de a avea la un moment dat date incorecte din cauza ca s-a modificat continutul anumitor cāmpuri si, dintr-un motiv sau altul, nu toate īnregistrarile afectate au fost actualizate.

Īn concluzie va trebui cautat un optim īntre performanta aplicatiei si eficienta stocarii datelor īn tabele.

Atunci cānd se introduc date īntr-un tabel, īnregistrarile sunt stocate īn general īn ordinea īn care ele sunt introduse. Aceasta este ordinea fizica a datelor. De obicei īnsa utilizatorii doresc sa proceseze datele īntr-o ordine diferita de cea īn care au fost introduse īnregistrarile īn tabele. Aceasta presupune definirea unei asa-numite ordini logice. Aceasta ordine logica va fi de asemenea utila atunci cānd se va dori cautarea īntr-un tabel a unei anumite īnregistrari.

Indexarea este metoda cel mai des utilizata de a ordona tabelele de date. Un index este de asemenea o tabela, care contine o valoare cheie (derivata de obicei din valorile a unul sau mai multe cāmpuri) pentru fiecare īnregistrare din tabela de date; indexul īnsusi este memorat īntr-o ordine logica specifica si contine pointeri (indicatori de adrese) care spun motorului de baze de date unde este localizata īnregistrarea curenta.

Indecsii sunt setati la proiectarea tabelei cu scopul de a mari viteza si de a garanta unicitatea unei īnregistrari. Cartea de telefoane de exemplu este o lista indexata dupa nume. Atunci cānd cautati numarul de telefon al unei persoane īl puteti gasi rapid uitāndu-va doar la cāteva pagini, daca stiti care este numele persoanei. Daca numerele de telefon ar fi date īn cartea de telefon īn ordinea īn care au fost ele atribuite abonatilor, o astfel de carte nu ar folosi nimanui, fiind aproape imposibil de a gasi numarul unei anumite persoane.

O tabela poate avea mai multi indecsi diferiti asociati, pentru a asigura pentru anumite situatii ordonarea datelor īntr-un fel sau īn altul. De exemplu tabela studentilor ar putea fi utila īn ordine alfabetica a acestora sau poate īn ordinea grupelor si eventual alfabetic īn cadrul fiecarei grupe sau, poate, descrescator dupa media rezultata īn urma introducerii notelor de examen. Fiecare index arata aceleasi date īntr-o ordine diferita, pentru un scop diferit.

Observatii.

1. Chiar daca este de dorit sa putem avea vederi diferite asupra datelor īn toate ordonarile posibile, trebuie avut īn vedere ca pentru baze de date mari a mentine o varietate foarte mare de indecsi poate prejudicia performanta aplicatiei, deoarece toti indicii trebuie actualizati ori de cāte ori datele se modifica. si īn aceasta problema programatorul aplicatiei va trebui sa aleaga o varianta optima de compromis.

2. Se pot īnsa crea diferite vederi a informatiilor dintr-un tabel si prin sortarea īnregistrarilor sau prin specificarea unei ordini dorite utilizānd clauza ORDER BY a unei comenzi SQL (Structured Query Language). Chiar daca indecsii nu sunt utilizati direct de un motor SQL, prezenta lor maresc viteze procesului de sortare atunci cānd exista o clauza ORDER BY.

Indexul poate fi un cāmp sau o combinatie de cāmpuri, iar cāmpurile ar putea necesita valori unice sau nu. Daca un index necesita o valoare unica, el este denumit index unic.

Cele mai obisnuite tipuri de indecsi sunt cei cu expresii cheie singulare, adica cei bazati pe valoarea unui singur cāmp din tabel. Exemple de astfel de indecsi sunt identificatorul de student (StudId) sau numele studentului (Nume) sau grupa (Grupa) etc. pentru tabela Studenti. Atunci cānd exista mai multe īnregistrari cu aceeasi valoare a cheii de indexare, asa cum ar putea fi cazul cu numele studentului sau cum este sigur cazul cu indexarea dupa grupa, īnregistrarile multiple sunt prezentate īn ordinea fizica īn cadrul ordinii impuse de indexul cheie singular. Figura 1.6 arata cum va arata tabela Studenti (cu ordinea fizica data īn figura 1.2) īn urma indexarii dupa cāmpul Grupa

Figura 1.6. Tabela Studenti indexata dupa cāmpul Grupa

Totusi, nu de putine ori ar putea fi necesara o ordine mai exacta. Acest lucru se poate face utilizānd expresii cu chei de indexare multiple. Dupa cum si numele o spune, indexul cheie multipla se bazeaza pe valorile din doua sau mai multe cāmpuri ale unui tabel. Un exemplu ar fi sa indexam tabelul Studenti dupa grupa si īn cadrul grupei alfabetic dupa nume (si poate chiar la nume identice alfabetic dupa prenume). Daca totusi exista īnregistrari care sa aiba aceiasi valoare cheie pentru doua sau mai multe īnregistrari, acestea vor aparea ca si īn cazul indecsilor cu chei singulare īn ordinea fizica a īnregistrarilor. Īn figura 1.7 se poate vedea tabela Studenti indexata cu o cheie multipla dupa Grupa, Nume si Prenume

Figura 1.7. Tabela Studenti cu index cheie multipla dupa cāmpul Grupa, Nume si Prenume

Atunci cānd normalizati datele, de obicei plasati informatiile īnrudite īn mai multe tabele relationale. La accesarea datelor īnsa, veti dori sa vedeti informatiile din toate tabelele īntr-un singur loc, denumit tabela virtuala (view). Aceasta tabela practic nu exista ca atare, dar īn baza de date este memorata descrierea ei. Aceasta descriere precizeaza ca datele view-ului provin dintr-o portiune a unei tabele, din mai multe tabele ori din mai multe portiuni ale mai multor tabele. Pentru a reusi acest lucru este necesara crearea de seturi de īnregistrari, care sa consolideze informatiile legate prin relatii si aflate īn doua sau mai multe tabele.

Un set de īnregistrari se creeaza din mai multe tabele utilizānd o comanda SQL care specifica numele cāmpurilor dorite, locatia cāmpurilor si relatia dintre tabele. Comanda SQL se poate īnsa memora ca o interogare (Query) īn baza de date. (A se vedea capitolul cu privire la comenzile SQL).

Microsoft Access are o interfata vizuala de proiectare foarte facila, pentru a defini tabele, indecsi, interogari si relatii īntre tabele. Este evident instrumentul cel mai performant de lucru cu bazele de date, mult superior lui Visual Data Manager, care are īnca unele lipsuri mari (de exemplu pentru operatia simpla de modificare a tipului unui cāmp dintr-o structura existenta a unui tabel trebuie recurs la artificii destul de complicate).

Foarte pe scurt va fi prezentata īn continuare crearea bazei de date Catalog.mdb si a uneia din tabelele acesteia, de exemplu tabela Studenti

Crearea unui fisier nou de tip baza de date se face selectānd File | New | Blank Database si alegānd apoi folderul si tastānd numele (Catalog) pentru noul fisier .mdb care va fi creat. La clic pe butonul Create va apare fereastra, īn cazul de fata Catalog : Database, fereastra ce va contine toate obiectele bazei de date care - dupa dorinta - se vor adauga pe parcurs, ca: tabele (Tables), interogari (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 sa creeze noile tabele ale bazei de date alegānd una din cele trei variante afisate īn fereastra din figura 1.8:

P      Create table in Design view - varianta pe care o vom utiliza efectiv mai jos;

P      Create table by using the wizard - varianta care ne conduce la alegerea unei structuri de tabel cu ajutorul unui vrajitor, utilizānd modele de structuri tabelare pentru cele mai diverse aplicatii economice, de afaceri, etc.;

P      Create table by entering data - o varianta simplista si cu facilitati reduse de a defini un tabel prin introducerea liniilor de date īn acesta si denumirea coloanelor cap de tabel, care vor deveni numele cāmpurilor respective.

Se recomanda īn general prima din variantele de mai sus ca fiind cea mai flexibila si performanta modalitate de a defini o tabela.

Alegānd cu un dublu clic de mouse prima din cele trei variante, va apare o fereastra 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 derulanta (Data Type) tipul dorit (Text, Memo, Number, Date/Time etc.) si se da o eventuala descriere a cāmpului (un comentariu) īn rubrica Description. Īn partea de jos a ferestrei Table, pagina General vor putea fi setate proprietati suplimentare cu privire la cāmpul respectiv, proprietati care depind de tipul cāmpului ales.

Figura 1.9. Fereastra Table pentru definirea structurii unei tabele

Observatii.

Pentru datele de tip Text proprietatea FieldSize indica lungimea īn numar de caractere a cāmpului.

Pentru datele numerice Number, proprietatea FieldSize ofera o lista de subtipuri numerice, ca Long Integer (valoarea implicita), 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.

Valoarea implicita cu care se initializeaza un cāmp la adaugarea unei noi īnregistrari este specificata de proprietatea DefaultValue.

Daca proprietatea Required are valoarea Yes, atunci trebuie sa se dea o valoare pentru cāmpul respectiv. Cāmpul nu poate ramāne necompletat īn varianta ca mai tārziu o valoare va fi oricum precizata.

Cāmpurile de tip Text si Memo pot avea ca valoare siruri de lungime 0 (vid) daca proprietatea AllowZeroLength are valoarea Yes.

Proprietatea ValidationRule permite precizarea unei conditii de validare a cāmpului respectiv, (de exemplu: >0 īn dreptul unui cāmp numeric).

Daca eventuala regula precizata de proprietatea ValidationRule nu este īndeplinita, atunci se poate afisa un mesaj de eroare precizat prin proprietatea ValidationText.

Cu proprietatea Format se poate specifica un format de afisare a valorii cāmpului, format care poate fi īn general ales dintr-o lista derulanta care este diferita de la un tip de date la altul.

Pentru tipurile de date Text sau Date/Time proprietatea InputMask ofera posibilitatea de a preciza un sablon de introducere a datelor, ca de exemplu un anumit sablon pentru introducerea numerelor de telefon (care, avānd de multe ori zerouri īn fata, trebuiesc declarate de tip Text si nu Number!) sau pentru introducerea datelor calendaristice.

Proprietatea Caption precizeaza un sir de caractere care se ataseaza cāmpului si care va aparea ca si cap de coloana īn locul numelui acestuia, atunci cānd se va deschide tabela (cu meniul Open din fereastra Database).

Proprietatea Indexed se refera la crearea unui index sau nu pe baza valorilor cāmpului respectiv, si permite alegerea uneia din urmatoarele trei variante:

No - nu se indexeaza dupa respectivul cāmp;

Yes (Duplicates OK) - se indexeaza dupa cāmpul respectiv, care poate avea valori identice īn doua sau mai multe īnregistrari;

Yes (No Duplicates) - se indexeaza dupa cāmpul respectiv, nefiind permise valori identice īn doua sau mai multe īnregistrari.

Dupa definirea structurii tabelei prin completarea cāmpurilor īn fereastra Table si a proprietatilor acestora, se īnchide fereastra Table cu butonul de īnchidere. Va apare o fereastra cu īntrebarea: Do you want to save changes to the design of Table1?, la care desigur ca se va raspunde cu Yes pentru a salva structura definita anterior, urmānd a da apoi numele tabelei, respectiv Studenti. Daca pentru tabela respectiva nu s-a definit nici o cheie primara, 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 (numar cu autoincrementare de la o īnregistrare la alta), care va fi considerat cheie primara, sau No, caz īn care se salveaza structura tabelei asa cum era, fara nici o cheie primara. Daca se alege raspunsul Cancel se revine īn fereastra de definire a structurii Table fara a se efectua nici o salvare.

Īn cazul ca s-a ales unul din raspunsurile Yes sau No, structura tabelei a fost creata si īn fereastra Database a aparut tabela Studenti (vezi figura 1.11).

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

Daca dupa ce s-a salvat tabela sub numele Studenti se constata ca s-a gresit sau s-a uitat ceva la definirea structurii tabelei, se selecteaza tabela Studenti din fereastra 1.11 si se alege din meniul contextual al acesteia Design View (sau se da clic pe butonul ).

Astfel se deschide din nou fereastra Table, īn care se pot insera sau sterge linii (cu comenzile Insert Rows sau Delete Rows din meniul contextual atunci se selecteaza o anumita linie), se pot redenumi cāmpuri sau modifica proprietatile acestora, se pot adauga proprietati de indexare, reguli de validare etc. ca si la crearea structurii unei tabele noi, respectiv se poate alege ca un anumit cāmp sa devina cheie primara de indexare (selectānd linia cu cāmpul respectiv si dānd un clic pe butonul Primary Key din bara de unelte standard Microsoft Access atunci cānd este deschisa o tabela īn modul Design view). Īn final, structura tabelei Studenti īn fereastra Design view ar arata ca īn figura 1.12.

Figura 1.12. Structura tabelei Studenti īn modul Design view

Pentru setari suplimentare a indecsilor īn ceea ce priveste ordinea, eventual descrescatoare, de indexare, respectiv setarea unor indecsi dupa cāmpuri multiple, va trebui, tot din modul Design view, selectat butonul Indexes . Pe ecran va apare fereastra Indexes, īn care se specifica numele indexului, unul sau mai multe cāmpuri care intra īn componenta respectivului index si ordinea de sortare crescatoare (este implicita) sau descrescatoare. Figura 1.13 arata fereastra Indexes īn cazul tabelei Studenti

Figura 1.13. Fereastra Indexes pentru tabela Studenti

Observati īn figura 1.13 ca NumPre este numele unui index cāmp multiplu, īn care indexarea se va face īn primul rānd crescator dupa nume, iar la nume identice dupa prenume.

Dupa efectuarea tuturor modificarilor se īnchide fereastra Table si apare o fereastra cu mesajul: Do you want to save changes to the design of table ′Studenti′ ?, la care, pentru a salva toate modificarile, se raspunde cu Yes.

Pentru a introduce date īn tabelele create se da dublu clic pe tabela dorita din fereastra Databases (sau se alege optiunea Open din meniul contextual care apare la un clic dreapta de mouse pe tabele selectata, sau se alege butonul ) - a se vedea figura 1.11. Īn fereastra aparuta se introduc datele dorite, ca īn figura 1.14.

Figura 1.14. Datele introduse īn tabela Studenti

Observatie. Īn general, datele vor fi introduse prin program si nu īn modul prezentat mai sus. S-a dat si varianta aceasta doar ca exemplu didactic.

Īn ceea ce priveste crearea relatiilor, Microsoft Access ofera o reprezentare vizuala foarte sugestiva a relatiilor dintre tabelele unei baze de date. Aceasta reprezentare permite utilizatorului sa traga o linie īntre cāmpurile relationale din tabele sau interogari. Astfel, din mediul Access daca alegem optiunea Relationships... din meniul Tools sau dam clic pe icon-ul corespunzator din bara de unelte standard, obtinem o fereastra intitulata Relationships Cu un simplu clic dreapta oriunde īn aceasta fereastra putem adauga, prin intermediul optiunii Show Tables, cāte o tabela a bazei de date. Apoi, cu metoda drag-and-drop se "traseaza" practic relatiile dintre tabele, unind cāmpurile care fac legatura īntre doua tabele. Butonul de mouse se elibereaza cānd indicatorul mouse-ului va deveni un mic dreptunghi fixat pe cāmpul destinatie. Īn caseta de dialog Relationships care apare se cere definirea legaturii pe care vrem sa o realizam. Tot aici, de obicei, se bifeaza optiunea Enforce Referential Integrity, care are rolul de a ne īmpiedica sa facem greseli la introducerea datelor.

Īn cazul exemplului discutat mai sus, relatiile sunt reprezentate īn Microsoft Access ca īn figura 1.5 de la paragraful 1.1.3.1.

Cāmpurile īngrosate reprezinta chei primare īn tabelele respective, iar simbolurile legaturilor (cifra 1 si simbolul ) indica faptul ca, spre exemplu, unei singure īnregistrari din tabelul Studenti, īi pot corespunde mai multe īnregistrari din tabelul Note

Oricāt de bine ar fi proiectata si implementata o baza de date, nu e exclus ca la un moment dat sa fie necesara modificarea structurii bazei de date si a tabelelor ei componente pentru a gestiona si alte date. Modificarile pot īnsemna noi tabele sau indecsi īn cadrul tabelelor, sau schimbari īn proprietatile tabelelor, cāmpurilor sau indecsilor. Cāteodata s-ar putea dori stergerea unei tabele, unor cāmpuri sau indecsi.