Automatizarea Evidentei Cititorilor cu Utilizarea Sgbd Integrate Microsoft Access

Politehnica

Automatizarea Evidentei Cititorilor cu Utilizarea Sgbd Integrate Microsoft Access

Byadmin ianuarie 1, 2024

Cuprins

Lista abrevierilor 2

Introducere 3

Baze de date relaționale 9

1.1 Normalizare 9

1.2 Chei 14

II. SGBD Acces 18

2.1 Crearea formularelor 19

2.2 Crearea rapoartelor 20

III. Crearea Sistemul Informațional de evidență a cititorilor 22

3.1 Crearea relațiilor tabelelor 31

3.2 Rafinarea proiectării 36

3.3 Aplicarea regulilor de normalizare 39

Concluzii și recomandări 41

Bibliografie 42

Anexe 43

Lista abrevierilor

ABRM – Asociația Bibliotecarilor din Republica Moldova;

BD – Bază de Date;

CNC – Casa Națională a Cărții;

LC – Limbajul de cereri;

LDD – Limbajul de descriere a datelor;

LPD – Limbajul de prelucrare a datelor;

QBE – Query By Examples;

SGBD – Sistem de Gestiune a Bazelor de Date;

SGBDR – Sistem de Gestiune a Bazelor de Date Relaționale;

SQL – Structured Query Language;

ULIM – Universitatea Liberă Internațională din Moldova;

VBA – Visual Basic for Application.

BCNF – Boyce-Codd Normal Form;

Introducere

Actualitatea utilizării cărților / manualelor in procesul educațional

În procesul evoluției societăților moderne pe diferite planuri, un rol esențial îi revine informației. Gradul de complexitate a diferitor unitați social-economice implică o creștere continuă a volumului și diversității informațiilor. Pentru a ușura procesul de producere a informației, care necesită un volum considerabil de resurse umane și materiale, s-a realizat apelul la tehnologiile avansate.

Cărțile au fost și vor rămâne cei mai buni prieteni și sfătuitori ai noștri, tot ele fiind în viața noastră un astfel de element central, al creării unui psihic sănătos, sau al unei culturi generale, este sprijinul în cazul atunci când avem decăderi nervoase, este uneori ceva mai mult decât un profesor deoarece cu ajutorul acestora putem să descoperim lucruri noi, anume ele, cărțile ne fac să fim mai buni, ne ajută să trecem mai ușor peste greutățile vieții (iar acestea sunt numeroase), într-un cuvânt: ne întărește.

Cartea este un mod de comunicare și reprezintă o ordonare a cuvintelor la formele lor cele mai expresive. La început se scria pe pereții peșterilor, pe tăblițe de lut, de lemn, fildeș, bronz, pe papirus. Cartea este un sprijin. Ea ne ajută să înțelegem și să pătrundem în tainele lumii, a universului. În filele ei putem descoperi sfaturi, putem culege înțelepciune, ne putem “adăposti” de gurile rele.

O carte bună este o mângâiere deoarece ne alină, ne atrage cu ajutorul subiectelor ei și ne face să uităm de viața cotidiană. Cartea mai este un îndemn pentru că citind o carte este un îndemn de a citi altele, astfel reușim să găsim răspunsuri la întrebările noastre. Cartea “ne face să trăim înafara minciunii, nedreptății și prejudecății”(M. Sadoveanu). Aceste vorbe ale unui mare scriitor al tarii noastre ne atrage atenția asupra unei mai calități a cărții adică puterea de influențare puterea de a ne transpune într-o altă lume o lume a fantasticului .

Toți acei care au acces la o bibliotecă vor fi cu mult mai puternic sufletește, psihic. Aceștia sunt cei care vor putea înfrunta mai ușor viața cei care vor avea un vocabular adecvat .

Cărțile sunt cele care scot la iveală din noi ce e mai bun. Ele pot sa descopere adevărați genii care pot ajuta la îndreptarea viitorului unei tari întregi. Cinstireа care i se cuvine cărții este ca și cinstirea atribuită Evangheliei și Bibliei deoarece este ceea ce avem nevoie, este ceea ce ne ajută mai mult decât ne putem imagina. Ea este o grupare a cuvintelor a cuvintelor, cuvintele fiind rostite fiecare cu altă inimă, deci cartea înfățișează inima în diferite posturi.

O carte este o provocare pentru fiecare dintre noi. Nu trebuie decât să profităm de această imensă comoară, să învățăm să prețuim.

Studiind internetul, la întrebarea ”Care este rolul cărților și a lecturii în viața omului”, am găsit răspunsuri ca:

Cititul îmbogățește vocаbularul, astfel că nu de puține ori am întâlnit cu toții adolescenți care au dificultăți în exprimare și nu cunosc sensul multor cuvinte. Ei bine, lectura ajută adolescentul să se exprime, îl învață cuvinte noi, noi sensuri și noi informații.

Lectura lărgește orizonturile. În momentul în când citești mai multe cărți, afli multe lucruri nebănuite, lucruri pe care ai vrea să le trăiești, întâmplări și locuri pe care ai vrea să le cunoști. Și astfel devii mai ambițios, vei dori să reușești în viață.

Cititul face bine sufletului și psihicului, iar lectura cărților aduce liniște interioară, aduce odihnă sufletească, deconectarea de la gândurile de zi cu zi și plus de asta, este și o terapie, în special pentru adolescent. Dacă acesta suferă, să spunem, cititul îl va ajuta să se sustragă de la zbuciumul său, va descoperi noi căi, nedescoperite pentru el până la acel moment. Pentru că eliberându-și creierul de stres, va găsi soluții. Cititul vindecă. Cartea înseamnă plăcere și relaxare.

Lectura îmbogățește cultura generală, sunt mulți dintre cei care citesc care au o cultură generală demnă de invidiat. De cele mai multe ori, școala nu reușește să acopere tot ceea ce noi ar trebui să știm, ea nu va putea niciodată să ne aducă la cunoștință tot, de aceea este esențial să citim cărți, cărți interesante, care să ne dezvolte vocabularul și gândirea. Întotdeauna autodidacții sunt de cele mai multe ori mult mai deștepți decât cei care au mers pe un singur fir al educației, și mereu au câte un as în mâne că în timp ce alții nici măcar nu se gândeau la așa ceva. Citește, citește orice, este bine să știi din toate câte ceva.

Cititul face viața mai frumoasă și mai ușoară. Un om care citește va lua din cărți tot ceea ce îl interesează și va folosi ceea ce citește acolo în viața de zi cu zi. Acele detalii îl pot scăpa dintr-o încurcătură, sau din contră îl va face să fii și mai apreciat.

Lectura educă și disciplinează. În toate cărțile sunt personaje bune și personaje negative de la care mereu avem câte ceva de învățat, și în care ne putem vedea un ideal. Și aproape în orice carte vedem că oamenii răi, cu multe defecte sau apucături nefaste, sfârșesc rău. Pe principiul binele învinge răul, tânărul va învăța că prin tertipuri și răutate nu va ajunge nicăieri. Și datorită cărților își va dori să fie bun, drept, muncitor.

Cititul evidențiază omul. O persoană care citește se va putea integra oriunde și în orice grup. Datorită cunoștințelor sale va putea să poarte orice discuția și va reuși să se facă plăcut și apreciat. Oamenii care citesc au o strălucire aparte.

Cărțile îți fac cunoscută iubirea. Cred că pentru prima dată în viață adolescentul descoperă iubirea din cărți și tot acolo el va descoperi toate fețele ei. Citind, tânărul va fi îndrăgostit de iubire, își va dori mult prezența acesteia în viața lui, va lupta pentru ea și va ști cum să o țină în viața lui. Astfel tânărul va pune mai puțin preț pe relațiile sexuale și mai mult pe sentiment.

Cititul te ajută să cunoști viața. În cărți sunt dezbătute toate problemele omului, toate riscurile, eșecurile, împlinirile și reușitele. Citind, noi învățăm să înfruntăm problemele cu optimism și curaj. Nu vom claca la prima piedică.

Lectura formează un om fără alte discuții, face dintr-un tânăr cu multe temeri, un matur de toată isprava. Face omul inteligent, romantic, respectuos, tandru, luptător, încrezător, curajos, bun, milos și așa mai departe. Practic îi arată care sunt adevăratele valori ale vieții.

Lectura înseamnă bogăție. Un tânăr care citește mult va fi un om împlinit sufletește și va dobândi o spiritualitate superioară semenilor lui care nu prea citesc. Cărțile sunt cele mai de preț avuții, din ele afli secretul reușitei.

Rolul cărților in viața oamenilor este de a îmbogăți vocabularul si a forma personalitatea. Oameni care citesc mult au personalitate, si au un vocabular bine-dezvoltat, in sensul că, atunci când vorbești cu un om, si folosește cuvinte pe care nu le-ai mai auzit, și aici mă refer, sa fie cuvinte de care nu auzi in viața de zi cu zi, acela este un care citește foarte mult si are ca hobby sa stea cu cartea in mana. Este bine sa citești, pentru ca ai foarte multe de învățat din cărți, de la personajele unei cărți, din cuvintele care se folosesc in cartea respectiva. Daca citești mult descoperi cuvinte multe si vei vedea ca fără sa vrei, vei avea un vocabular mai bogat, mai vast, si asta e bine, pentru ca toți apreciem persoane care au vocabular vast. În concluzie, e bine sa citești, mai ales ca este ceva relaxant;

Lectura e bună pentru dezvoltarea capacității de a comunica bine cu persoanele din jurul nostru si de a menține activ un vocabular coerent fără greșeli gramaticale, in același timp favorizează la scris (când completam formulare sau alte acte);

