APLICATIE PENTRU UN MAGAZIN VIRTUAL

CUPRINS s5g1gm
1. INRODUCERE
1.1. CE ESTE PHP?
1.2. SQL MySQL
1.3. TEMA LUCRARII
NECESITATEA ELABORARII APLICATIEI
1.4. SPECIFICATII DE DEFINITIE
2. MEMORIU TEHNIC
2.1. APLICATIE CENTRATA PE BAZE DE DATE
2.2. ABORDAREA METODICA A ACTIUNII DE PROIECTARE A APLICATIEI ANALIZA PROIECTARE Diagrama Entitate-Relatie
Diagrama Functionala Tipul arhitecturii pentru aplicatia creata IMPLEMENTARE TESTARE DOCUMENTARE
3. MEMORIU JUSTIFICATIV
3.1. SCHEMA BAZEI DE DATE
3.2. CONTRIBUTII PERSONALE
4. CAIET DE SARCINI
5. MANUAL DE OPERARE
5.1 INSTALARE
5.2 UTILIZARE
6. DEZVOLTARI ULTERIOARE BIBLIOGRAFIE ANEXE 1. ANEXA TABELE SI CAMPURI DIN TABELE 2. ANEXA COD SQL 3. ANEXA COD 4. ANEXA TABELE 5. ANEXA FIGURI 1.Introducere

In partea introductiva a lucrarii vom prezenta cateva cuvinte despre PHP si MySQL, scopul aplicatiei, cerinta aplicatiei, posibilitatile de utilizare practica, precum si notiunile de baza utilizate de catre clienti, notiuni utilizate la comanda unor produse online.
De asemenea, din partea introductiva va rezulta si necesitatea dezvoltarii unei astfel de aplicatii si implicatiile pe care le are utilizarea acesteia in cadrul activitatii de cumparare (comanda ) si evidenta clientilor care au cumparat ceva si deci folosit aplicatia.
1.1Ce este PHP?
Am ales limbajul PHP pentru cu seamana cu limbajul C, este free, usor de configurat.
PHP este un limbaj de scriptare pe partea de server proiectat anume pentru Web. PHP a fost conceput in 1994 si a fost initial munca unui singur om, Rasmus Lerdorf.
Intr-o pagina HTML putem ingloba cod PHP care va fi executat la fiecare vizitare a paginii. Codul PHP este interpretat pe serverul Web si genereaza un cod HTML sau o alta iesire care va fi vazuta de vizitator.
Este una dintre cele mai interesante tehnologii existente in prezent, deoarece imbina caracteristici dintre cele mai complexe cu simplitatea in utilizare. Ca si alte limbaje de scripting pentru Web, PHP permite furnizarea unui continut Web dinamic, adica un continut Web care se modifica automat de la o zi la alta sau chiar de la un minut la altul. In fiecare zii se introduc produse noi in baza de date, se schimba preturi, se pot introduce noi functionalitati pentru aplicatie si toate aceste modificari au nevoie de un mediu de programare care sa nu se deterioreze si sa suporte modificari frecvente.
Continutul Web este un element important in sustinerea traficului unui site Web; de regula vizitatorii nu vor mai revenii la o pagina Web care contine aceleasi informatii ca si cele prezentate la ultima vizita.
Spre deosebire de limbajele de scripting, precum JavaScript, PHP ruleaza pe serverul Web nu in browserul Web.
In consecinta, PHP poate obtine accesul la fisiere, baze de date si la alte resurse inaccesibile programului JavaScript. Pentru a putea lucra cu Asp sau cu alte limbaje inafara de PHP ar trebui sa cunosc Visual Basic sau Java
1.2 SQL si MySQL
MySQL este un sitem de gestiune a bazelor de date relationale foarte rapid si robust. O baza de date ne permite sa stocam, sa cautam, sa sortam si sa regasim datele in mod eficient. Serverul MySQL controleaza accesul la date pentru a garanta ca mai multi utilizatori pot lucra simultan cu acestea. Deci MySQL este un server multi-user (mai multi utilizatori) si multi-thread (mai multe fire de executie). Utilizeaza SQL (Structured Query Language), limbajul standard de interogare a bazelor de date din toata lumea.
SQl este limbajul standard pentru accesarea sistemelor de gestiune a bazelor de date relationale (SGBDR). Este un limbaj relative simplu dar foarte puternic, care poate obtine accesul la datele stocate in mai multe tabele, poate filtra datele dorite si poate sorta, rezuma si afisa rezultatele.
Instructiunile SQL trebuie incorporate in scripturile PHP astfel incat programele noastre PHP sa poata lucra cu bazele de date relationale.
Utilizand SQL, este posiblil accesul la datele stocate intr-o baza de date relationala fara a scrie un program de aplicatie, permitand frecvent evitarea intarzierilor si a costurilor implicate de programarea personalizata.
Utilizarea bazelor de date MySQL
PHP include o biblioteca de functii care furnizeaza o interfata cu sistemul MySQL de gestiune a bazelor de date. Folosind aceste functii, un program PHP poate obtine accesul la datele rezidente dintr-o baza de date MySQL si le poate modifica.
Majoritatea interractiunilor cu o baza de date se desfasoara dupa un model secvential simplu:
• Se deschide o conexiune cu serverul MySQL
• Se specifica baza de date la care se va obtine accesul
• Se emit interogari SQL, se obtine accesul la rezultatele interogarilor si se executa operatii non-SQL
• Se inchide conexiunea cu serverul MySQL

