Moniulotteisen datan liitos tähtimallissa

hyväksymispäivä arvosana arvostelija Moniulotteisen datan liitos tähtimallissa Jani H Rautiainen Helsinki 25.10.2005 Tietokannat nyt -seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Tiivistelmä Nykypäivänä lähes kaikki tietovarastot toteutetaan moniulotteisesti joko varta vasten kehitetyillä moniulotteisilla tietokannoilla tai moniulotteiseen tietomalliin perustuen relaatiotietokannan päälle. Tämän vuoksi useat perinteisistä tietokannoistakin sisältävät tehokkaita algoritmeja moniulotteisen tiedon käsittelyyn. Tässä kirjoituksessa annetaan perustiedot moniulotteiseen tietomalliin liittyen sekä tarkastellaan yhtä tapaa toteuttaa liitoksia tehokkaasti tähtimallin yhteydessä.

Sisältö 1 Johdanto 1 2 Moniulotteisuus 2 3 Moniulotteisen tietovaraston toteutus 5 3.1 Tähtimalli 6 3.2 Lumihiutalemalli 6 4 Liitos tähtimallissa 7 5. Yhteenveto 11 Lähteet

1 1 Johdanto Yritysten ja yhteisöjen suurimpana haasteena ei enää nykypäivänä ole itse tiedon kerääminen ja tallentaminen. Relaatiotietokantamalli (relational database model) ja koko tietotekniikan yleinen kehitys on luonut puitteet sille, että olemassa olevat tietokannat täyttyvät yhä yksityiskohtaisemmalla tiedolla ja jatkuvasti kiihtyvällä vauhdilla. Vaikka tietokantojen koon kasvu onkin yksi tietokantateollisuuden ongelmista, suurempi ja mielenkiintoisempi haaste sille on vastata siihen kysymykseen, kuinka tällaisia valtavia datamassoja pystyttäisiin hyödyntämään päätöksenteossa. Moniulotteinen tietokantamalli (multidimensional database model) onkin yksi avaintekijä edellisen ongelma-alueen sovelluksissa. Se tarjoaa inhimillisemmän rakenteen tiedon tallentamiseksi tietovarastoihin (datawarehouse) ja tukee samalla niiden sisältämän tiedon tosiaikaista käyttöä, analysointia ja raportointia (online analytical processing, OLAP) [KiW99]. Vaikka moniulotteisen tietokantamallin historia ulottuukin aina 1960- luvun loppupuolelle, oli se kuumimman tutkimuksen ja tuotekehittelyn kohteena vasta 1990-luvulla [PeJ01]. Silloin tutkijat alkoivat esittää erilaisia matemaattisesti muodollisia malleja moniulotteisille tietokannoille. Ja siitäkin huolimatta, ettei relaatiotietokantamalliin verrattavissa olevaa universaalia formalismia ole vieläkään esitetty, tietokantateollisuus on tuonut markkinoille useita tuotteita ja on näin implisiittisesti todistanut idean toimivuuden käytännössä [VaS99], [PeJ01]. Tämän kirjoituksen tarkoituksena on antaa lukijalle perustiedot moniulotteiseen tietomalliin liittyen sekä tarkemmin kuvata tehokkaan liitosalgoritmin toteutusta tähtimallissa. Luvussa 2 esitellään muutamia moniulotteisuuteen liittyviä peruskäsitteitä esimerkein ja kuvataan erityisesti tiedon analysoinnissa käytettyjä kyselyjä. Lisäksi annetaan muutamia esimerkkejä hyödyistä, joita moniulotteinen tietovarasto tarjoaa verrattuna perinteisiin operatiivisiin järjestelmiin. Kolmannessa luvussa kuvataan kaksi toisistaan poikkeavaa tapaa moniulotteisen tietovaraston toteuttamiseksi ja syvennytään tarkemmin tähtimalliin, jonka avulla moniulotteinen tietomalli on mahdollista rakentaa tavallisen relaatiotietokannan päälle. Neljännessä luvussa esitetään tehokas algoritmi, jolla tähtimallin yhteydessä tärkeä liitosoperaatio voidaan toteuttaa tehokkaasti ilman raskaita indeksejä.

