Sunteți pe pagina 1din 7

Analiza i proiectarea aplicaiei

Etapele parcurse n fazele de analiz i proiectare conduc la realizarea unui produs soft
care ine o eviden a aprovizionrii cu materiale (de la diveri furnizori), din cadrul unei uniti
economice.

I.1. Principalele etape n realizarea unei aplicaii


A) Analiza problemei i proiectarea aplicaiei - const n:
formularea problemei prin: studierea activitii vizate de aplicaie, precizarea
funciilor compartimetului n care se ncadreaz problema, identificarea
informaional a compartimentului i a modului de conectare din punct de vedere
informaional cu celelalte compartimente, etc;
analiza i inventarierea documentelor care particip la fluxul informaional;
precizarea situaiilor de ieire (listelor);
stabilirea datelor de intrare necesare;
construirea unui model matematic sau a unei scheme privind structura funcional a
sistemului informatic (prefigurarea obiectelor din baza de date);
proiectarea datelor i a tabelelor;
stabilirea datelor de intrare/ieire;
stabilirea relaiilor ntre tabele;
stabilirea metodelor de prelucrare necesare;
stabilirea drepturilor de acces i a proiectarea sistemului de parole pentru securitatea
informaiei;
stabilirea algoritmului de rezolvare pentru fiecare sarcin n parte, eventual cu
reprezentare grafic printr-o organigram.
B). Realizarea aplicaiei - const n:
construirea obiectelor i a modulelor de program corespunztoare;
testarea morfologic i sintactic a fiecrui modul de program n parte;
ntocmirea unui meniu prin intermediul cruia se pot lansa n execuie sarcinile specifice
ale aplicaiei;
verificarea schimbului de informaie ntre obiecte:
validarea funcionrii aplicaiei prin urmrirea rezultatelor obinute i compararea lor cu
rezultatele obinute pe alt cale;
ntocmirea documentaiei de utilizare.
C). Exploatarea aplicaiei - const n:
utilizarea aplicaiei folosind date reale;
actualizarea permanent a bazei de date;
eventuale modificri i/sau mbuntiri aduse aplicaiei.

I.2. Elemente de analiz

I.3. Alegerea SGBD-ului adecvat


SGBD-ul ales pentru realizarea aplicaiei trebuie s ndeplineasc urmtoarele condiii:
s permit actualizri complexe i repetate ale datelor;
s permit interogarea avansat a bazei de date;
s permit realizarea unei interfee prietenoase;
s permit dezvoltri ulterioare;
s permit manipularea datelor n condiii de securitate ridicat;
s poat fi folosit cu uurin att de utilizator ct i de programator;
s fie un SGBD de uz general, pentru care majoritatea societilor dispun de licen.
Avnd n vedere cele de mai sus am optat pentru Microsoft Access.
I.4. Proiectarea tabelelor i stabilirea relaiilor ntre tabele
Se definete o baz de date care conine tabelele:
1) tABONATI(Fig. 1.1.a. i Fig. 1.1.b.) conine datele despre abonai, necesare pentru a obine
informaii de identificare a acestora. Cmpurile tabelului sunt: Nr_abonat, Data_inscrierii,
Serie_BI, Nr_BI, Data_eliberarii_BI, Nume_abonat, Prenume_abonat, Adresa_abonat,
Telefon_abonat.

Fig. 1.1.a. Modul Datasheet View

Fig. 1.1.b Modul Design View

Cmpul Nr_abonat (AutoNumber, Long Integer) este cheia primar a tabelului; pe baza
informaiei din acest cmp se identific univoc articolele tabelului. Pentru cmpul
Data_inscrierii i pentru Data_eliberarii_BI, se folosete tipul Data/Time. Cmpul Nr_BI este
de tip Number, dimensiune Long Integer. Cmpurile Nume_abonat, Prenume_abonat,
Adresa_abonat sunt de tip Text, toate de dimensiune 50, cmpul Serie_BI este de tip Text,
dimensiune 2, n timp ce cmpul Telefon_abonat este de tip Text, dimensiune 10.
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
21)
22) tblnrcd (Fig. 1.2.a i 3.2.b) necesar pentru a obine informaii de identificare a
documentelor privind recepionarea materialelor de la furnizori. (nrnrcd, datanrcd,
codfurnizor, codgestiune, codfactur, datafactur ). Cheia primar a tabelului este nrnrcd
(numr nota de recepie i constatare de diferene), de tip Number (Long Integer). Cmpurile
datanrcd i datafactur sunt de tip Date/Time (Medium date). Cmpurile codfurnizor,
codgestiune i codfactur sunt de tip Number (Integer, Long Integer). Tabelul a fost indexat
(cu opiunea No Duplicates) pe cmpul nrnrcd.
Fig. 1.2.b Modul Design View