1.3Aplicabilitate
Aplicatia este destinata tuturor persoanelor care navigheaza pe internet (au acces la internet) doresc sa cumpere produse sau doar sa afle informatii despre anumite produse si care nu au timp pentru a vizita magazine. In plus aplicatia are mai multe categorii de produse (cosmetice, flori etc) .
Se urmareste crearea unei aplicatii care sa permita comanda unor produse online; comenzi care sunt verificate de administratorul aplicatiei si care vor fi livrate in functie de anumite criterii.
Aplicatia are urmatoarele functionalitati:
• Posibilitatea de a naviga prin categoriile de produse
• Posibilitatea de a vizualiza un produs si marirea imaginii
• Posiblitatea de a alege un produs si cantitatea dorita
• Posibilitatea de a vizualiza produsele aflate in cos si suma totala de achitat
• Posibilitatea de a modifica cantitatea unui anumit produs
• Posibilitatea de a renunta la toate produsele din cos

1.4Spectificatii de definitie
In urma vizitarii mai multor site-uri de acest gen cu functionalitati asemanatoare si a analizari temei (cerintei) aplicatiei au rezultat o serie de notiuni specifice acestui domeniu, care vor fi utilizate la faza de implementare sub forma unor elemente de proiectare.
Notiunea categorii produse arata clasele de produse. Sunt identificate prin denumirea care reprezinta aspectul mai general si comun al tipurilor de produse si produselor care le contin. Intr-o categorie de produse se pot include tipuri de produse sau produse fara tip adica care fac parte dintr-o anumita categorie si care nu mai au nevoie de o descriere comuna rezumata la un tip (de produs).
Notiunea tip produs reprezinta o clasificare a produselor dupa anumite caracteristici comune. Se identifica printr-un id (unic), denumire, id-ul categoriei din care face parte acest tip de produs si o poza.
Produsul este obiectul care poate fii cumparat, vizializat prin marirea pozei atasta si care se identifica printr-o denumire, anumite cacteristici, pret si o poza.
Notiunea de client reprezinta acea persoana care a cumparat (comandat) produse de la magazinul nostru virtual si se identifica prin id si datele personale (nume, prenume, sex, e-mail, telefon).
Adresa contine, adresele (datele mai importante de identificare) a tuturor clientilor . Pentru ca datele despre un anumit client sa fie memorate in baza de date acesta trebuie sa emita o cerere de aprovizionare.
Notiunea de cerere de aprovizionare este alcatuita din doua elemente mai importante comanda propriu-zisa si datele clientului care o efectueaza. Se identifica printr-un id, o data la care a fost efectuata cererea si contine toate elementele de comanda care alcatuiesc comanda respectiva.
Deci notiunea de comanda se identifica printr-un id (care este unic pentru fiecare comanda), pretul total (suma care trebuie achitata de client in moentul livrarii) si data la care a fost facuta comanda. O comanda se compune din unul sau mai multe elemente de comanda;
Notiunea de element de comanda reprezinta de fapt un produs si cantitatea pe care clientul doreste sa o cumpere din acest produs. Se identifica prin id-ul comenzii, al elementului de comanda, id-ul produsului ales, cantitatea dorita si pretul in functie de numarul de bucati.
Notiunea de livrare inseamna trimiterea produselor la domiciliu si confirmarea ca au fost primate de catre clientul care l-ea comandat printr-o semnatura si se identifica prin id-ul livrarii, id-ul comenzii care a fost livrata si data la care s-a efectuat livrarea.

2.Memoriu Tehnic

2.1 Aplicatii cu baze de date

O aplicatie este in principiu o colectie software consolidata cu scopul de a rezolva un set dat de probleme. Rezolvarea problemelor prin punerea in practica a software-ului se numeste software engineering.
Desi de multe ori nu ne dam seama, folosim in permanenta bazele de date. Ori de cate ori selectam un produs, sau daca efectuam o cautare (de la un magazin virual) folosim o baza de date. Baza de date care este interogata (cu ajutorul instructiunilor limbajului SQL) si se face o selectie dupa niste criterii ( transmise prin anumite metode GET, POST din php etc.)
Notiunea de baza de date este strans legata de notiunea de date, care refera „fapte culese din lumea reala”. Baza de date se refera la un volum mare de date, care sunt stocate pe suport fizic; ea reprezinta, in cazul sistemului computerizat, echivalentul arhivei din viata reala. Poate fii asemanata cu un biblioraft care este pur si simplu un loc fizic in care pot fii stocate date, indiferent care ar fi ele, sau cum ar fi structurate.
Pentru o baza de date cel mai important lucru este manipularea datelor continute in acea baza de date. Aceasta „manipulare” se refera la operatiile care se pot efectua asupra datelor: operatii de adaugare a unor date noi, operatii de regasire, de modificare, de stergere a datelor existente (care se realizeaza cu ajutorul instructiunilor limbajului SQL).
In continuare voi rezuma argumentele care au stat la temelia alegerii pe care am facut-o -; alegerea unei aplicatii centrata pe baze de date.
Aveam nevoie ca aplicatia sa permita stocarea unui volum mare de date (categorii, tipuri de produse; produse; informatii despre clienti, comenzi etc), la care sa existe acces tot timpul. Se stie ca in cazul bazelor de date, accentul este pus pe operatiile de memorare si regasire, efectuate asupra unor volume mari de date si mai putin asupra operatiilor de prelucrare a datelor, care este domeniul altor categorii de aplicare a informaticii. Acest aspect a constituit pentru mine argumentul principal, care m-a determinat sa aleg acest tip de aplicatie.
- posibilitatea stocarii unui volum relativ mare de informatii, precum si accesul ulterior la aceste informatii;
- remanenta informatiei, care in cazul unei aplicatii standard, fara baze de date, era incerta. Astfel, utilizatorul aplicatiei va avea posibilitatea sa verifice la un moment dat comenzile efectuate la o anumita data, clientii care au comandat ceva.
- simplificarea procesului de calcul, care in cazul calculului tabelar ar fi avut o complexitate ridicata, fara a avea un control real asupra fluxului de informatie gestionat;
- transparenta totala a implementarii, utilizatorul aplicatiei nu trebuie sa cunoasca modalitatile efective de implementare, modul de stocare a datelor, verificarile de corectitudine a informatiilor introduse. Utilizatorul nu trebuie sa cunoasca ce se intampla cu o informatie introdusa in sistem, dar in acelasi timp acesta trebuie sa aiba acces la informatia respectiva;
- fiind vorba de sume de bani, securitatea metodelor de calcul trebuie sa fie ridicata, trebuie sa fie eliminata pe cat posibil posibilitatea introducerii de erori in rezultatul final, iar o aplicatie care utilizeaza baze de date reuseste sa atinga acest obiectiv. In acest sens sunt necesare o serie de verificari la introducerea de informatii in sistem, care sa evite aceste erori(cum ar fi de exemplu verificarea ca la introducerea unui produs in cos sau, sa nu poata fi introduse valori negative).