2 2 Moniulotteisuus Yrityksille tietovarastot esiteltiin 1990-luvun alkupuolella yleisluontoisena ratkaisuna yritysten johtamisessa tarvitun tiedon hallintaan [MoK00]. Esittelynsä jälkeen tietovarastointi on nopeasti noussut yhdeksi tärkeimmistä sovelluksista tietokantateollisuudelle [MoK00]. Nopeasti tapahtunutta kehitystä osaltaan edesauttoivat edeltävinä vuosikymmeninä yrityksiin rakennetut operatiiviset tietojärjestelmät, joiden kautta johtamisessa tarvittava tietoaineisto oli jo valmiiksi olemassa. Operatiivisten tietojärjestelmien hyödyntäminen suoraan päätöksenteossa oli osoittautunut vaikeaksi. Tietovarastoinnin ja operatiivisten tietokantojen välillä on nimittäin kaksi suurta eroa [MoK00]. Ensinnäkin traditionaalisen tietokannan perimmäisenä tarkoituksena on tarjota niin ajan kuin tilankin suhteen tehokas ratkaisu sekä tiedon tallentamiseen että sen ylläpitoon. Tietovarastoinnin päällimmäisenä tarkoituksena on sen sijaan toimia ainoastaan tiedontallennuspaikkana - tietovaraston tulee tukea tiedon hakua, mutta sen ei useimmiten tarvitse tukea tiedon päivittämisestä [MoK00]. Normaalisti tietovarastojen tietosisältö päivitetään esimerkiksi kerran yössä ajettavilla eräajoilla jatkuvan päivittämisen sijaan [HaH01]. Toinen, vielä merkittävämpi ero on se, että tietovarastot ovat suoraan loppukäyttäjien ulottuvilla [MoK00]. Tavallisen tietokannan ja sen käyttäjän väliin on yleensä rakennettu yksinkertainen ja helppokäyttöinen liittymä. Tämän käyttöliittymän ansiosta loppukäyttäjän ei tarvitse tuntea eikä tietää mitään siitä monimutkaisesta rakenteesta, johon tieto lopulta tallennetaan tai mistä se haetaan. Tietovarastojen suorakäyttöön ajaa väistämättä niiden tarkoitus, tiedon analysointi. Kattavaa kyselykokoelmaa on mahdotonta laatia etukäteen ja tämän sijasta loppukäyttäjä itse laatii hakuja suoraan tietokantaa vastaan, minkä johdosta hänen tulee tuntea myös rakenne, jolla tiedot on tallennettu. Tämä asettaa selkeitä rajoituksia tietorakenteen monimutkaisuudelle, sillä tietovarastojen käyttäjät eivät juuri koskaan ole tietohallinnon ammattilaisia vaan esimerkiksi yrityksen myyntitietoa analysoivaa keskijohtoa [Mok00], [HaH01]. Moniulotteisuuden ehkä suurin hyöty liittyykin juuri tiedon esittämiseen. Moniulotteisessa tietokannassa tieto esitetään käyttäjälle niin sanottuna kuutiona (cube) tai hyperkuutiona (hypercube) [HaH01]. Hyperkuutio on kolmiulotteisen kuution yleistys n:ään ulottuvuuteen [Weis1]. Näin suora voidaan ajatella yksiulotteisena kuutiona ja normaa-

