Abordari de Tip Data Warehousing Implementare in MS SQL Server 2005

Introducere
Cap 1. Concepte de baz privind depozitelor de date

1.1._Depozite de date-delimitri conceptuale
1.2._Data warehousing
1.3._Obiectivele Data Warehouse

Cap 2. Arhitectura depozitelor de date
2.1 Arhitectura simplificat a depozitelor de date
2.2 Arhitectura depozitelor de date pe trei niveluri
2.3 Tipuri de depozite de date

Cap 3. Proiectarea i realizarea depozitelor de date
3.1 Analiza economic pentru proiectarea unui depozit
3.2 Viziuni de proiectare a unui depozit de date
3.3 Procesul de proiectare a unui depozit de date
3.4 Depozite de date versus baze de date operaionale

Cap 4. Modele de date multidimensionale
4.1 De la tabele i foi de calcul la cubul de date
4.2 Stele, fulgi de zapad i constelaiile de fapte

Cap 5. Software folosit n Data Warehousing
5.1 Instrumente de extragere i transformare a datelor
5.2 Instrumente de accesare i utilizare a depozitului de date

Cap 6. Studiu de caz-implementare n SQL Server 2005
6.1 Clasificare
6.2 Funciunile unui CRM
6.3 Modelarea i proiectarea sistemului CRM Pro Manager
6.3.1 Modelarea fluxului de date
6.3.2 Modelarea datelor sistemului
6.4 Proiectarea ieirilor
6.5 Proiectarea intrrilor i a interfeei
6.6 Proiectarea bazei de date
6.7 Implementarea sistemului
6.8 Funciunea aplicaiei
6.9 Ieirile i rapoartele sistemului
6.10 Sistemul de asisten

Cap 7. Concluzii i propuneri

Referine bibliografice

Anexe

3
3
4
6
7
7
9
10
11
11
11
12
13
16
16
18
21
21
22
24
26
30
30
30
33
40
42
46
47
50
53
55
56

Abordri de tip Data Warehousing-Implementare n Microsoft SQL Server 2005

2 | p a g i n a

INTRODUCERE

Conform unor studii recente, depozitele de date au devenit, la sfritul anilor
1990 una din cele mai importante dezvoltri din domeniul sistemelor informaionale.
Palo Alto Management Group previziona nc din 1998 c piaa data warehouse va
ajunge la 113.5 miliarde USD n 2002, incluznd aici vnzrile de sisteme data
warehouse, software adecvat i servicii. Industria data warehouse s-a dezvoltat
continuu n termeni de investiii, produse disponibile i proiecte elaborate. Se
apreciaz c aproximativ 90% din companiile multinaionale au implementate
depozite de date sau lucreaz la dezvoltarea unor proiecte data warehouse. Depozitele
de date sunt produsul mediului economic i al tehnologiilor avansate. Pe de o parte,
mediul economic este tot mai competitiv, global i complex i solicit informaii
elaborate pentru sprijinirea deciziilor strategice iar, pe de alt parte, evoluiile
tehnologiilor informaionale ofer soluii eficiente de gestionare a unor volume mari
de date integrate, de ordinul terabytes-ilor, asigurnd niveluri de sintez/detaliere
adecvate. Astfel evoluiile performante din hardware cum sunt sistemele de procesri
masive paralele (Massive Parallel Processing - MPP), sistemele de multiprocesare
simetric (symetric multi-processing-SPM), sistemele tip baze de date paralele fac
posibile ncrcarea, ntreinerea i accesul la baze de date de dimensiuni uriae.
Aplicaiile data warehouse sunt n msur s asigure i un timp mediu de rspuns
extrem de scurt pentru categorii extinse de utilizatori.

Depozitele de date (data warehouse) furnizeaz arhitecturi i instrumente utile
conducerii executive (business executives) prin organizarea sistematic, nelegerea i
utilizarea datelor n luarea deciziilor strategice. Un mare numr de organizaii
consider c sistemele data warehouse dispun de instrumente valoroase n mediul
economic de astzi, mediu competitiv i n rapid evoluie. n ultimii ani multe firme
au cheltuit milioane de dolari cu realizarea de depozite de date. Mult lume i d
seama c n condiiile competiiei sporite din fiecare industrie, depozitele de date sunt
armele care trebuie marketingului, reprezentnd calea de a pstra clienii. Primele
domenii care au adoptat tehnologia depozitelor de date au fost telecomunicaiile,
bncile i comerul cu amnuntul. Ulterior depozitele de date au ptruns i n alte
domenii cum ar fi industria farmaceutic, sistemul sanitar, asigurri, transporturi etc.
Studiile statistice arat c telecomunicaiile i sistemul bancar se menin n top
ntruct aloc cel puin 15% din bugetul IT pentru proiecte referitoare la depozite de
date. Un proiect data warehouse reprezint ns o investiie riscant i scump.
Costurile tipice pentru dezvoltarea unui depozit de date ntr-un interval de 3-6 luni se
situeaz ntre 0.8 i 2 milioane USD. Ponderea echipamentelor se situeaz ntre 1/2 i
2/3 din costul total al proiectului. O soluie pentru firmele mici i mijlocii este
recurgerea la data marts pentru care costurile se situeaz sub 100 000 USD ntr-un
interval adesea sub 90 de zile . Uneori investiiile n depozite de date nu se finalizeaz
cu succes. Motivaiile cele mai des ntlnite pentru eecul unor data warehouse includ
susinerea insuficient din partea conducerii organizaiei, insuficiena fondurilor i
politicile organizaionale defectuoase.

3 | p a g i n a

1. CONCEPTE DE BAZ PRIVIND DEPOZITELOR DE DATE

1.1. DEPOZITE DE DATE - DELIMITRI CONCEPTUALE

Depozitele de date (data warehouse) au fost definite n foarte multe moduri
nct este destul de dificil de formulat o definiie riguroas. n sens larg, un depozit de
date reprezint o baz de date care este ntreinut separat de bazele de date
operaionale ale organizaiei. Datele din sistemele surs sunt extrase, curite,
transformate i stocate n depozite specialen scopul sprijinirii proceselor decizionale.
Depozitele de date sprijin procesarea informaiilor furniznd o platform solid de
consolidare a datelor istorice pentru analiz. Un depozit de date este o sum de date
consistent din punct de vedere semantic care servete la o implementare fizic a unui
model de date pentru sprijinirea deciziei i stocheaz informaii pe care o organizaie
le solicit n luarea deciziilor strategice. n concordan cu W. H. Inmon, liderul n
construirea sistemelor data warehouse, un depozit de date este o colecie de date
orientate pe subiecte, integrate, istorice i nevolatile destinat sprijinirii procesului de
luare a deciziilor manageriale. n sintez, definiia prezentat mai sus exprim
caracteristicile majore ale depozitelor de date:
orientare pe subiecte;
integrare;
caracter istoric;
persistena datelor.

Orientarea pe subiecte. Sistemele operaionale tradiionale erau focalizate pe datele
cerute de compartimentele funcionale ale ntreprinderii. Odat cu reingineria
proceselor (Business Process Reengineering - BPR) ntreprinderile ncep s axeze pe
cerinele decizionale ale echipelor de conducere. Sistemele operaionale moderne sunt
orientate pe cerinele ntregului proces tranzacional i sprijin execuia proceselor de
la nceput pn la sfrit. Un depozit de date merge dincolo de informaiile
tradiionale prin focalizarea pe subiecte ale activitii ntreprinderii cum ar fi: clieni,
vnzri, profituri etc. Aceste subiecte necesit informaii din diverse surse pentru a
furniza o imagine complet a domeniului. n loc de a se concentra pe procesarea
operaiilor i tranzaciilor zilnice dintr-o organizaie, un depozit de date se focalizeaz
pe modelarea i analiza datelor pentru luarea deciziilor. Din acest motiv, depozitele de
date ofer, n mod tipic, o viziune simpl i concis relativ la un subiect specific
excluznd datele care nu sunt utile n procesul de sprijinire a deciziei.

Integrarea. Un depozit de date este, n mod uzual, construit prin integrarea unor
multiple surse heterogene: baze de date relaionale, fiiere, nregistrri privind
tranzacii online. Tehnicile de curire a datelor (data cleaning) i de integrare sunt
aplicate pentru a asigura concordana n conveniile de atribuire a numelor, de
codificare a structurilor, de atribuire a valorilor .a.m.d.

Caracterul istoric. Datele sunt stocate pentru a furniza informaii n perspectiv
istoric (de exemplu, 5-10 ani n urm). Astfel decidenii pot consulta valorile
succesive ale acelorai date pentru a determina evoluia n timp i a calcula anumii
indicatori.


4 | p a g i n a

Persistena datelor. Datele dintr-un depozit sunt permanente i nu pot fi modificate.
O actualizare a depozitului de date, ca urmare a modificrilor efectuate n datele surs,
nsemn adugare de date noi fr a modifica sau terge datele existente. Un depozit
de date este ntotdeauna memorat separat din punct de vedere fizic de datele
transformate din alte aplicaii. Datorit acestei separri, un depozit de date nu necesit
mecanisme de procesare a concurenei. n mod uzual solicit numai dou operaiuni n
accesarea datelor: ncrcarea iniial a datelor i accesul la date. Alte definiii ale
depozitelor de date surprind, cu unele nuanri, aceleai elemente eseniale:
Un depozit de date conine un volum foarte mare de date. Unele dintre aceste
date provin din sursele operaionale ale organizaiei, altele pot proveni din
surse externe;
Depozitul de date este organizat astfel nct s faciliteze folosirea datelor n
scopuri decizionale;
Depozitul de date furnizeaz instrumente prin intermediul crora utilizatorii
finali pot accesa rapid datele.

n continuare prezentm cteva definiii reprezentative din literatura de specialitate. n
viziunea lui Barry Devlin, un depozit de date nseamn o stocare a datelor unitar,
complet i consistent obinut dintr-o varietate de surse, disponibil utilizatorilor
finali ntr-un mod uor perceptibil i utilizabil n contextul afacerii. Dup Ralph
Kimball depozitul de date ofer acces la datele organizaionale; datele coninute sunt
consistente; datele pot fi separate i combinate n funcie de fiecare dimensiune sau
aspect al afacerii. Depozitul de date include, de asemenea, un set de instrumente
pentru interogare, analiz i prezentare a informaiilor; reprezint locul n caresunt
publicate datele folosite; calitatea datelor coninute n depozit reprezint o premis
pentru reingineria afacerii. Sam Anahory subliniaz finalitatea depozitelor de date
preciznd c un depozit de date include datele ... i procesele manageriale ... care fac
informaiile disponibile, permind managerilor s ia decizii corect fundamentate.

De asemenea, o serie de firme i-au adus contribuia n definirea, dezvoltarea i
popularizarea tehnologiilor data warehouseIBM, Software AG, Oracle, Microsoft,
Prism Solutions etc. De exemplu, Software AG definete depozitul de date ca
punctul central pentru difuzarea informaiilor ctre utilizatorii finali pentru sprijinirea
deciziilor i pentru acoperirea cerinelor informaionale ale conducerii. IBM a propus
un termen propriu pentru depozitele de date: Information Warehouse. Dup unii
autori, viziunea IBM se refer mai degrab la conectivitatea global a diverselor surse
de date, fiind un fel de "middleware generalizat" bazat pe arhitectura proprie DRDA -
Distributed Relational Database Architecture. De altfel, n literatura de specialitate se
folosesc i simultan cei doi termeni pentru depozite de date: Data Warehouse i
Information Warehouse. Dup Efraim Turban, scopul unui "data (or information)
warehouse este de a realiza un fond de date (data repository) care s fac accesibile
datele operaionale ntr-o form acceptabil pentru asistarea deciziilor i pentru alte
aplicaii.

1.2. DATA WAREHOUSING

n legtur cu depozitele de date o noiune frecvent utilizat este cea de "data
warehousing" care desemneaz procesul de construire i utilizare a depozitelor de date
(data warehouse). Construirea unui depozit de date necesit integrarea datelor,

5 | p a g i n a

curirea datelor (data cleaning) i consolidarea datelor. Utilizarea unui depozit de
date necesit adesea o colecie de tehnologii de asistare a deciziilor. Acestea permit
managerilor i specialitilor (de exemplu, analiti, consilieri etc.) s utilizeze depozitul
pentru a obine rapid i convenabil datele necesare i s ia deciziile bazate pe
informaiile din depozit. Ali autori utilizeaz termenul de data warehousing" pentru
a referi numai procesul de construire a depozitului de date, n timp de termenul de
warehouse DBMS" este utilizat pentru a referi conducerea i utilizarea depozitului de
date. n privina utilizrii datelor din depozitele de date trebuie precizat c multe
organizaii utilizeaz aceste informaii pentru sprijinirea lurii deciziilor n diferite
domenii de activitate cum ar fi:
sporirea focalizrii pe clieni care include analize ale vnzrilor (preferine,
periodicitate, cicluri bugetare, apetit pentru cumprare etc.);
reorientarea produciei i gestionarea portofoliului de produse, comparnd
performanele vnzrilor pe trimestre, ani, zone geografice, n ordinea celor
mai bune strategii de producie;
analiza operaiilor i cutarea surselor de profit;
gestionarea relaiilor cu clienii;
gestionarea costului activelor corporale.

Data warehousing este, de asemenea, foarte util din punct de vedere al integrrii
surselor de date heterogene. Multe organizaii colecteaz, n mod obinuit, diferite
tipuri de date i ntrein baze de date mari din surse de informaii multiple, heterogene,
autonome i distributive. Integrarea acestor date i obinerea unui acces eficient la ele
este lucrul cel mai dorit. Multe eforturi au fost depuse n industria bazelor de date i n
comunitile de cercetare pentru ndeplinirea acestui scop. n concepia bazelor de
date tradiionale integrarea bazelor de date heterogene este realizat de wrappers" i
integratori (integrators) sau mediatori (mediators) asupra bazelor de date multiple (ex.
IBM Data Joiner, Informix Data Blade). Cnd o interogare este pus unui site client,
un dicionar de metadate este utilizat la transformarea interogrii n interogri
corespunztoare site-urilor heterogene implicate. Aceste interogri sunt atunci mapate
i transmise proceselor locale de interogare. Rezultatele primite de la diferite site-uri
sunt integrate n rspunsul global.

Aceast concepie de interogare necesit procese complexe de filtrare i integrare care
concureaz la resursele de procesare. Este ineficient i potenial scump pentru
interogri frecvente, n special pentru interogri ce solicit agregri. Data
warehousing furnizeaz o interesant alternativ la conceptul tradiional de integrare a
bazelor de date heterogene descrise mai sus. Data warehousing folosete conceptul
update-driven" n care informaiile din surse multiple, heterogene sunt interogate n
avans i stocate n depozitul de date pentru integrare direct i analiz. Spre deosebire
de bazele de date cu procesare on-line, depozitele de date nu conin informaiile cele
mai proaspete. Cu toate acestea, un depozit de date determin o nalt performan
prin integrarea bazelor de date heterogene ntruct datele sunt copiate, preprocesate,
integrate, adnotate, nsumate i restructurate ntr-o colecie semantic de date
(semantic data store). n plus procesul de interogare din depozitul de date nu
interfereaz cu procesele din sursele locale. De altfel, depozitele de date pot stoca i
integra informaii istorice i sprijin interogri multidimensionale complexe.


6 | p a g i n a

1.3. OBIECTIVELE DATA WAREHOUSE

n sintez, scopurile unui depozit de date sunt urmtoarele:
S furnizeze utilizatorilor accesul sporit la date;
S furnizeze o singur versiune a adevrului;
S nregistreze cu acuratee trecutul;
S jongleze" cu nivelurile de acces sintez/detaliu la date;
S separe prelucrrile de nivel operaional i analitic;

Acces sporit la date pentru utilizatori. Depozitul de date furnizeaz accesul la
datele integrate ale ntreprinderii, anterior blocat prin ci neprietenoase. Utilizatorii
pot acum s stabileasc, cu un minim de efort, o conexiune garantat la depozitul de
date prin intermediul unui microcalculator. Securitatea este ntrit prin the
warehouse front-end application", prin serverul bazei de date sau prin ambele.

O singur versiune a adevrului. Datele din depozitele de date sunt consistente i au
calitatea asigurat nainte de a fi puse la dispoziia utilizatorilor finali. n msura n
care se se utilizeaz o surs comun de date, depozitele de date pun capt dezbaterilor
privind veridicitatea datelor utilizate sau citate n edinele de lucru. Depozitul de date
ncepe s fie resursa comun de date pentru nivelurile decizionale din organizaii.
Menionm c o singur versiune a adevrului" este adesea posibil numai dup
multe discuii i dezbateri asupra termenilor utilizai n organizaie. De exemplu,
termenul de client ru platnic" poate avea mai multe nelesuri: client care nu pltete
la timp, client care nu pltete dect parial, client care nu pltete niciodat etc. Ar
putea fi stabilit i o alt accepiune: clieni care au datorii mai vechi de o lun. n
mod sigur aceste accepiuni au influen asupra proceselor decizionale i asupra
pertinenei deciziilor.