Doresc ca baza de date pe care o utilizez in aplicatia mea, magvir sa memoreze toate comenzile efectuate si datele despre toti clientii care au comandat ceva.

2.2 ABORDAREA METODICA A ACTIUNII DE PROIECTARE A APLICATIEI

Dezvoltarea unui sistem este o activitate laborioasa ce cuprinde o multitudine de sub-activitati("tasks") desfasurate intr-o maniera metodica. Aceste sub-activitati pot fi grupate in etape importante. Fiecare etapa are definite clar elementele livrate (adica ce produse finale sunt obtinute la incheierea etapei) etapelor ulterioare.
In cadrul fiecarei etape (stadiu) sub-activitatile tind sa fie de scurta durata si pot fi estimate cu usurinta. Fiecare sub-activitate este divizata in mai multe sub-sub-activitati. O anumita sub-sub-activitate se poate repeta de un numar de ori din diferite motive.
Vom discuta despre dezvoltarea pe baza modelului CASE(Computer-Aided Szstems Engineering).
Prezentam in mare etapele importante de dezvoltare, conform acestui model, fara a insista cu detalii asupra metodelor si sub-activitatilor corespunzatoare fiecarei etape :
- etapa de strategie -; obiectivul este de a produce un set de modele de business, un set de recomandari si un plan agreat pentru dezvoltarea sistemelor de informatii ce vor servi nevoilor curente si viitoare ale organizatiei, tinand cont de constrangerile financiare si tehnice ale organizatiei.a9i Este analizata problema care trebuie rezolvata, pe baza specificatiilor de definitie. Aceste specificatii sunt obtinute in urma analizarii cerintelor aplicatiei, in acest caz este vorba de studierea unui pagini de internet care se ocupa cu relaizareaunor aplicatii pentru magazine virtuale. etapa de analiza -; Preia si verifica lucrurile obtinute in etapa strategie si le expandeaza in detaliu suficient pentru a asigura acuratetea de business, fezabilitatea si un fundament sanatos pentru proiectare, in cadrul domeniului organizatiei si avand in minte sisteme existente;a9i
- etapa de proiectare -; pe baza etapei de analiza, se realizeaza proiectarea aplicatiei, in urma careia rezulta directive concrete pentru etapa de implementarea9i, de exemplu se realizeaza proiectarea schemei bazei de date, stabilirea functiilor de business necesare in sistem, etc.;
- etapa de implementare -; realizarea efectiva a aplicatiei, scrierea codului, realizarea bazei de date, compilarea aplicatiei sub forma unui program executabil;
- etapa de testare -; produsul software este testat in conditii normale de utilizare si se rezolva eventualele probleme;
- etapa de documentare -; se scrie documentatia aplicatiei(sub forma tiparita si/sau online), se face instruirea viitorilor utilizatori ai aplicatiei.

Figura 1. Ciclul de viata al unui sistem informatica9i

Rezultatul stadiilor strategie si analiza trebuie sa fie complet independente de orice tehnica de implementare specifica, pentru a da proiectantului oportunitatea maxima de a folosi tehnologia potrivita si pentru a proiecta in coexistenta cu sisteme curente. Metoda CASE trebuie sa fie doar scheletul, ea trebuie completata cu ideile proprii si inovatia contribuie la calitatea produsului final.
Business-urile sunt in continua miscare. In linii mari se schimba nu CE este facut ci CINE si CUM face. Modelele folosite pentru a defini cerintele business-ului trebuie sa permita modificari rezonabile in structura organizatiei. Modelele trebuie sa fie de asemenea independente de toate solutiile cunoscute.
Cerintele ar trebui modelate si definite intr-o maniera generica. Cerintele functionale ar trebui sa defineasca ce este facut, nu cum sau de catre cine. Structura datelor trebuie sa permita modificari: in structura organizatiei, pentru exceptii si pentru limite curente si observabile.a9i
Pentru a ajunge la un rezultat satisfacator am parcurs etapele de analiza si proiectare, care sunt independente de o implementare anume, urmate de etapele de implementare, testare si documentare.

2.3 Etapa analiza. Entitati si Atribute

