Sprotna analitična obdelava v izbranem podjetju

Transcription

1 Kristjan Brodej Sprotna analitična obdelava v izbranem podjetju Diplomsko delo Maribor, december 2010

2 I Diplomsko delo univerzitetnega študijskega programa Sprotna analitična obdelava v izbranem podjetju Študent: Študijski program: Smer: Mentorica: Somentor: Lektorica: Kristjan Brodej UN Računalništvo in informatika Informatika red. prof. dr. Tatjana Welzer Družovec doc. dr. Marko Hölbl Janja Rostohar Maribor, december 2010

3 II

4 III ZAHVALA Zahvaljujem se mentorici dr. Tatjani Welzer Družovec za pomoč in vodenje pri opravljanju diplomskega dela. Prav tako se zahvaljujem somentorju dr. Marku Hölblu ter vsemu osebju fakultete, ki mi je kakorkoli pomagalo tekom študija. Še posebej se zahvaljujem staršem, ki so mi omogočili študij in mi vedno stali ob strani.

5 IV SPROTNA ANALITIČNA OBDELAVA V IZBRANEM PODJETJU Ključne besede: OLAP, poslovna inteligenca, poslovno odločanje, podatkovno skladišče, OLAP kocka UDK: /.658:005(043.2). Povzetek Ob dandanašnjih zaostrenih gospodarskih razmerah in hudi konkurenci na vedno bolj globalnih trgih so podjetja primorana v optimizacijo poslovnih in proizvodnih procesov. Učinkovito in hitro poslovno odločanje tako podjetjem predstavlja znatno konkurenčno prednost. Zato v zadnjem desetletju ravno poslovna inteligenca postaja ena glavnih tehnoloških prioritet podjetij. Diplomska naloga obravnava sprotno analitično obdelavo, eno pomembnejših tehnologij poslovne inteligence. V njej opredelimo tehnologijo, predstavimo njene komponente ter na praktičnem primeru podjetja Unior d.d. prikažemo njeno implementacijo z orodjem Oracle OLAP.

6 V OLAP TECHNOLOGY FOR SELECTED ENTERPRISE Key words: OLAP, business intelligence, business decision making, data warehouse, OLAP cube UDK: /.658:005(043.2). Abstract At today's tight economic conditions and fierce competition at increasingly global markets companies are forced to optimize their business and production processes. Quick and efficient business decision making gives them a significant competitive advantage. Business intelligence is therefore one of the top business technology priorities in the last decade. The diploma work focuses on the on-line analytical processing, one of the major technologies of business intelligence. It defines the technology, introduces its main components, and demonstrates implementation with Oracle OLAP tool on practical example of Unior d.d company.

7 VI VSEBINA 1 UVOD SPLOŠNO PODROČJE NAMEN STRUKTURA POSLOVNA INTELIGENCA DEFINICIJA POSLOVNO ODLOČANJE NAMENI IN NAČINI UPORABE REŠITEV POSLOVNE INTELIGENCE TEHNIČNI GRADNIKI POSLOVNE INTELIGENCE ETL postopki Podatkovno skladišče Podatkovno rudarjenje Večdimenzijsko analiziranje Poslovno poročanje OLAP - SPROTNA ANALITIČNA OBDELAVA DEFINICIJA OLTP in OLAP Coddova pravila FASMI VEČDIMENZIONALNI PODATKOVNI MODEL Notacija Shema modela Olap Kocka Mere Dimenzije OPERACIJE TEHNOLOGIJE OLAP Vrtanje navzdol Zvijanje navzgor Rezanje Vrtenje Vrtanje preko Primerjave, izračuni, izjeme in agregiranje SHRANJEVANJE IN PROCESIRANJE PODATKOV Agregiranje Tipi arhitektur OLAP sistemov...34

8 VII 3.5 POVPRAŠEVALNI JEZIK MDX PODROČJA UPORABE ORODJA IN PROIZVAJALCI PRIMER SPROTNE ANALITIČNE OBDELAVE PREDSTAVITEV PODJETJA OPIS PROBLEMA IN ŽELENI REZULTATI ORACLE IN OLAP Oracle OLAP Oracle Essbase Primerjava ANALIZA IN OPIS REŠITVE IZGRADNJA PODATKOVNEGA SKLADIŠČA Poenostavljen E-R diagram Shema dimenzijskega modela ETL Proces IZGRADNJA OLAP BAZE Priprava okolja Priprava delovnega področja Gradnja dimenzij Gradnja kocke PRIKAZ REZULTATOV Dostop s pomočjo SQL-a Dostop s pomočjo OLAP API ZAKLJUČEK VIRI, LITERATURA PRILOGE SEZNAM SLIK SEZNAM TABEL SEZNAM PRIMEROV NASLOV ŠTUDENTA KRATEK ŽIVLJENJEPIS...89

9 VIII UPORABLJENE KRATICE OLAP BI ETL OLTP MDX SQL PL/SQL SUPB RDBMS BLOB AWM OWB OLAP DML OCI JDBC ODBC HTTP TCP/IP IT BPM EBS Online analytical processing Business intelligence Extract, transform, and load Online transaction processing Multidimensional expressions Structured query language Procedural language/structured query language Sistem za upravljanje podatkovne baze Relational database management system Binary large object Analytic workspace manager Oracle warehouse builder Analytic workspace internal data definition and manipulation language Oracle call interface Java database connectivity Open database connectivity Hyper text transfer protocol Transmission control protocol/internet protocol Information technology Business performance management Oracle E-Business Suite

10 Sprotna analitična obdelava v izbranem podjetju Stran 1 1 UVOD Experts often possess more data than judgment. Colin Powell Dandanes kakovostne informacije v globalnem gospodarstvu postajajo ena glavnih konkurenčnih prednosti uspešnih podjetij. Podjetja imajo z razmahom informacijskih tehnologij dostop do ogromnih količin podatkov, ki pa sami po sebi ne zagotavljajo kakovostnejših informacij. Tako postaja ravno proces pridobivanja informacij iz dosegljivih podatkov ena od glavnih aktivnosti IT kadrov podjetij. 1.1 Splošno področje Ko govorimo o procesu pridobivanja znanja (informacij) v poslovnem svetu, ne moremo mimo pojma poslovne inteligence, ki v okviru informacijskih tehnologij pokriva procese in tehnologije, ki nudijo podporo poslovnemu odločanju. Eden od pomembnejših konceptov, ki se uvrščajo v domeno poslovne inteligence, je tudi sprotna analitična obdelava, ki se ji bomo podrobneje posvetili v diplomskem delu. 1.2 Namen Namen diplomskega dela je obravnava koncepta sprotne analitične obdelave. Sprotno analitično obdelavo ali tehnologijo OLAP, kot jo pogosto imenujemo z drugim imenom, bomo umestili v široko področje poslovne inteligence, razložili bomo, kaj se dejansko skriva pod samim pojmom OLAP tehnologije, predstavili osnovne koncepte ter razjasnili nekatere tehnične podrobnosti. Na primeru prodaje podjetja Unior d.d. si bomo ogledali primer vpeljave tehnologije v podjetje ter prikazali dejansko implementacijo tehnologije s programskimi rešitvami podjetja Oracle. Primarni namen praktičnega dela diplomske naloge je spoznavanje in testiranje tehnologije v sklopu podatkovne baze Oracle. Nastali sistem bo predstavljal le prototip implementacije.

11 Sprotna analitična obdelava v izbranem podjetju Stran Struktura V poglavju Poslovna inteligenca bomo razjasnili pojem poslovne inteligence. Razložili bomo, kaj so rešitve poslovne inteligence in kako jih uporabljamo za podporo poslovnemu odločanju. Na kratko se bomo dotaknili tudi tehničnih gradnikov. V osrednjem poglavju OLAP Sprotna analitična obdelava bomo definirali OLAP tehnologijo, si na kratko ogledali njeno zgodovino ter opisali večdimenzionalni model. Preko primerov bomo razložili operacije tehnologije, opisali tipe arhitektur OLAP sistemov ter preleteli povpraševalni jezik MDX. Na koncu bomo nekaj besed namenili tudi dejanskim področjem uporabe tehnologije, ter orodjem in proizvajalcem. Poglavje Primer sprotne analitične obdelave predstavlja praktični del diplomskega dela, kjer bomo prikazali vpeljavo OLAP tehnologije v segment delovanja podjetja UNIOR d.d. Navedli in opisali bomo faze vpeljave OLAP sistema ter prikazali dejanske rezultate sistema, ki ga bomo zgradili. V sklepnem poglavju Zaključek bomo povzeli rezultate in sklepe iz praktičnega dela ter skušali smiselno zaokrožiti celotno diplomsko delo s povzetkom ugotovitev, do katerih bomo prišli tekom izvedbe.

12 Sprotna analitična obdelava v izbranem podjetju Stran 3 2 POSLOVNA INTELIGENCA V zdajšnjem času se v podjetjih soočamo s poplavo razpršenih, redundantnih in nekonsistentnih podatkov, hkrati pa vedno več poslovnih odločitev temelji na točnih, konsistentnih in hitro dosegljivih informacijah. Posledično hiter in enostaven dostop do teh informacij predstavlja konkurenčno prednost in je pogoj za uspešno podjetje. Na Sliki 1 je prikazano razhajanje med razpoložljivimi podatki in uporabnimi informacijami v odvisnosti od količine in časa [15]. Slika 1: Informacijska vrzel Ponavadi sami procesno usmerjeni informacijski sistemi podjetij ne zmorejo slediti zahtevam po informacijah (hitrost, kvaliteta, kompleksnost, enostavnost dostopa) in tako se pojavi potreba po analitičnem sistemu, ki ni transakcijsko usmerjen, pač pa temelji na izpeljanih informacijah, analizi podatkov in hitrem dostopu do informacij. Takšen sistem imenujemo poslovna inteligenca (angl. business intelligence) ali skrajšano s tujko BI. Ob naraščajočem tempu sprememb na globalnem trgu in potrebi po čim hitrejšem odzivanju na njih, so podjetja prisiljena optimizirati svoje procese odločanja in tako ni presenetljivo, da je po Gartnerju [12] ravno poslovna inteligenca že vrsto let na vrhu tehnoloških prioritet podjetij. Glede na smernice in prakso v podjetjih bo tako verjetno tudi v nadaljnjih letih.

13 Sprotna analitična obdelava v izbranem podjetju Stran Definicija Poslovno inteligenco lahko najsplošneje definiramo kot proces pridobivanja informacij iz dosegljivih podatkov [23]. Torej iz množice podatkov izločimo in analiziramo le tiste, ki so pomembni, oz. nam prinašajo novo znanje. Za razumevanje definicije moramo poznati razliko med podatkom, informacijo in znanjem [10], ki jih pogosto grafično predstavimo v obliki piramide, kot je prikazano na Sliki 2. Podatek je neurejeno dejstvo, ki opisuje stvari, dogodke, aktivnosti in transakcije. Informacija so podatki, organizirani in predelani tako, da imajo za sprejemnika pomen. Znanje je sestavljeno iz informacij, ki so organizirane in predelane tako, da so miselno povezane, koristne in veljavne. Slika 2: Piramida znanja V poslovnem svetu je poslovna inteligenca generični pojem, ki opisuje uporabo notranjih in zunanjih informacij v podjetju, z namenom doseganja boljših rezultatov [26]. Pojem je bil prvič uporabljen leta 1958 v članku "A Business Intelligence System" IBM-ovega raziskovalca Hans Peter Luhna, ki je poslovno inteligenco opredelil kot zmožnost dojemanja medsebojnih razmerij med podanimi dejstvi na način, ki nas pelje proti želenemu cilju [13]. Leta 1989 pa je Howard Dresner s predlogom, da naj poslovna inteligenca opisuje koncepte in metode, ki izboljšujejo poslovno odločanje z uporabo sistemov, ki temeljijo na dejstvih, postavil danes splošno razširjeno definicijo [7]. Zgoraj napisano še povzemimo: Namen poslovne inteligence je torej preoblikovanje podatkov v informacije, s katerimi lahko optimiziramo poslovne procese v podjetju in posledično maksimiziramo dobiček podjetja.

14 Sprotna analitična obdelava v izbranem podjetju Stran Poslovno odločanje Cilj poslovne inteligence je podpora in izboljšanje poslovnega odločanja [17]. Poslovno odločanje lahko poenostavljeno predstavimo kot ponavljajoče se zaporedje štirih procesov, prikazanih na Sliki 3: Meritve (angl. measure) V tej fazi definiramo ključne metrike, ki jih uporabljamo v organizaciji. Ponavadi so to osnovni kazalci podjetja (prodaja, stroški, dobiček, ipd.). Na splošno bi lahko rekli, da v tej fazi odgovorimo na vprašanje: Kaj vpliva na poslovanje? Analiza (angl. analyze) V drugi fazi se podatki, definirani v prvi fazi, pregledajo in analizirajo, hkrati pa iščemo sedaj neznane povezave med njimi. Iščemo odgovor na vprašanje: Zakaj vpliva na poslovanje? Načrtovanje (angl. plan) V tretji fazi preučujemo predvidene posledice sprememb, osnovanih na rezultatih druge faze. Odgovarjamo na vprašanja: Kakšno bo poslovanje če? Izboljšave (angl. improve) V zadnji fazi na osnovi rezultatov prejšnjih faz definiramo dejanske rešitve, ki bodo izboljšale poslovanje. Odgovarjamo na: Kako spremeniti poslovanje na bolje? Slika 3: Proces izboljšave rešitev poslovne inteligence

15 Sprotna analitična obdelava v izbranem podjetju Stran Nameni in načini uporabe rešitev poslovne inteligence V prejšnjem podpoglavju smo ugotovili, da je primarni cilj poslovne inteligence podpora pri poslovnih odločitvah. Naštejmo področja ali dele procesa odločanja, kjer se uporabljajo ali pa so celo nujno potrebne rešitve poslovne inteligence [3]: Poročanje (angl. reporting) Poročanje je primarna funkcija poslovne inteligence, ki omogoča hiter in celovit pogled nad aktivnostmi in procesi poslovanja v podjetju. Poročanje mora biti enostavno izvedljivo, dosegljivo in praktično. Analize (angl. analysis) Proces razčlenitve problema na manjše dele za lažje razumevanje. Analiziranje pridobljenih podatkov preko večdimenzijske analize, analize trendov, raziskovanja podatkov, itd. Podatkovno rudarjenje (angl. data mining) Podatkovno rudarjenje ali odkrivanje znanja (angl. knowledge discovery) je sistematično iskanje nepoznanih vzorcev, pravil in korelacij v ogromnih količinah podatkov. Napovedovanje in planiranje (angl. forecasting and planning) Proces planiranja in napovedovanja želenega in predvidenega stanja v prihodnosti na podlagi trenutnih in preteklih podatkov. Nadzor procesov (angl. business activity monitoring) Centraliziran nadzor nad procesi, operacijami in transakcijami v realnem času, ki omogoča hitrejše reševanje problemov, lažje odločanje in izkoriščanje priložnosti.

16 Sprotna analitična obdelava v izbranem podjetju Stran Tehnični gradniki poslovne inteligence Temelj poslovne inteligence je tehnična platforma, ki dejansko omogoča uporabo vsebinskih rešitev. Informacijsko infrastrukturo sestavlja več orodij, ki imajo specifične naloge, poenostavljeno pa bi lahko dejali, da skrbijo za hrambo, transformacijo, obdelavo in prikaz podatkov oziroma informacij. Življenjski cikel teh podatkov [9] lahko predstavimo kronološko, kot je prikazano na Sliki 4. Slika 4: Življenjski cikel podatkov Podatke iz različnih virov zbiramo v podatkovnem skladišču na način, da ustrezajo prej definiranim zahtevam po obliki in vsebini. Ti podatki se potem bodisi oblikujejo, bodisi spremenijo v obliko, primerno za prikaz ali nadaljnjo analizo končnih uporabnikov. Osnova vsakega dobrega sistema poslovne inteligence so naslednji tehnični gradniki: ETL postopki, podatkovna skladišča, podatkovno rudarjenje, večdimenzionalno analiziranje, poslovno poročanje.

17 Sprotna analitična obdelava v izbranem podjetju Stran ETL postopki ETL (angl. ETL extract, transform, load) postopek je proces zajemanja, preoblikovanja in polnjenja podatkov iz različnih virov (izvorni sistem) v podatkovno bazo ali skladišče (ciljni sistem) [27]. Predstavlja enega od najvažnejših procesov izgradnje podatkovnih skladišč, vendar se uporablja tudi v klasičnih transakcijskih podatkovnih bazah. Pravilni, konsistentni in urejeni podatki predstavljajo temelj dobrega sistema poslovne inteligence. Proces je shematično prikazan na Sliki 5 [16]. Slika 5: ETL postopek Zajemanje podatkov je prva faza procesa ETL, katere cilj je pridobitev podatkov iz različnih izvornih sistemov (različne vrste podatkovnih baz, različni formati nepovezanih datotek, ostale podatkovne strukture), ki se lahko nahajajo na poljubnih platformah. Obstaja več možnosti zajema, od uporabe enostavnih skript do namenskih orodij. Prejeti podatki morajo ustrezati poslovnim in tehničnim zahtevam ciljnega sistema. Zaradi raznovrstnosti virov, različnih formatov, nepopolnosti podatkov je potrebno pogosto opraviti preoblikovanje zajetih podatkov. Del podatkov je morda potrebno odstraniti, del razcepiti/združiti, prilagoditi pomen vrednosti ('Y'=>'Da'), oplemenititi (skupna teža = teža_enote*količina), itd. Nazadnje moramo preoblikovane podatke shraniti na ciljni sistem. Glede na vrsto in količino podatkov je odvisno, kdaj in kako se bo shranjevanje izvajalo. Praviloma gre za periodičen postopek, ki se izvaja, ko je izvorni sistem neobremenjen ali neoperativen. Podatki se lahko vsakič napolnijo v celoti, če je možno, pa se napolnijo le spremembe.

