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 conţin date preluate din surse interne şi externe ale organizaţiilor.

Categorii: Sisteme informatice executive (Executive Information Systems);

Sisteme suport de decizie spaţiale;

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 colecţie de date orientată pe subiect, integrată,

dependentă de timp şi nevolatilă, destinată pentru a susţine procesul decizional dintr-o organizaţie”:

Orientată pe subiect. Într-un depozit, datele sunt organizate în funcţie de subiectele importante pentru

organizaţie, cum ar fi clienţii, produsele şi activităţile. Astfel un data warehouse poate oferi o viziune

simplă şi concisă despre un subiect specific, eliminând 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 relaţionale, fişiere, foi de calcul tabelar, chiar documente). Pentru

asigurarea consistenţei şi coerenţei informaţiilor au fost elaborate o serie de tehnici de curăţire a datelor

(data cleaning).

Nevolatilă. Datele stocate într-un depozit sunt permanente şi nu pot fi modificate. În accepţiunea data

warehouse operaţia de actualizare se referă la adăugarea de noi date din sursele existente, fără a modifica

sau şterge înregistrările anterioare. Înregistrările unui depozit sunt memorate separat din punct de vedere

fizic de datele ce urmează să fie procesate de alte aplicaţii.

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 tranzacţionale poate lua valori

între 60 şi 90 de zile. De asemenea, structura cheilor conţine implicit sau explicit un element de timp.

Construirea unui depozit de date este un proces lung şi complex. De aceea, unele organizaţii 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 vânzări, finanţe, asigurări)

- e construit şi folosit de un singur departament al unei organizaţii

- preia date din sistemul operaţional intern al organizaţiei, din depozitul de date central sau din surse

externe.

Clasificarea depozitelor de date în funcţie 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 cât ş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 legăturile lor reciproce, precum

şi cu mediul înconjurător;

depozitul de date departamental (departamental data warehouse/DDW) asistă procesele decizionale

care privesc oricare şi toate compartimentele şi interacţiunile lor reciproce, precum şi cu mediul

înconjurător;

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 uşor conexiuni la depozitul de date a cărui securitate va fi asigurată fie prin

intermediul aplicaţiei ce asigură interfaţa, fie prin serverul bazei de date.

Prezentarea unei sigure versiuni a realităţii

Întrucât datele memorate în depozitele de date au fost deja validate în sistemele operaţionale ale

organizaţiei, pot fi considerate pertinente şi valide asigurând o imagine fidelă a realităţii.

Înregistrarea cu acurateţe a datelor istorice

Cele mai multe dintre situaţiile necesare la fundamentarea deciziilor implică prezentarea unor informaţii

actuale comparativ cu informaţii similare din perioadele precedente. Majoritatea sistemelor

informaţionale nu sunt create pentru a furniza situaţii 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 tranzacţiilor curente.

Posibilitatea de a oferi rapid acces atât la datele de sinteză, cât şi la cele de detaliu

Prin intermediul rapoartelor dinamice şi a instrumentelor de interogare OLAP sunt oferite facilităţi de

vizualizare a informaţiilor sub unghiuri diferite şi la niveluri diferite de detaliere. Astfel se reduce timpul

necesar pentru colectarea, formatarea şi filtrarea informaţiilor plecând de la date.

Separarea prelucrărilor de nivel operaţional şi analitic

Sistemele operaţionale clasice, axate pe prelucrarea datelor, nu sunt create pentru a deservi procesele

decizionale. Încercările de a reuni în acelaşi sistem informaţiile operaţionale şi cele decizionale poate

afecta funcţionarea programelor. Pornind de la procesele operaţionale depozitele de date prezintă o

arhitectură distinctă proiectată special pentru activităţi decizionale.

Arhitectura depozitelor de date

- Într-un depozit de date pot fi memorate tipuri de date diverse necesare pentru a satisface cerinţele

informaţionale ale mai multor tipuri de utilizatori (date detaliate, date agregate, metadate).

