Microsoft Word - Perc_Kristof_diploma_univ.doc

Transkripcija

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

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

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

4 POVZETEK V diplomskem delu je na kratko opisano skladiše podatkov v zavarovalnici Triglav, njegovo nartovanje, oblikovanje in izgradnja ter razvoj OLAP aplikacije kot raunalniške rešitve izbranega problema. Podan je opis osnovnih pojmov, ki jih sreujemo pri delu s to tehnologijo. Raunalniš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 raunalniške rešitve diplomska naloga poda oceno uporabljenih orodij za razvoj v prihodnosti s to moderno informacijsko tehnologijo. KLJUNE 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

5 KAZALO 1 Uvod Predstavitev problema Predstavitev okolja Cilji Metode dela Skladiše podatkov in OLAP Uvod Skladiše podatkov Vedimenzionalne kocke olap Priprava poroil Razvoj skladiša podatkov za Službo trženja Razvoj modela podatkov Polnjenje skladiša podatkov Uporaba Razvoj kocke OLAP za službo trženja Uvod Razvoj vedimenzionalne kocke OLAP Testiranje Uporaba Pregledi in poroila za službo trženja Uvod Hyperion Analyzer Essbase excel Ocena okolja, postopkov in orodij Zakljuek Literatura in viri...51

6 1 UVOD 1.1 PREDSTAVITEV PROBLEMA Informacija arobna beseda povezana ne le z raunalništvom in informatiko, pa pa z vsemi vejami in nivoji odloanja 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 odloitve vodstva podjetja o prietku izgradnje novejšega in modernejšega informacijskega sistema, ki po zakljuku 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 priakovanja strank še veja. Potrebne so spremembe pri obstojeih 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 obstojeih 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 natannih analitinih pregledih, ki bi jim pomagali pri pripravi prodajnih akcij in pri razvoju novih programov zavarovanj. e bi bilo možno, bi želeli sami uporabljati raunalniško rešitev tako, da ne bi bili preve odvisni od sektorja informatike. V preteklih nekaj letih je Zavarovalnica Triglav postopoma zaela uporabljati novejšo informacijsko tehnologijo pri razvoju novih raunalniških rešitev. Omenim naj predvsem spletno programiranje (JAVA) in široko uporabo izvedenih rešitev, ki so omogoale 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 odloilo za poskusni razvoj manjšega skladiša podatkov in razvoja manjše OLAP kocke. Za pristop do podatkov bi konni uporabniki uporabljali on-line generator poroil. S ponujeno možnostjo so se v službi trženja strinjali. Razvili smo prvo aplikacijo v OLAP tehnologiji. Za izpolnjevanje doloenih 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

7 službi trženja so se hitro navadili na informacije iz OLAP-a. Pripravljali so tudi poroila 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 raunalniško rešitev na zaetku ni bilo interesa v vodstvih preostalih obmonih enot. V tem trenutku obstaja ideja za širjenje uporabe skladiša podatkov, OLPA-a in generatorja poroil. V letu 2005 je prišla zahteva po obsežni raunalniš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 veje aktivnosti pri prodaji na doloenem podroju Slovenije ali pri doloenih vrstah zavarovanj. Iskali bodo podatke o prodaji zavarovanj v premoženjskem sektorju v doloenem obdobju, na doloenem 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 razlinih kriterijih za kratkorono in srednjerono odloanje in planiranje. Podatki morajo biti analitini in hitro pristopni. Z analitinimi podatki bodo delali uporabniki sami; jih razporejali, doloali parametre, oblikovali in pripravljali poroila. 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 analitinih podatkov (OLAP) in orodjem za prikaz podatkov (generatorjem poroil, na primer Hyperion Analyzer) je celotna raunalniška rešitev zelo uporabna. Izkazala se je za uinkovito v primeru doloenih zahtev. Vodstvo sektorja informatike se je zato odloilo, da se pri reševanju zahtevka uporabi tehnologijo OLAP. 1.2 PREDSTAVITEV OKOLJA Zavarovalnica Triglav, d.d. je najveja 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 Zavarovalnica Triglav ima razvejano lastno poslovno mrežo, preko katere posluje. Organizirana je v dvanajstih obmonih enotah, od katerih vsaka obmona enota s svojim delovanjem pokriva doloeno obmoje. V okviru obmonih enot obstaja mreža poslovnih enot, predstavništev, zastopstev in agencij, ki poslujejo v posameznih krajih ali obinah. Takšna poslovna mreža zagotavlja, da je zavarovalna storitev v najveji meri približana zavarovancem tako ob sklepanju zavarovanj, kot ob nastanku morebitnih škod. Realizacija zavarovalne premije po organizacijskih enotah je razlina, obenem pa je odsev gospodarskih, finannih 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 uinkovito 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

8 vsaj del bremen prenesejo na zavarovalnico, ki s svojo strokovnostjo ter trdnim finannim zaledjem zagotavlja resnino 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 veji 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 tehninih pregledov motornih vozil, mejni prehodi, turistine agencije, banke in podobne ustanove. Zavarovalnica Triglav ohranja svoj tržni položaj oziroma ga na doloenih podrojih celo poveuje. 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, tehninih, družboslovnih, naravoslovno-matematinih, informacijskih in drugih ved. Centrala doloa in predpisuje postopke, ki se izvajajo na vseh dvanajstih obmonih enotah. Na Centrali se pripravlja strategija razvoja in poslovanja za Zavarovalnico Triglav. Podroje za informatiko V Centrali Zavarovalnice Triglav deluje sektor informatike, kjer razvijamo in vzdržujemo razline 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 raunalniške rešitve za sisteme premoženjskih zavarovanj pravnih in fizinih 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

9 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. Konno je obveljala ideja o kombinaciji lastnega razvoja z nakupom doloene 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 zaetku ni zaživela, saj uporabniki nekaj asa niso zmogli miselnega preskoka, ki ga morajo narediti za razumevanje kock OLAP in zelo enostavnega generatorja poroil Hyperion Analyzer. Vendar se je tudi to spremenilo. 1.3 CILJI V sektorju informatike moramo pregledati obstojee strukture podatkov. Na osnovi njih bomo pripravili model podatkov za skladiše podatkov. Doloiti moramo dimenzije OLAP kock, pri emer je potrebno upoštevati zmogljivosti strojne in programske raunalniš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 nauili. Vendar je prišlo tudi do namestitve novejših verzij programskih orodij, s katerimi v Sloveniji še ni nihe delal. Moj namen je prikazati razvoj nove aplikacije na teh orodjih v im krajšem asu. Istoasno bi rad vodstvu Zavarovalnice Triglav, d.d. prikazal možnosti razvoja s temi orodji in uporabnost le teh za pripravo še boljših raunalniških rešitev in strateških informacij. Cena teh orodij ni majhna in, e niso v celoti izkorišena, podjetje izgublja veliko konkurenno prednost, ki jo ima z dobrim informacijskim sistemom. Rezultat diplomske naloge bo kratek splošen opis skladiša podatkov in tehnologije OLAP ter praktien 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 znailnosti te objektne tehnologije. Pokazal bom tudi uporabo orodja Hyperion Analyzer za pripravo poroil 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 veletnem 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

