UNIVERZA V MARIBORU EKONOMSKO-POSLOVNA FAKULTETA

MARIBOR

DIPLOMSKO DELO ANALIZA PRODAJE S POMOČJO PODATKOVNEGA SKLADIŠČA V

PODJETJU PALOMA, D. D.

Kandidat: Tomaž KOMAN Študent izrednega študija Številka indeksa: 81519688 Program: visokošolski strokovni program Študijska smer: Podjetniška informatika Mentor: mag. Miroslav Petrič

Sladki Vrh, september, 2004

UNIVERZA V MARIBORU Ekonomsko-poslovna fakulteta

IZJAVA Kandidat, Tomaž KOMAN, absolvent študijske smeri Podjetniška informatika, študijski program Poslovna ekonomija (VS/96), izjavljam, da sem avtor tega diplomskega dela, ki sem ga napisal pod mentorstvom mag. Miroslava Petriča in uspešno zagovarjal 04.11.2004 . Zagotavljam, da je besedilo diplomskega dela v tiskani in elektronski obliki istovetno in brez virusov. Ekonomsko-poslovni fakulteti dovolim objavo diplomskega dela v elektronski obliki na spletnih straneh knjižnice. Hkrati dovoljujem, da ga lahko bralci uporabijo za svoje izobraževalne in raziskovalne namene s povzemanjem posameznih misli, idej, konceptov oziroma delov teksta iz diplomskega dela ob upoštevanju avtorstva in korektnem citiranju. Maribor, 04.11.2004 Podpis:

2

Predgovor Da bi lahko podjetja obvladovala vedno večji obseg poslovanja, so začela graditi transakcijske sisteme, ki so na operativnem nivoju podpirali njihovo poslovanje oziroma njihove vsakodnevne postopke. V devetdesetih letih pa je postalo poslovanje še kompleksnejše. Tržno gospodarstvo ustvarja vse bolj konkurenčno poslovno okolje, kjer je prostor le za najboljše. Za tiste, ki vlečejo prave poteze, za tiste, ki sprejemajo prave odločitve. Pravilno odločanje pa je mogoče samo, če so na voljo točne, pravočasne in transparentne informacije. Menedžerji na najvišji organizacijski ravni odločajo o problemih, ki so strateško pomembni za njihovo podjetje. Potrebujejo informacije iz okolja in informacije o dejavnikih znotraj podjetja, da lahko uspešno vodijo podjetje. Obstoječi transakcijski sistem, ki je namenjen za obvladovanje velikega števila podatkov, ki nastajajo z vsakodnevnimi opravili, ni bil več primeren za zagotavljanje informacij, ki so potrebna pri odločanju. Pojavila se je potreba po novem načinu pridobivanja informacij, s katerim bi lahko podjetje zadovoljilo potrebe in želje kupcev, načrtovalo tržno uspešno proizvodnjo, pripravljalo in izvajalo uspešne oglaševalne aktivnosti. Zato mora podjetje zgraditi nov sistem za podporo odločanja. Dober sistem za podporo odločanja olajša strokovnjakom in vodilnim izvajanje analitičnih nalog na njihovih poslovnih področjih in jim omogoča interpretacijo informacij v njim prilagojeni obliki. Sistem za podporo odločanja ob vsakem trenutku omogoča izdelavo poročil, katerih kriterije in predstavitev lahko uporabniki hitro prilagodijo glede na poslovne potrebe brez dragega poseganja informacijskih strokovnjakov. Ker sodobni sistemi za podporo odločanja temeljijo na konceptu podatkovnih skladišč, se bom v diplomski nalogi ukvarjal s problemom načrtovanja podatkovnega skladišča in njihovo implementacijo. Načrt izgradnje podatkovnega skladišča se bo nanašal na konkretno, v praksi izvedeno, izgradnjo podatkovnega skladišča v podjetju Paloma, d. d. Diplomsko delo je razdeljeno na tri tematske sklope. V prvem delu opisujem, zakaj prihaja pri pridobivanju podatkov do problemov, če podjetja gradijo sisteme za podporo odločanja, ki črpajo podatke direktno iz transakcijskih sistemov1. V drugem delu opisujem podatkovno skladišče. Na kratko bom predstavil osnovne elemente podatkovnega skladišča in procese, ki tečejo v podatkovnem skladišču. Predstavil bom dimenzijsko modeliranje, ki služi kot analitičen pripomoček pri planiranju podatkovnega skladišča in kot fizičen dizajn za njegovo implementiranje v relacijsko podatkovno zbirko. V nadaljevanju bom predstavil metodologijo »The Business Dimensional Lifecycle«, za načrtovanje podatkovnega skladišča. V zadnjem delu pa bom prikazal praktičen primer izgradnje podatkovnega skladišča oziroma področnega skladišča za prodajo in uporabo programa MS Excel za preučevanje podatkov iz podatkovnega skladišča.

1 Transakcijski informacijski sistemi (OLTP) so poslovni informacijski sistemi, ki omogočajo varno izvedbo več tisoč poslovnih transakcij med fizičnimi ali pravnimi subjekti. Transakcijski sistemi so povezani s podatkovno zbirko, ki vsebuje podatke o subjektih in objektih transakcij.

3

KAZALO 1 UVOD ................................................................................................................................ 5

1.1 Opredelitev področja in opis problema ................................................................................................ 5 1.2 Namen, cilji in trditve diplomskega dela ............................................................................................. 5 1.3 Predpostavke in omejitve ..................................................................................................................... 6 1.4 Metodologija raziskovanja................................................................................................................... 6

2 ZAKAJ POTREBUJEMO PODATKOVNO SKLADIŠČE.............................................. 7 2.1 OLTP ................................................................................................................................................... 7 2.2 Sistem za podporo odločanja ............................................................................................................... 7 2.3 Informacijska kriza .............................................................................................................................. 8 2.4 Napake v prejšnjih sistemih za podporo odločanja .............................................................................. 9 2.5 Faze pri odločanju.............................................................................................................................. 10 2.6 Zgodovina sistemov za podporo odločanja........................................................................................ 10 2.7 Tehnološki trendi ............................................................................................................................... 12 2.8 Podatkovno skladišče – edina možna rešitev ..................................................................................... 12

3 PODATKOVNO SKLADIŠČE ....................................................................................... 14 3.1 Podatkovno skladišče......................................................................................................................... 14 3.2 Osnovni elementi podatkovnega skladišča ........................................................................................ 14 3.3 Procesi v podatkovnem skladišču ...................................................................................................... 19 3.4 Poslovni proces in dimenzijsko modeliranje...................................................................................... 19 3.5 Dimenzijsko modeliranje ................................................................................................................... 20 3.6 Zvezdasta in snežinkasta struktura..................................................................................................... 21

3.6.1 Zvezdasta struktura ....................................................................................................................... 21 3.6.2 Snežinkasta struktura..................................................................................................................... 22

3.7 OLAP................................................................................................................................................. 22 3.7.1 Potreba po novem orodju .............................................................................................................. 22 3.7.2 Orodja OLAP ................................................................................................................................ 23 3.7.3 Kocka OLAP................................................................................................................................. 24 3.7.4 Shranjevanje kock OLAP.............................................................................................................. 25 3.7.5 Odjemalci OLAP........................................................................................................................... 25

3.8 Načrtovanje podatkovnega skladišča ................................................................................................. 25 3.8.1 The Business Dimensional Lifecycle ............................................................................................ 25 3.8.2 Planiranje projekta ........................................................................................................................ 26 3.8.3 Definicija poslovnih zahtev........................................................................................................... 27 3.8.4 Podatki: Dimenzijsko modeliranje ................................................................................................ 27 3.8.5 Podatki: Fizični dizajn................................................................................................................... 27 3.8.6 Podatki: Dizajn okolja za podatkovno hrambo in kocke OLAP.................................................... 27 3.8.7 Tehnologija: Načrtovanje tehnične arhitekture podatkovnega skladišča ...................................... 28 3.8.8 Tehnologija: Izbira produkta, inštalacija....................................................................................... 28 3.8.9 Programi: Specifikacija programov za uporabnike ....................................................................... 29 3.8.10 Uvajanje ................................................................................................................................... 29 3.8.11 Izvajanje in vzdrževanje ........................................................................................................... 29

4 PRAKTIČEN PRIMER IZGRADNJE PODATKOVNEGA SKLADIŠČA................... 30 4.1 Izdelava podatkovnega skladišča ....................................................................................................... 30 4.2 Priprava zagonskega elaborata........................................................................................................... 30 4.3 Poslovne zahteve................................................................................................................................ 30 4.4 Dimenzijsko modeliranje ................................................................................................................... 32 4.5 Fizični dizajn relacijske podatkovne zbirke ....................................................................................... 34 4.6 Dizajn okolja za podatkovno hrambo in kocke OLAP....................................................................... 34

4.6.1 Proces zajemanja podatkov iz virov.............................................................................................. 34 4.6.2 Proces, ki napolni dimenzije in tabelo dejstev iz podatkovne hrambe .......................................... 35 4.6.3 Proces kreiranja kocke OLAP in polnjenje kocke OLAP ............................................................. 36

4.7 Načrtovanje tehnične arhitekture podatkovnega skladišča, izbira produkta in inštalacija ................. 37 4.8 Specifikacija programov za uporabnike............................................................................................. 38 4.9 Uvajanje ............................................................................................................................................. 38 4.10 Izvajanje in izobraževanje.................................................................................................................. 38 4.11 Preučevanje podatkov z MS Excelom................................................................................................ 39

5 SKLEP.............................................................................................................................. 42

4

POVZETEK ............................................................................................................................. 43 SEZNAM LITERATURE........................................................................................................ 44 KAZALO TABEL.................................................................................................................... 45 KAZALO SLIK........................................................................................................................ 45

5

1 UVOD

1.1 Opredelitev področja in opis problema Danes delujejo podjetja v okolju, ki je dinamično in nestabilno. Uspešnost sodobnega podjetja je odvisna predvsem od sposobnosti njegovih menedžerjev, da pravočasno zaznajo in izkoristijo priložnosti v okolju, v katerem podjetje deluje. Da bi lahko ti natančno ocenili in izbrali tiste priložnosti, ki prinašajo največje korist, potrebujejo informacije. Zaposleni v prodaji niso bili zadovoljni z obstoječimi programskimi rešitvami v prodaji in marketingu. Čeprav se redno zbirajo najrazličnejši podatki, so vedno težave s poročili. Problemi nastopijo takoj, ko se delajo zahtevnejše analize, kjer na primer uporabnik želi dobiti primerjave vsot ali povprečij iz več let nazaj, mesečne rasti prodaje in kategorije izdelkov ter izmeriti sedanje povpraševanje in napovedati prihodnjo prodajo. Takšne analize so praviloma zamudne, večinoma zahtevajo tudi delno predpripravo podatkov. Obenem marsikdaj motijo računalniške rešitve na operativni ravni (OLTP sistemi), ki zagotavljajo sprotno procesiranje poslovnih dogodkov. Da bi lahko podjetje zadovoljilo potrebe in želje kupcev, načrtovalo tržno uspešno proizvodnjo, pripravljalo in izvajalo uspešne oglaševalne aktivnosti, mora zgraditi sistem za podporo odločanja. Ker sodobni sistemi za podporo odločanja temeljijo na konceptu podatkovnih skladišč, se bom v diplomski nalogi ukvarjal s problemom načrtovanja podatkovnega skladišča in njegovo implementacijo. Načrt izgradnje podatkovnega skladišča se bo nanašal na konkretno, v praksi izvedeno, izgradnjo podatkovnega skladišča v podjetju Paloma, d. d.

1.2 Namen, cilji in trditve diplomskega dela NAMEN Rešitev problema zanima podjetje Paloma, d. d., uporabilo ga bo namreč v praksi. Namen diplomskega dela je opis izgradnje podatkovnega skladišča za prodajno funkcijo. Podatkovno skladišče bo omogočilo enostavnejši dostop do informacij in s tem možnost za lažje odločanje. CILJI

• Najti metodologijo izgradnje podatkovnega skladišča. • Ugotoviti osnovne elemente podatkovnega skladišča in njihovo povezanost med

seboj. • Ugotoviti potrebne procese, ki se odvijajo v podatkovnem skladišču.

6

• Raziskati postopke, kako načrtovati izgradnjo kocke OLAP2 in snežinkaste strukture.

• Raziskati postopke, ki so potrebni za predstavitev podatkov z aplikacijo Excel.

TRDITVE • Računalniška rešitev na operativni ravni ni primerna za pridobivanje primernih

informacij za podporo odločanja. • Faze izgradnje podatkovnega skladišča si sledijo po določenem vrstnem redu. Faza

»Pridobivanje poslovnih zahtev« je ključnega pomena pri načrtovanju podatkovnega skladišča.

• Procesi v podatkovnem skladišču si sledijo v verižnem vrstnem redu. Vsak predhodni proces je bistven za nadaljevanje naslednjega.

• Brez kocke OLAP in orodji OLAP ni možno enostavno narediti kompleksnih analiz.

1.3 Predpostavke in omejitve Glavna predpostavka je, da sodobni informacijski sistemi za menedžment temeljijo na konceptu podatkovnih skladišč. Izgradnja podatkovnega skladišča je zahteven projekt, zato ga ne nameravam prikazati v celoti, ampak le ključne faktorje, ki so po mojem mnenju pomembni za njegovo uspešnost. Raziskava se bo nanašala na prodajni del poslovanja. Pri izgradnji podatkovnega skladišča sem uporabil programsko opremo podjetja Microsoft. Pri podpoglavju Preučevanje podatkov z MS Excelom so določeni podatki zakriti.