Pentru a ajunge la baza de date existenta, am utilizat o „schita”, pe care am creat-o in baza specificatiilor de definitie. Voi reda mai jos lista cu entitatile si cu atributele care constituie fundamentul descrierii schemei bazei de date.
Tab. 1 LISTA CU ENTITATI SI ATRIBUTE PENTRU CONSTRUIREA DIAGRAMEI E-R
NOTIUNE CALITATE
ENTITATE (E) / ATRIBUT(A)
Categorii produs E id_categorie A denumire A
Element comanda E id_elem_com A id_comanda A cantitate A pret A
Tipuri produse E id_tip A id_cat A denumire A poza A
Produse E id_produs A pret A caracteristici A poza_mare A
Comenzi E id_comanda A id_client A pret_total A

NOTIUNE CALITATE
ENTITATE (E) / ATRIBUT(A) data_comenzii A
Livrari E id_livrare A data_livrarii A
Clienti E nume A prenume A id_adresa A email A telefon A
Adresa E strada A nr_strada A apartament A cod_postal A oras A judet A
Cereri aprovizionare E id_cerere A cantitate A data_cererii A data_rezolvarii A

In tabelul 2 prezentam entitatile cu tipul acestora precum si cu legaturile dintre ele.

ENTITATE TIP ENTITATE ENTITATI CU CARE ARE LEGATURA dresa de baza - clienti categorii produse de baza - tipuri produse
- produse cerere_aprovizionare de baza - produse clientii de baza - comenzi
- element comanda comenzi de baza - element comanda
- clienti
- livrare element_comanda de legatura - produse
- comenzi livrare de baza - comenzi produse de baza - comenzi
- cerere aprovizionare
- tip produs tip produs de legatura - categorii produse
- produse

users de baza

Tab. 2 Lista cu entitatile (tipul acestora) si legaturile dintre ele

Aceste legaturi le-am stabilit pe baza textului care constituie specificatiile de definitie si sunt piesele de baza la proiectarea structurii bazei de date. Pentru inceput, entitatile si atributele acestora sunt elementele de baza pentru alcatuirea diagramei entitate-relatie.
Modelarea ER a fost inventata la mijlocul anilor '70 de Peter Chen si ramane in continuare principala abordare pentru modelarea datelor.a9i Prin aceasta reprezentare schematica sub forma unei diagrame se reprezinta entitatile, atributele si relatiile dintre entitati precum si tipul acestor relatii.
In tabelul 3 sunt enumerate atributele, pentru fiecare dintre acestea am stabilit tipul de date pe care il vor avea la realizarea bazei de date, in vederea reprezentarii corecte si complete a informatiei. Coloana a 2-a reprezinta numele efectiv utilizat pentru implementare, astfel am dorit sa evit folosirea caracterului spatiu in structura bazei de date. Mai este prcizata si entitatea de care apartine

ATRIBUT NUME UTILIZAT IN BD
TIP DE DATE LUNGIME ENTITATEA DE CARE APARTINE

Numar de identificare adresa id_ adresa int 11 adresa
Strada strada varchar 255 adresa
Numar strada numar_str int 11 adresa
Apartament apartament int 11 adresa
Cod Postal cod_postal varchar 100 adresa
Oras oras varchar 100 adresa
Judet judet varchar 100 adresa
Numar de identificare categorie id_categorie int 11 categorii_produs
Denumire denumire varchar 255 categorii_produs
Numar de identificare cerere id_cerere int 11 cerere_aprovizionare
Numar de identificare produs id_ produs int 11 cerere_aprovizionare
Numar de bucati (cantitate) cantitate double cerere_aprovizionare
Data efectuarii cererii data_cererii date cerere_aprovizionare

ATRIBUT NUME UTILIZAT IN BD
TIP DE DATE LUNGIME ENTITATEA DE CARE APARTINE

Data rezolvarii cererii data_rezolvarii date cerere_aprovizionare
Numar de identificare client id_client int 11 clienti
Nume nume varchar 255 clienti
Prenume prenume varchar 255 clienti
E-mail email varchar 100 clienti
Telefon telefon int 11 clienti
Numar de identificare comanda id_comanda int 11 comanda
Suma de achitat pret_total double comanda
Data efecuarii comenzii data_comenzii date comanda
Numar de identificare element de comanda nr_elem_com int 11 element de comanda
Cantitate (nr. buc.) produs cantitate int 11 element de comanda
Pret (pe elem. comanda) pret double element de comanda
Numar de identificare livrare id_livrare int 11 livrare
Data efectuarii livrarii data_livrare date livrare
Numar de identificare categorie id_cat int 11 produse
Numar de identificare tip produs id_ tip int 11 produse
Denumire produs denumire varchar 255 produse
Descriere (produs) caracteristici longtext produse

ATRIBUT NUME UTILIZAT IN BD
TIP DE DATE LUNGIME ENTITATEA DE CARE APARTINE
Poza poza varchar 255 produse
Poza mare poza_mare varchar 255 produse
Numar de identificare administratori ID int 11 users
Nume (folosit) administrator UserName varchar 255 users
Parola administrator UserPassword varchar 255 users

Tabel 3. Atributele cu tipurile de date corespunzatoare si entitatile de care apartin