10 Pred pripravo diplomske naloge sem preštudiral veliko gradiva za informacijske predmete študija informatike na Fakulteti za organizacijske vede, nekaj lankov v revijah z raunalniš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 teoretinega vidika, v nadaljevanju naloge pa opisal konkretne rešitve pri razvoju podatkovnega skladiša in kock OLAP ter pripravo poroil. V diplomski nalogi sem moral paziti na poslovno tajnost in zaupnost podatkov. Zato so doloeni podatki prikazani drugae od resninih, so zbrisani ali zakriti. Pri pisanju naloge sem uporabil domao in tujo strokovno literaturo, predvsem pa lastne izkušnje in znanja na tem podroju. Preden nadaljujem želim zaradi specifine 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 tono doloeno vrsto vozila s tono doloeno mojo motorja itd.; to je osnovna enota, najmanjši delek, ki se lahko zavaruje; to je najbolj natanno doloeno zavarovanje; zavarovalna podvrsta je skupina takšnih osnovnih, sorodnih zavarovanj, npr. vsa kasko zavarovanja osebnih motornih vozil; zavarovalna premija je znesek, ki ga zavarovanec plaa za doloeno zavarovanje; zavarovalna vsota je znesek, za katerega je doloen 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 doloenega rizika in je pogosto tudi zavarovanec; zavarovanec ali zavarovalec je lahko fizina ali pravna oseba ali samostojni podjetnik; zastopnik je delavec Zavarovalnice Triglav, ki na terenu ali v pisarni sklepa zavarovanja; zastop je obmoje, 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, nesree, 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

11 2 SKLADIŠE PODATKOV IN OLAP 2.1 UVOD Skladiše podatkov je nadgradnja v podjetju obstojeih podatkovnih sistemov od relacijskih baz podatkov do drugih datotenih sistemov. V skladiše podatkov prenesemo del ali vse operativne podatke, ki so lahko zelo razlini 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 vedimenzionalne 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 analitinem nivoju. 2.2 SKLADIŠE PODATKOV Koncept podatkovnega skladiša je prvi predstavil W.H.Inmon v zaetku 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 odloitvam.«inmonova definicija je najpomembnejša (v svoji literaturi o podatkovnih skladiših jo uporablja veina avtorjev) in našteva poglavitne znailnosti podatkovnega skladiša, ki jih bom podrobneje opisal kasneje. Ralph Kimball, ustanovitelj podjetja Red Brick Systems, je podatkovno skladiše oznail 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: Loeni od ostalih transakcijskih sistemov v podjetju in sestavljeni iz podatkov iz teh sistemov. Loenost od podatkov v transakcijskih sistemih je pomembna, ker s tem zagotovimo nemoteno obdelavo transakcij tudi ob zelo zahtevnih poizvedbah, ki bi sicer lahko upoasnile izvajanje transakcijskih aplikacij. Namenjeni izkljuno za povpraševanja poslovnih uporabnikov. Namen tako zbranih podatkov je torej podpora poslovnem odloanju. Dostopni uporabnikom, ki imajo omejeno znanje o raunalniš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 odloitvah, 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

12 Berry Devlin (1997) opisuje podatkovno skladiše kot»enotno, popolno in konsistentno shrambo podatkov, pridobljenih iz razlinih virov in ponujenih konnim uporabnikom na nain, ki ga razumejo in uporabljajo v poslovnem svetu«. Definicija poudarja enotnost podatkovnega skladiša, ki omogoa, da uporabniki razpolagajo z "eno samo resnico" o poslovanju. Popolnost in konsistentnost podatkov zagotavljata kvalitetne podatke, ki so tudi temelj kvalitetnih poslovnih odloitev. 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. Specifini namen podatkovnega skladiša je podpora poslovnim odloitvam, 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 odloitve. 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 poroil, sprotno analizo podatkov, lahko pa tudi osnovo za analitine aplikacije in implementacije metod za odkrivanje znanj iz podatkov. Skladiše podatkov omogoa, da se podatki razlinih sistemov združijo v enotno zbirko podatkov, se obravnavajo na enoten nain in so dostopni vsem pooblašenim uporabnikom. Hranijo se lahko tudi zgodovinski podatki zaradi pregleda po asovnih vrstah, esar transakcijski sistemi obiajno ne omogoajo. V skladiše podatkov je mogoe 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 izloi te, ki so uporabni in pripravni za prenos na zaasno podroje. V tem koraku se pripravi veliko koliino podatkov. V drugi fazi se podatke pregleda, preisti in izloi 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 doloene mere se lahko podatke združi v tistih sistemih, kjer se pripravlja specialno skladiše za ve dimenzijske analize. S tem se koliina podatkov zelo zmanjša. Zaradi zmanjšane koliine podatkov in združevanja je priprava poroil 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 nain, ki omogoa uporabnikom preprosto izdelavo poroil in analiz podatkov, saj so podatki shranjeni v obliki dimenzij in mer. Zaradi tega je njihovo delo uinkovitejše, saj si sami izdelajo poroila, kadar jih potrebujejo in jim ni treba akati, da jim ga izdela kdo drug. Praviloma je priprava takega poroila temeljeega 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

13 tudi hitrejša od priprave poroila na klasien nain z raunalniš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 odloili kakšna bo arhitektura in emu bo služilo. Tako loimo 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 podroja podjetja in je namenjeno širokemu krogu uporabnikov. Specializirano ali podrono skladiše podatkov (data mart) je namenjeno uporabi v ozko doloenem poslovnem podroju ali doloeni skupini uporabnikov. Za takšno specializirano skladiše podatkov so podatki posebej izbrani in prirejeni iz celovitega skladiša podatkov. Možno se je odloiti tekom priprave in razvoja skladiša podatkov, da gradimo le to za doloene uporabnike. Vendar je to redek primer, ker je uporabnost omejena, kasneje pa je skoraj nemogoe 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 poroila, drugi pa bi potrebovali zahtevnejša orodja. Za takšne primere so uporabni generatorji poroil za ad-hoc poroanje in analize OLAP. Nadalje obstajajo orodja za izvajanje statistike, rudarjenje po podatkih in vizualizacije, ki omogoajo pregled in prikaz podatkov na mnogo razlinih nainov 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

14 potrebna orodja za poslovno poroanje v smislu dostave ažurnih poroil izbranim prejemnikom, mnogo razsežnostne analize ali alarmiranja v primeru preseženih vnaprej doloenih vrednosti kazalnikov. Slika 2: Možnost izkorišanja skladiša podatkov (vir SRC.SI) Seveda obstajajo še naprednejše analitine programske rešitve, ki v splošnem omogoajo pregled kljunih kazalnikov poslovanja podjetja v raznih oblikah. Ta orodja nudijo dobre rezultate pri odkrivanju znanj iz podatkov. Osnovni namen poslovnega obvešanja je omogoiti uporabnikom preprost in hiter dostop do poslovnih informacij. Obiajno 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, poveati dobikonosnost, 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 znailnosti in razlike obeh sistemov sledee: Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 10 od 63