nregistrarea cu acuratee a trecutului. Multe date primite de manageri nu sunt
semnificative dac nu sunt comparate cu datele anterioare. De exemplu, rapoartele
care compar performanele actuale ale companiei cu cele din anul precedent sunt
comune. Rapoartele care arat performanele companiei pentru fiecare lun din ultimii
trei ani pot fi foarte interesante pentru decideni. Sistemele operaionale nu vor putea
permite acest gen de informaii. Un depozit de date va fi utilizat pentru nregistrarea
cu acuratee a trecutului, prsind sistemele OLPT libere pentru a realiza focalizarea
pe corecta nregistrare curent a tranzaciilor. Datele istorice sunt ncrcate i integrate
cu alte date n depozit pentru un acces rapid.

Acces combinat sintez/detaliu la date. Rapoartele dinamice i instrumentele de
interogare OLAP (de exemplu, releveele din programele de calcul tabelar, drill up,
drill down) permit utilizatorilor s vizualizeze informaiile din depozitul de date sub
diferite unghiuri i la diferite niveluri de detaliere. Aceste disponibiliti oferite de
depozitele de date reduc timpul i efortul necesar pentru colectarea, formatarea i
filtrarea informaiilor plecnd de la date.

Separarea prelucrrilor de nivel operaional i analitic. Procesele decizionale i
procesele operaionale sunt totalmente divergente arhitectural. ncercarea de a s reuni
n acelai sistem informaiile decizionale i operaionale determin ca ntreinerea
sistemului s devin o problem. Pornind de la procesele operaionale depozitul de
date furnizeaz o arhitectur separat pentru implementarea deciziilor.

7 | p a g i n a

2. ARHITECTURA DEPOZITELOR DE DATE

2.1. ARHITECTURA SIMPLIFICAT A DEPOZITELOR DE DATE

Esena unui depozit de date const ntr-o baz de date de dimensiuni foarte
mari coninnd informaiile pe care le pot folosi utilizatorii finali (clieni, furnizori,
companii de publicitate etc.). Arhitectura simplificat a unui depozit de date este
prezentat n figura de mi jos. n depozitul de date ntlnim mai multe tipuri de date
care corespund diferitelor cerine informaionale ale utilizatorilor: date detaliate, date
agregate, metadate. Metadatele descriu datele coninute n depozitul de date i modul
n care ele sunt obinute i stocate. Prin metadate se precizeaz structura datelor,
proveniena lor, regulile de transformare, de agregare i de calcul. Metadatele joac un
rol esenial n alimentarea depozitului cu date. Ele sunt utilizate n toate etapele de
ncrcare a datelor i sunt consultate i actualizate pe parcursul ntregului ciclu de
via al depozitului. Includerea datelor agregate n depozit, dei determin o cretere a
redundanei datelor, este necesar deoarece n acest fel se poate asigura un timp mediu
de rspuns ct mai redus. Sursele de date pentru depozite sunt: bazele de date
operaionale curente, bazele de date vechi arhivate precum i bazele de date externe.
Construirea depozitului de date presupune parcurgerea urmtoarelor etape:

1. Un proces de extragere a datelor din bazele de date operaionale sau din
surse externe urmat de copierea lor n depozitul de date. Acest proces
trebuie, cel mai adesea, s transforme datele n structura i formatul
intern al depozitului;

2. Un proces de curire a datelor, pentru a exista certitudinea c datele
sunt corecte i pot fi utilizate pentru luarea deciziilor;
3. Un proces de ncrcare a datelor corecte n depozitul de date;
Figura 2.1. Arhitectura de principiu a unui depozit

8 | p a g i n a

4. Un proces de creare a oricror agregri ale datelor: totaluri
precalculate, subtotaluri, valori medii etc. care se preconizeaz c vor
fi cerute i folosite de utilizatori. Aceste agregri sunt stocate n
depozitul de date mpreun cu datele importate din sursele interne i
externe;

Depozitele de date sunt destinate managerilor, analitilor i specialitilor angrenai n
luarea deciziilor strategice privind dezvoltarea i viitorul organizaiilor. Pentru aceasta
ei au nevoie de instrumente performante de accesare i utilizare a datelor din depozite,
instrumente asigurate prin software-ul asociat depozitului de date. Pe de o parte,
regsim instrumente necesare utilizatorilor care au nevoie de acces rapid de informaii
punctuale care includ un limbaj de interogare gen SQL sau generatoare de rapoarte
(Report Writers) ce transpun informaiile n formate adecvate. Pe de alt parte, sunt
intrumente specializate pentru asistarea deciziilor care transform informaiile n
forma cerut de decideni (grafice, diagrame, organigrame) sau ofer posibilitatea
analizei tendinelor, corelaiilor i interpretarea acestora. n aceast categorie se
ncadreaz instrumentele OLAP i Datamining. Instrumentele OLAP se bazeaz pe
reprezentarea multidimensional a datelor (cubul de date) i permite analiza
interactiv i rapid a datelor prin operaiuni de tip roll-up, drill-down, slice, dice etc.
Utilizatorul poate obine rezultate imediate parcurgnd dinamic dimensiunile cubului
de date lucrnd cu niveluri diferite de sintez/ detaliere. Instrumentele de tip data
mining asigur transformarea datelor n cunotine, de aceea mult lume consider
termenul data mining sinonim cu termenul de Knowledge Discovery in Databases
(KDD). Se utilizeaz tehnici ale analizei statistice sau de inteligen artificial care
permit descoperirea de corelaii, reguli, cunotine utile sprijinirii deciziilor. ntreaga
gam de instrumente software asociate depozitelor de date este prezentat n figura
nr.2 n partea stng snut evideniate componentele din partea de back-end
(instrumente de extragere i transformare) iar n partea dreapt componentele din
partea de front-end (instrumente de extragere i accesare a datelor).

Figura 2.2. Componentele software ale depozitelor de date


9 | p a g i n a

2.2. ARHITECTURA DEPOZITELOR DE DATE PE TREI NIVELURI

Nivelul de jos (bottom-tier) este constituit din serverul DD i este, n multe
cazuri, un sistem baze de date relaionale. Datele din bazele de date operaionale i din
sursele externe (cum ar fi informaii relative la profilul clientului furnizate de
consultani externi, rezultatele unor sondaje) sunt extrase utiliznd programe de
aplicaii tip interfaa cunoscute sub numele de gateways". Un gateway este sprijinit
de SGBD-ul de baz i permite programelor client s genereze cod SQL pentru a fi
executat de server. Exemplele gateways includ ODBC (Open Database Connection) i
OLE-DB (Open Linking and Embedding for Databases) la Microsoft i JDBC (Java
Database Connection). n acest mod datele sunt extrase, curite, transformate i
ncrcate n depozitul de date. De asemenea, trebuie luat n considerare i
modalitatea de mprosptare a datelor din depozit, pe msura trecerii timpului. Dac,
de exemplu, dimensiunea timp are n structur luna, trimestru, an nseamn c la
sfritul fiecrei luni, a fiecrui trimestru sau a fiecrui an datele din sistemul
operaional trebuie s mprospteze depozitul de date.

Figura 2.3. Arhitectura Data warehouse cu trei niveluri

Baze de date operaionale Surse

10 | p a g i n a

Nivelul mediu (middle tier) bazat pe un server OLAP care este implementat n mod
obinuit, utiliznd fie un model relaional OLAP (ROLAP) fie un model
multidimensional OLAP (MOLAP). Modelul ROLAP este o extensie a unui SGBDR
care mapeaz operaiunile pe date multidimensionale la operaiunile relaionale
standard. Modelul MOLAP este dedicat i implementeaz direct descrierea datelor i
a operaiilor multidimenionale.

Nivelul superior (top tier) este nivelul client care conine instrumente pentru
generarea interogrilor i a rapoartelor, instrumente de analiz i/sau instrumente data
mining (de exemplu, analiza trendului, predicii etc.)

2.3. TIPURI DE DEPOZITE DE DATE

Din punct de vedere al ariei de cuprindere, se ntlnesc trei modele de depozite
de date: depozite de ntreprindere (entreprise warehouse), data mart i depozite
virtuale de date. Un depozit de ntreprindere (Entreprise Warehouse) colecteaz
toate informaiile despre subiecte care privesc ntreaga organizaie. El furnizeaz un
volum extins de date. De regul conine date detaliate dar i date agregate, iar ca ordin
de mrime pornete de la civa gigabytes pn la sute de gigabytes, terabytes sau mai
mult. Un depozit de date de ntreprindere poate fi implementat pe tradiionalele
mainframes, pe superservere UNIX sau pe platforme cu arhitecturi paralele. Necesit
cheltuieli mai mari pentru modelare i ani de zile pentru proiectare i realizare.

Un data mart conine un subset al volumului de date din organizaie, specific unui
grup de utilizatori. Domeniul este limitat la subiecte specifice. De exemplu, un data
mart pentru marketing limiteaz subiectele la clieni, articole, vnzri. Datele
coninute n data mart sunt de obicei agregate. Data marts sunt, n mod curent,
implementate pe servere departamentale mai ieftine care se bazeaz pe UNIX sau
Windows/NT. Ciclul de implementare al unui data mart este mai curnd msurat n
sptmni dect n luni sau ani. Ca atare, un data mart poate fi considerat un
subansamblu al unui depozit de date mai uor de construit i ntreinut i mai puin
scump. Un depozit virtual (Virtual warehouse) este un set viziuni (views) asupra
bazelor de date operaionale. Pentru eficiena procesrii interogrilor numai unele din
viziunile de agregare pot fi materializate. Un depozit virtual este uor de construit dar
necesit capaciti suplimentare pe serverele de baze de date.


11 | p a g i n a

3. PROIECTAREA I REALIZAREA DEPOZITELOR DE DATE

3.1. ANALIZA ECONOMIC PENTRU PROIECTAREA UNUI DEPOZIT

Proiectarea unui depozit de date presupune aplicarea unei scheme de analiz
economic pentru a determina msura n care depozitul de date este necesar i
eficient. n primul rnd, trebuie ca depozitul de date s furnizeze avantaje
competitive prezentnd informaii relevante pe baza crora putem msura
performanele i putem face ajustrile critice pentru a ctiga n faa competitorilor. n
al doilea rnd, un depozit de date poate determina creterea productivitii din
moment ce permite obinerea rapid i eficient de informaii care descriu cu acuratee
organizaia. n al treilea rnd, un depozit de date faciliteaz gestiunea relaiilor cu
clienii din moment ce furnizeaz o viziune consistent despre clieni i produse
ntlnite pe toate liniile de afaceri, pe toate departamentele i pe toate pieele. n final,
un depozit de date determin reducerea costurilor prin reliefarea tendinelor,
direciilor i excepiilor pe perioade lungi de timp. Pentru proiectarea unui depozit de
date este necesar nelegerea i analiza proceselor economice din domeniu i
construirea unei scheme de analiz economic. Construirea unui sistem informaional
complex i vast poate fi comparat cu ridicarea unei cldiri mari i complexe, pentru
care proprietarul, arhitectul i constructorul au diferite viziuni. Aceste viziuni sunt
combinate ntr-o schem complex care reprezint perspectiva top-down, perspectiva
proprietarului sau, la fel de bine, perspectiva bottom-up sau viziunea celui care
implementeaz sistemul informaional.

3.2. VIZIUNI DE PROIECTARE A UNUI DEPOZIT DE DATE

Proiectarea unui depozit de date poate lua n considerare viziuni diferite:
viziunea top-down, viziunea datelor surs (data source view), viziunea depozitelor de
date i viziunea business query. Viziunea top-down permite selectarea informaiilor
relevante necesare n depozitul de date. Aceste informaii reprezint un sprijin
decizional n activitatea curent. Viziunea datelor surs (data source view) exprim
informaiile culese, stocate i gestionate de sistemele operaionale. Aceste informaii
pot fi documentate pe niveluri variate de detaliere i acuratee, de la tabele individuale
de date surs la tabele de date integrate. Datele surs sunt adesea modelate prin
tehnicile tradiionale de modelare a datelor cum sunt diagramele E-A (Entitate -
Asociaie) sau instrumentele CASE. Viziunea depozitelor de date are n vedere
tabelele de fapte i tabelele dimensiune. Reprezint informaiile care sunt stocate n
depozitele de date, incluznd contorizri i totaluri precalculate, ca i informaii
privitoare la sursa, data calendaristic, origine adugate pentru a furniza contextul
istoric. Viziunea business query ofer o perspectiv din punct de vedere al
utilizatorului final. Construirea i utilizarea unui depozit de date este o sarcin
complex din moment ce necesit abiliti de afaceri, abiliti tehnologice i
manageriale. Abilitile de afaceri necesare construirii unui depozit de date se refer la
nelegerea modului n care sistemele stocheaz i gestioneaz datele, la modul de
funcionare a instrumentelor de extragere care transfer datele din sistemul
operaional n depozite de date, la modul cum se construiete software-ul pentru
mprosptarea depozitului prin preluarea datelor din sistemele operaionale. Utilizarea

12 | p a g i n a

unor depozite de date implic nelegerea semnificaiei datelor coninute, ca i
nelegerea i traducerea cerinelor informaionale n interogri care pot fi satisfcute
de depozitele de date. Referitor la abilitile tehnologice, analitii datelor trebuie s
neleag cum se obin informaii cantitative i fapte derivate bazate pe concluzii de la
informaiile istorice din depozitele de date. Aceste ndemnri includ abilitatea de a
descoperi modele i tendine, de a extrapola trendul bazndu-se pe date istorice, de a
vedea anomaliile sau paradigmele i de a prezenta recomandri manageriale concrete
bazate pe asemenea analize. Abilitile de gestiune a programelor permit
intermedierea interfeei cu productorii, vnztorii i utilizatorii finali n privina
distribuirii rezultatelor rapid i la costuri acceptabile.

3.3. PROCESUL DE PROIECTARE A UNUI DEPOZIT DE DATE

Un depozit de date poate fi proiectat i construit utiliznd abordarea top-down,
abordarea bottom-up sau combinaii ale acestora. Abordarea top-down pornete cu
proiectarea i planificarea complet. Se utilizeaz n cazul cnd tehnologia este
matur i bine cunoscut i problemele economice care trebuie rezolvate sunt clare i
bine nelese. Abordarea bottom-up pornete cu experimente i prototipuri. Aceasta
este utilizat la nceputul stadiului de modelare i de dezvoltare tehnologic. Ea
permite unei organizaii s mearg nainte cu cheltuieli considerabil mai mici i s
evalueze beneficiile tehnologiei nainte de a face angajamente semnificative n aceast
direcie. n abordarea combinat, o organizaie poate exploata caracterul planificat i
strategic al abordrii top-down att timp ct reinem avantajele implementrii rapide i
oportune a aplicaiilor dup abordarea bottom-up. Din punct de vedere al ingineriei
programrii, proiectarea i construirea unui depozit de date const n urmtorii pai:
planificare, studiul cerinelor, analiza problemei, proiectarea depozitului, integrarea
datelor i testarea i, n final, utilizarea depozitului de date. Sistemele software mari
pot fi dezvoltate utiliznd dou metodologii: metoda n cascad sau metoda n spiral.
Metoda n cascad execut o analiz structurat i sistematic la fiecare pas nainte de
a trece la urmtorul. Metoda n spiral implic generarea rapid de sisteme funcionale
din ce n ce mai complete, la intervale scurte, ntre dou versiuni succesive. Acest
lucru constituie un atu important pentru dezvoltarea depozitelor de date, n special
pentru data marts pentru c intervalul de realizare este scurt, modificrile pot fi fcute
rapid i noile proiecte i tehnologii pot fi adaptate n mod rapid. n general, procesul
de proiectare a depozitului const n urmtorii pai:
1. Alegerea procesului economic de modelat, de exemplu: stocuri, vnzri
etc. Dac procesul economic este organizaional i implic colecii de
obiecte complexe i multiple modelul tip depozit de date trebuie
realizat. Dac procesul este departamental i focalizat pe analiza unui
singur domeniu va fi ales modelul data marts.
2. Alegerea nivelului de granularitate. Nivelul de granularitate este nivelul
de date fundamental, atomic care va fi folosit pentru reprezentarea
datelor n tabelul de fapte pentru fiecare proces.
3. Alegerea dimensiunilor care vor fi aplicate la fiecare nregistrare din
tabelul de fapte. Dimensiunile tipice sunt: timp, articol, client, furnizor,
depozit, tip tranzacii i stare.
4. Alegerea msurilor (valorilor) care vor popula fiecare nregistrare din
tabelul de fapte. Valorile tipice sunt numerice: de exemplu, vnzri_lei
i cantitatevndut.

13 | p a g i n a