Continuand analiza specificatiilor de definitie, extragem relatiile dintre entitati, care pot sa fie dintre urmatoarele tipuri:
- 1:N (one to many) - la o instanta a unei entitati ii corespunde una sau mai multe din cea de-a doua entitate
- 1:1 (one to one) - la o instanta a unei entitati ii corespunde o instanta a celei de-a doua entitatati
- N:N (many to many) - la o instanta a unei entitati ii corespunde una sau mai multe din cea de-a doua entitate si reciproc, acesteia din urma ii corespund una sau mai multe instante ale primei entitati. In acest caz trebuie introdusa o entitate de legatura pentru implementarea relatiei.
O relatie de legatura este o asociere intre doua entitati si este binara, in sensul ca este intotdeauna o asociere exact intre doua entitati sau o entitate cu ea insasi (ceea ce nu este cazul la noi). Fiecare relatie de legatura are doua capete pentru fiecare dintre ele existand un:
• nume
• grad / cardinalitate (cat de multi)
• optionalitate (optionala sau obligatorie)
Astfel relatiile pentru cazul de fata vor fi urmatoatrele:

ENTITATE 1 ENTITATE 2 TIP DE RELATIE
Categorii produse Produse 1:N*
Categorii produse Tipuri produse 1:N
Tipuri produse Produse 1:N*
Cereri aprovizionare Produse 1:N
Produse Element de comanda 1:N
Comenzi Element de comanda 1:N
Comenzi Livrari 1:1
Clienti Comenzi 1:N
Adresa Clienti 1:N

Tabel 4. Relatiile dintre entitati

Relatiile notate cu * sunt obligatorii.

2.4 Etapa analiza. Evenimente si Functii

Principala functie de business pe care trebuie sa o rezolve aceasta aplicatie ar fi efectuarea unei comenzi. Aceasta functie se imparte de fapt in mai multe functii mai mici care in final vor realiza comanda de produse.

Adaugare produs in cos:

<?php session_start();
$adaugat_in_cos = false; if(isset($_POSTa'id_produs'i))A if(isset($_SESSIONa"Produs".$_POSTa'id_produs'ii))A

$_SESSIONa"Produs".$_POSTa'id_produs'ii += $_POSTa'cantitate'i;
SelseA
$_SESSIONa"Produs".$_POSTa'id_produs'ii = $_POSTa'cantitate'i;
S
$adaugat_in_cos = true;
S
?>

Modificare cantitate (produs) sau stergere (daca e nevoie) :

Pentru fiecare produs se creaza un formular cu denumirea ModificareCant + produsid care contine un textfield cu noua cantitate si o imagine care face trimiterea formularului (facand click pe imagine se lanseaza functia gogo() ).
La trimiterea formularului se face verificarea pentru noua cantitate si apoi se face trimiterea.

while (list ($key, $val) = each ($_SESSION)) ?
$_SESSIONa‘Produs1’i = “30” ?
$key = “Produs1” $val = “30”
$_SESSIONa‘utitlizator’i = “ion” ?
$key = “utilizator’” $val = “ion”

session_start(); ? porneste sesiunea if(isset($_POSTa'newCant'i))A // daca a fost transmisa noua cantitate( a fost clickaita imaginea )
$_SESSIONa"Produs".$_POSTa'idprodus'ii = $_POSTa'newCant'i;
\? ex : $_SESSIONa‘Produs30’i = 15 if($_SESSIONa"Produs".$_POSTa'idprodus'ii == 0)A
// daca noua cantitate a fost 0 atunci produsul este sters din sesiune unset($_SESSIONa"Produs".$_POSTa'idprodus'ii);
S
S

2.5 Etapa proiectare. Diagrama Entitate-Relatie

In etapa de proiectare vom utiliza informatiile obtinute la faza de analiza pentru a realiza diagrama Entitate-Relatie, pe baza listelor cu entitati, atribute si relatii dintre acestea, precum si diagrama de functii, pe baza listei de evenimente si functii.

Diagrama Entitate-Relatie este o forma generalizata si abstractizata a listei de entitati si atribute, si este utilizata apoi pentru realizarea schemei bazei de date. Aceasta diagrama este independenta de sistemul de gestiune a bazelor de date utilizat in etapa de implementare.
Pentru generarea diagramei Entitate-Relatie, se pot utiliza unelte CASE, care permit editarea acesteia in mod vizual si care apoi pe baza diagramei astfel realizate pot sa genereze in mod automat structura bazei de date. Am utilizat in acest scop aplicatia AllFusion ERwin Data Modeler 4.1, dar pentru ca utiliza elemente de reprezentare a diagramei diferite de cele studiate, am decis sa realizez aceasta diagrama manual.
Prezentam in continuare cateva elemente de notatie ale diagramei Entitate-Relatie.

pentru entitati, exista urmatoarele notatii:
Dreptunghiul cu colturile rotunjite reprezinta entitatea, in care cu litere mari se noteaza denumirea entitatii, si cu litere mici se noteaza atributele.
Linia dintre entitati indica existenta unei relatii intre acestea. Astfel, linia continua indica o relatie obligatorie, linia intrerupta(punctata). pentru specificarea atributelor, exista 3 simboluri distincte:
# (diez) indica faptul ca atributul respectiv este un element de identificare a entitatii, numit si cheie, sau ID.
* (asterisc) indica faptul ca atributul este unul obligatoriu.
? (grad) indica faptul ca atributul este optional.
Diagrama entitate-relatie este:

Citirea diagramei E/R:
Cuvintele din apropierea liniilor sunt cuvinte cheie care definesc relatia si se citesc astfel:
<ENTITATE 1> <cuvant cheie><ENTITATE 2>

Cuvintele cheie care sunt deasupra liniei sunt pentru citirea in directia de la stanga la dreapta, iar cele care sunt sub linie pentru citirea in sens invers, de la dreapta la stanga.

Exemplu: comenzi este compusa element comanda element comanda apartine comenzi