15 Transakcijski sistemi Obdelava transakcij. Trenutni podatki, malo ali ni zgodovine Zelo podrobni podatki transakcij. Hitro vpisovanje podatkov. Možnost vpogleda v podatke posameznega poslovnega podroja. Poroila so pripravljena vnaprej. Obiajno ni možnosti preproste izdelave lastnih poroil, ampak jih je potrebno programirati. Poslovno obvešanje Vpogled v poslovanje, spremljanje uspešnosti in uresnievanje strateških ciljev. Zgodovinski podatki, možnosti primerjave po letih oziroma preteklih obdobjih. Podatki so združeni, delno sešteti in vnaprej izraunani. Hitre poizvedbe. Možnost vpogleda v podatke vseh poslovnih podroij, ki so zajeti. Možnost izdelave lastnih poroil in adhoc poizvedb je skoraj neomejena. Tabela 1: Primerjava trans. sistema posl. obvešanje (vir M. Ferle) 2.3 VEDIMENZIONALNE KOCKE OLAP Izraz OLAP (On-Line Analytical Processing) je leta 1993 uvedel E. F. Codd, ki velja za oeta relacijske podatkovne baze. Ugotovil je, da relacijske podatkovne zbirke za transakcijske sisteme ne izpolnjujejo potreb po podatkih za podporo odloanju. Predstavil je 12 pravil OLAP (kasneje razširjenih na 18), pri emer je predvidel, da so podatki v obliki vedimenzijske kocke, ne pa v relacijski obliki (1993). Codd kasneje ni ve nadaljeval nikakršnih raziskav na tem podroju, njegova pravila pa se danes ne upoštevajo ve, ker so nekatera med njimi zavirala razvoj tehnologije. Pendse navaja nekaj kljunih lastnosti, ki naj bi jih orodja OLAP imela. Omogoati morajo (1998) konstantno hiter dostop uporabnikov do podatkov (veina poizvedb naj bi bila izvedena v manj kot petih sekundah), analitine zmogljivosti (osnovne numerine in statistine analize) in podpirati veuporabniško okolje. Kljuna lastnost tehnologije je vedimenzijski (multidimensional) konceptualni pogled na podatke. OLAP je eno izmed kljunih orodij pri uporabi podatkovnih skladiš za podporo odloanju. Codd ga je predstavil skupaj z vedimenzijsko podatkovno zbirko, vendar je izraz postal uporaben tako za dimenzijske kot tudi relacijske predstavitve vedimenzijskih podatkov. Orodja OLAP omogoajo vedimenzijske 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 obraanje kocke«(slice and dice), pri katerem uporabniki lahko pogledajo podatke iz razlinih perspektiv in»vrtanje navzdol, navzgor in poez«(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

16 podatke navzdol (ve podrobnosti), navzgor (agregacija) in poez (drugi podatki na isti ravni podrobnosti). Slika 3: Potek priprave podatkov za kocko (vir Hyperion) OLAP analitine rešitve so namenjene vodstvenim delavcem in analitikom za podporo odloanja. Podpirajo hitre analize velikih koliin podatkov, ki so strukturirani in vedimenzionalno organizirani. Podatke za daljša asovna obdobja je možno analizirati s sekundnimi odzivnimi asi. Pri gradnji OLAP analitinih 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 POROIL Pravilno in uspešno zgrajeno podatkovno skladiše in razne nadgradnje v smislu programskih rešitev za analize poslovanja so ogromna pomo pri odloanju. Vendar moramo do teh podatkov priti na enostaven in hiter nain, poleg tega pa moramo imeti še dodatne možnosti za predstavitve in dodatne kalkulacije. Temu služi programska oprema za pripravo poroil generatorji poroil. 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 omogoajo tako imenovane ad hoc poizvedbe po podatkih iz podatkovne zbirke. Pri tem predstavljajo vmesnik med uporabniško poizvedbo po doloenih podatkih in podatkovno zbirko, kjer so želeni podatki shranjeni. Posamezna orodja se razlikujejo glede na stopnjo prijaznosti uporabniškega vmesnika oz. stopnjo raunalniškega znanja, ki ga uporabnik potrebuje za dostop do podatkov. Tako je pri nekaterih poizvedbenih orodjih nujno poznavanje poizvedbenega raunalniškega Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 12 od 63

17 jezika (npr. SQL), pri drugih se poizvedbe oblikujejo s pomojo grafinega vmesnika, pri tretjih v obliki posplošenega stavka v angleškem jeziku, ipd. Poizvedbena orodja pogosto omogoajo tudi doloeno stopnjo formatiranja predstavitve podatkov oz. izdelavo poroil, kar jih uvrša med orodja za poizvedbe in poroila. Koncept podatkovnega skladiša omogoa precej prednosti za orodja za poizvedbe in poroila. V podatkovnem skladišu so podatki za poizvedbe na enem samem mestu, oišeni in med seboj konsistentni. Uporabniki tako pridejo lažje do njih, podatki so tudi kvalitetnejši. Ker so podatki izloeni iz transakcijskih sistemov, odpade nevarnost, da bi na primer kompleksna SQL poizvedba ogrožala (povzroila upoasnitev 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 poroila in preglede, ki jih predvsem v vodstvu poslovnih enot ali podjetja in drugi naroniki vidijo. Omogoati morajo takšen prikaz podatkov, ki jasno, nedvoumno in hitro prikaže poslovne rezultate potrebne za odloanje (slika 4). Poleg tega mora biti omogoena prilagodljivost razlinim uporabnikom rezultatov in avtomatino osveževanje ob spremembah osnovnih podatkov. Slika 4: Razline možnosti poroil Dobro je, e so podatki iz poroil dovolj fleksibilni, da jih je možno prenesti v druga analitina 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 vasih potreben pogoj za dobra poroila o poslovanju podjetja. Ve o pripravi poroil bomo pisali v poglavju 5. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 13 od 63

18 3 RAZVOJ SKLADIŠA PODATKOV ZA SLUŽBO TRŽENJA 3.1 RAZVOJ MODELA PODATKOV Pri predstavitvi podatkov v podatkovnem skladišu ima kljuno vlogo podatkovni model. Na tem podroju se najpogosteje uporabljata dva pristopa: entitetno (Entity - Relationship modeling) in dimenzijsko (Dimensional modeling) modeliranje, ki ga ponekod v strokovni literaturi imenujejo tudi vedimenzijsko modeliranje (Multidimensional modeling). Podatkovni model ima v okolju podatkovnega skladiša velik pomen, ker omogoa predstavitev podatkov uporabnikom, služi kot nart podatkovnega skladiša in omogoa konsolidacijo podatkov iz razlinih izvorov in poslovnih podroij. 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 veinoma uporablja entitetno modeliranje. Pri tem se pogosto uporablja izraz OLTP (On-Line Transactional Processing) modeliranje. Pri praktini pripravi podatkovnega modela za skladiše podatkov bomo poleg na zahteve uporabnikov morali paziti tudi na znailnosti skladiša podatkov zaradi kasnejšega dograjevanja, e bi do tega prišlo. Znailnosti 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 podroij podjetja, kot so na primer zavarovanje in nain prodaje le teh. Integriranost skladiša podatkov ni dosežena s preprostim kopiranjem podatkov iz transakcijskega okolja. Podatke, ki so na razlinih lokacijah v podjetju in so pogosto nekonsistentni, bomo pri prenosu v skladiše podatkov, to je med ETL procesom, uredili in preistili tako, kot to priakujejo uporabniki. Podatki bodo morali biti asovno obstojni zato, ker jih preiš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 loujemo 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

19 ravnjo zrnatosti lahko odgovorimo na praktino vsako poizvedbo, z visoko ravnjo zrnatosti pa je število poizvedb, ki jih lahko uporabimo, omejeno. Seveda pa nizka raven zrnatosti pomeni zelo velike koliine podatkov in dolge ase izvajanja poizvedb. Uporabniki ponavadi želijo uinkovitost pri shranjevanju in dostopu do podatkov in možnost podrobnih poizvedb. To je mogoe dosei 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 obstojeo manjšo OLAP aplikacijo so bila priakovanja naronika in konnih uporabnikov za novo raunalniš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 priakovan še razvoj OLAP aplikacije. Definicija dimenzij in tabel dejstev V uspešnem sodelovanju z naronikom smo pripravili model podatkov, ki bo ustrezal izpolnitvi zahtev. Konna 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 obstojeih zavarovanj in na razvoj novih zavarovanj. Zahtevani podatki v konni 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 fizina oseba, lokacija, ki je geografska komponenta, prodajna pot ali nain prodaje zavarovanja, naša storitev, sklenjeno zavarovanje ali obravnavan škodni primer in as oz. datum dogodka. To je hkrati že grob opis bodoih dimenzij in enot mere. Dimenzija datum bo vsebovala potrebne podatke o datumih sklenjenega zavarovanja ali prijavi škodnega primera. Podatki o statusu zavarovalca (pravna/fizina 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

20 je o nainu 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 obmoni enoti ali pa tudi ožje, o zastopu znotraj obmone enote. Ko imamo dimenzije doloene, 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 loijo najprej po tem ali obravnavamo škodni primer ali sklenjeno zavarovanje, torej po izvoru. Pri sklepanju zavarovanj loimo spet dva procesa glede na status zavarovalca, ki je lahko pravna oseba ali fizina oseba. Slika 5: Diagrama tabel dejstev za prodajo zavarovanj in škode Tabela dejstev za sklenjena zavarovanja za fizine osebe Tabela dejstev za sklenjena zavarovanja za pravne osebe Tabela dejstev za škodne primere Datum K Datum K Datum K Izvor K Izvor K Izvor K Status zavarovalca K Status zavarovalca K Status zavarovalca K Prodajna pot K Prodajna pot K Prodajna pot K Lokacija K Lokacija K Lokacija K Zavarovanje K Zavarovanje K Zavarovanje K Premija Premija Znesek škode Zavarovalna vsota Zavarovalna vsota Število zavarovanj Število zavarovanj Tabela 2: Tabele dejstev Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 16 od 63

21 Definirali bomo tri tabele dejstev: OLAPA za sklenjena zavarovanja fizinih 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 fizine osebe sta enaki in zato je ta tabela dejstev prikazana samo enkrat. V podrobnem nartu tabele dejstev, ki je v tabeli 2 je popoln seznam vseh dejstev tabele dejstev. Vsebuje dejstva iz fizine tabele. Kljui dimenzij so oznaeni s K. Po definiranju dimenzijskih tabel dobimo model podatkov prikazan na sliki 6. Slika 6: Model podatkov brez entitet 3.2 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 omogoa 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

22 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 drugaen 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 analitina orodja v rokah konnih uporabnikov, s katerimi opravljajo analize in pripravljajo poroila 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 poroila 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. Obasno pridejo tudi bolj kompleksne zahteve po podatkih oz. poroilih, ki jih na drug nain 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

23 Še najve pa uporabljamo skladiše podatkov za pripravo OLAP kock. Zaradi možnosti, ki jih nudijo takšna analitina orodja, kot je OLAP, smo pripravili opisano skladiše podatkov. Kot pri nobeni drugi raunalniš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 mogoe druganih 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 odloanju. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 19 od 63

24 4 RAZVOJ KOCKE OLAP ZA SLUŽBO TRŽENJA 4.1 UVOD V podjetju Zavarovalnica Triglav, d.d. smo o tehnologiji OLAP zaeli 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 doloen 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 ronih nastavitev za vsako funkcijo razvoja posebej. To je zelo otežilo delo, saj smo se med razvojem prve OLAP kocke še uili in spoznavali z orodjem. V Sloveniji praktino 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 VEDIMENZIONALNE KOCKE OLAP Sedaj razvijamo OLAP aplikacije z orodji zadnje verzije. Razvoj je uinkovitejš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 v 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

25 IBM WebSphere Application server v5.1 (WAS) in IBM HTTP Server v sta zašitna znamka IBM korporacije. Predstavljata tako imenovano 'middleware software' kategorijo za gradnjo aplikacij in delo z njimi na razlinih platformah na svetovnem spletu. WAS omogoa uporabo že obstojeih 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 omogoa veliko boljši, enostavnejši ter hitrejši razvoj. Kar se tie zahtev po pomnilniku, je nova verzija neprimerno bolj prijazna in bolj prilagodljiva strojnemu okolju. Prej je obstajal samo en nain kalkulacije in s tem stroga doloitev 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 konnega 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 analitinih 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 nartovanjem kocke, definiranjem in pisanjem pravil doloanja posaminih dimenzij ter pripravo pravil za polnjenje in raunanje kocke. OLAP kocke razvijam z orodjem Essbase Administration Services (EAS). Orodje je moderno in napredno in razvijalcu omogoa, da sorazmerno hitro razvije novo kocko. EAS pomaga na vsaki stopnji razvoja. Veino 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 konani 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 praktinem razvoju OLAP aplikacije v našem podjetju. Velikokrat bom moral uporabiti angleški strokovni izraz, ker vasih ni mogoe pravilno logino prevesti doloenih raunalniš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

26 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 plaljiva 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 naina. Vsak nain ima svoje prednosti in slabosti. Uporaba prvega - block storage pomeni, da je potrebno za kocko izraunati vse možne kombinacije med dimenzijami in pripraviti prostor za rezultate kartezinega produkta teh kombinacij tudi, e je izraun vrednosti neke kombinacije enak ni. V tem primeru se rauna kombinacije za vse nivoje hierarhij vsake dimenzije. To pomeni porabo ogromne koliine 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 dinaminih izraunov. Prednost take aplikacije pa je ravno v stalno izraunanih vseh kombinacijah. Torej je priprava kakršnegakoli poroila vedno hitra. Drugi nain razvoja aplikacije z uporabo združenega pomnilnika - aggregate storage pomeni, da bo porabljeno najmanj pomnilnika, kot je mogoe. Dodatna kalkulacija ni Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 22 od 63

27 potrebna. Ob polnjenju dimenzij in podatkov se zelo hitro izvrši izraun samo na najvišjih nivojih hierarhij, kar pomeni malo porabljenega pomnilnika (3 GB) za eno OLAP kocko. Slabost tega je, da je pri pripravi poroil, ki zahtevajo rezultate na nižjih nivojih potrebno poakati nekaj sekund ali celo minut, da se takrat dinamino izvrši izraun. Razvijalec ali kasneje vzdrževalec aplikacije lahko po potrebi pripravi ukaze za dodatne kalkulacije ob polnjenju podatkov in s tem izboljša as priprave poroil. V nainu združenega spomina se vrednosti, katerih rezultat bi bil ni, ne rauna in se s tem tudi ne obremenjuje spomina. Slika 9: Kreiranje nove aplikacije Kako hitro bo kocka izraunana 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 doloimo. Napano oznaena dimenzija lahko zelo poslabša ali celo preprei raunanje 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

28 da v primeru, ko imamo bolj gosto kocko, izberemo block storage option (BSO) nain, e prevladujejo redke dimenzije, pa aggregate storage option (ASO) nain. Na koncu vpliva na izbiro vrste aplikacije še uporaba formul pri kalkulaciji. V ASO aplikaciji so dovoljene samo formule z osnovnimi matematinimi 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 nain BSO. Pri uporabi formul v enotah mere navadno raunamo 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 raunajo direktno iz osnovnih podatkov, pa pa so rezultat uporabe formul pri izraunih 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 odloitev o uporabi doloene metode ni. Najbolj se lahko zanesemo na izkušnje. Drugi najpomembnejši faktor so potrebe in zahteve konnega uporabnika. V predhodnih verzijah tega orodja - Essbase Administration Services pa je obstajal samo BSO nain definiranje aplikacije. V našem primeru smo se odloil 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: Doloitev lastnosti aplikacije Takoj po kreiranju aplikacije doloimo njene lastnosti (slika 10). Sem spadajo razne osnovne nastavitve za konne uporabnike (dovoljenje za delo z aplikacijo) in varnostne nastavitve. Vse to dosežemo z enostavnim oznaevanjem. Poleg tega Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 24 od 63

29 doloimo podroje (tudi velikost), kjer bodo spravljeni podatki za to aplikacijo in zaasno podroje, 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 naeloma lahko tvorimo ve kock, vendar to ni priporoljivo. 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 naronik raunalniške rešitve in funkcija OLAP kocke. Ime kocke se lahko za razliko od imena aplikacije ponavlja v razlinih 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

30 Po definiciji kocke se prikažejo ostale možnosti. Lastnosti kocke nas tokrat ne zanimajo, zato se lotimo narta (outline), kjer bomo v grobem definirali enote mere in dimenzije kocke. Že med izgradnjo skladiša podatkov smo s službo trženja doloili okvirno strukturo nove kocke, torej podatke, ki jih želijo dobiti iz tokratne raunalniš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 narta kocke in preverimo avtomatsko nastavljene parametre ter jih po potrebi spremenimo. Slika 12: Lastnosti narta kocke Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 26 od 63

31 Na zavihku outline vnesemo osnovne podatke o enotah mer in dimenzijah. To omogoimo z gumbom za dodajanje otrok na nart ali v izbrano pozicijo (Add a child to the selected member), kar vidimo na sliki 13 v levem ekranu. V Outline editorju obstajata dva naina dodajanja lanov narta kocke. En nain je že omenjeno dodajanje otrok na naslednji nižji nivo oznaenega 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 oznaen lan. lan narta je vsaka postavka na nartu kocke, ne glede na nivo na katerem se nahaja. Osnovne lane, to so lani na najvišjem prvem nivoju vedno vpišemo rono. Vsi ostali lani se pojavijo na nartu po polnjenju posamezne dimenzije kocke. Izjema so enote mere, kjer vpišemo lana z imenom enote mere in vse otroke - lane enot mer rono. Slika 13: Vpis narta 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 oznaimo lana enote mere in z gumbom za dodajanje otrok omogoimo 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

32 Na sliki 14 so oznaene vse lastnosti, ki jih lahko doloimo dimenzijam. Bistvena lastnost za enote mere je raunanje 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 oznaimo pri enotah mer, nikoli pa na prvem, najvišjem nivoju ostalih lanov narta. Ta lastnost nima vpliva v ASO aplikaciji. V BSO aplikaciji omogoi manjši porabljeni spominski prostor, vendar daljši as priprave poroil zaradi takrat izvedene dinamine kalkulacije. Slika 14: Lastnosti dimenzij (prvi) Vse ostale dimenzije (razen enote mere) so avtomatino oznaene 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 dinamino izraunajo ob kreiranju poroila. 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 doloimo le, e je hibriden celoten nart (outline). Drugae je ta možnost izkljuena. Podatke za hibridno dimenzijo delno izraunamo 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

33 Po doloitvi lastnosti dimenzij moramo natanneje definirati še lastnosti enot mer (slika 15). Essbase Administration Server nam v koraku gradnje narta kocke daje veliko razlinih možnosti za doloitev lastnosti enot mer. V našem primeru doloimo za vse enote mere, da se izloijo iz združevanja in medsebojnega seštevanja exclude from consolidation. To pomeni, da se med raunanjem 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 razline kategorije podatkov in veliko povedo v medsebojni primerjavi. Druge lastnosti, ki jih lahko pripišemo enotam mer v primeru, da se ne odloimo za možnost izloitve iz konsolidacije so konsolidacija s seštevanjem, odštevanjem, množenjem in deljenjem ali pa se pri konsolidaciji uporablja procentni raun. Tako dobimo že pripravljene razline rezultate. Slika 15: Lastnosti dimenzij (drugi) Preden nadaljujemo preverimo pravilnost vpisanih podatkov, postopkov in pravil z verificiranjem (gumb verify) ter shranimo nart kocke. S tem imamo narejen osnovni nart (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

34 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. Natanno definicijo posamezne dimenzije bomo doloili pri vpisu pravil za polnjenje dimenzij s podatki. Priprava pravil in dimenzij as je pri veini 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. Mogoe je izkljuena kakšna nedelja ali praznini dan. V tej dimenziji je dan zelo pomemben nivo pogledov in poroil. Višji nivo je lahko teden ali mesec, še višji trimeseje ali polletje in najvišji leto. Seveda bi lahko bil v doloenih 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

35 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 posamino zavarovalno podvrsto spada tudi ez tiso zavarovalnih enot. Prodajna pot je nain prodaje zavarovanj, npr. preko zastopnikov ali agencij skupaj ali za posameznega delavca. Dimenzija ima tri nivoje z enajstimi razlinimi 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 veja geografska podroja. Podatki se obravnavajo združeni za celotno obmono enoto ali zastop. Vsebuje tri nivoje. Na drugem je zaloga vrednosti trinajst obmonih enot. Na naslednjem nivoju so vpisani vsi obstojei zastopi znotraj obmone enote. Ta dimenzija je velika. Status zavarovalca je v Zavarovalnici zaradi naina poslovanja pomemben in pove, ali je sklenitelj pravna oz. fizina oseba ali samostojni obrtnik. S to dimenzijo omogoimo analize po sektorjih prodaje. Na drugem nivoju je zaloga vrednosti fizina oseba, pravna oseba, samostojni podjetnik. Izvor je specifina 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: obraunano, akontirano, likvidirane škode. Med temi dimenzijami so povezave redkejše (sparse), saj se zastopanost posaminega 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. Znailnost 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 natanno 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 doloena 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 odgovarjajoo 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 manjkajoe podatke. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 31 od 63

36 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

37 e bi kocka že delovala, bi v primeru popravljanja SQL ukaza spremembe shranili z gumbom OK/Save. Sprememba bi bila upoštevana ob naslednjem polnjenju dimenzije. Ker kreiramo novo dimenzijo, uporabimo gumb OK/Retrieve. Ukaz se izvede in v prej praznih vrsticah in stolpcih v 'Data Prep Editor' oknu se izpišejo prebrani podatki (slika 19): izvor, naziv izvora, vrsta in naziv vrste. Slika 19: Dimenzija izvor - oblikovanje Sedaj dokonno oblikujemo dimenzijo. Najprej pripravimo obliko kakršno želimo imeti na nartu kocke in kakršno bodo videli konni uporabniki pri pripravi poroil. To dosežemo z gumbi za pomikanje (move field), združevanje (join field) in razdruževanje (split field) stolpcev, za kreiranje novih stolpcev z branjem podatkov iz baze (create a field using join) ali z vpisom konstant (create a field using text). To dosežemo tako, da oznaimo stolpce, nad katerimi bomo izvajali omenjene operacije in pritisnemo na ikono. V našem primeru med stolpca izvor in naziv_izvora ter vrsta in naziv_vrste vstavimo novi polji s konstanto ' - ' (create a field using text). Tako imamo šest stolpcev. Prve tri in zadnje tri stolpce združimo z join field (slika 20). Seveda je oblikovanje lahko dosti bolj zahtevno in sestavljeno iz ve korakov. Z obliko smo zadovoljni in lotimo se doloanja lastnosti posameznih stolpcev oz. polj (slika 21). Oznaimo prvi stolpec podatkov in pritisnemo gumb Field properties. Na prvem ekranu (Global Properties slika 21, toka 1) imamo možnost dodati predpono (prefix) ali zapono (sufix). To je kakršnakoli konstanta, s katero želimo nekaj povedati ali nekako oznaiti doloena polja. Na drugem ekranu (Data Load Properties - slika 21, toka 2) je prikazan nart kocke (outline). Izberemo dimenzijo Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 33 od 63

38 izvor, da povežemo podatke in nart. Na tretjem ekranu (Dimension Build Properties - slika 21, toka 3) se odpre vrsta možnosti za definicijo polja, od katerih so najbolj uporabljane: generation, alias, property in formula. Doloiti moramo nosilce ali edinstvene kljue (unique key) za vsak nivo hierarhije. Takšen klju je lahko samo šifra podatka v dimenziji, lahko pa šifra skupaj z nazivom. Na vsakem nivoju v hierarhiji dimenzije moramo imeti kljuni podatek, na katerega bomo ob kalkulaciji kocke vezali vrednosti (enote mere). Temu kljuu moramo doloiti lastnost Generation. Slika 20: Po oblikovanju polj Mi smo šifre in nazive že združili in imamo za dimenzijo izvor samo dve polji za dva nivoja, torej bomo obakrat uporabili lastnost generacija. To naredimo z dvoklikom na Generation, potem gumb next za prehod na naslednje polje in zopet dvoklik Generation. V našem primeru šifra izvora skupaj z nazivom izvora pomenita edinstveni klju v podatkih. Slika 21: Doloanje lastnosti polj Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 34 od 63

39 Z alias oznaimo polje, ki logino spada k šifri,oznaeni z generation. To uporabimo, kadar sama šifra že zadoša pogoju o edinstvenosti kljua, za opis pa dodamo naziv kot alias. e želimo znotraj dimenzije za doloen nivo posebej doloiti nain izrauna vrednosti, to doloimo s property poljem, v katerem oznaimo nain izrauna. Takšna posebna zahteva je lahko med drugim dinamina kalkulacija samo za en nivo ali konsolidacija vrednosti navzgor samo za en nivo. Ta lastnost se ve uporablja pri BSO aplikacijah. Podobno kot lastnost property se uporablja formula, le da v tem primeru v polje vpišemo formulo za doloitev razmerja med dvema sosednjima nivojema hierarhije. Slika 22: Nastavitve podatkov in dimenzij Zakljuili smo z lastnostmi polj (field properties). Preverimo še ostale nastavitve, ki jih Essbase pripravi sam in se upoštevajo pri polnjenju podatkov in izraunu vrednosti enot mer. S klikom na gumb Data source properties (gumb na sliki 19) preverimo nastavitve osnovnih podatkov za zapis v nart dimenzije. Vidimo, kako so med seboj loeni podatki (tabulator, prazni razmak, fiksna širina podatkov, poseben znak). Na naslednjem gumbu nastavitve za polnjenje podatkov (Data load settings) je oznaen odnos do že obstojeih podatkov v kocki (slika 22). Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 35 od 63

40 Doloimo, da naj se obstojee vrednosti zamenja z novimi (najpogostejša izbira), možno pa je vrednosti tudi prišteti ali odšteti. V tem okencu doloimo kombinacije podatkov in vrednosti, katere nikoli ne želimo zapisati v kocko. V okencu nastavitve za gradnjo dimenzij (Dimension build settings) za dimenzijo izvor nastavimo nain razvršanja podatkov, kar se bo videlo na nartu dimenzije, dovolimo premikanje podatkov po nartu in dovolimo umik brisanje starih podatkov iz narta, ki ob ponovnem polnjenju niso ve obstajali v naboru osnovnih podatkov za dimenzijo. Z vgrajeno funkcijo za preverjanje pravilnosti vseh nastavitev in vnosov parametrov ter lastnosti validate (slika 19) se prepriamo o pravilnosti zgrajene dimenzije. Shranimo jo pod imenom izvor. Zdaj izvedemo polnjenje podatkov v dimenzijo. Z desnim gumbom miške kliknemo na kocko PRODAJA znotraj aplikacije PRO_ZT in iz seznama, ki se odpre, izberemo polnjenje podatkov (Load data). Na ukaznem oknu (slika 23), ki se odpre, izpolnimo podatke o strežniku, na katerem so vhodni podatki. Za dimenzijo, ki jo želimo napolniti (npr. izvor) poišemo še datoteko pravil. Slika 23: Polnjenje dimenzije izvor To je roni nain izvajanja ukaza za polnjenje. Po zakljuku kreiranja celotne kocke bomo napisali program za avtomatsko polnjenje celotne kocke naenkrat. Tokrat se dimenzija napolni v sekundi, saj je v dimenzijski tabeli samo šest podatkov. Zgrajeno imamo prvo dimenzijo. Enak postopek smo ponovili za ostale dimenzije, za Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 36 od 63

41 katere je bilo zaradi ve nivojev in veje kompleksnosti ve dela. Pri gradnji asovne dimenzije izstavit smo za nivoje uporabili lastnost property in z njo doloili dinamino kalkulacijo vrednosti povezanih z datumi. V dimenzijah prodajna pot in lokacije ZT uporabljamo pet mestne šifre zastopov in zastopnikov, ki so mnogokrat enake. Ker zaradi takšnega pokrivanja dela podatkov nastanejo težave pri kalkulaciji, saj podatki izpadejo iz izrauna in niso upoštevani, smo pri prodajnih poteh na vseh nivojih dodali predpono 'PP_'. S tem smo dobili potrebno razliko pri šifrah. Tudi polnjenje podatkov v te dimenzije je trajalo le po nekaj sekund. Ta hitrost je dosežena zaradi kvalitetne priprave podatkovnega skladiša in pravilne, zvezdaste strukture modela podatkov za OLAP kocko. Postopek pisanja pravil za pripravo enot mer je rahlo drugaen. SQL ukaz je bolj kompleksen. Za polnjenje vrednosti v enote mere je v SQL potrebno prebrati vse podatke iz dimenzij na najnižjem nivoju in jih povezati z vrednostmi v skladišu podatkov. Izvajanje polnjenja vrednosti traja pri takšni masi podatkov tri do štiri ure. Pri teh asovnih terminih se pozna izrazita prednost ASO aplikacij proti BSO aplikacijam. Pri BSO aplikacijah se po polnjenju podatkov izvaja še kalkulacija, ki je za našo staro kocko trajala okrog dvajset ur. Torej je pri asu obdelav napredek oiten. Pri BSO aplikacijah potrebujemo obutno ve spominskega prostora. Vsi SQL ukazi za polnjenje podatkov in vrednosti so v prilogi 3. Pregled sestave kocke (outline) Kocka PRODAJA je pripravljena. Dimenzije in podatki so napolnjeni. Spremenil se je outline nart kocke. Nart vsebuje vse podatke iz dimenzij, ki so se vsaj enkrat pojavili med poslovanjem zavarovalnice in so s tem zapisani v skladišu podatkov. Sedaj vsebuje tudi podatke o številu vrstic na posamezni stopnji hierarhije dimenzij. Vidimo lahko vse postavke iz dimenzij, ki se pojavljajo v skladišu podatkov. Outline sedaj postane skupek seznamov, iz katerih izbiramo kombinacije za pripravo poroil. Vrednosti v enotah mer na tem ekranu ne vidimo. Do njih pridemo v poroilih preko generatorjev poroil ali Microsoft Excela ali s podobnimi orodji. Vidimo pa število postavk na naslednjem nivoju dimenzij. V nartu kocke ne moremo kombinirati med seboj dimenzij. Ko nart dimenzije odpremo s klikom na '+', dobimo vrednosti na drugem nivoju in število postavk na naslednjem nivoju. Ko je kocka konana in pripravljena skripta ali program za avtomatsko raunanje kocke, redko pristopamo do narta kocke preko orodja Essbase Administration Server. Na podoben nain vidimo te kategorije pri pripravi poroil. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 37 od 63

42 Slika 24: Nart kocke PRODAJA Na sliki 24 je prikazan osnovni seznam iz narta dimenzij. Na naslednjih slikah je prikaz hierarhije dveh dimenzij: datum in zavarovanje (slike 25, 26 in 27). Že na pogled sta dva razlina prikaza. V asovni dimenziji imamo samo dejstva in ni nobenih nazivov oz. opisov postavk (slika 25). Na desnem ekranu pri zavarovanjih šifri lana sledi opis ali naziv lana. V dimenziji zavarovanj smo oznaili eno vrstico (Nezgodno zav. AO-plus) in smo zato na vrhu dobili lastnosti polja. Podatki v dimenziji so konsolidirani kot vsota, na kar kaže zapisan '+' ob vsaki postavki. To pomeni, da se vrednosti pri lanih tega nivoja seštevajo v vrednosti za lana naslednjega višjega nivoja. Pri lanu na najvišjem nivoju (to je ime dimenzije) znaka '+' ni, ker se ne sešteva naprej na višji nivo. Za plusom so številke s številom postavk na naslednjem nivoju. Na zadnjem nivoju hierarhije tega podatka ni ve. Slika 25: Izgled narta za asovno dimenzijo Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 38 od 63

43 Oznaka 'Alias' (slika 26) na prvem mestu naziva pove nain kreiranja dimenzije. Nosilec oz. klju posamezne postavke dimenzije je samo šifra skupine zavarovanj ali zavarovalne podskupine ali zavarovalne enote brez naziva kar pomeni, da sprememba naziva ne vodi v novo postavko v dimenziji. Slika 26: Izgled narta za dimenzijo zavarovanje V nekaterih drugih dimenzijah ne uporabljamo operatorja alias. V takšnih primerih je naziv lana združen s šifro lana (slika 27). To pa hkrati pomeni, da bi sprememba šifre ali naziva pripeljala do nove kombinacije znotraj doloene dimenzije in novega vnosa v nart dimenzije. Slika 27: Izgled narta za dimenzijo izvor Celoten nart se lahko spremeni ob vsakem novem raunanju vrednosti in polnjenju kocke s podatki. Najmanj kar se spremeni je asovna dimenzija zaradi dodanih dni. Vsak delovni dan je v bazi podatkov veliko novih vnosov, ki nastajajo v vseh procesih poslovanja zavarovalnice. Ti vpisi pomenijo nove vnose v kocko v obdobjih, ko se izvaja polnjenje. Teh vpisov v nart kocke je razen za asovno Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 39 od 63

44 dimenzijo malo, saj je vein postavk iz dimenzijskih tabel že vnesena v dimenzije. Seveda pa je veliko ve podatkov z vrednostjo (enotami mere) v skladišu podatkov, od koder se izvaja kalkulacija. Novih zapisov je v kocki mnogo manj kot v skladiše podatkov. Primeri izgledov narta ostalih dimenzij so v prilogi 4. Za dokonno uporabnost kocke je manjkal samo še program, ki bo celotni postopek polnjenja kock izvajal redno brez posega administratorja za OLAP. EAS omogoa dve poti za dosego te zahteve. Ena je MaxL DDL (data definition language) za EAS druga pa ESSCMD (Essbase commands). Vsak ima svojo prednost in slabost. ESSCMD je starejši, še iz prejšnjih verzij tega orodja. Uporaben je izkljuno za kreiranje aplikacij in polnjenje kock. Dela z enostavnimi kratkimi ukazi. MaxL na drugi strani zmore polnjenje kock, poleg tega je še uporaben jezik za avtomatsko kreiranje poroil. Uporablja pa daljše in komplicirane ukaze bolj podobne SQL. V ESSCMD smo pripravili program za polnjenje kocke. Izvaja se enkrat tedensko, kar je za vrste analize, ki jih izvajajo v službi trženja dovolj. Proži se avtomatsko s standardnimi orodji za pripravo obdelav. 4.3 TESTIRANJE Veino testiranja nove aplikacije smo opravili že med samim razvojem bodoe kocke. Glavnina truda je bila usmerjena v pripravo dobrih SQL ukazov. Ker je bilo skladiše podatkov dobro pripravljeno, so tudi nekateri SQL ukazi enostavni. Vsak ukaz smo testirali z direktnim izvajanjem povpraševanja nad skladišem podatkov. Najve asa je bilo potrebnega za pripravo SQL-a za podatke za enote mere. V prilogi 4 se lepo vidi, kako obsežen in kompliciran je ta select. Testirali smo ga po delih in na koncu v celoti. Testirali smo ga na delu podatkov in potem spet na bazi iz skladiša podatkov. V konni verziji SQL ukazov so bili vsi rezultati priakovano pravilni. Prvo polnjenje kocke smo izvedli z omejitvijo iskanja podatkov na krajše obdobje in eno obmono enoto. Tako smo testirali tudi vpliv koliine podatkov na as polnjenja. Po polnjenju kocke z vsemi podatki smo pripravili nekaj zelo razlinih poroil in njihove rezultate primerjali z našimi iz testiranja SQL ukazov direktno na bazi podatkov. Vsi testi so bili uspešno zakljueni. To je pomenilo, da lahko pristopimo k predstavitvi nove aplikacije, šolanju uporabnikov in uvedbi kocke v poslovne procese. 4.4 UPORABA Razvili smo po vseh merilih veliko vedimenzionalno kocko, ki bo pokrivala veino trenutnih zahtev službe za trženje po doloeni vrsti analiz. To je z uporabniškega vidika zelo v redu. S stališa razvijalcev raunalniške rešitve smo zadovoljni z zakljukom dela. Nova verzija Essbase Administration Server-ja (EAS) se je izkazala za precej izpopolnjeno glede na prejšnje verzijo programske opreme, s katero smo razvili Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 40 od 63

45 prvo, malo kocko. A vendar je orodje zahtevno in mestoma komplicirano, kar se vidi tudi iz te naloge. EAS ima še nekaj drugih možnosti, ki jih bomo v kratkem uporabili pri dopolnitvah dela z novo kocko. Za vse uporabnike obstaja ena sama aplikacija. Vsi uporabniki naj ne bi videli vseh podatkov iz cele Zavarovalnice Triglav. Za to je v EAS mogoe pripraviti filtre na katerikoli podatek. Za enostavnejše omejitve ene dimenzije na enem nivoju je programiranje filtra enostavno. Lahko pa se v filtrih uporabi bolj kompleksne ukaze in formule in se dovoli vpogled samo do doloenega izbranega vzorca podatkov. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 41 od 63

46 5 PREGLEDI IN POROILA ZA SLUŽBO TRŽENJA 5.1 UVOD Konni uporabniki pristopajo do podatkov pripravljenih v OLAP kocki. Sami ne vidijo ozadja opisanega v preteklem poglavju, pa pa uporabljajo posebna, za to namenjena programska orodja. Orodja za pripravo poroil jim omogoajo izvajanje bolj ali manj kompliciranih analiz in pregledov ter pripravo poroil. Na Zavarovalnici Triglav vsi uporabniki, ki delajo z OLAP rešitvami, uporabljajo generator poroil Hyperion Analyzer. Ker smo OLAP kocko razvili z orodjem Essbase Administration Server, je možen pristop do podatkov tudi preko Microsoft Excel-a. 5.2 HYPERION ANALYZER Hyperion Analyzer (HA) je spletno orodje. Razvilo ga je podjetje Hyperion Solutions Corporation in spada v celoten programski paket za razvoj OLAP aplikacij. Pogoj za delo z njim sta na OLAP strežniku namešena IBM WebSphere Application Server v5.1 (WAS) in IBM HTTP Server v Hyperion Analyzer omogoa pristop do podatkov iz OLAP kock na dva naina: preko javanskega okolja Java Web Client preko HTML okolja HTML Web Cilent Poleg tega isti vstopni portal uporabljamo administratorji za administracijo Hyperion Analyzer-ja in sicer za: Administration Tools Client pristop do orodij za administracijo Analysis Server Console pristop do seznamov aktivnosti na OLAP kockah Na Zavarovalnici Triglav uporabniki uporabljajo javansko okolje. Po prehodu preko osnovnega ekrana in prijave v aplikacijo dobijo možnost pristopa do podatkov. Na sliki 28 je prikazan prvi ekran aktivnega uporabnika. Na ekranu so razporejeni kvadratki, od katerih vsak pomeni svojo skupino poroil ali pregledov. Takšna skupina poroil, npr. CELJE lahko nastane na dva naina. Skupino poroil definira administrator OLAP aplikacije, ji doloi ime in doloenim uporabnikom dovoli pristop do skupine. Drugae lahko skupino doloi tudi uporabnik HA sam ob shranjevanju prvega poroila. Uporabniki lahko poroila in preglede spravljajo v razline skupine glede na tip poizvedbe ali kakšni drugi organizaciji. Vendar ni želeno, da bi se teh skupin nabralo preve. Zato smo pri nas doloili standard imenovanja skupin poroil in vsebin, ki spadajo v posamezne skupine. Skupine poroil so po vsebini razdeljene glede na geografsko pripadnost uporabnika, torej obmono enoto iz katere deluje in glede na vrsto specifinih poizvedb, ki so narejene za tono doloene potrebe. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 42 od 63

47 Nekaj skupin poroil je namenjenih za testiranje novosti. Takšne skupine poroil administrator obasno preisti oz. zbriše poroila in preglede v njih. Slika 28: Osnovni ekran Hyperion Analyzer-ja V skupino poroil vstopimo s klikom na odgovarjajo kvadratek. e že obstaja shranjeno poroilo, se avtomatino prikaže njegova vsebina (slika 29). Okno je razdeljeno na tri dele, od katerih zgornji del zasedajo ikone z možnostmi za razvoj poroil, levi del vsebuje podatke o dimenzijah in kocki ter strežniku, osrednji del pa je namenjen vsebini kocke in poroila. Na dnu so zavihki ostalih poroil, e jih je ve. V našem primeru smo pripravili poroilo o premiji in številu prodanih zavarovanj po vseh obmonih enotah in prodajnih poteh. Dejanski podatki o premiji in številu so spremenjeni in zakriti, kakor zahteva poslovnik podjetja o varovanju podatkov in poslovni skrivnosti. V poroilu s podatki operiramo na razline naine. S klikom na katerikoli del poroila dobimo vrsto možnosti. Podatke lahko raztegnemo (drill down) ali skrimo (drill up). To pomeni, da se izbrani nivo dimenzije raztegne na naslednji nižji nivo, npr. izbrana obmona enota Celje bi se raztegnila v zastope, ki jih vsebuje Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 43 od 63

48 oz. skri na višji nivo dimenzije. e bi oznaili prodajno pot v neki obmoni enoti, bi se le ta raztegnila na nivo posameznih vrst prodajnih poti in potem še naprej do vseh zastopnikov ali komercialistov. Slika 29: Pogled na poroilo Na sliki 30 je prikazan del razlinih možnosti za delo z že izdelanimi pregledi oz. poroili. Najpogosteje uporabljamo možnosti za razširitev ali zožitev pogleda na razne naine (Drill), orodja za dodatne analize (Analysis Tools) in prepis podatkov v druge programe ali datoteke (Export Data). Obstaja pa še kup drugih možnosti za oblikovanje poroila. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 44 od 63

49 Slika 30: Možnosti pregledovanja poroila e želimo izdelati novo poroilo, kliknemo ikono NEW na vrhu ekrana (slika 29), ki nam odpre okno za doloitev oblike poroila in nato še seznam vseh kock (e jih ve) do katerih smemo pristopati (slika 31). Oblika poroila je lahko navadna preglednica v obliki tabele (Spreadsheet), graf (Chart) ali kombinacija obojega. Po izboru aplikacije in kocke (PRO_ZT: PRODAJA) dobimo vpogled v outline nart izbrane kocke. Okno poroila je razdeljeno na štiri podokna: filtri, strani, kolone in vrstice. V podoknu filtri je na zaetku prikazan celoten nart kocke. Od tu z enostavnim premikanjem dimenzij v druga podokna oblikujemo poroilo. Slika 31: Kreiranje novega poroila Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 45 od 63

50 Z dvoklikom na dimenzijo v kateremkoli odseku jo razširimo na naslednje nivoje, koder zbiramo postavke za natannejše definiranje poroila. Nastane osnovni izgled poroila, ki se pojavi ob vsakokratnem odpiranju. Med pogledom pa lahko uporabljamo možnosti, ki so opisane na sliki 30. Slika 32: Poroilo v obliki grafa Poroilu lahko naknadno spremenimo izgled na razline naine, kar vasih olajša predstavo o podatkih (slika 32). 5.3 ESSBASE EXCEL Možnost pristopa do kocke z Essbase Excelom se uporablja redkeje, predvsem pa, e nimamo odgovarjajoega strežnika za spletno delo WebSphere. e želimo delati z Excelom, moramo namestiti dodaten modul, ki omogoi povezavo Essbase Administration Server in Microsoft Excel. Delo z Excelom je do uporabnika za spoznanje manj prijazno. Tudi izgled ekrana je manj pester in nekaterih možnosti iz Hyperion Analyzer-ja ni. Glavna prednost Excela je v tem, da lahko podatke po branju iz kocke enostavno obdelujemo: izvajamo nad njimi matematine operacije, razvršamo na želen nain, enostavno kopiramo v druga orodja in izkorišamo še ostale možnosti Microsoft Excela. Preko Excela lahko vasih naredimo hiter vpogled v kakšne podatke, ki jih potrebujemo, nimamo pa namena narediti pravega poroila. Takšen hiter vpogled spominja na poizvedbo iz baze podatkov z SQL ukazi. Primer vpogleda je na slikah 33 in 34. Ko izvedemo branje podatkov iz kocke, se na prvem vpogledu pokažejo vse dimenzije (slika 33) brez razporejenih vrednosti. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 46 od 63

51 Stolpci pomenijo posamezne dimenzije. Z desno tipko miške primemo dimenzijo, ki nas zanima, in jo premaknemo pred enote mere. S tem dobimo možnost razširjanja dimenzij v ostale nivoje. Slika 33: Otvoritveni list Slika 34: List po prerazporeditvi dimenzij V tem pregledu podatkov smo premaknili vse dimenzije na zaetek lista. Razširili smo dimenzijo status zavarovalca in dobili vse vrednosti razdeljene po teh postavkah. Kakor v Hyperion Analyzer-ju je možno tudi v Excelu postaviti filtre oz. omejiti pregled po doloenih lanih dimenzij. Krištof Perc: Izgradnja podat. skl. in razvoj uporabniške rešitve v tehnologiji OLAP stran 47 od 63