Din moment ce construirea unui depozit de date este o sarcin dificil i pe termen
lung, ocaziile de implementare trebuie clar definite. Scopurile unei implementri
iniiale ale unui depozit de date ar trebui s fie specifice, realizabile i msurabile.
Aceasta implic determinarea timpului i bugetului alocat, a subsetului din organizaie
care trebuie modelat, a numrului de surse de date selectate, a numrului i a tipurilor
de departamente utilizatoare. Odat ce depozitul de date este proiectat i construit,
dezvoltarea iniial a depozitului include instalarea iniial, planificarea derulrii
depozitului de date, instruirea i orientarea. Actualizarea platformelor i ntreinerea
lor trebuie de asemenea, luate n considerare. Administrarea depozitului de date
include mprosptarea datelor, sincronizarea datelor surs, planificarea reacoperirilor,
gestiunea controlului pentru acces i securitate, extinderea depozitului de date. Sfera
managementului include controlarea numrului i ariei de interogri, dimensiuni,
rapoarte, limitarea mrimii depozitului de date sau limitarea bugetului i resurselor.
Sunt disponibile categorii variate de instrumente de proiectare a depozitelor de date.
Instrumentele de dezvoltare a depozitelor de date furnizeaz funcii de definire i
editare a depozitului de metadate (scheme, scripturi, reguli), interogri, rapoarte de
ieire etc.. Instrumentele de analiz i planificare studiaz impactul schimbrilor i
mbuntirea performanelor cnd se schimb intervalele de timp.

3.4. DEPOZITE DE DATE VERSUS BAZE DE DATE OPERAIONALE

O comparaie ntre bazele de date i depozitele de date este n msur s ofere
o imagime coerent privind rolul depozitelor de date n organizaii precum i
raporturile cu alte tipuri de sisteme informatice. Att bazele de date ct i depozitele
de date conin mari cantiti de date structurate care pot fi consultate rapid datorit
structurilor de acces optimizate i se bazeaz, n majoritatea cazurilor, pe tehnologii
relaionale. Totui ele nu au fost proiectate pornind de la aceleai obiective i se
difereniaz prin numeroase aspecte. Sistemele de gestiune a bazelor de date sunt
adecvate aplicaiilor curente de gestiune i servesc la crearea i ntreinerea sistemelor
de baze de date operaionale. Aceste sisteme cunoscute sub denumirea de sisteme
OLTP (On-Line Transaction Processing) au ca obiectiv execuia on-line a tranzaciilor
i a proceselor de interogare. Ele ncorporeaz toate operaiile zilnice dintr-o
organizaie cum ar fi: aprovizionri, stocuri, producie, decontri, pli, contabilitate.
Sistemele depozite de date, pe de alt parte, servesc utilizatorii sau specialitii n
domeniul analizei datelor i lurii deciziilor. Aceste sisteme pot organiza i prezenta
datele n formate variate n ordinea solicitrilor de la diferii utilizatori. Aceste sisteme
sunt cunoscute sub numele de sisteme OLAP (On-Line Analytical Processing).

Bazele de date din sistemele operaionale conin date curente, detaliate care trebuie
actualizate i interogate rapid, n condiii de deplin securitate, constituind suportul
sistemelor informaionale de prelucrare a tranzaciilor (TPS). Depozitele de date sunt
concepute special pentru sprijinirea lurii deciziilor. Ele au ca obiectiv regruparea
datelor, agregarea i sintetizarea lor, organizarea i coordonarea informaiilor
provenind din surse diferite, integrarea i stocarea acestora pentru a da decidenilor o
imagine adecvat care s permit regsirea i analiza eficace a informaiilor necesare.
Interogrile obinuite ntr-un depozit de date sunt mai complexe i mai variate dect
cele din sistemele de gestiune a bazelor de date. Ele se aplic asupra unor volume
foarte mari de date i presupun calcule complexe (analiza tendinei, medii, dispersii
etc.) care necesit adesea agregri (group by). Deosebirile majore ntre OLTP i

14 | p a g i n a

OLAP sunt sintetizate n tabelul de mai jos i iau n considerare urmtoarele trsturi:
utilizatorii i orientarea sistemului, caracterul datelor coninute, nivelul de sintez,
unitatea de lucru, schemele de acces, numrul de nregistrri accesate, mrimea
bazelor de date, sistemul de evaluare etc.

Nr. crt. Trsturi OLTP OLAP
1. Destinaia Procese operaionale Procese informaionale
2. Orientarea sistemului Tranzacii Analize
Utilizatori Funcionari, Specialiti, manageri,
3. administratori BD,
profesioniti BD
executivi, analiti
4. Funcii Operaii zilnice Cerine informaionale pe termen
lung, asistarea deciziei
5. Instrumente folosite n
proiectare
Diagrame E-A Star/ snowflake
Nr. crt. Trsturi OLTP OLAP
6. Caracterul datelor Curente, noutate garantat Istorice, precizie meninut n timp
7. Nivelul de sintez Primitive, detaliere ridicat Sintetizare, consolidare
8. Unitatea de lucru Scurt, tranzacii simple Interogri complexe
9. Scheme de acces Read/write Aproape ntotdeauna Read
10. Focalizare Culegere date Furnizare informaii
11. Numr de nregistrri
accesate
Zeci Milioane
12. Numr de utilizatori Mii Sute
13. Mrimea bazelor de date 100 MB - GB 100 GB - TB
14. Prioriti Performane ridicate,
disponibilitate ridicat
Flexibilitate ridicat, autonomie
utilizatori finali
15. Sistem de evaluare Tranzacii culese Interogri culese, timp de rspuns

Tabelu1 3.1. Comparaie ntre sistemele OLTP i OLAP

Un sistem OLTP este orientat pe client (customer oriented) i este utilizat pentru
procesarea tranzaciilor i interogrilor. Un sistem OLAP este orientat spre pia
(market-oriented) i este utilizat de manageri, analiti i specialiti. Din punct de
vedere al datelor coninute un OLTP gestioneaz date curente care, n mod obinuit,
sunt destul de detaliate pentru a fi uor utilizate n luarea deciziilor curente. Un sistem
OLAP gestioneaz volume mari de date istorice furniznd faciliti pentru sintetizare
i agregare precum i pentru stocarea i gestionarea informaiilor cu diferite niveluri
de granularitate. Aceste aspecte fac ca datele s fie uor utilizate de ctre decideni,
mai ales n domeniile tactic i strategic. De asemenea, un sistem OLTP este focalizat
n principal pe datele curente dintr-o ntreprindere sau dintr-un departament fr a
referi date istorice sau date din alte organizaii. n contrast, un sistem OLAP cuprinde
date istorice i date care provin de la diferite organizaii, integrnd informaii din
surse heterogene. n sistemele OLTP unitile de acces sunt, n principal, tranzaciile
atomice. Aceste sisteme necesit mecanisme de control al concurenei i de
reacoperire. Accesul la sistemele OLAP este cel mai adesea de tip read-only, cu toate
acestea este posibil realizarea de interogri complexe. De ce nu se execut procesri
analitice on-line (OLAP) direct pe bazele de date existente mai degrab dect a cheltui
timp i resurse pentru a construi separat un depozit de date? Este o ntrebare
pertinent iar rspunsul poate explica i fundamenta investiia ntr-un depozit de date.
Argumentul forte pentru aceast separare este promovarea performanei ridicate n
ambele sisteme. O baz de date operaional este proiectat i adaptat pornind de la
sarcini i activiti cunoscute cum ar fi indexarea, utilizarea cheile primare, cutarea

15 | p a g i n a

unor nregistrri specifice, optimizarea interogrilor. Pe de alt parte, interogrile unui
depozit de date sunt adesea complexe. Ele implic calcule asupra unor grupuri mari de
date cu totalizri pe diferite niveluri ce pot necesita utilizarea de metode speciale de
organizare a datelor, de acces i implementare bazate pe viziuni multidimensionale.
Procesnd interogrile OLAP ntr-o baz de date operaional s-ar degrada substanial
performanele sarcinilor operaionale. De altfel, o baz de date operaional sprijin
procesarea concurent a tranzaciilor multiple. Controlul concurenei i mecanismele
de reacoperire sunt necesare pentru a asigura consistena i robusteea tranzaciilor. O
interogare OLAP are nevoie adesea de acces read-only la nregistrri pentru
sumarizare i agregare. Controlul concurenei i mecanismele de reacoperire, dac
sunt aplicate pentru operaiunile OLAP pot primejdui execuia tranzaciilor
concurente i astfel s reduc substanial consistena unui sistem OLTP. n final,
separarea dintre BD operaionale i depozitele de date se bazeaz pe structuri,
coninut, utilizatori i date diferite. Luarea deciziilor necesit date istorice pe cnd
bazele de date operaionale nu conin, n mod obinuit, date istorice. n acest context,
datele operaionale, dei abundente, sunt, n mod obinuit, departe de a fi complete
pentru luarea deciziilor. Asistarea deciziei solicit consolidarea datelor (totalizri i
agregri) din diferite surse, rezultnd date de nalt calitate, curate i integrate. n
contrast, bazele de date operaionale conin numai date neprelucrate (primare)
detaliate, cum sunt tranzaciile care trebuie consolidate naintea analizelor.

16 | p a g i n a

4. MODELE DE DATE MULTIDIMENSIONALE

4.1. DE LA TABELE I FOI DE CALCUL LA CUBUL DE DATE

Cubul de date permite modelarea i vizualizarea datelor n dimensiuni
multiple. El este definit prin dimensiuni i fapte. n termeni generali, dimensiunile
exprim perspectivele n care o anumit organizaie dorete s pstreze nregistrrile
privitoare la tranzaciile desfurate. De exemplu, firma ALFA SA poate crea un
depozit de date pentru vnzri care conine nregistrrile lund n considerare
urmtoarele dimensiuni: timp, articol, ramur i zon. Aceste dimensiuni permit
memorarea vnzrilor lunare pe articole, ramuri i zone. Fiecare dimensiune poate
avea un tabel asociat, numit tabel dimensiune, care descrie dimensiunile. De exemplu,
un tabel dimensiune pentru articol poate conine atributele: nume-articol, marca, tip.
Tabelele dimensiune pot fi specificate de utilizatori sau de experi sau pot fi generate
n mod automat i adaptate n funcie de distribuia datelor.Un model
multidimensional de date este organizat n jurul unei teme centrale, vnzri, de
exemplu. Aceast tem este reprezentat de tabelul de fapte. Faptul are o msur
numeric. El exprim msurile prin care dorim s analizm relaiile ntre dimensiuni.
De exemplu, faptele din depozitul de date vnzri includ: vnzri n lei (vnzri-lei)
cantitate-vndut (numrul de uniti vndute), total vnzri planificate. Tabelul de
fapte conine numele faptelor sau msurile precum i cheile pentru fiecare din tabele
dimensiune aflate n legtur.

Pentru clarificri figurile urmtoare ne vor pune n eviden cum lucreaz schemele
multidimensionale. Dei, n mod obinuit, ne bazm pe cuburi 3D, n depozitele de
date cubul este n-dimensional. Pentru o mai bun nelegere a cubului de date i a
modelului multidimensional de date pornim de la un exemplu de cub de date 2D care
poate fi, n principiu, un tabel sau o foaie de calcul privind vnzrile unei firme. n
particular, este vorba de datele despre vnzrile firmei ALFA SA pe articole vndute
trimestrial n municipiul Vaslui, dup cum se vede n Tabelul 4.1. n reprezentarea
2D, vnzrile din Vaslui sunt expuse lund n considerare dimensiunea timp
(organizat pe trimestre) i dimensiunea articol (organizat pe tipuri de articole
vndute). Valorile sunt afiate n milioane lei. Presupunem acum c dorim
vizualizarea datelor despre vnzri cu o a treia dimensiune: zona. Cele trei dimensiuni
sunt: timp, articol i zon (V, T, N, I).

_______Zona = "V"
Trimestre Articole
Service Calculatoare Telefoane Protecie
1 605 825 14 400
2 680 952 31 512
3 812 1023 30 501
4 927 1058 38 580

Tabelul 4.1. Viziune 2D privind vnzrile firmei ALFA SA

Varianta 3D este prezentat n Tabelul 4.2. Datele 3D sunt reprezentate ca serii de
tabele 2D. Conceptual, putem reprezenta aceleai date n formatul cub de date 3D ca
n Figura 4.1. Un cub de date este un set de date organizat i sumarizat ntr-o structur

17 | p a g i n a

multidimensional printr-un set de dimensiuni i msuri. Cubul de date furnizeaz un
mecanism facil pentru interogarea datelor cu un timp de rspuns foarte scurt. Fiecare
cub are o schem reprezentat de setul de tabele din depozitul de date. Tabelul central
este tabelul de fapte i este sursa de msuri din cub, iar tabelele dimensiune sunt
sursele de dimensiuni. Presupunem acum c dorim s vizualizm vnzrile adugnd
a patra dimensiune, cum ar fi furnizorii. Vizualizarea n 4D devine interesant. Totui
putem vedea cubul 4D ca serii de cuburi 3D ca n Figura nr. 4. Dac vom continua aa
putem afia orice n-D date ca serii de (n-1)D cuburi.

Tabelul 4.2. Viziune 3D privind vnzrile firmei ALFA SA

Figura 4.1. Cub 3D reprezentnd datele din Tabelul 3
Zona = "I" Zona = "N" Zona = "T" Zona = "V"
Articole Articole Articole Articole
T
r
i
m
e
s
t
r
e

S
e
r
v
i
c
e

C
a
l
c
u
l
a
t
o
a
r
e

T
e
l
e
f
o
a
n
e

P
r
o
t
e
c
i
e

S
e
r
v
i
c
e

C
a
l
c
u
l
a
t
o
a
r
e

T
e
l
e
f
o
a
n
e

P
r
o
t
e
c
i
e

S
e
r
v
i
c
e

C
a
l
c
u
l
a
t
o
a
r
e

T
e
l
e
f
o
a
n
e

P
r
o
t
e
c
i
e

S
e
r
v
i
c
e

C
a
l
c
u
l
a
t
o
a
r
e

T
e
l
e
f
o
a
n
e

P
r
o
t
e
c
i
e

1 85 88 89 62 108 968 38 872 81 74 43 59 60 825 14 40
4 2 3 7 8 6 1 5 0
2 49 89 64 69 113 102 41 925 89 76 52 68 68 952 31 51
3 0 8 0 4 4 9 2 0 2
3 95 92 59 78 103 104 45 100 94 79 58 72 81 102 30 50
2 4 9 4 8 2 0 5 8 2 3 1
4 65 99 63 87 114 109 54 984 97 86 59 78 92 105 38 58
9 2 0 2 1 8 4 4 7 8 0

18 | p a g i n a

Figura 4.2. Exemplu de Cub 4D

4.2. STELE, FULGI DE ZPAD I CONSTELAIILE DE FAPTE

Modelul de date entitate-asociaie (E-A) este curent utilizat n proiectarea
bazelor de date relaionale. Schema bazei de date const ntr-un set de entiti i de
relaii ntre ele. Ca model de date acesta este corespunztor reprezentrii on-line a
tranzaciilor. Totui un depozit de date, necesit o schem concis, orientat pe
subiecte care faciliteaz analiza on-line a datelor. Cel mai popular model pentru
depozitele de date este modelul multidimensional. Acesta poate fi n form de stea
(star schema), de fulg de zpad (snow-flake schema) sau de constelaie (constellation
schema).

Schema stea. Schema stea este cel mai comun model de date, n care depozitul de
date conine un tabel central voluminos (tabelul de fapte) i un set de tabele
nsoitoare (tabelele dimensiune) pentru fiecare dimensiune. Tabelul de fapte
cuprinde, fr redundane, cea mai mare parte a datelor. Graful asociat semn cu o
stea n care tabelele dimensiune sunt afiate radial njurul tabelului de fapte central.

Exemplul 1. Un exemplu de schem stea este prezentat n Figura 4.3. Vnzrile sunt
considerate cu 4 dimensiuni numite timp, articol, ramur i zon. Schema cuprinde un
tabel central pentru vnzri care conine chei pentru fiecare din cele 4 dimensiuni
naintea celor dou msuri: vnzri-lei i cantitate-vndut. Precizm c n aceast
schem stea fiecare dimensiune este reprezentat printr-un singur tabel i fiecare tabel
conine un set de atribute. De exemplu, tabelul zona conine atributele Cheie-zona,
localitate, jude, cod-potal, ara. Aceast definiie poate introduce o anumit
redundana. De exemplu, Negreti i Brlad sunt ambele din judeul Vaslui.
nregistrrile pentru aceste localiti vor conine: ... Negreti, Vaslui, ... Romnia; ...
Brlad, Vaslui, ... Romnia.

19 | p a g i n a

Figura 4.3. Schema stea a unui depozit de date pentru vnzri