3 lia taulukkolaskentaohjelman laskenta-arkkia vastaava kaksiulotteinen kuutio nelikulmiona. Kuutioon kuuluvien dimensioiden määrä sekä niiden määrittelyjoukot vaikuttavat siihen, kuinka harva (sparse) tai tiheä (dense) kuutio on [PeJ01]. Kuutio on sitä harvempi, mitä enemmän ulottuvuuksia siinä on käytössä ja mitä laajempi on kunkin dimension määrittelyjoukko. Vaikka hyperkuution ulottuvuuksien määrää ei teoriassa ole mitenkään rajattu, käytännön sovelluksissa rajana on yleisesti kymmenestä viiteentoista eri ulottuvuutta. Tätä suurempi määrä aiheuttaa helposti suorituskykyongelmia olemassa olevien työkalujen kanssa [PeJ01]. Ulottuvuuksien määrittelyjoukko on käytännön syistä yleensä diskreetti eli numeroituva. Hyvin usein dimensio on määritelty monitasoisena hierarkiana, jossa jokainen dimension jäsen kuuluu tietyn tason alle ulottuvuuden hierarkiassa ja jokainen taso kokoaa yhteen mielekkään yhdistelmän sen alapuolisista jäsenistä. Normaalisti ainoastaan alimman tason jäsenille syötetään dataa ja ylemmän tason jäsenten tietosisältö saadaan yhdistämällä yhteen kaikki sen alapuoliset jäsenet sovituin säännöin. Useissa tapauksissa on mielekästä määritellä samaan dimensioon useita hierarkioita. Tällöin dimension jäsenet voivat kuulua useampaan eri hierarkiaan. Käytännössä sovellukset kuitenkin yleensä vaativat, että jokaiselle jäsenelle on määritelty ainoastaan yksi vanhempi (parent) [PeJ01]. Dimension jäseniin voidaan liittää myös attribuutteja, jotka kuvaavat jäsenten eihierarkkisia ominaisuuksia [PeJ01]. Esimerkiksi pakkauskoko voisi olla tuotedimension ei-hierarkkinen ominaisuus, mutta se voitaisiin yhtä hyvin mallintaa myös pakkauskoko-ulottuvuudella. Jäseniin liitettyjen ominaisuuksien avulla voidaan myös muuttaa niiden käyttäytymistä. Esimerkiksi tilidimensiossa voidaan määritellä tilityyppiominaisuus, joka määrittelee kuinka eri tilejä yhdistellään toisiinsa. Näin tulo- ja menotilejä ei hierarkiassa laskettaisikaan normaalin tavan mukaan yhteen vaan menotilin arvo vähennettäisiin tulotilin arvosta. Dimensioiden väliset leikkauspisteet määrittelevät kuution solut (cell) [PeJ01]. Jokainen tallennettava tietoalkio varaa itselleen yhden kuution soluista. Solu määritteleekin pie-

4 nimmän jaoteltavissa olevan alkion, joka kuutioon voidaan tallentaa. Tällaista tietoalkiota kutsutaan faktaksi (fact) ja se kuvaa siis sitä kiinnostuksen kohdetta, jota halutaan analysoida [PeJ01]. Useimpien moniulotteisten järjestelmien yhteydessä vaaditaan, että faktat on implisiittisesti määritelty niihin liittyvien dimensiojäsenten kautta. Fakta voi siis olla olemassa ainoastaan silloin, kun sille on selkeästi määritelty paikka kuution jossakin solussa. Lisäksi yleinen vaatimus on, että faktat tallennetaan dimensiohierarkioiden alimpien tasojen väliseen leikkauspisteeseen. Kuvassa 1 on esitetty yksinkertainen kolmiulotteinen tietomalli. Kuva 1. Vuosimyynti kaupungeittain ja tuotteittain. Moniulotteisuus tarjoaa etuja myös tiedon analysoinnissa sillä perinteiseen relaatiotietomalliin verrattuna se tukee rakenteensa ansiosta hyvin analysoinnissa olennaisia kyselyjä. Tällaisia ovat esimerkiksi seuraavat [HaH01], [PeJ01], [KiW99] : leikkaa-ja-halkaise-kyselyn (slice-and-dice) tarkoituksena on pienentää tarkasteltavaa kuutiota. Esimerkiksi kuvan 1 kuutiossa voitaisiin ensin leikata kuutiosta ainoastaan maidon myynti ja tämän jälkeen halkaista jäljelle vuoden 2003 luvut jolloin tuloksena saataisiin maidon myynti kaupungeittain vuonna 2003. poraamalla ja yleistämällä (drill-down, roll-up) liikutetaan katselukulmaa dimensiohierarkiassa alas- tai ylöspäin. Kuvassa 1 esitellyn kuution kohdalla olisi mahdollista summaamalla yleistää erilliset maidon ja piimän myyntiluvut yhteen luomalla uusi taso maitotuotteet. Vastaavasti maitotuotteet-tasolta voitaisiin alemmalle tasolle porautuen analysoida sitä, mistä maitotuotteiden myynti tarkemmin koostuu.

