Proiectarea Unei Baze de Date Pentru Evidenta Operativa a Stocurilor de Produse Intr O Firma de Comert Exterior

CUPRINS

INTRODUCERE

În zilele noastre este bine știut că la baza unei companii eficiente se află un sistem informațional modern bine optimizat pe nevoile și cerințele acesteia, menit să îmbunătățească multitudinea proceselor existente în companie.

Sistemul informațional este un element component al sistemului de management iar automatizarea acestuia prin introducerea prelucrării, transmiterii și stocării automate a datelor dă naștere sistemului informatic.

Orice sistem informațional modern presupune includerea tehnologiilor informatice în activitățile de culegere, prelucrare și transmitere a datelor și se fundamentează pe o baza de date unde sunt incarcate toate informatiile unei firme.

Lucrarea își propune ca prin proiectarea si creearea unei baze de date si a unui sistem informational să îmbunătățească fluxul de informații și comunicare desfășurat atât între angajații unei companii cât și între angajații și clienții acestei firme, sistem menit să ajute în prelucrarea datelor și in gestionarea stocurilor companiei.

Alegerea temei a apărut din necesitatea unei metode mai bune de gestionare si actualizare a stocurilor, NIR-urilor, produselor și a managementului personalului în ideea de optimizare a fluxului informațional, de centralizare a informațiilor relevante din sistem pentru a reduce pierderea de resurse financiare și creșterea eficienței angajaților.

Obiectivul principal al sistemului constă în furnizarea de informații corecte și relevante atât conducerii cât și angajaților, clienților și partenerilor firmei (resellers) pentru a putea oferi o sursă de informații centralizate pentru angajații și conducerea companiei și transparență pentru colaboratori și clienți.

Cu ajutorul sistemului de raportare al aplicatiei se va putea cunoaște în orice moment, pe baza informatiilor introduse în baza de date, status-ul stocurilor produselor, istoricul nir-urilor cât și compararea rezultatelor acestora în diferite momente.

Sistemul propus urmărește creșterea eficienței companiei prin scăderea costurilor și timpulului de munca și odată cu acestea sa ofere o gestionare mai usoara si rapida a stocurilor de produse. Sistemul ruleaza pe o baza de date MySQL, a cărei structuri este prezentată în capitolul 4 si este realizat in Code Igniter urmarind structura MVC.

Capitolul 1 – ORGANIZAREA INFORMAȚIILOR ÎN MEDIUL ELECTRONIC

1.1 Date și colecții de date

În dezvoltarea aplicatiilor informatice pot fi puse în evidentã un numãr limitat de entitãti (liste, stive, cozi, cozi cu prioritãti, arbori binari, tabele de dispersie, grafuri), caracterizate printr-o stare si un comportament specific. Acestea sunt cunoscute sub numele de tipuri de date abstracte sau colectii de date si contin un numãr finit de elemente, de orice tip.

Colectiile de date difera de la limbaj la limbaj iar in prezenta lucrare sistemul informatic studiat ruleaza pe o baza de date MySQL.

MySQL este un sistem de gestiune a bazelor de date relațional, produs de compania suedeza MySQL AB și distribuit sub Licența Publică Generală GNU. Este cel mai popular SGBD open-source la ora actuală, fiind o componentă cheie a stivei LAMP (Linux, Apache, MySQL, PHP).

Deși este folosit foarte des împreună cu limbajul de programare PHP, cu MySQL se pot construi aplicații în orice limbaj major.

Există multe scheme API disponibile pentru MySQL ce permit scrierea aplicațiilor în numeroase limbaje de programare pentru accesarea bazelor de date MySQL cum ar fi: C, C++, C#, Java, Perl, PHP, Python, FreeBasic, etc., fiecare dintre acestea folosind un tip specific de API.

O interfață de tip ODBC denumită MyODBC permite altor limbaje de programare ce folosesc această interfață, să interacționeze cu bazele de date MySQL cum ar fi ASP sau Visual Basic. În sprijinul acestor limbaje de programare, unele companii produc componente de tip COM/COM+ sau .NET (pentru Windows) prin intermediul cărora respetivele limbaje să poată folosi acest SGBD mult mai ușor decât prin intermediul sistemului ODBC. Aceste componente pot fi gratuite (ca de exemplu MyVBQL) sau comerciale.

Licența GNU GPL nu permite încorporarea MySQL în soft-uri comerciale; cei care doresc să facă acest lucru pot achiziționa, contra cost, o licență comercială de la compania producătoare, MySQL AB.

MySQL este componentă integrată a platformelor LAMP sau WAMP (Linux/Windows-Apache-MySQL-PHP/Perl/Python).

Popularitatea sa ca aplicație web este strâns legată de cea a PHP-ului care este adesea combinat cu MySQL și denumit Duo-ul Dinamic. În multe cărți de specialitate este precizat faptul ca MySQL este mult mai ușor de invățat și folosit decât multe din aplicațiile de gestiune a bazelor de date, ca exemplu comanda de ieșire fiind una simplă și evidentă: „exit” sau „quit”.

Pentru a administra bazele de date MySQL se poate folosi modul linie de comandă sau, prin descărcare de pe internet, o interfață grafică: MySQL Administrator și MySQL Query Browser.

Un alt instrument de management al acestor baze de date este aplicația gratuită, scrisă în PHP, phpMyAdmin.

MySQL poate fi rulat pe multe dintre platformele software existente: AIX, FreeBSD, GNU/Linux, Mac OS X, NetBSD, Solaris, SunOS, Windows 9x/NT/2000/XP/Vista.

Datele sunt fapte culese din lumea reală. Ele sunt preluate din măsurători și observații și constituie orice mesaj primit de un receptor sub o anumită formă. O percepție a lumii reale poate fi privită ca o serie de obiecte sau fenomene distincte sau interdependente.

Datele în sine nu au nici un fel de semnificație. Mai mult decât atât, nefiind altceva decât o înșiruire de litere și cifre, ele pot primi diverse interpretări, cele mai multe dintre ele fiind, de obicei, greșite. Datele se refera la numere, fapte, diferite documente etc.

Informațiile se referă la date organizate, date care au fost filtrate și ordonate după anumite criterii. Dorința oricărui utilizator este obținerea de informație și nu manipularea unor date seci.

Un model de date corect alcătuit oferă posibilitatea transformării informațiilor în date și a acestora înapoi în informații fără a denatura sensul lor inițial.

A obține informație înseamnă, de fapt, a introduce datele disponibile într-un anumit context conferindu-le în acest fel o anume semnificație.

Ceea ce se înmagazinează într-o bază de date, sunt datele care au o natură statică în sensul că ele rămân în aceeași stare până în momentul modificării lor de către administratorul bazei de date prin intermediul unui proces manual sau automat.

Pentru ca datele să poată fi transformate în informație ele trebuie organizate astfel încât să poată fi prelucrate efectiv.

Pentru a determina în cazul unei aplicații modul de organizare a datelor, trebuie determinate acele caracteristici ale datelor care permit extragerea esenței înțelesului lor.

O mulțime formală și consistentă de reguli definește un model de date.

Pentru o aplicație particulară a unui model de date, numele obiectelor bazei de date împreună cu proprietățile lor și asocierile dintre ele se numește schemă.

Un ansamblu de date organizat după anumite criterii reprezintă o colecție de date.

O colecție de obiecte care au identitate proprie și sunt caracterizate de o condiție de apartenență se numește mulțime.

Procesul de definire și structurare a datelor în colecții, gruparea lor precum și stabilirea elementelor de legătură dintre componentele colecției și între colecții reprezintă organizarea datelor.

1.2 Diferenta intre fisiere si baze de date

Fișierul este o colecție de date organizate pe criterii calitative, de prelucrare și de scop. Un fișier reprezintă o colecție de date aflate în asociere, ce are o denumire și care este reprezentat, de obicei, cu ajutorul unei secvențe de bytes sub forma celor două vederi:

