U H, B

Studiu privind proiectarea unui

sistem integrat de gestiune pentru
retail
Masterand:
A
Richard-Horia-Andrei

Coordonator tiinic:
C. U. D. I.
C
Oana Andreea

Ianuarie 2014

Cuprins
Cuprins

Generaliti
1.1 Introducere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Gestiunea informatic . . . . . . . . . . . . . . . . . . . . . . . .

2
2
2

Concept ARHA/SM
2.1 Cerine preliminare . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Concluzii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Proiectarea de nivel nalt . . . . . . . . . . . . . . . . . . . . . .

3
4
8
9

Tehnologia de proiectare
3.1 Concepte generale . . . . . . . . . . . . .
3.2 Dezavantajul SaaS . . . . . . . . . . . . .
3.3 Tehnologia de stocare . . . . . . . . . . .
3.3.1 Fiiere plane . . . . . . . . . . . .
3.3.2 RDBMS . . . . . . . . . . . . . .
3.3.3 Proiectarea i modelarea RDBMS
3.3.4 Produse soware RDBMS . . . .
3.3.5 Concepte NoSQL . . . . . . . . .
3.3.6 Teorema CAP . . . . . . . . . . .
3.3.7 ORM-ul i Consideraii nale . .
3.4 Limbajul de programare . . . . . . . . . .
3.4.1 Tehnologii server-side . . . . . .
3.4.2 Tehnologii client-side . . . . . .
3.5 Infrastructura . . . . . . . . . . . . . . .

Anexe

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

11
11
11
12
13
15
16
17
19
21
22
23
23
27
28
30

Bibliograe

31

1
1.1

Generaliti
Introducere

Gestionarea i administrarea companiilor este un proces complex, care a dat

natere soluiilor noi n domenii interdependente ca managementul, economia,
securitatea n munc i logistica. O ntreprindere i desoar activitatea cu
scopul de a obine prot prin realizarea de produse i/sau prestarea de servicii cu
aport de ore depuse de personal i cheltuial de materii prime. Aceast activitate
este ns n permanent legtur cu societatea, ntruct serviciile i produsele o
au ca destinatar nal, dar este i sub permanena inuen a acesteia, printr-o
diversitate de factori pe care aceasta i creaz. Singurul mod n care o companie
poate aciona este prin schimbarea strategiei interne n procesele de decizie,
amortiznd efectele negative cnd apar.
Simultan cu globalizarea pieelor de desfacere i stabilirea de normative
asupra proceselor de producie desurate n diferite domenii, s-a observat
c lipsa informrii asupra unei perspective economice, a operaiilor interne i
asupra competiiei devine un neajuns deosebit de sever. Urmrirea acestor aspecte economice, n pieele de desfacere moderne, precum i a competiiei, dar
i o serie de ali factori cum ar , spre exemplu, ecacitatea unui program de
marketing, sau anumite comportamente observate n segmentele-int de pia
au depit limita de informaii pe care un operator uman le poate procesa. Sistemele care gestioneaz deci astfel de date sunt de obicei informatizate, considerate enterprise-class datorit disponibilitii i scalabilitii, n comparaie cu
un soware realizat pentru un utilizator desktop, funcionarea lor este mission
critical - sunt absolut necesare funcionrii companiei, iar defectarea lor poate
aduce att daune nanciare ct i juridice. Aceste sisteme funcioneaz prin
analize complexe, att prin algoritmi clasici, ct i prin algoritmi de tip genetic
sau reele neurale pentru a permite structurarea datelor ntr-un mod facil, dar i
oferirea de previziuni conform cu datele introduse i factorii cunoscui.
n acest proiect ne propunem proiectarea unui astfel de sistem i vom analiza
toate aspectele necesare pentru a atinge acest scop.

1.2

Gestiunea informatic

Un sistem de gestiune informatic urmrete micrile bunurilor, capitalului i

personalului i prezint aceste date n diferite forme.
n cadrul activitii de retail, gestiunea informatic cuprinde diferite aspecte
precum:
Urmrirea uxurilor - administratorul companiei poate realiza uxuri
specice n funcie de prolul su pe care utilizatorii, angajti sau colab2

oratori, le exploateaz; n acelai timp permite celui dinti s urmreasc

uxurile iniiate i starea acestora.
Inventarierea - este utilizat n mai multe scopuri: realizarea analizelor
statistice i previziunilor de consum n vederea reducerii achiziiilor
i eliminarea pierderilor (spre exemplu, prin supraachizii de bunuri
perisabile); controlul automat al stocurilor i depozitarea automatizat;
generearea de rapoarte asupra stocurilor, precum i plasarea de comenzi
noi, e prin intermediul operatorilor umani, e automat, ctre furnizori;
observarea i prevenirea sustragerii de produse din depozite.
Analiza nanciar - realizat pentru a optimiza prolul de activitate
n funcie de evoluia pieei, precum i pentru a agrega informaiile
economice solicitate de organismele scale guvernamentale
Generarea de rapoarte - care pot att de tipuri specice, precum facturi,
declaraii de inventar, e de necesar i declaraii de venit, precum i alte
rapoarte cu uz intern sau specic.
Aspecte de securitate - diferite funcii ale sistemului trebuiesc accesate
doar de utilizatori care au dreptul de a le accesa, conferite conform ei
postului, pregtirii, etc.
Gestiunea unor alte elemente sau interfaa cu soware-ul aferent care
le gestioneaz - servicii secundare necesare companiei precum serviceul, marketingul sau trainingul angajailor, care pot doar subcontractate,
neavnd departamente dedicate.
n general, un sistem de acest tip are, din punctul de vedere al utilizatorului,
cteva funcionaliti mult mai simple: agregarea valorii contractelor i facturilor
pe durate de timp, de obicei luni; agregarea vnzrilor i produselor cu cea
mai mare cutare, agregarea sumelor ncasate pe baz de bon scal, agregarea
clienilor dup zone geograce i suma tranzaciilor, pentru realizarea de oferte
reciproc avantajoase. De multe ori ns, n funcie de specicul ecrei afaceri,
pot necesare i alte funcionaliti.
Pe msur ce activitatea se diversic i compania particip n tranzacii cu
piee tot mai largi, necesarul unui sistem de gestiune cu ct mai multe faciliti
devine imperativ.

Concept ARHA/SM

Dup un studiu pe un numr redus de participani, dessurat de autor, n vederea

realizrii unui produs cu caracter competitiv, s-au tras un numr de concluzii
3

referitoare la sistemele deja existente. Pe baza acestor concluzii, s-au determinat

urmtoarele cerine ca ind un minim necesar pentru orice produs soware care
va avea un avantaj indisputabil n pia.
Sistemul proiectat, numit n continuare ARHA/SM (dup numele autorului
i Shop manager), va oferi rspunsul la aceste cerine nu ca funcionaliti
cap de a, ca cele mai vizibile pe yer-ul de prezentare, ci ca reacie logic
la evoluia pieei i familiarizarea tuturor utilizatorilor de pachete soware cu
anumite procese de lucru.

2.1

Cerine preliminare

1. Interoperabilitate: ntre produsele deja existente s-a constatat o lips de

intercomunicare, precum i utilizarea excesiv a fenomenului de vendor
lock-in: blocarea cumprtorului doar n gama de produse de la un anumit
productor, ntruct cel din urm refuz s se ncadreze standardelor (sau
dezvolt n paralel standarde proprii, dar cu limit de circulaie doar n
cadrul companiei). Aceste practici se ntlnesc mai des n cadrul produselor
de ni sau pieii de consum (spre exemplu, Sony sau Apple), ntr-un mediu
industrial ind considerat mai degrab un neajuns (un modul care nu se
poate monta pe ina deja existent, alturi de celelalte, necesit investiii
suplimentare i modicri n sistemul existent).
Din acest motiv, sistemul proiectat, va avea ca prim scop interoperabilitatea: vor exista module proiectate pentru mai multe funcii, ns modul
n care acestea vor comunica ntre ele, precum i modul n care alte aplicaii
(deja existente, prin mbuntiri, sau realizate ulterior) se pot interfaa cu
aceste module va public.
2. Interfa cu utilizatorul modern: Exist sisteme n producie care i
astzi folosesc interfee de tip terminal, precum o consol la distan,
accesat prin SSH sau telnet, sau o interfa direct n linia de comand de
Windows. Am putea considera acest aspect o eroare de analiz, ntruct
nu este recomandat ca sistemele deja existente i oamenii deja instruii s
e schimbate, respectiv reeducai, ns n acest caz, avem libertatea de a
proiecta acest sistem de la zero. Optm astfel pentru o interfa modern,
uid i deosebit de responsiv, cu care majoritatea utilizatorilor sunt
familiarizai din interaciunea cu dispozitivele de zi cu zi: smartphoneuri,
tablete, televizoare inteligente, etc.
Aceasta dorete ca utilizatorul, familiarizat cu procesul specic pe care
trebuie s l desoare n cadrul activittii sale, s nu necesite training i s
ofere n mod ct mai intuitiv toate cmpurile de date necesare introducerii
4

de elemente noi i s le prezinte ntr-o form ct mai accesibil atunci