- Metadatele precizează structura datelor având rolul de a descrie datele colectate în depozit şi modul în

care acestea sunt obţinute ş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 operaţionale curente,

arhivele bazelor de date operaţionale, dar şi baze de date externe.

Proiectarea depozitelor de date:

Etapele generale ale procesului de proiectare data warehouse:

Colectarea informaţiilor privind obiectivele şi necesităţile sistemului şi delimitarea procesului

economic ce va fi modelat (în acest stadiu se va stabili oportunitatea realizării unui depozit de date sau

a unui data mart).

Alegerea dimensiunilor ce vor fi aplicate înregistrărilor din tabelul de fapte (exemple de

dimensiuni: timp, firma, furnizor, etc.).

Alegerea măsurilor 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 coerenţa între viziunile grupurilor de

utilizatori.

2) acest model superior va putea fi extins şi rafinat pe măsura dezvoltării sistemului şi va minimiza

riscurile apariţiei problemelor de integrare.

3) în paralel se vor implementa, la nivel departamental, data marts bazate pe acelaşi 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 organizaţii:

1. Identificarea cerinţelor informaţionale şi studiul proceselor economice.

2. Determinarea necesităţilor impuse de dezvoltarea depozitului de date pentru suportul hardware.

3. Identificarea surselor de date şi modelarea datelor.

4. Extragerea, transformarea şi încărcarea datelor.

5. Proiectarea cuburilor OLAP

6. Proiectarea aplicaţiilor client pentru exploatarea depozitului de date.

7. Optimizarea performanţelor.

8. Testarea funcţionalităţii şi controlul calităţii componentelor realizate.

9. Lansarea depozitului de date în exploatare.

10. Asigurarea exploatării în condiţii optime şi asistarea utilizatorilor.

11. Determinarea eventualelor noi cerinţe informaţionale.

Noţiuni 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 noţiunii de cub tridimensional la cub n-dimensional sau hipercub.

Cubul de date permite modelarea si vizualizarea datelor în dimensiuni multiple.

Consiliul OLAP defineşte 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 rânduri şi coloane, fiecare fiind o dimensiune. O matrice tridimensională poate fi vizualizată ca un cub

cu fiecare dimensiune formând o faţă a cubului........Dimensiunile tipice ale datelor dintr-o întreprindere

sunt timpul, măsurile, produsele, regiunile geografice, canalele de distribuţie etc.”

Dimensiunile reprezintă categorii de informaţie. Dimensiunile sunt atribute de identificare a

evenimentelor măsurabile sau a lucrurilor pe care le analizăm.

Într-un cub n-dimensional (hypercub) o dimensiune este reprezentată printr-o axă;

De exemplu, într-o bază de date pentru analiza vânzărilor se identifică următoarele dimensiuni: Timp,

Regiune/locaţie, Client, Agent de vânzare, Produs.

Exemplul cel mai des întâlnit î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 atât o

bună cunoaştere a domeniului economic de către proiectant.

O dimensiune conţine mai mulţi membri (atribute). De exemplu, toate lunile, trimestrele şi anii formează

dimensiunea Timp şi toate oraşele, regiunile şi ţările dimensiunea Locaţie.

Atributele unei dimensiuni se poziţionează î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, săptămâni, luni, trimestre şi ani), Locaţia geografică este o dimensiune ierarhică

