Arhitectura sistemelor OLAP

download Arhitectura sistemelor OLAP

of 13

Transcript of Arhitectura sistemelor OLAP

  • 8/8/2019 Arhitectura sistemelor OLAP

    1/13

    Arhitectura sistemelor OLAP

    5-1

    5. Arhitectura sistemelor OLAP

    Sistemele OLAP permit analitilor i managerilor s mbunteascperformanele unei firme, printr-un acces interactiv rapid la o mare varietate de viziunide date organizate, pentru a reflecta aspectul multidimensional al datelor dintr-ontreprindere. Modelul conceptual multidimensional este cel mai natural mod de avizualiza informaiile din afaceri. Dar stocarea acestor volume mari de informaiimultidimensionale, ntr-un mod practic pe calculator, este departe de a fi uor. Datelemultidimensionale nu trebuie s fie numai stocate ci trebuie s fie vizualizate,actualizate i folosite pentru calculul altor rezultate, preferabil n mai puin de cincisecunde. Modul cum sunt stocate va afecta performana i funcionalitatea la fiecare dincelelalte cerine. Din acest motiv, instrumentele OLAP trebuie s ofere un rspunsrapid, indiferent de volumul de date ce trebuie utilizat pentru o simpl interogare.Timpul de rspuns pentru o cerere ar trebui s depind de numrul de rezultate afiate

    pe ecran i nu de dimensiunea bazei de date. n practic, cele mai multe aplicaii OLAPsunt foarte mprtiate. n general mai puin de o celul dintr-o mie de celule are date.

    Deoarece aplicaiile OLAP sunt de fapt sisteme suport de decizie interactive, esteimportant ca ele s rmn rapide, chiar dac baza de date este mare i mprtiat. Seurmrete s se consume mai puin spaiu fizic pentru stocarea informaiilor lips sau aindecilor. Multe soluii posibile exist, fiecare cu avantaje i dezavantaje.

    Factorii ce determin alegerea unei soluii sunt : Volumul de date curente stocat. Dac volumul este relativ mic, o stocare n

    RAM ar fi cea mai bun soluie; Gradul de mprtiere a datelor. Dac datele sunt foarte mprtiate, poate fi

    necesar o indexare mai complex i compresia datelor, care vor faceinstrumentul mai lent;

    Frecvena de actualizare a datelor i modul cum se face actualizarea (n loturisau celule individuale);

    Numrul de utilizatori; Tipul arhitecturii client/server (unde are loc procesarea multidimensional); Cantitatea de memorie real i virtual valabil. Aceasta va determina cte date

    active trebuie pstrate n memorie; Performana discului i a microprocesorului; Frecvena de modificare a dimensiunilor bazei de date etc.

    innd cont de aceti factori, proiectanii de instrumente OLAP selecteaztehnicile pe care le vor utiliza pentru a stoca i gestiona datele multidimensionale,

    pentru aceste aplicaii. Astfel, nici un instrument nu este optim pentru orice aplicaie

  • 8/8/2019 Arhitectura sistemelor OLAP

    2/13

    Arhitectura sistemelor OLAP

    5-2

    OLAP. Toate instrumentele folosesc o combinaie de tehnici. Prima decizie ce trebuieluat este de a stabili unde sunt stocate datele din model, cnd sunt procesate iaccesate.

    n ultimii ani, un numr mare de instrumente OLAP permit stocarea datelor attn baze de date relaionale ct i multidimensionale. Astfel, modul de stocare a datelor adevenit un criteriu de clasificare a sistemelor OLAP i anume n: sisteme ROLAP,

    sisteme MOLAP i sisteme HOLAP. n acest capitol, se vor prezenta comparativ acestesisteme. Se va pune accentul pe avantajele i dezavantajele lor, precum i pe tipurile deaplicaii pentru care sunt destinate. n finalul capitolului, se prezint comparativ tipurilede arhitecturi specifice sistemelor OLAP.

    5.1. Sisteme ROLAP

    n ultimii ani, un numr mare de instrumente OLAP permit stocarea datelormultidimensionale n baze de date relaionale (depozite de date). Chiar dac o aplicaieOLAP stocheaz toate datele sale ntr-o baz de date relaional, totui ea va lucraseparat, pe o copie separat a datelor (depozite de date/centre de date), nu pe baza de

    date tranzacional. Aceasta permite s fie structurat optim pentru OLAP mai binedect pentru alte aplicaii. Datele multidimensionale pot fi stocate n depozite dedate/centre de date, utiliznd schema stea sau fulg de zpad. Problema este de a oferiacces rapid i flexibilitate n manipularea multidimensional. Totui tabela de fapte esteun mod ineficient de a stoca volume mari de date. Dac sunt multe variabile, exist

    posibilitatea de a nu le putea stoca pe toate ntr-o singur tabel de fapte (gradul demprtiere poate diferi mult ntre grupurile de variabile). Datele pot fi ncrcate dinmultiple surse, astfel actualizrile unei singure tabela de fapte foarte mare suntineficiente. De aceea, n aplicaiile complexe, tabela de fapte este partiionat n grupuride variabile dup gradul de mprtiere, stabilindu-se, de asemenea, dimensiunilecorespunztoare i sursele de date. n aplicaiile OLAP complexe pot exista 10..20 detabele de fapte. Pentru o bun performan la interogare, unele agregri trebuie

    antecalculate i stocate n tabele de agregate. n aplicaiile complexe pot exista mii detabele de agregate.n figura 5-1, este prezentat arhitectura unui sistem ROLAP. Un motor ROLAP

    face trecerea dinamic ntre modelul de date multidimensional logic Mi modelul destocare relaional R. Tehnic vorbind acest motor implementeaz o transformare a uneicereri multidimensionale m pe modelul de date multidimensional logic M, ntr-o cerererelaional r pe modelul de stocare R. Eficiena la interogare este factorul dominatasupra performanei globale a sistemului i scalabilitii. Strategiile de optimizare suntfactorii principali n diferenierea sistemelor ROLAP existente. Preocuparea major estegsirea celei mai eficiente reprezentri a cererii pentru un SGBDR dat i a schemei date,

    precum i ncrcarea dinamic echilibrat ntre SGBDR i motorul ROLAP. ntructoptimizatorul de cereri al SGBDR ar putea s nu fie capabil s aleag planul de execuie

    optim pentru cereri, unele instrumente (de exemplu DSS Server/Microstrategy) mpartcererea complex n mai multe subcereri, care sunt executate secvenial (SQL n maimuli pai). S considerm QR(m) setul tuturor reprezentrilor relaionale ale cereriimultidimensionle m pentru modelul relaionalR (incluznd toate variantele n mai muli

    pai). Pentru fiecare cerere, motorul ROLAP trebuie s aleag o reprezentare optim pebaza unui criteriu (de exemplu performana cererii).

    Unele operaii multidimensionale nu pot fi exprimate uor folosind limbajulSQL. Este necesar pentru motorul ROLAP s implementeze aceste operaii folosindstructuri de date multidimensionale. Aceasta complic problema de optimizare prin

  • 8/8/2019 Arhitectura sistemelor OLAP

    3/13

    Arhitectura sistemelor OLAP

    5-3

    extinderea spaiului de cutare QR(m). ncrcarea echilibrat ntre serverul de baz dedate i motorul ROLAP este un rezultat al strategiei utilizate pentru a alege cerereaoptim. Evaluarea operaiilor multidimensionale de ctre motorul ROLAP poate reducetimpii de procesare a unei cereri dar i scalabilitatea global a sistemului.

    Factorii ce influeneaz decizia de optimizare pot fi mprtii n statici idinamici (ce pot fi evaluai numai la momentul execuiei). Factorii statici sunt: natura

    operaiei multidimensionale, complexitatea operaiei executate de motorul ROLAP fade complexitatea implementrii relaionale. Factorii dinamici includ caracteristicile dencrcare ale serverului de baz de date i ale motorului ROLAP, volumul datelorcurente ce trebuie s fie transferate de la sistemul relaional la motorul ROLAP. Deexemplu, Decision Suite/Microstrategy permite administratorului s determine locaia

    procesrii prin metadate.

    Alte probleme ale instrumentelor ROLAP sunt: i) metamodelele (pentru oschem stea sau fulg de zpadmetamodelul este foarte important); ii) seturile defuncii complexe etc. Limbajul SQL standard nu permite operaii multidimensionale.Specialitii ofer trei soluii pentru a aduga funcionalitate multidimensional la datelestocate n tabelele SQL : i) integrarea procesrii multidimensionale n sistemul degestiune a bazei de date relaionale, fie prin extinderea limbajului SQL sau prinadugarea funcionalitii multidimensionale n nucleul SGBD-ului; ii) executarea nmai muli pai a comenzilor SQL (multipass SQL). Instrumentul OLAP realizeaz oserie de comenzi SELECT, n care ieirile comenzilor anterioare sunt stocate n tabele

    temporale, care sunt apoi utilizate de comenzile urmtoare; iii) ncrcarea datelorrelevante din tabelele corespunztoare pe un server de aplicaie intermediar, unde esterealizat procesarea multidimensional.

    Datorit modului complicat n care datele sunt stocate pe disc, instrumenteleOLAP ce folosesc baze de date relaionale permit numai citirea datelor. Alteinstrumente trebuie s fie utilizate pentru actualizarea datelor de baz i a tabelele deagregate. Aceste instrumente ROLAP nu pot fi folosite pentru analize de tip what-if.

    Aplicaia analitic client

    Motor ROLAP

    SGBDR

    Figura 5-1. Arhitectura unui sistem ROLAP

    Clieni OLAP

    optimizarea cerererii procesarea multidimensionalmultidimensionale

    generarea cererii transformarerela ionale

    metadate

    Interfaa

    multidimensional

    SQL interfaarelaional

  • 8/8/2019 Arhitectura sistemelor OLAP

    4/13

    Arhitectura sistemelor OLAP

    5-4

    n concluzie, stocarea datelor multidimensionale se face ntr-o baz de daterelaional atunci cnd:

    Volumul de date este prea mare pentru a fi duplicat. Datele atomice nu suntcopiate n baza de date multidimensional ci sunt stocate n baze de daterelaionale surs (depozite de date/ centre de date) i citite cnd este nevoie.

    Datele surs se modific frecvent i este mai bine de a citi n timp real dect dincopii.

    Integrarea cu alte sisteme informatice relaionale existente. Firma are o politic de neduplicare a datelor n alte structuri de fiiere, pentru

    securitate sau alte motive, chiar dac aceasta conduce la aplicaii mai puineficiente.Cteva avantaje ale sistemelor ROLAP sunt: i) se integreaz cu tehnologia i

    standardele existente; ii) sistemele MOLAP nu permit cereri ad-hoc eficace, deoarecesunt optimizate pentru operaii multidimensionale; iii) actualizarea sistemelor MOLAPeste dificil; iv) sistemele ROLAP sunt adecvate pentru a stoca volume mari de date,

    prin utilizarea procesrii paralele i a tehnologiilor de partiionare etc; v) sistemeleMOLAP sunt limitate la 5-10 dimensiuni i sunt adecvate pentru aplicaiidepartamentale cu volume mici de date i dimensionalitate limitat, iar sistemele

    ROLAP au o arhitectur flexibil ce ofer suport pentru o varietate mare de SSD-uri icerine analitice (figura 5-2); vi) volatilitatea descrie gradul la care datele i structurilede date se modific n timp. Datele cu un nivel de volatilitate sczut rmn relativconstante. De exemplu, datele despre timp au un nivel sczut de volatilitate (zilele suntgrupate ntotdeauna n luni i lunile sunt ntotdeauna grupate n ani). Datele despre

    produse, angajai, clieni se modific frecvent. Volatilitatea datelor afecteaz cerinelede procesare n lot ale sistemului. Ori de cte ori datele atomice se modific, dateleagregate, ce au fost antecalculate, trebuie s fie recalculate. De aceea, datele volatile auun impact mai mare asupra unui sistem, care conine un volum mare de informaiiagregate, dect asupra unui sistem care calculeaz valorile agregate la momentulexecuiei. Att sistemele ROLAP ct i cele MOLAP sunt optime pentru aplicaii cuvolatilitate sczut a datelor. Pentru aplicaiile cu volatilitate ridicat a datelor, numaisistemele ROLAP sunt optime.

    5.2. Sisteme MOLAP

    Cel mai evident mod de a stoca datele multidimensionale este ca o simplmatrice. Spaiul este rezervat pentru fiecare combinaie posibil ntre membriidimensiunilor. n unele instrumente, numai valorile nenule sunt stocate. Numaimatricile ce conin date sunt stocate fizic. Fiecare dimensiune a matricii reprezint odimensiune a cubului. Coninutul matricii sunt msurile cubului. O astfel de matrice aremulte avantaje: se identific rapid locaia oricrei celule, iar celulele pot fi actualizate

    fr a afecta locaia fizic a celorlalte celule. Totui stocarea datelor pe disc folosind osimpl matrice, ce reflect direct viziunea utilizatorului, este foarte rar eficient. Chiari atunci cnd datele sunt stocate n memorie, este adesea necesar de a pstra datele ntr-un format mai complex dect o simpl matrice. Aceasta are legatur cu fenomenul demprtiere i cu cerina de a modifica dimensiunile, fr s fie nevoie s sereconstruiasc din nou ntreaga matrice. n cazul stocrii pe disc a datelor mprtiate,datele sunt citite n blocuri i dac fiecare bloc are un grad de mprtiere mare, multe

    blocuri goale sau aproape goale vor fi stocate n memorie, iar memoria va fi utilizat demult mai multe ori dect este necesar.

  • 8/8/2019 Arhitectura sistemelor OLAP

    5/13

    Arhitectura sistemelor OLAP

    5-5

    Sistemele MOLAP au pus accentul pe flexibilitatea i optimizarea tehnicilor destocare i pe conceptul de tranzacie. Sistemele MOLAP nu au nc o tehnologie pentru

    stocarea i gestionarea datelor unanim acceptat. Stocarea fizic a datelormultidimensionale, precum i fenomenul de mprtiere sunt preocupri majore, ndomeniul bazelor de date multidimensionale. O tehnic de stocare a datelor optim artrebui s in cont de muli factori dinamici i anume: i) profilul datelor i volumul lor(numrul de dimensiuni i membrii ai dimensiunilor, tipuri de date etc); ii) fenomenulde mprtiere (n care dimensiuni sau combinaii de dimensiuni, tipul de mprtiere);iii) frecvena de modificare n sursele de date (ct de des vor fi actualizate bazele dedate multidimensionale); iv) frecvena de modificare n datele multidimensionale (deexemplu pentru analiza de tip what if); v) frecvena de modificare n modelulmultidimensional (dimensiuni, membri ai dimensiunilor); vi) accesul concurent; vii)accesul la scriere etc.

    Ideal un SGBDMD ar trebui s aleag structura de date optim n funcie deaceti factori. n cele mai multe SGBDMD comerciale se utilizeaz o tehnic de stocare

    pe dou niveluri. La nivelul inferior sunt stocate toate dimensiunile dense. Nivelulsuperior conine dimensiunile mprtiate ca o structur index, care conine pointeri lacuburile de date dense din nivelul inferior.

    Unele dintre instrumentele OLAP ofer administratorului un numr foartelimitat de opiuni de optimizare. De exemplu, Arbor Essbase (Hyperion Essbase) are ometod proprie pentru stocarea i ncrcarea datelor multidimensionale n memorie.Aceasta metod utilizeaz o structur multinivel (cu un numr arbitrar de niveluri pentrudiferitele grade de mprtiere). Administratorul poate specifica dimensiunile dense imprtiate, care construiesc cele dou niveluri. Oracle Express suport, de asemenea, ostructur pe dou niveluri. Pilot Decision Support Suite (Pilot Software) suport aa

    numitele multicuburi. Timpul este tratat ca o dimensiune dens, iar toate celelaltedimensiunile sunt considerate mprtiate.O a dou problem este transferul conceptului de tranzacie aa cum este

    cunoscut i acceptat n lumea relaional la SGBDMD. Puine instrumente MOLAP (deexemplu Arbor Essbase ) permit acces multiutilizator concurent att la citire ct i lascriere. Majoritatea instrumentelor MOLAP permit acces multiutilizator la citire imonoutilizator la scriere. SGBDMD blocheaz ntreaga baz de date n timpulactualizrilor (care este o form foarte simpl de acces concurent). De asemenea, multeinstrumente MOLAP au o noiune foarte vag a conceptului de tranzacie. Modificrile

    Atomicitate(Gb) 1000

    1 2

    1003 ROLAP 4

    10

    5 6MOLAP

    10 100 1000 dimensionalitate

    1=SSD pentru analiza vnzrilor (activitate de comer) 4=SSD pentru analiza polielor de asigurare2=SSD pentru analiza promoional 5=EIS pentru analiza financiar3=SSD pentru analiza profitului bancar 6= SSD pentru analiza creditului bancar

    Figura 5-2. Utilizarea sistemelor MOLAP /ROLAP pentru diferite tipuri de aplicaii SSD

  • 8/8/2019 Arhitectura sistemelor OLAP

    6/13

    Arhitectura sistemelor OLAP

    5-6

    n cuburile de date pot fi executate ca adugri n cub sau n timpul analizei de tip whatif. Adesea ele cer o actualizare incremental a agregatelor sau msurilor, care suntcalculate pe baz de formul. Astfel de dependene fac actualizrile mult maicomplicate. Conceptul de tranzacie este legat de multe alte probleme cum ar fi:

    propietile ACID (atomic, consistency, isolation, durability). Pentru a realiza propietile ACID, toi termenii (n special consistena i izolarea) trebuie

    reanalizai. De exemplu, dependenele ntre datele de detaliu, datele agregate imsuri complic noiunea de consisten. mecanismul de blocare.Dac controlul concurenial este realizat printr-o tehnic

    de blocare, trebuie s fie definite modurile de blocare i nivelul la care se faceblocarea. Blocarea ntregii baze de date nu este o soluie foarte potrivit. Totuiinterdependenele ntre date fac ca definirea nivelurilor de blocare s fie o

    problem complex. strategia de propagare a modificrilor. Datele (agregate i msuri) trebuie

    modificate n conformitate cu modificrile din datele de detaliu sau din modelulde date.Sunt i alte probleme importante, deja rezolvate n SGBDR, dar care sunt

    nerezolvate sau numai parial rezolvate n SGBDMD cum ar fi: i) restaurarea bazei de

    date; ii) conceptul de tabel virtual; iii) baze de date distribuite etc.Avantajul sistemelor MOLAP este c ofer o viziune multidimensional direct

    a datelor, n timp ce sistemele ROLAP sunt o interfa multidimensional la datelerelaionale. SGBDMD cer antecalcularea tuturor agregatelor posibile, astfel sunt adeseamai performante dect SGBDR tradiionale, dar mai dificil de actualizat i administrat.Deoarece bazele de date multidimensionale folosesc acelai motor att pentru stocarect i pentru procesarea datelor i acest motor are informaii complete despre structurilede date multidimensionale i manipulrile multidimensionale, este uor pentruinstrument de a manipula datele multidimensionale i de a face calcule corecte icomplexe. Totui multe baze de date multidimensionale nu ofer facilitatea derecuperare a erorilor i alte faciliti specifice bazelor de date relaionale.

    Cteva avantaje ale sistemelor MOLAP sunt: i) tabelele relaionale nu suntpotrivite pentru date multidimensionale; ii) matricile multidimensionale permit stocareaeficient a datelor multidimensionale; iii) limbajul SQL nu este corespunztor pentruoperaii multidimensionale. Tabelul 5-1 prezint o analiz comparativ ntre sistemeleROLAP i sistemele MOLAP.

    Tabelul 5-1. Analiz comparativ ntre sistemele ROLAP i MOLAPCriterii MOLAP/ Baze de date

    multidimensionale

    ROLAP/ Baze de date relaionale

    Spaiul de disc ocupat Mare, dac agregatele suntantecalculate (explozia datelorderivate i fenomenul demprtiere)

    Posibil zero, dac sunt folosite bazede date existente nemodificate(depozite de date virtuale), dar poatefi mare dac noi structuri sunt create

    Performana la ncrcareadatelor

    Moderat Sczut

    Viteza de calcul Mare MicVolumul datelor atomice Mediu la mare (Mb-Gb) Extrem de mare (Gb-Tb)Posibilitatea de acces ladate de ctre alte aplicaii(integrare cu alte sistemeexistente)

    Limitat Excelent n principiu, dar poate filimitat dac este folosit o schemcomplex

    Accesul la date ncet i adesea limitat,citire/scriere

    Performan moderat, adesea accesnumai la citire

    Dimensionalitate Mic (modele Mare (modele multidimensionale

  • 8/8/2019 Arhitectura sistemelor OLAP

    7/13

    Arhitectura sistemelor OLAP

    5-7

    multidimensionale simple, 5-10 dimensiuni)

    complexe)

    Modificarea dimensiunilor Bun dar baza de date trebuies fie off-line

    Bun

    Volatilitatea datelor Adecvate pentru volatilitatesczut

    Adecvate pentru volatilitate ridicat

    Faciliti de administrare aSGBD-ului

    Puine Foarte puternice

    Uurina de a construiaplicaii de ctre utilizatoriifinali

    Moderat Aproape imposibil

    Arhitectura Client/server pe dou sau treiniveluri, lipsa standardelor

    Client/server pe dou sau treiniveluri, arhitectur deschis,standarde

    Managementul metadatelor Nu Da

    Limbaj de interogare Specific fiecrui instrument SQLFaciliti de calcul Foarte complexe, n toate

    dimensiunileLimitate

    Jonciuni Nu DaAgregri dinamice Nu DaJonciuni stea Nu DaPartiionarea datelor Nu DaCereri paralele Nu DaIndeci bitmap Nu DaAlgoritmi hash Da DaAgregare n lot Da DaIndexare Da DaMsuri derivate Da DaComparaii ale perioadelorde timp

    Da Da

    Analiza valutelor Nu Da

    Previziuni Da DaConsolidri financiare Da DaTipul aplicaiilor La nivel departamental La nivelul ntreprinderii

    n [COLL96], se face o evaluare comparativ a sistemelor ROLAP i MOLAP.Se utilizeaz un model de afaceri cu ase dimensiuni al unei firme de buturi. Fiecaredimensiune este compus dintr-o ierarhie de membri. Se consider urmtorul numr demembrii pentru fiecare dimensiune:

    dimensiunea Canal: 6 membri; dimensiunea Produs: 1500 de membri; dimensiunea Zona de desfacere: 100 membri; dimensiunea Timp: 17 membri;

    dimensiunea Scenariu: 8 membri; dimensiunea Msuri: 50 msuri;Se dorete stabilirea profitului real al firmei pentru luna curent i comparaia lui

    cu bugetul alocat, apoi operaii de drill down pe regiuni de desfacere i familie de produse. Sistemul ROLAP utilizeaz o schemstea denormalizat. Agregrile suntantecalculate i stocate n tabela de fapte. Numrul potenial de rnduri din tabela de

    fapte este produsul cartezian al dimensiunilor:canal(6)* produs(1500)* piaa de desfacere(100) * timp(17) * scenariu(8) = 122milioane .

  • 8/8/2019 Arhitectura sistemelor OLAP

    8/13

    Arhitectura sistemelor OLAP

    5-8

    Dac se consider un grad de mprtiere de 80% , numrul de rnduri este de 24

    milioane (20%*122 mil). Dimensiunea unui rnd este de 500 bytes i tabela de fapteajunge la 13Gb. Dac se consider i indecii construii pe fiecare coloan (cod_canal,cod_produs, cod_pia, cod_timp i cod_scenariu) necesari pentru a se executa

    jonciunile, dimensiunea tabelei de fapte ajunge la 17 Gb (blocul de date de 4K) .

    n ciuda popularitii bazelor de date relaionale n aplicaiile tranzacionale,autorii demonstreaz c modelul relaional nu este potrivit pentru aplicaii OLAP,datorit numrului mare de operaii I/O necesare pentru a executa operaii simple dedrill down sau calcule simple.

    Pentru sistemul MOLAP, datele relevante pentru analiz sunt extrase dintr-undepozit de date relaional sau alte surse de date i ncrcate ntr-o baza de datemultidimensional (un cub cu 6 dimensiuni). Implementarea acestui cubn-dimensionaleste specific lui Essbase.Autorii constat c: i) ncrcarea este foarte rapid, deoarecedatele corespunztoare oricrei combinaii de membrii ai dimensiunilor pot fi ncrcatecu o singur operaie de I/O, valorile sunt antecalculate, indecii corespunztori sunt dedimensiuni mici i pot fi stocai n memorie; ii) stocarea este foarte eficient deoarece

    blocurile conin numai date, pentru localizarea unui bloc de date este necesar un singur

    index, indecii rezid complet n memorie; iii) calculele sunt eficiente, deoarece numaio singur citire i o singur scriere I/O pe bloc sunt necesare pentru a agrega toat bazade date (tabelul 5-2).

    Tabelul 5-2. Comparaie ntre sisteme ROLAP i MOLAPROLAP MOLAP

    Spaiul ocupat pe disc (Gb) 17 10ncrcarea datelor(I/O) 240 1Calculul datelor derivate (timpul I/O n ore) 237 2

    Deci bazele de date multidimensionale utilizeaz cel mult jumtate din spaiu,

    ncarc datele i calculeaz datele derivate mult mai repede dect bazele de daterelaionale.

    O serie de instrumente OLAP permit stocarea datelor multidimensionale nfiiere, pe client (desktop OLAP). Volumul de date multidimensionale stocat pe clienteste mic i poate fi creat la cerere (utiliznd faciliti Web).

    5.3. Sisteme hibride (HOLAP)

    Un sistem OLAP hibrid (HOLAP) este un sistem care utilizeaz pentru stocareadatelor att baze de date relaionale ct i baze de date multidimensionale n scopul de a

    beneficia de caracteristicile corespunztoare i de tehnicile de optimizare. Un sistemHOLAP trebuie s aib urmtoarele caracteristici:

    transparena locaiei i a accesului: locaia datelor utilizate trebuie s fieascuns pentru utilizator. Transparena accesului permite utilizatorului sacceseze datele la fel, indiferent dac sunt stocate n BDR sau BDMD;

    transparena fragmentrii: fragmentarea datelor trebuie s fie invizibil pentruutilizator (cererile utilizatorului trebuie s fie descompuse n cereri pariale nfuncie de sistemul de stocare);

  • 8/8/2019 Arhitectura sistemelor OLAP

    9/13

    Arhitectura sistemelor OLAP

    5-9

    transparena performanei: trebuie furnizate tehnici de optimizare pentru ambelesisteme MOLAP i ROLAP;

    un model de date comun utilizat att de datele relaionale ct i de datemultidimensionale;

    alocarea optim n sistemele de stocare: sistemele hibride ar trebui sbeneficieze de strategiile de alocare specifice sistemelor distribuite;

    realocarea automat (reorganizarea distribuiei datelor n sistemele de stocareMOLAP i ROLAP).Sunt diferite arhitecturi pentru un sistem hibrid OLAP:

    integrarea sistemelor MOLAP i ROLAP printr-o interfa comun. ClientulOLAP poate fi luat n considerare ntr-o astfel de soluie, ntruct ofer ointerfa comun pentru SGBDMD i motoarele ROLAP. Totui multe dincerinele listate mai sus nu sunt satisfcute. De exemplu, Seagate Holosutilizeaz aceast arhitectur, permite tehnici de stocare relaionale imultidimensionale integrate n aa numita arhitectur OLAP compus.

    integrarea mutual a sistemelor ROLAP i MOLAP. Aceasta arhitectur poate figsit la Arbor Essbase, care ofer acces la datele relaionale (IBM DB2 OLAP

    Server). extensii la SGBDR sau SGBDOR prin utilizarea tehnologiei datablade (de

    exemplu Informix cu opiunea Metacube). Totui acesta nu este un sistem OLAPhibrid (Metacube este un motor ROLAP, deci nu este nc implicat unSGBDMD).

    Aplicaiile complexe i cu grad mare de mprtiere vor folosi o combinaie aacestor moduri de stocare. Datele care sunt utilizate cel mai des vor fi stocate nmemoria RAM. Datele care sunt utilizate regulat, dar nu frecvent pot fi stocate n bazede date multidimensionale optimizate. n final, volumele mari de date detaliate suntstocate n baze de date relaionale surs. n figura 5-2 [THOM96] se prezint strategiade stocare optim pentru aplicaii de diferite mrimi i grade de mprtiere. Desigurscara este aproximativ i va depinde de hardware-ul utilizat.

    mprtiate0.00001%

    0.00001% stocare n BDR sauhibrid

    0.001%

    0.1% stocare n RAMstocare n BDM

    1%

    10%

    100%Dense Volumul de date de baz (celule)

    Figura 5-2. Moduri de stocare

  • 8/8/2019 Arhitectura sistemelor OLAP

    10/13

    Arhitectura sistemelor OLAP

    5-10

    Pentru aplicaii foarte mprtiate, o soluie hibrid este probabil cea mai bun.Aria graficului, n care sistemele MOLAP sunt recomandate, reflect abilitatea lor de astoca cel mai eficient volume medii pn la mari de date. Pentru date foarte mprtiatesau pentru baze de date foarte mari, o strategie de stocare de tip baz de date relaional

    poate fi singura opiune fezabil. n general, dac se dorete implementarea uneisingure aplicaii, este mai eficient din punct de vedere al costului de a selecta un

    instrument mai simplu dect unul proiectat special pentru acea aplicaie. Pentru scopuristrategice i aplicaii complexe poate fi necesar de a achiziiona un instrument complex.n funcie de tipul bazei de date se poate alege tehnica de indexare folosit. Cele maimulte baze de date multidimensionale stabilesc automat tehnica de indexare.

    5.4. Arhitectura sistemelor OLAP

    Aplicaiile OLAP au o varietate mare de arhitecturi, unele foarte complexe.Multe aplicaii OLAP stocheaz volume mari de date, care nu pot fi duplicate pentrufiecare utilizator. Aceast cerin impune arhitectur client/server. n arhitectura

    client/server, att clientul ct i unul sau mai multe procesoare ale serverului pot facetransformri multidimensionale i calcule.n principiu, se pot defini mai multe niveluri logice ntr-o arhitectur

    client/server (figura 5-3). n general, ntr-o implementare particular, nu toate acesteniveluri logice pot exista ca niveluri distincte, astfel nct dou sau mai multe pot ficombinate ntr-un singur program.

    Totui n cazuri extreme, ar putea fi niveluri separate, executate pe mainiseparate. n figura 5-3 volumele de date transmise ntre niveluri sunt indicate degrosimea sgeilor. Volumele vor varia n funcie de aplicaie. Figurile de la 5-4 la 5-8ilustreaz diferite tipuri de configuraii client/server, iar tabelul 5-3 prezint avantajele

    Figura 5-3. Niveluri logice n arhitectura client/server

    1.Fiiere de date

    2

    3

    4

    5Interfaa

    Calcule ad hocmultidimensionale

    Calculemultidimensionale nlot

    Gestiunea datelor

    Se mpart ntre client i server depinde delocaia datelor

    Calcule fcute n avans pe server

    Motor pentru gestiunea datelor-baze de daterelaionale sau multidimensionale

    Datele i agregatele stocate trebuie s fiedistribuite ntre utilizatori

  • 8/8/2019 Arhitectura sistemelor OLAP

    11/13

    Arhitectura sistemelor OLAP

    5-11

    i dezavantajele lor. n principiu, cnd un server suport un numr mare de utilizatori, sedistribuie nu numai capacitatea lui de procesare i memoria dar i datele ntre utilizatori.ntr-o aplicaie, ce permite utilizatorilor s modifice datele, este foarte important camodificrile fcute de un utilizator, s fie imediat valabile la ceilali utilizatori (carealtfel ar lucra cu informaii vechi). Cele mai moderne instrumente OLAP (celemultiprocesor) ofer un mediu multiutilizator adevrat.

    Server de baz de date relaional client OLAP

    -

    Figura 5-5. Arhitectura client/server (server relaional/client OLAP)

    Fiierede dateGestiuneadatelor

    Calcule multidimensionalen lot

    Calcule multidimensionalead-hoc

    Interfaa

    Server de fiiere client OLAP

    Figura 5-4. Server de fiiere-client OLAP

    Fiiere dedate Gestiunea

    datelor

    Calcule multidimensionalen lot

    Calcule multidimensionalead-hoc

    Interfaa

    Server de baz de date relaional Server de aplicaii client OLAP

    Figura 5-6. Arhitectura pe trei niveluri

    Fiierede date

    Gestiuneadatelor

    Calcule multidimensionalead-hoc

    Interfaa

    Calcule multidimensionalen lot

    Server OLAP client OLAP

    Figura 5-7. Arhitectura client/server (Server OLAP/client OLAP)

    Fiierede date

    Gestiuneadatelor

    Calcule multidimensionalead-hoc

    Interfaa

    Calcule multidimensionalen lot

  • 8/8/2019 Arhitectura sistemelor OLAP

    12/13

    Arhitectura sistemelor OLAP

    5-12

    Tabelul 5-3. Tipuri de arhitecturi client/serverDescriere Faciliti Dezavantaje

    Server de fiiere/client

    OLAPNumai nivelul 1 este pe unserver de fiiere, nivelurile2-5 pe client

    Uor de implementat,independent de protocoalele dereea, server ieftin. Orice serverde fiiere poate fi folosit

    Nu este chiar o arhitecturclient/server. Procesarea nu seface pe server. Poate cere clieniPC puternici. Poate genera traficexcesiv n reea, deoarece toatedatele trebuie s fie mutate laclieni pentru procesare.

    Securitatea trebuie s fiegestionat de aplicaiile client.Greu de implementatactualizarea multiutilizator

    Server relaional/client

    OLAPNivelurile 1 i 2 sunt ntr-unserver de baze de daterelaional, nivelurile 3-5 peclient

    n funcie de aplicaie poate figestionat securitatea pe server.Reduce ncrcarea reelei,deoarece datele pot fi selectatei procesate parial de serverulde baz de date, nainte de a fitrimise la client pentru procesarei prezentare. Cele mai multeprocesri pot fi fcute deSGBD-ul relaional, care

    permite o exploatare bun aprocesrii paralele. Capabil deactualizri online cu blocri maibune a datelor.

    Cere un SGBD potrivit peserver, adaugnd la costuri icomplexitatea. Poate generatrafic excesiv n reea, dac toateprocesrile multidimensionalesunt fcute pe client.

    Arhitectura pe trei niveluriNivelurile 1 i 2 pe un serverde baze de date relaional,nivelul 3 pe unul sau maimulte servere de aplicaii,nivelurile 4 i 5 pe client.Nivelul 3 poate avea, deasemenea, o baz de datelocal pentru stocareainformaiilor

    multidimensionale.

    Distribuie flexibil a procesriintre serverul de baz de date iserverele de aplicaii. Se reducetraficul n reea pentru c datelepot fi procesate acolo unde suntstocate.Funcionalitate ridicat prinutilizarea unui SGBD relaionalcomplex i a unui server deaplicaii puternic. Scalabilitate

    bun n funcie de dimensiuneaaplicaiei.

    Greu de implementat i se cereexperien n reele. Adesea maipuin deschis dect arhitecturacu baz de date distribuit .Scalabilitatea n funcie denumrul de utilizatori poate firestricionat de limitele fiecruiserver de baz de date sau deaplicaii .

    Server OLAP/ clientOLAPNivelurile 1-3 pe un serverde baz de datemultidimensional, nivelurile4 i 5 pe client.

    Performan optim cu trafic nreea minim. Costuri hardwaremici. Uor de implementatactualizarea multiutilizator adatelor multidimensionale, cusecuritate multidimensional lanivel de detaliu. Aplicaiilecomplexe sunt mai simplu deimplementat.

    n general o arhitectur maipuin deschis. Instrumentele deacest tip sunt adesea maispecializate i mai puinpotrivite pentru utilizaregeneral.

    Server de baz de date relaional Server de aplicaii client WEB

    Figura 5-8. WEB OLAP pe trei niveluri

    Fiierede date

    Gestiuneadatelor

    Interfaa

    Calcule multidimensionalen lot

    Calcule multidimensionalead-hoc

  • 8/8/2019 Arhitectura sistemelor OLAP

    13/13

    Arhitectura sistemelor OLAP

    5-13

    WEB OLAP pe trei

    niveluriNivelurile 1 i 2 sunt pe unserver relaional, nivelurile 3i 4 pe serverul de aplicaii inivelul 5 pe un browserWEB conectat prin Internet

    sau Intranet.

    Uor de utilizat pentru un numrmare de utilizatori, incluzndacei utilizatori din afaraorganizaiei. Reea la un costmic. Nu cere software dedicatpe client, reducnd costurile cusoftware-ul. Suport o varietate

    de platforme.

    Funcionalitate i performanredus. Reduce manipulrile dedate la nivel de client.