Sisukord (andmeaitade dimensionaalne modelleerimine)Sisukord (andmeaitade dimensionaalne modelleerimine)..........................................................1

Sissejuhatus andmeaitadessse.....................................................................................................2

Ajalugu....................................................................................................................................3

Mis on andmeait?....................................................................................................................4

Andmelett................................................................................................................................6

Andmeaida roll kindlustuses...................................................................................................7

Dimensionaalne modelleerimine................................................................................................9

Milline on dimensionaalne mudel?.......................................................................................10

Dimensionaalse modelleerimise omadused..........................................................................12

Andmeletid ja dimensionaalne modelleerimine....................................................................13

Dimensionaalse modelleerimise tehnika...............................................................................14

Dimensionaalse mudeli üldkuju........................................................................................14

Dimensionaalse mudeli sees liikumine.............................................................................15

Lumehelbekese-struktuur..................................................................................................16

Surrogaatvõti.....................................................................................................................18

Dimensioontabeli disain....................................................................................................18

Aeglaselt muutuvad dimensioonid................................................................................18

Rämps-dimensioonid....................................................................................................20

Mitu-mitmele dimensioonid..........................................................................................20

Rollidega dimensioonid................................................................................................22

Dimensioonidevahelised hierarhiad..............................................................................22

Faktide tabeli disain..........................................................................................................25

Liidetav, poolliidetav ja mitteliidetav fakt....................................................................25

Faktideta faktide tabel...................................................................................................25

Erineva detailsuse astmega faktide tabelid ja ümberjaotamine....................................27

Kellaaeg dimensionaalses mudelis...............................................................................28

Erinevad mõõtühikud dimensionaalses mudelis...........................................................29

Erinevad rahaühikud faktide tabelis..............................................................................30

[1], [2], [3], [4]

Pieter Adriaans, Dolf Zantinge „Data mining”. Lk 1-3, 25-27.

Ralph Kimball “The data warehouse toolkit”. Lk xxiii-

Ralph Kimball, Laura Reeves, Margy Ross, Warren Thornthwaite “The Data Warehouse

Lifecycle Toolkit” Lk 10-11,

Sissejuhatus andmeaitadessseJutus “Babeli raamatukogu” kirjeldab Lõuna-Ameerika kirjanik Jorge Louis Borges

lõpmatut raamatukogu. Tegemist on lõputu ruumide võrguga, kusjuures ruumid on täidetud

raamaturiiulitega. Enamustel raamatutel ei ole tähendust ja neil on mõistetamatud pealkirjad

nagu “Axaxaxaxax mlö”. Inimesed liiguvad selles raamtukogus ringi kuni nad surevad,

teadlased arendavad raamatukogu kohta hüpoteese nagu ‘kusagil peab olema keskne

kataloog’, ‘raamatukogus on olemas kõikvõimalikuid raamatud’, ‘raamatukogul on lõpmatu

struktuur, mis kordab end lõpmatult’. Neid hüpoteese ei saa kontrollida, sest raamatukogu

sisaldab lõpmatul hulga andmeid, kuid ei mingit informatsiooni.

Babeli raamatukogu võib võrrelda situatsiooniga, milles end tänapäeval leiavame: me

elame universumis, kus on liiga palju andmeid ja liiga vähe informatsiooni. Suurest

andmehulgast informatsiooni leidmiseks vajalike võtete areng on üks peamisi väljakutseid

tarkvara arendajatele. Andmehulk maailmas kahekordistub igal aastal, selle tagajärjeks on aga

tähendusrikka informatsiooni järsk vähenemine. Me ei näe metsa puude tõttu.

Enamus rahvusvahelisi organisatsioone toodavad nädalas rohkem informatsiooni kui

enamik inimesi suudab elu jooksul lugeda. Oleme jõudnud olukorrani, kus rohkem andmeid

tähndab vähem informatsiooni. Tulevikus professionaalina, teadlasena või äriettevõttena

elujäämiseks ei piisa enam ainult lugemise ja interpreteerimise võimest. Mehaaniline andmete

tootlus ja taastootlus sunnivad meid omaks võtma strateegiaid ja arendama mehaanilisi

meetodeid andmete filtreerimiseks, valimiseks ja interpreteerimiseks.

Oskus õppida on elusolenditele omane ja seda isegi väga lihtsatele organismidele nagu

taimed ja amööbid. Taimed õppivad vastuvõetava valguse hulka maksimiseerima pöörates

oma lehed päikese poole – see on elementaarne keskkonnaga kohanemise vorm. Inimesed on

õppinud kasutama väga keerulist ja tundliku struktuuri – keelt – universumi seaduspärade

uurimiseks. Evolutsiooniteooria õpetab, et ellu jäävd vaid need liigid, mis suudavad

keskkonnaga kohaneda.

Organisatsioonidel on tänapäeval surve turu muutustele kiiresti vastata. Loogiliste

otsuste langetamiseks vajavad nad kiiret juurdepääsu kõikvõimalikule informatsioonile.

2

Organisatsiooni jaoks õigete otsuste langetamiseks on oluline uurida minevikku ja leida

asjakohaseid trende. Ilmselgelt peab sellise analüüsi tegemiseks olema juurdepääs kogu

toetavale informatsoonile, mis aga on salvestatud väga suurtesse andmebaasidesse. Lahendus

sellistele andmetele juurdepääsuks ja efektiivsele otuste langetamisele on andmeaida

paigaldamine.

Ajalugu

Andmetöötluse eesmärgiks 1960ndatel oli organisatsiooni tööks vajalike kannete

automatiseerimine, alustades sageli raamatupidamise funktsioonidega nagu pearaamat,

nõuded jne. Arvutusvõimsuse ja andmete hoiustamisvõimaluste kasvades automatiseeriti üha

rohkem rakendusi. Iga uue funktsiooniga tekkis ettevõttele juurde üha rohkem andmeid.

Andmed olid aga konkreetsele rakendusele spetsiifilistes failides ja andmebaasides kinni.

Hoolimata suurtest andmehulkadest, paistis juhtidele kättesaadava informatsiooni kvantiteet ja

kvaliteet aastate jooksul kahanevat: andmed olid lukustatud suurtesse süsteemidesse ja

nendeni jõudmine oli äärmiselt keeruline.

1980ndatel hakati failidesse salvestatud andmeid ja hierarhilisi andmebaase asendama

relatsiooniliste andmebaasidega, mis pidid võimaldama võrdset juurdepääsu. Kui müügi

andmebaas koosnes toote, turu ja aja olemitest, ei sõltunud lõpptulemus sellest, kas küsiti

toote küsimus enne turu küsimust või vastupidi. Hierarhiliste andmebaaside korral tuli

küsimusi esitada kindlas järjekorras andmebaasi juurest alates. Loodeti, et relatsiooniliste

andmebaaside kasutuselevõtt vabastab lõpuks ettevõtte informatsiooni.

Relatsioonilisi andmebaase ei saanud siiski kasutada väga efektiivselt, kuna nad ei

sisaldanud veel andmeid. Niisiis hakati kasutama relatsioonilisi tehnoloogiaid primaarsete

äritoodangute nagu tellimused, arved ja ärikannete andmete kogumiseks. Peatselt jõuti

probleemini: varased relatsioonilised süsteemid olid kahetsusväärselt aeglased kannete

töötlemiseks.

Kannetetöötlemise kriisi positiivne külg oli, et see sundis tootjaid parandama

relatsiooniliste andmebaaside tarkvara. Samas aga keskenduti kannete töötlemisele ning

paistis justkui oleks relatsiooniliste andmebaaside eesmärk andmete sisestamine mitte nende

kätte saamine.

1980ndate aastate lõpus hakati arendama uut tüüpi rakendust, mille eesmärgiks oli

sellise andmehoidla tekkimine, mis koondaks endasse olulised andmed organisatsiooni

erinevatest rakendustest. Termini “andmeait” (ingl.k. data warehouse) võttis esimesena

kasutusele Bill Inmon 1990, kes ise defineeris termini järgnevalt: andmeait on subjekt-

3

orienteeritud, integreeritud, ajast sõltuv püsivate andmete kogu, mille eesmärk on toetada

otsustelangetamise protsessi.

Mis on andmeait?

Organisatsiooni töös eristatakse kahte fundamentaalselt erinevat arvutisüsteem:

tegevussüsteem (ingl. k. operational system) ja informatsioonisüsteem (ingl. k. informational

system). Tegevussüsteemid funktsioon on ärikannete talletamine, nad töötlevad ja haldavad

andmeid ettevõtte igapäevase töö toetamiseks (raamatupidamissüsteemid,

palgaarvestussüsteemid jne). Informatsioonisüsteemid on loodud andmete analüüsimiseks ja

