Izgradnja podatkovnega skladišča in razvoj uporabniške rešitve v tehnologiji OLAP : diplomsko delo univerzitetnega študija

UNIVERZA V MARIBORU FAKULTETA ZA ORGANIZACIJSKE VEDE. Diplomsko delo univerzitetnega študija Smer: Organizacijska informatika. IZGRADNJA PODATKOVNEGA SKLADIŠ A IN RAZVOJ UPORABNIŠKE REŠITVE V TEHNOLOGIJI OLAP. Mentor: red. prof. dr. Jože Zupan i Kranj, marec 2006. Kandidat: Krištof Perc.

ZAHVALA Zahvaljujem se mentorju prof. dr. Jožetu Zupan i u za pomo in nasvete pri izdelavi diplomskega dela. Zahvaljujem se ženi Karmen in h erki Veroniki, da sta mi med študijem ob delu stali ob strani in me spodbujali..

IZJAVA Izjavljam, da sem diplomsko delo univerzitetnega študija samostojno izdelal pod vodstvom mentorja prof. dr. Jožeta Zupan i a..

POVZETEK V diplomskem delu je na kratko opisano skladiš e podatkov v zavarovalnici Triglav, njegovo na rtovanje, oblikovanje in izgradnja ter razvoj OLAP aplikacije kot ra unalniške rešitve izbranega problema. Podan je opis osnovnih pojmov, ki jih sre ujemo pri delu s to tehnologijo. Ra unalniška rešitev je narejena na osnovi podane zahteve s strani Zavarovalnice Triglav, d.d. Opisal sem tudi procese v poslovanju zavarovalnice, ki so neposredno povezani s problemom. Poleg opisa tehnologije in postopkov razvoja ra unalniške rešitve diplomska naloga poda oceno uporabljenih orodij za razvoj v prihodnosti s to moderno informacijsko tehnologijo.. KLJU NE BESEDE -. skladiš e podatkov OLAP kocka dimenzija zavarovanje. ABSTRACT The diploma assignment describes a data warehouse for Zavarovalnica Triglav, its planning, design and implementation of an OLAP application as the solution of the selected problem. General terms related to data warehousing are defined. Requirements for the application were provided by insurance company Zavarovalnica Triglav, d.d. Therefore, we also described some problems related to business processes in the insurance company. The technology that was used and steps in developing application are described, and evaluation of the tools used in the development is given. Perspectives for further development using up-to-date technology are indicated.. KEYWORDS -. data warehouse OLAP cube dimension insurance.

KAZALO 1. 2. 3. 4. 5. 6 7 8. Uvod ................................................................................................................. 2 1.1 Predstavitev problema ......................................................................... 2 1.2 Predstavitev okolja............................................................................... 3 1.3 Cilji....................................................................................................... 5 1.4 Metode dela ......................................................................................... 5 Skladiš e podatkov in OLAP .......................................................................... 7 2.1 Uvod .................................................................................................... 7 2.2 Skladiš e podatkov .............................................................................. 7 2.3 Ve dimenzionalne kocke olap............................................................ 11 2.4 Priprava poro il.................................................................................. 12 Razvoj skladiš a podatkov za Službo trženja ............................................. 14 3.1 Razvoj modela podatkov.................................................................... 14 3.2 Polnjenje skladiš a podatkov ............................................................. 17 3.3 Uporaba............................................................................................. 18 Razvoj kocke OLAP za službo trženja ......................................................... 20 4.1 Uvod .................................................................................................. 20 4.2 Razvoj ve dimenzionalne kocke OLAP.............................................. 20 4.3 Testiranje........................................................................................... 40 4.4 Uporaba............................................................................................. 40 Pregledi in poro ila za službo trženja.......................................................... 42 5.1 Uvod .................................................................................................. 42 5.2 Hyperion Analyzer.............................................................................. 42 5.3 Essbase excel.................................................................................... 46 Ocena okolja, postopkov in orodij ............................................................... 48 Zaklju ek........................................................................................................ 50 Literatura in viri ............................................................................................. 51.

