Sunteți pe pagina 1din 27

Sisteme suport de decizie orientate pe date (Data Driven Decision Support Systems)

Def: Un SSDOD este un sistem informatic interactiv care-i ajut pe manageri s utilizeze baze de date de
dimensiuni foarte mari ce conin date preluate din surse interne i externe ale organizaiilor.

Categorii:
Sisteme informatice executive (Executive Information Systems);
Sisteme suport de decizie spaiale;
Sisteme suport de decizie care utilizeaz depozite de date (datawarehouse);
Sisteme OLAP.

Sisteme suport de decizie ce utilizeaz depozite de date

n 1995, Bill Inmon definea depozitul de date ca fiind o colecie de date orientat pe subiect, integrat,
dependent de timp i nevolatil, destinat pentru a susine procesul decizional dintr-o organizaie:

Orientat pe subiect. ntr-un depozit, datele sunt organizate n funcie de subiectele importante pentru
organizaie, cum ar fi clienii, produsele i activitile. Astfel un data warehouse poate oferi o viziune
simpl i concis despre un subiect specific, eliminnd datele considerate irelevante n procesul de
asistare a deciziei.

Integrat. Depozitele de date sunt constituite prin colectarea datelor din multiple surse eterogene
existente n ntreprinderi (baze de date relaionale, fiiere, foi de calcul tabelar, chiar documente). Pentru
asigurarea consistenei i coerenei informaiilor au fost elaborate o serie de tehnici de curire a datelor
(data cleaning).

Nevolatil. Datele stocate ntr-un depozit sunt permanente i nu pot fi modificate. n accepiunea data
warehouse operaia de actualizare se refer la adugarea de noi date din sursele existente, fr a modifica
sau terge nregistrrile anterioare. nregistrrile unui depozit sunt memorate separat din punct de vedere
fizic de datele ce urmeaz s fie procesate de alte aplicaii.

Dependent de timp. Datele din depozitul de date sunt asociate cu elemente temporale. n depozitul de
date, orizontul de timp este cuprins ntre 5 i 10 ani, n timp ce n sistemele tranzacionale poate lua valori
ntre 60 i 90 de zile. De asemenea, structura cheilor conine implicit sau explicit un element de timp.

Construirea unui depozit de date este un proces lung i complex. De aceea, unele organizaii utilizeaz
centrele de date (data mart).

Centru de date:
- depozit de date la nivel de departament
- are dimensiuni mai reduse (10-50 Gb)
- este concentrat pe un singur subiect (de exemplu vnzri, finane, asigurri)
- e construit i folosit de un singur departament al unei organizaii
- preia date din sistemul operaional intern al organizaiei, din depozitul de date central sau din surse
externe.



Clasificarea depozitelor de date n funcie de aria de cuprindere a proceselor decizionale:
depozitul de date de tip galactic (galactic data warehouse/GDW) asist procesele decizionale
manageriale la nivelul compartimentelor ntreprinderii ct i la nivelul ntreprinderii luat ca un ntreg, n
toate tipurile de afaceri;
depozitul de date orientat pe un proces de afacere (business process data warehouse/BPDW) asist
procesele decizionale care privesc oricare i toate procesele de afaceri i legturile lor reciproce, precum
i cu mediul nconjurtor;
depozitul de date departamental (departamental data warehouse/DDW) asist procesele decizionale
care privesc oricare i toate compartimentele i interaciunile lor reciproce, precum i cu mediul
nconjurtor;
centru de date de tip proces de afaceri (business process data mart/BPDM) asist procesele decizionale
centrate pe un singur proces de afaceri;
centru de date departamental (departamental data mart-DDM) asist procesele decizionale centrate pe
un singur departament.

