Proiectarea Unei Aplicatii Informatice Care Sa Permita O Evidenta Clara a Numarului de Rapoarte

Capitolul 1. STUDIUL ȘI ANALIZA SISTEMULUI EXISTENT

1.1 Prezentarea succintă a companiei Avangate

Avangate reprezintǎ soluția de comerț digital preferatǎ de companii software și de ser-vicii cloud care își propun sǎ își dezvolte afacerea la nivel global. Cu Avangate companiile soft-ware pot deservi cumpǎrǎtori individuali și le pot îndeplini așteptǎrile de creștere prin vânzǎri oriunde și prin orice canal la nivel internațional.

Fondatǎ în 2006, Avangate își are sediul central în Amsterdam, Olanda. Este un fur-nizor de încredere pentru soluții agile a eCommerce creat pentru companii Software și SaaS care se bazeazǎ pe Avangate pentru a-și crește business-ul la nivel internațional prin orice canal și orice model.

Soluția eCommerce Avangate permite companiilor software sǎ integreze rapid schim-bǎrile din industrie, sǎ ajungǎ eficient în fața clienților și sa adopte noi modele de business cu focus pe optimizarea profitabilitǎții în canalele online și offline.

Avangate reprezintǎ furnizorul nr.1 de soluții pentru comerț (eCommerce + facturare + distributie) la nivel global, pentru piețele de software și servicii online.

Valorile companiei sunt:

Oamenii ne fac ceea ce suntem astǎzi și astfel încurajǎm în mod natural lucrul în echipǎ, implicarea, responsabilitatea și respectul reciproc;

Excelența este o valoare care ne inspirǎ sǎ livrǎm doar rezultate de înaltǎ cali-tate atât extern, cât și intern și sǎ ne îmbunǎtǎțim continuu cunoștințele;

Rǎsplǎtim creativitatea, inițiativa și promovǎm inovația, aceasta fiind un motor puternic ce ne propulseazǎ înainte;

Plǎcerea clienților este cu adevarat testul suprem al eforturilor noastre și mǎsu-ra succesului. Clienții și partenerii apreciazǎ eficiența, flexibilitatea, integritatea și trans-parența.

Avangate a fost fondatǎ în 2006 ca membrǎ a familiei de companii GECAD. De la în-ființarea sa, Avangate a devenit o prezențǎ solidǎ pe piața internaționalǎ a comerțului digital, a-jutând companiile sǎ-și accelereze vânzǎrile online prin orice canal, orice model și orice piațǎ.

În octombrie 2013 Francisco Partners a achiziționat Avangate. Francisco Partners este o companie de capital privat, lider global, concentratǎ exclusiv pe investiții în tehnologie și afa-ceri în domeniul serviciilor tehnologice.

Echipa Avangate este alcatuitǎ din:

Președinte & CEO;

Chief Operating Officer;

SVP, Vânzǎri Internaționale;

CMO/SVP Marketing și Produse;

Chief Information Officer;

Chief Product Evanghelist;

Directorii Birourilor Regionale: – VP, Vânzǎri America de Nord;

– VP, Vânzǎri Europa de Vest;

– VP, Vânzǎri EMEA;

– VP, Vânzǎri APAC.

Valorile fundamentale ale companiei se ghideazǎ astfel încât sǎ livreze constant rezul-tate excepționale pentru clienți și comunitatea companiei Avangate. Avangate reprezintǎ o com-panie deschisǎ cu o viziune directǎ, ce depune toate eforturile pentru a ajuta companiile soft-ware și SaaS sǎ obținǎ rezulte maxime din afacerea lor.

Avangate a avut un parcurs extraordinar pentru a ajunge unde este astǎzi fiind destul de încrezǎtoare ca poate oferi soluții profesionale eficiente pentru a acoperi toate nevoile clien-tilor de business, astfel încât aceștia sǎ se ocupe doar de creșterea afacerii lor.

1.2 Principalele activități ale companiei Avangate

Avangate ajută producătorii de software și SaaS sau servicii în cloud, prin platforma de comerț electronic și serviciile pe care le oferǎ, să își vândă produsele online în orice țară, indiferent de modelul de business (produs descărcabil sau serviciu), indiferent de canalul prin care vând – direct, prin parteneri sau distribuitori.

Producătorii își setează produsele în platformă, prețurile (globale sau pentru fiecare piață în parte), recurentă (dacă este cazul), alte informații despre produs – și își prezintă produsele pe site-ul propriu, prin site-urile partenerilor, afiliaților, chiar și în produs, oriunde doresc. În momentul în care clientul apasă butonul „Cumpără acum” sau chiar și „Încearca gratuit acum”, noi preluăm clientul în paginile noastre securizate care sunt traduse în mai mult de 30 de limbi pentru a crește confortul clientului cu pagina de plată, mai departe oferim peste 30 de metode de plată, ne ocupăm și de emiterea facturilor pentru firme, suport clienți 24 din 7.

Avangate practic se ocupă de tot ce înseamnă partea de vânzare, inclusiv transfer valutar, gestionarea taxelor în fiecare țară în parte, trimiterea codurilor de licențe, linkurilor pentru descărcare sau a detaliilor de acces la produs, plus optimizarea proceselor, astfel încât clientul să beneficieze, de exemplu, o rată cât mai mare de conversie în coșul de cumpărături, să poți să faci teste de optimizare între două prețuri pe o anumită piață, să poata să tranzacționeze pe orice device – coșul de cumpărături arată diferit pentru desktop față de mobil și toate aceste lucruri trebuie luate în considerare.

Ofera și ajutor pe partea de canale de vânzări – avand o rețea de 40.000 de afiliați specializați în promovarea software-ului pe care o pune la dispoziția clienților – aceștia se conectează la rețea și își pot alege partenerii cu care vor să lucreze și au un modul dedicat pentru gestionarea afiliaților. La fel și pentru distribuitori.

Dat fiind caracterul inevitabil al SaaS, abilitatea Avangate de a susține orice model în mod egal – și a administra licențele, subscripțiile, facturarea recurentǎ și reînnoirile simultan, transformǎ platforma Avangate în cea mai bunǎ opțiune pentru orice companie software.

Avangate oferǎ serviciilor online și SaaS tot ce le este necesar pentru a stimula veni-turile recurente globale și a profita de cea mai largǎ distribuție disponibilǎ în toate piețele în dezvoltare. Avangate permite eficientizarea și reducerea termenelor de platǎ – pentru a scurta ciclul de vânzare, a beneficia de facturarea recurentǎ și pentru a accelera creșterea veniturilor.

1.3. Studiu de conducere

Sistemul de conducere prin scopul său este menit să ia deciziile de nivel organizatoric și să formeze strategii pe termen lung urmând bunul mers al firmei pe piața în care își desfășoară activitatea.

Compania Avangate are ca principal Manager de nivel înalt Directorul General urmat de managerii departamentelor instituției. Aceștia în urma informațiilor primite de la managerii de nivel mediu analizează situația proiectelor în desfășurare și cele deja realizate pentru a găsi punți de dezvoltare și pentru a stabili strategia de urmat pentru viitor. De asemenea Managerii departamentelor se asigură de calitatea serviciilor oferite de firma prin fiecare departament menținând o legătură constanța cu clienții societății și urmărind realizarea comenzilor la cel mai înalt grad de satisfacție al clientului.