5 suodattamalla (filter) saadaan esille ainoastaan haluttu asia, esimerkiksi maitotuotteet. kuutiota kääntämällä (rotating) saadaan vaihdettua jäsenten ryhmittelyä. Kuvassa 1 on näkymä vuosimyyntiin tuotteittain, mutta kuutiota kääntämällä esiin saataisiin esimerkiksi piimän vuosimyynti kaupungeittain. järjestelemällä (ranking) saadaan esille tiettyyn arvojoukkoon kuuluvat luvut. Näin voitaisiin esimerkiksi etsiä kaksi parhaiten myynyttä tuotetta Helsingistä vuonna 2002. Moniulotteinen tietomalli ei siis pelkästään ole inhimillisempi tiedonesitystapa vaan tarjoaa sen lisäksi täyden uudenlaisia tapoja tiedon analysointiin. Lisäksi se on myös usein tehokkaampi näiden analyyttisten kyselyjen suorittamisessa [HaH01], [PeJ01]. Näistä seikoista johtuen ei olekaan ihme, että tietovarastot yhä useammin toteutetaan moniulotteisuuteen pohjautuen. Seuraavassa luvussa tarkastellaankin kahta erilaista tapaa, joiden avulla moniulotteinen tietovarasto on mahdollista toteuttaa. 3 Moniulotteisen tietovaraston toteutus Moniulotteisen tietovaraston toteuttamiseksi on kaksi lähtökohdiltaan erilaista ratkaisua. Niin sanottu moniulotteinen OLAP (multidimensional OLAP, MOLAP) tarkoittaa jonkin markkinoilla jo valmiiksi olevan moniulotteisen tietokannan hyödyntämistä. Vaihtoehtona edelliselle on rakentaa moniulotteinen tietovarasto relaatiotietokannan päälle, jolloin puhutaan relaatio OLAP:sta (relational OLAP, ROLAP). Edellä mainituilla kahdella ratkaisulla on keskenään eräitä merkittäviä eroavaisuuksia. Nykyisin markkinoilla olevat moniulotteiset tietokannat ovat toteutuksiltaan varsin kirjavia verrattuna pitkälle standardisoituihin relaatiotietokantaratkaisuihin [VaS99]. Toisaalta moniulotteiset tietokannat on alusta asti suunniteltu tukemaan moniulotteisen tiedon käsittelyä ja sisältävät hyvinkin monimutkaisia optimointimenetelmiä ja indeksointiratkaisuja [HaH01], [PeJ01]. Tästä johtuen ne ovat usein suorituskyvyllisesti parempia ja tilankäytöltään tehokkaampia. Tätä etua tosin kaventaa se, että useista perinteisistäkin tietokannoista löytyy nykyään paranneltuja indeksirakenteita ja optimoituja algoritmeja moniulotteisen tiedon käsittelyyn. Yhtenä etuna relaatiotietokantapohjaisessa ratkaisussa on se, että se ei vaadi tiedon siirtämistä operatiivisista järjestelmistä tietovarastoon

6 vaan sallii tiedon analysoinnin suoraan niistä [MoK00], [HaH01]. Suurin etu relaatiopohjaisessa ratkaisussa lienee kuitenkin se, ettei se vaadi yritykseltä lisäinvestointeja vaan tietovarasto voidaan toteuttaa käyttäen jo olemassa olevia järjestelmiä. Koska moniulotteisten tietokantojen toteutustavat on usein luokiteltu liikesalaisuuksiksi eivätkä siksi ole julkisesti saatavilla ja koska relaatiotietokantaan pohjautuvat tietovarastot ovat varsin yleisiä, keskitymme seuraavaksi tarkastelemaan rakennetta, jonka avulla moniulotteinen tietomalli saadaan toteutettua käyttäen tavallista relaatiotietokantaa [ChD97]. 3.1 Tähtimalli Tähtimalli (star schema) koostuu kahdesta tai useammasta taulusta. Niin sanottu faktataulu (fact table) toimii tähden keskuksena ja sen sakaroita kuvaavat dimensiotaulut (dimension table) [MoK00]. Faktataulussa on jokaista dimensiotaulua kohden sarakkeet, joihin on tallennettu dimensiotauluihin viittaavat vierasavaimet. Näiden lisäksi faktataulussa on yksi tai useampi sarake, joihin tallennetaan itse seurattava suure. Dimensiotaulu sisältää sarakkeen jokaista siihen liittyvää attribuuttia kohti. Kuvassa 2 on esitetty yksinkertainen esimerkki tähtimallin mahdollisesta taulurakenteesta. Kuva 2. Tähtimallin taulurakenne. 3.2 Lumihiutalemalli Rakenteestaan johtuen edellisessä kappaleessa esitelty tähtimalli on varsin toisteinen. Jos esimerkiksi ajanhetkeä on mallinnettu omalla dimensiolla, sama vuosi voi esiintyä dimensiotaulussa 365 kertaa jokaista vuoden päivää kohti. Toisteisuus ei kuitenkaan useimmiten ole ongelma, koska moniulotteiseen tietomalliin tallennettava tieto on pää-