Univerza v Mariboru - Fakulteta za organizacijske vede. 1. UVOD. 1.1. PREDSTAVITEV PROBLEMA. Diplomsko delo univerzitetnega študija. Informacija – arobna beseda povezana ne le z ra unalništvom in informatiko, pa pa z vsemi vejami in nivoji odlo anja v podjetju in z vodenjem le-tega. Podjetje brez prave, dobre informacije ne more preživeti in ne bo preživelo. Informacije nastajajo neprenehoma v vseh poslovnih dejanjih in dogodkih, potrebno pa jih je predelati in oblikovati tako, da bodo uporabne za vodstvo podjetja in vse uporabnike do najnižjega nivoja. To se zgodi v informacijskem sistemu v podjetju. Ker se je vodstvo v našem podjetju že davno zavedlo tega in se vsi zaposleni tega zavedamo tudi sedaj, se je pripravi teh informacij vedno dajalo velik pomen. Izgradnja informacijskega sistema ni enkratno opravilo. Ne naredimo nekega novega informacijskega sistema in ga damo v uporabo ter pozabimo nanj. Informacijski sistem mora rasti in se razvijati skupaj s podjetjem. Dopolnjevanje takega sistema in priprava vedno novih ter bolj popolnih informacij lahko traja do odlo itve vodstva podjetja o pri etku izgradnje novejšega in modernejšega informacijskega sistema, ki po zaklju ku razvoja v celoti nadomesti starega. Kakor v vsakem drugem podjetju je tudi v zavarovalnicah potreben stalen razvoj dejavnosti. Glede na veliko konkurenco na trgu zavarovanj so pri akovanja strank še ve ja. Potrebne so spremembe pri obstoje ih zavarovanjih ali se pokaže potreba po novem zavarovanju rizika, ki še ne obstaja. Za nova zavarovanja so potrebne raziskave tržiš a. Za spremembe in dopolnitve obstoje ih zavarovanj pa potrebujemo analize prodaje zavarovanj skozi obdobja ter analize nastalih škodnih primerov pri posameznih zavarovanih rizikih. Pred petimi leti so v službi trženja izrazili željo po ažurnih, hitrih, raznolikih in natan nih analiti nih pregledih, ki bi jim pomagali pri pripravi prodajnih akcij in pri razvoju novih programov zavarovanj. e bi bilo možno, bi želeli sami uporabljati ra unalniško rešitev tako, da ne bi bili preve odvisni od sektorja informatike. V preteklih nekaj letih je Zavarovalnica Triglav postopoma za ela uporabljati novejšo informacijsko tehnologijo pri razvoju novih ra unalniških rešitev. Omenim naj predvsem spletno programiranje (JAVA) in široko uporabo izvedenih rešitev, ki so omogo ale razne vpoglede v podatke iz baze podatkov. Takšne rešitve niso zadoš ale zahtevam iz službe trženja. Zato se je vodstvo informatike odlo ilo za poskusni razvoj manjšega skladiš a podatkov in razvoja manjše OLAP kocke. Za pristop do podatkov bi kon ni uporabniki uporabljali on-line generator poro il. S ponujeno možnostjo so se v službi trženja strinjali. Razvili smo prvo aplikacijo v OLAP tehnologiji. Za izpolnjevanje dolo enih zahtev uporabnikov informacij se je OLAP pokazal kot dokaj uspešen. V. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 2 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. službi trženja so se hitro navadili na informacije iz OLAP-a. Pripravljali so tudi poro ila za vodstvo podjetja, s katerimi so bili zadovoljni. Vendarle možnosti teh orodij za uporabnike še zdale niso izkoriš ene, saj obstaja ena sama manjša aplikacija, ki pa res daje zadovoljive rezultate Še za to ra unalniško rešitev na za etku ni bilo interesa v vodstvih preostalih obmo nih enot. V tem trenutku obstaja ideja za širjenje uporabe skladiš a podatkov, OLPA-a in generatorja poro il. V letu 2005 je prišla zahteva po obsežni ra unalniški rešitvi uporabni za službo za marketing ter upravo družbe. Vodstvo službe za marketing potrebuje dobre informacije o prodaji zavarovanj na terenu za svoje akcije usmerjanja ve je aktivnosti pri prodaji na dolo enem podro ju Slovenije ali pri dolo enih vrstah zavarovanj. Iskali bodo podatke o prodaji zavarovanj v premoženjskem sektorju v dolo enem obdobju, na dolo enem teritoriju, glede na prodajno pot s podatki o premiji, zavarovalni vsoti in številu zavarovanj. Prav tako uprava družbe potrebuje podatke o prodaji po mnogih razli nih kriterijih za kratkoro no in srednjero no odlo anje in planiranje. Podatki morajo biti analiti ni in hitro pristopni. Z analiti nimi podatki bodo delali uporabniki sami; jih razporejali, dolo ali parametre, oblikovali in pripravljali poro ila. Podatki morajo biti sorazmerno ažurni, torej stari maksimalno en teden. Takšne podatke lahko vsebuje dobro skladiš e podatkov. e skladiš e podatkov nadgradimo z orodjem za pripravo analiti nih podatkov (OLAP) in orodjem za prikaz podatkov (generatorjem poro il, na primer Hyperion Analyzer) je celotna ra unalniška rešitev zelo uporabna. Izkazala se je za u inkovito v primeru dolo enih zahtev. Vodstvo sektorja informatike se je zato odlo ilo, da se pri reševanju zahtevka uporabi tehnologijo OLAP.. 1.2. PREDSTAVITEV OKOLJA. Zavarovalnica Triglav, d.d. je najve ja in najstarejša slovenska zavarovalnica. Znanje in izkušnje se v njej nabirajo že ve kot stoletje saj je pravni naslednik Vzajemne zavarovalnice iz Ljubljane, ki je bila ustanovljena leta 1900. Zavarovalnica Triglav ima razvejano lastno poslovno mrežo, preko katere posluje. Organizirana je v dvanajstih obmo nih enotah, od katerih vsaka obmo na enota s svojim delovanjem pokriva dolo eno obmo je. V okviru obmo nih enot obstaja mreža poslovnih enot, predstavništev, zastopstev in agencij, ki poslujejo v posameznih krajih ali ob inah. Takšna poslovna mreža zagotavlja, da je zavarovalna storitev v najve ji meri približana zavarovancem tako ob sklepanju zavarovanj, kot ob nastanku morebitnih škod. Realizacija zavarovalne premije po organizacijskih enotah je razli na, obenem pa je odsev gospodarskih, finan nih in razvojnih možnosti posamezne regije. Vendar mo Zavarovalnice Triglav ni le v njeni starosti in razvejanosti, temve tudi v številu sklenjenih zavarovanj. Z vrsto zavarovanj, ki jih zavarovalnica ponuja zavarovancem, le-ti u inkovito zaš itijo svoje premoženje in poslovne interese ter. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 3 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. vsaj del bremen prenesejo na zavarovalnico, ki s svojo strokovnostjo ter trdnim finan nim zaledjem zagotavlja resni no varnost. V ponudbi Zavarovalnice Triglav so vse vrste premoženjskih in osebnih zavarovanj. Med premoženjskimi zavarovanji so to zavarovanja premoženja in premoženjskih interesov, avtomobilska, kmetijska, transportna zavarovanja, zavarovanja kreditov in zavarovanja za prosti as ter potovanja. Zaokroženo ponudbo osebnih zavarovanj sestavljajo vse vrste osebnih, rentnih, pokojninskih, nezgodnih in zdravstvenih zavarovanj. Zavarovalnica Triglav ima vodilni tržni položaj na zavarovalniškem trgu v Sloveniji. Dosega 55 odstotni tržni delež pri premoženjskih zavarovanjih in še ve ji pri osebnih zavarovanjih. Poslovanje Zavarovalnice Triglav je vpeto tudi v mednarodne okvire, saj sodeluje z vsemi najpomembnejšimi pozavarovalnicami na svetu, s strani najpomembnejših evropskih zavarovalnic pa je pooblaš ena za likvidacijo tujih škod v Sloveniji. Zavarovalnica Triglav sodeluje s številnimi organizacijami in podjetji v Sloveniji, s katerimi ima pogodbe za opravljanje zavarovalnih poslov, zlasti inkaso premije. To so podjetja za izvajanje tehni nih pregledov motornih vozil, mejni prehodi, turisti ne agencije, banke in podobne ustanove. Zavarovalnica Triglav ohranja svoj tržni položaj oziroma ga na dolo enih podro jih celo pove uje. Izkoriš a dobro razvito lastno poslovno mrežo, kakovostno ponudbo zavarovalnih storitev, samo organizacijo sklepanja zavarovanj in prednosti strokovnega znanja zavarovalnih delavcev. Centrala Zavarovalnice Triglav Sedež Zavarovalnice Triglav, d.d. – Centrala je v Ljubljani. Na Centrali se izvajajo vodstvene, razvojne in usklajevalne funkcije družbe. V njej so zaposleni v glavnini visoko izobraženi, specializirani strokovnjaki ekonomskih, organizacijskih, tehni nih, družboslovnih, naravoslovno-matemati nih, informacijskih in drugih ved. Centrala dolo a in predpisuje postopke, ki se izvajajo na vseh dvanajstih obmo nih enotah. Na Centrali se pripravlja strategija razvoja in poslovanja za Zavarovalnico Triglav. Podro je za informatiko V Centrali Zavarovalnice Triglav deluje sektor informatike, kjer razvijamo in vzdržujemo razli ne informacijske sisteme za celotno Zavarovalnico Triglav. Delam v oddelku za objektne tehnologije premoženjskih zavarovanj na delovnem mestu organizatorja programerja. Na oddelku razvijamo in vzdržujemo ra unalniške rešitve za sisteme premoženjskih zavarovanj pravnih in fizi nih oseb v tehnologijah Lotus Notes, Olap, Hyperion Analyzer in SQL z uporabo baze podatkov DB2. Podatke iz te baze podatkov rpajo tudi programi, ki so napisani v objektno orientiranem jeziku JAVA. Ti programi se uporabljajo za spletno poslovanje z uporabniki znotraj in zunaj Zavarovalnice Triglav.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 4 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Velik del informacijskega sistema premoženjskih zavarovanj je bil še do nedavnega star in težak za vzdrževanje. Z marsikatero storitvijo uporabniki niso bili zadovoljni. Dodaten razvoj je bil zelo težaven. Tudi podjetje ni veliko vlagalo v informacijsko tehnologijo, programsko podporo, strojno opremo in ljudi. Vodstvo je dolgo razmišljalo o najbolj primerni prihodnosti informatike v Zavarovalnici Triglav. Kon no je obveljala ideja o kombinaciji lastnega razvoja z nakupom dolo ene programske podpore, ki ustreza našim zahtevam. Pripravili smo dober podatkovni model in s tem dobro bazo podatkov. Razvili smo posamezne programske pakete na novih platformah. Veliko aplikacij smo razvili za spletno poslovanje. Pripravili smo prvo podatkovno skladiš e in razvili manjšo OLAP aplikacijo. Ta najmodernejša tehnologija na za etku ni zaživela, saj uporabniki nekaj asa niso zmogli miselnega preskoka, ki ga morajo narediti za razumevanje kock OLAP in zelo enostavnega generatorja poro il Hyperion Analyzer. Vendar se je tudi to spremenilo.. 1.3. CILJI. V sektorju informatike moramo pregledati obstoje e strukture podatkov. Na osnovi njih bomo pripravili model podatkov za skladiš e podatkov. Dolo iti moramo dimenzije OLAP kock, pri emer je potrebno upoštevati zmogljivosti strojne in programske ra unalniške opreme. Izkušnje imamo iz preteklosti, ko smo razvijali prvo manjšo OLAP kocko pol leta, nato pa sta polnjenje kocke in kalkulacija trajala dva meseca. V tem asu smo se seveda veliko nau ili. Vendar je prišlo tudi do namestitve novejših verzij programskih orodij, s katerimi v Sloveniji še ni nih e delal. Moj namen je prikazati razvoj nove aplikacije na teh orodjih v im krajšem asu. Isto asno bi rad vodstvu Zavarovalnice Triglav, d.d. prikazal možnosti razvoja s temi orodji in uporabnost le teh za pripravo še boljših ra unalniških rešitev in strateških informacij. Cena teh orodij ni majhna in, e niso v celoti izkoriš ena, podjetje izgublja veliko konkuren no prednost, ki jo ima z dobrim informacijskim sistemom. Rezultat diplomske naloge bo kratek splošen opis skladiš a podatkov in tehnologije OLAP ter prakti en prikaz izgradnje skladiš a podatkov in razvoja aplikacije OLAP. Pri pripravi skladiš a podatkov za OLAP aplikacijo bodo osnova podatki iz centralne baze podatkov za premoženjski sektor Zavarovalnice Triglav. Nadalje bom prikazal razvoj kocke v tehnologiji OLAP z opisom zna ilnosti te objektne tehnologije. Pokazal bom tudi uporabo orodja Hyperion Analyzer za pripravo poro il na osnovi OLAP kocke.. 1.4. METODE DELA. Sam sodelujem pri procesu informatizacije Zavarovalnice Triglav, d.d. osem let. V prejšnjem podjetju sem najprej sodeloval pri ve letnem vzdrževanju slabega in starega informacijskega sistema. Kasneje sem bil eden glavnih lenov v razvoju popolnoma novega in modernega IS. Izkušenj z razvojem informacijskih sistemov se mi je torej nabralo za ez dve desetletji.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 5 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Pred pripravo diplomske naloge sem preštudiral veliko gradiva za informacijske predmete študija informatike na Fakulteti za organizacijske vede, nekaj lankov v revijah z ra unalniško tematiko, nekaj tuje in naše literature. Uporabil sem gradivo s strokovnega izobraževanja. Pripravil sem si precej zapiskov svojega dela v podjetju in nekaj internega gradiva. Tako je nastalo kar nekaj gradiva, ki sem ga uporabil v tej diplomski nalogi. Tematike sem se najprej na kratko lotil s teoreti nega vidika, v nadaljevanju naloge pa opisal konkretne rešitve pri razvoju podatkovnega skladiš a in kock OLAP ter pripravo poro il. V diplomski nalogi sem moral paziti na poslovno tajnost in zaupnost podatkov. Zato so dolo eni podatki prikazani druga e od resni nih, so zbrisani ali zakriti. Pri pisanju naloge sem uporabil doma o in tujo strokovno literaturo, predvsem pa lastne izkušnje in znanja na tem podro ju. Preden nadaljujem želim zaradi specifi ne dejavnosti – zavarovalništva razložiti in razjasniti nekaj osnovnih pojmov, ki bolj pogosto nastopajo v svetu zavarovalništva in tudi v tej diplomski nalogi. Osnovni zavarovalniški pojmi: zavarovalna enota je najbolj osnovno zavarovanje, npr. zavarovanje delnega kaska kraje vozila pri avtomobilskem zavarovanju za to no dolo eno vrsto vozila s to no dolo eno mo jo motorja itd.; to je osnovna enota, najmanjši del ek, ki se lahko zavaruje; to je najbolj natan no dolo eno zavarovanje; zavarovalna podvrsta je skupina takšnih osnovnih, sorodnih zavarovanj, npr. vsa kasko zavarovanja osebnih motornih vozil; zavarovalna premija je znesek, ki ga zavarovanec pla a za dolo eno zavarovanje; zavarovalna vsota je znesek, za katerega je dolo en predmet ali riziko zavarovan; zavarovalni riziko je stvar zavarovanja, npr. riziko kraje vozila; zavarovanec je oseba, ki je zavarovana; zavarovalec je oseba, ki zavaruje sebe ali stvar ali dogodek za primer nastopa dolo enega rizika in je pogosto tudi zavarovanec; zavarovanec ali zavarovalec je lahko fizi na ali pravna oseba ali samostojni podjetnik; zastopnik je delavec Zavarovalnice Triglav, ki na terenu ali v pisarni sklepa zavarovanja; zastop je obmo je, ki ga pokriva zastopnik; prodajna pot je pot, po kateri je prišlo do zavarovanja: preko agencije, preko zastopnika, preko komercialista, itd. V veliko primerih se zgodijo nezgode, nesre e, poškodovanja zavarovane stvari. V takšnih primerih govorimo o škodah.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 6 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. 2. SKLADIŠ E PODATKOV IN OLAP. 2.1. UVOD. Skladiš e podatkov je nadgradnja v podjetju obstoje ih podatkovnih sistemov – od relacijskih baz podatkov do drugih datote nih sistemov. V skladiš e podatkov prenesemo del ali vse operativne podatke, ki so lahko zelo razli ni glede na proces, kjer so nastali. Te podatke predelamo, uredimo in zapišemo v podatkovno skladiš e. To so vhodni podatki za druge procese, med drugim tudi za OLAP aplikacije. Za potrebe OLAP informacijskih sistemov podatke združimo v obliko, ki odgovarja zahtevam uporabnikov. OLAP ve dimenzionalne kocke so zelo koristen vir strateških informacij za vodstva podjetij. V takšnih kockah so lahko podatki pripravljeni tudi za druge uporabnike, vendar na analiti nem nivoju.. 2.2. SKLADIŠ E PODATKOV. Koncept podatkovnega skladiš a je prvi predstavil W.H.Inmon v za etku 90. let. Inmon podatkovno skladiš e definira, kot (1993) »vsebinsko usmerjeno (subject oriented), integrirano (integrated), obstojno (non volatile), asovno variantno (time variant) zbirko podatkov za podporo poslovnim odlo itvam.« Inmonova definicija je najpomembnejša (v svoji literaturi o podatkovnih skladiš ih jo uporablja ve ina avtorjev) in našteva poglavitne zna ilnosti podatkovnega skladiš a, ki jih bom podrobneje opisal kasneje. Ralph Kimball, ustanovitelj podjetja Red Brick Systems, je podatkovno skladiš e ozna il kot »prostor, kjer lahko ljudje dostopajo do svojih podatkov« (1996). Podatkovno skladiš e torej predstavlja shrambo podatkov, ki pa morajo biti na voljo uporabnikom. Kelly (1994) opisuje podatke v podatkovnem skladiš u. Ti so: • Lo eni od ostalih transakcijskih sistemov v podjetju in sestavljeni iz podatkov iz teh sistemov. Lo enost od podatkov v transakcijskih sistemih je pomembna, ker s tem zagotovimo nemoteno obdelavo transakcij tudi ob zelo zahtevnih poizvedbah, ki bi sicer lahko upo asnile izvajanje transakcijskih aplikacij. • Namenjeni izklju no za povpraševanja poslovnih uporabnikov. Namen tako zbranih podatkov je torej podpora poslovnem odlo anju. • Dostopni uporabnikom, ki imajo omejeno znanje o ra unalniških sistemih ali podatkovnih strukturah. Ni torej dovolj, da so podatki dostopni informatikom in zahtevnejšim uporabnikom z znanjem strukture podatkovnih zbirk in poizvedovalnih jezikov (na primer SQL). Podatki morajo biti dostopni vsem, ki jih potrebujejo za pomo pri poslovnih odlo itvah, torej tudi analitikom in srednjemu in najvišjemu sloju upravljavcev.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 7 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Berry Devlin (1997) opisuje podatkovno skladiš e kot »enotno, popolno in konsistentno shrambo podatkov, pridobljenih iz razli nih virov in ponujenih kon nim uporabnikom na na in, ki ga razumejo in uporabljajo v poslovnem svetu«. Definicija poudarja enotnost podatkovnega skladiš a, ki omogo a, da uporabniki razpolagajo z "eno samo resnico" o poslovanju. Popolnost in konsistentnost podatkov zagotavljata kvalitetne podatke, ki so tudi temelj kvalitetnih poslovnih odlo itev. Michael J. Corey in Michael Abbey iz podjetja Oracle v knjigi (1997) opredeljujeta podatkovno skladiš e kot: »množico informacij podjetja, izpeljanih direktno iz operativnih sistemov in nekaterih zunanjih virov. Specifi ni namen podatkovnega skladiš a je podpora poslovnim odlo itvam, ne poslovnim operacijam«. V tej definiciji so eksplicitno omenjeni tudi zunanji viri. Podatkovno skladiš e torej ni le vmesna postaja podatkov iz transakcijskih sistemov na njihovi poti do uporabnikov, ampak vsebuje tudi podatke iz zunanjih virov, ki so pomembni za poslovne odlo itve. e povzamemo, je skladiš e podatkov namenjeno zbiranju, hranjenju in posredovanju pomembnih poslovnih podatkov podjetja. Za razliko od poslovnih informacijskih sistemov podjetja, ki služijo podpori sprotnemu poslovanju, skladiš a podatkov predstavljajo vir podatkov za poslovno obveš anje, izdelavo standardnih in ad-hoc poro il, sprotno analizo podatkov, lahko pa tudi osnovo za analiti ne aplikacije in implementacije metod za odkrivanje znanj iz podatkov. Skladiš e podatkov omogo a, da se podatki razli nih sistemov združijo v enotno zbirko podatkov, se obravnavajo na enoten na in in so dostopni vsem pooblaš enim uporabnikom. Hranijo se lahko tudi zgodovinski podatki zaradi pregleda po asovnih vrstah, esar transakcijski sistemi obi ajno ne omogo ajo. V skladiš e podatkov je mogo e prenesti razen podatkov iz poslovnih informacijskih sistemov podjetja tudi podatke, pridobljene iz zunanjih virov. Proces prenosa podatkov v skladiš e imenujemo s tujo kratico ETL – Extract Transform Load. V procesu ETL so definirane tri faze prenosa podatkov iz zunanjih virov v skladiš e podatkov. V prvem koraku se iz zunanjih virov podatkov izlo i te, ki so uporabni in pripravni za prenos na za asno podro je. V tem koraku se pripravi veliko koli ino podatkov. V drugi fazi se podatke pregleda, pre isti in izlo i neuporabne ter nepopolne podatke. Takšni podatki praviloma gredo v posebno obdelavo, saj naj bi skladiš e podatkov zajemalo vse operativne podatke. Podatke se pretvori v obliko, ki je uporabna za naslednjo obdelavo. Do dolo ene mere se lahko podatke združi v tistih sistemih, kjer se pripravlja specialno skladiš e za ve dimenzijske analize. S tem se koli ina podatkov zelo zmanjša. Zaradi zmanjšane koli ine podatkov in združevanja je priprava poro il ali izvajanje ad-hoc poizvedb hitrejše. V zadnji fazi se vrši prenos oziroma zapis podatkov v skladiš e podatkov. V skladiš u podatkov so podatki oblikovani na na in, ki omogo a uporabnikom preprosto izdelavo poro il in analiz podatkov, saj so podatki shranjeni v obliki dimenzij in mer. Zaradi tega je njihovo delo u inkovitejše, saj si sami izdelajo poro ila, kadar jih potrebujejo in jim ni treba akati, da jim ga izdela kdo drug. Praviloma je priprava takega poro ila temelje ega na podatkih iz skladiš a podatkov. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 8 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. tudi hitrejša od priprave poro ila na klasi en na in z ra unalniško obdelavo na osnovi rednih poslovnih podatkov. Ali je neko skladiš e podatkov veliko ali majhno? To niti ni pomemben podatek, saj je v skladiš ih podatkov vedno zapisano zelo veliko podatkov. Pomembno je, da so se razvijalci skladiš a podatkov že med razvojem odlo ili kakšna bo arhitektura in emu bo služilo. Tako lo imo celovita, specializirana in kombinirana skladiš a podatkov.. Slika 1:. Skladiš e podatkov, izvor podatkov in uporaba (vir SRC.SI). Celovito skladiš e podatkov (enterprise data warehouse) vsebuje številna poslovna podro ja podjetja in je namenjeno širokemu krogu uporabnikov. Specializirano ali podro no skladiš e podatkov (data mart) je namenjeno uporabi v ozko dolo enem poslovnem podro ju ali dolo eni skupini uporabnikov. Za takšno specializirano skladiš e podatkov so podatki posebej izbrani in prirejeni iz celovitega skladiš a podatkov. Možno se je odlo iti tekom priprave in razvoja skladiš a podatkov, da gradimo le to za dolo ene uporabnike. Vendar je to redek primer, ker je uporabnost omejena, kasneje pa je skoraj nemogo e takšno skladiš e podatkov razširiti za širši krog uporabnikov. Uporabniki rešitev za poslovno obveš anje imajo raznovrstne potrebe. Nekaterim zadostujejo vnaprej pripravljena poro ila, drugi pa bi potrebovali zahtevnejša orodja. Za takšne primere so uporabni generatorji poro il za ad-hoc poro anje in analize OLAP. Nadalje obstajajo orodja za izvajanje statistike, rudarjenje po podatkih in vizualizacije, ki omogo ajo pregled in prikaz podatkov na mnogo razli nih na inov glede na želeni rezultat. Za sprotno spremljanje uspešnosti poslovanja podjetja so Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 9 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. potrebna orodja za poslovno poro anje v smislu dostave ažurnih poro il izbranim prejemnikom, mnogo razsežnostne analize ali alarmiranja v primeru preseženih vnaprej dolo enih vrednosti kazalnikov.. Slika 2:. Možnost izkoriš anja skladiš a podatkov (vir SRC.SI). Seveda obstajajo še naprednejše analiti ne programske rešitve, ki v splošnem omogo ajo pregled klju nih kazalnikov poslovanja podjetja v raznih oblikah. Ta orodja nudijo dobre rezultate pri odkrivanju znanj iz podatkov. Osnovni namen poslovnega obveš anja je omogo iti uporabnikom preprost in hiter dostop do poslovnih informacij. Obi ajno je to preko skladiš a podatkov. Za uporabnike to pomeni manj porabljenega asa za zbiranje podatkov in ve asa za analizo podatkov in ukrepanje. S tem so doseženi cilji poslovnega obveš anja, ki so: izboljšati poslovanje, pove ati dobi konosnost, zmanjšati zaloge in pomagati pri vodenju podjetja ter planiranju. Za boljšo predstavo naredimo še primerjavo med transakcijskimi, to je operativnimi sistemi in poslovnim obveš anjem, kamor spadajo razni direktorski informacijski sistemi, seveda pa tudi OLAP. Transakcijski sistemi so podpora sprotnemu poslovanju podjetja. V njih se obdelujejo sprotne poslovne informacije. Pri poslovnem obveš anju se za izvor informacij uporablja skladiš e podatkov. Podatki za uporabo v namene poslovnega obveš anja dodatno obdelamo, ponavadi združimo, seštevamo, pripravimo primerjalne analize, itd. Razni avtorji uporabljajo podobne primerjave, kot navaja Maja Ferle (2004), so osnovne zna ilnosti in razlike obeh sistemov slede e:. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 10 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Transakcijski sistemi Obdelava transakcij.. Poslovno obveš anje Vpogled v poslovanje, spremljanje uspešnosti in uresni evanje strateških ciljev. Trenutni podatki, malo ali ni Zgodovinski podatki, možnosti zgodovine primerjave po letih oziroma preteklih obdobjih. Zelo podrobni podatki transakcij. Podatki so združeni, delno sešteti in vnaprej izra unani. Hitro vpisovanje podatkov. Hitre poizvedbe. Možnost vpogleda v podatke Možnost vpogleda v podatke vseh posameznega poslovnega podro ja. poslovnih podro ij, ki so zajeti. Poro ila so pripravljena vnaprej. Možnost izdelave lastnih poro il in adObi ajno ni možnosti preproste hoc poizvedb je skoraj neomejena. izdelave lastnih poro il, ampak jih je potrebno programirati. Tabela 1: Primerjava trans. sistema – posl. obveš anje (vir M. Ferle). 2.3. VE DIMENZIONALNE KOCKE OLAP. Izraz OLAP (On-Line Analytical Processing) je leta 1993 uvedel E. F. Codd, ki velja za o eta relacijske podatkovne baze. Ugotovil je, da relacijske podatkovne zbirke za transakcijske sisteme ne izpolnjujejo potreb po podatkih za podporo odlo anju. Predstavil je 12 pravil OLAP (kasneje razširjenih na 18), pri emer je predvidel, da so podatki v obliki ve dimenzijske kocke, ne pa v relacijski obliki (1993). Codd kasneje ni ve nadaljeval nikakršnih raziskav na tem podro ju, njegova pravila pa se danes ne upoštevajo ve , ker so nekatera med njimi zavirala razvoj tehnologije. Pendse navaja nekaj klju nih lastnosti, ki naj bi jih orodja OLAP imela. Omogo ati morajo (1998) konstantno hiter dostop uporabnikov do podatkov (ve ina poizvedb naj bi bila izvedena v manj kot petih sekundah), analiti ne zmogljivosti (osnovne numeri ne in statisti ne analize) in podpirati ve uporabniško okolje. Klju na lastnost tehnologije je ve dimenzijski (multidimensional) konceptualni pogled na podatke. OLAP je eno izmed klju nih orodij pri uporabi podatkovnih skladiš za podporo odlo anju. Codd ga je predstavil skupaj z ve dimenzijsko podatkovno zbirko, vendar je izraz postal uporaben tako za dimenzijske kot tudi relacijske predstavitve ve dimenzijskih podatkov. Orodja OLAP omogo ajo ve dimenzijske analize podatkov, ki nadomestijo ve zaporednih poizvedb in uporabniku olajšajo navigacijo in vrtanje po podatkih. Ker so podatki strukturirani v obliki hiperkocke, katere dimenzije predstavljajo osnovne poglede na podatke (na primer asovni, geografski...), lahko uporabniki uporabljajo prijeme, kot so »razrez in obra anje kocke« (slice and dice), pri katerem uporabniki lahko pogledajo podatke iz razli nih perspektiv in »vrtanje navzdol, navzgor in po ez« (drill down, up and across), kjer vrtanje pomeni navigacijo uporabnikov skozi Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 11 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. podatke navzdol (ve podrobnosti), navzgor (agregacija) in po ez (drugi podatki na isti ravni podrobnosti).. Slika 3:. Potek priprave podatkov za kocko (vir Hyperion). OLAP analiti ne rešitve so namenjene vodstvenim delavcem in analitikom za podporo odlo anja. Podpirajo hitre analize velikih koli in podatkov, ki so strukturirani in ve dimenzionalno organizirani. Podatke za daljša asovna obdobja je možno analizirati s sekundnimi odzivnimi asi. Pri gradnji OLAP analiti nih rešitev je potreben individualen pristop za vsako rešitev posebej, saj naj bi bila vsaka OLAP kocka pisana uporabniku na kožo.. 2.4. PRIPRAVA PORO IL. Pravilno in uspešno zgrajeno podatkovno skladiš e in razne nadgradnje v smislu programskih rešitev za analize poslovanja so ogromna pomo pri odlo anju. Vendar moramo do teh podatkov priti na enostaven in hiter na in, poleg tega pa moramo imeti še dodatne možnosti za predstavitve in dodatne kalkulacije. Temu služi programska oprema za pripravo poro il – generatorji poro il. Medtem, ko se je OLAP pojavil vzporedno s pojavom koncepta podatkovnega skladiš a, pa so orodja za poizvedbe v uporabi že bistveno dlje asa. Poizvedbena orodja omogo ajo tako imenovane ad hoc poizvedbe po podatkih iz podatkovne zbirke. Pri tem predstavljajo vmesnik med uporabniško poizvedbo po dolo enih podatkih in podatkovno zbirko, kjer so želeni podatki shranjeni. Posamezna orodja se razlikujejo glede na stopnjo prijaznosti uporabniškega vmesnika oz. stopnjo ra unalniškega znanja, ki ga uporabnik potrebuje za dostop do podatkov. Tako je pri nekaterih poizvedbenih orodjih nujno poznavanje poizvedbenega ra unalniškega Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 12 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. jezika (npr. SQL), pri drugih se poizvedbe oblikujejo s pomo jo grafi nega vmesnika, pri tretjih v obliki posplošenega stavka v angleškem jeziku, ipd. Poizvedbena orodja pogosto omogo ajo tudi dolo eno stopnjo formatiranja predstavitve podatkov oz. izdelavo poro il, kar jih uvrš a med orodja za poizvedbe in poro ila. Koncept podatkovnega skladiš a omogo a precej prednosti za orodja za poizvedbe in poro ila. V podatkovnem skladiš u so podatki za poizvedbe na enem samem mestu, o iš eni in med seboj konsistentni. Uporabniki tako pridejo lažje do njih, podatki so tudi kvalitetnejši. Ker so podatki izlo eni iz transakcijskih sistemov, odpade nevarnost, da bi na primer kompleksna SQL poizvedba ogrožala (povzro ila upo asnitev ali celo zaustavitev) normalno delo transakcijskega sistema. Podatkovni modeli v skladiš u podatkov skupaj z meta podatki pomagajo uporabnikom do lažjega razumevanje strukture podatkov. S temi orodji pripravimo poro ila in preglede, ki jih predvsem v vodstvu poslovnih enot ali podjetja in drugi naro niki vidijo. Omogo ati morajo takšen prikaz podatkov, ki jasno, nedvoumno in hitro prikaže poslovne rezultate potrebne za odlo anje (slika 4). Poleg tega mora biti omogo ena prilagodljivost razli nim uporabnikom rezultatov in avtomati no osveževanje ob spremembah osnovnih podatkov.. Slika 4:. Razli ne možnosti poro il. Dobro je, e so podatki iz poro il dovolj fleksibilni, da jih je možno prenesti v druga analiti na orodja, kjer se rezultate kombinira še z drugimi analizami. Veliko takšnih orodij obstaja pri izvajalcih Microsoft, SAS, SAP, IBM, ORACLE in še kje. Kombinacija ve preglednic je v asih potreben pogoj za dobra poro ila o poslovanju podjetja. Ve o pripravi poro il bomo pisali v poglavju 5.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 13 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. 3. RAZVOJ SKLADIŠ A PODATKOV TRŽENJA. 3.1. RAZVOJ MODELA PODATKOV. ZA SLUŽBO. Pri predstavitvi podatkov v podatkovnem skladiš u ima klju no vlogo podatkovni model. Na tem podro ju se najpogosteje uporabljata dva pristopa: entitetno (Entity Relationship modeling) in dimenzijsko (Dimensional modeling) modeliranje, ki ga ponekod v strokovni literaturi imenujejo tudi ve dimenzijsko modeliranje (Multidimensional modeling). Podatkovni model ima v okolju podatkovnega skladiš a velik pomen, ker omogo a predstavitev podatkov uporabnikom, služi kot na rt podatkovnega skladiš a in omogo a konsolidacijo podatkov iz razli nih izvorov in poslovnih podro ij. Ne glede na izbrani model so med modeliranjem za transakcijsko okolje in modeliranjem za okolje podatkovnega skladiš a precejšnje razlike. V transakcijskem okolju se ve inoma uporablja entitetno modeliranje. Pri tem se pogosto uporablja izraz OLTP (On-Line Transactional Processing) modeliranje. Pri prakti ni pripravi podatkovnega modela za skladiš e podatkov bomo poleg na zahteve uporabnikov morali paziti tudi na zna ilnosti skladiš a podatkov zaradi kasnejšega dograjevanja, e bi do tega prišlo. Zna ilnosti so torej vsebinska usmerjenost, integriranost in asovna obstojnost. Vsebinska usmerjenost skladiš a podatkov se bo izražala v tem, da bo organizirano okoli pomembnejših vsebinskih podro ij podjetja, kot so na primer zavarovanje in na in prodaje le teh. Integriranost skladiš a podatkov ni dosežena s preprostim kopiranjem podatkov iz transakcijskega okolja. Podatke, ki so na razli nih lokacijah v podjetju in so pogosto nekonsistentni, bomo pri prenosu v skladiš e podatkov, to je med ETL procesom, uredili in pre istili tako, kot to pri akujejo uporabniki. Podatki bodo morali biti asovno obstojni zato, ker jih pre iš ene in urejene nalagamo v skladiš e podatkov, nato pa jih le še beremo. Ažuriranja podatkov v splošnem pomenu te besede ni. Podatkovno skladiš e bo zato nekakšen arhiv podatkov, pomembnih za podjetje. Podatkovno skladiš e vsebuje pet vrst podatkov in sicer (tako Gray in Watson 1998): (1)sveže in (2) stare podrobne podatke, (3) nizko in (4) visoko agregirane podatke ter (5) meta podatke. e pustimo ob strani meta podatke, ki imajo povsem drugo vlogo kot prve štiri vrste podatkov, nam ostaneta dva kriterija, po katerih lo ujemo podatke v podatkovnem skladiš u: • raven agregacije podatkov. • starost podatkov. Raven agregacije podatkov imenujemo tudi zrnatost podatkov in se nanaša na raven podrobnosti podatkov v podatkovnem skladiš u. im ve je podrobnosti, nižja je raven zrnatosti in obratno. Stvar je pomembna zaradi poizvedovanj. Z zelo nizko Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 14 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. ravnjo zrnatosti lahko odgovorimo na prakti no vsako poizvedbo, z visoko ravnjo zrnatosti pa je število poizvedb, ki jih lahko uporabimo, omejeno. Seveda pa nizka raven zrnatosti pomeni zelo velike koli ine podatkov in dolge ase izvajanja poizvedb. Uporabniki ponavadi želijo u inkovitost pri shranjevanju in dostopu do podatkov in možnost podrobnih poizvedb. To je mogo e dose i s shranjevanjem podatkov v dveh ravneh zrnatosti, emur pravimo dualna zrnatost. Mi bomo pripravili zelo podrobno skladiš e podatkov, ker ga bomo nadgradili z OLAP aplikacijo, za katero se pri kalkulaciji pripravi baza podatkov višje ravni zrnatosti. Za novejše podatke, ki odsevajo nedavno dogajanje potrebujemo nižjo raven zrnatosti kot pri starih podatkih, ki jih ne potrebujemo pogosto in zadoš a višja zrnatost podatkov. Zato bi lahko stare podrobne podatke shranili na arhivska mesta z slabšim asom dostopa. Mi bomo pripravili enotno skladiš e podatkov ne glede na starost podatkov. Glede na že obstoje o manjšo OLAP aplikacijo so bila pri akovanja naro nika in kon nih uporabnikov za novo ra unalniško rešitev velika. Rok izdelave podatkovnega modela nadgrajenega z OLAP kocko je bil sorazmerno zelo kratek – šest mesecev. Kimball (2004) ocenjuje, da je za pripravo modela podatkov in podatkovnega skladiš a podprtega z ETL metodo za en poslovni proces potrebno šest mesecev. V našem primeru pa je bil pri akovan še razvoj OLAP aplikacije. Definicija dimenzij in tabel dejstev V uspešnem sodelovanju z naro nikom smo pripravili model podatkov, ki bo ustrezal izpolnitvi zahtev. Kon na rešitev bo vezana na zahteve po informacijah o obnašanju naših storitev na trgu, s imer bodo v službi trženja in upravi podjetja ustrezno reagirali na obnašanje trga pri prodaji obstoje ih zavarovanj in na razvoj novih zavarovanj. Zahtevani podatki v kon ni rešitvi obsegajo možnosti analize obnašanja naslednjih vrednosti: • premijo sklenjenih zavarovanj, • število sklenjenih zavarovanj, • zavarovalno vsoto zavarovanega rizika in • znesek škod iz škodnih primerov. Pokriti moramo šest kriterijev za navzkrižne analize: izvor, kamor spada naša stranka v naših poslovnih procesih, status zavarovalca v smislu ali je to pravna ali fizi na oseba, lokacija, ki je geografska komponenta, prodajna pot ali na in prodaje zavarovanja, naša storitev, sklenjeno zavarovanje ali obravnavan škodni primer in as oz. datum dogodka.. • • • • • •. To je hkrati že grob opis bodo ih dimenzij in enot mere. Dimenzija datum bo vsebovala potrebne podatke o datumih sklenjenega zavarovanja ali prijavi škodnega primera. Podatki o statusu zavarovalca (pravna/fizi na oseba) bodo v dimenziji status zavarovalca, o izvoru (zavarovanje/škoda) pa v dimenziji izvor. Podatke, povezane z vrsto storitve oz. vrsto sklenjenega zavarovanja bomo zapisali v dimenzijo zavarovanje. Dimenzija prodajna pot bo vsebovala podatke o tržni poti, to. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 15 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. je o na inu prodaje zavarovanja. Ta podatek potrebujemo tudi ob otvoritvi škodnega spisa v primeru škodnega dogodka. V dimenziji lokacija bo podatek o geografskem položaju, kjer je bilo sklenjeno zavarovanje oz. prijavljena škoda. To pomeni podatek o obmo ni enoti ali pa tudi ožje, o zastopu znotraj obmo ne enote. Ko imamo dimenzije dolo ene, se lotimo definiranja tabel dejstev. Vemo, da operativni podatki izhajajo iz treh procesov, ki jih bomo pokrili z enim skladiš em podatkov. Ti procesi se lo ijo najprej po tem ali obravnavamo škodni primer ali sklenjeno zavarovanje, torej po izvoru. Pri sklepanju zavarovanj lo imo spet dva procesa glede na status zavarovalca, ki je lahko pravna oseba ali fizi na oseba.. Slika 5:. Diagrama tabel dejstev za prodajo zavarovanj in škode. Tabela dejstev za sklenjena zavarovanja za fizi ne osebe. Tabela dejstev za sklenjena zavarovanja za pravne osebe. Tabela dejstev za škodne primere. Datum K Izvor K Status zavarovalca K Prodajna pot K Lokacija K Zavarovanje K. Datum K Izvor K Status zavarovalca K Prodajna pot K Lokacija K Zavarovanje K. Datum K Izvor K Status zavarovalca K Prodajna pot K Lokacija K Zavarovanje K. Premija Zavarovalna vsota Število zavarovanj. Premija Zavarovalna vsota Število zavarovanj. Znesek škode. Tabela 2: Tabele dejstev Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 16 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Definirali bomo tri tabele dejstev: • OLAPA za sklenjena zavarovanja fizi nih oseb, • OLAPP za sklenjena zavarovanja pravnih oseb in • OLAPS za odprte škodne primere. Na sliki 5 sta prikazani tabeli dejstev za škode in sklepanje zavarovanj. Tabeli dejstev za sklepanje zavarovanj za pravne in fizi ne osebe sta enaki in zato je ta tabela dejstev prikazana samo enkrat. V podrobnem na rtu tabele dejstev, ki je v tabeli 2 je popoln seznam vseh dejstev tabele dejstev. Vsebuje dejstva iz fizi ne tabele. Klju i dimenzij so ozna eni s K. Po definiranju dimenzijskih tabel dobimo model podatkov prikazan na sliki 6.. Slika 6:. 3.2. Model podatkov brez entitet. POLNJENJE SKLADIŠ A PODATKOV. Ponavadi ima arhitektura podatkovnega skladiš a tri komponente: • Programska oprema za pridobivanje podatkov v podatkovno skladiš e skrbi za prenos, konsolidacijo in agregacijo podatkov iz operativnih sistemov in zunanjih izvorov v podatkovno skladiš e. • Podatkovno skladiš e samo vsebuje podatke in ustrezno programsko opremo. • Programska oprema na uporabniški strani omogo a uporabnikom dostop do podatkov in njihovo analizo.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 17 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Podatke za skladiš e podatkov lahko sedaj rpamo iz centralne relacijske baze podatkov IBM DB2. S programi za prenos in iš enje podatkov beremo vrsto tabel na vhodni strani in jih po urejanju in združevanju zapišemo v tabele dejstev OLAPA, OLAPP in OLAPS. Na vhodu je seveda druga en model podatkov, ki je prirejen in razvit za transakcijske operativne programe. Zato je ve vhodnih tabel. Ko so tabele dejstev napolnjene, preidemo na polnjenje dimenzijskih tabel zvezdaste sheme. V naslednji fazi bomo izvajali programe za polnjenje OLAP kocke. V to obdelavo spadajo ukazi za polnitev dimenzij s podatki in pripravo - kalkulacijo vrednosti. isto na koncu celotnega procesa priprave skladiš a podatkov so na vrsti analiti na orodja v rokah kon nih uporabnikov, s katerimi opravljajo analize in pripravljajo poro ila in preglede. Glede na zahteve uporabnikov osvežujemo skladiš e podatkov tedensko. Do sedaj je ta gostota zadoš ala. Po teoriji bi seveda lahko obnavljali podatke dosti bolj redko, tudi vsako uro. Vendar niti poro ila za službo trženja ali upravo podjetja niti ad-hoc analize ne bazirajo na tako svežih podatkih, da bi bil potrebno bolj pogosto polnjenje skladiš a podatkov.. 3.3. UPORABA. Podatke iz opisanega skladiš a podatkov uporabljamo najve za hitre analize raznih vrst, ko niso potrebne dolge priprave in daljša programiranja. Ob asno pridejo tudi bolj kompleksne zahteve po podatkih oz. poro ilih, ki jih na drug na in ni možno pripraviti.. Slika 7:. Življenjski cikel skladiš a podatkov (vir Kosar). Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 18 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Še najve pa uporabljamo skladiš e podatkov za pripravo OLAP kock. Zaradi možnosti, ki jih nudijo takšna analiti na orodja, kot je OLAP, smo pripravili opisano skladiš e podatkov. Kot pri nobeni drugi ra unalniški rešitvi, tudi pri vzdrževanju skladiš a podatkov ne smemo zaspati. Kosar (Bischoff in Alexander, 1997:66) opisuje življenjski cikel skladiš a podatkov (slika 7) in opozarja, da je potrebno tudi tu spremljati razvoj. Velika verjetnost je, da vsi živi informacijski sistemi rastejo in se razvijajo. S tem nastajajo vedno novi podatki v vedno novih in mogo e druga nih datotekah, bazah in ostalih podatkovnih zbirkah. Ker se spreminja vhodna struktura podatkov za skladiš e podatkov, je tudi podatkovni model skladiš a potreben stalnega dopolnjevanja v kolikor želimo uspešno uporabljati te podatke za analize in pomo pri odlo anju.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 19 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. 4. RAZVOJ KOCKE OLAP ZA SLUŽBO TRŽENJA. 4.1. UVOD. V podjetju Zavarovalnica Triglav, d.d. smo o tehnologiji OLAP za eli razmišljati pred petimi leti in že pred štirimi leti poleg podatkovnega skladiš a razvili tudi prvo OLAP kocko. Poleg enot mer je vsebovala še asovno in štiri druge dimenzije. Prvo OLAP kocko smo razvili z orodji starejše oz. prejšnje generacije, ki so bila aktualna pred štirimi ali petimi leti. Tu naj omenim predvsem: • IBM WebSphere Application server v4.5, • IBM HTTP Server v1.2, • IBM DB2 OLAP Server v8.1 in • Essbase Application Manager v6.5. Ta orodja so bila nerodna in zapletena za uporabo kljub že precej visokim številkam verzij. Prva tri omenjena orodja so bolj vezana na strežnik, ki je bil dolo en za razvoj OLAP-a. Razvijalec je moral poskrbeti edino za start servisov. Zanimivo je bilo, da je moral biti IBM DB2 OLAP Server v8.1 nameš en na strežniku, nujno pa za razvoj tudi IBM DB2 OLAP Client v8.1 – verzija za razvijalca – na razvojni postaji. Kasneje bomo videli, da sedaj zadoš a orodje nameš eno na strežniku. Zadnje orodje - Essbase Application Manager v6.5, s katerim smo razvijali OLAP aplikacije, je bilo nameš eno na razvojnih postajah. Bilo je precej okorno. Zahtevalo je izkušenega razvijalca, ki je obvladal vrsto ro nih nastavitev za vsako funkcijo razvoja posebej. To je zelo otežilo delo, saj smo se med razvojem prve OLAP kocke še u ili in spoznavali z orodjem. V Sloveniji prakti no ni bilo velikih podjetij z razvito OLAP rešitvijo, zato smo se lahko zanašali predvsem nase. Ve o omenjenih orodjih, eprav novejših verzij, bom napisal v naslednjem poglavju.. 4.2. RAZVOJ VE DIMENZIONALNE KOCKE OLAP. Sedaj razvijamo OLAP aplikacije z orodji zadnje verzije. Razvoj je u inkovitejši, hitrejši, manj kompliciran in za razvijalca prijetnejši. Na strežniku za OLAP aplikacije imamo nameš ene: • IBM WebSphere Application server v5.1, katerega del je IBM HTTP Server v1.3.28 ter • IBM DB2 OLAP Server v8.2. To so moderna orodja zadnjih verzij. Orodja so nameš ena samo na strežniku in ves as aktivna. e strežnik deluje, nam razvijalcem ni potrebno skrbeti za ta del podpore.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 20 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. IBM WebSphere Application server v5.1 (WAS) in IBM HTTP Server v1.3.28 sta zaš itna znamka IBM korporacije. Predstavljata tako imenovano 'middleware software' kategorijo za gradnjo aplikacij in delo z njimi na razli nih platformah na svetovnem spletu. WAS omogo a uporabo že obstoje ih spletnih aplikacij ali njihov razvoj. Skrbi za distribucijo in možnost hkratne uporabe spletnih aplikacij ve uporabnikom. Brez teh orodij ne bi bilo vpogledov v rešitve, ki jih prinaša OLAP aplikacija. IBM DB2 OLAP Server v8.2 je okolje za razvoj OLAP aplikacij – kock. V nazivu obeh verzij je razlika samo v drugem delu številke verzije, prej 8.1, sedaj 8.2, vendar novejša verzija orodja vsebuje veliko izboljšav in omogo a veliko boljši, enostavnejši ter hitrejši razvoj. Kar se ti e zahtev po pomnilniku, je nova verzija neprimerno bolj prijazna in bolj prilagodljiva strojnemu okolju. Prej je obstajal samo en na in kalkulacije in s tem stroga dolo itev potrebnega pomnilnika za neko kocko. V primeru velike kocke – ve dimenzij z ve nivoji v hierarhiji posamezne dimenzije – je bilo potrebnega sorazmerno zelo veliko pomnilniškega prostora. Druga možnost je bila omejiti se pri pripravi kocke – definirati manj dimenzij z manj nivoji. To je bilo zaradi zahtev kon nega uporabnika težko narediti. Z novo verzijo smo dobili možnost boljše uporabe spominskega prostora. Na razvojni postaji imam nameš en Essbase Administration Services v7.1 podjetja Hyperion Solutions Corporation. To podjetje je IBM-ov partner, ki je prevzel razvoj OLAP orodij in podobnih spletnih analiti nih orodij za korporacijo IBM. Ker je podatkovno skladiš e pripravljeno in narejena zvezdna shema dimenzijskih relacijskih tabel, se bom sedaj ukvarjal samo še z definiranjem OLAP aplikacije, definiranjem in na rtovanjem kocke, definiranjem in pisanjem pravil dolo anja posami nih dimenzij ter pripravo pravil za polnjenje in ra unanje kocke. OLAP kocke razvijam z orodjem Essbase Administration Services (EAS). Orodje je moderno in napredno in razvijalcu omogo a, da sorazmerno hitro razvije novo kocko. EAS pomaga na vsaki stopnji razvoja. Ve ino ukazov se izvaja z izbiranjem podanih funkcij ali možnosti ali nastavitev. Nekaj ve dela je pri oblikovanju prikaza zaloge vrednosti za dimenzije. Najve dela in asa nam vzame priprava ukazov za polnjenje dimenzij in pripravo rezultatov. To opravimo s programiranjem z SQL ukazi. Seveda so pomembna vsa pravila takšnega programiranja, saj lahko v primeru slabih ukazov polnjenje dimenzij traja zelo dolgo. Še ve asa pa je potrebno za polnjenje rezultatov – enot mer. Še enkrat ve vidimo, kako pomembno je dobro skladiš e podatkov. Po kon ani fazi razvoja kocke in testiranju rezultatov pripravimo program za izvajanje celote ukazov, ki redno napolnijo OLAP kocko. Ta kratko opisan postopek bom prikazal na dejanskem prakti nem razvoju OLAP aplikacije v našem podjetju. Velikokrat bom moral uporabiti angleški strokovni izraz, ker v asih ni mogo e pravilno logi no prevesti dolo enih ra unalniških izrazov. Kratek angleški izraz mnogokrat pove ve kot dolg opis v slovenš ini. Po prijavnem protokolu na EAS nadaljujemo z delom na razvoju. Na osnovnem ekranu (slika 8) imamo postavke za administracijo EAS (Essbase Administration Servers) in orodja za razvoj OLAP aplikacij (Essbase Analytic Servers). Tretja. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 21 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. možnost so orodja z dodatnimi možnostmi za razvoj (Essbase Deployment Servers), ki jih naše podjetje nima in ne potrebuje, so pa posebej pla ljiva in dobavljiva.. Slika 8:. Po prijavi v orodje EAS. Postopek razvoja nove OLAP kocke bo potekal od definicije aplikacije preko definicije kocke, dimenzij in njihovih lastnosti do pisanja pravil za polnjenje podatkov ter izvajanja le teh. Aplikacija je ime, pod katerim bomo mi in uporabniki poznali to OLAP rešitev. Kocka je pri IBM-u 'cube', pri firmi Hyperion Solutions pa ji pravijo 'database'. V takšni bazi podatkov so res vsi podatki za kocko, vendar je izraz 'database' v svetu informatike bolj oznaka za pravo bazo podatkov. Definicija aplikacije Aplikacija je lahko, glede na uporabo spominskega prostora (slika 9), definirana na dva na ina. Vsak na in ima svoje prednosti in slabosti. Uporaba prvega - block storage pomeni, da je potrebno za kocko izra unati vse možne kombinacije med dimenzijami in pripraviti prostor za rezultate kartezi nega produkta teh kombinacij tudi, e je izra un vrednosti neke kombinacije enak ni . V tem primeru se ra una kombinacije za vse nivoje hierarhij vsake dimenzije. To pomeni porabo ogromne koli ine pomnilnika (100 GB) za eno OLAP kocko s 5 dimenzijami, ki pokriva en proces (marketing) v srednje velikem podjetju (Zavarovalnica Triglav). Druga slabost je redno izvajanje celotne kalkulacije kocke, ker ni dinami nih izra unov. Prednost take aplikacije pa je ravno v stalno izra unanih vseh kombinacijah. Torej je priprava kakršnegakoli poro ila vedno hitra. Drugi na in razvoja aplikacije z uporabo združenega pomnilnika - aggregate storage pomeni, da bo porabljeno najmanj pomnilnika, kot je mogo e. Dodatna kalkulacija ni Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 22 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. potrebna. Ob polnjenju dimenzij in podatkov se zelo hitro izvrši izra un samo na najvišjih nivojih hierarhij, kar pomeni malo porabljenega pomnilnika (3 GB) za eno OLAP kocko. Slabost tega je, da je pri pripravi poro il, ki zahtevajo rezultate na nižjih nivojih potrebno po akati nekaj sekund ali celo minut, da se takrat dinami no izvrši izra un. Razvijalec ali kasneje vzdrževalec aplikacije lahko po potrebi pripravi ukaze za dodatne kalkulacije ob polnjenju podatkov in s tem izboljša as priprave poro il. V na inu združenega spomina se vrednosti, katerih rezultat bi bil ni , ne ra una in se s tem tudi ne obremenjuje spomina.. Slika 9:. Kreiranje nove aplikacije. Kako hitro bo kocka izra unana in kako veliko ali malo spominskega prostora bo zasedla je odvisno tudi od pravilne definicije dimenzij. Pomembno je, koliko medsebojnih križanj ali odnosov imajo dimenzije. e je teh veliko (prodaja vseh zavarovanj na vseh lokacijah), so to goste - dense dimenzije. e je teh križanj malo (vsa zavarovanja se ne prodajajo na vseh lokacijah), so to redke sparse dimenzije. Pomembno je, da dimenzijam to lastnost pravilno ocenimo in dolo imo. Napa no ozna ena dimenzija lahko zelo poslabša ali celo prepre i ra unanje kocke. Ti vplivi se poznajo pri oblikovanju aplikacije z izborom Using block storage, pri izboru Using aggregate storage pa te definicije dimenzij ne vplivajo na hitrost kalkulacij. Prav tako razlikujemo goste - dense kocke z veliko gostoto med-dimenzijskih kombinacij in redke 'sparse' kocke s sorazmerno malo kombinacijami med dimenzijami. Pravilo je,. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 23 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. da v primeru, ko imamo bolj gosto kocko, izberemo block storage option (BSO) na in, e prevladujejo redke dimenzije, pa aggregate storage option (ASO) na in. Na koncu vpliva na izbiro vrste aplikacije še uporaba formul pri kalkulaciji. V ASO aplikaciji so dovoljene samo formule z osnovnimi matemati nimi funkcijami in to samo pri enotah mer. e uporabljamo bolj kompleksne formule ali želimo uporabljati formule tudi v ostalih dimenzijah, moramo nujno kreirati aplikacijo na na in BSO. Pri uporabi formul v enotah mere navadno ra unamo medsebojna razmerja dveh sorodnih vrednosti, ali seštevamo oz. množimo vrednosti med sabo. Pri bolj kompliciranih analizah imamo lahko v enotah mere definirane vrednosti, ki se pri kalkulaciji ne ra unajo direktno iz osnovnih podatkov, pa pa so rezultat uporabe formul pri izra unih znotraj kocke. Formule lahko uporabljamo tudi v ostalih dimenzijah kocke. Uporabljajo se za primerjave med podatki, za združevanja v skupine, za prirejanje novih vrednosti in še za mnogo drugih operacij s podatki in vrednostmi. Seznam ukazov in funkcij, katere lahko uporabljamo v formulah je v prilogah 1 in 2. Popolnoma univerzalnega pravila za odlo itev o uporabi dolo ene metode ni. Najbolj se lahko zanesemo na izkušnje. Drugi najpomembnejši faktor so potrebe in zahteve kon nega uporabnika. V predhodnih verzijah tega orodja - Essbase Administration Services pa je obstajal samo BSO na in definiranje aplikacije. V našem primeru smo se odlo il za razvoj aplikacije z imenom PRO_ZT (prodaja za Zavarovalnico Triglav) in aggregate storage option (ASO). Ime aplikacije mora biti edinstveno in se na OLAP strežniku ne sme ponoviti.. Slika 10: Dolo itev lastnosti aplikacije Takoj po kreiranju aplikacije dolo imo njene lastnosti (slika 10). Sem spadajo razne osnovne nastavitve za kon ne uporabnike (dovoljenje za delo z aplikacijo) in varnostne nastavitve. Vse to dosežemo z enostavnim ozna evanjem. Poleg tega Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 24 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. dolo imo podro je (tudi velikost), kjer bodo spravljeni podatki za to aplikacijo in za asno podro je, potrebno v primeru kalkulacij. Definicija kocke (database) Sledi oblikovanje kocke z imenom PRODAJA (slika 11). V vsaki ASO aplikaciji smemo tvoriti le eno kocko. V BSO aplikaciji na eloma lahko tvorimo ve kock, vendar to ni priporo ljivo. Z ve kockami v eni aplikaciji ne bi ni pridobili. Zato v praksi tudi v primeru uporabe block storage option tvorimo le eno kocko na aplikacijo.. Slika 11: Kreiranje nove kocke Imena programov, objektov, aplikacij, kock itd. imamo standardizirana. Zato se iz imena kocke in aplikacije slutita naro nik ra unalniške rešitve in funkcija OLAP kocke. Ime kocke se lahko za razliko od imena aplikacije ponavlja v razli nih aplikacijah. Tudi na naši zavarovalnici imamo ve aplikacij in enako ime kock v njih. Imena kock povedo, kakšne vrste podatke vsebuje, kot npr. Prodaja, Popusti in Komercialisti.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 25 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Po definiciji kocke se prikažejo ostale možnosti. Lastnosti kocke nas tokrat ne zanimajo, zato se lotimo na rta (outline), kjer bomo v grobem definirali enote mere in dimenzije kocke. Že med izgradnjo skladiš a podatkov smo s službo trženja dolo ili okvirno strukturo nove kocke, torej podatke, ki jih želijo dobiti iz tokratne ra unalniške rešitve. Osnovne vrednosti v rezultatih imenujemo enote mere in te so: zavarovalna premija, število zavarovanj, zavarovalna vsota in škode (znesek škod). Poleg enot mer bomo kreirali še asovno dimenzijo ter pet drugih dimenzij: zavarovanje, prodajna pot, lokacija, status zavarovalca in izvor. Na seznamu pod kocko PRODAJA izberemo outline. Na zavihku properties-lastnosti (slika 12) lahko pogledamo lastnosti na rta kocke in preverimo avtomatsko nastavljene parametre ter jih po potrebi spremenimo .. Slika 12: Lastnosti na rta kocke Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 26 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Na zavihku outline vnesemo osnovne podatke o enotah mer in dimenzijah. To omogo imo z gumbom za dodajanje otrok na na rt ali v izbrano pozicijo (Add a child to the selected member), kar vidimo na sliki 13 v levem ekranu. V Outline editorju obstajata dva na ina dodajanja lanov na rta kocke. En na in je že omenjeno dodajanje otrok na naslednji nižji nivo ozna enega lana. lanu na višjem nivoju pravimo starš - parent. Druga možnost je dodajanje sorodnika (Add a sibling to the selected member) na isti nivo kot je že ozna en lan. lan na rta je vsaka postavka na na rtu kocke, ne glede na nivo na katerem se nahaja. Osnovne lane, to so lani na najvišjem – prvem nivoju vedno vpišemo ro no. Vsi ostali lani se pojavijo na na rtu po polnjenju posamezne dimenzije kocke. Izjema so enote mere, kjer vpišemo lana z imenom enote mere in vse otroke - lane enot mer ro no.. Slika 13: Vpis na rta kocke Po vrsti vpišemo vse dimenzije (slika 13, osrednji ekran): • enote mere, • datum, • zavarovanje, • prodajna pot, • lokacija, • status zavarovalca in • izvor. Nato še za enote mere vnesemo otroke. Najprej ozna imo lana enote mere in z gumbom za dodajanje otrok omogo imo vnos (slika 13, desni ekran): • premija, • število zavarovanj, • zavarovalna vsota in • škode.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 27 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Na sliki 14 so ozna ene vse lastnosti, ki jih lahko dolo imo dimenzijam. Bistvena lastnost za enote mere je ra unanje – Accounts Dimension type. Ko kliknemo ta gumb ali ikono se poleg lana enote mere zapiše Accounts. Lastnost Label only pomeni, da ne bo s lanom shranjena nobena vrednost iz kalkulacije. To lastnost vedno ozna imo pri enotah mer, nikoli pa na prvem, najvišjem nivoju ostalih lanov na rta. Ta lastnost nima vpliva v ASO aplikaciji. V BSO aplikaciji omogo i manjši porabljeni spominski prostor, vendar daljši as priprave poro il zaradi takrat izvedene dinami ne kalkulacije.. Slika 14: Lastnosti dimenzij (prvi ) Vse ostale dimenzije (razen enote mere) so avtomati no ozna ene za dimenzije brez tipa – 'No Dimension Type' in za shranjevanje vrednosti k lanom skupaj – 'Store Data (unless optimizations are possible)'. Pri naši ASO aplikaciji vrednosti niso spravljene zaradi optimizacije in se dinami no izra unajo ob kreiranju poro ila. Naslednjo lastnost atribut – 'Attribute Dimension Type' uporabimo, e kreiramo dimenzijo, v kateri so zapisani samo opisi druge dimenzije. Takšna atribut dimenzija ne more dobiti vrednosti iz enot mer. Prav posebno lastnost nosijo hibridne dimenzije. Te lahko dolo imo le, e je hibriden celoten na rt (outline). Druga e je ta možnost izklju ena. Podatke za hibridno dimenzijo delno izra unamo pri kalkulaciji, delno pa se po potrebi preberejo direktno iz baze podatkov. Od tu tudi naziv hibridna dimenzija.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 28 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Po dolo itvi lastnosti dimenzij moramo natan neje definirati še lastnosti enot mer (slika 15). Essbase Administration Server nam v koraku gradnje na rta kocke daje veliko razli nih možnosti za dolo itev lastnosti enot mer. V našem primeru dolo imo za vse enote mere, da se izlo ijo iz združevanja in medsebojnega seštevanja – exclude from consolidation. To pomeni, da se med ra unanjem kocke vrednosti posameznih enot mer ne seštevajo. Ni nam namre ne pove seštevek premij, škod in zavarovalnih vsot ter števila zavarovanj. To so popolnoma razli ne kategorije podatkov in veliko povedo v medsebojni primerjavi. Druge lastnosti, ki jih lahko pripišemo enotam mer v primeru, da se ne odlo imo za možnost izlo itve iz konsolidacije so konsolidacija s seštevanjem, odštevanjem, množenjem in deljenjem ali pa se pri konsolidaciji uporablja procentni ra un. Tako dobimo že pripravljene razli ne rezultate.. Slika 15: Lastnosti dimenzij (drugi ) Preden nadaljujemo preverimo pravilnost vpisanih podatkov, postopkov in pravil z verificiranjem (gumb verify) ter shranimo na rt kocke. S tem imamo narejen osnovni na rt (outline) strukture kocke. Opisali smo samo imena dimenzij in enot mer ter nekaj osnovnih lastnosti. Ne vidimo pa še oblike dimenzij in njihove hierarhije.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 29 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. e sedaj pogledamo lastnosti kocke PRODAJA in zavihek dimenzij (slika 16), vidimo vpisanih sedem dimenzij s po enim lanom – staršem razen za enote mer, kjer jih je pet: en starš in štirje otroci.. Slika 16: Lastnosti kocke in pregled dimenzij Do sem je postopek priprave nove kocke potekal hitro. Natan no definicijo posamezne dimenzije bomo dolo ili pri vpisu pravil za polnjenje dimenzij s podatki. Priprava pravil in dimenzij as je pri ve ini analiz zelo pomemben faktor, saj primerjave med obdobji najbolje orišejo poslovanje vsakega podjetja. Torej je as najpomembnejša dimenzija. Ta dimenzija je vedno gosta (dense) dimenzija. V nekem obdobju je skoraj vsak dan kakšna aktivnost ali pri sklepanju zavarovanj ali pri obravnavanju škodnih primerov. Vsak takšen dan se pojavi v dimenziji in to so skoraj vsi dnevi iz zaloge vrednosti dni v nekem obdobju. Mogo e je izklju ena kakšna nedelja ali prazni ni dan. V tej dimenziji je dan zelo pomemben nivo pogledov in poro il. Višji nivo je lahko teden ali mesec, še višji trimese je ali polletje in najvišji leto. Seveda bi lahko bil v dolo enih poslovnih pregledih dan premajhna enota in bi zgradili kocko s tednom na najnižjem nivoju. V Zavarovalnici Triglav bomo v asovno dimenzijo vgradili štiri nivoje: • celotno obdobje skupaj, • leto, • mesec in • dan oz. datum.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 30 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. V našem primeru sledi še pet drugih dimenzij: • Zavarovanje so podatki o vrstah in podvrstah zavarovanj, posameznih zavarovanjih in skupinah zavarovanj. Našteta so vsa zavarovanja, ki jih lahko stranke sklenejo v Zavarovalnici Triglav. To je zelo velika dimenzija z nekaj deset tiso lani. Prvi nivo so vsa zavarovanja skupaj. Na drugem nivoju imamo približno deset skupin zavarovanj. Na tretjem nivoju je vpisanih preko sto zavarovalnih podvrst. Na etrtem nivoju so vsa zavarovanja Zavarovalnice Triglav – zavarovalne enote. V posami no zavarovalno podvrsto spada tudi ez tiso zavarovalnih enot. • Prodajna pot je na in prodaje zavarovanj, npr. preko zastopnikov ali agencij skupaj ali za posameznega delavca. Dimenzija ima tri nivoje z enajstimi razli nimi prodajnimi potmi na drugem nivoju in do tristo zastopniki na tretjem nivoju. To je velika dimenzija. • Lokacija je dimenzija, kjer so opisana manjša ali ve ja geografska podro ja. Podatki se obravnavajo združeni za celotno obmo no enoto ali zastop. Vsebuje tri nivoje. Na drugem je zaloga vrednosti trinajst obmo nih enot. Na naslednjem nivoju so vpisani vsi obstoje i zastopi znotraj obmo ne enote. Ta dimenzija je velika. • Status zavarovalca je v Zavarovalnici zaradi na ina poslovanja pomemben in pove, ali je sklenitelj pravna oz. fizi na oseba ali samostojni obrtnik. S to dimenzijo omogo imo analize po sektorjih prodaje. Na drugem nivoju je zaloga vrednosti fizi na oseba, pravna oseba, samostojni podjetnik. • Izvor je specifi na dimenzija, ki pove, iz katerega od obsežnih zavarovalniških projektov (zasebni sektor ali pravni sektor) in iz katerih procesov (sklepanje ali škodni oddelek) je prišla enota mere. To je majhna dimenzija s tremi nivoji. Zaloga vrednosti na drugem nivoju je: PNZ-FO (zasebni sektor), PNZ-PO (pravni sektor), RAZNO ter na tretjem nivoju: obra unano, akontirano, likvidirane škode. Med temi dimenzijami so povezave redkejše (sparse), saj se zastopanost posami nega dogodka, sklenitve zavarovanja ne pojavlja ob vsakem asu na vsaki lokaciji po vsaki prodajni poti. Podobno je s škodnimi primeri. Sledi opis korakov pisanja navodil za oblikovanje dimenzije in polnjenje le te s podatki. Opisali bomo postavitev ene dimenzije. Za ostale bomo podali samo najpomembnejše podatke in ukaze. Zna ilnost tega programskega orodja je, da najprej opišemo pravilo za polnjenje podatkov v dimenzijo. To je navadno SQL ukaz za branje iz skladiš a podatkov. Ko prvi izvedemo SQL ukaz, na osnovi prikazanih podatkov natan no oblikujemo dimenzijo, njene nivoje in obliko prikaza podatkov v njej. Ko so vsi ti postopki gotovi in potrjeni – verificirani, shranimo datoteko pravil. S tem je dolo ena dimenzija kocke. Na seznamu pod kocko PRODAJA izberemo 'rules files' – datoteke pravil. Odpre se okno 'Data Prep Editor' – okolje za oblikovanje dimenzij (slika 17). Pripravili bomo pravilo za dimenzijo izvor. V oknu 'File' izberemo 'Open SQL'. V oknu za vnos SQL ukazov izberemo odgovarjajo o bazo/skladiš e podatkov – DWCILJ. Sedaj imamo odprto prazno okno za vnos SQL ukazov z vpisanimi osnovami sintakse SQL-a, to je SELECT, FROM in WHERE. Vpišemo manjkajo e podatke.. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 31 od 63.

Univerza v Mariboru - Fakulteta za organizacijske vede. Diplomsko delo univerzitetnega študija. Slika 17: Pisanje pravil za dimenzijo – osnovni ekran Vpišemo SQL za pristop do dimenzijske tabele DIM_IZVOR (slika 18): SELECT distinct izvor, naziv_izvora, vrsta, naziv_vrste FROM dim_izvor WHERE 1=1 order by izvor,vrsta;. Slika 18: Dimenzija izvor – SQL ukaz Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP. stran 32 od 63.