Schema fulg de zpad" (snowflake). Modelul snowflake este o variant a
modelului stea, unde o parte din tabelele dimensiune sunt normalizate. De aceea,
datele sunt mprite n tabele suplimentare. Rezult o schem reprezentat ntr-un
graf similar unui fulg de zpad. Diferena major ntre modelul fulg de zpad" i
modelul stea este c tabelele dimensiune din modelul fulg de zpad" pot fi pstrate
n forma normalizat ceea ce determin o redundan redus. Asemenea tabele sunt
uor de ntreinut i se economisete spaiu de stocare, deoarece un tabel dimensiune
mare poate deveni enorm cnd structura dimensional este inclus n coloane. Totui
aceast economie de spaiu este neglijabil n comparaie cu volumul foarte mare de
date din tabelul de fapte. Mai mult, structura fulg de zpad poate reduce
eficacitatea browsing-ului" cnd mai multe ,join-uri" trebuie executate la o
interogare. De aceea, schema fulg de zpad este mai puin rspndit fa de schema
stea n proiectarea depozitelor de date.

Exemplul 2. Un exemplu de schem fulg de zpad" pentru vnzrile firmei ALFA
SA este prezentat n Figura 4.4. Aici tabelul de fapte vnzri este identic cu cel din
schema stea din Figura 4.3. Principala diferen ntre cele dou scheme const n
definirea tabelelor dimensiune. Dintr-un singur tabel dimensiune pentru articol din
schema stea, n schema fulg de zpad" rezult dou tabele: unul nou pentru articol i
altul pentru furnizor. Atributul cheie_furnizor din furnizori face legtura cu tabelul
articol. n mod similar, tabelul dimensiune zona poate fi normalizat n dou noi
tabele: zona i localitatea. Atributul cheie-localitate face legtura ntre cele dou table.
Normalizarea poate continua.

20 | p a g i n a

Figura 4.4. Schema stea a unui depozit de date pentru vnzri

n modelul multidimensional datele sunt organizate n multiple dimensiuni, iar fiecare
dimensiune conine mai multe niveluri de abstractizare definite prin ierarhii. Aceast
organizare furnizeaz utilizatorilor flexibilitate n vizualizarea datelor din diferite
perspective. Operaiunile OLAP asupra cubului de date ofer o flexibilitate sporit
pentru a materializa diferite viziuni (views), permind interogri i analize
interactive. Din acest motiv OLAP furnizeaz un mediu utilizator prietenos pentru
analiza interactiv a datelor: Drill-up (roll-up); Drill-down; Dice; Slice; Pivot (rotate).


21 | p a g i n a

5. SOFTWARE FOLOSIT IN DATA WAREHOUSING

5.1. INSTRUMENTE DE EXTRAGERE I TRANSFORMARE A DATELOR

Ca parte a procesului de extragere i transformare, echipa de dezvoltare va
avea nevoie de instrumente care s poat extrage, transforma, integra, curi i ncrca
datele din sistemele surs n una sau mai multe baze de date ale depozitului. Echipa
data warehouse are mai multe opiuni privind instrumentele de extragere a datelor,
ns alegerea depinde n principal de urmtorii factori:
Bazele de date i platforma sistemului surs;
Funcionaliti de extragere i duplicare existente;
Intervalele de timp n care sistemele operaionale sunt disponobile.

Bazele de date i platforma sistemului surs. Instrumentele de extragere i
transformare nu pot accesa toate tipurile de surse de date i toate tipurile de platforme
de operare. Atta timp ct nu exist disponibiliti pentru investiii n componente
middleware, opiunile sunt limitate la acele instrumente care sunt compatibile cu
sistemele surs din ntreprindere.

Funcionaliti de extragere i duplicare existente. Sistemele surs pot avea deja
posibiliti de extragere i duplicare ncorporate, fie prin aplicaiile folosite, fie prin
motorul bazei de date. Disponibilitatea acestor funcionaliti pot reduce dificultile
legate de procesul de extragere a datelor.

Intervalele de timp n care sistemele operaionale sunt disponobile. Unele
mecanisme de extragere sunt mai rapide i mai eficiente dect altele. Ferestrele de
timp din sistemele operaionale determin timpul disponibil pentru procesul de
extragere i acest aspect poate limita opiunile echipei de dezvoltare n ce privete
alegerea instrumentelor de extragere. n practic se ntlnesc dou metode de baz
pentru extragerea datelor din sistemele operaionale:
Extragerea n mas;
Replicarea.

n metoda extragerii n mas (bulk extractions) ntregul depozit de date este
mprosptat periodic prin extragerea datelor din sistemele surs. Toate datele necesare
sunt extrase din sistemele surs iar depozitul de date este reconstruit complet. Aceast
tehnic implic mari costuri legate de transmiterea datelor n reea, n schimb ofer
avantajul unei ntreineri comode a depozitului de date.

Metoda replicrii ia n considerare doar datele noi din sistemele surs. n acest caz
sunt extrase doar datele noi sau datele care au suferit modificri de la ultima extragere
din sistemele surs. Aceast metod este eficient din punctul de vedere al volumului
de date care se vehiculeaz n reea, dar necesit aplicaii complexe care s gestioneze
schimbrile intervenite. Instrumentele de transformare transform datele extrase ntr-
un format adecvat care este necesar pentru a putea fi stocate n depozitul de date.

22 | p a g i n a

Majoritatea instrumentelor de transformare ofer urmtoarele capabiliti:
Partiionarea i consolidarea cmpurilor;
Standardizarea;
Deduplicarea.

Partiionarea i consolidarea cmpurilor. Anumite secvene de date sunt
implementate ntr-un singur cmp fizic din sistemul surs, ceea ce duce la necesitatea
partiionrii lor n mai multe cmpuri n depozitul de date. n acelai timp, pot fi
cazuri n care mai multe cmpuri din sistemele surs trebuie consolidate astfel nct
datele s fie stocate n depozit ntr-un singur cmp.

Standardizarea. Standardele i conveniile pentru abrevieri, formate de date, tipuri de
date etc sunt aplicate secvenelor individuale de date pentru a crete uniformitatea
coninutului.

Deduplicarea. Se definesc reguli pentru a identifica nregistrri duplicat. Cnd se
descoper un duplicat, dou sau mai multe nregistrri sunt comasate pentru a forma o
singur nregistrare n depozitul de date.

SISTEM SURS TIPUL TRANSFORMRII DEPOZIT DE DATE
Cmpul Adresa
Str. Unirii Nr. 123, Municipiul
Iai, 6600, Romnia
Partiionare cmpuri Nr. Str. 123
Strada: Unirii
Localitate: Iai
Tip localitate: Municipiu
Cod Potal: 6600
Tara: Romnia
Sistem A, Funcie:
Manager general
Sistem B, Funcie:
Director general
Consolidare cmpuri Funcie:
Manager sau Director general
Data comenzii:
21 Nov. 2002
Data comenzii:
01-09-02
Standardizare Data comenzii:
21 Noiembrie 2002
Data comenzii:
01 Septembrie 2002
Sistem A, Nume
angajat:
Popescu I. Vasile
Sistem B, Nume
angajat:
Popescu Vasile
Deduplicare Nume angajat:
Popescu I. Vasile

Tabelul 5.1. Exemple de transformri de date

5.2. INSTRUMENTE DE ACCESARE I UTILIZARE A DEPOZITULUI

Cele mai cunoscute sunt instrumentele OLAP (Online Analytical Processing)
care permit utilizatorilor s realizeze interogri ad-hoc asupra depozitului de date.
Suita instrumentelor OLAP se mparte deocamdat n dou categorii principale:
MOLAP i ROLAP. Instrumentele MOLAP ofer faciliti analitice pentru baze de
date multidimensionale i au un timp de rspuns foarte mic datorit structurii eficiente
de stocare a datelor. Aceste instrumente ofer i funcionaliti privind realizarea de

23 | p a g i n a

previziuni i diverse calcule statistice. Instrumentele ROLAP ofer faciliti analitice
pentru bazele de date relaionale. Exemple de instrumente OLAP:
Essbase OLAP (Arbor Software);
Powerplay (Cognos);
R/OLAP/XL (Intranet Business Systems).

Instrumentele pentru realizarea rapoartelor permit utilizatorilor s produc
rapoarte sofisticate pe baza datelor din depozitul de date. Exist la ora actual dou
categorii principale de instrumente pentru producerea rapoartelor:
Generatoare de rapoarte;
Servere de rapoarte.

Generatoarele de rapoarte permit utilizatorilor s creeze rapoarte parametrizate care
pot fi lansate n execuie ori de cte ori este nevoie. Aceste generatoare necesit un
efort iniial de programare pentru definirea modelului de raport, iar odat ce modelul
corect definit generarea raportului presupune doar apelarea. Serverele de rapoarte
sunt similare cu generatoarele de rapoarte, dar au capabiliti suplimentare care permit
utilizatorilor s gestioneze momentele de producere a rapoartelor. Aceast opiune
este foarte util atunci cnd echipa de dezvoltare a depozitului de date prefer ca
operaiunea de generare a rapoartelor s se desfoare noaptea, dup ce depozitul de
date a fost ncrcat. Programnd generarea rapoartelor pentru perioade de timp n care
personalul nu lucreaz, depozitul de date va putea fi astfel folosit pentru realizarea
interogrilor ad-hoc. Unele servere de rapoarte pot avea i funcionaliti legate de
distribuirea rapoartelor; de exemplu, un server de rapoarte poate trimite prin e-mail
noile rapoarte generate sau le poate include ntr-o pagin web care s poat fi accesat
prin intranetul ntreprinderii.


24 | p a g i n a

6. STUDIU DE CAZ: CUSTOMER RELATIONSHIP MANAGEMENT

Este aproape imposibil s deschizi o publicaie IT actual i s nu te loveti de
acronimul CRM (Customer Relationship Management). Iar cum coninutul acoperit
de acest termen este ct se poate de divers, ntrebarea fundamental se ridic imediat:
Ce este, de fapt, CRM? Din pcate, rspunsul nu este deloc simplu, dei exist o
literatur abundent pe aceast tem, disponibil n Internet sau n librrii. Principala
dificultate o reprezint caracterul interdisciplinar al domeniului, care ine att de
management ct i de tehnologie. Urmarea fireasc este c sub o plaj att de larg
ncape o diversitate nucitoare de produse i servicii, ncepnd de la agende de birou
i centrale telefonice pn la cele mai sofisticate sisteme de data mining. Ceea ce,
desigur, nu poate dect s sporeasc confuzia, aa c domeniul este un adevrat
paradis al firmelor de consultan. Ca i n multe alte domenii, este greu de stabilit n
ce msur tehnologia a influenat modelul de business i n ce msur schimbarea
modelului economic a cerut o tehnologie care s susin noua abordare. Cert este c se
constat o tranziie de la un model de management centrat pe produs spre un model
centrat pe client. Motivele acestei tranziii sunt multiple. Deregularizarea i
globalizarea au nlturat n mare msur barierele comerciale, astfel nct companiile
acioneaz pe o pia n care abundena de produse este fr precedent. Devine din ce
n ce mai improbabil ca un produs s se impun pe o pia tot mai dinamic, n care
concurenii i adapteaz extrem de rapid ofert. Aflat n faa unei diversiti de
produse comparabile din perspectiva calitii i preului, uneori greu de difereniat,
clientul tinde s aprecieze din ce n ce mai mult serviciile conexe produsului (att cele
dinainte de vnzare, ct i cele ulterioare) precum i calitatea relaiei cu productorul
sau vnztorul. ntr-o lume pe care producia de mas nu a ncetat s o
depersonalizeze, clientul devine din ce n ce mai sensibil la o abordare personalizat.

Din perspectiva vnztorului, lucrurile se pot exprima i n cifre. Un studiu publicat
de PIMS arat c, n medie, un client nemulumit va povesti experiena negativ unui
numr de 7 -10 persoane, n timp ce un client mulumit va recomanda compania unui
numr de 3 - 4 cunoscui. Aceast diferen este fundamental. De aici deriv i
rezultatele altor studii: o cretere a ratei de pstrare a clienilor cu doar 5% poate
aduce profituri suplimentare de pn la 125%, n funcie de profilul companiei. Pe de
alt parte, analizele relev c este mult mai ieftin s pstrezi un client dect s atragi
unul nou. n fine, merit amintit aici vechea regul a lui Pareto: 80/20 (n acest
context: 20% dintre clieni i aduc 80% din vnzri). Concluzia este c e mai uor s
produci dect s vinzi ce ai produs, iar cheia problemei o reprezint loialitatea
clienilor. Modelul centrat pe client implic o strategie unitar, promovat de la cel
mai nalt nivel de management, care pune accentul pe calitatea relaiilor cu clienii.
1

Definire i clasificare. Unele articole afirm c CRM este de fapt o tentativ de a
implementa la o scar mult mai mare modelul prvliei tradiionale de cartier (mom-
and-pop department store). Acest model este extrem de elocvent i merit dezvoltat
puin. Proprietarii prvliei i asigur loialitatea clienilor n primul rnd pe baza
relaiei personale cu acetia i a ncrederii reciproce pe care aceast relaie o induce.
Proprietarul i cunoate personal pe fiecare n parte, le cunoate situaia social i

1
http://www.intraweb.ro/txt/Articole/Domenii/CRM/show

25 | p a g i n a

familial, le cunoate preferinele i obiceiurile, cunoate istoria cumprturilor
recente i intuiete nevoile i posibilitile acestora. De asemenea, proprietarii
prvliei cunosc "demografia" cartierului, tiu cnd are loc o nunt, un botez sau o
nmormntare i care sunt modelele tradiionale de achiziii n astfel de mprejurri,
afl cnd cineva s-a mutat n zon (un potenial client) sau cnd cineva a plecat. Pe
baza acestor cunotine, proprietarul prvliei adopt tehnica de vnzare cea mai
potrivit, ncepnd cu tonul conversaiei formale de rigoare, trecnd prin prezentarea
unei oferte specifice pentru clientul respectiv, alturi de recomandri i informaii
privind produsele noi, i pn la ncheierea propriu-zis a vnzrii, prin mijloace de
plat agreate de cumprtor. Cu siguran c acest model idilic nu este aplicabil la
modul direct unui lan de supermarket-uri sau unei companii aeriene, dar ideea este c
mijloacele informatice actuale permit memorarea i gestionarea eficient a
informaiilor despre clieni, ceea ce ar putea ajuta la o mai relaie mai eficient, dac
nu cu fiecare client n parte, mcar cu acei clieni care sunt mai "valoroi" (valoarea
pe termen lung a clientului - customer lifetime value - este o metric folosit adesea n
procesul de segmentare a bazei de clieni). De pild, un lan de magazine poate oferi
carduri speciale clienilor care fac cumprturi repetate sau peste o anumit valoare,
carduri care pot atrage reduceri de pre. n schimb, vnztorul obine date de
identificare a clientului, pe baza crora se pot apoi agrega informaii despre fiecare
vnzare n parte, n oricare magazin, precum i informaii despre orice alte interaciuni
(de pild reclamaii, cereri de suport tehnic sau service, etc.) Pe baza acestor
informaii, care constituie o "imagine a clientului" din perspectiva companiei, se pot
deduce multe aspecte specifice, ceea ce va permite vnztorului s-i personalizeze
oferta n funcie de obiceiurile, preferinele i posibilitile clientului. n plus, analize
statistice coroborate cu date demografice pot furniza informaii globale cu valoare
strategic, care pot permite managementului s observe evoluia de ansamblu a
afacerii i s ia decizii n concordan cu acestea. De pild se pot identifica categoriile
socio-profesionale sau grupele de vrst cele mai active din punctul de vedere al
vnzrilor, ceea ce va permite campanii de marketing mai precis orientate, cu costuri
mai mici i eficien sporit. n fine, "imaginea clientului" permite i aplicarea unor
tehnici de marketing direct (one-to-one), cum ar fi furnizarea prin e-mail a unor
prezentri de produse susceptibile de a fi de interes pentru clientul respectiv. Ne
putem imagina cu uurin scenarii pentru diverse alte domenii (de altfel, domeniul
comerului cu amnuntul nu este printre cele tipice pentru CRM).

De asemenea, exist domenii n care relaia cu clientul are anumite particulariti care
impun o abordare specific, cum ar fi centrele de asisten (help-desk), comerul prin
ageni de vnzri n teren, companiile de vnzri prin pot sau prin Internet. n final,
nu doar companiile comerciale au nevoie de relaii de calitate cu clienii. Exist multe
organizaii administrative sau cu caracter social care au adoptat tehnologii CRM
pentru a rspunde mai bine cerinelor i pentru a reduce cheltuielile.
Gartner Group: CRM este o strategie de business destinat s optimizeze
profitabilitatea ntreprinderii pe baza sporirii satisfaciei clientului. Pentru a
pune n practic aceast strategie, o organizaie trebuie s-i ajusteze
comportamentul i s implementeze procese i tehnologii care s sprijine
interaciunea controlat cu clienii, prin toate canalele de comunicare.
CRMguru.com: CRM este o strategie de business prin care se selecteaz i se
gestioneaz clienii n vederea optimizrii valorii acestora pe termen lung.
CRM necesit o cultur managerial centrat pe client, care s susin procese
eficiente de marketing, vnzri i service. Aplicaiile CRM pot contribui la

26 | p a g i n a