Cărțile au rolul de a-ti deschide ochii si de a te învață de 3 ori mai multe lucruri decât televizoarele;

Cultură cică… În fine, citești o carte, un roman, ceva din proprie plăcere, doar nu o să te oprească nimeni pe stradă sa te ia la întrebări despre nu știu ce cărți…

Nu au nici un rol, doar daca ai nevoie de ele. Tu ești regizorul si hotărăști daca cărțile au un rol sau nu in viața ta. In viața unui doctor au un rol destul de important, ii învață cum sa acționeze, când și de ce. Acum gândește-te ce vrei sa te faci si vei afla ce rol au cărțile in viața ta;

Rolul ei este de a te învăța mai multe dar si acela de a-ți transforma vorbirea obișnuită într-una plastica pe care o au toți scriitorii dar si aceia de a i-ți îmbunătăți ziua si a o face mai bună;

Rolul cărților e important în viața fiecărui om, î-ți îmbogățește vocabularul și fiecare carte are rolul ei dacă o folosești și o înțelegi.

Scopul creării unei BD care ar ține evidența vizitelor

Numărul utilizatorilor deserviți de DIB ULIM constituie 6 899 (studenți, cadre didactico-științifice universitare, alte categorii de angajați, precum și a persoanelor din afara universității). În anul 2013 au fost în medie: intrări per zi – 358 utilizatori; per oră – 39.

În medie, un utilizator a vizitat spațiile DIB de 15 numărului utilizatorilor externi, care au beneficiat de serviciile DIB în anul 2012: 46 persoane

Aceste numere imediat ne duc la ideea ca o evidența manuală a vizitelor este una migăloasă și ineficientă, fapt care practic ne obligă să creăm o BD a tuturor utilizatorilor, unde fiecare sa aibă un identificator separat, datorită căruia să fie mult mai ușor de găsit utilizatorul in BD, precum și să ușureze crearea rapoartelor, sau chiar putem spune, să automatizeze crearea acestor rapoarte pentru a putea duce evidența celor care vizitează spațiile sălilor de lectură, precum și pentru a putea crea o statistică reală a numărului de vizite, sau, altfel spus, de a putea crea rapoarte de vizită, în care să fie indicată frecvența intrărilor în sălile de lectură.

Posibilitățile MS Acces

La baza SGBDR Microsoft Access se afla modelul relațional al datelor si modelul prezentat pe obiecte. În comparație cu alte SGBDR, produsul Microsoft Access di spune de toate componentele un BD stocate într-un fișier cu extensia MDB.

SGBDR Microsoft Access permite definirea, consultarea și actualizarea BD, și în plus și partajarea acestora între mai mulți utilizatori (până la 20 concomitent). Pentru a executa comenzile, în SGBDR Microsoft Access se asigură facilități ca: meniuri, instrumente specifice, casete de dialog precum și combinații de taste.

Produsul Microsoft Access permite lucrul cu 3 limbaje QBE (Query By Examples), SQL (Structured Query Language) și VBA (Visual Basic for Application), deci, există mai multe modalități de realizare a aplicațiilor pentru BD sub SGBDR Microsoft Access

Cuvintele cheie ale tezei

sistem informatic – totalitatea entităților care operează cu informația pentru optimizarea proceselor business, fără utilizarea tehnicilor de calcul;

sistem informațional – un sistem informatic care utilizează tehnica de calcul;

informație – noutate, descoperire, mesaj;

date – informație in context cunoscut.

aplicație – un complex de programe care asigura prelucrarea automata a informației pentru un procentităților care operează cu informația pentru optimizarea proceselor business, fără utilizarea tehnicilor de calcul;

sistem informațional – un sistem informatic care utilizează tehnica de calcul;

informație – noutate, descoperire, mesaj;

date – informație in context cunoscut.

aplicație – un complex de programe care asigura prelucrarea automata a informației pentru un proces;

dicționar de date – un sistem al BD-lor destinat păstrării centralizate a informației despre date, legături dintre date, tipul si foratul de reprezentare al datelor, sistemul de securitate, si altele.

limbajul de descriere a datelor (LDD) – limbajul care permite descrierea structurii bazei de date, a componentei, a relațiilor dintre componente, a drepturilor de acces al utilizatorilor la baze de date (BD);

limbajul de cereri (LC) – limbajul in care se scriu programele pentru realizarea prelucrarii datelor;

limbajul de prelucrare a datelor (LPD) – limbajul care permite operații asupra BD, cum ar fi încărcarea BD, înserarea, ștergerea, căutarea sau modificarea unui element, realizarea de statistici.

Baze de date relaționale

Principalele sarcini ale unei baze de date sunt:

reducerea surplusului de informație prin identificarea informațiilor comune si alcătuirea corespunzatoare a aplicațiilor;

eliminarea inconveniențelor ce rezultă din reducerea expresiilor repetitive, care rol repetitiv, și nu aduc nici o noutate;

utilizarea simultană a datelor de mai mulți utilizatori;

standardizarea informațiilor;

asigurarea securitații bazelor de date prin acordarea și urmărirea modului de acces al utilizatorilor la componentele BD;

asigurarea integritații bazelor de date;

asigurarea sincronizării in cazul utilizării simultane a unei baze de date de către mai mulți utilizatori în același timp, sau a distribuirii informației pe mai multe sisteme de dirijare a datelor.

1.1 Normalizare

La proiectarea unei baze de date relaționale, principalul obiectiv în realizarea unui model logic este crearea unei reprezentări corecte a datelor, relațiilor dintre ele și a constrângerilor. Pentru atingerea acestui obiectiv, trebuie identificat un set adecvat de relații. Normalizarea reprezintă o tratare de jos în sus a proiectării bazelor de date, care începe prin examinarea relațiilor dintre atribute. Totuși, de multe ori metodologia de proiectare abordează o tratare de sus în jos a BD (care începe prin identificarea principalelor entități și relații), caz în care normalizarea este folosită ca tehnică de validare.

Procesul de normalizare este o metodă formală, care identifică relațiile bazându-se pe cheile primare ale acestora și pe dependențele funcționale dintre atribute. Normalizarea ajută proiectanții de BD, prin prezentarea unei serii de teste care pot fi aplicate relațiilor individuale, pentru a preveni apariția anomaliilor de reactualizare.

Unul din principalele scopuri urmărite la proiectarea bazelor de date relaționale, este gruparea atributelor în relații în așa fel încât să se minimizeze redundanța datelor și prin aceasta să se reducă spațiul de stocare necesar relațiilor de bază implementate.

Codd a definit inițial 3 forme normale, notate prin FN1, FN2 și FN3. Întrucât într-o primă formulare, definiția FN3 ridică ceva probleme, Codd și Boyce au elaborat o nouă variantă, cunoscută sub numele de Boyce-Codd Normal Form (BCNF). Astfel BCNF este reprezentată separat în majoritatea lucrărilor. R. Fagin a tratat cazul FN4 și FN5.

O relație este într-o formă normală dacă satisface o mulțime de constrângeri specificată în figura 1.1.1. De exemplu, se spune că o relație se află în a doua formă normală FN2 dacă și numai dacă se află în FN1.

Fig.1.1. Formele normale ale relațiilor dintr-o BDR

Normalizarea bazei de date relaționale poate fi imaginată ca un proces prin care dacă e să pornim de la relația inițială/universală R, se realizează descompunerea succesivă a acesteia în subrelații, aplicând operatorul de proiecție. Relația R poate fi ulterior reconstruită din cele n relații obținute în urma normalizării, prin operații de joncțiune, și avem ceea de la ce ne-am pornit.

Prima formă normală (FN1)

FN1 este strâns legată de noțiunea de atomicitate/unicitate a atributelor unei relații.

Astfel, aducerea unei relații în FN1 presupune introducerea noțiunilor de:

– atribut simplu;

– atribut compus;

– grupuri repetitive de atribute.

Atributul simplu- Atribut compus

Prin atribut simplu (atribut atomic) se înțelege un atribut care deja nu mai poate fi descompus în alte atribute, în caz contrar, atributul este compus (atribut neatomic).

Exemplu: Exemplele care urmează, sun exemple de atribute care pot fi considerate simple sau compuse, în funcție de circumstanțe și de obiectivele bazei de date.

– Data calendaristică – este un atribut în care apar câmpurile: zi, lună, an;

– Adresa – este un atribut în care apar câmpurile: strada, nr, bloc, scara, etaj, apartament, localitate;

– Data operațiunii bancare – este un atribut în care apar câmpurile data, ora;

– Buletin/carte identitate – este un atribut în care apar câmpurile: seria, nr.

Aceste atribute pot fi atomice sau neatomice. Astfel adresa clienților agenției imobiliare interesează la nivel global, pe când pentru adresa ofertei sau a cererii de imobile este vitală prelucrarea separată a fiecărui câmp considerat. Analog, atributul „nume” reprezentă un atribut simplu al acestei baze de date, deoarece numele clientului interesează la nivel global.

Grupuri repetitive de atribute

Un grup repetitiv este un atribut (grup de atribute) dintr-o relație, care apare cu valori multiple pentru o singură apariție a cheii primare și a relației nenormalizate.

În cazul în care o factură conține mai multe produse, relația de mai sus va avea grupurile repetitive: „cod_produs”, „denumire_produs”, „cantitate”, „pret_unitar”, „valoare”, valoare_tva”.

Aducerea unei relații universale la FN1

FN1 este tratată în general cu superficialitate, deoarece principala cerință

– atomicitatea valorilor – este ușor de îndeplinit (cel puțin la prima vedere).