7 sääntöisesti harvaa. Toisteisuutta voidaan kuitenkin haluttaessa vähentää niin kutsutulla lumihiutalemallilla (snowflake schema) [PeJ01]. Lumihiutalemalli sisältää taulun jokaista dimension tasoa kohden jolloin esimerkkinä mainittu dimensio hajoaisi kolmeksi tauluksi: vuosi, kuukausi ja päivä. 4 Liitos tähtimallissa Koska tähtimallia käytetään hyvin monesti tietovarastojen yhteydessä, tulee käytössä olevan tietokannan tukea tehokkaasti siinä suoritettavia kyselyjä. Tavallinen kysely tähtimallia vastaan etenee niin, että ensimmäisessä vaiheessa dimensiotauluista suodatetaan jäljelle halutut jäsenet, jonka jälkeen suoritetaan liitos niiden ja faktataulun välillä [Wei02]. Tämän jälkeen voidaan tulostaulu viedä ryhmitellä halutulla tavalla sekä suorittaa jäsenten välistä yhdistelyä (aggregate). Seuraavaksi esitellään menetelmä, pushdown hash join, jolla dimensiotaulujen ja faktataulun välisiä liitoksia voidaan toteuttaa tehokkaasti ilman ylimääräisiä tietokantarakenteita kuten ylläpidollisesti raskaita indeksejä. Kuva 3. Esimerkissä käytetyn tähtimallin taulurakenne. Tyypillinen kysely kuvan 3 tähtimallissa voisi olla esimerkiksi [Wei02]: SELECT SUM(f.c1), SUM(f.c2) FROM f, d1, d2, d3, d4

8 WHERE f.fk1=d1.k AND f.k2=d2.k AND f.fk3=d3.k AND f.k4=d4.k AND d1.c1=a1 AND d2.c2=a2 AND d3.c3=a3 AND d4.c4=a4 Jos dimensiotaulujen suodatuksen tuloksena saatavat tulostaulut eivät ole todella pieniä, paras strategia kyselyn toteuttamiseksi on todennäköisesti suorittaa liitokset oikealle syvässä kyselypuussa (right-deep query tree) kuten kuvassa 4 on kuvattu [Wei02]. Oletuksena on, että jokaisesta dimensiotaulusta jää suodatuksen jälkeen jäljelle tuhat riviä ja että jokainen liitos faktataulun ja dimensiotaulun välillä vähentää tuloksena saatavien rivien määrän kymmenesosaan. Näin siis ensimmäisessä liitoksessa joudutaan käsittelemään kaikki satamiljoonaa faktataulun riviä, toisessa liitoksessa tulostauluun jäljelle jääneet miljoona riviä ja kolmannessa satatuhatta, kunnes lopulta neljännen liitoksen lopputuloksena saadaan vastauksena kymmenentuhatta riviä. Kuva 4. Oikealle syvä kyselypuu. Parannetun menetelmän periaatteena on parantaa tehokkuutta vähentämällä liitoksessa läpikäytävien rivien määrää mahdollisimman lähelle todellista lopputulosta [Wei02]. Esimerkin tapauksessa tarkoituksena olisi siis päästä heti niin lähelle kymmentätuhatta riviä kuin mahdollista. Idea menetelmän takana on kerätä etukäteen lista niistä dimensiotaulujen riveistä, joiden kanssa on tarpeen muodostaa liitos faktataulun kanssa ja faktataulua läpikäydessä hypätä suoraan niiden rivien yli, joiden kanssa liitoksen tekemistä ei tarvita.

