back first p home  Full page last p forward

         
SlideShow Vajadused
         SlideShow Mitmedimensionaalne analüütika
            SlideShow Probleemistik
            SlideShow Mitmedimensionaalne analüütika
               SlideShow Agregeerimine
            SlideShow Dimensioonid
            SlideShow Hierarhiad
               SlideShow Andmete esitamine
         SlideShow OLAP tehnoloogia
            SlideShow Multidimensionaalne OLAP (MOLAP)
            SlideShow Relatsiooniline OLAP (ROLAP)
            SlideShow OLAP või mitte-OLAP?
            SlideShow OLAP turg
         SlideShow Andmelaondus (data warehousing)
            SlideShow Snapshot vs. Transactional
            SlideShow Mitmedimensionaalne andmelaondus
            SlideShow Indeksid
            SlideShow Agregeerimine
            SlideShow Puhverdamine
            SlideShow Laiendused andmebaaside platvormile DDW ja ROLAP tarbeks
            SlideShow Kuubipuud
            SlideShow Hierarhiad
            SlideShow Osasummad
            SlideShow Lähendamine
         SlideShow Mitmedimensionaalsed andmebaasid MDD
         SlideShow Kirjandust

SlideShow

Vajadused

Olgugi, et mitmete aastakümnete jooksul on relatsiooniliste andmebaaside valdkond põhjalikult teadlaste poolt uuritud ning teoreetilistel alustel kirjeldatud, püstitab tarbimise jätkuvalt kiire areng ning täis-elektrooniliste kanalite kasutuselevõtt andmehalduse osas uusi probleeme, mille lahendamine väljakujunenud andmebaasiteooriat järgides võib osutuda oluliselt ebaefektiivseks.

Keskmise suurusega telefonikompanii registreerib tänapäeval arenenud riigis kümneid miljoneid telefonikõnesid päevas, riigipiire ületavate kaubanduskettide sadades kassades läbivad igas sekundis toodete triipkoodid infrapunakiirte vihu ning sadu miljoneid kliente teenindavatelt pankadelt oodatakse tehingute talletamist aastakümneteks. American Airlines'i lendude reserveerimise süsteem SABRE töötleb näiteks 4000 transaktsiooni sekundis [Kim96]. Suure turuhõivega kaubandus- ja teenindusettevõtete jaoks tähendab vaid paari aasta pikkuse tegevusinfo jälje jäädvustamine ja kättesaadavaks tegemine kümnete miljardite kirjetega andmekogu, mis olenevalt atribuutide arvust ja andmete iseloomust võib andmebaasina ulatuda terabaitide suurusjärku.

Teiselt poolt on needsamad ettevõtted asetatud turule, mis eeldab iga aastaga järjest enam kliendikesksemat teenindust, konkurentsivõimelisemaid pakkumisi, kaasaegsemaid tehnoloogiaid. See omakorda aga nõuab kiireid, täpseid, informeeritud ning mõõdetud otsuseid igal ettevõtte opereerimise tasandil -- alates müüvast ja teenindavast personalist kuni planeerijate ja strateegiliste visionäärideni. Ühesõnaga, oodatakse teadlikku juhtimist.

Mainitud arengute ajendil tekib ettevõtte töösüsteemidele (i.k. operational systems või ka legacy systems) uus päringusurve, mille taga seisavad analüütikud, planeerijad ning ettevõtte keskastme- ja tippjuhid. Olukorra teeb veelgi keerulisemaks nimetatud tarbijate soov saada "kogu" infot, sest juhtkond vajab reeglina ülevaatlikku pilti kõikidest ettevõtte tegevusvaldkondadest ja toimeandmetest. Seetõttu ei ole tihtipeale teada, milliseid küsimusi soovitakse järgmisel ajahetkel küsida. Praktika on näidanud, et standardsed andmebaasisüsteemid suudavad uueneva tehnoloogia ja erinevate haldusvõtete (hajutamine, puhverdamine, dubleerimine) abil skaleeruda piisavalt suurele andmehulgale, et hoida ettevõtte operatsioone käigus, kuid juhtimiseks vajaliku info saamiseks vajatakse selegelt uut lähenemist.

Viimane kümnend on turule toonud uute tehnoloogiatena andmelaonduse (i.k. data warehousing), andmekaevandamise (i.k data mining) ning ärianalüütika (i.k. business intelligence) tarkvaraperekonna, millest on suurima populaarsuse saavutanud mitmedimensionaalse reaalaja andmetöötluse ehk OLAP (i.k. On-Line Analytical Processing) vahendid.


SlideShow

Mitmedimensionaalne analüütika


SlideShow

Probleemistik

90ndate algul olid juhtimis-info-süsteemide loojad pandud probleemi ette: "Luua süsteem, mis suudab vastata kõigile potensiaalsetele ettevõtte tegevust puudutavatele küsimustele ooteajata ning seda ka väga suure toimeandmete kogumi korral."

Selles sõnastuses võib lahutada probleemi mitmeks eraldiseisvaks alam-probleemiks:

  1. Süsteemi valmisolek leida vastused küsimustele, mida pole süsteemi loomise ajal teada.

  2. Ettevõtte kogu tegevust kirjeldava info kuvamine (näiteks müügiandmed, finantstulemused, personaliinfo jne)

  3. vastamine ooteajata ka suure toimeandmete hulga korral

Esimese alam-probleemi jaoks oli üks lahendus juba mõnda aega väga selgel kujul olemas, sest SQL süntaks võimaldab praktiliselt igast relatsioonilisest andmebaasist pärida andmeid igal võimalikul kujul. Vajati vaid spetsiaalset tööjõudu, kes analüütiku või juhi inimkeelsele päringule andmebaasisüsteemidest vastuse leiaks. Tarbimise kasvades osutus aga selline tõlkide pidamine liiga ebaefektiivseks -- kalliks ja aeglaseks. Täna turul olevad multidimensionaalse analüütika vahendid on suunatud otse lõppkasutaja töölauale -- analüütikust tegevjuhini.

Teine alam-probleem kujutab endast sisuliselt integreerimise probleemi, millele on leevendust toonud arengud andmelaonduse valdkonnas. Läbimõeldud IT arhitektuuriga suures teenindus- või kaubandusettevõttes on tänapäeval implementeeritud ühtne andmeait, kuhu kogutakse pidevalt andmeid kõigist ettevõtte operatsioonilistest töösüsteemidest.

Jõudluse ning skaleeritavuse probleemi lahendamiseks on enamlevinud võtted andmeaida näol andmete dubleerimine, eel-andmetöötluse sisseseadmine (näiteks kuupide genereerimine) ning töötlemise hajutamine vaba ressursiga ajaperioodidele.


SlideShow

Mitmedimensionaalne analüütika

Enamasti OLAP märksõna all kasutatav mitmedimensionaalne andmemudel sündis ajendatuna vajadusest universaalse andmemudeli järgi, mis oleks kasutatav analüütika eesmärgil, piisavalt lihtne lõppkasutajale mõistmiseks ja tarkvaraliseks navigeerimiseks ning sõltumatu andmete kontekstist.