(vecini, oraşe, 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 mulţi membri au conexiuni în sus şi jos, în ierarhie.

Conexiunile în sus sunt de tip (m:1) şi sunt numite asocieri părinte. Conexiunile în jos sunt de tip (1:m) şi

sunt numite asocieri copil.

Un membru ce nu are părinte se numeşte membru radăcină (root).

Membrii ce nu au copii sunt numiţi frunză (scaune, paturi, mese, radio cu baterii, televizoare color etc).

Pentru a identifica poziţia unui membru într-o dimensiune se folosesc conceptele de înălţime şi adâncime

în ierarhie. Înălţimea se stabileşte de jos în sus. Din acest motiv nivelul (L0) al ierarhiei reprezintă

nodurile frunză ale ierarhiei (înălţimea cea mai mică).

Adâncimea în ierarhie este stabilită de sus în jos. Există posibilitatea ca doi membri, care au aceeaşi

înălţime, să aibă adâncimi diferite şi invers (structuri arborescente neechilibrate).

Alte exemple de ierarhii :

Dimensiunea Timp şi arborele ierarhic aferent :

Dimensiunea Firme şi arborii ierarhici aferenţi :

Dimensiunea Conturi şi arborii ierarhici aferenţi :

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 vânzari 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 măsură într-un cub de date este o funcţie numerică ce poate fi evaluată în fiecare punct din spaţiul

cubului de date. Măsurile reprezintă valorile centrale care sunt analizate prin cubul de date.

Valoarea măsurii 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 vânzări :

conţine două măsuri numite vânzări-lei şi cantitate-vândută.

Deci o măsură (variabilă) este un indicator de performanţă prin care se poate analiza performanţa

activităţii modelate.

Măsurile pot fi clasificate după posibilitatea de a se însuma după dimensiuni:

măsuri aditive - care se pot însuma după toate dimensiunile.

De exemplu, măsura “volumul vânzărilor” se poate calcula pentru o categorie de produse sau pentru o

anumită regiune sau pentru a anumită perioadă de timp.

măsuri semiaditive - care se pot însuma numai după unele dimensiuni.

De exemplu, măsura “numărul de clienţi” este semiaditivă, deoarece se poate calcula numărul de clienţi

î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 cunoaşte numărul de clienţi şi dorim

să aflăm numărul de clienţi pentru categoria de produse, nu se pot aduna aceste numere. Rezultatul poate

fi eronat, deoarece pot exista clienţi, care au cumpărat mai multe tipuri de produse, din categoria

respectivă.

măsuri 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 conţine măsurile activităţii (de exemplu cifra de afaceri sau

suma salariilor pot reprezenta astfel de măsuri).

Exemple de fapte întâlnite în tabele de fapte pentru diferite domenii de activitate:

• Comerţ cu amănuntul: cantitatea vîndută , valoarea vânzărilor;

• Telecomunicaţii: durata convorbirilor în minute, numărul mediu de apeluri;

• Bănci: valoarea operaţiunilor, numărul mediu de operaţiuni;

• Asigurări: valoarea despăgubirilor

• Transport aerian: preţul biletelor, greutatea bagajelor.

Faptele sunt valori numerice pe care utilizatorii le analizează şi le sintetizează pentru a înţelege mai bine

diverse aspecte ale afacerii.

În tabela de fapte măsurile sunt stocate conform granularităţii stabilite a depozitului.

Pe lângă măsuri, tabela de fapte conţine şi chei externe ce creează legătura cu tabelele de tip nomenclator

asociate dimensiunilor.

Fiecare dimensiune poate avea un tabel asociat cu ea, numit tabel dimensiune, care conţine informaţiile

detaliate despre atributele dimensiunilor.

Tabelele dimensiune conţin câmpuri care descriu faptele.

Exemple de atribute pentru tabele dimensiune din domeniile prezentate mai sus la tabelele de fapte:

• Comerţ cu amănuntul: denumirea magazinului, codul magazinului, denumirea produsului, categoria

produsului, ziua din săptămână ;

• Telecomunicaţii: originea apelului, destinaţia apelului

• Bănci: numele clientului, numărul contului, data, domeniul de activitate al clientului, numele

administratorului de cont;

• Asigurări: tipul poliţei de asigurare, bunurile asigurate;

• Transport aerian: numărul zborului, destinaţia zborului, clasa de călătorie.

Granularitatea reprezintă gradul de detaliere a depozitului. Astfel, în funcţie de granularitatea stabilită, se

poate specifica cifra de afaceri la nivel de zi sau la nivel de lună.

În determinarea granularităţii depozitului sunt parcurse două etape:

1. Se vor determina dimensiunile ce vor fi luate în consideraţie pentru măsurile din tabela de fapte.

2. Se va stabili pentru fiecare dimensiune, în cadrul ierarhiei, până la ce nivel de detaliu este necesar şi

util să se ajungă.

Obs:

1) Un model multidimensional va include cel puţin o tabelă de fapte şi mai multe tabele dimensiune.