1.4 Metodologija raziskovanja Pri diplomski nalogi bom uporabil poslovno raziskavo. Diplomsko delo temelji na teoretičnem opisu izgradnje podatkovnega skladišča. K opisu izgradnje podatkovnega skladišča sem pristopil deskriptivno. Pri izdelavi diplomskega dela so uporabljene sledeče metode:

• preučitev širšega področja problema ter opredelitev osnovnih pojmov na podlagi domače in tuje literature,

• razgovori z zaposlenimi v prodaji, • analiza teoretičnih in praktičnih rešitev na področju podatkovnih skladišč, • analiza podatkov za izgradnjo podatkovnega skladišča.

2 Sprotna analitična obdelava ali OLAP (On-Line Analytical Processing) je tehnologija, ki omogoča uporabnikom hiter ter zanesljiv vpogled in dinamično analizo večdimenzionalnih podatkov.

7

2 ZAKAJ POTREBUJEMO PODATKOVNO SKLADIŠČE

2.1 OLTP Poslovanje podjetja sestoji iz številnih funkcij, tako ročnih kot avtomatiziranih. Nekatere med njimi so zelo enostavne, na primer obdelava naročila od trenutka prejema kupčevega naloga do zagotovitve, da se zahtevano blago odpremi na njegov naslov. Nekatere druge pa so lahko zelo kompleksne, kot so primer obdelava osebnih dohodkov v velikem podjetju, ki zajema številne podsisteme, s katerimi se spremljajo število opravljenih ur na delu, nadure, odsotnosti, spremembe v vrednosti točk, spremembe različnih davkov, prispevkov in podobno (Srića 1995, 46). Potrebe po nekaterih računalniških aplikacijah so jasne. Na primer, komercialni sistem omogoča spremljanje materialnega poslovanja, prodajo, nabavo in drugo. Kadrovski sistem je namenjen zbiranju in obdelavi vseh vrst podatkov o zaposlenih (lastnosti, znanje, družinski člani in podobno). Kaj imajo te aplikacije skupnega? Vse aplikacije podpirajo določen poslovni proces v podjetju in omogočajo učinkovito zbiranje transakcijskih podatkov. So nujne za normalno poslovanje podjetja, saj omogočajo učinkovito opravljanje vsakodnevna opravila na operativnem nivoju. Brez teh računalniških aplikacij ne more preživeti nobeno sodobno podjetje. Vse te aplikacije tvorijo tako imenovani transakcijski informacijski sistem (sistem OLTP – Online Transaction Processing System). Podjetja so začela graditi sisteme OLTP v šestdesetih letih in so postala popolnoma odvisna od njih. Ko podjetje raste in se razvija je treba narediti na stotine računalniških programov, ki nudijo podporo v različnih poslovnih funkcijah. Dnevno zbirajo, obdelujejo, shranjujejo in posredujejo podatke in informacije za potrebe upravljanja, odločanja in nadzora poslovnih funkcij. V devetdesetih letih je postalo poslovanje še kompleksnejše. Tržno gospodarstvo ustvarja vse bolj konkurenčno poslovno okolje, kjer je prostor le za najboljše. Za tiste, ki vlečejo prave poteze, za tiste, ki sprejemajo prave odločitve. Pravilno odločanje pa je mogoče samo, če so na voljo točne, pravočasne in transparentne informacije. Menedžerji na najvišji organizacijski ravni odločajo o problemih, ki so strateško pomembni za njihovo podjetje. Potrebujejo informacije za določanje poslovnih strategij, določanje ciljev in nadzorovanje rezultatov. Za uspešno odločanje pa potrebujejo informacije iz okolja in informacije o dejavnikih znotraj podjetja. Sistem OLTP, ki je namenjen za obvladovanje velikega števila podatkov, ki nastajajo z vsakodnevnimi opravili, ni bil primeren za zagotavljanje informacij za podporo odločanja, zato se je pojavila potreba po novem načinu pridobivanja informacij.

2.2 Sistem za podporo odločanja Kakovost odločitve (ko se na primer odločamo za določeno poslovno strategijo) je odvisna od kakovosti informacij, ki jih imamo na voljo. Ustrezna informacija zmanjšuje tveganje in negotovost pri sprejemanju odločitev. Dandanes se ne moremo več pritoževati zaradi

8

pomanjkanja podatkov in informacij. Kvečjemu jih imamo v preobilju. Tako se zaradi pomembnosti informacij pri poslovnem odločanju, neustreznem ravnanju z informacijami, ki so na voljo in izjemno visoki stopnji uporabe osebnih računalnikov pri delu pojavlja potreba po sistemih za podporo odločanja (SPO). SPO vsebujejo poleg podatkovne baze tudi bazo tehnik, metod, napovedi in statistik, kar daje možnost boljšega oblikovanja informacijskih pregledov. S takšnim sistemom je mogoče oblikovati sporočila v skladu s problemom odločanja ter zagotoviti pomembne nadgrajene informacije (Srića 1995, 74). SPO je mogoče vpeljati šele tedaj, ko v podjetju pred tem že razvijejo sistem OLTP. SPO podpirajo menedžment pri odločanju, omogočajo prikazovanje različnih poslovnih podatkov iz sistemov OLTP in iz drugih podatkovnih virov, omogočajo analizo prikazanih podatkov, omogočajo pripravo kvantitativnih odločitvenih modelov, napovedovanje posledic odločitev – simuliranje; »kaj če« (what if) in »iskanje ciljev« (goal seek). Uspešnost sodobnega podjetja je torej odvisna predvsem od sposobnosti njegovih menedžerjev, da pravočasno zaznajo in izkoristijo priložnosti v okolju, v katerem deluje podjetje. Poleg tega morajo tudi opaziti nevarnosti iz okolja. Določitev priložnosti in nevarnosti sta mogoča le na podlagi informacij, da bi pa lahko podjetje izkoristilo priložnosti in odpravili nevarnosti iz okolja, pa mora imeti informacije o lastnih prednostih in slabostih (ibidem, 151).

2.3 Informacijska kriza Ne glede na velikost podjetja veliko število aplikacij, podatkovnih baz ali velika količina informacij3, ki je potrebna za nemoteno delovanje poslovnih funkcij podjetja, se nam postavlja vprašanje, za koliko let nazaj imamo shranjene informacije o kupcih, prodaji, finančne informacije, kadrovske informacije in kje so vse te informacije? Soočeni smo lahko z naslednjimi dejstvi (Ponniah 2001, 4):

• podjetje je izgubilo podatke in s tem informacije, • informacijski sistem ni zmožen učinkovito vseh teh podatkov pretvoriti v uporabne

strateške informacije. Če imamo veliko količino podatkov v podjetju, zakaj potem menedžerji ne uporabljajo teh podatkov? Zakaj potem lahko govorimo o informacijski krizi? Veliko podjetji se sooča z informacijsko krizo, ne zaradi pomanjkanja podatkov, ampak zaradi načina hranjenja podatkov, ki so lahko shranjeni v neprimerni obliki ali na različnih mestih in jih ni mogoče uporabiti pri sprejemanju strateških odločitvah. Ti podatki so uporabni pri zagotavljanju poročil o vsakodnevnih poslovnih dogodkih (na primer pregled prodanega blaga ali pregled knjigovodskih sprememb), vendar delno uporabni pri odločanju o poslovnih strategijah.

3 Za podatke lahko ugotovimo, da so nizi znakov, ki pojasnjujejo pojave. Izraženi so z različnimi znaki. Podatki lahko dosežejo pri prejemniku različno stopnjo namembnosti. Ker se prejemniki različno odzivajo nanje, podatki ne dosežejo vedno v celoti svojega namena. Če prejemnik podatke o določenem pojavu le zazna, prejme s tem sporočilo o tem pojavu. Če prejemnik sprejme in dojame sporočilo, ki zanj pomeni nekaj novega, je s tem dobil novico. Sporočilo pa je za prejemnika informacija šele v primeru, če je nanjo reagiral z akcijo (Bobek 1995, 30).

9

Podatki o poslovanju so lahko shranjeni na različnih računalniških sistemih in v različnih formatih. Nekateri podatki so shranjeni na računalnikih s starejšim operacijskim sistemom, v tekstovnih datotekah. Zaposleni uporabljajo pri svojem delu preglednice, zato so podatki lahko shranjeni tudi v preglednicah ali pa so shranjeni v relacijskih bazah. Več, kot se je uporabljalo različnih računalniških tehnologij v podjetju, tembolj so podatki razpršeni po podjetju in zapisani v različnih formatih. Da bi lahko menedžerji sprejemali pravilne odločitve, pa potrebujejo vse te informacije integrirane v celovit sistem. Napoved povpraševanja je osnova za večino pomembnih odločitev v podjetju. Odločitve o višini zalog, nabavljenih količinah surovin in številu proizvedenih izdelkov so odvisne od predvidenega povpraševanja. Če v podjetju nimajo zanesljivih napovedi o bodočem povpraševanju po izdelkih, povečujejo tveganje za prekinitev proizvodne verige. Da bi pa lahko uspešno napovedovali povpraševanje, potrebujejo menedžerji informacije, da jih lahko nato uporabljajo pri svojih odločitvah. Menedžerji morajo zato imeti možnost pregleda poslovanja podjetja iz različnih zornih kotov.

2.4 Napake v prejšnjih sistemih za podporo odločanja Poglejmo si dve tipični situaciji v podjetju:

• Sektor za marketing analizira prodajo v izbrani regiji in ugotovi iz mesečnih poročil, da je prodaja drastična padla. Zato želi dobiti podatke o prodaji za dve leti nazaj. Sektor za marketing bi z analizo podatkov oblikoval novo strategijo, da popravi nastalo situacijo. V sektorju za informatiko ugotovijo, da nimajo takšnih poročil, kot jih želi sektor za marketing, zato je treba izdelati novo poročilo.

• Sektor za marketing že dolgo uporablja določeno poročilo. Nekega dne pride želja iz sektorja za marketing, da bi poročilo dodali dodatne kolone. Ko so dobili novo poročilo, so ugotovili, da poročilo še vedno ni takšno kot so si želeli, zato ponovno želijo spremembo poročila. Nato so še ugotovili nekonsistentnost podatkov na različnih poročilih.

Opisana primera nam pokažeta kako uporabniki pridobivajo informacije. Postopki so zamudni, v sektorju informatike imajo zato veliko dela s programiranjem novih ali spreminjanjem starih poročil. Uporabniki pogosto tudi ne morejo točno definirati, kaj potrebujejo. Šele ko vidijo poročilo, ugotovijo, kaj potrebujejo. Vse to vodi do slabe volje v oddelku informatike, saj morajo ponovno spreminjati programe, kar vzame veliko časa. Posledično pa uporabniki ne naročajo novih poročil zaradi nezadovoljstva v sektorju informatike. Vse to pa ima za posledico pomanjkanja informacij. Z leti tako nastane veliko število novih poročil, aplikacij, ki zbirajo podatke iz različnih virov in začasno shranjujejo podatke za kasnejšo uporabo. Vse skupaj tvori veliko število aplikacij, poročil in začasnih podatkovnih zbirk. Imamo tako imenovano situacijo »Poročevalskih špagetov« (glej sliko 1). Celoten tak sistem pa je težko vzdrževati. Podatki so v takšnem sistemu velikokrat podvojeni in so zelo verjetno tudi nekonsistentni.

10

SLIKA 1: POROČEVALSKI ŠPAGETI

OLTP

Porabniki informacij

Programi, poročila, začasne podatkovne baze

Vir: Berce (2001b, str. 9)

2.5 Faze pri odločanju Kot smo že omenili, uporabniki pogosto ne morejo točno definirati, kaj potrebujejo. Šele ko prepoznajo problem, lahko izberejo možno rešitev. Izbrano rešitev problema nato realizirajo. Nato ocenijo uspeh. Če niso zadovoljni z uspehom ponovno preučijo problem. Ponavljanje se nadaljuje tako dolgo dokler ni izbrana rešitev uspešna. Iz slike 2 je razviden iterativen proces pri odločanju, ki je odvisen od informacij in povratne zveze. SLIKA 2: FAZE PRI ODLOČANJU

Vir: Srića (1995, str 64)

2.6 Zgodovina sistemov za podporo odločanja Odločitveni proces je proces preoblikovanja informacij v odločitve. Informacija je zato surovina za odločitveni proces, proizvod pa je upravljalni ukrep. Ko je odločevalec soočen

Prepoznavanje problema

Ugotavljanje morebitnih rešitev

Izbor

Akcija

Ocena uspeha

OK

11

z odločitveno situacijo in v okviru nje z možnimi alternativami, se odloči za tisto, s katero bo dosegel želene cilje. Pri tem izhaja iz znanja, ki ga ima nakopičenega v sebi. Če z znanjem, ki ga ima, tega ne more narediti, potrebuje dodatno znanje, ki mu ga mora zagotoviti informacijski sistem z informacijo (Bobek 1995, 47). SPO je računalniški informacijski sistem, sestavljen iz množice strojne opreme, programske opreme in ljudi. Namen SPO je podpora uporabnikom pri procesu odločanja tako na operativnem kot na taktičnem in strateškem nivoju (glej sliko 3). SLIKA 3: VODSTVENE RAVNI V PODJETJU

Vir: Koletnik, Kovač, Rozman (1993, str. 22) V odvisnosti od velikosti podjetja in poslovanja so podjetja pridobivala strateške informacije na različne načine (Ponniah 2001, 8):