Logică: reprezintă felul în care utilizatorul vede fișierul;

Fizică: reprezintă felul în care fișierul este stocat în memoria externă a calculatorului.

Aceste două vederi pot fi, evident, foarte diferite între ele.

O bază de date reprezintă o colecție integrată și structurată de date operaționale înmagazinate pe un mediu de stocare. Elsmari și Navathe definesc o bază de date sub forma unei colecții de date aflate în asociere.

Scopul unei baze de date este acela de a înmagazina datele în așa fel încât să se poată obține informația dorită în orice moment.

Informațiile, spre deosebire de date, au un caracter dinamic în sensul că ele se modifică în funcție de datele înmagazinate în baza de date, dar și în sensul că ele pot fi procesate și prezentate în diverse feluri.

Pentru a face diferența dintre date și informații, Hernandez propune următoarea axiomă:

„ Datele reprezintă ceea ce se înmagazinează; informația reprezintă ceea ce se extrage.”

Cu alte cuvinte, datele trebuie extrase în așa fel din baza de date încât să capete semnificație.

Evoluția în timp a metodelor de organizare a datelor e legată de soluțiile tehnice de înmagazinare a acestora și cuprinde nivelele:

Nivelul I – organizarea datelor în fișiere clasice;

Nivelul II – organizarea mixtă în fișiere;

Nivelul III – organizarea datelor în bazele de date clasice;

Nivelul IV – organizarea datelor în bazele de date relaționale;

Nivelul V – organizarea datelor în baze de date distribuite.

1.3 Avantajele si dezavantajele gruparii datelor la nivel de baze de date

Avantajele sistemelor de gestiune a bazelor de date față de sistemele clasice, cu fișiere sunt următoarele:

Controlul redundanței datelor

Risipa de spațiu care se face prin stocarea acelorași informații în mai multe fișiere este mult diminuată prin utilizarea bazelor de date, dar nu complet eliminată datorită altor cereri de îmbunătățire a performanțelor.

Coerența datelor

Dacă un articol de date e înmagazinat de mai multe ori trebuie să se garanteze că toate copiile acestuia vor fi actualizate dacă se reactualizează o valoare a sa (valoarea articolului e aceeași pentru toate copiile sale).

Mai multe informații de la aceeași cantitate de date

Se pot obține prin integrarea fișierelor ce conțin informații diferite despre aceleași date.

Partajarea datelor

Datele pot fi utilizate de către mai mulți utilizatori în același timp. De asemenea se pot face modificări sau adăugiri la baza de date existentă fără a fi necesară definirea repetată a tuturor cerințelor referitoare la acestea.

Integritatea crescută a datelor

Se referă la validitatea și coerența datelor înmagazinate și se exprimă prin constrângeri (reguli de coerență).

Constrângerile se pot aplica articolelor de date din cadrul unei singure înregistrări sau relațiilor dintre înregistrări.

Securitatea crescută

Se realizează prin atribuirea unor nume de utilizatori și parole ce permit identificarea persoanelor autorizate să folosească baza de date și impun modalitatea de utilizare a acestor date.

Aplicarea standardelor

Se referă la formatul datelor, convențiile privind denumirile, documentarea, procedurile de reactualizare, regulile de acces.

Reducerea costurilor

Prin realizarea integrării se alocă fonduri centralizat și nu separat fiecărui departament.

Rezolvarea conflictelor

Fiecare utilizator va avea propriile cerințe ce pot intra în conflict cu ale altora. Administratorul bazei de date poate lua decizii ce duc la utilizarea optimă a resurselor.

Creșterea accesibilității datelor și a capacității de răspuns

Se realizează prin intermediul utilizării limbajelor de programare din generația a IV-a (ex. SQL, QBE).

Creșterea productivității

Prin furnizarea unor funcții ce permit manipularea fișierelor și a introducerii limbajelor de programare din generația a IV-a ce reduc mult timpul de programare.

Independența datelor

Duce la creșterea capacității de întreținere prin faptul că descrierile datelor sunt separate de aplicații.

Controlul concurenței este îmbunătățit

Se garantează că dacă doi sau mai mulți utilizatori accesează simultan aceleași date nu se pierd informații sau nu se alterează integritatea acestora.

Asigurarea salvării de siguranță și a refacerii

Prin recuperarea ultimei stări coerente a bazei de date în cazul apariției unei defecțiuni hard sau soft.

Dezavantajele sistemelor de gestiune a bazelor de date față de sistemele clasice, cu fișiere sunt următoarele:

Complexitatea

Trebuie avute în vedere o serie de probleme referitoare la date care se manifestă suplimentar față de cazul aplicațiilor clasice.

Se face mai întâi o analiză amănunțită a datelor și apoi a aplicației propriu-zise.

Dimensiunea

SGBD-urile ocupă mult spațiu pe disc.

Costul

a) sistemelor SGBD;

b) elementelor hard achiziționate;

c) conversiei aplicațiilor existente la noul SGBD și noua configurație hard.

Performanța

Este mai redusă în cazul utilizării SGBD-urilor care au un caracter mai general, în locul unei aplicații simple bazată pe fișiere care apelează o singură funcție.

Efectul unei defecțiuni

Efectul unei defecțiuni este mult mai mare datorită centralizării, o defecțiune minoră afectează toți utilizatorii.

1.4 Concepte specifice bazelor de date

Simplitatea modelului bazei de date relaționale rezultă din simplitatea conceptelor cu care operează: structuri simple și abstracte de date, independența fizică de date, cadrul puternic, general și realist oferit aplicațiilor ș.a.m.d.

Modelul relațional oferă o interfață flexibilă ce este prevăzută cu cele mai potrivite componente necesare oricărui utilizator la toate nivelele, oferind o mare independență a datelor (produsul obținut este relativ independent de implementarea internă).

Baza de date relațională constă din unul sau mai multe relații sau tabele. Principalele concepte ale modelului relațional sunt:

Atributul – este o coloană ce are un nume propriu și unic într-o relație (câmp). Fiecare relație conține o listă de atribute (sau coloane) definite pe un anumit domeniu.

Domeniul – reprezintă setul posibil de valori pe care îl poate avea unul sau mai multe atribute. Utilizatorul poate defini domeniul de definiție, dar numai în anumite produse își poate defini propriile domenii.

Tuplu – un rând din cadrul unei relații (înregistrare). Un rând dintr-un tabel reprezintă asocierea dintre seturile de valori. Fiecare relație conține un set de tupluri (sau rânduri).

Intensia – structura unei relații împreună cu specificațiile și constrângerile de domeniu aplicate. Se modifică rar.

Extensia – starea relației (valorile din cadrul unei relații se pot modifica). Reprezintă conținutul curent al bazei de date ce corespunde schemei bazei de date și se modifică frecvent.

Gradul – numărul de atribute dintr-o relație.

Cardinalitatea – numărul de tupluri dintr-o relație.

Baza de date relațională – reprezintă o colecție de relații ce pot fi modificate (tabele).

O astfel de colecție este descrisă sub forma unui set de scheme de relații din cadrul bazei de date, numite scheme relaționale ale bazei de date. Relațiile sunt alcătuite din două părți:

instanța – un tabel cu rânduri și coloane;

schema – specifică numele relației împreună cu numele și tipul fiecărei coloane.

1.5 Scopul unei baze de date

Scopul unei baze de date este de a reprezenta un mediu virtual, sigur si accesibil in care pot fi stocate multiple informatii necesare activitatii oricare entitati financiare, acestea fiind la indemana operatorilor si a managerilor in orice moment printr-un mediu informatic.

Scopul unui sistem de gestiune al unei baze de date este acela de a oferi un mediu care să fie și convenabil, dar și eficient pentru a putea fi folosit la:

extragerea informațiilor din baza de date;

înmagazinarea datelor în baza de date.

Capitolul 2 – BAZE DE DATE RELATIONALE