otsuste langetamiseks, nende struktuur on modelleeritud tegevussüsteemi andmete

arhiveerimiseks. Kui tegevussüsteemide andmed on tavaliselt väiksemast valdkonnast, siis

informatsioonisüsteemid võivad hõlmata andmeid mitmetest valdkondadest ja seega vajada

suurt hulka seonduvaid tegevusandmeid. Tegevussüsteemide puhul on oluline jõudlus,

informatsioonisüsteemidel lai skoop ja paindlikkus.

Andmeait on teatavate karakteristikutega andmekogu, mida kasutatakse tavaliselt

analüüsi eesmärkidel. Andmeait on subjekt-orienteeritud, ajast sõltuv, integreeritud ja

puhastatud andmetega (tähendusega ja sisuga kooskõlalised andmed), optimiseeritud, et

toetada analüüsi vahendeid ja organisatsiooni funktsionaalsust, täiesti kõlbmatu kasutuseks

tegevussüsteemina. Et ärianalüüsiks salvestatud andmetele on kõige parem ligi pääseda

eraldades nad andmetest tegevusandmebaasides, ongi andmeaida eesmärk vabastada

informatsioon, mis on lukustatud tegevusandmebaasides ja täiendada seda informatsiooniga

teistest – sageli välistest – andmeallikatest. Andmeait võib kombineerida andmeid mitmetest

allikatest nagu müük, turundus, finants ja tootlus, olla seesmistest ja välistest allikatest saadud

integreeritud andmete hoidla, mis sisaldab lisaks detailsetele andmetele ka summaarseid

andmed.

Andmeaida subjektile orienteeritus tähendab, et andmeait disainitakse ettevõte ühe

tegevusala jaoks, andmed on organiseeritud ümber teemade (nagu müük) mitte ümber

operatsiooniliste programmide (nagu tellimuste töötlemine). Andmeait ei sisalda

informatsiooni, mida ei kasutata andmete analüütilisel töötlemisel.

Andmeait on ajast sõltuv: ta sisaldab aja jooksul kogutud informatsiooni, mis

tähendab, et alati peab olema ühendus andmeaidas oleva informatsiooni ja sisestamise aja

vahel. Kõik andmed andmeaidas on täpsed mingil ajahetkel, tagades nii ajaloolise vaate

andmetele. Pea kõik andmed tüüpilises andmeaidas on korraldatud aja-dimensioonist

lähtuvalt. Et andmeaidad on loodud tegevusandmete arhiveerimiseks, säilitatakse andmeid

4

seal väga pikka aega. Andmeaita laetud andmete säilitamise maksumus on minimaalne.

Enamus kuludest on seotud andmete üleviimisega ja puhastamisega. Suur osa andmeaida

päringutest kasutab aega peamise filtreeriva kriteeriumina. Aja-dimensioon kasutatakse

andmeaidas peamise ristviitamise tunnusena. Ajast sõltuvus on oluline aspekt andmeaitade

juures, kuna ta seob andmeaidanduse andmekaevandusega (ingl.k. data mining).

Andmeait peegeldab organisatsiooni äri-informatsiooni. Andmeaita on kogutud

andmeid erinevatest allikatest ja liidetud kooskõlaliseks tervikuks, seega on andmeait

integreeritud andmekogu.

Andmeaita toodud andmed on püsivad (ingl.k. non-volatile) st pärast seda, kui

andmed on jõudnud andmeaita, ei tohiks selle informatsiooniga enam mingeid muudatusi

teha. Andmed andmeaidas on staatilised, mitte dünaamilised. Näiteks ei muutu ei tellimuse

staatus ega ka turunduse müügikampaania detailid. Andmed tegevussüsteemidest liiguvad

andmeaita, kui enamus olemitega seotud tegevustest on lõpetatud. Oluline on mõista, et pärast

seda, kui andmed on jõudnud andmeaita, muudetakse neid vaid äärmuslikel juhtudel. Pidevalt

muutuvad andmed edastatakse andmeaita hetketõmmiste (ingl.k. snapshot) kaupa. Seega on

andmeait alati täidetud ajalooliste andmetega.

Lõpp-taseme kasutaja jaoks vajalik informatsioon on andmeaidas olemas, kusjuures

andmeait on struktureeritud nii, et vajalike andmeid on sealt kerge leida. Andmeaida disain on

mõeldud otsuste langetamise päringuteks, seega eraldatakse tegevusandmetest vaid see osa

andmetest, mis on vajalik otsuste langetamiseks, ja salvestatakse andmeaita.

Andmeaidale esitatavad fundamentaalsed nõuded on:

Andmeait võimaldab ligipääsu organisatsiooni andmetele. Andmeaida struktuur

on mõistetav (korrektselt sildistatud, ilmne) ja ligipääsetav ning ligipääsu

iseloomustab kõrge jõudlus.

Andmeaida andmed on terviklikud. Informatsioon organisatsiooni ühest osast

võib olla ühildatud informatsiooniga organisatsiooni teisest osast. Kui kahel

organisatsiooni mõõdul on sama nimi, siis nad peavad tähendama sama asja.

Terviklik informatsioon tähendab kõrgekvaliteedilist informatsiooni st

informatsioon peab olema põhjendatud ja täielik.

Andmeait on elastne ja kohandatav andmeallikas. Andmeait on disainitud

pidevaks muutumiseks. Kui andmeaita lisatakse uusi andmeid, ei muudeta

olemasolevaid andmeid. Andmeait moodustub andmelettidest (ingl.k. data mart).

Erinevate andmelettide disain peab olema hajutatud ja kuhjuv.

Andmeid andmeaidas saab eraldada ja kombineerida iga võimaliku äri mõõduga.

5

Andmeait on otsuste langetamise nurgakivi. Andmeaidas on otsustelangetamiseks

vajalikud õiged andmed.

Andmelett

Andmeaidad on tavaliselt väga suured ja sageli ka ebaloomulikult homogeensed

andmekogumid. Andmete homogeensuse tagamiseks kasutatavad struktuurid muudavad aga

andmeaida hoiustamise ja säilitamise keeruliseks. Samuti peab andmeait olema sageli

ehitatud vastamaks konkreetse kasutajategrupi vajadustele. Andmelett on lahendus ühele

olulisemale konfliktile andmeaida disainis: jõudlus paindlikkuse vastu.

Andmelett on subjekt-orienteeritud organistasiooni andmete kogu, mida kasutatakse

analüütilistel eesmärkidel. Andmeleti eesmärgiks on vähendada andmebaasi mahtu

spetsiifilistele subjektidele keskendudes, mis võimaldab modelleerida andmeid intuitiivsemal

viisil ja tagada sellega ka parem ligipääs informatsioonile. (www.carolla.com/wp-dw.htm).

Andmelett sisaldab vaid neid andmeid, mis on vajalikud spetsifitseritud äriküsimustele

vastamiseks.

Tavaliselt on andmelett disainitud vastamaks ühe osakonna vajadustele, toetamaks

nende otsustelangetamise protsessi. Sageli nimetatakse andmeletti ka kohalikuks

andmeaidaks (ingl.k. local data warehouse). Andmelett sisaldab mõõdukalt ajaloolisi

andmeid ning andmed andmeletis on viidud niisugusele detailsuseastmele, mis vastab

kasutajate vajadustele.

Sõltuvalt andmeleti seosest ettevõtte andmeaidaga (ingl.k. enterprise data warehouse

– EDW) eristatakse kolme tüüpi andmelette: sõltuvad andmeletid, sõltumatud andmeletid ning

andmeait ise moodustub andmelettidest.

Sõltuv andmelett on selline andmelett, mis kasutab andmeallikana tsentraalset

organisatsiooni andmeaita. Sõltuvad andmeletid on arhitektuuriliselt ja struktuuriliselt

terviklikud. Sõltumatut andmeletti eristab sõltuvast asjaolu, et tema andmeallikaks on

tegevussüsteemid. Sõltumatud andmeletid on peibutavad, sest nende ehitamine on odav, lihtne

ning võtab vähe aega, kuid mitme andmeleti korral tekib andmete liiasus ning pikemas

perspektiivis vaadelduna on sõltumatud andmeletid ebastabiilsed ja sõltuvate andmelettidega

võrreldes arhitektuuriliselt ebakindlamad. (http://www.dmreview.com/article_sub.cfm?

articleId=1675).

file:///C:/Documents%20and%20Settings/Piret/My%20Documents/InfBak/New%20Folder/

Andmeaitadest.htm

6

Kolmas tüüp andmelette on sellised, mille korral andmeletid moodustavad andmeaida.