Obiectivele Data Warehouse
Furnizarea accesului sporit la date
Depozitul de date furnizeaz accesul la datele integrate ale ntreprinderii.
Utilizatorii pot stabili relativ uor conexiuni la depozitul de date a crui securitate va fi asigurat fie prin
intermediul aplicaiei ce asigur interfaa, fie prin serverul bazei de date.
Prezentarea unei sigure versiuni a realitii
ntruct datele memorate n depozitele de date au fost deja validate n sistemele operaionale ale
organizaiei, pot fi considerate pertinente i valide asigurnd o imagine fidel a realitii.
nregistrarea cu acuratee a datelor istorice
Cele mai multe dintre situaiile necesare la fundamentarea deciziilor implic prezentarea unor informaii
actuale comparativ cu informaii similare din perioadele precedente. Majoritatea sistemelor
informaionale nu sunt create pentru a furniza situaii de acest tip. ntr-un data warehouse datele istorice
sunt colectate i integrate pentru a asigura un acces rapid, ce nu ar putea fi posibil ntr-un sistem care are
drept principal obiectiv nregistrarea tranzaciilor curente.
Posibilitatea de a oferi rapid acces att la datele de sintez, ct i la cele de detaliu
Prin intermediul rapoartelor dinamice i a instrumentelor de interogare OLAP sunt oferite faciliti de
vizualizare a informaiilor sub unghiuri diferite i la niveluri diferite de detaliere. Astfel se reduce timpul
necesar pentru colectarea, formatarea i filtrarea informaiilor plecnd de la date.
Separarea prelucrrilor de nivel operaional i analitic
Sistemele operaionale clasice, axate pe prelucrarea datelor, nu sunt create pentru a deservi procesele
decizionale. ncercrile de a reuni n acelai sistem informaiile operaionale i cele decizionale poate
afecta funcionarea programelor. Pornind de la procesele operaionale depozitele de date prezint o
arhitectur distinct proiectat special pentru activiti decizionale.

Arhitectura depozitelor de date



- ntr-un depozit de date pot fi memorate tipuri de date diverse necesare pentru a satisface cerinele
informaionale ale mai multor tipuri de utilizatori (date detaliate, date agregate, metadate).

- Metadatele precizeaz structura datelor avnd rolul de a descrie datele colectate n depozit i modul n
care acestea sunt obinute i stocate. Prin intermediul metadatelor se descriu regulile de transformare,
agregare i calcul utilizate.
- Sursele din care pot proveni datele colectate n depozit sunt: bazele de date operaionale curente,
arhivele bazelor de date operaionale, dar i baze de date externe.



Proiectarea depozitelor de date:

Etapele generale ale procesului de proiectare data warehouse:

Colectarea informaiilor privind obiectivele i necesitile sistemului i delimitarea procesului
economic ce va fi modelat (n acest stadiu se va stabili oportunitatea realizrii unui depozit de date sau
a unui data mart).
Alegerea dimensiunilor ce vor fi aplicate nregistrrilor din tabelul de fapte (exemple de
dimensiuni: timp, firma, furnizor, etc.).
Alegerea msurilor ce vor fi memorate n tabelul de fapte (de exemplu: salarii totale, cifra de
afaceri lunar, etc.)
Stabilirea nivelului de granularitate (nivelul de baz ce va fi folosit pentru reprezentarea datelor n
tabelul de fapte).



1) definirea unui model de date la nivel superior, care s asigure coerena ntre viziunile grupurilor de
utilizatori.
2) acest model superior va putea fi extins i rafinat pe msura dezvoltrii sistemului i va minimiza
riscurile apariiei problemelor de integrare.
3) n paralel se vor implementa, la nivel departamental, data marts bazate pe acelai model prestabilit de
date.
4) stadiul final va presupune realizarea unui depozit multi-nivel pentru ansamblul compartimentelor
ntreprinderii ce va ngloba toate datele distribuite n data marts.






n practic, realizarea unui proiect Data Warehouse la nivelul unei organizaii:

1. Identificarea cerinelor informaionale i studiul proceselor economice.
2. Determinarea necesitilor impuse de dezvoltarea depozitului de date pentru suportul hardware.
3. Identificarea surselor de date i modelarea datelor.
4. Extragerea, transformarea i ncrcarea datelor.
5. Proiectarea cuburilor OLAP
6. Proiectarea aplicaiilor client pentru exploatarea depozitului de date.
7. Optimizarea performanelor.
8. Testarea funcionalitii i controlul calitii componentelor realizate.
9. Lansarea depozitului de date n exploatare.
10. Asigurarea exploatrii n condiii optime i asistarea utilizatorilor.
11. Determinarea eventualelor noi cerine informaionale.

Noiuni de baz privind modelul multidimensional de date