cnd sunt solicitate date anterioare sau informaii agregate asupra acestor
date. S-a constatat n cazul pachetelor soware studiate c utilizatorii sunt
expui n mod direct relaiilor din bazele de date utilizate, forndu-i s
execute mai multi pai dect este necesar sau chiar emind erori la care
utilizatorul nu va putea reaciona (erori cauzate mai degrab de proiectarea
greit a capetelor de tabele sau relaiilor).
3. Interfa universal cu dispozitivele hardware: n retail este necesar
conectarea cu diferite dispozitive care ofer funcii indisponibile pe un
PC desktop obinuit: scanarea de coduri de bare, cntrirea, micarea
benzilor transportoare i rotirea automat, depozitarea automat. Suportul
hardware care ofer aceste funcii este deosebit de variat. Spre exemplu,
cititoarele de coduri de bare liniare se pot conecta ca o simpl tastaur PS/2,
oferind o mu adiional pentru conectarea tastaturii terminalului, se pot
conecta prin USB, sau printr-o plac dedicat, de tip PCI/E. Se constat
diferite probleme cu aceste implementri, spre exemplu - introducerea de
logic suplimentar n cititor care s combine datele de la tastatur i cititor
a fost deseori implementat prin inhibarea semnalelor tastaturii atunci
cnd un cod de bare valid este citit, cauznd n unele cazuri blocarea sau
resetarea controllerului de tastatur - o situaie cu care utilizatorul nu va
familiarizat, i de multe ori necesitnd resetarea ntregului terminal.
Dei piaa abund de dispozitive hardware pentru retail, n general
realizarea unui sistem integrat care poate reprodus uor n cazul
extinderii necesit un proiect dedicat, care analizeaz compatibilitatea
dintre aceste dispozitive. Prin acest cerin dorim s realizm o platform
care s ofere o interfa generic pentru clasele de dispozitive utilizate i
module individuale pentru ecare produs existente, oarecum similar cu
driverele sistemului de operare, iniial realizate pentru cele mai comune
dispozitive hardware.
Aceste drivere pot avea n vedere att interaciuni directe, din dispozitivele ataate terminalului pe care se lucreaz - spre exemplu, o imprimant
termic pentru bonuri este legat, n majoritatea cazurilor, pe portul serial
al terminalului. Alte dispozitive ns, precum cntarele electronice integrate n punctele de vnzare sunt legate prin Ethernet ntr-o reea local.
Date ind aceste cazuri, driverele trebuiesc s preia informaii att n mod
direct, accesnd funciile sistemului de operare, ct i n mod indirect, prin
datele primite pe un socket.
4. Simplicarea rapoartelor: Activitile comerciale de orice natur necesit
5

n Romnia, precum menioneaz n mod repetat sursele media1 , un numr

mare de rapoarte: declaraii de conformitate, rapoarte nanciare, mai
multe tipuri de facturi, declaraii asupra angajailor, diferite registre n
funcie de prolul specic, etc. Aceste rapoarte sunt adesea, n funcie
de desinatar, realizate cu personalizri, spre exemplu sediul de lucru
i numele companiei, capitalul social care n decursul existenei unei
societi vor suferi modicri.
S-a constatat n sourile existente o decien deosebit de grav la adresa
utilizatorului asupra capacitii de personalizare a acestor rapoarte anume, nul. Rapoartele generate sunt, pentru cazurile studiate, de obicei
hard-codate, probabil datorit problemelor care apar n a implementa un
sistem de tehnoredactare programatic i necesit rescrierea i recompilarea
codului, precum i meninerea unei baze de cod diferite pentru ecare
client, n cazul n care sunt solicitate modicri. Acest lucru complic nu
doar munca utilizatorilor, ci i a celor care proiecteaz i execut sistemul,
care, spre exemplu - n cazul unui update de soware - sunt nevoii s
aplice acel update pe toate ramurile de cod existente pentru ecare client,
s-l recompileze i testeze pentru ecare client, dup care s-l distribuie.
O decien mai redus, legat de aspectul interfeei cu utilizatorul, s-a
constatat i n cazul solicitrii de rapoarte anterioare, n care utilizatorii
sunt de obicei prezentai cu o matrice de butoane, referitoare la toate
rapoartele pe care pachetul soware le poate produce i n cazul apsrii
unuia dintre acestea, solicitarea direct a cheii primare din baza de date
pentru raportul cerut, r posibilitatea de a explora intrrile existente.
Utilizatorul este astfel obligat s caute datele pentru raportul dorit, s le
noteze n mod separat, s revin n contextul tipririi de rapoarte i s
introduc datele cheii primare alese. Acest ux nu este considerat optim.
5. Absena pregtirii sistemului n vederea instalrii pachetelor studiate,
precum i a administratorilor de sisteme a fost constatat foarte rar,
i este privit ca un neajuns. Sistemele PC utilizate pentru a lucra
ca terminal sunt de multe ori blocate pentru lucrul exclusiv n scopul
pentru care au fost achiziionate. Pregtirea sistemului este necesar din
cauza utilizrii unei platforme de programare Just-in Time Compilation,
precum variante vechi de Visual Basic sau de maini virtuale soware,
precum platforme .NET, Java sau ActionScript. Mai ru ns, s-a constatat
chiar blocarea anumitor parametri de funcionare (spre exemplu, rezoluia
ecranului) la valori xe, independente de cauze bine determinate, doar
1

O simpl cutare Google pe termenul birocraie excesiv a returnat, la data scrierii acestui
document, aproximativ 150.000 rezultate

pentru ncadrarea corect a interfeei grace. Acest ultim defect este

cel mai adesea cauz a realizrii pachetului soware r a ine cont de
utilizator, i doar prin urmrirea oferirii a unor funcii care pot enumerate
uor i prezentate n paralel cu soware-ul competitiv.
Pentru a realiza acest lucru s-au efectuat mai multe experimente referitoare la complexitatea meninerii unui sistem cu diferite platforme-suport
pentru limbaje de programare. Concluzia la care s-a ajuns, att din punct
de vedere al realizrii soware, ct i din punct de vedere al familiaritii
utilizatorului, dar i din punct de vedere al modicrilor asupra mainii
i necesarului de mentenan impus a fost utilizarea unui browser i realizarea produsului ca aplicaie web.
6. Sistem transparent de baup Pierderea datelor a ajuns s e un element
mai puin discutat n ziua de azi, datorit creterii abilitii tehnologiilor
de stocare, a apariiei de tehnologii noi de stocare r piese n micare,
precum i a suportului de distribuie a datelor in the cloud pe servere
nchiriate, aate n diferite locaii. Multe dintre sistemele din acest studiu
nu au avut sisteme de backup sau au oferit o interfa foarte rudimentar
pentru execuia acestui proces: deschiderea unei ferestre care conine toate
ierele importante i att, lasnd la latitudinea utilizatorului ce se va
ntmpla, r a-l informa asupra strii procesului sau natura activitii pe
care trebuie s o desoare. Unul singur a oferit posibilitatea de a efectua
totul printr-un singur click prin inscripionarea unui CD. Dei acesta
depete cu mult media, considerm acest aspect nesatisctor: este
necesar achiziionarea de consumabile care au o via limitat, unitile
de inscripionare pentru utilizatorii de rnd au o via foarte limitat, care
nu se supune unui proces de backup zilnic sau chiar mai des - corelat
cu evenimentele importante (spre exemplu, backup dup emiterea ecrei
facturi) iar dup orice standard modern, CD-urile sunt mai mult un produs
arhaic dect tehnologie modern.
Aplicaia ARHA/SM a fost proiectat s efectueaz backup online pe
serverele pe care este rulat, informnd utilizatorul, foarte sumar, asupra
dii ultimului proces de backup efectuat. ntruct, aa cum se va constata
mai trziu, ARHA/SM nu este un soware clasic, ci oferit ca serviciu,
utilizatorul i poate accesa oricnd datele, chiar de pe un sistem nou
instalat, r a necesar s instaleze pachete soware.
7. Securitatea datelor: Spionajul industrial i economic este un proces
prin care o companie obine diferite date, de natur tehnic, proprietate
intelectual sau nanciar asupra unui competitor cu intenia de a-i
modica un aspect al funcionrii sale pentru a ctiga o parte din
7

segmentul de pia ocupat de ctre compania victim. Acest lucru a devenit

mult mai uor astzi, datorit ubicuitii Internetului. n cadrul pachetelor
soware studiate, s-a constatat lipsa total a sistemelor de securitate, cu
cteva excepii - care de obicei stocau parola de pornire n text plan ntrun ier cu un nume care sugereaz explicit coninutul su.
Vom ncerca n proiectarea ARHA/SM s trecem peste un sistem de
securitate de tip on/o i s realizm un sistem modern, care permite
realizarea de structuri ierarhice (angajaii nu pot realiza declaraii ctre
FISC, oferii nu pot emite facturi - dect cel care este angajat i pe postura
de vnztor, etc) cu un sistem exibil de drepturi i grupuri de utilizatori.

2.2

Concluzii