Dintre toate formele normale, doar FN1 are caracter este una obligatorie, se spune că o bază de date este normalizată daca toate relațiile se află măcar în FN1.

O relație este în FN1 dacă domeniile pe care sunt definite atributele relației sunt constituite numai din valori atomice. Un cuplu nu trebuie să conțină atribute sau grupuri de atribute repetitive.

Aducerea relațiilor în FN1 presupune eliminarea atributelor compuse și a celor repetitive.

Se cunosc trei soluții pentru determinarea grupurilor repetitive:

– eliminarea grupurilor repetitive pe orizontală (în relația R inițială, în locul atributelor compuse se trec componentele acestora, ca atribute simple);

– eliminarea grupurilor repetitive prin adăugarea de tupluri;

– eliminarea grupurilor repetitive prin construirea de noi relații

Primele două metode generează relații stufoase prin duplicarea forțată a unor atribute, respectiv tupluri, creându-se astfel redundanțe masive cu multiple anomalii de actualizare.

Metoda a treia presupune eliminarea grupurilor repetitive prin construirea de noi relații, ceea ce generează o structură ce oferă cel mai mic volum de redundanță.

Etapele de aducere a unei relații în FN1 sunt:

I. se construiește câte o relație pentru fiecare grup repetitiv;

II. în schema fiecărei noi relații obținute la pasul 1 se introduce și cheia primară a relației R nenormalizate;

III. cheia primară a fiecărei noi relații va fi compusă din atributele chei ale relației R, plus unul sau mai multe atribute proprii.

A doua formă normală (FN2)

FN2 este strâns legată de noțiunea de dependență funcțională. Noțiunea de dependență funcțională a fost prezentată în cursul 5: „Restricții de integritate ale modelului relațional”.

O relație se află în a doua formă normală FN2 dacă:

1. se află în forma normală FN1 și

2. fiecare atribut care nu este cheie este dependent de întreaga cheie primară.

Etapele prin care o relație FN1 ajunge la FN2 sunt:

I. Se identifică cheie primară a relației care se află în FN1;

II. Se identifică toate dependențele dintre atributele relației, cu excepția acelora în care sursa este un atribut component al cheii primare;

III. Se identifică toate dependențele care au ca sursă un atribut sau subansamblu de atribute din cheia primară;

IV. Pentru fiecare atribut (sau subansamblu) al cheii de la pasul III se creează relație care va avea cheia primară atributul (subansamblul) respectiv, iar celelalte atribute vor fi cele care apar ca destinație în dependențele de la etapa III.

Chiar dacă au fost eliminate o parte din redundanțe, mai rămân și alte redundanțe ce se vor elimina aplicând alte forme normale.

A treia formă normală (FN3)

O relație se află în forma normală trei FN3 dacă:

1. se găsește în FN2 și

2. fiecare atribut care nu este cheie depinde direct de cheia primară.

A treia regulă de normalizare cere ca toate câmpurile din tabele să fie independente între ele.

Etapele prin care o relație ajunge din FN2 în FN3 sunt:

I. Se identifică toate atributele care nu fac parte din cheia primara și sunt surse ale unor dependențe funcționale;

II. Pentru fiecare dintre aceste atribute, se construiește câte o relație în care cheia primară va fi atributul respectiv, iar celelalte atribute, destinațiilor considerate;

III. Din relația de la care s-a pornit se elimină atributele destinație, și se identificată la primul pas, păstrându-se atributele surse.

Observația 1: Această formă, a treia formă normală mai poate suferi o serie de rafinări pentru a putea obține o structură performantă de tabele ale bazei de date. De exemplu se observă că „nume_client” este un câmp în care este înscris un text destul de lung format dintr-o succesiune de litere, semne speciale (punct, virgulă, cratimă), spații, numere. Ordonarea și regăsirea informațiilor după astfel de câmpuri este înceată și mai greoaie decât dacă ar fi să căutăm după câmpurile numerice. Din acest motiv putem introduce un nou atribut „cod_client”, care să fie numeric și care să mai fie și cheia primară de identificare pentru fiecare client.

Observația 2: O altă observație ar putea fi făcută în legătură cu tabelele care se află în cea de a treia formă normală, și anume că „total_valoare_factura” este un câmp care ar trebui să conțină informații sintetice, obținute prin însumarea valorii tuturor ofertelor aflate pe o factură. Este însă de preferat ca astfel de câmpuri să fie calculate în rapoarte sau interogări și să nu fie memorate în tabelele bazei de date.

Verificarea punerii în practică corecte a procesului de normalizare se realizează în așa fel încât uniunea acestora să producă relația inițială, cu alte cuvinte, descompunerea trebuie să fie fără pierderi care ar schimba ceva semnificativ.

Celelalte forme normale se întâlnesc mai rar în practică, ele fiind considerate mai mult la nivel teoretic. Aceste forme nu sunt respectate, în general, pentru că beneficiile de eficiență pe care le aduc nu compensează costul și munca de care este nevoie pentru a le respecta

1.2 Chei

Cheile reprezintă puntea de legătură dintre diferite tabele.

Fiecare tabel trebuie să conțină cel puțin un câmp, al cărui valoare să fie unică pentru fiecare înregistrare(câmp cheie principală). Acest câmp este util pentru a putea identifica în mod unic fiecare înregistrare. Pentru stabilire cheii principale, trebuie să parcurgem următorii pași:

Deschidem tabelul și afișăm structura acestuia;

Selectăm câmpul care vrem să fie cheie principală;

Alegem din meniul Edit opțiunea Primary Key.

Puterea unui sistem relațional al bazei de date cum este Microsoft Access provine din capacitatea de a găsi și reuni rapid informații memorate în tabele separate utilizând interogări, formulare, și rapoarte. Pentru aceasta, fiecare tabel trebuie să includă un câmp, sau un set de câmpuri care să identifice în mod unic fiecare înregistrare care este memorată în tabel. Această informație se numește cheia primară a tabelului. După desemnarea unei chei primare pentru un tabel, Access în continuare va preveni introducerea oricărei dublări sau valori Null în câmpurile cheii primare (ceea ce ar încălca regulile cu privire la alocarea cheii principale a unui tabel în Acces).

Există trei tipuri de chei primare ce pot fi definite în Access:

Chei primare AutoNumerotare

Un câmp AutoNumerotare poate fi setat să introducă automat un număr secvențial pe măsură ce se fac introduceri de noi date în tabel. Desemnarea acestui de câmp ca cheie primară pentru tabel este cel mai simplu mod de a crea chei primare. Dacă înainte de prima salvare nu stabiliți o cheie primară a tabelului nou creat, Microsoft Access va cere permisiunea creării unei chei primare. Dacă sunteți de acord, Microsoft Access va crea o cheie primară AutoNumerotare.

*Chei primare AutoNumerotare într-o bază de date reprodusă

Există considerații suplimentare dacă tabelul va fi utilizat cu reproducerea bazei de date.

Dacă mai puțin de 100 de înregistrări sunt adăugate normal între diverse reproducerile sincronizate, trebuie de utilizat o setare Întreg Lung pentru proprietatea DimensiuneCâmp pentru a ocupa mai puțin spațiu pe disc.

Dacă mai mult de 100 de înregistrări sunt adăugate normal între reproducerile sincronizate, trebuie de utilizat Reproducere_ID pentru setarea proprietății DimensiuneCâmp pentru a împiedica asocierea aceleiași valori a cheii primare înregistrărilor din fiecare reproducere. De reținut, totuși, că un câmp AutoNumerotare cu o dimensiune de câmp Reproducere ID produce o valoare de 128 biți care va necesita mai mult spațiu pe disc.

Chei primare pentru un singur câmp

Dacă aveți un câmp ce conține valori unice cum ar fi numere, ID sau coduri produs, se poate desemna câmpul respectiv ca o cheie primară. Puteți preciza o cheie primară pentru un câmp ce conține deja date atât timp cât acel câmp corespunde regulilor pentru câmpurile – cheie primară (nu conține valori dublate sau valori Null).

Chei primare pentru câmpuri multiple

Sunt situații în care nu se poate asigura unicitatea unui singur câmp, în așa caz este posibilitatea de-a desemna două sau mai multe câmpuri drept cheie primară. Cea mai cunoscută situație de acest fel este în tabelul care este utilizat pentru a corela alte două tabele într-o relație mulți-la-mai-mulți. De exemplu, un tabel Detalii Comandă poate corela tabelele Comenzi și Produse. Cheia sa primară conține două câmpuri: IDComandă și IDProdus. Tabelul Detalii Comandă poate lista multe produse și mai multe comenzi, dar fiecare produs poate fi listat doar o dată pe comandă, în acest caz combinarea câmpurilor IDComandă și IDProdus produce o cheie primară corespunzătoare.

Fig. 1.2.1 Reprezentarea cheilor principale pentru câmpuri multiple

Fiecare produs poate fi listat doar o singură dată în comandă.

Un alt exemplu ar fi o bază de date cu ajutorul caruia se face inventarierea, care utilizează un câmp pentru cod produs alcătuit din două sau mai multe câmpuri (produs și subprodus).

În cazul când nu ești sigur că se poate selecta o combinație corespunzătoare de câmpuri pentru o cheie primară pentru câmpuri multiple, probabil trebuie să adăugați un câmp AutoNumerotare și să îl desemnați ca o cheie primară. De exemplu, combinarea câmpurilor Prenume și Nume pentru producerea unei chei primare nu este o alegere bună, deoarece în acest caz se pot întâlni dublări la asocierea acestor două câmpuri.