Sellise lähenemise korral ehitatakse organisatsiooni andmeletid ning tegevuspoole inimesed

pääsevad ligi kas kõigile või mõnele neist. Teoreetiliselt on lihtsam ning kiirem ehitada

andmelette ning kui andmelett on valmis, siis hankida andmeid neist kõigist, kui ehitada ning

hooldada tsentraalset andmeaita. Sellist lähenemist kasutades on oluline tagada, et andmeid

erinevates andmelettides on võimalik korralikult kasutada ning et need andmed on täielikud.

(www.datawarehouse.com/article/?articleid=2997)

Andmeaida roll kindlustuses

Kindlustus on oluline ja kasvav sektor andmeaitadeturul. Äri kasvu jätkamiseks on

kaks peamist võimalust: preemiate kasv või kulude vähendamine. Konkurents sunnib

kindlusfirmasid kaaluma kliendi-vaenulike hinnakirju. Selles situatsioonis ei jää muud üle kui

otsida teid ja vahendeid kulude vähendamiseks. Kulud selles harus tulevad pea täielikult

nõuetest.

Kindlustusseltsid sooritavad keerulisi tehinguid, mida tuleb analüüsida mitmel

erineval viisil. Andmebaasides, mille suurused ulatuvad terabaitidesse, on kiire ligipääs

andmeanalüüsile raske, kuid hädavajalik. Tegevussüsteemid on modelleeritud andmete

efektiivseks kogumiseks mitte väljastamiseks, andmed on aga sageli hajutatud mitmetes

tegevussüsteemides. Seega andmete tihedam sidumine ja ühtsel terviklikul viisil esitamine on

väljakutse mitmetele kindlusseltsidele

Kindlustusseltsid säilitavad tohututes kogustes andmeid oma tegevuse ja klientide

eelistuste kohta. Nende andmete sees on varjatud mustrid, mis paljastavad tarbijate tüüpilist

käitumist ja mis aitavad ettevõtetel häälestada oma turundusstrateegiat, vähendada riske.

Kindlustust võib nimetada esimeseks andmeanalüüsi kasutavaks äriks, mis arenes enne

automatiseerimis ajastut. Tasuvus kindlustusharus vajab suure täpsusega riskide ja preemiate

hindamist.

Andmeaitasid saab kindlustuses rakendada nii seaduses sätestatud kui ka äri

valdkondades, seal hulgas:

Õigeaegsed ja täpsed finants- ja regulatiivaruanded

Aruannete ja analüüsi sisemine jõudlus

Kliendi seoste haldus (ingl.k. Customer Relationship Management – CRM)

Kliendi, toote ja ettevõtte kasumlikkus

Ettevõtte rahanduslik tugevdamine ja kindlustamine

7

Andmeaida efektiivne rakendamine ja kasutamine annab tulemusi järgmistes

valdkondades:

Müügikulude vähendamine efektiivsete komisjonide, vahendajate ja

analüüsikanali tõttu.

Märkimisväärsed tulemused turunduse parandamises ja otsemüügis klientide

segmentatsiooni ja võimaluste identifitseerimise tõttu.

Parandatud müügihinnad arenenud analüütika ja kaevandamise tehnika tõttu.

Klientide rahulolu kasv parema nõuete haldamise jälgimise tõttu.

Parem tootearendus komponentide tasemel toote kasumlikkuse analüüsi tõttu.

8

Dimensionaalne modelleerimineMudel on millegi reaalselt eksisteeriva enamasti lihtsustatud esitus. Organisatsiooni

andmemudel kirjeldab organisatsiooni andmevajadust. Andmete modelleerimise (ingl.k. data

modeling) idee on andmeaidandusest üle kümne aasta vanem. Andmete modelleerimise

eesmärgiks on saada 360kraadine vaade organisatsioonist ja tema andmetest. Andmete

modelleerimise tulemuseks on tabelite ja nendevaheliste seoste graafiline esitus. Et

andmeaitade eesmärgiks on tuua korda andmete kaosesse, on andmeaida loomise juures

oluline andmete modelleerimise juures kasutada andmetest mitte protsessidest lähtuvat

vaadet. (http://database.ittoolbox.com/browse.asp?c=DBPeerPublishing&r=http%3A%2F

%2Fwww%2Eteradata%2Ecom%2Ft%2Fpdf%2Easpx%3Fa%3D83673%26b%3D130575)

Andmeaida andmete modeleerimisel kasutatakse enamasti kas olemi-seose

modelleerimist (ingl.k. entity-relationship modeling), dimensionaalset modelleerimist (ingl.k.

dimensional modeling) või siis mõlemaid koos. Olemi-seose modelleerimistehnikad kujutavad

andmete struktuuri, samas dimensionaalsed tehnikad modelleerivad andmete tähendust. Ei saa

öelda, et on olemas õige või vale modelleerimistehnika. Nii olemi-seose modelleermistehnikal

kui ka dimensionaalselt modeleerimistehnikal on omad plussid ja miinused. Olgu siinkohal

siiski öeldud, et teemakohases kirjanduses soovitatakse enamasti modelleerida andmeait

dimensionaalselt.

Olemi-seose modelleerimine on loogilise disaini tehnika, mida kasutatakse

andmeelementidevaheliste mikroskoopiliste seoste illustreerimiseks, näiteks ettevõtte

ärireeglite kirjeldamiseks. Selle distsipliini eesmärk on kaotada liiasus andmete vahel, mis on

aga eriti kasulik kannete töötlemise juures tegevussüsteemides, kuna muudab kanded väga

lihtsaks ja deterministlikuks. Olemi-seose mudeli saab ehitada subjekt-orienteeritult ning

mudeli struktuuri on võimalik kaasata ka ajafaktor. Andmeaitade disainis on olemi-seose

mudel viidud tavaliselt võimalikult lähedale kolmandale normaalkujule. Olemi-seose

modelleerimise juures on aga omad miinused:

Lõpp-kasutajatel on raske mõista ning meeles pidada olemi-seose mudelit. Lõpp-

kasutajad ei saa liikuda olemi-seose mudelis. Ei ole olemas graafilist kasutajaliidest,

mis teeks üldise olemi-seose mudeli lõppkasutajatele mõistetavaks. Näiteks joonisel 1

on kujutatud lihtne süsteem tellimuste vastuvõtmiseks, kuid selle süsteemi olemi-seose

mudel koosneb paljudest tabelitest ning lõpp-kasutajal on keeruline sealt talle huvi

pakkuvat infot kätte saada.

9

Joonis 1. Olemi-seose mudel ettevõttele, kes müüb tooteid jaemüügi kettidele ja mõõdab jaemüüjate

efektiivsust

Tarkvara ei saa kasulikult teha päringuid üldisesse olemi-seose mudelisse.

Maksumusel põhinevad optimiseerijad, mis püüavad seda teha, langetavad sageli

valesid otsuseid ja nende jõudlus on märkimisväärselt halb.

Seega ei ole olemi-seose mudel intuitiivne ning tema jõudlus on madal.