Tüüpilise relatsioonilise andmebaasi puhul räägitakse kirjetest ning atribuutidest, olemitest ning nendevahelistest seostest. Kirje võib tähistada ühte konkreetset Klienti, mille atribuutideks võiksid olla näiteks Nimi, Telefon, Vanus, Sissetulek. Samas andmebaasis võib olla ka tabel Tooted, atribuutideks Hind, Tootegrupp, Tootja. Klientide ja Toodete omavahelist seost kirjeldab tabel Ostud, kus on registreeritud kõik ostud säilitades andmed: Aeg, Ostja, Toode, Kogus, Müügipunkt.

OLAP/image002.jpg

Klassikalises OLAP lahenduses defineeritakse vaadeldaval andmekogul k mõõdikut, mida peetakse huvitavaks jälgida ning ülejäänud atribuutide baasil n dimensiooni, asetades mõõdikud n-mõõtmelisse ruumi. Võtame eelmisest näitest mõõdikuteks Käive (= Hind * Kogus) ning Kogus. Dimensioonideks oleks sel juhul sobiv valida näiteks Aeg, Vanus, Sissetulek, Toode, Müügipunkt. Valitud viis dimensiooni moodustavadki 5-mõõtmelise ruumi, kus ruumipunktides on kirjeldatud mõõtude Käive ja Kogus väärtused.

OLAP/image004.jpg

F({Aeg, Vanus, Sissetulek, Toode, Müügipunkt}) = {Käive, Kogus}


SlideShow

Agregeerimine

Järgmisena tuleb otsustada, kuidas talitada juhtudel, kui samal kuupäeval on kaks ühesuguse sissetulekuga ühevanust klienti ostnud samast poest sama toodet -- st. juhtudel kui sama n-vektoriga on kirjeldatud kaks või enam transaktsiooni. Selliste puhkude käitlemiseks rakendatakse andmete agregeerimist ning iga mõõdikuga defineeritakse lubatud agregeerimisoperaatorid, mis reeglina on tavlised SQL funktsioonid SUM, AVG, MIN, MAX või ilma argumentideta ka COUNT.

Meie näites omaksid tähendust mõlema mõõdiku jaoks SUM, AVG ning COUNT. Edasise näite lihtsustamiseks vaatleme vaid juhte, kus mõõdikutele rakendatakse grupeerimiseks summeerimisfunktsiooni SUM.

Agregeerimise rakendamisega saavutatakse, et funktsioon F on ühene ning iga diskreetse n-mõõtmelise ruumi punkt määrab maksimaalselt ühe väärtuste kombinatsiooni ehk mõõdikute k-vektori. Edasises on agregeerimisel veelgi tähtsam osa.

Andmetest lõplikku n-mõõtmelise andmekuubi moodustamisega oleme teinud esimese sammu universaalse esituse poole. Valisime väärtused, mille muutumist me soovime jälgida ning atribuudid/dimensioonid, mis neid väärtusi kirjeldavad (mõjutavad). Oleme vabanenud keerulisest andmemudelist, mis on siiani olnud sõltuvuses andmestu sisust, ning asendanud selle ühtse üldistatud struktuuriga. Pärimine andmekuubist on muutunud triviaalseks, kui on teada dimensioonid ja mõõdikud. Kuid lahendust pole leidnud andmehulga probleem, sest hõredal ruumilisel kujul ei pruugi andmemaht olla oluliselt väiksem algsest. Samuti on andmed sellisel detailsusastmel, et analüütikust lõppkasutajal ei ole nendega veel midagi peale hakata.


SlideShow

Dimensioonid

Andmekogudes võivad atribuudid esineda erinevate väärtuse tüüpidega -- nii tekivad dimensioonid, mis võivad olla reaalarvulised pidevad, diskreetsete arvuliste väärtustega või hoopis nominaalsete väärtustega (pärisnimed). Nominaalse andmetüübi põhiline erinevus arvulistest seisneb selles, et diskreetsed väärtused on mõtestatult järjestatavad ning järjestuse järgi grupeeritavad (ranges), kuid nominaalsed mitte. Nominaalsed dimensioonid on tüüpiliselt nimelised -- geograafilised asukohad, kaupade nimed, jne. Olgugi, et nimed on tavaks järjestada alfabeetiliselt, ei ole see järjestus sisuline -- pole põhjust, miks Põlva peaks olema enne Tallinnat ja see omakorda enne Tartut.

Esimene dimensioonide valimisega kaasnev ülesanne on leida kompromiss andmehulga ja minimaalse detailsusastme vahel. Ühelt poolt soovime, et analüüsis oleks meil võimalik minna pisimate detailideni, teisalt aga soovime, et andmekuup jääks võimalikult tagasihoidlike mõõtmetega ning loodud n-mõõtmeline ruum ei oleks liiga "hõre". Pärast pidevate väärtuste diskretiseerimist osutub efektiivseks ka teiste arvuliste väärtuste ümardamine kokkulepitud diskreetsusastmele. Pole tõenäoline, et meil on oluline teha vahet klientidel, kellede sissetulekud on 5003 krooni ja 5004 krooni.

Olgu varem toodud näites kokkulepitud järgmised minimaalsed detailsused:

Aeg -- kuupäev

Vanus -- viis aastat

Sissetulek -- 1000ndetes kroonides

Toode -- nominaalne (grupeerimata)

Müügipunkt -- nominaalne (grupeerimata)


SlideShow

Hierarhiad

Siiani läbitu baasil on õnnestunud luua selge andmemudel ning realiseerida hästi balanseeritud andmekuup. Olenevalt kokkulepitud detailsusastmest ning andmete iseloomust ulatuvad dimensioonid reeglina mõnesajast väärtusest mõnesaja tuhandeni (näiteks tooted). Hetkel on andmestu optimeeritud leidmaks vastust küsimusele:

Q1. Kui palju müüsime kaupluses XXX 3. märtsil 25-30 aastastele 4000-5000 kroonise sissetulekuga klientidele tooteid YYY?

On selge, et tegemist ei ole tüüpilise analüütilise küsimusega ega sobiva andmeesitusega ettevõtte juhtimisinfo saamiseks. Inimese poolt kasutatavaks muutub andmestu alles siis, kui on defineeritud hierarhiad dimensioonidel. Mitmed dimensioonid on juba loomult hierarhilised:

Aeg: Kõik → Aasta → Kvartal → Kuu → Kuupäev

Vanus: Kõik → {0-20,20-30,30-40,40-60,60-100} → 5 a. periood

Sissetulek: Kõik → 5000 krooni täpsus → 1000 krooni täpsus

Toode: Kõik → Valdkond → Tootegrupp → Toode

Müügipunkt: Kõik → Piirkond → Linn→ Müügipunkt

OLAP/image006.jpg

Hierarhiad annavad andmetele ülevaatlikuse ning võimaldavad kasutajal andmetest kasulikku informatsiooni filtreerida. Hierarhiate abil on võimalik küsida:

Q2. Millised kliendid genereerisid enim piimatoodete käivet Tartus käesoleva aasta teises kvartalis?

Vastuse otsimisel rakendame funktsiooni F({II kvartal, Kõik, Kõik, Piimatooted, Tartu}), mis ei viita enam ruumipunktile, vaid kuubisegmendile, mille piirid on defineeritud hierarhiate ehitusega. Funktsiooni arvutamiseks peame käesoleval juhul summeerima kõik piiritletud segmenti jäävad mõõdud.

Hierarhiate ehitamine dimensioonidele on multidimensionaalse lahenduse realiseerimisel challenging ülesanne, eriti nominaalset tüüpi dimensioonidele. Sellest, kuidas hierarhiad peegeldavad reaal-maailma, sõltub informatsiooni täpsus, asjakohasus ning andmestu kasutusmugavus.


SlideShow

Andmete esitamine

Inimene suudab igapäevases elus hästi ette kujutada kolmemõõtmelist ruumi, levinud tehnilised vahendid esitavad infot vaid kahemõõtmelisel tasapinnal: paberil või ekraanil. Järgmine probleem ongi n-mõõtmelise andmestu esitamine kahemõõtmelisel tasapinnal -- tabelina.

Levinud lahendus on triviaalne: kasutaja saab valida kaks dimensiooni, mille "lõikes" ta soovib andmestut vaadata, ning andmekuubi segment projitseeritakse ülejäänud dimensioonidel agregeerivat funktsiooni kasutades valitud tasandile. Dimensioonide hierarhilisus võimaldab kasutajal valida ka andmete esitamise granulaarsuse.

Q3. Kuidas mõjutab kliendi vanus Põhja-Eestis toiduainete müügikäivet tootegrupiti?

Vastusena esitatakse dimensioonide Vanus ja Toode lõikes tabel, milles toodud mõõdud saadakse segmendi {Kõik,Kõik,Kõik,Toiduained,Põhja-Eesti} agregeerimisel vanuse- ning tootegruppide järgi.

Terminiga slice "n" dice iseloomustatakse tüüpilist OLAP analüüsi, kus peamised operatsioonid on andmekuubist teatud segmentide eraldamine (slice) ning alamkuubi pööramine soovitud dimensioonide lõikesse (dice). Hierarhiate abil saavad võimalikuks veel kaks OLAP-le iseloomulikku operatsiooni: DRILLDOWN ja ROLLUP. Operatsioonid väljendavad liikumist kuubis sügavuti ehk dimensiooni hierarhiat järgides üldisemalt spetsiifliisemale (drilldown) ja vastupidi (rollup).

OLAP/Ops.png

OLAP/Hier.png

Q4. Huvitav..., et juunis on Tallinnas tehtud eriti suurt käivet vorstitoodete osas, huvitav millised konkreetsed tooted on selle esile kutsunud? (Iga vastus esitatud küsimusele tõstatab viis uut küsimust)

Tasub tähele panna, et OLAP andmeesituses on iga esitatud mõõt (arvuline väärtus) saadud mingi n-mõõtmelise ruumisegmendi agregeerimisel. OLAP kasutajaliideses piisab vaid esitatud väärtusele klikkida, ning käivitatakse uus päring, mis võtab aluseks väärtuse arvutamiseks tarvitatud ruumisegmendi ning esitab selle samades dimensioonides, kuid hierarhiate mõttes astme võrra täpsema detailsusega.

OLAP andmekuup sisaldab alati algandmetest agregeeritud väärtusi -- ka kõige madalamal hierarhiate taselemel, i.e. ruumipunktis, asuv väärtus on üldiselt agregaat. Mõned OLAP rakendused võimaldavad kõige madalamale agregatsiooni tasemele (suurima detailsuseni) jõudes välja kutsuda päringu alg-andmeallikal, mis esitab väärtuse arvutamisel kasutatud transaktsioonid. Algsete transaktsioonide kuvamise operatsiooni tähistamiseks on levinud fraas REACH THROUGH.

OLAP rakenduse puhul eeldatakse tehnoloogialt ooteajata andmete serveerimist ning selle saavutamisel muutub andmete analüüs mänglevaks kuubikeerutamiseks reaalajas. OLAP kasutajaliideselt oodatakse andmete visualiseerimist tabelite ja graafikutena, juurdepääsu kontrolli, ajatelje analüüsi ning kõiki slice'n'dice ja drilldown võimalusi.

Eelnevaga on kirjeldatud multidimensionaalse analüüsi ideoloogia ning ühisosa funktsioonidest, mis on erinevate OLAP tööriistade lõppkasutajale saadaval. Siiani on aga taotluslikult puutumata tehnoloogiad, mis võimaldavad hiigelsuurtel andmekogudel reaalajas analüüsi rakendada. Tehnilise back-end lahenduse poolest on peaaegu kõik OLAP tööriistad erinevad. Järgnevas vaatleme ühiseid jooni ning probleeme kuubistu loomises, talletamises ning haldamises.


SlideShow

OLAP tehnoloogia

OLAP teenus on tüüpiliselt lahendatud kolmekihilisena: kasutajaliides, OLAP server, algandmete kogud. Moodne kasutajaliides toimib veebibrauseris, pihuarvutis või desktop programmina, algandmete kogudeks on tavaliselt ettevõtte andmeladu, operatsioonilised andmekogud (ODS -- operatsional datastore) või töösüsteemide andmebaasid. Multidimensionaalse andmetöötlusega tegeleb OLAP serverikiht, mida järgnevas on põhjust lähemalt uurida.

OLAP/image008.jpg

OLAP/Arch.png

Suures plaanis võib OLAP vahendid jagada andmestu haldamise järgi kaheks: Multidimensional OLAP (MOLAP või ka lihtsalt OLAP) ning Relational OLAP (ROLAP). Esimesel juhul talletatakse andmekuupe spetsiaalselt selleks otstarbeks loodud mälustruktuurides, ROLAP korral aga hoiustatakse andmeid andmeaidas või ka tavalisel kombel andmebaasis ning emuleeritakse multidimensionaalset analüüsi on-the-fly. Viimane eeldab andmemudeli täpselt kirjeldamist ning toimib seejärel translaatorina, tõlkides OLAP päringud SQL-i. Mitmetes lahendustes on kasutatud häid omadusi mõlemast lähenemisest ning jõutud hübriidse haldusmudelini -- Hybrid OLAP (HOLAP).


SlideShow

Multidimensionaalne OLAP (MOLAP)

MOLAP serveri ülesanne on etteantud andmekogu baasil genereerida andmekuubid, talletada need operatiivmälus (juhul, kui seda on piisavalt) ning vastata operatiivselt kasutajaliideste päringutele. Kuubi genereerimise algoritmid ning andmestruktuurid on iga tootja puhul erinevad, kuid idee on alati sama -- teostada agregeerimise näol võimalikult palju eel-arvutusi, et kiirendada kasutajapäringuid. Täiskuubi genereerimisel arvutatakse kõikide mõõtude väärtused mitte ainult igas ruumipunktis, vaid ka kõikidel segmentidel (st. hierarhiate kõikidel tasemetel).