eficientizarea relaiilor cu clienii, n condiiile n care organizaia dispune de
conducerea, strategia i cultura potrivit.
Paul Greenberg: CRM este un sistem complet care (1) furnizeaz un mijloc
i o metod de a mbunti experiena unui client particular astfel nct acesta
s rmn un client fidel; (2) furnizeaz mijloace att tehnologice ct i
funcionale pentru a identifica, captura i reine clienii; (3) furnizeaz o
imagine unitar a clientului n cadrul ntregii organizaii.
Larry Tuck: CRM [este o strategie care] extinde conceptul de vnzare de la
un act discret, realizat de un vnztor, la un proces continuu care implic
ntregul personal al unei companii. Este arta/tiina de a colecta i de a utiliza
informaiile despre client pentru a consolida loialitatea acestuia i a-i spori
valoarea pe termen lung. Este imposibil de conceput acest proces fr a lua n
calcul tehnologia, dar este important de reinut c relaia cu clientul, relaia
uman, este principala for.

Pentru a pune o oarecare ordine conceptual n aceast multitudine de cerine i de
funcionaliti care se pretind unui sistem CRM, se recurge adesea la o diviziune
similar cu cea de tip front office - back office practicat n ERP. Astfel, funciile
operative legate de interaciunea cu clientul sunt reunite sub genericul CRM tactic, n
timp ce activitile preponderent analitice se ncadreaz n ceea ce se cheam CRM
strategic. n principiu, latura tactic furnizeaz laturii strategice datele primare
colectate din interaciunea cu clienii, iar latura strategic furnizeaz laturii tactice
informaii rezultate din procesele analitice. Aceast diviziune nu se suprapune peste
structura organizaional. De pild, unele activiti ale departamentului de marketing
sunt de ordin strategic (de pild conceperea i administrarea unei campanii) pe cnd
unele sunt mai degrab de ordin tactic (de pild realizarea efectiv a unor aciuni
cuprinse ntr-o campanie). Pe de alt parte, i componentele tipice ale unui sistem
informatic de tip CRM ntretaie n mod obinuit demarcaiile formale ntre
departamente. n fine, mai merit subliniat faptul c din punctul de vedere al
tehnologiei (mai cu seam software), soluiile CRM nu au nici ansa omogenitii
(cerinele sunt extrem de diferite, se mbin diverse instrumente specifice), nici ansa
completitudinii (dei exist pe pia "suite CRM", analitii sunt de acord c nici una
nu poate pretinde c acoper toate cerinele) i nici ansa generalitii (n marea
majoritate a cazurilor, implementarea implic mult "customizare"). n cele din urm,
implementarea unei soluii CRM este un fel de puzzle, n care alegerea pieselor
componente, adaptarea lor la cerinele specifice i integrarea lor cu cele existente
reprezint partea tehnologic.

6.1. CLASIFICARE

CRM tactic. Centrul de apel (call center) este componenta central n
interaciunea dintre clieni i organizaie. Termenul evoc n principal telefonia, dar
semnificaia actual cuprinde toate canalele prin care clientul intr n contact cu
organizaia, motiv pentru care unii prefer termeni care s evite confuzia: centru de
comunicare sau centru de contact. Oricum s-ar numi, ideea este c indiferent dac este
vorba de un apel telefonic, de un mesaj e-mail, de o interaciune prin site-ul Web, de o
scrisoare clasic, de un fax, etc., aici se face identificarea clientului, redirecionarea
(dac este cazul) spre persoana sau serviciul potrivit i se memoreaz o "urm" a
interaciunii. Identificarea este primul pas i se bazeaz informaiile de contact ale

27 | p a g i n a

clienilor. Tehnologiile implicate sunt diverse. Se distinge n primul rnd CTI
(Computer Telephony Integration), care permite de pild identificarea clientului pe
baza numrului apelant. Diverse metode automate se pot aplica i pentru celelalte
canale. Oricum (chiar i prin identificare interactiv), important este ca agentul uman
s dispun ct mai rapid de profilul clientului i ca interaciunea s lase o urm n
sistem (la modul minimal: marca de timp, canalul de intrare, agentul i, dac e cazul,
rezumatul interaciunii). Redirecionarea poate beneficia la rndul ei de tehnologii
specifice. n cazul centrelor de apel de tip help desk, dup identificare, agentul uman
poate fi asistat de calculator n stabilirea problemei, prin parcurgerea unui arbore de
situaii tipice. Dac se ajunge la nodurile terminale e OK, agentul poate oferi
informaia solicitat, altfel programul identific automat un rol care corespunde
situaiei (de pild tehnicianul cu specializarea necesar sau agentul de vnzri
potrivit). Rutarea apelului spre un agent uman care corespunde rolului se face sincron
cu profilul clientului i cu problematica identificat pn la momentul apelului.
ncheierea interaciunii este urmat de completarea (parial automat) a "urmei".
Canalele asincrone pot beneficia i ele de automatizri, ncepnd cu identificarea (de
pild pe baza adresei de e-mail), rspunsuri automate (unele bazate pe metode
sofisticate de "nelegere" automat) i, desigur, mecanismul de workflow prin care se
asigur circulaia mesajului pn la rezolvare, ntr-un interval de timp stabilit. Site-ul
Web al organizaiei joac un rol tot mai important n interaciunea cu clienii, fiind
considerat adesea parte integrant a centrului de apel. O practic uzual este
identificarea la log-in i personalizarea interfeei n funcie de profilul clientului.

De asemenea, site-ul Web este un instrument util pentru a culege informaii utile
despre client (chiar i prin memorarea paginilor vizitate). Adesea site-ul Web servete
i ca centru de suport sau servicii client cu "autoservire", ofer sesiuni chat (tratate de
regul ntr-o manier similar cu apelurile telefonice), funcii de tip call back. Uneori,
centrul de apel este folosit i ca mijloc de comunicare dinspre organizaie spre client.
De pild anumite oferte speciale pot fi ataate clienilor selectai spre a le fi furnizate
dac clientul acceseaz centrul de apel ntr-un interval de timp (tendina este de
reduce "agresivitatea" implicit a mesajului). Gestiunea forei de vnzri (Sales Force
Automation - SFA) este desemneaz o clas de aplicaii care, istoric vorbind, precede
conceptul de CRM, fiind apoi integrate n aceast categorie. Iniial erau aplicaii
autonome utilizate de agenii de vnzri i, totodat, de managementul
departamentului de vnzri pentru coordonarea activitii agenilor. Integrarea n
CRM a nsemnat un salt calitativ, deoarece vnztorii dispun n acest context de
informaii mai detaliate despre clieni, agregate din surse diverse (de pild din
interaciunile cu departamentul de servicii pentru clieni, din analizele realizate de
departamentul de marketing, etc.).

La rndul lor, aplicaiile SFA furnizeaz acum date utile n profilul clientului, date
care sunt valorificate de marketing, pentru service i asisten tehnic, etc. O aplicaie
SFA se bazeaz pe un planificator de activiti (activity scheduler) care funcioneaz
att n regim individual, pentru fiecare agent, ct i la nivel de grup. Pe lng
posibilitatea de a-i planifica interaciunile cu clienii, agenii pot s-i coordoneze
aciunile att n cadrul departamentului, ct i n conexiune cu departamentele de
marketing sau de service i asisten tehnic. Planificatorul dispune de obicei de
posibiliti de nlnuire a activitilor (de exemplu dac un agent trimite unui client
informaii despre un produs sau un serviciu, planificatorul leag aceast aciune de un
apel telefonic care trebuie dat peste o sptmn), poate s semnaleze neconcordane

28 | p a g i n a

ntre ageni pe baza unor reguli (de pild, la planificarea unui ntlniri cu un client,
semnaleaz faptul c un alt agent a contactat sau va contacta acelai client), permite
distribuirea sarcinilor (nsoite de notificri prin e-mail). Aplicaiile de SFA trebuie s
ofere i informaii la zi despre produsele i serviciile oferite spre vnzare, mpreun cu
schemele de calcul al preurilor i discount-urilor, despre aciunile promoionale i
chiar despre stocuri i lanul de aprovizionare (de altfel aceste aplicaii sunt adesea
conexe).

n final, adesea aplicaiile SFA dispun de elemente de mobilitate, astfel nct s poat
fi folosite pe teren, cu ajutorul diverselor calculatoare portabile. Aceasta implic
posibiliti de conectare de la distan, autonomie, sincronizare cu datele centrale i
aa mai departe. n funcie de profilul organizaiei, n zona "tactic" se mai pot ntlni
aplicaii specifice, ca de exemplu cele pentru service i suport tehnic, aplicaii pentru
expediie i distribuie, aplicaii de aprovizionare (supply chain management).
Important este c toate aceste aplicaii utilizeaz n comun datele despre clieni i sunt
cuprinse n acelai sistem de workflow management.

CRM strategic. Administrarea activitii de marketing (marketing
automation) cuprinde de fapt o ntreag gam de aplicaii. Dar, nainte de aplicaii,
automatizarea marketingului este un proces care const din proiectarea i executarea
campaniilor de marketing, urmat de msurarea rezultatelor campaniilor, folosind
aplicaii care susin selectarea i segmentarea bazei de clieni, urmresc contactele cu
clienii i eventual evalueaz rezultatele contactelor pentru a determina grupuri int
mai adecvate pentru viitoarele campanii. Dac excludem de aici prile de
administrare a proiectelor (care nu impun softuri specifice CRM), de planificare a
activitilor (similare sau chiar comune cu cele de la vnzri), sistemul de workflow
management la nivelul companiei (care este o component integratoare), precum i
urmrirea contactelor (proces prezentat pentru centrele de apel), rmnem cu o
singur categorie specific acestui nivel: aplicaiile de administrare a campaniilor de
marketing (campaign management - CM). Produsele din clasa CM cuprind n mod
normal funcionaliti de planificare specifice, care de regul se bazeaz pe un set de
tipare sau abloane (templates) care sunt apoi rafinate n funcie de necesiti, astfel
nct o mare parte din determinarea etapelor i stabilirea bugetelor corespunztoare
sunt predefinite n concordan modelele care s-au dovedit cele mai potrivite
organizaiei.

Desigur, planificarea campaniilor de bazeaz pe analiza bazei de clieni, dar o
caracteristic valoroas este posibilitatea de a adapta planificarea i execuia n funcie
de rezultate pariale (de pild stabilirea unor prioriti noi pentru canalele care se
dovedesc cele mai eficiente). Posibilitatea de personalizare a masajului precum i a
ofertelor promoionale n funcie de segmentare sau chiar de istoria relaiei la nivel de
client este o cerin din ce n ce mai important, iar un rol important n aceast
personalizare l joac nsui clientul, cruia i se ofer adesea posibilitatea de a alege
canalul preferat, de a permite sau nu oferte pe diverse grupe de produse sau de a opta
pentru o "temporizare" specific (de pild nu mai des de odat pe sptmn).
Posibilitile de personalizare permit, de pild, difuzarea de newsletters asamblate
dinamic pe baza profilului clientului sau configurarea dinamic a sitului Web n
funcie de vizitator.


29 | p a g i n a

Viziunea complet asupra datelor clienilor permite evitarea difuzrii de mesaje
redundante (cum ar fi abordarea repetat pe diferite canale) sau contradictorii (de
pild o anumit ofert venind de la agentul de vnzri i o alta de la marketing). De
asemenea, integrarea (att la nivelul informaiilor pentru clieni, ct i prin workflow)
permite coordonarea campaniei de marketing cu activitatea de vnzri (de pild
oportunitile sau ofertele speciale pentru anumite segmente sunt imediat disponibile
agenilor de vnzri) sau cu serviciile pentru clieni. De asemenea, reaciile clienilor
(activi sau poteniali) pot fi centralizate i analizate indiferent de canalul pe care vin
(prin mesaje e-mail, prin agenii de vnzri n teren, etc.). Funcionalitile legate de
analiza rezultatelor se bazeaz pe posibilitile de a realiza interogri pe seturi limitate
de date, de a manevra liste, de a aplica metode statistice i diverse metrici specifice,
precum i de a adapta n mod dinamic metodele de segmentare i stabilire a grupurilor
int. Pe baza acestor rezultate se adapteaz dinamic campaniile n desfurare sau se
concep viitoarele campanii.

Dincolo de facilitile analitice la nivelul activitii de marketing, de regul mai exist
un nivel, destinat managementului organizaiei. Este nivelul strategic cel mai nalt,
care trebuie s beneficieze de o viziune integratoare, care s cuprind - alturi de
informaiile actuale i istorice legate de clieni - i informaiile provenind din celelalte
departamente, cum ar fi cele financiar-contabile sau cele de producie, dezvoltare etc.
De asemenea, posibilitile de analiz strategic sporesc odat cu integrarea unor date
externe (cum ar fi cele demografice sau cele provenind din studii de pia). Tendina
ultimului deceniu este ca aceste date s fie integrate n "depozite de date" (data
warehouse), adic baze de date special concepute pentru analiz multidimensional,
alimentate cu date din sistemele operaionale sau din surse externe i pre-procesate
prin metode specifice (de pild agregare i sumarizare). Rolul depozitelor de date
este de a permite realizarea unor analize prin instrumente OLAP (On Line Analytical
Processing). Aceste instrumente permit analize bazate pe diverse dimensiuni i
metrici, concretizate n aa-numitele "cuburi de date" (datacubes), care pot fi privite
n diverse perspective. De pild, o perspectiv posibil se poate baza pe dimensiunile
produs, canal de distribuie, client i timp, ceea ce permite studierea evoluiei
vnzrilor n funcie de clasa de produse, canalul de distribuie i o anumit
segmentare a bazei de clieni. Analiza se poate focaliza prin creterea nivelului de
detaliere (procedeu denumit drill-down). De pild de la o viziune pe trimestre se poate
trece la una pe luni sau sptmni, de la clase de produse se poate trece la produse
individuale.

De asemenea, se pot aplica procedee statistice (de pild se pot face comparaii ntre
mediile vnzrilor pentru un anumit segment de clieni n diverse zone geografice).
De asemenea, se poate spori nivelul de generalitate al analizare, se pot schimba
metricile (de pild volumul vnzrilor exprimat cantitativ sau valoric) sau structurarea
(de pild, se poate merge pe o segmentare a bazei de clieni dup valoare lor pe
termen lung sau dup grupe de vrst, sex, nivel de pregtire etc). Acest nivel
strategic superior nu este specific CRM i nu se bazeaz pe tehnologii specifice, dar
nu poate fi omis dintr-o prezentare general deoarece, pn la urm, aici de nchide
cercul. Aici se studiaz tendinele, aici se identific oportunitile de afaceri, aici se
stabilesc politicile. De pild, managementul poate decide adaptarea gamei de produse
pentru a corespunde mai bine cerinelor clienilor, poate decide direciile n care
trebuie s insiste marketingul, poate decide o politic de recrutare i instruire a
personalului astfel nct s corespund exigenelor unei politici manageriale orientat

30 | p a g i n a

spre client. Nu n ultimul rnd, decide liniile directoare ale adoptrii tehnologiilor care
s susin aceast politic.

6.2. FUNCIUNILE UNUI CRM

CRM este o filozofie de business, descriind o stategie de plasare a clientului n
centrul proceselor, al activitilor i al culturii unei organizaii. Stategia comut
focusarea de pe ciclul de via a produsului ctre ciclul de via a clientului i ncearc
s lungeasc perioada de activitate a acestuia cu organizaia, dezvoltnd produse i
servicii care s extind relaia cu clientul dincolo de aspectele tranzacionale curente.
Dintre funciunile unui CRM, amintim urmtoarele:
gestionarea relaiei i interaciunii ntr-o abordare orientat spre client;
asigurarea meninerii clienilor i managementul activ al relaiei cu acetia;
creterea profitabilitii pe client;
gestiunea activ a portofoliilor de clieni i a plngerilor;
managementul devoltrii produselor i proceselor;
asigurarea loialitii clienilor;
semnalarea imediat a oportunitilor de afaceri/cross-selling;
monitorizarea rezultatelor campaniilor i a schimbrilor n produse/preuri;
automatizarea i managementul corespunztor al noilor clieni i linii de
business;
2

6.3. MODELAREA I PROIECTAREA SISTEMULUI CRM PRO MANAGER

O component esenial n cadrul unui sistem informaional o constituie
prelucrrile. Aceast component are rolul de a transforma datele n informaii
respective datele sau informaiile n cunotine. n general procesele de prelucrare sunt
compuse din: activiti, aciuni, faze, operaii i evenimente. Pentru a rezolva cerinele
utilizatorilor i ale altor entiti din sistem, analistul trebuie s neleag i s
reprezinte fluxurile de date i procesele de transformare ale acestora. Descrierea
preliminar a prelucrrilor sistemului i ale fluxurilor de date i informaii ntre
acestea, n cadrul analizei sistemului informaional, se realizeaz cu ajutorul
modelelor conceptuale ale prelucrrilor. Acestea reflect conexiunile i structura
informaional general a prelucrrilor din sistemul analizat.

6.3.1. MODELAREA FLUXULUI DE DATE