: dimensiunea, atributul, ierarhia, tabelele de fapte i cele de dimensiuni.

Depozitele de date se bazeaza pe modelul de date multidimensional care vede datele sub forma unui cub
de date. Structurarea datelor ntr-un format multidimensional poart numele de hipercub de date, prin
extinderea noiunii de cub tridimensional la cub n-dimensional sau hipercub.


Cubul de date permite modelarea si vizualizarea datelor n dimensiuni multiple.
Consiliul OLAP definete hypercubul ca un grup de celule de date aranjate dup dimensiunile datelor.
De exemplu, o foaie de calcul tabelar exemplific o matrice bidimensional cu celulele de date aranjate
n rnduri i coloane, fiecare fiind o dimensiune. O matrice tridimensional poate fi vizualizat ca un cub
cu fiecare dimensiune formnd o fa a cubului........Dimensiunile tipice ale datelor dintr-o ntreprindere
sunt timpul, msurile, produsele, regiunile geografice, canalele de distribuie etc.

Dimensiunile reprezint categorii de informaie. Dimensiunile sunt atribute de identificare a
evenimentelor msurabile sau a lucrurilor pe care le analizm.
ntr-un cub n-dimensional (hypercub) o dimensiune este reprezentat printr-o ax;
De exemplu, ntr-o baz de date pentru analiza vnzrilor se identific urmtoarele dimensiuni: Timp,
Regiune/locaie, Client, Agent de vnzare, Produs.
Exemplul cel mai des ntlnit n cadrul depozitelor de date este dimensiunea timp. Alegerea dimensiunilor
constituie una dintre etapele cele mai importante n proiectarea unui depozit de date i presupune att o
bun cunoatere a domeniului economic de ctre proiectant.

O dimensiune conine mai muli membri (atribute). De exemplu, toate lunile, trimestrele i anii formeaz
dimensiunea Timp i toate oraele, regiunile i rile dimensiunea Locaie.

Atributele unei dimensiuni se poziioneaz ntr-o succesiune de niveluri numit generic ierarhie.
Cele mai multe dimensiuni au o structur multi-nivel sau ierarhic. Timpul este o dimensiune ierarhic
multi-nivel (ore, zile, sptmni, luni, trimestre i ani), Locaia geografic este o dimensiune ierarhic
(vecini, orae, state i ri).
Exemplu de ierarhie de produse dintr-o fabric :

Elementele individuale sau nodurile sunt numite membri (produse electronice, echipamente de birou etc).
Cei mai muli membri au conexiuni n sus i jos, n ierarhie.
Conexiunile n sus sunt de tip (m:1) i sunt numite asocieri printe. Conexiunile n jos sunt de tip (1:m) i
sunt numite asocieri copil.
Un membru ce nu are printe se numete membru radcin (root).
Membrii ce nu au copii sunt numii frunz (scaune, paturi, mese, radio cu baterii, televizoare color etc).
Pentru a identifica poziia unui membru ntr-o dimensiune se folosesc conceptele de nlime i adncime
n ierarhie. nlimea se stabilete de jos n sus. Din acest motiv nivelul (L0) al ierarhiei reprezint
nodurile frunz ale ierarhiei (nlimea cea mai mic).
Adncimea n ierarhie este stabilit de sus n jos. Exist posibilitatea ca doi membri, care au aceeai
nlime, s aib adncimi diferite i invers (structuri arborescente neechilibrate).

Alte exemple de ierarhii :
Dimensiunea Timp i arborele ierarhic aferent :

Dimensiunea Firme i arborii ierarhici afereni :



Dimensiunea Conturi i arborii ierarhici afereni :