18 Sprotna analitična obdelava v izbranem podjetju Stran Podatkovno skladišče Ugotovili smo, da podjetja posedujejo velike količine razpršenih, različno organiziranih, nepovezljivih in neurejenih podatkov, ki kot informacije predstavljajo osnovo za uspešno poslovanje podjetij. Tako ni presenetljivo, da želimo hrambo podatkov organizirati tako, da nam bodo podatki na voljo čim hitreje in v obliki, ki nam najbolj ustreza. Ravno v ta namen se uporabljajo podatkovna skladišča (angl. data warehouse). Pojem podatkovnega skladišča je bil prvič omenjen leta 1990, ko je Bill Imonn podatkovno skladišče definiral kot vsebinsko usmerjeno, integrirano, časovno odvisno, nespremenljivo zbirko podatkov, namenjeno podpori poslovnega odločanja [30]. V podatkovnih skladiščih se podatki torej združujejo po vsebini (področju) in ne po viru (procesu), iz katerega izvirajo, kar omogoča lažje razumevanje in dostop. Podatki so integrirani v sistem, kar pomeni, da ustrezajo določenim pravilom oz. zahtevam, s katerimi zagotovimo poenotenje podatkov iz različnih virov in njihovo konsistenco. Vsi podatki vsebujejo časovno komponento, kar omogoča enostavno časovno analiziranje, hkrati pa so praviloma nespremenljivi, statični in se s časom samo dodajajo, kar je v nasprotju s transakcijskimi sistemi, kjer se podatki tekom procesov ves čas spreminjajo. Na Sliki 6 lahko vidimo štiri osnovne konceptualne dele podatkovnega skladišča, od katerih ima vsak svoje specifične lastnosti in funkcije znotraj celotnega sistema [26]. Slika 6: Klasični gradniki podatkovnega skladišča

19 Sprotna analitična obdelava v izbranem podjetju Stran 10 Področje izvornih sistemov vsebuje sisteme, iz katerih podatkovno skladišče pridobiva podatke. Praviloma gre za operativne sisteme, ki so popolnoma neodvisni od podatkovnega skladišča, zato se ne štejejo kot sestavni del skladišča. S stališča podatkovnega skladišča sta glavni prioriteti izvornih sistemov razpoložljivost in zmogljivost. Področje priprave podatkov vsebuje vmesno pomnilniško področje, kjer so podatki shranjeni, preden se prenesejo v podatkovno skladišče in nabor funkcij za ETL procese, ki podatke ustrezno prečistijo in transformirajo. Področje predstavitve podatkov je osrednje mesto podatkovnega skladišča, kjer organiziramo, hranimo in vzdržujemo podatke. Obstajata dva možna pristopa organizacije podatkov: Dimenzionalni in normalizirani, oba bomo nekoliko podrobneje opisali v nadaljevanju. Podatki v samem skladišču so lahko logično (fizično) ločeni glede na specifično področje poslovanja iz katerega prihajajo, takrat govorimo o področnem podatkovnem skladišču ali informacijski tržnici (angl. data mart). Področje dostopa do podatkov je končni del podatkovnega skladišča, ki z različnimi orodji in postopki omogoča končnemu uporabniku dostop do podatkov. Tudi ta del bomo nekoliko podrobneje opisali v naslednjih podpoglavjih. Glede na organizacijo poznamo tri osnovne arhitekture podatkovnih skladišč [14]: Centralizirana arhitektura, Porazdeljena arhitektura, Federativna arhitektura. Pri centralni arhitekturi je v središču podatkovno skladišče, ki se polni iz operativnih baz, področna skladišča se polnijo iz centralnega podatkovnega skladišča. Podatkovni model je normaliziran, za modeliranje pa se uporablja klasični entitetno-relacijski model, kot ga poznamo iz podatkovnih baz. Pri porazdeljeni arhitekturi je več področnih skladišč povezanih v logično podatkovno skladišče (področno skladišče je podmnožica). Podatkovni model je dimenzionalni, uporablja se dimenzijsko modeliranje. Federativna arhitektura je kombinacija centralne in porazdeljene arhitekture. Temelji na skupnem poslovnem modelu (angl. common business model) in področnih pripravah podatkov, ki so v skupni lasti.

20 Sprotna analitična obdelava v izbranem podjetju Stran Podatkovno rudarjenje Podatkovno rudarjenje je proces odkrivanja pomembnih odvisnosti, vzorcev in trendov s preiskovanjem velikih količin podatkov, shranjenih v podatkovnih shrambah. Pri tem se uporabljajo tehnologije za odkrivanje vzorcev, kakor tudi statistične in matematične tehnike [4]. Če povzamemo. Podatkovno rudarjenje je sistematično iskanje informacij v veliki količini podatkov. Slika 7: Metodologija podatkovnega rudarjenja Procesu podatkovnega rudarjenja pogosto pravimo tudi proces odkrivanja znanja v podatkovnih bazah ali krajše proces KDD (angl. knowledge discovery in databases). Kot je razvidno s Slike 7, gre za ciklični proces, ki poteka preko več faz, skozi katere lahko s pravilno uporabo in razumevanjem vhodnih in izhodnih podatkov, pridemo do uporabnih informacij, ki nam pomagajo pri poslovnem odločanju. Naštejmo in kratko opišimo skupine problemov, ki jih obravnava podatkovno rudarjenje: klasifikacija (angl. classification), gručenje (angl. clustering), regresija (angl. regression), asociativna pravila (angl. association rule learning).

21 Sprotna analitična obdelava v izbranem podjetju Stran 12 Klasifikacija je razvrščanje podatkov vnaprej določene množice. Primer klasifikacije bi bilo določanje spola glede na podatke, pridobljene iz nekega vprašalnika. Za podoben princip gre pri gručenju, le da tu množica možnih razvrščanj ni vnaprej določena in jo definira sam proces gručenja. Pri regresiji poskušamo natančno določiti neko vrednost, količino podatka. Na primer, na osnovi podatkov o prodaji želimo predvideti, koliko bodo določeni tipi strank zapravili v naslednjem letu. Asociativna pravila pa skušajo najti odvisnosti med posameznimi podatki. Tipični primer je analiza nakupne košarice (angl. market basket analysis) - trgovine skušajo ugotoviti, kateri izdelki se prodajajo skupaj, da bi povečali možnost nakupa z ustrezno postavitvijo izdelkov in akcijskimi cenami. Za reševanje problemov se uporabljajo različni principi in postopki, kot so klasične statistične in matematične metode, genetski algoritmi (angl. genetic algorithms) in nevronske mreže (angl. neural networks) Večdimenzijsko analiziranje V podjetjih se pogosto porajajo kompleksna vprašanja tipa: Kakšna je skupna, najmanjša, največja, povprečna prodaja v zadnjem četrtletju glede na skupino izdelkov in prodajno regijo napram prejšnjemu četrtletju? Podatki, ki nam lahko odgovorijo na takšna in podobna vprašanja, se v podjetjih praviloma nahajajo v transakcijskih relacijskih podatkovnih bazah in so po navadi zaradi normalizacije porazgubljeni po mnogih tabelah, kar pomeni kompleksnost poizvedovanja (tehnično in vsebinsko znanje, hitrost poizvedovanja, obremenitev sistema). Analitiki in vodstveni kader so tako prisiljeni pomoč iskati pri informatikih, kar pa za podjetje pomeni dodatno delo in časovni zamik. Da se temu izognemo, uporabljamo večdimenzijsko organizacijo podatkov in postopke ter orodja za njihovo analizo. Sprotna analitična obdelava ali krajše OLAP (angl. online analytical processing) omogoča neposredno, enostavno in fleksibilno poizvedovanje, rezanje podatkov po poljubnih dimenzijah ter njihovo agregiranje. Podrobno jo bomo predstavili v poglavju, ki sledi.

22 Sprotna analitična obdelava v izbranem podjetju Stran Poslovno poročanje Kakovostne informacije in analize ne dosežejo cilja, v kolikor niso predstavljene pravočasno in na pravilni način. Tako je prav predstavitev podatkov eden ključnih faktorjev poročanja. V ta namen se v podjetjih uporabljajo različni sistemi za poročanje. Najpogosteje se podatki končnim uporabnikom podajajo v obliki poročil (angl. report). Poročila so lahko dinamična ali statična. Uporabniki jih lahko dobijo v tiskani obliki, po elektronski pošti, v obliki spletne strani, v informacijskem sistemu, lahko pa so zbrana na t. i. nadzornih ploščah (angl. dashboard), kjer lahko uporabniki hitro in pregledno dostopajo do osnovnih informacij, vendar imajo tudi možnost podrobnejše analize (angl. master-detail). Pri načinu dostopa omenimo tudi delitev na t. i. "push/pull" poročila, torej, ali je poročilo dostavljeno samodejno, ali pa na zahtevo uporabnika. Za prikaz podatkov uporabljamo različna orodja. Želene lastnosti le-teh so: enostavnost ustvarjanja in spreminjanja poročil, enostavnost in zmogljivost upravljanja (dostava, omejitve dostopa), hitrost in preglednost, možnost poosebljanja, možnost nadaljnje analize in poizvedovanja, možnost integracije z analitičnimi orodji (izvoz podatkov, povezljivost). Izdelava dobrega poslovnega poročila naj bi sledila naslednjim korakom [1]: določitev obsega (namena) poslovnega poročila; določitev ciljnega občinstva (vodstveno osebje, analitiki, referenti, itd.); pridobitev, organiziranje in preučitev relevantnih podatkov; analiza in ovrednotenje relevantnih podatkov; določitev rešitev, odgovorov in priporočil, ki bodo pomagali uporabnikom; določitev strukture in oblike poročila.

23 Sprotna analitična obdelava v izbranem podjetju Stran 14 3 OLAP - SPROTNA ANALITIČNA OBDELAVA 3.1 Definicija Kot smo že ugotovili, se tehnologija OLAP uporablja za napredno analiziranje velikih količin podatkov ter za njihov pregleden in jasen prikaz. Povedano drugače: OLAP je tehnologija, ki analitikom, menedžerjem in vodstvenemu kadru omogoča vpogled v podatke s hitrim, konsistentnim in interaktivnim dostopom do široke množice različnih pogledov na informacije, transformirane iz surovih podatkov, tako da dobijo pravo sliko o podjetju in njegovem stanju [20]. Za boljše razumevanje tehnologije OLAP je potrebno razumeti tudi, zakaj se za analizo podatkov ne uporabljajo kar klasični transakcijski sistemi OLTP in OLAP Informacijski poslovni sistemi podjetij so v veliki meri namenjeni operativnemu delu v podjetju (knjiženje naročil, spreminjanje zaloge, ipd.), tako lahko rečemo, da so transakcijsko usmerjeni. Takšnim sistemom pravimo sistemi za sprotno obdelavo transakcij (angl. online transaction processing - OLTP). Osnovna značilnost OLTP sistemov so podrobni atomarni podatki, shranjeni v normaliziranih podatkovnih strukturah, optimiziranih za vpisovanje in ažuriranje podatkov. Na Sliki 8 je prikazana razlika med operativnim in analitičnim nivojem podatkov v podjetjih. Slika 8: Operativni in analitični nivo podatkov v podjetjih

24 Sprotna analitična obdelava v izbranem podjetju Stran 15 Zakaj torej za poizvedbe in analize ne bi uporabljali obstoječih sistemov? Na to vprašanje smo delno odgovorili že v podpoglavju o večdimenzijskem analiziranju. Glavni razlog je razlika v potrebi po podatkih na operativnem in analitičnem nivoju. Pri operativnem delu je pomembna posamezna transakcija, pri analizah pa nas zanimajo različni agregirani podatki, sestavljeni iz velikega števila različnih transakcij, šifrantov in izračunov. V OLTP sistemih so podatki v operativnih relacijskih bazah razkropljeni po velikem številu normaliziranih tabel, kar pomeni zapleteno, dolgotrajno in za sistem moteče izvajanje povpraševanj. Tako analiz in povpraševanj ne morejo izvajati kar končni uporabniki, ki najbolje vedo, kaj pravzaprav želijo. Zato se v podjetjih uporabljajo OLAP sistemi, ki za vir podatkov uporabljajo podatke OLTP sistemov, hkrati pa so, z vnaprej pripravljenimi podatki in enostavnimi vmesniki, primerni za uporabo s strani končnih uporabnikov, ki imajo omejeno strokovno znanje in čas. V Tabeli 1 so na kratko navedene glavne razlike med obema vrstama sistemov. Tabela 1: Primerjava OLTP in OLAP sistemov Značilnost OLTP OLAP Obdelava Operacije Informacije Transakcije Poslovni dogodek Prenos podatkov Časovna komponenta Nenehno spreminjanje Posnetki stanja Organizacija Zapletena, normalizirana Dimenzijski model Obremenitev Enakomerna Neenakomerna Dostop En zapis Agregirani podatki Uporabniki DBA, informatiki, referentje Analitiki, menedžerji Št. uporabnikov Operacije Enostavne Kompleksne Dostop Branje/pisanje Branje Vrsta podatkov Osnovni, podrobni Sumarizirani, konsolidirani Velikost Majhna (nekaj GB) Velika (do TB) Prioriteta Razpoložljivost Fleksibilnost

25 Sprotna analitična obdelava v izbranem podjetju Stran Coddova pravila Odgovorili smo na vprašanji zakaj in kako se uporablja tehnologija OLAP. Zdaj pa se podrobneje posvetimo lastnostim in zahtevam OLAP sistemov. Dr. Edgar Codd je leta 1993 objavil članek z naslovom "Providing OLAP to User- Analysts: An IT Mandate", v katerem je z 18 pravili definiral, kaj naj bi bil OLAP sistem, oziroma, katerim lastnostim morajo zadoščati OLAP sistemi [11]. S strani stroke mu je bilo očitano, da je bila vsebina preveč naklonjena proizvajalcu, ki je naročilo raziskavo (podjetje Arbor, ki je kasneje razvilo Essbase). Kljub temu pravila pogosto srečamo v povezavi s prvo definicijo tehnologije. Razdeljena so v štiri skupine, nekatere pomembnejše točke pravil bomo podrobneje razložili v naslednjih poglavjih. 1. Osnovne lastnosti B (Basic Features B) F1: Večdimenzionalni koncept F2: Intuitivno upravljanje s podatki F3: Olap sistem kot vmesnik (med podatki in prikazom) F4: Različen dostop do podatkov (lastno skladišče, transakcijska baza) F5: Več podprtih modelov za analiziranje podatkov F6: Odjemalec-strežnik arhitektura F7: Transparentnost F8: Večuporabniška podpora 2. Posebne lastnosti S (Special Features S) F9: Nespreminjanje izvornih podatkov F10: Shranjevanje rezultatov F11: Izločevanje manjkajočih vrednosti F12: Obravnava manjkajočih vrednosti

26 Sprotna analitična obdelava v izbranem podjetju Stran Lastnosti poročanja (Reporting Features R) F13: Fleksibilnost poročanja F14: Učinkovitost poročanja F15: Samodejna prilagoditev fizične sheme 4. Upravljanje dimenzij (Dimension Control) F16: Splošnost dimenzij F17: Neomejeno število dimenzij in nivojev agregacije F18: Možnost izvajanja operacij med dimenzijami FASMI Leta 1995 je skupina neodvisnih analitikov pod vodstvom Nigela Pendse oblikovala krajšo in manj pristransko definicijo, katere ime je postalo tudi drugi pojem za tehnologijo OLAP. Že samo ime definicije: hitra analiza deljenih večdimenzionalnih informacij (angl. Fast Analysis of Shared Multidimensional Information - FASMI), definira osnovne lastnosti/zahteve tehnologije [2]: HITROST (angl. fast) Sistem naj bi bil sposoben obdelati večino povpraševanj/operacij v 5 sekundah, najpreprostejše v sekundi in najzahtevnejše v najpozneje 20 sekundah. Zahteve so bile oblikovane na podlagi študij obnašanja končnih uporabnikov pri uporabi analitičnih orodij. Zadostitev takšnih zahtev po hitrosti ni lahka naloga in zahteva uporabo več pristopov, od katerih omenimo vnaprejšnje agregiranje, ki ga bomo v nadaljevanju še obdelali.

27 Sprotna analitična obdelava v izbranem podjetju Stran 18 ANALITIČNOST (angl. analysis) Sistem mora pokrivati vso poslovno logiko in statistične analize, ki so pomembne uporabniku, hkrati pa mora biti dovolj enostaven za uporabo. Uporabniku mora biti omogočeno kreiranje povpraševanj in njihov prikaz brez dodatnega programiranja. Način izvedbe povpraševanj in prikaza ni pomemben, le da so zagotovljene zahteve. DELJIVOST (angl. shared) Sistem zadošča vsem varnostnim zahtevam za zaupnost podatkov (tudi do nivoja posamezne celice v tabeli), hkrati pa pri večuporabniškem ažuriranju podatkov zagotavlja pravilno in hitro delovanje zaklepanja posameznih zapisov. Sočasni dostop je pogost problem pri OLAP produktih, saj se zmotno predvideva, da OLAP aplikacije uporabljajo le operacije branja (angl. read-only). VEČDIMENZIONALNOST (angl. multidimensional) Sistem zagotavlja večdimenzionalni koncept organizacije podatkov, ki vključuje podporo hierarhičnega večdimenzionalnega pregleda podatkov, saj je takšen način analiziranja najbolj logičen in naraven. Zahteva ne predpisuje niti minimalnega števila dimenzij, niti tehnologije (podatkovni model) podatkovnega skladišča, le da je končni rezultat uporabniku res predstavljen v večdimenzijskem konceptualnem pogledu. Zagotovo gre za ključno in najpomembnejšo zahtevo, brez katere ne moremo govoriti o OLAP sistemu! INFORMACIJA (angl. information) Vsebuje vse podatke in informacije, ne glede na to, kje in kako so odvisni od aplikacije. Zmogljivost sistema mora biti torej takšna, da zadošča vsem podatkovnim zahtevam. Merimo količino podatkov, ki jih sistem lahko obdela in ne koliko jih lahko shrani. Sem spadajo učinkovitost, sistemske zahteve, redundanca podatkov, integracija s podatkovnim skladiščem, itd.

28 Sprotna analitična obdelava v izbranem podjetju Stran Večdimenzionalni podatkovni model Sistemi OLAP temeljijo na večdimenzionalnem podatkovnem modelu. Gre za enostaven in preprost model, temelječ na principu, podobnem pomnjenju človeških možganov, ki podatke urejajo, združujejo in razvrščajo v logične skupine. Model sestoji iz dimenzij in mer, ki jih združujemo v kocke. Mere predstavljajo vrednosti podatkov, dimenzije pa kategorije, po katerih jih razvrščamo. Dimenzije opredeljujejo njihovi atributi, vsebinsko pa so razdeljene na nivoje, ki se razvrščajo v hierarhije. Struktura večdimenzionalnega podatkovnega modela je prikazana na Sliki 9. Slika 9: Struktura večdimenzionalnega podatkovnega modela Za lažjo predstavo si izberimo realni primer, ki ga bomo uporabljali skozi pregled konceptov tehnologije. Predpostavimo, da nas zanima prodaja podjetja čez čas, glede na vrsto izdelka in lokacijo, kjer se je prodal. Tako lahko definiramo kocko prodaja, z merami vrednost in količina ter dimenzije čas, izdelek ter lokacija. V dimenziji čas definirajmo nivoje leto, četrtletje, mesec in njihovo logično hierarhijo. Tako je sedaj posamezni podatek o vrednosti in količini prodaje v kocki prodaja definiran s podatkom o času prodaje (dimenzija čas), vrsti izdelka (dimenzija izdelek) in krajem (dimenzija lokacija), kjer se je prodal.