• Ad hoc poročila – Ta stopnja je bila na začetku. Uporabniki so poslali zahtevo za izdelavo specialnih poročil. Programi so se pisali za vsako poročilo posebej.

• Posebni zbirni programi – Razvijalci programov so vnaprej predvidevali, katera poročila se občasno izvajajo. Izdelala se je serija programov, ki so se izvajali periodično, da bi lahko zbirali podatke iz različnih sistemov in/ali datotek. Podatki so nato služili kot osnova za pripravljena poročila.

• Male aplikacije – Napisale so se enostavne aplikacije, ki so črpale podatke iz zbirnih datotek. Uporabniki so lahko postavljali pogoje s parametri. Poročila so lahko uporabniki pregledovali tudi na ekranih.

• Informacijski centri – Uporabniki so lahko v informacijskih centrih naročili programe ali pa pogledali podatke na ekranih. To so bili že vnaprej pripravljeni programi ali ekranske slike.

• SPO – Podjetja so začela graditi posebne sisteme za zagotavljanje strateških informacij. Spet, kot v prejšnjih stopnjah, so ti sistemi pridobivali podatke iz zbirnih tabel. Aplikacije so bile narejene na osnovi menijev.

12

• Direktorski informacijski sistem – Osnovni namen je prikazati strateške informacije na enostaven način, uporaba aplikacij pa mora biti enostavna za uporabo. Sistem omogoča tudi enostavne poizvedbe, vendar so bile na razpolago samo ekranske slike in poročila. Programi so bili narejeni namensko za posameznega uporabnika. Če je menedžer želel videti dodatno podatkovno analizo tudi po drugih kriterijih (regijo, izdelek), je moral takšen program že obstajati. Te omejitve so povzročale nezadovoljstvo pri menedžerjih.

Vsi opisani poskusi, da bi zagotavljali strateške informacije, so bili bolj ali manj neuspešni. Kaj je glavni razlog prejšnjih SPO za neuspešnost? Osnovni razlog je bil, da so poizkušali pridobivati strateške informacije iz sistemov OLTP.

2.7 Tehnološki trendi Tehnološke spremembe v računalniški strojni opremi so tako intenzivne, da v kakšni drugi veji tehnike težko najdemo podoben primer. Trenutno še nič ne kaže na to, da bi se takšna stopnja rasti že začela zmanjševati (Gradišar 2000, 145). Stare tehnike ne zadoščajo več novim trendom. Ekranske slike in različna poročila ne zadoščajo več željam uporabnikov. Zmanjšuje se cena strojne opreme in povečuje procesorska moč, stroški podatkovnega shranjevanja so vedno manjši, povečuje se hitrost podatkovnega prenosa po omrežjih. Znižanje cen strojne opreme je omogočilo, da je lahko računalnik na vsaki pisalni mizi. Z novimi aplikacijami je postalo delo z računalnikom prijaznejšo in enostavnejšo. Izboljšana povezljivost, povečana hitrost omrežji in interneta so omogočili dostopnost do velikanskega števila podatkov. Da lahko zagotavljamo strateške informacije, potrebujemo veliko podatkov shranjenih v ustreznih formatih. Nova tehnologija je omogočila, da se lahko shranjuje velika količina podatkov ob nizkih stroških. Menedžerji tako lahko pridobivajo strateške informacije interaktivno. Obdelave velikih količin podatkov in interaktivni vmesniki zahtevajo dodatno računalniško moč. Povečanje računalniške moči v zadnjih letih in njihova relativno nizka cena pa je omogočila pridobitev strateških informacij s pomočjo osebnega računalnika. Kar pred nekaj leti z obstoječo tehnologijo ni bilo možno, je sedaj z novo tehnologijo možno.

2.8 Podatkovno skladišče – edina možna rešitev S sistemom OLTP je težko pregledovati podatke iz različnih zornih kotov. V sistemu OLTP podatki prikazujejo samo trenutno stanje (ni zgodovinskih podatkov) in so lahko shranjeni na različnih sistemih in v različnih formatih. Poizvedbe in različni izpisi, ki črpajo podatke iz sistema OLTP, velikokrat motijo sam sistem OLTP. Zato lahko sklepamo, da sistemi OLTP niso primerni za pridobivanje strateških informacij za podporo odločanja.

13

Kot smo ugotovili, potrebujemo drugačen SPO. Potrebujemo nov sistem, ki bo namenjen samo za pridobivanje strateških informacij. Lastnosti novega sistema naj bi bile naslednje (Ponniah 2001, 12):

• podatkovna zbirka je načrtovana za analitične poizvedbe, • podatki so združeni iz različnih virov, • enostavna uporaba in načrtovana za interaktiven dostop do podatkov, • dostop do podatkov naj bo optimalen za intenzivno branje, • omogočeno dodajanje trenutnih in zgodovinskih podatkov in njihovo popravljanje, • sistem omogoča uporabnikom, da sprožajo poizvedbe in dobijo rezultate v živo.

Večina procesov v sistemu za pridobivanje strateških informacij bo analitičnih. Uporabnik bo lahko sprožal enostavne poizvedbe in poročila, da bo lahko analiziral trenutne in zgodovinske podatke. Podjetje, ki zgradi podatkovno skladišče, v resnici zgradi nov informacijski sistem. Novi informacijski sistem ima shranjene podatke ločeno od podatkov, ki jih potrebuje sistem OLTP. Sodobni SPO slonijo na podatkovnih skladiščih, kjer so vsi podatki smiselno urejeni in enostavno dostopni in omogočajo uporabnikom uporabo najsodobnejših tehnologij.

14

3 PODATKOVNO SKLADIŠČE

3.1 Podatkovno skladišče Podatkovno skladišče je lokacija, kjer so shranjeni podatki, ki vsebujejo strateške informacije. Podatkovno skladišče uporabniku zagotavlja informacije in s tem pomoč pri odločitvah. Podatkovno skladišče vsebuje:

• poslovne podatke, • integrirane zgodovinske podatke iz različnih virov, • vsebinsko usmerjene, prečiščene in skladne podatke.

Podatkovno skladišče, kot je definiral Bill Inmon, je podatkovno zbirka in ima naslednje lastnosti (Todman 2001, 32):

• vsebinsko usmerjeno na predmet, • nespremenljivost, • integriranost in konsistentnost, • časovna dimenzija.

Vsebinska usmerjenost na predmet pomeni, da so podatki organizirani okoli predmeta (npr. izdana faktura) in ne okoli aplikacij OLTP (kot je v primeru sistema OLTP »naročilo«). Nespremenljivost pomeni, da podatke, ki smo jih zapisali v podatkovno skladišče, ne spreminjamo več. Vsak, ki uporablja podatkovno skladišče, mora biti prepričan, da bo dobil vedno isti rezultat. Podatkovno zbirka v sistemu OLTP je izrazito spremenljiva in je malo verjetno, da bomo dobili pri poizvedbah vedno enake podatke. Integriranost in konsistentnost: podatki so vedno shranjeni v istem formatu. Integracija podatkov je problem velike večine podjetij, predvsem v podjetjih, ki uporabljajo različno informacijsko tehnologijo. Razlike se pojavljajo tudi pri različnih aplikacijah enake tehnologije, ko se uporabljajo različni podatkovni tipi za polja, ki opisujejo enako stvar. Da lahko podatki pridejo v podatkovno skladišče, pa morajo biti integrirani. Časovna dimenzija: beleži se zgodovina podatkov. Skoraj vse poizvedbe, ki berejo podatke iz podatkovnega skladišča, so v zvezi s časom. Podatkovno skladišče nam pomaga pri reševanju vprašanja, kaj se je dogajalo v preteklosti.

3.2 Osnovni elementi podatkovnega skladišča Podatkovno skladišče je sestavljeno iz različnih elementov. Slika 4 nam prikazuje osnovne elemente podatkovnega skladišča.

15

SLIKA 4: OSNOVNI ELEMENTI PODATKOVNEGA SKLADIŠČA

Vir: Kimball (1998, str 15) IZVORNI SISTEM Izvorni podatki lahko prihajajo v podatkovno skladišče iz različnih virov:

• OLTP, • notranji podatki, • zunanji podatki.

Sistemi OLTP so aplikacije, ki so namenjene za sprotno zbiranje podatkov poslovnih entitet. Zagotavljati morajo učinkovito vnašanje, ažuriranje in poizvedovanje majhnega števila vrstic podatkov naenkrat. Tipični značilnosti sta: hiter dostop do konkretnega zapisa podatkov in učinkovito obdelovanje majhnega števila transakcijskih podatkov hkrati. Da ti sistemi dosegajo te lastnosti, so običajno relacijski4 in normalizirani. V tem primeru nudijo

4 Vrsta podatkovne zbirke, v kateri so podatki organizirani tako, da ustrezajo pravilom relacijske teorije, torej v obliki tabel stolpcev in vrstic (zapisov), opremljenih s ključi, tabele pa so med seboj v odnosih. Zapisi v tabelah so prek posebnih polj med seboj povezani.

Hranilna naprava: Datoteka; Zbirka podatkov; Drugo Procesi: • čiščenje, • odstranjevanje, • združevanje, • odstranjevanje

dvojnih podatkov,

• standardizacija, • preoblikovanje, • arhiviranje, … Uporabniki ne morejo posegat v hrambo podatkov

Izvorni sistem

Okolje za hrambo podatkov

Področno skladišče 1: Dizajnirano je lahko za OLAP poizvedbe. Dimenzijsko modelirano, vsebinsko usmerjeno na predmet, dimenzije so lahko skupne, …

Področno skladišče 2:

Področno skladišče 3:

Dinamične poizvedbe

Razna poročila

Aplikacije za uporabnike

Modeli za predvidevanje, analizo, izkopavanje podatkov

Predstavitveni strežnik

podatkovnega skladišča

Orodja za dostop do podatkov za končnega uporabnika

Izločanje polnjenje

Izločanje polnjenje

Izločanje polnjenje

Nalaganje

Vnos rezultatov pridobljenih iz modelov

Vnos prečiščenih dimenzij

Skupne dimenzije in tabela dejstev

Skupne dimenzije in tabela dejstev

Nalaganje

Nalaganje

16

izjemno zmogljivost in zagotavljajo konsistenco podatkov. Relacijska podatkovna zbirka shranjuje podatke v več med seboj povezanih tabelah. Vsaka tabela vsebuje podatke o določeni entiteti, npr. o artiklih, partnerjih, dokumentih in drugo. Relacija pa je vzpostavljena tako, da imajo tabele atribute, ki so tuji ključi (ključi drugih tabel). Shema relacijske podatkovne zbirke je zato izredno razvejana in kompleksna, saj vsebuje veliko število hkratnih podatkovnih povezav med tabelami. Ker se vse transakcije beležijo v podatkovni bazi, je ta baza praviloma zelo velika. Zaradi velikega števila transakcijskih mest pa tudi polno obremenjena. Transakcijska podatkovna zbirka praviloma obsega le podatke omejenega časovnega obdobja, ponavadi enega poslovnega leta. Podatkovna zbirka, ki je optimizirana za transakcijske sisteme, mora biti normalizirana. To pomeni, da se podatki v podatkovni zbirki ne smejo nepotrebno podvajati. Pri podvajanju podatkov v tabeli se uvede novo tabelo ter se jo poveže z relacijo. Tako omogočimo enostavnejšo in hitrejšo ažuriranje podatkov. Relacijska struktura je izredno učinkovita za podatkovne zbirke OLTP. Atributi tabel so lahko indeksirani, da zagotovimo hitro poizvedovanje ali filtriranje (Kimball 1998, 14). Notranji podatki – v vsakem podjetju imajo določeni uporabniki v svojih preglednicah, dokumentih, včasih tudi v svojih podatkovnih zbirkah, podatke, ki bi bili koristni v podatkovnem skladišču. Dodajanje »notranjih podatkov« je kompleksni proces, sploh, če so shranjeni na različnih platformah. Zunanji podatki – veliko menedžerjev je odvisnih od podatkov, ki se nahajajo izven podjetja. Uporabljajo različne statistične podatke, podatke o konkurenci, standardne finančne indikatorje, demografske podatke. Z zunanjimi podatki lahko dobijo menedžerji sliko podjetja, kako posluje, kaj je naredilo in kako je poslovalo v preteklem obdobju. Dobljene rezultate lahko tudi primerjamo s konkurenco. OKOLJE ZA PODATKOVNO HRAMBO Izvorne podatke je treba prenesti v predstavitveni strežnik. Ker pa so lahko izvorni podatki na različnih sistemih, jih moramo najprej preoblikovati v ustrezno obliko. Podatki na virih so lahko nepravilni, nekonsistentni, zastareli ali pa manjkajo. Zato moramo preveriti njihovo veljavnost. Namen okolja za podatkovno hrambo in sklop procesov, ki prečistijo, preoblikujejo, združujejo, arhivirajo, izločajo dvojnike, je, da se podatki pripravijo za uporabo v podatkovnem skladišču. Tako je lahko okolje za podatkovno hrambo vse, kar je med izvornim sistemom in predstavitvenim strežnikom. Zelo je priporočljivo, da se vse skupaj nahaja na enem mestu. Omenjeni procesi zagotavljajo referenčno integriteto med podatki v podatkovnem skladišču. Podatki v okolju za podatkovno hrambo niso dostopni za poizvedbe končnih uporabnikov (Kimball 1998, 16). DIMENZIJSKI MODEL Specifično modeliranje podatkov, ki je alternativa entitetno orientiranem modeliranju5. Dimenzijski model vsebuje enake informacije kot entitetno orientiran model, le da so podatki v dimenzijskem modelu drugače organizirani in bolj razumljivi, kar omogoča učinkovite poizvedbe (Kimball 1998, 17) 5 Slikovni prikaz entitet in odnosov med njimi. Rabi kot osnova za ustvarjanje relacijskega podatkovnega modela.