9 Algoritmin suorittamiseksi voidaan erottaa kaksi toisistaan erillistä tapausta [Wei02]. Jos faktataulun vierasavaimille fk i on luotu indeksit indexfk i, voidaan dimensiotaulun suodatuksessa saatu tulostaulu järjestää sen avaimen dk i mukaan ja tämän jälkeen faktataulun indeksiä indexfk i käyttäen kerätä ne faktataulun rivit, joista löytyy vastaava vierasavain fk i. Lopputuloksena saadaan bittikartta, joka kertoo, mitkä faktataulun rivit voidaan liittää läpikäydyn dimensiotaulun kanssa. Käyttämällä samaa menetelmää kaikille dimensiotauluille ja yhdistämällä bittikartat toisiinsa kaksi kerrallaan loogisilla operaattoreilla (,, ), saadaan faktataulun riveistä bittikartta, jota voidaan käyttää niin sanotun skip scan -menetelmän kanssa [Wei02]. Kokonaisuudessaan kuvatun menetelmän nimi on index push down join. Jos kaikille faktataulun dimensioavaimille on rakennettu indeksit ja menetelmää myös hyödynnetään kaikkien dimensioiden yhteydessä, faktataulun skip scannauksen lopputuloksena pitäisi olla yhtä monta riviä kuin koko kyselyn lopputuloksena saadaan. Näin siis faktataulusta luettavien sivujen määrä vähenee merkittävästi. Varsinaiset liitokset faktataulun ja dimensiotaulujen välillä tarvitaan ainoastaan sen vuoksi, että lopulliseen tulostauluun saadaan halutut sarakkeet dimensiotauluista. Esitetyn menetelmän suoritus on kuvattu kuvassa 5. Kuva 5. Index push down join -menetelmän suoritus.

10 Jos faktataulun vierasavaimille ei ole luotu indeksejä, joudutaan käyttämään toista vaihtoehtoa. Menetelmässä ylläpidetään jokaisen dimensiotaulun läpikäynnin yhteydessä bittivektoria bv, jonka pituus on n ja jonka jokaisen bitin arvoksi asetetaan alussa 0. Dimensiotaulun läpikäynnin yhteydessä lasketaan hyväksyttyjen rivien avaimille dk i hajautusarvo v {0..n-1} ja bittivektorissa v:tä vastaavan bitin arvoksi asetetaan 1. Saatua bittivektoria käytetään edelleen hyväksi faktataulun läpikäynnissä niin, että jokaisen faktataulun rivin vierasavaimeen fk i kohdistetaan sama hajautusfunktio. Mukaan tulostauluun poimitaan ainoastaan ne rivit, joiden kohdalla bittivektorin bv vastaavan bitin arvoksi on asetettu 1. Samaa menetelmää voidaan toistaa kaikkien dimensiotaulujen yhteydessä. Kuvatun algoritmin nimi on bit-vector push-down join ja sen suoritus yhden dimensiotaulun yhteydessä on esitetty kuvassa 6. Kuva 6. Bit-vector push-down join -menetelmän suoritus. Jälkimmäisenä kuvattua menetelmää käyttäen faktataulusta luettavien sivujen määrää ei saada vähennettyä yhtä dramaattisesti kuin ensimmäisen algoritmin yhteydessä, koska hajautusfunktiosta riippuen eri lukuja voi kuvautua samalle arvolle. Tästä johtuen menetelmä ei pysty takaamaan, että jokaisen dimensiotaulun läpikäynnin yhteydessä faktataulusta palautettaisiin ainoastaan ne rivit, jotka lopullisessa tulostaulussa tarvitaan [Wei02]. Huolimatta tästä menetelmä voi merkittävästi vähentää faktataulusta palautettavien rivien määrää verrattuna yksinkertaisimpaan algoritmiin. Etuna algoritmilla on