Modelarea prelucrrilor reprezint o tehnic de organizare i documentare a
tuturor proceselor de culegere, prelucrare, stocare i transmitere a datelor n interiorul
sau exteriorul sistemului analizat precum i a politicilor i procedurilor care
guverneaz aceste procese. Modelarea conceptual nu are ca obiectiv descrierea unor
detalii privind mijloacele concrete de prelucrare i stocare fizic a datelor. Un rol
important n construcia modelelor pentru prelucrrile sistemului, l are activitatea de
descompunere a prelucrrilor. Tehnica utilizat pentru descompunerea proceselor de
prelucrare este cunoscut sub denumirea de decompoziie.

2
E-Finance nr. 88, 15 dec. 2007 - 15 ian. 2008

31 | p a g i n a

Diagrama de decompoziie. Decompoziia reprezint activitatea prin care un sistem
este descompus n subsistemele, procesele sau subprocesele sale componente. Cel mai
utilizat instrument n decompoziia sistemului l reprezint diagrama de decompoziie.
Diagrama de decompoziie este o reprezentare ierarhic a componentelor i
subcomponentelor sistemului. n cadrul procesului de colectare, are loc strngerea
tuturor datelor care vor sta la baza formrii cunotinelor. Prin procesul de prelucrare
datelor, acestea iau forma informaiilor, informaii ce prin interpretare devin
cunotine. n cadrul procesului de transmitere, cunotinele acumulate vor fi puse la
dispoziia managerului, pentru a servi ca suport n procesul decizional, aa cum
rezult din figura 2.1. Tehnica de decompoziie are ca rezultat doar descompunerea
funcional a proceselor de prelucrare, fr a scoate n eviden fluxurile de date
dintre acestea i condiiile tehnice de realizare. Din aceast cauz decopoziia este
integrat n procesul de modelare conceptual a prelucrrilor.

Figura 6.1. Diagrama de decompoziie

Diagrama de context i diagrama de nivel zero. n analiza sistemelor
informaionale cel mai utilizat instrument de reprezentare a modelului prelucrrilor
sunt diagramele fluxurilor de date (DFD). Aceste diagrame constituie tehnici de
analiz structurat a sistemului i au un rol important att n procesul de identificare i
definire a cerinelor sistemului ct i n procesul de reverse engineering. Diagrama
fluxului de date este un instrument de reprezentare grafic a fluxurilor de date,
proceselor de prelucrare i a locurilor de stocare ale acestora n cadrul sistemului
analizat. Tehnica diagramelor fluxurilor de date scoate n eviden intrrile,
prelucrrile i ieirile de date din cadrul sistemului analizat sau proiectat, aa cum
apar n tabelul 2.1.

Element DFD Tip element
Clieni
Entiti externe Marketing
Management
Comand
Fluxuri de date

Factur
Comentariu website
Interogare date colectate
Raport date prelucrate
Raport final date prelucrate

32 | p a g i n a

Fi comenzi
Locuri de stocare Situaie vnzri
Statistic
Colectare date
Prelucrri Prelucrare date
Interpretare date
Transmiteredate

Tabelul 6.1. Coninutul DFD

Entitatea extern, reprezint emitentul sau receptorul datelor din exteriorul
sistemului analizat. Aceast entitate poate fi o alt diviziune organizatoric,
clienii, o persoan sau o aplicaie informatic.
Fluxul de date reprezint direcia de micare a diferitelor structuri de date.
Printr-o structur de date se nelege un document, un raport listat, o interogare
a bazei de date sau datele dintr-o fereastr a aplicaiei.
Prelucrarea reprezint o activitate de transformare sau interpretare a datelor.
Stocarea de date reprezint locul de nregistrare i stocare a datelor, care poate
fi un document sau un fiier.

Diagrama de context (figura 2.2 ), este o imagine general a sistemului analizat,
coninnd doar o singur prelucrare (sistemul nsui) i mai multe fluxuri de date ntre
aceasta i entitile externe, pentru a reflecta obiectivele i graniele sistemului sau
proiectului. Diagrama de nivel zero (figura 2.3), conine toate procesele de pe primul
nivel de subordonare procesului principal din diagrama de decompoziie. Astfel,
diagrama de nivel zero, se obine prin descompunerea diagramei de context n procese
de prelucrare direct descendente. Aceste subprocese de regul se noteaz cu numere
ntregi ncepnd de la 1.

Figura 6.2. Diagrama de context


33 | p a g i n a

1
Colectare
2
Prelucrare
3
Interpretare
5
Transmitere
CLIENI
MARKETING
MANAGEMENT
Factur
Comand
Statistic
Situaie vnzri
Fi comenzi
Comand
Factur
Comentariu website
Comentariu website

Figura 6.3. Diagrama de nivel zero

6.3.2. MODELAREA DATELOR SISTEMULUI

Dup investigarea sistemului, echipa de analiz i proiectare deine o serie de
date i informaii, sub forma documentelor sau fiierelor cu privire la operaiile i
procesele din sistem. Pentru a modela aceste date n vederea proiectrii bazei de date,
trebuiesc parcurse urtoarele etape: Modelarea sau proiectarea conceptual a bazei de
date; Proiectarea logic a bazei de date; Proiectarea fizic a bazei de date; Rolul
esenial al modelrii conceptuale este de a oferi o imagine fidel a datelor sistemului
i relaiilor dintre acestea, fr a fi dependente de tehnologiile utilizate. Pornind de la
acest model, sistemul va putea fi uor rafinat i implementat n cadrul oricrei
tehnologii. Fazele elaborrii modelului conceptual al bazei de date sunt:
Determinarea dependenelor funcionale;
Identificarea tipurilor de entiti;
Determinarea structurii de atribute ale entitilor i domeniile acestora;
Determinarea atributelor chei candidate i primare;
Identificarea tipurilor de relaii dintre entiti;
Reprezentarea diagramei entitate-relaie;


34 | p a g i n a

Verificarea i validarea modelului;
Revizuirea modelului mpreun cu utilizatorii sistemului.

Structura entitilor-matricea dependenelor funcionale. Dependena funcional
reprezint o relaie de asociere ntre dou atribute dintre care unul este determinant iar
cellalt este determinat. Matricea dependenelor funcionale (tabelul 2.3), reprezint
un tabel n care sunt definite relaiile de asociere dintre atribute. Pe coloan sunt
marcate cu 1 relaiile de determinare dintre determinant (pe linie) i determinat (pe
coloan). Cu 1* sunt marcate relaiile de reflexivitate. Atributele din coloana
denumire trebuie sa fie unice. Dup ce a fost definit matricea dependenelor
funcionale, se construiete diagrama dependenelor funcionale. Aceast diagram
reflect n cascad relaiile de dependen dintre atribute.

Nr. Crt. Simbol Denumire Atribut determinant
1. CLN Clieni Id_client
2. CTG Categorii Id_categorie
3. PRD Produse Id_produs
4. CMZ Comenzi Id_comand
5. DRY Diary Id
6. S_ZNA Statistica_zon Id_statistic_zon
7. ZNA Zon Id_denumire_zon
8. S_DST Statistic_distribuie Id_statistic_distribuie
9. DST Distribuie Id_canal_distribuie
10. S_PRT Statistic_pre Id_statistic_pre
11. PRT Pre Id_prere pre
12. S_CLT Statistic_calitate Id_statistic_calitate
13. CLT Calitate Id_prere_calitate
14. S_PUB Statistic_publicitate Id_statistic_publicitate
15. PUB Publicitate Id_canal_publicitate
16. S_LIV Statistic_livrare Id_statistic_livrare
17. LIV Livrare Id_prere_livrare
18. S_COM Statistic_complexa Id_statistic_complex
19. ACM Alte comentarii Id_alt_comentariu

Tabelul 6.2. Entitile DER

N
r
.

C
r
t

D
e
n
u
m
i
r
e

a
t
r
i
b
u
t

T
i
p

l
u
n
g
i
m
e
ENTITI
C
L
N

C
T
G

P
R
D

C
M
Z

D
R
Y

S
_
Z
N
A

Z
N
A

S
_
D
S
T

D
S
T

S
_
P
R
T

P
R
T

S
_
C
L
T

C
L
T

S
_
P
U
B

P
U
B

S
_
L
I
V

L
I
V

S
_
C
O
M

A
C
M

1
I
d
_
c
l
i
e
n
t

9
(
1
0
)

1
*
1
2
D
e
n
u
m
i
r
e
_

c
l
i
e
n
t

X
(
5
0
)

1

35 | p a g i n a

3
D
a
t
e
_

c
l
i
e
n
t

X
(
5
0
)

1
4
T
e
l
e
f
o
n

X
(
1
0
)

1
5
W
e
b
s
i
t
e

X
(
5
0
)

1
6
I
d
_

c
a
t
e
g
o
r
i
e

9
(
1
0
)

1
*
1 1
7
D
e
n
u
m
i
r
e
_
c
a
t
e
g
o
r
i
e

X
(
5
0
)

1
8
I
d
_
p
r
o
d
u
s

9
(
1
0
)

1
*
1 1 1 1 1 1 1 1 1
9
D
e
n
u
m
i
r
e
_
p
r
o
d
u
s

X
(
5
0
)

1
1
0
C
o
m
p
o
-
z
i
i
e

M
E
M
O

1
1
1
P
r
e

9
(
1
0
)

1
1
2
U
M

X
(
3
)

1
1
3
P
o
z

O
L
E

O
B
J
1
1
4
I
d
_

c
o
m
a
n
d

9
(
1
0
)

1
*


36 | p a g i n a

1
5
C
a
n
t
i
t
a
t
e

9
(
1
0
)

1
1
6
L
i
v
r
a
t

X
(
2
)

1
1
7
D
a
t
a
_

c
o
m
a
n
d

D

1
1
8
I
d

9
(
1
0
)

1 1
*

1
9
D
t
e

D

1
2
0
E
t
i
m
e

9
(
1
0
)

1
2
1
T
e
x
t
_
f
i
e
l
d

M
E
M
O

1
2
2
C
a
t
e
g
o
r
y

9
(
1
0
)

1
2
3
D
e
t
a
i
l
s

M
E
M
O

1
2
4
I
d
_

s
t
a
t
i
s
t
i
c
_

z
o
n

9
(
1
0
)

1
*

2
5
I
d
_

d
e
n
u
m
i
r
e
_
z
o
n

9
(
1
0
)

1 1
*
1
2
6
Z
o
n

X
(
5
0
)

1

37 | p a g i n a

2
7
I
d
_

s
t
a
t
i
s
t
i
c
_

d
i
s
t
r
i
b
u
i
e

9
(
1
0
)

1
*

2
8
I
d
_
c
a
n
a
l
_

d
i
s
t
r
i
b
u
i
e

9
(
1
0
)

1 1
*
1
2
9
D
i
s
t
r
i
b
u
i
e

X
(
5
0
)

1
3
0
I
d
_

s
t
a
t
i
s
t
i
c
_

p
r
e

9
(
1
0
)

1
*

3
1
I
d
_
p
r
e
r
e
_
p
r
e

9
(
1
0
)

1 1
*
1
3
2
S
c
o
r
_
p
r
e

9
(
1
0
)

1
3
3
P
r
e

X
(
5
0
)

1
3
4
I
d
_

s
t
a
t
i
s
t
i
c
_

c
a
l
i
t
a
t
e

9
(
1
0
)

1
*

3
5
I
d
_
p
r
e
r
e
_
c
a
l
i
t
a
t
e

9
(
1
0
)

1 1
*
1
3
6
S
c
o
r
_

c
a
l
i
t
a
t
e

9
(
1
0
)

1
3
7
C
a
l
i
t
a
t
e

X
(
5
0
)

1
3
8
I
d
_

s
t
a
t
i
s
t
i
c
_

p
u
b
l
i
c
i
t
a
t
e

9
(
1
0
)

1
*


38 | p a g i n a

3
9
I
d
_
c
a
n
a
l
_

p
u
b
l
i
c
i
t
a
t
e

9
(
1
0
)

1 1
*
1
4
0
P
u
b
l
i
c
i
t
a
t
e

X
(
5
0
)

1
4
1
I
d
_

s
t
a
t
i
s
t
i
c
_

l
i
v
r
a
r
e

9
(
1
0
)

1
*

4
2
I
d
_
p
r
e
r
e
_
l
i
v
r
a
r
e

9
(
1
0
)

1 1
*
1
4
3
L
i
v
r
a
r
e

X
(
5
0
)

1
4
4
I
d
_

s
t
a
t
i
s
t
i
c
_

c
o
m
p
l
e
x

9
(
1
0
)

1
*

4
5
I
d
_
a
l
t
_

c
o
m
e
n
t
a
r
i
u

9
(
1
0
)

4
6
D
e
s
c
r
i
e
r
e
_
c
o
m
e
n
t
a
r
i
u

X
(
5
0
)

Tabelul 6.3. Matricea dependenelor funcionale

Diagrama entitate-relaie. Modelarea entitate relaie este realizat cu ajutorul
diagramei entitate-relaie (DER). Elaborarea unei DER (figura 2.4), este precedat de
o serie de etape de rafinare a datelor. Datele, relaiile i restriciile impuse de aceste
relaii sunt structurate n mod iterativ cu un cadru general n care sunt gestionate
datele necesare sistemului analizat. Modelul DER are la baz reprezentarea datelor
sub forma unor entiti i a relaiilor dintre aceste entiti, relaii determinate de
caractersticile i tipul datelor. Aceast structurare va permite o implementare mai
uoar i mai fidel a modelului ntr-un sistem de gestiune a bazelor de date.
Conceptele utilizate n cadrul modelelor entitate-relaie sunt urmtoarele:
Entitile: reprezint obiecte, persoane, evenimente sau concepte ale
realitii modelate, care pot fi descrise printr-un set de proprieti.
Ansamblul entitilor care au caracteristici i proprieti comune poart
denumirea de clas a entitii sau tipul entitii. Fiecare tip de entitate
are o denumire care caracterizeaz coninutul entitii;

39 | p a g i n a

Atributele: reprezint proprieti sau caracteristici ale entitilor.
Fiecare tip de entitate trebuie s conin un atribut sau grup de atribute
care s identifice n mod unic instanele entitilor. Atributele sau
grupul de atribute care identific n mod unic instanele unui tip de
entitate, poart denumirea de cheie candidat. O cheie candidat selectat
pentru a identifica n mod unic instanele unui tip de entitate poart
denumirea de identificator al entitii sau cheie primar.
Relaiile dintre entiti: reprezint asocieri ntre instanele diferitelor
tipuri de entiti. Gradul unei relaii reprezint numrul tipurilor de
entiti care particip la ele. Relaiile dintre entiti sunt caracterizate
prin cardinalitatea relaiilor. Cardinalitatea relaiilor dintre entiti
reprezint numrul instanelor entitii B, care pot fi asociate fiecrei
instane a entitii A. Cardinalitatea relaiilor dintre entiti poate fi:
1:1, 1:n, m:n, 0:1, 0:n. Cardinalitatea relaiilor dintre entiti este
determinat i n funcie de atributele entitilor.

Figura 6.4. Diagrama Entitate-Relaie


40 | p a g i n a

6.4. PROIECTAREA IEIRILOR

Analiza de sistem se finalizeaz cu raportul analizei de sistem, prin care se
sintetizeaz i se documenteaz constatrile etapei de analiz. Un raport sintetic i un
exemplar din documentaie servesc drept elemente de baz pentru proiectarea
sistemului. Ieirile unui sistem informaional sunt constituite din ansamblul listelor
sau rapoartelor rezultate n urma prelucrrii automate a datelor, situaii utilizate pentru
justificarea operaiunilor economico-financiare i pentru suportul procesului
decizional. Proiectarea i realizarea lor constituie unul din obiectivele cele mai
importante ale proiectrii sistemului informatic, ele fiind elemente materiale care
justific utilitatea sistemului i chiar existena lui. Obiectivul proiectrii este de a
determina formatul i coninutul tuturor documentelor imprimate, a graficelor i a
structurii ieirilor ctre alte documente. Determinarea concret a coninutului, formei
i circuitului informaional al situaiilor de ieire sunt realizate n funcie de natura
activitii unitii patrimoniale, de cerinele informaionale ale sistemului decizional,
de numrul utilizatorilor i locul acestora n ierarhia unitii, de gradul de ptrundere
al lor n cunoaterea sistemului infomaional, domeniul de activitate din care face
parte lucrarea, etc. De asemenea, la proiectarea coninutului i formei situaiilor de
ieire se recomand s se in seama de restriciile datorate caracteristicilor i
performanelor tehnice ale echipamentelor periferice i s se urmreasc o valorificare
ct mai deplin a posibilitilor de prelucrare a acestora.