2.1 Sisteme de gestiune a bazelor de date

Sistemul de gestiune a bazelor de date (SGBD) este un sistem de programe ce permite definirea, crearea și întreținerea bazei de date precum și accesul controlat la acesta.

Din punct de vedere conceptual, gestiunea bazelor de date se bazează pe ideea separării structurii bazei de date de conținutul acesteia.

În sistemele de baze de date definirea datelor se separă de programele aplicație, astfel încât utilizatorii văd doar definiția externă a unui obiect fără a cunoaște modul în care e definit acesta și cum funcționează. În acest mod, definiția internă a obiectului poate fi modificată fără a afecta utilizatorii acestuia dacă nu se modifică definiția externă.

De exemplu, dacă sunt adăugate noi structuri de date sau sunt modificate cele existente, atunci programele aplicație nu sunt afectate dacă nu depind direct de ceea ce se modifică.

Structura bazei de date reprezintă o colecție de descrieri statice ale tipurilor de entități împreună cu relațiile logice stabilite între ele.

Relațiile logice reprezintă asociațiile dintre mai multe entități.

O entitate este un obiect distinct ce trebuie reprezentat în baza de date.

Un atribut este o proprietate ce descrie un anumit aspect al obiectului ce se înregistrează în baza de date.

Bazele de date sunt de obicei folosite la gestionarea unei mari cantități de date, ceea ce presupune existența următoarelor caracteristici:

definirea structurilor (modelarea datelor);

utilizarea unor mecanisme de manipulare a datelor;

asigurarea securității datelor în baza de date;

asigurarea controlului concurenței în cazul utilizării sistemului de către mai mulți utilizatori

Orice sistem de gestiune al bazelor de date are următoarele componente:

A . Limbajul de definire a datelor

Cu ajutorul acestui limbaj se specifică tipurile de date și structurile precum și constrângerile asupra datelor. Instrucțiunile limbajului sunt compilate și transformate într-un set de tabele înmagazinate într-un fișier special numit dicționar de date sau catalogul sistemului (descrierea datelor se întâlnește sub denumirile de catalog de sistem, dicționar de date sau meta-date ceea ce înseamnă date despre date).

Structura de înmagazinare a datelor precum și metodele de acces utilizate de sistemul bazei de date sunt specificate cu ajutorul unui set de definiții folosit cu scopul ascunderii detaliilor de implementare a schemelor bazei de date.

B. Limbajul de manipulare a datelor

Acest limbaj este folosit pentru a ajuta utilizatorul să acceseze și să folosească datele aflate în baza de date într-un mod interactiv.

Cu ajutorul acestui limbaj se pot:

– extrage date din baza de date;

– introduce date în baza de date;

– elimina date din baza de date;

– actualiza date din baza de date.

C. Administratorul bazei de date

Administratorul bazei de date este un program ce asigură interfața dintre datele înmagazinate, aplicațiile care folosesc aceste date și întrebările adresate sistemului cu ajutorul cărora se extrag datele necesare.

De obicei, bazele de date necesită un spațiu mare de înmagazinare pe mediul de stocare ales, ce poate ajunge de ordinul gigabytes-ilor.

Pentru a putea fi prelucrate datele se transferă din memoria externă în memoria internă a sistemului.

Scopul sistemului bazei de date este acela de a ușura accesul la date, iar administratorul bazei de date este răspunzător de următoarele:

asigură interacțiunea cu administratorul de fișiere (trebuie să transfere instrucțiunile limbajului de manipulare a datelor în comenzi de nivel scăzut recunoscute de sistemul de fișiere);

asigură integritatea datelor prin verificările pe care le efectuează în momentul actualizării datelor astfel încât acestea să nu încalce constrângerile impuse și să fie consistente;

asigură securitatea datelor prin accesul controlat la date pe care îl oferă utilizatorilor (aceștia nu pot accesa orice fel de date dacă nu le este permis acest lucru);

creează copiile de siguranță și asigură refacerea datelor, în cazul apariției unei erori sau defecțiuni în baza de date, la starea la care acestea se aflau înainte de apariția erorii sau defecțiunii;

asigură controlul concurenței păstrând consistența datelor atunci când acestea sunt accesate în același timp de mai mulți utilizatori.

2.2 Caracteristici ale bazelor de date relationale

În sens larg, o bază de date este o colecție de date organizată (structurată). O bază de date are, în principal, următoarele roluri: stocare (memorare) și organizarea datelor (structurare).

Ca și utilitate, bazele de date permit:

(1) memorarea unor cantități mari de date,

(2) regăsirea datelor pe baza unor criterii ce căutare (ce sunt legate în mod direct de structurarea datelor)

(3) prelucrarea unor volume mari de date (filtrare, ordonare, agregare).

Bazele de date relaționale sunt un tip de baze de date în care datele, văzute ca și atribute ale entităților reale, sunt socate în tabele și sunt legate între ele prin relații.

Acest mod de structurare a datelor, bazat pe legături între date, permite eliminarea redundanței, astfel încât stocarea și, mai ales, modificarea unei informații se face într-un singur loc, iar, din punct de vedere funcțional, această structură permite regăsirea, filtrarea, ordonarea și agregarea datelor, în mod natural.

Bazele de date relaționale (BDR) utilizează modelul de date relațional și noțiunile aferente. BDR au o solidă fundamentare teoretică, în special prin cercetările de la IBM conduse de E.F.Codd.BDR este un ansamblu organizat de tabele (relații) împreună cu legăturile dintre ele.

Atunci când dorim să realizăm o bază de date relațională trebuie să știm clar ce avem de făcut, adică să stabilim obiectivele activității noastre.

În acest sens, câteva dintre cele mai importante obiective, ce trebuie avute în vedere sunt:

• Partiționarea semnifică faptul că aceleași date trebuie să poată fi folosite în moduri diferite de către diferiți utilizatori;

• Deschiderea se referă la faptul că datele trebuie să fie ușor adaptabile la schimbările care pot apărea (actualizarea structurii, tipuri noi de date etc.);

• Eficiența are în vedere stocarea și prelucrarea datelor, care trebuie să se facă la costuri cât mai scăzute, costuri care să fie inferioare beneficiilor obținute;

• Reutilizarea înseamnă faptul că fondul de date existent trebuie să poată fi reutilizat în diferite aplicații informatice;

• Regăsirea este o actvitate frecventă pe bazele de date și de aceea cererile de regăsire trebuie să poată fi adresate ușor de către toate categoriile de utilizatori, după diferite criterii;

• Accesul înseamnă modul de localizare a datelor și acest lucru trebuie să poată fi realizat prin diferite moduri de acces, rapid și ușor;

• Modularizarea presupune faptul că realizarea BDR trebuie să se poată face modular pentru generalitate și posibilitatea lucrului în echipă;

• Protecția bazei de date trebuie asigurată sub ambele aspecte: securitatea și integritatea datelor;

• Redundanța se asigură în limite acceptabile prin implementarea unui model de date pentru baze de date și prin utilizarea unei tehnici de proiectare a BDR. Se asigură astfel, o redundanță minimă și controlată;

• Independența datelor față de programe trebuie asigurată atât la nivel logic cât și și fizic.

Bazele de date relaționale au evoluat ca un tip special de aplicații informatice, și anume cele care au organizarea datelor în memoria externă conform unui model de date specific. De aceea, în metodologia de realizare a BDR se parcurg, în cea mai mare parte, cam aceleași etape ca la realizarea unei aplicații informatice, cu o serie de aspecte specifice. Pe de altă parte, în literatura de specialitate, sunt diferite propuneri de metodologii de realizare a bazelor de date.

2.3 Modelul entitate – relatie

Modelul entitate relatie se bazează pe o percepție a lumii reale ca fiind alcătuită dintr-o colecție de obiecte de bază sau concepte (entități) împreună cu relațiile care se stabilesc între ele. Fiecare entitate are asociat un set de atribute care o descriu, iar o relație reprezintă o asociere dintre două sau mai multe entități. Mulțimile tuturor entităților sau relațiilor de același tip sunt cunoscute sub denumirea de tipuri de entități sau relații.