Dei realizarea unui sistem informatic implic mai multe etape teoretice, precum:
Stabilirea cerinelor
Analiza i realizarea de specicaii
Proiectarea
Implementarea
Testarea funcional pe uniti
User Acceptance Testing
majoritatea analitilor de sistem au tendina de a parcurge parial acest ux,
dac nu doar una singur scierea de cod lucru explicat prin tendina de
supra-atribuire a sarcinilor de lucru i nedistribuia corect a membrilor ntro echip, dar nu rar si din cauza ntrzierilor sau nepredrii din partea clientului
a cerinelor produsului.
Dar tot att de adevrat este i faptul c parcurgerea acestor etape poate duce
la rezultate superioare i la eliminarea unor erori de proiectare i programare
nc din fazele iniiale ale proiectului. Ceea ce este mai duntor este faptul c
de obicei se renun la etapele de analiz i proiectare ale produsului, care sunt
etape cheie n dezvoltarea aplicaiei, ele furniznd o schematizare i o vedere de
ansamblu, care duc la o nelegere mai profund a problemei abordate.
Proiectarea unei aplicaii soware complexe, de dimensiuni mari, dezvoltat
n cadrul unei echipe de soware, nu se face trecnd direct la implementarea
programului, ci trebuie s urmeze etapele enumerate mai sus. Dup cum se
observ, proiectarea nu se termin odat cu implementarea, pentru c sistemul
8

creat trebuie testat si apoi instalat. Dup instalarea produsului soware acesta
trebuie ntreinut, operaie care trebuie realizat continuu.
Ceea ce s-a descris mai sus constituie unul din cele trei cicluri ale metodologiilor utilizate n analiza si proiectarea sistemului, i anume ciclul de via al unui
sistem informatic o metodologie comun de dezvoltare a sistemelor, caracterizat prin mai multe faze care marcheaz evoluia eforturilor de analiz i
proiectare a sistemelor (Hoer), i care constituie obiectul de studiu al ingineriei
programrii (este un domeniu care ncearc o abordare sistematic a dezvoltrii,
operrii, ntreinerii si retragerii unui program de pe pia).
n cazul de fa, s-a preferat o analiz a sistemelor deja existente, precum i un
studiu asupra utilizatorilor acestor sisteme i agregarea neajunsurilor raportate
pe parcursul exploatrii acestor sisteme ntr-o form simplicat, prin elaboarea
cerinelor capitolului anterior.

2.3

Proiectarea de nivel nalt

Sistemul se va compune dintr-un numr de blocuri corelate:

Modulul nanciar prelucreaz diferitele tranzacii care au loc dar ofer i
informaii directe sau agregate asupra situaiilor nanciare anterioare sau
curente
Modulul inventar prelucreaz schimbrile care au loc n stocuri, precum
ofer i informaii directe sau agregate asupra stocurilor curente
Modulul hardware abstractizeaz diferite subsisteme comune n retail:
cititoare de coduri de bare, benzi de deplasare, sisteme de depozitare i
inventariere automatizat, precum i o serie de sisteme mai puin necesare
n retail, precum diveri senzori (necesari, spre exemplu, modulului
furnizori, pentru a invoca comenzi automate).
Modulul hardware este singurul modul cu caracteristici speciale ind
nu este implementat pe server - deoarece este necesar interaciunea cu
dispoztive de la sediul clientului, acesta adun aceste mesaje i le transmite
ctre server pentru procesare
Modulul de relaionare cu terii lucreaz cu modulul furnizori i cel cu
clienii i adun informaii despre comportamentul acestora - ct de rapid
efectueaz pli sau ct de des returneaz produsele, calitatea produselor
oferite i numrul de rebuturi, precum administreaz i informaii despre
acetia - adrese, telefoane utile, relocri, preferine

 Modulul furnizori lucreaz mpreun cu modulul inventar i modulul hardware i urmrete att administrarea furnizorilor de servicii i produse, ct
i plasarea de comenzi noi n cazul unor praguri ajustabile, e din inventar,
e prin declanarea unor evenimente observate de senzori (spre exemplu,
creterea excesiv a temperaturii n camera frigoric poate solicita n mod
automat o investigaie), precum i sugera pli automate, prin intermediul
modulului bancar
Modulul clieni este un modul similar cu cel de furnizori, dar mai simplicat
Modulul rapoarte depinde de majoritatea celorlalte module i permite
generarea de rapoarte n funcie de date individuale sau agregate
Modulul de securitate este implementat n toate modulele existente,
prin solicitarea i autenticarea jetoanelor unice oferite de modulul de
securitate; modulele pot oferi securitate mai granular dect cea implicit
- la nivel de modul. Acest modul ofer utilizatorilor i jetoanele unice,
n funcie de conrmarea autenticitii lor (spre exemplu prin perechi de
tip user-parol, sau n colaborare cu modulul hardware, prin citirea unui
smartcard, sau mpreun cu modulul angajai, prin citirea cardului de
access i unui cod PIN, etc)
Modulul angajai i bunuri urmrete buna desurare a unor operaii precum deplasarea vehiculelor, pontarea angajailor, plata salariilor, accesul
n incint (n colaborare cu modulul hardware).
Modulul bancar permite efectuarea de diferite pli ctre diferite bnci
Modulul backup efectueaz copii de siguran ale datelor, ns, datorit
infrastructurii server care va implementat pentru stocarea datelor
(server multiple cu baze de date hot-standby, precum i sisteme de stocare
RAID10) nu va utilizat dect n situaii excepionale (spre exemplu, n
cazul n care clientul prefer lucrul oine i ARHA/SM nu este oferit ca
SaaS, ci ca main virtual).
Aceste module vor funciona corelat, prin schimbul de mesaje de tip JSON
ntre ele, i n funcie de observaiile empirice cute n producie, vor putea
distribuite pe diverse servere (evident, mai puin modulul hardware, care va cu
siguran modulul cu distribuia cea mai mare ntre clieni, anume de 1:1, pentru
a putea utiliza imprimantele termice i/sau casele de marcat).
Mesajele vor putea emise nu doar de ctre modulele existente pe servere,
ci n timp, i de alte module dezvoltate n mod independent de ctre clieni sau
furnizate la cerere.
10

Tehnologia de proiectare

3.1

Concepte generale

Sistemul proiectat va unul modular, de tip aplicaie web. Motivarea deciziei

este dat de mai multe aspecte:
O aplicaie de acest tip este deosebit de uor de depanat dup ce prototipul
iniial este n producie, ntruct bazele de date pot clonate i nu mai sunt
necesare deplasri la sediul clientului
Soluiile bugurilor critice constatate n cazul unui client pot propagate
ctre ali clieni n mod transparent (n mod necesar ind necesar
mpingerea de updateuri ctre toi clienii)
Tehnologia web este rspndit pe toate platformele majore existente
astzi: Windows, Linux/BSD, Android dar i n foarte multe dispozitive de
ni (smart TV, spre exemplu). Proiectarea unei aplicaii desktop pentru o
platform r suport web este probabil mult mai complex dect instalarea
unui browser.
Accesul la aplicaie poate oferit ca SaaS2 clientului, oferind avantaje n
sistemul de licen pentru ambele pri.
Necesitile sistemului pe care va rula sunt minime: un browser web cu
tehnologie compatibil ECMAScript (Javascript)

3.2

Dezavantajul SaaS

Aceast tehnologie prezint i un singur dezavantaj - absena conectivitii cu

serverul care ofer suportul informatic duce la blocarea complet a serviciului.
Acest dezavantaj poate eliminat n mai multe moduri - precum stocarea local
a tuturor datelor critice introduse pn la restabilirea conexiunii (cu pierderea
parial de funcionalitate), instalarea serverelor pe baz de cldire, n funcie de
densitatea de utilizatori si accesarea acestor sisteme dintr-o reea local sau chiar
instalarea pachetului soware de tip daemon i a celor de baze de date local, pe
maina pe care va rula sistemul.
ntruct ultima metod prezint att dezavantaje din punctul de vedere al
securitii datelor ct i posibiliti mrite de realizare a copiilor pirat dar i
o pregtire anterioar a sistemlui anterior instalrii ARHA/SM a sistemului
vom considera aceast variant neabil i o vom elimina. ns, n scopul
2

Soware as a service

11

acoperirii unei piee ct mai largi, se va avea n vedere virtualizarea complet

a sistemului de operare pe care pachetul ARHA/SM ruleaz i oferirea acestei
variante clienilor n cazuri speciale - n acest caz, necesarul de pachete soware
instalate pe terminal mrindu-se de la 0 (plecnd de la presupunerea c orice
sistem pe care se va rula, va avea conectivitate web i un browser) la 1, anume
pachetul soware de tip hypervisor (VBox, Xen, VMWare, etc).
Mai specic, putem elimina parial dezavantajul enumerat prin oferirea unui
suport de comunicaie wireless mpreun cu pachetul soware (sau decontarea
achiziiei unui astfel de suport + a abonamentului lunar), precum a modemurilor
3G sau a conectivitii ntr-o reea WiFi local. Se poate presupune c n funcie
de calitatea semnalului i a datelor transmise, accesul la aplicaie va greoi; acest
lucru a fost eliminat din start datorit arhitecturii modulelor soware: partea de
client nu va funciona prin rencrcarea unor pagini dinamice, ci prin tehnologii
moderne precum Angular i AJAX. Acest lucru ne garanteaz ca pachetele
schimbate cu serverul vor consta, n cea mai mare parte, din datele nou aate
(valoarea unei facturi, inventarul pentru un produs, etc) i nu din simboluri care
descriu pagina (elemente de sintax HTML sau CSS); modul de funcionare al
primelor dou tehnologii amintite face ca paginile web s se ncarce o singur
dat iar orice comunicaie ulterioar s conin doar date relevante aplicaiei (i
nu meta-informaii: aezarea n pagin a datelor, tabele, poziionarea imaginilor,
culori, etc).
n mod interesant, suportul pentru browsere moderne a evoluat sucient de
mult, nct, tehnologii precum WebSQL sau IndexedDB permit existena bazelor
de date relaionale direct n browser. Putem astfel s realizm o parte din
funcionaliti n regim oine: modicarea inventarului, facturarea, generarea
unor rapoarte.