29 Sprotna analitična obdelava v izbranem podjetju Stran Notacija Za konceptualno večdimenzijsko modeliranje se uporablja več notacij. Omenimo uporabo UML razrednih diagramov (angl. UML class diagram) ter shemo dejstev (angl. fact schema) [27]. Zaradi splošne razširjenosti klasičnega E/R modela (angl. entity/relationship model) se najpogosteje uporablja t. i. zvezdaer (angl. starer) model, ki poleg obstoječih elementov E/R notacije vključuje še [5]: Ime kocke: Ime mere: Povezavo hierarhija: Slika 10: Primer kocke prodaja v M/ER notaciji Na Sliki 10 je prikazan zvezdaer model našega primera kocke prodaja z ustreznimi merami in dimenzijami.

30 Sprotna analitična obdelava v izbranem podjetju Stran Shema modela Večdimenzionalni model lahko predstavimo z relacijskim modelom, ki ga imenujemo shema modela. Gre za relacije med tabelami, iz katerih zgradimo večdimenzionalni model, hkrati pa je to relacijski model podatkovnega skladišča. V praksi se uporabljata dve shemi, ki sta ime dobili po obliki razporeditve samih tabel: zvezdna shema (angl. star-schema) in snežinkasta shema (snowflake-schema). Zvezdna shema Najpogosteje se uporablja zvezdna shema, ki je sestavljena iz osrednje tabele, imenovane tabela dejstev (angl. fact table) ter zunanjih dimenzijskih tabel (angl. dimensional table). V tabeli dejstev so podatki o merah ter ključi dimenzijskih tabel, v dimenzijskih tabelah pa podatki o dimenzijah, kot je razvidno s Slike 11. DIMENZIJSKA TABELA: Trgovina PK ID TRGOVINA DRUŽBA DIMENZIJSKA TABELA: Čas PK ID DATUM LETO TABELA DEJSTEV - Prodaja PK PRODAJA_ID VREDNOST KOLICINA FK1 ČAS_ID FK2 TRGOVINA_ID FK3 IZDELEK_ID DIMENZIJSKA TABELA: Izdelek PK ID IZDELEK ZNAMKA Slika 11: Primer zvezdne sheme Snežinkasta shema Shema je izpeljana iz zvezdne sheme, le z razliko, da so tabele dimenzij normalizirane. Ker se želimo znebiti redundance v dimenzijskih tabelah, ponavljajoče se atribute prenesemo v pomožne tabele, ki jih z dimenzijsko povežemo preko tujih ključev. Snežinkasta shema se uporablja za zelo obsežne sisteme, zaradi posledično večje kompleksnosti poizvedb se ji poskušamo izogniti.

31 Sprotna analitična obdelava v izbranem podjetju Stran Olap Kocka Olap kocka (angl. cube, multidimensional cube, multicube) je osnovna podatkovna struktura v OLAP sistemu. Predstavlja množico podatkov, ki so shranjeni na večdimenzionalni način, torej v obliki mer in dimenzij, tako da jih lahko analiziramo in predstavimo iz različnih perspektiv (dimenzij) [16]. Slika 12: Kocka prodaja s tremi dimenzijami Na Sliki 12 lahko vidimo kocko prodaja, ki smo jo definirali pri predstavitvi večdimenzionalnega modela. Podatki v merah so v kocki v presečiščih dimenzij. S pomočjo operacij in agregiranih podatkov (koncepta, ki ju bomo podrobno predstavili v naslednjih podpoglavjih) lahko hitro in enostavno pridobimo podrobne ali sumarne podatke glede na poljubno kombinacijo dimenzij. Po navadi je kocka predstavljena v treh dimenzijah, saj si tako lahko najlažje predstavljamo sam koncept, sicer pa je število dimenzij neomejeno, vendar se zaradi preglednosti giblje med 4 in 15 dimenzijami.

32 Sprotna analitična obdelava v izbranem podjetju Stran Mere Mere (angl. measures) ali dejstva (angl. facts) združujejo dejanske podatke dimenzijskega modela, ki jih analiziramo. Tipični primeri mer so že omenjena prodaja ali pa prihodek, strošek, dobiček ipd. Mero bi lahko definirali tudi kot celico (presečišče) dimenzij kocke, vrednost, ki jo lahko ovrednotimo v vsaki točki kocke. Podatki mer se nahajajo v tabeli dejstev sheme večdimenzijskega modela [16]. Poznamo dve vrsti mer: shranjene mere (angl. stored measures), izračunane izpeljane mere (angl. calculated, derived measures). Shranjene mere se preračunavajo in shranjujejo neposredno v podatkovni strukturi (kocki), torej imamo za mero fizični zapis njene vrednosti. Pri izračunanih merah pa se v podatkovni strukturi shrani le način izračuna mere (po navadi iz drugih mer), do samega izračuna pa pride šele ob prikazu oziroma ob izvedbi poizvedbe. Tako izračunane mere ne porabljajo fizičnega prostora kocke, niti jih ni potrebno preračunavati ob polnjenju. Tipični primer izračunane mere je recimo dobiček. Za izračun potrebujemo le vrednosti shranjenih mer prihodek in strošek in enačbo izračuna dobička (dobiček = prihodek strošek). Mere so lahko poljubnega formata, posledično jih delimo na aditivne, poladitivne in neaditivne. Poladitivne so tiste, nad katerimi lahko izvajamo operacije samo glede na nekatere dimenzije. Najenostavnejši primer bi bila mera zaloga na skladišču, kjer imamo dimenzije izdelek, skladišče in čas. V tabeli dejstev imamo zapise posameznih zalog v posameznih skladiščih v določenih časovnih obdobjih. Če seštejemo vse zaloge po skladiščih ali po določenem izdelku v določenem obdobju, dobimo pravilno vrednost zalog za posamezni izdelek (skladišče), v kolikor pa seštejemo zaloge po dimenziji čas, bomo dobili napačen podatek (uporabiti bi morali recimo povprečje itd.). Pri uporabi operacij nad merami moramo biti vedno pozorni na vsebinsko pravilnost modela, saj rešitve včasih na prvi pogled izgledajo pravilno, a so lahko napačne. Neaditivne mere pa so na primer različna razmerja ipd.

33 Sprotna analitična obdelava v izbranem podjetju Stran Dimenzije Dimenzija (angl. dimension) je eden izmed vidikov, po katerem analiziramo podatke oziroma način kategorizacije podatkov, ki skupaj določujejo določen del, vidik analiziranega problema (mere). Praktično pa je to ena izmed dimenzijskih tabel v shemi večdimenzijskega modela. Dimenzijski podatki se načeloma ne spreminjajo pogosto in so napram podatkom v merah občutno manjše velikosti. Dimenzije lahko uporabljamo v poljubnem številu kock (različne tabele dejstev si delijo iste dimenzijske tabele), takšne dimenzije imenujemo deljene dimenzije (angl. shared dimension), v primeru, da pa je določena dimenzija namenjena izključno eni kocki, pa ji pravimo privatna dimenzija (angl. private dimension) [16]. Dimenzija ima atribute, ki jo definirajo. Za naš primer, recimo dimenzije izdelek, bi bil eden izmed atributov na primer naziv izdelka ali pa tip izdelka. Posamezno dimenzijo lahko gledamo tudi skozi različne nivoje abstrakcije oziroma združevanja. Primer za dimenzijo čas: osnovni tip podatka, po katerem je dimenzija definirana je datum, vendar bi pri analiziranju mogoče želeli podatke obravnavati bolj splošno, mogoče nas zanima mesečna prodaja, ali pa prodaja po kvartalih. Zato dimenzije dodatno delimo na nivoje, ki so po navadi tudi hierarhično razvrščeni, oziroma organizirani v logično zaporedje. Obratno bi lahko rekli, da hierarhije delimo na nivoje. Obstajajo pa tudi dimenzije brez hierarhij (angl. flat dimensions), ki imajo le en nivo. Na Sliki 13 vidimo koncept nivojev in njihove hierarhične ureditve na primeru dimenzije izdelek. Slika 13: Hierarhija dimenzije izdelek

34 Sprotna analitična obdelava v izbranem podjetju Stran 25 Dimenzije z več nivoji imajo praviloma eno hierarhijo, vendar to ni pogoj. Odvisno od potreb in praktične izvedbe imamo lahko pri eni dimenziji več hierarhij (različna obravnava istih podatkov, recimo pri časovni dimenziji lahko čas obravnavamo po klasičnem koledarju, za finančne analize pa po finančnem koledarju Slika 14). Slika 14: Dve različni hierarhiji iste dimenzije čas Poznamo dva osnovna tipa hierarhij [25]: uravnotežene hierarhije (angl. balanced hierarchies), neuravnotežene hierarhije (angl. unbalanced hierarchies). Slika 15: Uravnotežena in neuravnotežena hierarhija

35 Sprotna analitična obdelava v izbranem podjetju Stran 26 Pri uravnoteženi hierarhiji vsak nivo predstavlja isti tip informacije, kjer so vsi pripadniki istega nivoja logično ekvivalentni. Pri neuravnoteženi hierarhiji pa na istem nivoju ni logične povezanosti. Praviloma tudi vse veje neuravnotežene hierarhije niso iste globine. Razliko med tipoma vidimo na Sliki 15, kjer je kot primer neuravnotežene hierarhije prikazana organizacijska struktura. Člani istega nivoja so sicer hierarhično na isti stopnji, vendar vsebinsko niso ekvivalentni (tajnica-direktor). Omenimo še pogosti podtip uravnotežene hierarhije: v primeru, da za posamezen nivo v specifičnih primerih v hierarhiji nimamo podatka, govorimo o tako imenovani pomanjkljivi nivojski hierarhiji (angl. ragged hierarchy). Primer bi bila hierarhija kontinent-država-zvezna država-mesto v ZDA in Sloveniji (Slika 16). Slika 16: Pomanjkljiva nivojska hierarhija Kot smo omenili, se dimenzije načeloma ne spreminjajo, vendar imamo tudi tu izjeme, kjer glede na vrsto sprememb poznamo naslednje dimenzije: ne zanima nas prejšnje stanje; počasno spreminjanje, majhne dimenzije; hitro spreminjanje, velike dimenzije; neprestane spremembe.

36 Sprotna analitična obdelava v izbranem podjetju Stran 27 Kako spremeniti dimenzijske podatke, da imamo s spremembami čim manj dela in da je zagotovljena pravilnost in konsistenca podatkov? Pri prvi in zadnji vrsti sprememb je rešitev enostavna. V kolikor ne potrebujemo starih podatkov, se lahko celotna dimenzija prepiše in se uporabljajo novi podatki. Pri neprestanih spremembah, pa je pametno dimenzijo spremeniti v mero in jo obravnavati kot navadne mere. Pri ostalih dveh vrstah pa se po navadi poslužujemo enega izmed naslednjih principov: Uvedba novega atributa, praviloma se trenutna vrednost zapiše v nov atribut (old_), nova pa v obstoječega (uporablja se v primeru, da ne potrebujemo časovne sledi). Spremembe so novi zapisi v dimenziji (drug primarni ključ), zagotovljena je popolna časovna sled (generalizacija ključa). Uvedba dodatne dimenzije, določene atribute dimenzije izločimo v novo dimenzijo, v tabeli dejstev imamo dodaten ključ za novo dimenzijo. Različne različice združenih zgornjih pristopov (recimo uvedba nove dimenzije, vendar v izvorni še vedno hranimo zadnje podatke o izločenih atributih ipd.).

37 Sprotna analitična obdelava v izbranem podjetju Stran Operacije tehnologije OLAP Kot smo videli v prejšnjih podpoglavjih, so podatki v kockah organizirani v obliki mer in dimenzij. Še vedno pa ne vemo, kako priti do specifičnih podatkov, ki nas zanimajo. Kako iz kocke pridobiti podatke na način, da nam bodo odgovorili na analitična vprašanja, ki se pogosto pojavljajo v podjetjih? Za izvajanje poizvedb nad podatki v kocki in njihov ustrezen prikaz se uporabljajo različne operacije OLAP, ki nam omogočajo manipulacijo podatkov in raznovrstne poglede in primerjave. Različna orodja omogočajo različno uporabo operacij, vsem pa je skupen osnoven princip. Oglejmo si osnovne operacije tehnologije OLAP ter poskušajmo njihove rezultate prikazati na enostavnih primerih kocke prodaja. Osnovne operacije so [8]: vrtanje navzdol, zvijanje navzgor, rezanje, vrtenje, vrtanje preko, primerjave, izračuni, izjeme in agregiranje Vrtanje navzdol Vrtanje navzdol (angl. drill-down) je v osnovi operacija, ki nam iz splošnejših podatkov prikaže bolj podrobne. V primeru naše kocke prodaja bi operacija vrtanje navzdol nad dimenzijo čas prikazala podrobnejše podatke o prodaji za izbrano leto. V Tabeli 2 so prikazani začetni sumarni podatki prodaje po letih, v Tabeli 3 pa vidimo rezultat operacije, kjer je prodaja po letu 2009 razdrobljena na posamezne kvartale, hkrati pa vidimo podatke o prodaji posameznih izdelkov. Praktično pa to z vidika dimenzijskega modela pomeni bodisi pomik navzdol po hierarhiji dimenzije, bodisi "dodajanje" nove dimenzije (dodatna omejitev prikaza podatkov, torej izbira prikaza specifičnega izdelka). Specifična operacija vrtenja navzdol je operacija vrtanja skozi, pri kateri pridemo do elementarnih podatkov, ki predstavljajo en zapis v tabeli dejstev.

38 Sprotna analitična obdelava v izbranem podjetju Stran 29 Tabela 2: Primer prikaza kocke prodaja po dimenziji čas Čas Vrednost Količina Tabela 3: Primer prikaza kocke prodaja po operaciji vrtanje navzdol (podrobnejši prikaz po dimenzijah čas (za leto 2009) in dodajanje dimenzije izdelek) Čas/Izdelek DVD CD TV Vrednost Količina Vrednost Količina Vrednost Količina Q Q Q Q Zvijanje navzgor Zvijanje navzgor (angl. drill-up) je obratna operacija operacije vrtanja navzdol. Torej pomik od podrobnih podatkov k bolj splošnim (pomik navzgor po hierarhiji dimenzije oziroma "odvzemanje" dimenzije) Rezanje Rezanje (angl. slice and dice) je operacija, s katero dobimo podmnožico kocke z rezanjem kocke na rezine. Praktično to pomeni fiksiranje ene ali več dimenzij. Če fiksiramo eno dimenzijo, govorimo o rezini podatkov (angl. slice), v kolikor pa več dimenzij, pa o večdimenzionalni rezini (angl. dice). S fiksiranjem dimenzije dejansko izberemo specifičen podatek in opazujemo vrednosti po preostalih dimenzijah. Na Sliki 17 lahko vidimo slikovni prikaz operacije rezanja s fiksiranjem različnih podatkov dimenzij. Pri prvem primeru smo izbrali samo podatke o prodaji iz lokacije LJ. Pri drugem pa smo lokacije razširili še s KP ter dodatno omejili čas prodaje.

39 Sprotna analitična obdelava v izbranem podjetju Stran 30 Slika 17: Operacija rezanja nad kocko prodaja Vrtenje Operacija vrtenja (angl. pivot) spremeni oblikovni videz poročila z rotiranjem osi podatkov. V bistvu gre za podoben princip, kot je menjava osi v klasičnih vrtilnih tabelah. Operacija ne prikazuje drugih podatkov, le zamenja pogled na njih. V Tabelah 4 in 5 lahko vidimo primer uporabe operacije. Tabela 4: Primer prikaza kocke prodaja po dimenziji čas in izdelek Čas/Izdelek DVD CD TV GSM Tabela 5: Primer operacije vrtenje nad podatki iz Tabele 4 Izdelek/Čas DVD CD TV GSM

40 Sprotna analitična obdelava v izbranem podjetju Stran Vrtanje preko Pri vrtanju navzdol smo se pomikali po vertikalni osi dimenzijskega modela, pri vrtanju preko pa se pomikamo po horizontalni osi. Vrtamo lahko preko dimenzij ali preko mer. Poglejmo si vrtanje preko dimenzij na primeru prodaje. Če nas zanima prodaja glede na izdelek, hitro ugotovimo, da se tip izdelka CD prodaja najslabše. Verjetno bomo omejili ponudbo tega izdelka, vendar nas pred tem zanima, ali je prodaja enako slaba na vseh področjih. Zato želimo iste podatke analizirati še skozi dimenzijo kraj, da bomo lahko ponudbo izdelka bolj učinkovito omejili glede na povpraševanje. Praktični primer uporabe operacije je prikazan v Tabelah 6 in 7. Podobno je vrtanje preko mer, le da tu nad določenim aspektom podatkov ne gledamo iz druge dimenzije, pač pa tudi preko druge mere, ki je lahko tudi v drugi kocki, pri čemer je pogoj, da ima iste dimenzije kot kocka, iz katere izvajamo operacijo. Operacija je koristna, saj pogosto želimo ugotovljene lastnosti analizirati skozi različne zorne kote (za naš primer bi recimo poleg mere prodaja bila zanimiva tudi mera stroškov, zaposlenih itd.) Tabela 6: Sumarna prodaja po letih, vrednost prodaje izdelka CD najmanjša Čas/Izdelek DVD CD TV Vrednost Količina Vrednost Količina Vrednost Količina Skupaj: Tabela 7: Izvedena operacija vrtanje preko iz dimenzije čas na lokacija Lokacija/Izdelek DVD CD TV Vrednost Količina Vrednost Količina Vrednost Količina LJ KP MB CE Skupaj:

41 Sprotna analitična obdelava v izbranem podjetju Stran Primerjave, izračuni, izjeme in agregiranje Na koncu omenimo še nekaj za OLAP manj specifičnih operacij, ki pa se tudi uporabljajo pri analiziranju podatkov OLAP kock in uporabnikom zelo pomagajo pri analizah. Pri primerjavah imamo v mislih primerjave podatkov med in po različnih dimenzijah. Najbolj reprezentativen primer bi bila primerjava podatkov po časovni dimenziji. Zanima nas recimo primerjava prodaje med dvema letoma (četrtletjema ipd.). Pogosto se pri prikazu podatkov uporabljajo končne in delne vsote, ki se lahko nanašajo bodisi na izbrane dimenzije ali celotne kocke, recimo skupna vsota prodaje. Izračunavanju teh vsot pravimo agregiranje podatkov. Za lažjo in boljšo predstavitev podatkov uporabljamo različne izračune, pogosto nas zanimajo razni deleži posameznih vrednosti ali pa bolj specifične enačbe, ki so lahko poljubno kompleksne. Za lažje in hitrejše analize se uporablja tudi operacija prikaza izjem, ki končnim uporabnikom nazornejše prikaže podatke, ki so različni od pričakovanih. Za določanje izjem se uporabljajo različne statistične metode, ki jih lahko tudi ustrezno prilagodimo, da ustrezajo specifičnim potrebam. Tabela 8: Prikaz operacij primerjave, izračuna izjeme in agregiranja Izdelek CD Lokacija/Čas Razlika Odstotek LJ ,5 % KP % MB ,9 % CE % Skupaj: % Na primeru kocke prodaja smo v Tabeli 8 izvedli operacijo primerjanje nad dimenzijo izdelek po dimenziji lokacija za dimenzijo čas. Izračunali smo razliko med prodajo v letih 2008 in 2009 ter odstotek razlike med njima. S pomočjo prikaza izjem smo jasno izpostavili največja odstopanja med prodajo v obeh letih ter vse podatke sešteli po dimenziji lokacija.

42 Sprotna analitična obdelava v izbranem podjetju Stran Shranjevanje in procesiranje podatkov Kot smo ugotovili v podpoglavju 3.2, je osnovna podatkovna struktura tehnologije OLAP večdimenzijska kocka, ki je sestavljena iz mer ter dimenzij. Ko se vedno bolj približujemo dejanskim orodjem in implementacijam tehnologije OLAP, moramo kocko definirati nekoliko širše, saj različni načini izvedbe OLAP sistemov na različne načine hranijo in obdelujejo podatke, ki jih potrebujejo za izvrševanje povpraševanj uporabnikov. Tako si kocko predstavljajmo kot koncept iz večdimenzionalnega podatkovnega modela, ki je lahko fizično implementiran na poljuben način. Podatki, ki jih bo sistem uporabil za analizo, so lahko locirani na poljubni lokaciji v poljubnem sistemu. OLAP sistem mora sam poskrbeti, da bodo podatki ob povpraševanju uporabnika ustrezno obdelani in predstavljeni na pravilen način. Različne pristope hrambe in obdelave podatkov za dosego želenih ciljev OLAP sistemov bomo predstavili v nadaljevanju. Na splošno procesu zajemanja podatkov iz izvornega sistema in shranjevanju/organiziranju v OLAP kocko pravimo procesiranje kocke (angl. data cube processing). Poenostavljeno lahko rečemo, da obstajata dva osnovna načina procesiranja: polno procesiranje (angl. full processing), prirastno procesiranje (angl. incremental processing). Pri polnem procesiranju ob vsaki izvedbi procesiranja se vsi podatki v kocki zbrišejo in ponovno shranijo/organizirajo v kocko. Pri prirastnem procesiranju pa se dodajajo samo novi podatki, ki so se v izvornem sistemu dodajali/spremenili od zadnjega procesiranja kocke [25] Agregiranje Že pri večdimenzionalnem modelu in operacijah smo omenjali agregacije oziroma agregiranje. Agregacije (angl. agregations) so osnovni koncept OLAP tehnologije in osnova za hitro poizvedovanje nad podatki. Povedano enostavno so agregacije vnaprej izračunani in shranjeni podatki mer iz kombinacij nivojev dimenzij. Za nazoren primer zopet uporabimo kocko Prodaja. Za izdelek DVD nas zanima skupna prodaja v letu Za odgovor na to vprašanje bi najprej iz tabele dejstev (v najslabšem primeru) izbrali vse izdelke DVD, nato pa bi morali izločiti še vse transakcije, ki niso bile opravljene leta 2009 ter sešteti vrednost prodanih izdelkov. Torej, kar precej operacij primerjanja in seštevanja

43 Sprotna analitična obdelava v izbranem podjetju Stran 34 in kar je najpomembneje: procesiranja v času izvajanja poizvedbe, ko uporabnik želi odgovor čim hitreje. Namesto tega lahko vse procesiranje opravimo predhodno in ob poizvedbi samo poiščemo želeno agregacijo. Tako si pri našem primeru za vsa leta predhodno izračunamo in shranimo podatke o prodaji posameznega izdelka, ki se ob poizvedovanju lahko potem prikažejo v trenutku. Seveda že pri našem poenostavljenem primeru hitro ugotovimo, da pri velikem številu podatkov število agregacij začne hitro naraščati. Število agregacij a narašča po enačbi: a = n i= 1 l i kjer je: n l - število dimenzij - število nivojev i-te dimenzije Popolno agregiranje tako ni smiselno in v realnih primerih niti ni izvedljivo, saj bi za izračun in hrambo porabili preveč časa in prostora (pojav se imenuje eksplozija agregatov). Tako se agregirajo samo določeni nivoji, ostali pa se potem izračunavajo iz preostalih. Za optimalno delovanje je potrebno najti ustrezno ravnovesje med hitrostjo povpraševanj in številom agregatov (angl. view selection problem) [29] Tipi arhitektur OLAP sistemov Tipe arhitektur OLAP sistemov razlikujemo glede na mesto hranjenja in obdelave podatkov, ki jih analiziramo [28], pri čemer gre omeniti, da gre pri dejanskih implementacijah sistemov po navadi za uporabo mešanice večih arhitektur. Glede na mesto hrambe podatkov obstajajo tri različne možnosti: relacijska podatkovna baza (angl. relational database), večdimenzionalna podatkovna baza (angl. multidimensional database), datoteke pri odjemalcu (angl. client-based files).

44 Sprotna analitična obdelava v izbranem podjetju Stran 35 Podatki so torej lahko shranjeni v denormaliziranih tabelah na klasičnih relacijskih podatkovnih bazah, ki jih upravljajo SUPB - sistemi za upravljanje podatkovne baze (angl. RDBMS relational database management system). Najpogosteje uporabljena možnost je shranjevanje v večdimenzionalnih podatkovnih bazah, zasnovanih in optimiziranih posebej za hrambo večdimenzijskih struktur. Tretja možnost pa je uporaba manjših gruč podatkov na odjemalčevem sistemu (zunanji ali delovni pomnilnik), ki se pridobijo pred analizo. Podobno tudi za mesto obdelave podatkov poznamo tri možnosti: relacijski SUPB (angl. RDBMS-SQL), strežniški večdimenzionalni obdelovalec (angl. multidimensional server engine), odjemalčev večdimenzionalni obdelovalec (angl. client multidimensional engine). Za obdelavo se uporaba klasičnega SQL-a po navadi izkaže za neučinkovito, vendar se kljub temu uporablja, najpogosteje za predpripravo podatkov. Tako se večdimenzionalna obdelava najbolj pogosto izvaja bodisi na strežniku bodisi pri odjemalcu, pri čemer je pomembno, da je za izvajanje na voljo dovolj sistemskih resursov (procesorska moč in delovni pomnilnik) ter ustrezna povezava z virom hrambe podatkov. Vseh 9 možnih kombinacij sestavlja matriko različnih arhitektur, ki pa za določene kombinacije ni smiselna (recimo hramba podatkov pri odjemalcu, obdelava pri strežniškem večdimenzionalnem obdelovalcu). Matrika arhitektur je prikazana v Tabeli 9. Tabela 9: Matrika različnih arhitekturnih možnosti OLAP sistemov Relacijska podatkovna baza Večdimenzionalna podatkovna baza Datoteke pri odjemalcu Relacijski SUPB Strežniški večdimenzionalni obdelovalec Odjemalčev večdimenzionalni obdelovalec

45 Sprotna analitična obdelava v izbranem podjetju Stran 36 Tako lahko iz smiselnih šestih kombinacij definiramo štiri arhitekture OLAP sistemov, ki so na Sliki 18 prikazani s svojo glavno značilnostjo: ROLAP Relational OLAP (1,4 in 7) MOLAP Multidimensional OLAP (5 in 8) HOLAP Hybrid OLAP (4 in 5) DOLAP Desktop OLAP (9) Slika 18: Tipi arhitektur tehnologije OLAP ROLAP sistemi ali relacijski OLAP sistemi črpajo podatke iz relacijskih podatkovnih baz. Prednost ROLAP sistemov je zmožnost obdelave velikih količin podatkov, vendar je njihova implementacija zahtevna in časovno potratna. Njihova največja pomanjkljivost je počasnost in nezmožnost izvajanja zahtevnejših operacij (zgolj funkcionalnosti SQL-a). Ravno zaradi teh razlogov se po navadi uporabljajo zgolj kot pasivno orodje za poročanje, ne pa kot interaktivni analitični sistem, ki se odziva na zahteve uporabnika.

46 Sprotna analitična obdelava v izbranem podjetju Stran 37 MOLAP ali večdimenzijski OLAP sistemi hranijo večdimenzijsko organizirane podatke v večdimenzionalni podatkovni bazi. Omogočajo hitro izvajanje zahtevnejših operacij. Večdimenzijski OLAP sistemi so najpogosteje uporabljeni sistemi OLAP tehnologije. Zaradi drugačne organizacije podatkov postavitev MOLAP sistemov zahteva fizično podvajanje podatkov in dodatno vlaganje v opremo in človeške vire za informacijsko podporo in razvoj sistema. HOLAP ali hibridni OLAP sistemi so mešanica ROLAP in MOLAP sistemov. Poskušajo izrabiti prednosti obeh tipov ter izničiti njune pomanjkljivosti. DOLAP ali namizni OLAP sistemi hranijo in obdelujejo podatke na odjemalčevi strani. Posledično imajo omejeno funkcionalnost in kapaciteto napram zgoraj omenjenim sistemom. Kljub temu so primerni za obdelavo podatkov v manjših obsegih, njihova prednost pa je enostavnost namestitve in uporabe ter ugodna cena. V literaturi pogosto zasledimo tudi delitev arhitektur OLAP glede na lokacijo hrambe agregatov, kar je v bistvu poenostavitev zgoraj opisane delitve. Kot smo razložili v prejšnjem podpoglavju, se agregati izračunajo iz vnesenih podatkov ob vnosu podatkov. Tako lahko rečemo, da hranjene podatke delimo na dva tipa: vhodni (osnovni) podatki, agregirani podatki. Glede na to, kako pri OLAP sistemih shranjujemo ta dva tipa podatkov, tako ločimo tri arhitekture sistemov: MOLAP shranjuje oba tipa v večdimenzionalni podatkovni bazi, ROLAP shranjuje oba tipa v relacijski podatkovni bazi, HOLAP pa shranjuje vhodne podatke v relacijski bazi, agregacije pa v večdimenzionalni podatkovni bazi.