17

Temeljna sestavna dela dimenzijskega modela sta tabela mer z dejstvi ali merami in dimenzijske tabele, ki vsebujejo opisne podatke. Najbolj pogosti obliki oziroma strukturi dimenzijskega modela sta zvezdasti in snežinkasti strukturi. PREDSTAVITVENI STREŽNIK Predstavitveni strežnik je računalnik, na katerem so podatki iz podatkovnega skladišča organizirani in shranjeni za direktne poizvedbe in za uporabo različnim aplikacijam. Podatki v predstavitvenem strežniku morajo biti oblikovani in shranjeni v dimenzijskem modelu. Če predstavitveni strežnik temelji na relacijski podatkovni zbirki, potem so tabele organizirane v zvezdasti strukturi. Podatkovno zbirko v predstavitvenem strežniku polnimo s podatki iz okolja podatkovne hrambe. Podatkovna zbirka v predstavitvenem strežniku je vir podatkov za učinkovite poizvedbe in se periodično posodablja s podatki, ki so bili v podatkovni hrambi preoblikovani in kontrolirani. PODROČNA SKLADIŠČA Zaradi napornega uresničevanja in uvajanja podatkovnega skladišča in zaradi potreb po uporabi se je razvil koncept področnih skladišč. Omogoča, da se pri uvajanju podatkovnih skladišč ni treba obremenjevati z vsemi poslovnimi enotami oz. vsemi poslovnimi funkcijami, pač pa je omogočen postopen pristop po posameznih področjih. Namesto da iščemo ključne elemente na ravni celotnega podjetja, se osredotočimo samo na določeno področje oz. določeno poslovno funkcijo in ta del uresničimo preko specializiranega področnega skladišča, ki dejansko zožuje tako vire za polnjenje kot tudi potencialne uporabnike, s čimer se močno zmanjša zapletenost problema. Takšen pristop omogoča hitrejše rezultate z nižjimi stroški in večjo verjetnost uspeha za celoten projekt skladiščenja podatkov. Gradnja področnih skladišč pomeni namreč gradnjo podatkovnega skladišča po posameznih delih. S tem seveda veliko lažje pridobimo podporo pri vodstvu. Bistvo pristopa je ciljna usmerjenost, saj si sodelujoči v procesu izgradnje zastavijo ozko usmerjen in enostavno dosegljiv cilj. Verjetnost uspeha je vsaj na začetku precej velika. Seveda pa s takšnim pristopom izgubimo preglednost, ki je sicer značilna za klasično podatkovno skladišče. Področno skladišče omogoča vpogled le v eno razsežnost poslovanja, brez povezave z ostalimi deli oz. ostalimi poslovnimi funkcijami. To pa je ravno v nasprotju s strateško konkurenčnostjo podjetja, ki mora obvladovati in nadzorovati celotno poslovno dogajanje. Zaradi tega moramo najti kompromis med izgradnjo po delih in izgradnjo celovitega podatkovnega skladišča. OLAP OLAP (On-Line Analytical Processing) pomeni sprotno analitično obdelavo (podatkov). Glavna značilnost te tehnologije je, da lahko uporabnik na podatke gleda iz več različnih dimenzij s pomočjo t. i. kocke OLAP. Podatki, ki se morda na prvi pogled zdijo nepovezani, dobijo s pomočjo večdimenzionalnega pogleda neko uporabno vrednost. Še

18

pred analiziranjem podatkov pa je treba te ustrezno zbirati in shranjevati. S tem namenom so razvili t. i. podatkovna skladišča. Podatki v kocki OLAP so zasnovani tako, da se za izdelavo potrebnih poročil porabi čim manj časa in truda. Kocka OLAP nam tudi pohitri izvajanje poizvedb, ker so določene vrednosti vnaprej izračunane in jih pri poizvedbi ni treba ponovno izračunati, za kar bi drugače računalnik potreboval določen čas. REŠITVE ZA UPORABNIKE Sklop orodij, ki poizvedujejo, analizirajo in predstavljajo informacije, namenjene podpori pri poslovnem odločanju v obliki poročil. Navadno je sklop sestavljen iz orodja za dostop podatkov za končnega uporabnika, preglednice, grafičnega vmesnika in uporabniškega vmesnika, kar poenostavi predstavitev poročila končnemu uporabniku (Kimball 1998, 21). ORODJE ZA DINAMIČNO SESTAVLJANJE POIZVEDB Specifično orodje za dostop do podatkov, ki omogoča dinamično sestavljanje enostavnih poizvedb s pomočjo povezav med različnim tabelami mer (preko skupne dimenzije, ki povezuje obe tabeli mer). Kimball trdi, da je 10 % takih uporabnikov, ki bi lahko svoje poizvedbe izdelovalo na tak način, ostalih 90 % uporabnikov pa bi lahko izvajalo dinamične poizvedbe po vnaprej pripravljenih šablonah (Kimball 1998, 22). APLIKACIJE ZA MODELIRANJE To so računalniške aplikacije, ki omogočajo obdelavo podatkov iz podatkovnih zbirk. Aplikacije omogočajo simulacije v okviru poslovnega odločanja (npr. analizo »kaj če«, »iskanje cilja«, razne zapletenejše metode, kot je analiza Monte Carlo ipd.). Poznamo tudi aplikacije za izkopavanje podatkov, ki omogočajo uporabo računalniško podprtih tehnik za iskanje skritih zakonitostih v podatkih podatkovnih skladišč (Bobek 2003, 12). METAPODATKI Metapodatki so vse informacije o okolju podatkovnega skladišča, ki se ne uporabljajo dejansko kot podatek. Metapodatki so izjemno pomembni pri uporabi podatkovnega skladišča, v katerih so zbrani podatki iz številnih virov, uporabljajo pa jih uporabniki, ki niso seznanjeni z izvirnim pomenom vsakega podatka. V metapodatkih, so zbrane tudi dodatne informacije, kot so način in časovna razporeditev osveževanja podatkov iz vira, pojasnila o tem, kako so bili podatki prečiščeni in filtrirani med prenosom v podatkovno skladišče, o tem, ali so bili združeni ali preračunani, in podobno (Pahor 2002, 259). Metapodatki vsebujejo informacije o podatkih: kakšni podatki se nahajajo v skladišču, od kod izvirajo, kako in kdaj so bili preneseni, kako so bili transformirani, čemu so namenjeni in podobno. Kvalitetni metapodatki so nujno potrebni, da lahko uporabniki pravilno uporabljajo podatke iz podatkovnega skladišča. Pomembno je, da se v fazi izgradnje podatkovnega skladišča dokumentirajo vse oblike metapodatkov. Na podlagi dobre dokumentacije imajo taki metapodatki tudi svojo korist, ki se kaže v tem, da s svojo vsebino olajšajo uporabo podatkov tudi na področjih, ki jih ne poznamo dobro.

19

3.3 Procesi v podatkovnem skladišču V podatkovnem skladišču se odvijajo različni procesi. Iz slike 4 je razvidno, da se v podatkovnem skladišču odvijajo naslednji procesi (Bobek 2003, 24):

• izločanje podatkov iz operativnih podatkovnih baz, • polnjenje podatkov v podatkovno hrambo, • čiščenje podatkov v podatkovni hrambi, • nalaganje podatkov iz podatkovne hrambe v osrednjo predstavitveno podatkovno

zbirko, • nalaganje podatkov v kocko OLAP, • omogočanje pristopa do podatkov, • arhiviranje podatkov iz podatkovnega skladišča.

Vsi našteti procesi so nujno potrebni za delovanje podatkovnega skladišča. Določeni procesi so avtomatizirani in delujejo po določenem urniku in zaporedju.

3.4 Poslovni proces in dimenzijsko modeliranje V podjetjih se odvijajo najrazličnejši poslovni procesi in s tem serija določenih dogodkov. Vrsta in frekvenca dogodkov je odvisna od samega poslovnega procesa. Izdelava izdelka, rezervacija sedeža, izdana faktura, naročilo knjige, vse te aktivnosti prispevajo k uspehu ali neuspehu poslovanja. Za poslovanje pa je pomembno, da podjetje beleži dogodke s sistemom OLTP. Večina podjetji ima različne sisteme OLTP za različne procese. Zagotavljati pa morajo učinkovito vnašanje, ažuriranje in poizvedovanje po majhnih količinah podatkov naenkrat. Tipična značilnosti teh sta: hiter dostop do konkretnega zapisa podatkov in učinkovito obdelovanje majhnega števila podatkov hkrati. Da ti sistemi dosegajo te lastnosti, so običajno relacijski in normalizirani in s tem nudijo izjemno zmogljivost in zagotavljajo konsistenco podatkov (Adamson, Venerable 1998, 3). Sistem OLTP je izdelan za obvladovanje velikega števila podatkov, ki nastajajo z vsakodnevnimi opravili, vendar ni primeren za iskanje odgovorov na vprašanja, ki si jih uporabniki običajno zastavljajo. Primeri takšnih vprašanj so:

• Kateri izdelek se je prejšnji mesec najbolje prodajal? • Kakšen je trend prodaje po regijah? • Kateri izdelek je izgubil največ tržnega deleža v zadnjih nekaj letih?

Sistem OLTP, ki mora v takem primeru kategorizirati in sešteti ogromno količino podatkov, ki so organizirani na relacijski način, dobesedno odpove, saj ni sposoben dela opraviti v dovolj kratkem času. Relacijska zasnova podatkovne zbirke ima veliko slabost, saj je v iskanju za čim večjo učinkovitost procesiranja transakcij nastala podatkovno zbirka, v katerih je praktično nemogoče delati poizvedbe. Relacijski modeli so postali zelo kompleksni in lahko vsebujejo več tisoč tabel in povezav med njimi. Zaradi take kompleksnosti končni uporabniki relacijskih modelov ne morejo razumeti ali si jih zapomniti, niti ne obstajajo splošni grafični vmesniki, ki bi modele približali uporabnikom in jim omogočili enostavne poizvedbe. Na drugi strani programi poizvedb ne znajo dobro

20

optimizirati, saj iz modela niso vidne dejanske relacije med podatki. Uporaba relacijskih modelov pravzaprav onemogoči intuitiven in hiter dostop do informacij. Podatkovno skladišče pa je tako oblikovano, da rešuje zgoraj navedene probleme. Zgrajeno je, da daje odgovore na vprašanja, ki so osredotočena na celoten poslovni proces in ne na posamezen dogodek znotraj procesa. Dizajn podatkovnega skladišča mora direktno zrcaliti pogled na poslovanje, kakršnega vidi uporabnik.

3.5 Dimenzijsko modeliranje Dimenzijsko modeliranje, znano tudi kot zvezdasta shema (angl. Star Scheme), je tehnika, ki identificira in predstavi informacije, ki so pomembne za ljudi s poslovnimi vprašanji. Dimenzijsko modeliranje služi kot analitičen pripomoček pri planiranju podatkovnega skladišča in kot fizičen dizajn za njegovo implementiranje v relacijsko podatkovno zbirko. Vprašanja in zahteve, kot so: »Pokaži največjo maržo po vrsti izdelkov«, »Pokaži terjatve po razredih zamud in kupcih«, »Kakšno je gibanje zalog po poslovnih partnerjih?«, »Kakšne so plače po izobrazbi?«, imajo nekaj skupnega. Vsa vprašanja in zahteve so osredotočena na poslovni proces, zahtevajo povzetek mnogih poslovnih dogodkov in razkrivajo, kaj je pomembno spremljati v poslovnem procesu: marža, terjatve, vrsta izdelkov, stopnja izobrazbe. Iz vsakega vprašanja lahko ugotovimo, kako se spremlja ali meri poslovanje v poslovnem procesu. Velikost marže, stanje zalog, velikost terjatev, vse naštete mere se uporabljajo v podjetjih za spremljanje poslovanja. Mere lahko preučujemo in analiziramo iz različnih zornih kotov. Marže lahko spremljamo za neko vrsto proizvodov, lahko spremljamo samo za posamezen izdelek, spremljamo po kupcih ali skozi različna obdobja. Dimenzijski model je tako direktna preslikava načina, kako se spremlja poslovni proces. Zbirajo se mere, ki so pomembne za poslovanje in parametri, s katerimi bomo lahko analizirali mere iz različnih zornih kotov. Meram lahko tudi rečemo dejstva, parametrom, s katerimi bomo mere analizirali, pa lahko rečemo dimenzije. Adamson in Venerable (1998, 5) predlagata, da kreiramo tabelo, kjer bodo vpisane dimenzije in mere. Tabela 1 nam prikazuje pomembne mere in dimenzije pri poslovnem procesu naročilo. TABELA 1: MERE IN DIMENZIJE PRI PROCESU NAROČILO Mere Dimenzije Prodaja v SIT Ime kupca Skupni stroški Država kupca Marža v SIT Poštna številka kupca Količina prodanih izdelkov Datum naročila Mesec naročila Kvartal naročila Leto naročila Prodajalec Prodajno področje Regija Ime proizvoda Klasifikacija proizvoda

21

