Sistem Informatic Privind Activitatea Financiara
CUPRINS
INTRODUCERE
Odată cu evoluția economiei mondiale, afacerile au început sa devina tot mai complexe, și astfel volumul de date ce trebuiau prelucrate a crescut într-un ritm accelerat. Evoluția tehnologiei informației și posibilitățile pe care aceasta le oferă au dus la apariția imediată a produselor software de analiză și gestiune a datelor, ca soluție la această problemă, cele mai multe aplicatii de acest gen folosind bazele de date relaționale, ca modalitate de stocare a informației. În prezent, desfășurarea oricărei activități economice, financiare sau bancare nu se poate imagina fără utilizarea unui puternic suport informatic care să asigure avantajul concurențial în raport cu ceilalți competitori de pe piață.
Lucrarea de față prezintă modalitățile de definire și utilizare a bazelor de date folosind limbajul SQL și este însoțită pentru exemplificare de aplicația de gestiune financiară GeFinSQL. Pentru dezvoltarea programului a fost folosit limbajul de programare C#, și sistemul de gestiune a bazelor de date MySQL.
Printre funcțiile aplicației GeFinSQL se numără stocarea informațiilor privind furnizorii și clienții unei societăți comerciale, a datelor legate de salariații acesteia, simularea calculului salariilor și a contribuțiilor individuale ale angajaților, gestiunea intrărilor și ieșirilor contabile, precum și realizarea unei situații generale a conturilor. Aplicația este de tip multi-user, multi-societate, deci se pot stoca informații de la mai multe societăți comerciale, accesul la date fiind restricționat de drepturile pe care il are fiecare utilizator asupra societății respective.
Motivul alegerii acestei teme a fost posibilitatea îmbinării lucrului cu baze de date, utilizarea unui limbaj de programare orientat-obiect și aplicarea și aprofundarea cunoștințelor din domeniului financiar-contabil.
Lucrarea este structurată pe 3 capitole, acoperind atât noțiuni teoretice cât și aspecte legate de modul de realizare a aplicației GeFinSQL.
În primul capitol sunt prezentate câteva aspecte legate de sistemele informatice, componente, structură și modalități de realizare ale acestora, noțiuni teoretice privind evoluția modalităților de stocare a datelor și necesitatea automatizării activităților informaționale. De asemenea sunt descrise modelul relațional, limbajul SQL, bazele de date relaționale, sistemele de gestiune a bazelor de date relaționale (SGBDR) împreună cu câteva exemple, prezentȃnd mai în detaliu sistemul MySQL. Tot aici există o prezentare generală a limbajului de programare C#.
Al doilea capitol cuprinde o descriere a etapelor de analiză și proiectare a structurii bazei de date folosite precum și aspecte ale interfeței, incluzând aici tipurile de obiecte, funcții și alte componente ale limbajului C# ce au fost utilizate, precum și modul de realizare a conexiunii cu baza de date, tabelele, tipurile de date folosite și instrucțiunile ce stau la baza dezvoltării bazei de date și interogării acesteia.
Ultimul capitol tratează aspecte legate de funcționalitatea programului GeFinSQL pe fiecare modul. În continuare se va face o descriere în detaliu a modului în care datele sunt introduse în baza de date folosind interfața grafică, exemplificând pentru două societăți comerciale fictive. Prin popularea bazei de date și crearea mai multor utilizatori cu drepturi diferite de acces, se va evidenția faptul că prin intermediul aplicației există un controlul total al datelor. Fiecare utilizator are acces numai la informațiile care îl privesc, atfel asigurăndu-se securitatea tuturor datelor stocate pe server.
În secțiunea Anexe sunt cuprinse fragmente mai relevante din codul sursă, capturi de ecran și alte figuri care ajută la prezentarea anumitor aspecte ale aplicației.
CAPITOLUL 1
NOȚIUNI TEORETICE
Sisteme informatice financiare
Un sistem reprezintă un ansamblu de elemente (componente) interdependente, între care se stabilește o interacțiune dinamică, pe baza unor reguli prestabilite, cu scopul atingerii unui anumit obiectiv.
Interacțiunea dinamică dintre elemente se materializează în fluxurile stabilite între acestea, fluxuri implicând resursele existente.
Conform teoriei sistemelor orice organism economic este un sistem deoarece:
Prezintă o structură proprie constând dintr-o mulțime de elemente constitutive care interacționează între ele pe principii funcționale;
Fluxurile existente între componentele organizatorice implică resursele organismului economic. În cadrul oricărui organism economic se produc fluxuri materiale (de materii prime, semifabricate, produse finite etc), fluxuri financiare și fluxuri informaționale.
Mulțimea componentelor organizatorice și interacțiunea dintre acestea urmăresc realizarea unui anumit obiectiv global: funcționarea firmei în condiții optime sau atingerea unor obiective.
Lucrările în domeniul sistemicii au condus la definirea unui model care promovează viziunea sistemică asupra întreprinderii pe care o consideră formată din următoarele trei subsisteme:
Subsistemul decizional valorifică informațiile oferite de subsistemul informațional în fundamentarea deciziilor.
Subsistemul informațional joacă un dublu rol: pe de o parte asigură toate informațiile necesare luării deciziilor pe toate nivelurile de responsabilitate, conducere și control iar pe de altă parte asigură căile de comunicare între celelalte subsisteme, deoarece deciziile formulate de subsistemul de conducere sunt transmise factorilor de execuție prin subsistemul informațional (flux descendent).
Subsistemul operativ (în cadrul căruia se desfășoară procesele economice specifice domeniului de activitate a agentului economic) are loc culegerea datelor care apoi sunt transmise subsistemului informațional (flux ascendent) în vederea stocării și prelucrării datelor necesare obținerii informațiilor utilizate în fundamentarea deciziior la nivelul subsistemului decizional (de conducere).
Sistem informațional și sistem informatic
Sistemul informațional reprezintă ansamblul tehnico-organizatoric de culegere, transmitere, stocare și prelucrare a datelor în vederea obținerii informațiilor necesare procesului decizional. Subsistemul informațional se interpune între subsistemul decizional și subsistemul operativ având drept scop asigurarea informațiilor necesare staffului managerial reprezentând în același timp un mijloc de comunicare între celelalte două subsisteme. Subsistemul informațional nu trebuie văzut doar ca o interfață între sistemul operativ și sistemul de conducere ci și ca elementul de legătură a mediului intern al firmei și cel exterior lui (mediu economic, financiar, bancar). Scopul principal al sistemului informațional este de a furniza fiecărui utilizator, în funcție de responsabilitățile și atribuțiile sale, toate informațiile necesare.
Sistemul informatic reprezintă o parte a sistemului informațional care permite realizarea operațiilor de culegere, transmitere, stocare, prelucrare a datelor și difuzare a informațiilor astfel obținute prin utilizarea mijloacelor tehnologiei informației (TI) și a personalului specializat în prelucrarea automată a datelor.
Sistemul informatic cuprinde:
ansamblul informațiilor interne și externe, formale sau informale utilizate în cadrul firmei precum și datele care au stat la baza obținerii lor;
software-ul necesar procesării datelor și difuzării informațiilor în cadrul organizației;
procedurile și tehnicile de obținere (pe baza datelor primare) și de difuzare a informațiilor;
platforma hardware necesară prelucrării datelor și disipării informațiilor;
personalul specializat în culegerea, transmiterea, stocarea și prelucrarea datelor.
Sistemul informatic este structurat astfel încât să corespundă cerințelor diferitelor grupuri de utilizatori:
factori de conducere la nivelul conducerii strategice, tactice și operative;
personalul implicat în procesul culegerii și prelucrării datelor;
personalul implicat în procesul cercetării științifice și proiectării de noi produse și tehnologii de fabricație.
Abordări în realizarea sistemelor informatice
În realizarea unui sistem informatic se poate opta pentru una din următoarele soluții:
– sistem informatic centralizat
– sistem informatic descentralizat
Sistemul informatic centralizat se caracterizează prin faptul că întregul proces de stocare și prelucrare a datelor precum și de dezvoltare a sistemului se realizează la nivelul unei singure locații în care se află un singur sistem de calcul, de regulă un mainframe, care stochează o bază de date unică precum și ansamblul programelor de aplicație. Utilizatorii interacționează cu sistemul prin intermediul terminalelor (care au rol de thin-client).
Avantajele centralizării sunt reprezentate de controlul efectiv asupra utilizării și dezvoltării software-ului, controlul asupra securității și integrității datelor, partajarea resurselor hard, soft și a datelor între utilizatori, eliminarea riscului incompatibilității hard și soft în cadrul sistemului, promovarea cu ușurință a standardelor (tehnice, de proiectare, procedurale etc) la nivelul întregului sistem, asigurarea serviciilor solicitate de către utilizatori prin puterea de calcul a sistemului central (mainframe-ul).
Dezavantajele centralizării sunt reprezentate de următoarele aspecte: “căderea“ sistemului de calcul blochează toți utilizatorii, alterarea datelor și a programelor, voită sau accidentală, afectează toți utilizatorii, sistemul se poate dovedi lent și inflexibil la nevoile utilizatorilor, adesea fiind insuficient adaptat nevoilor locale sau de grup ale utilizatorilor, poate realiza un timp mare de răspuns în cazul unor solicitări simultane ale mai multor utilizatori.
Sistemul informatic descentralizat se caracterizează prin faptul că datele, software-ul și puterea de calcul sunt dispersate în diferite locații (chiar dispersate geografic) ale organizației. Prelucrarea se realizează pe calculatoare personale independente sau în cadrul unor rețele locale.
Printre avantajele descentralizării amintim: datele sunt stocate și prelucrate local, soft-ul este mai bine adaptat nevoilor locale, avariile hard, soft sau ale bazei de date la nivelul unei locații nu afectează celelalte locații, configurația sistemului poate fi gândită în funcție de nevoile diferitelor departamente din cadrul organizației sau chiar a utilizatorilor locali, mai marea autonomie și motivare la nivelul utilizatorului local.
Dezavantajele descentralizării sunt: riscuri mari legate de incompatibilități hard și soft între diferite locații, apariția inerentă a unor duplicări ale datelor și software-ului în diferite locații, dificultatea realizării unor proiecte complexe la nivel local, riscul de fragmentare a politicii TI, costuri mai mari în comparație cu sistemul centralizat.
Tendința actuală este net orientată către descentralizare care trebuie să se realizeze astfel încât întreaga responsabilitate și autoritate pentru funcțiile descentralizate ale SI să aparțină managementului local, să se asigure alinierea la standardele utilizate la nivelul SI global al organizației. La nivel central urmează să se realizeze elaborarea strategiei la nivelul întregului SI al organizației, managementul comunicațiilor în cadrul rețelei locale ale organizației, administrarea datelor și refacerea în caz de dezastre.
Astăzi, arhitectura promovată în realizarea sistemelor descentralizate este arhitectura client-server caracterizată prin faptul că aplicațiile și datele puse la dispoziția utilizatorilor sunt dispersate pe diferitele componente hardware în funcție de numărul utilizatorilor care trebuie să aibă acces și de puterea de calcul necesară.
Structura generală a unui sistem informatic
Pentru a defini structura generală a unui sistem informatic este necesar să plecăm de la funcția acestuia de a prelucra datele disponibile în vederea obținerii informațiilor necesare luării deciziilor în procesul conducerii. Cele trei componente majore care formează sistemul informatic sunt: intrările, prelucrăre la nivelul utilizatorului local.
Dezavantajele descentralizării sunt: riscuri mari legate de incompatibilități hard și soft între diferite locații, apariția inerentă a unor duplicări ale datelor și software-ului în diferite locații, dificultatea realizării unor proiecte complexe la nivel local, riscul de fragmentare a politicii TI, costuri mai mari în comparație cu sistemul centralizat.
Tendința actuală este net orientată către descentralizare care trebuie să se realizeze astfel încât întreaga responsabilitate și autoritate pentru funcțiile descentralizate ale SI să aparțină managementului local, să se asigure alinierea la standardele utilizate la nivelul SI global al organizației. La nivel central urmează să se realizeze elaborarea strategiei la nivelul întregului SI al organizației, managementul comunicațiilor în cadrul rețelei locale ale organizației, administrarea datelor și refacerea în caz de dezastre.
Astăzi, arhitectura promovată în realizarea sistemelor descentralizate este arhitectura client-server caracterizată prin faptul că aplicațiile și datele puse la dispoziția utilizatorilor sunt dispersate pe diferitele componente hardware în funcție de numărul utilizatorilor care trebuie să aibă acces și de puterea de calcul necesară.
Structura generală a unui sistem informatic
Pentru a defini structura generală a unui sistem informatic este necesar să plecăm de la funcția acestuia de a prelucra datele disponibile în vederea obținerii informațiilor necesare luării deciziilor în procesul conducerii. Cele trei componente majore care formează sistemul informatic sunt: intrările, prelucrările și ieșirile.
Intrările reprezintă ansamblul datelor încărcate, stocate și prelucrate în cadrul sistemului în vederea obținerii informațiilor.
Prelucrările, cel de al doilea element definitoriu al sistemului informatic, reprezintă un ansamblu omogen de proceduri automate realizând crearea inițială și actualizarea bazei de date, exploatarea bazei de date, reorganizarea bazei de date și salvarea/restaurarea bazei de date.
Ieșirile sistemului informatic sunt reprezentate de rezultatele prelucrărilor desfășurate.
Aceste ieșiri, în funcție de natura prelucrărilor care le-au generat, sunt de două categorii: Ieșiri obținute în urma unor operații de transfer al datelor, care nu și-au modificat valoarea față de momentul introducerii lor în sistem. De exemplu: numărul și data unei facturi, denumirea unui produs, cantitatea facturată etc. A doua categorie de ieșiri sunt cele obținute în urma unor operații de calcul pe baza unor algoritmi prestabiliți (valoarea produsului facturat, total factură, valoarea vânzărilor pe luna…etc).
Tehnologii pentru automatizarea ciclului de prelucrare a datelor financiar-contabile
De mii de ani contabilitatea s-a adaptat la cerințele de informare a celor ce aveau nevoie de informațiile sale. Astfel, de la contabilitatea rudimentară a culturii egiptene, bazată de un sistem contabil simplu, axat pe partida simplă, s-a ajuns la sistemul contabil în partidă dublă, în care se încearcă eliminarea suportului informativ de bază (hârtia) și înlocuirea lui cu un suport mai puțin vulnerabil și mai rapid ca mijloc de culegere, prelucrare și transmitere a datelor financiar-contabile.
Tranziția spre mijloacele de prelucrare și stocare electronică a cunoscut o evoluție în trepte. Primul calculator și primele aplicații de contabilitate au fost inventate în a doua jumătate a secolului XX. Acesta a fost perioada în care un calculator central era folosit de mai mulți utilizatori conectați prin intermediul unor terminale neinteligente. La începuturile lor, aceste sisteme se limitau doar la a reproduce sistemele de contabilitate manuală, adică repetau aceleași proceduri de prelucrare a datelor contabile, dar cu ajutorul calculatorului. În felul acesta se culegeau aceleași date, se generau aceleași informații care erau transmise acelorași destinatari și se menținea aceeași structură organizatorică.
Următorul pas l-a constituit apariția calculatoarelor personale, moment în care a apărut și posibilitatea descentralizării prelucrării datelor. Necesitățile de informare în această perioadă s-au schimbat: conducerile și acționarii firmelor manifestă noi nevoi de informare, mai diverse.
Investitiile în IT din anii 90 au ajutat foarte mult companiile sa se extinda si sa stabileasca retele de date, accelerându-si astfel substantial colectarea de date la nivel de întreprindere. Cu toate acestea capacitatea companiilor de a folosi în întregime aceste date – prelucrarea si transformarea lor în informatii – a ramas în urma; astfel, firmele au o multime de date dar foarte putina informatie la dispozitie.
Tot mai mult în ultima perioada se pune accent pe întelegerea aspectelor unei afaceri prin analiza si rafinarea datelor operatiunilor unei firme. Este un proces ce rezulta din datele colectate la nivel de firma din diverse activitati interne (marketing, vânzari, productie) si/sau externe (comportamentul clientilor sau al competitiei ca raspuns al activitatilor interne). Aceasta colectare este iterativa si ciclica, de aceea datele strânse trebuiesc organizate pentru a facilita transformarea lor în informatie (de ex. raportari, interogari, analize sau prezentari). Finalitatea acestor procese reprezinta un set de decizii ce afecteaza mersul si productivitatea oricarei afaceri. Practic, procesul implica o rafinare a datelor – ele sunt extrase din baze de date (foarte mari în cele mai multe cazuri) si transformate în informatie utilizabila pentru obtinerea de raspunsuri variate la nivel executiv.
Aplicatiile care au apărut sa rezolve aceste probleme permit agregarea si sumarizarea pe categorii specifice si detaliate în acelasi timp, specifice unui anumit proces sau analize, prezentând informatiile exacte si excluzând elementele în plus sau irelevante. Mai specific, se pune accent pe orice sistem informatic care poate micsora distanta dintre acumularea de date si folosirea lor cu un impact direct în îmbunatatirea productivitatii si/sau eficientei unei companii.
Teoria bazelor de date relaționale
Bazele de date relaționale (BDR) utilizează modelul de date relațional și noțiunile aferente. BDR au o solidă fundamentare teoretică, în special prin cercetările de la IBM conduse de E.F.Codd.
Modelul relațional
Modelul relațional a fost propus de către IBM și a revoluționat reprezentarea datelor făcând trecerea la generația a doua de baze de date. Modelul este simplu, are o solidă fundamentare teoretică fiind bazat pe teoria seturilor (ansamblurilor) și pe logica matematică. Pot fi reprezentate toate tipurile de structuri de date de mare complexitate, din diferite domenii de activitate.
Modelul relațional este definit prin: structura de date, operatorii care acționează asupra structurii și restricțiile de integritate.
1) Conceptele utilizate pentru definirea structurii de date sunt: domeniul, tabela (relația), atributul, tuplul, cheia și schema tabelei.
Domeniu este un ansamblu de valori caracterizat printr-un nume. El poate fi explicit sau implicit. Tabela/relația este un subansamblu al produsului cartezian al mai multor domenii, caracterizat printr-un nume, prin care se definesc atributele ce aparțin aceleași clase de entități. Atributul este coloana unei tabele, caracterizată printr-un nume. Cheia este un atribut sau un ansamblu de atribute care au rolul de a identifica un tuplu dintr-o tabelă. Tipuri de chei: primare/alternate, simple/comune, externe. Tuplul este linia dintr-o tabelă și nu are nume. Ordinea liniilor (tupluri) și coloanelor (atribute) dintr-o tabelă nu trebuie să prezinte nici-o importanță. Schema tabelei este formată din numele tabelei, urmat între paranteze rotunde de lista atributelor, iar pentru fiecare atribut se precizează domeniul asociat.
Schema bazei de date poate fi reprezentată printr-o diagramă de structură în care sunt puse în evidență și legăturile dintre tabele. Definirea legăturilor dintre tabele se face logic construind asocieri între tabele cu ajutorul unor atribute de legătură. Atributele implicate în realizarea legăturilor se găsesc fie în tabelele asociate, fie în tabele distincte construite special pentru legături. Atributul din tabela inițială se numește cheie externă iar cel din tabela finală este cheie primară. Legăturile posibile sunt 1:1, 1:m, m:m. Potențial, orice tabelă se poate lega cu orice tabelă, după orice atribute.
Legăturile se stabilesc la momentul descrierii datelor prin limbaje de descriere a datelor (LDD), cu ajutorul restricțiilor de integritate. Practic, se stabilesc și legături dinamice la momentul execuției.
2) Operatorii modelului relațional sunt operatorii din algebra relațională și operatorii din calculul relațional.
Algebra relațională este o colecție de operații formale aplicate asupra tabelelor (relațiilor), și a fost concepută de E.F.Codd. Operațiile sunt aplicate în expresiile algebrice relaționale care sunt cereri de regăsire. Acestea sunt compuse din operatorii relaționali și operanzi. Operanzii sunt întotdeauna tabele (una sau mai multe). Rezultatul evaluării unei expresii relaționale este format dintr-o singură tabelă. Algebra relațională are cel puțin puterea de regăsire a calcului relațional. O expresie din calculul relațional se poate transforma într-una echivalentă din algebra relațională și invers.
Codd a introdus șase operatori de bază (reuniunea, diferența, produsul cartezian, selecția, proiecția, joncțiunea) și doi operatori derivați (intersecția și diviziunea). Ulterior au fost introduși și alți operatori derivați (speciali). În acest context, operatorii din algebra relațională pot fi grupați în două categorii: pe mulțimi și speciali.
Algebra relațională este prin definiție neprocedurală (descriptivă), iar calculul relațional permite o manieră de căutare mixtă (procedurală/neprocedurală).
Calculul relațional se bazează pe calculul predicatelor de ordinul întâi (domeniu al logicii) și a fost propus de E.F. Codd. Predicatul este o relație care se stabilește între anumite elemente și care poate fi confirmată sau nu. Predicatul de ordinul 1 este o relație care are drept argumente variabile care nu sunt predicate. Variabila poate fi de tip tuplu (valorile sunt dintr-un tuplu al unei tabele) sau domeniu (valorile sunt dintr-un domeniu al unei tabele). Cuantificatorii (operatorii) utilizați în calculul relațional sunt: universal (∀) și existențial (∃).
Construcția de bază în calculul relațional este expresia relațională de calcul tuplu sau domeniu (funcție de tipul variabilei utilizate).
Expresia relațională de calcul este formată din: operația de efectuat, variabile (tuplu respectiv domeniu), condiții (de comparație, de existență), formule bine definite (operanzi-constante, variabile, funcții, predicate; operatori), cuantificatori.
Pentru implementarea acestor operatori există comenzi specifice în limbajele de manipulare a datelor (LMD) din sistemele de gestiune a bazelor de date relaționale (SGBDR). Aceste comenzi sunt utilizate în operații de regăsire (interogare).
După tehnica folosită la manipulare, LMD sunt bazate pe:
calculul relațional (QUEL în Ingres, ALPHA propus de Codd);
algebra relațională (ISBL, RDMS);
transformare (SQL, SQUARE);
grafică (QBE, QBF).
Transformarea oferă o putere de regăsire echivalentă cu cea din calculul și algebra relațională. Se bazează pe transformarea (mapping) unui atribut sau grup de atribute într-un atribut dorit prin intermediul unor relații. Rezultatul este o relație (tabelă) care se poate utiliza într-o altă transformare.
Grafica oferă interactivitate mare pentru constrirea cererilor de regăsire. Utilizatorul specifică cerea alegând sau completând un ecran structurat grafic. Poate fi folosit de către toate categoriile de utilizatori în informatică.
3) Restricțiile de integritate ale modelului relațional sunt structurale și comportamentale.
Restricțiile structurale sunt:
Restricția de unicitate a cheii. Într-o tabelă nu trebuie să existe mai multe tupluri cu aceeași valoare pentru ansamblul cheie;
Restricția referențială. Intr-o tabelă t1 care referă o tabelă t2, valorile cheii externe trebuie să figureze printre valorile cheii primare din t2 sau să ia valoarea null (neprecizat);
Restricția entității. Intr-o tabelă, atributele din cheia primară nu trebuie să ia valoarea NULL.
Pe lângă acestea, există o serie de alte restricții structurale care se referă la dependențele dintre date: funcționale, multivaloare, joncțiune etc. (sunt luate în considerare la tehnicile de proiectare a bazelor de date relaționale – BDR).
Restricțiile de comportament sunt cele care se definesc prin comportamentul datelor și țin cont de valorile din BDR:
Restricția de domeniu. Domeniul corespunzător unui atribut dintr-o tabelă trebuie să se încadreze între anumite valori;
Restricții temporare. Valorile anumitor atribute se compară cu niște valori temporare (rezultate din calcule etc.).
Restricțiile de comportament fiind foarte generale se gestionează fie la momentul descrierii datelor (de exemplu prin clauza CHECK), fie în afara modelului la momentul execuției.
Baze de date relationale
BDR este un ansamblu organizat de tabele (relații) împreună cu legăturile dintre ele. Bazele de date relaționale au evoluat ca un tip special de aplicații informatice, și anume cele care au organizarea datelor în memoria externă conform unui model de date specific. De aceea, în metodologia de realizare a BDR se parcurg, în cea mai mare parte, cam aceleași etape ca la realizarea unei aplicații informatice, cu o serie de aspecte specifice. Pe de altă parte, în literatura de specialitate, sunt diferite propuneri de metodologii de realizare a bazelor de date.
Ținând cont de cele două aspecte de mai sus, sunt propuse câteva actvivități care trebuie parcurse la realizarea unei baze de date. Aceste activități vor fi regăsite, sub aceeași denumire sau sub denumiri diferite, în majoritatea metodologiilor de realizare a bazelor de date, din literatura de specialitate.
Activitățile (etapele) parcurse pentru realizarea unei BDR sunt: analiza de sistem, proiectarea noului sistem, realizarea componentelor logice, punerea în funcțiune, dezvoltarea.
1) Scopul analizei de sistem este de a evidenția cerințele aplicației și resursele utilizate (studiul), precum și de a evalua aceste cerințe prin modelare (analiza).
2) Proiectarea structurii bazei de date se face pe baza modelelor realizate în activitatea de analiză. Inainte de proiectarea bazei de date se alege tipul de sistem de gestiune a bazei de date. Alegerea SBGD-ului se face ținând cont de două aspecte: cerințele aplicației (utilizatorului) și performanțele tehnice ale SGBD-ului. Cerințele aplicației se referă la: volumul de date estimat a fi memorat și prelucrat în BDR; complexitatea problemei de rezolvat; ponderea și frecvența operațiilor de intrare/ieșire; condițiile privind protecția datelor; operațiile necesare (încărcare/validare, actualizare, regăsire etc.); particularitățile activității pentru care se realizează baza de date. Performanțele tehnice ale SGBD-ului se referă la: modelul de date pe care-l implementează; ponderea utilizării SGBD-ului pe piață și tendința; configurația de calcul minimă cerută; limbajele de programare din SGBD; facilitățile de utilizare oferite pentru diferite categorii de utilizatori; limitele SGBD-ului; optimizările realizate de SGBD; facilitățile tehnice; lucrul cu mediul distribuit și concurența de date; elementele multimedia; instrumentele CASE; interfețele de comunicare; posibilitatea de autodocumentare; instrumentele specifice oferite.
Proiectarea BDR se realizează prin proiectarea schemelor BDR și proiectarea modulelor funcționale specializate.
Schemele bazei de date sunt: conceptuală, externă și internă.
a) Proiectarea schemei conceptuale pornește de la identificarea setului de date necesar sistemului. Aceste date sunt apoi integrate și structurate într-o schemă (exemplu: pentru BDR relaționale cea mai utilizată tehnică este normalizarea). Pentru acest lucru se parcurg pașii:
Stabilirea schemei conceptuale inițiale care se deduce din modelul entitate-asociere (vezi analiza structurală). Pentru acest lucru, se transformă fiecare entitate din model într-o colecție de date (fișier), iar pentru fiecare asociere se definesc cheile aferente. Dacă rezultă colecții izolate, acestea se vor lega de alte colecții prin chei rezultând asocieri (1:1, 1:m, m:n).
Ameliorarea progresivă a schemei conceptuale prin eliminarea unor anomalii (exemplu: cele cinci forme normale pentru BDR relaționale).
Stabilirea schemei conceptuale finale trebuie să asigure un echilibru între cerințele de actualizare și performanțele de exploatare (exemplu: o formă normală superioară asigură performanțe de actualizare, dar timpul de răspuns va fi mai mare).
Tehnica de normalizare este utilizată în activitatea de proiectare a structurii BDR și constă în eliminarea unor anomalii (neajunsuri) de actualizare din structură.
Anomaliile de actualizare sunt situații nedorite care pot fi generate de anumite tabele în procesul proiectării lor:
Anomalia de ștergere semnifică faptul că stergând un tuplu dintr-o tabelă, pe lângă informațiile care trebuie șterse, se pierd și informațiile utile existente în tuplul respectiv;
Anomaliile de adăugare semnifică faptul că nu pot fi incluse noi informații necesare într-o tabelă, deoarece nu se cunosc și alte informații utile (de exemplu valorile pentru cheie);
Anomalia de modificare semnifică faptul că este dificil de modificat o valoare a unui atribut atunci când ea apare în mai multe tupluri.
Normalizarea este o teorie construită în jurul conceptului de forme normale (FN), care ameliorează structura BDR prin înlăturarea treptată a unor neajunsuri și prin imprimarea unor facilități sporite privind manipularea datelor.
Normalizarea utilizează ca metodă descompunerea (top-down) unei tabele în două sau mai multe tabele, păstrând informații (atribute) de legătură.
FN1. O tabelă este în FN1 dacă toate atributele ei conțin valori elementare (nedecompozabile), adică fiecare tuplu nu trebuie să aibă date la nivel de grup sau repetitiv. Structurile de tip arborescent și rețea se transformă în tabele cu atribute elemntare. O tabelă în FN1 prezintă încă o serie de anomalii de actualizare datorită eventualelor dependențe funcționale incomplete. Fiecare structură repetitivă generează (prin descompunere) o nouă tabelă, iar atributele la nivel de grup se înlătură, rămânând doar cele elemntare.
FN2. O tabelă este în FN2 dacă și numai dacă este în FN1 și fiecare atribut noncheie al tabelei este dependent funcțional complet de cheie. Un atribut B al unei tabele depinde funcțional de atributul A al aceleiași tabele, dacă fiecărei valori a lui A îi corespunde o singură valoare a lui B, care îi este asociată în tabelă. Un atribut B este dependent funcțional complet de un ansamblu de atribute A în cadrul aceleiași tabele, dacă B este dependent funcțional de întreg ansamblul A (nu numai de un atribut din ansamblu). O tabelă în FN2 prezintă încă o serie de anomalii de actualizare, datorită eventualelor dependențe tranzitive. Eliminarea dependențelor incomplete se face prin descompunerea tabelei inițiale în două tabele, ambele conținând atributul intermediar (B).
FN3. O tabelă este în FN3 dacă și numai dacă este în FN2 și fiecare atribut noncheie depinde în mod netranzitiv de cheia tabelei. Într-o tabelă T, fie A,B,C trei atribute cu A cheie. Dacă B depinde de A și C depinde de B atunci C depinde de A în mod tranzitiv. Eliminarea dependențelor tranzitive se face prin descompunerea tabelei inițiale în două tabele, ambele conținând atributul intermediar (B). O tabelă în FN3 prezintă încă o serie de anomalii de actualizare, datorate eventualelor dependențe multivaloare. O definiție mai riguroasă pentru FN3 a fost dată prin forma intermediară BCNF (Boyce Codd Normal Form): o tabelă este în BCNF dacă fiecare determinant este un candidat cheie.Determinantul este un atribut elementar sau compus față de care alte atribute sunt complet dependente funcțional.
FN4. O tabelă este în FN4 dacă și numai dacă este în FN3 și nu conține două sau mai multe dependențe multivaloare. Într-o tabelă T, fie A,B,C trei atribute. În tabela T se menține dependența multivaloare A dacă și numai dacă mulțimea valorilor lui B ce corespunde unei perechi de date (A,C), depinde numai de o valoare a lui A și este independentă de valorile lui C.
FN5. O tabelă este în FN5 dacă și numai dacă este în FN4 și fiecare dependență joncțiune este generată printr-un candidat cheie al tabelei. În tabela T (A,B,C) se menține dependența joncțiune (AB, AC) dacă și numai dacă T menține dependența multivaloare A –>> B sau C.
Dependența multivaloare este caz particular al dependenței joncțiune. Dependența funcțională este caz particular al dependenței multivaloare.
b) Proiectare schemei externe are rolul de a specifica viziunea fiecărui utilizator asupra BDR. Pentru acest lucru, din schema conceptuală se identifică datele necesare fiecărei viziuni. Datele obținute se structurează logic în subscheme ținând cont de facilitățile de utilizare și de cerințele utilizator. Schema externă devine operațională prin construirea unor viziuni (view) cu SGBD-ul și acordarea drepturilor de acces. Datele într-o viziune pot proveni din una sau mai multe colecții și nu ocupă spațiul fizic.
c) Proiectarea schemei interne presupune stabilirea structurilor de memorare fizică a datelor și definirea căilor de acces la date. Acestea sunt specifice fie SGBD-ului (scheme de alocare), fie sistemului de operare. Proiectarea schemei interne înseamnă estimarea spațiului fizic pentru BDR, definirea unui model fizic de alocare (a se vedea dacă SGBD-ul permite explicit acest lucru) și definirea unor indecși pentru accesul direct, după cheie, la date.
Proiectarea modulelor funcționale ține cont de concepția generală a BDR, precum și de schemele proiectate anterior. În acest sens, se proiectează fluxul informațional, modulele de încărcare și manipulare a datelor, interfețele specializate, integrarea elementelor proiectate cu organizarea și funcționarea BDR.
3) Realizarea componentelor logice. Componentele logice ale unei BD sunt programele de aplicație dezvoltate, în cea mai mare parte, în SGBD-ul ales. Programele se realizează conform modulelor funcționale proiectate în etapa anterioară. Componentele logice țin cont de ieșiri, intrări, prelucrări și colecțiile de date. În paralel cu dezvoltarea programelor de aplicații se întocmesc și documentațiile diferite (tehnică, de exploatare, de prezentare).
4) Punerea în funcțiune și exploatarea. Se testează funcțiile BDR mai întâi cu date de test, apoi cu date reale. Se încarcă datele în BDR și se efectuează procedurile de manipulare, de către beneficiar cu asistența proiectantului. Se definitivează documentațiile aplicației. Se intră în exploatare curentă de către beneficiar conform documentațiiei.
5) Dezvoltarea sistemului. Imediat după darea în exploatare a BDR, în mod continuu, pot exista factori perturbatori care generează schimbări în BDR. Factorii pot fi: organizatorici, datorați progresului tehnic, rezultați din cerințele noi ale beneficiarului, din schimbarea metodologiilor etc.
Definirea sistemului de gestiune a bazelor de date relaționale (SGBDR)
Teoria relațională, foarte bine pusă la punct într-un domeniu de cercetare distinct, a dat o fundamentare solidă realizării de SGBD-uri performante. La sfârșitul anilor 80 și apoi în anii 90 au apărut, în special o dată cu pătrunderea în masă a microcalculatoarelor, numeroase SGBDR-uri. Aceasta a însemnat o evoluție de la SGBD-urile de generația întâi (arborescente și rețea) spre cele de generația a doua (relaționale). Această evoluție s-a materializat, în principal în: oferirea de limbaje de interogare neprocedurale, îmbunătățirea integrității și securității datelor, optimizarea și simplificarea acceselor.
Teoria relațională este un ansamblu de concepte, metode și instrumente care a dat o fundamentare riguroasă realizării de SGBDR performante. E.F. Codd (cercetător la IBM) a formulat 13 reguli care exprimă cerințele maximale pentru ca un SGBD să fie relațional. Regulile sunt utile pentru evoluarea performanțelor unui SGBDR.
Regulile lui Codd sunt greu de indeplinit în totalitate de către SGBDR. Pornind de la cele 13 reguli de mai sus, au fost formulate o serie de criterii (cerințe) pe care trebuie să le îndeplinească un SGBD pentru a putea fi considerat relațional într-un anumit grad. S-a ajuns astfel, la mai multe grade de relațional pentru SGBDR: cu interfață relațională (toate datele se reprezintă în tabele, există operatorii de selecție, proiecție și joncțiune doar pentru interogare), pseudorelațional (toate datele se reprezintă în tabele, există operatorii de selecție, proiecție și joncțiune fără limitări), minimal relațional (este pseudorelațional și în plus, operațiile cu tabele nu fac apel la pointeri observabili de utilizatori), complet relațional (este minimal relațional și în plus, există operatorii de reuniune, intersecție și diferență, precum și restricțiile de integritate privind unicitatea cheii și restricția referențială).
În concluzie, SGBDR este un sistem software complet care implementeză modelul de date relațional și respectă cerințele impuse de acest model. El este o interfață între utilizatori și baza de date.
Caracterizarea SGBDR
Sistemele relaționale îndeplinesc funcțiile unui SGBD cu o serie de aspecte specifice care rezultă din definirea unui SGBDR.
Caracterizarea SGBDR se poate face pe două niveluri: global (sistemele relaționale sunt privite ca o categorie distinctă de SGBD) și particular (fiecare SGBDR are aspecte individuale comparativ cu altele similare).
A. Mecanismele și instrumentele care ajută la caracterizarea globală a SGBDR-urilor sunt: limbajele relaționale, protecția datelor, optimizarea cererilor de regăsire, utilitarele specializate.
1) Limbajele relaționale: SGBDR oferă seturi de comenzi pentru descrierea și manipularea datelor. Acestea pot fi incluse într-un singur limbaj relațional (SQL, QUEL, QBE, SQUARE, ALPHA, ISBL) sau separate în LDD și LMD. În ambele situații, comenzile pentru definirea datelor sunt distincte de cele pentru manipularea datelor.
Limbajele relaționale de definire a datelor (LDD) sunt simplificate, cu puține comenzi. Descrierea datelor este memorată în BDR, sub formă de tabele, în dicționarul (metabaza) bazei de date. Facilități de descriere sunt prezente în SGBDR prin comenzi, care definesc anumite operații, la nivelurile: conceptual, logic, fizic.
Caracterizarea generală a LMD se face după modul de tratare a datelor, operatorii relaționali, realizatorii și utilizatorii limbajului. Toate LMD relaționale realizează o tratare la nivel de ansamblu a datelor: unitatea de informative pentru lucru este tabela. Avantajele sunt date de posibilitatea gestionării automat a tuplurilor duplicate și prelucrarea paralelă a ansamblurilor.
La comunicarea unui LMD relational cu un limbaj universal, avantajele se pierd deoarece comunicarea se poate face doar tuplu cu tuplu și nu la nivel de ansamblu. Deoarece limbajele universale oferă alte avantaje legate de proceduralitate, soluția este de a integra în acestea un limbaj relațional. Cursorul este soluția în SGBDR pentru a face trecerea de la tratarea la nivel de ansamblu la cea la nivel de înregistrare (tuplu).
Caracterizarea funcțională a LMD se face după facilitățile de interogare, actualizare a datelor, etc. Facilitățile de interogare a datelor sunt puternice și oferite prin comenzi pentru interogarea tabelelor de bază și interogarea tabelelor virtuale (exemplu SELECT).
Facilitățile de actualizare a datelor se referă la actualizarea tabelelor de bază și a tabelelor virtuale prin comenzile: INSERT INTO (adaugă rânduri la sfârșitul unei tabele); UPDATE ( modifică rânduri dintr-o tabelă); DELETE FROM (șterge rânduri dintr-o tabelă). Unele SGBDR nu permit actualizarea tabelelor virtuale (exemplu Foxpro), altele permit acces lucru cu o serie de restricții pentru ca operația să se propage spre tabelele de bază fără ambiguități.
Caracterizarea calitativă a LMD se face după puterea selectivă, ușurința de învățare, utlizare și eficiența limbajului. Puterea selectivă a LMD relaționale este dată de posibilitatea selectării datelor după criterii (filtre) complexe (exemplu comanda SELECT). Ușurința de învățare și utilizare este nuanțată în funcție de tipul LMD-ului relațional. Cele bazate pe calculul relațional sunt neprocedurale (descriptive), deci ușor de învățat și utilizat (apropiat, ca stil, de limbajul natural) (exemplu QUEL) iar cele bazate pe algebra relațională sunt procedurale (algoritmice), deci mai greu de învățat și utilizat (exemplu ISBL). Cele intermediare promovează stilul neprocedural dar acceptă și elemente de control procedural (exemplu SQL) iar cele bazate pe grafică oferă primitive grafice pentru machetarea cererilor de regăsire, deci ușor de utilizat (exemplu QBE). Eficiența utilizării este determinată de posibilitatea optimizării cererilor de regăsire. LMD bazate pe calculul relațional lasă compilatorul să aleagă ordinea de execuție a operațiilor, deci rezultă o eficiența mare. LMD bazate pe algebra relațională au o ordine impusă pentru execuția operațiilor, deci rezultă o eficiență mica.
2) Aspectele privind protecția datelor sunt foarte importante pentru un sistem de bază de date și ele trebuie implementate de către SGBDR. Protecția bazei de date se referă la integritatea datelor (integritatea semantică, concurența la date, salvarea/restaurarea) și securitatea datelor (autorizarea accesului, viziunile, procedurile speciale, criptarea).
a) Integritatea semantică. Definirea restricțiilor de integritate se face, conform cerințelor modelului relațional, în LDD (exemplu CREATE TABLE, ALTER TABLE). Utilizarea restricțiilor de integritate se face cu ajutorul unor mecanisme care controlează validitatea regulilor pentru fiecare nouă stare a BD. Aceste mecanisme sunt metode de detectare a inconsistenței datelor (se verifică restrcițiile de integritate) la sfârșitul tranzacțiilor, care se realizează automat de SGBDR și puncte de verificare a integrității fixate de utilizator, acolo unde dorește el în program.
b) Concurența la date (coerența). Unitatea de lucru pentru asigurarea coerenței datelor este tranzacția. Aceasta este un ansamblu de comenzi tratate unitar. Tranzacția se execută în totalitate sau deloc. Coerența poate fi afectată la actualizarea concurentă sau la incidente.
3) Cererile de regăsire se exprimă în SGBDR în diferite limbaje relaționale. Pentru a se obține un rezultat optim, se utilizează interfețe automate de rescriere a cererilor de regăsire, prin parcurgerea a doi pași:
Exprimarea cererilor de regăsire sub forma unor expresii algebrice relaționale, care are la bază echivalența dintre calculul și algebra relațională .
Aplicarea unor transformări algebrice relaționale asupra expresiilor construite în pasul anterior, pentru a se obține expresii relaționale echivalente și eficiente.
Transformarea se poate realiza prin doua strategii de optimizare: generale, specifice.
Strategiile generale sunt independente de modul de memorare a datelor. Ele se bazează pe propietățile operațiilor din algebra relațională (comutativitatea, asociativitatea, compunerea). Astfel de strategii sunt: selecția înaintea joncțiunii, proiecția înaintea joncțiunii, selecția înaintea proiecției, combinarea selecției multiple.
Strategiile specifice țin cont de modul de memorare a datelor și ele sunt caracteristice unui SGBDR. Elementele care influențează executarea operațiilor ce intervin la o cerere de regăsire sunt: accesul direct, reguli de ordonare a expresiilor algebrice specifice unui SGBDR.
4) Posibilitatile de utilizare ale unui SGBDR sunt influențate de utilitarele specializate pe care le are, pentru diferitele categorii de utilizatori (în Oracle: Developer pentru dezvoltatori, Designer pentru analiști, Administration Tools și Utilities pentru administrator etc.).
B. Pentru a face o caracterizare particulară,un anumit SGBDR vom lua în considerare o serie de criterii de comparație. Aceste criterii se vor urmări, grupate pe anumite categorii, pentru câteva SGBDR-uri care ne interesează. După această analiză vom avea un argument serios pentru a putea alege un SGBDR în scopul dezvoltării unei aplicații cu baze de date.
Gruparea caracteristicilor particulare de comparație a SGBDR-urilor o vom face în funcție de facilitățile de descriere, manipulare, utilizare și administrare a datelor. Caracteristicile în funcție de facilitățile de descriere sunt: modul de implementare a modelului relațional; conceptul de bază de date utilizat în schemă; definirea metadatelor; definirea relațiilor virtuale; actualizarea schemei relației; restricțiile de integritate ce pot fi declarate. Caracteristicile în funcție de facilitățile de manipulare sunt: LMD relațional implementat; funcțiile de calcul aritmetic și funcțiile agregate; modurile de acces la date; programarea orientată-obiect; tratarea valorii NULL; optimizarea cererilor de regăsire; actualizarea relațiilor de bază și virtuale. Caracteristicile în funcție de facilitățile de utilizare și administrare sunt: instrumentele de dezvoltare; instrumentele CASE; instrumentele analize statistice; software-ul pentru acces de la distanță; utilitarele de întreținere; mecanismele pentru autorizarea accesului la date.
Exemple de SGBDR
Oracle. Este realizat de firma Oracle Corporation USA. Sistemul este complet relațional, robust, se bazează pe SQL standard extins. Arhitectura sistemului este client/server, permțând lucrul, cu obiecte și distribuit. Are BD Internet și modul de optimizare a regăsirii. Ultima versiune este Oracle 10g.
DB2. Este realizat de firma IBM. Sistemul respectă teoria relațională, este robust și se bazează pe SQL standard. Permite lucrul distribuit și are modul de optimizare a regăsirii.
Informix. Este realizat de firma Informix, respectă teoria relațională și permite lucru distribuit.
Progress. Este realizat de firma Progress Software. Are limbaj propriu (Progress 4GL) dar suportă și SQL. Rulează pe o gamă largă de calculatoare sub diferite sisteme de operare.
SQL Server. Este realizat de firma Microsoft. Se bazează pe SQL și rulează în arhitectura client/server.
Ingress II. Este realizat de firma Computer Associates. Este un SGBDR complet, implementează două limbaje relaționale (întâi QUEL și apoi SQL) și este suportat de diferite sisteme de operare (Windows, UNIX). Lucrează distribuit în arhitectura client/server, are extensie cu facilități orientate obiect și permite aplicații de tip Internet. Organizarea fizică a tabelelor se face prin sistemul de operare.
Visual FoxPro. Este realizat de firma Microsoft. Are un limbaj procedural propiu foarte puternic, o extensie orientată obiect, programare vizuală și nucleu extins de SQL.
Access. Este realizat de firma Microsoft. Se bazează pe SQL, are limbajul procedural gazdă (Basic Access) și instrumente de dezvoltare.
Paradox. Este realizat de firma Borland. Are limbaj procedural propiu (PAL) și suportă SQL.
MySQL este un sistem de gestiune a bazelor de date relațional, produs de compania suedeză MySQL AB și distribuit sub Licența Publică Generală GNU. Este cel mai popular SGBD open-source la ora actuală, fiind o componentă cheie a stivei LAMP (Linux, Apache, MySQL, PHP).
Deși este folosit foarte des împreună cu limbajul de programare PHP, cu MySQL se pot construi aplicații în orice limbaj major. Există multe scheme API disponibile pentru MySQL ce permit scrierea aplicațiilor în numeroase limbaje de programare pentru accesarea bazelor de date MySQL, cum are fi: C, C++, C#, Borland Delphi, Java, Perl, PHP, Python, FreeBasic, etc., fiecare dintre acestea folosind un tip spefic API. O interfață de tip ODBC denumită MyODBC permite altor limbaje de programare ce folosesc această interfață, să interacționeze cu bazele de date MySQL cum ar fi ASP sau Visual Basic. În sprijinul acestor limbaje de programare, unele companii produc componente de tip COM/COM+ sau .NET (pentru Windows) prin intermediul cărora respetivele limbaje să poată folosi acest SGBD mult mai ușor decât prin intermediul sistemului ODBC. Aceste componente pot fi gratuite (ca de exemplu MyVBQL) sau comerciale.
Licența GNU GPL nu permite încorporarea MySQL în softuri comerciale; cei care doresc să facă acest lucru pot achiziționa, contra cost, o licență comercială de la compania producătoare, MySQL AB.
MySQL este componentă integrată a platformelor LAMP sau WAMP (Linux/Windows-Apache-MySQL-PHP/Perl/Python). Popularitatea sa ca aplicație web este strâns legată de cea a PHP-ului care este adesea combinat cu MySQL și denumit Duo-ul Dinamic. În multe cărți de specialitate este precizat faptul ca MySQL este mult mai ușor de invățat și folosit decât multe din aplicațiile de gestiune a bazelor de date, ca exemplu comanda de ieșire fiind una simplă și evidentă: „exit” sau „quit”.
Pentru a administra bazele de date MySQL se poate folosi modul linie de comandă sau, prin descărcare de pe internet, o interfață grafică: MySQL Administrator și MySQL Query Browser. Un alt instrument de management al acestor baze de date este aplicația gratuită, scrisă în PHP, phpMyAdmin.
MySQL poate fi rulat pe multe dintre platformele software existente: AIX, FreeBSD, GNU/Linux, Mac OS X, NetBSD, Solaris, SunOS, Windows 9x/NT/2000/XP/Vista.
Interfața cu utilizatorul
Interfața asigură un mecanism de interacțiune utilizator – aplicație. Din punct de vedere arhitectural, o interfață este costituita din: ferestre (form-uri), controale și meniuri.
Form-urile sunt fundația pe care se construiește interfața cu utilizatorul. În general acestea conțin un număr de opțiuni sau informații necesare aplicației, dar pot și să recepționeze comenzile utilizatorilor. Spre deosebire de aplicațiile consola, interfețele grafice se caracterizează printr-o interacțiune bogată cu utilizatorii.
Form-urile Windows sunt noua platformă pentru aplicațiile Microsoft Windows, bazate pe .Net Framework. Acest mediu asigură un set de clase extensibile, clare, orientate pe obiect, care permit dezvoltarea de aplicații Windows îmbunătățite.
Un form este o parte din ecran, de obicei de formă rectangulară, utilizată pentru a prezenta informații utilizator, și pentru accepta informații de la utilizator. Cel mai ușor mod de a defini interfața utilizator pentru un form este de a plasa controale pe suprafața acesteia. Ca toate obiectele din .Net Framework, formurile sunt instanțe ale claselor.
Clasa Control implementează funcționalități de bază cerute de clasele care afișează informații utilizatorului. De asemenea intrările de la tastatură și de la dispozitivele de pointare. Controalele reprezintă legătura care ajută ca informația și opțiunile să fie accesibile utilizatorilor. Meniurile asigură o modalitate structurată pentru expunerea comenzilor disponibile utilizatorilor aplicației. Meniurile sunt de obicei folosite pentru accesul la comenzi de un nivel mai înalt, care ar putea fi comune tuturor componentelor aplicatiei, de exemplu salvarea sau ieșirea din aplicație. Comenzile pot fi afișate într-o ordine și manieră uzuale, care să ajute utilizatorii să se obișnuiască repede cu aplicația.
Limbajul de programare C#
C# este un limbaj de programare orientat pe obiecte asemănător limbajului C++. El a fost dezvoltat de firma Microsoft, ca soluție standard pentru dezvoltarea aplicațiilor Windows. Creatorii lui sunt Anders Hejlsberg (autor al limbajelor Turbo Pascal și Delphi), Scot Wiltamuth și Peter Golde.
C# respectă standardul ECMA-334 (European Computer Manufactures Association).
Limbajul C# folosește Microsoft .NET Framework, o colecție de clase care poate fi descărcată prin Internet și care este întreținută și ameliorată permanent de Microsoft. Prima versiune datează din 2001, deci toată această soluție tehnologică este de dată recentă.
Clasele conținute în .NET sunt neutre față de limbaj (aplicațiile pot fi scrise în diverse limbaje) și ușurează munca de programare în realizarea interfețelor aplicațiilor, accesul la date, conectarea la servere de baze de date, accesarea resurselor din Internet, programarea aplicațiilor bazate pe comunicații prin rețele, etc..
Aplicațiile care folosesc .NET sunt executate într-un mediu software denumit CLR (Common Language Runtime). Acesta poate fi asimilat unui procesor virtual, asemănător mașinii virtuale Java, care furnizează servicii de management a resurselor calculatorului, asigurare a stabilității și securității execuției. Deși Microsoft a conceput CLR ca soluție destinată propriilor sisteme de operare, la ora actuală există astfel de procesoare virtuale și pentru alte sisteme de operare. Astfel, în cadrul proiectului Mono – www.gomono.com, susținut de compania Novell, s-au dezvoltat soluții alternative pentru Linux, Solaris, Mac OS, BSD, HP-UX, și chiar Windows, asigurându-se astfel portabilitatea aplicațiilor scrise în limbaje bazate pe .NET.
Dezvoltarea de aplicații în C# se realizează folosind un mediu de programare, firma Microsoft oferind mediul profesional Visual C# .NET.
CAPITOLUL 2
APLICAȚIA DE GESTIUNE FINANCIARĂ GEFINSQL
ANALIZĂ ȘI PROIECTARE
Analiza de sistem
Scopul analizei de sistem este de a evidenția cerințele aplicației și resursele utilizate (studiul), precum și de a evalua aceste cerințe prin modelare.
Definirea cerințelor
Se dorește realizarea unui produs program pentru evidența intrărilor și iesirilor de produse și marfă și gestiunea acestora într-un plan de conturi. De asemenea se dorește menținerea unor evidențe privind alte aspecte ale unei societăți comerciale, cum ar fi salariații, agenții, furnizorii și clienții acesteia. Programul trebuie sa țină evidența mai multor societatăți simultan.
Datele și evenimentele aplicației
Pornind de la cerințele aplicației se identifică entitățile ce vor fi incluse în proiectarea programului: fenomene, procese, obiecte concrete sau abstracte. Evenimentele principale ce vor fi incluse în proiectarea aplicației sunt următoarele:
Adăugarea unei intrări
Pe baza analizelor făcute anterior, când firma are nevoie de o anumită marfa/produs se produce o intrare în gestiune, adica o comandă către un furnizor. Se verifică daca există un contract valabil cu furnizorul respectiv și dacă acesta este expirat, se face prelungirea contractului.
Datele evenimentului:
Despre intrare: numărul documentului, furnizorul, valoarea intrării
Despre furnizor: nume, contul pe care se face intrarea în contabilitate, adresa furnizorului, codul unic de înregistrare, data expirării contractului și contul pe care se va efectua plata
Adăugarea unei ieșiri
Ieșirile în gestiunea firmei se referă la comenzile de marfă/produse pe care societatea le primește de la diferiți clienți. La adăugarea unei ieșiri,se verifică daca există un contract valabil cu clientul respectiv și dacă acesta este expirat, se face prelungirea contractului.
Datele evenimentului:
Despre ieșire: numărul documentului, clientul, valoarea ieșirii
Despre client: nume, contul pe care se face ieșirea din contabilitate, adresa clientului, codul unic de înregistrare, data expirării contractului și contul pe care se va efectua încasarea
Adăugarea/ștergerea articolelor pe/de pe un document
Fiecare document intrare/ieșire poate conține unul sau mai multe articole (marfă/produse). Valoarea cumulată a acestor articole va constitui valoarea totala a documentului. La adăugarea unui articol se verifică dacă s-a efectuat deja intrarea documentului în contabilitate, caz în care nu este permisă modificarea conținutului intrării/ieșirii respective.
Datele evenimentului:
Despre document: numărul documentului, starea documentului
Despre articol: denumirea articolului, contul contabil, cantitatea, prețul, valoarea TVA-ului
Validarea unei intrări/ieșiri
La efectuarea operației de validare, documentul va intra în gestiunea contabilă la valoarea curentă. Se verifică daca documentul conține cel puțin o înregistrare. Dacă intrarea/ieșirea este vidă, validarea nu este posibilă. Înregistrarea contabilă se va face pe fiecare articol al documentului în parte. De asemenea se verifică daca documentul nu a fost deja validat. Starea documentului se va modifica în „validat”, permițând efectuarea plății/încasării.
Datele evenimentului:
Despre document: numărul documentului, starea documentului
Despre client/furnizor: numele clientului/furnizorului, contul furnizorului/clientului
Despre articol: valoare articol, cont articol
Efectuarea plății/încasării unei intrări/ieșiri
La efectuarea operației de plată/încasare, documentul va intra în gestiunea contabilă la valoarea curentă ca achitat. Se verifică daca documentul a fost validat, urmând ca starea acestuia să se modifice în „achitat”.
Datele evenimentului:
Despre document: numărul documentului, valoarea documentului
Despre client/furnizor: numele clientului/furnizorului, contul furnizorului/clientului
Devalidarea unei intrări/ieșiri
La efectuarea operației de devalidare, documentul va fi șters din gestiunea contabilă. Se verifică starea documentului, iar dacă acesta a fost introdus în contabilitate, va fi șters, însa comanda va rămăne în gestiunea intrărilor/ieșirilor ca nevalidat. Vor fi șterse atăt valorile de intrare căt și valoarea achitată a documentului, dacă acest lucru a fost realizat.
Datele evenimentului:
Despre document: numărul documentului, starea documentului
Adăugarea/ștergerea articolelor contabile
Se pot efectua și modificări în gestiunea contabilă pentru alte conturi decât cele de inrări/ieșiri de mărfuri/produse.
Datele evenimentului:
Despre articolul contabil: numărul documentului, contul de debit, contul de credit și valoarea înregistrării
Alocarea agenților pe comenzi
La alocarea unui agent pe o comandă se verifică mai întâi dacă agentul este disponibil (dacă nu este deja angajat în transportul altei comenzi) și apoi dacă s-a efectuat încasarea documentului comenzii. Dacă una din cele doua cerințe nu este îndeplinită, alocarea nu se poate face.
Datele evenimentului:
Despre document: numărul documentului, starea documentului
Despre agent: nume, telefon, CI, autovehicul, stare agent
Calcul salarii
Pe baza salariului brut/net al unui angajat se pot efectua calcule privind contribuțiile individuale ale salariaților.
Datele evenimentului:
Despre angajat: salariul brut/net
Analiza structurală
Analiza structurală evidențiază, la nivel conceptual, modul de structurare a datelor și a legăturilor dintre ele. Cea mai utilizată tehnică este entitate-asociere.
Identificarea entităților și a atributelor acestora
Pe baza analizelor anterioare au fost identificate următoarele entități care vor forma o bază de pornire pentru structura proiectului:
Intrări: nr. document, valoare, furnizor, stare document
Ieșiri: nr. document, valoare, client, stare document
Articole: nume articol, cont articol
Articole contabile: nr. document, valoare, cont credit, cont debit
Furnizori: nume, adresă, cont analitic, CUI, IBAN, data exp. contr
Clienți: nume, adresă, cont analitic, CUI, IBAN, data exp. contr
Salariați: nume, funcție, data angajării, norma, salariu, adresă, date personale
Agenți: nume, stare agent, autovehicul, CI, telefon
Urmând cerințele aplicației, vom adăuga entitatea societăți cu atributele nume, adresa, cod fiscal, nr. registrul comerțului, capital social, telefon. Aceasta va satisface cerința obținerii unei evidențe pentru mai multe societăți comerciale.
Pentru a putea identifica mai ușor înregistrările fiecărei entități și a diferenția înregistrările cu atribute similare, se vor introduce atribute de identificare unică pentru fiecare entitate (codIntrare, codArticol, etc.).
Diagrama E/R
Pe baza analizei structurale si a analizei de sistem se poate întocmi o diagramă preliminară entitate-asociere (entity-relationship). Pornind de la o astfel de diagramă, se pot construi, în actvitatea de proiectare, schemele relațiilor (tabelelor).
Fig. 2.1 Diagrama E-R preliminară
Analiza dinamică
Analiza dinamică evidențiază comportamentul elementelor sistemului la anumite evenimente.
Componenta Ieșiri
Identificarea stărilor:
Ieșire nouă
Verificare client
Înregistrare ieșire
Validare ieșire
Încasare ieșire
Devalidare ieșire
Alocare agent
Identificarea componentelor externe:
Clienți, articole contabile
Urmărind stările și componentele externe putem face modelarea dinamică:
Fig. 2.2 Diagrama de tranziție pentru componenta ieșiri
Componenta Intrări
Identificarea stărilor:
Intrare nouă
Verificare furnizor
Înregistrare intrare
Validare intrare
Încasare intrare
Devalidare intrare
Identificarea componentelor externe:
Furnizori
Articole contabile
Urmărind stările și componentele externe putem face modelarea dinamică:
Fig. 2.3 Diagrama de tranziție pentru componenta intrări
Componenta Salariați
Identificarea stărilor:
Cerere calcul salariu
Verificare salariat selectat
Așteptare date noi
Calcul salariu
Urmărind stările și componentele externe putem face modelarea dinamică:
Fig. 2.4 Diagrama de tranziție pentru componenta salariați
Analiza funcțională
Această etapă de analiză evidențiază modul de asigurare a cerințelor informaționale (fluxul prelucrărilor) din cadrul sistemului. Cea mai utilizată tehnică este diagrama de flux al datelor. Pentru întocmirea acesteia este nevoie de identificarea în prealabil a actroilor care produc sau consumă date, a proceselor/operațiilor la care sunt supuse datele și a depozitelor unde sunt memorate date pentru accesul ulterior.
Pentru aplicația GeFinSQL vom realiza diagrama de flux al datelor pentru următoarele componente:
Componenta ieșiri
Identificarea actorilor:
Firmă
Agent
Identificarea operațiilor:
Înregistrare ieșire
Determinare număr ieșire
Verificare contract client
Validare ieșire
Încasare ieșire
Alocare agent
Verificare agenți
Identificarea depozitelor de date:
Articole contabile
Agenți
Clienți
Ieșiri
Pe baza operațiilor și actorilor stabiliți anterior se poate realiza modelul funcțional:
Fig. 2.5 Diagrama flux de date pentru componenta ieșiri
Componenta intrări
Componenta intrări este similară celei de ieșiri, singura diferență fiind că nu se face alocarea pe agenți.
Identificarea actorilor:
Societate
Identificarea operațiilor:
Înregistrare intrare
Determinare număr intrare
Verificare contract furnizor
Validare intrare
Încasare intrare
Identificarea depozitelor de date:
Articole contabile
Furnizori
Intrări
Pe baza operațiilor și actorilor stabiliți anterior se poate realiza modelul funcțional:
Fig. 2.6 Diagrama flux de date pentru componenta intrări
Componenta clienți
Identificarea actorilor:
Firmă
Ieșire
Identificarea operațiilor:
Înregistrare client
Verificare client
Identificarea depozitelor de date:
Clienți
Componenta furnizori
Identificarea actorilor:
Societate
Intrare
Identificarea operațiilor:
Înregistrare furnizor
Verificare furnizor
Identificarea depozitelor de date:
Furnizori
Pe baza analizei realizate pentru componentele clienți și furnizori vom realiza o singură diagramă flux de date având în vedere similaritățile dintre acestea.
Fig. 2.7 Diagrama flux de date pentru componentele clienți/furnizori
Componenta articole contabile
Identificarea actorilor:
Ieșire
Intrare
Identificarea operațiilor:
Înregistrare articol contabil
Validare
Achitare/încasare
Identificarea depozitelor de date:
Articole contabile
Fig. 2.8 Diagrama flux de date pentru componenta articole contabile
Componenta agenți
Identificarea actorilor:
Ieșire
Agent
Identificarea operațiilor:
Înregistrare agent
Verificare agenți
Alocare agent
Identificarea depozitelor de date:
Agenți
Fig. 2.8 Diagrama flux de date pentru componenta articole contabile
Proiectarea de sistem
Se importă toate diagramele realizate în faza de analiză și în faza de proiectare de sistem.
Construirea arhitecturii sistemului
Pentru a trece mai departe la construirea arhitecturii sistemului se vor alege sistemul de gestiune al bazelor de date si interfața grafică cu utilizatorul. Am ales MySQL ca SGBD si C# pentru dezvoltarea interfeței.
În alegerea arhitecturii am ținut cont de facilitățile pe care le oferă limbajul C#, astfel că fiecare clasă de baza (intrări, ieșiri, agenți, etc.) va fi înglobată într-o clasa de tip windows form, pentru a evita simplifica structura proiectului. Așadar, sistemul va avea două componente: clase de interfețe grafice (care vor conține toate funcțiile celor de bază) și clase de acces la bazele de date.
Fig. 2.9 Arhitectura sistemului
Detalierea modelului obiectual
În această etapă a proiectării se va reface structura modelului obiectual realizat anterior, prin includerea unor aspecte care nu au fost atinse în faza de analiză, sau se pot modifica componente deja existente pentru a optimiza structura sistemului.
Implementarea accesului restricționat la date se va face prin adăugarea a trei tabele noi în baza de date, și anume utilizatori, drepturi și drepturifis cu următoarele funcții:
Tabela „utilizatori” va ține o evidență a utilizatorilor care se pot loga la aplicație și va stoca câteva date personale pentru aceștia. Programul va conține un modul separat pentru manipularea utilizatorilor, acces la această secțiune va avea numai administratorul aplicației.
Tabela „drepturi” va conține drepturile de acces utilizatorilor la societățile din gestiune, dar nu și asupra componentelor individuale ale programului.
Tabela „drepturifis” va conține drepturile de acces pentru fiecare modul al aplicației, acestea vor fi împărțite în drepturi de citire și drepturi de modificare.
Din tabela „agenți” va fi scos atributul „autovehicul”, care va constitui o tabelă separată. De asemenea, tot din „agenți” se va elimina atributul „stare” prin care se făcea verificarea existenței unei comenzi deja alocate pentru un agent. Pentru aceasta, tabela „comenziclienti” va fi creată, conținând informații atât despre agentul alocat, cât și despre comandă (ieșire). Atributele tabelei pot fi vizualizate în diagrama E/R finală.
Se va crea o nouă tabelă „gestiunearticole” care va constitui tipul (cheie externă) pentru „articole”.
Gestiunea articolelor din componentele „intrări” și „ieșiri” se va face prin două tabele noi, „intrăriarticole” și „ieșiriarticole”. Acestea vor ține o gestiune a tuturor articolelor incluse pe documentele contabile de tip „intrare” și „ieșire”.
Pe baza noilor modificări la modelul obiectual, diagrama E/R va fi reconstruită (a se vedea anexa 1).
Modelul de comunicare între clase
Acest model evidențiază relațiile și interacțiunile dintre componentele generale ale sistemului.
Componentele clasei de interfețe grafice va conține clasele:
Intrări/Ieșiri
Furnizori/Clienți
Agenți
Autovehicule
Articole contabile
Societăți
Utilizatori
Articole
Gestiune articole
Salariați
Fișe conturi
Clasa fișe conturi va face o centralizare a tuturor documentelor contabile emise, și nu se va constitui într-o tabelă separată în baza de date. Pe baza informațiilor din faza de analiză și proiectare de sistem se poate întocmi diagramade comunicare între clase:
Fig. 2.10 Diagrama de comunicare între clase
Definirea interfețelor
Principalele operații pentru componentele clasei de interfețe:
Operații intrări/ieșiri:
Adăugare intrare/ieșire
Modificare intrare/ieșire
Ștergere intrare/ieșire
Validare
Achitare/Încasare
Devalidare
Pentru articole: Adăugare, Modificare, Ștergere
Operații furnizori/clienți:
Adăugare furnizor/client
Modificare furnizor/client
Ștergere furnizor/client
Prelungește contract
Operații agenți:
Adăugare agent
Modificare agent
Ștergere agent
Alocare agent-comandă
Operații autovehicule:
Adăugare autovehicul
Modificare autovehicul
Ștergere autovehicul
Operații salariați:
Adăugare salariat
Modificare salariat
Ștergere salariat
Calcul salariu/contribuții
Operații articole:
Adăugare articol
Modificare articol
Ștergere articol
Operații gestiune articole:
Adăugare tip articol
Modificare tip articol
Ștergere tip articol
Operații articole contabile:
Adăugare articol contabil
Modificare articol contabil
Ștergere articol contabil
Operații societăți:
Adăugare societate
Modificare societate
Ștergere societate
Operații utilizatori:
Adăugare utilizator
Modificare utilizator
Ștergere utilizator
Acordare drepturi
Alaturi de cele nouă componente ale clasei de interfețe, se mai alătură și clasa fișe conturi, care nu are nicio operație atribuită, aceasta fiind doar de vizualizare și sintetizare a datelor.
Modelarea secvenței de ferestre
Fig. 2.10 Diagrama secvenței de ferestre
Proiectarea obiectuală
Plecând de la modelarea problemei realizata în etapa de analiza si de la planul stabilit în etapa de proiectare de sistem, proiectarea obiectuala definitiveaza clasele si asocierile, interfetele si algoritmii utilizati pentru implementarea operatiilor.
Proiectarea bazei de date
Conform rezultatelor obținute în etapele de analiză și proiectare am ajuns la o configurație finală a bazei de date. Aceasta va conține 17 tabele, după cum urmează:
Tabela societăți conține datele societăților aflate în gestiune. Aproape toate celelalte tabele sunt legate de ea printr-o cheie externă. Astfel, selecția se face în funcție de drepturile fiecărui utilizator, pe societăți.
Atributele tabelei societăți:
Atribute de identificare unică: cod, nume
Atribute reprezentând date fiscale: codFiscal, nrRegCom, micro, codCAEN, capSoc, cont1, cont2, banc1, banc2, filiala1, filiala2
Atribute reprezentând adresa: loc, jud, sect, str, nrStr, codPostal, bl, sc, et, apt
Alte atribute: tel, email
Secvența de cod SQL prin care se creează tabela societăți este următoarea:
CREATE TABLE societati (cod INT(4) NOT NULL PRIMARY KEY,
nume VARCHAR(20) NOT NULL UNIQUE KEY, codFiscal VARCHAR(25), nrRegCom VARCHAR(25), micro VARCHAR(3), codCAEN VARCHAR(5),
capSoc VARCHAR(10), loc VARCHAR(25), jud VARCHAR(25), sect VARCHAR(2), str VARCHAR(25), nrStr VARCHAR(5), codPostal VARCHAR(25), bl VARCHAR(10), sc VARCHAR(10), et VARCHAR(3), apt VARCHAR(4),
tel VARCHAR(25), email VARCHAR(25), cont1 VARCHAR(25),
banc1 VARCHAR(25), filiala1 VARCHAR(25), cont2 VARCHAR(25),
banc2 VARCHAR(25), filiala2 VARCHAR(25));
Secvențele de cod asociate celorlalte tabele sunt listate in secțiunea anexe (a se vedea anexa 2).
Tabela utilizatori ține evidența persoanelor care folosesc aplicația. Aici sunt memorate date prin intermediul cărora se face logarea.
Atributele tabelei utilizatori:
Atribute de identificare unică: cod, nume
Atribute reprezentând date de logare: nume, pass
Atribute reprezentând date personale: numen, prenumen, ci, cnp
Tabela drepturi oferă date prin care se restricționează accesul la societățile din gestiune.
Atributele tabelei drepturi:
Atribute de identificare unică: codUtilizator, codSocietate
Atribute cheie externă: codUtilizator, codSocietate
Atribute reprezentând restricții de acces la citire: dRread
Atribute reprezentând restricții de acces la modificare: dRwrite, dRadmin
Tabela drepturifis oferă date prin care se restricționează accesul la componentele aplicației.
Atributele tabelei drepturifis:
Atribute de identificare unică: codUtilizator
Atribute cheie externă: codUtilizator
Atribute reprezentând restricții de acces la citire: clRead, agRead, artRead, gestRead, autoRead, salRead, intrRead, iesRead, bdRead, fisecontRead, artcontRead
Atribute reprezentând restricții de acces la modificare: clWrite, fzWrite, agWrite, artWrite, gestWrite, autoWrite, salWrite, intrWrite, iesWrite, bdWrite, fisecontWrite, artcontWrite
Tabela salariați conține date despre angajații societății din gestiune.
Atributele tabelei salariați:
Atribute de identificare unică: cod
Atribute cheie externă: codSocietate
Atribute reprezentând date personale: nume, prenume, CNP, judet, adresa, telefon A
Atribute reprezentând date de angajare: functie, dataAngajarii, norma, salariu, contract
Tabela furnizori ține o evidență a firmelor cu care societatea din gestiune colaborează din punct de vedere al aprovizionării.
Atributele tabelei furnizori:
Atribute de identificare unică: cod, nume
Atribute cheie externă: codSocietate
Atribute reprezentând datele firmei: CUI, contAnalitic, judet, adresa, IBAN, dataExp
Tabela clienți ține o evidență a firmelor cu care societatea din gestiune colaborează din punct de vedere al desfacerii.
Atributele tabelei clienți:
Atribute de identificare unică: cod, nume
Atribute cheie externă: codSocietate
Atribute reprezentând datele firmei: CUI, contAnalitic, judet, adresa, IBAN, dataExp
Tabela intrări conține toate comenzile societăților din gestiune către furnizorii acestora.
Atributele tabelei intrări:
Atribute de identificare unică: nrDoc
Atribute cheie externă: codFurnizor, furnizor, codSocietate
Atribute reprezentând datele comenzii: tip, valoare, TVA, total, neachitat, status
Tabela intrări conține toate comenzile primite de societățile din gestiune de la clienții acestora.
Atributele tabelei intrări:
Atribute de identificare unică: nrDoc
Atribute cheie externă: codClient, client, codSocietate
Atribute reprezentând datele comenzii: tip, valoare, TVA, total, neachitat, status
Tabela intrăriarticole conține toate articolele de pe documentele de tip intrare și valorile individuale ale acestora.
Atributele tabelei intrăriarticole:
Atribute de identificare unică: codArt
Atribute cheie externă: tip, articol, codArticol, UM, TVA, codSocietate
Atribute reprezentând datele comenzii: cantitate, pret, valoare, TVAtot, total, contArticol
Tabela ieșiriarticole conține toate articolele de pe documentele de tip ieșire și valorile individuale ale acestora.
Atributele tabelei ieșiriarticole:
Atribute de identificare unică: codArt
Atribute cheie externă: tip, articol, codArticol, UM, TVA, codSocietate
Atribute reprezentând datele comenzii: cantitate, pret, valoare, TVAtot, total, contArticol
Tabela gestiunearticole ține evidența tipurilor de articole ce pot intra în gestiune.
Atributele tabelei gestiunearticole:
Atribute de identificare unică: cod, nume
Atribute cheie externă: codSocietate
Atribute reprezentând datele tipului de articol: contArticol, contVen, contCh
Tabela articole ține evidența articolelor din gestiune.
Atributele tabelei articole:
Atribute de identificare unică: cod, nume
Atribute cheie externă: tip, codSocietate
Atribute reprezentând datele articolului: UM, TVA, pretVanzare, pvTVA, stocMinim
Tabela articolecontabile ține evidența contabilă a intrărilor și ieșirilor, precum și a altor tipuri de documente.
Atributele tabelei articolecontabile:
Atribute de identificare unică: nrDoc, codArt
Atribute cheie externă: nrDoc, codSocietate
Atribute reprezentând datele articolului contabil: contDeb, contCr, suma, explicatie, valid
Tabela agenți conține date despre agenții de transport ai societăților din gestiune.
Atributele tabelei agenți:
Atribute de identificare unică: cod, nume
Atribute cheie externă: autovehicul, codSocietate
Atribute reprezentând datele agentului: telefon, ci
Tabela autovehicule reține date despre parcul auto al societăților din gestiune.
Atributele tabelei autovehicule:
Atribute de identificare unică: cod, numarInmatriculare
Atribute cheie externă: codSocietate
Atribute reprezentând datele autovehiculului: tipVehicul, marca, combustibil
Tabela comenziclienți conține toate ieșirile din contabilitate odată ce au fost efectuate încasările pentru acestea.
Atributele tabelei comenziclienți:
Atribute de identificare unică: cod
Atribute cheie externă: codIeșire, numeClient, codAgent ,codSocietate
Atribute reprezentând datele autovehiculului: termen
Implementarea claselor de bază
Clasa GeFinSQL este clasa de bază a aplicației, prin care se face logarea și se stabilește baza de date care va fi utilizată.
Clasa are două atribute care rețin datele de logare cum ar fi numele utilizatorului, societatea prin care s-a logat și baza de date.
public BDparam BDpar;
public USRparam USRpar;
Clasele BDparam și USRparam au următoarea structură:
public class BDparam
{
public string bd;
public string server;
public string uid;
public string password;
}
public class USRparam
{
public string user;
public int codUser;
public string password;
public struct drepturi
{
public string dRread;
public string dRwrite;
public string dRadmin;
}
public drepturi drp;
public string societate;
public int codSoc;
}
Secvențe relevante din funcțiile clasei:
Crearea bazei de date în cazul lipsei acesteia:
MySqlConnection conNewDb = new MySqlConnection("Data Source = " + BDpar.server + "; Persist Security Info = yes;" + " UserId = " + BDpar.uid + "; PWD = " + BDpar.password + ";");
conNewDb.Open();
MySqlCommand commandNew = conNewDb.CreateCommand();
commandNew.CommandText = "create database " + BDpar.bd;
commandNew.ExecuteNonQuery();
Verificarea existenței tabelelor:
for (int i = 0; i < 17; i++)
{
if (indx[i] == 0)
{
result = MessageBox.Show("Lipseste tabela " + bazeD[i] + ". Doriti sa o creati acum?", "Baza date incompleta!", MessageBoxButtons.YesNo);
if (result == DialogResult.Yes)
{
conn.Open();
command.CommandText = BDcomm[i];
command.ExecuteNonQuery();
conn.Close();
}
}
}
conNewDb.Close();
Bdcomm este un obiect de tip arraylist care preia comenzile de creare a tabelelor dintr-un fișier extern „constr.dat”, iar indx și bazed sunt vectori formați in urma executării query-ului „show tables”. Conexiunea și executarea unui query pe baza de date se realizează folosind următoarea secvență de cod:
MySqlConnection connection_1 = new MySqlConnection(connectString); MySqlCommand command_1 = connection_1.CreateCommand(commandString);
connection_1.Open();
command_1.ExecuteNonQuery();
connection_1.Close();
Apelarea constructorior pentru celelalte clase de interfață:
private void utilizatoriToolStripMenuItem_Click(object sender, EventArgs e)
{
Utilizatori UTI = new Utilizatori(this);
UTI.MdiParent = this;
UTI.Show();
}
Toate celelalte 9 clase de interfață sunt apelate în mod similar. După cum se poate observa, toate celelalte clase primesc ca parametru clasa de bază GeFinSQL, astfel facilitându-se accesul la toate atributele generale ale aplicației.
Datorită similarităților dintre tabelele intrări și ieșiri, am implementat o clasă de interfață comună, și anume clasa IntrăriIeșiri. Pentru a face diferența între cele două tabele, clasa primește ca parametru variabila table FC, prin care se face inițializarea atributului propriu cu același nume. Valoarea parametrului poate fi „intrări” sau „ieșiri”.
Interogarea bazei de date se face cu ajutorul unei variabile de tipul MySqlDataReader.
MySqlDataReader reader;
command.CommandText = "select * from " + tableFC + " where societate = " + parentForm.USRpar.codSoc.ToString();
conn.Open();
reader = command.ExecuteReader();
while (reader.Read())
{
ListViewItem lvi = new ListViewItem(reader[0].ToString());
lvi.SubItems.Add(reader[1].ToString());
lvi.SubItems.Add(reader[2].ToString());
lvi.SubItems.Add(reader[3].ToString());
lvi.SubItems.Add(reader[4].ToString());
lvi.SubItems.Add(reader[5].ToString());
lvi.SubItems.Add(reader[6].ToString());
lvi.SubItems.Add(reader[7].ToString());
listaIOLv.Items.Add(lvi);
}
Pentru a evita prăbușirea aplicației am folosit instrucțiunile try – catch pentru tratarea excepțiilor.
Am folosit pentru validarea de date o funcție pe care am inclus-o in clasa de bază:
public class Validare
{
public bool isDouble(string dbl)
{
bool b = true;
try
{
Convert.ToDouble(dbl);
}
catch
{
b = false;
}
return b;
}
…
}
Clasa validare mai conține 3 funcții de genul isDouble, și anume isDate, isCNP și isContract care sunt concepute in mod similar.
Generarea codului unic de înregistrare la adăugarea unei intrări/ieșiri noi se face prin intermediul următoarei secvențe de cod:
command.CommandText = "select nrDoc from " + tableFC;
reader = command.ExecuteReader();
//generare cod
int cod = 0;
ArrayList arr = new ArrayList();
while (reader.Read()) arr.Add(Convert.ToInt32(reader[0].ToString()));
for (int i = 0; i < (arr.Count – 1); i++)
for (int j = i + 1; j < arr.Count; j++)
if ((int)arr[i] > (int)arr[j])
{
int aux = (int)arr[i];
arr[i] = arr[j];
arr[j] = aux;
}
cod = 1;
for (int j = 0; j < arr.Count; j++) if (cod != (int)arr[j]) break;
else cod++;
reader.Close();
Pentru ștergerea unei înregistrări se folosesc următoarele comenzi:
command.CommandText = "delete from " + tableFC + " where nrDoc = " + listaIOLv.SelectedItems[0].Text + " and societate = " + parentForm.USRpar.codSoc.ToString();
command.ExecuteNonQuery();
Pentru modificarea unei înregistrări se folosește următoarea secvență de cod:
command.CommandText = "select cod from " + fzcl + " where nume = '" + IOFzClCb.Text + "' and societate = " + parentForm.USRpar.codSoc.ToString();
reader = command.ExecuteReader(); reader.Read(); string rdr = reader[0].ToString();
if (tableFC == "iesiri") fzcl = "client"; else fzcl = "furnizor";
command.CommandText = "update " + tableFC + " set nrDoc = '" + IONrDocTb.Text + "', tip = '" + IOTipCb.Text + "', cod = '" + rdr + "', " + fzcl + " = '" + IOFzClCb.Text + "' where nrDoc = " + listaIOLv.SelectedItems[0].Text + " and societate = " + parentForm.USRpar.codSoc.ToString();
reader.Close();
command.ExecuteNonQuery();
Pentru adăugarea unei înregistrări se folosesc următoarele comenzi:
command.CommandText = "insert into " + tableFC + " values(" + IONrDocTb.Text + ", '" + IOTipCb.Text + "', '" + rdr + "', '" + IOFzClCb.Text + "', '0', '0', '0', '0', '0', " + parentForm.USRpar.codSoc.ToString() + ")";
command.ExecuteNonQuery();
Tot in clasa IntrăriIeșiri se efectuează adăugarea de articole pe documentele deja intrate în gestiune. Mai întâi se verifică dacă este selectat un document folosind optiunea selecteditems a obiectului de tip listview listaIOLv și pe urmă se pot introduce datele noului articol.
Afișarea articolelor deja introduse pentru un anumit document se realizează la schimbarea selecției pe obiectul listaIOLv, folosind eventul selectedIndexChanged. La apariția acestui eveniment, articolele sunt introduse inntr-un alt obiect de tip listview, listaIOArtLv.
Celelalte clase de interfață sunt implementate în mod asemănător, având aproximativ aceleași funcții pentru realizarea adăugării, modificării sau ștergerii de înregistrări (se folosesc instrucțiunile SQL insert, update și delete ca și aici). În general am utilizat evenimentele diferitelor obiecte ale formului pentru a interoga sau modifica baza de date.
Particularități ale claselor:
Pentru afișarea și modificarea drepturilor de acces la societăți și modulele aplicației am folosit 4 vectori de obiecte de tip checkbox pe care le-am creat în funcție de numărul de societăți existente, folosind următoarea funcție:
public void dinamChb(CheckBox[] chb, ListView lst, int x, int y, int z)
{
for (int i = 0; i < lst.Items.Count; i++)
{
chb[i] = new CheckBox();
this.Controls.Add(chb[i]);
chb[i].Location = new Point(lst.Location.X + lst.Columns[0].Width + x, lst.Location.Y + (i * y) + z);
chb[i].BringToFront();
chb[i].BackColor = lst.BackColor;
chb[i].Text = "";
chb[i].Size = new Size(15, 15);
chb[i].Enabled = false;
chb[i].CheckedChanged += new EventHandler(Utilizatori_CheckedChanged);
}
}
Pentru clasa societăți am utilizat un obiect de tip panel pentru afișarea volumului mare de date aparținând societăților. Pentru aceasta m-am folosit de evenimentul selectedIndexChanged:
MySqlDataReader reader;
command.CommandText = "select * from societati where cod = " + socLv.SelectedItems[0].Text;
conn.Open();
reader = command.ExecuteReader();
reader.Read();
if (reader[4].ToString() == "yes") microintrepChb.Checked = true;
else microintrepChb.Checked = false;
codCAENCb.Items.Add(reader[5].ToString());
codCAENCb.Text = reader[5].ToString();capSocTb.Text = reader[6].ToString(); adrLocTb.Text = reader[7].ToString(); adrJudCb.Text = reader[8].ToString();
adrSecTb.Text = reader[9].ToString();adrStrTb.Text = reader[10].ToString(); adrNTb.Text = reader[11].ToString();adrCodPTb.Text = reader[12].ToString();
adrBlTb.Text = reader[13].ToString(); adrScTb.Text = reader[14].ToString(); adrEtTb.Text = reader[15].ToString(); adrApTb.Text = reader[16].ToString();
adrTlTb.Text = reader[17].ToString();adrEmlTb.Text = reader[18].ToString(); cont1Ct.Text = reader[19].ToString();cont1Bc.Text = reader[20].ToString();
cont1Fil.Text = reader[21].ToString();cont2Ct.Text = reader[22].ToString(); cont2Bc.Text = reader[23].ToString();cont2Fil.Text = reader[24].ToString();
conn.Close();
Fragmente din codul sursă mai sunt listate în secțiunea anexe (a se vedea anexa 3).
CAPITOLUL 3
PREZENTAREA APLICAȚIEI GEFINSQL
În acest capitol se va face o prezentare a părții funcționale a aplicației, evidențiind cu câteva exemple modul în care se realizează comunicarea cu baza de date.
Logarea și stabilirea conexiunii la baza de date
La pornirea aplicației, va apărea o fereastră de login care conține 3 câmpuri ce trebuiesc completate cu datele utilizatorului: nume utilizator, parola și societatea pe care se va lucra.
Fig. 3.1 Fereastra de logare
La bifarea opțiunii „Reține utilizatorul și parola”, datele de logare vor fi reținute într-un fișier extern, și la o pornire ulterioară a aplicației aceste date vor fi introduse automat de către program.
La accesarea secțiunii „Verifică setările de conexiune”, fereastra se va lărgi, permițând introducerea datelor privind conexiunea la baza de date prin intermediul a trei câmpuri: UID, parola și baza de date. Ultimul din acestea este format din serverul unde este localizată baza de date, caracterul „/” și numele bazei de date.
La apăsarea butonului „Acceptă”, în cazul în care baza de date specificată nu există, aplicația va afișa un mesaj anunțând acest lucru, și daca este selectată opțiunea „yes”, aceasta va fi generată automat. De asemenea, dacă baza de date este incompletă, pentru fiecare tabelă lipsă se va proceda similar, acestea fiind generate automat la cererea utilizatorului.
Fig. 3.2 Secțiunea „Verifică setările de conexiune”
Fig. 3.3 Mesaj de eroare
Dacă toate câmpurile sunt completate corect, se va efectua logarea și va apărea meniul principal în partea de sus a ferestrei de bază.
Meniul principal
Meniul principal conține patru opțiuni: „Fișiere”, „Operații/Listări”, „Administrare” și „Ajutor”:
Fig. 3.4 Meniul principal
Meniul „Administrare”
Vom trata mai întâi meniul „administrare” deoarece de aici se efectuează operații low-level asupra societăților, utilizatorilor și a bazei de date. La accesarea meniului, va apărea submeniul acestuia.
Unele opțiuni pot fi inactive, în funcție de drepturile pe care le are fiecare utilizator. Opțiunile DE configurare societăți, utilizatori și cele de backup și încărcare a fișierelor de backup pentru baza de date sunt accesibile numai utilizatorului de tip admin, iar opțiunea „Consultare BD” este activă numai utilizatorilor care au acest drept în tabela drepturifis. Celelalte două opțiuni de schimbare a societății sau a parolei sunt accesibile tuturor userilor, acestea nemodificănd decât într-o mică măsură înregistrările din baza de date.
Meniul „Administrare” în cele două variante, activ și parțial restricționat arată în felul următor:
Fig. 3.5 Meniul „Administrare”
Fereastra „Configurare societăți”
Configurarea datelor necesare programului, pentru fiecare societate în parte este extrem de importantă pentru funcționarea corectă a programului. Ecranul de configurare și modul în care acesta este structurat vă este prezentat în imaginea de mai jos:
Fig. 3.6 Fereastra de configurare a societăților
După cum se observă, la selectarea unei societăți, toate datele acesteia apar în câmpurile ferestrei, însa informațiile nu se pot modifica direct, ci doar prin apăsarea butonului „Modifică”.
Informațiile solicitate în această fereastră la crearea unuei noi societăți prin accesarea butonului „Adaugă”, sunt:
Cod – fiecărei societăți nou create i se va asocia un cod. Implicit, programul generează coduri începând cu 0001.
Denumirea societății
Codul unic de identificare (CUI)
Nr.registrul comerțului – se va trece numărul de înregistrare de la oficiul registrului comerțului. Acesta se va înscrie sub forma Jcj/nnnn/aaaa. Un exemplu de astfel de înregistrare este J40/1234/2006.
La societățile existente deja se vor putea modifica denumirea, codul fiscal și/sau numărul de înmatriculare prin accesarea butonului „Modifică”. La o societate deja creată nu se va putea modifica defel codul intern al acesteia, acesta fiind unic pentru fiecare societate în parte.
La adăugarea/modificarea unei societăți noi, va apărea un panel unde se pot introduce denumirea, CUI și nr. de întregistrare, iar celelalte controale își vor modifica starea, permițând introducerea informațiilor (adresa și unitățile bancare).
Fig. 3.7 Câmpurile care apar la modificarea/adăugarea unei societăți
Daca se selectează butonul „Renunță”, nu se va efectua nicio modificare asupra bazei de date, chiar daca au fost introduse informații în câmpurile aferente societății. Dacă se apasă butonul „Salvează”, societatea va fi introdusă în baza de date.
La ștergerea unei înregistrări, programul avertizează utilizatorul de operația pe care urmează să se efectueze, pentru a evita ștergerile din greșeală. În gestiune trebuie să existe cel puțin o societate, programul nu mai permite ștergerea dacă a rămas o singură societate listată.
Fereastra „Utilizatori”
În concepția programului există două tipuri de utilizatori:
1. Administrator
2. Utilizator normal
Programul vine cu utilizatorul ADMIN, utilizator de tip Administrator, creat implicit. Nu se pot crea alți utilizatori cu drepturi de administrator. Utilizatorul ADMIN trebuie să fie unic. Se pot crea oricâți alți utilizatori normali ai programului, aceștia avand implicit parola DEFAULT, pe care aceștia o pot modifica ulterior.
Drepturile utilizatorilor sunt de acces sau modificare și se împart în drepturi firmă și drepturi fișiere. La bifarea optiunii de modificare pentru o firmă/un fișier, se bifează automat și opțiunea de citire.
La ștergerea unei înregistrări, programul avertizează utilizatorul de operația pe care urmează să o efectueze, pentru a evita ștergerile din greșeală. Utilizatorul ADMIN nu poate fi șters.
Ecranul de configurare a utilizatorilor (useri) este următorul:
Fig. 3.8 Fereastra „Utilizatori”
Panelul de date de intrare pentru utilizatori este vizibil numai după apăsarea butoanelor „Adaugă” sau „Modifică”. Când se introduce sau modifică un utilizator butoanele de manipulare sunt inactive, la fel și lista cu utilizatori.
Fereastra „Consultare BD”
Submeniul „Consultare BD” permite efectuarea de selecții din baza de date, însă numai pe societatea curentă.
Selecțiile din baza de date (selecții SQL) reprezintă o opțiune care necesită cunoștințe medii despre baze de date și despre sintaxa limbajului SQL. SQL – Structured Query Language, permite utilizatorilor ca prin anumite comenzi aplicate asupra bazelor de date să extragă din acestea informații, seturi sau subseturi de date.
În principiu ecranul pus la dispoziție de către opțiunea „Consultare BD”, vă permite construirea de asemenea fraze, instrucțiuni, de selecție a datelor, în mod asistat, prin parcurgerea a mai multor etape:
Selectarea tabelei din care se va face extragerea de informații
Selectarea câmpurilor și a funcțiilor care vor fi afișate
Scrierea condițiilor de bază
Scrierea condițiilor de grupare
Scrierea condițiilor suplimentare
Scrierea condițiilor de ordonare
După ce au fost introduse toate datele de selecție, prin apăsarea butonului „Execută” se face interogarea bazei de date și comanda SQL este afișată pe ecran împreună cu rezultatele selecției, în cazul unei interogări reușite. Dacă datele nu au fost introduse corect, se va afișa un mesaj de eroare.
Fereastra „Consultare BD” este următoarea:
Fig. 3.9 Fereastra „Consultare BD”
Opțiunile „Schimbare parolă” și „Schimbare societate”
Schimbarea parolei pentru orice utilizator se poate face accesând submeniul „Schimbare parolă”. Pentru aceasta, programul solicită mai întâi parola veche și apoi afișează fereastra de logare, însă numai cu câmpul parola activ. La fel și pentru schimbarea societății, cu precizarea că selectarea unei societăți asupra căreia nu există drepturi de acces nu este permisă. Prezentarea mai detaliată a acestor aspecte este realizată în secțiunea anexe (a se vedea anexa 4).
Opțiunile „Backup BD” și „Încarcă fișierele de backup”
Prin intremediul acestor submeniuri se generează fișiere externe cu toate datele bazei de date, care pot fi încărcate ulterior în cazul pierderii de informații parțiale sau totale. La încărcarea fișierelor într-o altă baze de date care are deja înregistrări efectuate, datele existente vor fi suprascrise.
Meniul „Fisiere”
Prin intermediul meniului „Fișiere” se manipulează date privind gestiunea terților societății, a agenților, articolelor și salariaților. Unele opțiuni pot fi inactive, în funcție de drepturile pe care le are fiecare utilizator.
Tot de aici se poate închide aplicația.
La accesarea meniului „Fișiere” va apărea submeniul acestuia.
Vom prezenta în continuare mai în detaliu numai ferestrele „Clienți” și „Salariați”, iar pentru celelalte componente vom trece în revistă numai funcțiile mai importante, prezentări vizuale pentru acestea fiind listate în secțiunea anexe (a se vedea anexa 5).
Meniul „Fișiere are următoarea configurație:
Fig. 3.10 Meniul „Fișiere”
Fereastra „Clienți”
Pentru gestiunea clienților există patru operații: adăugare, modificare, ștergere și prelungire contract.
La adăugarea sau modificarea unui client, va apărea panelul cu câmpurile pentru introducerea informațiile privind clientul. Atât timp cat acest panel este vizibil, celelalte funcții ale aplicației, precum și lista clienților vor fi inactive. Acestea vor putea fi din nou accesate după efectuarea operației de salvare sau renunțare.
Fig. 3.11 Fereastra „Clienți”
Prin accesarea funcției de prelungire a contactului, data expirării acestuia va fi prelungită cu un an. Dacă un contract cu un client nu mai este în vigoare, nu se pot înregistra ieșiri pentru acel client.
Fereastra furnizori prezintă exact aceleași caracteristici, cu diferența că informațiile sunt memorate în baza de date în tabela „furnizori”.
Ferestrele „Autovehicule”, „Articole” și „Gestiune articole”
Aceste ferestre sunt pur și simplu de gestiune, neavând funcții suplimentare, decât pe cele de adăugare, modificare și ștergere de înregistrări.
Fereastra „Autovehicule” gestionează parcul auto al societății, având o referință externă în fereastra „Agenți” (fiecare agent are în gestiune un autovehicul înregistrat aici).
Fereastra „Gestiune articole” înregistrează tipurile de articole ce pot intra în gestiune, având o referință externă în fereastra „Articole” (fiecare articol este inclus într-o categorie/clasă de articole din tabela „gestiunearticole”). La rândul ei, fereastra „Articole” are o referință externă în fereastrele „Intrări” și „Ieșiri”.
Fereastra „Agenți”
Fereastra „Agenți” conține, pe lângă funcțiile de bază, operația de alocare a agentului pe o anumită comandă. Comenzile sunt venite de la clienți prin intermediul documentelor de tip ieșire. După ce ieșirile sunt încasate, acestea pot fi alocate agentilor disponibili. Dacă un agent este deja alocat altei comenzi, butonul „Alocați agentul” devine inactiv. După expirarea termenului de livrare, agentul va fi eliberat, permițând alocarea lui pentru o altă comandă. Dacă se dorește renunțarea la operației de alocare, se va selecta prima înregistrare a obiectului de tip combobox (înregistrare vidă) și se va apăsa din nou butonul „Alocați agentul”.
Fig. 3.12 Fereastra „Agenți”
Fereastra „Salariați”
Pentru această fereastră, voi prezenta numai funcția „Simulare calcul salarii” care poate fi accesată apăsȃnd butonul cu același nume. La apăsarea butonului, va apărea pe ecran o nouă fereastră:
Fig. 3.13 Fereastra „Simulare calcul salarii”
În această fereastră, câmpurile care se pot modifica sunt „Cursul valutar utilizat”, „Salariu net” și „Salariu brut”. Dacă înaintea accesării butonului de calcul salarii a fost selectat un angajat din lista salariaților, câmpul „Salariu net” va fi completat cu salariul acestuia. Realizarea calculelor se face la schimbarea selecției pe cele trei câmpuri.
Meniul „Operații/listări”
Prin intermediul meniului „Operații/listări” se manipulează date privind gestiunea articolelor contabile, a intrărilor și ieșirilor și se poate realiza fișa conturilor. Unele opțiuni pot fi inactive, în funcție de drepturile pe care le are fiecare utilizator.
La accesarea meniului „Fișiere” va apărea submeniul acestuia.
Fig. 3.14 Meniul „Operații/Listări”
Fereastra „Articole contabile”
Fereastra „Articole contabile” permite adăugarea, modificarea sau ștergerea articolelor contabile, inclusiv a articolelor contabile generate la validarea documentelor introduse în secțiunea „Intrări/Ieșiri”. Adăugarea, modificarea și/sau ștergerea sunt operații standard și se realizează similar celorlate componente ale aplicației.
Datele solicitate la introducerea unui articol contabil sunt:numărul documentului, cont debit, cont credit și suma. Explicația pentru toate articolele se generează automat.
Prezentarea vizuală a acestei ferestre este realizată în secțiunea anexe (a se vedea anexa 6).
Ferestrele „Intrări” și „Ieșiri”
Operațiile de cumpărare și vânzare se introduc în program, utilizând ecranele funcționale pentru intrări și ieșiri. Ecranele funcționale pentru operarea cumpărărilor și vânzărilor, conțin două tabele (zone) pentru introducerea datelor:
1. Tabelul care conține datele pentru antetul documentelor
2. Tabelul pentru detaliile documentelor
Adăugarea, modificarea și/sau ștergerea sunt operații standard și se realizează similar celorlate componente ale aplicației, numai că aceste operații se efectuează atât pentru documente, cât și pentru articolele incluse pe fiecare document.
Fig. 3.15 Fereastra „Ieșiri”
Pentru introducerea unei cumpărări/vânzări mai întâi se introduce documentul în prima zonă, urmând sa se adauge, pe rând articolele pentru fiecare document.
Operația de validare generează noi înregistrări în tabela „gestiunearticole”. Contul de credit va fi contul clientului/furnizorului pentru care s-a introdus documentul, iar contul de debit va fi contul articolului, pentru fiecare articol de pe document. Validarea nu este permisȃ pentru documente vide.
Operația de încasare/plată, de asemenea generează noi înregistrări în tabela „gestiunearticole”. Contul de credit va fi contul de casă, iar contul de debit va fi contul clientului/furnizorului pentru care s-a introdus documentul. Prin această operație se introduc înregistrări și în tabela „comenziclienți”.
Operația de devalidare șterge toate înregistrările efectuate în tabela „gestiunearticole” pentru documentul devalidat.
Fereastra „Fișe conturi”
Permite listarea fișei de cont pentru un cont ales din listă. Datele sunt preluate din tabela „articolecontabile”. Pentru fiecare cont sunt afișate și date agregate.
Fig. 3.16 Fereastra „Fișe conturi”
Fereastra „Fișe conturi” nu are înglobată nicio funcție, scopul acesteia fiind doar de analiză și sinteză.
ANEXE
Anexa nr. 1
Diagrama E/R finală
Anexa nr. 2
Secvența de cod pentru generarea tabelelot
CREATE TABLE utilizatori (cod INT(4) NOT NULL PRIMARY KEY,
nume VARCHAR(20) UNIQUE,
pass VARCHAR(20),
numen VARCHAR(20),
prenumen VARCHAR(20), ci VARCHAR(8),
cnp VARCHAR(14));
CREATE TABLE drepturi (codUtilizator INT(4) NOT NULL,
codSocietate INT(4) NOT NULL,
dRread VARCHAR(3) DEFAULT "yes" NOT NULL,
dRwrite VARCHAR(3) DEFAULT "no" NOT NULL,
dRadmin VARCHAR(3) DEFAULT "no" NOT NULL);
CREATE TABLE societati (cod INT(4) NOT NULL PRIMARY KEY,
nume VARCHAR(20) NOT NULL UNIQUE KEY,
codFiscal VARCHAR(25),
nrRegCom VARCHAR(25),
micro VARCHAR(3),
codCAEN VARCHAR(5),
capSoc VARCHAR(10),
loc VARCHAR(25),
jud VARCHAR(25),
sect VARCHAR(2),
str VARCHAR(25),
nrStr VARCHAR(5),
codPostal VARCHAR(25),
bl VARCHAR(10),
sc VARCHAR(10),
et VARCHAR(3),
apt VARCHAR(4),
tel VARCHAR(25),
email VARCHAR(25),
cont1 VARCHAR(25),
banc1 VARCHAR(25),
filiala1 VARCHAR(25),
cont2 VARCHAR(25),
banc2 VARCHAR(25),
filiala2 VARCHAR(25));
CREATE TABLE drepturifis (codUtilizator INT(4) NOT NULL,
clRead VARCHAR(3) NOT NULL, clWrite VARCHAR(3) NOT NULL,
fzRead VARCHAR(3) NOT NULL, fzWrite VARCHAR(3) NOT NULL,
agRead VARCHAR(3) NOT NULL, agWrite VARCHAR(3) NOT NULL,
artRead VARCHAR(3) NOT NULL, artWrite VARCHAR(3) NOT NULL,
gestRead VARCHAR(3) NOT NULL, gestWrite VARCHAR(3) NOT NULL,
autoRead VARCHAR(3) NOT NULL, autoWrite VARCHAR(3) NOT NULL,
salRead VARCHAR(3) NOT NULL, salWrite VARCHAR(3) NOT NULL,
intrRead VARCHAR(3) NOT NULL, intrWrite VARCHAR(3) NOT NULL,
iesRead VARCHAR(3) NOT NULL, iesWrite VARCHAR(3) NOT NULL,
bdRead VARCHAR(3) NOT NULL, bdWrite VARCHAR(3) NOT NULL,
fisecontRead VARCHAR(3) NOT NULL, fisecontWrite VARCHAR(3) NOT NULL,
artcontRead VARCHAR(3) NOT NULL, artcontWrite VARCHAR(3) NOT NULL);
CREATE TABLE furnizori (cod INT(4) NOT NULL PRIMARY KEY,
nume VARCHAR(20) UNIQUE,
CUI VARCHAR(9),
contAnalitic VARCHAR(85),
judet VARCHAR(20),
adresa VARCHAR(40),
IBAN VARCHAR(24),
dataExp VARCHAR(10),
societate INT(4));
CREATE TABLE clienti (cod INT(4) NOT NULL PRIMARY KEY,
nume VARCHAR(20) UNIQUE,
CUI VARCHAR(9),
contAnalitic VARCHAR(85),
judet VARCHAR(20),
adresa VARCHAR(40),
IBAN VARCHAR(24),
dataExp VARCHAR(10),
societate INT(4));
CREATE TABLE autovehicule (cod INT(4) NOT NULL PRIMARY KEY,
numarInmatriculare VARCHAR(10) UNIQUE,
tipVehicul VARCHAR(30),
marca VARCHAR(30),
combustibil VARCHAR(8),
societate INT(4));
CREATE TABLE agenti (cod INT(4) NOT NULL PRIMARY KEY,
nume VARCHAR(20) UNIQUE,
telefon VARCHAR(25), CI VARCHAR(8),
autovehicul VARCHAR(10),
societate INT(4));
CREATE TABLE gestiunearticole (cod INT(4) NOT NULL PRIMARY KEY,
nume VARCHAR(20) UNIQUE,
contCh VARCHAR(85),
contVen VARCHAR(85),
contArticol VARCHAR(85),
societate INT(4));
CREATE TABLE articole (cod INT(4) NOT NULL PRIMARY KEY,
nume VARCHAR(20) UNIQUE,
UM VARCHAR(10),
TVA VARCHAR(10),
tip VARCHAR(20),
pretVanzare VARCHAR(15),
pvTVA VARCHAR(15),
stocMinim VARCHAR(20),
societate INT(4));
CREATE TABLE salariati (cod INT(4) NOT NULL PRIMARY KEY,
nume VARCHAR(20),
prenume VARCHAR(20),
functie VARCHAR(20),
dataAngajarii VARCHAR(10),
norma VARCHAR(2),
salariu VARCHAR(15),
CNP VARCHAR(13),
judet VARCHAR(20),
adresa VARCHAR(40),
telefon VARCHAR(25),
contract VARCHAR(15),
societate INT(4));
CREATE TABLE intrari (nrDoc INT(4) NOT NULL,
tip VARCHAR(20),
cod VARCHAR(4),
furnizor VARCHAR(20),
valoare VARCHAR(15),
TVA VARCHAR(15),
total VARCHAR(15),
neachitat VARCHAR(15),
status CHAR(1),
societate INT(4));
CREATE TABLE iesiri (nrDoc INT(4) NOT NULL,
tip VARCHAR(20),
cod VARCHAR(4),
client VARCHAR(20),
valoare VARCHAR(15),
TVA VARCHAR(15),
total VARCHAR(15),
neachitat VARCHAR(15),
status CHAR(1),
societate INT(4));
CREATE TABLE intrariarticole (nrDoc INT(4) NOT NULL,
tip VARCHAR(20),
articol VARCHAR(20),
cod VARCHAR(4),
UM VARCHAR(10),
TVA VARCHAR(15),
cantitate VARCHAR(15),
pret VARCHAR(15),
valoare VARCHAR(15),
TVATot VARCHAR(15),
total VARCHAR(15),
cont VARCHAR(85),
codArt INT(4) NOT NULL,
societate INT(4));
CREATE TABLE iesiriarticole (nrDoc INT(4) NOT NULL,
tip VARCHAR(20),
articol VARCHAR(20),
cod VARCHAR(4),
UM VARCHAR(10),
TVA VARCHAR(15),
cantitate VARCHAR(15),
pret VARCHAR(15),
valoare VARCHAR(15),
TVATot VARCHAR(15),
total VARCHAR(15),
cont VARCHAR(85),
codArt INT(4) NOT NULL,
societate INT(4));
CREATE TABLE articolecontabile (nrDoc INT(4) NOT NULL,
contDeb VARCHAR(85),
contCr VARCHAR(85),
suma VARCHAR(20),
explicatie VARCHAR(85),
valid CHAR(1),
codArt INT(4) NOT NULL,
societate INT(4));
CREATE TABLE comenziclienti (cod INT(4) NOT NULL PRIMARY KEY,
codiesire INT(4),
numeClient VARCHAR(20),
codAgent INT(4),
termen VARCHAR(10),
societate INT(4));
Anexa nr. 3
Alte fragmente de cod
//Preluarea Conturilor din fisierul extern Conturi.dat
FileStream FILE2 = new FileStream("Conturi.dat", FileMode.Open, FileAccess.ReadWrite);
StreamReader sr2 = new StreamReader(FILE2);
while (sr2.Peek() >= 0) listaConturiLv.Items.Add(sr2.ReadLine());
FILE2.Close();
sr2.Close();
//functia de validare de date – CNP
public bool isCNP(string cnp)
{
bool b = true;
try
{
b = isDate(cnp[5].ToString() + cnp[6].ToString() + "." + cnp[3].ToString() + cnp[4].ToString() + "." + cnp[1].ToString() + cnp[2].ToString() + "11");
if ((cnp[0] != '1') && (cnp[0] != '2')) b = false;
Convert.ToInt32(cnp[7].ToString() + cnp[8].ToString());
Convert.ToInt32(cnp[9].ToString() + cnp[10].ToString());
Convert.ToInt32(cnp[11].ToString() + cnp[12].ToString());
}
catch
{
b = false;
}
return b;
}
//calcul contributii pe baza salariului net
private void simSalNetTb_Leave(object sender, EventArgs e)
{
Validare vld = new Validare();
if (vld.isDouble(simSalNetTb.Text) == false)
{
MessageBox.Show("Nu ati introdus salariul net corect!", "Atentie!");
goto sfarsit;
}
double dbl = 0;
double total = 0;
dbl = (100 * Convert.ToDouble(simSalNetTb.Text)) / 70.14; dbl = Math.Round(dbl, 2);
simSalBrutTb.Text = dbl.ToString();
dbl = 0.105 * Convert.ToDouble(simSalBrutTb.Text); total += dbl; dbl = Math.Round(dbl, 2);
simCASTb.Text = dbl.ToString();
dbl = 0.055 * Convert.ToDouble(simSalBrutTb.Text); total += dbl; dbl = Math.Round(dbl, 2);
simSanTb.Text = dbl.ToString();
dbl = 0.005 * Convert.ToDouble(simSalBrutTb.Text); total += dbl; dbl = Math.Round(dbl, 2);
simSomTb.Text = dbl.ToString();
dbl = 0.16 * (Convert.ToDouble(simSalBrutTb.Text) – total); total += dbl; dbl = Math.Round(dbl, 2);
simImpTb.Text = dbl.ToString(); total = Math.Round(total, 2);
simTCSTb.Text = total.ToString();
if (vld.isDouble(simCursValTb.Text) == true)
{
dbl = Convert.ToDouble(simSalNetTb.Text) / Convert.ToDouble(simCursValTb.Text); dbl = Math.Round(dbl, 2);
simSalNetEuroTb.Text = dbl.ToString();
dbl = Convert.ToDouble(simSalBrutTb.Text) / Convert.ToDouble(simCursValTb.Text); dbl = Math.Round(dbl, 2);
simSalBrutEuroTb.Text = dbl.ToString();
}
else
{
simSalNetEuroTb.Text = "0";
simSalBrutEuroTb.Text = "0";
}
sfarsit:
vld.isDouble(simCASTb.Text);
}
//functia de trecere din modul adaugare/modificare in modul vizualizare si invers
public void switchAdMod()
{
listaSalLv.Enabled = !listaSalLv.Enabled;
adSalBtn.Enabled = !adSalBtn.Enabled;
modSalBtn.Enabled = !modSalBtn.Enabled;
stgSalBtn.Enabled = !stgSalBtn.Enabled;
panelSal.Visible = !panelSal.Visible;
simSalBtn.Visible = !simSalBtn.Visible;
salNumTb.Clear(); salPrenTb.Clear(); salFctTb.Clear(); salDataTb.Clear(); salNormTb.Clear(); salSalTb.Clear(); salCNPTb.Clear(); salJudCb.Text = ""; salAdrTb.Clear(); salTelTb.Clear(); salContrTb.Clear();
listaSalLv.SelectedItems.Clear();
}
//verificarea drepturilor pentru consultarea BD
command.CommandText = "select * from drepturifis where codUtilizator = " + parentForm.USRpar.codUser.ToString();
reader = command.ExecuteReader();
reader.Read();
if (reader[1].ToString() == "yes") listaTabLv.Items.Add("clienti");
if (reader[3].ToString() == "yes") listaTabLv.Items.Add("furnizori");
if (reader[5].ToString() == "yes") listaTabLv.Items.Add("agenti");
if (reader[7].ToString() == "yes") listaTabLv.Items.Add("articole");
if (reader[9].ToString() == "yes")
listaTabLv.Items.Add("gestiunearticole");
if (reader[11].ToString() == "yes") listaTabLv.Items.Add("autovehicule");
if (reader[13].ToString() == "yes") listaTabLv.Items.Add("salariati");
if (reader[15].ToString() == "yes")
{
listaTabLv.Items.Add("intrari");
listaTabLv.Items.Add("intrariarticole");
}
if (reader[17].ToString() == "yes")
{
listaTabLv.Items.Add("iesiri");
listaTabLv.Items.Add("iesiriarticole");
}
if (reader[23].ToString() == "yes")
listaTabLv.Items.Add("articolecontabile");
Anexa nr. 3
Prezentarea opțiunilor de schimbare parolă și societate
Schimbarea societății
Schimbarea parolei
Anexa nr. 5
Prezentarea ferestrelor „Autovehicule”, „Articole” și „Gestiune articole”
Fereastra „Autovehicule”
Fereastra „Articole”
Fereastra „Gestiune articole” în modul adăugare/modificare
Fereastra „Gestiune articole” în modul vizualizare
Anexa nr. 6
Prezentarea ferestrei „Articole contabile”
Fereastra „Articole contabile” la ștergerea unei înregistrări
Fereastra „Gestiune articole” în modul adăugare/modificare
BIBLIOGRAFIE
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Sistem Informatic Privind Activitatea Financiara (ID: 148874)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.