Fiecare categorie de produse poate fi compusa din unul sau mai multe produse si fiecare produs trebuie sa apartina unei categorii si numai uneia.
Fiecare categorie de produse poate avea unul sau mai multe tipuri de produse si fiecare tip de produs trebuie sa aiba o categorie si numai una.
Fiecare tip de produs trebuie sa contina unul sau mai multe produse si fiecare produs poate sa apartina unui tip de produs si numai unuia.
Fiecare produs poate fi inclus intr-una sau mai multe cereri de aprovizionare si fiecare cerere de aprovizionare trebuie sa fie compusa din unul sau mai multe produse.
Fiecare produs poate fi inclus intr-unul sau mai multe elemente de comanda si fiecare element de comanda trebuie sa contina un produs si numai unul.
Fiecare element de comanda trebuie sa apartina unei comenzi si numai uneia si fiecare comanda poate fi compusa din unul sau mai multe elemente de comanda.
Fiecare comanda apartine unei livrari si fiecare livrare corespunde unei comenzi.
Fiecare comanda trebuie sa apartina unui client si numai unuia si fiecare client poate detine una sau mai multe comenzi.
Fiecare client trebuie sa aiba o adresa si numai una si fiecare adresa poate avea unul sau mai multi clienti.

Se poate observa in diagrama Entitate-Relatie existenta unor atribute de identificare, identificatori unici sau de tip cheie, acestea sunt necesare pentru stabilirea legaturilor dintre entitati in faza de implementare a schemei bazei de date. In continuare vom enumera aceste atribute:

ATRIBUT ENTITATEA DE CARE APARTINE TIP ATRIBUT id_categorie Categorii produse Not null, primary key, autoincrement id_tip Tipuri produse Not null, primary key, autoincrement id_produs Produse Not null, primary key, autoincrement id_cerere Cereri aprovizionare Not null, primary key, autoincrement id_elem_com Element comanda Not null, primary key, autoincrement id_comanda Comenzi Not null, primary key, autoincrement id_client Clienti Not null, primary key, autoincrement id_adresa Adresa Not null, primary key, autoincrement id_livrare Livrari Not null, primary key, autoincrement

Tabel 6. Atribute de identificare

Am exclus entitatea user din diagrama Entitate-Relatie pentru ca legatura acesteia cu alte entitati a fost ignorata din considerente bine intemeiate.

2.6 Etapa proiectare. Diagrama Functionala

Diagrama functionala

E1

E2

E3

E5

E6

Cautare avansata si stergere exista pentru toate tabelele din baza de date.
Adaugare exista pentru urmatoarele tabele: - categorii produse;
- produse;
- tipuri produse;
- users;
Modificare exista pentru tabelele: - categorii produse;
- cerere aprovizionare;
- comanda;
- produse;
- users;

2.7 Etapa proiectare. Arhitectura aplicatiei

Modelul Client/Server

Toate organizatiile din ziua de azi guvernamentale, economice si majoritatea intreprinderilor mari si mici recunosc rolul central pe care aplicatiile software il au in cadrul lor, aplicatiile avand rolul reducerii costurilor si imbunatatirii serviciilor fata de competitie.
Aceasta dezvoltare si necesitatea utilizarii pe o arie mare a unor date de interes comun a dus la aparitia, utilizarea si proiectarea modelului Client/Server, care ofera date distribuite, portabilitate intre platforme si un acces standardizat la resurse.
Termenul de Client/Server provine de la metoda traditionala de accesare a unui computer central numit server de catre computere aflate la distanta sau clienti intr-o infrastructura de retea. Serverele utilizeaza baze de date relationale in stocarea si intretinerea datelor intre care exista referinte. Aceste referinte sunt mentionate printr-o tehnologie denumita integritate referentiala (referential integrity) care ofera mecanisme care actioneaza asupra datelor (trigger) si proceduri de stocare (stored procedure).
Acest model este o combinatie a trei tehnologii: sistemul relational de management al bazelor de date (DBMS), reteaua si interfata client (bazata pe GUI/PC). Fiecare element contribuie in functionarea platformei avand rolul sau, dar independent in executia functiilor sale.
Foarte multa lume considera clientul si serverul ca fiind doua entitati hardware, dar de fapt sunt entitati software. Modelul Client/Server implica o entitate software (clientul) care efectueaza cereri, acestea fiind indeplinite de o alta entitate software (serverul). Clientul este cel ce transmite o cerere server-ului, acesta o interpreteaza si apoi o efectueaza. Pentru a putea indeplini cererea serverul poate referi o sursa de informatie.
(baze de date), sa efectueze procesari asupra datelor, sa controleze periferice sau sa efectueze cereri aditionale altor servere. In foarte multe arhitecturi, un client poate face cereri la multiple servere si un server poate deservi mai multi clienti.
Relatia intre client si server este una de comanda/control, clientul initiaza cererea si serverul este cel ce o indeplineste transmitand rezultatul clientului, aplicatia fiind procesata prin divizarea ei intre cele doua entitati iar transferul de date este bidirectional. Un server nu initializeaza niciodata un dialog cu clientii. Clientul poate functiona pe un server hardware si sa efectueze cereri de la un server care ruleaza pe un alt server hardware sau pe un PC sau clientul si serverul pot functiona pe acelasi computer.
Spre deosebire de un sisitem file/server in care datele sunt aduse de pe file server pentru a fi procesate pe o masina locala in acest sistem comenzile sunt transmise asupra bazelor de date localizate pe server, rezultatul fiind transmis inapoi clientului pentru a fi vizualizat.
Arhitectura efectueaza toate aspectele software, ea trebuie sa ia in considerare complexitatea aplicatiei, nivelul de integrare si interfatare cerut, numarul utilizatorilor, raspandirea lor geografica natura retelelor si toate tipurile de tranzactii necesare inainte de a decide tipul arhitecturii.
De asemenea alegerea arhitecturii afecteaza timpul de dezvoltare, flexibilitatea precum si intretinerea aplicatiei. La majoritatea aplicatiilor end-user se urmareste: prezentare, procesare si date. Arhitecturile Client/Server definesc cum aceste trei componente sunt impartite intre entitatile software si distribuite in retea, exista o varietate de moduri cum pot fii divizate si implementate, utilizarea unor astfel de arhitecturi putand aduce multe beneficii in viitor companiei permitand adaptarea la diferite standarde si tehnologii. Cateva din caracteristicile acestei arhitecturi sunt:
Centralizarea informatiei -; intr-un astfel de mediu, datele sunt stocate pe un server central si exista un singur punct de control care administreaza cererile aplicatiilor si platformelor. Aceste servere de baze de date utilizeaza un sistem de management al bazelor de date (DBMS) pentru a definii, stoca si manipula date. Serverul este generic; programatorii neavand nevoie sa cunoasca un limbaj anume pentru a accesa date. Utilizand tehnicile de identificare o organizatie poate crea magazii de date de la diferite servere distribuite in diferite zone geografice. Aceasta tehnica maximizeaza performantele fara a compromite modelul centralizat si reduce probabilitatea existentei de date redundante in aplicatii.
Serverul procesor central -; preluand acest avantaj, organizatiile pot reduce procesarea redundanta prin utilizarea procedurilor trigger si de stocare. Server-ul este orientat in procese standard ca: mentinerea unor reguli, validari si referinte de integritate iar prin intermediul functiilor de stocare pe un server comun datele pot fi manipulate corect din punct de vedere logic si viabile pentru o varietate de limbaje si unelte ale lor.