Mere in dimenzije v tabeli 1 lahko med seboj kombiniramo v različnih kombinacijah, da bi lahko odgovorili na različna vprašanja. Vsako mero lahko kombiniramo z vsako dimenzijo. Lahko analiziramo prodajo po kupcih ali pa po poštni številkah. Pogledamo lahko skupne marže za celo leto ali pa po dnevih. Analiziramo lahko prodajo in marže po klasifikacijah proizvodov za določen kvartal v določenem letu. Iz tabele 1 je razvidno, da imajo določene dimenzije nekaj skupnega. Določene dimenzije opisujejo kupca, proizvod ali prodajalca. Podatke iz tabele 1 zato lahko preoblikujem v novo strukturo, kjer so mere prikazane v sredini, skupine dimenzij, ki opisujejo isto stvar, pa so združene in narisane okoli mer. Skupne dimenzije postanejo atributi nove dimenzije, ki opisuje določen predmet (naročilo). Dobili smo nov model (glej sliko 5), ki ga imenujemo dimenzijski model. S tem modelom tako približamo podatkovni model uporabniku. SLIKA 5: DIMENZIJSKI MODEL PROCESA NAROČILO

Prednost dimenzijskega modela je tudi v tem, da ima predvidljivo strukturo, zato lahko podjetja, ki razvijajo orodja za podatkovna skladišče, te optimizirajo. Dimenzijska struktura nam tudi omogoča, da nam ni treba spreminjati programov za poizvedbe, če dodajamo nove dimenzijske tabele ali samo vrstice v tabele.

3.6 Zvezdasta in snežinkasta struktura

3.6.1 Zvezdasta struktura Dimenzijski model nato lahko preprosto preslikamo v tabele v podatkovni zbirki. Dimenzijski model, kot je na sliki 5, lahko z majhnimi spremembami implementiramo v relacijsko podatkovno zbirko, kjer postane dimenzijski model zvezdasta struktura (angl. Star Scheme). Vse dimenzije z njihovimi atributi postanejo tabele, imenovane dimenzijske tabele (angl. Dimension Table), katerim se še dodeli primarni ključ. Mere pa se vpišejo kot atributi tabele dejstev (angl. Fact Table). Tabela dejstev tako vsebuje mere in tuje ključe, ki so povezani s primarnimi ključi v dimenzijskih tabelah (glej sliko 6).

MERE NAROČILA Vrednost Stroški Marža

Količina

PROIZVOD Ime proizvoda

Znamka klasifikacija

DATUM NAROČILA Datum Mesec Kvartal

Leto

KUPEC Ime kupca

Pošta Država

PRODAJALEC Ime prodajalca

Prodajno področje Regija

atributi

Ime dimenzije

22

SLIKA 6: ZVEZDASTA STRUKTURA

3.6.2 Snežinkasta struktura Zvezdasta shema predstavlja visoko denormalizirane tabele. Poznamo še snežinkasto strukturo, ki je varianta zvezdaste strukture. V snežinkasti strukturi so podatki bolj normalizirani, saj so določene dimenzijske tabele določene z več tabelami (glej sliko 7). SLIKA 7: SNEŽINKASTA STRUKTURA

3.7 OLAP

3.7.1 Potreba po novem orodju Za analize uporabnik potrebuje orodja, ki so enostavna za uporabo, vendar je možno z njimi delati kompleksne analize. Uporabniki, ki so dnevno postavljeni v vlogo odločevalcev, nujno potrebujejo hitre ter točne informacije, ki pa jih ne morejo vnaprej

TABELA DEJSTEV: PRODAJA Caskey ZaposlenKey IzdelekKey KupecKey PrejemnikKey MERE: cena, količina, rabat

DIMENZIJA ZAPOSLENI ZaposlenKey Ime zaposlenega Delovno mesto

DIMENZIJA KUPEC KupecKey Ime kupca Država kupca regija

DIMENZIJA PREJEMNIK PrejemnikKey Ime prejemnika Država prejemnika Regija

DIMENZIJA IZDELEK IzdelekKey Ime izdelka klasifikacija

DIMENZIJA CAS CasKey Datum Dan Mesec leto

Tabela dejstev: Prodaja IzdelekKey KupecKey PrejemnikKey

Dimenzija izdelek IzdelekKey Ime izdelka velikost VrstaBlagID

Tabela VrstaBlaga VrstaBlagID Vrstablaga Klasifikacija

23

določiti. Poleg tega pa niso vešči pisanja poizvedb SQL6, da bi lahko sami neposredno poiskali potrebne podatke po podatkovnem skladišču. Zato je prišlo do potrebe po novem orodju za analiziranje in prikazovanje podatkov.

3.7.2 Orodja OLAP Za orodja OLAP so značilne predvsem naslednje lastnosti: večdimenzionalnost, hiter dostop in kalkulacije, vrtanje v globino, močne analitične sposobnosti, prožnost in večuporabniški dostop. Večdimenzionalnost omogoča uporabnikom pregled vrednosti različnih kazalnikov poslovne uspešnosti podjetja, primerjave s podatki iz preteklosti ali napovedanimi podatki za prihodnost po posameznih dimenzijah in njihovih hierarhijah. Poizvedovanje z orodji OLAP poteka enostavno, brez pisanja zapletenih stavkov SQL, zato lahko dela poizvedbe vsakdo. Uporabnik prehaja med različnimi nivoji podatkov, ki so v določeni hierarhiji, od celotnih za določeno dimenzijo, do podrobnejših, kar imenujemo vrtanje v globino. Odzivni časi so pretežno konstantni ne glede na vrsto poizvedbe in ne smejo biti večji od nekaj sekund, saj morajo slediti miselnemu procesu uporabnika. Čim boljše odzivne čase se skuša doseči s predsumiranimi tabelami, z ustreznim indeksiranjem tabel in predračunanimi vsotami (Rožanec 2000, 101). Orodje OLAP mora poleg osnovnih seštevanj in povprečij po hierarhijah vsebovati tudi naprednejše funkcije za finančne, prodajne in druge analize, ki povečujejo njegove analitične sposobnosti. Po drugi strani se lastnost prožnosti nanaša na različne načine pregledovanja podatkov (v obliki matrik, različnih vrst grafov, tabel s poljubno razmestitvijo stolpcev in vrstic), rotacijo (podatkovna struktura ne pogojuje prikaza podatkov). Večina današnjih orodij OLAP je tipa odjemalec/strežnik, kar zagotavlja hkraten dostop do podatkov in njihovo obdelavo večjemu številu uporabnikov (ibidem, 102). Tipična arhitektura OLAP je sestavljena iz strežnika OLAP, ki se nahaja med podatkovnim skladiščem in uporabnikom (glej sliko 8). Slika nam jasno prikazuje tok podatkov. Kocka OLAP se napolni s podatki iz relacijske podatkovne zbirke. Strežnik OLAP pa nato omogoča poizvedovanje po podatkih. SLIKA 8: ARHITEKTURA OLAP

6 Poizvedba SQL je stavek, s katerim ukažemo programu, naj izvede določeno poizvedbo v relacijski podatkovni zbirki in vrne rezultat.

Podatkovno Skladišče – relacijska

zbirka podatkov

OLAP strežnik uporabnik

24

3.7.3 Kocka OLAP Bistvo tehnologije OLAP je večdimenzionalna kocka. Sestavljena je iz dimenzij in mer. Kocka OLAP vsebuje določen del podatkov iz podatkovnega skladišča, ki predstavlja množico podatkov poslovnega procesa. Vsaka dimenzija ima poljubno (končno) zalogo vrednosti. Dimenzije so entitete, ki se pojavljajo v poslovnem procesu: izdelki, kupec, valuta, vrsta poslovanja in predvsem čas. Dimenzije mnogokrat vsebujejo hierarhije, s katerimi je mogoče podatke sešteti ali kako drugače združevati. Primer je dimenzija kupec, ki na najvišjem nivoju obsega celotno regijo, na nivoju nižje državo, do najnižjega nivoja, kjer so člani dimenzije posamezni kupci. Celice v kocki OLAP vsebujejo dejstva ali mere, ki jih uporabniki izpisujejo ali pregledujejo. Običajno gre za različne zneske, velikosti, števila in podobno. Za praktično uporabo, kjer uporabniki pregledujejo podatke glede na poljubne kriterije (dimenzije) na poljubnih ravneh hierarhije, morajo biti količine aditivne. To je še zlasti pomembno, kadar uporabnik obdeluje zelo veliko število podatkov, saj verjetno ne želi gledati posameznih zapisov, ampak ga zanimajo agregirane količine. Osnovni elementi kocke so dimenzije, člani dimenzije, celice in hierarhije dimenzij (glej sliko 9). SLIKA 9: OSNOVNI ELEMENTI KOCKE OLAP

Vir: Mirosoft Corporation (1999, 53) Vsako celico v kocki določa vrednost posamezne dimenzije. Celico si je tako moč predstavljati kot točko v kocki. Vrednosti koordinate, ki določa celico v kocki, je enaka članu dimenzije v posamezni dimenziji. Število dimenzij v kocki OLAP je lahko več kot tri. Uporaba kocke (trorazsežnega koordinatnega sistema) kot prispodobe za predstavitev večdimenzionalnih podatkovnih baz je posledica človekovega naravnega razumevanja prostora, ki je omejeno na tri.

Dimenzija: Kupec Kupec 1 Kupec 2 Kupec 3

Dimenzija: Izdelek Serviete Rolice Robčki Vložki

Celica

Zah. EU Juž EU Sre EU

Član dimenzije

1.Kvartal 2.Kvartal 3.Kvartal 4.Kvartal Dimenzija : Čas

Bih Hrvaška Srbija

Merkator Konzum …..

Hierarhija dimenzije kupec

25

3.7.4 Shranjevanje kock OLAP Za shranjevanje kock OLAP se lahko uporablja klasična relacijsko zasnovana podatkovna zbirka, večdimenzionalna podatkovna zbirka ali pa kombinacija obeh. Glede na tehnologijo ločimo tri glavne načine, kako naj bodo shranjene kocke OLAP:

1. MOLAP – večdimenzionalni OLAP, 2. ROLAP – relacijski OLAP, 3. HOLAP – hibridni OLAP.

MOLAP uporablja način shranjevanja podatkov, ki je bil narejen izrecno za večdimenzionalne analize. MOLAP prepiše podatke iz podatkovnega vira (podatkovnega skladišča ali transakcijske podatkovne zbirke) v kocko OLAP. Poleg podatkov se v kocko shranijo še agregati7. Ko se kocke pregledujejo, podatkovni vir ni več potreben, ker so vsi podatki že v kocki OLAP. Strežnik, na katerem je kocka OLAP, tako skrbi za same podatke in za njihovo posredovanje uporabnikom. ROLAP uporablja strukturo relacijskih podatkovnih zbirk. Podatki se ne prepišejo iz podatkovnega vira, ampak ostanejo na viru. Agregati so shranjeni v isti podatkovni zbirki, v tabelah, ki jih izdela strežnik OLAP. Med pregledovanjem podatkov se ti potegnejo neposredno iz podatkovnega vira. V ozadju analiz in pregledovanj podatkov se nahaja poizvedovalni jezik SQL. Strežnik OLAP tako samo simulira kocko OLAP. HOLAP (Hybrid OLAP) kombinira oba načina. Podatki so shranjeni v podatkovnem skladišču. Agregati pa so shranjeni v kocki OLAP, ki se nahaja v strežniku OLAP. HOLAP podatke upravlja kot ROLAP, agregate pa kot MOLAP.

3.7.5 Odjemalci OLAP Uporabniki lahko uporabljajo različne vrste odjemalcev. Najpogosteje se pojavljajo v obliki preglednic kot samostojen izdelek ali kot dodatek k razširjenim preglednicam. Zmogljiva orodja OLAP ponujajo popoln aplikacijski programski vmesnik, ki omogoča izdelavo namenske programske opreme, ki dostopa do podatkov v kocki OLAP.

3.8 Načrtovanje podatkovnega skladišča

3.8.1 The Business Dimensional Lifecycle Podatkovno skladiščenje je proces integracije in prečiščevanja podatkov z namenom, da pridobimo informacije, ki bodo dostopne za analiziranje in poročanje širšemu krogu uporabnikov. Preden pa se lotimo postavitve podatkovnega skladišča, se moramo zavedati, da imamo opravka z iterativnim procesom, ki zahteva potrpežljiv pristop. Korak za

7 Predhodno izračunani podatki, ki skrajšajo odzivni čas. Strežniku OLAP pri posredovanju podatkov ni treba ponovno preračunavati, ampak posreduje že predhodno agregirane podatke.

26

korakom se bližamo končni strukturi, določene faze je treba, kot že rečeno, ponavljati tudi večkrat. Ralph Kimball za gradnjo podatkovnega skladišča predlaga metodologijo »The Business Dimensional Lifecycle« (glej sliko 10). Diagram podrobno opisuje faze, ki jih moramo izvesti za uspešno načrtovanje in izgradnjo podatkovnega skladišča. SLIKA 10: THE BUSINESS DIMENSIONAL LIFECYCLE DIAGRAM

Vir: Kimball (1998, str. 33)

3.8.2 Planiranje projekta Načrtovanje podatkovnega skladišča se začne s planiranjem projekta. Projekt izgradnje podatkovnega skladišča je treba pripraviti tako, da bi bila njegova poslovna korist čim večja, izvedbeno tveganje pa čim manjše. S pojmom projekt razumemo vrsto za gradnjo podatkovnega skladišča potrebnih opravil, ki so opredeljena v zagonskem elaboratu. V zagonskem elaboratu natančno definiramo vsebino in cilje projekta, taktiko izvedbe projekta, plan projekta, projektno organizacija, plan kontrole izvajanja in ekonomiko projekta. Projekt izgradnje podatkovnih skladišč je podvržen dvema najpomembnejšima rizikoma (Berce 2001a, 10):