Într-o cheie primară pentru câmpuri multiple, ordinea câmpurilor poate fi importantă. Câmpurile dintr-o cheie primară pentru câmpuri multiple sunt sortate în raport cu ordinea lor în vizualizare în mod proiectare_tabel. Puteți modifica ordinea câmpurilor tip cheie primară în fereastra Indexuri.

1.3 Relații

Relațiile între două tabele nu sunt obligatorii, dar sunt necesare, în general, pentru construirea interogărilor care acționează asupra acestor table (deși relația s-ar putea construi și când se construiește interogarea). Tipuri de relații:

Relația One-To-Many – Este cea mai frecventăutilizată în proiectarea bazelor de date Access și are următoarele caracteristici:

Dacă T1 (Tabela Facultăți) și T2 (Tabela Studenți) sunt două tabele în care există o relație One-To-Many atunci: Tabela T1 este tabela primară iar T2 este tabela legată. Cheia de legătură din tabela primară trebuie să fie declarată cheie primară. Tabela legătură poate avea cheie primară dar diferită de cea de legătură. Fiecărei înregistrări din tabela One trebuie să îi corespundă 0, 1 sau mai multe înregistrări din tabela Many; Fiecărei înregistrări din tabela Many trebuie să-i corespundă cel mult o înregistrare din tabela One.

Relația One-To-One – Este o relație utilizată rar în proiectarea bazelor de date Access și are caracteristici ca:

Cheile de legătură din ambele tabele sunt chei primare; fiecărei înregistrări din una din tabele îi corespunde maxim o înregistrare din cealaltă. Una din tabele este primară iar cealaltă legată. În proiectare se încearcă să se elimine astfel de legături, se permite așa ceva doar în cazuri când ambele tabele sunt voluminoase, adică au multe coloane, și ar periclita buna folosință a bazei date.

Relația Many-To-Many – de obicei nu este recomandată în baze de date Access, dar existentă în realitate.

Două tabele se află în relația Many-to-Many dacă fiecărei înregistrări din prima tabelă îi corespunde 0,1 sau mai multe înregistrări din a doua și invers. În Access aceste relații pot fi introduse prin crearea unei a treia tabele, care va fi numită de legătura, cu existența a două relații de tip One-to-Many.

II. SGBD Acces

Microsoft Office Access organizează informațiile existente în tabele: liste de rânduri și coloane ce amintesc de registrul unui contabil sau de o foaie de lucru din Microsoft Office Excel. Într-o bază de date simplă, se poate să aveți doar un singur tabel. Pentru cele mai multe baze de date va trebui să aveți mai multe tabele, iar conexiunea dintre acestea se va efectua prin intermediul cheilor (primare sau secundare în dependență de context). De exemplu, sunt cazuri când se poate să aveți un tabel care stochează informații despre servicii, un alt tabel care stochează informații despre comenzi și un altul cu informații referitoare la studenți.

Sistemul de gestiune a bazelor de date relaționale Microsoft Access conservă avantajele sistemelor de gestiune, asigurând astfel interfața între BD și utilizator. SGBD Microsoft Access permite definirea, consultarea și actualizarea BD și în plus, partajarea datelor între mai mulți utilizatori (simultan, într-o BD Access pot lucra mai mult de 20 de utilizatori)

La baza SGBDR Microsoft Access se afla modelul relațional al datelor si modelul prezentat pe obiecte. In comparație cu alte SGBDR, produsul Microsoft Access dispune de toate componentele un BD stocate într-un fișier cu extensia MDB.

SGBDR Microsoft Access permite definirea, consultarea precum și actualizarea BD, iar un avantaj al acestuia mai este ca permite și partajarea acestora între mai mulți utilizatori (până la 20 care pot lucra concomitent). Pentru a executa comenzile, în SGBDR, Microsoft Access se asigură facilități ca: meniuri, instrumente specifice, casete de dialog precum și combinații de taste care asigură o utilizare mai rapidă a comenzilor.

Produsul Microsoft Access permite lucrul cu 3 limbaje QBE (Query By Examples), SQL (Structured Query Language) și VBA (Visual Basic for Application), deci, există mai multe modalități de realizare a aplicațiilor pentru BD sub SGBDR Microsoft Access

Fiecare rând se mai numește înregistrare și fiecare coloană, de asemenea, se mai numește câmp. O înregistrare este o modalitate semnificativă și consistentă de a combina anumite informații sau detalii. Un câmp este un element singular de informație – un tip de element care apare în orice înregistrare.. Fiecare coloană sau câmp conține un anumit tip de informație despre acest serviciu, cum ar fi numele, sau careva date de contact.

2.1 Crearea formularelor

O metodă des utilizată pentru introducerea datelor în tabele este crearea de formulare. Cu ajutorul formularelor putem aloca exact atât spațiu cât este necesar pentru fiecare câmp și putem introduce informații în mai multe tabele simultan. Formularele pot interoga o bază de date MS Access, regăsi înregistrărilor și afișa pe browser.

O aplicație Access de obicei este o formă principală pe care se pot afla controalele.

Atunci când lucrăm cu date relaționale, de cele mai multe ori este nevoie să vizualizăm datele din mai multe tabele, sau interogări în același formular. De exemplu, dorim să vedem date despre client, dar, în același timp, să vedeți și informații despre comenzile clientului. Sub-formularele sunt un instrument util pentru acest lucru.

Un sub-formular este tot un formular dar care se inserează în alt formular. Formularul primar este numit formular principal, iar formularul din interiorul formularului se numește sub-formular. O combinație formular / sub-formular este denumită uneori formular ierarhic, formular coordonator/detaliu sau formular părinte/fiu.

Formularul principal și sub-formularul din acest tip de formular sunt legate, pentru ca sub-formularul să afișeze doar înregistrări relaționate cu înregistrarea curentă din formularul principal.

Poți crea un formular în trei diverse moduri:

Autoforms oferă foarte rapid formulare care conțin toate câmpurile într-un singur tabel;

Form Wizard ne ajută să creăm un formular furnizându-se o serie de casete de dialog din care poți alege câmpurile și stilul pentru formular;

Creând un formular pornind de la zero, ai la dispoziție o grilă de machetare în care pot fi plasate câmpuri. Este modul cel mai dificil, dar asigură cel mai bun control (Design View). Aceasta este cea mai folosită metodă, și poate fi aplicată inclusiv pentru editarea formularelor care au fost create cu cele 2 metode descrise inițial.

Adăugarea etichetelor este utilizată pentru a putea adăuga formularului titluri, subtitluri, text explicativ și altele. Trebuie să adaugăm în formular un obiect care se numește etichetă. În cazul în care bara de instrumente nu este afișată, alegem opțiunea Toolbox din meniul View sau putem executa clic pe butonul Toolbox de pe bara de instrumente.

Tot cu metoda Design View se pot edita și:

Secțiunile unui formular

Detail – care conține câmpurile ce se repetă în formular, împreună cu informațiile de formatare și alte obiecte auxiliare;

Form Header/Footer – sunt antetele și subsolurile formularului;

Page Header și Page Footer – sunt acele zone care sunt repetate în partea de sus sau de jos a fiecărei pagini a formularului atunci când acesta este tipărit;

Group Header și Group Footer – reprezintă antetele și subsolurile unui grup de date, atunci când datele sursei de date ale formularului sunt grupate cu ajutorul clauzei SQL „Group by”, sau prin butonul de grupare. De obicei, anume aici este și locul unde se introduc titluri și subsoluri care conțin câmpul după care se va face gruparea.

2.2 Crearea rapoartelor

Rapoartele sunt obiecte prin intermediul cărora se generează rezultate profesionale care pot fi afișate pe ecran, tipărite pe hârtie sau afișate pe Internet. Există metode de generare a rapoartelor ca:

Autoreport – indicat pentru a crea un raport simplu, care este bazat pe un singur tabel sau pe o singură interogare.

Report Wizard asigură un compromis acceptabil între ușurința în utilizare și flexibilitate. Cu Report Wizard, poți utiliza mai multe tabele și interogări și putem alege o machetă și un format pentru raportul tău, care să difere de altele.

Creând un raport pornind de la zero, avem la dispoziție o grilă de machetare în care plasezi câmpuri. Acesta este modul cel mai dificil, dar asigură cel mai bun control (Design View). Aceasta este cea mai folosită metodă, și se poate fi aplicată pentru a edita rapoartele care au fost create cu primele două metode.

Adăugarea controalelor cu ajutorul controalele din raport, în modul de vizualizare Report Design este asemănător cu modul de lucru cu controalele în modul Form Design. Selectarea controalelor se efectuează când facem clic pe control. În jurul acestuia apar mânere de selecție. Mutarea obiectelor se efectuează prin selecția obiectul respectiv, apoi poziționarea indicatorului mouse-ului deasupra unei laturi a chenarului astfel încât acesta să se transforme într-o palmă deschisă și neagră. După aceasta, executăm clic și tragem controlul în noua poziție. Redimensionarea obiectelor se efectuează selectând obiectul, apoi poziționând indicatorul mouse-ului deasupra unui mâner de selecție și trăgându-l pentru a redimensiona obiectul. Formarea obiectelor de text – utilizează listele derulante Font și Font Size de pe bara cu instrumente pentru a alege fonturi, apoi utilizează butoanele Bold, Italic sau Underline de pe bara cu instrumente pentru a aplica anumite atribute. Putem adăuga, de asemenea, linii și imagini în rapoarte, la fel ca în formulare.

Tot cu metoda Design View se pot edita și:

Secțiunile unui raport

Detail – acesta conține câmpurile care se repetă în raport, împreună cu informațiile de formatare și obiectele auxiliare formatării.

Report Header/Footer – sunt antetele și subsolurile raportului.