Un alt element important în cadrul diagramelor entitate-relație îl reprezintă precizarea constrângerilor de cardinalitate care exprimă numărul de entități asociate altui tip de entitate prin intermediul unui tip de relație.

Modelul entitate-asociere este cel mai utilizat in proiectarea bazelor de date si contine:

Identificarea entităților: fenomene, procese, obiecte concrete sau abstracte (substantivele din prezentarea activității descrise) (exemple de entități: Persoane, Produse, Beneficiari).

Identificarea asocierilor dintre entități ca fiind legăturile semnificative de un anumit tip (verbele din prezentarea activității descrise).

Identificarea atributelor ce caracterizează fiecare entitate în parte (exemple de atribute: Marca, Nume, Adresă).

Stabilirea atributelor de identificare unică a realizărilor entității, drept chei

Schema conceptuala si diagrama entitate – relatie

Modelul conceptual al bazelor de date relaționale poate fi reprezentat printr-o schemă conceptuală sau printr-o diagramă entitate – relație (ER). Schema conceptuală a unei baze de date este o descriere de forma:

Nume_entitate={lista de atribute}.

Exemplu: Entitatea ELEV={CNP, Nume, Adresa, Clasa}

Diagrama entitate – relație:

Intre entitați se pot stabili relații. Aceste relații se pot reprezenta prin Diagrama entitate – relație (Figura 1).

Fig 1. Diagrama entitate-relatie

2.4 Proiectarea unei baze de date relationale

Proiectarea BDR se realizează prin proiectarea schemelor BDR și proiectarea modulelor funcționale specializate.

Schemele bazei de date sunt:

conceptuală

externă

internă

a) Proiectarea schemei conceptuale pornește de la identificarea setului de date necesar sistemului. Aceste date sunt apoi integrate și structurate într-o schemă (exemplu: pentru BDR relaționale cea mai utilizată tehnică este normalizarea). Pentru acest lucru se parcurg pașii:

• Stabilirea schemei conceptuale inițiale care se deduce din modelul entitate-asociere (vezi analiza structurală). Pentru acest lucru, se transformă fiecare entitate din model într-o colecție de date (fișier), iar pentru fiecare asociere se definesc cheile aferente.

Dacă rezultă colecții izolate, acestea se vor lega de alte colecții prin chei rezultând asocieri (1:1, 1:m, m:n).

• Ameliorarea progresivă a schemei conceptuale prin eliminarea unor anomalii (exemplu: cele cinci forme normale pentru BDR relaționale).

• Stabilirea schemei conceptuale finale trebuie să asigure un echilibru între cerințele de actualizare și performanțele de exploatare (exemplu: o formă normală superioară asigură performanțe de actualizare, dar timpul de răspuns va fi mai mare). Tehnica de normalizare este utilizată în activitatea de proiectare a structurii BDR și constă în eliminarea unor anomalii (neajunsuri) de actualizare din structură.

Anomaliile de actualizare sunt situații nedorite care pot fi generate de anumite tabele în procesul proiectării lor:

• Anomalia de ștergere semnifică faptul că stergând un tuplu dintro tabelă, pe lângă informațiile care trebuie șterse, se pierd și informațiile utile existente în tuplul respectiv;

• Anomaliile de adăugare semnifică faptul că nu pot fi incluse noi informații necesare într-o tabelă, deoarece nu se cunosc și alte informații utile (de exemplu valorile pentru cheie);

• Anomalia de modificare semnifică faptul că este dificil de modificat o valoare a unui atribut atunci când ea apare în mai multe tupluri.

Normalizarea este o teorie construită în jurul conceptului de forme normale (FN), care ameliorează structura BDR prin înlăturarea treptată a unor neajunsuri și prin imprimarea unor facilități sporite privind manipularea datelor.

Normalizarea utilizează ca metodă descompunerea (top-down) unei tabele în două sau mai multe tabele, păstrând informații (atribute) de legătură.

FN1. O tabelă este în FN1 dacă toate atributele ei conțin valori elementare (nedecompozabile), adică fiecare tuplu nu trebuie să aibă date la nivel de grup sau repetitiv. Structurile de tip arborescent și rețea se transformă în tabele cu atribute elemntare.

O tabelă în FN1 prezintă încă o serie de anomalii de actualizare datorită eventualelor dependențe funcționale incomplete. Fiecare structură repetitivă generează (prin descompunere) o nouă tabelă, iar atributele la nivel de grup se înlătură, rămânând doar cele elementare.

FN2. O tabelă este în FN2 dacă și numai dacă este în FN1 și fiecare atribut noncheie al tabelei este dependent funcțional complet de cheie. Un atribut B al unei tabele depinde funcțional de atributul A al aceleiași tabele, dacă fiecărei valori a lui A îi corespunde o singură valoare a lui B, care îi este asociată în tabelă. Un atribut B este dependent funcțional complet de un ansamblu de atribute A în cadrul aceleiași tabele, dacă B este dependent funcțional de întreg ansamblul A (nu numai de un atribut din ansamblu).

O tabelă în FN2 prezintă încă o serie de anomalii de actualizare, datorită eventualelor dependențe tranzitive. Eliminarea dependențelor incomplete se face prin descompunerea tabelei inițiale în două tabele, ambele conținând atributul intermediar (B).

FN3. O tabelă este în FN3 dacă și numai dacă este în FN2 și fiecare atribut noncheie depinde în mod netranzitiv de cheia tabelei. Într-o tabelă T, fie A,B,C trei atribute cu A cheie. Dacă B depinde de A (A Æ B) și C depinde de B (B Æ C) atunci C depinde de A în mod tranzitiv.

Eliminarea dependențelor tranzitive se face prin descompunerea tabelei inițiale în două tabele, ambele conținând atributul intermediar (B). O tabelă în FN3 prezintă încă o serie de anomalii de actualizare, datorate eventualelor dependențe multivaloare.

O definiție mai riguroasă pentru FN3 a fost dată prin forma intermediară BCNF (Boyce Codd Normal Form): o tabelă este în BCNF dacă fiecare determinant este un candidat cheie.Determinantul este un atribut elementar sau compus față de care alte atribute sunt complet dependente funcțional.

FN4. O tabelă este în FN4 dacă și numai dacă este în FN3 și nu conține două sau mai multe dependențe multivaloare. Într-o tabelă T, fie A,B,C trei atribute. În tabela T se menține dependența multivaloare A dacă și numai dacă mulțimea valorilor lui B ce corespunde unei perechi de date (A,C), depinde numai de o valoare a lui A și este independentă de valorile lui C.

FN5. O tabelă este în FN5 dacă și numai dacă este în FN4 și fiecare dependență joncțiune este generată printr-un candidat cheie al tabelei. În tabela T (A,B,C) se menține dependența joncțiune (AB, AC) dacă și numai dacă T menține dependența multivaloare A –>> B sau C.

Dependența multivaloare este caz particular al dependenței joncțiune. Dependența funcțională este caz particular al dependenței multivaloare.

b) Proiectare schemei externe are rolul de a specifica viziunea fiecărui utilizator asupra BDR. Pentru acest lucru, din schema conceptuală se identifică datele necesare fiecărei viziuni. Datele obținute se structurează logic în subscheme ținând cont de facilitățile de utilizare și de cerințele utilizator. Schema externă devine operațională prin construirea unor viziuni (view) cu SGBD-ul și acordarea drepturilor de acces. Datele într-o viziune pot proveni din una sau mai multe colecții și nu ocupă spațiul fizic.