Performante -; serverul este un computer dedicat sa proceseze un set limitat de cereri de la clienti. Singura sa functie este sa proceseze cererile asupra bazelor sale de date. SQL ofera facilitati eficiente de utilizare a traficului in retea deoarece doar subseturi ale datelor sunt transmise in retea, in plus serverele si DBMS sunt desemnate sa gestioneze baze de date masive fara o degradare simtitoare a performantelor.
Securitate -; serverele ce lucreaza pe platforme ca UNIX, Windows NT sau OS/2 pot oferi o mai mare securitate pentru managementul bazelor de date in comparatie cu file server-ele standard. Mecanismele de duplexing, mirroring si copiere permise administratorilor asigura evitarea dezastrelor, de asemenea aceste baze de date permit definirea de utilizatori si parole care permit evitarea accesului unor persoane neautorizate.
Referitor la costurile unor astfel de arhitecturi, server-ele sunt cele ce necesita procesoare rapide, memorie, hard disc-uri mari si un sistem de operare, clientii care le acceseaza. Licentierea, instalarea si intretinerea unor sisteme ca Oracle, Sybase sau Informix necesita sute de mii de dolari iar dezvoltarea unor aplicatii necesita memorie, masini noi si noi sisteme de operare. Din acest motiv in prezent multe organizatii care au utilizat mainframe-uri s-au acomodat foarte usor acestui mediu Client/Server care ofera o excelenta infrastructura pentru a asigura informatie organizatiei asigurand integritate, viteza si securitate. Cele mai populare tipuri de arhitecturi sunt cu doua entitati (two-tier) si cu trei (three-tier).
Arhitectura two-tier. In aceasta implementare, cele trei componente ale unei aplicatii (prezentare, procesare si date) sunt divizate in doua entitati (tiers): codul aplicatiei client si baza de date server. O aplicatie client dezvolta un limbaj si un mecanism de interschimb pentru a transmite cererea serveru-ului. Prezentarea este detinuta in exclusivitate de client, procesarea este impartita intre client si server si datele sunt stocate si accesate de pe server. PC-ul client isi asuma intreaga responsabilitate a functionarii logice a aplicatiei, timp in care motorul bazei de date verifica integritatea. Intr-o astfel de topoligie motorul datelor este cel ce proceseaza cererile clientului, limbajul utilizat fiind o forma a SQL, transmiterea unei cereri presupune ca aplicatia client sa cunoasca sintaxa serverului sau aceasta sa fie tradusa printr-o aplicatie (API), totodata sa se cunoasca serverul, cum sunt organizate datele si denumirea lor. Datele transmise clientului pot fi manipulate de acesta cum doreste, datele de pe server fiind centralizate. Aceste medii detin o varietate de structuri de date, totodata aceste arhitecturi bine in medii eterogene, aplicatia client detinand controlul oricarei modificari care apare in cadrul unui sistem ducand doar la modificarea aplicatiei client.
Sistemul de securitate intr-un astfel de mediu este complicat deoarece un user trebuie sa detina parole pentru fiecare server SQL, iar cresterea utilizatorilor poate duce la compromiterea securitatii bazelor de date aflate pe server. In prezent majoritatea aplicatiilor client/server sunt proiectate sa lucreze cu produse middleware care duc la cresterea securitatii, ele detinand unelte de acces la date.