Page Header Și Page Footer – reprezintă zonele care se repetă în partea de sus sau de jos a fiecărei pagini a raportului atunci când acesta se tipărește.

Group Header Și Group Footer –sunt antetele și subsolurile unui grup de date, atunci când datele din sursa de date a raportului sunt grupate prin clauza SQL „Group By”, sau cu ajutorul butonului de grupare. De cele mai multe ori, aici este locul unde se introduc titluri și subsoluri care conțin câmpul după care se face gruparea, precum și expresii care conțin funcții de agregare SQL.

III. Crearea Sistemul Informațional de evidență a cititorilor

Ce reprezintă o bună proiectare a unei baze de date?

Aceasta este întrebarea pe care ne-o punem la început de cale. Sunt anumite principii ne ghidează procesul de proiectare al unei baze de date. Primul principiu ar fi acela că informațiile care se repetă (care mai sunt numite și date redundante) au o influență negativă(dăunătoare chiar), deoarece consumă spațiu și sporesc probabilitatea producerii erorilor. Al doilea principiu îl putem considera caracterului complet al informațiilor și importanța corectitudinii acestora. Dacă o bază de date conține informații incorecte, orice rapoarte care extrag informații din această baza de date vor conține, de asemenea, informații incorecte. Prin urmare, orice decizie pe care o luăm bazându-ne pe aceste rapoarte va fi greșit formulată.

O bună proiectare a unei baze de date este, o proiectare care:

Împarte informațiile în tabele pe baza subiectelor, pentru a face o reducere a datele redundante.

Furnizează programului Access informațiile necesare pentru ca acesta sa poată asocia informațiile din tabele după necesități.

Asistă și asigură acuratețea și integritatea informațiilor.

Adaptează necesitățile de prelucrare a datelor și cele de raportare.

Procesul de proiectare

Procesul de proiectare constă în pași cai:

Determinarea scopului bazei de date

Baza noastră de date are ca scop automatizarea monitorizării intrării studenților în sălile de lectură din cadrul DIB ULIM. Este nevoie de această automatizare pentru a ușura efectuare statisticilor lunare / săptămânale / semestriale referitor la vizitarea de către studenți a sălilor.

Găsirea și organizarea informațiilor necesare

Pentru a face aceasta BD, avem nevoie de lista tuturor studenților din cadrul ULIM, fiecare nume însoțit de informația de bază despre student, cum este: facultatea, numărul carnetului de student, anul de studii, eventul niște date de contact, ca în caz de întârziere a restituirii cărților împrumutate sa-l contactăm, și, un identificator unic pentru fiecare student în baza noastră, care va fi id_student.

Împărțirea informațiilor în tabele

Împărțim informația în tabele ca Studenți, facultăți, iar mai apoi, în timpul lucrului cu aceste tabele vom vedea dacă este necesitatea de a mai introduce și alte tabele, la fel și pe viitor, la o posibilă utilizare mai pe larg a acestei baze de date, sa ținem cont ca tabelele să fie destul de ușor de schimbat / adică să fie destul de flexibile, iar denumirile coloanelor să fie intuitive.

Transformarea elementelor de informații în coloane

Decidem ce informații să stocăm în fiecare tabel. Fiecare element devine un câmp care este afișat sub formă de coloană în tabel. De exemplu, în tabelul studenți, include câmpuri, cum sunt: Nume de familie și facultatea la care studiază, iar tabelul facultăți include date precum denumirea facultății și numărul de studenți care își fac studiile acolo.

Specificarea cheilor primare

Alegem cheia primară pentru fiecare tabel. Aceasta este o coloană care este utilizată pentru a identifica în mod unic fiecare rând. Un exemplu poate fi ID_facultate sau ID_student.

Configurarea relațiilor din tabel

Privim fiecare tabel și decidem cum asociem datele dintr-un tabel cu datele din alte tabele, și stabilim/trasăm relațiile.

Rafinarea proiectării

Analizăm proiectarea pentru a elimina erorile. Creăm tabele și adăugăm câteva înregistrări de date eșantion. Mai revăd aranjarea datelor în tabelă, și mai facem unele schimbări care simplifică utilizarea bazei.

Aplicarea regulilor de normalizare

Aplicăm regulile de normalizare a datelor pentru a vedea dacă tabelele sunt corect structurate. Efectuăm ajustări pentru tabele, dacă este necesitate în cazul lor de-a le efectua.

Determinarea scopului bazei de date

Ne notăm scopul bazei de date pe o foaie: "Baza de date a utilizatorilor păstrează o listă a informațiilor despre utilizatori (studenți) în scopul producerii de liste de corespondență și de rapoarte. La necesitate, această bază poate fi, cu unele modificări, utilizată și pentru a ține evidența vizitelor+ evidența cărților împrumutate, iar, daca baza va fi conectată cu baza unde se păstrează titlurile prezente în bibliotecă să creeze anumite statistici referitor la numărul de cărți împrumutate la moment, frecvența împrumutării unui anumit titlu, sau lipsa interesului utilizatorilor pentru un altul." În dependență de complexitatea bazei, precum și de numărul de persoane care o utilizează, scopul trebuie să includă când și de către cine va fi utilizată baza de date, informație care trebuie să fie accesibile pentru toți eventualii utilizatori. Ideea principală a construirii acestui scop, este să se descrie riguros misiunea bazei de date, care să fie consultată în cadrul procesului de proiectare.

Găsirea și organizarea informațiilor necesare

Pentru a găsi și organiza informațiile necesare, începem cu informațiile existente. De exemplu, înregistrez inițial câțiva studenți într-un registru sau se pot ține informații despre utilizatori în formulare, într-un dulap pentru dosare. Colectăm aceste documente și trecem în listă fiecare tip de informații pe care le avem (de exemplu, fiecare casetă completată dintr-un formular). Examinând datele deja existente, în care sunt înregistrați studenții constatăm de fapt că nu prea avem date despre acești studenți, în actualele fișe de înregistrare sunt notate doar nume, prenume, și id-ul alocat acestui student de către angajați, pentru a putea ține evidența documentelor celor care au împrumutat documente din sală. Deja în documentele sus-menționate, dacă să le deschidem pe fiecare separat găsim informații detaliate despre student – utilizator. Fiecare dintre aceste date prezentate în documentul lăsat în biblioteca pe perioada împrumutului cărții reprezentă o coloană din tabel.

Pe măsură ce pregătim lista, ne dăm seama că ea din prima nu va fi neapărat perfectă, însă ulterior ea va mai fi perfecționată.

După asta, luăm în considerare tipurile de rapoarte sau de liste poștale pe care dorim să le obțineți din baza de date. Drept exemplu poate servi necesitatea creării unui raport de vânzări pentru un produs, care va afișa vânzările în funcție de regiune, sau un raport de rezumare a inventarului, care afișează nivelurile de inventar ale produselor. Tot în același mod se pot genera scrisori formale, care vor fi trimise clienților pentru a-i anunța de evenimente sau de oferte speciale care vor avea loc pe viitor. În primul rând trebuie de proiectat mintal raportul și să ni-l imaginăm cum va arăta, ce informații ați dori să puneți în raport? Treceți fiecare element în listă ca să îl mai analizați ulterior, dacă va fi necesitatea. Faceți același lucru pentru scrisoarea formală și pentru orice alt raport pe care considerați că îl veți crea.

Proiectarea mintală a rapoartelor și a listelor poștale pe care dorim să le creăm ne va ajuta la identificarea elementelor de care vom avea nevoie în ulterior construita bază de date.

Este destul de logic ca să se construiască un prototip al fiecărui raport, sau listare de ieșire și să luăm în considerare elementele necesare pentru a produce raportul de care avem nevoie. De exemplu, atunci când examinăm o scrisoare formală, poate să ne vină în minte alte idei. Pentru a putea include o formulă care ar avea rol de introducere corespunzătoare — de exemplu, șirul "Dl.", "Dna." sau "Dra." cu care începe o formulă de salut, va fi necesitatea de creat un element pentru introducere. De asemenea, o scrisoare este mai bine să se înceapă cu “Dragă Dl. Georgescu”, decât cu “Dragă Dl. Florin Georgescu”. Așadar, de obicei este mai comod și mai rațional să stocăm numele de familie separat de prenume.

Trebuie să ținem cont de faptul că informațiile trebuie să fie despărțite în cele mai mici părți utile. În cazul unui nume, pentru ca numele de familie să fie mai disponibil, vom despărți numele în două părți — Nume și Prenume. Pentru ca să sortăm un raport după numele de familie, de exemplu, este util și recomandat să se stocheze separat numele de familie. În general, pentru a putea sorta, căuta, celula sau raportul în funcție de un element informațional, trebuie pus acel element într-un câmp personal.

Gândiți-vă la întrebările la care doriți, sau simplu trebuie să răspundă baza de date pe care o proiectați. De exemplu, avem nevoie să știm: câte vânzări s-au finalizat pentru produsul principal? Unde locuiesc studenții? Cine este furnizorul produsului care se vinde cel mai bine? Anticiparea unor astfel de întrebări ajută să ne dați seama de elementele suplimentare care trebuie înregistrate.

După ce colectăm aceste informații, suntem gata pentru pasul următor.

Împărțirea informațiilor în tabele

Pentru a împărți informațiile în tabele, trebuie să alegem cele mai importante entități sau subiecte. De exemplu, după ce găsim și organizăm informațiile unei baze de date pentru vânzări de produse, lista preliminară poate conține elementele din imaginea de mai jos:

Entitățile principale care sunt afișate aici sunt produsele, furnizorii, clienții și comenzile. Așadar, ar fi logic să pornim cu aceste patru tabele: unul pentru date despre produse, unul pentru date despre furnizori și un al treilea pentru date despre comenzi. Deși lista inițial este incompletă, este un bun punct de pornire. Lista poate fi rafinată până când se ajunge la un proiect care funcționează bine.

Inițial, când suntem în fază preliminară, suntem tentați să stocam toate datele întru-n singur tabel, în locul la mai multe, care cer timp pentru creare, apoi va trebui să le facem relații, normalizare a acestora, însă dacă să analizăm imaginea de mai jos, în care se conține informație despre produse și furnizori într-un singur tabel, obținem multe dublări de date la rânduri:

În asemenea caz, fiecare rând conține informații despre produse, cât și despre furnizorul lui. Deoarece este posibilitatea ca multe produse să aibă același furnizor, numele și informațiile furnizorului se pot repeta de multe ori. Acest lucru utilizează irațional spațiul de pe disc. Dacă ar fi să înregistrăm informațiilor despre furnizor o singură dată, într-un tabel separat pe care să-l numim Furnizori, iar apoi legarea acelui tabel cu tabelul Produse, este o soluție cu mult mai bună.

Cea de-a doua problemă a acestui proiect poate apărea atunci când trebuie modificate informațiile despre furnizor. De exemplu, dacă presupunem că trebuie să schimbăm adresa unui furnizor. Deoarece apare în multe locuri aceasta, se poate, în mod absolut nedorit, să modifice adresa într-un loc, iar noi să uităm să o modificăm în celelalte. Înregistrarea adresei furnizorului într-un singur loc rezolvă problema.

Când proiectăm baza de date, trebuie să încercăm să înregistrăm fiecare informație o singură dată. Dacă se repetă aceeași informație, cum ar fi adresa unui anumit furnizor, în mai multe locuri putem încerca să amplasăm informația într-un tabel separat.

În final, dacă ar fi să presupunem că există un singur produs furnizat de Coho Winery și că dorim să-l ștergem, dar să păstrăm numele și informațiile furnizorului. Cum se poate efectua ștergerea înregistrării produsului fără a pierde informațiile despre furnizor, sau dacă în genere este imposibil. Răspunsul de fapt este acela că este imposibil, deoarece fiecare înregistrare conține date despre un produs, cât și despre un furnizor, astfel este imposibil să fie șterse separat. Pentru ca să reușim să păstrăm datele separate, trebuie să împărțim tabelul în două tabele: unul pentru informații despre produse și celălalt pentru informații despre furnizori. În asemenea caz, ștergerea înregistrării unui produs ar șterge doar datele despre produs, nu și datele despre furnizor.

Transformarea elementelor informaționale în coloane

Pentru a stabili coloanele dintr-un tabel, mai întâi de toate trebuie să ne decidem asupra informațiilor necesare pentru a înregistra subiectul în tabel. Fiecare înregistrare a tabelului va conține același set de coloane, așadar pot fi stocate informațiile din câmpurile Nume, Adresă, Oraș-CodPoștal, Abonat la mesaje de poștă electronică, Formulă introductivă și Adresă de poștă electronică pentru fiecare înregistrare în parte.

După ce este stabilit setul inițial de coloane pentru fiecare tabel, avem posibilitatea să îmbunătățim coloanele. De exemplu, este intuitiv să se stocheze numele clienților în două coloane: prenume și nume de familie, pentru a fi posibilă ulterioara sortare a acestora, căutarea și/sau indexarea pentru una singură dintre coloane. În același mod, adresa este alcătuită din cinci componente separate, adresă, oraș, județ, cod poștal și țară/regiune, și este logic să fie stocată și aceasta în coloane separate. Pentru a efectua căutarea, filtrarea sau sortarea după județ, de exemplu, informațiile despre județ trebuie să fie stocate într-o coloană separată.

De asemenea, trebuie să fim informați că dacă informațiile conținute în baza de date au/vor avea caracter intern sau și internațional. De exemplu, atunci când planificăm să stocăm adrese internaționale, este mai bine să avem o coloană Regiune în locul coloanei Județ, deoarece o astfel de coloană ar putea fi utilizată cu aceeași iscusință și de către străini, fără a le da acestora bătăi de cap suplimentare. Asemănător, codul poștal este mai bun decât codul Zip dacă stocați adrese internaționale.

Câteva sfaturi pentru stabilirea coloanelor:

Trebuie de stocat cele mai mici părți logice din informații.

Uneori poate fi tentant să creăm un singur câmp pentru nume complete, sau pentru id_facultate, împreună cu nume_facultate. Dacă se combină mai multe tipuri de informații într-un câmp, este dificil să le regăsim ulterior, atunci când avem nevoie de ele ca date individuale. Trebuie să despărțim informațiile în părți logice; de exemplu, creați câmpuri separate pentru prenume și pentru nume de familie, sau pentru id-ul facultății, și numele acesteia.

După îmbunătățirea coloanelor de date din fiecare tabel, se poate alege cheia primară a fiecărui tabel.

Specificarea cheilor primare

Fiecare tabel trebuie să includă o coloană sau un set de coloane care să identifice, în mod unic, fiecare rând stocat în tabel. În terminologia bazelor de date, acesta reprezintă cheia primară a tabelului. Access utilizează câmpuri de tipul cheie primară pentru a putea rapid asocia date din tabele multiple și a cumula datele.

După ce am identificat identificatorul care va fi cheia primară, care va fi unic pentru un tabel, (poate fi utilizat un număr de produs care identifică în mod unic fiecare produs din catalog), avem posibilitatea să utilizăm acest identificator ca și cheie primară a tabelului — dar numai după ce ne asigurăm că valorile din această coloană vor fi întotdeauna diferite pentru fiecare înregistrare, adică nu se vor repeta. Nu pot exista valori duplicate într-o cheie primară. Literatură de specialitate ne recomandă să nu utilizăm numele oamenilor pentru cheia primară, deoarece numele nu sunt unice, și probabilitatea ca acestea să se repete, mai ales din considerentul că baza de date va conține persoane din aceeași regiune geografică, este mare probabilitatea ca să existe doi oameni cu același nume în același tabel.

O cheie primară trebuie întotdeauna să aibă o valoare. Dacă există posibilitatea ca valoarea unei coloane să devină neatribuită sau necunoscută adică lipsită de valoare la un anumit moment, nu se poate utiliza ca și componentă într-o cheie primară, și, deci acest câmp cu siguranță nu-l vom declara cheie primară.

Trebuie întotdeauna să alegem o cheie primară a cărei valori nu se va schimba. Într-o bază de date care utilizează mai multe tabele, putem utiliza cheia primară a unui tabel care referință în alte tabele. Dacă schimbăm cheia primară, modificarea trebuie aplicată oriunde mai poate fi apelată această cheie. Utilizarea unei chei primară care nu se va modifica, adică va fi stabilă pe tot parcursul utilizării bazei curente de date, reducând șansele de a se desincroniza cheia primară cu tabelele care fac referință la ea.

În multe cazuri, se utilizează ca și cheie primară un număr unic ales arbitrar. De exemplu, i se poate atribui fiecărei comenzi un număr unic de comandă. Singurul scop al alocării unui număr de comandă este identificarea acesteia. O dată atribuit, nu se schimbă niciodată, rămânând stabil pe întreaga durată a utilizării prezentei baze de date.

Dacă lipsește o coloană, sau un set de coloane care ar putea fi utilizate ca și cheie primară, luăm în considerare utilizarea unei coloane care are tipul de date AutoNumerotare. Când utilizăm tipul de date AutoNumerotare, Access automat atribuie o valoare. Un astfel de identificator nu are date; nu conține informații care descriu rândul pe care îl reprezintă. Identificatorii fără date sunt cei mai potriviți pentru rolul de cheie primară, deoarece nu se modifică pe parcurs. Este mai mare probabilitatea ca o cheie primară care conține date despre un rând — cum ar fi un număr de telefon sau numele unui client — să se modifice, deoarece se poate modifica informația în sine.

O coloană setată la tipul de date AutoNumerotare este o cheie primară tocmai potrivită deoarece nu există două ID-uri identice pentru același produs.

În unele cazuri, este de preferabil să se utilizeze două sau mai multe câmpuri care împreună formează cheia primară a unui tabel. De exemplu, un tabel Detalii Comenzi care stochează elemente de linie pentru comenzi ar folosi două coloane în cheia sa primară : ID Comandă și ID Produs. Când o cheie primară utilizează mai mult de o coloană, aceasta mai este numită și cheie compusă.

În cazul unei bazei de date pentru vânzări de produse, se poate crea o coloană de tipul AutoNumerotare, care pentru fiecare dintre tabele ar îndeplini rolul de cheie primară: IDProdus pentru tabelul Produse, IDComandă pentru tabelul Comenzi, IDClient pentru tabelul Clienți și IDFurnizor pentru tabelul Furnizori.

3.1 Crearea relațiilor tabelelor

După ce am împărțit informațiile în tabele, este nevoie să facem o asociere utilă a informațiilor. De exemplu, următorul formular include informații din mai multe tabele.

Informațiile din acest formular provin din tabelul Clienți…

…tabelul Angajați…

…tabelul Comenzi…

…tabelul Produse…

…și tabelul Detalii Comandă.

Access reprezintă un sistem de gestionare a bazelor de date relaționale. Într-o bază de date relațională, informațiile se împart în tabele separate, bazate pe diferite subiecte. Pot utiliza relațiile dintre tabele pentru a asocia informațiile în modurile utile.

Crearea unei relații de tipul unul-la-mai-mulți

