Modul de Proiectare Si Implementare a Unei Baze de Date

2015

Cuprins

Introducere

Capitolul 1 – Concepte generale

1.1 Tipuri de baze de date

1.1.1 Baze de Date Ierarhice

1.1.2 Baze de Date Rețea

1.1.3. Baze de Date Relaționale

1.1.4. Baze de Date Orientate pe Obiecte

1.2. Arhitectura bazei de date

1.3 Etapele realizării unei baze de date

Capitolul 2 – SGBD (Acces)

2.1 Arhitectura aplicațiilor Microsoft Access

2.2 Microsoft Access – Tabele

2.2.1 Crearea tabelelor

2.2.2 Design View

2.2.3 Datasheet View

2.2.4 Table Wizard

2.2.5 Salvarea tabelelor

2.3. Operații asupra înregistrărilor dintr-o tabelă

2.3.1. Adăugarea înregistrărilor

2.3.2. Ștergerea de înregistrări

2.3.3. Căutarea unei înregistrări se realizează în acces secvențial sau în acces direct

2.3.4. Modificarea înregistrărilor

2.3.5. Ordonarea înregistrărilor

2.3.6. Înghețarea afișării câmpurilor

2.4. Definirea relațiilor între tabele

Capitolul 3. – Aplicație Practică

3.1 Prezentarea problemei

3.2 Analiza problemei

3.4. Proiectarea schemei conceptuale

3.5. Proiectarea schemei externe

3.6. Proiectarea schemei externe

3.7. Proiectarea aplicației

Concluzii

Bibliografie

Introducere

Evidența cu ajutorul calculatorului reprezintă o activitate care se regăsește în multe domenii de activitate cum sunt: evidența populației, evidența elevilor și studenților, evidența mărfurilor într-un depozit, evidenta cărților intr-o bibliotecă etc.

Când vorbim de evidența cu ajutorul calculatorului atunci automat trebuie să vorbim de baze de date.

Lucrarea de fața prezintă modul de proiectare și implementare a unei baze de date destinate realizării evidenței automate a elevilor într-o școală.

Conceptul de bază de date se referă la stocarea volumelor mari de date pe suport de memorie de capacitate corespunzătoare. Pentru a realiza stocarea și prelucrarea acestor volume de date s-au dezvoltat tehnici și metode specifice domeniului.

Primele baze de date erau dezvoltate pe sisteme de calcul de tip mainframe și erau manipulate de oameni special pregătiți pentru a gestiona aceste sisteme.