47 Sprotna analitična obdelava v izbranem podjetju Stran Povpraševalni jezik MDX MDX (angl. MultiDimensional expressions) je povpraševalni jezik, namenjen večdimenzijskim OLAP analitičnim sistemom. V osnovi je zelo podoben SQL-u (angl. Structured Query Language), ki se uporablja za povpraševanje po klasičnih relacijskih podatkovnih bazah. SQL vrača rezultate poizvedb v obliki tabel, MDX pa v obliki kock. Prvič je bil predstavljen leta 1997 kot del Microsoftovega OLE DB for OLAP (ODBO), zato ni presenetljivo, da je sintaksa jezika tudi zelo podobna sintaksi formul Microsoftovih preglednic. Sčasoma je jezik prevzelo vedno več proizvajalcev OLAP orodij in ta trenutek predstavlja de facto standard za povpraševanja v OLAP sistemih. Kompleksnost jezika presega zastavljeni obseg diplomskega dela, zato bomo tematiko zgolj povzeli [19]. Splošna sintaksa poizvedbe jezika MDX sestoji iz štirih osnovnih stavkov (angl. clause), neobvezne dele sintakse poizvedbe bomo označili z oglatimi oklepaji, z velikimi tiskanimi črkami pa bomo navajali rezervirane besede: [WITH [MEMBER <naziv člana> AS '<vrednost ali izraz >' SET <naziv nabora> AS{ '<specifikacija nabora>}']...] SELECT <specifikacija osi> [, <specifikacija osi>...] FROM <specifikacija kocke> [WHERE <specifikacija izseka> [<specifikacija izseka> ]] Z jezikom MDX povprašujemo v izbrani kocki po različnih dimenzijah ter kot rezultat dobimo vrednosti izbranih mer. Uporabljamo lahko vse operacije, ki smo jih omenili v podpoglavju 3.3. Poizvedba sestoji iz rezerviranih besed, ki jih ne smemo uporabljati v druge namene (recimo poimenovanje osi, naborov ipd.) in izgleda nekako takole: SELECT os1 ON COLUMNS, os2 ON ROWS FROM kocka WHERE mera, dimenzija

48 Sprotna analitična obdelava v izbranem podjetju Stran 39 S stavkom SELECT definiramo, po katerih dimenzijah oseh (angl. axis) naj se vrnejo rezultati. Načeloma je lahko število osi neomejeno, vendar se po navadi uporablja dvodimenzionalni način prikaza, ki nam je najbolj domač, za prikaz po več kot dveh dimenzijah pa se uporablja gnezdenje (angl. nesting). Za definicijo osi obstaja več načinov, najpreprostejši je prikaz po vseh članih (angl. members) dimenzije, opcijsko lahko navedemo tudi posamezne nivoje dimenzije, kar zapišemo na naslednji način: <ime_dimenzije>.[<ime_nivoja>].members Spoznali smo, kako definiramo vse člane dimenzije (nivoja dimenzije), vendar pa včasih želimo izbrati samo posamezne člane, kar storimo z naštevanjem (angl. enumeration) posameznih članov, ki jih zapišemo v zavite oklepaje in ločimo z vejico (ker so lahko imena članov dvoumna (imena, številke ali rezervirane besede), se v praksi zapisujejo v oglatih oklepajih, česar mi zaradi uporabe oglatih oklepajev za označbo neobveznih delov sintakse jezika ne bomo uporabljali): {<ime_dimenzije>. <ime_člana1>, <ime_dimenzije>.<ime_člana2>, } Poseben primer definicije posamezne osi je uporaba n-teric (angl. tuple), s katerimi lahko eni osi priredimo kombinacijo več dimenzij oziroma njihovih članov, kar si lahko predstavljamo podobno kot operacijo rezanja (fiksiranje dimenzij). Struktura vsake n-terice (rezine) mora biti vselej enaka. Posamično n-terico zapišemo v navadnih oklepajih, člane dimenzij pa ločimo z vejicami: (<ime_člana_dimenzije1>, <ime_člana_dimenzije2>, ) V stavku FROM definiramo, katera kocka naj se uporablja za povpraševanje. V jeziku MDX se za eno povpraševanje lahko uporablja samo ena kocka. S stavkom WHERE omejimo podatke poizvedbe bodisi po merah bodisi dimenzijah. Stavek je neobvezen, v primeru, da ga ne navedemo, se uporabijo privzete mere in vsi podatki. Dejansko gre pri omejitvi podatkov za operacijo rezanja, kjer za analiziranje izbiramo samo del podatkov kocke. Sintaksa je enaka sintaksi n-terice, saj je v bistvu uporabljena ista operacija: (<ime_člana_dimenzije1>, <ime_člana_dimenzije2>, [Measures.<ime_mere>])

49 Sprotna analitična obdelava v izbranem podjetju Stran 40 Stavek WITH je neobvezen in se uporablja za izračunane člane (angl. calculated members) in nabore članov (angl. sets), ki jih lahko kasneje uporabljamo v stavkih SELECT in WHERE ter tako izboljšamo analizo ali pa samo poenostavimo poizvedbo. Izračunani člani se uporabljajo za izračunane mere, ki jih dobimo iz obstoječih mer (recimo dobiček: dobiček = prihodek strošek). Izračunano mero potem uporabljamo kot normalno mero iz kocke, naslavljamo pa jo z imenom, ki smo ga navedli ob definiciji. Nabori članov pa so v bistvu množice n-teric z isto strukturo, ki jim dodelimo ime in s tem olajšamo in poenostavimo uporabo. Uporablja se sintaksa naštevanja z zavitimi oklepaji. Jezik MDX vsebuje veliko število funkcij za delo z večdimenzijskimi podatki, ki nam olajšajo delo s kocko. Naštejmo nekaj skupin funkcij ter njihovih primerov: dimenzijske, hierarhične in nivojske funkcije (CURRENTMEMBER, PARENT), numerične funkcije za preračunavanje mer (SUM, COUNT), logične funkcije (AND, OR), funkcije za delo z nizi znakov (FORMAT_STRING), ostale funkcije (CROSSJOIN, UNION). Za lažjo predstavo si oglejmo še praktični primer uporabe jezika MDX. Za našo kocko Prodaja nas zanima povprečna vrednost enote izdelka v zadnjih treh letih, vendar samo za prodajo v Mariboru. Zgradimo enostavno MDX poizvedbo, ki nam bo odgovorila na zgoraj zastavljeno vprašanje. Da bomo lahko izračunali vrednost enote izdelka, bomo najprej delili skupno vrednost prodaje posameznega izdelka s prodano količino, to bomo storili v stavku WITH. Hkrati bomo uporabili funkcijo za delo z nizi znakov FORMAT_STRING, da bo vrednost izraza zaokrožena na dve decimalki. Na os X bomo priredili posamezne izdelke, na os Y pa dimenzijo časa. Pri izdelkih bomo z uporabo rezervirane besede MEMBERS prikazali vse člane dimenzije, za dimenzijo čas pa bomo uporabili naštevanje in prikazali zadnja tri leta. Podatke bomo črpali iz kocke Prodaja, kar bomo definirali v stavku FROM. Na koncu pa še rezanje podatkov po lokaciji MB iz dimenzije Lokacija ter izbira prikaza izračunane mere VrednostEnote.

50 Sprotna analitična obdelava v izbranem podjetju Stran 41 Na primeru kocke Prodaja povpraševanje in njen rezultat, ki smo ga predstavili kar v tabelarični obliki v Tabeli 10, izgledata takole: WITH MEMBER Measures.VrednostEnote AS 'Measures.Vrednost % Measures.Količina ', FORMAT_STRING = '#.## ' SELECT Izdelki.MEMBERS ON COLUMNS, {Čas.[2008], Čas.[2009], Čas.[2010]} ON ROWS FROM Prodaja WHERE ( Lokacija.[MB], Measures.VrednostEnote ) Tabela 10: Prikaz rezultata povpraševanja MDX nad kocko Prodaja Lokacija MB Čas/Izdelek DVD CD TV GSM ,50 364,00 710,50 0, ,50 354,50 615,50 0, ,00 340,00 775,00 231, ,00 350,00 600,00 112,50 Na koncu omenimo, da za OLAP povpraševanja obstajajo tudi drugi načini (po navadi posebnosti posameznih orodij), med katerimi naštejmo najpogosteje uporabljene: XMLA - XML for Analysis, ODBO - OLE DB for OLAP in že omenjeni SQL in shranjene procedure (angl. stored procedures).

51 Sprotna analitična obdelava v izbranem podjetju Stran Področja uporabe Orodja OLAP tehnologije se uporabljajo na vseh področjih, kjer se pojavljajo potrebe po analiziranju in obdelovanju velikih količin podatkov iz različnih zornih kotov. Navedimo nekaj tipičnih primerov uporabe tehnologije [28]: Marketinška in prodajna analiza (angl. marketing and sales analysis) je področje, ki ga uporablja večina podjetij, po večini pa ni pokrito tako dobro, kot bi si v samih podjetjih želeli. Na splošno bi lahko področje razdelili na tri glavne panoge, ki imajo specifične lastnosti in analitične potrebe: proizvodnja in ponudba storitev, trgovina ter finančne storitve. Prednost dobre marketinške in prodajne analitike je boljši vpogled v prodajo, lažje predvidevanje trendov, enostavnejše odkrivanje priložnosti in nenazadnje izboljšana produktivnost. Analiza uporabniške dejavnosti (angl. clickstream analysis) je eno izmed področij uporabe, ki prihaja vedno bolj do izraza, saj se delež poslovanja na internetu ves čas vztrajno povečuje. Pri analizi uporabniške dejavnosti gre za spremljanje in analiziranje obnašanja uporabnikov na spletnih straneh. Iz množice podatkov se poskuša pridobiti in uporabiti informacije, kot so recimo: lokacije dostopa, čas dostopa, razumljivost navigacije in vsebine, zanimivost/obiskanost posameznih delov strani itd. Finančno poročanje (angl. financial reporting) je široko področje, ki se bolj ali manj informacijsko pokrito izvaja v vsakem podjetju. Zaradi svoje specifike in zakonsko predpisanih zahtev se pri finančnih poročilih uporabljajo namembne aplikacije, ki so zasnovane posebej za finančno poročanje. Že v osnovi so finančna poročila dimenzijsko zasnovana: obdobja, kontni načrt, organizacijska struktura, tipi računov so značilne dimenzije, s katerimi imamo opravka pri finančnem poročanju in glede na katere se izvajajo vse analize. Vodstveno poročanje (angl. management reporting) združuje podatke več področij poslovanja in jih predstavi v obliki informacij, s katerimi se lahko lažje, hitreje in bolje sprejemajo poslovne odločitve. Vse bolj uporabljeni so direktorski poslovni sistemi (angl. EIS - executive information systems), ki vodstvenemu kadru na pregleden način (ključni kazalci poslovanja, preglednice, grafi) postrežejo z relevantnimi podatki poslovanja.

52 Sprotna analitična obdelava v izbranem podjetju Stran Orodja in proizvajalci Vrednost trga produktov OLAP tehnologije je v zadnjih 15 letih v stalnem porastu, saj se podjetja vedno bolj zavedajo prednosti, ki jih prinaša informacijsko podprto poslovno odločanje. Na Sliki 19 vidimo konstantno letno rast tržne vrednosti OLAP produktov [2]. Slika 19: OLAP tržna vrednost v milijardah ameriških dolarjev Izbira OLAP orodja na prvi pogled ne predstavlja velike težave, saj je na trgu na voljo precej proizvajalcev s širokim spektrom orodij. Podjetja po navadi največjo skrb dajejo varnosti naložbe, predvsem v smislu trdnosti podjetja na trgu, saj prevzemi ali propadi proizvajalcev po navadi pomenijo ponovne investicije in dolgotrajne procese migracije. Glede na preteklo dogajanje in veliko konsolidacijo trga OLAP tehnologij leta 2007 je skrb na mestu. Preden se odločimo za specifičen produkt določenega prodajalca, si moramo odgovoriti na nekaj vprašanj, ki nam lahko do neke mere zagotovijo varnost [2]: Ima orodje funkcionalne in tehnološke prednosti pred konkurenco? Je orodje eden glavnih delov proizvajalčeve ponudbe? Je orodje vidno na proizvajalčevi spletni strani, predstavitvah, oglaševanju? Se orodje sklada z osnovno vizijo in prodajno strategijo proizvajalca? Ima proizvajalec na tem področju prekrivajoče se produkte? Proizvajalec vlaga v razvoj in izboljšave orodja, ali samo nudi podporo?

53 Sprotna analitična obdelava v izbranem podjetju Stran 44 V primeru, da smo na vprašanja odgovorili pritrdilno, lahko rečemo, da je naložba v proizvajalčevo orodje varna. Pomembno je tudi dejstvo, da pri izbiri OLAP orodja, sama velikost proizvajalca ne pomeni nujno tudi varnosti naložbe. Poleg trdne pozicije orodja na trgu so pri izbiri odločilni tudi naslednji vsebinski faktorji: funkcionalnost in enostavnost orodja; možnost integracije in povezljivost z ostalimi orodji in sistemi; dobre performančne lastnosti (količina podatkov, hitrost, število uporabnikov); tehnična podpora in pomoč proizvajalca (pred, med in po implementaciji); zanesljivost in razširljivost; vrsta platforme; cena. Zgolj informativno si na kratko poglejmo največje proizvajalce in najpomembnejše produkte tehnologije OLAP. Kot lahko vidimo na Sliki 20, pri proizvajalcih primat še vedno drži Microsoft, vendar se mu po velikih združitvah približuje tudi Oracle [2]. Slika 20: Tržni delež podjetij tehnologij OLAP

54 Sprotna analitična obdelava v izbranem podjetju Stran 45 Pri orodjih naštejmo pomembnejše OLAP strežnike ter navedimo njihove proizvajalce z njihovimi spletnimi stranmi, kjer si lahko ogledamo podrobnosti o samih produktih [6]. Tabela 11: OLAP strežniki OLAP strežnik Proizvajalec Spletna stran Microsoft Analysis Services Microsoft Essbase Oracle TM1 IBM www-01.ibm.com/software/data/cognos Mondrian OLAP server Pentaho mondrian.pentaho.org Palo Jedox Oracle Database OLAP Option Oracle Microstrategy OLAP Services Microstrategy SAS OLAP Server SAS Institute

55 Sprotna analitična obdelava v izbranem podjetju Stran 46 4 PRIMER SPROTNE ANALITIČNE OBDELAVE V nadaljevanju si oglejmo še testni primer uporabe tehnologije OLAP. V podjetju Unior d.d. se je po uvajanju direktorskega poslovnega sistema pojavila želja po preučitvi tehnologije OLAP ter njene podpore s strani podatkovnih baz podjetja Oracle. Kot zaposleni v informacijskem oddelku podjetja sem se v okviru diplomskega dela odločil posvetiti tej nalogi. 4.1 Predstavitev podjetja Unior d.d. je med največjimi in izvozno najpomembnejšimi slovenskimi podjetji. Znano je kot čvrsto, na zunanji trg usmerjeno podjetje, z urejeno proizvodnjo in usposobljenim, z izkušnjami bogatim kadrom. Sedež in glavni obrat podjetja je v Zrečah. Družba z osnovnim kapitalom pribl. 23 milijonov evrov zaposluje okoli 2000 delavcev. Slika 21: Lokacija sedeža podjetja Podjetje, ki se je na začetku imenovalo Štajerska železoindustrijska družba z omejeno zavezo, je bilo ustanovljeno leta 1919 in je nadaljevalo tradicijo prvih železarn (fužin) s tega področja, ki so delovale že v 18. stoletju. Med vojno je bilo podjetje požgano, a se je obnovilo in po njej prešlo v družbeno last. Sledila je temeljita rekonstrukcija tovarne in

56 Sprotna analitična obdelava v izbranem podjetju Stran 47 oblikovanje še danes vodilnih programov družbe: izdelave orodja in utopnega kovanja odkovkov. V 70-letih se je podjetje preimenovalo v Unior, tovarna kovanega orodja Zreče (ime je skovanka besedne zveze univerzalno orodje) in to ime nosi še danes. Hkrati je pričelo z dejavnostjo v turizmu. Sredi 70-ih se je začela izgradnja turistične ponudbe na Rogli, nekaj let kasneje pa še Zdravilišča Terme v samih Zrečah. V nadaljnjih letih se je uveljavilo kot pomemben partner evropske avtoindustrije ter razširilo prodajo orodja po celem svetu, hkrati pa iskalo možnosti tudi v drugih dejavnostih. Teženje k stabilnemu in uspešnemu sistemu je vodilo v diverzifikacijo prodajno-proizvodnih programov in tako sedaj družba zajema širok spekter produktov in storitev. Prodajno-proizvodni programi podjetja so razdeljeni v 4 skupine: Odkovki, Ročno orodje, Strojegradnja, Turizem. Odkovki ustvarjajo največji delež prodaje in izvoza med programskimi enotami družbe Unior. Temeljna dejavnost programa je utopno kovanje jekla, ki ga dopolnjujeta strojna obdelava odkovkov in proizvodnja sintranih delov iz kovinskih prahov. Program ročnega orodja, ki obsega več kot 3000 različnih izdelkov, je rezultat bogate tradicija orodnega kovaštva, upoštevanje novih tehnoloških dognanj in uporaba vrhunskih materialov, kot sta krom in vanadijevo jeklo. Unior d.d. se uveljavlja tudi kot vse uglednejši ponudnik strojegradnje, ki je podprta z namenskimi CNC obdelovalnimi stroji, CAD projektiranjem, s preciznimi proizvodnimi procesi ter zagotovljeno montažo in servisnimi storitvami. Med pomembnejšimi programi družbe pa je tudi turizem, ki se od sedemdesetih let razvija na osnovi naravnih danosti bližnje okolice in Pohorja. Obstoječe zmogljivosti pa družba poleg izboljševanja širi tudi na druge lokacije po Sloveniji.

57 Sprotna analitična obdelava v izbranem podjetju Stran Opis problema in želeni rezultati Uspešnost poslovanja podjetij je v največji meri odvisna od uspešnosti prodaje. Zato je učinkovita analiza prodaje temelj za dobro poslovanje. Trenutna prodaja, primerjave s preteklimi obdobji, trenutni deleži realizacije napram planirani prodaji, podatki o uspešnosti referentov, rangiranje kupcev itd. so pomembne informacije, ki jih pogosto ne pridobimo na dovolj hiter in enostaven način. V podjetju Unior d.d. je zadostitev zgoraj omenjenih zahtev zaradi specifične proizvodnje, storitev in širokega spektra ponudbe pogosto nezdružljiva in zahteva ločeno obravnavo za posamezni program. V testni implementaciji smo poskušali zgraditi model, ki bo ustrezal vsem programom, hkrati pa bo zadosten in uporaben na vseh nivojih odločanja, od krovnega vodstva do samih referentov. Zaradi varovanja poslovnih skrivnosti smo uporabili nekoliko prirejene podatke prodajnega področja, določene aspekte pa smo popolnoma izpustili. Ob dejanskem uvajanju sistema bi faza zbiranja zahtev in analize rešitev ter nenazadnje sama implementacija morala biti precej bolj obsežna in natančna, vendar smo zaradi omejenega obsega in težnje k celovitosti diplomskega dela poskušali izvesti in opisati le najpomembnejše dele. Podatki o prodaji, ki so nas zanimali, se nahajajo v transakcijski bazi Oracle ERP sistema Oracle E-Business Suite. Sam sistem poleg centralnega poslovnega informacijskega sistema predstavlja tudi integracijsko središče, kamor se stekajo podatki o prodaji iz področij, ki niso informacijsko pokrite s strani Oracle EBS (na primer pretežni del prodaje programa Turizem). To nam je zelo olajšalo delo pri izgradnji podatkovnega skladišča (tržnice), ki se uporablja za OLAP sistem. V podjetju je analitično področje prodaje že pokrito z velikim številom izpisov in poročil, ki so bodisi navadna SQL povpraševanja bodisi zametki ROLAP podatkovnih sistemov. Največjo težavo predstavlja obremenitev operativnega delovanja transakcijske baze med samim izvajanjem poizvedb, hkrati pa je pri obstoječih rešitvah majhna možnost spreminjanja in manipulacije podatkov s strani končnih uporabnikov. V sodelovanju s prodajnimi referenti posameznih programov in vodje informacijskih rešitev podjetja smo definirali splošne cilje in zahteve, ki jim mora zadoščati sistem.

58 Sprotna analitična obdelava v izbranem podjetju Stran 49 Glavni transakcijski podatki s področja prodaje, ki jih želimo spremljati, so: vrednost prodaje v EUR; količina v pripadajoči merski enoti; teža v pripadajoči merski enoti. Podatke analiziramo z različnih vidikov. Tako nas zanima prodaja glede na: čas, vrsto izdelka/storitve, prodajalca oz. referenta, stranko, organizacijsko strukturo podjetja, tip transakcije. Ker nismo želeli dodatnih stroškov z OLAP strežniki in ločenimi podatkovnimi skladišči, je bila za celoten sistem predvidena že obstoječa baza Oracle Database 10g Enterprise Edition (Release Production With the Partitioning, OLAP and Data Mining options), ki se uporablja že za ERP sistem. Izvedba polnjenja/osveževanja podatkovnega skladišča ter samega OLAP sistema naj bi imela čim manj vpliva na operativno delo baze in naj bi bila čim bolj avtomatizirana in robustna. Z izgradnjo OLAP sistema smo želeli zagotoviti konsistenten vir podatkov, ki jih bo mogoče bodisi obdelovati neposredno preko obstoječih Oraclovih orodij za analizo (recimo Discoverer Viewer) bodisi integrirati v poljubne sisteme. Zaželena je bila tudi možnost integracije z Office Excel-om, ki je najpogosteje uporabljeno orodje za prikaz in obdelavo podatkov v prodaji in marketingu. Glavni cilj teoretičnega dela diplomskega dela torej ni bil v izgradnji popolnoma brezhibnega sistema, ki bi se lahko takoj uporabljal v operativnem delu, pač pa v spoznavanju same rešitve, raziskovanju možnosti uporabe ter v pridobitvi izkušenj z implementacijo. Nastali delujoči sistem, ki se bo lahko uporabljal za testiranje, hkrati vsebuje konsistentne podatke s transakcijskega sistema, tako da je mogoče tudi enostavno preverjanje pravilnosti delovanja.

59 Sprotna analitična obdelava v izbranem podjetju Stran Oracle in OLAP Podjetje Oracle na trgu OLAP orodij nastopa z dvema produktoma: Oracle OLAP, Oracle Essbase. V nadaljevanju si bomo na kratko ogledali njune lastnosti, podobnosti in razlike [18], [22], [21]. Nekoliko podrobneje se bomo posvetili orodju Oracle OLAP, ki je integralni del Oracle podatkovne baze in smo z njim izvedli tudi praktični del diplomskega dela Oracle OLAP Oracle OLAP je večdimenzionalno analitično orodje, vgrajeno v Oracle podatkovni strežnik. Dejansko lahko govorimo o kombinirani večdimenzionalno-relacijski podatkovni bazi, ki združuje dva načina hrambe in obdelave podatkov. Največja prednost orodja je ravno v sklopljenosti z relacijsko podatkovno bazo, saj lahko tako za delo z večdimenzionalnimi podatki uporabljamo kar SQL, hkrati pa so nam na voljo vse napredne funkcionalnosti relacijskih podatkovnih baz (varnost, reševanje in obnova podatkov, administracija, itd.). Oracle OLAP ima bogato zgodovino, ki sega v šestdeseta leta prejšnjega stoletja. Izhaja iz samostojnega orodja Express podjetja Management Decision Systems, ki ga je v devetdesetih letih kupil in nadalje razvijal Oracle. Leta 2002 pa je v različici 9i R2 postal integrirani del Oracle podatkovne baze. Arhitekturo sistema Oracle OLAP lahko razdelimo na tri osnovne dele (Slika 22): večdimenzionalna podatkovna baza z različnimi možnostmi dostopa; administracijska orodja za kreiranje in upravljanje z večdimenzijskimi podatki; orodja za dostop in prikaz večdimenzijskih podatkov.

60 Sprotna analitična obdelava v izbranem podjetju Stran 51 Slika 22: Arhitektura Oracle OLAP Srce sistema OLAP je podatkovni strežnik z večdimenzionalnimi podatki, ki so shranjeni v posebnih delovnih prostorih, imenovanih Analytic workspaces. Te delovne prostore si lahko predstavljamo kot vsebnike za večdimenzijske kocke. Shranjeni so v posebnih relacijskih tabelah kot binarni podatki (BLOBs). Sam SUPB skrbi za ustrezno hrambo in dostop do delovnih prostorov, ki so tudi fizično shranjeni kot navadni relacijski podatki v podatkovnih področjih (angl. tablespace). Dejanske delovne prostore urejamo preko OLAP/AW java vmesnika (Analytic Workspace Java API in Oracle OLAP), ki nam omogoča tudi povpraševanje in izdelavo kock. Za urejanje delovnih prostorov ter gradnjo, polnjenje in administracijo kock se uporabljata dve orodji: Analytic Workspace Manager (AWM), Oracle Warehouse Builder (OWB). Orodji imata grafični vmesnik ter veliko naprednih možnosti, prikazov ter čarovnikov, delujeta pa na osnovi OLAP/AW vmesnika. Ker sta orodji združljivi, se lahko uporabljata hkrati, za vse operacije pa je mogoče generirati tudi PL/SQL skripte, ki se lahko zaganjajo

61 Sprotna analitična obdelava v izbranem podjetju Stran 52 tudi brez samega orodja. Glavna razlika med orodjema je v namembnosti: AWT je specifično orodje za urejanje delovnih prostorov, OWB pa je orodje za izgradnjo in administracijo podatkovnih skladišč. Proces izgradnje delovnega prostora, ki ju orodji podpirata je sestavljen iz treh korakov: izgradnja dimenzijskega modela; povezava dimenzijskega modela z izvornimi podatki; polnjenje podatkov v delovni prostor. Izgradnjo, oblikovanje in administracijo delovnih prostorov si bomo podrobneje ogledali pri dejanskem primeru v nadaljevanju. Za napredno delo z večdimenzionalnimi podatki se lahko uporablja OLAP DML. Gre za bogat proceduralni jezik z velikim številom funkcij in operacij. Če želimo videti strukturo metapodatkov OLAP, uporabimo aktivni katalog (angl. active catalog), kjer so zbrani vsi podatki, ki zadevajo delovne prostore. PL/SQL paket DBMS_AW pa združuje vse operacije za delo z delovnimi prostori, ki jih lahko administratorji uporabljajo neposredno preko konzole baze. Za dostop do podatkov obstaja veliko možnosti in ker je Oracle OLAP del Oracle podatkovne baze, lahko do večdimenzijskih podatkov dostopa vsako orodje, ki lahko dostopa do Oracle podatkovne baze. Tako dejanska komunikacija poteka preko Oracle Call Interface (OCI), Java Database Connectivity (JDBC) ali Open Database Connectivity (ODBC) standardov. Obstajata dva glavna načina za povpraševanje po podatkih: SQL poizvedbe, OLAP API (neposredni večdimenzijski način za orodja). Primarni način povpraševanja je s pomočjo SQL pogledov (angl. view), ki se tvorijo s pomočjo funkcije OLAP_TABLE, ki pridobi večdimenzijske podatke in jih prezentira v relacijski dvodimenzionalni obliki. Primer ukaza, ki izpiše vse člane dimenzije: select * from table(cube_table('delovno_podrocje','','',limitmap_parameter)); Kjer je limitmap_parameter dejanski opis preslikave dimenzijskih struktur v relacijske stolpce, pri čemer je lahko podan kot ime spremenljivke, kjer so te preslikave definirane, ali pa dejanski opis preslikave. Podrobneje si bomo funkcijo ogledali pri praktični izvedbi.

62 Sprotna analitična obdelava v izbranem podjetju Stran 53 V različici 11g je uvedena tudi uporaba materializiranih pogledov (angl. materialized views) na osnovi kock, ki imajo vse lastnosti navadnih materializiranih pogledov (kreiranje, osveževanje, itd.), hkrati pa v enem samem pogledu združujejo vse podatke kocke. Možno je uporabiti tudi povpraševanje s pomočjo MDX jezika (vmesnik podjetja Simba Technologies). Nekaj orodij in vmesnikov, ki omogočajo dostop do večdimenzijskih podatkov: Dostop preko OLAP API: Discoverer for OLAP, OLAP Spreadsheet Addin, BI Beans, Reports OLAP Plugin. Dostop preko SQL-a: Business Objects, Microstrategy, Cognos, Oracle BI EE, Oracle Publisher, Oracle Application Express ter ostala orodja, ki omogočajo SQL dostop do Oracle podatkovne baze. Naštejmo še nekaj lastnosti in dejanskih funkcionalnosti Oracle podatkovne baze, ki jih lahko zaradi močne sklopljenosti s samim jedrom baze uporabljamo tudi z Oracle OLAP: varnostno kopiranje in obnovitev (Datapump), napredni bazni ukazi (flashback query, flashback table, resumable_timeout), razporejevalnik opravil (Job Scheduler v okviru Analytic Workspace Manager), administracija in nadzor (Database/Grid Control Manager), združevanje strežnikov nad eno bazo (Real Application Clusters).

63 Sprotna analitična obdelava v izbranem podjetju Stran Oracle Essbase Oracle Essbase je tipičen primer OLAP strežnika. Gre za samostojno večdimenzionalno bazo (angl. multidimenional database management system MDBMS), ki predstavlja platformo za večdimenzionalno analiziranje podatkov. Ime izvira iz angleškega izraza Extended Spread Sheet database, kar bi lahko prevedli kot: podatkovna baza za razširjene preglednice. Essbase je bil razvit v podjetju Arbor Software v začetku devetdesetih let. Arbor Software se je nato konec devetdesetih let združil s podjetjem Hyperion Software, Essbase pa se je kasneje nekaj časa tržilo tudi pod imenom DB2 Olap Server pri podjetju Microsoft. Leta 2007 je Hyperion Software prevzelo podjetje Oracle in od leta 2009 Essbase poznamo pod imenom Oracle Essbase. Sistem Oracle Essbase sestavljajo trije osnovni nivoji: nivo odjemalca (angl. client tier), vmesni nivo (angl. middle tier), nivo podatkovne baze (angl. database tier). Slika 23: Arhitektura Oracle Essbase

64 Sprotna analitična obdelava v izbranem podjetju Stran 55 Na nivoju odjemalca se nahajajo razvijalna in analitična orodja, ki jih za delo potrebujejo administratorji in končni uporabniki. Vmesni nivo, ki bi ga lahko imenovali tudi povezovalni nivo, vsebuje storitve, ki obdelujejo zahteve nivoja odjemalca in izvajajo ustrezne operacije nad nivojem baze podatkov. Nivo podatkovne baze je srce sistema. Sestavlja ga eden ali več Essbase strežnikov, ki skrbijo za hrambo, obdelavo in dostavo podatkov. Dejanska komunikacija in povpraševanja med posameznimi nivoji najpogosteje potekajo preko HTTP ali TCP/IP protokolov in MDX povpraševalnega jezika. Naštejmo in na kratko opišimo še osnovne komponente arhitekture Essbase (Slika 23): Essbase server, Administration Services, Spreadsheet Add-in, Smart View for Office, Provider Services. Essbase server je večdimenzionalna podatkovna baza, ki je jedro celotnega sistema. Omogoča več načinov shranjevanja in ima veliko knjižnico funkcij za definicijo poslovne logike. Mogoča je tudi uporaba več strežnikov hkrati, kar poveča zmogljivost sistema. Za upravljanje Essbase serverjev se uporablja Administration Services server, ki preko grafičnega vmesnika Administration Services console, izvaja vse potrebne administracijske operacije (definicije, nadzor, operacije nad podatki, opravila itd.). Spreadsheet Add-in je programski dodatek, ki omogoča tabelaričnim analitičnim orodjem (kot recimo Microsoftov Excel) neposreden dostop do podatkov, naprednejše možnosti obdelave in z ustreznimi varnostnimi pravicami tudi njihovo spreminjanje. Za podobno stvar gre tudi pri Smart Viewu, le da je ta programski dodatek namenjen vsem orodjem Microsoft Office paketa, hkrati pa omogoča tudi povezavo na nekatere ostale Oraclove produkte. Provider Services pa je nabor ponudnikov (angl. provider), ki delujejo kot vmesnik med končnimi analitičnimi orodji in podatki v sistemu. Oracle Essbase vsebuje še množico nekoliko manj pomembnih komponent in orodij, ki jih zaradi obsega diplomskega dela ne bomo omenjali.

65 Sprotna analitična obdelava v izbranem podjetju Stran Primerjava Glavna razlika med produktoma je vsekakor v arhitekturi obeh sistemov. Pri Oracle Essbase imamo opravka s samostojnim OLAP strežnikom s standardno trinivojsko arhitekturo, Oracle OLAP pa je razširitev relacijske podatkovne baze z vsemi funkcionalnostmi, ki jih imajo klasični OLAP sistemi. Pri izbiri produkta je zato gotovo na prvem mestu vprašanje: Kakšna je trenutna podatkovna organiziranost v podjetju? V kolikor že uporabljamo Oracle podatkovno bazo in hočemo samo nadgraditi podatkovno skladišče, je smotrna izbira Oracle OLAP. V primeru, da pa imamo v podjetju več različnih podatkovnih virov, ki jih želimo integrirati in analizirati, je boljša rešitev Oracle Essbase. Ena izmed velikih razlik je gotovo tudi standardni način povpraševanja. Kljub temu da Oracle OLAP podpira uporabo klasičnega MDX povpraševalnega jezika, se primarno uporablja SQL, kar je za večino IT strokovnjakov velika prednost, saj jim je SQL domač že iz relacijskih baz. Na splošno bi lahko rekli, da gre pri Essbase za celovit produkt, ki je bolj uporabniško usmerjen, na drugi strani pa je Oracle OLAP nekoliko bolj specifično orodje, ki zahteva določeno predznanje in poznavanje Oraclovih podatkovnih baz. Omenimo tudi močno sklopljenost Essbase strežnika s Hyperionovo družino Oraclovih proizvodov za upravljanje poslovnih procesov (angl. BPM - business process management). Tabela 12: Primerjava Oracle OLAP in Oracle Essbase Funkcionalnost Oracle OLAP Oracle Essbase Shranjevanje podatkov Večdimenzijska polja Večdimenzijska polja Povpraševalni jezik SQL MDX in XML/A Tip procesiranja Vgrajeno v podatkovno bazo Samostojni strežnik Odvisnost Oracle Data base Standard Edition Katerikoli podatkovni vir Primarna uporaba Razširitev podatkovnih skladišč Podpora OLAP aplikacijam

66 Sprotna analitična obdelava v izbranem podjetju Stran Analiza in opis rešitve Na podlagi potreb, preteklih izkušenj in zahtev smo zgradili tipičen OLAP sistem. Na Sliki 24 je prikazana fizična zgradba rešitve. Sistem je v osnovi sestavljen iz treh glavnih komponent, pri čemer je iz varnostnih in administracijskih razlogov dejanski OLAP strežnik ločen od baznega strežnika: izvorni sistem v našem primeru produkcijska ERP baza, olap strežnik v našem primeru testna baza, identična produkcijski bazi, orodja za prikaz in obdelavo podatkov. Končni uporabniki in analitična orodja ERP Aplikacijski strežnik OLAP Bazni strežnik ERP Bazni strežnik Slika 24: Arhitekturna zasnova rešitve Podobno lahko potek gradnje rešitve razdelimo na tri glavne aktivnosti, ki jih bomo podrobneje opisali v naslednjih podpoglavjih: izgradnja podatkovnega skladišča, izgradnja OLAP baze, integracija in prikaz rezultatov.

67 Sprotna analitična obdelava v izbranem podjetju Stran Izgradnja podatkovnega skladišča Kot smo ugotovili že pri definiciji problema, so podatki, ki smo jih obdelovali, zbrani v podatkovni bazi ERP sistema. Shranjeni so v relacijskih tabelah, ki jih logično združujemo v sheme (angl. schema). Shema je skupek podatkovnih objektov (angl. database objects), ki jih lahko uporablja določen uporabnik (angl. user). Pravila za dostop in manipulacijo nad objekti sheme se dodelijo (angl. grant) s tako imenovanimi privilegiji (angl. privileges). Od ostalih baznih objektov, ki smo jih uporabljali, omenimo še poglede (angl. view) in sinonime (angl. synonym). Pogled je dejansko shranjeno povpraševanje, ki navzven deluje kot navadna tabela, sinonim pa je alternativno ime za obstoječ bazni objekt. Ker smo zaradi fizične delitve podatkovnega skladišča in OLAP baze iz ene baze morali dostopati do druge, smo morali uporabiti tudi tako imenovano neposredno povezavo med bazami (angl. database link). PL/SQL kodo, ki smo jo uporabili za gradnjo, smo logično združili v paket (angl. package), ki praviloma združuje vsebinsko povezane procedure, funkcije, tipe itd. Za samodejno izvajanje določenih opravil (na primer zagon procedure) smo uporabili posel (angl. job). Vsi omenjeni koncepti so del Oracle podatkovne baze. Zaradi jedrnatosti in preglednosti smo določene podrobnosti izpustili, saj niso potrebne za razumevanje izvedbe. Vsi objekti, ki smo jih potrebovali za izgradnjo podatkovnega skladišča, se nahajajo v shemi APPS, ali pa ima shema APPS dovoljenja za njihov dostop (z ustreznimi pravicami in sinonimi). Za ustreznost podatkov skrbi ERP sistem pri kreiranju transakcij, zato lahko predpostavimo, da so podatki prečiščeni, pravilni ter konsistentni. Zaradi enostavnosti implementacije smo samo podatkovno skladišče ustvarili kar na bazi, kjer se nahajajo podatki (ime baze PERP, shema APPS). Tako je, kar zadeva izgradnjo podatkovnega skladišča, bila naša naloga le: ustrezno povezati podatke iz transakcijskih tabel ERP sistema, definirati normalizirano dimenzijsko shemo podatkovnega skladišča, napolniti podatkovno skladišče ter ga inkrementalno osveževati.

68 Sprotna analitična obdelava v izbranem podjetju Stran Poenostavljen E-R diagram Zanima nas poslovno področje prodaje, natančneje področje terjatev. Da smo lahko zgradili podatkovno skladišče, smo morali najprej razumeti domensko področje in strukturo podatkov terjatev. Za osnovo so nam služile transakcije terjatev, ki so dejansko postavke faktur, ki se izstavljajo kupcem. Podatki se lahko vnašajo ročno, večinoma pa se generirajo avtomatsko ob uvozih iz prodajnih naročil oziroma dejanskih odprem. Transakcije, ki se fakturirajo na drugih sistemih (recimo prodajalne, turistične blagajne itd.), se v sistem uvažajo periodično v večjih paketih. Ko je transakcija zaključena in prenesena v glavno knjigo, se smatra kot prihodek. Na Sliki 25 vidimo primer vnosne forme za transakcijo terjatev iz poslovnega sistema Oracle EBS. Slika 25: Forma transakcij terjatev Dejanski podatki transakcij so shranjeni v objektih ra_customer_trx_all - glave, ra_customer_trx_lines_all - pozicije in ra_cust_trx_line_gl_dist_v - razdelitve. Podatki o izdelku/storitvi posamezne linije se nahajajo v tabeli mtl_system_items, njihova podrobnejša kategorizacija pa v pogledu mtl_categories in tabeli mtl_item_categories. Podatki o prodajnih referentih so v tabeli ra_salesreps_all. Vsaka transakcija pripada določenemu programu/stroškovnemu mestu/kontu in ti

69 Sprotna analitična obdelava v izbranem podjetju Stran 60 podatki se nahajajo v tabeli gl_code_combinations. Fakture delimo tudi po tipu (dobropis, bremepis, proforma itd.). Podatke o tipu fakture najdemo v tabeli ra_cust_trx_types_all. Podrobni podatki o prejemnikih faktur pa se nahajajo v objektih ra_customers, ra_site_uses in ra_addresses. Celoten podatkovni model je zelo kompleksen, zato smo ga nekoliko poenostavili, hkrati pa smo zato uporabili tudi precej normaliziranih pogledov. Na Sliki 26 vidimo diagram celotnega modela, ki smo ga uporabili za gradnjo podatkovnega skladišča. Slika 26: Poenostavljen E-R diagram

70 Sprotna analitična obdelava v izbranem podjetju Stran Shema dimenzijskega modela Podatkovno skladišče smo zgradili s pomočjo večdimenzionalnega podatkovnega modela, ki nam je služil kot osnova za gradnjo, dejansko pa tudi kot fizično ogrodje za podatkovno skladišče. Zvezdna shema dimenzijskega modela, prikazana na Sliki 27, je sestavljena iz tabele dejstev in dimenzijskih tabel: unior_olap_prodaja tabela dejstev z zahtevanimi merami, unior_olap_cas dimenzija časa, unior_olap_delitev dimenzija z organizacijskimi podatki, unior_olap_prodajalci dimenzija s podatki o prodajalcih (referentih), unior_olap_izdelek dimenzija s podatki o izdelku, unior_olap_stranke dimenzija s podatki o kupcih, unior_olap_racun dimenzija s podatki o vrsti in tipu računa. UNIOR_OLAP_CAS UNIOR_OLAP_PRODAJALCI PK MESEC_ID MESEC MESEC_NAZIV MESEC_RAZPON MESEC_ZADNJI_DATUM KVARTAL_ID KVARTAL KVARTAL_NAZIV KVARTAL_RAZPON KVARTAL_ZADNJI_DATUM LETO_ID LETO LETO_NAZIV LETO_RAZPON LETO_ZADNJI_DATUM PK UNIOR_OLAP_PRODAJA PK PRODAJALEC_ID VIR_ID PRODAJALEC_NAZIV PRODAJALEC_STEVILKA PRODAJA_ID PK UNIOR_OLAP_DELITEV DELITEV_ID PROGRAM_ID PROGRAM PROGRAM_NAZIV STROSKOVNO_MESTO_ID STROSKOVNO_MESTO STROSKOVNO_MESTO_NAZIV KONTO_ID KONTO KONTO_NAZIV POVEZANA_DRUZBA_ID POVEZANA_DRUZBA POVEZANA_DRUZBA_NAZIV PK UNIOR_OLAP_RACUN RACUN_ID RACUN RACUN_NAZIV TIP_RACUNA_ID TIP_RACUNA TIP_RACUNA_NAZIV PK FK1 FK2 FK3 FK4 FK5 FK6 UNIOR_OLAP_IZDELEK CARINSKA_ID CARINSKA CARINSKA_NAZIV CARINSKA_OSNOVNA_ID CARINSKA_OSNOVNA CARINSKA_OSNOVNA_NAZIV TRX_ID TRX_DATUM TRX_STEVILKA VREDNOST_EUR TEZA_KG KOLICINA IZDELEK_ID STRANKA_ID DELITEV_ID PRODAJALEC_ID CAS_ID RACUN_ID PK UNIOR_OLAP_STRANKE STRANKA_ID STRANKA_NAZIV STRANKA_NASLOV_ID STRANKA_NASLOV_NAZIV STRANKA_MESTO STRANKA_POSTA STRANKA_DRZAVA_ID STRANKA_DRZAVA STRANKA_DRZAVA_NAZIV STRANKA_TIP_ID STRANKA_TIP_NAZIV Slika 27: Shema dimenzijskega modela

71 Sprotna analitična obdelava v izbranem podjetju Stran ETL Proces Z opredeljenim virom podatkov in pripravljeno shemo dimenzijskega modela podatkovnega skladišča smo potrebovali le še ETL proces, ki bo polnil skladišče. Kot omenjeno v prejšnjih poglavjih ima Oracle namenska orodja, ki skrbijo za podatkovna skladišča, vendar smo za naš primer poskušali polnjenje skladišča implementirati sami s PL/SQL procedurami. Naš cilj je bil ustvariti preslikavo med E-R modelom in dimenzijskim modelom, hkrati pa zagotoviti periodično osveževanje ter konsistenco podatkov. Da so procedure, ki smo jih uporabili, logično združene, smo ustvarili paket UNIOR_OLAP_PACKAGE, ki nam bo služil tudi kot nadzor nad osveževanjem. Primer 1 prikazuje deklaracijo PL/SQL paketa. Primer 1: Deklaracija paketa UNIOR_OLAP_PACKAGE CREATE OR REPLACE PACKAGE APPS.UNIOR_OLAP_PACKAGE AS /***************************************************************************** NAME: UNIOR_OLAP_PACKAGE PURPOSE: ETL process REVISIONS: Ver Date Author Description Kristjan 1. Created this package. ******************************************************************************/ zadnjaposodobitev DATE; trenutnaposodobitev DATE; FUNCTION posodobipodatkovnoskladisce RETURN NUMBER; PROCEDURE vstavilog(datum IN DATE, vrsta IN VARCHAR2, opis IN VARCHAR2); PROCEDURE posodobidimenzijocas; PROCEDURE posodobidimenzijoprodajalec; PROCEDURE posodobidimenzijodelitev; PROCEDURE posodobidimenzijoizdelek; PROCEDURE posodobidimenzijostranka; PROCEDURE posodobidimenzijoracun; PROCEDURE posodobidejstvoprodaja; END UNIOR_OLAP_PACKAGE; / Princip delovanja je enostaven. Preslikavo iz relacijskega podatkovnega modela baze v model podatkovnega skladišča smo definirali s SQL poizvedbami, ki polnijo fizične tabele sheme dimenzijskega modela z INSERT stavki. Prva polnitev je bila trivialna, saj smo samo preslikali vse zapise iz izvornih objektov v tabele podatkovnega skladišča. Pri inkrementalnem polnjenju pa smo morali upoštevati tudi časovno komponento. Vsi zapisi v transakcijskih tabelah imajo poleg podatkov tudi časovni znački kreiranja in posodobitve zapisa (CREATION_DATE, LAST_UPDATE_DATE), na katere smo se lahko sklicevali.

72 Sprotna analitična obdelava v izbranem podjetju Stran 63 S funkcijo posodobipodatkovnoskladisce (Primer 2) se izvede celotna posodobitev podatkovnega skladišča. Pomemben je podatek o zadnji posodobitvi, s katerim določimo, kateri zapisi se morajo ustvariti oziroma popraviti (izbris in ponovni vnos). Enak princip se uporablja pri vseh procedurah za tabelo dejstev in dimenzije. Za lažji nadzor in sledljivost vsako osveževanje beležimo v posebno LOG tabelo unior_olap_log. Primer 2: Funkcija posodobipodatkovnoskladisce FUNCTION posodobipodatkovnoskladisce RETURN NUMBER IS korakiposodobitve VARCHAR(100); napaka_string VARCHAR2(1000); BEGIN korakiposodobitve := 'Inicializacija posodobitve'; --ustvarim sejo (polnjenje pogledov) FND_GLOBAL.APPS_INITIALIZE(1381,50475,222); --pridobim zadnji in trenutni datum posodobitve SELECT zadnji_datum_osvezitve, SYSDATE INTO zadnjaposodobitev, trenutnaposodobitev FROM unior_olap_parametri; vstavilog(trenutnaposodobitev,'začetek','inicializacija posodobitve skladišča'); --dimenzija ČAS vstavilog(trenutnaposodobitev,'potek','posodobitev dimenzije: Čas'); posodobidimenzijocas; --dimenzija PRODAJALEC vstavilog(trenutnaposodobitev,'potek','posodobitev dimenzije: Prodajalec'); posodobidimenzijoprodajalec; --dimenzija DELITEV vstavilog(trenutnaposodobitev,'potek','posodobitev dimenzije: Delitev'); posodobidimenzijodelitev; --dimenzija IZDELEK vstavilog(trenutnaposodobitev,'potek','posodobitev dimenzije: Izdelek'); posodobidimenzijoizdelek; --dimenzija STRANKA vstavilog(trenutnaposodobitev,'potek','posodobitev dimenzije: Stranka'); posodobidimenzijostranka; --dimenzija RAČUN vstavilog(trenutnaposodobitev,'potek','posodobitev dimenzije: Račun'); posodobidimenzijoracun; --factable PRODAJA vstavilog(trenutnaposodobitev,'potek','posodobitev dejstva: Prodaja'); posodobidejstvoprodaja; --posodobitev uspešna vstavilog(trenutnaposodobitev,'konec','posodobitev skladišča končana uspešno'); UPDATE unior_olap_parametri SET zadnji_datum_osvezitve = trenutnaposodobitev; RETURN 1; COMMIT; --kakrsnakoli napaka EXCEPTION WHEN OTHERS THEN napaka_string := 'SQL Napaka: ' korakiposodobitve ' - ' SQLERRM; vstavilog(trenutnaposodobitev,'napaka',napaka_string); RETURN -1; END posodobipodatkovnoskladisce;

73 Sprotna analitična obdelava v izbranem podjetju Stran 64 V Primeru 3 je prikazana implementacija procedure posodobidimenzijostranka, ki polni dimenzijsko tabelo unior_olap_stranke. V prvem delu iz tabele izbrišemo podatke, ki so se med zadnjim osveževanjem spremenili, v drugem pa napolnimo nove in spremenjene. Primer 3: Implementacija procedure posodobidimenzijostranka PROCEDURE posodobidimenzijostranka IS BEGIN DELETE unior_olap_stranke WHERE stranka_id IN ( SELECT ra.customer_id FROM ra_customers rc, ra_site_uses rsu, ra_addresses ra WHERE rsu.status = 'A' AND rsu.primary_flag = 'Y' AND rsu.site_use_code = 'BILL_TO' AND rsu.address_id = ra.address_id AND ra.customer_id = rc.customer_id AND rc.creation_date < zadnjaposodobitev AND rc.last_update_date > zadnjaposodobitev ); vstavilog( trenutnaposodobitev, 'POTEK', 'Število brisanih pozicij: ' SQL%ROWCOUNT ); INSERT INTO unior_olap_stranke ( SELECT ra.customer_id stranka_id, rc.customer_name stranka_naziv, ra.address_id stranka_naslov_id, address4 stranka_naslov_naziv, city stranka_mesto, postal_code stranka_posta, ft.iso_numeric_code stranka_drzava_id, ft.territory_code stranka_drzava, ftt.territory_short_name stranka_drzava_naziv, DECODE(rc.party_type, 'ORGANIZATION',1,'PERSON',2 ) stranka_tip_id, DECODE(rc.party_type,'ORGANIZATION','ORGANIZACIJA','PERSON','OSEBA' ) stranka_tip_naziv, rc.last_update_date FROM ra_customers rc, ra_site_uses rsu, ra_addresses ra, fnd_territories ft, fnd_territories_tl ftt WHERE rsu.status = 'A' AND rsu.primary_flag = 'Y' AND rsu.site_use_code = 'BILL_TO' AND rsu.address_id = ra.address_id AND ft.territory_code = ra.country AND ft.territory_code = ftt.territory_code AND ftt.language = 'SL' AND ra.customer_id = rc.customer_id AND rc.last_update_date > zadnjaposodobitev ); vstavilog( trenutnaposodobitev, 'POTEK', 'Število vstavljenih pozicij: ' SQL%ROWCOUNT ); END posodobidimenzijostranka;

74 Sprotna analitična obdelava v izbranem podjetju Stran 65 Za inkrementalno osveževanje moramo funkcijo posodobipodatkovnoskladisce zaganjati vsaj enkrat dnevno, da bodo podatki izražali dejansko stanje v prodaji. Zaradi minimalne obremenitve transakcijske baze smo nastavili osveževanje na 12. uro ponoči, tako da je stanje v podatkovnem skladišču veslej stanje preteklega dne. Načeloma bi lahko osveževanje prožili tudi pogosteje. Dejanski zagon funkcije je izveden s pomočjo že omenjenega mehanizma poslov, ki se jih zaganja preko baznega paketa DBMS_JOB (z novejšimi različicami baze nadomeščen s paketom DBMS_SCHEDULER). Primer 4 prikazuje deklaracijo posla, ki periodično izvaja želeno funkcijo. Za zagon poljubne kode PL/SQL moramo zagnati le proceduro SUBMIT z naslednjimi parametri: job samoustvarjena številka posla, what ime funkcije/procedure, ki se naj zažene, next_date čas zagona, interval nastavitev intervala, no_parse ali se naj ob predložitvi koda, ki se mora zagnati, preveri. Primer 4: Deklaracija posla DECLARE X NUMBER; BEGIN SYS.DBMS_JOB.SUBMIT ( job => X,what => 'UNIOR_OLAP_PACKAGE.posodobiPodatkovnoSkladisce();',next_date => to_date(' :00:00','dd.mm.yyyy hh24:mi:ss'),interval => 'SYSDATE+1',no_parse => FALSE ); SYS.DBMS_JOB.BROKEN (job => X, broken => TRUE); COMMIT; END; /

75 Sprotna analitična obdelava v izbranem podjetju Stran Izgradnja OLAP baze Ko smo imeli podatke pripravljene in shranjene v de-normaliziranih dimenzijskih tabelah podatkovnega skladišča, smo se lahko lotili gradnje OLAP baze. Ker za OLAP delovni prostor nismo uporabili istega strežnika kot za podatkovno skladišče, smo morali najprej pripraviti okolje ter postaviti novo Oracle podatkovno bazo. Preden smo dejansko začeli gradnjo, smo potrebovali tudi AWM upravitelja, s katerim smo lahko bazo oblikovali preko grafičnega vmesnika. Logični model baze, definiran s shemo dimenzijskega modela, smo morali spremeniti v fizični model s kreiranjem dimenzij in same OLAP kocke. Ko smo podatke iz podatkovnega skladišča naložili v kocko, je bila OLAP podatkovna baza pripravljena za uporabo Priprava okolja Na kratko si oglejmo, kakšen je bil postopek namestitve delujočega OLAP delovnega prostora, ki se uporablja za sprotno analitično obdelavo. V kolikor bralec želi podrobne informacije o namestitvi, jih lahko najde v Oracle namestitvenem priročniku, ki je na voljo tudi na spletu [24]. Postopek postavitve lahko razdelimo na sledeče faze: priprava namestitvenega okolja; namestitev podatkovne baze 10g R2 ( ); namestitev potrebnih popravkov; konfiguracija orcl instance in vzpostavitev nadzornega okolja; namestitev AWM OLAP upravitelja; kreiranje delovne sheme GLOBAL na instanci orcl. Preden smo lahko začeli z nameščanjem baze, smo potrebovali gostitelja (strežnik, PC) z ustrezno strojno konfiguracijo. Uporabili smo kar nekoliko zmogljivejši osebni računalnik (Intel E8400, 3GB Ram, 800 GB HDD) z Windows XP 32 bitnim operacijskim sistemom in povezavo z omrežjem, v katerem se nahaja podatkovno skladišče ter ostala analitična orodja, ki smo jih uporabljali. Ena od zahtev je tudi namestitev navideznega vmesnika za mrežo Microsoft Loopback Adapter.

76 Sprotna analitična obdelava v izbranem podjetju Stran 67 Oracle Database 10g Enterprise Edition je plačljiv komercialen produkt, za katerega potrebujemo ustrezna dovoljenja in licence. V sklopu pogodbe, ki ga ima podjetje Unior d.d. s podjetjem Oracle, smo bili upravičeni do uporabe. V sklopu OTN (Oracle Technology Network Developer License) razvojne licence pa je mogoče produkt v testne namene brezplačno prenesti tudi neposredno z Oraclove spletne strani. Bazo je možno namestiti na več načinov, odvisno od potreb in naprednosti uporabnika. Sami smo uporabili kar standardno namestitev preko čarovnika Oracle Universal Installer (Slika 28): Slika 28: Izbira načina namestitve podatkovne baze Standardna namestitev pripravi okolje za bazo ter predpripravi začetno instanco baze orcl. Po uspešni namestitvi opravimo še klasična ponamestitvena opravila, navedena v namestitvenem priročniku. Najpomembnejši sta prevajanje neveljavnih baznih objektov ter namestitev potrebnih baznih popravkov. Za našo bazo sta bila posebej pomembna dva popravka, ki ju lahko prenesemo kar s spleta: patch for Windows (številka popravka ) in OLAP A Patch for Windows (številka popravka ).

77 Sprotna analitična obdelava v izbranem podjetju Stran 68 Nadzor in administracija baze se najlažje izvaja preko posebne spletne konzole, imenovane Database Control. Tu so na enem mestu zbrane vse funkcije, ki jih potrebuje bazni administrator, od spremljanja obremenitve sistema do nastavitev varnostnih kopij. Na Sliki 29 je prikazana nadzorna plošča med polnjenjem OLAP skladišča. Slika 29: Database Control nadzorna plošča Za upravljanje delovnih prostorov, v katerih se nahajajo večdimenzijski objekti, potrebujemo AWM OLAP upravitelja, ki je dosegljiv na Oraclovih spletnih straneh. Namestitev je enostavna in zajema le razpakiranje stisnjene datoteke in zagon izvedljive datoteke awm\bin\awm.exe. Preden pa lahko pričnemo delati z OLAP delovnim prostorom, potrebujemo še delovno shemo GLOBAL in pripadajoče podatkovno področje, ki ju lahko ustvarimo kar v Database Control nadzorni plošči. V kolikor je namestitev OLAP komponent baze izvedena pravilno, mora poizvedba, prikazana v Primeru 5, vrniti navedene vrednosti. Primer 5: Poizvedba o veljavnosti OLAP namestitve SELECT comp_name, version, status FROM dba_registry WHERE comp_name LIKE '%OLAP%'; COMP_NAME VERSION STATUS OLAP Analytic Workspace VALID Oracle OLAP API VALID OLAP Catalog VALID

78 Sprotna analitična obdelava v izbranem podjetju Stran Priprava delovnega področja Delovni prostor predstavlja OLAP vsebnik v podatkovni bazi, kamor se hranijo večdimenzijski objekti, kot so dimenzije in kocke. AWM upravitelja smo morali povezati s podatkovno bazo ter delovno shemo, kjer smo ustvarili novo delovno področje. Pri povezavi na podatkovno bazo smo vpisali podatke o bazi: gostitelj:port:ime_instance (v našem primeru: kristjan-1.brodej.com:1521:orcl), pri shemi pa izbrali našo shemo GLOBAL. Znotraj sheme smo morali le še kreirati novo delovno področje, ki smo ga imenovali kar enako kot shemo: GLOBAL. Tako smo bili pripravljeni na kreiranje OLAP objektov. Na Sliki 30 je prikazana nadzorna plošča AWM upravitelja. Slika 30: Kreirano delovno področje GLOBAL Omenimo še dve omejitvi Oracle OLAP, ki sta zahtevali, da smo podatke iz podatkovnega skladišča še nekoliko priredili: V tabeli dejstev morajo biti kombinacije dimenzij posameznega zapisa edinstvene. Za najvišji nivo podatkov dimenzije je potrebno ustvariti fizični zapis. Da smo zadostili zahtevam, smo na shemi GLOBAL ustvarili poglede, katerih poizvedbe preko povezave med bazami črpajo podatke iz sheme APPS podatkovnega skladišča. Za prvo omejitev je bilo potrebno le sumirati vse mere in jih grupirati po vseh ključih dimenzij. Tako se morebitni identični zapisi z različnimi vrednostmi mer združijo v en zapis s seštetimi merami. Pri drugi omejitvi pa smo v pogledu k originalnim podatkom

79 Sprotna analitična obdelava v izbranem podjetju Stran 70 nivojev dimenzij dodali nivo ALL z edinstvenim primarnim ključem. Tako smo dobili naslednje poglede, s katerimi smo lahko napolnili OLAP bazo: UNIOR_PRODAJA_FACT UNIOR_CAS_DIM UNIOR_DELITEV_DIM UNIOR_IZDELEK_DIM UNIOR_PRODAJALCI_DIM UNIOR_RACUN_DIM UNIOR_STRANKE_DIM Primer 6: Pogled UNIOR_PRODAJA_FACT CREATE OR REPLACE FORCE VIEW "GLOBAL"."UNIOR_PRODAJA_FACT" ( "VREDNOST_EUR", "KOLICINA", "TEZA_KG", "CAS_ID", "DELITEV_ID", "PRODAJALEC_ID", "IZDELEK_ID", "STRANKA_ID", "RACUN_ID" ) AS ( select sum(vrednost_eur) vrednost_eur, sum(kolicina) kolicina, sum(teza_kg) teza_kg, cas_id, delitev_id, prodajalec_id, izdelek_id, stranka_id, racun_id from unior_olap_prodaja@perp_apps_unior.si group by cas_id, delitev_id, prodajalec_id, izdelek_id, stranka_id, racun_id ); Preden smo lahko uporabili neposredno povezavo med bazama, smo jo morali definirati v bazi, kjer se uporablja, kar smo storili z naslednjim ukazom: CREATE PUBLIC DATABASE LINK "PERP_APPS_UNIOR.SI" CONNECT TO APPS IDENTIFIED BY <PWD> USING 'PERP'; kjer sta APPS in <PWD> ime in geslo sheme, 'PERP' pa ime baze iz konfiguracijske datoteke TNSNAMES.ora, kjer so navedeni dostopni podatki do podatkovnega skladišča.

80 Sprotna analitična obdelava v izbranem podjetju Stran Gradnja dimenzij Dimenzije smo dejansko definirali že s shemo dimenzijskega modela. Ker smo model zgradili v normalizirani obliki in že pripravljenimi nivoji, je bila gradnja dimenzij enostavna [25]. Naštejmo vse dimenzije: ČAS, DELITEV, IZDELEK, PRODAJALEC, RAČUN, STRANKA. Postopek gradnje dimenzij je potekal v treh fazah: definicija nivojev, definicija hierarhij, preslikava fizičnih podatkov v dimenzijo. Za gradnjo smo uporabili AWM upravitelja, kjer smo v mapi Dimensions kreirali nove dimenzije. Za nekoliko nazornejšo predstavo si dejanski potek na kratko oglejmo na primeru dimenzije DELITEV (Slika 31). Osnova za opredelitev dimenzije je razdelitev pozicije fakture. Z razdelitvijo imamo v mislih dodelitev k ustrezni organizacijski, finančni strukturi. Praktično to pomeni, da prihodek pozicije računa določimo k specifični kombinaciji programa/stroškovnega mesta/konta. Ravno navedene kategorizacije pa so pravzaprav že kar nivoji dimenzije, ki smo jih definirali v podmapi Levels. Ko smo določili nivoje, smo morali določiti tudi njihovo hierarhično razvrstitev. To smo storili v podmapi Hierarchies. Hierarhija se enostavno definira tako, da se ji določi ime in po vrstnem redu našteje pripadajoče nivoje. Pogosto se zgodi tudi, da ima lahko določena dimenzija različno hierarhično razvrstitev nivojev. V našem primeru lahko tako znotraj določenega programa analiziramo posamezna stroškovna mesta in konte, lahko pa bi nas na primer zanimala razmerja posameznih programov znotraj specifičnega konta. V takšnih primerih lahko znotraj ene dimenzije opredelimo več vrst hierarhij, pri čemer pa mora obstajati ena,

81 Sprotna analitična obdelava v izbranem podjetju Stran 72 ki je opredeljena kot primarna. Za dimenzijo DELITEV smo zato ustvarili dve hierarhiji: PRIMARNA in SEKUNDARNA. V kolikor želimo, da ima dimenzija poleg naziva (opisa) še kakšne dodatne atribute, jih lahko dodamo v podmapi Attributes. Ko imamo definirano strukturo dimenzije, se lahko lotimo povezovanja dejanskih podatkov z definirano strukturo. To smo storili v podmapi Mapping. Povezovanje poteka tako, da se iz ustreznega objekta (v našem primeru pogleda UNIOR_DELITEV_DIM) določijo povezave posameznih stolpcev s pripadajočimi nivoji. Če imamo več hierarhij, se povezave določijo za vse nivoje različnih hierarhij. Slika 31: Primer preslikave dimenzije DELITEV Ko smo opredelili nivoje, hierarhije in povezavo z virom podatkov, smo lahko podatke iz pogleda UNIOR_DELITEV_DIM dejansko prenesli v ustvarjeno dimenzijo, kar smo storili s tako imenovanim vzdrževalnim čarovnikom (angl. Maintenance wizard). Pri dimenzijah omenimo še možnost uporabe obstoječih primarnih ključev iz virov podatkov, ali pa uporabo novoustvarjenih nadomestnih ključev (angl. surrogate key).

82 Sprotna analitična obdelava v izbranem podjetju Stran Gradnja kocke Gradnja kocke je potekala po naslednjem postopku: V mapi Cubes smo ustvarili novo kocko UNIOR_PRODAJA, ki smo ji dodelili v prejšnjem poglavju navedene dimenzije ČAS, DELITEV, IZDELEK, PRODAJALEC, RAČUN in STRANKA. Čarovnik za ustvarjanje kocke nam ob ustvarjanju kocke ponudi tudi napredne nastavitve, ki so že prenastavljene na priporočene vrednosti, vendar jih je moč spremeniti. Nastavitve vplivajo na način procesiranja kocke ter hitrost delovanja in vzdrževanja (Slika 32). Omenimo najpomembnejše: vrstni red dimenzij v kocki, redkost posameznih dimenzij (angl. sparsity), vrstni red in metode agregiranja, deli kocke naj se preračunajo že ob izgradnji (angl. presummarized), rezultati se hranijo v predpomnilnik v okviru seje (angl. session cache). Slika 32: Kreiranje kocke UNIOR_PRODAJA

83 Sprotna analitična obdelava v izbranem podjetju Stran 74 Ko smo ustvarili kocko smo nadaljevali z najpomembnejšim delom definicije kocke - opredelitvijo mer, ki smo jih za kocko UNIOR_PRODAJA ustvarili v podmapi Measures: KOLICINA, TEZA, VREDNOST. Za vsako mero smo izbrali tudi ustrezni podatkovni tip ter podobno kot pri sami kocki, nastavili podatke o predračunanju, predpomnjenju ipd. Poleg navadnih mer je v podmapi Calculated Measures možno ustvariti tudi izračunane mere. Pri kreiranju lahko izbiramo med široko paleto operacij, od enostavnih aritmetičnih do bolj zapletenih časovnih in primerjalnih. Tako lahko izvajamo poljubne računske operacije nad merami, dodajamo končne in tekoče vsote, deleže, primerjamo mere napram preteklim obdobjem. Kot primer smo ustvarili naslednje izračunane mere: DELEZ delež napram celotni prodaji, PRIMERJAVA primerjava napram prejšnjemu obdobju, VSOTA tekoča vsota, vezana na dimenzijo čas. Slika 33: Preslikava tabele (pogleda) dejstev v kocko

84 Sprotna analitična obdelava v izbranem podjetju Stran 75 Enako kot pri dimenzijah moramo tudi pri kocki v podmapi Mappings povezati kocko s fizičnim objektom, kjer so shranjeni podatki o merah. V našem primeru smo za preslikavo uporabili pogled UNIOR_PRODAJA_FACT. Posamezne mere iz pogleda smo povezali z ustvarjenimi merami v kocki, posamezne tuje ključe dimenzijskih tabel pa z dimenzijami, definiranimi za kocko, kot lahko vidimo na Sliki 33. Zadnji korak gradnje kocke pa je spet polnjenje kocke s podatki, ki se enako kot pri dimenzijah, opravi z vzdrževalnim čarovnikom. V čarovniku določimo, kateri deli kocke naj se napolnijo, ali se naj neobstoječi podatki in dimenzije brišejo ipd. Določimo lahko čas izvajanja, ker izbiramo med takojšnjo izvedbo ali uvedbo razporeda izvajanja, kjer se lahko uporabi tudi več sočasnih procesov, kar pohitri dejansko izvajanje polnjenja. Orodje nam generira tudi SQL skripto z ukazi za polnjenje izbrane kocke. Polnjenje smo implementirali preko generirane skripte (Primer 7), ki jo lahko izvajamo mimo samega AWM upravitelja. Uporabili smo mehanizem poslov, ki smo jih uporabili že pri ETL skriptah, pri čemer smo razpored izvajanja nastavili tako, da se izvaja po osveževanju podatkovnega skladišča. S tem smo OLAP bazo napolnili s podatki in pripravili za uporabo. Primer 7: Skripta za osveževanje kocke PRODAJA_UNIOR declare xml_clob clob; xml_str varchar2(4000); isaw number; begin DBMS_LOB.CREATETEMPORARY(xml_clob,TRUE); dbms_lob.open(xml_clob, DBMS_LOB.LOB_READWRITE); dbms_lob.writeappend(xml_clob, 184, ' <BuildDatabase Id="Action3" AWName="GLOBAL.GLOBAL" BuildType="EXECUTE" RunSolve="true" CleanMeasures="false" CleanAttrs="false" CleanDim="false" TrackStatus="true" MaxJobQueues="0" >'); dbms_lob.writeappend(xml_clob, 42, ' <BuildList XMLIDref="CAS.DIMENSION" />'); dbms_lob.writeappend(xml_clob, 46, ' <BuildList XMLIDref="DELITEV.DIMENSION" />'); dbms_lob.writeappend(xml_clob, 46, ' <BuildList XMLIDref="IZDELEK.DIMENSION" />'); dbms_lob.writeappend(xml_clob, 49, ' <BuildList XMLIDref="PRODAJALEC.DIMENSION" />'); dbms_lob.writeappend(xml_clob, 44, ' <BuildList XMLIDref="RACUN.DIMENSION" />'); dbms_lob.writeappend(xml_clob, 46, ' <BuildList XMLIDref="STRANKA.DIMENSION" />'); dbms_lob.writeappend(xml_clob, 47, ' <BuildList XMLIDref="UNIOR_PRODAJA.CUBE" />'); dbms_lob.writeappend(xml_clob, 18, ' </BuildDatabase>'); dbms_lob.close(xml_clob); xml_str := sys.interactionexecute(xml_clob); dbms_output.put_line(xml_str); end; /

85 Sprotna analitična obdelava v izbranem podjetju Stran Prikaz rezultatov Kot smo omenili že pri predstavitvi Oracle OLAP-a, je dostop do podatkov v OLAP kockah možen preko množice orodij, ki imajo svoje prednosti in slabosti. V nadaljevanju si na kratko poglejmo primera možnih dostopov do podatkov, ki smo jih zbrali v kocki UNIOR_PRODAJA. Na splošno lahko rečemo, da za dostop do podatkov obstajata dva različna načina: s pomočjo klasičnih SQL poizvedb nad generiranimi relacijskimi objekti, s pomočjo OLAP API nad dimenzijskimi podatki v OLAP bazi. Preden smo lahko dejansko začeli uporabljati ustvarjeno OLAP bazo, smo morali obvezno preveriti pravilnost zbranih podatkov. To smo najlažje storili tako, da smo nekaj podatkov, za katere vemo, da so pravilni, primerjali s podatki, pridobljenimi iz OLAP sistema. Za naš primer, na podlagi obstoječih poročil in analiz, vemo, da je imela referentka Mihaela Fendre v letu ,25 evrov realizirane prodaje. Omenjeni znesek lahko pridobimo tudi preko v Primeru 8 prikazane SQL poizvedbe nad dejanskimi transakcijskimi tabelami iz prodajnega poslovanja, kjer omejimo čas transakcij na leto 2008 ter primarnega prodajnega referenta na , kar je številka prodajne referentke Mihaele Fendre. Primer 8: Poizvedba realizacije referentke Mihaele Fendre v letu 2008 SQL> SELECT 2 SUM(rctld.amount) 3 FROM 4 ra_customer_trx_all rct, 5 ra_customer_trx_lines_all rctl, 6 ra_cust_trx_line_gl_dist_v rctld 7 WHERE 8 rct.customer_trx_id = rctl.customer_trx_id 9 AND rctld.customer_trx_line_id = rctl.customer_trx_line_id 10 AND rctld.account_class = 'REV' 11 AND rct.complete_flag = 'Y' 12 AND rct.primary_salesrep_id = AND rct.trx_date BETWEEN to_date(' ','dd.mm.yyyy') 14 AND to_date(' ','dd.mm.yyyy') 15 ; SUM(RCTLD.AMOUNT) ,25

86 Sprotna analitična obdelava v izbranem podjetju Stran 77 Do identičnega rezultata pa smo prišli tudi v kocki UNIOR_PRODAJA, če smo fiksirali dimenzijo Prodajalec ter si ogledali vrednost prodaje v letu 2008, s čimer smo potrdili pravilnost. Podatke, shranjene v delovnih prostorih, lahko hitro analiziramo kar s pomočjo na Sliki 34 prikazanega AWM pregledovalnika mer (angl. Measure Data Viewer). Na tak način lahko preverimo več različnih podatkov ter skupne seštevke, s čimer hitro potrdimo ali ovržemo pravilnost agregiranih podatkov celotne kocke. Slika 34: Kocka UNIOR_PRODAJA za referentko Mihaelo Fendre Dostop s pomočjo SQL-a Kot že omenjeno, se SQL povpraševanja tvorijo s pomočjo funkcije OLAP_TABLE, ki večdimenzijske podatke iz kocke prezentira v relacijski dvodimenzijski obliki, kjer so posamezni nivoji dimenzij dejansko relacijske vrstice. Funkcijo po navadi uporabimo v povezavi s pogledi, nad katerimi potem izvajamo dejanska povpraševanja, kot je praksa v klasičnih relacijskih okoljih. Glede na povpraševanje nam pogled vrne ustrezne rezultate, ki jih bodisi nadalje obdelujemo bodisi prikažemo kot končne rezultate.

87 Sprotna analitična obdelava v izbranem podjetju Stran 78 Sintaksa definicije pogleda dimenzije: CREATE OR REPLACE VIEW ime_pogleda AS SELECT kolona_1, kolona_2, kolona_n FROM TABLE(OLAP_TABLE( 'ime_delovnega_področja', 'tabela_objektov', 'opcijski_dml_ukazi', 'parameter_limit_map')) [MODEL stavek]; Omenimo, da se pri definiciji pogledov za boljše performance lahko uporablja posebni MODEL stavek, ki ga ne bomo posebej razlagali. Parameter limit_map je dejanski opis preslikave dimenzijskih struktur v relacijske stolpce. Primer parametra za dimenzijo račun: DIMENSION RACUN FROM RACUN WITH - HIERARCHY RACUN_PRIMARNA_PRNT FROM RACUN_PARENTREL(RACUN_HIERLIST \'PRIMARNA\') - INHIERARCHY RACUN_INHIER - FAMILYREL RACUN_VSE_LVLDSC, - RACUN_VRSTA_LVLDSC, - RACUN_TIP_LVLDSC - FROM RACUN_FAMILYREL(RACUN_LEVELLIST \'VSE\'), - RACUN_FAMILYREL(RACUN_LEVELLIST \'VRSTA\'), - RACUN_FAMILYREL(RACUN_LEVELLIST \'TIP\') - LABEL RACUN_LONG_DESCRIPTION - ATTRIBUTE RACUN_LEVEL FROM RACUN_LEVELREL Primer pogleda dimenzije racun: CREATE OR REPLACE FORCE VIEW "GLOBAL"."RACUN_DIMVIEW" ("RACUN", "RACUN_LEVEL", "RACUN_TIP_LVLDSC", "RACUN_VRSTA_LVLDSC", "RACUN_VSE_LVLDSC", "RACUN_PRIMARNA_PRNT") AS SELECT "RACUN","RACUN_LEVEL","RACUN_TIP_LVLDSC","RACUN_VRSTA_LVLDSC","RACUN_ VSE_LVLDSC","RACUN_PRIMARNA_PRNT" FROM table(olap_table ('GLOBAL.GLOBAL duration session', '', '', '&(RACUN_LIMITMAP)')) MODEL DIMENSION BY (RACUN) MEASURES ( RACUN_LEVEL, RACUN_TIP_LVLDSC, RACUN_VRSTA_LVLDSC, RACUN_VSE_LVLDSC, RACUN_PRIMARNA_PRNT ) RULES UPDATE SEQUENTIAL ORDER();

88 Sprotna analitična obdelava v izbranem podjetju Stran 79 Za primer prodaje smo ustvarili poglede za dimenzije in glavni pogled za kocko: CAS_DIMVIEW DELITEV_DIMVIEW IZDELEK_DIMVIEW PRODAJALEC_DIMVIEW RACUN_DIMVIEW STRANKA_DIMVIEW UNIOR_PRODAJA_CUBEVIEW V pogledu UNIOR_PRODAJA_CUBEVIEW imamo navidezno vse možne kombinacije hierarhij, nivojev dimenzij in pripadajočih vrednosti, ki jih lahko enostavno pridobimo z ustrezno poizvedbo. V Primeru 9 je prikazana poizvedba, ki nam vrne vrednost prodaje IZVIJAČEV v državo Francija za leto Dejanske vrednosti se v poglede napolnijo šele ob izvajanju poizvedbe glede na parametre, definirane v pogojih poizvedbe. Tako imamo navidezno na voljo relacijske objekte, ki se obnašajo kot navadne tabele z vsemi možnimi kombinacijami dimenzij. Primer 9: Primer SQL poizvedbe nad kocko UNIOR_PRODAJA SQL> execute dbms_aw.aw_attach('global', true); PL/SQL procedure successfully completed. SQL> select 2 cas_dim.cas_leto_lvldsc leto, 3 izdelek_dim.izdelek_skupina_lvldsc skupina_izdelka, 4 stranka_dim.stranka_drzava_lvldsc drzava, 5 prodaja_fact.vrednost vrednost 6 from 7 cas_dimview cas_dim, 8 delitev_dimview delitev_dim, 9 izdelek_dimview izdelek_dim, 10 prodajalec_dimview prodajalec_dim, 11 racun_dimview racun_dim, 12 stranka_dimview stranka_dim, 13 unior_prodaja_cubeview prodaja_fact 14 where 15 --povezave 16 prodaja_fact.cas = cas_dim.cas 17 and prodaja_fact.delitev = delitev_dim.delitev 18 and prodaja_fact.izdelek = izdelek_dim.izdelek 19 and prodaja_fact.prodajalec = prodajalec_dim.prodajalec 20 and prodaja_fact.racun = racun_dim.racun 21 and prodaja_fact.stranka = stranka_dim.stranka 22 --nivoji 23 and cas_dim.cas_level = 'LETO' 24 and delitev_dim.delitev_level = 'VSE' 25 and izdelek_dim.izdelek_level = 'SKUPINA' 26 and prodajalec_dim.prodajalec_level = 'VSI' 27 and racun_dim.racun_level = 'VSE' 28 and stranka_dim.stranka_level = 'DRZAVA' 29 --pogoji 30 and cas_dim.cas_leto_lvldsc = '2008' 31 and delitev_dim.delitev_vse_lvldsc = 'VSE' 32 and izdelek_dim.izdelek_skupina_lvldsc = 'IZVIJAČI' 33 and prodajalec_dim.prodajalec_vsi_lvldsc = 'VSI' 34 and racun_dim.racun_vse_lvldsc = 'VSI' 35 and stranka_dim.stranka_drzava_lvldsc = 'Francija' 36 ; LETO SKUPINA_IZDELKA DRZAVA VREDNOST IZVIJAČI Francija 10787,36

89 Sprotna analitična obdelava v izbranem podjetju Stran Dostop s pomočjo OLAP API Najpogosteje uporabljeno orodje za analiziranje podatkov v podjetjih je gotovo urejevalnik preglednic Microsoft Excel. Ravno iz tega razloga smo do podatkov naše kocke UNIOR_PRODAJA poskusili dostopati tudi na ta način. Dostop do podatkov iz baze je omogočen preko OLAP API vmesnika in preden sploh lahko vzpostavimo povezavo z OLAP bazo, potrebujemo dodatek (angl. plugin) za Excel, ki se imenuje Oracle Business Intelligence Spreadsheet Add-In, ki ga lahko brezplačno prenesemo s spleta. Po namestitvi imamo v urejevalniku dodatni zavihek Dodatki z menijem OracleBi, kjer so na voljo orodja in funkcije za delo z večdimenzijskimi podatki. Na Sliki 35 je primer povezave. Za dostop do baze kreiramo novo povezavo, kjer navedemo ime baze, port in ime gostitelja ter vnesemo podatke o delovni shemi, kjer je delovno področje z našo kocko. S pomočjo čarovnika izberemo mere ter dimenzije, ki jih želimo na preglednici, oblikujemo izgled preglednice in po potrebi dodamo še poljubne pogoje za prikaz. Slika 35: Dostop do podatkov kocke UNIOR_PRODAJA preko Excel-a