(http://www.dmreview.com/editorial/online/ate_view.cfm?articleId=4409&topicId=230008)

Milline on dimensionaalne mudel?

Dimensionaalne modelleerimine on loogilise disaini tehnika, mille eesmärk on esitada

andmed standardses raamistikus, mis on intuitiivne ja võimaldab kõrge jõudlusega

juurdepääsu. Dimensionaalne modelleerimine sarnaneb ditsipliinile, mis kasutab

relatsioonilist modelleerimist mõnede oluliste piirangutega. Iga dimensionaalne mudel

koosneb enamasti ühest tabelist, mille võti koosneb paljudest osadest ja mida nimetatakse

faktide tabeliks (ingl.k. fact table), ning hulgast väiksematest tabelitest, mida nimetatakse

dimensioonide tabeliteks (ingl.k. dimension table). Faktide tabelit nimetatakse mõnikord ka

mõõtjaks (ingl.k. meter). Dimensionaalset mudelit luues võib ette tulla olukordi, kus ühel

mudelil on mitu faktide tabelit, kuid sellised mudelid on harvaesinevad. Faktide tabelit

iseloomustab faktide tabeli fundamentaalne seeme, mis näitab kui sageli pannakse andmeid

10

tegevussüsteemidest andmeaita (kord päevas, kord nädalas, kord kuus jne). Igal dimensiooni

tabelil on üheosaline primaarne võti, mis vastab täpselt ühele faktide tabeli mitmeosalise

võtme osale (vt joonis 2). Dimensionaalsele modelleerimisele on iseloomulik tähekujuline

struktuur (ingl.k. star join schema).

Joonis 2. Joonisel 1 kujutatud süsteemi jaemüügi protsessi dimensionaalne mudel

Et faktide tabelil on mitmeosaline võti, mis moodustub kahest või rohkemast välisest

võtmest, väljendab alati mitu-mitmele seost. Tavaliselt sisaldab faktide tabel ka ühte või

rohkemat arvulist liidetavat fakti, mis on tõesed võtmete kombinatsiooni korral. Faktide

liidetavus on väga oluline, kuna andmeaida rakendused ei otsi pea kunagi välja ühte faktide

tabeli kirjet. Tavaliselt on tulemuseks sadu kirjeid korraga ja mõistlik on kui nendega on

võimalik teha aritmeetika põhitehteid.

Dimensioonide tabel sisaldab enamasti kirjeldavat tekstilist informatsiooni.

Dimensiooni atribuudid on andmeaida päringute kõige huvitavamate piirangute allikaks ning

struktureeritud päringute keele (ingl.k. structured query language – SQL) vastustes ridade

pealkirjade allikaks. Dimensioonide tabelid on andmeaita sisenemisepunktid.

Andmebaasi dimensionaalse mudeli võlu on, et ta on lõpp-kasutajate jaoks mõistetav

ja lõpp-kasutajad nõustuvad, et tegemist on n.-ö. nende tegevusega.

11

Dimensionaalse modelleerimise omadused

Andmeaida seisukohast on dimensionaalsel modelleerimisel mitmeid omadusi, mida

dimensionaalselt modeleerides on kergem realiseerida kui olemi-seose modeleerimistehnikat

kasutades.

Esiteks on dimensionaalne modelleerimine standardne raamistik. Aruannete ja

pärigute tegemise vahendite ning kasutajaliideste puhul eeldatakse, et andmeait on

modelleeritud dimensionaalseks. Näiteks: peaaegu kõik lõpp-kasutaja poolt päringutesse

seatud piirangud, on pärit dimensioonitabelitest ning seega saab lõpp-kasutaja vahend tagada

bitivektoritest indeksite abil dimensiooni atribuutide lehitsemise kõrge jõudluse. Metaandmed

saavad kasutada dimensiooni väärtuste teadaolevaid võimsusi, et suunata kasutajaliidese

käitumist. Erinevalt maksumusel põhinevast optimiseerija saab andmebaasi mootor teha

tugevaid oletusi kõigepealt piirates dimensioonide tabeleid ja siis “rünnates” faktide tabelit

Cartesiuse korrutisega nende dimensioonide tabelite võtmetest, mis rahuldavad kasutaja

piiranguid. Selline lähenemine võimaldab väärtustada n-suunalise ühenduse faktide tabeliga

läbides faktide tabeli indeksi üheainsa korra. Samas ei pruugi ühtne raamistik kõikides

situatsioonides sobiv olla. Dimensionaalse mudeli ehitamisel kasutatakse eeldefineeritud

seoseid, mis on küll väga kasulikud teatud äriküsimustele vastamisel, kuid võivad takistada

keerulisematele küsimustele vastuste leidmist. Erinevad inimeste grupid ettevõtetes vajavad

andmetest erinevaid vaateid ning sageli on keeruline jagada üht andmeaita.

Teine dimensionaalse modelleerimise omadus on tähekujuline struktuur, mis peab

vastu ootamatutele muutustele kasutaja käitumises. Iga dimensioon on ekvivalentne. Kõiki

dimensioone saab vaadelda sümmeetriliselt võrdsete sisendpunktidena faktide tabelisse.

Loogilist disaini saab teha sõltumata oodatavate päringute mustrist. Kasutajaliidesed on

sümmeetrilised ja päringu strateegiad on sümmeetrilised.

Kolmas dimensionaalse modelleerimise omadus on, et ta on kergesti kohandatav uute

andmeelementidega ja uute disaini otsustega. Ühtegi päringu või aruande tegemise vahendit ei

pea muutmise korral ümber programmeerima ning vanad rakendused töötavad muutmise

korral samamoodi kui varem ning annavad samu tulemusi. Kõiki olemasolevaid tabeleid saab

muuta lisades uusi andmeridu tabelisse. Faktide tabelisse saab lisada uusi fakte juhul, kui nad

on kooskõlas olemasoleva faktide tabeli fundamentaalse seemnega. Kogu mudelisse saame

lisada täiesti uusi dimensioone, kuid üks uue dimensiooni väärtus on seotud iga olemasoleva

faktide tabeli kirjega. Dimensioonide tabelisse saame lisada uusi atribuute.

12

Neljas dimensionaalse modelleerimise omadus on mitmete standardsete lähenemiste

olemasolu ärimaailma sarnaste modeleerimissituatsioonide käsitlemiseks nagu näiteks

aeglaselt muutuvad dimensioonid, ettemaksuga andmebaasid jne. Dimensionaalne mudel

toetab küll ajaloo talletamist läbi muutuvate dimensioonide, kuid sõltuvalt muutuste tüüpidest

võib andmemudel muutuda väga keeruliseks.

Andmeletid ja dimensionaalne modelleerimine

Sõltuvalt andmelettide ja andmeaida vahelistest seostest, saab kombineerida ka

dimensionaalset ja olemi-seose modeleerimistehnikat. Sõltuvate andmelettide korral kirjeldab

andmeait ettevõtte ärireegleid, on andmelettide andmeallikaks ning otsest ligipääsu andmetele

toetab vaid sekundaarse eesmärgina. Andmelett on intuitiivne ligipääs tegevusvaldkonna

kasutajate jaoks. (www.datawarehouse.com/article/?articleid=2908). Üldiselt mida

normaliseeritum ning paindlikum andmemudel on, seda kehvem on päringute jõudlus, sest

normaliseertud disaini korral kasutatakse päringus optimiseeritud disainist rohkem tabeleid.

Seega võib sõltuvate andmelettidega disaini korral modelleerida andmeletid dimensionaalselt

ning andmeaida olemi-seose modellerimistehnikat kasutades. Nii on lõpptaseme kasutajate

jaoks andmeletid optimiseeritud disainiga, kuid andmed andmeaidas on modelleeritud

paindlikult. (www.datawarehouse.com/article/?articleid=3204)

Andmeaidas, mis moodustub erinevatest andmelettidest, on andmeletid omavahel

ühendatud andmeaida magistraal-arhitektuuri (ingl.k. Data Warehouse Bus Architecture)

kasutades. Iga andmeleti struktuur modelleeritakse dimensionaalselt, kusjuures ühe

andmeaida siseselt peavad kõik andmeletid olema ehitatud kooskõlas olevatest

dimensioonidest ja faktide tabelitest. Kooskõlaline dimensioontabel on selline

dimensioontabel, mille tähendus on sama iga faktide tabeli, millega teda saab ühendada,

korral. Kooskõlaliste faktide määratlust on vaja, kui erinevates andmelettides kasutatakse

sama terminoloogiat. Kooskõlalised faktid on näiteks kasum, aastatulu, standard hind ja

standard kulu. Kui kõik andmeletid jaotada laiali üksikuteks füüsilisteks tabeliteks erinevatele

andmebaasi serveritel, siis ainus füüsiline viis andmete kombineerimiseks erinevatest

tabelitest ning integreeritud andmeaida saavutamiseks on, kui andmete dimensioonid

tähendavad sama kõikides mudelites. Kooskõlalised dimensioonid ja faktid ongi andmeaida

‘magistraaliks’.

http://dw.ittoolbox.com/browse.asp?c=DWPeerPublishing&r=http%3A%2F%2Fwww

%2Eavanco%2Ecom%2Fd%5Fwarehouse%2Ehtm

13

Dimensionaalse modelleerimise tehnika

Selles alampeatükis tutvustatakse lähemalt standardset dimensionaalse modelleerimise

tehnikat.

Dimensionaalse mudeli üldkuju

Dimensionaalse modelleerimise fundamentaalne idee on, et peaaegu igat tüüpi

tegevuse andmeid saab esitada andmekuubikuna, kus kuubiku küljed sisaldavad mõõdetud

väärtusi ja kuubiku servad määravad andmedimensioonid (vt joonis 3). Iga punkt kuubikus on

kuubi servade poolt määratud koordinaatide lõikepunktides. Muidugi on disainitud mudelites

rohkem kui kolm dimensiooni, sellest tulenevalt nimetatakse seda kuubikut ka

hüperkuubikuks (ingl.k. hypercube). Dimensionaalne mudel koosneb tavaliselt 4 kuni 15

dimensioonist.

Joonis 3. Tegevuse dimensionaalne mudel: iga punkt kuubikus sisaldab mõõdetavadi suurusi konkreetse

aja, toote ja turu kombinatsiooni kohta

Dimensionaalse mudeli korral eristatakse fakte ja atribuute. Fakt on tavaliselt miski,

mis ei ole varasemalt teada. Paljud faktid ärimaailmas on arvulised, kuigi võib esineda ka

tekstilisi tunnuseid, ja iga numbrilise tunnuse puhul peaks tekkima kahtlus, et tegemist on

faktiga mitte atribuudiga. On numbrilisi tunnuseid (nagu näiteks “standard hind”), mis esialgu

tunduvad olevat varasemalt teada olevad (näiteks toodet) iseloomustavad atribuudid, lähemal

vaatlemisel aga on näha, et nende väärtusi muudetakse paar korda aastas ja seega peaks olema

tegemist faktide tabeli tunnusega.

Atribuudid on tavaliselt kirjeldavad tekstilised tunnused. Kõige ilmsemad atribuudid

on toote karakteristikud nagu näiteks toote maitse, mida ei saa mõõta ja mida me teame ette.

Luues uue toote uue maitsega, loome uue tootedimensiooni kirje. Tekstilised atribuudid on

14

organiseeritud dimensioonidesse. Dimensioon on kogum atribuutidest, mis on tugevalt

üksteisega korreleeritud.

Dimensionaalse mudeli sees liikumine

Liikumise dimensionaalse mudeli sees saab jagada sügavamale liikumiseks (ingl.k.

drill down) ja üldisemale tasemele liikumiseks (ingl.k. drill up).

Dimensionaalses mudelis mängivad dimensioontabelite atribuudid olulist rolli. Need

atribuudid on tekstilised või käituvad tekstiliste väärtustena, nad on diskreetsete väärtustega

ning nad on rakenduses piirangute ja aruannetes ridade päiste allikaks. Kasutaja saab luua

aruandesse rea päise vedades dimensiooni atribuudi suvalisest dimensioontabelist aruandesse

(vt joonis 4). Dimensionaalse mudeli eelis on, et kõik dimensioonide atribuudid saavad olla

ridade päisteks. Raportisse saab lisada nii palju ridade päiseid kui kasutaja soovib. Seega

näeme, et sügavamale liikumine ei tähenda muud kui päringu täpsustamist, näiteks lisades

olemasolevasse SQL päringusse dimensioontabelist rea päise.

Üldisemale tasemele liikumine on ridade päiste eemaldamine, kusjuures ridade päiseid

ei pea eemaldama samas järjekorras kui neid lisati. Iga kord kui kasutaja lisab või eemaldab

rea päise, luuakse uus tabelite ühendamise päring.

15

Joonis 4. Tähekujulise struktuuri ja aruande seos

Lumehelbekese-struktuur

Öeldakse, et dimensionaalne mudel on lumehelbekese kujuga (ingl.k. snowflake

schema), kui need dimensiooni väljad, millel on vähem erinevaid väärtusi, viiakse üle eraldi

tabelitesse ja ühendatakse originaaltabeliga kunstlike võtmetega. Näide lumehelbekese kujuga

dimensioonist on toodud joonisel 5. Üldjuhul ei ole andmeaida modelleerimisel soovitav

kasutada lumehelbekese struktuuriga dimensioone. Lumehelbekese-struktuur muudab

lõppkasutaja jaoks andmeaida kasutamise keerulisemaks ja päringud aeglasemaks. Mõnikord

loodetakse hoida kokku vaba ketta ruumi, kuid arvestades andmeaida suurust ning uute

võtmete hoidmisele kuluvat ruumi on kokkuhoid väga väike ega kaalu üles sellega kaasnevaid

kaotusi kiiruses ja lihtsuses. Enamasti soovitatakse kasutada tähekujulise-struktuuriga mitte

lumehelbekese-struktuuriga dimensionaalset mudelit.

16

Joonis 5. Näide juhust, kus lumehelbekese-struktuur ei õigusta end

Hoolimata lumehelbekese-struktuuri miinustest, on siiski situatsioone, kus on kasulik

luua dimensioonile alamdimensioone. Näiteks joonisel 6 on alamdimensioon hulk

demograafilisi atribuute, mis on mõõdetud selle maakonna jaoks, kus klient elab. Kõigil ühe

maakonna elanikel on samad demograafilised atribuudid. Demograafilised andmed sisaldavad

50 erineva demograafilise maakonna nime, suurust ning maakonna ja riigi elanike arvu suhet

väljendatuna protsentides. Antud juhul on mõistlik kasutada alamdimensiooni, sest

demograafilise tabeli väärtused võivad olla sageli eraldi huvipakkuvaks materjaliks, suure

kliendi dimensiooni korral hoiame kokku palju ruumi ning ilmselt administreeritakse neid

tabeleid iseseisvalt ja erinevatel aegadel.

Joonis 6. Näide mudelist, kus lumehelbekese-struktuuri kasutamine on mõistlik

Lisaks on olemas situatsioone, kus tähekujulise-struktuuriga mudelit ei olegi võimalik

andmete põhjal luua ning andmeid tuleb modelleerida lumehelbekese-struktuuriga. Näiteks

situatsioon, kus soovime, et faktide tabel kirjeldaks igakuiseid klientidele saadetud arveid

ning faktide tabel on ühendatud kliendi dimensiooniga. Mis saab aga siis, kui üks arve

saadetakse mitmele toakaaslasele? Sellised situatsioonid ei ole harvad. Mõistlik on

aktsepteerida, et arvel võib olla mitu klienti, sellist situatsiooni nimetatakse loomulikuks

dimensioonide kordsuseks (ingl.k. Natural Dimension Multiplicity). Loomuliku dimensiooni

ja fakti valiku korral on tähekujulise-struktuuri korral dimensioontabeli ja faktide tabeli vahel

mitu-mitmele seos. Sellise situatsiooni lahendamisest on täpsemalt juttu alapeatükis Mitu-

mitmele dimensioonid. (http://www.datawarehouse.com/article/?articleid=3004)

17

Surrogaatvõti

Kõik dimensionaalse mudeli võtmed peavad olema ilma tähenduseta surrogaatvõtmed

(ingl.k. surrogate key). Kõikidel dimensioontabelitel on üheosalised võtmed, mis definitsiooni

järgi on primaarsed võtmed st võti määrab kirje unikaalsuse dimensioontabeli sees.

Surrogaatvõti on asendus algsele primaarsele (välisele) võtmele, iga rea unikaalne

identifikaator, mida saab kasutada tabeli primaarse võtmena. Surrogaatvõtit kasutatakse, sest

algse primaarse võtme väärtus (näiteks kliendi number) võib muutuda, mis toob endaga kaasa

suuremaid probleeme. Surrogaatvõtme ja primaarse võtme erinevust saab edukalt ära kasutada

aeglaselt muutuvate dimensioonide korral (vt alapeatükk Aeglaselt muutuvad dimensioonid)

Vältida tuleb n.-ö. tarku võtmeid (ingl.k. smart key), millel on tähendus st dimensiooni

primaarne võti ei tohiks koosneda dimensioontabeli atribuutidest ning sellest tulenevalt ei

tohiks dimensioontabeli ühendus faktide tabeliga olla kahe- või kolmekordne, mis kasutaks

mitmeid välju ühenduse kummastki otsast.

(http://datawarehouse.ittoolbox.com/documents/document.asp?i=1501)

Dimensioontabeli disain

Aeglaselt muutuvad dimensioonid

(http://www.windowsitpro.com/SQLServer/Article/ArticleID/25544/25544.html)

(http://www.1keydata.com/datawarehousing/scd.html)

Enamasti on dimensioonid üksteisest loogiliselt sõltumatud, kuid esineb dimensioone,

mis sõltuvad ajast: inimeste nimed muutuvad, nad abielluvad ja lahutavad, peredesse sünnib

lapsi juurde ning perekonnad kolivad. Kuidas hallata selliseid dimensioone? Kõiki muutuda

võivaid andmeid ei saa panna faktide tabelisse ega muuta dimensioone ajast sõltumatuks.

Selle asemel eeldatakse, et enamus dimensioone on ajas peaaegu konstantsed ning säilitatakse

sõltumatu dimensionaalne struktuur väikeste lisadega dimensioonide ajas muutuvate andmete

säilitamiseks. Selliseid peaaegu konstantseid dimensioone nimetatakse aeglaselt muutuvateks

dimensioonideks (ingl.k. slowly changing dimension).

Vaatame näitena ettevõtte andmeaida kliendi dimensiooni (vt joonis 7).

Dimensiooni_voti Kliendi_voti Kliendi_eesnimi Kliendi_perekonnanimi Linn

1 1001 Katrin Tamm Tartu

Joonis 7. Algne kliendi dimensioontabeli kirje.

Algselt elas klient Katri Tamm Tartus. Alates 2. juuni 2004 kolis Katrin Tamm Pärnusse.

Kuidas parandada kliendi dimensioontabelit selle muutuse peegeldamiseks?

18

Aeglaselt muutuva dimensiooni korral valitakse muutuvate andmete haldamiseks

kolme lähenemise vahel:

Ajaloo ülekirjutamine. Dimensiooni kirje vanad väärtused kirjutatakse üle ning

kaotatakse võimalus jälgida n.-ö. vana ajalugu. Ülekirjutamise eelis on mõistagi tema

lihtsus, samas aga kaugenetakse üldisest andmeaida eesmärgist, milleks on ajaloo

täpne jälgimine. Sellist lähenemist kasutatakse, kui atribuudi vanal väärtusel ei ole

tähtsust või vana väärtus on vale. Eelpool kirjeldatud näite korral on tulemus toodud

joonisel 8.

Joonis 8. Esimest tüüpi aeglaselt muutuvate dimensioonide lahendus.

Ajaloo säilitamine. Muutmise hetkel luuakse uus dimensiooni kirje uute atribuutide

väärtustega, millega eraldatakse vana kirjeldus uuest. Selline lähenemine eraldab

antud dimensiooni kirje seisukohast ajaloo väga selgelt kaheks ning analüüsi tegemine

võib sellega seoses keerukaks osutuda, kuna uut atribuudi väärtust ei saa kasutada

muutumise kuupäevast varasemateks päringuteks. Kiirelt muutuvate väikeste

dimensioonide korral soovitatakse samuti luua uus dimensioonikirje uute atribuudi

väärtustega.

Teist tüüpi aeglaselt muutuvate dimensioonide korral on mõistlik kasutada kahte võtit:

rakenduse võti ja dimensiooni võti. Rakenduse võti on võti, mis ei muutu antud kirje

muutumise korral. Rakenduse võti on sageli sisulise tähendusega väline võti.

Dimensiooni võti on surrogaatvõti, mis seob omavahel faktide tabeli ja

dimensioontabeli ridu. Dimensiooni kirje muutudes muutub dimensiooni võtme

väärtus, kuid mitte rakenduse võtme väärtus. Iga dimensiooni võtme korral tuleb

jälgida ka võtme jõus olemise kuupäevi: efektiivne_alates_kuupaev ning

efektiivne_kuni_kuupaev.

Teist tüüpi aeglaselt muutuvate dimensioonide korral oln eelpool kirjeldatud ülesande

lahendus toodud joonisel 9.

Joonis 9. Lahendus teist tüüpi aeglaselt muutuvate dimensioonide korral.

Ajaloo ühe versiooni säilitamine. Algsesse dimensiooni kirjesse luuakse väli ‘kehtiv’

uute atribuutide väärtuste hoidmiseks säilitades samal ajal ka vanad väärtused (näiteks

19

‘kehtiv_perekonnanimi’, ‘praegune_linn’). Faktide tabeliga on sellisel juhul antud

dimensiooni seisukohast seotud ainult üks võti. Jälgida saab ainult atribuudi

originaalset väärtust ja kehtivat väärtust, vahepealsed väärtused lähevad kaduma. Seda

lähenemist võib modifitseerida säilitades mingi konkreetse arvu viimaseid väärtusi.

Selleks tuleb lisada dimensioontabelisse vastav arv veerge väärtuste säilitamiseks ning

iga säilitatud väärtuse kohta ka veerg kuupäeva, millest alates see väärtus kehtib,

säilitamiseks.

Antud tüüpi aeglaselt muutuvate dimensioonide korral on lahendus toodud joonisel 10.

Joonis 10. Lahendus kolmandat tüüpi aeglaselt muutuvate dimensioonide korra.

Rämps-dimensioonid

Dimensionaalset mudelit luues, tuleb eraldada andmeid keerulistest andmete tootmise

allikatest ning jagada neid dimensioonidesse. Selle protsessi käigus võib ette tulla

mitmesuguseid lippe (ingl.k. flag) ning tekstilisi atribuute, mida ei õnnestu kohrentsel viisil

organiseerida ning mille tähendus on sageli ebaselge. Sellised väljad on sageli täidetud juhuti

või nende sisu näib sõltuvat kirje kontekstist. Sellise situatsiooni lahendamiseks on küll

mitmeid variante, kuid ükski neist ei ole soovitatav:

Jätta lipud ja atribuudid muutmata faktide tabeli kirjeteks. Selline lähenemine võib

põhjustada faktide tabeli põhjendamatut paisumist. On mõtetu luua viiest

dimensioonist ja viiest faktist koosnev mudel ning siis lisada tekstilisi kirjeid faktide

tabelisse.

Panna iga atribuut ja fakt eraldi dimensiooni, mille tagajärjel võib aga 5-

dimensioontabeliga mudel paisuda 25-dimensioontabeliga mudeliks.

Jätta kõik sellised lipud ja atribuudid disainist välja, mis võib olla kõige mõistlikum

lahendus, kui eelnevalt välja selgitada, et nendel andmetel ei ole tegevus-inimeste

jaoks sisu.

Sellist tüüpi probleemide lahendus on uurida nende lippude ja tekstiliste atribuutide

tähendust ning pärast kõigi teiste dimensioonide loomist koondada nad ühte või mitmesse

rämps-dimensiooni (ingl.k. junk dimension). Rämps-dimensioonidesse sobivad ka

kommentaaride lahtrite sisud, mis on sageli seotud faktide tabeliga, kuid sellisel juhul tuleks

luua ka kirje ‘kommentaar puudub’.

20

Mitu-mitmele dimensioonid

Mitmetes klassikalistes disainisituatsioonides on faktide tabel fundamentaalne ja

kergesti mõistetav ning iga faktide tabeliga seotud dimensiooni olemus on ilmne ja

kooskõlaline. Kuid sageli võib ühe faktide tabeli kirje kohta olla dimensioonil null, üks või

mitu väärtust, kusjuures see arv ei pruugi olla teada enne faktide tabeli kirje loomist. Selliseid

dimensioone nimetatakse ka mitu-mitmele dimensioonideks (ingl.k. many-to-many

dimension).

Joonisel 11 on toodud näide mitu-mitmele dimensioonist, kus iga faktide tabeli kirje

on haigla arve. Probleemne dimensioon on diagnoosi dimensioon, sest tegelikkuses võib ühel

patsiendil olla rohkem kui üks diagnoos. Sellise situatsiooni modelleerimiseks ei saa lisada

kordset diagnoosi dimensiooni skeemile, sest esiteks ei tea me diagnooside arvu ülemist piiri

ja teiseks on sellise skeemi korral päringute tegemine ebamugav.

Joonis 11. Arvepõhine skeem, mille korral diagnoosi dimensioonil võib olla ainult üks väärtus korraga.

Probleemi lahendamiseks lisatakse vahetabel faktide tabeli ja diagnoosi

dimensioontabeli vahele (joonis 12). Originaalne diagnoosi võti faktide tabelis üldistatakse

spetsiaalseks diagnooside grupi võtmeks. Diagnooside grupi tabel, mis on vahetabel, sisaldab

konkreetset kirjete hulka iga patsiendi jaoks. Iga diagnooside grupi tabel sisaldab

dimensioonide grupi võtit, diagnoosi võtit ja kaalu faktorit. Patsient, kellel on kolm diagnoosi,

on kolm kirjet vastavas diagnoosi grupis, kusjuures kaalude summa peab olema 1. Et aja

jooksul võib patsiendil olla erinevad diagnooside grupid, siis diagnooside grupi tabelile võib

lisada patsiendi võtme, alguse kuupäeva ja lõpu kuupäeva.

21

Joonis 12. Kordse diagnoosi probleemi lahendus vahetabeli lisamisel

Rollidega dimensioonid

Andmeaitade korral tähendab roll situatsiooni, kus üks dimensioon esineb ühes faktide

tabelis mitu korda. Näiteks võib faktide tabel kirje kujutada kliendi tellimuse staatust ja

lõppasukohta. Sellist faktide tabelit nimetatakse akumuleeruvaks kaadritega faktide tabeliks.

Olgu sellise mudeli dimensioonid:

Tellimuse kuupäev

Pakkimise kuupäev

Saatmise kuupäev

Vastuvõtmise kuupäev

Maksmise kuupäev

Tagastamise kuupäev

Arve staatus

Klient

Toode

Ladu

Esimesed kuus dimensiooni on kõik kuupäevad. Kuid me ei saa ühendada neile

dimensioonidele vastavaid võtmeid ühte tabelisse, sest SQL interpreteerib sellist situatsiooni

olukorrana, kus kõik kuupäevad peaksid samad olema. Selle asemel tuleb panna SQL uskuma,

et on olemas kuus sõltumatut ajadimensiooni tabelit. Hoolimata sellest, et me ei saa kasutada

ühte aja tabelit, tahame siiski administreerida ainult ühte tabelit. Loome kuus SQL-vaadet aja

tabelist st kuus erinevalt kirjeldatud ajadimensiooni, kusjuures peame kõik atribuudid

nimetama unikaalselt.

Dimensioonidevahelised hierarhiad

Suvalise struktuuri kujutamine on relatsioonilises keskkonnas keeruline ülesanne.

Hierarhilise struktuuriga puutume kokku näiteks soovides aruandlust erinevate klientide

aastatulude kohta, kusjuures klientide vahel on struktuur (joonis 13).

22

Joonis 13. Vanem- ja alamklientide skemaatiline diagramm

Üks võimalus hierarhia modelleerimiseks on luua kliendi dimensiooni rekursiivne

viide, mis sisaldab vanem-organistasiooni võtit (joonis 14). Kuigi selline lähenemine on

kompaktne ja efektiivne kirjeldamaks suvalist hierarhiat, ei saa seda mõistlikult kasutada

standardse SQLiga. SQLi GROUP BY funktsiooni ei saa kasutada rekursiivset puu struktuuri

mööda alla minekuks, et summeerida liidetavaid fakte nagu näiteks kliendi aastatulu. Oracle’i

CONNECT BY funktsiooni ei saa samuti kasutada, sest kuigi ta suudab hallata rekursiivseid

viitasid, ei saa teda kasutada tabelite ühendamiseks.

Joonis 14. Kleindi dimensioon rekursiivse viidaga

Et luua efektiivsemat SQLile orienteeritud disaini, esitame kõigepealt nõudmised

disainile:

tahame hoida kliendi dimensiooni originaali nii, et kliendi võtit saaks otse ühendada

faktide tabeliga, kasutades selleks vajadusel vahetabelit.

tahame, et oleks võimalik liita kokku liidetavaid fakte läbi klientide hierarhia alampuu,

kasutades standardset SQL GROUP BY loogikat.

23

tahame summeerida liidetavaid fakte kas üle otseste alamklientide või kõige

madalama taseme klientide hoolimata sellest, kui sügav või keeruline on klientide

hierarhia puu, kasutades standardset SQL GROUP BY loogikat.

tahame, et oleks võimalik leida nii iga kliendi otsest vanemat kui ka kõige kõrgemat

vanemat ühe sammuga kasutades selleks standardset SQL loogikat.

Sellistele nõudmistele vastava struktuuri saamiseks loome vahetabeli kliendi dimensiooni ja

faktide tabeli vahele (joonis 15). Ei kliendi dimensiooni ega ka faktide tabelit ei pea mingil

moel muutma. Vahetabeli kasutamine on valikuline. Kui vahetabel jäetakse välja, ühendub

kliendi dimensioon faktide tabeliga tavalisel viisil ja klientide hierarhias navigeerida ei saa.

Kui vahetabelit kasutatakse, asub ta kliendi dimensiooni ja faktide tabeli vahel ja teda saab

kasutada kahel erineval viisil.

Joonis 15. Kliendi dimensioon vahetabeliga, mis võimaldab teha SQL päringuid hierarhias.

Vahetabel sisaldab ühte kirjet iga tee jaoks kliendist tema iga alamkliendini joonisel

13 kujutatud hierarhias. On olemas ka kirje nullpikkusega teeks kliendist iseendasse. Iga tee

kirje sisaldab kliendi vanema võtit, konkreetse alamkliendi võtit, tasemete arvu kliendi

vanema ja alama vahel ning lippu, mis annab teada, kas on tegemist kõige alumise tasemega.

Soovides organisatsiooni hierarhias alla minna, ühendatakse tabelid nii nagu näidatud

joonisel 15 ülemises mudelis. Klientide dimensiooni iga atribuudiga saab piirata päringut ja

pärida kõigi alamklientide iga agregeeritud tunnust. Soovides organisatsiooni hierarhias üles

minna, ühendame tabelid joonisel 15 alumises mudelis kujutatud viisil.

24

Faktide tabeli disain

Liidetav, poolliidetav ja mitteliidetav fakt

Faktide tabeli faktid peaksid olema võimaluse korral liidetavad st dimensioone pidi

faktide kokku liitmine omab tähendust. Poolliidetavad faktid on faktid, mida saab kokku liita

mõnda dimensiooni pidi ning mitteliidetavaid fakte ei saagi kokku liita. Tegevuse diskreetsed

numbrilised mõõdud on liidetavad, samas intensiivsuse diskreetsed numbrilised mõõdud

(nagu konto jääk) on poolliidetavad faktid. Tähtsaimad intensiivsuse mõõdud on sellised, mis

kujutavad olukorda mingil ajahetkel (nagu näiteks kontojääk ja laoseis). Erinevalt tegevuse

mõõtudest ei esita nad voogu mingist punktist alates. Intensiivsuse mõõdud on tavaliselt

liidetavad kõiki dimensioone pidi välja arvatud ajadimensiooni. Ajavahemiku keskmise

kontojäägi ja laoseisu leidmiseks tuleb kokku liita ajavahemiku fakti väärtused ning jagada

ajaperioodide arvuga, kuid funktsioon SQL AVG leiab keskmise üle kõigi saadud väärtuste.

Mõõdetud fakt võib harva olla ka tekstiline, kuid sellist olukorda tuleks vältida ja

võimaluse korral tekstilised väärtused dimensioontabelitesse panna. Näide tekstilisest faktist

on politseiniku poolt kuriteo paigas kirja pandud ilma kirjeldus, millel ei ole etteantud

piiranguid ning kirjeldused erinevad üksteisest oluliselt. Sellise kirjelduse jaoks eraldi

dimensiooni luues oleks ilmselt faktide tabel ja ilma dimensioontabel sama suured ning

dimensiooni loomine seega kasutu.

Faktideta faktide tabel

On modelleerimise situatsioone, mille korral faktide tabelis ei ole ühtegi fakti. Need

faktideta faktide tabelid on väga kasulikud kirjeldamaks sündmusi ja katvust.

Faktideta faktide tabeli variant on dimensionaalne mudel, mis salvestab sündmusi.

Joonisel 16 on toodud näide dimensionaalsest mudelist, millega jälgitakse üliõpilaste

igapäevast kooliskäimist. Mudelisse kuuluvad dimensioonid:

Kuupäev. Iga kalendripäeva kohta üks Kuupäeva dimensiooni kirje.

Üliõpilane. Iga üliõpilase kohta üks Üliõpilase dimensiooni kirje.

Kursus. Iga semestri iga kursuse kohta üks Kursuse dimensiooni kirje.

Õppejõud. Iga õppejõu kohta üks Õppejõu dimensiooni kirje.

Ruumid. Iga ruumi, laboratooriumi või spordiväljaku kohta Ruumi dimensiooni kirje.

Iga faktide tabeli kirje on konkreetse üliõpilase kursusest osavõtmine: kui üliõpilane

astub loenguruumi, genereeritakse uus kirje. Faktide tabeli iga kirje sisaldabki ainult viie

dimensiooni võtit. Ühtegi ilmset fakti, mida salvestada iga kord, kui üliõpilane loengust osa

25

võtab, ei ole. Et lihtsustada SQL päringuid, võib lisada igale kirjele faktisarnase välja

Kohalkäimine. Et kirje tekib igakord, kui üliõpilane loengust osa võtab, siis on kõik välja

Kohalkäimine väärtused 1-d.

Joonis 16. Faktideta faktide tabel, mis kujutab üliõpilase loengust osavõtmist.

Dimensionaalne mudel, mis salvestab katvust on samuti faktideta faktide tabeli

variant. Tüüpiline näide on toodud joonisel 17. Katvuse tabeleid on sageli vaja, kui primaarne

faktide tabel on hõre. Joonisel 17 on lihtne kampaania müügi faktide tabel, kus on konkreetsel

kampaania päeval iga laost müüdud toote kohta üks kirje.

Joonis 17. Faktideta faktide tabel, mis kujutab kampaaniatoodete müüki poodide ja ajaperioodide kaupa

26

Seega kasutatakse faktideta faktide tabeleid salvestamaks sündmusi andmeaidas, kui

sündmusega ei ole seotud numbrilisi mõõtmisi ning katvuse garanteerimiseks.

Erineva detailsuse astmega faktide tabelid ja ümberjaotamine

Dimensionaalne mudel on seda võimsam, mida detailsemad on faktid. Kui

disainimisel ilmnevad erineva detailsuse astmega faktid, peaks püüdma viia kõik faktid

madalaimale tasemele. Seda protseduuri võib vaadelda kõrgema taseme faktide madalamale

tasemele ümberjaotamisena (ingl.k. allocate). Näiteid ümberjaotamise vajaduse kohta

andmeaidas on mitmeid, kõige tuntum on kulude jaotamine. Kauba kohaletoimetamise arvel

võib olla kirjas kohaletoimetamise kulu summaarselt mitte iga artikli kohta eraldi. Siinkohal

tuleks summaarne kulu laiali jagada iga kohaletoimetatud kaubaartikli kohta eraldi. Vastasel

juhul tuleb kohaletoimetamise kulu kirjeldada kõrgema taseme tabelis (nagu näiteks arve

tabelis), mille tulemusel muutub kulusid ja tulusid arvestav kasumi päring keerulisemaks tänu

erineval detailsuse astmel tabelitele. Samuti on võimatu pidada arvestust konkreetse

kaubaartikli kulude ja tulude üle.

Siiski võib ette tulla situatsioone, mil faktide ümberjaotamine madalaimale tasemele

on võimatu ning andmeaida disainis tuleb kirjeldada üldisema taseme fakte eraldi faktide

tabelis. Sellised situatsioonid tekivad üldiste plaanide tegemisel või prognoosimisel. Näiteks

võib ettevõtte juhtkond saada regulaarselt kokku, et prognoosida aasta tulu ja kulu. Sellised

summad eksisteerivad vaid väga üldistel tasemetel ning nende laiali jaotamine artiklite kaupa

on ebavajalik. Päring, mis viib omavahel vastavusse prognoosid tegelike summadega, peab

suutma õiged summad õigete jaotuste alla kokku liita.

Püüdes parandada andmeaida jõudlust või vähendada päringute keerukust, võib

andmeaida faktide kirjete disainimisel tekkida vigu agregeeritud faktide kasutamisel. Joonisel

18 kujutatud kuise fundamentaalse seemnega faktide tabelis on kirjed viimase_aasta_kogus ja

riiklik_kogus. Need kirjed võivad küll vähendada mõndade spetsiifiliste päringute keerukust,

kuid päringud, mille argumendiks on rohkem kui üks päev, võivad seda välja mitu korda

arvestada. Sarnaselt võib olla mitmel korral arvestatud väli riiklik_kogus, kui päring puudutab

rohkemat kui ühte riigi piirkonda. On väga oluline, et kui faktide tabeli fundamentaalne seeme

on valitud, esitatakse kõik faktide tabeli liidetavad argumendid selle seemne tasemel.

27

Joonis 18. Faktide tabel vale fundamnetaalse seemnega faktidega

Kellaaeg dimensionaalses mudelis

Üksikute kannete vaatlemisel võib osutuda vajalikuks säilitada ka kande kellaaeg

minuti või isegi sekundi täpsusega. Sellisel juhul ei looda ajadimensiooni ühe kirjega iga

minuti või sekundi kohta. Tavaliselt lahutatakse päev ja kellaaeg kaheks tunnuseks faktide

tabelis (vt joonis 19). Päeva väljendatakse kui võtit ajadimensiooni, kuid kellaaega on parem

kirjeldada numbrilise faktina kui dimensioonina, välja arvatud juhtudel, kui on tegemist

tekstiliste väärtustega, mis iseloomustavad mingeid päeva osasid nagu näiteks ‘Lõunaaeg’.

Kellaaega väljendatakse minutite või sekundite arvuna keskööst.

Joonis 19. Kellaaja lisamine faktide tabelisse.

Rakendustes, mis ulatuvad üle mitme ajadimensiooni, võib olla vajalik, et nii päev kui

ka kellaaeg oleks väljendatud nii kohalikus ajas kui ka Greenwichi ajas (Greenwich Mean of

Time – GMT). Selleks luuakse eraldi ajadimensioonid ja kellaaja faktid kohaliku aja jaoks ja

GMT jaoks (joonis 20). Ainult ühe ajadimensiooni või kellaaja fakti kasutamine ei ole

põhjendatud erinevate ajadimensioonide arvu ning ühest ajadimensioonist teise arvestamise

keerukuse tõttu. Kahe erineva aja interpretatsiooni olemasolu võib olla väga kasulik.

Analüüsides erinevates ajatsoonides asuvate helistamiskeskuste tööd, saab vaadelda kõnede

arvu n.-ö. reaalajas, kasutades GMT ajadimensiooni, ning kohalikus ajas.

28

Joonis 20. Müügi faktide tabel ettevõtte jaoks, kellel on vaja võrrelda müüki üle erinevate ajatsoonide

Erinevad mõõtühikud dimensionaalses mudelis

Disainides dimensionaalset mudelit, mis hõlmab erinevaid äriprotsesse ning kirjeldab

toote liikumist läbi süsteemi protsesside, võib tekkida konflikt hulkade esitamisel. Numbrid

võivad küll õiged olla, kuid erinevad osapooled võivad soovida hulki esitatuna erinevate

mõõtühikute kaudu. Näiteks tootmisjuht soovib näha toote kogu elutsüklit autokoormates või

tõstealustes, müügijuhid kohaletoimetamise pakendites, müügipakkides või tarbija ühikutes.

Sarnaselt võib ühel toote kogusel olla erinevad majanduslikud väärtustused:

inventarinimekirja hind, algne müügihind, lõplik müügihind.

Vaatleme näiteks situatsiooni, kus on 12 fundamentaalset kvantiteedi fakti ja 5

mõõtühiku interpretatsiooni. Vale oleks esitada 12 kvantiteedi fakti faktide tabelis ning

kirjeldada vastavad faktorid dimensiooni tabelis (joonis 21). Selline disain võib tuua kaasa

vigu ühikute valimisel. Samuti on vale esitada erinevad faktide ja mõõtühikute

kombinatsioonid faktide tabelis. Selleks vajaksime 12×5 kvantiteedi fakti igas faktide tabelis.

Joonis 21. Vale disain juhuks, kus faktide tabeli hulgad peavad olema väljendatuna erinevates

mõõtühikustes

29

Korrektne lahendus (joonisel 22) on luua faktide tabel 12 kvantiteedi faktiga, 4 ühiku

faktoriga (kui nelja faktori väärtused on 0-d on ühikuks viies ühik). Mõõtühikute ja hinna

faktorite käsitlemine faktidena vähendab toote dimensiooni väikestest muutustest tulenevate

uute kirjete hulka.

Joonis 22. Soovitatav disain erinevate mõõtühikute käsitlemiseks andmeaidas

Erinevad rahaühikud faktide tabelis

Rahvusvahelises ettevõttes võivad olla tehingute summad väljendatud mitmes

erinevas valuutas. Võime teisendada erinevad valuutad üheks standardsekes valuutaks, kuid

soovi korral võime teha dimensionaalse mudeli paindlikumaks nii, et iga riigi müügijuht saab

vaadata müügitulemusi oma riigi rahaühikutes. Selline paindlikkus on saavutatav väljendades

kõik rahasummad faktide tabelis kohalikus valuutas ja rahvuvahelises standardvaluutas ning

lisades mudelisse spetsiaalse valuuta konverteerimise faktide tabeli (joonis 23).

Joonis 23. Tehingute jälgimine mitme valuutaga süsteemis vajab valuuta konverteerimise faktide tabelit

Vaatleme suure hulgimüügifirma, kellel on harud kõikjal Vaikse ookeani rannikul,

müügitulemusi. Olgu Uus-Meremaa osa Vaikse ookeani regioonist. Ettevõtte peakorter asugu

Kalifornias. Olgu ühine valuuta andmeaida faktide tabelis USA dollar. Uus-Meremaal

30

toimunud müügi kanne faktide tabelis väljendatakse Uus-Meremaa dollarites ja USA

dollarites. Regiooni müügijuht saab vaadata kogu Vaikse ookeani regiooni müüki Austraalia

dollarites kasutades valuuta konverteerimise tabelit.

Faktide tabelis on summad, mis on väljendatud kohalikus valuutas, alati täpsed kuna

müük toimus selles valuutas. Vastava summa konverteerimiseks USA dollariteks kasutatakse

sama päeva kurssi. Konverteerimise faktide tabelis on kõikide valuutade kursid mõlemat pidi

(näiteks USA dollaritest Austraalia dollariteks ning vastupidi – Austraali dollaritest USA

dollariteks) kuna eeldatakse, et vastavad kursid ei ole võrdsed.

31