1.4. Studiul sistemului condus

Sistemul condus reprezintă un ansamblu de activități omogene sau complementare, respectiv identice, asemănătoare sau înrudite, care au o logică în manifestarea lor propriu-zisă și contribuie la o mai bună gestionare a resurselor și creșterea eficienței de ansamblu a între-prinderii.

Acesta este format din managerii de nivel mediu care asigură conducerea operativă a întreprinderii.

– Departamentul Financiar – Contabil – înglobează activitățile de obținere și folosire rațională a disponibilităților bănești, controlul operațiilor în care s-au investit fonduri bănești, stabilirea necesarului de mijloace financiare și găsirea de noi surse de finanțare a activității.

– Departamentul de Resurse Umane – reprezintă un ansamblu de activități care urmă-resc procesele la care se supun resursele umane, adică asigurarea întreprinderii cu forță de mun-că calificată, recrutarea personalului, selecționarea, încadrarea, promovarea, retribuirea salaria-ților, pregătirea și specializarea anagjatilor. De asemenea, în cadrul acestui departament sunt analizate problemele sociale, de asistentă medicală și raporturile manager-salariați și sunt inclu-se activități administrative, de secretariat și protocol.

– Departamentul IT – prin rolul sau se are în vedere atât funcționarea în parametrii nor-mali a tuturor resurselor IT (de la calculatoare, imprimante, telefoane, centrale telefonice digi-tale, până la prize, cabluri utp, management servere) ci și organizarea și achiziționarea de noi re-surse, astfel încât volumul de muncă per angajat să aibă un grafic de crește exponențial aducând beneficii materiale firmei.

1.5. Studiul sistemului informațional

Modelul conceptual de comunicație este un model determinat în urma analizei fluxurilor informaționale din cadrul activitǎții (-lor) informatizate. Conceptele fundamentale cu care opereazǎ acest model sunt: actorii; fluxurile informaționale; diagrame de flux; matrice de flux; diagramele de dependențǎ între documente.

Actorii – entitǎțile implicate în funcționarea normalǎ a activitǎților unei firme. Actorii nu reprezintǎ neapǎrat persoane, în cadrul sistemului informațional financiar contabil, ci pot fi: societǎți comerciale, servicii din cadrul firmei, etc. Actorii sunt reprezentați în MCC prin intermediul unor cercuri.

Fluxurile informaționale – ansamblul informațiilor schimbate între actori. Fluxurile de informații sunt reprezentate prin intermediul sǎgeților, care indicǎ direcționarea informațiilor între actori.

Diagramele de flux – prezintǎ legǎturile dintre actori, prin intermediul schimburilor de informații reflectate cu ajutorul fluxurilor informaționale.

Matricele de flux – forma de reprezentare tabelarǎ a fluxurilor schimbate între actori. La intersecția liniilor cu coloanele, fluxurile apar sub douǎ forme: fluxuri interne și fluxuri externe.

Diagramele de dependențǎ între documente – reflectǎ relația de dependențǎ care existǎ între documente, de tipul “un document depinde de alt document”. Practic, reflectǎ fluxul informațional, generat de mișcarea documentelor. Aceastǎ diagramǎ are și rolul de a asigura luarea în considerare a tuturor documentelor, fǎrǎ riscul de a uita unele dintre ele.

1.5.1. Studiul fluxului informațional

INTRĂRI IEȘIRI

1.5.2. Descrierea documentelor utilizate. Modelul conceptual al datelor

Modelarea conceptualǎ presupune, înainte de elaborarea celor trei modele specifice (model conceptual de comunicație, model conceptual al datelor și model conceptual al intrǎ-rilor), identificarea tuturor documentelor vehiculate în cadrul activitǎții ce urmeazǎ a fi infor-matizate: documente de intrare și documente de ieșire. Sunt culese toate pozițiile (atributele) din aceste documente, iar acolo unde este cazul, și modalitǎțile de calcul aferente, sau modalitatea de derivare a unor atribute din altele. Aceastǎ modelare este independentǎ de limbajul de programare sau de sistemul de gestiune a bazelor de date în care se va implementa sistemul.

Realizeazǎ o modelare abstractǎ a datelor, plecând de la intrǎrile și ieșirile viitorului sistem, prin utilizarea a trei concepte de bazǎ: entitate, relație, proprietate.

Documentele utilizate în cadrul companiei Avangate cuprind:

1. un formular de comandǎ în care clientul își poate descrie afacerea cu produse soft-ware, prin acesta clientul va putea obține toate instrumentele necesare, precum și evaluarea necesarǎ pentru ca acesta (clientul) sǎ poatǎ avea un cont de acces pe siteul companiei Avan-gate.

Dupǎ completarea formularului prezentat anterior, clientul trebuie sǎ furnizeze și date-le de contact, acestea vor fi trecute în formularul numǎrul 2, prin furnizarea acestor date clientul v-a putea fi informat în legaturǎ cu rezultatul obținut în urma evaluǎrii datelor, mai exact clien-tul va fi anunțat dacǎ activarea contului a fost aprobatǎ sau nu, la adresa menționatǎ de acesta, email sau adresa unde își are sediul firma, va fi încheiat și un contract între client și compania Avangate.

Un ultim document ar fi un al 3 lea formular care conține informații cu privire la pro-blemele întâmpinate de cǎtre client, cu ajutorul acestor informații, Avangate va gǎsi soluții op-time pentru a ajuta clientul în atingerea obiectivelor propuse.

Dupǎ completarea acestor formulare, clientului i se va oferi soluția cea mai optimǎ pentru afacerea lui, acesta fiind contactat pentru a i se comunica dacǎ cererea i-a fost aprobatǎ în urma evaluǎrii efectuate de cǎtre Avangate.

1.5.3. Proceduri de prelucrare a datelor utilizate. Modelul conceptual al pre-lucrǎrilor

Din punct de vedere conceptual, modelul conceptual al prelucrărilor surprinde prelucrările informatice efectuate într-un anumit context. Conceptele de bază cu care operează modelul conceptual al prelucrărilor, sunt: evenimentul; operația; sincronizarea; procesul.

Evenimentul – stimul din afara sistemului sau din interiorul acestuia. Un eveniment poate avea și proprietăți.

Operația – set de acțiuni, întreprinse de sistem, ca răspuns la unul sau mai multe eve-nimente interne sau externe. În urma execuției unei operații, există posibilitatea ca acestea să genereze alte evenimente, condiționate de îndeplinirea unor reguli de declanșare a acestora.

Sincronizarea – se referă la lista evenimentelor care trebuie să șe producă, concretizate în reguli de activare a unei operații. Evenimentele se pot grupa în propoziții logice, prin utili-zarea operatorilor logici și/sau/nu.

Procesul – se referă la un ansamblu de operații executate, din același domeniu.

Descrierea fiecărui eveniment se realizează prin precizarea tipului acestuia (din interiorul sau din afara sistemului) si a proprietăților sale.

Descrierea fiecărei operații se realizează prin precizarea procesului care a generat-o, a evenimentelor care au generat-o, a evenimentelor declanșate în urma ei, a regulilor de declan-sare și a acțiunilor întreprinse asupra sistemului, pentru rezolvarea acestei operații.