O dată cu dezvoltarea sistemelor personale (PC), au apărut și primele aplicații de baze de date care foloseau un singur fișier pentru a stoca toată informația din baza de date (denumite baze de date „flat file"). Ele erau de tip Xbase, un limbaj care s-a răspândit foarte repede fiind folosit în special la manipularea datelor. Sistemele care l-au folosit au fost dBase, FoxBase, FoxPro. Aceste versiuni rulau sub sistemul MS-DOS și împărtășeau limitările acestuia. Cea mai răspândită aplicație care folosește limbajul xBase a fost FoxPro, sistem dezvoltat inițial de firma Fox Software sub numele de Foxbase.

Chiar și în zilele noastre există firme care stochează date extrem de importante în baze de date FoxPro, iar cel mai cunoscut exemplu este cel al organizației care gestionează Euro Tunel.

La începutul anilor 90, firma Microsoft Corporation a lansat aplicația Access, aplicație care se bazează în mare parte pe logica de stocare a sistemului FoxPro, sistem care fusese achiziționat de firmă în 1989. Aplicația Access a devenit, în scurt timp, cea mai folosită aplicație de gestiune a bazelor de date „flat file" de pe sistemele personale. Ajuns acum la versiunea 2003 SGBD-ul MS-Access s-a schimbat fiind scalabil către baze de date Microsoft SQL Server. Totodată, începând cu versiunea 7 i s-a adăugat un limbaj de programare dedicat (Visual Basic for Applications – VBA), bazat pe limbajul de programare Visual Basic. Prin intermediul acestuia se puteau manipula datele mai ușor, se puteau folosi automatisme pentru diverse interogări, afișări etc. Începând cu versiunea 9, limbajul integrat este compatibil cu Visual Basic și cu limbajul folosit de MS SQL Server. Versiunea 2003 poate genera programe executabile (fișiere *.exe) astfel încât nu mai este nevoie de prezența acestuia pe mașina pe care rulează o aplicație specifică MS-Access. Acest mod de lucru amintește de posibilitatea de a genera executabile adăugată SGBD-ului FoxPro chiar de la versiunile sub MS-DOS.

În privința sistemelor server, piața s-a dezvoltat uimitor de repede deoarece s-a constatat cât de folositoare sunt sistemele dedicate acestui lucru. Oracle a lansat și și-a dezvoltat baza de aplicații server, astăzi ajungând la versiunea 9. Începând cu versiunea 8i, au fost introduse extensii orientate pe obiecte. Lansată cu ocazia Oracle OpenWorld, Oracle 9i reprezintă cea mai completă infrastructura pregătită pentru rularea aplicațiilor Internet. Oracle 9i include Oracle 9i Database și Oracle 9i Application Server si pachetul de unelte de dezvoltare Oracle 9i Developer Suite.

În ceea ce privește corporația Microsoft, aceasta a lansat tot în anul 2000 serverul de baze de date SQL Server 2000. Aplicația se dorește a fi un concurent direct pentru aplicațiile Oracle, iar pentru acest fapt i s-a adăugat suport 100% pentru limbajul XML prin intermediul căruia se poate interoga direct serverul dintr-un browser (dacă serverul a fost configurat să suporte această facilitate).

Tot în 2000, compania IBM a lansat varianta 7 a aplicației DB2. Aceasta aplicație, ca și Oracle, este implementata pe mai multe platforme (inclusiv Linux), fiind o aplicație pur obiectuală.

Pe sistemele Linux, cel mai folosit server de baze de date este MySQL. Cu toate că există un alt produs gratuit (MySQL este gratuit atât timp cât aplicația dezvoltata nu este revânduta) – PostgreSQL, MySQL rămâne preferatul programatorilor de Linux. De ce? Pentru că limbajul cel mai folosit pe partea de server web – PHP – dispune de o extensie MySQL înglobată. Dar nu numai acest lucru a influențat folosirea MySQL. Una dintre alegeri a fost și datorită ușurinței administrării acestui server, el dispunând de un client de accesare inclus.

Există sute de modalități de depozitare a datelor în baza de date. Cele mai utile aplicații de computer stochează date, dar adesea ele o fac în moduri proprii, specifice.

În tot mai mare măsură, oamenii de afaceri își dau seama că o mulțime de informații importante rămân neutilizate sau neintegrate, fiindcă nu sunt într-un format „adecvat”. Companiile se instalează pe Internet și se interesează de reacțiile la produsele lor. Tot mai mult, acele reacții vin sub formă de e-mail-uri. Foarte puține companii pot face uz pe scară largă de informația din acele e-mail-uri, le pot sorta, căuta sau exploata de o manieră organizată. Și mai puține companii încă pot utiliza eficient datele pe bază de HTML, cum ar fi cataloagele Web ale competitorilor lor.

Capitolul 1 – Concepte generale

Conceptul de bază de date a apărut în anul 1969, la prezentarea primului raport CODASYL. Ideea de bază în organizarea datelor se întemeia pe existența unui fișier de descriere globală a datelor prin care se realiza independența programelor față de date și a datelor față de programe.

Prin intermediul acestui fișier se realiza accesul utilizatorilor. Acest fișier de date conținea colecțiile de date și legăturile dintre ele. Ulterior, acest concept a fost preluat și dezvoltat pentru bazele de date rețea, apoi relaționale și orientate pe obiect.

O bază de date poate fi definită de una sau mai multe colecții de date (Ki) aflate în interdependență, împreună cu descrierea datelor și a relațiilor dintre ele, (B=(K1, K2, … )). O bază de date trebuie să îndeplinească următoarele condiții:

să asigure o independență sporită a datelor față de programe și invers;

concepția structurii bazei de date trebuie făcută astfel încât să se asigure informațiile necesare și suficiente pentru necesitățile de informare și decizie;

să asigure o redundanță minimă și controlată a datelor;

să permită un acces rapid la informațiile stocate în baza de date. (1)

1.1 Tipuri de baze de date

Din punctul de vedere al criteriilor luate în considerare, bazele de date se împart:

după orientare:

generalizate;

specializate;

după modelul de date:

ierarhice;

rețea;

relaționale;

orientate pe obiect;

după amploarea geografică:

locale;

distribuite;

după limbajele utilizate:

autonome (dispun de limbaje proprii);

cu limbaj gazdă;

mixte;

Cele mai cunoscute tipuri de baze de date sunt cele împărțite după criteriul modelului de date, pe care le voi detalia în cele ce urmează: (2)

1.1.1 Baze de Date Ierarhice

Bazele de date ierarhice se caracterizează prin faptul că elementele componente au relații de subordonare de tip unu la mulți, astfel încât fiecare entitate are în subordine una sau mai multe entități și este subordonată, la rândul ei, unei singure entități superioare, conform modelului ierarhic de organizare a datelor. În acest model de organizare a bazelor de date :

entitățile (câmpurile și înregistrările) sunt structurate sub formă de noduri;

nodurile conectează ramurile unui arbore descendent; un nod de pe nivelul inferior este subordonat unui singur nod din nivelul ierarhic imediat superior, dar poate fi în relație cu n noduri aflate la nivelul inferior; altfel spus: fiecare entitate are un nod părinte și mai multe noduri copil;

Observații.

dacă se șterge un nod părinte, se șterg toate nodurile copil subordonate;

un nod copil poate fi adăugat numi dacă au fost adăugate mai întâi nodurile părinte;

între nodurile copii nu pot fi stabilite relații.

Exemplu: Considerăm o bază de date pentru sistemul de rezervări a unei companii aeriene. Nodul părinte = București. Acest nod are patru copii: Cluj, Constanța, Iași, Timișoara. Timișoara are doi copii: 210 și 211. Zborul 210 are trei copii: pasagerii. (2)

Fig. 1.1. Baza de date ierarhică

1.1.2 Baze de Date Rețea

Acest model este similar cu modelul de tip ierarhic cu deosebirea:

că un nod copil poate să aibă mai multe noduri părinți;

între nodurile părinte și nodurile copil se adaugă conexiuni adiționale (unui nod i se poate adăuga o cale nouă și pot fi trasate ramuri noi);

în această organizare fiecare entitate poate avea un număr nelimitat de conexiuni. (1)

Exemplu: Baza de date a produselor care s execută într-o fabrică. Fiecare produs este format din mai multe ansambluri, iar fiecare ansamblu este format din mai multe piese. Fiecare piesă poate intra în componența mai multor produse. (5)

Fig. 1.2. Baza de date rețea

1.1.3. Baze de Date Relaționale

Modelul relațional asociază unei entități o tabelă bidimensională numită relație.

Baza de Date Relațională este o colecție de tabele (sau fișiere de date) numite relații sau structuri, legate între ele prin câmpuri comune numite câmpuri cheie.

În tabelă, coloanele reprezintă atributele entității iar liniile (rândurile) tabelei reprezintă membrii entității.

Fiecare coloană are un nume distinct, prima linie fiind destinată amplasării acestor nume de atribute. O linie dintr-o relație se numește tuplu. Numărul de tupluri dintr-o relație reprezintă cardinalitatea relației.

Numărul de atribute (n în figura 1.3) se numește gradul relației. La nivelul organizării fizice există următoarele corespondențe:

o relație poate fi asociată unui fișier,

un tuplu se asociază cu o înregistrare,

coloană corespunde unui câmp din înregistrare. (2)

Fig. 1.3. Elementele unei relații

Privită prin prisma modelului relațional, baza de date apare ca o colecție de relații (tabele), în care fiecare coloană reprezintă un atribut distinct, iar fiecare rând, un tuplu distinct, de unde și apelativul tabelă bidimensională. (2)

Cheia este un câmp (atribut) sau un ansamblu de câmpuri (atribute) care au rolul de a identifica un tuplu dintr-o tabelă.

Tipuri de chei:

primare / alternate,

simple / comune,

externe.

Tuplurile unei relații se pot identifica în mod unic prin intermediul valorilor unuia sau mai multor câmpuri (eventual toate câmpurile), care joacă rol de cheie primară a relației respective.

Se numește domeniu primar un domeniu pe care este definit un singur atribut drept cheie primară. Dându-se două relații R1 și R2 cu atributele A1 și A2 chei primare definite pe același domeniu primar D, spunem că A1 este cheie externă, dacă, utilizând o parte din valorile sau toate, fizice există următoarele corespondențe:

o relație poate fi asociată unui fișier,

un tuplu se asociază cu o înregistrare,

coloană corespunde unui câmp din înregistrare. (2)

Fig. 1.3. Elementele unei relații

Privită prin prisma modelului relațional, baza de date apare ca o colecție de relații (tabele), în care fiecare coloană reprezintă un atribut distinct, iar fiecare rând, un tuplu distinct, de unde și apelativul tabelă bidimensională. (2)

Cheia este un câmp (atribut) sau un ansamblu de câmpuri (atribute) care au rolul de a identifica un tuplu dintr-o tabelă.

Tipuri de chei:

primare / alternate,

simple / comune,

externe.

Tuplurile unei relații se pot identifica în mod unic prin intermediul valorilor unuia sau mai multor câmpuri (eventual toate câmpurile), care joacă rol de cheie primară a relației respective.

Se numește domeniu primar un domeniu pe care este definit un singur atribut drept cheie primară. Dându-se două relații R1 și R2 cu atributele A1 și A2 chei primare definite pe același domeniu primar D, spunem că A1 este cheie externă, dacă, utilizând o parte din valorile sau toate, putem regăsi tuplurile relației R2.

Altfel spus, un atribut al unei relații este cheie externă, dacă se regăsește pe post de cheie primară într-o altă relație.

Nici un câmp (atribut) care participă la formarea cheii nu poate avea valori nule. (2)

Exemplu:

O bază de date ce conține 4 tabele. Câmpurile tabelelor sunt:

– elevi : id_e, nume_e, pren_e, adresa_e;

– note : id_n, id_e, id_d, nota1, nota2, nota3;

– disciplină :id_d, id_p, dendisciplină;

– profesori : d_p, nume_p, pren_p, adresa_p; (5)

Fig. 1.4 Exemplul – Relații

1.1.4. Baze de Date Orientate pe Obiecte

Bazele de date orientate pe obiecte, numite și baze de date obiectuale, sunt construite pe modele de date complexe, structurate pe obiect. Conceptul de obiect definește o entitate informațională atât ca structură cât și ca funcții (comportament).

Bazele de date orientate pe obiect reprezintă o abordare mai eficientă față de cele menționate, dar nu le substituie total. Superioritatea acestora poate fi rezumată în următoarele:

se construiesc o singură dată și pot fi utilizate de nenumărate ori, ceea ce asigură crearea rapidă de aplicații complexe;

modificările intervenite pe parcurs nu afectează toată logica aplicației, ci doar obiectele respective, asigurând o flexibilizate sporită a întregului sistem. (1)

1.2. Arhitectura bazei de date

Arhitectura unei baze de date cuprinde :

baza de date propriu-zisă – se memorează colecțiile de date;

Sistemul de Gestiune a Bazei de Date (SGBD) – ansamblu de programe care realizează gestiunea și prelucrarea complexă a bazei de date;

un set de proceduri manuale și automate;

un dicționar al bazei de date – informații despre date, structura acestora, elementele de descriere a semanticii, elemente de statistică, documentații, etc.;

mijloace hard utilizate;

personal implicat.

Complexitatea problemelor care apar în activitatea unei unități economice implică prelucrarea operativă a datelor și obținerea de rezultate (informații) care sunt suportul deciziei managerilor.

Volumul acestor date este în continuă creștere, ceea ce determină necesitatea organizării și memorării lor pe suporturi tehnice adresabile, organizare care poate fi făcută în fișiere sau în baze de date.

Fișierele reprezintă colecții de date omogene din punct de vedere al conținutului, colecții care reprezintă înregistrări fizice. O înregistrare fizică poate conține una sau mai multe înregistrări logice. Înregistrarea logică este definitivă ca o unitate de prelucrare din punct de vedere al programului utilizator. Organizarea datelor în fișiere și accesul la ele sunt asigurate de un set de programe dedicate care sunt reunite sub denumirea de Sistem de Gestiune a Fișierelor (SGF), componenta a Sistemului de Operare (SO).

Conceptul de bază de date pornește de la ideea că există un fișier de descriere globală a datelor, prin care se realizează independența programelor față de date și acestora față de programe. Astfel, putem spune ce o bază de date este o colecție de date aflate în interdependență, împreună cu descrierea datelor și a relațiilor dintre ele.

Acest ansamblu structurat de date conține structuri de date legate funcțional între ele. Datele organizate în astfel de colecții trebuie să fie interogabile prin conținut după orice fel de criterii si trebuie să ofere posibilitatea regăsirii structurii datelor. (3)

Descrierea unei baze de date presupune:

determinarea structurilor de date;

legăturile dintre aceste structuri;

regulile care să asigure coerența datelor, reguli care se mai numesc și reguli de integritate. (2)

1.3 Etapele realizării unei baze de date

În proiectarea unei baze de date sunt prevăzute mai multe etape:

analiza sistemului sau a domeniului economic și a cerințelor informaționale asociate, pentru care se realizează baza de date;

proiectarea structurii bazei de date, adică elaborarea schemei conceptuale externe și a schemei conceptuale interne;

încărcarea datelor în baza de date;

exploatarea și întreținerea bazei de date. (3)

Analiza sistemului economic presupune patru etape:

analiza componentelor sistemului și a legăturilor dintre acestea, sau analiza structurală în urma căreia rezultă modelul structural sau static al sistemului;

analiza stărilor sistemului și a tranzițiilor posibile între aceste stări, în raport cu anumite evenimente. În urma acestei analize rezultă modelul dinamic sau temporal;

analiza transferurilor informaționale (a tranzacțiilor), în urma căreia se obține modelul funcțional al modelului economic;

integrarea modelelor sistemului economic (structural, dinamic și funcțional), în scopul corelării și completării lor. (2)

Tehnica diagramelor entitate-asociere

Analiza sistemului economic are ca obiectiv evidențierea componentelor din cadrul sistemului pentru care urmează să se colecteze și să se memoreze informații în baza de date, precum și evidențierea legăturilor dintre aceste componente.

Tehnica diagramelor entitate-asociere permite construirea modelului structural sub forma unei diagrame entitate-asociere, prin parcurgerea următorilor pași:

Identificarea componentelor (entităților) din cadrul sistemului economic. Fiecare entitate prezintă mai multe realizări. În urma acestei etape se elaborează o primă formă a diagramei entitate-asociere.

Identificarea asocierilor dintre entități și codificarea acestora. Legăturile dintre entități sunt reprezentate prin arce neorientate, care fac legătura între nodurile ce reprezintă entitățile participante la asociere.

Fig.1.5. Diagramă entitate-asociere

Tipul sau forma legăturii se exprimă cu ajutorul cardinalității. Cardinalitatea asocierilor exprimă numărul minim și numărul maxim de realizări (instanțe) de entitate, care pot fi asociate cu o realizare a partenerului de asociere. Cardinalitatea se exprimă prin perechi de numere, câte o pereche pentru fiecare entitate din cadrul legăturii.

Identificarea atributelor aferente entităților și asocierile dintre entitați.

Stabilirea atributelor de identificare a entităților.

Tipuri de legături între entități

După cardinalitatea asocierii. În acest caz, se are în vedere gradul asocierii și obligativitatea participării entităților la asociere.

După gradul asocierii (maximele cardinalității), identificăm următoarele tipuri de asocieri (legături):

asociere de tip „unu la unu”

asocieri de tip „unu la mulți”

asocieri de tip „mulți la mulți”

După obligativitatea participării entităților la asociere (minimele cardinalității), există:

asocieri parțiale

asocieri totale

Concomitent, după gradul asocierii și după obligativitatea participării la asociere, sunt:

asocieri parțiale de tip „unu la unu”

asocieri totale de tip „unu la unu”

asocieri parțiale de tip „unu la mulți”

asocieri totale de tip „unu la mulți”

asocieri parțiale de tip „mulți la mulți”

asocieri totale de tip „mulți la mulți”

După numărul de entități distincte care participă la asociere:

asocieri binare (între două entități distincte)

asocieri recursive (asocieri ale entităților cu ele însele)

asocieri complexe (între mai mult de două entități distincte)

Asocierile parțiale sunt acele asocieri care nu obligă participarea la asociere a tuturor entităților vizate, ci numai a unora dintre ele sau a nici uneia. Această obligativitate este reflectată de minimele cardinalității. Valoarea zero a uneia dintre minime arată lipsa de obligativitatea participării partenerului la această asociere, în timp ce o valoare mai mare decât zero exprimă obligativitatea participării la asociere. (1)

Tipuri de atribute

Atributele exprimă caracteristici ale componentelor domeniului economic analizat sau ale asocierilor dintre aceste componente.

De obicei, atributele sunt asociate entităților, dar ele pot descrie și asocierile dintre acestea.

Atributele pot fi clasificate astfel:

Atribut compus sau bloc, constituit din cel puțin alte două atribute. Valoarea sa este reprezentată de valorile atributelor componente;

Atribut calculat sau dedus. Valoarea sa nu este cunoscută direct, ci calculată pe baza valorilor altor atribute;

Atributul simplu este acel atribut care are valori atomice;

Atributul repetitiv sau multivaloare. Este un atribut care la un moment dat are mai multe valori ce apar sub forma unor liste de valori.

Un atribut de identificare se numește cheie dacă se caracterizează prin unicitatea valorii sale pentru fiecare instanță a entității. (1)

Capitolul 2 – SGBD (Acces)

Pentru crearea unei baze de date, pentru actualizarea conținutului acesteia, pentru consultarea și prelucrarea datelor stocate aici este utilizat un sistem specializat de programe cunoscut sub denumirea de Sistem de Gestiune a Bazelor de Date (SGBD).

SGBD reprezintă ansamblul de programe care asigură interfața între baza de date și utilizatorii acesteia.

Un SGBD trebuie să asigure următoarele funcții elementare:

definirea bazei de date;

încărcarea bazei de date;

introducerea datelor în baza de date;

accesul la date (interogare, actualizare);

modificarea unor date existente în baza de date;

ștergerea unor date;

extragerea informațiilor stocate în baza de date;

protejarea datelor; etc

Cele mai importante caracteristici ale SGBD-ului Access sunt:

este un sistem de gestiune a bazelor de date relațional;

posibilitatea creării unei baze de date care să poată fi utilizată de către un utilizator sau mai mulți utilizatori în mod partajat;

creează o bază de date care poate fi utilizată în mod exclusiv sau în mod multiutilizator;

permite interogarea bazei de date fie în mod grafic, utilizând interfața QBE (Query By Example), fie utilizând limbajul SQL (Structured Query Language);

permite automatizarea unor activități/acțiuni prin programare în limbajul VBA (Visual Basic for Applications) sau apelând la generatorul de macrocomenzi;

realizarea importului/exportului de date către alte aplicații ale pachetului Microsoft Office sau ale SGBD relaționale (FoxPro, xBase, Paradox, etc.) ;

permite accesul la baze de date din rețeaua Internet, fiind un instrument util pentru publicarea informațiilor în paginile Web;

permite utilizarea obiectelor ACCESS din cadrul altor aplicații rulate sub sistemul de operare Windows;

permite crearea de grupuri de obiecte definite de utilizator în cadrul bazei de date. (4)

2.1 Arhitectura aplicațiilor Microsoft Access

O bază de date ACCESS poate fi definită ca o colecție de obiecte: tabele (table), cereri de interogare (query), formulare (form), rapoarte (report), pagini Web (pages),comenzi macro (macro) și module (module).

Fig. 2.1. Aplicația Microsoft Access

Subliniez diferența majoră care există între Microsoft Access și alte sisteme de gestiune a bazelor de date. Astfel, în Visual FoxPro, prin baze de date (database) se înțeleg doar acele fișiere în care sunt stocate datele.

– Tabele (Table) este un obiect definit de utilizator în care sunt stocate datele (expresia modelului relațional).

– Formularul (Form) este un obiect care permite introducerea datelor, afișarea acestora sau controlul întregii aplicații.

– Interogarea (Query) este un obiect care permite vizualizarea informațiilor obținute prin prelucrarea datelor din una sau mai multe tabele (permit extragerea din baza de date a acelor date de care utilizatorul are nevoie).

– Raportul (Report) este un obiect care permite formatarea și tipărirea informațiilor obținute în urma consultării bazei de date sub formă de documente.

– Pagina Web de accesare a datelor (Pages) reprezintă un obiect care include un fișier HTML și alte fișiere suport în vederea furnizării accesului la date prin intermediul browser-elor Internet.

– Comanda Macro (Macro) reprezintă un obiect care conține o definiție structurată a uneia sau mai multor acțiuni pe care Access le realizează ca răspuns la un anumit eveniment.

– Modulul (Module) reprezintă un obiect care conține proceduri definite de utilizator și scrise în limbajul de programare Visual Basic.

În figura 2.2. de mai jos sunt prezentate legăturile ce există între diferitele obiecte ce compun o aplicație realizată în Access. Astfel, în cadrul tabelelor sunt stocate datele introduse inițial de utilizator sau extrase cu ajutorul cererilor de interogare și sunt afișate sub formă de rapoarte sau sunt modificate cu ajutorul formularelor sau paginilor Web de accesare a datelor. Cererile de interogare pot folosi funcții Visual Basic în vederea realizării unor calcule definite de utilizator.

Fig. 2.2. Legături între obiectele Microsoft Acces

2.2 Microsoft Access – Tabele

Datele ce fac obiectul prelucrării (datele de intrare) vor fi memorate într-o bază de date; elementele fundamentale ce creează o bază de date relațională sunt tabelele. Este esențial ca fiecare tabel al bazei de date să conțină informații specifice unui singur tip de obiecte.

Un tabel reprezintă o colecție de date legate între ele, memorată pe linii și coloane; fiecare linie conține o înregistrare (entitate completă de date referitoare la un anumit tip de obiecte). La rândul ei, fiecare înregistrare este compusă din coloane sau câmpuri (un câmp reprezentând cea mai mică entitate de date).

Într-un tabel se stochează atât descrierea structurii tabelei cât și înregistrările de date. (4)

La lansarea aplicației Access se afișează fereastra de bază Access :

Fig. 2.3. Microsoft Access – Fereastra principală

2.2.1 Crearea tabelelor

Gestiunea tabelelor (creare, modificare, vizualizare, ștergere) unei baze de date Access se poate realiza din secțiunea Tables a ferestrei bazei de date (Database Window) figura 2.2.. În această secțiune se găsesc controale specifice care permit crearea, modificarea sad vizualizarea structurii unui tabel.

Fig. 2.4. Database Window

Există mai multe modalități de creare a tabelelor puse la dispoziție de către Access:

alegând comanda Table din meniul Insert;

prin acționarea butonului de comandă New din fereastra Database Window;

folosind hiperlink-urile salvate în fereastra bazei de date (Create table in Design View, Create table by using wizard, Create table by entering data);

importând dintr-o bază de date (Import Table);

legând de alte tabele aparținând altor baze de date (Link Table). (4)

2.2.2 Design View

Design View este echivalentă cu acționarea hyperlink-ului Create table in Design View. Utilizatorul stabilește absolut toți parametrii necesari pentru descrierea structurii unui tabel: numele câmpurilor, tipurile de date ale acestora; reguli de validare, etc..

Fereastra Access de descriere a tabelei (figura 2.3) este formată din două zone:

zona A în care se definesc câmpurile din structura tabelei

zona B în care sunt precizate proprietățile acestora. (4)

Fig. 2.5. Design View

Descrierea câmpurilor

Numele câmpului (Field Name) – trebuie să respecte următoarele reguli:

poate să conțină litere (majuscule sau minuscule), cifre și caractere speciale;

poate să conțină maximum 64 de caractere;

este interzisă utilizarea caracterelor: punct (.), semnul exclamării (!), parantezele drepte ([]);

numele câmpului nu poate să înceapă cu un spațiu.

Tipul de date al câmpului (Data Type); utilizatorul are la dispoziție zece tipuri de date de bază (tabelul 2.1.), pentru unele dintre ele fiind disponibile subtipuri de date, în funcție de necesități; subtipurile se configurează în zona de jos a ferestrei (secțiunea General).

Comentarii (Description) – proprietate opțională, unde utilizatorul poate introduce sub formă de șiruri de caractere diverse informații cu privire la câmp. (4)

Tipurile și subtipurile de date

Tipurile și subtipurile de date Access sunt prezentate în tabelul 2.1..

Tabelul 2.1. Tipuri de date

Field Properties

În zona B (General și Lookup) se pot stabili valori pentru două categorii de proprietăți:

– proprietăți pe care le au toate câmpurile;

– proprietăți specifice anumitor câmpuri, în funcție de tipul de date.

Proprietăți din categoria General:

Field Size – stabilește dimensiunea maximă admisă pentru tipurile de date Number, AutoNumber, Text; pentru primele două, valorile sunt precizate în tabelul 2.1, iar pentru tipul Text o valoare între 0 și 255;

Decimal places – stabilește numărul de zecimale utilizat pentru afișarea unui număr; valorile posibile sunt Auto (numărul este afișat cu atâtea zecimale cu cât a fost calculat; nu sunt afișate mai mult de 15 zecimale) sau un număr între 0 și 15.

Format – stabilește formatul de afișare a unui câmp; aceste formate se pot defini de utilizator cu ajutorul unor secvențe speciale sau, pentru unele tipuri de date, există deja predefinite formate uzuale. Formatul dorit se selectează din lista oferită în urma activării butonului de control. Pentru datele de tip numeric, de exemplu, se poate opta între următoarele formate de afișare: General, Number, Currency, Euro, Fixed, Standard, Percent, Scientific; (fig. 2.4.)

Pe lângă aceste formate predefinite se mai pot utiliza anumite combinații speciale de caractere. Caracterele ce se pot utiliza într-un format de afișare al unui câmp numeric sunt prezentate în tabelul 2.2.

Pentru câmpurile numerice formatul de afișare se împarte în patru zone separate prin caracterul „ ; ”:

prima zonă se referă la modul de afișare al numerelor pozitive;

a doua zonă se referă la modul de afișare al numerelor negative;

a treia zonă se referă la modul de afișare al numărului zero;

a patra zonă se referă la modul de afișare al valorii Null. (4)

Tabel 2.2. Caracterele ce se pot utiliza într-un format de afișare al unui câmp numeric

Caption – stabilește un șir de caractere care va fi afișat în titlul unei coloane, în momentul introducerii datelor; dacă această proprietate nu are nici o valoare, șirul afișat în titlul unei coloane este chiar numele câmpului; valoarea acestei proprietăți nu are nici o influență asupra numelui câmpului în utilizarea sa în interogări, VBA, etc. (4)

Exemplu: dacă numele unui câmp este DenProd, și în proprietatea Caption se scrie Denumire Produs.

Default Value – stabilește o valoare implicită care este propusă în momentul în care se introduc date într-un tabel; se recomandă în cazul în care există o valoare preponderentă a conținutului unui câmp; în cazul în care utilizatorul nu introduce o altă valoare în câmpul respectiv, valoarea din această proprietate va fi memorată în conținutul acestuia. (5)

Exemplu: pentru un câmp care memorează valoarea TVA, ținând cont că pentru majoritatea produselor aceasta este 19%, pentru a ușura munca de culegere date, este recomandat ca în proprietatea Default Value să se stabilească această valoare. La introducerea datelor, dacă un produs are această cotă, atunci valoarea sa nu se mai tastează.

Input Mask – stabilește un format (mască, șablon) de introducere a datelor pentru un anumit câmp. La fel ca în cazul proprietății Format, există o serie de caractere prin care se stabilește acest format de introducere a datelor; în cazul în care se utilizează ambele proprietăți, proprietatea Format are prioritate față de proprietatea Input Mask. (5)

Proprietatea Input Mask pune la dispoziția utilizatorului câteva măști predefinite dar și posibilitatea definirii unor măști personalizate. Măștile personalizate se definesc sub forma a trei zone separate prin caracterul punct și virgulă (;):

prima zonă se utilizează pentru definirea propriu-zisă a formatului de introducere;

a doua zonă, se utilizează pentru a specifica dacă se memorează și caracterele care fac parte din șablonul de introducere sau nu; valoarea zero stabilește că se memorează inclusiv caracterele din definiția șablonului, iar valoarea unu inhibă această posibilitate:

a treia zonă se utilizează pentru a specifica un caracter, care este afișat într-o poziție din șablon.

Caractere ce se pot utiliza pentru definirea unui șablon de introducere a datelor sunt prezentate în tabelul 2.3. (4)

Exemplu:

\O\R\A\:00:00:00 va afișa și cuvântul ORA: fără a fi memorat. De remarcat că Access transformă automat secvența \O\R\A\: în ORA:.

"(040)-"00\-00000## este un posibil șablon pentru introducerea unui număr de telefon din România; la introducere va afișa: (040)– – . Prin utilizarea caracterului 0,nu se permit prefixe decât din două cifre, și numere de telefon de minim 5 cifre, iar prin utilizarea caracterului # sunt permise numere din 6 și 7 cifre.

>AAAA<aaaa definește un format de introducere în care primele 4 caractere sunt obligatorii și sunt transformate automat în majuscule, iar următoarele 4 sunt opționale și transformate automat în minuscule. (5)

Utilizarea proprietății Input Mask inhibă tasta Insert, singurul mod de lucru fiind cel de suprascriere.

Tabel 2.3. Caractere ce se pot utiliza pentru definirea unui șablon de introducere a datelor

Validation Rule – definește o regulă de validare pentru un câmp, practic o expresie ce se a testa pentru conținutul introdus într-un câmp. Regulile de validare se testează după introducerea unei valori într-un câmp sau în momentul în care se încearcă salvarea unei înregistrări (în momentul în care se încearcă introducerea unei înregistrări noi, la trecerea ie la o înregistrare la alta, sau la salvarea explicită a acesteia) pentru câmpurile nevizitate de utilizator. Dacă o regulă de validare a unui câmp nu se verifică, înregistrarea nu se poate salva decât dacă se corectează conținutul câmpului în așa fel încât să se verifice regula de validare stabilita Expresia pentru această proprietate se poate scrie și în mod asistat cu ajutorul ferestrei Expression Builder, ce poate fi invocată din butonul . Numele câmpurilor dintr-o expresie Validation Rule trebuie scris între caracterele [ ]. O expresie Validation Rule la nivel de câmp nu poate referi alte câmpuri, decât cel curent. Se pot utiliza funcții Access, constante, operatori, etc. (4)

Exemple de reguli de validare pentru un câmp de tip Number, Integer:

>100 and <=200 stabilește valorile posibile între 101 și 200

<>Null sau Is Not Null câmpul trebuie să conțină o valoare.

Exemple de reguli de validare pentru un câmp de tip Text:

"Călărași" Or "București" Or "Brașov"

In("Calarași"; "București"; "Brașov") valoarea câmpului nu poate fi decât una din cele trei.

Mid([nume];l;l)="A" primul caracter introdus în câmpul nume nu poate fi decât A sau a.

Exemple de reguli de validare pentru un câmp de tip Date/Time:

>=Date() data introdusă trebuie să fie mai mare sau egală cu data sistemului.

Year([data factura])=Year(Date()) anul din câmpul data factura trebuie să fie în momentul introducerii, același cu cel din data sistemului. (2)

Validation Text – definește un mesaj de atenționare care va fi afișat în momentul în care regula de validare definită în proprietatea Validation Rule este încălcată.

Required – poate lua valoarea Yes sau No, corespunzătoare valorilor logice adevărat (True) sau fals (False) și stabilește dacă valoarea unui câmp este obligatoriu (Yes) de introdus sau nu (No). Pentru câmpurile de tip Text, Memo, Hyperlink este bine să se utilizeze această proprietate în strânsă legătură cu proprietatea Allow Zero Length.

Allow Zero Length – stabilește dacă este permisă introducerea unui șir de lungime zero (Yes) sau nu (No) într-un câmp de tip Text, Memo sau Hyperlink. Variantele de memorare în condițiile utilizării proprietăților Required și Allow Zero Length sunt prezentate în tabelul 2.5.

Date/Time – formatele predefinite de afișare pentru câmpurile de tip sunt prezentate în figura 2.5. (1)

Tabel 2.4. Caractere care se pot utiliza într-un câmp de tip Date/Time

Exemplu:

"Data: "dd/mm/yy" săptămâna: "ww afișează Data: 01/06/01 săptămâna: 22

dddd/mmmm/yyyy afișează vineri/iunie/2001 "ORA:"hh:nn:ssAM/PM afișează ORA:12:00:00AM(5)

Tabel 2.5. Proprietățile Allow zero length și Required

Indexed – stabilește un câmp drept index. Valori posibile:

No – neindexat

Yes (Duplicates OK) – sunt permise valori duplicate pe câmpul index;

Yes (No Duplicates) – index; nu sunt permise valori duplicate pe acest câmp.

Pentru câmpurile de tip Yes/No formatele de afișare predefinite sunt: True/False, Yes/No, On/Off.

Pe lângă aceste formate predefinite, utilizatorul își poate crea propriile formate pentru câmpurile logice într-o structură formată din trei zone separate prin caracterul „ ; ”.

în prima zonă, se poate stabili un text care nu are influență asupra conținutului câmpului;

a doua zonă este utilizată pentru a stabili un text afișat în cazul în care valoarea memorată este adevărat (True);

a treia zonă este utilizată pentru textul afișat în cazul în care valoarea memorată este False.

În cazul câmpurilor de tip logic, efectul formatelor definite de utilizator se poate observa numai dacă se utilizează controale de tip casetă de text (Text Box).

În cazul câmpurilor de tip Text sau Memo, nu există formate predefinite de afișare, însă prin intermediul unor caractere, utilizatorul își poate stabili propriile formate. Aceste formate se stabilesc sub forma a două zone:

prima zonă se utilizează pentru a stabili formatul propriu-zis de afișare al conținutului câmpului;

a doua zonă, pentru stabilirea formatului de afișare în cazul valorilor vide sau Null.

Caractere ce se pot utiliza pentru stabilirea formatelor de afișare pentru câmpurile de tip Text sau Memo:

@ – este obligatorie introducerea unui caracter sau spațiu;

& – nu este obligatorie introducerea unui caracter;

> – transformă toate caracterele în majuscule, indiferent de modul de tastare;

< – transformă toate caracterele în minuscule, indiferent de modul de tastare; (4)

Exemplu: <; „Nu exista text” va afișa șirul introdus cu litere minuscule, iar în cazul în care nu este introdus un șir va afișa textul Nu exista text.

Așa cum s-a amintit, pe lângă aceste formate de caractere predefinite se pot utiliza și secvențe speciale de caractere, care pot fi utilizate după necesități. Sunt caractere care se pot utiliza pentru orice tip de câmp și caractere care se pot utiliza numai pentru anumite tipuri de date.

Caractere care se pot utiliza în orice tip de câmp :

„șir caractere” afișează șirul de caractere dintre ghilimele împreună cu conținutul câmpului;

! aliniază conținutul unui câmp la stânga, în loc de alinierea dreapta;

[Culoare] afișează conținutul unui câmp în culoarea precizată;

(space) (5)

Definirea cheii primare și a indecșilor

Orice tabelă trebuie să posede o cheie primară (Primary Key), adică un câmp sau un grup de câmpuri care identifică în mod unic fiecare înregistrare. Dacă utilizatorul nu stabilește o cheie primară, Access stabilește una în mod implicit creând un câmp de tip AutoNumber care va conține un număr unic pentru fiecare înregistrare. Deși Access creează în mod implicit o cheie primară, următoarele rațiuni recomandă utilizatorului să definească o cheie primară:

cheia primară este un index.

indecșii realizează o clasificare a datelor după unul sau mai multe câmpuri ceea ce are drept consecință creșterea vitezei de realizare a interogărilor.

la fiecare adăugare a unei noi înregistrări, Access nu autorizează înregistrări duble pentru câmpul cheie primară.

Microsoft Access afișează datele în ordinea cheii primare.

În afară de indecși pe un singur câmp se pot defini și indecși multipli, care funcționează pe mai multe câmpuri simultan. Aceștia se pot defini/modifica numai în fereastra Indexes. În aceeași fereastră se pot gestiona și indecșii pe un singur câmp. Fereastra cu indecșii unei tabele (Indexes) se activează din meniul View, opțiunea Indexes (figura 2.6.)

Fig. 2.6. View -> Indexes

Pentru definirea unui index (sau pentru o cheie primară) format din mai multe câmpuri, se scrie numele indexului în coloana Index Name, iar în coloana Field Name se aleg câmpurile care formează indexul sau cheia primară.

Coloana Sort Order indică modul de ordonare al datelor în index. În cazul indecșilor ce includ mai multe câmpuri, valoarea proprietății Indexed, pentru fiecare câmp în parte este No.

Proprietățile din fereastra Indexes:

Primary – valoarea Yes indică faptul că indexul este cheie primară;

Unique – valoarea Yes indică faptul că indexul va avea valori unice, nefiind permise duplicatele; pentru o cheie primară, această proprietate are obligatoriu valoarea Yes.

Ignore Nulls – valoarea Yes indică faptul că sunt permise valorile Null într-un index; Pentru o cheie primară, această proprietate are obligatoriu valoarea No.

Pe lângă modalitatea descrisă anterior, cheia primară a unui tabel se mai poate defini astfel:

dacă este vorba de o cheie formată dintr-un singur câmp, se poziționează cursorul în câmpul respectiv, se acționează click dreapta și se alge opțiunea Primary Key;

pentru chei primare formate din mai multe câmpuri, se selectează câmpurile din bordura ferestrei de proiectare și se acționează butonul menționat anterior.

O cheie externă nu se definește explicit în Access sub noțiunea de cheie externă, ea fiind stabilită prin definirea relațiilor dintre tabele. Pentru creșterea performanțelor se recomandă definirea de indecși pentru fiecare cheie externă. (1)

2.2.3 Datasheet View

Datasheet View este echivalentă cu acționarea hyperlink-ului Create table by entering data. În această variantă, Access propune o fereastră de introducere date sub forma unui tabel cu nume de câmpuri generice Field1, Field2….Field10. Inserarea de noi câmpuri pe lângă cele zece propuse implicit, se realizează din meniul Insert->Column.

Schimbarea numelor implicite ale coloanelor se realizează din meniul Format->Rename Column funcție de datele introduse în celule, la salvarea tabelului, Access stabilește ce tip de date va aloca fiecărui câmp.

Dacă, de exemplu, coloana unui câmp conține celule cu numere și o celulă cu un șir de caractere, Access, va alege pentru acel câmp tipul de date Text. Dacă o coloană conține numai numere, Access va alege un tip de date numeric, care să satisfacă toate valorile existente în celulele câmpului. Această variantă de creare a unui tabel este avantajoasă doar în cazul în care se dorește crearea rapidă a unui tabel, fără a interesa prea mult tipurile de date ale câmpurilor, numele acestora, stabilirea de reguli de validare și alte parametrizări importante, toate aceste operații fiind disponibile doar după salvarea tabelului prin modificarea structurii acestuia (butonul de comandă Design View). (1)

2.2.4 Table Wizard

Table Wizard este echivalentă cu acționarea hyperlink-ului Create table by using wizard. Alegerea acestei variante are ca efect activarea unei ferestre în care se propun diverse modele de tabele cu o mare varietate de câmpuri.

Proprietăți ale unui tabel

Pentru a vizualiza fereastra cu proprietăți a unui tabel se activează opțiunea Properties din meniul View.

Validation Rule – are aceeași semnificație ca proprietatea cu același nume atașată câmpurilor, numai că operează la nivel de tabel. În momentul în care se încearcă salvarea unei înregistrări (în momentul în care se încearcă introducerea unei înregistrări noi, la trecerea de la o înregistrare la alta, sau la salvarea explicită a acesteia), dacă nu se verifică această regulă de validare, nu se va putea salva înregistrarea. Față de aceeași proprietate la nivel de câmp, la nivel de tabel, se pot referi mai multe câmpuri ale tabelului în expresia care definește proprietatea.

Validation Text – afișează un mesaj în momentul în care regula de validare definită la nivel de tabel, este testată și nu se verifică.

Filter – stabilește un criteriu în funcție de care vor fi selectate înregistrările în fereastra de introducere date. Pentru a activa/dezactiva filtrul trebuie acționat butonul Apply Filter sau din meniul Records, opțiunea Apply Filter/Sort respectiv Remove Filter/Sort.

Order By – stabilește ordinea de afișare a înregistrărilor, în momentul introducerii datelor. Numele câmpurilor trebuie precizate între [ ]. (2)

2.2.5 Salvarea tabelelor

Tabelele Access se pot salva în mai multe moduri:

din meniul File se alege opțiunea Save;

se execută click pe butonul Save de pe bara cu instrumente de lucru;

se execută evenimentul click pe butonul de închidere a ferestrei de descriere a tabelei

din meniul de control se alege opțiunea Close

Indiferent de modul de salvare, Access afișează caseta de dialog Save As care solicită furnizarea unui nume pentru tabelă. Utilizatorul introduce numele tabelei în caseta de text Table Name și apoi execută click pe butonul OK. Numele tabelelor pot avea până la 64 de caractere și trebuie să respecte convențiile Access descrise pentru formarea numelor de câmpuri. (2)

2.3. Operații asupra înregistrărilor dintr-o tabelă

Într-o tabelă Access se pot realiza următoarele operații:

Adăugarea înregistrărilor;

Ștergerea de înregistrări;

Căutarea de înregistrări;

Modificarea înregistrărilor;

Ordonarea înregistrărilor;

Filtrarea înregistrărilor;

Pentru a efectua aceste operații este necesar ca tabela să fie deschisă în modul DataSheet View. (4)

2.3.1. Adăugarea înregistrărilor

Dacă tabela este deschisă imediat după creare, Access va afișa o foaie de date vidă, iar pointerul de înregistrare va fi plasat pe prima și unica linie, pe butonul ei de selecție (butonul gri din prima coloană din tabela afișată în modul Datasheet View).

Pentru a introduce date se plasează pur și simplu cursorul pe câmp și se introduce o valoare. în timp ce se efectuează această operație, pointerul de înregistrare se transformă într-un creion, ilustrând faptul că se editează o înregistrare. O nouă linie vidă apare dedesubtul primei linii. În locul pointerului de înregistrare figurează un asterisc indicând o nouă înregistrare.

Dacă tabela care se deschide în modul Datasheet View conține date, pentru a adăuga o nouă înregistrare trebuie plasat cursorul pe ultima linie (al cărei pointer este un asterisc) și se introduce noua înregistrare. Pentru plasarea cursorului pe ultima linie se execută click pe butonul New Record de pe bara cu instrumente sau se alege Insert –> Record sau se utilizează tasta săgeata în jos.

2.3.2. Ștergerea de înregistrări

Pentru a șterge una sau mai multe înregistrări se selectează înregistrarea sau înregistrările și se acționează tasta Delete sau butonul Delete Record de pe bara cu instrumente sau se alege din meniul Edit –> Delete. Se recomandă o atenție deosebită la ștergerea înregistrărilor deoarece Access nu permite anularea ștergerii înregistrării.

2.3.3. Căutarea unei înregistrări se realizează în acces secvențial sau în acces direct

Căutarea secvențială a unei înregistrări se face utilizând setul de butoane din partea stângă a barei aflate în partea de jos a ferestrei Datasheet View: Next Record, First Record, Last Record, Previous Record.

Pentru căutarea directă se selectează câmpul în care se face căutarea și se utilizează butonul Find de pe bara cu instrumente sau se alege Edit –> Find (figura 2.7.).

Căutarea se poate realiza în întreaga tabelă, începând cu înregistrarea curentă până la sfârșitul tabelei (Down), de la înregistrarea curentă spre prima înregistrare sau de la ultima înregistrare spre începutul tabelei (Up), opțiuni care se pot preciza în zona Search. Din lista derulantă Match (potrivire) se poate selecta:

Whole Field (întregul câmp);

Start of Field (începutul câmpului);

Any Part of Field (orice parte a câmpului).

Pentru a indica o căutare care să țină seama de literele mari și mici, se marchează caseta Match Case. (4)

Fig. 2.7. – Find

2.3.4. Modificarea înregistrărilor

Pentru înlocuirea automată a valorilor dintr-un câmp din mai multe înregistrări se utilizează caseta de dialog Replace. Caseta Replace se afișează prin comanda Edit –> Replace sau a combinației de taste Ctrl + H (figura 2.8.).

Comanda va înlocui valorile din câmpurile care se potrivesc cu valorile introduse în caseta de text Find What. Înlocuirea se face cu valorile specificate în caseta de text Replace With. Înlocuirea se poate face selectiv prin căutarea fiecărei valori de înlocuit și confirmarea înlocuirii (butoanele Field Next și Replace) sau pentru toate înregistrările care corespund criteriul de înlocuire (butonul Replace All). (5)

Fig. 2.7. Replace

2.3.5. Ordonarea înregistrărilor

Ordonarea și filtrarea înregistrărilor sunt operații deosebit de importante pentru utilizatori, dar ele vizează îndeosebi cererile informaționale ale utilizatorilor, motiv pentru care ele sunt realizate pentru obiectele tip Query (cereri de iterogare) – capitolul 3.

2.3.6. Înghețarea afișării câmpurilor

Dacă o tabelă conține prea multe câmpuri, ele nu pot fi afișate toate în modul Datasheet View. Pentru a vizualiza toate câmpurile se folosește bara de derulare orizontală sau înghețarea afișării câmpurilor. Pentru înghețarea afișării câmpurilor executăm operațiile:

se deschide tabela în modul Datasheet View;

se selectează coloana sau coloanele a căror afișare se va îngheța executând click pe butoanele antetelor acestor coloane;

se utilizează comanda Format –> Freeze Columns (înghețarea coloanelor).

Pentru „dezghețarea” coloanelor „înghețate” se alege comanda Format –> Unfreeze All Columns.

2.4. Definirea relațiilor între tabele

Pentru a avea acces simultan la datele din mai multe tabele ale aceleiași baze de date este necesar să se definească relațiile standard dintre aceste tabele. Relațiile între tabele se definesc pe baza valorilor unui câmp dintr-o tabelă utilizat drept cheie primară și valorilor aceluiași câmp dintr- o altă tabelă, unde este utilizat drept cheie externă. Access impune existența aceluiași tip de date pentru câmpurile care participă la o relație.

În cazul câmpului de tip Number proprietatea Field Size a celor două câmpuri trebuie să fie identică. Relația dintre câmpurile de tip Text trebuie, în principiu, să folosească câmpuri de aceeași lungime.

Se recomandă ca stabilirea relațiilor între tabele să se facă înainte de înregistrarea datelor. În Access există următoarele posibilități de realizare a relațiilor dintre tabele:

– Relația 1 – 1 (one-to-one sau unu la unu) este cea mai simplă relație între două tabele. În această relație, unei valori a câmpului cheie principală dintr-o tabelă îi corespunde o singură valoare din câmpul folosit drept cheie externă din cealaltă tabelă. Altfel spus, unei înregistrări din tabela aflată în partea stângă a relației îi corespunde o singură înregistrare din tabela aflată în partea dreaptă a relației. Tabelele aflate într-o relație one-to-one se pot combina într-o singură tabelă, în care apar toate câmpurile celor două tabele. Relațiile de acest tip nu sunt uzuale.

Tabelul A Tabelul B

– Relația 1 – n (one-to-many sau unul la mai mulți) constituie tipul cel mai răspândit de relații. Conform acestei relații unei înregistrări din tabela aflată în partea stângă a relației îi corespund două sau mai multe înregistrări din tabela aflată în partea dreaptă a relației. Asocierea se bazează pe un câmp cheie principală unic într-o tabelă și un câmp cheie externă din cealaltă tabelă care admite valori duplicate.

Tabelul A Tabelul B

– Relația n–1 (many-to-one sau mai mulți la unul) este opusă relației 1–n. Pentru a crea relația many-to-one este suficient să se inverseze relația one-to-many. De aceea, se spune că relația many-to-one este reflexivă, adică relația many-to-one este reflexia relației corespondente one-to-many. Dacă se selectează o înregistrare din tabela din partea many a relației se poate afla înregistrarea care corespunde cheii sale externe din tabela din partea one a relației. Relațiile n – 1 nu sunt bazate pe câmpuri cheie primară din nici una dintre cele două tabele. (1)

Tabelul A Tabelul B

– Relația m–n (many-to-many sau mulți la mai mulți) nu poate fi exprimată ca o simplă relație între două tabele. Relația many-to-many se poate exprima prin intermediul unei a treia tabele care are relații one-to-many și many-to-one cu cele două tabele

Tabelul A Tabelul B

Indiferent de tipul de relații existent între două/mai multe tabele este esențial ca cele două câmpuri participante la aceasta să aibă exact același tip de date.

Pe lângă stabilirea relațiilor între tabelele unei baze de date, Access permite și specificarea unor reguli care forțează integritatea datelor. Aceste reguli se numesc restricții de integritate referențială. Ele permit să se conserve intacte relațiile între tabele într-un sistem de gestiune a unei baze de date relaționale.

Integritatea referențială funcționează după câmpul cheie. Acest sistem verifică în mod continuu câmpul cheie, primară și străină, la fiecare operație de adăugare, ștergere sau modificare a unei înregistrări. Dacă o schimbare a unei chei afectează legătura între tabele, sistemul avertizează că se violează regulile de integritate referențială.

Atunci când două tabele sunt legate printr-o relație, o tabelă se numește părinte și cealaltă se numește copil. Acest sistem este cunoscut sub numele de relație părinte-copil. Integritatea referențială garantează că nu vor exista înregistrări orfane adică înregistrare copil fără o înregistrare părinte.

Capacitatea de a asigura în mod automat integritatea referențială este o caracteristică importantă a programului Access.

Definirea legăturilor dintre tabele se realizează din meniul Tools-> Relationships, acesta activând un panou de editare vizuală a acestora. Prima activare a acestei opțiuni are ca efect și afișarea unei ferestre cu obiectele bazei de date ce se pot plasa în panou prin dublu-click sau selectarea obiectului și butonul Add (figura 2.8.). (1)

Fig. 2.8. Relationships

Pentru a putea defini o legătură între două tabele, trebuie să existe compatibilitate între tipul de date al cheii primare și cel al cheii externe corespunzătoare.

După plasarea tuturor tabelelor în panoul de editare, definirea propriu-zisă a unei relații se realizează prin drag-and-drop dinspre cheia primară a unei tabele spre cheia externă corespunzătoare sau invers. După realizarea acestei operații, finalizarea definirii unei legături se realizează în fereastra din figura 2.9, unde este prezentată definirea unei relații între tabelul furnizor (cheie primară cod furnizor) și tabelul produs (cheie externă id).

Dacă o cheie este formată din mai multe câmpuri, acestea se editează corespunzător în panoul Edit Relationship (figura 2.9.) (2)

Fig. 2.9. Edit Relationships

Opțiunile din fereastra Edit Relationships au următoarea semnificație:

Enforce Referential Integrity – definește o restricție de integritate referențială. Nu se permite actualizarea valorii unei chei externe, dacă această valoare nu există deja în tabelul unde aceasta este cheie primară.

Cascade Update Related Fields – actualizarea valorii unei chei primare dintr-un tabel se propagă și în înregistrările din tabelele unde aceasta este cheie externă.

Cascade Delete Related Fields – ștergerea valorii unei chei primare, are ca efect și ștergerea înregistrărilor din tabelele unde aceasta este cheie externă.

În caseta Relationship Type sunt prezentate tipurile de legături care pot exista între două tabele :

One to One -1-1;

One to Many – 1–n

Dacă în această casetă este afișat mesajul Indeterminate, înseamnă că tipul de relație nu poate fi definit, cea mai probabilă eroare fiind incompatibilitatea între tipul de date al cheii primare și cel al cheii externe, sau inexistența unei chei primare în relația respectivă.

Butonul de comandă Join Type permite și definirea unor tipuri de relații particulare între tabele, așa cum se observă din figura 2.10.

Variantele 2 și 3 permit utilizarea implicită în interogări a join-urilor externe de tip Left și Right, care presupun într-o interogare luarea în considerare a tuturor înregistrărilor dintr-un tabel, indiferent dacă au sau nu înregistrări corespondente după câmpul (câmpurile) de legătură în celalalt tabel. în exemplul de legătură prezentat în figura 2.10, este posibilă o interogare între cele două tabele, în care vor fi luate în considerare toate înregistrările din tabelul produse, indiferent dacă au sau nu corespondent în tabelul furnizor. (1)

Fig. 2.10. Edit Relationships –> Join Properties

Capitolul 3. – Aplicație Practică

3.1 Prezentarea problemei

Problema tratată este cea a implementării unei baze de date pentru realizarea evidenței automate a elevilor. Pentru aceasta trebuie precizate informațiile care sunt stocate pentru o perioada mai mare de timp.

Informațiile care se păstrează uzual într-o școală (bineînțeles, cele despre elevii școlii) sunt următoarele:

nume;

prenume;

numele tatălui;

numele mamei;

numărul matricol;

data nașterii;

locul nașterii;

telefon acasă;

telefon părinți;

disciplinele parcurse și notele obținute;

repetările.

3.2 Analiza problemei

Analiza problemei care trebuie rezolvată are ca scop elaborarea modelelor care să permită ulterior elaborarea structurii bazei de date. Această analiză presupune următoarele etape:

identificarea entităților informaționale care vor fi stocate în baza de datei și a legăturilor dintre acestea, activitate cunoscută sub numele de analiză statică sau structurală;

identificarea stărilor în care se pot afla aceste entități și a tranzițiilor posibile între aceste stări în raport cu anumite evenimente (analiza dinamică);

identificarea transferurilor de date din cadrul sistemului (analiza funcțională).

Pentru construirea modelului structural trebuie parcurse următoarele etape:

identificarea componentelor din cadrul sistemului informatic;

identificarea asocierilor dintre entități și calificarea lor;

identificarea atributelor aferente entităților și asocierilor lor;

Stabilirea atributelor de identificare a entităților. (5)

Pentru problema prezentată se pot identifica trei entități care se află în legătură una cu alta, și anume: entitatea ELEV, entitatea CATALOG și entitatea DISCIPLINA.

Diagrama structurală, corespunzătoare celor trei entități și a legăturilor dintre ele, este prezentată în figura următoare :

Figura 3.1 – Diagrama entitate-relație

Legătura dintre entitățile ELEV și CATALOG este de tipul “unu la mulți”. Aceasta înseamnă ca un elev va apare în catalog cel puțin o dată dar, în mod normal, el va apare în mai multe instanțe ale entității CATALOG.

Entitățile identificate sunt caracterizate fiecare de o serie de atribute.

În continuare sunt prezentate entitățile din diagrama structurală împreună cu atributele fiecăreia.

Figura 3.2 – Atributele entității ELEV

Figura 3.3.- Atributele entității CATALOG

Figura 3.4 – Atributele entității DISCIPLINA

Ca atribut de identificare pentru entitatea ELEV se alege atributul NRMATRICOL. Pentru entitatea CATALOG, atributul de identificare este atributul NRMATRICOL, iar pentru entitatea DISCIPLINA acesta este coddiscip.

Analiza dinamică are drept scop explicarea comportamentului elementelor componente ale sistemului informatic analizat.

În urma acestei analize se obține modelul dinamic al sistemului analizat.

Construirea modelului dinamic presupune următoarele etape :

identificarea stărilor în care se pot afla componentele sistemului;

identificarea evenimentelor care determină trecerea unei componente dintr-o stare în alta;

stabilirea succesiunii (fluxului) de evenimente și construirea unei diagrame care să reflecte tranzițiile de stare pentru componentele sistemului (diagrama de flux a evenimentelor).

Figura 3.5. Diagrama de flux a evenimentelor, corespunzătoare stărilor celor două entități

La realizarea diagramei de flux a evenimentelor este necesar să se țină cont de restricțiile dinamice ale sistemului care servesc la identificarea tranzițiilor admisibile între două stări.

În figura 3.5 sunt prezentate stările în care se pot afla cele trei entități care compun sistemul.

Tranzițiile entităților sistemului dintr-o stare în alta influențează tranzacțiile (transferurile de date) care au loc în interiorul sistemului, iar acestea la rândul lor influențează modul de realizare a aplicațiilor software destinate sistemului.

Analiza funcțională are drept scop determinarea transformărilor de date care se produc în cadrul sistemului informatic analizat în scopul satisfacerii cerințelor informaționale aferente acestuia. Transformările de date se vor reprezenta sub forma unei diagrame de flux a prelucrărilor, în care nodurile reflectă procesele de prelucrare informațională, iar arcele reflectă fluxurile informaționale.

În cadrul analizei funcționale, accentul se deplasează de la realitatea analizată către cerințele informaționale ale utilizatorilor, cerințe a căror satisfacere constituie obiectivul realizării bazei de date.

Construirea modelului funcțional presupune parcurgerea următoarelor etape:

identificarea datelor de intrare și a datelor de ieșire din sistem;

construirea diagramelor de flux, prin care sunt reflectate legăturile procedurale dintre intrări și ieșiri;

identificarea restricțiilor;

precizarea criteriilor de optimizare.

Datele de intrare pentru problema analizată sunt următoarele:

datele care descriu atributele entității ELEV, în cazul adăugării de noi elevi;

datele care descriu atributele entității CATALOG, pentru evidența notelor și a absențelor;

datele care descriu atributele entității DISCIPLINA, pentru evidența disciplinelor care trebuie predate conform planului de studiu;

Datele de ieșire sunt reprezentate de:

lista elevilor dintr-o anumită clasă;

catalogul în formă electronică;

alte rapoarte la cerere.

Prelucrările de date care trebuiesc efectuate constau în următoarele acțiuni:

adăugarea de noi elevi în baza de date;

ștergerea unui elev;

extragerea de rapoarte privind elevii care studiază, eventual acest raport trebuie sa fie ordonate.

Diagramele de flux a prelucrărilor sunt prezentate în figurile următoare.

Figura 3.6. Diagrame de flux a prelucrărilor

În final cele trei modele ale sistemului vor fi integrate pentru se obține o reprezentare completă a sistemului analizat. Modelul structural și cel dinamic sunt obținute prin investigarea sistemului real, a proprietăților intrinseci, statice și dinamice ale componentelor acestui sistem, proprietăți care sunt independente de aplicațiile care operează asupra lor.

Modelul funcțional este rezultatul analizei cerințelor informaționale ale utilizatorilor, mai precis a tranzacțiilor prin care pot fi satisfăcute aceste cerințe.

Perspectiva diferita din care este realizata analiza explica de ce rezultatele obținute pot sa difere fiind necesara o coordonare, deci o integrare a lor.

În cadrul etapei de integrare a modelelor sistemului se stabilește în ce măsură modelul structural și cel dinamic satisfac necesitățile diferitelor aplicații, verificându-se complitudinea (existența elementelor informaționale solicitate) și consistența lor (în ce măsură componentele modelelor sunt necesare și suficiente în raport cu procesele de prelucrare). Se verifică dacă relațiile dintre componentele sistemului sunt stabilite în mod corespunzător, pentru a face posibilă regăsirea informațiilor din mai multe entități. Se determină, de asemenea, dacă legăturile dintre entități asigură coerența informațiilor, posibilitatea efectuării de actualizări concomitente asupra datelor redundante.

Se urmărește ca toate elementele informaționale participante la diferitele tranzacții să fie asignate ca atribute ale diferitelor entități.

Pe baza acestei analize integrate se efectuează adăugările și/sau corelările necesare între modelele sistemului.

În final se ajunge ca modelul dinamic și cel structural să nu mai fie complet independente de aplicații, iar modelul funcțional să nu mai fie orientat exclusiv pe aplicații.

Modelele obținute în urma analizei sistemului informațional sunt modele ale datelor despre sistem. O caracteristică esențiala a acestor modele este faptul că sunt independente de instrumentul, respectiv SGBD-ul prin intermediul căruia devin operaționale.

3.4. Proiectarea schemei conceptuale

Proiectarea schemei conceptuale a bazei de date presupune următoarele activități:

Stabilirea colecȚiilor de date și definirea detaliată a conținutului acestora. La stabilirea acestora se pleacă de la entitățile identificate în etapa de analiză a sistemului. Fiecărei entități îi corespunde, de obicei, o colecție de date în cadrul schemei conceptuale. În aceste colecții vor figura atributele specifice entităților plus eventual o serie de atribute pentru exprimarea legăturilor cu celelalte componente ale sistemului real, atribute cunoscute sub numele de chei externe. Deoarece nu întotdeauna există o corespondență strictă între entitățile din modelele semantice și colecțiile de date din schema conceptuală a bazei de date și din considerente de ameliorare a lucrului pe aceste colecții de date se poate decide “spargerea” unei entități în două sau mai multe colecții de date. Acest lucru duce la o creștere a flexibilității de operare cu colecțiile de date respective. “Spargerea” unei entități în două sau mai multe colecții de date se realizează ținând seama de cerințele informaționale ale sistemului și de durata de existență a datelor în cadrul sistemului. Astfel, datele care sunt solicitate mai des de către utilizatori, cele care se modifică la intervale reduse de timp sau cele care, deși nu se modifica prea des, sunt solicitate frecvent de către programe pentru a genera alte date (prin calcul sau în alt mod), pot constitui colecții separate de date pentru a reduce timpul necesar regăsirii informațiilor căutate. Cu toate acestea, îmbunătățirea performanțelor în manipularea entităților nu presupune obligatoriu mărirea numărului colecțiilor de date folosite în cadrul schemei conceptuale. Aceasta deoarece nu se poate admite o creștere nelimitată a numărului de colecții de date lucru care determină creșterea dificultăților de localizare și accesare a datelor. Legăturile între un număr mare de colecții de date impune și creșterea redundanței datelor în cadrul bazei de date și deci o utilizare ineficientă a suportului de memorare.

determinarea legaturilor dintre colectiile de date și a modului de reprezentare a acestora în cadrul schemei conceptuale se realizează, în principiu pe baza legăturilor dintre entitățile identificate în cadrul etapei de analiză a sistemului și a cerințelor informaționale. Este necesar să se determine, de asemenea și legăturile dintre colecțiile care nu au corespondent direct în entitățile care compun sistemul, dar care la rândul lor se află în asociere, unele cu altele. Modul de reprezentare a legăturilor dintre colecțiile de date depinde de modelul datelor suportate de SGBD. Astfel, modelul ierarhic și cel rețea utilizează pointeri (adrese legătură) pentru înlănțuirea datelor în cadrul colecțiilor. Modelul relațional reprezintă legăturile dintre colecțiile de date (relații) cu ajutorul cheilor externe sau cu ajutorul unor colecții de date distincte. Această reprezentare uniformă a datelor și a asocierilor între date prin intermediul relațiilor constituie o caracteristică a modelului relațional, care conferă acestuia o mare simplitate și flexibilitate.

testarea schemei CONCEPTUALE obȚinute presupune verificarea completitudinii și consistenței schemei conceptuale, adică determinarea gradului în care schema conține elementele informaționale necesare satisfacerii cerințelor informaționale ale diferiților utilizatori și măsura în care legăturile stabilite între aceste elemente informaționale reflectă raporturile naturale dintre componentele sistemului real. De asemenea, prin testarea schemei conceptuale trebuie să se verifice dacă redundanța datelor este la un nivel minim și poate fi controlată. Testarea schemei conceptuale permite identificarea unor eventuale erori de proiectare care fac necesară revizuirea schemei. În acest caz se va relua etapa de proiectare a structurii bazei de date, și, uneori, și etapa de analiză a sistemului și a cerințelor informaționale.

descrierea schemei conceptuale în limbajul de descriere a datelor de care dispune SGBD-ul și încărcarea acestei descrieri în baza de date.

Descrierea schemei conceptuale a bazei de date se realizează în limbajul de descriere a datelor de care dispune SGBD-ul folosit. Rezultatul acestei descrieri îl constituie proiectul bazei de date sau schema bazei de date.

Compilatorul limbajului de descriere a datelor permite aducerea schemei bazei de date în forma la care aceasta poate fi memorata in baza de date.

La realizarea acestor activitatea sunt utilizate, în principal modelul structural și cel dinamic al sistemului analizat.

Pentru aplicația noastră, colecțiile de date care definesc cele trei entități ale sistemului vor fi identice cu descrierea entităților realizată prin diagramele entitate-relație.

În continuare sunt descrise colecțiile de date utilizate în cadrul bazei de date.

ELEV

NRMATRICOL CARACTER 4

NUME CARACTER 30

PRENUME CARACTER 33

DATANAST DATE/TIME

TATA CARACTER 15

MAMA CARACTER 15

ADRESA CARACTER 40

TELEFON CARACTER 15

CATALOG

NRMATRICOL CARACTER 4

CODDISCIP CARACTER 6

DATA DATE/TIME

ABSENTA CARACTER 1

NOTA CARACTER 2

DISCIPLINA

CODDISCIP CARACTER 5

DENUMIRE CARACTER 23

ANSTUDIU CARACTER 2

3.5. Proiectarea schemei externe

Schema externă a bazei de date reprezintă forma sub care apare schema conceptuală pentru un utilizator oarecare. Programele de aplicație operează asupra schemei conceptuale prin intermediul schemei externe, având acces doar la acele elemente care sunt incluse în schema externă.

În general, elementele care compun schema externă sunt similare celor care compun schema conceptuală, depinzând totuși de tipul de SGBD utilizat.

În cazul aplicației de față, schema externă cuprinde structura rapoartelor care trebuiesc întocmite de către programe prin selectarea informațiilor corespunzătoare.

Rapoartele care trebuiesc întocmite de către aplicație sunt următoarele:

lista ordonată descrescător a elevilor dintr-o clasă anumită pe baza mediei obținute;

catalogul;

alte rapoarte, la cererea utilizatorului.

Raportul care cuprinde rezultatele elevilor va conține, practic următoarele informații: antetul documentului, clasa pentru care se extrag date, titlul raportului, lista propriu-zisă a elevilor și a mediilor acestora.

Pentru vizualizarea situației școlare a unui elev se întocmește un raport ce va conține: numele și prenumele elevului, clasa în care este, lista disciplinelor cu notele obținute și cu absențele acumulate. Acest raport poate fi vizualizat pe ecran sau trimis la imprimanta.

3.6. Proiectarea schemei externe

Schema internă reprezintă modul cum sunt stocate datele pe suportul de memorie externă.

Pentru problema analizată, schema internă este reprezentată de descrierea structurii tabelelor din baza de date.

Structura tabelelor MS-Access se poate observa mai jos.

Relațiile generate automat între cele trei tabele sunt prezentate mai jos.

3.7. Proiectarea aplicației

Această etapă a realizării aplicației presupune efectuarea următoarelor activități :

identificarea datelor de intrare și ieșire;

identificarea acțiunilor;

proiectarea structurii aplicației;

proiectarea procedurilor;

proiectarea formularelor de introducere a datelor

proiectarea rapoartelor;

implementarea aplicației;

testarea și depanarea aplicației.

Acțiunile aplicației se pot identifica din schema funcțională și constau în următoarele:

introducere date pentru înregistrarea unui elev nou;

modificare date privind anumiți elevi;

ștergerea informațiilor privind un anumit elev dacă aceasta a absolvit sau a fost transferat la altă școala;

introducere date privind acumularea de noi absențe;

căutare elev pentru care se specifică numele sau numărul matricol;

afișare date elevi, la cererea utilizatorului;

modificare date personale ale elevilor;

ștergerea unui elev din baza de date;

Fiecare din aceste activități va fi implementată prin intermediul unei unelte specializate din cele oferite de MS-Acces.

Pentru acțiuni deosebite se pot realiza și proceduri de lucru în limbajul Visual Basic for Application. Acest limbaj permite dezvoltarea de aplicații direct din mediul MS-Office.

Interogarea bazei de date se va realiza prin intermediului instrumentului numit Querry care implementează căutarea de tip QBE (Querry By Example) și prin intermediul limbajului SQL. De altfel, în MS-Access orice interogare realizată prin QBE are asociată și o frază SQL care conduce la rezultatul dorit.

Introducerea datelor în tabele se realizează prin intermediul formularelor pentru introducere date prezentate mai jos.

ADAUGARE ELEV:

ADAUGARE DISCIPLINA:

ADAUGARE NOTA/ABSENTA:

Extragerea informațiilor din baza de date se va realiza cu ajutorul rapoartelor pe care MS-Access le poate realiza foarte ușor.

Exemple de rapoarte sunt prezentate mai jos:

Concluzii

Este evident că un sistem modern, adresat procesului de învățare nu mai poate folosi numai mijloacele tradiționale de înregistrare și informare. Perfecționarea unui sistem, oricare ar fi el nu mai poate fi conceput fără a ține seama de tehnologiile moderne.

În prezenta lucrare am încercat să prezint etapele care trebuiesc parcurse pentru a realiza o bază de date prin intermediul căreia se poate ține evidența elevilor într-o școală, precum și situația lor școlară. Prin diferite interogări ale bazelor de date se pot obține rapid informații despre situația absențelor, a notelor ș.a.

Consider că aplicația poate fi utilă pentru o mai bună evidența a elevilor într-o școală, iar prin intermediul unui modul special ar putea permite interogarea din exterior de către părinți care astfel ar putea supraveghea mult mai bine activitatea școlară a elevilor (note și absențe).

Cu toate acestea, desigur, aplicația poate fi îmbunătățită. Astfel, s-ar putea adăuga mai mute rapoarte, de exemplu generarea unui raport care sa conțină cei mai buni elevi (cu medii peste 9 – exemplu), respectiv un raport cu elevii problema.

Bibliografie

1. Dușmănescu D., Baze de Date, Editura Universității din Ploiești, 2005

2. Lungu I., ș.a., Baze de date. Organizare, proiectare, implementare, Editura All, București 1998

3. Perkins J., Bryan M., SQL fără profesor în 14 zile, Editura Teora, București, 1998

4.https://paurelian.files.wordpress.com/2008/09/curs-microsoft-access.pdf

5.http://documentareonline.ro/pdf_samples/Sample_bl7qzXBbTWmzSYKVtHlbuBY.pdf

Bibliografie

1. Dușmănescu D., Baze de Date, Editura Universității din Ploiești, 2005

2. Lungu I., ș.a., Baze de date. Organizare, proiectare, implementare, Editura All, București 1998

3. Perkins J., Bryan M., SQL fără profesor în 14 zile, Editura Teora, București, 1998

4.https://paurelian.files.wordpress.com/2008/09/curs-microsoft-access.pdf

5.http://documentareonline.ro/pdf_samples/Sample_bl7qzXBbTWmzSYKVtHlbuBY.pdf