c) Proiectarea schemei interne presupune stabilirea structurilor de memorare fizică a datelor și definirea căilor de acces la date. Acestea sunt specifice fie SGBD-ului (scheme de alocare), fie sistemului de operare. Proiectarea schemei interne înseamnă estimarea spațiului fizic pentru BDR, definirea unui model fizic de alocare (a se vedea dacă SGBD-ul permite explicit acest lucru) și definirea unor indecși pentru accesul direct, după cheie, la date.

Proiectarea modulelor funcționale ține cont de concepția generală a BDR, precum și de schemele proiectate anterior. În acest sens, se proiectează fluxul informațional, modulele de încărcare și manipulare a datelor, interfețele specializate, integrarea elementelor proiectate cu organizarea și funcționarea BDR.

Realizarea componentelor logice

Componentele logice ale unei BD sunt programele de aplicație dezvoltate, în cea mai mare parte, în SGBD-ul ales. Programele se realizează conform modulelor funcționale proiectate în etapa anterioară. Componentele logice țin cont de ieșiri, intrări, prelucrări și colecțiile de date. În paralel cu dezvoltarea programelor de aplicații se întocmesc și documentațiile diferite (tehnică, de exploatare, de prezentare).

Punerea în funcțiune și exploatarea

Se testează funcțiile BDR mai întâi cu date de test, apoi cu date reale. Se încarcă datele în BDR și se efectuează procedurile de manipulare, de către beneficiar cu asistența proiectantului. Se definitivează documentațiile aplicației. Se intră în exploatare curentă de către beneficiar conform documentațiiei.

Dezvoltarea sistemului

Imediat după darea în exploatare a BDR, în mod continuu, pot exista factori perturbatori care generează schimbări în BDR. Factorii pot fi: organizatorici, datorați progresului tehnic, rezultați din cerințele noi ale beneficiarului, din schimbarea metodologiilor etc.

2.5 Regulile de normalizare a datelor

Normalizarea reprezintă proiectul logic al unei baze de date. Principalul obiectiv al unui proiect logic este dezvoltarea schemelor relaționale corecte. În acest scop trebuie:

evitate datele redundante;

evitate anomaliile de modificare;

asigurată reprezentarea relațiilor dintre atribute;

facilitată verificarea actualizărilor care nu trebuie să forțeze integritatea bazei de date.

Normalizarea este un proces de reducere a redundanțelor și creștere a stabilității unei baze de date. Existența redundanțelor într-o bază de date produce următoarele efecte defavorabile:

pierdere inutilă de spațiu;

scăderea performanțelor de cost;

apariția inconsistențelor;

imposibilitatea reprezentării datelor.

Normalizarea presupune determinarea locului în care trebuie plasate anumite date în cadrul tabelelor bazei de date, stabilind totodată relațiile dintre acestea.

Prin cuvântul “normă” se înțelege respectarea unui standard și reprezintă setul de condiții impuse și cunoscute sub denumirea de forme normale.

Pentru a respecta aceste reguli trebuie identificate condițiile care trebuie respectate în scopul evitării încălcării integrității datelor impunându-se în acest scop descompunerea relațiilor. Denormalizarea este procesul invers, opus normalizării efectuat cu scopul îmbunătățirii performanțelor bazei de date.

Normalizarea este, cu alte cuvinte, un proces de descompunere a unui tabel în două sau mai multe tabele cu scopul eliminării redundanțelor care generează anomalii de actualizare. În timpul procesului de normalizare, structura tabelelor se testează cu ajutorul formelor normale care impun regulile de descompunere.

Capitolul 3 – Realizarea programului de gestiune a stocurilor unei firme

3.1 Crearea bazei de date pentru gestiunea stocurilor

Baza de date, după cum denotă și numele său, reprezintă baza tuturor proceselor ce au loc în aplicatia dezvoltată. Aceasta a fost proiectată să fie cât mai eficientă din punct de vedere al spațiului folosit cât și a vitezei de încărcare. Informațiile asemănătoare sunt separate pe diferite tabele și legate între ele prin chei și id-uri, astfel evitând repetarea intrărilor asemănătoare si scăzând timpul de incărcare al aplicației.

Baza de date rulează pe platforma MySQL si in aplicația prezentată contine doar informatii de test, informatiile despre furnizori, clienți, intrari si iesiri ale firmei IT GENETICS fiind confidențiale. Baza de date stă la baza aplicației si îi asigură acesteia toate informațiile necesare pentru a oferi lista de produse, categorii, producatori, clienți, furnizori cat și statusul stocurilor, intrările, ieșirile si rapoartele de stoc si de mișcări.

Baza de date este formată din 12 tabele fiecare cu multiple coloane.

Cele 12 tabele sunt cele prezentate în figura 2:

Figura 2 – Structura de tabele conținute de baza de date

Fiecare inregistrare este unica printr-un id căruia îi este atribuit o cheie primara pentru a ajuta la indexarea mai rapida a datelor din baza de date.

O detaliere in ordine alfabetică a bazei de date si a tabelelor aferente este urmatoarea:

Category

Customer

Entry

Entry_product

Exit

Exit_product

Manufacturer

Product

Setting

Supplier

User

User_group

4.4 Etape in proiectarea bazei de date

In urma intâlnirii cu staff-ul de la IT Genetics, a fost înteles necesarul de câmpuri pentru fiecare tabel.

Cu ajutorul SGBD-ului dbForge Studio for MySQL au fost create tabelele category, customer, entry, entry_product, exit, exit_product, manufacturer, product, supplier, user, user_group.

Baza de date a fost apoi normalizată, am adăugat chei primare si auto increment-uri, si am scăpat de toate câmpurile ce nu erau necesare activitatii din prezent a firmei IT GENETICS.

4.5 Utilizarea programului de gestiune a stocurilor firmei

Aplicația a fost concepută pentru a fi user-friendly, rapidă și pentru a asigura siguranța datelor. Aplicația este concepută din multiple interfețe fiecare cu un scop bine definit, accesul între fiecare dintre acestea făcându-se usor cu ajutorul meniului.

Proiectarea interfețelor a fost făcută ținând cont și de utilizatorul nespecialist în informatică, aceasta fiind intuitivă și user-friendly iar pașii de urmat în procesele necesare utilizatorilor pot fi deduși din aplicație.

Mediul grafic este atât complet cât și complex. S-a ținut cont pe parcursul dezvoltării ca acesta să nu fie aglomerat cu elemente grafice dar, pentru a putea fi mai intuitiv, câteva iconițe sugestive au fost totuși implementate.

Astfel aplicația a devenit facilă fără a fi supraîncărcata de resurse grafice.

Interfața este auto adaptivă (Figura 10), elementele fiind aranjate în așa fel încât să arate bine și să încapă toate informațiile pe toate rezoluțiile disponibile pe monitoarele de pe piață. Se recomandă, totuși, folosirea unui monitor FULL HD (1980×1080) utilizatorilor acestei aplicații pentru o mai bună experiență.

Atractivitatea interfeței este încă un punct forte al aplicației. Compania a dorit ca aplicația să fie branduită cu numele firmei și să aibă un design plăcut, astfel aplicația a fost creată pe un spectru de culori plăcute și neutre ochilor care să nu obosească operatorul care petrece 8 ore pe zi în fața acestei aplicații.

Interfața este foarte ușor de învățat și de utilizat, mai ales pentru cei familiarizați cu toate procesele și obiceiurile din compania căreia i-a fost destinată aplicația.

În momentul in care accesăm aplicația întâlnim, în cazul în care nu suntem logați deja, pagina de login (Figura 9). Aici se pot loga userii deja adăugați in baza de date, adăugarea unor utilizatori noi necesitând permisiuni la interfața de utilizatori.

Figura 9. – Interfata de login

Fiecare user are predefinită in baza de date email-ul acestuia. În cazul în care userul își uită parola, acesta are opțiunea de a o reseta folosind link-ul de parolă uitată.

In momentul login-ului ne este prezentată prima pagina a aplicației, anume panoul principal (Figura 10).

Figura 10. – Panoul principal al aplicatiei