În prealabil după ce este primită de la client cererea de creare a contului de acces, in-formațiile sunt colectate de către Managerul de Cont și sunt derulate mai departe către res-ponsabilii în firma cu evaluările iinformatiilor furnizate de către client.

Completarea datelor cerute de către Avangate, vor ajuta la crearea contului de utili-zator și la gestionarea siteului în funcție de alegerea făcută de către client (pachetul de servicii ales de acesta).

Datele de contact furnizate de către client, trebuie să fie date reale deoarece acestea vor fi trecute printr-un filtru de aprobare, iar în cazul în care se constată că datele nu sunt reale, atunci clientul nu este eligibilsi în concluzie contul nu poate fi aprobat. În cazul în care datele sunt valide, acestea vor primi un nume de utilizator, o parolă și nstructiuni de accesare a Panoului de control Avangate eCommerce.

Pentru a finaliza înregistrarea datelor completate în cele 3 formulare, este necesară validarea acestora prin introducerea unui cod de verificare, acesta fiind un cod uni pentru fiecare solicitare. După introducerea datelor și a codului cererea este trimisă spre evaluare, aceasta urmând să fie procesată și verificată pentru a putea obține aprobarea.

În urma aprobării, consultanții Avangate i-au legătură cu clientul, confirmandu-i-se astfel activarea contului și faptul că va primi prin poștă contractul încheiat între el și compania Avangate.

1.5.4. Analiza sistemului actual și identificarea neajunsurilor existente în func-ționarea sistemului existent

Sistemul informațional al departamentului așa cum se prezintă în momentul de față a rămas neschimbat încă de la întemeierea firmei în cauza. Acesta prezintă :

– management deficitar al istoricului evaluărilor și al evaluărilor în curs datorită fap-tului că nu există o soluție unitară în sistem, ci managementul reprezintă alegerea fiecărui angajat în fluxul informațional de date să își organizeze datele așa cum consideră de cuviință.

– neexistență unei funcții de a crea rapoarte în funcție de client (bancă), Manager de Cont, Consultant sau doar pentru a avea o situație asupra numărului de evaluări total pe o zi/ luna/an.

1.5.5. Direcții de perfecționare a sistemului actual

Soluția singulară pentru evoluția afacerii departamentului de evaluări o reprezintă o soluție integrată, automatizată care să ofere :

– management eficace al comenzilor de intrare și a organizării datelor atât pentru Managerii de Cont cât și pentru Consultanți prin distribuirea automată de responsabilitate către un Consultant, de la introducerea în sistem a unei comenzi și până la terminarea raportului de evaluare. Comanda introdusă în sistem fiind unică și pentru Managerii de Cont cât și pentru Consultanți, aceștia din urmă putând să completeze spațiile care le revin pentru finalizarea comenzii în sistem.

– notificare prin email la repartizarea unei comenzi de la un Manager de Cont către un Consultant, pentru o eficientizare și o optimizare a timpului de realizare a evaluării datelor.

– organizarea maximală a datelor prin implementarea de funcții avansate de sor-tare/afișare/căutare/filtrare a datelor în timpi optimi.

– funcție avansată de generare rapoarte de activitate.

– funcție de mesagerie internă pentru o comunicare fluentă între utilizatorii sis-temului.

– controlul eficace al drepturilor fiecăruia în sistem prin implementarea de conturi cu răspunderi controlabile.

Capitolul 2 Proiectarea de ansamblu a sistemului informatic

2.1. Obiectivele și oportunitatea aplicației informatice

Pentru activitǎțile întreprinse de clienți au fost stabilite următoarele obiective ale nou-lui sistem informatic:

crearea unei posibilități de management și organizare centralizate a datelor de intrare.

asigurarea redundanței și securității datelor.

automatizarea procesului de schimb de informații între membrii departamentelor și în cadrul acțiunii de atribuire de responsabilitate.

Aplicația ce urmează a fi dezvoltată se interpune între managerii de cont, consul-tanții și departamentul de contabilitate, creând astfel o relație automatizată între departamentele respective.

Locul aplicației informatice în sistem

Avangate Commerce Cloud este creat pe o platforma Cloud și Infrastructura tehno-logica, aceasta oferind practic un set bogat de funcționalitǎți integrate pentru a oferi clienților puterea și flexibilitatea necesare pentru a opera și dezvolta propria afacere.

Configurarea Avangate se bazeazǎ pe șabloane și include setǎri standard, predefinite de ecommerce. Este construitǎ într-un mod ce pune într-un timp foarte scurt o afacere pe picioa-re fǎrǎ a întâmpina probleme uzuale care apar în procesele de integrare. In ceea ce privesc inte-grǎrile avansate, clienții se pot baza pe expertiza oferitǎ de Avangate ce ajutǎ la includerea eco-mmerce în aplicațiile proprii, precum și în CRM, web analytics, DRM, ERP și multe altele.

Definirea intrărilor sistemului

Intrările în sistem asigură generarea datelor de intrare, care vor face obiectul prelu-crărilor automate prin intermediul algoritmilor de calcul și de prelucrare.

Rolul documentelor de intrare (DI) ale unui sistem constă în faptul că vor consemna starea și dinamica fenomenelor și proceselor petrecute în sistemul operant/productiv și au următoarele particularități:

sunt generate (întocmite) la locul și în momentul (desfășurării) producerii unui pro-ces sau fenomen;

reflectă operații specifice prin intermediul cărora vor fi generate tranzacțiile externe;

circuitul, termenele, intervalele obligatorii și modul concret de prelucrare, sunt sti-pulate în reglementări legale sau de norme interne;

gradul de prelucrare al informațiilor de pe DI este minim;

modelele documentelor de intrare conțin zone evidențiate și/sau colorate în diverse moduri, în scopul asigurării clarității, calității și exactității generării și introducerii datelor în sis-tem;

Clasificate după maniera în care intră în sistem, informațiile sunt:

intrări off-line – sunt cele care intră în sistem prin intermediul documentelor și care presupune operația de introducere în sistem sau colectare a lor;

intrări on-line – sunt acele informații care sunt introduse direct în sistem – în mo-mentul producerii fenomenului real – prin intermediul terminalelor, a stațiilor de lucru sau transmisiei de date.

2.4. Definirea sistemului de codificare

Prin codificare se înțelege procesul se substituire a valorii reale a unui atribut cu o altă valoare, iar valoarea reală va fi stabilită prin operația de decodificare.

Sistemul de codificare este format din totalitatea elementelor privind necesitatea, o-biectul, cerințele codificării, funcțiile codurilor, tipuri de coduri, activitățile impuse de codifi-care și coduri folosite. Este o operație foarte importantă cu efecte deosebite asupra performan-țelor tehnice ale noului sistem.

Necesitate codificării care este generată de: operații de grupare, ierarhizare și locali-zare a elementelor; utilizarea mai bună a suportului și a memoriei; minimizarea timpului de răs-puns și a erorilor; securitatea, confidențialitatea și abstractizarea informațiilor; simplitatea u-tilizării codurilor; uniformizarea denumirilor; posibilitatea manipulării electronice a informații-lor.

Obiectul codificării care constă în: obiecte, fenomene, operații, proprietăți, etc.; intrări sau ieșiri din sistem; elemente auxiliare.

Cerințele codificării sau reguli ce trebuiesc respectate: unicitatea codului; stabilitatea și suplețea în timp; controlabilitatea codului; comoditatea utilizării; concizia; extensibilitatea.