OBS :
Ierarhiile dimensionale grupeaza nivelurile de la general spre granular
interogarile utilizeaza ierarhiile pentru a permite vizualizarea datelor aflate pe niveluri diferite de
granularitate avantaj major al depozitelor de date.
La proiectarea ierarhiilor trebuie avute n vedere relatiile dintre structurile organizatiei(firme cu
divizie de vnzari multinivel)
Ierarhiile impun o structura de tip parinte-copil asupra valorilor dimensiunii : pentru o valoare de
pe un anumit nivel, valoarea de pe nivelul ierarhic imediat superior este parinte, iar valorile de pe
nivelul imediat inferior sunt copii este permis accesul rapid la date pentru analisti
Nivelul o pozitie n ierarhie
_ sunt ordonate de la general catre particular nivelul radacina este nivelul cel mai general
_ legaturile dintre niveluri definesc relatiile parinte-copil
Deplasarea n ierarhie catre nivelele superioare, cu un grad sporit de agregare poarta numele de
rollup, iar parcurgerea ierarhiei catre nivelele inferioare, mai detaliate, se numeste drill down
Exemple: n dimensiunea timp, lunile sunt agregate (rollup) n trimestre, trimestrele sunt agregate
n ani etc
n dimensiunea produse, produsele sunt agregate n subcategorii, subcategoriile sunt
agregate n categorii iar categoriile sunt agregate n toate produsele
Analiza datelor porneste de la nivelul cel mai de sus al ierarhiei dimensionale si coboara gradual
catre nivelele inferioare.
O msur ntr-un cub de date este o funcie numeric ce poate fi evaluat n fiecare punct din spaiul
cubului de date. Msurile reprezint valorile centrale care sunt analizate prin cubul de date.
Valoarea msurii este calculat pentru un punct dat prin agregarea datelor corespondente perechii
respective valoare-dimensiune diferite pentru punctul dat.
De exemplu, schema stea a depozitului de date pentru vnzri :

conine dou msuri numite vnzri-lei i cantitate-vndut.

Deci o msur (variabil) este un indicator de performan prin care se poate analiza performana
activitii modelate.

Msurile pot fi clasificate dup posibilitatea de a se nsuma dup dimensiuni:
msuri aditive - care se pot nsuma dup toate dimensiunile.
De exemplu, msura volumul vnzrilor se poate calcula pentru o categorie de produse sau pentru o
anumit regiune sau pentru a anumit perioad de timp.
msuri semiaditive - care se pot nsuma numai dup unele dimensiuni.
De exemplu, msura numrul de clieni este semiaditiv, deoarece se poate calcula numrul de clieni
ntr-o anumit perioad de timp sau pentru o anumit regiune, dar nu este aditiv de-a lungul dimensiunii
Produs. Dac pentru fiecare produs (dintr-o categorie de produse) se cunoate numrul de clieni i dorim
s aflm numrul de clieni pentru categoria de produse, nu se pot aduna aceste numere. Rezultatul poate
fi eronat, deoarece pot exista clieni, care au cumprat mai multe tipuri de produse, din categoria
respectiv.
msuri neaditive - care nu se pot nsuma dup nici o dimensiune (exemplu: profitul marginal).

Obs : Variabilele neaditive pot fi combinate cu alte variabile pentru a deveni aditive.



Exemplu :


Tabela de fapte a unui model este tabela ce conine msurile activitii (de exemplu cifra de afaceri sau
suma salariilor pot reprezenta astfel de msuri).

Exemple de fapte ntlnite n tabele de fapte pentru diferite domenii de activitate:
Comer cu amnuntul: cantitatea vndut , valoarea vnzrilor;
Telecomunicaii: durata convorbirilor n minute, numrul mediu de apeluri;
Bnci: valoarea operaiunilor, numrul mediu de operaiuni;
Asigurri: valoarea despgubirilor
Transport aerian: preul biletelor, greutatea bagajelor.

Faptele sunt valori numerice pe care utilizatorii le analizeaz i le sintetizeaz pentru a nelege mai bine
diverse aspecte ale afacerii.

n tabela de fapte msurile sunt stocate conform granularitii stabilite a depozitului.
Pe lng msuri, tabela de fapte conine i chei externe ce creeaz legtura cu tabelele de tip nomenclator
asociate dimensiunilor.

Fiecare dimensiune poate avea un tabel asociat cu ea, numit tabel dimensiune, care conine informaiile
detaliate despre atributele dimensiunilor.
Tabelele dimensiune conin cmpuri care descriu faptele.