Tähistagu D[1] ... D[n] dimensioonide 1 kuni n väärtuste hulki ning H[1] ... H[n] vastavatele dimensioonidele ehitatud hierarhiate tippe. Siis kuubi andmemaht avaldub:

(n+k)*P[0<i][£n](|Di|+|Hi|)

Olgu meil üks laiem dimensioon, mis koos hierarhiatega sisaldab 10 000 elementi (näiteks Tooted), üks keskmine 1000 elemendiga (näiteks Aeg) ning kolm väikest 100 elemendist dimensiooni. Siis arvestades keskmiselt 5-baidise andmehoiustustasuga saame kahe mõõdu jaoks andmekuubi mahuks 350 000 000 000 000 baiti e. 350 terabaiti. Õnneks osutub reaalelus n-dimensionaalne andmeruum üldiselt hõredaks --paljudes kombinatsioonides andmeid lihtsalt ei eksisteeri. Iga päev ei õnnestu müüa igat saadaolevat toodet igat tüüpi kliendile. Vaid ainult mõningaid tooteid mõnda tüüpi kliendile. Reaalelus suudavad OLAP analüüsiserverid kuubid realiseerida mõnekümnest megabaidist kuni paari gigabaidini ulatuvas andmemahus. Andmemudeli loomisel on kasulik meeles pidada, et sama andmehulga pealt moodustatud hõredad kuubid on alati aeglasemad kui tihedad kuubid.

Lisaks sellele, et andmekuupides asetsevad andmed hõredalt -- nende jaotus ei pruugi samuti olla ühtlane. Kuubis võivad esineda segmendid, milles andmete sisaldumine käib tavaelu loogikareeglite vastu (näiteks rasedad meesterahvad). Kogu ettevõtte tegevusandmestu (müük, personal, finantsid, jne) kirjeldamine samade dimensioonide abil võib osutuda väga ebaefektiivseks või üldse lootusetuks ettevõtmiseks. Seepärast luuaksegi vastavalt analüüsi eesmärkidele tavaliselt mitu andmekuupi (sarnaselt view--de loomisega relatsioonilises baasis), mis kirjeldavad mõõte erinevates dimensioonide komplektides. Tihtipeale võivad ka mõned dimensioonid kattuda (näiteks Aeg), mis võimaldavad kuupe ühiste dimensioonide baasil kokku siduda (nagu joinimine DBs) ning kasutaja võib analüüsi käigus navigeerida ühest kuubist teise.

Andmekuupide genereerimine on üldiselt väga ressursimahukas tegevus, mis planeeritakse öisesse perioodi, mil süsteemide kasutus on minimaalne. Vahel ei ole kõikide ruumipunktide jaoks väärtuste ning hierarhiapõhiste vahesummade arvutamine üldsegi vabas aja-aknas võimalik -- selleks puhuks on strateegiad, mis teostavad kuubi genereerimise staadiumis ainult osa agregeerimist ning jätavad teatud arvutused päringupõhiseks protsessimiseks -- teostavad mõned arvutused alles siis, kui neid andmeid küsitakse. Näiteks võidakse algandmete põhjal arvutada väärtused vaid n-mõõtmelise ruumi kõigis sisepunktides, kahemõõtmelisele tasandile projekteerimine e. kuubi "külje" arvutamine ning hierarhiate baasil agregeerimise võib teostada alles konkreetse päringu tarvis.

Võimalusel genereeritakse kuubid igal öösel, kuid olenevalt vajadusest ning andmehulgast võib see toimuda iga tunni tagant või ka nädalavahetuseti. Mõned OLAP serverid on võimelised ka kuube "värskendama" -- agregeerima uued andmed olemasolevasse kuupi sisse, ilma seda uuesti algusest peale ehitamata. Teatud puhkudel ei pruugi aga värskendamine olla üldsegi efektiivne [allikas KR98], kuna uuendatavate väärtuste otsimine ning indeksite värskendamine võib osutuda veelgi aeganõudvamaks.

OLAP Council pakub välja andmevahetuseks ning -talletuseks ühtse standardi objekt-orienteeritud lähenemisel. [Ei ole teada, palju seda kasutatakse.]


SlideShow

Relatsiooniline OLAP (ROLAP)

Nagu juba mainitud, ei eelda ROLAP server eraldi multidimensionaalset andmekuupi, vaid on võimeline andmebaasiskeemi abil OLAP päringud käivitama otse relatsioonilises SQL's ning suvalisel ANSI SQL andmebaasiplatvormil.

Lihtsamal juhul piisab ROLAP teenuse üles seadmiseks seoste kirjeldamisest tabelite vahel, dimensioonideks valitud andmeväljade märkimisest ning mõõtude defineerimisest. Päringute töötlemisel kasutab ROLAP server agregeerivat GROUP BY konstruktsiooni, et moodustada andmeallikast väärtuste pärimise tarvis SQL lausend.

Puhas ROLAP translaator algsüsteemide andmebaasidel skaleerub ainult üsna väikestele andmekogudele ning on reaalsuses harv nähtus. Tavaliselt kasutatakse ROLAP lähenemist multidimensionaalseks analüüsiks optimeeritud struktuuriga andmelaol või kasutab teenusserver ooteaja vähendamiseks spetsiaalseid operatiivmälu või DB-põhiseid andmekogusid. Viimast tüüpi rakendusi klassifitseeritakse kui hübriidseid OLAP süsteeme -- Hybrid OLAP (HOLAP).

Relatsioonilise andmebaasi optimeerimist multidimensionaalseks analüüsiks ning sellega seotud probleeme puudutatakse lähemalt andmelaondust käsitlevas peatükis.


SlideShow

OLAP või mitte-OLAP?

Termin "OLAP" ehk Online Analytic Processing tuli algselt käibele vastandina lühendile "OLTP" ehk Online Transactional Processing. Lühend "OLAP" ei avalda tegelikkuses mingit kasulikku infot selle kohta, milleks OLAP vahendid head on ning veel vähem nende toimimise põhimõtete kohta. Aastal 1993 avaldas relatsioonilise andmebaasimudeli loojaks tituleeritud E.F.Codd 12 kriteeriumit OLAP aplikatsioonidele [Cod93]. Kaks aastat hiljem 1995 lisandus tema töö järjes neile veel 6 kriteeriumit. Coddi kriteeriumid pidid aitama kasutajal kindlaks teha, kas vaadeldav aplikatsioon on OLAP rakendus või mitte. Ilma piisava põhjenduseta esitatud Coddi 18 postulaati ei baseerunud matemaatilisel mudelil ja on osati üldsegi vasturääkivad. Kuna tööd sponsoreeris OLAP tarkvara tootja Hyperion, ollakse tänaseks veendunud, et Coddi nime all avaldatud OLAP kriteeriumite loomisega ei olnud dr. Coddil endal suurt midagi pistmist [OR, Kim96].