11 se, ettei se vaadi mitään ylimääräisiä indeksejä, mikä voi olla merkittävä etu suurien faktataulujen yhteydessä. Push down hash join -menetelmän yhteydessä saavutettava tehokkuushyöty riippuu suuresti siitä, kuinka karsivia dimensiotauluihin kohdistettavat suodatukset ovat, faktataulun koosta ja siitä, kuinka suuri osa faktataulun riveistä vastaa dimensiotauluihin kohdistettaviin ehtoihin [Wei02]. Jos dimensiotauluun kohdistettu ehto karsii vain vähän, esimerkiksi viisi prosenttia, palautettavien rivien määrästä, menetelmää ei ole mielekästä hyödyntää lainkaan kyseisen dimensionkohdalla. Toisaalta tehokkuushyötyä rajoittaa ainoastaan se, kuinka suuri osa faktataulun riveistä joudutaan palauttamaan [Wei02]. Tästä johtuen saavutettava hyöty voi olla merkittävä, jos faktataulun koko on suuri ja dimensiotauluun kohdistettava ehto hyvin leikkaava. Edellä kuvattuja menetelmiä on myös mahdollista hyödyntää yhdessä niin, että joidenkin dimensiotaulujen kohdalla käytetään hyväksi jompaakumpaa esitellyistä tehokkaammista menetelmistä ja toisten dimensiotaulujen yhteydessä hyödynnetään ensimmäisenä esiteltyä, yksinkertaista menetelmää. Tehokkaammat menetelmät on myös mahdollista yhdistää, jolloin joidenkin dimensiotaulujen kohdalla voidaan ottaa avuksi molempien parhaat puolet. Yhdistelymahdollisuuksista ja vaihtelevasta tehokkuushyödystä johtuen tietokantojen kyselyoptimoijat arvioivatkin usein etukäteen, mitä vaihtoehtoa kunkin dimension kohdalla kannattaa hyödyntää. 5. Yhteenveto Kuten olemme huomanneet, moniulotteinen tietomalli tarjoaa merkittäviä parannuksia tietovarastointiin. Relaatiomalliin verrattuna se tarjoaa huomattavasti selkeämmän tietorakenteen tiedon tallettamiseksi, mikä merkittävästi parantaa tietovaraston suorakäyttömahdollisuuksia. Tämän lisäksi se on myös usein tehokkaampi suorituskyvyllisesti ja tilan suhteen taloudellisempi. Etenkin näiden ominaisuuksien vuoksi se on vakiinnuttanut asemansa tietovarastojen ensisijaisena toteutusmallina huolimatta siitä, ettei aidoille moniulotteisille tietokannoille ole olemassa standardoitua toteutustapaa. Edellisen vastapainoksi olemme nähneet, että moniulotteinen tietomalli on mahdollista toteuttaa myös tavallisen relaatiotietokannan päälle tehokkaasti. Tulevaisuudessa moniulotteisen

12 tietomallin hyödyntäminen levinneekin yhä laajemmalle, sillä sen edut tiedon analysoinnissa on jo nyt todistettu käytännössä. Lähteet ChD97 Chaudhuri, S. ja Dayal, U., An Overview of Data Warehousing and OLAP Technology. ACM SIGMOD Record, 26:1, maaliskuu 1997, sivut 65-74. HaH01 Hasan, H. ja Hyland P., Using OLAP and Multidimensional Data for Decision Making. IT Pro, syys-lokakuu, 2001, sivut 44-50. KiW99 Kiviniemi J. ja Wolski A., OLAP-tekniikoiden käyttömahdollisuudet teollisuusprosessien analysoinnissa. Automaatio 1999, syyskuu, 1999, Helsinki. MoK00 Moody, D. L. ja Kortink, M. A. R., From Enterprise Models to Dimensional Models: A Methodology for Data Warehouse and Data Mart Design. Proceedings of the International Workshop on Design and Management of Data Warehouses, Tukholma, Ruosi, Kesäkuu 2000, sivut 5.1-5.12. PeJ01 Pedersen, T. B. ja Jensen, C. S., Multidimensional Database Technology. Computer, 34:12, joulukuu 2001, sivut 40-46. VaS99 Vassiliadis, P. ja Sellis, T., A Survey on Logical Models for OLAP Databases. ACM SIGMOD Record, 28:4, joulukuu 1999, sivut 64-69. Wei02 Weininger, A., Efficient Execution of Joins in a Star Schema. Proceedings of the 2002 ACM SIGMOD international conference on Management of data, Madison, Wisconsin, kesäkuu 2002, sivut 542-545. Weis1 Weisstein E. W., Hypercube. MathWorld A Wolfram Web Resource. <http://mathworld.wolfram.com/hypercube.html>.