Exemple de atribute pentru tabele dimensiune din domeniile prezentate mai sus la tabelele de fapte:
Comer cu amnuntul: denumirea magazinului, codul magazinului, denumirea produsului, categoria
produsului, ziua din sptmn ;
Telecomunicaii: originea apelului, destinaia apelului
Bnci: numele clientului, numrul contului, data, domeniul de activitate al clientului, numele
administratorului de cont;
Asigurri: tipul poliei de asigurare, bunurile asigurate;
Transport aerian: numrul zborului, destinaia zborului, clasa de cltorie.
Granularitatea reprezint gradul de detaliere a depozitului. Astfel, n funcie de granularitatea stabilit, se
poate specifica cifra de afaceri la nivel de zi sau la nivel de lun.
n determinarea granularitii depozitului sunt parcurse dou etape:
1. Se vor determina dimensiunile ce vor fi luate n consideraie pentru msurile din tabela de fapte.
2. Se va stabili pentru fiecare dimensiune, n cadrul ierarhiei, pn la ce nivel de detaliu este necesar i
util s se ajung.

Obs:
1) Un model multidimensional va include cel puin o tabel de fapte i mai multe tabele dimensiune.
2) Relaiile dintre tabela sau tabelele de fapte i tabelele dimensiune se realizeaz pe baz de chei externe.

Tabelele de fapte dintr-un model multidimensional se pot ncadra n una dintre urmtoarele categorii:

Tabele de tip cumulativ tabele n care majoritatea faptelor sunt de tip cumulativ i, n general, au
rolul de a urmri evoluia unor factori de-a lungul unor perioade de timp
Tabele de tip Snapshot tabele n care faptele prezentate sunt de tip semiaditiv sau non aditiv i au
rolul de a surprinde evoluia factorilor analizai la un anumit moment n timp.

Aditive n cazul n care nsumarea valorilor n cadrul ierarhiilor dimensiunilor conduce la un rezultat
logic (de exemplu cifra de afaceri se poate cumula n cadrul ierarhiei timp dar i n cazul unei
dimensiunii Locaie Geografic)
Parial aditive n cazul n care nsumarea valorilor n cadrul ierarhiilor dimensiunilor are sens doar
pentru anumite dimensiuni (de exemplu soldul contului de disponibiliti poate fi nsumat n cadrul unei
dimensiuni reprezentnd filialele unei companii dar nu are sens s fie cumulat n cadrul dimensiunii timp
de la o zi la alta)
Non Aditive faptele care nu pot fi nsumate n cadrul nici uneia dintre dimensiunile corespunztoare
tabelei de fapte (de exemplu nsumarea ratelor de rentabilitate nu conduce la nici un rezultat logic)














Daca se doreste adaugarea nca a unei dimensiuni furnizorii cub 4D. Acesta poate fi vazut ca serie de
cuburi 3D.
Exemple:

Cele mai des ntlnite reprezentri ale modelului multidimensional de date sunt schemele stea, fulg
de zpad i constelaie.

Fie modelul relaional al unei baze de date pentru facturarea produselor vndute de ctre o firm care
dispune de mai multe puncte de desfacere (magazine):


Schema stea a modelului relaional al bazei de date pentru facturarea produselor:

O schem stea simpl const ntr-o tabel de fapte i mai multe tabele dimensiune.

Tabelul ce conine faptele ocup poziia central i este conectat la tabelele dimensiune pe baza cheilor
externe pe care acestea le conin.

Alt exemplu: schema stea a unui depozit de date pentru vnzri :

msuri
Schema fulg de zpad (snowflake) a modelului relaional al bazei de date pentru facturarea
produselor:

Modelul snowflake este o variant a modelului stea , unde o parte din tabelele dimensiune sunt
normalizate. De aceea, datele sunt mprite n tabele suplimentare.


Tabelele dimensiune sunt proiectate respectnd regulile de normalizare din modelul relaional, conferind
astfel o economie de spaiu n depozitul de date.

Alt exemplu: schema fulg de zpad a depozitului de date pentru vnzri din exemplul anterior :




Schema constelaie (constelaie de fapte):

Acest model apare n cazul existenei mai multor tabele de fapte ce utilizeaz aceleai tabele-dimensiune.

n acest exemplu s-a dorit adugarea n schem a tabelei de fapte referitoare la facturile de aprovizionare
cu materii prime ale firmei. n acest sens la schema prezentat n cazul modelului stea se va mai aduga
un tabel de fapte ce exploateaz dimensiunile comune.