• dostopnost in kakovost vhodnih podatkov: če za proces, ki bi ga radi “videli” v podatkovnem skladišču, ni ustreznih strojno čitljivih podatkov, potem podatkovnega skladišča kratko malo ne moremo zgraditi. Vendar je to redek primer. Ponavadi strojno zapisani podatki obstajajo, vprašanje pa je, kako dobri so. Ob načrtovanju podatkovnega skladišča ne moremo narediti čudeža, v katerem bi iz slabih podatkov naredili boljše, zato je takšen projekt vnaprej obsojen na propad;

• poslovna zanimivost in uporabnost podatkov: pričakovanja uporabnikov in vodstva so kaj hitro prevelika. V večini podatkovnih skladišč vidimo pretekle podatke, vodstvo pa bi želelo gledati v prihodnost. V podatkovnih skladiščih je največ internih podatkov, za poslovanje pa sta zelo pomembna tudi trg in dogajanje v okolju.

Izbira produkta in inštalacija

Uvajanje

Dimenzijsko modeliranje

Planiranje projekta

Definicija poslovnih

zahtev

Načrtovanje tehnične arhitekture podatkovnega

skladišča

Specifikacija programov za

uporabnike

Fizični dizajn

Izdelava programov za

končne uporabnike

Dizajn okolja za hrambo podatkov in

OLAP kocke

Izvajanje in

vzdrževanje

Projektni management

27

Oba opisana rizika lahko z dobro pripravo projekta v veliki meri zmanjšamo s sponzorjem projekta in z dobrim načrtom projekta. Sponzor projekta je vodstveni delavec, ki za projekt zastavi svoje dobro ime. Je najvišja avtoriteta projekta, kateremu je odgovoren tudi vodja projekta. Preden začnemo s planiranjem projekta moramo poznati naročnika in razumeti zahteve, ki nam jih posreduje naročnik. Faza planiranje projekta je tudi odvisna od faze definicije poslovnih zahtev, zato je v diagramu obojestranska puščica.

3.8.3 Definicija poslovnih zahtev Za natančno določanje poslovnih zahtev moramo dobro razumeti probleme ter poznati potrebe uporabnikov (naročnikov projekta). Uporabniki in njihove zahteve vplivajo na vsako odločitev v izgradnji podatkovnega skladišča. Zahteve določajo, kateri podatki morajo biti v podatkovnem skladišču, kako bodo organizirani in kako pogosto se bodo posodabljali. Natančna definicija poslovnih zahtev je najpomembnejši predpogoj za uspešen projekt, saj so vse faze v nadaljevanju odvisne od poslovnih zahtev. Poslovne zahteve lahko zbiramo z intervjuji, razgovori, lahko pa jih najdemo tudi v različnih poslovnih dokumentih. Za uspešen projekt je zato nujno treba opraviti razgovore z bodočimi uporabniki, da se ugotovi, katere informacije želijo uporabniki pridobiti iz sistema, kako sedaj pridobivajo informacije ter kaj pogrešajo. Natančen pregled dosedanjih načinov analiziranja poslovanja podjetja in razgovori z uporabniki so predpogoj za uspešno končanje projekta. Poslovne zahteve tako predstavljajo osnovo za tri vzporedne niti pri načrtovanju:

• tehnologije, • podatkov, • programov za končne uporabnike.

3.8.4 Podatki: Dimenzijsko modeliranje Dimenzijsko modeliranje je tehnika, ki identificira in predstavi informacije, ki so pomembne za ljudi s poslovnimi vprašanji. Služi tudi kot analitičen pripomoček pri planiranju podatkovnega skladišča in kot fizičen dizajn za njegovo implementiranje v relacijski podatkovni zbirki (glej poglavje Dimenzijsko modeliranje).

3.8.5 Podatki: Fizični dizajn V tej fazi zgradimo shemo relacijske podatkovne zbirke podatkovnega skladišča, ki implementira dimenzijski model podatkovnega skladišča.

3.8.6 Podatki: Dizajn okolja za podatkovno hrambo in kocke OLAP To fazo načrtovanja podatkovnega skladišča lahko razdelimo na naslednje procese:

28

• proces, ki zajema podatke iz virov in jih nato prečisti, preoblikuje in združi ter jih prenese v podatkovno hrambo,

• proces, ki napolni dimenzije in tabelo dejstev s podatki iz podatkovne hrambe, • proces kreiranja kocke OLAP in polnjenje kocke OLAP s podatki iz dimenzij in

tabele dejstev v podatkovnem skladišču. Vsi procesi so iterativni in jih lahko ponavljamo, dokler nismo zadovoljni z rezultatom. Podatke na virih je treba prenesti v predstavitveni strežnik. Ker pa so lahko podatki na virih shranjeni na različnih sistemih, jih moramo najprej preoblikovati v ustrezno obliko. Podatki na virih so lahko nepravilni, nekonsistentni, zastareli ali pa manjkajo. Zato moramo preveriti njihovo veljavnost. Treba je narediti sistem, ki bo podatke prečistil, preoblikoval, združil in nato napolnil dimenzijske tabele in tabelo dejstev. Prednost podatkovne hrambe je, da so podatki ločeni od izvornega sistema in tako procesi v podatkovnem skladišču ne motijo sistema OLTP. Treba je tudi definirati kocko OLAP. Izhodišče za izgradnjo kocke OLAP je dimenzijski model podatkovnega skladišča, kjer so že definirane dimenzijske tabele in tabela dejstev. Odvisno od poslovnih zahtev in izbrane tehnologije izberemo še način shranjevanja kocke OLAP, MOLAP, ROLAP ali HOLAP.

3.8.7 Tehnologija: Načrtovanje tehnične arhitekture podatkovnega skladišča Da bi se lahko procesi v podatkovnem skladišču nemoteno odvijali, je treba pravilno načrtovati tehnično infrastrukturo podatkovnega skladišča. Na tehnično arhitekturo vpliva velikost podatkovnega skladišča. Oceniti je treba velikost tabele dejstev, dimenzij, agregatov in kock OLAP, ko bo podatkovno skladišče napolnjeno s podatki. Oceniti je tudi treba razpoložljivost in zanesljivost delovanja podatkovnega skladišča, varnostno politiko in posebne zahteve za podporo procesom v podatkovnem skladišču. Na osnovi zahtev se moramo odločiti o tehnični arhitekturi, potrebni za nemoteno delovanje podatkovnega skladišča. Opredeliti moramo karakteristiko:

• strojne opreme, • programskih orodjih za vse procese v podatkovnem skladišču in programov za

dostop do podatkovnega skladišča, • povezav med strojnimi in programskimi komponentami.

3.8.8 Tehnologija: Izbira produkta, inštalacija Ko smo izbrali ustrezno programsko in strojno opremo in določili arhitekturo sistema, je treba ta sistem še inštalirati.

29

3.8.9 Programi: Specifikacija programov za uporabnike Poslovne zahteve imajo močan vpliv, kako se bodo informacije posredovale. Zahteve definirajo kako, kdaj in kam bodo uporabniki dobili informacijo iz podatkovnega skladišča. Pri načrtovanju podatkovnega skladišča je zelo pomembna funkcionalnost programov za uporabnike. Še tako zmogljiv sistem je neuporaben, če uporabnik ne more priti do podatkov enostavno in prijazno, saj uporabniki ponavadi nimajo veliko časa za učenje, kako naj uporabljajo program. Zato je za uspeh projekta izredno pomembno, da imajo programi za uporabnike naslednje lastnosti:

• biti mora preprost in intuitiven za uporabo, • podatke mora prikazovati zelo pregledno, • podpirati mora možnost vnaprej pripravljanja pogledov, • omogočiti dovolj hitre poizvedbe (vrtanje v globino).

3.8.10 Uvajanje Uvajanje je vzpostavljanje tekoče uporabe sistema. Obsega predvsem izobraževanje in urjenje uporabnikov za delo na novem sistemu, testiranje sistema in ugotavljanje ustreznosti in učinkovitosti sistema.

3.8.11 Izvajanje in vzdrževanje Treba je nadaljevati z izobraževanjem in nuditi pomoč uporabnikom in prilagajati programe zaradi nenehno spreminjajočih se potreb uporabnikov. Posebno pozornost je treba posvetiti procesom v podatkovni hrambi, da se zagotovi njihovo učinkovito delovanje. Med tekočo uporabo je treba iskati in odkrivati tudi možnosti za čimbolj učinkovito delovanja sistema. Nadzorovati in posodabljati je treba tudi vso tehnično infrastrukturo.

30

4 PRAKTIČEN PRIMER IZGRADNJE PODATKOVNEGA SKLADIŠČA

4.1 Izdelava podatkovnega skladišča Zaposleni v prodajnem sektorju niso bili zadovoljni z obstoječimi programskimi rešitvami v prodaji in marketingu. Redno se je zbirala velika količina podatkov, pa vendar so nastajale težave s poročili. Problemi so nastopili takoj, ko so se delale zahtevnejše analize, kjer uporabnik želi dobiti primerjave med vsotami ali povprečij iz več let nazaj, rasti prodaje glede na prejšnje mesece ter izmeriti sedanje povpraševanje in napovedati prihodnjo prodajo. Rešitev za zgoraj omenjene probleme je bila v izgradnji podatkovnega skladišča. Pri načrtovanju podatkovnega skladišča imamo na voljo dva osnovna pristopa. To sta pristopa od zgoraj navzdol in od spodaj navzgor. Prvi pristop izhaja iz potreb vodstva in ključnih uporabnikov ter iz njih izpeljemo zasnovo podatkovnega skladišča. Pri drugem načinu pa izhajamo iz poslovnega procesa in obstoječih podatkovnih virov ter iz njih izpeljemo zasnovo podatkovnega skladišča. Za izgradnjo podatkovnega skladišča sem izbral pristop od spodaj navzgor, ker bom obravnaval samo prodajni proces. Rezultat bo področno skladišče za prodajo.

4.2 Priprava zagonskega elaborata Sam projekt sem začel z njegovim planiranjem. Zato sem pripravil zagonski elaborat, kjer sem opisal, kaj želim doseči s projektom, določil sem njegov obseg, kjer sem definiral njegove cilje, katero poslovno področje je obravnavano, povzetek dimenzij in kock, povzetek grobe zasnove transformacije in tehnično arhitekturo ter definiral organizacijo projekta, povzetek projektnega plana in opredelil predvidene stroške projekta. Med vodstvenimi delavci sem našel sponzorja, ki je imel posluh za projekt in bo potem s svojo avtoriteto projekt tudi utemeljeval in pomagal oživeti podatkovno skladišče.

4.3 Poslovne zahteve Kot smo že omenili, lahko poslovne zahteve pridobivamo različno. Poslovne zahteve sem pridobil iz pogovorov v prodajnem sektorju in sektorju informatike ter iz analize obstoječih poročil, ki se dnevno ali mesečno izpisujejo za sektor prodaje. Pri razgovoru so uporabniki opredelili vprašanja, na katere bi radi dobili odgovor. Ta vprašanja so mi v nadaljevanju služila kot osnova za izgradnjo podatkovnega skladišča:

• Kateri kupci so izkazali največjo lojalnost oz. so bili naši najboljši kupci? • Kakšna je bila skupna, povprečna, najmanjša in največja prodaja glede na vrsto

artikla in regijo v prvem polletju?

31

• Primerjava prodaje določenega izdelka v prvem polletju lani in letos. • Primerjava prodaje po regijah: za vse izdelke in vsak izdelek posebej. • Iskanje izstopajočih (nepričakovanih) primerov. • Kateri artikli so ključni za poslovanje podjetja? • Katera regija je najpomembnejša? • Kakšna je prodajna napoved za prvo polovico prihajajočega poslovnega leta? • Kakšna je plačilna navada kupca? • Analiza ABC kupcev. • Primerjava prodaje med lastno blagovno znamko in tujo blagovno znamko.

Pri definiranju poslovnih zahtev so mi bili v veliko pomoč tudi različni dokumenti in poročila, ki se uporabljajo v prodaji. Iz samih poročil (glej sliko 11) je bilo enostavneje analizirati poslovni proces, ugotoviti poslovne zahteve uporabnikov in iz njih določiti mere in dimenzije kot iz intervjujev, saj uporabniki včasih niso znali natančno definirati vsebine analiz in poročil, ki bi jih potrebovali. SLIKA 11: PRIMER POROČILA PREGLED PRODAJE PO KLASIFIKACIJAH

Iz pridobljenih informacij sem ugotovil, da želijo uporabniki spremljati poslovni proces prodaje izdelka oziroma želijo spremljati izdane fakture. Zato bo podatkovno skladišče vsebinsko usmerjeno okoli poslovnega dogodka izdaje fakture. Iz samih razgovorov sem tudi ugotovil, da se prodaja izdelkov spremlja ločeno, za naročnike (plačnike) izdelkov ter prejemnike izdelkov. Ker ni nujno, da je plačnik izdelkov tudi prejemnik izdelkov, bom moral to posebnost upoštevati pri dimenzijskem modeliranju.

32