Funcțiile codurilor: descriptivitate totală sau parțială a obiectului codificat; identifi-carea parțială sau concretă; control corectitudinii codului; operativitatea prelucrării.

Tipologia codurilor – sau tipurile de coduri posibile după: natura caracterelor: nume-ric, alfabetic, alfanumeric; modul de control al erorilor: autodetectoare de erori, autocorectoare; structură: secvențiale, structurate (ierarhizate, juxtapunere); modul atribuirii: manual, automat.

Realizarea codificării este procedeul prin care se asigură: determinarea obiectelor codi-ficabile; pregătirea codificării; realizarea nomenclatorului de coduri; întreținerea nomenclato-rului.

Coduri standard utilizate: cod document; cod bancar; cod operație; cod beneficiar/ cli-ent; codificare statistică.

2.5. Modelarea datelor și modelarea prelucrǎrilor

O ramură foarte importantă în proiectarea unei aplicații o reprezintă modelarea datelor și a felului în care ele relaționeazǎ între ele. Tehnologia de specialitate a stabilit mai multe mo-dalități prin care se pot determina structura tipurilor de date cu care se va lucra.

Proiectarea și realizarea unui sistem informatic care presupune prelucrarea automată a datelor necesită, pe lângă activitățile legate de formularea problemei, de analiză acesteia în ve-derea găsirii algoritmului de rezolvare și o altă activitate, deosebit de importantă, legată de or-ganizarea datelor, în concordanță atât cu caracteristicile tehnice ale echipamentelor de calcul, cât și cu cerințele de prelucrare. Acestea trebuie să fie structurate astfel încât prin codificarea și apoi memorarea lor pe suporți tehnici să permită prelucrarile necesare, stocarea și regăsirea ulterioară a datelor după criteriile stabilite.

Modelarea conceptuală a datelor reprezintă o metodă abstractă de reprezentare a tipu-rilor de date, a legăturilor dintre acestea, a dinamicii acestor legături prin intermediul unor con-cepte specifice cum ar fi: tip entitate, tip relație, tip proprietate, cardinalitate, chei primare, chei secundare, etc.

Modelul logic al datelor se obține în urma conversiei MCD pe MOD prin următoarele etape:

transformarea MCD/MOD, exprimat prin formalismul entitate – relație, în MLD exprimat prin formalismul specific SGBD folosind un model relațional propus de E.F.CODD sau navigațional propus de CODASYL;

cuantificarea modelului logic;

optimizarea generală pentru realizarea MLD optimizat.

Modelarea logică a prelucrărilor (MLP) cuprinde ansamblul de acțiuni, concepte și documente aferente descrieri structuri logice a prelucrărilor și descriere a modelului sau mo-delelor posibile de prelucrare a datelor în conformitate cu parametri fixați anterior: SO, arhi-tectura comunicațiilor, tipul de structuri utilizate și SGD ales. Modelul logic trebuie să asigure funcțiile:

Modelarea logică a prelucrărilor se bazează pe rezultatele furnizate de modelul con-ceptual și organizatoric al prelucrărilor și el trebuie să asigure următoarele funcții: structu-rarea sistemului în componente logice: subsisteme, aplicații, proceduri sau unități logice de prelucra-re; modelarea prelucrărilor la nivel logic prin folosirea conceptelor: centru de lucru logic, mași-nă logică, unitate logică de prelucrare, subschemă logică de date;

Figura nr. 2 Structura unui Sistem Informatic

Subsistemul informatic – este o parte a SI prin intermediul căreia se automatizează o funcție asociată unui organism sau o operație a unei funcții;

Aplicația Informatică (AI) – este o componentă a unui subsistem informatic ce asigură informatizarea unei activități, proces sau a unei operații complexe;

Unitatea Logică de Prelucrare (ULP) este o parte componentă a AI caracterizată prin prelucrări omogene și specifice ce acționează asupra unei SD specifice sau unui DP se mai numește și procedura logică.

Modelarea fizică a datelor are ca element central conceptul de bază de date, apărut ca o necesitate a eliminării neajunsurilor generate de realizare a aplicațiilor bazate pe fișiere în care structura fișierelor era descrisă în programe, iar activitatea de întreținere devenise greoaie.

O ramură foarte importantă în proiectarea unei aplicații o reprezintă modelarea datelor și a felului în care ele relationeaza între ele. Tehnologia de specialitate a stabilit mai multe mo-dalități prin care se pot determina structura tipurilor de date cu care se va lucra.

Proiectarea și realizarea unui sistem informatic care presupune prelucrarea automată a datelor necesită, pe lângă activitățile legate de formularea problemei, de analiză acesteia în ve-derea găsirii algoritmului de rezolvare și o altă activitate, deosebit de importantă, legată de or-ganizarea datelor, în concordanță atât cu caracteristicile tehnice ale echipamentelor de calcul, cât și cu cerințele de prelucrare. Acestea trebuie să fie structurate astfel încât prin codificarea și apoi memorarea lor pe suporți tehnici să permită prelucrarile necesare, stocarea și regăsirea ulterioară a datelor după criteriile stabilite.

Legăturile și relațiile dintre date poate fi stabilit prin Modelarea Conceptuală a Datelor, această modalitate fiind reprezentată prin modelul Entitate-Asociere (Diagrama Entitate – Aso-ciere sau DEA).

Luând în considerare activitatea firmei, comercializarea produselor software găsim că:

– firma primește prin diferite metode abordate de clienți comenzile pentru achizitio-narea produsului/lor.

– după ce comenzile sunt primite un utilizator introduce datele primite în sistem. Apoi alt utilizator se ocupă de verificarea datelor urmând să completeze cu detalii comanda primită inițial.

– firma are câte un responsabil pentru fiecare client (bancă) cu care aceasta colabo-rează.

– fiecare comandă reprezintă un tip de produs ce trebuie distribuit în funcție de nece-sitǎțile clientului.

2.7. Stabilirea colecțiilor de date

Organizarea datelor ocupă un loc important în proiectarea sistemelor informatice, de a-ceasta depinzând eficiența sistemului informatic. Organizarea datelor presupune:

definirea, structurarea, ordonarea și gruparea datelor în colecții omogene de date ;

stabilirea legăturilor (relațiilor) între date, între elementele unei colecții de date, res-pectiv între colecții de date;

reprezentarea datelor pe un suport informațional prelucrabil intr-un sistem de calcul.

Pe lângă cerințele legate de timpul de acces la date, de spațiul de memorie, organizarea datelor urmărește realizarea unicității datelor.

După ce au fost definite și corelate relațiile dintre entitătile ce urmeazǎ a fi implemen-tate în baza de date fizicǎ, urmeazǎ a fi definite și atributele fiecǎrei entităti prin care se vor crea respectivele legături.

În cele ce urmeaza se vor defini atributele pentru fiecare entitate:

CONTINUT (Comanda)

– id, Account_Manager, Banca, Data_Comanda, Nume_Client, Adresa_Client, Telefon_Client, CNP_RegCOM, Nr_Inreg_Fiscala, Banca_Client, Sucursala_Banca, Cont _Banca,Tip_Produs, Persoana_Contact, Telefon_Contact, Consultant_Delegat, Data_ livrare , Data_Confirmare_primire.

UTILIZATOR