În panoul principal ne sunt arătate statistici ale fiecărei înregistrări din baza de date relevante aplicației noastre. Avem număratoare de înregistrari pentru clienți, furnizori, intrări in stoc, ieșiri din stoc, produse, categorii și producători.

În partea inferioară a panoului principal sunt afișate ultimele 10 mișcari din stoc. Mișcarile din stoc reprezintă intrările sau ieșirile din stoc a produselor.

În momentul apăsării butonului de extindere a meniului, intâlnim meniul ce prezintă linkurile către restul interfețelor construite in aplicație. (Figura 11)

Figura 11. – Meniul aplicației

Categoria Business din meniu cuprinde interfețele urmatoare:

Clienți

Furnizori

Categoria Catalog din meniu cuprinde catalogul itemilor relevanți in activitatea operatorilor:

Produse

Categorii

Producători

Categoria Inventar cuprinde interfetele de intrări și ieșiri din stoc.

Categoria Rapoarte cuprinde cele două rapoarte: Raportul de mișcari si raportul de stoc produse.

Categoria Utilizatori cuprinde interfețele de adăugare a utilizatorilor și a grupurilor de utilizatori necesare accesului in aplicație.

Interfața de clienti este folosită pentru a adăuga/edita/șterge clienți.

Lista de clienți este importantă in momentul adăugării unei ieșiri, ieșirea evidențiind plecarea produsului din stoc, implicit finalizarea unei comenzi către un client. (Figura 12)

Rezultatele sunt filtrabile si paginate in eventualitatea existenței a mai multor rezultate.

Figura 12. – Interfața de clienti

Figura 13. – Formularul de adăugare/editare clienți

Interfața de furnizori este folosită pentru a adăuga/edita/șterge furnizori. Lista de furnizori este importantă in momentul adăugarii unei intrări, intrarea evidențiind venirea produsului in stoc, implicit venirea unei comenzi de la un furnizor la firmă.

Rezultatele sunt filtrabile si paginate in eventualitatea existenței a mai multor rezultate. (Figura 14)

Figura 14. – Lista de furnizori

Figura 15 – Formular furnizori

Interfața de produse este folosită pentru a adăuga/edita/șterge produse. Lista de produse este importantă in momentul adăugarii unei intrări sau a unei ieșiri mișcarea fiind inregistrată pe produse, respectiv pe id-ul unic al acestora.

Rezultatele sunt filtrabile si paginate in eventualitatea existenței a mai multor rezultate. (Figura 16)

Figura 16 – Lista produse

Figura 17 – Formular produse

Interfața de intrări reprezintă epicentrul aplicației, ea stând la baza gestiunii stocului produselor.

Adăugarea unei intrări noi se realizează foarte usor, imediat cum intrăm in formularul de adăugare, completăm informațiile cerute de către aplicație iar apoi folosind tabelul din dreapta interfeței adaugăm produsele si cantitatea livrată de către furnizori.

La confirmarea formularului de adăugare, pentru fiecare produs, stocul pe acestea este incrementat, iar mișcarea este inregistrată si adăugată in baza de date.

Rezultatele sunt filtrabile si paginate in eventualitatea existenței a mai multor rezultate. (Figura 18)

Singura diferența de funcționare între interfețele de intrare si ieșire este că interfața de intrare incrementează stocul produselor si necesită detaliile facturii primite de la furnizor iar interfața de ieșire decrementează stocul și necesită detaliile facturii oferite clientului care a achizitionat produsul in urma unei comenzi.

Figura 18 – Lista de intrari

Figura 19 – Formularul de intrari

In momentul în care a fost inregistrată o intrare sau o ieșire in/din baza de date, se pot modifica doar informațiile specifice acesteia, nu și produsele pe care s-a incrementat stocul pentru a nu produce inadvertente in stocul produselor.

Daca produsele au fost adaugate greșit, greseala se poate rectifica doar prin ștergerea intrării sau a ieșirii.

In urma ștergerii unei intrări sau a unei ieăiri, produsele revin la stocul lor inițial, ca și cum nu ar fi fost afectate de intrare/ieșire niciodată.

Concluzii

Aplicația realizată pentru societatea IT GENETICS S.R.L. va fi destinată să servească operatorii, managerii departamentelor și directorul general.

Această aplicație informatică are ca obiectiv creearea unui mijloc modern de organizare al stocului de produse, informațiile fiind centralizate și relaționate cu ajutorul unei baze de date MySQL.

Condițiile principale impuse de companie pentru creearea acestei aplicații erau:

Creșterea eficienței firmei

Creșterea productivității amgajaților

Minimalizarea pierderilor

Crearea unui soft inteligibil și pentru viitori dezvoltatori

Terminarea aplicației în timp util pentru noul an fiscal

Sistemul a fost conceput și proiectat pentru a aduce un plus de management firmei pentru care s-a făcut proiectarea.

Deoarece sistemul actual pe care firma funcționează este deficitar din multe puncte de vedere această aplicație informatică vine să modifice multe aspecte ale sistemului prezent promițând să îmbunătățească calitatea și viteza tuturor fluxurilor prezente în companie.

In concluzie se poate spune că scopul aplicatiei a fost atins, printr-o mai bună organizare a procesului de gestionare a stocului de produse se modifică timpul de răspuns al operatorului crescând productivitatea și eficiența firmei și totodată și imaginea acesteia evoluând în ochii clienților, furnizorilor și a partenerilor.

Cu ajutorul rapoartelor managerii știu tot timpul de situatia stocurilor în timeline-ul stabilit de ei și pot pune la punct strategii evoluate de marketing. Acestea sunt doar câteva dintre exemplele îmbunătățirilor pe care le-a livrat sau le va livra această aplicație.

În viitor aplicația va fi imbunătățită, urmând ca in momentul in care staff-ul si managementul se obisnuiește cu aplicația dezvoltată, aceasta să fie implementată direct in platforma lor online, pe serverul lor principal. Produsele vor fi legate de cele afisate pe website, iesirile vor fi legate direct de comenzile depuse de operatori sau clienți, platforma devenind mult mai vastă.

Se va lucra pe normalizarea bazei de date actuale a magazinului online pentru a imbunătăți perfomanța de rulare a acestuia si viteza de răspuns in acțiunea cu operatorii si clienții.

Bibliografie

Anghel Traian, Manualul tau de Php – Editura Albastra, Buc. 2012

Botezatu Cornelia, Proiectarea sistemelor informatice. Metode sistemice. Editura ProUniversitaria, Buc, 2007

Chichernea Virgil, G. Garais, Baze de date. Sistemul FoxPro vol.II, Editura Prouniversitaria, 2006

Frost & Sullivan: The European Market for E-Commerce Software – A New Study; Shift in investment prioritisation galvanises expansion of e-commerce software market, http://search.proquest.com/pqcentral/docview/445970085/9CA1238B9E9E49B5PQ/1?accountid=35090

Paul Taylor, A new force drives entire industry: E-COMMERCE.Traditional companies are getting to grips with the challenge of reorganising their businesses to take advantage of the internet: [Surveys edition], http://search.proquest.com/pqcentral/docview/249017650/9CA1238B9E9E49B5PQ/9?accountid=35090

Velicanu Manole, Dictionar explicativ al sistemelor de baze de date – Bucuresti 2005

An exploratory study of Web-based electronic commerce applications,http://search.proquest.com/pqcentral/docview/200057088/A237EA0072C41FAPQ/3?accountid=35090

Beginning PHP5, Apache, and MySQL Web development, http://search.proquest.com/pqcentral/docview/200236668/475B376F2B724F9BPQ/2?accountid=35090

E-commerce hype or utopia?: [SECOND Edition], http://search.proquest.com/pqcentral/docview/270497670/9CA1238B9E9E49B5PQ/3?accountid=35090

MySQL 5.5: Improving on the World's Most Popular Open Source Database, http://search.proquest.com/pqcentral/docview/893817662/48DC2A7D6C45498FPQ/11?accountid=35090