Coninutul i circuitul ieirilor sistemului. Pentru definitivarea formei i formatului
de editare a situaiilor de ieire, analitii de sistem au n vedere o serie de reguli
generale pentru formatarea acestora, astfel nct utilizatorii situaiilor sau rapoartelor
sa obin informaiile necesare ntr-un format ct mai accesibil. Recomandrile
generale de formatare a ieirilor sunt:
Titlul listei sau situaiei trebuie s fie descriptiv, dar concis i prezentat
ntr-o form clar a formularului n partea superioar a paginii, central;
Precizarea numrului i/sau datei situaiei tiprite, includerea datei
ntocmirii pe fiecare copie a raportului listat.
Fiecare pagin trebuie numerotat, astfel nct utilizatorul s aib un punct
de referin cnd dorete s localizeze elementele inoportune.
Toate coloanele trebuie s aib nume ct mai relevante, pentru a permite
orientarea utilizatorului asupra coninutului raportului. Tiprirea pe fiecare
pagin a capului de tabel.
Numerotarea liniilor de la primul pn la ultimul rnd.
Sortarea ntr-o ordine logic, dup una sau mai multe chei, ascendent sau
descendent. Marcarea cu anumite linii sau caractere speciale a titlurilor
pentru a fi scoase n eviden.
n cazul ieirilor pentru site-urile web se recomand utilizarea motoarelor
de cutare, formatarea textului prin stiluri CSS, navigare realizat att prin
meniu ct i prin icon-uri i butoane adicente.

1. FI CLIENI
Loc de obinere: departament vnzri;
Destinaie: departament marketing, management;
Nr. de exemplare: 3;
Frecvena: zilnic;
Dispozitiv sau periferic de ieire: consol, imprimant;

41 | p a g i n a

2. FI COMENZI
Frecvena: zilnic;

3. RAPORT STATISTIC ZON
Frecvena: sptmnal;

4. RAPORT STATISTIC DISTRIBUIE
Frecvena: sptmnal;

5. RAPORT STATISTIC PRE
Frecvena: sptmnal;

6. RAPORT STATISTIC CALITATE
Frecvena: sptmnal;

7. RAPORT STATISTIC PUBLICITATE
Frecvena: sptmnal;

8. RAPORT STATISTIC LIVRARE
Frecvena: sptmnal;


42 | p a g i n a

9. RAPORT ZON-CATEGORIE-PRODUS-PRE
Frecvena: sptmnal;

10. RAPORT CATEGORIE-PRODUS-PRE-CALITATE
Frecvena: sptmnal;

11. RAPORT CLIENT-COMAND-CATEGORIE-PRODUS
Frecvena: sptmnal;

12. RAPORT ZON-DISTRIBUIE-CATEGORIE-PRODUS
Frecvena: sptmnal;

13. RAPORT PRODUS-ZON-DISTRIBUIE-LIVRARE
Frecvena: sptmnal;

6.5. PROIECTAREA INTRRILOR I A INTERFEEI

Proiectarea intrrilor sistemului informatic reprezint o etap esenial pentru
asigurarea calitii, consistenei i exactitii prelucrrilor i ieirilor acestuia.
Importana acestei etape n cadrul ciclului de via al dezvoltrii sistemelor este
subliniat de expresia legendar: GIGO (garbage in, garbage out). Intrrile sistemului
reprezint ansamblul datelor introduse n cadrul sistemului informatic pentru
prelucrarea acestora i obinerea situaiilor de ieire. Din punctul de vedere al modului
de introducere al datelor n sistem, intrrile pot fi:
Intrri manuale: introducerea datelor se realizeaz direct sau indirect de
ctre un operator uman prin tastare, scanare sau voce.
Intrri automate: introducerea datelor n sistem se realizeaz fr
intervenia operatorului uman, prin preluare automat din cadrul altor surse
de date.

43 | p a g i n a

Proiectarea intrrilor este o activitate de stabilire a regulilor i procedurilor de lucru
pentru preluarea, verificarea-validarea i introducerea datelor din cadrul diferitelor
surse de date. Proiectarea intrrilor are n vedere urmtoarele aspecte:
Tipul surselor de intrare (coduri de bar, documente, fiiere);
Natura i coninutul cmpurilor din sursele de date. Trebuie s se identifice
i s se stabileasc ct mai exact tipul i lungimea fiecrui cmp ce va fi
introdus, respectiv coninutul acestuia;
Proceduri de validare a datelor la intrare;
Stabilirea tehnologiilor pentru intrarea datelor n sistem;

Introducerea inadecvat a datelor n sistem poate genera o serie de erori. Cele mai
cunoscute erori la introducerea datelor sunt:
Adugarea unor anumite caractere la un anumit cmp. De exemplu
adugarea mai mult de 13 cifre la codul numeric personal;
Trunchierea cmpurilor. De exemplu introducerea incomplet a codului
unui produs.
Transpunerea (inversarea) caracterelor. De exemplu inversarea cifrelor
din cadrul preului unitar.
Introducerea inadecvat a unui cmp de un anumit tip n cadrul unui
cmp de alt tip. De exemplu introducerea unor caractere alfanumerice n
cadrul cmpului preului unui produs.
Erorile aprute la introducerea datelor pot s afecteze semnificativ integritatea i
acurateea prelucrrilor i ieirilor. Pentru reducerea acestor erori, analistul trebuie s
proiecteze proceduri i operaii de validare a intrrilor. Validarea reprezint operaia
prin care se realizeaz verificarea i testarea datelor din cadrul surselor de intrare, n
funcie de natura, coninutul i rolul acestora n prelucrarea i obinerea ieirilor.
Validarea intrrilor presupune implementarea n cadrul programelor informatice a
unor proceduri care s realizeze verificarea i testarea datelor la intrarea lor, evitndu-
se nregistrarea n program a unor date eronate. Cele mai importante teste de validare
sunt:
Verificarea introducerii complete a caracterelor unui cmp, asigur
introducerea tuturor caracterelor dintr-un anumit cmp, eliminnd erorile
de trunchiere;
Verificarea tipului de date, asigur introducerea datelor corespunztor
tipului de dat din cmpul unde vor fi introduse datele;
Verificarea integrrii ntr-un interval de valori, asigur introducerea
datelor cu valori ntre un minim i un maxim;
Verificarea pe baza caracterului de control, asigur introducerea datelor
fr erori de inversare. Caracterul de control este obinut printr-un algoritm
de calcul ntre caracterele cmpului i este adugat la cmp;
Verificarea consistenei datelor, presupune corelarea datelor din dou sau
mai multe cmpuri;
Verificarea existenei anumitor caractere ntr-un cmp, asigur
introducerea unor caractere eseniale n cadrul cmpului;


44 | p a g i n a

1. PRODUSE
Denumire cmp Tip (lungime) Condiii de validare
Categorie X(50) NOT NULL
Denumire produs X(50) NOT NULL
Compozitie MEMO NOT NULL
Pret 9(10) >0
UM X(3) NOT NULL
Poza OLE OBJ NOT NULL

Tabelul 6.4. Produse

2. CATEGORII
Cod categorie 9(5) NOT NULL

Tabelul 6.5. Categorii

3. CLIENI
Denumire client X(50) NOT NULL
Date client MEMO NOT NULL
Telefon X(10) NOT NULL
Website X(50) NOT NULL

Tabelul 6.6. Clieni

4. COMENZI
Client X(50) NOT NULL
Eveniment X(50) NOT NULL
Produs X(50) NOT NULL
Cantitate 9(10) >0
Livrat X(2) NOT NULL
Data comanda D NOT NULL

Tabelul 6.7. Comenzi

5. STATISTIC ZON
Denumire ZONA X(50) NOT NULL

Tabelul 6.8. Statistic pe zon

6. STATISTIC DISTRIBUIE
Canal DISTRIBUTIE X(50) NOT NULL

Tabelul 6.9. Statistic pe distribuie

45 | p a g i n a

7. STATISTIC PRE
Parere PRET X(50) NOT NULL

Tabelul 6.10. Statistic pe pre

8. STATISTIC CALITATE
Parere CALITATE X(50) NOT NULL

Tabelul 6.11. Statistic pe calitate

9. STATISTIC PUBLICITATE
Canal PUBLICITATE X(50) NOT NULL

Tabelul 6.12. Statistic pe publicitate

10. STATISTIC LIVRARE
Parere LIVRARE X(50) NOT NULL

Tabelul 6.13. Statistic pe livrare

11. STATISTIC COMPLEX
DISTRIBUTIE X(50) NOT NULL
PRET X(50) NOT NULL
CALITATE X(50) NOT NULL
ZONA X(50) NOT NULL
PUBLICITATE X(50) NOT NULL
LIVRARE X(50) NOT NULL

Tabelul 6.14. Statistic complex

12. ALTE COMENTARII
Descriere comentariu MEMO NOT NULL

Tabelul 6.15. Statistic pe alte comentarii

Interfaa cu utilizatorul (figura 2.4) reprezint partea sistemului, prin care utilizatorii
interacioneaz cu acesta. Interfaa cuprinde mecanismele fizice i mecanismele
grafice, prin care utilizatorul navigheaz, introduce i obine datele i informaiile
prelucrate. Interfaa sistemului are trei pri eseniale:
Mecanismul de navigare, reprezint modul n care utilizatorul d
comenzi sistemului n funcie de operaiile pe care dorete s le

46 | p a g i n a

execute. Navigarea se realizeaz n general, la nivel grafic prin meniuri
i butoane de comand, iar la nivel fizic prin tastatur, mouse, etc.
Mecanismul de intrare, reprezint modul n care sistemul capteaz
(preia) datele i informaiile. Intrarea se realizeaz n general, la nivel
grafic prin ferestre, iar la nivel fizic prin tastatur, scanner i microfon.
Mecanismul de ieire, reprezint modul n care sistemul prezint
informaiile utilizatorilor sau le distribuie ctre alte sisteme. Ieirile
sunt redate n general, la nivel grafic prin rapoarte i ferestre de afiare,
iar la nivel fizic prin imprimant i plotter.

6.6. PROIECTAREA BAZEI DE DATE

n cadrul sistemelor informatice un element esenial l constituie stocarea i
gestiunea datelor introduse i prelucrate. Sistemele informatice actuale utilizeaz,
pentru stocarea datelor, bazele de date, att la nivel desktop (statice, pe un singur
calculator) ct i la nivel distribuit (client-server). Obiectivele fundamentale pentru
analist n aceast faz sunt:
- transpunerea modelului conceptual al datelor, reprezentat prin DER, ntr-un
model logic al bazei de date;
- tratarea modelului bazei de date prin normalizare;
- implementarea modelului logic al bazei de date ntr-un model fizic, prin
SQL;
- implementarea modelului fizic al bazei de date ntr-un SGBD;
- proiectarea securitii bazei de date;
- testarea i rafinarea bazei de date n funcie de cerinele sistemului i
tehnologia utilizat de ctre SGBD;
3

Cea mai rspndit form de organizare a bazelor de date este cea a bazelor de date
relaionale. Pentru a proiecta o astfel de baz de date, analistul trebuie s aib n
vedere conceptele fundamentale ale acestora. Pentru scopurile webului i numai, o
baz de date reprezint o component special, accesat prin intermediul unui server,
utilizat n scopul organizrii i stocrii informaiilor i este cea mai potrivit pentru a
permite accesarea i actualizarea rapid a acestor informaii. O baz de date este
centrat pe o structur organizaional, numit tabel. Informaiile sunt organizate n
tabele deoarece tabelele sunt o modalitate logic de reprezentare a informaiilor
expuse. Tabelele se prezint ntr-un format bazat pe rnduri i coloane. Prile de
informaii nrudite, numite cmpuri, sunt afiate de-a lungul prii de sus a tabelului ca
i coloanele. Mai multe cmpuri formeaz o nregistre sau tuplu.
4
La proiectarea bazei
de date trebuie avute n vedere mai multe obiective, care vor fi enumerate mai jos.
Dei ar fi ideal s poat fi mplinite toate aceste obiective de proiectare, n unele
cazuri ele se exclud reciproc i ar trebui cutat o soluie optim. Cele mai importante
obiective n proiectarea unei baze de date sunt:
eliminarea datelor redundante;
capacitatea de a localiza foarte rapid anumite nregistrri individuale;

3
Brnda Claudiu (2007), Proiectarea sistemelor informatice Note de curs
4
Jennifer Ackerman Kettel, Kate J. Chase (2005), Microsoft Office FronPage 2003, Editura All,
Bucureti, pag. 280

47 | p a g i n a

posibilitatea de a face mbuntiri care s fie uor de implementat
pentru baza de date;
pstrarea unei uoare mentenane a bazei de date;
5

Proiectarea logic a bazei de date presupune rafinarea i validarea prin normalizare a
modelului conceptual al datelor, reprezentat prin DER, n vederea transpunerii
acestuia ntr-un model relaioanl optim. Proiectarea logic a bazei de date pleac de la
modelul entitate-relaie astfel:
entitaile sunt transpuse n relaii (tabele);
atributele entitilor sunt transpuse n atributele relaiilor;
relaiile dintre entiti sunt transpuse n relaii dintre tabele;
entitile sunt rafinate prin normalizare;

Etapele parcurse pentru obinerea modelului logic al bazei de date sunt:
actualizarea modelului conceptual cu datele din ieirile, intrrile i
interfaa proiectat;
normalizarea i integrarea DER a modelului conceptual al datelor ntr-
un model relaional;
validarea relaiilor din cadrul modelului innd cont de tranzaciile din
sistem i stabilirea modelului logic final;

Normalizarea reprezint procesul de analiz a relaiilor de dependen funcional din
cadrul unor structuri complexe de date i transformare a acestora n structuri simple i
stabile. Procesul de normalizare a fost introdus pentru prima data de ctre E.F. Codd
n anul 1972. Acesta a demonstrat c n cadrul relaiilor unei baze de date exist o
serie de anomalii datorate unei structuri inadecvate. nchipuindu-ne normalizarea dus
la extrem, acest lucru ar nsemna ca fiecare informaie s nu apar dect o singur
dat ntr-o baz de date. Practic ns, acest lucru nu este totdeauna posibil i nici de
dorit. Tabelele bazei de date sunt prezentate schematic n Anexa 1.

6.7. IMPLEMENTAREA SISTEMULUI

Unul dintre cele mai utilizate servicii Internet este www-ul (World Wide
Web), care reprezint o modalitate de transmitere a informaiilor prin intermediul
documentelor de tip hypertext. Hypertextul este un text care conine legturi.
Legturile conecteaz texte sau imagini dintr-o pagin cu alte pagini. Crearea de
documente hypertext necesit o metod de stabilire a legturilor ntre documente. n
acest scop, fiecare document este identificat printr-o adres unic, denumit URL
(Uniform Resource Locator), prin intermediul creia browser-ul poate contacta
serverul potrivit i solicita documentul dorit.
6

Tehnologia ASP (Active Server Pages). ASP (Active Server Pages) reprezint o
tehnologie Microsoft. Pentru crearea unei aplicaii ASP este nevoie de IIS (Internet
Information Services), un serviciu oferit de Microsoft care se gsete n pachetul MS

5
Muntean Cornelia, Crearea de aplicaii Visual Basic 6.0 cu baze de date Acces, Editura Mirton,
Timioara, pag. 11
6
Dnia Doina, Mircea Gabriela, Hurbean Clin, Popovics Alexandra, Hauer Ileana (2005),
Tehnologia informaiei i a comunicaiilor pentru economiti, Editura Mirton, Timioara, pag. 175

48 | p a g i n a

Windows. Fiierele de tip ASP reprezint nite fiiere textuale, cu extensia .asp n
care se conine cod ASP, HTML, JavaScript sau altceva de felul acesta. Codul ASP
este citit, executat i convertit n HTML (HyperText Markup Language), apoi oferit
clientului. Astfel clientul primete HTML curat i nu are nevoie de nimic mai mult
dect de un browser bun. Pentru aceasta sistemul are nevoie ca n bara de adres a
browser-ului s se culeag numele server-ului pe care se afl aplicaia. Exemplu:
http://localhost . n rezultat trebuie s apar pagina de start a site-ului, n care se ia
hotrre asupra utilizatorului, care a accesat pagina, adic dac este un membru al
sistemului i dac da spre ce pagin trebuie redirecionat. Se pune ns urmtoarea
ntrebare cine sau mai bine zis ce se ocup pe server de toate aceste lucruri.
Rspunsul este urmtorul: serviciul menionat mai sus IIS. Astfel dac s-a neles
corect codul, ASP nu poate fi vizualizat cu ajutorul click-dreapta > View Sourse,
deoarece astfel vei vedea doar codul HTML, care de fapt este rezultatul execuiei
codului ASP. Codul ASP se afl pe server i nu este disponibil tuturor. ASP folosete
limbaje de tip script cum ar fi VBScript (Visual Basic Script) sau JavaScript. Ca
limbaj de baz este utilizat VBScript. Este necesar de menionat faptul c JavaScript
i Java nu este una i aceeai. JavaScript este un limbaj de tip script, i nu trebuie
confundat cu mult complexul limbaj Java, oferit de Sun Microsystem. n ceea ce
privete Java, exist aa-numitul JSP (Java Server Pages) o alternativ a ASP, care
este bazat pe JavaScript. Oricum ambele fac acelai lucru i fac parte din aa-
numitele tehnologii WEB. Ca SGBD a fost ales MS Acces.
7