-id, accType, userName, userEmail, US, PS, defaultuserResPerPage, userResPerPage, userBanks, userFields, defaultuserFields,userModify, defaultuserModify, userModifyC, defaultuserModifyC,userView,defaultuserView,userAdd,defaultuserAdduserDelete,defaultuserDelete,userPostNav,defaultuserPostNav,userSort,defaultuserSort,userSortDir,defaultuserSortDir, userMessages, defaultuserMessages, userReports, default user Reports.

MESSAGES

– id, userFrom, userTo, userMessage, userMessageTitle, data

BANKS

– id, Banci

PRODUCTTYPE

– id, Produs

Analizând datele culese din modul în care firma funcționează în prezent identificăm următoarele entități:

– COMENZI

– BĂNCI

– TIPURI PRODUSE

– UTILIZATORI

– MESAJE

2.6. Diagrama Entitate – Asociere

Modelul Entitate-Asociere (Entity-Relationship Model) este un model conceptual de nivel înalt al unei baze de date, care definește mulțimile de entitǎți și asocierile dintre ele, dar nu impune nici un mod specific de structurare și prelucrare a datelor.

Elementele esențiale ale modelului Entitate – Asociere sunt entitǎțile (entities) și aso-cierile dintre acestea (relationships).

O entitate (entity) este "orice poate fi identificat în mod distinctiv"; o entitate se referǎ la un aspect al realitǎții obiective care poate fi deosebite de restul universului și poate reprezenta un obiect fizic, o activitate, un concept, etc. Orice entitate este descrisǎ prin atributele sale. Un atribut (attribute) este o proprietate care descrie un anumit aspect al unei entitǎți.

Toate entitǎțile similare, care pot fi descrise prin aceleași atribute, aparțin unui ace-luiași tip de entitate (entity type), iar colecția tuturor entitǎților de același tip dintr-o bazǎ de da-te constitue o mulțime de entitǎți (entities set). În general, în modelul E-A se folosește aceeiași denumire atât pentru un tip de entitate cât și pentru mulțimea entitǎților de acel tip.

În proiectarea bazelor de date se considerǎ douǎ categorii de entitǎți: entitǎți normale (puternice, obisnuite-regular entities) și entitǎți slabe (dependente -weak entities).

Entitǎțile normale au o existențǎ proprie în cadrul modelului, în timp ce entitǎțile slabe nu pot exista decât dacǎ existǎ o entitate normalǎ (puternicǎ) cu care sunt asociate. De exemplu, o entitate “dependent” poate sǎ reprezinte o persoanǎ care depinde de un angajat al unei institu-ții (adicǎ se aflǎ în întreținerea acestuia). O entitate “angajat” este o entitate puternicǎ, deoarece ea existǎ în mod mod normal în modelul activitǎții instituției, în timp ce o entitate “dependent” este o entitate slaba: nu se va înregistra o astfel de persoanǎ decât dacǎ pǎrintele (susținǎtorul) acesteia este angajat în acea instituție.

O asociere (relationship) este o corespondențǎ între entitǎți din douǎ sau mai multe mulțimi de entitǎți. Gradul unei asocieri este dat de numǎrul de mulțimi de entitǎți asociate. Asocierile pot fi binare (de gradul 2, între 2 mulțimi de entitǎți) sau multiple (între k mulțimi de entitǎți, k> 2).

Asocierile binare sunt, la rândul lor, de trei categorii, dupǎ numǎrul elementelor din fiecare dintre cele doua mulțimi puse în corespondențǎ de asocierea respectiva. Fiind date douǎ mulțimi de entitǎți, E1 și E2, se definesc urmǎtoarele categorii de asocieri binare:

• Asocierea “unul-la-unul” (one-to-one) este asocierea prin care unui element (entitate) din mulțimea E1 îi corespunde un singur element din mulțimea E2, și reciproc; se noteazǎ cu 1:1.

Asocierea “unul-la-multe” (one-to-many) este asocierea prin care unui element din multimea E1 îi corespund unul sau mai multe elemente din multimea E2, dar unui element din E2 îi corespunde un singur element în multimea E1; se noteaza cu 1:N.

Asocierea “multe-la-multe”(many-to-many) este asocierea prin care unui element din multimea E1 îi corespund unul sau mai multe elemente din multimea E2, si reciproc; se noteaza cu M:N.

O asociere între douǎ sau mai multe mulțimi de entitǎți este, în același timp, o asociere între tipurile de entitǎți corespunzǎtoare.

Diagrama Entitate – Asociere (Entity-Relationship Diagram) reprezintǎ modelul Enti-tate Asociere prin mulțimile de entitǎți și asocierile dintre acestea.

Existǎ numeroase variante de notații pentru redarea diagramei E-A. Una dintre cele mai folosite notații reprezintǎ un tip de entitate (precum și mulțimea de entitǎți de acel tip) prin-tr-un dreptunghi, iar atributele tipului de entitate prin elipse conectate printr-o linie continuǎ la acesta. Pentru entitațile puternice se utilizeazǎ un dreptunghi încadrat cu o linie simplǎ, iar pen-tru entitațile slabe se utilizeazǎ un dreptunghi încadrat cu linie dublǎ.

O asociere (tip de asociere) dintre douǎ sau mai multe tipuri de entitǎți se reprezintǎ printr-un romb conectat prin link-uri (linii continue, formate din unul sau mai multe segmente) la tipurile de entitǎți asociate. O asociere poate sǎ aibǎ sau nu un nume; dacǎ are un nume, aces-ta poate fi înscris în rombul respectiv sau în vecinatatea acestuia. Categoria asocierii se noteazǎ prin înscrierea multiplicitǎții pe fiecare link care conduce la un tip de entitate.

Este posibil ca o asociere sǎ prezinte ea însǎși atribute, și aceste atribute se reprezintǎ prin elipse conectate la asocierea respectivǎ.

Figura nr.3 Diagrama Entitate-Asociere

Relațiile dintre tabele:

Utilizator – Mesaje = PK username FK userFrom

Utilizator – Comenzi = PK username FK Account_Manager

Tip Produs – Comenzi = PK Proprietati FK Tip_Produs

Banci – Comenzi = PK Banci FK Banca.

2.8. Alegerea tehnologiei de prelucrare

Comerțul electronic reprezintă multitudinea proceselor software și comerciale necesare afacerilor să funcționeze numai, sau în primul rând, utilizând fluxuri digitale de date. Comerțul electronic presupune utilizarea Internetului, comunicații digitale și aplicații software în cadrul proceselor de vânzare/ cumpărare, el fiind o componentă a procesului de e-business.

În momentul de față există o multitudine de firme care utilizează comerțul electronic, în domenii diverse ca marketing direct, vânzări, servicii pentru clienți, servicii bancare, distri-buirea sigură a informațiilor etc.

Aplicațiile de comerț electronic sunt orientată către consumatorul final (B2C) sau către alți comercianți (B2B).

Noile activități bazate pe Tehnologia informației și comunicațiilor (TIC) au un impact deosebit asupra societății. În este prezentat impactul asupra afacerilor, precum și avantajele utilizării noilor tehnologii în activitățile de comerț și afaceri. De exemplu, se constată că prac-ticarea marketingului pe Internet este cu 25% mai ieftin decât prin metodele obișnuite. Princi-palele cerințe pentru aplicațiile de comerț electronic sunt: interfețe puternice; fiabilitate foarte mare; securitate ridicată si viteză ridicată de prelucrare și transmitere a datelor.