Mysql database provides full transactional support,http://search.proquest.com/pqcentral/docview/206694766/48DC2A7D6C45498FPQ/1?accountid=35090

Professional PHP5, http://search.proquest.com/pqcentral/docview/200145013/475B376F2B724F9BPQ/5?accountid=35090

The inclusion of Web site usability in an electronic commerce acceptance model, http://search.proquest.com/pqcentral/docview/305428054/A237EA0072C41FAPQ/1?accountid=35090

Web application design and implementation; Apache 2, PHP5, MySQL, JavaScript, and Linux/Unix,http://search.proquest.com/pqcentral/docview/200133050/475B376F2B724F9BPQ/4?accountid=35090

Wikipedia – www.wikipedia.org

ANEXE

Anexa 1 – Scriptul de creare al bazei de date

DROP TABLE IF EXISTS `exit`;

CREATE TABLE `exit` (

exit_id INT(11) NOT NULL AUTO_INCREMENT,

invoice_prefix VARCHAR(26) NOT NULL,

invoice_no INT(11) NOT NULL DEFAULT 0,

invoice_date DATE NOT NULL,

customer_id INT(11) NOT NULL DEFAULT 0,

customer VARCHAR(100) NOT NULL,

date_added DATETIME NOT NULL,

date_modified DATETIME NOT NULL,

PRIMARY KEY (exit_id),

INDEX invoice_no (invoice_no)

)

ENGINE = MYISAM

AUTO_INCREMENT = 3

AVG_ROW_LENGTH = 64

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table category

–

DROP TABLE IF EXISTS category;

CREATE TABLE category (

category_id INT(11) NOT NULL AUTO_INCREMENT,

name VARCHAR(255) NOT NULL DEFAULT '',

sort_order INT(3) NOT NULL DEFAULT 0,

status TINYINT(1) NOT NULL,

date_added DATETIME NOT NULL,

date_modified DATETIME NOT NULL,

PRIMARY KEY (category_id)

)

ENGINE = MYISAM

AUTO_INCREMENT = 65

AVG_ROW_LENGTH = 35

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table customer

–

DROP TABLE IF EXISTS customer;

CREATE TABLE customer (

customer_id INT(11) NOT NULL AUTO_INCREMENT,

name VARCHAR(64) NOT NULL,

sort_order INT(3) NOT NULL,

PRIMARY KEY (customer_id)

)

ENGINE = MYISAM

AUTO_INCREMENT = 5

AVG_ROW_LENGTH = 44

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table entry

–

DROP TABLE IF EXISTS entry;

CREATE TABLE entry (

entry_id INT(11) NOT NULL AUTO_INCREMENT,

invoice_prefix VARCHAR(26) NOT NULL,

invoice_no INT(11) NOT NULL DEFAULT 0,

invoice_date DATE NOT NULL,

supplier_id INT(11) NOT NULL DEFAULT 0,

supplier VARCHAR(100) NOT NULL,

date_added DATETIME NOT NULL,

date_modified DATETIME NOT NULL,

PRIMARY KEY (entry_id),

INDEX invoice_no (invoice_no)

)

ENGINE = MYISAM

AUTO_INCREMENT = 3

AVG_ROW_LENGTH = 64

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table entry_product

–

DROP TABLE IF EXISTS entry_product;

CREATE TABLE entry_product (

entry_product_id INT(11) NOT NULL AUTO_INCREMENT,

product_id INT(11) NOT NULL,

entry_id INT(11) NOT NULL,

name VARCHAR(255) NOT NULL,

model VARCHAR(255) NOT NULL,

quantity INT(4) NOT NULL,

PRIMARY KEY (entry_product_id)

)

ENGINE = MYISAM

AUTO_INCREMENT = 11

AVG_ROW_LENGTH = 80

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table exit_product

–

DROP TABLE IF EXISTS exit_product;

CREATE TABLE exit_product (

exit_product_id INT(11) NOT NULL AUTO_INCREMENT,

product_id INT(11) NOT NULL,

exit_id INT(11) NOT NULL,

name VARCHAR(255) NOT NULL,

model VARCHAR(255) NOT NULL,

quantity INT(4) NOT NULL,

PRIMARY KEY (exit_product_id)

)

ENGINE = MYISAM

AUTO_INCREMENT = 5

AVG_ROW_LENGTH = 76

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table language

–

DROP TABLE IF EXISTS language;

CREATE TABLE language (

language_id INT(11) NOT NULL AUTO_INCREMENT,

name VARCHAR(32) NOT NULL,

code VARCHAR(5) NOT NULL,

locale VARCHAR(255) NOT NULL,

image VARCHAR(64) NOT NULL,

directory VARCHAR(32) NOT NULL,

filename VARCHAR(64) NOT NULL,

sort_order INT(3) NOT NULL DEFAULT 0,

status TINYINT(1) NOT NULL,

PRIMARY KEY (language_id),

INDEX name (name)

)

ENGINE = MYISAM

AUTO_INCREMENT = 3

AVG_ROW_LENGTH = 66

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table manufacturer

–

DROP TABLE IF EXISTS manufacturer;

CREATE TABLE manufacturer (

manufacturer_id INT(11) NOT NULL AUTO_INCREMENT,

name VARCHAR(64) NOT NULL,

sort_order INT(3) NOT NULL,

PRIMARY KEY (manufacturer_id)

)

ENGINE = MYISAM

AUTO_INCREMENT = 16

AVG_ROW_LENGTH = 44

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table product

–

DROP TABLE IF EXISTS product;

CREATE TABLE product (

product_id INT(11) NOT NULL AUTO_INCREMENT,

name VARCHAR(100) NOT NULL,

model VARCHAR(64) NOT NULL,

quantity INT(4) NOT NULL DEFAULT 0,

minimum INT(4) NOT NULL DEFAULT 0,

manufacturer_id INT(11) NOT NULL,

category_id INT(11) NOT NULL,

sort_order INT(11) NOT NULL DEFAULT 0,

status TINYINT(1) NOT NULL DEFAULT 0,

date_added DATETIME NOT NULL,

date_modified DATETIME NOT NULL,

PRIMARY KEY (product_id)

)

ENGINE = MYISAM

AUTO_INCREMENT = 56

AVG_ROW_LENGTH = 148

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table setting

–

DROP TABLE IF EXISTS setting;

CREATE TABLE setting (

setting_id INT(11) NOT NULL AUTO_INCREMENT,

`group` VARCHAR(32) NOT NULL,

`key` VARCHAR(64) NOT NULL,

value TEXT NOT NULL,

serialized TINYINT(1) NOT NULL,

PRIMARY KEY (setting_id)

)

ENGINE = MYISAM

AUTO_INCREMENT = 198

AVG_ROW_LENGTH = 166

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table supplier

–

DROP TABLE IF EXISTS supplier;

CREATE TABLE supplier (

supplier_id INT(11) NOT NULL AUTO_INCREMENT,

name VARCHAR(64) NOT NULL,

sort_order INT(3) NOT NULL,

PRIMARY KEY (supplier_id)

)

ENGINE = MYISAM

AUTO_INCREMENT = 4

AVG_ROW_LENGTH = 44

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table user

–

DROP TABLE IF EXISTS user;

CREATE TABLE user (

user_id INT(11) NOT NULL AUTO_INCREMENT,

user_group_id INT(11) NOT NULL,

username VARCHAR(20) NOT NULL,

password VARCHAR(40) NOT NULL,

salt VARCHAR(9) NOT NULL,

firstname VARCHAR(32) NOT NULL,

lastname VARCHAR(32) NOT NULL,

email VARCHAR(96) NOT NULL,

code VARCHAR(40) NOT NULL,

ip VARCHAR(40) NOT NULL,

status TINYINT(1) NOT NULL,

date_added DATETIME NOT NULL,

PRIMARY KEY (user_id)

)

ENGINE = MYISAM