Microsoft Access constituie un mediu excelent pentru dezvoltarea de aplicaii la orice
nivel. Este unul dintre cele mai uoare sisteme de gestiune de baze de date i unul
dintre cele mai puternice. Utilizatorii cu diverse niveluri de pregtire i experien au
constatat c aplicaia Microsoft Access i poate ajuta la crearea unor aplicaii care s
ndeplineasc aproape orice cerin. Microsoft Access 2003 este aplicaia de
management al bazelor de date pus la dispoziie de suita Microsoft Office. Spre
deosebire de Excel, Access ne permite s stocm i s administrm volume mari de
date, organizate n uniti numite nregistrri. O baz de date Access const din
urmtoarele obiecte:
Tabele conin toate nregistrrile;
Interogri localizeaz nregistrri specifice;
Formulare afieaz nregistrrile din tabele, una cte una;
Rapoarte tipresc loturi de nregistrri;
Pagini de acces la date pun la dispoziie date prin prisma paginilor
Web;
Macrocomenzi aciuni automate uzuale;
Module stocheaz declaraii si proceduri Visual Basic, care ne permit
s scriem programe pentru bazele de date, astfel nct acestea s poat
interaciona cu alt software.

ASP Maker si ASP Report Maker. Instrumentele de dezvoltare rapid a aplicaiilor
reprezint soluia propus de industria de software pentru ieirea dintr-o criz,
provocat de creterea exponenial a complexitii aplicaiilor moderne. Rapid
Application Development (RAD) este o metodologie, aplicabil n procesul de
dezvoltare al aplicaiilor, care focalizeaz asupra construirii de aplicaii ntr-un timp
foarte scurt. Termenul a devenit relativ recent pe pia un nume-sonor, care, n

7
http://www.informbusiness.md/index.html

49 | p a g i n a

general, descrie aplicaii care pot fi proiectate i dezvoltate pn n 60-90 de zile, dar
la nceput s-a dorit s descrie un proces de dezvoltare care implic prototipizarea
aplicaiei i folosirea ei n mod repetat.
8
Metoda ctig teren datorit simplitii cu
care sunt abordate sistemele, iar din ciclul de via al sistemelor se folosesc doar patru
etape. RAD se bazeaz pe doi factori substaniali, cum ar fi:
sporirea vitezei de derulare a operaiilor economice i odat cu aceasta,
diminuarea posibilitilor de control asupra lor;
apariia multor instrumente puternice bazate pe folosirea calculatorului
n domeniul realizrii sistemelor, ca: CASE i prototipizarea;
Diferena dintre RAD i JAD const n faptul c prototipul devine elementul
fundamental al noului sistem, ecranele afiate n timpul prototipizrii devin ecrane ale
sistemului i nu modele ale unui posibil sistem. Suportul central este oferit de
instrumentele integrate n CASE, n care sunt incluse i generatoarele de coduri ale
programrii. Reuita sa depinde de urmtoarele elemente: instrumentele folosite;
personalul existent; managementul existent; metodologia utilizat; Etapele ciclului de
via sunt: planificarea, analiza, proiectarea i implementarea, iar pentru RAD avem:
planificarea cerinelor, proiectul utilizatorului, construirea i fasonarea sa. RAD-ul
poate avea avantaje dintre care amintim unele n continuare:
Ca un prim avantaj ar fi c, sistemele informaionale pot fi realizate
ntr-un timp de patru ori mai scurt dect metodele tradiionale, deci
sunt mult mai ieftine;
Implicarea personal a beneficiarului duce ca riscul nereuitei s se
diminueze, iar calitatea sistemului sporete datorit numeroaselor teste
ce se fac pe parcurs;
Reducerea timpului de definitivare a proiectului i punerea lui n
lucru, duce la rspunderea mai rapid i mai bun la cerinele
beneficiarului;
Consistena, care apare datorit rapiditii analitilor RAD, ce
neglijeaz existena unor ecrane interne ale aplicaiei, dar i cele din
alte aplicaii;
Standardele de programe, ce sunt realizate n fazele timpurii ale RAD
i face dificil implementarea mai trziu;
Refolosirea modulelor, n unele cazuri analitii omit sau nu au timp s
cerceteze dac aceleai ecran sau rapoarte mai exist n alte aplicaii;
Scalabilitatea, arat c sistemul proiectat de RAD este util, folosirea sa
conduce la extinderea ariei beneficiarilor iniiali ce au participat la
construirea sistemului;
Administrarea sistemului este aproape neglijat n timpul RAD. Apar
probleme ca: ntreinerea i reorganizarea bazelor de date, constituirea
copiilor de siguran i reconstruirea sistemului dup avarii, etc., toate
fiind relevante pentru asigurarea proteciei i securitii sistemului.
9

Asp Maker (figura 3.1), ofer o serie de caracteristici i anume: Opiuni de adugare /
copiere, vizualizare, editare, tergere; Faciliti de cutare rapid i detaliat; Niveluri
avanste de securitate pentru utilizatori, n scopul protejrii informaiei; Export ctre
HTML / Word / Excel / CSV / XML; Multi-coloana de sortare; Notificare prin e-mail

8
McMahon, D. (2000), Rapid Application Development, McGraw-Hill, International Edition, pag. 27
9
Avornicului Constantin (2007), Managementul i proiectarea sistemelor informatice Note de curs

50 | p a g i n a

pe Adugare / Editare / tergere; Opional sistem CAPTCHA; ncrcarea de fiiere n
folder i baza de date;
10

Microsoft SQL Server 2005 este soluia Microsoft de generaie urmtoare pentru
managementul i analiza datelor, care ofer securitate, scalabilitate i disponibilitate
crescute pentru datele ntreprinderii i aplicaiile analitice, fcnd crearea,
implementarea i managementul acestora mai facile. SQL Server 2005 ofer o soluie
integrat de management i analiz a datelor ,care va ajuta organizaiile de orice
dimensiune s:
Dezvolte, implementeze i administreze aplicaii la nivel de ntreprindere mai
sigure, scalabile i fiabile;
Maximizeze productivitatea IT prin reducerea complexitii crerii,
implementrii i administrrii aplicaiilor pentru baze de date;
Partajeze date pe mai multe platforme, aplicaii i dispozitive pentru a facilita
conectarea sistemelor interne i externe;
Controleze costurile fr a sacrifica performana, disponibilitatea,
scalabilitatea sau securitatea;

6.8. FUNCIUNEA APLICAIEI

Interfaa pentru introducerea datelor. Consideraiile generale legate de
interfaa utilizator sunt date de culori, mod de introducere general, tip de componente
(controale) grafice utilizate, etc. 60% din utilitatea interfeei este dat de modul n
care interfaa utilizator se potrivete cu modelul mental al utilizatorului despre o
anumit funcionalitate. Interaciunea influeneaz utilitatea ntr-o proporie de 30%,
iar prezentarea (modul n care aceasta arat) conteaz ntr-o proporie de 10%. n
continuare vor fi prezentate formele din program pentru introducerea datelor.

Figura 6.5. Fereastra de adugare produse

10
http://www.hkvstore.com/aspmaker/features.asp

51 | p a g i n a

Figura 6.6. Fereastra de adugare clieni

Figura 6.7. Fereastra de adugare statistic zon

Figura 6.8. Fereastra de adugare statistic distribuie


52 | p a g i n a

Figura 6.9. Fereastra de adugare statistic pre

Figura 6.10. Fereastra de adugare statistic calitate

Figura 6.11. Fereastra de adugare statistic publicitate


53 | p a g i n a

Figura 6.12. Fereastra de adugare statistic livrare

Figura 6.13. Fereastra de adugare statistic complex

6.9. IEIRILE I RAPOARTELE SISTEMULUI

Ieirile sistemului informatic (Anexa 2 - Anexa 15 ) conin rezultatul
prelucrrilor efectuate asupra datelor de intrare i se pot prezenta sub forma unor
rapoarte, a unor situaii de raportare afiate pe ecran, scrise pe hrtie sau nregistrate
pe un suport extern. Rapoartele pot fi listate la imprimant, vizualizate pe monitor sau
memorate pe un suport magnetic n vederea continurii prelucrrilor n cadrul altor
subsisteme informatice. Adeseori rapoartele de ieire sunt nsoite de reprezentri
grafice, sub forme adecvate, pentru a se putea observa mai uor evoluia unui proces
sau a unui fenomen economic. Acestea se recomand ndeosebi managerilor de nivel
nalt, care au nevoie de informaii cu grad mare de sintetizare.

54 | p a g i n a

Clasificarea iesirilor:
a) Gradul de agregare:
Rapoarte sintetice;
Rapoarte analitice;
b) Natura informaiilor coninute:
Rapoarte coninnd datele de stare ale sistemului condus;
Rapoartele statistice cuprinznd informaii cu caracter statistic
necesare raportrilor ierarhice;
Rapoarte previzionale care permit anticiparea evoluiei unor procese
i fenomene economice;
c) Destinaia rapoartelor:
Rapoarte de uz intern destinat cerinelor proprii de informare i
control;
Rapoarte de uz general cu un coninut prestabilit;
d) Frecvena de generare:
Rapoarte periodice, ntocmite la intervale regulate de timp, cum sunt:
Rapoarte zilnice;
Rapoarte lunare;
Rapoarte trimestriale;
Rapoarte anuale;
Rapoartele de excepie;
Rapoarte la cerere;

1. FI CLIENI:
Anexa 2. Evidena clienilor

2. FI COMENZI:
Anexa 3. Evidena comenzilor

3. RAPORT STATISTIC ZON:
Anexa 4. Situaia pieei de desfacere pe zone

4. RAPORT STATISTIC DISTRIBUIE:
Anexa 5. Situaia pieei de desfacere pe hypermarket-uri

5. RAPORT STATISTIC PRE:
Anexa 6. Perceperea preului de ctre clieni

6. RAPORT STATISTIC CALITATE:
Anexa 7. Perceperea calitii de ctre clieni

7. RAPORT STATISTIC PUBLICITATE:
Anexa 8. Situaia activitii de publicitate

8. RAPORT STATISTIC LIVRARE:
Anexa 9. Situaia activitii de livrare

55 | p a g i n a

9. RAPORT ZON-CATEGORIE-PRODUS-PRE:
Anexa 10. Raport Zon-Categorie-Produs-Pre

10. RAPORT CATEGORIE-PRODUS-PRE-CALITATE:
Anexa 11. Raport Categorie-Produs-Pre-Calitate

11. RAPORT CLIENT-COMAND-CATEGORIE-PRODUS:
Anexa 12. Raport Client-Comand-Categorie-Produs

12. RAPORT ZON-DISTRIBUIE-CATEGORIE-PRODUS:
Anexa 13. Raport Zon-Distribuie-Categorie-Produs

13. RAPORT PRODUS-ZON-DISTRIBUIE-LIVRARE:
Anexa 14. Raport Produs-Zon-Distribuie-Livrare

14. PROFILUL CONSUMATORULUI:
Anexa 15. Profilul consumatorului n funcie de categoriile de produse
achiziionate

Anexa 16. Profilul consumatorului n funcie de categorii i de produsele
achiziionate

Anexa 17. Profilul consumatorului n funcie de raportul pre-calitate perceput

Anexa 18. Profilul consumatorului n funcie de zona de distribuie i de
publicitate

Anexa 19. Situaia comenzilor n funcie de categorii produse, produse i clieni

6.10. SISTEMUL DE ASISTEN

Atunci cnd se vorbete despre documentaie, aceasta este mprit n dou
categorii de baz, documentaia sistemului i documentaia utilizatorului. n
majoritatea sistemelor, sunt cunoscute cele trei tipuri de manuale: de prezentare, de
utilizare i de operare. Manualul de prezentare se adreseaz organelor de conducere.
Din el trebuie s rezulte concepia general a sistemului i o scurt descriere a fiecrei
componente funcionale. Manualul de utilizare se ntocmete pentru fiecare
component funcional n parte, cu rolul de descriere a modului de utilizare a
acestuia. Manualul de operare descrie condiiile n care are loc exploatarea sistemului.
El se adreseaz operatorilor sistemului. Pe baza celor descrise, rezult c manualul de
prezentare i cel de operare constituie pri ale documentaiei sistemului, iar manualul
de utilizare reprezint documentaia utilizatorului.
11

11
Oprea D. (1999), Analiza i proiectarea sistemelor informaionale economice, Editura Polirom, Iai,
pag. 134

56 | p a g i n a

7. CONCLUZII I PROPUNERI

Eforturile necesare introducerii unor soluii CRM nu sunt neglijabile. Pe piaa
occidental, bugete de ordinul a 500.000 de dolari sunt considerate la limita de jos iar
eecuri rsuntoare s-au nregistrat chiar dup investiii de ordinul zecilor de milioane
de dolari. Vestea bun este ns faptul c diversitatea tehnologiilor implicate permit
abordarea gradual, pornind de la anumite componente vitale (de pild centrul de
apel, sau administrarea campaniilor de marketing), urmnd ca efectul implicit
integrator s "cheme" n timp produse corespondente pentru celelalte funciuni.
Exist, desigur, i varianta unei abordri integrate, iar marii furnizori de soluii CRM
ofer soluii integrate, care din punct de vedere software se constituie n suite CRM,
dar care cuprind de regul i servicii asociate (consultan, instruire, asisten, etc.).
Este cazul unor companii ca Peoplesoft, Siebel i Vantive, sau a unor furnizori de
soluii ERP, cum sunt Oracle i SAP. Analitii atrag ns atenia c, de fapt, nu exist
soluii general aplicabile i nici suite soft care s acopere n totalitate nevoile specifice
ale diverselor organizaii. Aceasta implic fie recurgerea la adaptarea
("customizarea") soluiilor integrate furnizate de marii productori, fie recurgerea la
soluii mixte, contnd din produse specializate de la diveri productori. De pild se
poate combina o soluie de marketing de la Epiphany cu un call center de la Vanguard
bazat pe soluii CTI de la Saratoga cu o component pentru vnzri de la Applix. n
acest ultim caz trebuie inut seama de faptul c integrarea poate fi dificil, costisitoare
i s-ar putea s atrag dup sine i achiziii suplimentare (de pild un sistem de
workflow management) sau customizri. O alt variant o reprezint soluiile
integrate de la furnizori specializai pe anumite segmente de pia. Complexitatea
implementrii unor soluii CRM depete n cele mai multe cazuri competenele
interne ale unei organizaii, ceea ce explic de ce chiar mari firme din IT recurg la
consultan n domeniul CRM. n privina repartiiei costurilor, este foarte relevant un
studiu realizat de Gartner, care relev c ntr-o implementare CRM tipic doar 28%
din cheltuieli se fac pentru a cumpra software, iar cca. 38% merg spre servicii cum ar
fi adaptarea programelor, integrarea aplicaiilor i instruirea personalului. Restul
cheltuielilor merg spre achiziii de hardware (23%) i spre zona telecomunicaiilor
(11%).

Ca direcii viitoare, se dorete integrarea unui modul de inteligen artificial, care s
permit scanarea unei persoane prin sistem video, i s i identifice sexul, vrsta,
timpul de expunerea la o reclam, precum i cele mai frecventate trasee dintr-un
hypermarket.

57 | p a g i n a

REFERINE BIBLIOGRAFICE

1. Avornicului Constantin (2007), Managementul i proiectarea sistemelor
informatice -Note de curs;

2. Brnda Claudiu (2007), Proiectarea sistemelor informatice - Note de curs;

3. Dnia Doina, Mircea Gabriela, Hurbean Clin, Popovics Alexandra, Hauer
Ileana (2005), Tehnologia informaiei i a comunicaiilor pentru economiti,
Editura Mirton, Timioara, pag. 175;

4. E-Finance nr. 88, 15 dec. 2007 - 15 ian. 2008;

5. Jennifer Ackerman Kettel, Kate J. Chase (2005), Microsoft Office FronPage
2003, Editura All, Bucureti, pag. 280;

6. McMahon, D. (2000), Rapid Application Development, McGraw-Hill,
International Edition, pag. 27;

7. Muntean Cornelia (2003), Crearea de aplicaii Visual Basic 6.0 cu baze de
date Acces, Editura Mirton, Timioara, pag. 11;

8. Muntean Mihaela (2002), Baze de date in sisteme informatice economice,
Editura Mirton, Timioara;

9. Oprea D. (1999), Analiza i proiectarea sistemelor informaionale economice,
Editura Polirom, Iai, pag. 134;

10. http://crm.cas-software.com/ro/Software_CRM/Functionalitati_CRM.asp;

11. http://download.chip.eu/ro/Mediacore-CRM-2.1.1_1268603.html;

12. http://www.informbusiness.md/index.html;

13. http://www.intraweb.ro/txt/Articole/Domenii/CRM/show;

14. http://www.hkvstore.com/aspmaker/features.asp;

Abordari de Tip Data Warehousing Implementare in MS SQL Server 2005

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Abordari de Tip Data Warehousing Implementare in MS SQL Server 2005

Încărcat de

Drepturi de autor:

Formate disponibile

Introducere

Cap 1. Concepte de baz privind depozitelor de date

S-ar putea să vă placă și