Software pentru comerț electronic include componente pentru realizarea prezentării, componente pentru efectuarea sigură a plăților cu ajutorul cărților de credit sau de debit și com-ponente pentru securizarea tranzacțiilor.

Principalele caracteristici ale aplicațiilor electronice care oferă servicii de succes sunt: capacitatea de utilizare, scalabilitatea, siguranța, fiabilitatea, mentenabilitatea, disponibilitatea și eficiența.

Există mai multe modalități de realizarea a site-urile de comerț electronic: pornind de la zero, prin particularizarea unor aplicații generice și prin utilizarea unor platforme dedicate.

Dezvoltarea aplicațiilor de comerț electronic pornind de la zero presupune utilizarea unei tehnologii de tip server-side scripting existentă alături de serverul HTTP. Tehnologiile de tip server-side scripting necesită un interpretor de scripturi, acestuia asociindu-se unui limbaj de server-side scripting. Caracteristicile generale ale aplicațiilor realizate folosind aceste tehnologii pe partea de server, indiferent de limbajul de scripting folosit sunt:

necesită un procesor pentru paginile dinamice sau un mediu de execuție;

într-o pagină de script pot fi îmbinate limbajul HTML și secvențe de cod;

secvențele de cod care sunt executate pe partea de server, înainte de a tri-mite pagina la client;

există astfel posibilitatea de a particulariza paginile în mod dinamic;

oferă posibilitatea de interacțiune cu baze de date diferite;

au acces la toate resursele serverului Web (fișiere, rețea).