3.3

Tehnologia de stocare

Sistemele de stocare se refer la modul n care aplicaia stocheaz datele

introduse de utilizator, datele procesate, precum i orice evenimente istorice
care confer informaii asupra versiunii datelor (migraia personalului, repartiia
veniturilor ntre distribuitori, tipurile de furnizori care au dat faliment, etc).
n mod clasic, sistemele de stocare se mparte n dou categorii: stocarea
n iere simple i stocare n baze de date relaionale (RDBMS/SQL - Relational
Database Management System, accesate prin Structured ery Language).
Ultimii ani ns au adus tehnologii disruptive care vor descrise sumar: XML, i
ulterior JSON - un tip de reprezentare a datelor tabelare cu form liber, i r
constrngeri relaionale; precum si sisteme de baze de date nerelaionale, NoSQL
- precum Mongo, CouchDB, redis. ntruct dezvoltarea cu ultimele sisteme
enumerate confer numeroase avantaje programatorilor, att prin eliminarea
12

potenialelor probleme n lucrul cu RDBMS sau iere simple, ct si prin

diminuarea perioadei de dezvoltare, le vom oferi propriul subcapitol.
3.3.1 Fiiere plane
Aceast form de stocare devine tot mai rar ntlnit. Se refer n general la
crearea unei structuri arborescente cu ierarhia specic sistemului de iere,
folosite din intermediul aplicaiei dezvoltate, n care datele introduse de utilizator
sunt stocate ntr-o form accesibil si programatic. Spre exemplu:
Bloc de cod 1: Exemplu de stocare n iere plane
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

+ Stocare /
+ Facturi /
factura -01
factura -02
factura -05
+ Furnizori /
furnizor -01
furnizor -02
+ Angajati /
angajat -01
+ Bilant /
+ Venituri /
2014 -01 -01
2014 -01 -02
2014 -01 -03
+ Cheltuieli /
2014 -01 -01
2014 -01 -03

n aceste iere se stocheaz cel mai adesea date sub form tabular sau
de forma variabil=valoare. Putem de exemplu, rezuma toi furnizorii ntrun singur ier ca apoi s enumerm caracteristicile specice ecruia (nume,
cod CAEN, adres, telefon primar) n acest ier. Datele vor introduse cu
un furnizor pe rnd (separte prin caracterul ascii \n, cunoscut ca separator
de linie, cod 0x0A) i valorile dintre diferite cmpuri pot separate printr-o
multitudine de caractere, spre exemplu, caracterul tab (\t, cod 0x09), virgule
sau alte simboluri speciale - cu condiia ca acest caracter de separare s nu e
folosit n datele propriu-zise, sau s e implementat un sistem de escaping spre exemplu, cel din standardul C prevede ca introducerea caracterului ascii
0x0A se face cu codul \n, al caracterului tab, cu codul \t, iar al caracterului \,
folosit n scopul special de a aa caractere neprintabile, cu codul \\. Fiierele
de acest tip prezint ntotdeauna riscul ca utilizatorii s le modice manual,
precum i s le defecteze iremediabil prin introducerea caracterelor de escape.
13

Modicarea manual prezint riscuri de securitate care pot parial diminuate