2) Relaţiile 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 următoarele categorii:

Tabele de tip cumulativ – tabele în care majoritatea faptelor sunt de tip cumulativ şi, în general, au

rolul de a urmări evoluţia 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 evoluţia factorilor analizaţi 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 “Locaţie Geografică”)

Parţial aditive – în cazul în care însumarea valorilor în cadrul ierarhiilor dimensiunilor are sens doar

pentru anumite dimensiuni (de exemplu soldul contului de disponibilităţi poate fi însumat în cadrul unei

dimensiuni reprezentând 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 corespunzătoare

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 întâlnite reprezentări ale modelului multidimensional de date sunt schemele „stea”, “fulg

de zăpadă” şi “constelaţie”.

Fie modelul relaţional al unei baze de date pentru facturarea produselor vândute de către o firmă care

dispune de mai multe puncte de desfacere (magazine):

Schema stea a modelului relaţional al bazei de date pentru facturarea produselor:

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

Tabelul ce conţine faptele ocupă poziţia centrală şi este conectat la tabelele dimensiune pe baza cheilor

externe pe care acestea le conţin. Alt exemplu: schema stea a unui depozit de date pentru vânzări :

măsuri

Schema fulg de zăpadă (snowflake) a modelului relaţional 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 împărţite în tabele suplimentare.

Tabelele dimensiune sunt proiectate respectând regulile de normalizare din modelul relaţional, conferind

astfel o economie de spaţiu în depozitul de date.

Alt exemplu: schema fulg de zăpadă a depozitului de date pentru vânzări din exemplul anterior :

Schema constelaţie (constelaţie de fapte):

Acest model apare în cazul existenţei mai multor tabele de fapte ce utilizează aceleaşi tabele-dimensiune.

În acest exemplu s-a dorit adăugarea î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 adăuga

un tabel de fapte ce exploatează dimensiunile comune.

Numele de constelaţie provine din faptul că acest model are la bază modelul stea, dar conţine mai multe

tabele de fapte. În unele lucrări de specialitate modelul este denumit “galaxie”.

Alt exemplu: schema constelaţie a depozitului de date pentru vânzări din exemplul anterior, la

care se adaugă tabela de fapte Shipping :

Exemple de definire a schemelor stea, fulg de zăpadă şi constelaţie 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 relaţional de interogare cum este SQL poate fi utilizat pentru a specifica interogările

Un limbaj pentru mineritul datelor poate fi utilizat pentru specificarea sarcinilor data mining. Limbajul SQL bazat pe data mining (Data Mining Query Language - DMQL) conţine şi primitive

pentru definirea depozitelor de date şi a data marts.

Un depozit de date sau un data mart poate fi definit utilizând 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. vânzări 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. vânzări 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, vânzari). 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_vânduta).

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 – câmpuri 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 hotarârea 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.

►Soluţiile OLAP se bazează pe principiul restructurării 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 enunţat o definiţie simplă şi la obiect constând în cinci cuvinte pentru tehnologia

OLAP: Fast Analysis of Shared Multidimensional Information (pe scurt FASMI):

Fast – Se referă la timpul rapid de răspuns şi presupune ca sistemul să returneze rezultatele

solicitate de utilizatori într-un timp mai mic de 5 secunde. Se are în vedere obţinerea unui timp de

răspuns sub o secundă pentru cele mai simple analize.

Analysis – Analiza presupune ca sistemul să facă faţă analizelor statistice şi cerinţelor

