sissejuhatus andmeaitadessse - kursused · web viewenamasti on dimensioonid üksteisest loogiliselt...
TRANSCRIPT
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