Tehnologia ASP.NET dezvoltată de Microsoft permite crearea și rularea în mod dina-mic a aplicațiilor Web interactive în cadrul platformei Microsoft.NET. Folosind ASP.NET se pot combina pagini HTML, comenzi de script și diferite controale pentru crearea de pagini Web interactive sau aplicații Web complexe. Dezvoltarea aplicațiilor Web folosind tehnologia ASP. NET se realizează prin intermediul unor limbaje moderne de programare (C#, VB.NET), care utilizează aceleași biblioteci de clase.

Clienții, prin intermediul unui navigator Internet, accesează pagini JSP care conțin cod Java executat pe mașina virtuală Java (JVM) de pe sever. Rezultatele prelucrărilor efectuate sunt trimise clientului în format HTML prin serverul Web. Fișierele JSP sunt transformate de către procesorul JSP în fișiere sursă Java, care conțin pe lângă codul existent în fișierele JSP și sec-vențe de cod propriu motorului JSP.

Un servlet este un program Java care rulează în cadrul serverul Web sau al servelor de aplicații și funcționează ca un strat de mijloc între cererile provenite de la clienți și aplicații sau baze de date existente pe partea de server.

J2EE (Java 2 Platform, Enterprise Edition) definește un standard pentru dezvoltarea aplicațiilor de întreprindere multi-strat. Aplicațiile de întreprindere sunt simplificate prin utilizarea de componente modulare standardizate, având un set complet de servicii care preiau o parte din funcționalitatea aplicațiilor, astfel încât atenția se va concentra la partea de business.

Platforma J2EE utilizează platforma J2SE (Java 2 Platform, Standard Edition), în plus fața de aceasta oferă suport pentru:

Java Servlets API ;

tehnologia JSP;

componente EJB (Enterprise JavaBeans);

conectivitate la baze de date;

tehnologia XML;

interconectivitate cu servicii Web. Standardul J2EE include specificații complete pentru asigurarea portabilității cu majoritatea sistemelor de tip enterprise existente.

Tehnologia PHP (Hypertext Preprocessor) utilizează un limbaj de scripting pe partea de server care oferă o serie de funcții pentru:

acces la majoritatea bazelor de date;

afișarea de imagini și fișiere PDF;

acces la diferite servicii;

prelucrarea fișierelor XML;

realizarea plăților online.

Arhitectura aplicațiilor de comerț electronic bazate pe JSP conține elementele de bază necesare funcționării aplicației, fiind prezentate componentel la nivel generic.

În funcție de tehnologia și platforma utilizate, de numărul de utilizatori, numărul și varietatea de produse și servicii oferite, se alege sistemul de gestiune a bazelor de date. Printre cele mai cunoscute se enumără Microsoft SQL Server, Oracle, IBM DB2, Ingres, PostgreSQL, MySQL.

Timpul necesar dezvoltării aplicațiilor de comerț electronic pornind de la zero este destul de mare, costurile variind în funcție de dimensiunea și complexitatea aplicației.

Utilizarea de pachete software predefinite destinate comerțului electronic reduce consi-derabil timpul necesar realizării aplicațiilor de comerț electronic, acesta fiind avantajul prin-cipal.

În cazul în care se dorește extinderea sau modificarea aplicației, flexibilitatea acestei soluții este relativ redusă.

În sunt prezentate cele mai utilizate platforme de comerț electronic atât pentru B2C cât și pentru B2B. Astfel, producătorii cu cea mai mare cotă de piață sunt ATG, BroadVision, IBM, Microsoft, Oracle și SAP.

Produsele oferite de ATG, Broad Vision și IBM conduc în aplicațiile destinate comer-țului de tip B2C iar cele ale IBM, Oracle și SAP furnizează cele mai bune opțiuni pentru comer-țul de tip B2B. Cea mai mare prezentă pe piața o au produsele oferite de IBM, Microsoft, Oracle și SAP.

2.9. Estimarea necesarului de resurse și a calendarului de realizare

Resurse Hardware

Pentru a accelera procesul de proiectare va fi nevoie de 3 computere dotate cu procesoare de ultimă generație, Intel Core 2 Duo sau echivalent, 1GB Ram și 100 GB HDD, care vor rula în paralel. În acest fel procesul de proiectare v-a scădea la jumătate.

Resurse software

Ca și resursă software este necesar ca fiecare computer să fie dotat cu sistem de ope-rare Microsoft Windows XP (deoarece aplicatia va fi proiectată pentru platforma Windows), alături de MSSQL Server 2005 si de serverul APACHE plus PHP.

Resurse umane

Un inginer proiectant pentru Baza de Date, un inginer proiectant pentru punerea la punct al iesirilor/intrărilor, un inginer proiectant pentru clasele/modulele aplicatiei.

Resurse financiare

Se estimează o suma de proiectare / programare / implementare de 30.000 euro.

Estimare total numar zile pentru elaborarea proiectului

Se estimeaza un total de aproximativ 92 de zile

Capitolul 3 Proiectarea de detaliu a aplicatiei informatice

3.1. Definirea obiectivelor aplicatiei informatice

Pentru activitatea din cadrul Departamentului au fost stabilite următoarele obiective ale noului sistem informatic:

– crearea unei posibilități de management și organizare centralizate a datelor de intrare.

– asigurarea redundanței și securității datelor.

– automatizarea procesului de schimb de informații între membrii departamentelor și în cadrul acțiunii de atribuire de responsabilitate.

– implementarea unui sistem de software care va permite o evidența clară a numă-rului de rapoarte a fost realizat într-o anume perioadă sau de către o anumită persoană.

Aplicația care urmează a fi dezvoltată se interpune manageriide cont, consultanții și departamentul de contabilitate, creând o relație automatizată între departamentele respective.

3.2. Proiectarea logica si fizica a intrarilor

După ce acestea au fost definite în cadrul proiectării de ansamblu, acestea urmează a fi detaliate.

Sistemul va funcționa în felul următor:

– Clientul trimite o comandă sub formă electronică, fie că aceasta este sub formă de email sau fax.

– Detaliile incluse în această cerere sunt următoarele:

Bancă, Data _Comandă, Numele Clientului,AdresăClientului, TelefonulClientului, CNP sau Nr. Reg. COM, Nr. Inreg. Fiscală, Banca Clientului, Sucursală Băncii, Cont Bancă, Tipul Proprietății, Persoană Contact, Telefon Contact.

Aceste detalii vor fi completate în continuare cu: Data Comandă și Consultant de către Account Manager iar Consultantul va completa și el la rândul lui Data Distribuire și Da-ta Livrare.

3.5. Proiectarea bazei de date

Activitățile fazei de proiectare detaliată privesc componentele principale ale oricărui sistem informatic, respectiv baza de date, interfețele (formulare, rapoarte, meniu) și programele. Desfășurarea acestor activități nu este secvențială ci, mai curând, paralelă și iterativă. Baza de date trebuie sa reflecte specificațiile de proiectare privind formularele și rapoartele din sistem, iar proiectarea formularelor și rapoartelor nu poate fi finalizată fără ca schema bazei de date să fie clar definită. Totuși, baza de date reprezintă „nucleul” oricărui sistem informatic, în jurul său „gravitând” celelalte componente.

Principalele activități care formează ciclul de viață al bazei de date sunt: proiectarea schemei logice, proiectarea fizică a bazei de date și alocarea datelor în rețea, implementarea și întreținerea bazei de date.

Proiectarea logică presupune organizarea datelor în tabele și coloane, conform regu-lilor modelului relațional (acesta fiind modelul cel mai popular de organizare a datelor). După cum se poate observa din figura 5, proiectarea logică a bazei de date presupune transformarea modelului conceptual al datelor prin aplicarea regulilor și conceptelor specifice modelului rela-țional și a criteriilor de calitate aplicabile modelului logic al datelor, aspecte ignorate în etapa modelării conceptuale. Scopul urmărit constă în obținerea unui model relațional pur, adică neafectat de cerințele nefuncționale și cele de performanță în accesarea datelor, nici de facili-tățile oferite de diferite SGBD-uri existente pe piață. Toate aceste aspecte sunt înglobate în eta-pa proiectării fizice a bazei de date.

Figura 5. Nivelurile de abstractizare a datelor

Obiectivul principal al proiectări fizice constă în optimizarea performanțelor bazei de date în ce privește stocarea fizică și accesul la date. În unele situații timpii de acces ceruți pot fi obținuți prin intermediul indecșilor însă, de multe ori este necesară modificarea structurii logice a datelor prin procesul denormalizării. Dacă la proiectarea schemei logice s-a urmărit prezer-varea integrității datelor prin procesul de normalizare, acum poate deveni necesară introducerea unui anumit nivel de redundanță a datelor sau introducerii în schema bazei de date a câmpurilor calculate. Principala provocare constă în găsirea compromisului optim între ușurința păstrării integrității datelor și performanțele bazei de date. Denormalizarea implică selectarea proceselor dominante (interogare și actualizare a datelor) pe baza frecvenței, volumului de date și priorității acestora, evaluarea costurilor totale ale operațiunilor de actualizare, interogare și stocare a datelor, precum și evaluarea efectelor determinate de pierderea integrității datelor.

De asemenea, la proiectarea fizică vor fi luate în considerare și facilitățile oferite de SGBD-ul ales. Diferențele dintre diferite SGBD-uri se referă adesea la tipurile de date suportate, reprezentarea sau nu a relațiilor dintre clase și subclase, implementarea relațiilor recursive.

Prin urmare, schema logică a bazei de date poate diferi, mai mult sau mai puțin, de schema fizică a bazei de date.

Proiectarea schemei logice a bazei de date poate fi realizată în mai multe moduri. Abordarea tradițională, aplicată în special bazelor de date relaționale, presupune constituirea re-lației universale prin reunirea tuturor datelor elementare (atribute) identificate în faza de analiză și repartizarea lor în tabele pe baza analizei dependențelor dintre atribute (dependențe func-ționale, dependențe multivaloare și de joncțiune) și aplicarea procesului de normalizare. Această abordare a înregistrat unele succese în cazul bazelor de date de dimensiuni mici și medii, însă ea devine foarte greoaie în cazul bazelor de date de dimensiuni mari și foarte mari.

Introducerea modelului entitate-relație (ER) a determinat reorientarea specialiștilor către o nouă abordare în proiectarea bazelor de date. Modelarea conceptuală a datelor cu ajuto-rul diagramelor entitate-relație (DER) a fost descrisă prima dată în lucrările lui P.P. Chen, publi-cate în 1976, deși primele încercări de formalizare sunt înregistrate în anii ’60 și aparțin lui Charles Bachman. Ulterior, modelul lui Chen a înregistrat numeroase modificări și extensii. Simplitatea, ușurința învățării și posibilitatea formalizării cerințelor sistemului așa cum sunt ele în realitate, independent de opțiunile de organizare și tehnologice au sporit vertiginos popula-ritatea modelului ER încă din anii ’80.

Noua abordare presupune, mai întâi, modelarea conceptuală a datelor prin construirea diagramei entitate-relație (DER), care evidențiază entitațile de date ale sistemului, proprietățile acestora și legăturile dintre entități. Ulterior, prin aplicarea unor reguli simple, are loc trans-formarea modelului entitate-relație în schema logică a bazei de date. Tabelele astfel obținute sunt în final analizate din perspectiva normalizării putând rezulta noi tabele.

Utilizarea modelului ER oferă o serie de avantaje fața de abordarea tradițională repre-zintă un util instrument de comunicare între proiectanți și utilizatorii finali pe parcursul fazelor de analiză și proiectare logică; este foarte ușor de înțeles și conceput. În general, prezentarea grafică permite exprimarea unui volum mare de informații sub o formă compactă, ușor de urmărit și înțeles; utilizează conceptul de abstractizare, ceea ce reduce considerabil numărul obiectelor luate în considerare la analiza și proiectarea bazei de date. Prin utilizarea noțiunii de entitate ca abstractizare pentru datele elementare (atribute) se vor analiza mai puține obiecte (numărul entitaților de date este mult mai mic decât numărul datelor elementare din sistem) și mai puține relații între obiecte (numărul relațiilor dintre entități este mult mai mic decât numărul relațiilor de dependență existente între atribute). Deși datele elementare sunt reprezentate și în această abordare, ca proprietăți ale entităților, totuși numărul dependențelor ce trebuie analizate este mult redus, fiind luate în considerare doar dependențele la nivelul entităților (adică dependențele dintre atributele unei entități) și nu la nivelul întregii baze de date (adică dependențele dintre atributele relației universale).

Existența unui set complet de reguli de transformare a DER în tabele ale bazei de date. Aceste reguli permit transformarea simplă și rapidă a cerințelor informaționale ale sistemului, structurate în DER, în baza de date. Majoritatea instrumentelor CASE oferă suport pentru generarea automată a bazei de date în funcție de SGBD-ul dorit.

Din cele prezentate rezultă că există două strategii de proiectare a bazei de date:

strategia bottom-up, reprezintă abordarea tradițională și presupune constituirea relației universale care urmează a fi supusă normalizării pentru a se obține tabelele bazei de date;

strategia top-down, presupune construirea DER care va fi apoi transformată într-un set de tabele prin aplicarea unor reguli. Tabelele astfel obținute vor fi analizate din perspectiva normalizării.

Pornind de la aceste două strategii, pot fi identificate mai multe demersuri de proiec-tare a bazei de date, mai mult sau mai puțin riguroase. Două dintre ele corespund celor două strategii, ele fiind descrise pe scurt anterior. Un demers mai riguros presupune combinarea celor două strategii; se aplică ambele strategii obținându-se două modele logice ale datelor, iar din compararea lor va rezulta schema logică finală a bazei de date. Acest demers presupune par-curgerea următorilor patru pași:

Construirea câte unui model logic al datelor pentru fiecare categorie de utilizatori iden-tificată. Acest pas presupune normalizarea imaginilor asupra bazei de date (formulare și ra-poarte) specifice fiecărei categorii de utilizatori.

Integrarea perspectivelor, care presupune combinarea tuturor perspectivelor normalizate ale uti-lizatorilor și obținerea schemei globale a bazei de date.

Întocmirea modelului conceptual al datelor pentru întregul sistem și transformarea acestuia într-un set de tabele normalizate.

Compararea modelului logic consolidat al datelor rezultat prin integrarea perspec-tivelor utilizatorilor cu cel obținut prin transformarea DER, în vederea definirii modelului logic final.

În practică, poate fi angajat un alt demers mai simplu de proiectare a bazei de date, constând în transpunerea directă a cerințelor sistemului în modelul logic al datelor, fără parcurgerea unor pași intermediari. Un asemenea demers poate fi aplicat în cazul bazelor de date de dimensiuni foarte mici sau dacă proiectantul are o mare experiență în domeniul proble-mei. Oricum, alegerea unui demers sau a altuia depinde de complexitatea bazei de date, expe-riența echipei de proiectare, timpul și resursele financiare disponibile sau cerințele de calitate dorite.

Structurarea datelor în fișiere este o operație de definire a structurilor logice, de des-criere a conținutului informațional pe articole. Structurarea logică se prezintă ca un șir de carac-tere constituit prin concatenarea mai multor elemente informaționale.

Proiectarea structurilor logice constă în stabilirea elementelor informaționale care compun articole ținându-se seama de conținutul real al intrărilor informaționale de rolul fiecărui fișier în procesul prelucrării. Structura datelor din fișier implică definirea conținutului informa-țional al articolelor.

Prin precizarea caracteristicilor logice de utilizare analistul stabilește caracteristicile descriptive specifice datelor și modul lor de existentă și utilizare.

Caracteristica principală pe baza careia se stabilește formatul articolelor este factorul de repetitivitate al anumitor elemente informaționale din structură. Indicatorii de activitate ai fișierelor sunt obligatoriu de definit și respectat deoarece nivelul lor sunt condiție esențiala a realizării următoarelor operații:

stabilirea necesarului de suporturi tehnice de date;

estimarea duratelor de exploatare a fișierelor;

planificarea operațiilor de culegere și control.

Indicatori pentru fișiere – cei mai reprezentativi indicatori folosiți pentru gestiunea datelor a căror nivele maxime trebuie estimate la momentul proiectării logice sunt:

n (numărul de articole estimate în perioadele de vârf din activitate)

ns (numărul de articole șterse la momentul actualizării unui fișier)

na (numărul de articole noi adăugate la momentul actualizării unui fișier

ne (numărul de articole exploatate la momentul unei prelucrări automate)

nm (numărul de articole modificate la momentul actualizării unui fișier)

Un indicator utilizat frecvent pentru caracterizarea stabilitătii în timp, stabilitate specifică pentru fiecare tip de colecție în parte este ponderea (m) a articolelor actualizate într-o perioadă de timp.

Pentru caracterizarea modului de utilizare al articolelor din fișier, în procesul prelu-crării, se poate calcula indicele de utilizare al articolelor din fișier (Iu).

Proiectarea fizică de detaliu a fișierelor. Caracteristicile fizice la nivel de fișier – vizea-ză în principiu asocierea acelor parametrii generali și a acelor atribute reprezentative care des-criu cel mai bine proprietățile colecției de date și mediul lor de stocare, fișierele sunt recunos-cute și utilizate de diferite componente din cadrul sistemelor de operare.

Proiectarea structurii bazelor de date – structura bazei de date reprezintă un model al datelor exprimat în concepte specifice unui anumit sistem de gestiune a bazelor de date (SGBD), lucru ce face ca proiectarea bazei de date să reprezinte transpunerea modelelor concep-tuale în termenii unui model al datelor suportat de un anumit tip de SGBD, model ierarhic, re-țea, relațional, funcțional.

Determinarea legăturilor dintre colecțiile de date și a modului de reprezentare a aces-tora se realizează pe baza legăturilor naturale dintre obiectele descrise cu ajutorul entităților identificate. Presupunem entitățile “gestiuni” și “materiale”, relațiile dintre entități pot fi de 3 tipuri:

Relații de tipul unu la unu –atunci când într-o gestiune se poate afla un singur material iar un material aparține unei singure gestiuni;

Relații de tipul unu la mulți atunci când într-o gestiune se pot afla unul sau mai multe materiale, iar un material aparține unei singure gestiuni.

Relații de tipul mulți la multi atunci când într-o gestiune se pot afla unul sau mai multe materiale, iar un material poate aparține uneia sau mai multor gestiuni.

Pentru entitățile gestiuni și materiale, pot exista gestiuni care nu dețin nici un material, reprezentând gestiunile de produse finite dar nu poate exista un material care să nu apartină nici unei gestiuni.

Proiectarea tehnologiilor de prelucrare a datelor. Caracteristicile tehnologiei de prelu-crare automată a datelor – se poate defini ca fiind ansamblu de procedee, mijloace și metode utilizate în domeniul prelucrarii automate a datelor, având ca scop final, obținerea unor tabele, liste, grafice și alte tipuri de situații de ieșire ce conțin informațiile necesare fundamentării deciziilor, controlul execuției lor și execuția unor operațiuni.

Obicectivele urmărite în proiectarea organizarea și funcționarea tehnologiei de pre-lucrare automată a datelor, sunt subordonate obiectivului principal: asigurarea furnizării din pro-cesul prelucrării, în timp util, a informațiilor necesare și suficiente de calitate corespunzătoare și cu cost minim pe unitatea de informație prelucrată și modificată.

Tehnologia de prelucrare automată a datelor trebuie să asigure realizarea obiectivelor secundare:

utilizarea eficientă a resurselor implicate;

realizarea concordanței între cerințele concrete și metodele și procedeele utilizate;

asigurarea calității informației în procesul prelucrării și păstrării ei pe parcursul întregului flux.

Operațiile tehnologice în prelucrarea automată a datelor sunt:

operații tehnologice de pregătire a datelor în vederea prelucrării lor auto-mate;

operații tehnologice de prelucrare propriu-zisă a datelor;

operații tehnologice de redare a rezultatelor obținute prin prelucrare.

3.6. Schema de sistem a aplicatiei