prin implementarea de sume de control - spre exemplu, modicarea numrului
de produse facturate i de numerar ncasat.
Mai mult, aceste iere tabulare prezint un dezavantaj major: dac un rnd
necesit elemente suplimentare, este necesar modicarea tuturor rndurilor:
spre exemplu, dac un furnizor adaug o linie telefonic suplimentar pentru
plasarea comenzilor unui anumit tip de produse este necesar parcurgerea
manual a ierului i introducerea unui cmp blanc pentru toi ceilali furnizori
care nu posed acest al doilea telefon. Trebuie considerat ns i informaia
referitoare la acest telefon secundar, informaie numit metadata: un alt
furnizor poate oferi un numr de telefon secundar pentru suport tehnic, acest
numr poate introdus n noul cmp, ns un utilizator poate vedea n aplicaie
trei termeni: Telefon 2 - care nu este deosebit de informativ despre ce serviciu se
presteaz la acest numr de telefon, Telefon pentru plasri comenzi produs x caz n care un alt furnizor, oferind produsul y, va avea nevoie din nou de un cmp
special i este irelevant n cazul celui de-al doilea furnizor, care nu ofer produsul
x sau Telefon suport tehnic, caz n care, pentru primul furnizor, informaia va
greit.
Aceast problem nu este singura care poate aprea. Interogarea pe o
alt cheie dect cea salvat (de exemplu, dup codul CAEN) este problematic,
ntruct trebuiesc citite toate ierele. Realizarea de informaii agregate - spre
exemplu numrul de facturi i valoarea acestora emis ctre toi clienii care sunt
din Bucureti, presupune deja o serie de probleme mai complexe: nu doar toate
ierele trebuiesc citite i ncrcate n structuri de date, dar acest lucru trebuie
cut progresiv, r a utiliza ntreaga memoria, de obicei prin citire repetat i
atribuirea unui scor de relevan. Acest mod de lucru seamn cu o parte din
sarcinile specice unui motor RDBMS. Putem arma c un pachet complex, care
ar folosi acest tip de stocare, a ales s scrie propriul RDBMS (evident, cu o baz
de utilizatori mult mai mic dect un RDBMS real, i bug-urile aferente).
Datorit relaiilor complexe care apar ntre date, precum i necesitii de
mentenan permanent pe un astfel de sistem, informatica de gestiune folosete
foarte rar acest mod de stocare, cu excepia produselor soware foarte simple.
Dezvantajul major al sistemelor de tip plain-text este c soware-ul nu poate
implementat pentru medii de lucru cu mai muli utilizatori (de exemplu, dou
case de marcat) dect cu dezavantaje majore (necesitatea unui al treilea sistem
care s agrege datele generate de cele dou sisteme n mod oine sau lucrul n
regim exclusiv: atunci cnd un utilizatorul utilizeaz sistemul cel de-al doilea
este pus n ateptare.

14

3.3.2 RDBMS
Bazele de date ofer un mod de acces la date simplicat, conform unor reguli
descrise de programatorii aplicaiei precum i metode de introducere i modicare. Bazele de date sunt o urmare logic a informatizrii diferitelor aspecte din
toate domeniile, istoria lor oferind o serie de pai tot mai mari, de la cabinetele
de are.
Bazele de date relaionale sunt o subgrup a bazelor de date, care prevd un
set de reguli descrise de Edgar Codd. n esen, ele sunt simple tabele ntre care
pot exista diferite legturi. Sistemele de gestiune ale bazelor de date relaionale
nu sunt un concept nou. Apar din 1974, din eforturile IBM depuse pentru
System R, primul prototip RDBMS. Aceste pachete soware au ajuns deosebit
de complexe i cu performane ridicate, tehnologiile aferente ind un subiect
dezbtut att n cercurile academice ct i n grupurile de cercetare private - o
serie de subiecte sunt utilizarea modelelor i obiectelor, conceptul de tranzacii
atomice (un grup de tranzacii e are succes integral la introducere e toate
tranzaciile eueaz), tehnici de control pentru accesul concurent, modicarea
limbajului de interogare, mbuntiri referitoare la tehnicile de stocare sub RAID
(acces paralel la uniti de disc).
Sistemele RDBMS se pot clasica n
Stocare n memorie cu backup pe discuri, pentru acces mult mai rapid
(spre exemplu, SAP HANA).
Orientat pe eveniment care ofer suport programatic pentru declanarea
anumitor condiii n date sau relaii: introducerea unui rnd, scderea
totalului de coloane n tabela extern sub un numar dat, etc. Sunt
cunoscute cu denumirea de triggers
Fermele de date i bazele de date de tip cloud exist n alt locaie, de
obicei subcontractat de la o companie care se ocup doar de baze de date,
i uneori pot paratajate i cu ali clieni pentru data mining sau marketing
Bazele de date distribuite sunt stocate pe mai multe sisteme de calcul
Bazele de date integrate (embedded) fac parte comun cu aplicaia, r a
necesar un pachet soware daemon, ind distribuite de obicei ca biblioteci
statice - spre exemplu sqlite3.
textbf Bazele de baze de date sau bazele de date federate constau n sisteme
RDBMS distincte integrate transparent de un sistem central, numit sistem
de management federat (FDBMS)

15

Pe lng bazele de date relaionale, exist diverse categorii de baze de date

care nu implic folosirea modelului relaional descris de Edgar Codd, spre
exemplu:
Bazele de date de tip graf
Bazele de date paralele n care o parte a resurselor hardware sunt partajate
Bazele de date probabilistice folosesc logica fuzzy pentru a rspunde
interogrilor
Bazele de date de timp real proceseaz tranzaciile sucient de rapid nct
s ofere un rezultat aproape instantanee, dar nu garanteaz corectitudinea
datelor. Acestea sunt un subiect de cercetare actual, exist prototipuri
dezvoltate n cadrul universittii Toronto, precum i unele open source
(MayBMS, Orion, Trio, BayesStore).
Bazele de date temporale ofer similariti cu sistemele de versionare a
ierelor, oferind informaii istorice despre datele introduse
Bazele de date multidimensionale ofer concepte de tabele mai complexe
dect cele clasice (utilizate, spre exemplu, n stocarea informaiilor pe un
dispoztiv GPS i execuia de interogri de genul Unde se a cea mai
apropiat pomp de benzin spre care pot naviga pe strzi?)
Bazele de date nestructurate ofer un mod de a stoca date arbitrare care nu
se ncadreaz n mod armonios n bazele de date comune - de exemplu
agregarea de mesaje email, conferine i mesaje electronice din diverse
platforme de chat, stocare media, etc
3.3.3 Proiectarea i modelarea RDBMS
sunt o parte integrat a uxului de exploatare a acestor sisteme i n general,
un domeniu de studiu n sine. Scopul dorit este conceptualizarea unui sistem
corespunztor cu anumite reguli n care datele ce urmeaz a stocate se
ncadreaz i optimizarea operaiilor de scriere i citire pentru diverse cazuri acces simultan, vitez, integritate.
Procesul tipic de proiectare const n determinarea relaiilor ntre diferite
elemente i suprapunerii unei structuri logice pe aceste relaii.

16

Normalizarea este un mod sistematic prin care proiectantul bazei de date se

asigur c structura obinut este potrivit pentru interogri generale i nu exist
caracteristici nedorite - cele trei operaii de inserare, modicare i tergere nu
produc anomalii - care pot duce la pierderea integrittii datelor. n general este
preferat ca ntreaga baz de date s e proiectat normalizat, iar n funcie de
performanele dorite, s se parcurg la denormalizarea selectiv.
Normalizarea poate descris n termeni simpli ca orice date care se repet
vor deveni tabele independente. n prima form normal putem considera datele
referitoare la coduri CAEN: dac pentru ecare furnizor i client business se
va completa, alturi de codul CAEN i descrierea acestuia, se poate ajunge
la inconsistente - acelai cod s aiba descrieri diferite datorit, spre exemplu,
unei erori de introducere de ctre operator. Modicarea bazei de date pentru
a corespunde cu prima form normal implic crearea unui tabel suplimentar
cu coduri CAEN i referirea doar cu codul n tabelele clienilor i furnizorilor.
n aplicaie, cnd se dorete vizualizarea unui client, aplicaia va efectua
operaiunea de intersecie (JOIN) ntre client i codurile CAEN i va aa
utilizatorului doar descrierea codului CAEN.
Urmtoarele forme normale impun restricii succesive de mprire a relaiilor dintre tabele, ns ultima form care este necesar n producie este de obicei
a treia. Forme suplimentare, precum Boyce-Codd, a patra form normal (4NF)
sau 5NF exist, ns au mai mult aplicaii teoretice.
n general, formele normale nu sunt reguli stricte de urmat n proiectarea
bazelor de date, ci doar indicaii ntruct pot exista cazuri specice n care
normalizarea ar duce la complexitate ridicat din partea pachetului soware
dezvoltat, sau chiar pierderi de performan.
3.3.4 Produse soware RDBMS
Exist o varietate foarte mare de produse RDBMS, att comerciale, ct si opensource. Cu excepia MSSQL, urmtoarele RDBMS pot funciona nativ att pe
Windows, ct i pe diferite distribuii Linux: PostgreSQL, MySQL, DB2, MariaDB,
Oracle - suportul pentru BSD ind ns mai restrns. Toate sistemele enumerate
se supun propriettilor ACID (atomicitate, consistent, izolare, durabilitate - care
implic caracteristicile enumerate asupra tranzaciilor individuale), diferenele
majore ntre ele ind mai mult de performan n cazuri speciale, limite maxime
asupra tipurilor de date i diferite tipuri de indexuri, unde PostgreSQL ofer
cea mai mare varietate: indexarea dup funcii hash, dup expresii, suport
pentru indeci compui adresai pariali, procesarea n sens invers a indecilor,
procesarea coloanelor boolene dup operaii logice pe hri de bii (bitmap) i
indeci spaiali.
Agnosticitatea fa de RDBMS este o problem recent, ind cauzat de
17

faptul c ecare dezvoltator a urmrit introducerea unor funcii competitive prin

specicarea de cuvinte-cheie noi; pentru a nu-i pierde avantajul competitiv,
ceilali dezvoltatori au urmrit s introduc funcii similare, dar din diferite
motive, e juridice, e pentru a clientul s rmn del productorului, au ales
s foloseasc un alt cuvnt-cheie pentru funcii similare sau identice.
Specicaia SQL (ISO/IEC 9075) care determin un set de reguli pentru
limbajul de interogare (i ca urmare a abaterii de la acestea, productorii RDBMS
au realizat produse ne-agnostice), descrie i conceptul de SQL schema: un
spaiu de denumiri unice (namespace) n cadrul unei baze de date individuale,
elementele din acest spaiu ind adresate cu .. Spre exemplu, o interogare
calicat integral (prin baz de date, schem i tabel) poate urmtoarea:
1

SELECT * FROM baza_de_date . schema . tabel

Problema apare cnd se scriu interogri de urmtorul tip:

1
2

SELECT * FROM baza_de_date1 . tabel

SELECT * FROM dezvoltare . tabel

comparativ cu:
1
2

SELECT * FROM baza_de_date2 . tabel

SELECT * FROM productie . tabel

n acest caz se ridic ntrebarea: la ce se refer termenii de producie

respectiv dezvoltare - scheme sau baze de date? O alt problem: ce se ntmpl
dac avem mai multe scheme cu tabele identice?
Diveri productori au urmat diferite abordri: MySQL se comport la
fel (dar transparent) cu CREATE SCHEMA i CREATE DATABASE, implementnd
ntr-un mod simplu funcionalitatea de inter-corelare: eliminarea complet a
schemelor. PostgreSQL implementeaz scheme reale, conform standardului,
oferind chiar funcionaliti de inter-corelare ntre baze de date. Oracle ofer
o alt abordare, n care un utilizator este identic cu o schem, iar accesarea
schemelor intercorelate se face n funcie de relaiile stabilite de administratorul
de baze de date ntre utilizatori.
Ca urmare a faptului c tehnologia RDBMS confer diferene foarte mici ntre
diferite produse, precum i a faptului c produsul soware pe care urmeaz
s-l dezvoltm este un exemplu tipic de utilizare RDBMS, ind n principiu
agnostic3 . Din acest motiv, vom urmri chiar s implementm n decursul
realizrii pachetului soware a unui nivel de abstractizare, care ne va permite
s schimbm infrastructura RDBMS accesat din mers, n funcie de specicul
clientului i operaiunile pe care acesta le va desura (evident, cu migrarea
datelor dintr-un sistem n cellalt).
3

Termenul de database-agnostic se refer la faptul c un produs soware poate funciona cu

mai multe tipuri de RDBMS, interogrile ctre cel ales ind cute de aa natur nct nu folosesc
funcii exclusive doar acelui sistem

18

3.3.5 Concepte NoSQL

NoSQL, cunoscut i ca Not Only SQL este un DBMS pentru stocare i
interogare a datelor implementat diferit de relaiile directe, utilizate n bazele
de date relaionale. Aceste sisteme au fost create ca urmare a necesarului
stocrii datelor care nu pot n mod direct relaionale, simplitii de proiectare,
creterii orizontale a puterii de calcul i control mai precis asupra disponibilitii.
Structura de date intrinsec este diferit de RDBMS - graf, perechi cheie-valoare
sau document.
Soluiile NoSQL sunt utilizate preponderent n sisteme big data i aplicaii
web n timp real. Denumirea lor sugereaz faptul c se poate folosi att limbajul
SQL, ct i o metod paralel de acces la date. Conform teoriei CAP, care va
descris ulterior, aceste tipuri de DBMS prefer disponibilitatea i rezistena
la partiionare n detrimentul consistenei datelor. Din acest motiv, majoritatea
DBMS nu sunt concordante cu specicaiile tranzaciilor de tip ACID (dei exist
unele sisteme recent proiectate, precum FoundationDB, care urmresc tocmai
acest lucru).
Exist mai multe abordri n utilizarea acestor DBMS, ecare cu diverse
categorii. Datorit tocmai acestei varieti precum i a suprapunerilor pariale
ntre sisteme, este dicil s denim o partiionare clare ntre ele, exemplul cel
mai comun de categorii nd cel bazat pe modelul de date cu care se lucreaz:
Organizarea pe coloane
Bazele de date de tip document
Perechi cheie-valoare (KV)
Bazele de date graf
Organizarea pe coloane folosete un tuplet compus dintr-un nume unic al
coloanei, o cheie, o valoare i o descriere a datei la care tupletul respectiv a fost
introdus, pentru a putea urmri expirarea datelor. Conform teoremei CAP, bazele
de date distribuite nu pot garanta consistena, ntruct disponibilitatea este mai
important. Unele sisteme mai complexe, precum Apache Cassandra, folosesc
un ceas vectorial pentru a determina tupleii nvechii (un ceas vectorial este un
mecanism de ordonare parial a evenimentelor ntr-un sistem distribuit, care
poate determina nclcarea regulilor de cauzalitate).
Stocarea n document este o metod familiar multor utilizatori; ind cunoscut ca baz de date semistructurat este unul dintre cele mai abordate forme
de NoSQL, ind uneori chiar sinonim cu acest termen. n esen, ecare rnd
19

poate vizualizat ca un document zic, pe care pot scrise date arbitrare (numele coloanelor, subtabele sau valori pentru coloane). Spre exemplu, n problema
anterioar a ierelor plane, se creaz cte un document pe furnizor, o coloan
n ecare document numit Telefon care va conine perechi de tipul: Telefon
primar - pentru toi furnizorii, Telefon pentru comand produs x - pentru al
doilea furnizor i Telefon suport tehnic pentru al treilea furnizor.
Problema datelor parial suprapuse este acum rezolvat mult mai elegant,
ntruct aceste numere de telefon au elemente n comun (modul de utilizare),
dar au i date asociate (cnd este necesar apelarea lor) care nu pot stocate
ntr-o structur ca un ier simplu. Orice sistem DBMS pe baz de document
are un limbaj de interogare care descrie un view, anume un mod de acces la
date. Spre exemplu, n unele sisteme pe baz de document, putem crea un view
pentru aarea telefoanelor unui furnizor, dar i unul pentru aarea agendei
telefonice a companiei. Nu va exista diferen n implementare: aceluiai view
i va solicitat s emit coloana cu telefoane pentru un furnizor dat, sau pentru
toi furnizorii.
Unele implementri, precum CouchDB ofer funcii de partiionare sau
replicare att n regim Master-Slave ct i n regim Master-Master[1]. Aici se
nate o problem interesant, specic nu doar acestui pachet, ci a oricrui
DBMS care favorizeaz partiionarea n detrimentul integritii: ce se ntmpl
dac, prin absurd, doi utilizatori conectai la servere diferite (dar temporar
necorelate), vor modica n acelai moment aceleai date? Problema nu este
deosebit de comun, ntruct, n general ambele servere vor asocia datelor
momentul modicrii (iar un sistem de tip NoSQL n general pstreaz i
informaia istoric), iar ansa ca ambii utilizatori s introduc datele n acelai
moment, pentru rezoluii de milisecund este de 1/100 (dac considerm c cei
doi utilizatori se coordoneaz i au un timp de reacie de 10ms, ambele cazuri
destul de improbabile); pentru a preveni ns acest gen de probleme pentru
datele generate automat, sistemele de tip NoSQL confer mereu i o modalitate
de arbitraj care informeaz aplicaia asupra conictelor i i permit s declare o
singur intrare ca ind cea mai recent.
DBMS cu perei KV sunt un concept deosebit de simplu: un server stocheaz
diferite de date prin introducerea lor - la introducerea oricreia i se aloc un
index, adresarea acestora cndu-se prin furnizarea cheii obinute anterior, de
obicei dat de o funcie hash sau a unei valori unice, aleatoare. Aplicaia care
folosete sistemul decide care este modul de utilizare al acestor valori.
ntruct majoritatea relaiilor, cnd sunt necesare, sunt implementate n
aplicaie, se pot genera sute de interogri, ns DBMS pe baz de cheie i valoare
(numite n continuare KV din eng., key-value store) rspund la acestea mult mai
20

rapid dect ar dura o operaiune de tipul scanare integral tabel ntr-un RDBMS.
Acest sistem este avantajos pentru structuri ierarhice: execuia operaiunii fulltable scan i returnarea datelor, pentru construirea unui arbore devine imposibil
dup stocarea unui anumit volum de date pe RDBMS, astfel nct este necesar
parcurgerea ntregii structuri prin interogri repetate. ntruct DBMS KV sunt
adesea stocate complet n memorie, accesul la date este mult mai rapid pentru
un set similar de date, comparativ cu RDBMS.
Sistemele DBMS KV exceleaz la partiionare orizontal: cnd un sistem
ncepe s e utilizat la maxim, un al doilea poate congurat s preia jumtate
din interogri prin partiionarea datelor, dup cheie, pe jumtate: spre exemplu,
cheile cu prex ntre 0 i 7 vor preluate de sistemul vechi, iar cele ntre 8 i 15
de al doilea server (considernd c toate cheile sunt notate, spre exemplu cu 32
de simboluri hexazecimale) Partiionarea de acest tip este de obicei folosit cnd
este vorba de sute de milioane de intrri, dar avantajul este acum evident: cnd
returnarea sau introducerea datelor este lent, datele sunt din nou repartiionate.
DBMS de tip graf stocheaz date mpreun cu relaiile pe care le descriu.
Datele sunt de obicei noduri, ntr-o form similar cu documentele: spre exemplu
furnizorii, angajaii i clienii. Exploatarea implic construcia de legturi ntre
acetia i descrierea acestor legturi, spre exemplu data i casierul care a efectuat
o vnzare, precum i realizarea de observaii i deducerea unor relaii indirecte,
spre exemplu, numrul de produse reclamate defecte de ctre clientul x n funcie
de numrul de achiziii de submodule folosite n acel produs cumprate de la
furnizorul y.
3.3.6

Teorema CAP

Teorema CAP, a fost emis n 2000 ca o conjectur, la Berkely, de ctre Eric

Brewer. n 2002 a fost dovedit formal de ctre Nancy Lynch i Seth Gilbert
de la MIT, armndu-i astfel statutul de teorem.
Teorema este prezentat sub forma unui triunghi a trei proprieti: Consistena datelor (C), Disponibilitatea datelor (Availability) i Partiionarea datelor
(P), din care doar dou pot active la un moment dat, n detrimentul celeilalte.
Conceptul de NoSQL sacric integritatea datelor - anume integritatea, n
favoarea partiionrii (exemplul anterior, cu doi utilizatori modicnd sincron
aceleai date) [1].
ns chiar autorul menioneaz ntr-un articol mai recent din 2012[2], faptul
c perspectiva 2 din 3 este neltoare ntruct un sistem NoSQL poate lua
decizii cu granularitate mult mai n ntre C i A, n funcie de operaia executat,
datele sau utilizatorul care le soliit. Disponibilitatea devine dintr-un concept
binar un continuu de la 0% la 100%, existnd ns i nivele suplimentare de
21

integritate - spre exemplu integritatea parial ntre partiii, precum i schemele

de rezvolvare ale conictelor - anume, care dintre cele dou (sau mai multe)
partiii deine datele cele mai noi care trebuiesc propagate, precum i chiar asupra
partiiilor, privind lipsa unei decizii universale (n cadrul unui sistem distribuit)
asupra prezenei unei partiii.
Acelai articol menioneaz ns c, datorit faptului c partiiile sunt rare, nu
este adesea necesar ca s e sacricate integritatea sau disponibilitatea. Aa cum
s-a menionat, majoritatea sistemelor NoSQL nu ofer conformitate cu normele
ACID - exemplul anterior ind considerat o eroare, i trebuind tratat ca dou
tranzacii diferite, dar ofer n schimb un concept foarte apropiat de integritate
eventual - refacerea conexiunii din exemplul anterior i sincronizarea datelor
ntre cele dou servere determin ridicarea unui eveniment de tip conict,
invocarea codului specic pentru tratarea acestui conict (dac ambii utilizatori
au modicat un numr de telefon, este posibil ca acesta s fost modicat
de ctre furnizor, iar utilizatorii s aduc la zi agenda telefonic a companiei,
posibilitatea ca amndoi s introduc acelai numr de telefon este mare - dar
unul dintre ei poate s cut o greeal prin adugarea unui spaiu suplimentar
sau introducerea de linue n numrul de telefon n acest caz, codul de tratare
al conictului poate compara cele dou numere de telefon dup eliminarea
cratimelor i spaiilor i decide rezolvarea automat a conictului. Acesta este
ns un caz particular, dar un exemplu mult mai probabil ntlnit n practic, dar
exist i cazuri n care poate necesar intervenia manual asupra conictelor.)
3.3.7 ORM-ul i Consideraii nale
Alegerea unui DBMS n aceast faz este unu pas decisiv n analiza sistemului
ARHA/SM, n special datorit posibilitilor foarte largi oferite de sisteme NoSQL
i diferenele de implementare. S-a hotrt alegerea unui sistem de tip RDBMS,
datorit agnosticismului fa de implementare, comparativ cu dependabilitatea
ridicat a aplicaiei fa de DBMS n cazul sistemelor NoSQL, precum i datorit
faptul c pe parcursul dezvoltrii acestui proiect, este posibil angajarea de
ingineri soware; familiaritatea cu sistemele RDBMS comparativ cu cele NoSQL
este nc mult mai rspndit
Alegerea unei platforme specice RDBMS specice nu i rostul, dar menionm
necesitatea utilizrii unui nivel de abstractizare peste date sau chiar a unui
modul soware superior acestui sistem de abstractizare, anume un produs de
tip Object-Relational Mapper. ORM-ul rezolv diferite probleme specice pachetelor RDBMS, i permite interschimbarea liber a acestora, mai mult, permite
i o abordare programatic simpl - se scriu clase generice care descriu cum sunt
interogate bazele de date i care este legtura rezultatului obinut cu variabilele
membru ale unui obiect, astfel, prin interogarea - spre exemplu - a tabelei de
22

clieni i mpreun cu aceasta, a tabelei de vnzri ctre un client (pe cheia unui
client anume), se obine o referin ctre un obiect de tip Client pe care ni-l putem
imagina cu variabilele-membru de tip: String nume; Date data_nasterii;
Integer suma_facturi, de unde primele dou variabile vor extrase din prima
tabel i coloanele cu acelai nume, iar cea de-a treia variabil va o funcie
agregat de tip SELECT SUM(total_factura) FROM facturi WHERE cumparator=17.
Exemple de sisteme de mapare ctre RDBMS sau ORM sunt, n funcie de
limbajul de programare, alese doar pentru faptul c suport RDBMSurile alese
(MySQL, PostgresQL, Oracle, IBM DB2, MSSQL)
C++: WtDBO, QxOrm, LitesQL
Java: Foarte numeroase, ntruct Java are drivere native pentru foarte
multe RDBMS: CAyenne, Hibernate, Ibatis, JDO, JOOQ
.NET: iBatis, NHibernate, Persistor.NET, SubSonic
PHP: CakePHP, CodeIgniter (acestea dou oferind funcii i de MVC, ind
mai degrab un cadru de dezvoltare rapid al aplicaiilor comparativ cu un
ORM, dar putnd folosite exclusiv ca ORM), PHPixie, Torpor, Zend, PDO
Python: Django, sQLObject, web2py

3.4

Limbajul de programare

3.4.1 Tehnologii server-side

n ziua de astzi, exist o multitudine de limbaje de programare cu scopuri att
de diverse, nct alegerea unuia care s satisfac un set de cerine poate deveni n
sine o problem. n cutarea unui limbaj de programare, mpreun cu platforma
sa aferent (main virtual, sistem de operare, biblioteci co-dependente) vom
urmri un numr de factori:
Limbajul s e optimizat pentru web i s prezinte o variete de funcii
specice
Limbajul s poat funciona ca modul al unui daemon hp, i nu prin
interpretarea ierelor de ctre o arhitectur de tip CGI (din considerente
de performan)
Limbajul s e uor de folosit, s existe suport pentru un numr ct mai
vast de operaii n mod nativ prin biblioteci sau module interne (grac,
rapoarte, compresie, statistice i economice, preferabil i ORM).
23

 Limbajul s funcioneze pe infrastructura aleas, preferabil dezvoltatorii

limbajului s recomande i ei infrastructura ca preferenial
Limbajul s e cunoscut de un numr ct mai mare de dezvoltatori
Pentru rezolvarea acestei probleme se vor considera Java, PHP, Python i
.NET.
Not: conform seciunii de infrastructur grupul de limbaje i maina virtual
.NET nu funcioneaz sub distribuii Linux, ind distribuit exclusiv pentru
Windows. Dei exist un proiect care urmrete portarea claselor i a API-ului
de .NET pentru Linux i web, anume Mono preferm ns evitarea .NET, nu
n ultimul rnd datorit daemonului web cu care lucreaz - IIS - i a reputaiei
limitate a acestuia.
Conform unui studiu recent4 , din site-urile majore, 6 folosesc PHP, 2 folosesc
Python, 6 folosesc Java, 2 folosesc ASP.NET, 4 folosesc Python iar n mod
surprinztor, exist i tehnologii web implementate n C++, folosite de 3 servicii
web majore. Totalul siteurilor studiate este de 12, ind mai mic dect suma
tehnologiilor utilizate, ntruct unele servicii folosesc mai multe tehnologii
simultan. Tragem urmtoarele concluzii:
Limbajul preferat pentru servere web este Java, probabil din cauza vechimii
i a numrului mare de ingineri soware care au fost educai n acesta
Urmtoarele limbaje, la paritate sunt PHP i Python
C++ este n mod surprinztor utilizat n web. Menionm ns c acesta
nu este folosit n mod direct, ci printr-un precompilator intermediar, din
PHP (HipHop for PHP, dezvoltat de Facebook) care transform codul PHP
n cod C++, dezvoltatorii avnd foarte rar contact cu acesta - cu unele
pierderi, precum funciile de reecie i execuia variabilelor ca cod surs,
n contextul funciei curente.
ASP.NET este folosit doar de dou site-uri, ambele aparinnd dezvoltatorului acestui limbaj
Conform indexului TIOBE, realizat privat de compania Tiobe, care urmrete
trendurile n popularitatea limbajelor de programare, concluziile trase corespund
rezultatelor din ultimii ani, cu excepia c Java rmne n urma limbajelor PHP
i Python.
4

hp://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites

24

Java: Limbajul Java este un limbaj matur, concurent, orientate pe obiecte,

proiectat s aib ct mai puine dependine i cunoscut ca primul limbaj larg
folosit care funcioneaz pe o diversitate de platforme. Disciplina de tipologie a
variabilelor este de tip static (variabilele trebuiesc s treac prin casting explicit
de la un tip la altul), sigur, nu folosete pointeri. Problema polimorsmului este
rezolvat prin eliminarea polimorsmului cu totul.
Java are a trei siteuri de joburi studiate, cea mai mare baz de programatori
experi. Acest lucru se poate datora faptului c Java are aproape 20 de ani
de existen, este folosit n foarte multe platforme business (Enterprise class
soware), exist numeroase comuniti care ofer biblioteci pentru aplicaii ct
mai diverse precum i datorit faptului c iniial, Java a fost singurul limbaj de
programare universal ca suport pe arhitecturi diferite.
PHP a nceput ca un proiect personal al lui Rasmus Lerdorf. Este un limbaj care
i-a nceput dezvoltarea efectiv dn 1997, are disciplina de tipologie dinamic
(dou stringuri care conin numere, adunate, vor oferi rezultatul matematic ca
un alt string) i nu folosete n mod explicit pointeri, dar permite existena
referinelor n semnturi.
PHP este urmtorul limbaj ca numr de programatori disponibili, ns cu
o vechime i experien n limbaj mai redus dect java. PHP este un limbaj
orientat exclusiv pentru web, care ofer suport extins pentru interpretarea de
cmpuri, citirea variabilelor de browser, cookies, funcii de internaionalizare,
securitatea datelor specic web-ului. Versiunea 5 i-a adus suport deplin pentru
progamarea orientat pe obiecte.
Are numeroase biblioteci care l fac n mod special atractiv pentru ARHA/SM,
printre care: GD i ImageMagik pentru prelucrare grac, suport pentru operaii
economice i statistice i un strat de abstractizare cu RDBMS, anume PDO (PHP
Data Objects). [3]
Python este un limbaj orientat-obiect, funcional i reectiv, cu disciplin de
tipologie dinamic. Este folosit att ca limbaj de scripting n cadrul proiectelor
mai mari ct si ca limbaj de sine stttor. Are cteva caracteristici deosebit
de interesante, precum un mod special de adresare a vectorilor, indentarea i
denirea blocurilor de cod omite acoladele (caracteristice celor dou limbaje
anterioare) n favoarea indentrii forate prin taburi sau spaii: contextul unei
instruciuni este dat de indentare (este considerat un avantaj pentru uurina
altor programatori de a nelege cod existent).
Python este un limbaj matur, folosit de instituii de cercetare precum CERN
i NASA i are un numr foarte mare de biblioteci. Python este n primul rnd un
limbaj interpretat, n jurul cruia s-au construit biblioteci pentru funcionalitatea
25

web: Django, Pylons, web2py.

Din punct de vedere al disponibilitii minii de lucru, python este cel mai
slab reprezentat n Romnia.
Concluzii Din experiena personal, pentru proiecte medii cum este ARHA/SM,
limbajul cel mai potrivit este PHP. Familiaritatea cu toate trei mi permite s
enumr urmtoarele aspecte:
Dei Java ar prea cel mai accesibil din punctul de vedere al minii de lucru,
proiectele dezvoltate n Java pot cpta rapid aspectul de cod dezordonat,
mai ales pe msur ce numrul de oameni implicai n dezvoltarea acestuia
crete.
Dei Java are cele mai multe platforme pentru web, precum servleii i JSP,
Spring, JavaServer Faces, Tapestry, Struts, nici una dintre acestea nu sunt
uor de utilizat pentru proiecte de aceast natur, i adesea nici nu au rostul
- depanarea este greoaie, view-urile din contextul MVC sunt programate
doar cu limbaje de descriere care necesit compilri suplimentare la orice
modicare.
Python pare ideal, ns baza mic de programatori cunosctori att ai
limbajului ct i, mai important, ai platformelor web, l fac neatractiv pe
termen lung
Soluia care rmne de compromis este PHP: Codul rezultat poate mai
ordonat dect cel de Java, este sucient de rspndit n Romnia, ind,
pentru muli, primul limbaj nvat chiar nainte de contactul cu mediul
academic
Din punct de vedere al portabilitii toate cele trei limbaje funcioneaz
att pe Windows ct i pe Linux, dar interpretorul (maina virtual)
pentru Java a captat doar recent statutul de soware deschis, ind
implementate numeroase maini virtuale de diferite comuniti nainte de
acest eveniment. Dei a existat maina virtual pentru Java oferit de
productor pentru Linux, se prefer de multe ori utilizarea doar de soware
open-source pe aceste sisteme. Argumentul era adesea legat de faptul c un
bug pe un sistem nchis i cut public va exploatat mult mai repede dect
va putea productorul s completeze un ux de activiti pentru corectarea
acestuia, pe cnd o comunitate open-source, neind supus acestor aspecte
de management, l-ar putea xa mult mai repede.

26

3.4.2 Tehnologii client-side

Conceptul clasic de tehnologie web a fost ca ecare funcie independent a unui
produs soware s e implementat ca o pagin web, care va prelucrat de
ctre server i transmis clientului cu ecare cerere a sa. Spre exemplu, dac
perspectiva curent cere integrarea datelor din mai multe tabele i execuia de
diferite calcule pe acestea, serverul le va executa pentru ecare solicitare a paginii
respective. Se pot ajunge la situaii n care clientul cere n mod exagerat date de
la server, suprasolicitndu-l i blocnd accesul altor utilizatori.
Tehnologiilor de descriere a paginilor, precum XHTML i CSS, li se altur
un limbaj client-side, cunoscut ca JavaScript i DOM. Acesta permite accesul
la diferite elemente descrise de ctre pagin, precum butoane, diviziuni grace,
legturi i modicarea proprietilor acestora n scopuri ct se poate de diverse
- de la realizarea de animaii i mbuntirea interfeei cu utilizatorul pn la
preluarea parial a sarcinilor de pe server.
Pe baza tehnologiei JavaScript a fost dezvoltat o tehnic cunoscut ca AJAX,
care a aprut n 2002. Ajax nu este o tehnologie n sine ci mai mult o mbinare
neateptat ntre tehnologiile deja existente: Javascript i daemonii web. Aceast
tehnologie simplic interaciunea ntre aplicaia client i server: o parte din
cererile clientului sunt trimise direct ctre server, iar acesta rspunde doar cu
datele relevante, acest lucru este efectuat direct din pagin, sub Javascript; codul
de Javascript fa efectua apoi modicrile necesare n pagin pentru a aa noile
date obinute. Iniial a folosit o structur de iere numit XML, care permite
crearea ierarhiilor de orice tip, dar trendul actual este spre tehnologia JSON, care
este interschimbabil din punct de vedere al reprezentrii coninutului cu XML,
dar este mult mai compact ca notaie, i poate citit i scris manual mult mai
uor. O alt variant de utilizare a AJAX este transmisia i recepia de fragmente
HTML direct de la server, care apoi sunt inserate n pagin r a prelucrate.
Tehnologia AJAX ofer dou avantaje care fac sistemul de corelare ntre
pagini i funcii nvechit: mult mai puine date redundante sunt transmise,
precum limbajul de demarcare HTML i elementele repetitive care apar n cadrul
navigrii ntre pagini i doar datele pe care utilizatorul le dorete la un moment
dat sunt solicitate, reducnd astfel solicitarea serverului.
AngularJS este un modul de aplicaii web, client-side, dezvolat i meninut
de Google, care are ca scop reducerea suplimentar a paginilor web, crend
ceea ce este cunoscut ca aplicaii web cu o singur pagin. Acestea necesit
doar (X)HTML, CSS i JavaScript pentru a funciona, dar contrar cu ceea ce
sugereaz numele, ele pot mai adesea mult mai complexe dect aplicaiile multipagin. Dezvoltarea proiectul a urmrit n principiu: decuplarea funciilor de
acces DOM de ctre logica aplicaiei, care poate mbuntii gradul de testare al
codului, decuplarea server-client care permite lucrul simultan la cele dou pri
27

ale produsului i utilizarea deosebit de simpl.

O tehnologie n plin evoluie, care merit menionat este Node.js. Plecnd
de la uurina n a scrie cod JavaScript, s-a realizat o platform scalabil pentru
aplicaii server-side scalabile. Este o tehnologie dirijat de evenimente, foarte
similar cu Javascript i care implementeaz propriul server web. Poate adesea
utilizat ca middleware, spre exemplu pentru a oferi ntr-un sistem de tranziie
r AngularJS un mod de a rspunde mult mai rapid interogrilor AJAX. Aceasta
poate folosit i pentru dezvoltarea aplicaiilor integrale, ns, datorit vrstei
destul de mici a, nu are nc un numr sucient de mare de cunosctori.

3.5

Infrastructura

Infrastructura utilizat n mod curent pentru aplicaii web distribuite i care au

acces intens la date este n general o stiv LAMP: Linux, Apache, PHP, MySQL.
Preferina utilizrii sistemelor de operare din clasa Linux n mediul enterprise
este motivat de mai multe aspecte:
Instalare i administrare facil - comparativ cu sistemul Windows, pachete
ntregi pot instalate prin execuia unor simple comenzi, dup care sunt
gata de a intra n producie
Suport deosebit de bun pentru virtualizare i paravirtualizare automat - n
cazul n care va necesar scalarea pe orizontal, este necesar ca aceasta
s se fac automat: clonarea mainii care ruleaz baza de date sau aplicaia
s poat cut automat, n funcie de gradul de ncrcare al serverului,
pornit i deploy-at pe un server liber. Suport este oferit prin interfaa
API pentru Xen: XCS i XAPI.
Drivere recunoscute pentru gruparea discurilor magnetice n ansamble
RAID. Un ansamblu RAID permite scrierea e n paralel, dar segmentat
(RAID0) e n paralel, dar identic (RAID1) a unui sector de date, pentru
a mbunti semnicativ viteza de scriere i citire, precum i protecia la
defectarea unuia dintre acestea. Arhitecturi hibride de tipul RAID1+0 sunt
posibile.
Codul surs ale pachetelor soware utilizate sunt publice - pachetele web
precum Apache, dar i limbajul de programare PHP sau bazele date MySQL, PostgreSQL, CouchDB ofer, prin intermediul distribuiei acces la
ierele surs i permit compilarea acestora integral; este avantajos pentru
c un bug x critic ale acestora poate veni mult mai repede din partea
comunitii de dezvoltatori (sau poate efectuat chiar n regie proprie),
comaprativ cu un produs comercial sau cu surs nchis.
28

 Managerii distribuiei Linux folosite se asigur c instalarea mai multor

pachete nu genereaz incompatibiliti, precum binecunoscutul DLL Hell
din Windows, n care programae diferite care utilizeaz biblioteci dinamice
de versiuni diferite nu pot coexista.

29

Anexe

30

Bibliograe
[1] J. Chris Anderson, Jan Lehnardt, Noah Slater, CouchDB: e Denitive Guide.
OReilly Media, ianuarie 2010, ISBN: 978-0-596-15589-6
[2] Eric Brewer, CAP Twelver Years Later: How the Rules Have Changed.
hp://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-havechanged, original n publicaia Computing Now (www.computer.org), 30
mai 2012
[3] Kevin Tatroe, Peter MacIntyre, Rasmus Lerdorf, Programming PHP. OReilly
Media, martie 2002. ISBN: 978-1-56592-610-3
Pe coperta patru este ataat o anex care reprezint multitudinea de tabele i
relaiile dintre acestea utilizate n proiectarea ARHA/SM.
Cheile externe cele mai des folosite sunt
id_client - cheie extern cu tabelul clienti care descrie un rnd aferent
din acesta
id_furnizor - cheie extern cu tabelul furnizori care descrie un rnd
aferent din acesta
id_anjagat - cheie extern cu tabelul angajat care descrie un rnd
aferent din acesta: angajatul care efectueaz o aciune - pontarea n
sistem, deplasarea cu un vehicul, propunerea unei tranzacii, modicri
de inventar
id_produs - cheie utilizat spre tabelul produse care descrie produsul
respectiv
id_factura - cheie spre tabelul facturi, care desemneaz detaliile
generale ale unei facturi
n continuare, prezentm i o scurt explicaie asupra unor tabele:
tranzactii - descrie tranzaciile care au fost propuse spre efectuare cu
bncile
banci - bncile cu care exist legturi contractuale, necesar pentru a
distribui tranzaciile
tranzactii_interne - descrie toate activitile nanciare care au avut
loc n companie, dar care nu necesit neaprat o rezolvare cu banca (spre
exemplu, vnzarea de produse sau achiziia de carburant)
31

 angajati
facturi
facturi_produse - o tabel normalizat ntre produse i facturi care
conine listele de produse facturate pe ecare factur individual, conform
cheilor externe
venituri - totalitatea intrrilor n bilan din diferite surse
utilizatori - elemente de securitate
pontaj - momentele cnd utilizatorii au folosit cardurile de access sau alte
sisteme de pontare
repere_gps - date din teren, trimise de pe vehiculele aate n deplasri
bunuri - bunurile din proprietatea companiei
istorie_bunuri - date istorice asupra bunurilor (spre exemplu, reparaii
efectuate asupra vehiculelor)
detalii_contact - informatii de contact despre diverse persoane de
interes

32