4.4 Dimenzijsko modeliranje Iz vprašanj, ki so jih opredelili uporabniki, in različnih dokumentov sem ugotovil, kako želijo uporabniki spremljati in analizirati izdane fakture. Če podrobneje analiziramo vprašanje: »Kakšna je bila skupna, povprečna, najmanjša in največja prodaja po kosih in vrednostih glede na vrsto artikla (klasifikacija) in regijo v prvem polletju?«, lahko ugotovimo, da so mere kosi in vrednost fakture, dimenzije pa regija, izdelek in obdobje. Iz ostalih vprašanj in poročil sem enako določil mere in dimenzije, ki so podane v tabeli 2. TABELA 2: MERE IN DIMENZIJE PRI PROCESU IZDANE FAKTURE Mere Dimenzije Vrednost fakture v EUR Klasifikacija artiklov – nivo 1 Vrednost fakture v SIT Klasifikacija artiklov – nivo 2 Število kosov Klasifikacija artiklov – nivo 3 Število palet Klasifikacija artiklov – nivo 4 Število paketov Ime artikla Cena Datum izdaje fakture Leto izdaje fakture V katerem polletje je bila izdana faktura Mesec izdaje fakture Regija Blagovna znamka Skupni promet plačnika (zadnjih 12 mesecev) Plačnik Država plačnika Prejemnik Država prejemnika Plačilna navada plačnika (zamuda pri plačilih)

Dimenzije, ki opisujejo enak predmet (Artikel, plačnik, prejemnik …) nato združimo in jih preoblikujemo, da dobimo dimenzijski model (glej sliko 12). SLIKA 12: DIMENZIJSKI MODEL IZDANA FAKTURA

Ker želijo uporabniki pregledovati tudi plačilne navade plačnikov, sem dodal dimenziji »Plačnik« atribut plačilna navada. Plačniki bodo tako razvrščeni v posamezne skupine (glej

Mere pri izdaji fakture • Število palet • Število paketov • Število komadov • Vrednost fakture v SIT • Vrednost fakture v EUR • Cena

Artikli Naziv artikla Klasifikacija artikla nivo 1 Klasifikacija artikla nivo 2 Klasifikacija artikla nivo 3 Klasifikacija artikla nivo 4

Obdobje Leto izdaje fakture Mesec izdaje fakture Dan izdaje fakture Polletje izdaje fakture

Blagovna znamka Ime blagovne znamke prejemnik Država prejemnika

Regija Ime regije

Prejemnik Ime prejemnika Država prejemnika Regija prejemnika Promet prejemnika

Plačnik Ime plačnika Država plačnika Regija plačnika Plačilna navada

33

tabelo 3). Če npr. plačnik zamuja s plačilom triintrideset dni je v skupini plačilna navada 32-60 dni. TABELA 3: PLAČILNA NAVADA IN PROMET PREJEMNIKA Plačilna navada Promet prejemnika Plačilna navada 0 1-1.000 EUR Plačilna navada 1-30 dni 1.001-10.000 EUR Plačilna navada 31-60 dni 10.001-100.000 EUR Plačilna navada 61-90 dni 100.001-500.000 EUR Plačilna navada 91-120 dni 500.001-1M EUR Plačilna navada manj kot 0 >1M EUR Plačilna navada več kot 121

Podjetje posluje z različnimi kupci, ki delajo različen promet. Večji, kot je promet, pomembnejši je za podjetje. Da bi lahko uporabniki enostavno analizirali podatke za določene kupce z določenim prometom, sem dodal atribut promet (glej tabelo 3) v dimenzijo plačniki. Za nadaljevanje načrtovanja podatkovnega skladišča igra pomembno vlogo koncept zvezdne strukture podatkovnega skladišča kot osnove za zajem podatkov v kocko OLAP. V fazi definiranja dimenzijskega modela in zvezdaste/snežinkaste strukture se je treba osredotočiti na ugotavljanje, ali je predhodno določene dimenzije smiselno organizirati v hierarhije. Hierarhije predstavljajo osnovo za združevanje podatkov in tako zagotavljajo možnost obravnavanja shranjenih podatkov na različnih kumulativnih ravneh. S primernimi dimenzijami in njihovimi atributi bomo kasneje uporabnikom lažje in učinkoviteje prikazovali podatke (glej sliko 13). SLIKA 13: SNEŽINKASTA STRUKTURA IZDANE FAKTURE

34

4.5 Fizični dizajn relacijske podatkovne zbirke S programom SQL Server Enterprise Manager8 in SQL Query Analyzer9 naredimo novo podatkovno zbirko in fizično definiramo dimenzije z atributi (glej sliko 14) in primarnimi ključi ter tabelo dejstev z merami in tujimi ključi. Osnova za kreiranje dimenzij in tabele dejstev je snežinkasta struktura izdane fakture. SLIKA 14: PRIMER KREIRANJA DIMENZIJE ARTIKLI

4.6 Dizajn okolja za podatkovno hrambo in kocke OLAP

4.6.1 Proces zajemanja podatkov iz virov Podatke iz virov sem moral najprej prečistiti, preoblikovati in združiti, preden sem lahko napolnil z njimi dimenzije in tabelo dejstev. Aktivnosti sem izvajal s pomočjo različnih servisov za prenos podatkov iz virov v podatkovno skladišče. Te operacije so s stališča pravilnosti podatkov najbolj kritične. Pri prenosu se velikokrat srečujemo s problemi nepravilnih ali nepopolnih podatkov. Če so podatki nepopolni, jih moramo avtomatsko dopolniti, seveda, če je to mogoče. Pri zagotavljanju ustreznih podatkov so zelo dobrodošla orodja za pretvorbo podatkov (Data Transformation Services – DTS), ki so vključena v strežnik MS SQL Server. DTS je komponenta strežnika, s katerim je možno v grafični obliki načrtovati in izvajati transformacije podatkov, načrtovati ustrezne podatkovne vire in izvajati stavke SQL. Na sliki 15 je grafičen prikaz uporabe orodja DTS. Slika 15 nam prikazuje tako imenovani paket DTS, ki zajema podatke iz virov, preoblikuje, prečisti in združi podatke ter jih nato shrani v podatkovno hrambo. Pakete DTS je možno avtomatsko zaganjati.

8 SQL Enterprise Manager je glavno orodje za konfiguriranje in administriranje MS SQL Serverja. 9 SQL Query Analyzer je grafični vmesnik za interaktivno pisanje in testiranje stavkov SQL in paketnih datotek.

CREATE TABLE [dbo].[ARTI_DIM] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [KLJUC] [varchar] (6) COLLATE Slovenian_BIN NULL , [NAZIV] [varchar] (35) COLLATE Slovenian_BIN NULL , [KLAS] [varchar] (9) COLLATE Slovenian_BIN NULL , [EMER] [varchar] (3) COLLATE Slovenian_BIN NULL , [STAN] [varchar] (11) COLLATE Slovenian_BIN NULL , [DIMEN] [varchar] (25) COLLATE Slovenian_BIN NULL , [CART] [varchar] (9) COLLATE Slovenian_BIN NULL , [OPOM] [varchar] (60) COLLATE Slovenian_BIN NULL , [N1] [varchar] (39) COLLATE Slovenian_BIN NULL , [N2] [varchar] (42) COLLATE Slovenian_BIN NULL , [N3] [varchar] (44) COLLATE Slovenian_BIN NULL , [N4] [varchar] (47) COLLATE Slovenian_BIN NULL ) ON [PRIMARY] GO ALTER TABLE [dbo].[ARTI_DIM] WITH NOCHECK ADD CONSTRAINT [PK_ARTI_DIM] PRIMARY KEY CLUSTERED ([ID]) ON [PRIMARY]

35

SLIKA 15: PAKET OKOLJA DTS PODATKOVNE HRAMBE

4.6.2 Proces, ki napolni dimenzije in tabelo dejstev iz podatkovne hrambe Ko sem napolnil podatkovno hrambo sledi proces, ki napolni dimenzije in tabelo dejstev (glej sliko 16). V tem procesu dodajamo nove vrstice v dimenzijske tabele in tabelo dejstev. SLIKA 16: PAKET DTS, KI NAPOLNI DIMENZIJE IN TABELO DEJSTEV

36

4.6.3 Proces kreiranja kocke OLAP in polnjenje kocke OLAP Microsoft SQL Server 2000 Analysis Services je strežnik za sprotno analizo (OLAP – online analytical processing) in odkrivanje zakonitosti v podatkih (data mining). V njem lahko zgradimo in urejamo kocke OLAP, katerih glavni namen je omogočiti končnim uporabnikom in drugim aplikacijam hiter dostop do podatkov v podatkovnih skladiščih. Delo s strežnikom Analysis Services poteka preko orodja Analysis Manager. Najprej določimo podatkovni vir, ki je snežinkasta struktura izdane fakture, ki se nahaja v predstavitvenem strežniku podatkovnega skladišča. Nato kreiramo dimenzije (glej sliko 17) in kocko OLAP, določimo mere iz tabele dejstev, izberemo način shranjevanja kocke OLAP in na koncu slednjo napolnimo s podatki (glej sliko 18). SLIKA 17: PRIMER IZDELAVE DIMENZIJE ARTIKLI

Slika 17 nam prikazuje dimenzijo artikli. Na sliki je lepo razvidna hierarhija v dimenziji. Artikle bo tako možno pregledovati in združevati po različnih nivojih. Nivojev je pet. Začne se z nivojem celotni gotovi izdelki, nato sledi vrsta proizvoda (robčki, serviete, brisače …) ter naslednja nivoja, ki razčlenjujeta proizvod po lastnostih in oblikah. Zadnji nivo nam prikaže posamezen artikel. SLIKA 18: SHRANJEVANJE KOCKE OLAP IN POLNJENJE

37

Tako kot ostale procese lahko proces polnjenja kocke OLAP avtomatiziramo s paketom DTS (glej sliko 19). SLIKA 19: PAKET DTS, KI NAPOLNI KOCKO OLAP

4.7 Načrtovanje tehnične arhitekture podatkovnega skladišča, izbira produkta in inštalacija

Da bi se lahko procesi v podatkovnem skladišču nemoteno odvijali, je treba pravilno načrtovati tehnično infrastrukturo podatkovnega skladišča. Ker del sistema OLTP v podjetju Paloma teče na strežniku MS SQL Server 2000, sem za predstavitveni strežnik in strežnik za podatkovno hrambo izbral kar strežnik MS SQL Server 2000 in strežnik MS SQL Server Analysis Services za strežnik OLAP. Za strojno opremo, na katerem bo predstavitveni strežnik, strežnik OLAP in podatkovna hramba, pa sem izbral zmogljivejši osebni računalnik. Za programska orodja, ki so potrebna za delovanje procesov v podatkovnem skladišču, in tudi samo dizajniranje sem uporabil Microsoftovo orodje DTS, SQL Query Analyzer in SQL Enterprise Manager. Orodje DTS je skupek programov, v katerem je možno v grafični obliki načrtovati ustrezne postopke za transformacijo podatkov, prenos podatkov v hrambo, podatkovno skladišče in kocko OLAP ter oblikovati programe, ki se bodo avtomatsko izvajali. Sama tehnična arhitektura je razvidna iz dokumenta tehnična arhitektura podatkovnega skladišča (glej sliko 20).

38

SLIKA 20: TEHNIČNA ARHITEKTURA PODATKOVNEGA SKLADIŠČA

4.8 Specifikacija programov za uporabnike Pri izbiri programov za uporabnike obstajata dve možnosti. Prva možnost je izdelava samostojne aplikacije ali nakup že izdelane aplikacije. Ker se v podjetju uporablja MS Office sem izbral program za prikaz in analizo podatkov iz kocke OLAP Microsoft Excel. Za analiziranje podatkov sem uporabili tehnologijo vrtilnih tabel. Vrtilna tabela je tabela, ki v programu za preglednice povzema informacije iz kocke OLAP in nam omogoča poizvedovanje po podatkih brez pisanja zapletenih stavkov SQL in prehajanje med različnimi nivoji podatkov, od popolnih proti podrobnejšim podatkom, kar imenujemo vrtanje v globino.

4.9 Uvajanje Faza uvajanje je z vidika uporabnika najpomembnejša. Zato smo organizirali predstavitve, kjer smo prikazali praktično uporabo analiziranja podatkov s programom MS Excel. Uporabnikom smo tudi razdelili kratka navodila, kako uporabljati MS Excel in vrtilne tabele. Nato smo uvajanje nadaljevali na podlagi individualnega dela. Z vsakim uporabnikom smo skupaj ponovno osvežili osnove uporabe sistema, istočasno pa smo zbirali predloge izboljšav.

4.10 Izvajanje in izobraževanje V tej fazi smo spremljali odzive uporabnikov in dopolnjevali podatkovno skladišče. Dnevno smo tudi analizirali procese v podatkovnem skladišču in odpravljali pomanjkljivosti. Treba je bilo tudi izdelati dodatne kontrolne programe, ker so bili določeni podatki iz virov nekonsistentni ali pomanjkljivi.

Strežnik podatkovnega skladišča

Odjemalec podatkovnega skladišča

Osrednji Novell strežnik

OS= Novell 3.12 Disk= 200 GB Zbirka podatkov = VSAM Btrieve Btrieve produkcijske

baze

OLAP brskalnik OS= MS Win XP, MS WIN 98

OS= MS Win 2000 Procesor= 2.8 gHz Disk= 80 GB RDBMS Server=MS SQL Server 2000 OLAP Server=MS SQL Server Analysis Services

OLAP Kocka

Relacijska zbirka podatkov – Snežinkasta struktura

Hramba podatkov

Protokol=TCP/IP

Protokol=TCP/IP

MS SQL Server 2000 produkcijske baze

Osrednji MS SQL Server 2000