Fig. 1.2.b Modul Design View

23) tblmataprovizionat (Fig. 1.3.) - pentru a avea informaii privind cantitile primite i
recepionate precum i preurile corespunztoare; (nrnrcd, codmaterial, cantaprov,
pretaprov). Cheia primar este compus din cmpurile nrnrcd i cod material, ambele de tip
Number i dimensiune Long Integer. Tabela a fost indexat pe cmpurile nrnrcd i
codmaterial, ambele cu opiunea Duplicates OK. Tot de tip Number sunt i cmpurile
cantaprov (Long Integer) respectiv pretaprov (Single).

Fig. 1.3. Modul Design View

Tabelele tblnrcd i tblmataprovizionat au ca surs de date documentul Nota de


Recepie i de Constatare de Diferene. Tabela tblnrcd cuprinde partea comun a
documentului cu cheia primar nrnrcd, iar tabela tblmataprovizionat cuprinde datele din partea
n care sunt consemnate materialele care au intrat (acestea pot fi mai multe), identificarea
acestora realizndu-se prin cmpul cheie primar compus din nrnrcd i cod material.
24) tblmaterial (Fig. 1.4.)- pentru a obine numele i unitatea de msur a materialelor; conine
cmpurile codmaterial (cheia primar, de tip Number), denmaterial (Text, avnd Field
Size=30) i um (Text, avnd Field Size=5). Tabelul a fost indexat pe cmpul codmaterial, cu
opiunea No Duplicates.

Fig. 1.4. Tabelul tblmaterial

25) tblplati (Fig. 1.5.) - din care rezult plile


efectuate ctre furnizori conine cmpurile
coddocument, sumdocument, datadocument,
codfurnizor. Cheia primar este coddocument de tip
Number, cu Field Size de tip Integer. Tot de acelai tip
sunt i cmpurile sumdocument (Field Size=Long
Integer) i codfurnizor (Field Size=Integer).
Cmpul datadocument este de tip Date/Time
(Medium Date).

Fig. 1.5. Tabelul tblplati


Fereastra Relationships prezentat n figura de mai jos ilustreaz structura datelor ce
corespunde modului de funcionare descris mai sus. Relaiile dintre tabele sunt controlate logic
prin impunerea integritii refereniale.
Fig. 1.6. Relaiile dintre tabelele bazei de date
Relaiile ntre tabele sunt stabilite n urma analizei efectuate astfel:
unu-la-mai-muli, ntre ABONATI i IMPRUMUTURI, astfel unui articol din
ABONATI i pot corespund mai multe articole din IMPRUMUTURI. Cmpul de
legtur este Nr_abonat, cheie primar n tabelul ABONATI i cheie strin n
tabelul IMPRUMUTURI.
unu-la-mai-muli, ntre IMPRUMUTURI i DETALII_RESTITUIRE, astfel unui
articol din IMPRUMUTURI i pot corespunde mai multe articole din
DETALII_RESTITUIRE. Cmpul de legtur este Nr_cerere, cheie primar n
tabelul IMPRUMUTURI i cheie strin n tabelul DETALII_RESTITUIRE.
mai-muli-la-unu, ntre DETALII_RESTITUIRE i CARTI, astfel mai multor
articole din DETALII_RESTITUIRE le corespund un singur articol din CARTI.
Cmpul de legtur este Cota, cheie primar n tabelul CARTI i cheie strin n
tabelul DETALII_RESTITUIRE.
mai-muli-la-unu, ntre CARTI i EDITURI, astfel mai multor articole din CARTI
le corespund un singur articol din EDITURI. Cmpul de legtur este Nr_editura,
cheie primar n tabelul EDITURI i cheie strin n tabelul CARTI.