AUTO_INCREMENT = 2

AVG_ROW_LENGTH = 192

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Definition for table user_group

–

DROP TABLE IF EXISTS user_group;

CREATE TABLE user_group (

user_group_id INT(11) NOT NULL AUTO_INCREMENT,

name VARCHAR(64) NOT NULL,

permission TEXT NOT NULL,

PRIMARY KEY (user_group_id)

)

ENGINE = MYISAM

AUTO_INCREMENT = 2

AVG_ROW_LENGTH = 1444

CHARACTER SET utf8

COLLATE utf8_general_ci;

–

– Dumping data for table `exit`

–

INSERT INTO `exit` VALUES

(1, 'ITG', 1, '2015-07-05', 2, 'Nord Auto Express SRL', '2015-07-05 20:25:13', '2015-07-05 20:25:13'),

(2, 'ITG', 2, '2015-07-05', 1, 'Jolly Fun Service SRL', '2015-07-05 20:28:03', '2015-07-05 20:28:03');

–

– Dumping data for table category

–

INSERT INTO category VALUES

(59, 'Laptopuri', 1, 1, '2015-07-04 22:41:11', '2015-07-04 22:41:33'),

(60, 'Tablete', 2, 1, '2015-07-04 22:41:23', '2015-07-04 22:41:23'),

(61, 'Telefoane', 3, 1, '2015-07-04 22:41:29', '2015-07-04 22:41:29'),

(62, 'Periferice', 4, 1, '2015-07-04 22:41:53', '2015-07-04 22:42:21'),

(63, 'Imprimante', 5, 1, '2015-07-04 22:42:02', '2015-07-04 22:42:02');

–

– Dumping data for table customer

–

INSERT INTO customer VALUES

(1, 'Jolly Fun Service SRL', 1),

(2, 'Nord Auto Express SRL', 4),

(3, 'KMG Line Auto Center SRL', 3),

(4, 'Rapsodia Tour SRL', 2);

–

– Dumping data for table entry

–

INSERT INTO entry VALUES

(1, 'DNB', 3696, '2015-07-01', 3, 'Danubius EXIM SRL', '2015-07-05 20:06:22', '2015-07-05 20:13:40'),

(2, 'NOD', 45, '2015-07-06', 1, 'Network One Distribution SRL', '2015-07-05 20:14:04', '2015-07-05 20:14:04');

–

– Dumping data for table entry_product

–

INSERT INTO entry_product VALUES

(6, 52, 1, 'Telefon mobil Apple iPhone 6, 16GB, Gold', 'IPH616GB', 10),

(7, 53, 1, 'Telefon mobil Apple iPhone 6, 32GB, Gold', 'IPH616GB32', 10),

(8, 54, 1, 'Telefon mobil Apple iPhone 6, 64GB, Gold', 'IPH616GB64', 10),

(9, 50, 2, 'Laptop Asus X553MA-SX455B', 'X553MA-BING-SX455B', 5),

(10, 51, 2, 'Laptop Toshiba Satellite L50-B-1VX', 'PSKTWE-01U00DG6', 15);

–

– Dumping data for table exit_product

–

INSERT INTO exit_product VALUES

(4, 52, 2, 'Telefon mobil Apple iPhone 6, 16GB, Gold', 'IPH616GB', 1),

(1, 50, 1, 'Laptop Asus X553MA-SX455B', 'X553MA-BING-SX455B', 5);

–

– Dumping data for table language

–

INSERT INTO language VALUES

(1, 'English', 'en', 'en_US.UTF-8,en_US,en-gb,english', 'gb.png', 'english', 'english', 2, 1),

(2, 'Romana', 'ro', 'ro_RO', 'ro.png', 'romana', 'romana', 1, 1);

–

– Dumping data for table manufacturer

–

INSERT INTO manufacturer VALUES

(11, 'Apple', 1),

(12, 'Asus', 2),

(13, 'Toshiba', 3),

(14, 'Philips', 4),

(15, 'Sony', 5);

–

– Dumping data for table product

–

INSERT INTO product VALUES

(50, 'Laptop Asus X553MA-SX455B', 'X553MA-BING-SX455B', 0, 0, 12, 59, 1, 1, '2015-07-05 14:40:26', '2015-07-05 20:23:45'),

(51, 'Laptop Toshiba Satellite L50-B-1VX', 'PSKTWE-01U00DG6', 15, 0, 13, 59, 1, 1, '2015-07-05 14:41:48', '2015-07-05 14:41:48'),

(52, 'Telefon mobil Apple iPhone 6, 16GB, Gold', 'IPH616GB', 9, 10, 11, 61, 1, 1, '2015-07-05 14:44:22', '2015-07-06 00:45:02'),

(53, 'Telefon mobil Apple iPhone 6, 32GB, Gold', 'IPH616GB32', 10, 0, 11, 61, 1, 1, '2015-07-05 14:45:24', '2015-07-05 14:45:24'),

(54, 'Telefon mobil Apple iPhone 6, 64GB, Gold', 'IPH616GB64', 10, 0, 11, 61, 1, 1, '2015-07-05 14:46:41', '2015-07-05 14:46:41');

–

– Dumping data for table supplier

–

INSERT INTO supplier VALUES

(1, 'Network One Distribution SRL', 1),

(2, 'Telecom IMPEX SRL', 3),

(3, 'Danubius EXIM SRL', 2);

–

– Dumping data for table user

–

INSERT INTO user VALUES

(1, 1, 'admin', '688fde91032893479720b5fe6dcfa052b8a5de2d', '3d3a96d9c', 'Plescan', 'Andrei', '[anonimizat]', '', '109.99.60.120', 1, '2015-03-27 11:48:51');

–

– Dumping data for table user_group

–

INSERT INTO user_group VALUES

(1, 'Administrator', 'a:2:{s:6:"access";a:17:{i:0;s:17:"business/customer";i:1;s:17:"business/supplier";i:2;s:16:"catalog/category";i:3;s:20:"catalog/manufacturer";i:4;s:15:"catalog/product";i:5;s:18:"common/column_left";i:6;s:18:"common/filemanager";i:7;s:11:"common/menu";i:8;s:14:"common/profile";i:9;s:15:"inventory/entry";i:10;s:14:"inventory/exit";i:11;s:21:"localisation/language";i:12;s:15:"report/movement";i:13;s:12:"report/stock";i:14;s:14:"system/startup";i:15;s:9:"user/user";i:16;s:15:"user/user_group";}s:6:"modify";a:17:{i:0;s:17:"business/customer";i:1;s:17:"business/supplier";i:2;s:16:"catalog/category";i:3;s:20:"catalog/manufacturer";i:4;s:15:"catalog/product";i:5;s:18:"common/column_left";i:6;s:18:"common/filemanager";i:7;s:11:"common/menu";i:8;s:14:"common/profile";i:9;s:15:"inventory/entry";i:10;s:14:"inventory/exit";i:11;s:21:"localisation/language";i:12;s:15:"report/movement";i:13;s:12:"report/stock";i:14;s:14:"system/startup";i:15;s:9:"user/user";i:16;s:15:"user/user_group";}}');

Copyright Notice

© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.

Acest articol: Proiectarea Unei Baze de Date Pentru Evidenta Operativa a Stocurilor de Produse Intr O Firma de Comert Exterior (ID: 150266)

Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.

Proiectarea Unei Baze de Date Pentru Evidenta Operativa a Stocurilor de Produse Intr O Firma de Comert Exterior

Copyright Notice

Terorismul Informatic O Noua Forma de Amenintare la Adresa Infrastructurilor Strategice

Aplicatii Software Pentru Sisteme Embedded

Evaluarea Asistata de Calculator la Modulul Bazele Electronicii Analogice

Tehnologii Recente Pentru Aplicatii Web

Realizarea Unui Magazin Virtual

Cultura Informatiei In Centrul de Documentare Si Informare (cdi)

Copyright Notice

Similar Posts