OS= MS Win 2000 Zbirka podatkov = MS SQL 2000 Enterprise RDBMS

Protokol=IPX/SPX

OLAP brskalnik= MS Excel

39

4.11 Preučevanje podatkov z MS Excelom Preden lahko začnemo analizirati podatke iz kocke OLAP s programom MS Excel, se moramo povezati s strežnikom OLAP. V meniju »Podatki« kliknimo »Uvozi zunanje podatke« in nato »Nova poizvedba v podatkovni zbirki«. V pogovornem oknu »Choose Data Source« na kartici OLAP Cubes kliknimo »New Data Source« in nato še enkrat nato kliknimo »V redu«. Izberimo ime za podatkovni vir, izberimo ponudnika OLAP in kliknimo »Connect«. Nato dokončajmo večdimenzionalnega čarovnika za povezavo. Ko smo povezani, se nam prikaže vrtilna tabela (glej sliko 21). SLIKA 21: VRTILNA TABELA

Na desni strani so podani elementi kocke OLAP (dimenzije in mere), na levi pa tabela, kamor bomo elemente enostavno povlekli in spustili. Če želimo na primer ugotoviti, katera regija je bila leta 2002 za podjetje najpomembnejša, enostavno izberemo dimenzijo regija, obdobje za leto 2002 in mero neto EUR in jih povlečemo v tabelo (glej sliko 22). SLIKA 22: KATERE REGIJE SO ZA PODJETJE NAJPOMEMBNEJŠE?

40

Če želimo ugotoviti prodajno napoved za določeno skupino proizvodov s pomočjo linearnega trenda, izberemo ustrezno obdobje, skupino artiklov in prodajo (Neto EUR). Ustvarimo linijski graf. Z desnim klikom na linijo na grafu, dobimo možnost, da naredimo trendno črto. Izberemo vrsto trendne črte in za koliko časovnih enot želimo napoved (glej sliko 23). SLIKA 23: KAKŠNA JE PRODAJNA NAPOVED?

Vrtanje v globino je možno pri vseh dimenzijah, ki imajo določeno hierarhijo. Podrobnost podatkov raste proti nižjim nivojem v hierarhiji. Začetno poročilo vsebuje zelo strnjene agregirane podatke, vsa naslednja poročila (nižja v hierarhiji) pa vse bolj podrobne podatke. Uporabnik »prehaja« iz poročila na poročilo s klikanjem na posamezne dimenzije, klik na določen podatek v poročilu višje ravni odpre poročilo na nižji ravni, ki prikaže želen podatek podrobneje (glej sliko 24). Na sliki je razvidno vrtanje v globino po dimenziji artikli (nivo 1, nivo 2, nivo 3, nivo 4) in dimenziji obdobje (polletje). SLIKA 24: PREGLED PRODAJE ARTIKLOV ZA LETO 1999 IN 2000

41

Slika 25 nam prikazuje primerjavo prodajo določenih skupin brisač med zahodno Evropo in južno Evropo od leta 1999 in do leta 2002. Če bi želeli pregled podatkov za določeno brisačo, moramo samo dimenzijo artikli vrtati v globino do nivoja 4. SLIKA 25: PRIMERJAVA PRODAJE BRISAČ PO REGIJAH

Kupci izdelkov imajo različne plačilne navade. Da bi lahko analizirali, s kakšnim zamikom se plačuje blago, izberemo dimenzijo plačilna navada in mero neto EUR (glej sliko 26). Plačniki so razdeljeni v razrede plačilne navade, ki nam povedo, s kakšno zamudo so plačniki plačevali blago. S klikom na razred plačilne navade lahko pridemo do posameznega plačnika. Razred plačilne navade pa nam pove, s kolikšnim zamikom kupec plačuje izdelke. SLIKA 26: PLAČILNE NAVADE PLAČNIKOV

42

5 SKLEP Tema diplomske naloge je izbrana iz poslovnega področja, konkretno iz zagotavljanja računalniške podpore zaposlenim v prodaji. Največji problem sistema OLTP je, da če bi ga uporabljali za SPO, ne bi hranil zgodovinskih podatkov. Pomanjkljivost sistema OLTP se pokaže takoj, ko se med letom spremenijo osnovni šifranti. Tako bo prikazoval samo nove podatke in to za nazaj. SPO, ki črpa podatke direktno iz sistema OLTP, moti samo delovanje sistema OLTP. V diplomski nalogi je prikazana metodologija izgradnje podatkovnega skladišča, ki je ena izmed možnih rešitev. Metodologija »The Business Dimensional Lifecycle« avtorja Ralpfa Kimballa zahteva gradnjo več med seboj prepletenih sistemov. Prednost take zasnove je možnost preverjanja ustreznosti rešitve na različnih vmesnih stopnjah izgradnje podatkovnega skladišča. Posebnost metodologije je, da so vse faze odvisne od faze definicije poslovnih zahtev. Preučil sem tudi, kateri so osnovni elementi podatkovnega skladišča. Problem, ki ga je bilo treba rešiti, je bil sam način zajemanja podatkov v kocko OLAP. Pri preučevanju literature sem naletel na dva načina zajemanja podatkov in nato polnjenje kocke OLAP. To je neposredno zajemanje podatkov iz operativne baze v kocko OLAP ali pa izdelava podatkovne hrambe in prenos obdelanih podatkov v kocko OLAP. Obe možnosti imata svoje prednosti in slabosti, vendar mislim, da je druga možnost z uporabo podatkovne hrambe boljša, saj je tak sistem dolgoročno zagotovo stabilnejši in v primeru izredno velikih količin podatkov tudi učinkovitejši. Pri ugotavljanju potrebnih procesov, ki se odvijajo v podatkovnem skladišču, sem ugotovil, da je najobsežnejši proces priprava podatkov za polnjenje v podatkovno skladišče, ki ga ni mogoče enostavno avtomatizirati. Podatki iz virov so bili velikokrat nekonsistentni, zato sem moral nekonsistentne podatke ustrezno preoblikovati. Kot primerna rešitev se je izkazala, da sem nekonsistentne podatke pri dimenzijah vpisoval v atribut »NEZNANO«. Tako so uporabniki sami ugotovili nekonsistentnost podatkov in jih tudi odpravili. Pri načrtovanju podatkovnega skladišča je zelo pomembna funkcionalnost programov za uporabnike. Še tako zmogljiv sistem je neuporaben, če uporabnik ne more priti do podatkov enostavno in prijazno, saj uporabniki ponavadi nimajo veliko časa za učenje, kako naj uporabljajo program. Pri delu s programom MS Excel so imeli uporabniki velike težave. Težave so nastajale tudi zaradi nepoznavanja metapodatkov, ki vsebujejo informacije o podatkih, ki se nahajajo v podatkovnem skladišču, in kako so organizirani. Problem je tudi predstavljala relativna kompleksnost uporabe vrtilnih tabel. Zato lahko sklepam, da brez orodij OLAP ne bi bilo možno delati kompleksnih analiz, saj je malo verjetno, da bi povprečni uporabnik znal pisati poizvedbe SQL. Dandanes je tako brez pomoči sodobne informacijske tehnologije, kamor sodijo podatkovno skladišče in orodja OLAP, praktično nemogoče uspešno voditi podjetje. Predpogoj, da lahko izrabimo informacijsko tehnologijo, pa je ustrezna računalniška pismenost.

43

POVZETEK Ključne besede: Sistem za podporo odločanja, OLTP, OLAP, podatkovno skladišče, kocka OLAP, dimenzijsko modeliranje, Microsoft SQL Server, Analysis Services, Microsoft Excel, DTS services V prvem delu podajam osnovne vzroke za uvedbo podatkovnega skladišča, kjer sprotna analitična obdelava podatkov igra pomembno vlogo. V drugem delu so opisane osnovne značilnosti podatkovnega skladišča, tehnologije OLAP ter predstavitev samih podatkov v takšnem sistemu. Opisan je postopek načrtovanja in implementacije podatkovnega skladišča ter dimenzijsko modeliranje. V zadnjem poglavju je prikazan primer izgradnje področnega skladišča prodaja in uporaba programa MS Excel s področnim skladiščem. SUMMARY Key words: Decision support system, OLTP, OLAP, data warehousing, OLAP cube, dimensional modeling, Microsoft SQL Server, Analysis Services, Microsoft Excel, DTS Services The first chapter gives the reasons for introduction of data warehouse, where on-line analytical processing plays an important role. The second chapter gives you an overview of data warehouse and OLAP technology and representation of data in these systems. In this chapter we discuss the creation and implementation of data warehouse and multidimensional data modelling. In the last chapter I present an example of how to build a data mart sales and how to use the MS Excel within data mart.

44

SEZNAM LITERATURE Adamson, Christopher in Venerable, Michael. 1998. Data Warehouse Design Solutions. New York: A John Wiley & Sons. Berce, Janez. 2001a. Mala kuharica za skladiščenje podatkov z Microsoft SQL Server. 2000. Berce Janez, s. p., informacijsko svetovanje. Berce, Janez. 2001b. Izgradite podatkovno skladišče Delavnica. Berce Janez, s. p., informacijsko svetovanje. Bobek, Samo in Dušan, Lesjak. 1995. Informatika za ekonomiste. Maribor: Ekonomsko-poslovna fakulteta. Bobek, Samo. 2003. Računalniške rešitve za podporo managementa [Online]. EPF Maribor. Available: http://epf-oi.uni-mb.si/clani/bobek/informatika/tema7.pdf [6. 3. 2003]. Gradišar, Miro in Resinovič, Gortan. 2000. Informatika v organizaciji. Kranj: Moderna organizacija. Kimball, Ralph. 1998. The Data Warehose Lifecycle Toolkit. New York: A John Wiley & Sons. Koletnik Franc, Kovač Jure, Rozman Rudi. 1993. Management. Ljubljana: Gospodarski vestnik. Microsoft. 1999. Designing and Implementing a Data Warehouse Using Microsoft SQL Server 7.0. Microsoft Corporation. Pahor, David. 2002. Leksikon računalništva in informatike. Ljubljana: Pasadena. Ponniah, Paulraj. 2001. Data Warehouse fundamental. New York: A John Wiley & Sons, Inc. Rožanec, Alenka. 2000. Izgradnja večdimenzionalnih podatkovnih baz za programske rešitve OLAP. Dnevi slovenske informatike Portorož. Zbornik posvetovanja 2000, 100-105. Srića, Velimir, Sonja, Treven, in Mile, Pavlič. 1995. Informacijski sistemi. Ljubljana: Gospodarski vestnik Todman, Chris. 2001. Designing a Data Werehouse. Hewlett-Pacard Company

45

KAZALO TABEL TABELA 1: MERE IN DIMENZIJE PRI PROCESU NAROČILO .................................. 20 TABELA 2: MERE IN DIMENZIJE PRI PROCESU IZDANE FAKTURE..................... 32 TABELA 3: PLAČILNA NAVADA IN PROMET PREJEMNIKA.................................. 33 KAZALO SLIK SLIKA 1: POROČEVALSKI ŠPAGETI ............................................................................ 10 SLIKA 2: FAZE PRI ODLOČANJU .................................................................................. 10 SLIKA 3: VODSTVENE RAVNI V PODJETJU............................................................... 11 SLIKA 4: OSNOVNI ELEMENTI PODATKOVNEGA SKLADIŠČA............................ 15 SLIKA 5: DIMENZIJSKI MODEL PROCESA NAROČILO ........................................... 21 SLIKA 6: ZVEZDASTA STRUKTURA............................................................................ 22 SLIKA 7: SNEŽINKASTA STRUKTURA........................................................................ 22 SLIKA 8: ARHITEKTURA OLAP .................................................................................... 23 SLIKA 9: OSNOVNI ELEMENTI KOCKE OLAP ........................................................... 24 SLIKA 10: THE BUSINESS DIMENSIONAL LIFECYCLE DIAGRAM ....................... 26 SLIKA 11: PRIMER POROČILA PREGLED PRODAJE PO KLASIFIKACIJAH ......... 31 SLIKA 12: DIMENZIJSKI MODEL IZDANA FAKTURA.............................................. 32 SLIKA 13: SNEŽINKASTA STRUKTURA IZDANE FAKTURE .................................. 33 SLIKA 14: PRIMER KREIRANJA DIMENZIJE ARTIKLI ............................................. 34 SLIKA 15: PAKET OKOLJA DTS PODATKOVNE HRAMBE...................................... 35 SLIKA 16: PAKET DTS, KI NAPOLNI DIMENZIJE IN TABELO DEJSTEV .............. 35 SLIKA 17: PRIMER IZDELAVE DIMENZIJE ARTIKLI................................................ 36 SLIKA 18: SHRANJEVANJE KOCKE OLAP IN POLNJENJE ...................................... 36 SLIKA 19: PAKET DTS, KI NAPOLNI KOCKO OLAP ................................................. 37 SLIKA 20: TEHNIČNA ARHITEKTURA PODATKOVNEGA SKLADIŠČA............... 38 SLIKA 21: VRTILNA TABELA........................................................................................ 39 SLIKA 22: KATERE REGIJE SO ZA PODJETJE NAJPOMEMBNEJŠE? ..................... 39 SLIKA 23: KAKŠNA JE PRODAJNA NAPOVED?......................................................... 40 SLIKA 24: PREGLED PRODAJE ARTIKLOV ZA LETO 1999 IN 2000 ....................... 40 SLIKA 25: PRIMERJAVA PRODAJE BRISAČ PO REGIJAH ....................................... 41 SLIKA 26: PLAČILNE NAVADE PLAČNIKOV............................................................. 41