Nigel Pendse ja Robert Creeth, kes üllitavad OLAP tootjatest sõltumatult iga-aastast mahukat OLAP tarkvara ja turu analüüsi "OLAP Report", pakkusid aastal 1995 vastuseks Coddi segastele 18 kriteeriumile välja 5 implementatsioonist sõltumatut määrangut, mille alusel võib kindlaks teha, kas tegemist on OLAP analüütikat võimaldava tootega. Pendse/Creeth loodud FASMI (Fast Analysis of Shared Multidimensional Information) test on leidnud erialastes töödes laia kasutust ning sisuliselt asendanud Coddi kriteeriumid.

Kiirus - OLAP päringutelt oodatakse tulemuste esitamist lõppkasutajale vähemalt 5 sekundi jooksul. Uurimused on näidanud, et juba 20 sekundit kestvaid päringuid peab OLAP kasutaja ebaõnnestunuteks.

Analüüs -- OLAP kasutajaliideselt oodatakse lõppkasutajale ja rakendusele sobilikku intuitiivselt kasutatavat analüütikat. Analüütika sisse-seadmine eeldab reeglina implementatsioonifaasis valemite ja muude rakenduse põhiste seoste defineerimist. Analüütika võib sisaldada lisaks tüüpilisele slice--n--dice ja drilldown-le näiteks aegridade analüüsi, kulude allokeerimise mudeleid, "mis siis kui?" analüüsi (what-if?) ning andmekaevandamise valdkonnas kasutusel olevaid meetodeid.

Jagatus -- Jagatuse kriteerium viitab sellele, et süsteem peab võimaldama mitme kasutaja teenindamist ning sealjuures kasutajaõiguste kontrollimist andmetele ligipääsuks. OLAP analüütikas esitatavate andmete konfidentsiaalsus on enamasti ettevõttele eriti oluline.

Mitmedimensionaalsus -- Eelnevas kirjeldatud mitmedimensionaalset lähenemist analüütikale peetakse OLAP võtmeks. Kui lühendi OLAP asemel peaks kasutama ühtainust sõna, siis N.Pendse pakub, et see võiks olla just "mitmedimensionaalne".

Informatsioon -- Sisendinformatsiooni hulk on otseselt rakenduse kiirust mõjutav faktor ning seetõttu ka oluline mõõdupuu OLAP aplikatsioonide klassifitseerimisel.


SlideShow

OLAP turg

[Siin võiks olla paar sõna veel OLAP tarkvara turumahu ja popimate toodete kohta]

Maailmas OLAP turg 3.5 miljardit dollarit aastas. Oodatakse mahu kasvu 5 miljardi dollarini aastal 2004.

Microsoft tuli ja võttis kolme aastaga 20% turust. Suurimad kukkujad on "vanad poisid" Oracle ja Hyperion.

Eestis on OLAP implementeeritud ca. 5-10 ettevõttes -- Hansapank, Ühispank, Eesti Telefon, Eesti Raudtee, Tallinna Kaubamaja


SlideShow

Andmelaondus (data warehousing)

"Andmeladu talletab suure hulga (large collection) teemakohaseid (subject-oriented) integreeritud ajaloolisi (time-variant) staatilisi (non-volatile) andmeid, toetamaks analüütikat ja juhtkonna otsustusprotsessi." [Kim96]