Numele de constelaie provine din faptul c acest model are la baz modelul stea, dar conine mai multe
tabele de fapte. n unele lucrri de specialitate modelul este denumit galaxie.

Alt exemplu: schema constelaie a depozitului de date pentru vnzri din exemplul anterior, la
care se adaug tabela de fapte Shipping :



Exemple de definire a schemelor stea, fulg de zpad i constelaie de fapte

Modelele de date multidimensionale prezentate mai sus pot fi descrise i printr-un limbaj de programare
care dispune de comenzi adecvate.

Un limbaj relaional de interogare cum este SQL poate fi utilizat pentru a specifica interogrile
Un limbaj pentru mineritul datelor poate fi utilizat pentru specificarea sarcinilor data mining.

Limbajul SQL bazat pe data mining (Data Mining Query Language - DMQL) conine i primitive
pentru definirea depozitelor de date i a data marts.

Un depozit de date sau un data mart poate fi definit utiliznd dou primitive, una pentru definirea cubului
i una pentru definirea dimensiunilor:

Comanda pentru definirea cubului:
define cube (nume - cub) [(lista - dimensiuni)] : (lista - valori)

Comanda pentru definirea dimensiunilor:
define dimension (nume - dimensiune) as (atribut _sau _lista _ sudimensiune)

De exemplu schema stea a depozitului de date pt. vnzri din ex. anterior e definit n DMQL astfel:

define cube vanzari-stea [timp, articole, ramura, zona]: vanzari_lei = sum(vanzari_lei),
cantitate_vanduta = count(*)

define dimension timp as (cheie_timp, zi, zi_din_sapt, luna, trimestru, an)

define dimension articol as (cheie_articol, nume_articol, categorie, tip, tip_furnizor)

define dimension ramura as (cheie_ramura, nume_ramura, tip_ramura)

define dimension zona as (cheie_zona, localitate, strada, judet, cod_postal)
Schema snowflake a depozitului de date pt. vnzri din ex. anterior e definit n DMQL astfel:


define cube vanzari-fulg_de_nea [timp, articole, ramura, zona]:vanzari_lei = sum(vanzari_lei),
cantitate_vanduta = count(*)

define dimension timp as (cheie_timp, zi, zi_din_sapt, luna, trimestru, an)

define dimension articol as (cheie_articol, nume_articol, categorie,tip, furnizor(cheie_furnizor,
tip_furnizor))

define dimension ramura as (cheie_ramura, nume_ramura, tip_ramura)

define dimension zona as (cheie_zona, den_zona, localitate(cheie_localitate, localitate, strada, judet,
cod_postal))

Procesul de proiectare a unui depozit de date

1. Alegerea procesului economic modelat (stocuri, vnzari). Daca procesul este organizational
(implica colectii de date complexe si multiple) se justifica realizarea unui depozit de date. Daca
procesul este departamental se va alege solutia data marts.

2. Alegerea nivelului de granularitate - nivelul de date fundamental folosit pentru reprezentarea
datelor n tabelul de fapte pentru fiecare proces.

3. Alegerea dimensiunilor aplicate la fiecare nregistrare din tabelul de fapte (ex: timp, articol,
client, furnizor, depozit, tip tranzactii, stare).

4. Alegerea masurilor care vor popula fiecare nregistrare din tabelul de fapte (ex: cant_vnduta).

Exemplu de proiectare a schemei unui depozit de date

Obiectivele aplicatiei:
Proiectarea si realizarea unui depozit de date din domeniul vanzarilor (facturare)
_ Firma furnizeaza o serie de servicii si are acoparire la nivel de judet cu reprezentare in
principalele orase
_ Serviciile sunt furnizate in principal catre agenti economici
Descrierea sistemelor operationale
_ Nivel mediu de informatizare
_ Exista mai multe aplicatii care gestioneaza datele din domeniul vanzarilor, cu referire la
urmatoarele entitati: agenti_ec, tipuri_servicii, facturi, etc.
_ Bazele de date operationale sunt realizate in Visual FoxPro:
AGENTIM TIPURI FACTURI

Structurile tabelelor, semnificatiile campurilor si secventele de continut AGENTIM:

coda- cod de identificare al fiecarui agent
nume- denumirea agentului
judet, oras, adresa cmpuri care contin adresa agentului
banca banca la care agentul are cont deschis
cont numarul contului
codf codul fiscal al agentului
contr numarul contractului
datac data contractarii
Tip_ag tipul agentului economic:
0 - agenti mari 4 agenti in apartamente
1 agenti mici 5 agenti desfiintati
3- asociatii de locatari



Structurile tabelelor, semnificatiile campurilor si secventele de continut TIPURI:

tip codul serviciului prestat
produs denumirea serviciului
pret pretul de cost al serviciului
um unitatea de masura
Temei legea sau hotarrea care sta la baza prestarii serviciului.


Structurile tabelelor, semnificatiile campurilor si secventele de continut FACTURI:

coda codul agentului pret pret pe unitate de masura
numar numarul facturii cant cantitatea
data data emiterii facturii val valoarea fara TVA a serviciului
datas data scadentei facturii Tva valoarea pentru TVA
tip codul pentru serviciul prestat Vt valoarea totala
um unitatea de masura pentru serviciul prestat




Stabilirea tabelelor de fapte si a tabelelor dimensiune pentru acest exemplu

tabelul FACTURI poate fi stabilit ca tabel de fapte
Faptele care descriu tranzactiile efectuate sunt:
Cantitatile facturate
Valoarea fara TVA
Valoarea TVA
Valoarea totala
tabelele: AGENTIM si TIPURI sunt tabele dimensiune - fiecare trazactie este interpretata din
aceste perspective

Tehnologia OLAP (On Line Analytical Processing)

Tehnologiile OLAP sunt concepute pentru exploatarea bazelor de date multidimensionale i au
ca rol exploatarea facil a dimensiunilor n care sunt structurate datele.

Soluiile OLAP se bazeaz pe principiul restructurrii datelor n formatul multidimensional de
hypercub.

Tehnicile OLAP se bazeaz pe metodologia proprie de structurare a datelor ntr-un context
decizional, pe tehnici specifice sistemelor de gestiune a bazelor de date i pe instrumente specifice
de exploatare a structurilor de date.

OLAP Report a enunat o definiie simpl i la obiect constnd n cinci cuvinte pentru tehnologia
OLAP: Fast Analysis of Shared Multidimensional Information (pe scurt FASMI):
Fast Se refer la timpul rapid de rspuns i presupune ca sistemul s returneze rezultatele
solicitate de utilizatori ntr-un timp mai mic de 5 secunde. Se are n vedere obinerea unui timp de
rspuns sub o secund pentru cele mai simple analize.
Analysis Analiza presupune ca sistemul s fac fa analizelor statistice i cerinelor
domeniului astfel nct s poat fi considerat relevant de ctre utilizatorii int. Este necesar s li
se permit utilizatorilor definirea de noi calcule ca parte integrant a procesului de analiz i de
oferire de instrumente de raportare a datelor n forma dorit fr a necesita cunotine de
programare.
Shared Partajarea presupune ca sistemul s implementeze toate necesitile de securitate
pentru asigurarea confidenialitii.
n funcie de volumul de date gestionat de sistem i de tendina lor de evoluie, este necesar de
multe ori efectuarea unor copii de siguran pentru date, caz n care, pentru ncadrarea in
categoria OLAP, trebuie ca sistemul s realizeze aceste operaii ntr-un timp satisfctor i n
condiii de maxim securitate.
Multidimensional Existena mai multor dimensiuni de analiz este caracteristica cheie a
sistemelor de tip OLAP. Aceast caracteristic presupune ca sistemul s permit reprezentarea
unui model conceptual multidimensional al datelor, incluznd i posibilitatea reprezentrii
ierarhiilor multiple.
Information Informaia provine din exploatarea ansamblului de date, dar i din mediul
exterior sistemului. Msurarea acestei caracteristici se refer la stabilirea cantitii de date primare
de intrare pe care o prelucreaz sistemul i nu a numrului de gigabiti afectai pentru stocarea lor.

OLAP utilizeaz baze de date multidimensionale, prin contrast cu bazele de date relaionale care
sunt bidimensionale prin definiie.
O facilitate extrem de puternic oferit de OLAP este posibilitatea de a construi scenarii i n
consecin, posibilitatea de a rspunde la ntrebri de tipul ce ar fi dac? n timp ce depozitele de
date pot oferi rspunsuri numai la ntrebri de tipul Cine?, Ce?, Unde?, Cnd?.