Luând în considerare acest exemplu: tabelele studenți și Facultăți din baza de date pentru automatizarea intrărilor, angajații bibliotecii pot crea oricând rapoarte care să prezinte situația reală legată de vizite per zi/luna/săptămână. Așadar, pentru orice persoană din exterior, din tabelul facultăți poate extrage numărul de studenți care își fac studiile aici, și din aceste date poate face anumite statistici mai generale legate de numărul total de studenți în instituția dată, precum și de frecvența vizitelor acestora din rapoarte. Relația dintre facultăți și tabelul studenți este, prin urmare, o relație de tipul unul-la-mai-mulți.

Pentru a reprezenta o relație de tipul unul-la-mai-mulți în proiectul bazei de date, luăm cheia primară din partea "unu" a relației și o adăugăm ca o coloană suplimentară la tabelul din partea "mai-mulți" a relației. În imaginea de mai sus, de exemplu, adăugăm coloana ID furnizor, din tabelul Furnizori, la tabelul Produse. Access poate utiliza numărul de ID al furnizorului în tabelul Produse pentru a găsi furnizorul potrivit pentru fiecare produs.

Coloana ID furnizor din tabelul produse este numită cheie externă. Cheia externă este cheia primară a altui tabel. Coloana ID furnizor din tabelul Produse este o cheie externă, deoarece ea este și cheia primară a tabelului Furnizori.

Furnizați baza pentru a uni tabelele legate prin stabilirea perechilor de chei: chei primare și chei externe. În cazul când nu se știe sigur care tabele ar trebui să partajeze o coloană comună, identificarea unei relații unu-la-mai-mulți va asigura necesitatea unei coloane partajate între cele două tabele implicate.

Crearea unei relații mai-mulți-la-mai-mulți

Luați în considerare relația dintre tabelul Produse și tabelul Comenzi.

O comandă poate include mai multe produse, dar pe de altă parte, un produs poate apărea în mai multe comenzi consecutiv. Din acest considerent, pentru fiecare înregistrare din tabelul Comenzi, pot exista mai multe înregistrări în tabelul sus-numit Produse. Și pentru fiecare înregistrare din tabelul Produse, la fel pot exista mai multe înregistrări în tabelul Comenzi. Această relație este de tipul mai-mulți-la-mai-mulți, din cauza că pentru orice produs pot exista mai multe comenzi; și pentru orice comandă pot exista mai multe produse. Trebuie însă sa reținem faptul că pentru a detecta relațiile de tipul mai-mulți-la-mai-mulți dintre tabele, este important să luăm în considerare ambele sensuri ale relației.

Subiectele celor două tabele — comenzi și produse — se află într-o relație mai-mulți-la-mai-mulți. Acest lucru reprezintă o problemă. Pentru a înțelege această problemă, imaginați-vă ce se întâmpla dacă încerci să creezi o relație între două tabele adăugând câmpul ID_produs la tabelul Comenzi. Pentru a avea mai mult de un produs pentru fiecare comandă, avem nevoie de mai mult de o înregistrare pentru fiecare comandă din tabelul Comenzi. S-ar repeta informațiile despre comandă pentru fiecare rând asociat cu o comandă, rezultatul fiind o proiectare ineficientă care poate produce date inexacte. Aceeași problemă apare dacă se adaugă câmpul ID comandă la tabelul Produse — apar mai multe înregistrări în tabelul Produse pentru fiecare produs. Cum se rezolvă această problemă?

Răspunsul pentru această problemă este crearea celui de-al treilea tabel, numit și tabel de joncțiune, care separă relația mai-mulți-la-mai-mulți în două relații unu-la-mai-mulți. Inserând cheia primară a fiecăruia dintre cele două tabele în cel de-al treilea tabel. Ca rezultat, al treilea tabel înregistrează aparițiile și instanțele relației.

Fiecare înregistrare care se află în tabelul Detalii comandă reprezintă un element linie într-o comandă. Cheia primară a acestui tabel constă în două câmpuri: cheile externe ale tabelelor Comenzi și Produse. Utilizarea câmpului IDComandă singular, nu funcționează ca o cheie primară pentru acest tabel, deoarece o comandă poate avea mai multe elemente linie, astfel că IDComandă se repetă pentru fiecare element linie dintr-o comandă, în așa mod, încât câmpul nu conține valori unice. Nici utilizarea câmpului IDProdus de unul singur nu funcționează, deoarece un produs poate apărea în mai multe comenzi diferite, dar, împreună, cele două câmpuri produc mereu o valoare unică pentru fiecare înregistrare unitară.

În baza de date pentru vânzări de produse, tabelele Comenzi și Produse nu sunt legate direct. În schimb, ele sunt asociate indirect prin tabelul Detalii comandă. Relația mai-mulți-la-mai-mulți între comenzi și produse se reprezintă în baza de date utilizând două relații unu-la-mai-mulți:

Între tabelele Comenzi și Detalii comandă există o relație unu-la-mai-mulți. Fiecare comandă are mai mult de un element line, dar fiecare element linie este conectat numai cu o singură comandă.

Între tabelele Produse și Detalii comandă este o relație unu-la-mai-mulți. Fiecare produs poate avea mai multe elemente linie asociate, dar fiecare element linie face referire la un singur produs. Din tabelul Detalii comandă, se pot determina toate produsele dintr-o anumită comandă. De asemenea, se pot determina toate comenzile pentru un anumit produs.

După ce incorporăm tabelul Detalii comandă, lista tabelelor și câmpurilor poate arăta cam așa:

Crearea unei relații de tipul unu-la-unu

Un alt tip de relație este relația unu-la-unu. De exemplu, fie ca vorbim despre faptul că avem nevoie să fie înregistrate câteva informații speciale despre produse suplimentare, de care vom avea nevoie rar sau care se aplică numai câtorva produse. Deoarece de aceste informații vom avea nevoie rar, iar stocarea informațiilor în tabelul Produse ar produce spații libere pentru fiecare produs la care acestea nu se aplică, le amplasăm într-un tabel separat. Ca și tabelul Produse, ID produs se utilizează cu rolul de cheie primară. Relația dintre acest tabel suplimentar și tabelul Produs este o relație de tipul unu-la-unu. Pentru fiecare înregistrare din tabelul Produs, există o singură înregistrare care se potrivește în tabelul suplimentar. Când întâlnim astfel de relații, ambele tabele trebuie să împartă un câmp comun.

Când observăm necesitatea unei relații unu-la-unu în baza de date, trebuie să ne gândim dacă se pot pune împreună informațiile din cele două tabele, într-un singur tabel. Dacă, dintr-un anumit motiv, nu dorim/nu este posibil să facem acest lucru, poate din considerentul că ar rezulta multe spații libere, lista următoare vă arată cum se reprezintă relația în proiectare:

Întrucât ambele tabele sunt bazate pe aceeași tematică, putem configura relația utilizând aceeași cheie primară în ambele tabele.

Dacă cele două tabele au subiecte diferite, și cu chei primare diferite, trebuie să alegem unul din tabele (oricare) și să inserăm cheia sa primară în celălalt tabel pe post de cheie externă.

Determinarea relațiilor dintre tabele ne ajută să ne asigurăm că avem tabelele și coloanele corecte. Când există o relație unu-la-unu sau unu-la-mai-mulți, tabelele implicate trebuie să partajeze o coloană sau mai multe. Când există o relație mai-mulți-la-mai-mulți, este necesar și binevenit un al treilea tabel pentru a reprezenta relația.

3.2 Rafinarea proiectării

Din momentul în care avem tabelele, câmpurile și relațiile de care avem nevoie, trebuie să creăm și să populăm tabelele cu date eșantion și să încercăm să lucrăm cu informațiile: creând interogări, adăugând înregistrări noi și așa mai departe. Acest lucru ajută la evidențierea problemelor potențiale — de exemplu, este posibil să avem nevoie să adăugăm o coloană pe care am uitat să o inserăm în timpul fazei de proiectare, sau este posibil să avem un tabel care să trebuiască separat în două tabele pentru a elimina duplicarea.

Vedem dacă se poate utiliza baza de date pentru a obține răspunsurile dorite. Creăm schițe neprelucrate ale formularelor și rapoartelor, și vedem dacă ne arată datele pe care le așteptăm. Căutăm dublurile inutile de date și, dacă le găsim, modificăm proiectarea pentru a le putea elimina.

Pe măsură ce testăm baza de date inițială, descoperim că se pot face îmbunătățiri. Mai jos prezint la nivel teoretic lucrurile care trebuie verificate pentru a fi siguri de buna-funcționare a bazei date:

Câteva lucruri care trebuie verificate:

Ați uitat vreo coloană? Dacă da, apar informațiile în tabelele existente? Dacă informațiile sunt despre altceva, este posibil să fie nevoie să creați un alt tabel. Creați o coloană pentru fiecare element informațional care trebuie urmărit. Dacă informațiile nu se poate calcula de pe o altă coloană, probabil aveți nevoie de o coloană nouă pentru asta.

Sunt inutile unele coloane, pentru că se pot calcula din câmpuri deja existente? Dacă un element informațional se poate calcula dintr-o altă coloana deja existentă — ca, de exemplu, prețul redus calculat din prețul de vânzare — este mai bine, în general, să se procedeze așa și să se evite crearea unei coloane noi.

Introduceți în mod repetat informații dublate în unul din tabele? Dacă da, probabil că trebuie împărțit tabelul în două tabele între care să existe o relație de tipul unu-la-mai-mulți.

Aveți tabele cu multe câmpuri, un număr limitat de înregistrări și multe câmpuri goale în înregistrările individuale? Dacă da, gândiți-vă la reproiectarea tabelului astfel încât să aibă mai puține câmpuri și mai multe înregistrări.