Andmeladu täidab kaasaegses ettevõttes mitut eesmärki:

  1. Päringukoormuse vähendamine operatsioonilistelt süsteemidelt. Töösüsteemide ülesanne on ilma viivituseta infot vastu võtta - transaktsioone töödelda ja registreerida. Samaaegne info pärimine, millega kaasneb kirjete ning indeksite lukustamine, on süsteemile halvav. Operatsiooniliste süsteemide koormust aitab vähendada ka ajaloolise info eemaldamisega, millega kaasneb andmemahu vähenemine töösüsteemi andmebaasis.

  2. Erinevates töösüsteemides asuvate andmete tsentraliseeritud talletamine, sealjuures võimaluse korral eri süsteemidest pärit andmete integreeririmine. Tihtipeale võib suures ettevõttes olla sama info kajastatud mitme eri süsteemi andmebaasides, kuid veidi erineval kujul.

  3. Staatilise vaate tekitamine andmetest. Töösüsteemides muutuvad väärtused ning seosed olemite vahel nii kiiresti, et sama päring käivitatuna 5 minutit hiljem võib anda hoopis teised tulemused.

  4. Andmemudeli optimeerimine vastamaks andmeanalüüsi vajadustele. Töösüsteemis tavapärases kasutuses tegeletakse korraga vaid ühe kontoga (account), olgu see klient, makse, toode või ükskõik milline teine suurus. Seepärast on andmemudelid optimeeritud konkreetse konto leidmiseks ning mitte ülevaatlikuks analüüsiks.

  5. Andmelao kasutuselevõtuga eeldatakse, et sinna jõuvad vaid hea kvaliteediga andmed. Selle garanteerimiseks viiakse seatakse sisse andmete puhastamise ning auditeerimise protseduurid.

    OLAP/image010.jpg

    Lihtsustatult võib andmeladu pidada hoidlaks (tavaliselt DB), kuhu kantakse töösüsteemidest ettemääratud intervalli tagant (tavaliselt öösiti) ettevõtte tegevust kirjeldavad toimeandmed. Seejuures võidakse rakendada andmete transformeerimist kujule, mis lihtsustab analüütilise eesmärgiga pärimise toimetamist.


    SlideShow

    Snapshot vs. Transactional

    Tüüpiline suure andmemahuga töösüsteem tegeleb transaktsioonidega -- olgu need müügitehingud kauplemissüsteemis, kõned telefonikeskjaamas, kanded pearaamatusse, ülekanded pangasüsteemis või külastused veebikeskkonnas.

    Suurtesse transaktsioonipõhistesse süsteemidesse on reeglina sisseehitatud nn. saldotabelid (balance data) - lisaks transaktsioonide registreemisele hoitakse ka transaktsioonidega seotud kontode saldosid, mida vastavalt töödeldavate transaktsioonidega pidevalt suurendatakse või vähendatakse. Olenevalt kontekstist võib tegemist olla näiteks kontojäägiga panga- või finantssüsteemis, toote laoseisuga müügisüsteemis, kliendi telefoniarvega sidekompaniis jne.

    Vahel ei osutu otstarbekaks andmelattu kanda kõiki registreeritud transaktsioone, vaid näiteks ainult kontode päevalõpu saldod. Sellisel moel hetkeseisude (snapshot) regulaarne kogumine pakub andmelaonduses laialt kasutatava alternatiivi transaktsioonilistele mudelitele. Samas pakub transaktsiooniline mudel siiski paremat granulaarsust ning valik kahe mainitud lähenemise vahel sõltub laondamise eesmärkidest ning tehnilistest võimalustest.


    SlideShow

    Mitmedimensionaalne andmelaondus

    Kuigi andmeladu ei vaja definitsiooni järgi spetsiaalset andmemudelit, annab andmete mõistlik ümberstruktureerimine võitu mitte ainult analüütiliste päringute töötlemiskiiruses vaid võimldab muuta päringud ka oluliselt lihtsamaks.

    OLAP populaarsus viitab selgelt mitmedimensionaalse lähenemise eelistele tegevusandmete analüüsil ning on mõistetav, miks otsiti võimalust dimensionaalset lähenemist kasutada otse relatsioonilise andmebaasi kontekstis. Juba 90-ndate alguseks oli välja kujunenud vastav terminoloogia ning universaalsne multidimensionaalne andmemudel. Andmekuupi kirjeldavas relatsioonilises mudelis kogutakse kõik mõõdud ühte "faktitabelisse" (facts table), mis on n võtme läbi seotud kuni n "dimensioonitabeliga" (dimension tables).

    OLAP/image012.jpg

    [star-schema joonis]

    Dimensioonil defineeritud hierarhiaid võib andmemudeli normaliseerimise huvides kirjeldada eraldi tabelites, mis on üks-mitmele seosega ühendatud dimensioonitabeliga. Sellist optimeeritud täht-skeemi kutsutakse ka lumehelbe-skeemiks (snowflake schema). Mõned allikad [too näiteid!!!] soovitavad siiski dimensioonide normaliseerimisest loobuda ning kirjeldada dimensiooni juurde kuuluvad hierarhiad samas dimensioonitabelis. Lumehelbe-skeemi kasutamisel saadav võit andmemahus on kaduvväike, kuid päringud muutuvad andmebaasimootori jaoks keerulisemaks ning potensiaalselt aeglasemaks.

    OLAP/image014.jpg

    [sama joonis lumehelbe skeemiga]

    Märksõnaga Dimensional Data Warehousing (DDW) kirjeldatakse dimensionaalsete andmemudelite alusel loodud andmebaasi või "ladu. Dimensionaalse vaate viimine andmelao tasemele muudab sobiva tarkvara abil edasise OLAP kuupide genereerimise triviaalseks ülesandeks. Samuti on väikese või keskmise mahuga DDW ideaalne baas relatsioonilise ROLAP lahenduse implementeerimiseks.

    Andmelao optimeerimine

    DDW pakub küll sobivaima relatsioonilise andmemudeli ROLAPi jaoks, kuid miljarditesse kirjetesse ulatuva faktitabeli puhul ei ole ooteajata OLAP päringute töötlemine reaalne. Päringute kiirendamiseks on levinud järgmised põhilised tehnikad.


    SlideShow

    Indeksid

    Praktiliselt kõik levinud andmebaasimootorid toetavad indeksitena B-puid, mille abil on otsing kirjete arvu suhtes logaritmilise keerukusega ülesanne. Elementaarne kaalutlus DDW puhul on faktitabeli varustamine n-indeksiga kuubi iga dimensiooni tarbeks. Täieliku indekseerimise miinused on andmemahu praktiliselt kolmekordistumine ning kirjete lisamisel tekkiv lisakoormus indeksite täiendamisel. B-puude täiendamine on samuti logaritmilise keerukusega tippude arvu suhtes ning seega tõsist probleemi indeksite täiendamine ei kujuta. Indekseerimise abil muutub lihtsaks kuubisegmendi eraldamine e. slicing.


    SlideShow

    Agregeerimine

    OLAP päringu puhul on vaieldamatult ressursimahukaim toiming väljalõigatud kuubisegmendi või halvemal juhul kogu andmekuubi väärtuste liitmine, keskmistamine, võrdlemine või mõne muu funktsiooni järgi agregeerimine. Kui agregeeritavate faktide arv on F, siis kahele dimensioonile projitseerimise keerukuseks võib lugeda vähemalt F*(log|D1|+log|D2|).

    Levinud lahendus päringute agregeerimise etapi kiirendamiseks on kasutada eelnevalt teatud tasemeni agregeeritud väärtusi. Eel-agregeerimist toimetatakse sel puhul sarnaselt MOLAP lahendusega öisel ajal, pärast seda kui andmeladu on uute toimeandmetega värskendatud. Paljud andmebaasid võimaldavad kasutajal luua realiseeritud vaateid (materialised views), mis ei seisne ainult päringu-SQL talletamises, vaid ka reaalse andmestruktuuri loomises ning selle kooskõla säilitamises algtabelitega. Üks võimalus ongi genereerida andmelaol agregeeritud vaated või uued ajutised tabelistruktuurid agregaatide hoidmiseks. Testid on näidanud [allikas], et relatsioonilisel DB tehnoloogial põhinevate agregeeritud realiseeritud vaadete täiendamine on ebaotstarbekas ning efektiivsem on vaated pärast uute andmete lisandumist uuesti genereerida.

    On mõistetav, et suure dimensioonide ning faktide hulga korral ei õnnestu eelnevalt valmis luua agregeeritud vaateid dimensioonide kõikide m-kombinatsioonide jaoks m>1 && m<=n, sest agregeeritud vaadete hulk osutub ülemäära suureks ning kui m ei ole oluliselt väiksem kui n, siis ka väga andmemahukaks. Eel-agregeeritud vaadete ülesseadmisel tuleb luua andmete sisu või kasutuspraktika järgi strateegia, millistes dimensioonides on kõige efektiivsem vaated luua. Tuleb meeles pidada, et eeltööks võimalik aja-aken on piiratud. Kasutuseta ajal peab läbi viima:

    1. andmete lugemine töösüsteemidest;

    2. puhastamine ning transformeerimine andmelao mudelile;

    3. andmete laadimine andmeaita -- indeksite täiendamine;

    4. relatsiooniliste agregeeritud kuupide täiendamine või re-genereerimine.

    Piisavalt vähe-hõreda ruumi puhul on selgelt kõige kasulikum eelnevalt agregeerida n vaade, sest selliseid on ainult üks ning seda saab kasutada kõikide järgnevate vaadete loomisel. Samuti saab n vaatelt lugeda kõik OLAP päringud. Käesoleva töö autor leiab, et andmete varjatud konteksti korral on järgmisena efektiivne strateegia luua kõik 2-vaated, mida on [n*(n-1)/2] tükki. Nimetatud vaated projitseerivad kogu andmekuubi suvalisele kahemõõtmelisele tasandile ja on kasutatavad kõikide selliste OLAP päringute jaoks, milles ei kasutata ühtegi filtreerivat tingimust -- st. ei eraldata kuubist segmenti. Kahemõõtmeliste vaadete loomise kaalutlus on tingitud asjaolust, et iga filtreeriva päringu korral on heade hierarhiate korral liidetavate väärtuste hulk juba vähemalt suurusjärgu (10 korda) võrra väiksem.

    Andmelao põhimõtete kohaselt ladustatud andmeid praktiliselt kunagi ei muudeta, vaid ainult lisatakse regulaarselt uusi (daily increment). Kui üheks dimensiooniks on valitud Aeg, siis on tõenäoline, et igal päeval lisandub andmekuubile uus segment, mis olemasoleva kuubiga ei lõiku. Seetõttu sobib mõnedes lahendustes kuupide (agregeeritud vaadete) inkrementaalne täiendamine -- olemasolevat kuupi ei pruugi uuesti genereerida, piisab vaid kirjutada kuupi kirjeldavale agregaatide tabelile otsa lisandunud segment ning täiendada indekseid. Selline lähenemine on võimalik muidugi vaid nende m vaadete jaoks, mille üks dimensioon on Aeg.

    Mõnedes ROLAP serverites ning tänapäevastel andmelao platvormidel on juba sisseehitatud agregaatnavigaator (aggregate navigator), mis aitab kasutaja eest kapseldatud kujul agregeeritud vaateid luua, hooldada ning päringute sooritamisel valida kõige sobivam vaade.


    SlideShow

    Puhverdamine

    Suuremas organisatsioonis võib andmelaol ning multidimensionaalsel analüütikal olla tuhandeid regulaarseid kasutajaid. Tähelepanek, et andmeladu on regulaarsete värskenduste vaheperioodil täiesti staatiline (tüüpiliselt terve tööpäeva), loob võimalused kasutada OLAP päringute puhverdamiseks paremaid tehnikaid, kui seda on iga serveriga kaasaskäiv disk-caching süsteem. Nutikas ROLAP server või andmelao agregaatnavigaator salvestab sooritatud OLAP päringute tulemused enda jaoks agregeeritud vaatena ning päringu kordumisel ei pruugi enam andmelao baas-struktuuridest andmeid kasutada.


    SlideShow

    Laiendused andmebaaside platvormile DDW ja ROLAP tarbeks

    Relatsiooniliste andmebaasiplatvormide tagasihoidlik maksumus ning mugavalt saadaval oskusteave (know-how) on muutnud DDW + ROLAP lähenemise ettevõtete jaoks väga atraktiivseks. Samas jääb jõudluse ning andmemahulise skaleeruvuse poolest ROLAP enamikes situatsioonides alla kallimale MOLAP hüperkuubilahendusele. Seetõttu otsitakse tööstusharus hoolega sobivaid täiendusi andmebaaside platvormile, mis võimaldaksid kiiremat mitmedimensionaalset analüüsi. Järgnevas on toodud ülevaade huvitavamatest uurimissuundadest nimetatud valdkonnas.


    SlideShow

    Kuubipuud

    Üks praktilisemaid lahendusi on Roussopouluse ja Kotidise poolt välja pakutud [KR98] ROLAP agregeeritud vaadete talletamise alternatiivne andmestruktuur -- "kuubipuu". Tüüpiliselt on relatsioonilises paradigmas kirjed salvestatud kettale ISAM tabeliformaadis või mõnesugusel teisel järjestamata kujul. Järjestuse defineerimiseks ning otsingu kiirendamiseks kasutatakse indekseid, mis on lahendatud B-puudena. B-puus on otsing logaritmilise keerukusega ning puu iga leht viitab kirjele andmebaasitabelis.

    Relatsioonlises andmekuubis mõistliku ajaga päringute töötlemine on võimalik vaid ulatusliku indeksite kasutamise abil. Lisaks iga dimensiooni indekseerimisele on soovitav indekseerida ka olulisemad dimensioonide kombinatsioonid. Samas indeksite kasutamine mitmekordistab andmemahu ning muudab andmete lisamise/värskendamise ressursimahukaks toiminguks.

    Autorite uurimus näitab, et B-puude abil eraldi asuvale andmetabelile viitamine ei ole mitmedimensionaalses andmemudelis otstarbekas lähenemine. Kattuvad indeksid dubleerivad viiteid ning võtmeid, mida eraldiasuvas andmetabelis veelgi korratakse. Autorid soovitavad andmekuubi väärtusi ning kõiki indekseid talletada ühtselt R-puus. R-puu on B-puuga sarnane sidus atsükliline graaf, mis on sobiv vektorite sorteerimiseks ruumis ning mis võeti algselt kasutusele [Gut84] 3-D modelleerimisvahendites.

    Kuubipuudel läbiviidud katsetused näitavad, et kuubipuud annavad traditsioonilise B-puu indekseerimistehnikaga võrreldes:

    1. 10 korda kiirema päringutöötluse

    2. 100 korda kiirema inkremendi töötlemise (uute kirjete lisamine)

    3. 51% võitu andmemahus

    Lisaks olgu märgitud, et käesoleva töö autor katsetas PostgreSQL platvormil R-puude kasutamist vektoriaalsel andmekuubi indekseerimisel, kuid kahjuks võrreldavaid tulemusi ei saavutanud. [sellest ka, et miks siis mitte. ...]


    SlideShow

    Hierarhiad

    Jagadish, Lakshmanan ja Srivastava [JLS99] juhivad tähelepanu asjaolule, et andmekuubi dimensioonidele ehitatud hierarhiatel on keskne roll OLAP päringute formuleerimisel ning töötlemisel, kuid DB platvormid ei paku selleks piisavalt toetust. Täht-skeemil ning lumehelbe-skeemil põhineva traditsioonilise lähenemise nõrkustena toovad autorid esile näiteks fakti, et dimensioonile ehitatud hierarhia peab moodustama balanseeritud puu ning hierarhia igal tasemel peavad olema homogeensed atribuudid. Reaalelus on see nõue harva iseenesest täidetud -- näiteks ei pruugi organisatsiooni struktuur olla balansseeritud hierarhia, samuti toodete liigitus ega geograafiline jaotus. Tähelepanu juhitakse ka sellele, et OLAP päringute optimeerimine hierarhilises mudelis on samuti liigselt keerukas ülesanne.

    Lahendusena pakutakse välja SQL(H) andmemudel, mille puhul on andmebaasi tasandil kasutatud lisatabeleid võimaldamaks balanseerimata hierarhia-puid ning heterogeensete atribuutide kasutamist erinevatel hierarhia tasanditel ja dimensiooni eri piirkondades. Tabelid on lõppkasutaja eest peidetud, kasutades SQL(H) päringukeele laienduses realiseeritud DIMENSION-fraasi. Samuti on päringute efektiivseks töötlemiseks koostatud hierarhilise seostamise algoritm bitmap indeksite baasil (hierarhical bitmap joins).


    SlideShow

    Osasummad

    ROLAP ja DDW rakenduste puhul piirab praktikas enim jõudlust faktor, et mõõtude agregeerimine nõuab alati kõikide kuubisegmendi väärtuste lugemist ning töötlemist -- liitmist, keskmistamist või võrdlemist. OLAP päringute puhul on harv juhus, kui vaadeldakse ühte kuubi punkti või väga väikest segmenti, enamikel juhtudest tuleb summeerida piki kuubi

    Sobivaks kasutamiseks tiheda kuubi puhul on pakutud [HAMS97] mõõtude talletamist osasumma-kuubis. Olgu vaatluse all kliendi Vanust kirjeldav dimensioon ning mõõduks klientide arv. Sellisel juhul leiduksid 10-aastase täpsusega andmekuubis väärtused järgneval kujul:

    {0-10, 10-20, 20-30, 30-40, 40-50, 50-60, 60-70, 70-80} → {5,67,92,53,23,43,12,7}

    Osasumma-kuubis oleks sama informatsioon organiseeritud nii, et agregeeritud väärtuste leidmiseks peaks kulutama võimalikult vähe ressursse:

    {0-80, 0-40, 0-20, 40-60, 0-10, 20-30, 40-50, 60-70} → {302, 217, 72, 66, 5, 92, 23, 12}

    Võime veenduda, et sellises esitusviisis ei ole andmeid kaduma läinud, kuid kui esimesel juhul on maksimaalne tehete arv 8 (kogusumma leidmine), siis teisel juhul on keerukaim arvutus 4 tehte mahuga: 70-80 → 302 -- 217 -- 66 -- 12. Veelgi olulisem on siinjuures asjaolu, et OLAP päringute spetsiifikat järgides oleks valdav enamus päringuid lahendatavad 1-2 tehte abil.

    Kuigi näide oli lihtsuse huvides toodud ühedimensionaalsel juhul, on kerge minna üle mitmedimensioonaalsele juhule, kus järjendi binaarse jaotamise asemel poolitatakse dimensioon-haaval n-mõõtmelist kuupi.

    Kirjeldatud lähenemise miinuseks on tõsiasi, et osasumma-kuup osutub reeglina tihedaks (ning andmemahukaks) olenemata sellest, et algandmed asuvad ruumis hõredalt ning on DDW skeemis efektiivselt talletatavad.

    Autori märkus: Huvitavaid tulemusi võiks anda osasummade tehnoloogia sidumine R-puu indeksite ning kuubipuudega. Osasummasid saaks hoida puu vahetippudes ning päringutulemuse arvutamist oleks võimalik teostada kuubisegmendi otsingu käigus puud läbides.


    SlideShow

    Lähendamine

    Võttes arvesse, et OLAP analüütika sihtrühma kuuluvad enamikus lõppkasutajad, kellele on oluline andmetest kiiresti ülevaatliku pildi saamine, on mõningates kontekstides rakendatav mõõtude ligilähedane agregeerimine. Lainenditel (wavelet) põhinevad aproksimeerimise meetodid [VWI98, VW99] võimaldavad kiiresti kuvada keskmistatud andmetelt arvutatud ligilähedase päringutulemuse ning seda vastavalt kasutaja soovile detailsuskoefitsentide järgi astmeliselt täpsustada kuni algtäpsusega agregaatideni välja.

    Olgu algne andmejärjend:

    {2,2,0,2,3,5,4,4}

    Kahandades arvude kahekaupa keskmistamise teel järk-järgult andmete resolutsiooni, saame:

    {2,1,4,4} → {1.5,4} → {2.75}

    Lisaks arvutame välja ka detailsuskoefitsendid (detail coefficient):

    {0,-1,-1,0} {0.5,0} {-1.25}

    Talletates madalaima resolutsiooni koos kõikide koefitsentidega on pöördtehetega võimalik taastada nii algandmed kui ka kõik vahepealsed resolutsioonid.

    {2.75, -1.25, 0.5, 0, 0, -1, -1, 0}

    Eeldusel, et võime kasutaja nõusolekul tagastada päringutulemusena ligikaudseid väärtusi, väheneb oluliselt aeganõudvate sisend-väljund operatsioonide arv ning masssilise summeerimise asemel võime kasutada korrutamist.


    SlideShow

    Mitmedimensionaalsed andmebaasid MDD

    Veel midagi huvitavat ...

    Praktiline näide -- ROLAP realisatsioon


    SlideShow

    Kirjandust

    [AAD+96] S. Agarwal, R. Agrawal, P. M. Deshpande, A. Gupta, J. F. Naughton, R. Ramakrishnan, and S. Sarawagi. On the computation of multidimensional aggregates. In Proc. 22nd VLDB, pages 506--521, Mumbai, Sept. 1996.

    [AMS97] C.-T. Ho, R. Agrawal, N. Megiddo, and R. Srikant. Range queries in OLAP data cubes. In Proceedings of the 1997 ACM SIGMOD International Conference on Management of Data, Tucson, AZ, May 1997.

    [Cod93] E. F. Codd. Providing OLAP: An IT Mandate. Unpublished Manuscript, E. F. Codd and Associates, 1993

    [GBLP96] J. Gray, A. Bosworth, A. Layman, and H. Pirahesh. Data cube: A relational aggregation operator generalizing group-by, cross-tab, and sub-totals. In Proc. 12th ICDE, pages 152--159, New Orleans, March 1996.

    [GL97] Gyssens, M. and Lakshmanan, L.V.S. "A foundation for multi-dimensional databases," Technical Report, Concordia University and University of Limburg, February 1997.

    [GL98] Gingras F. and Lakshmanan L.V.S. nD-SQL: a multi-dimensional language for interoperability and olap. VLDB, 1998.

    [Gut84] A.Guttman. R-Trees: A Dynamic Index Structure for Spatial Searching. In Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 157--166, Boston, Ma, June 1984.

    [HAMS97] C.-T. Ho, R. Agrawal, N. Megiddo, R. Srikant. Range Queries in OLAP Data Cubes. In Proceedings of the 1997 ACM SIGMOD International Conference on Management of Data, Seattle, WA, June 1998.

    [Han97] J. Han. OLAP mining: An integration of OLAP with data mining. In Proceedings of the 7th IFIP 2.6 Working Conference on Database Semantics (DS-7), pages 1--9, 1997.

    [IKA00] T. Imielinski, L.Khachiyan, A.Abdulghani. Cubegrades: Generalizing association rules. Tech. Rep. Dept. Computer Science, Rutgers Univ., August 2000.

    [JLS99] H. V. Jagadish, Laks V. S. Lakshmanan, D. Srivastava. What can Hierarchies do for Data Warehouses? The {VLDB} Journal, pages 530--541, June 1999.

    [Kim96] R.Kimball. The Data Warehouse Toolkit. John Wiley & Sons, 1996.

    [KR98] Y. Kotidis and N. Roussopoulos. An alternative storage organization for ROLAP aggregate views based on cubetrees. In Proc. ACM SIGMOD Intl. Conf. on Management of Data, pages 249--258, Seattle, WA, June 1-4 1998.

    [OR] N. Pendse and R. Creeth. The OLAP report, 1995-2002. The online report is available on the web at [39]http://www.olapreport.com/

    [VWI98] S. Vitter, M. Wang, and B. Iyer. Data cube approximation and histograms via wavelets. In Proceedings of Seventh International Conference on Information and Knowledge Management, pages 96--104, Washington D.C., November 1998.

    [VW99] J.S. Vitter and M. Wang. Approximate Computation of Multidimensional Aggregates of Sparse Data Using Wavelets. In Proceedings of the 1999 ACM-SIGMOD International Conference on Management of Data, Philadelphia, PA, June 1999


    ©Jaak Vilo; 2004 "OLAP.thtml" (26 slides) 25.11.2014 22:52