domeniului astfel încât să poată fi considerată relevantă de către 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ă fără a necesita cunoştinţe de

programare.

Shared – Partajarea presupune ca sistemul să implementeze toate necesităţile de securitate

pentru asigurarea confidenţialităţii.

În funcţie de volumul de date gestionat de sistem şi de tendinţa lor de evoluţie, 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 operaţii într-un timp satisfăcător şi în

condiţii de maximă securitate.

Multidimensional – Existenţa 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, incluzând şi posibilitatea reprezentării

ierarhiilor multiple.

Information – Informaţia provine din exploatarea ansamblului de date, dar şi din mediul

exterior sistemului. Măsurarea acestei caracteristici se referă la stabilirea cantităţii de date primare

de intrare pe care o prelucrează sistemul şi nu a numărului de gigabiti afectaţi pentru stocarea lor.

OLAP utilizează baze de date multidimensionale, prin contrast cu bazele de date relaţionale care

sunt bidimensionale prin definiţie.

O facilitate extrem de puternică oferită de OLAP este posibilitatea de a construi scenarii şi în

consecinţă, posibilitatea de a răspunde la întrebări de tipul „ce ar fi dacă?“ în timp ce depozitele de

date pot oferi răspunsuri numai la întrebări de tipul „Cine?“, „Ce?“, „Unde?“, „Când?“.

OPERAŢII OLAP ÍN MODELE DE DATE MULTIDIMENSIONALE

Operaţiunile OLAP asupra cubului de date oferă o flexibilitate sporită pentru a materializa diferite

viziuni (views), permiţând interogări şi analize interactive:

• Drill-up (roll-up); • Slice;

• Drill-down; • Pivot (rotate).

• Dice;

Drill-up execută agregări 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.

Operaţiunea Drill-up de mai sus realizează agregarea datelor parcurgând ascendent ierarhia zona de la

nivelul localitate la nivelul regiune.

Când drill-up-ul este executat prin reducerea dimensiunii, una sau mai multe dimensiuni sunt şterse din

cub. De exemplu, considerăm cubul de date vânzări numai cu două dimensiuni: zona şi timp. Roll-up

poate fi executat prin ştergerea fie a dimensiunii timp, rezultând o agregare a vânzărilor pe zone, fie a

dimensiunii zona, rezultând o agregare în timp.

Rezultatul operaţiunii drill-up, parcurgând conceptul ierarhic zona de jos în sus, este:

Drill-down - este opusul operaţiunii drill-up. Parcurgerea ierarhiei este de la cele mai puţin 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 operaţii 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ă vânzările pe lună .

Íntrucât un drill-down adaugă mai multe detalii la date, el poate fi, de asemenea, executat prin adăugarea

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 selecţie pe o dimensiune a unui cub dat .

Exemplu: o operaţiune slice unde vânzările sunt selectate de la cubul central pentru dimensiunea timp

utilizând criteriul timp = “T1“:

Dice - defineşte un subcub prin mai multe dimensiuni.

De exemplu o operaţiune dice bazată pe următorul criteriu de selecţie:

(zona =”Tulcea“ or “Vaslui“ and (trim = “T1“ or “T2“) and (articol =“service“ or “calculatoare“)

Pivot (rotate) - roteşte axele de vizualizare a datelor în ordinea cerută de alternativa prezentării lor.

De exemplu o operaţie pivot unde sunt rotite axele pentru articol şi zona în 2-D.

Rotaţia axelor se poate aplica şi pentru reprezentări 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 prezentând datele cu diferite

niveluri de sintetizare sau grupare (group by).

Matricea cuboidului este referită tot ca un cub de date.

Exemplu: matricea cuboidului formând 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 vârf). Ín

acest exemplu acesta este totalul vânzărilor, sau însumarea vânzărilor în lei pentru toate cele 4

dimensiuni.

Cuboidul vârf este, în mod obişnuit, denumit cu all (toate).