A fost împărțit fiecare element informațional în cele mai mici părți utile? Dacă trebuie efectuate operații de raportare, sortare, căutare sau calculare pentru un element informațional, puneți acel element în propria sa coloană.

Conține fiecare coloană date despre subiectul tabelului? Dacă o coloană nu conține informații despre subiectul tabelului, aceasta aparține unui alt tabel.

Sunt toate relațiile dintre tabele reprezentate prin câmpuri comune sau printr-un al treilea tabel? Relațiile unu-la-unu și unu-la-mai-mulți necesită coloane comune. Relațiile mai-mulți-la-mai-mulți necesită un al treilea tabel.

Rafinarea tabelului Produse

Presupunând că, după examinarea și reevaluarea proiectului bazei de date, am decis să stocăm o descriere a categoriei alături de numele acesteia. Dacă adăugăm un câmp Descriere categorie la tabelul Produse, trebuie să repetăm descrierea fiecărei categorii pentru fiecare dintre produsele care intră in acea categorie — iar aceasta nu este o soluție optimă pentru noi la momentul dat.

O soluție mai bună ar fi să categorizăm un subiect nou de urmărit pentru baza noastră, cu propriul tabel și propria cheie primară. Putem adăuga cheia primară de la tabelul Categorii la tabelul Produse, cu rol de cheie externă, care într-un fel să se repete.

Între tabelele Categorii și Produse există o relație unu-la-mai-mulți: o categorie poate include mai mult de un produs, dar un produs poate aparține numai unei categorii.

Când revizualizați structurile tabelului, căutați grupuri repetitive. De exemplu, luați în considerare un tabel care conține următoarele coloane:

ID produs

Nume

ID produs1

Nume1

ID produs2

Nume2

ID produs3

Nume3

În acest caz, fiecare produs este un grup repetitiv de coloane, care diferă numai prin adăugarea unui număr la sfârșitul numelui coloanei. Când vedeți coloanele numerotate astfel, ar trebui să reanalizați proiectarea.

Un astfel de proiect are mai multe defecte. Pentru început, vă obligă să stabiliți o limită superioară pentru numărul produselor. După ce se depășește această limită, trebuie adăugat un grup de coloane nou la structura tabelului, ceea ce reprezintă o activitate administrativă majoră.

O altă problemă este faptul că furnizorii care au mai puțin decât numărul maxim de produse vor irosi spațiu, din moment ce coloanele suplimentare vor fi goale. Cel mai serios defect al unui astfel de proiect este faptul că efectuarea multor activități, cum ar fi sortarea sau indexarea unui tabel după ID-urile sau numele produselor, devine dificilă.

Oricând vedeți un grup repetitiv, reanalizați cu atenție proiectarea, în ideea de a împărți tabelul în două. În exemplul de mai sus, este mai bine să utilizați două tabele, unul pentru furnizori și unul pentru produse, legate prin ID furnizor.

3.3 Aplicarea regulilor de normalizare

Regulile de normalizare, numite deseori și reguli de normalizare a datelor pot fi aplicate ca un pas din cadrul acestei proiectării. Acestea din urmă se utilizează pentru a verifica dacă tabelele sunt structurate corect. Procesul aplicării regulilor de normalizare a datelor la proiectarea bazei de date este numit normalizarea bazei de date, sau doar normalizare.

Normalizarea ne este foarte utilă dacă deja am determinat toate elementele informaționale și am creat un proiect preliminar. Scopul este să ne asigurăm că am împărțit elementele informaționale în tabelele corespunzătoare. Normalizarea nu ne poate ajuta să ne asigurăm că avem de la început toate elementele de date corecte, chiar dacă noua ne-ar fi plăcut aceasta.

Regulile sunt aplicate succesiv, asigurându-ne la fiecare pas că proiectul va ajunge la ceea ce se numește o "Formă Normală." În principiu, sunt acceptate cinci forme normale — de la prima formă normală până la a cincea. În această lucrare le descriu doar pe 3, primele trei, deoarece acestea sunt necesare și suficiente pentru majoritatea proiectelor de baze de date.

Prima formă normală

Prima formă normală ar însemna că există o singură valoare la fiecare intersecție dintre un rând și o coloană, și niciodată o listă de valori. De exemplu, nu poate exista un câmp care se numește Preț în care să plasați mai multe prețuri. Dacă privim intersecția dintre un rând și o coloană ca pe o celulă, atunci fiecare celulă poate conține doar o singură valoare.

A doua formă normală

A doua formă normală ar necesita ca fiecare coloană care nu este cheie să depindă în totalitate de cheia primară, și nu doar de o parte a cheii. Această regulă se aplică atunci când se utilizează o cheie primară care conține câteva coloane. De exemplu, dacă analizăm cazul când avem un tabel care conține trei coloane, dintre care ID comandă și ID produs se presupune că alcătuiesc cheia primară:

ID comandă (cheie primară)

ID produs (cheie primară)

Nume produs

Această proiectare încalcă a doua formă normală, deoarece Nume produs depinde de ID produs, dar nu și de ID comandă, așadar nu este dependent de întreaga cheie primară. Nume produs trebuie eliminat din tabel, el aparținând de un alt tabel (Produse).

A treia formă normală

A treia formă normală cere ca fiecare coloană care nu este cheie să depindă în totalitate de întreaga cheie primară, dar mai trebuie și ca toate coloanele care nu sunt chei să fie reciproc independente.

Dacă ar fi s-o formulăm în alt mod de a spune, ar fi că fiecare coloană care nu este cheie trebuie să depindă de cheia primară în întregime și numai de cheia primară. De exemplu mai jos avem un model de tabel, care conține următoarele coloanele ID produs (cheie primară)

Nume

PSV

Reducere

Dacă ar fi să presupunem că reducere depinde de prețul sugerat de vânzare. Acest tabel încalcă a treia formă normală, din cauza că există o coloană care nu este cheie, astfel că reducere, depinde de altă coloană care nu este cheie primară. Independența coloanelor înseamnă că se poate modifica orice coloană care nu este cheie fără a afecta a le afecta pe altele. Dacă se modifică o valoare din câmpul srp, se modifică în mod corespunzător reducere, așadar încălcându-se regula. În acest caz, reducere trebuie mutat în alt tabel pentru care prv este cheie.

Concluzii și recomandări

Crearea unei astfel de Baze de Date era deja de ceva timp o necesitate pentru Departamentul Informațional Biblioteconomic ULIM, fapt care a ajutat ca această idee să fie primită din start, și aplicarea ei să simplifice crearea rapoartelor referitor la vizite/intrări.

Scopul unei astfel baze de date pentru bilbioteca unei instituți de învățămînt, în general, este automatizarea proceselor și a activității instituției, creșterea și analiza eficienței, înregistrarea și securizarea volumelor mari de informații. O bază de date în cadrul bibliotecii unei instituții de învățămînt poate fi folosită de angajații bibliotecii, precum și de persoanele din conducere pentru a putea verifica autenticitatea rapoartelor prezentate de către angajați. Anumite informații din baza date a bibliotecii instituției de învățămînt este folosită de către instituții superioare(Casa Națională a Cărții – CNC, Asociația Bibliotecarilor din Republica Moldova – ABRM) pentru anumite servicii oferite, baza de date poate fi folosită ca un suport pentru crearea unui site, unde studenții ar putea solicita anumite servicii online, sau să poată rezerva anumite cărți din fond.

Alt scop ar fi păstrarea informațiilor prin intermediul unor mijloace tehnice, contemporane, sigure și monitorizarea accesului la informațiile păstrate. Pentru persoanele din conducere ar fi utilă pentru analiza rezultatelor oferite de angajați, pentru actualizarea listelor de utilizatori, Pentru profesori, un scop unei baze de date poate fi folosirea bazei de date pentru a afla câți dintre studenții lui întradevăr au vizitat biblioteca.Elevii sau studenții ar putea să o folosească mai des pentru aflarea materialelor solicitate de ceilalți colegi ai lor, în cazul când nuștiu sigur de ce liteatură au nevoie, sau e vorba despre o temă mai complexă, care ar cerceta o analiză mai amănunțită a fondului bibliotecii.

Bibliografie

Marquis, Anette. Windows 95 – Ghidul dumneavoastră pentru Access, traducere de Călin Suciu, București: Editura All, 1998, 233 p.

Fotache, Marin. Database Designers and Normalization. București, 2005. – 224 p.

Fotache, Marin. Proiectarea bazelor de date: Normalizare și postnormalizare. – Iași:Polirom, 2005. – 348 p. ISBN 973-681-898-5

Microsoft Access 2000 – manualul începătorului. – București: Editura Teora, 2001

Microsoft Access 2003 – Programare fulger. – București: Editura Teora, 2003

Țâmbulea, Leon. Ms Access pentru programatori. – Cluj-Napoca: ProMedia Plus, 1997. – 196 p.

Popov Lilia. Tehnologii informaționale, Sistemul de operare Microsoft Windows. Indicații metodice cu privire la aplicații și însărcinări practice: – Bălți, 2013. – 208 p. ISBN 978-9975-50-096-8

Velicanu, Manole. Sisteme de gestiune a bazelor de date prin exemple. – Bucurelti: Editura ASE, 2013. – 186 p. ISBN 978-606-674-9

Bragaru, T. Dezvoltarea sistemelor informatice: suport de curs. – Chișinău: CEP USM, 2005. – 427 p. ISBN 9975-70-467-0

http://www.referatexp.com/limba-romana/cartea-%E2%80%93-importanta-si-semnificatia-in-viata-omului/

http://brainly.ro/tema/49181

Anexe