Arhitectura three-tier. Aceasta arhitectura a aparut datorita limitarilor arhitecturii precedente, ea aduce ca noutate separarea prezentarii, procesarii si datelor in entitati (tiers) software distincte. Aceleasi tipuri de unelte care in arhitectura precedenta erau utilizate pentru prezentare, acum ele sunt dedicate doar pentru prezentare. Cand clientul solicita o cerere pentru acces la date sau o procesare a datelor, cererea se face la nivelul de mijloc care este un server.
Acest nivel poate efectua procesari de date sau cereri asemeni unui client la alte servere. Serverele din nivelul de mijloc pot fi multi-treaded si pot fi accesate de clienti multipli, asemeni unei aplicatii separate. Sistemele three-tier pot fi implementate utilizand o varietate de tehnologii, mecanismul de cerere al clientului de la server in majoritatea sistemelor este utilizat apelul procedurilor remote (RPC).
Apelul unor astfel de proceduri de catre client asigura sistemului o flexibilitate foarte mare in comparatie cu apelurile SQL efectuate de client in arhitectura precedenta, aceasta datorita faptului in care parametrii necesari cererii efectuate de client sunt foarte usor transmisi si specificatiile structurilor de date care preiau datele primite (if any), acest lucru permitand organizatiilor sau structurilor back-end (aflate pe servere) sa poata sa-si modifice configurarile in sistem, datele sa poata fi organizate ierarhic, relational sau obiectual permitand firmelor sa simplifice trecerea la noi tehnologii legate de organizarea bazelor de date, fara a fi nevoie de modificari la nivelul aplicatiei client. Un alt avantaj este acela ca avand entitatile software separate permit o alocare flexibila a resurselor.
Entitatile mijlocii (servere) pot fi alocate dinamic si repartizate in functie de necesitatile firmei. Traficul de retea este redus avand server-ele nivelului de mijloc, preluand date de la structuri precise inainte sa le distribuie la clienti in retea, PC-urile client fiind dedicate doar prezentarii, memoria si discurile fiind reduse. Din punct de vedere al dezvoltarilor software modularitatea ofera reutilizarea unor subrutine cu efort minim reducand costurile.
In concluzie aceasta arhitectura are un termen lung de functionare al aplicatiilor indiferent de modificarile aparute in afaceri, cod reutilizabil, intretinerea usoara si usurinta in migrarea catre noi platforme server si medii.

2.8 Etapa implementare

Pentru implementarea aplicatiei am ales mediul de programare PHP si MySql.

.

3. MEMORIU JUSTIFICATIV

3.1 Proiectarea si implementarea bazei de date

Proiectarea bazei de date am facut-o pe baza etapelor studiate in capitolul anterior, iar implementarea cu ajutorul produsului SQLyog.
Baza de date va fi sub forma unor fisiere de tip frm, MYD si MYI. Pentru fiecare tabel din baza de date vom avea 3 astfel de fisiere.
In urma etapelor de analiza si de proiectare prezentate in capitolul anterior, am realizat structura bazei de date cu ajutorul produsului SQLyog. Astfel, baza de date contine un numar de 9 tabele, 8 dintre ele sunt cele corespunzatoare entitatilor prezentate in tabelul 1 .
- categorii_produse
- tip_produs
- produse
- cerere_aprovizionare
- element_comanda
- comanda
- clienti
- livrari
- adresa
- users
Celelalt tabel este auxiliar, nu rezulta in urma analizei, ci au fost introduse ca elemente ajutatoare pentru administrare. Acesta este:
- user -; contine userii care au dreptul sa administreze site-ul cu numele, si parola user-ului.
In figura urmatoare, prezentam structura bazei de date, cu tabelele si legaturile dintre ele. Observam ca fata de atributele prezente in diagrama entitate-relatie, sunt prezente si atributele de identificare de tip chei straine, care se propaga in momentul realizarii legaturilor dintre tabele. De exemplu, in tabela produse, atributul id_tip, este cheie straina propagata din tabela tipuri produse, pentru a se face legatura dintre cele 2 tabele.

1
8

1 1
11 8

8

1
8 8 8 1 1
8
8

8 1

3.2 Proiectarea interfetei utilizator

Meniul aplicatiei
Meniul principal al aplicatiei este implementat in HTML, iar cel de la mersul trenurilor in PHP si au urmatoarea structura :

Magazin

Categorii produse

Tipuri produse

Produse

Produse

Home

Informatii

Cautare produs

Cautare tip produs

Continutul cosului

Golire cos

Meniul este pus in fiecare pagina, iar pagina principala home arata in felul urmator:

In partea stanga se afla categoriile de produse, iar daca este selectata categoria, va aparea (se va incarca) tot in aceeasi pagina tipurile de produse corespunzatoare categoriei selectate, ca si in exemplu de mai jos:

O categorie de produse poate contine atat tipuri de produse cat si produse fara tip (adica care au id_tip “null” cand sunt introduse in baza de date). Deci sunt produse care apartin acelei categorii dar nu au tip:

La cautarea unui produs sau unui tip se vor afisa in mijloc rezultatul cautarii (produsele sau tipurile gasite) :

In cazul in care textul introdus nu a fost gasit printre denumire si caracteristici se va afisa mesajul:
“Textul cautat” nu a fost gasit in baza de date.

La introducerea unui produs in cos va apare produsul selectat singur in pagina in felul urmator:

Pentru a face comanda produselor selectate se face clik pe Continutul cosului este din orice pagina si se vor afisa toate produsele din cos. Tot aici se pot modifica cantitatea unui produs sau se poate sterge prin introducerea valorii “0” in casuta Modificare cantitate.

Dupa aceea daca doriti sa comandati produsele completati formularul cu datele personale si faceti click pe butonul Factureaza iar daca dariti sa mai adaugati si alte produse la comanda puteti sa navigati in continoare si sa selectati produsele dorite.

Dupa ce faceti click pe butonul Factureaza in pagina va aparea mesajul :

“Comanda a fost efectuata”