OPERAII OLAP N MODELE DE DATE MULTIDIMENSIONALE

Operaiunile OLAP asupra cubului de date ofer o flexibilitate sporit pentru a materializa diferite
viziuni (views), permind interogri i analize interactive:
Drill-up (roll-up); Slice;
Drill-down; Pivot (rotate).
Dice;

Drill-up execut agregri pe cubul de date, prin escaladarea ierarhiei pentru o dimensiune sau prin
reducerea dimensiunii. De exemplu, pt. cubul central de date de mai jos:





Aceast ierarhie a fost definit prin ordinea total : strada <localitate < jude < regiune.
Operaiunea Drill-up de mai sus realizeaz agregarea datelor parcurgnd ascendent ierarhia zona de la
nivelul localitate la nivelul regiune.

Cnd drill-up-ul este executat prin reducerea dimensiunii, una sau mai multe dimensiuni sunt terse din
cub. De exemplu, considerm cubul de date vnzri numai cu dou dimensiuni: zona i timp. Roll-up
poate fi executat prin tergerea fie a dimensiunii timp, rezultnd o agregare a vnzrilor pe zone, fie a
dimensiunii zona, rezultnd o agregare n timp.







Rezultatul operaiunii drill-up, parcurgnd conceptul ierarhic zona de jos n sus, este:
Drill-down - este opusul operaiunii drill-up. Parcurgerea ierarhiei este de la cele mai puin detaliate
niveluri la cele mai detaliate.
Drill-down poate fi realizat fie prin parcurgerea descendent a ierarhiei pentru o dimensiune, sau prin
introducerea de dimensiuni suplimentare.

Rezultatul unei operaii drill-down executate pe cubul central prin parcurgerea conceptului ierarhic pentru
timp definit astfel: zi < luna < trimestru < an:


Drill-down merge descendent pe ierarhia timp, de la nivelul trimestru la un nivel mai detaliat- luna.
Cubul de date rezultat detaliaz vnzrile pe lun .
ntruct un drill-down adaug mai multe detalii la date, el poate fi, de asemenea, executat prin adugarea
unei noi dimensiuni la cub.
De exemplu, un drill-down pe cubul central anterior, poate determina introducerea unei dimensiuni
suplimentare cum ar fi tip client.

Slice - execut o selecie pe o dimensiune a unui cub dat .

Exemplu: o operaiune slice unde vnzrile sunt selectate de la cubul central pentru dimensiunea timp
utiliznd criteriul timp = T1:












Dice - definete un subcub prin mai multe dimensiuni.

De exemplu o operaiune dice bazat pe urmtorul criteriu de selecie:
(zona =Tulcea or Vaslui and (trim = T1 or T2) and (articol =service or calculatoare)















Pivot (rotate) - rotete axele de vizualizare a datelor n ordinea cerut de alternativa prezentrii lor.

De exemplu o operaie pivot unde sunt rotite axele pentru articol i zona n 2-D.
Rotaia axelor se poate aplica i pentru reprezentri 3-D.













ALTE ASPECTE PRIVIND CUBUL DE DATE

n literatura data warehouse cubul de date este denumit cuboid.

Stabilind setul de dimensiuni, putem construi matricea cuboidului, fiecare prezentnd datele cu diferite
niveluri de sintetizare sau grupare (group by).
Matricea cuboidului este referit tot ca un cub de date.
Exemplu: matricea cuboidului formnd cuburi de date pentru dimensiunile: timp, articole, zon, furnizor:


Cuboidul situat la nivelul cel mai de jos este numit cuboid de baz :
cuboidul 4D este cuboid de baz pentru dimensiunile timp, articol, zon i furnizor.

Cuboidul 0D care ne arat cel mai nalt nivel de sintetizare este numit apex cuboid (cuboid vrf). n
acest exemplu acesta este totalul vnzrilor, sau nsumarea vnzrilor n lei pentru toate cele 4
dimensiuni.
Cuboidul vrf este, n mod obinuit, denumit cu all (toate).