PODATKOVNO SKLADIŠČE ZA ZAVAROVALNICO - … · V diplomski nalogi sem v prvem delu ... Diplomsko delo predstavlja opis rešitve ki temelji na podatkovni zbirki Oracle. ... orodja

Diplomsko delo visokošolskega strokovnega študija

Smer: Informatika v organizaciji in managementu

PODATKOVNO SKLADIŠČE ZA

ZAVAROVALNICO

Mentor: zasl. prof. dr. Vladislav Rajkovič Kandidat: Vajo Lukić

Kranj, Maj 2011

ZAHVALA

Zahvaljujem se mentorju zasl. prof.dr. Vladislavu Rajkoviču za pomoč pri izdelavi

diplomskega dela

Povzetek

V podjetju NLB Vita d.d. Ţivljenjska zavarovalnica, Ljubljana (v nadaljevanju NLB

Vita) smo pred enim letom na podlagi analize lastnih potreb in glede na zahteve po

poročanju Nadzornemu svetu zavarovalnice in Agenciji za zavarovalni nadzor,

pričeli z izgradnjo podatkovnega skladišča. Projekt smo razdelili na dva dela. V

prvem delu je planirano postaviti infrastrukturo za izgradnjo podatkovnega skladišča

ter ga napolniti s podatki, ki bodo zadostovali za izdelavo zahtevanih poročil. V

drugem delu pa ţelimo zagotoviti nadgradnjo skladišča s poročili, ki jih potrebujejo

sektorji zavarovalnice za podporo poslovnim procesom.

Projekt je trenutno v drugi fazi, ker ţe poteka izdelovanje nekaterih poročil. Ker nam

lastna znanja niso zadostovala, smo k sodelovanju pritegnili tudi nekaj strokovnjakov

iz NLB, ki so ţe bili udeleţeni v podobnih projektih znotraj banke. Z njihovo

pomočjo upamo projekt bo dokončan v predvidenih rokih.

V diplomski nalogi sem v prvem delu predstavil celoten pogled na trenutno

organizacijo informacijske podpore v NLB Vita, vrsto organizacijskih teţav in ovir,

ki se kaţejo ob snovanju podatkovnega skladišča in njihove morebitne rešitve. V

nalogi sem obdelal glavne vzroke, ki so povod za izgradnjo podatkovnega skladišča,

kot so potrebe za poslovno odločanje in zahteve po poslovnem poročanju.

V drugem delu sem se posvetil razpoloţljivim tehnologija in načinom izgradnje

podatkovnih skladišč. Hkrati sem predstavil postavitev pilot projekta poročanja z

uporabo podatkovnega skladišča.

Ključne besede

- Podatkovno skladišče, poslovno poročanje, poslovno odločanje

Abstract

Building of a data warehouse in NLB Vita d.d. Life insurance, Ljubljana (in

following text NLB Vita), started a year ago, initiated by reporting requirements to

Management board and to Agency for insurance overview, and also based on the

analysis of companies needs. First phase of the project should result in development

of infrastructure for data warehouse, as well as filling it with data required for

reporting processes. In the second phase we plan to build all necessary reports for

various departments, in order to support their business processes.

The project itself is currently in the second phase, and some reports are already being

produced. Because of a lack of necessary technical skills and experience, some

members of a data warehouse team from NLB bank joined our efforts. With their

help we hope to finish project in due time.

In this work I gave a complete overview of IT department organization in NLB Vita,

and also represented a series of hurdles on the path to the successful building of a

data warehouse, along with solutions to these problems. This work presents main

issues that provoked starting of this project, like decision making, business reporting

etc.

In the second part of this work, I am focusing on available technologies and discuss a

ways of building data warehouses. At the same time I am presenting a pilot project as

a demonstration for data warehouse reporting.

Keywords

- Data warehouse, decision making, business reporting

Kazalo

1 Uvod ..................................................................................................................... 1

1.1 Predstavitev problema ................................................................................... 1

1.2 Predstavitev okolja ........................................................................................ 2

1.3 Predpostavke in omejitve .............................................................................. 3

1.4 Metode dela ................................................................................................... 3

2 Podatkovna skladišča ........................................................................................... 5

2.1 Kratek zgodovinski pregled razvoja podatkovnih skladišč ........................... 5

2.2 Osnovni pojmi o podatkovnih skladiščih ...................................................... 6

2.3 Razlike med transakcijskimi sistemi in podatkovnimi skladišči................... 8

2.4 Arhitektura podatkovnih skladišč ................................................................. 9

2.5 Sheme podatkovnih skladišč ....................................................................... 11

2.6 Logično modeliranje podatkovnega skladišča ............................................ 12

2.7 Fizično modeliranje podatkovnih skladišč .................................................. 13

3 Prikaz stanja in uporabe informacijske tehnologije v organizaciji .................... 14

3.1 Organiziranost sektorja informacijskih sistemov na nivoju druţbe ............ 14

3.2 Kritična analiza ........................................................................................... 20

4 Prenova procesa poročanja ................................................................................ 22

4.1 Planiranje in načrtovanje ............................................................................. 22

4.2 Tehnična izvedba ........................................................................................ 25

Fizična infrastruktura ......................................................................................... 25

Logični podatkovni model ................................................................................. 26

4.3 Dimenzijski model za spremljanje letnega plana prodaje ........................... 32

5 Zaključki ............................................................................................................ 45

5.1 Učinki in dodana vrednost .......................................................................... 46

5.2 Pogoji za nadaljevanje projekta .................................................................. 47

5.3 Moţnosti nadaljnjega razvoja ..................................................................... 47

Literatura in viri ..................................................................................................... 48

Priloge .................................................................................................................... 50

Kazalo slik ............................................................................................................. 50

Kazalo tabel ........................................................................................................... 50

Pojmovnik .............................................................................................................. 51

Kratice in akronimi ................................................................................................ 51

Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 1

1 Uvod

Za učinkovito poslovanje zavarovalnice predvsem pri odločanju o razvoju novih

produktov in kakovostnem spremljanju tekočih poslov so ključnega pomena

informacije, ki so na razpolago v informacijski podpori zavarovalnice. Za poslovno

odločanje je v zavarovalnici najpomembnejša kvalitetna i aţurna informacija o

sprotnem likvidnem stanju sredstev zavarovalnice ter podatki, ki jih potrebujemo za

izračun matematičnih rezervacij zavarovalnice.

Poleg podatkov o likvidnih sredstvih in finančnih tokovih v zavarovalnici pa so

seveda pomembni tudi ostali nefinančni podatki, kot so denimo podatki o številu

strank, številu polic, številu škod in odkupov v obdobju, posamezni podrobni podatki

o policah, strankah in produktih.

Finančni del poslovanja je v zavarovalnicah običajno kakovostno podprt tudi z

ustrezno informacijsko podporo, saj se računalniški podpori finančnega dela, kot je

glavna knjiga, od samega začetka uporabe računalništva posveča velik del

razpoloţljivih strojnih in človeških virov. Problem nastane, ko se poizkušajo

pridobiti nefinančni podatki ali pa analitični finančni podatki, saj računovodski del

računalniške podpore velik del podatkov hrani na sintetičnem in ne analitičnem

nivoju.

1.1 Predstavitev problema

Pri iskanju ustrezno organiziranih analitičnih podatkov, tako finančnih kot

nefinančnih, v zavarovalnicah velikokrat naletimo na vrsto različnih problemov. V

NLB Vita se navadno najprej srečamo z različnimi, med seboj nepovezanimi

aplikacijami ter celo z različnimi platformami in različnimi izvajalci podpore.

Nepovezanost posameznih delov računalniške podpore poslovanju nas pripelje do

zelo teţavnega zbiranja podatkov z pripravo kvalitetnih in celovitih informacij. Poleg

tega, da imamo podatke zbrane v večjih aplikacijah, je znanje, ki nam omogoča

pridobitev podatkov, bolj ali manj na voljo. Predvsem pri aplikacijah, ki so jih

razvijali in jih vzdrţujejo zunanji izvajalci, je dostop do ţelenih podatkov teţaven,

zanj pa se navadno porabi veliko časa. V trenutku, ko posel obvladujemo z več

aplikacijami, pa nastane še problem nepovezanosti posameznih podatkov med seboj.

Med seboj povezani so samo določeni segmenti posameznih aplikacij. Določene

aplikacije pa so celo popolnoma samostojne.

Posamezne aplikacije zagotavljajo tudi različne časovne okvire vpogledov v

zgodovino podatkov. Transakcijski sistemi navadno ne omogočajo pregleda

podatkov za daljše zgodovinsko obdobje. Problem nastane predvsem v primeru, če se

je tehnologija transakcijskega sistema menjala. Zaradi tega je treba za dostop do

podatkov iz starejšega sistema uporabiti vrsto različnih aplikacij na različnih

platformah ali celo različnih medijih (arhiv na papirju ali na disketah).



Glavni problem je organizirati več ločenih nepovezanih delov računalniške podpore

poslovanju v skupno povezano smiselno celoto. Ker obstoječe aplikacije bolj ali

manj kvalitetno in zadovoljivo pokrivajo potrebe za izvedbo posla, je potrebno

izdelati ustrezno podatkovno skladišče, v katerem bodo na razpolago podatki iz vseh

aplikacij. Te podatke je med seboj treba maksimalno povezati ter zagotoviti ustrezno

programsko opremo, ki bo omogočala izvajanje ţelenih poizvedb in predstavitev ter

izvoz teh podatkov.

Sistemi, ki jih najdemo v naravno razvitih arhitekturah podatkov v praksi, so

preprosto nezadostni za izvajanja nalog podpore informacijskih potreb zaradi

pomanjkanja medsebojne integracije podatkov in zaradi različnih časovnih

intervalov, ki jih le-ti pokrivajo (Inmon, 2002).

1.2 Predstavitev okolja

Leta 2002 je belgijska bančno zavarovalniška skupina KBC s pridobitvijo 34-

odstotnega lastniškega deleţa v Novi Ljubljanski banki d.d., vstopila na slovenski trg

finančnih storitev. V strategiji razvoja Skupine NLB je bil tedaj za obdobje od leta

2002 do leta 2006 kot eden izmed strateških ciljev opredeljen tudi razvoj bančnega

zavarovalništva oz. uporaba skupne trţne poti in baze komitentov za prodajo bančnih

in zavarovalniških storitev.

Leta 2003 je bila tako ustanovljena NLB Vita, ţivljenjska zavarovalnica, d.d. ki je do

danes ţe dosegla 6-odstotni trţni deleţ. NLB in strateška partnerica KBC Insurance,

sta jo ustanovili vsaka s polovičnim kapitalskim vloţkom. Ustanovljena je bila z

namenom opravljanja zavarovalnih poslov, za katere je pridobila dovoljenje

Agencije za zavarovalni nadzor, in za druge posle, ki jih zavarovalnica lahko

opravlja v skladu z veljavnimi predpisi doma in v tujini. NLB Vita je bila prva

zavarovalnica v Sloveniji, ki je svoje storitve trţila izključno pri bančnih okencih.

Glavna ideja pri ustanovitvi je bilo zdruţevanje konkurenčne prednosti NLB kot

najmočnejše banke v Sloveniji z znanjem in izkušnjami KBC na področju

zavarovalništva, investicijskega bančništva in upravljanja ter informacijske

tehnologije.

NLB Vita je predvsem produktna tovarna, ki se osredotoča na razvoj produktov, s

katerimi NLB omogoči ponudbo modernih ţivljenjskih zavarovanj, prilagojenih

potrebam strank v vsakem trenutku. Tovrstna zavarovanja prinašajo novo obliko

varnosti in doseganje potencialno višjih donosov na sredstva, kot jih ponujajo

tradicionalni varčevalni programi, hkrati pa poskrbijo za varno prihodnost

zavarovane osebe in njene druţine. Ţivljenjska zavarovanja so tudi primerna oblika

za dodatno motiviranje zaposlenih.

NLB Vita trţi zavarovalne produkte izključno v poslovni mreţi bank članic skupine

NLB in Banke Celje. NLB Vita v poslovalnicah bank ponuja moderne produkte,

prilagojene trţni poti bančnega zavarovalništva, kot so to:



Ţivljenjsko zavarovanje z zajamčenim donosom

Osnovno ţivljenjsko zavarovanje

Ţivljenjsko zavarovanje posojilojemalcev, kjer je trajanje zavarovanja vezano

na dokončno odplačilo posojila

Ţivljenjsko zavarovanje, vezano na enote investicijskega sklada

Nezgodno zavarovanje imetnikov plačilnih kartic

Nezgodno zavarovanje imetnikov zlatih plačilnih kartic

Nezgodno zavarovanje imetnikov osebnih računov ipd.

Poslanstvo družbe je poslovati in rasti odgovorno do strank in okolja, se nenehno

potrjevati kot strokovna, inovativna in dinamična zavarovalnica, ki z optimalnim

izkoriščanjem trţenjskih, razvojnih in procesnih sinergij svojim strankam omogoča

varnejšo in bogatejšo prihodnost.

NLB Vita bo bančna zavarovalnica, ki bo na slovenskem trgu na sodoben način

ponujala transparentne, fleksibilne, raznolike zavarovalne produkte, ki bodo vsem

segmentom bančnih komitentov nudile kvalitetno storitev, ţeleno varnost in stabilne

donose na vloţena sredstva.

Vizija in cilji družbe so krepitev poloţaja vodilne bančne zavarovalnice na

domačem trgu. Na področju ţivljenjskih zavarovanj je cilj povečanje trţnega deleţa

ter ustvarjanje visokega donosa na vloţeni kapital. Poslovati tako, da bo vseskozi

zagotovljena likvidnost, solventnost in kapitalska ustreznost zavarovalnice. Produkti

morajo biti moderni, prilagojeni potrebam strank, ter poslovanje pa bo pregledno in

stroškovno učinkovito.

NLB Vita bo prepoznavna, transparenta, fleksibilna, strokovna in inovativna

zavarovalnica, ki se bo hitro odzivala na potrebe svojih strank ter na priloţnosti in

nevarnosti iz okolja in svojim zaposlenim nudila prijetno delovno okolje.

1.3 Predpostavke in omejitve

Diplomsko delo predstavlja opis rešitve ki temelji na podatkovni zbirki Oracle.

Diplomska naloga je tehnično zasnovana na podatkovni zbirki Oracle različica

10.2.0.3, ki je nameščena na Windows Server 2008 operacijskem sistemu.

Podatkovni model je bil razvit z uporabo programskih jezikov SQL in PLSQL, in

orodja PLSQL Developer verzije 8. Nazivi podatkovnih zbirk in streţnikov so zgolj

simbolični. Tehnični detajli se nanašajo izključno na omenjeno različico podatkovne

zbirke in omenjeno različico operacijskega sistema.

1.4 Metode dela

Diplomsko delo je izdelano na podlagi konkretnega projekta v okviru rednega dela v

sektorju informatike zavarovalnice. V diplomskem delu so prikazani procesi

načrtovanja in implementacije, in so podrobno predstavljeni vsi realni delovni



procesi in postopki. Vzporedno z vodenjem projekta za implementacijo

podatkovnega skladišča v zavarovalnici je potekala tudi izdelava diplomske naloge.

Znanja ki sem jih pridobil v okviru dodiplomskega študija ter znanja in izkušnje ki

sem jih pridobil praktično pri sodelovanju na številnih projektih, so mi veliko

pomenila tekom izdelave diplomske naloge. Pri izdelavi naloge sem se zanašal na

praktične primere, teorijo, primere iz literature in ţe znane metodologije za

postavitev podatkovnih skladišč.



2 Podatkovna skladišča

Skladiščenje podatkov je nov koncept ki se je pojavil sredi 90-ih let 20-ega stoletja.

Razvil se je zaradi potrebe hitrega pridobivanja informacij v kratkem času, in se

uporablja kot podpora sistemu poslovnega odločanja. Skladišče podatkov vsebuje

ogromno količino podatkov ki omogočajo izdelavo kakovostnih in natančnih poročil,

ki pomagajo vodstvenemu kadru podjetja pri sprejemanju poslovnih odločitev.

V tem poglavju sem podal kratek zgodovinski razvoj podatkovnih skladišč, in tudi

razlago o tem kako je prišlo do pojave podatkovnih skladišč. Definiral sem glavne

lastnosti podatkovnih skladišč, cilje za njihovo izgradnjo in opisati model podatkov

ki se takrat uporablja.

2.1 Kratek zgodovinski pregled razvoja podatkovnih skladišč

V zgodovinskem pregledu skladiščenja podatkov je treba začeti z opisom kako se je

počelo s podatki preden je nastal koncept skladiščenja podatkov. Skozi zgodovino

sistemskega razvoja je glavni poudarek vedno bil na razvoju operacijskih sistemov.

Za takšne sisteme ni bilo praktično hraniti stare podatke za nedoločen čas, in se jih je

shranjevalo v arhive (večinoma na magnetne trakove ipd.) Takšen način dela je bil

značilen za sisteme v 70-ih letih prejšnjega stoletja, ki so bili monolitni sistemi z

centraliziranimi računalniki. Vendar so takšni sistemi bili glavni vir podatkov za

poslovne analize. Takšnim sistemom pravimo legacy systems.

V 80-ih letih prejšnjega stoletja prihaja do popularizacije osebnih računalnikov. Moč

teh narašča, in se pojavljajo nove moţnosti kot je recimo grafični uporabniški

vmesnik (GUI – graphical user interface) zaradi česa postaja uporaba računalnikov

vedno bolj enostavna. Vse to bo pripeljalo do tega da se bo zmanjšal prepad med

programerji in uporabniki. Tovrstni sistemi bojo omogočili prenos podatkov iz

podedovanih sistemov v osebne računalnike in tudi razvoj orodij za izdelavo analiz

in poročil. Vendar je takšen način dela povzročal tudi teţave zaradi fragmentacije

podatkov na več osebnih računalnikov. Drugi velik problem je bilo pomanjkanja

enotnega standarda za črpanje podatkov zaradi česa so uporabniki morali poznati

strukturo podatkovne baze, kar je za marsikaterega uporabnika bila velika ovira pri

vsakdanjem delu.

Preden so nastala podatkovna skladišča, so sistemi za podporo odločanju bili najbolj

napredna orodja za analizo podatkov. Čeprav zaradi visoke cene nikoli niso bili

pogosto uporabljani, so bili pomemben člen v verigi razvoja sistemov za skladiščenje

podatkov.

Kot smo videli, skozi zgodovino se je s podatki ravnalo na različne načine. V samem

začetku razvoja informacijskih sistemov, se je podatke celo izločalo iz sistema na

posebej za to določene zunanje medije za shranjevanje podatkov. Glavni razlog za to

je bila nezadostno razvita tehnologija. Tedanji računalniki niso imeli dovolj moči, so



imeli premajhno kapaciteto in niso mogli zadovoljiti vseh potreb uporabnikov. Ker

se je tehnologija razvoja elektronskih komponent vedno izboljševala, so se pojavljali

močnejši procesorji, diski z večjo gostoto zapisovanja in kapaciteto in nove vhodne

in izhodne enote. Kljub močnemu napredku in razvoju komponent, je njihova cena

postopoma padala in so računalniki postajali vedno bolj dostopni navadnemu

človeku. Vse to je omogočilo razvoj različnih načinov za shranjevanje in obdelavo

podatkov in posledično tudi razvoj skladiščenja podatkov.

Prav tako se kot posledica razvoja pojavljajo močnejši osebni računalniki, ki

omogočajo razvoj tehnologije streţnik/odjemalec in tudi razvoj distribuiranih

sistemov. Programska podpora tudi napreduje, in se na osebnih računalnikih

uporabljajo vedno močnejše različice programov. Razvoj osebnih računalnikov je

pomemben za razvoj podatkovnih skladišč, ker so prav ta danes glavni način za

dostopanje do podatkovnih skladišč.

Drugi pomemben dejavnik ki je močno vplival na razvoj skladiščenja podatkov je

nastanek in razvoj Intraneta in uporaba spletnih uporabniških programov. Intranet

omogoča dostop do podatkov v podatkovnem skladišču vsem zaposlenim v podjetju.

Še ena sprememba v delovnem okolju je vplivala na razvoj podatkovnih skladišč. V

90-ih letih prejšnjega stoletja se je zrušil komunizem, kar je povzročilo nastanek

novih drţav ki so hitro vpeljale trţno orientirano ekonomijo, s čem so nastali in se

odprli novi trgi. Ritem ţivljenja postaja hitrejši, čas je vedno bolj pomemben,

pojavlja je globalizacijsko gibanje, korporacije se širijo čez meje več drţav in

informacija postaja najbolj vredno blago, če je pravočasna in natančna. Skupaj s tem

se pojavljajo potrebe po podatkovnih skladiščih.

2.2 Osnovni pojmi o podatkovnih skladiščih

Kaj je podatkovno skladišče ? Podatkovno skladišče je relacijska zbirka, bolj

prilagojena poizvedbam in analizi podatkov, kot transakcijskim obdelavam. Običajno

vsebuje zgodovinske podatke izvlečene iz transakcijskih podatkov, čeprav lahko

vsebuje tudi podatke iz drugih virov.

Podatkovno skladišče ločuje obremenitve ki nastajajo zaradi analize od tistih ki

nastajajo zaradi transakcijskih obdelav in omogoča podjetju da poenoti podatke iz

več različnih virov. Poleg tega da ima lastnosti relacijske zbirke, podatkovno

skladišče lahko vsebuje tudi ETL moţnosti (Extract, Transformation, Load - pridobi,

pretvori, prenesi), OLAP (On-Line Analytical Processing- sprotna analiza podatkov),

Data Mining in druge funkcije ki omogočajo zbiranje in dostavo podatkov poslovnim

uporabnikom.

Podatkovno skladišče je baza podatkov, kjer so podatki urejeni, prečiščeni in

integrirani v enotno strukturo, tako da lahko na dokaj enostaven način, z enostavnimi

poizvedbami, pridemo do ţelenih informacij. Vendar pa, v odvisnosti od avtorja,

obstaja veliko različnih definicij podatkovnega skladišča.



Bill Inmon, ki ga nekateri imajo za očeta podatkovnega skladišča, je leta 1990

opredelil termin podatkovno skladišče. Njegova definicija je : podatkovno skladišče

je vsebinsko orientirana, integrirana, časovno odvisna in statična zbirka podatkov,

namenjena podpori procesa poslovnega odločanja.

Integrirana (Integrated) - podatki zbrani v podatkovno skladišče iz različnih

virov in spojeni v skladno in razumljivo celoto.

Vsebinsko orientirana (Subject oriented) - podatki, ki nam podajajo

informacije o določeni vsebini, namesto o aplikacijah operativnega sistema

organizacije.

Časovno odvisna (Time variant) - vsi podatki v podatkovnem skladišču

imajo svojo časovno komponento in so časovno odvisni, torej nam

omogočajo analizo časovnih vrst.

Statična (Static) - podatki so statični, dodajajo se novi, stari pa se ne

spreminjajo in ne brišejo. Tako lahko pridobi management podrobno sliko

organizacije.

Drug veliki predstavnik podatkovnih skladišč pa je Ralph Kimball, ki pa drugače

definira podatkovno skladišče. Pravi, da je podatkovno skladišče posnetek

transakcijskih podatkov, ki so strukturirani na tak način, da so primerni za vse vrste

analiz in poizvedb.

Podatkovno skladišče je zbirka podatkov, ki je samo za branje in se uporablja kot

osnova sistemov za podporo odločanja. Podatkovno skladišče je zbirka podatkov, ki

omogoča podporo pri odločanju managementa. Podatkovno skladišče vsebuje veliko

podatkov, ki so prisotni v poslovnem sistemu v določenem času.

Slika 1: Proces skladiščenja podatkov



2.3 Razlike med transakcijskimi sistemi in podatkovnimi skladišči

Transakcijski sistemi ali OLTP (Online Transaction Processing Systems) sistemi so

za uspešno poslovanje podjetja nujni. Njihov cilj je avtomatizacija poslovnih

procesov. Glavna značilnost je operativna baza podatkov, ki je zbirka medsebojno

povezanih operativnih podatkov, ki so shranjeni v računalnikovem pomnilniku brez

nepotrebnega podvajanja na način, ki omogoča njihovo uporabo številnim

uporabnikom z različnimi zahtevami. Podatki so shranjeni tako, da so neodvisni od

programov, ki jih uporabljajo.

OLTP sistemi 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 na enkrat. Tipični značilnosti le-teh 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

relacijski in normalizirani. V tem primeru nudijo izjemno zmogljivost in zagotavljajo

konsistenco podatkov.

Podatkovna skladišča se precej razlikujejo od sistemov za sprotno obdelovanje

podatkov. Razlogi za te razlike so zahteve ki se zastavljajo takšnim sistemom

oziroma njihov namen. Prav zaradi tega je ena najbolj opaznih razlik med

transakcijskimi sistemi in podatkovnimi skladišči ta, da v podatkovnih skladiščih

podatki običajno niso normalizirani, dokler so v transakcijskih sistemih po navadi v

tretji normalni formi. Baza podatkov, ki je optimizirana za transakcijske sisteme,

mora biti normalizirana. To pomeni, da se podatki v bazi ne smejo nepotrebno

podvajati. V primeru podvajanja podatkov v tabeli, se uvede novo tabelo in se med

seboj poveţe z relacijo ena proti mnogo. Na tak način omogočimo enostavnejšo in

hitrejšo aţuriranje podatkov.

OLTP sistem je izdelan za obvladovanje velikega števila podatkov, ki nastajajo z

vsakodnevnimi opravili, vendar ni primeren za iskanje vprašanj, ki si jih vodstvo in

poslovni analitiki običajno zastavljajo. Poglejmo si vprašanje, ki je izredno poslovno

usmerjeno: »Kateri artikel je bil najbolj prodajan v zadnjem četrtletju v izbrani

poslovni enoti ?«. OLTP sistem, ki mora v takem primeru kategorizirati in sešteti

ogromno količino podatkov, ki so organizirani na relacijski način, včasih dobesedno

odpove, saj ni sposoben dela opraviti v razumno kratkem času. Poleg tega izvajanje

takih poizvedb nad podatkovno bazo zahteva veliko specifičnega znanja, ki ga

običajno poslovni analitiki nimajo. Zato bi ustrezne podatke lahko pripravljala

zadolţena sluţba, vendar ta način ne bi zadoščal osnovni zahtevi, to je hiter odzivni

čas. Zato se je pojavila potreba po posebni podatkovni bazi, ki je namenjena

poslovnim analizam.

Za pridobivanje takšnih informacij potrebujemo drugačno strukturo baze podatkov,

usmerjeno za obvladovanje bolj poslovnih, analitičnih in raziskovalnih poizvedb.

Tako strukturo imajo podatkovna skladišča, ki so optimizirana za zajemanje in

obdelovanje podatkov s pomočjo orodij OLAP (On-Line Analytical Processing).



Zanjo je značilna zvezdasta (in sneţinkasta) shema (več o tem v nadaljevanju), ki je

zelo preprosta. Takšna rešitev je osredotočena samo na analiziranje podatkov.

Tovrstna podatkovna struktura daje hitre odzive na kompleksne poizvedbe, ki

zahtevajo velike količine podatkov zaradi dveh značilnosti :

1. podatki so shranjeni v dimenzijski obliki in ne v relacijski in

2. predhodno izračuna agregate, da lahko doseţe hiter odziv na uporabnikove

zahteve.

Za podatkovna skladišča se priporoča podvajanje podatkov, saj se lahko z

zmanjševanjem normalizacije poizvedbe izvajajo na oţjem predelu podatkovne baze.

To povečuje hitrost obdelovanja podatkov. Dodaten prostor, ki ga zasedajo ne

normalizirane dimenzijske tabele, je dejansko zelo majhen v primerjavi s prostorom,

ki ga zasedejo tabele dejstev.

Ključna prednost sistema OLAP pa je, da omogoča pregledovanje podatkov iz vseh

moţnih perspektiv, ne da bi poznali nepostopkovni strukturirani poizvedovalni jezik

(SQL - angl. Structured Query Language) in priprava poročil brez nepotrebnega

čakanja.

2.4 Arhitektura podatkovnih skladišč

Arhitektura je zbirka pravil o strukturi, ki je globalni okvir za oblikovanje sistema ali

produkta. Podatkovna arhitektura (data arhitecture) nam pove, kako so podatki

razporejeni po sistemu. Glavna lastnost arhitekture podatkov za podatkovno

skladišče je, da so ti podatki samo za branje in so namenjeni za podporo odločanju.

Izvor podatkov oziroma vir podatkov so podatki različnih bazah podatkov,

datotekah, na papirju itd. ki bodo s pomočjo ekstrakcije iz operativnih, transakcijskih

sistemov preneseni v podatkovno skladišče. Izvor podatkov je lahko tudi zunaj

organizacije (npr. tečajna lista).

Osnovno vprašanje pri izgradnji podatkovnih skladišč je, kako zbirati in zajemati

podatke za poslovne analize. Osnova analiz so notranji (transakcijski) in zunanji

podatki, ki morajo biti shranjeni v bazi podatkov. Kako bomo podatke zbrali, je

odvisno od potreb in zahtev podjetja. Moţnih je več načinov in vsak ima svoje

prednosti ter slabosti Tri najpogosteje uporabljane oblike podatkovnih skladišč so :

1. Osnovna oblika podatkovnih skladišč (Basic Data Warehouse Architecture ) -

Pri tej obliki končni uporabnik skozi podatkovno skladišče direktno dostopa

do podatkov zajetih iz transakcijskih sistemov

2. Podatkovno skladišče z začasnim področjem za obdelovanje podatkov (Data

Warehouse Architecture with Staging Area) – preden podatke prenesemo v

podatkovno skladišče jih je treba obdelati in prečistiti. To lahko storimo

programsko, ali s pomočjo začasnega področja za obdelovanje podatkov



3. Podatkovno skladišče z začasnim področjem za obdelovanje podatkov in s

področnimi skladišči (Data Warehouse Architecture with Staging Area and

Data Marts) – če podatke v podatkovnem skladišču ţelimo prilagoditi za

uporabo v različnih oddelkih organizacije, za to uporabimo področna

skladišča.

Odločitev o arhitekturi je ena najpomembnejših odločitev pri načrtovanju

podatkovnega skladišča. Ne poznamo arhitekture, ki bi ustrezala vsem, ampak

določene arhitekture bolj ustrezajo nekaterim situacijam kot druge. Vsekakor pa, pri

izbiri ustrezne arhitekture moramo upoštevati nekaj osnovnih dejavnikov :

poslovni cilji - ali potrebujemo vse podatke organizacije ? Ali bo veliko

število hkratnih uporabnikov podatkovnega skladišča.

poloţaj odgovorne osebe v podjetju - uspešnost zagotavlja samo odgovorna

oseba na dovolj visokem poloţaju v organizaciji.

vrsta posla - ali je organizacija centralizirana ali decentralizirana ? Ali je

pripravljena na podvajanje in razširjanje podatkov ?

značilnosti podatkov - pomembno je dvoje : velikost podatkovnega skladišča

in kompleksnost. Drugače moramo obravnavati kompleksne podatke kot

enostavne, drugače moramo obravnavati situacijo, ko imamo malo zelo

velikih in kompleksnih tabel, kot situacijo, ko imamo veliko majhnih in

enostavnih tabel.

poizvedbe in procesne zahteve - ali bodo poizvedbe enostavne ali

kompleksne ?

razvitost organizacije – če hočemo vzpostaviti uspešno in kvalitetno

podatkovno skladišče, mora imeti organizacija urejen in razvit informacijski

in organizacijski del.



Slika 2: Osnovne komponente podatkovnega skladišča

2.5 Sheme podatkovnih skladišč

Pri izdelavi podatkovnega skladišča je treba poslovni proces prevesti v primerno

obliko. Tej prevedbi pravimo dimenzijsko modeliranje. Izraz shema pomeni mnoţico

objektov relacijske podatkovne zbirke (npr. tabele, vpogledi, indeksi). Dve obliki

shem sta karakteristični za podatkovna skladišča : zvezda in snežinka. V večini

primerov se za podatkovna skladišča uporablja zvezdasta podatkovna struktura. Ime

je dobila po njenem videzu. Sestavljena je iz več dimenzijskih tabel, ki so povezane z

osrednjo tabelo (t.i. tabelo dejstev) z relacijo 1:N.

Tabela dejstev je srce zvezdaste sheme in zavzame 97% do 99% prostora na disku od

celotne strukture, ker vsebuje vse vrednosti, ki jih z orodji OLAP obdelujemo.

Sestavljena je iz dveh različnih tipov polj. Prvi so tuji ključi dimenzijskih tabel in

drugi so vrednosti meritev. Tabele dejstev običajno nimajo posebej polja za glavni

ključ, ampak je le-ta sestavljen iz vseh tujih ključev. Prilagojene so za izredno hitro

naraščanje števila vrstic podatkov, saj se jih z novimi podatki polni na vsako uro, dan

ali teden. Na primer nočno polnjenje faktur, ki so bile izstavljene prejšnjega dne.

Dimenzijske tabele so razporejene okoli centralne tabele (tabele dejstev) in

omogočajo pregledovanje meritev iz različnih perspektiv. Vsaka dimenzijska tabela

predstavlja eno dimenzijo kocke. Vsebinsko so to entitete, ki se pojavljajo v

poslovnem procesu: izdelki, poslovne enote, valuta, vrsta poslovanja in predvsem

obdobje.



Za zvezdasto shemo je značilna izredna preprostost. Osnovna struktura nima verige

med seboj povezanih tabel. Vsaka dimenzijska tabela je direktno povezana s tabelo

dejstev (primarni ključ do tujega ključa). To omogoča hitro poizvedovanje nad

velikim številom podatkov. Tabele, povezave in polja v tej shemi imajo posebno

označevanje, prilagojeno večdimenzionalni strukturi OLAP kock. Običajno se

podatkov v tabelah nikoli ne aţurira in briše, izjemoma v primeru popravljanja napak

ali pa pri popravljanju celotne sheme. Optimizirana je za namene sprotnega

analitičnega obdelovanja in zato mora omogočiti učinkovito branje podatkov.

Dimenzijske tabele so denormalizirane, ker potrebujemo minimalno število povezav.

V nekaterih primerih pa se uporablja tudi snežinkasto shemo, za katero je značilno,

da so tudi dimenzijske tabele normalizirane in posledica je bolj razvejana struktura

podatkov.

2.6 Logično modeliranje podatkovnega skladišča

Logično modeliranje se začne z modeliranjem podatkov. Model podatkov je

ponazoritev podatkov o predmetih, dogodkih, osebah, dokumentih ter njihovih

povezavah v okviru izbranega poslovnega postopka ali poslovne funkcije. Ena izmed

tehnik za modeliranje podatkov je metoda entitet-povezav (ER). Pri tej metodi

uporabljamo naslednje štiri komponente : entiteta, atribut, povezava, ključ. Entitete

so posamezne stvari ali pojave, ki obstajajo v sistemu ki ga modeliramo, in ki jih

lahko ločimo drugo od druge. Pri vsaki entiteti lahko identificiramo vrsto lastnosti.

Lastnosti ki so tako pomembne da jih vključimo v podatkovni model, imenujemo

atributi. Entitete nastopajo v medsebojnih povezavah. Če povezav ne bi bilo, potem

ne bi bilo nobene potrebe po podatkovnem modelu niti po modeliranju. Ključ je tisti

atribut določene entitete, ki enolično določa pojav iz mnoţice istovrstnih pojavov.

Čeprav se omenjena tehnika večinoma uporablja pri modeliranju visoko

normaliziranih sistemov kot so transakcijski sistemi, se jo da uporabiti tudi pri

modeliranju dimenzij za podatkovna skladišča. Namesto da jo uporabimo za

določanje kateri podatki pripadajo kateri klasi entitet, jo uporabimo za določanje

kateri podatki pripadajo tabeli dejstev, kateri pa tabelam dimenzij.

Glavna naloga pri načrtovanju podatkovnega skladišča je prevedba poslovnih

dogodkov v dimenzijski model (ang. Dimensional Model). Dimenzijsko modeliranje

je specifično modeliranje podatkov, ki so organizirani tako, da ob uporabi omogočajo

učinkovite poizvedbe in so razumljivi tako uporabnikom kot informatikom.

Dimenzijski model sluţi kot analitično orodje pri načrtovanju podatkovnega

skladišča in kot fizični model implementacije v podatkovno bazo. Dimenzijski model

mora v celoti odraţati poslovni proces tako, kot ga razumejo menedţerji in torej

odseva poslovne potrebe ter omogoča odgovor na vsa poslovna vprašanja. Če

govorimo z jezikom menedţerjev in uporabnikov, govorimo o poslovni uspešnosti,

stroških in merah. Elemente katere merimo z merami, pa imenujemo dimenzije.

Ključne mere najdemo na dva načina :



v strateških dokumentih in poslovnih poročilih podjetja ter v razgovoru z

vodstvenimi delavci. Običajno z njimi merimo kakovost, učinkovitost in

učinek procesa (količinsko, vrednostno).

s pregledom poslovnih dogodkov v obravnavanem procesu. Kot rezultat

poslovnih dogodkov nastajajo poslovna dejstva, ki jih opišemo z merami.

Dimenzije na podlagi znanih gradiv določimo glede na ključne poslovne vire,

ki so vključeni v poslovne dogodke.

Rezultat logičnega modeliranja je mnoţica entitet in atributov, ki predstavlja tabele

dejstev in tabele dimenzij podatkovnega skladišča. Logično modeliranje lahko

opravimo samo s svinčnikom in papirjem, ali s pomočjo specializiranih orodij kot sta

Oracle Data Warehouse Builder in Oracle Designer.

2.7 Fizično modeliranje podatkovnih skladišč

Tekom procesa fizičnega modeliranja podatkovnega skladišča, informacije zbrane pri

logičnem modeliranju, pretvarjamo v fizično strukturo podatkovnega skladišča.

Fizično modeliranje je kreiranje podatkovnega skladišča s pomočjo SQL ukazov.

Odločitve ki jih sprejemamo tekom fizičnega modeliranja so v glavnem odvisne od

tega kakšno stopnjo hitrosti poizvedb ţelimo doseči in kako bo kasneje potekalo

vzdrţevanje podatkovnega skladišča. Modeliranje fizične strukture pomeni prevedbo

vseh logičnih komponent v njihove fizične ekvivalente : entitete pretvarjamo v

tabele, povezave pretvarjamo v tuje ključe, atribute pretvarjamo v stolpce tabel,

primarne edinstvene identifikatorje v primarne ključe.



3 Prikaz stanja in uporabe informacijske tehnologije v

organizaciji

V grobem bi razvoj in informacijsko podporo NLB Viti lahko razdelil :

1. glede na vrsto posla (podpora pravnim osebam in zasebnikom, podpora

občanom) in

2. glede na avtorstvo (lastni razvoj in vzdrţevanje, lastni razvoj s podporo

zunanjih izvajalcev, zunanji razvoj in podpora)

Organiziranost sektorja informacijskih sistemov poteka na nivoju skupin.

Sodelovanje s skupino NLB se izvaja na treh nivojih :

1. NLB kot solastnik druţbe lahko narekuje izhodišča za delovanje informatike

v NLB Vita. V tem kontekstu nastaja strategija IKT na nivoju skupine, ki bo

v posameznih delih obvezujoča tudi za NLB Vito. Dosedanje aktivnosti na

področju celovitega obvladovanja informatike v skupini so bile usmerjene

predvsem v bančne članice skupine, v prihodnosti bo več sodelovanja in

obveznih usmeritev tudi za nebančne članice.

2. NLB je ponudnik infrastrukturnih storitev in za NLB Vito opravlja storitve v

zvezi z strojno opremo, omreţjem, internetom in standardno programsko

opremo.

3. NLB kot prodajna mreţa je uporabnik aplikativne rešitve eVita.

Skupina KBC v skupini NLB trenutno nastopa kot finančni investitor, zato ni teţenj

po prilagajanju organizacije informatike načinu dela v KBC.

Informatika NLB Vite je s KBC-jem povezana posredno, prek skupine uporabnikov

aplikacije iGAS. V tej skupini NLB Vita sodeluje tako na nivoju IKT-ja, kot tudi na

poslovnem nivoju. Sodelovanje na poslovnem nivoju je nekaj časa bilo prekinjeno in

je zaradi skupnih interesov v letu 2009 obnovljeno. V prihodnosti so moţne

spremembe odnosov med skupinama NLB in KBC, kar lahko pomembno vpliva na

organizacijo dela.

3.1 Organiziranost sektorja informacijskih sistemov na nivoju

družbe

NLB Vita je po številu zaposlenih in organizacijskih enot majhno podjetje, z

relativno nizko stopnjo formaliziranosti internih procesov. To velja tudi za procese,

povezane z informatiko. Sektor za informatiko v NLB Vita ima direktorja,

namestnika direktorja, dva razvojna inţenirja in enega študenta.

Pri upravljanju sprememb je doseţena zadovoljiva stopnja urejenosti, pri čemer za

osrednjo aplikacijo veljajo postopki skupine uporabnikov KBC iGAS. Za aplikacijo

na prodajnem mestu veljajo postopki NLB d.d., za interne zahteve pa so izdelana



interna navodila. Upoštevana so načela ločitve razvojnega okolja, testnih okolij in

produkcijskega okolja.

Zahteve se izvajajo v klasičnem ciklu: uporabniška zahteva – specifikacija rešitve –

dobava rešitve (notranji ali zunanji razvoj) - uporabniški sprejemni test – prenos v

produkcijo. Prioritete zahtev določi poslovna stran na rednih sestankih razvojnega

kolegija informatike (RIT). Pri procesu upravljanja sprememb ni vzpostavljen

skrbniški sistem v smislu formalno določenih vlog uporabniških in IT skrbnikov

aplikacij ter njihovih namestnikov. Trenutno tudi ni vzpostavljeno polno

nadomeščanje posameznikov za nekatere vloge: predvsem to velja za oba IT

skrbnika aplikacij. To v primeru odpovedi ali daljše odsotnosti predstavlja

pomembno operativno tveganje.

Učinkovitost procesa upravljanja sprememb se je v nekaterih primerih pokazala

izkazala kot pomanjkljiva, razlog pa je bil v pomanjkanju resursov za področje

specifikacije zahtev, razvoja rešitev in uporabniškega testiranja.

Proces upravljanja verzij programske opreme je vključen v proces upravljanja

sprememb. Procesi upravljana incidentov, upravljanja konfiguracije in upravljanja

ravni storitev so le delno formalizirani. Glede na majhno število zaposlenih v

Sektorju informatike in zaradi obremenjenosti z operativnim in razvojnim delom,

bodo za napredek na teh področjih potrebni dodatni notranji ali zunanji kadrovski

resursi.

Znanje zaposlenih v Sektorju informatike je zelo dobro, zagotovljeno je redno

dodatno izobraţevanje in izpopolnjevanje. Glede na poglobljeno poznavanje

platform, razvojnih orodij in vsebine, lahko NLB Vita aktivno in pomembno

prispeva k rezultatom v skupini »KBC iGAS user group« in pri aplikativni podpori

bančnemu okencu NLB. Sodelovanje s skupinama KBC in NLB ter tudi neposredno

s posameznimi članicami skupin je ţe doslej pripomoglo k implementaciji

posameznih rešitev, kar kaţe na priloţnost za prenos dobrih praks tudi v prihodnje.

Med zaposlenimi iz drugih sektorjev je domensko znanje dobro, v prihodnosti pa je

zaţelena nadgradnja znanj s področja projektnega dela in projektnega vodenja.

Trenutno projekte razvoja preteţno vodi Sektor informatike.

Področje aplikativne podpore poslovnim procesom

NLB Vita pri svojem poslovanju uporablja lastne in kupljene aplikativne rešitve.

Nekateri poslovni procesi so podprti z več kot eno aplikacijo (vodenje polic,

obravnavanje škod), kar lahko pomeni neustrezno rešitev pri operativnem izvajanju

postopkov in kompleksnejše poročanje. Nekateri poslovni procesi niso podprti z

nobeno aplikacijo (upravljanje naloţb, planiranje, spremljanje rezultatov druţbe), kar

pomeni na odvisnost od ročnih postopkov in posledično povečano operativno

tveganje napak. V nadaljevanju je podan kratek opis poslovnih aplikacij ki so v

uporabi v NLB Vita.



Tabela 1: Seznam najpomembnejših aplikacij NLB Vita

Aplikacija Dobavitelj Opis

Baza

podatkov

Razv.

Orodje OS

Plat-

forma

eVita Lasten

razvoj

Prodajno mesto

(okence NLB) DB/2 VB, ASP Win Web

iGAS Airas, UK Sistem za vodenje

polic Oracle

Oracle

Designer Win C/S

LISA Lasten

razvoj

Nadgradnja

sistema za vodenje

polic

Oracle Oracle

Developer Win C/S

Vasco Vasco, SLO Glavna knjiga,

Saldakonti Firebird Delphi Win C/S

Taurus Analitika,

SLO

Vodenje finančnih

naloţb Oracle MS VS Win C/S

MS Access

pripomočki

Lasten

razvoj

DD, opominjanje,

kolektivna

zavarovanja.

Access,

Oracle Access Win C/S

MoSes

Towers

Perrin, US,

UK

Sistem za

modeliranje

finančnih tokov

(aktuarstvo)

- - Win C/S

Obličje

Ţe v okviru projekta ustanavljanja zavarovalnice so razvijalci NLB pod vodstvom

NLB Vite izdelali aplikacijo eVita, ki podpira proces prodaje na bančnem okencu

NLB. Ta aplikacija je zgrajena kot integralni del informacijskega sistema NLB in

neposredno uporablja osrednje NLB-jeve baze podatkov na glavnem računalniku

(IBM Mainframe). V obdobju, ko je eVita v produkciji, je NLB razvil novo osrednjo

aplikacijo za bančno okence - NBO. Tej aplikaciji postopoma dodajajo vse

funkcionalnosti, potrebne na okencu, ni pa jasne usmeritve v zvezi z vključitvijo

eVite v ta okvir.

Vzdrţevanje eVite je nekaj časa potekalo v NLB, potem je bilo preneseno na

zunanjega izvajalca (SRC). V prejšnjem letu smo vzdrţevanje prevzeli sami, ker

NLB, oz. SRC nista več zagotavljala ustrezne podpore. Dejstvo, da to aplikacijo

obvladuje NLB Vita, predstavlja pomembno prednost v smislu fleksibilnosti in

hitrosti razvoja. Razvoj poteka usklajeno z NLB.



Zaledje

Osrednja aplikacija za vodenje zavarovanj je iGAS, ki jo v okviru skupine KBC

uporabljajo še štiri druge zavarovalnice. Upravljanje sprememb poteka prek

servisnega centra v KBC, kar zahteva relativno dolge cikluse razvoja. Pri

dosedanjem sodelovanju z dobaviteljem Airas Intersoft Ltd., se je izkazalo, da je

njihova razvojna skupina zelo majhna. Ključni posegi v sistem so največkrat odvisni

od enega samega človeka. To občasno povzroča teţave pri zagotavljanju resursov

Airas Intersoft Ltd, predstavlja pa tudi operativno tveganje.

Aplikacija iGAS ne pokriva nekaterih temeljnih funkcionalnosti, ki so zahtevane v

NLB Viti. Manjkajoče funkcionalnosti so bile pokrite z lastnim razvojem - v začetku

z uporabo MS Excela in MS Accessa, kasneje pa z novo, relativno kompleksno

aplikacijo LISA ki ima tehnične osnove (platforma) enake kot iGAS in predstavlja

neke vrste razširitev osrednje aplikacije. Z razvojem LISE se postopoma opuščajo

stare rešitve v MS Accessu. Glavnina procesov, za katere se še vedno uporablja MS

Access, se nanaša na kolektivne produkte.

Aplikacije iGAS, Lisa in eVita, oz. njihove baze podatkov se lahko med sabo

poljubno povezujejo, ker Sektor informatike razpolaga z ustreznim poznavanjem

platform in podatkovnih modelov. Seveda je potrebno pri tem upoštevati pravne

omejitve in varnostne zahteve.

Vasco, glavna knjiga, je zaključen programski paket po sistemu »plug and play«,

brez prilagoditve uporabniku. Trenutno se nekatere vknjiţbe v to aplikacijo še vedno

vnašajo ročno. Aplikacija vključuje generične vmesnike, ki omogočajo avtomatski

uvoz podatkov. V prihodnosti bomo poskušali to moţnost čim več izkoristiti in

avtomatizirati vse prenose katere lahko. Prav tako pa ni tehničnih ali vsebinskih ovir

za izvoz podatkov iz Vasca v druge baze (npr. v podatkovno skladišče).

Aplikacija MoSes je sistem za modeliranje finančnih tokov, ki ga uporabljajo v

aktuarstvu. Vse zahtevane podatke uvaţajo prek generičnih vmesnikov iz različnih

virov, predvsem iz iGASa.

Ţe hiter pregled tabele daje vpogled v (pre)veliko raznovrstnost aplikativnih rešitev

glede na razvojna orodja in baze podatkov. Pri kupljenih paketih (Vasco in MoSes)

to ne prinaša posebnih teţav, saj je moţna izvedba ustreznih povezav prek

vmesnikov. Večje teţave raznovrstnost povzroča pri lastnem razvoju, saj je za

vzdrţevanje in razvoj potrebno obvladovanje različnih tehnologij, kar je z majhnim

številom zaposlenih informatikov relativno teţko.

Če pogledamo vse aplikacije ki podpirajo posle v zavarovalnici NLB Vita, lahko

rečemo da so določene bolj, določene pa manj povezane med sabo. Nekatere so celo

popolnoma nepovezane z ostalimi aplikacijami in so njihovi izhodi izključno v obliki

papirnih poročil. To povzroči ročno primerjanje in prepisovanje rezultatov ţe pri



rednem delu, še bolj pa zaplete postopke pri izdelavi kompleksnega poročila.V

nadaljevanju je predstavljena shema aplikacijskih in podatkovnih okolij:

Slika 3: Shema aplikacijskih in podatkovnih okolij NLB Vita

VITADEV

VITAPROD

VITATEST IGASTEST

IGASPROD

IGAS

(prod)

IGAS

(test)

LISA

(prod)

LISA

(dev)

LISA

(test)

Production DB server CCLGORA02

Production app.server CSMAVITA02

Test DB server TSMAORA04

Test app. server TTRGVITA01

Read only Read / Write

Database

instance

Application

instance

SIM

UT

ES

TD

EV

PR

OD

Verzija 1. Pripravil V. Lukić, 15.10.2009

NLB Vita: Shema aplikacijskih in podatkovnih okolij

IGASSIMUIGAS

(simu)



Strateški cilji razvoja informatike

Glavni cilj strategije informatike je zagotoviti čim bolj učinkovito podporo

poslovanju, ki bo omogočala doseganje zastavljenih poslovnih ciljev. Učinkovita

podpora poslovanju pomeni zagotavljanje pravočasne in kakovostne informacije ob

doseţeni ustrezni stopnji varnosti in stroškovne učinkovitosti.

Pomembnejši cilji, ki izhajajo iz glavnega cilja so razdeljeni v tri sklope:

1. Vzpostavitev organizacijskih in kadrovskih pogojev za učinkovito

upravljanje, razvoj in uporabo informacijskega sistema. Pri tem se bo NLB

Vita osredotočila na izboljšavo naslednjih procesov: upravljanje zahtev in

sprememb (Request & Change Management), upravljanje incidentov in

problemov (Incident & Problem Management), upravljanje verzij programske

opreme (Release Management), upravljanje konfiguracije (Configuration

Management) in upravljanje ravni storitev (Service Level Managemet).

2. Nadaljnji razvoj aplikativne podpore poslovnim procesom v smeri povečanja

karakteristik kakovosti kot so: funkcionalna in stroškovna učinkovitost,

celovitost, povezljivost, prenosljivost, varnost, zanesljivost, uporabnost,

primernost za vzdrţevanje.

Upravi druţbe bo zagotovljen sistem za zagotavljanje informacij za podporo

odločanju. Sistem bo zgrajen na podlagi obstoječih baz podatkov in na podlagi

podatkovnega skladišča. Podatkovno skladišče bodo poleg uprave uporabljale tudi

druge organizacijske enote, predvsem za izdelavo poročil za zunanje uporabnike.

Spodnja slika prikazuje ciljno shemo aplikacij v NLB Viti, kot izhaja iz zgoraj

opisanih ciljev:



Back-end : support

Front-end

Back-end : operations

eVita

Data warehouseVasco

GL

Business intelligence & Reporting

Asset

Mngmnt

SW

iGAS LISA

Internet

Moses

Slika 4: Ciljna shema uporabniških aplikacij NLB Vita

3.2 Kritična analiza

Finančni del poslovanja je v zavarovalnicah običajno kakovostno podprt tudi z

ustrezno informacijsko podporo, saj se računalniški podpori finančnega dela, kot je

glavna knjiga, od samega začetka razširjene uporabe računalništva posveča velik del

razpoloţljivih strojnih in človeških virov. Problem nastane, ko se poizkušajo

pridobiti nefinančni podatki ali pa analitični finančni podatki, saj računovodski del

računalniške podpore velik del podatkov hrani na sintetičnem in ne analitičnem

nivoju.

Pri iskanju ustrezno organiziranih analitičnih podatkov, tako finančnih kot

nefinančnih, pa v zavarovalnicah velikokrat naletimo na vrsto različnih problemov.

V NLB Vita se navadno najprej srečamo z različnimi, med seboj nepovezanimi

aplikacijami ter celo z različnimi platformami in različnimi izvajalci podpore.

Nepovezanost posameznih delov računalniške podpore poslovanju nas pripelje do

zelo teţavnega zbiranja podatkov z pripravo kvalitetnih in celovitih informacij. Poleg

tega, da imamo podatke zbrane v večjih aplikacijah, je znanje, ki nam omogoča

pridobitev podatkov, bolj ali manj na voljo. Predvsem pri aplikacijah, ki so jih

razvijali in jih vzdrţujejo zunanji izvajalci, je dostop do ţelenih podatkov teţaven,

zanj pa se navadno porabi veliko časa. V trenutku, ko posel obvladujemo z več

aplikacijami, pa nastane še problem nepovezanosti posameznih podatkov med seboj.

Med seboj povezani so samo določeni segmenti posameznih aplikacij. Določene

aplikacije pa so celo popolnoma samostojne.



Posamezne aplikacije zagotavljajo tudi različne časovne okvire vpogledov v

zgodovino podatkov. Transakcijski sistemi navadno ne omogočajo pregleda

podatkov za daljše zgodovinsko obdobje. Problem nastane predvsem v primeru, če se

je tehnologija transakcijskega sistema menjala. Zaradi tega je treba za dostop do

podatkov iz starejšega sistema uporabiti vrsto različnih aplikacij na različnih

platformah ali celo različnih medijih.

Glavni problem je organizirati več ločenih nepovezanih delov računalniške podpore

poslovanju v skupno povezano smiselno celoto. Ker obstoječe aplikacije bolj ali

manj kvalitetno in zadovoljivo pokrivajo potrebe za izvedbo posla, je potrebno

izdelati ustrezno podatkovno skladišče, v katerem bodo na razpolago podatki iz vseh

aplikacij. Te podatke je med seboj treba maksimalno povezati ter zagotoviti ustrezno

programsko opremo, ki bo omogočala izvajanje ţelenih poizvedb in predstavitev ter

izvoz teh podatkov.

Sistemi, ki jih najdemo v naravno razvitih arhitekturah podatkov v praksi, so

preprosto nezadostni za izvajanja nalog podpore informacijskih potreb zaradi

pomanjkanja medsebojne integracije podatkov in zaradi različnih časovnih

intervalov, ki jih le-ti pokrivajo (Inmon, 2002).



4 Prenova procesa poročanja V nadaljevanju sem opisal prototipno rešitev, ki z uporabo tehnologije skladiščenja

podatkov rešuje slabosti prej opisanega stanja. Ta rešitev pokriva proces poročanja

glede realizacije letnega plana. Poročilo sicer nastaja v Sektorju trţenja in prodaje,

in ga uporabljata tako uprava zavarovalnice kot sam sektor trţenja, za redno

spremljanje in analiziranje rezultatov prodaje. Poročilo se izdeluje v večjih različicah

: ločeno po podruţnicah in produktih, samo po poslovalnicah, samo po podruţnicah.

Vsa omenjena poročila predstavljajo pomembno orodje za dolgoročno planiranje

dela zavarovalnice.

Področje prodaje smo sicer izbrali z dobrim razlogom: samo poročanje ni tudi edini

cilj prototipne rešitve. Še en dodaten in nič manj pomemben cilj je, pokazati kar se

da večjemu številu zaposlenih, tako upravi kot ostalimi, vso moč in vse prednosti

uporabe tehnologije podatkovnih skladišč.

4.1 Planiranje in načrtovanje

V tem času ni enotnega mnenje katera razvojni pristop pri gradnji podatkovnih

skladišč je najboljši. Sicer se skoraj vedno porablja eden izmed dveh pristopov:

1. Prvi, od zgoraj navzdol - je povezan z Billom Inmonom, pionirjem na

področju podatkovnega skladiščenja.

2. Drugi, od spodaj navzgor - je povezan z Ralphom Kimballom, visoko

cenjenim strokovnjakom s področja podatkovnega skladiščenja. Njegov

pristop temelji na iterativnem dodajanju posameznih PPS.

Slika 5: Kimballova shema podatkovnih skladišč



Oba pristopa imata prednosti in pomanjkljivosti, mi pa smo glede na naše delovno

okolje prednost vseeno dali le enemu. Ker je planiranje in razvoj celovitega

podatkovnega skladišča izredno obseţna in kompleksna naloga, smo se glede na

razpoloţljive resurse v naši druţbi odločili za pristop »od spodaj navzgor«, ki ga

priporoča Kimball. V skladu s tem pristopom smo razdelili naloge na obvladljive

manjše naloge, katerih rezultate potem zdruţujemo v celoto. Pri načrtovanju razvoja

PS vedno v mislih imamo arhitekturo ki omogoča razvoj celovitega PS, hkrati se

osredotočamo na razvoj posameznih PPS, z izpolnjevanjem manjših, laţje rešljivih

nalog.

Z uporabo pristopa »od spodaj navzgor«, najprej zgradimo posamezna PPS, ki

omogočajo poročanje in analiziranje za natančno določenih poslovnih procesov. PPS

vsebujejo podatke na najniţjem nivoju podrobnosti (atomarne podatke) in po potrebi

še seštete podatke. Zdruţitev posameznih PPS v skupno PS pa realiziramo preko

skupnega “vodila”, ki ni nič drugega, kot uporaba skupnih dimenzij pri razvoju

posameznih zvezdnih diagramov.

Zaradi omejenega obsega, se lahko PPS hitro zgradi po razmeroma nizki ceni s čem

doseţemo hitro vračilo vloţka. Če se PPS izkaţe za uspešno, postopoma dodajamo

nova PPS ali nadgradimo obstoječa. PPS so med seboj povezana preko skupnih

dimenzij in merljivih dejstev, z uporabo katerih uporabniki lahko povprašujejo po

vseh PPS hkrati.

Največje tveganje pri uporabi tega pristopa je neusklajenost med podatki in

posledično morebitne “različne verzije resnice” videne s strani uporabnikov.

Odpravljanje tovrstnih tveganj je moţno le z strogim vzdrţevanjem skladnih skupnih

dimenzij in merljivih dejstev.

Koraki pri načrtovanju dimenzijskega modela

Pri načrtovanju posameznih dimenzijskih shem smo upoštevali priporočila ki jih

navaja Kimball glede zaporedja korakov načrtovanja:

1. Izbira poslovnega procesa ki ga želimo modelirati: pri prvem koraku se, z

upoštevanjem uporabniških zahtev in glede na dostopnost izvornih podatkov,

odločimo kateri poslovni proces bomo obdelali. Prvi dimenzijski model, ki ga

bomo zgradili mora dati odgovore na najbolj pomembna poslovna vprašanja.

Zaradi hitrosti izvedbe je zaţeleno da se najprej implementira PPS ki se polni

iz enega samega vira podatkov.

Izbrani proces, »realizacija letnega plana« je glede na priporočila prvega

koraka zelo primeren. Se polnita iz le dveh različnih podatkovnih virov. Daje

pa odgovore na zelo pomembna vprašanja :

• kakšno je dnevno stanje prodaje zavarovalnih produktov po

podruţnicah glede na letni plan in



• kolikšen procent realizacije letnega plana ima zavarovalnica na

določeni dan

2. Določitev zrna tabele dejstev: drugi korak določa zrno tabele dejstev,

oziroma kakšen nivo podrobnosti podatkov bo dostopen v dimenzijskem

modelu. Priporočljivo je da razvijemo model za najbolj drobno informacijo ki

se pojavlja v poslovnem procesu, ker nam edino ta omogoča največjo moţno

analitično fleksibilnost. Tipična zrna so posamezne transakcije procesa ali

dnevni oz. mesečni posnetki stanj.

Pri izbranemu procesu smo se odločili za zapise na nivoju posameznih

transakcij, z dodatnim beleţenjem mesečnih posnetkov stanj.

3. Določitev dimenzij: v tretjem koraku naredimo opredelitev dimenzij.

Pogosto ţe samo zrno tabele dejstev določi vse potrebne dimenzije.

Najpogosteje uporabljane dimenzije so čas, stranka, usluţbenec, produkt,

prodajno mesto, tip transakcije ipd.

Dimenzije ki jih potrebujemo pri obvladovanju tega procesa so : dan,

agent(komercialist), podruţnica, poslovalnica, banka, zavarovalni produkt, tip

transakcije, valuta, polica, tip police, tip transakcije.

4. Določitev merljivih dejstev: v četrtem koraku izberemo merljiva dejstva.

Dejstva se morajo ujemati z zrnom tabele dejstev. Po navadi so merljiva

dejstva numerične aditivne vrednosti, kot so na primer število prodanih enot,

znesek vplačil, dnevno stanje računa ipd.

Merljivi dejstvi ki sta nujni pri oblikovanju poročil realizacije letnega plana in

stanja odprtih terjatev sta : znesek transakcije in število prodanih enot.



4.2 Tehnična izvedba

Fizična infrastruktura

Produkcijski streţnik CCLGORA02 je virtualno ime streţnikov Oracle gruče. Gručo

sestavljata dva streţnika CSMAORACL02 in CTRGORACL02, ki se fizično

nahajata na naslovu Šmartinska 132, v sistemski sobi. Gruča CCLGORA02 se nahaja

znotraj omreţja NLB (sistem WAN).

Slika 6: Logična shema Windows gruče streţnikov

Tehnična specifikacija streţnikov :

Tip streţnika: Compaq Proliant DL 380 G5

Tip procesorja: 2 x Intel Xeon /3.00GHzDUAL CORE

Delovni spomin: 32GB

Aktivna mreţna kartica: Team (1Gbit in 100Mbit adapter), 100Mbit

(heartbeat)

Diski: Operacijski Sistem uporablja RAID 0+1 – zrcaljenje (2x146 GB).

Podatki se nahajajo na SAN diskovni enoti preko optične povezave

Detajlen prikaz gruče in njenih povezav je prikazan na sliki spodaj :



Slika 7: Fizične povezave streţnikov

Logični podatkovni model

Logični podatkovni model prototipa sestavlja 13 dimenzijskih tabel in dve tabeli

dejstev. Ker so podatki v dimenzijskih tabelah normalizirani, lahko govorimo o

zvezdastem modelu.

Definiranje atributov

Pri oblikovanju podatkovnega modela sem se hkrati posvetil tudi optimizaciji porabe

prostora na trdem disku. Vsa tekstovna polja so bila določena kot tip VARCHAR2,

vsi primarni ključi pa podatkovni tip NUMBER ali DATE. Uporaba numeričnih ali

datumskih podatkovnih tipov za ključe je zelo pomembna, ker se na ta način zmanjša

potreben prostor za shranjevanje podatkov v tabeli dejstev. En primer določanja tipa

podatkov atributov je prikazan na naslednji sliki:



Slika 8: Prikaz atributov na primeru dimenzije VITA_DIM_DAN

Določitev ključev

Pri določanju primarnih ključev sem uporabil model izpeljanih ključev. Primer

izpeljanega ključa je polje ID, ki je primarni ključ dimenzije VITA_DIM_POLICA.

Tukaj bi kot primarni ključ lahko uporabili tudi polje SIFRA_POLICE, vendar bi v

tem primeru podatki zaradi tekstovnega podatkovnega tipa na diskih zasedali

bistveno več prostora.



Slika 9: Prikaz uporabe primarnega ključa

Oblikovanje indeksov

Za pohitritev iskanja podatkov v tabelah dejstev sem uporabil binarne (bitmap)

indekse. Glavne prednosti binarnih indeksov so:

- lahko se uporabljajo pri paralelnih poizvedbah,

- bistveno pospešijo ad-hoc poizvedbe

- so manjši od navadnih B-drevesnih indeksov

Binarni indeksi se v podatkovnih skladiščih obnesejo bolje kot navadni B-drevesni

indeksi. Razlog je njihova narava oz. način implementacije, ki omogoča zelo hitro

iskanje po atributih ki imajo razmeroma majhno število različnih vrednosti, kljub

velikemu številu zapisov v objektu. Na primer, v tabeli ki vsebuje en milijon vrstic,

stolpec ki ima 10 000 različnih vrednosti, je dober kandidat za binarni indeks (Oracle

Database Data Warehousing Guide 10g Release 2 (10.2), 2010).



Slika 10: Primer uporabe binarnih indeksov

Kreiranje materializiranih vpogledov

Ena izmed glavnih prednosti Oracle tehnologij, je moţnost uporabe materializiranih

vpogledov (MV). Njihov glavni namen je pohitritev iskanja in pregledovanja

agregiranih numeričnih podatkov. MV pretvorijo dolgotrajne poizvedbe v končne

rezultate in jih potem hranijo za nadaljnjo uporabo. V podatkovnih skladiščih se ta

pristop obnese predvsem pri prikazovanju agregiranih podatkov tabel dejstev, ko jih



je treba seštevati po najpomembnejših dimenzijah. Podatki shranjeni v MV se lahko

osveţujejo na več načinov :

Avtomatsko (angl. on commit) osveţevanje: ki se izvaja po vsaki potrditvi

spremembe v tabeli dejstev. Ta avtomatizem zagotavlja vsebinsko enakost

podatkov v tabeli dejstev in v materializiranem vpogledu. Slaba lastnost

mehanizma je večja obremenitev sistema zaradi stalnega preračunavanja.

Na zahtevo (angl. on demand): osveţitev vpogledov se izvaja v času ko je

sistem manj obremenjen, npr. ponoči. Pomanjkljivost tega pristopa je ta da je

pri pregledovanju podatkov vedno treba upoštevati razlikovanje vsebine med

tabelo dejstev in materializiranim pogledom nad to tabelo.

En primer ukaza za kreiranje materializiranega vpogleda :

CREATE MATERIALIZED VIEW MV_PLAN_REALIZACIJA_PREMIJA

BUILD IMMEDIATE

REFRESH FORCE

ENABLE QUERY REWRITE AS

SELECT pn.leto_plana,

rl.naziv_podruznice,

rl.naziv_produkta,

rl.realizacija,

pn.plan_nova_premija,

rl.opis_tipa,

rl.sifra_valute,

round(nvl(rl.realizacija,

0) * 100 / nvl(pn.plan_nova_premija,

0),

2) procent

FROM (SELECT po.id id_podruznice,

pr.id id_produkta,

po.naziv_podruznice,

pr.naziv_produkta,

v.sifra_valute,

dn.leto,

tp.opis_tipa,

SUM(re.znesek_vplacila) realizacija

FROM vita_fkt_realizacija re,

vita_dim_produkt pr,

vita_dim_podruznica po,

vita_dim_dan dn,

vita_dim_valuta v,

vita_dim_tip_police tp

WHERE re.id_produkta = pr.id

AND re.id_podruznice = po.id

AND re.id_datum_vplacila = dn.id

AND re.id_tipa_starosti_police = tp.id

AND re.id_valute = v.id

AND tp.opis_skupine = 'REALIZACIJA PLANA'

GROUP BY po.id,

pr.id,

pr.naziv_produkta,

v.sifra_valute,

dn.leto,

tp.opis_tipa,

po.naziv_podruznice) rl,

(SELECT id_podruznice,

id_produkta,

leto_plana,



SUM(plan_stevilo_polic) plan_stevilo_polic,

SUM(plan_portfeljska_premija) plan_portfeljska_premija,

SUM(plan_nova_premija) plan_nova_premija

FROM vita_fkt_plan_prodaje

GROUP BY id_podruznice,

id_produkta,

leto_plana) pn

WHERE rl.id_podruznice = pn.id_podruznice

AND rl.id_produkta = pn.id_produkta

AND rl.leto = pn.leto_plana

ORDER BY rl.naziv_podruznice,

rl.naziv_produkta

/

Primer poizvedbe iz materializiranega vpogleda: SELECT t.leto_plana,

t.naziv_produkta,

t.plan_nova_premija,

t.realizacija,

t.sifra_valute,

t.procent

FROM mv_plan_realizacija_premija t

WHERE t.leto_plana = 2011

AND t.opis_tipa = 'NOVA POLICA'

AND upper(t.naziv_podruznice) = 'MOSTE'

Na spodnji sliki je prikaz poizvedbe v orodju PLSQL Developer:

Slika 11: Primer uporabe materializiranega vpogleda



4.3 Dimenzijski model za spremljanje letnega plana prodaje

Tabele dimenzij

Dimenzija komercialistov VITA_DIM_AGENT:

Vsaka posamezna vrstiva dimenzije predstavlja določenega prodajnega

agenta zavarovalnice. En zapis vsebuje kontaktne in lokacijske podatke

komercialistov: ime in priimek, podruţnico, poslovalnico, datum

pridobivanja licence, datum poteka licence ipd. Vrstica vsebuje tudi atribut

ID_VIRA v katerem hranimo izvorni ključ.

Tabela 2: Dimenzija VITA_DIM_AGENT

NAZIV POLJA TIP PODATKA OPIS

ID NUMBER Šifra agenta v PS

ID_VIRA NUMBER Izvorna šifra agenta

IME VARCHAR2 Ime agenta

PRIIMEK VARCHAR2 Priimek agenta

IME_IN_PRIIMEK VARCHAR2 Ime in priimek agenta

SPOL VARCHAR2 Spol agenta

SIFRA_BANKE VARCHAR2 Šifra banke agenta

BANKA VARCHAR2 Poln naziv banke agenta

PODRUZNICA VARCHAR2 Podružnica agenta

POSLOVALNICA VARCHAR2 Poslovalnica agenta

REGIJA VARCHAR2 Regija agenta

MST_DELAVCA VARCHAR2 Matična številka delavca

DELOVNO_MESTO VARCHAR2 Delovno mesto agenta

LICENCA_OD DATE Datum izdaje licence agenta

LICENCA_DO DATE Datum ukinitve licence agenta

TELEFON VARCHAR2 Tel. številka agenta

FAX VARCHAR2 Številka faksa agenta

GSM1 VARCHAR2 GSM1 številka agenta

GSM2 VARCHAR2 GSM2 številka agenta

EMAIL1 VARCHAR2 Primarna elektronska pošta agenta

EMAIL2 VARCHAR2 Sekundarna elektronska pošta agenta

KREIRAL VARCHAR2 Uporabnik kreiranja zapisa

KREIRANO DATE Datum kreiranja zapisa

SPREMENIL VARCHAR2 Uporabnik spremembe zapisa

SPREMENJENO DATE Datum spreminjanja zapisa



Dimenzijska tabela VITA_DIM_BANKA

Vsebuje osnovne podatke o bankah v skupini ki prek svojih komercialistov in

mreţe poslovalnic trţijo ţivljenjska zavarovanja

Tabela 3: Dimenzija VITA_DIM_BANKA


ID NUMBER Šifra banke v PS

ID_VIRA NUMBER Izvorna šifra banke

NAZIV_BANKE VARCHAR2 Naziv banke

NASLOV VARCHAR2 Naslov banke

REGIJA VARCHAR2 Regija banke

ODPRTA_DNE DATE Datum odprtja banke

ZAPRTA_DNE DATE Datum zaprtja banke

STATUS VARCHAR2 Status banke

TELEFON VARCHAR2 Tel. številka banke

FAX VARCHAR2 Številka faksa banke





Dimenzijska tabela VITA_DIM_DAN

Vsebuje časovne podatke. Posamezna vrstica predstavlja dan v letu ki je

opredeljen z datumom. Dimenzija ima veliko uporabnih opisnih polj kot so:

naziv kvartala, naziv meseca, praznik, vikend ipd. Dimenzija omogoča tudi

vrtanje v globino ker vsebuje hierarhijo atributov : leto, kvartal,mesec,dan.

Tabela 4: Dimenzija VITA_DIM_DAN


ID NUMBER Šifra datuma v PS

DATUM DATE Datum (DD.MM.YYYY)

DATUM_OPIS VARCHAR2 Opis datuma z besedami

DAN NUMBER Naziv dneva

DAN_OPIS VARCHAR2 Opis dneva

DAN_V_TEDNU NUMBER Zap. št. dneva v tednu

DAN_V_MESECU NUMBER Zap. št. dneva v mesecu

DAN_V_LETU NUMBER Zap. št. dneva v letu

ZADNJI_DAN_TEDNA VARCHAR2 Zadnji dan tedna ?

ZADNJI_DAN_MESECA VARCHAR2 Zadnji dan meseca ?

TEDEN_V_MESECU NUMBER Zap. Št. tedna v mesecu

TEDEN_V_LETU NUMBER Zap. Št. tedna v letu

MESEC NUMBER Zap. Št. meseca

MESEC_OPIS VARCHAR2 Naziv meseca

MESEC_V_LETU NUMBER Zap. Št. meseca v letu

MESEC_ZAD_DATUM DATE Zadnji dan v mesecu



MESEC_ST_DEL_DNI NUMBER Št. delovnih dni v mesecu

MESEC_ST_KOL_DNI NUMBER Št. koledarskih dni v mesecu

KVARTAL NUMBER Oznaka kvartala v letu

KVARTAL_OPIS VARCHAR2 Naziv kvartala

KVARTAL_V_LETU NUMBER Zap. Št. kvartala v letu

KVARTAL_ZAC_DATUM DATE Začetni datum kvartala v letu

KVARTAL_KON_DATUM DATE Končni datum kvartala v letu

LETO NUMBER Številka leta

LETO_OPIS VARCHAR2 Naziv leta

DELOVNI_DAN VARCHAR2 Delovni dan ?

PRAZNIK VARCHAR2 Praznik ?

VIKEND VARCHAR2 Vikend ?





Dimenzijska tabela VITA_DIM_FREKVENCA

Ta dimenzija predstavlja pregled osnovnih načinov plačevanja zavarovalnih

premij : redne, mesečne, polletne, letne, enkratne, dodatne ipd.

Tabela 5: Dimenzija VITA_DIM_FREKVENCA


ID NUMBER Šifra frekvence plačevanja v PS

ID_VIRA NUMBER Izvorna šifra frekvence plačevanja

OPIS_FREKVENCE VARCHAR2 Opis frekvence plačevanja





Dimenzijska tabela VITA_DIM_PODRUZNICA

Vsebuje osnovne podatke o podruţnicah v prodajni mreţi skupine NLB.

Tabela 6: Dimenzija VITA_DIM_PODRUZNICA


ID NUMBER Šifra podruţnice v PS

ID_VIRA NUMBER izvorna šifra podruţnice

NAZIV_PODRUZNICE VARCHAR2 Naziv podružnice

IME_VODJE VARCHAR2 Ime vodje podružnice

SPOL_VODJE VARCHAR2 Spol vodje podružnice

NASLOV VARCHAR2 Naslov podružnice

REGIJA VARCHAR2 Regija podružnice

ODPRTA_DNE DATE Datum odprtja podružnice

ZAPRTA_DNE DATE Datum zaprtja podružnice

STATUS VARCHAR2 Status podružnice



TELEFON VARCHAR2 Telefonska št. podružnice

FAX VARCHAR2 Št. faksa podružnice





Dimenzijska tabela VITA_DIM_POLICA

Vsebuje najpomembnejše podatke o zavarovalnih policah : datum sklepanja

ponudbe, osnovno višino zavarovalne premije, trajanje zavarovanja ipd.

Tabela 7: Dimenzija VITA_DIM_POLICA


ID NUMBER Šifra police v PS

ID_VIRA NUMBER Izvorna šifra police

SIFRA_POLICE VARCHAR2 Šifra police (št.pogodbe)

ID_FREKVENCE_POLICE NUMBER Šifra frekvence police v PS

ID_STATUS_POLICE NUMBER Šifra statusa police v PS

DATUM_ZACETKA_ZAVAROVANJA DATE Datum začetka zavarovanja police

DATUM_KONCA_ZAVAROVANJA DATE Datum konca zavarovanja police

DATUM_VNOSA_PONUDBE DATE Datum vnosa zav. Ponudbe

DATUM_PODPISA_PONUDBE DATE Datum podpisa zav. Ponudbe

TRAJANJE_ST_LET NUMBER Število let trajanja ponudbe

TRAJANJE_ST_MESECEV NUMBER Število mesecev trajanja ponudbe

ID_TRENUTNE_POSLOVALNICE NUMBER Šifra sedanje poslovalnice v PS

ID_ZACETNE_POSLOVALNICE NUMBER Šifra začetne poslovalnice v PS

ID_LASTNIKA NUMBER Šifra lastnika police v PS

ZNESEK_PREMIJE NUMBER Znesek premije police

DAN_BREMENITEV NUMBER Zap.št. dneva direktnih bremenitev

ID_STEVILKE_KREDITA NUMBER Šifra kredita police v PS





Dimenzijska tabela VITA_DIM_POSLOVALNICA

Vsebuje osnovne podatke o poslovalnicah v prodajni mreţi skupine NLB.

Tabela 8: Dimenzija VITA_DIM_POSLOVALNICA


ID NUMBER Šifra poslovalnice v PS

ID_VIRA NUMBER izvorna šifra poslovalnice

NAZIV_POSLOVALNICE VARCHAR2 Naziv poslovalnice

IME_VODJE VARCHAR2 Ime vodje poslovalnice

SPOL_VODJE VARCHAR2 Spol vodje poslovalnice

NASLOV VARCHAR2 Naslov poslovalnice

REGIJA VARCHAR2 Regija poslovalnice



ODPRTA_DNE DATE Datum odprtja poslovalnice

ZAPRTA_DNE DATE Datum zaprtja poslovalnice

STATUS VARCHAR2 Status poslovalnice

TELEFON VARCHAR2 Telefonska št. poslovalnice

FAX VARCHAR2 Št. faksa poslovalnice





Dimenzijska tabela VITA_DIM_PRODUKT

Predstavlja ponudbo pregled vseh zavarovalnih produktov. Različni atributi

ki govorijo o tipih zavarovanj omogočajo poizvedovanje glede na riziko

produkta, tip zavarovanja, način plačila zavarovanja ipd.

Tabela 9: Dimenzija VITA_DIM_PRODUKT


ID NUMBER Šifra produkta v PS

ID_VIRA NUMBER Izvorna šifra produkta

TIP_RIZ_PRODUKTA VARCHAR2 Tip rizika produkta

TIP_ZAV_PRODUKTA VARCHAR2 Tip zavarovanja produkta

TIP_PLAC_PRODUKTA VARCHAR2 Tip načina plačila produkta

NAZIV_PRODUKTA VARCHAR2 Naziv produkta

OPIS_PRODUKTA VARCHAR2 Opis produkta

KODA_PRODUKTA VARCHAR2 Šifra produkta

DAT_VELJ_OD DATE Datum začetka prodaje produkta

DAT_VELJ_DO DATE Datum konca prodaje produkta

SIFRA_RACUNA VARCHAR2 Šifra računa produkta

RACUN VARCHAR2 Polna šifra računa produkta

RACUN_OKRA VARCHAR2 Okrajšana šifra računa produkta

OZNAKA_VALUTE VARCHAR2 Šifra valute produkta

OPIS_VALUTE VARCHAR2 Opis valute produkta

IME_VALUTE VARCHAR2 Naziv valute produkta

ENOTA_VALUTE NUMBER Enota valute produkta





Dimenzijska tabela VITA_DIM_STATUS_POLICE

Dimenzija omogoča pregledovanje zavarovalnih poslov glede na status

zavarovalnih polic. Nekatere moţne vrednosti atributa so : aktivna,

prekinjena, prijava škode, delni odkup, odloţeni odkup ipd.

Tabela 10: Dimenzija VITA_DIM_STATUS_POLICE


ID NUMBER Šifra statusa police v PS



ID_VIRA VARCHAR2 Izvorna šifra statusa police

OPIS_STATUSA VARCHAR2 Opis statusa police





Dimenzijska tabela VITA_DIM_TIP_POLICE

Dimenzija govori o različnih tipih polic, ki so razvrščeni v skupine glede na

namen. Npr. skupina »realizacija« vsebuje tipe : nove police in police

portfelja (stare police).

Tabela 11: Dimenzija VITA_DIM_TIP_POLICE


ID NUMBER Šifra tipa police police v PS

OPIS_TIPA VARCHAR2 Izvorna šifra tipa police

OPIS_SKUPINE VARCHAR2 Opis skupine tipa police





Dimenzijska tabela VITA_DIM_TIP_TRANSAKCIJE

Vsebuje seznam vseh moţnih tipov transakcij na polici. Moţne vrednosti

atributov so : vplačilo premije, vračilo premije, izplačilo, obračun premije,

obračun škode ipd.

Tabela 12: Dimenzija VITA_DIM_TIP_TRANSAKCIJE


ID NUMBER Šifra tipa transakcije na polici v PS

OPIS_TRANSAKCIJE VARCHAR2 Izvorna šifra tipa transakcije na polici

OPIS_SKUPINE VARCHAR2 Opis skupine tipa transakcije na polici





Dimenzijska tabela VITA_DIM_VALUTA

Vsebuje detajlne opisne podatke o vseh valutah v katerih se trţijo ţivljenjska

zavarovanja.

Tabela 13: Dimenzija VITA_DIM_VALUTA


ID NUMBER Šifra valute v PS

ID_VIRA NUMBER Izvorna šifra valute

SIFRA_VALUTE VARCHAR2 Naziv valute

OPIS_VALUTE VARCHAR2 Opis valute



FORMAT_VALUTE VARCHAR2 Format valute

TOLERANCA VARCHAR2 Toleranca valute

DENOMINACIJA VARCHAR2 Denominacija valute

UNIV_SIFRA_VALUTE VARCHAR2 Univerzalna šifra valute

ZAOKROZANJE VARCHAR2 Zaokrožanje valute





Tabele dejstev

Tabela dejstev vsebuje podatke o vsaki opravljeni transakciji na najbolj drobnem

nivoju. To omogoča poizvedovanje in seštevanje podatkov z uporabo večjega števila

različnih kriterijev : po komercialistih, po produktih, podruţnicah, bankah ipd.

Po navadi se do podatkov dostopa ločeno, za vsako polica posebej. Zaradi tega je

dostop hiter. Nasprotno temu se v podatkovnem skladišču izvajajo poizvedbe, ki

zahtevajo seštete podatke,in te se morajo izvesti čim hitreje. Pristop iz transakcijskih

sistemov se tu ne obnese. Pri poizvedbah tega tipa prihaja do velikega števila

povezovanj med tabelami, kar bistveno vpliva na daljši čas izvajanja.

Glavni razlog za uporabo denormalizacije v metodologiji podatkovnega skladiščenja

predstavlja zmanjševanje števila povezav med tabelami. Denormalizacija se izvaja

tako v dimenzijah kot tudi v tabelah dejstev. V bistvu gre za kompromis med :

časom izvajanja poizvedb in

zasedenostjo prostora na diskih.

Transakcijski sistemi, ki so običajno normalizirani do tretje normalne forme,

zagotavljajo minimalno redundanco podatkov in preprečujejo nepravilnosti pri

posodabljanju podatkov, in vse to v zameno za daljši čas izvajanja poizvedb v

primerjavi s podatkovnim skladiščem, ki pa hitrejše poizvedbe zagotavlja le s

povečano porabo diskovnega prostora.

Tabele dejstev so zaradi beleţenja zgodovinskih poslovnih dogodkov, posledično

največji porabniki diskovnega prostora. V praksi obstaja in se uporablja več načinov

zmanjševanja porabe diskovnega prostora. Tekom priprave logičnega podatkovnega

modela je dobro imeti v mislih da prihranek pri definiranju posameznega polja v

tabeli dejstev, lahko pomeni finančni prihranek zaradi manjših potreb po diskovnem

prostoru celotnega sistema. Rezultat optimizacije so izredni finančni prihranki v

primerih kjer so tabele dejstev lahko zelo velike.

Pri načrtovanju logičnega podatkovnega modela sem ţelel doseči to, da bi se v tabeli

dejstev popolnoma izognil tekstovnim podatkovnim tipom. Zato sem za vsa polja ki



predstavljajo reference na dimenzije ali mere, uporabljal datumski ali numerični tip

podatkov.

Tabela dejstev VITA_FKT_REALIZACIJA

Omogoča spremljanje letnega plana prodaje ker vsebuje mero »znesek

vplačila« ki na najbolj atomarnem nivoju govori o vseh transakcijah na polici.

Ostali atributi – ključi oz. povezave do dimenzijskih tabel, omogočajo opisno

predstavljanje vseh transakcij in poizvedovanje in seštevanje po različnih

kriterijih.

Tabela 14: Tabela dejstev VITA_FKT_REALIZACIJA


ID NUMBER Šifra zapisa transakcije v PS

ID_VIRA NUMBER Izvorna šifra transakcije

ID_TIPA_TRANSAKCIJE NUMBER Šifra tipa transakcije v PS

ID_TIPA_STAROSTI_POLICE NUMBER Šifra tipa starosti police v PS

ID_BANKE NUMBER Šifra banke v PS

ID_PODRUZNICE NUMBER Šifra podružnice v PS

ID_POSLOVALNICE NUMBER Šifra poslovalnice v PS

ID_AGENTA NUMBER Šifra agenta v PS

ID_POLICE NUMBER Šifra police v PS

ID_PRODUKTA NUMBER Šifra produkta v PS

ID_DATUM_VPLACILA NUMBER Šifra datuma v PS

ZNESEK_VPLACILA NUMBER Znesek transakcije police





ID_VALUTE NUMBER Šifra valute v PS

Tabela dejstev VITA_FKT_PLAN_PRODAJE

Predstavlja letni plan prodaje po zavarovalnih produktih, poslovalnicah in

podruţnicah. Mere so: število novo sklenjenih polic, premija novih polic in

premija portfelja.

Tabela 15: Tabela dejstev VITA_FKT_PLAN_PRODAJE


ID NUMBER Šifra zapisa v PS

ID_PODRUZNICE NUMBER Šifra podruţnice v PS

ID_POSLOVALNICE NUMBER Šifra poslovalnice v PS

ID_PRODUKTA NUMBER Šifra produkta v PS

LETO_PLANA NUMBER Leto plana prodaje

PLAN_STEVILO_POLIC NUMBER Plan števila novih polic

PLAN_PORTFELJ_PREMIJA NUMBER Plan portfeljske premije

PLAN_NOVA_PREMIJA NUMBER Plan premije novih polic







ID_VALUTE NUMBER Šifra valute v PS

Naslednja slika podaja celoten fizični podatkovni model za spremljanje letnega plana

prodaje ţivljenjskih zavarovanj, po produktih in podruţnicah poslovne mreţe. Tabela

dejstev VITA_FKT_REALIZACIJA vsebuje devet tujih ključev preko katerih je

povezana primarnimi ključi ostalih dimenzijskih tabel.



Slika 12: Podatkovni model: realizacija letnega plana prodaje zavarovanj



Slika 13: Podatkovni model: letni plan prodaje zavarovanj

Zgornja slika predstavlja del dimenzijskega podatkovnega modela ki govori o

letnem planu prodaje ţivljenjskih zavarovanj, po produktih in podruţnicah poslovne

mreţe. Tabela dejstev VITA_FKT_REALIZACIJA v povezavi s tem modelom, daje

odgovore na vprašanja o procentu realizacije letnega plana, po posameznih

podruţnicah in zavarovalnih produktih.

Odgovor na vprašanje, kakšna je npr. realizacija letnega plana v podruţnicah

Ljubljana-center in Moste, lahko dobimo z naslednjo SQL poizvedbo :



SELECT rl.naziv_produkta "Naziv produkta",

rl.realizacija "Realizacija premije",

pn.plan_nova_premija "Plan premije",

rl.sifra_valute "Valuta",

round(nvl(rl.realizacija,

0) * 100 / nvl(pn.plan_nova_premija,

0),

2) "% realizacije"

FROM (SELECT po.id id_podruznice,

pr.id id_produkta,

po.naziv_podruznice,

pr.naziv_produkta,

v.sifra_valute,

SUM(re.znesek_vplacila) realizacija

FROM vita_fkt_realizacija re,

vita_dim_produkt pr,

vita_dim_podruznica po,

vita_dim_dan dn,

vita_dim_valuta v,

vita_dim_tip_police tp

WHERE re.id_produkta = pr.id

AND re.id_podruznice = po.id

AND re.id_datum_vplacila = dn.id

AND re.id_tipa_starosti_police = tp.id

AND re.id_valute = v.id

AND tp.id = 2

AND dn.datum BETWEEN '01.01.2011' AND '31.12.2011'

AND upper(po.naziv_podruznice) IN ('MOSTE', 'LJUBLJANA - CENTER')

GROUP BY po.id,

pr.id,

pr.naziv_produkta,

v.sifra_valute,

po.naziv_podruznice) rl,

(SELECT id_podruznice,

id_produkta,

SUM(plan_stevilo_polic) plan_stevilo_polic,

SUM(plan_portfeljska_premija) plan_portfeljska_premija,

SUM(plan_nova_premija) plan_nova_premija

FROM vita_fkt_plan_prodaje

WHERE leto_plana = 2011

GROUP BY id_podruznice,

id_produkta) pn

WHERE rl.id_podruznice = pn.id_podruznice

AND rl.id_produkta = pn.id_produkta

ORDER BY rl.naziv_produkta

Rezultat poizvedbe oziroma znesek in procent realizacije letnega plana za dve izbrani

podruţnici je prikazan v spodnjih tabelah :

Tabela 16: Realizacija letnega plana podruţnice Ljubljana - Center

Naziv produkta Realizacija premije Plan premije Valuta % realizacije

NLB Naloţba Vita Multi 607.375,00 1.293.016,23 EUR 46,97

NLB Varčevanje Vita plus 6.500,00 197.461,04 EUR 3,29

NLB Varčevanje Vita plus -enkratno 28.615,00 258.123,26 EUR 11,09

NLB Vita Razigrana z zajamčenim donosom 21.848,98 46.122,39 EUR 47,37

NLB Vita Senior 4.600,00 98.034,71 EUR 4,69

Ţivljenjsko zavarovanje kreditojemalcev 1.602,58 73.228,00 EUR 2,19



Tabela 17: Realizacija letnega plana podruţnice Moste

Naziv produkta Realizacija premije Plan premije Valuta % realizacije

NLB Naloţba Vita Multi 216.801,00 866.703,51 EUR 25,01

NLB Varčevanje Vita plus 5.000,00 132.357,53 EUR 3,78

NLB Varčevanje Vita plus -enkratno 8.000,00 173.018,76 EUR 4,62

NLB Vita Razigrana z zajamčenim donosom 1.355,00 30.915,16 EUR 4,38

NLB Vita Senior 5.400,00 65.712,17 EUR 8,22

Ţivljenjsko zavarovanje kreditojemalcev 3.810,76 57.302,78 EUR 6,65



5 Zaključki

Za pravilno odločanje vedno potrebujemo pravočasno in natančno informacijo, ki

nam prinaša prednost, zasluţek in napredek. Vsaka organizacija ima ogromno

pomembnih in nepomembnih podatkov, iz katerih je treba izločiti le informacije, s

katerimi se bomo hitreje in pametneje odločali. Če ţelimo te podatke pretvoriti v

informacije, jih moramo organizirati na tak način, ki to pretvorbo omogoča kar se da

hitreje. Eden izmed takšnih načinov je prav gotovo tehnologija skladiščenja

podatkov.

Tehnologija podatkovnih skladišč omogoča hiter dostop do podatkov in hitre

poizvedbe. Uporaba orodij OLAP pa, uporabnikom omogoča samostojno delo brez

pomoči programerjev. Uporabnik si lahko sam sestavlja določene poizvedbe in

poročila, jih ureja in spreminja po lastnih ţeljah in potrebah. To kar dosegamo s

takšnim pristopom so: krajši čas in niţji stroški izdelave poročil, posledično pa večja

učinkovitost vseh zaposlenih. Pravilna uporaba tehnologije in orodij poslovne

inteligence, pri prenovi poslovnih procesov ima veliko moţnosti za uspeh.

Kako bomo modelirali podatkovno skladišče, je odvisno od posamezne organizacije

in njenih delovnih procesov. Magične univerzalne rešitve ni. Pravilna pretvorba

poslovnih procesov v primeren podatkovni model je eden izmed ključnih elementov

uspešne postavitve in kasnejše nadgradnje podatkovnega skladišča. Če ţelimo

izdelati kakovosten podatkovni model moramo upoštevati dobre prakse in pravila,

hkrati pa podrobno poznati vsak posamezen poslovni proces ki ga obvladujemo.

Končni podatkovni in dimenzijski model morata biti razumljiva razvijalcu in

uporabniku. Pri načrtovanju se moramo drţati standardov imenovanja objektov in

njihovih delov, katerih nazivi morajo biti jasni in razumljivi. Slab dimenzijski model

je pogosto razlog propada podobnih projektov. Slaba analiza delovnih procesov, in

posledično slab dizajn podatkovnega modela, kot rezultat dajeta neuporaben sistem

katerem uporabniki ne zaupajo in ga potem niti ne uporabljajo.

Organizacije se prenove poslovnih procesov običajno lotevajo s projektnim

pristopom, z jasno določenimi cilji, finančnimi in časovnimi omejitvami. Tako smo

tudi v NLB Viti pri gradnji informacijskega sistema PS uporabili projektni pristop.

PS je za zavarovalnico bil in še vedno je strateški projekt. Traja s prekinitvami ţe več

kot leto dni in je pri njem sodelovalo okrog osem ljudi različnih profilov in znanj.

Pilot projekt je zaključen in objekti projekta bodo v kratkem preneseni v produkcijo.

Je bil pilot projekt uspešen ? Po mojem mnenju zagotovo. Prinesel je novo

tehnologijo, nova znanja, nova orodja ki jih do sedaj še nismo uporabljali. Ta

tehnologija nam bo omogočala boljši pregled nad vsemi zavarovalniškimi storitvami

na zanesljiv in natančen način. Sodobna zavarovalnica, kot je NLB Vita, ima v svoji

ponudbi veliko storitev, namenjenih tako fizičnim kot pravnim osebam. Tako široka

paleta ponudbe pa s sabo prinaša tudi izredno veliko rešitev, razvitih na različnih

platformah. Dnevno zbiranje različnih poslovnih podatkov in prenos teh podatkov v

enoten sistem je izredno zahtevno opravilo. Zaradi zunanjih zahtev smo začeli s to



nalogo, zaradi nas samih pa smo se odločili za sodobno arhitekturo podatkovnih

skladišč.

Sedaj, ko je pilot projekt zaključen, lahko povem, da smo naredili zelo kvaliteten

podatkovni in dimenzijski model, ki se ga brez teţav bo dalo nadgrajevati. Zgradili

smo zanesljiv in stabilen informacijski sistem z vsemi potrebnimi kontrolnimi

mehanizmi. Pri tem smo še bistveno skrajšali čas zbiranja podatkov in racionalizirali

celoten proces.

Osnovni namen projekta je bil izpolnjen. Na enem mestu so zbrane vse informacije o

transakcijah ki govorijo o realizaciji plana prodaje. Analiza teh informacij je hitra in

zanesljiva zaradi uporabljene OLAP tehnologije. Za zavarovalnice in ostale finančne

druţbe velja, da pravočasne in popolne informacije vplivajo na njihovo poslovanje in

poslovni uspeh. Zato je informacijski sistem, v katerem se ustvarjajo kakovostne in

zanesljive informacije, ogromnega pomena, ker zavarovalnici zagotavlja strateško in

konkurenčno prednost na trţišču.

5.1 Učinki in dodana vrednost

Ţe v pričetku smo projekt razdelili na dve fazi, saj smo bili zaradi ostalih delovnih

nalog zelo časovno omejeni in ni bilo pogojev, da bi v kratkem roku zgradili popolno

podatkovno skladišče.

Edini pogoji, ki so bili postavljeni ţe v začetku projekta so izrecno zahtevali, da se

postavi takšna struktura projekta, ki bo omogočala enostavno nadgradnjo in

enostavno vključitev dodatnih podatkov v skladišče.

Vsi sektorji v zavarovalnici, predvsem pa Sektor spremljave zavarovanj in Sektor

trţenja in prodaje so dobili nalogo izdelati seznam ţelja in izdelati študijo moţnosti

uporabe podatkovnega skladišča za podporo poslovnim odločitvam.

Nekatere postavke pomembne za poslovne odločitve zavarovalnice, ki naj bi jih

podatkovno skladišče v prihodnosti omogočalo :

Gibanje portfelja - uspešnost po tipih zavarovanj, doseganje plana, gibanje

odkupov, povprečje trajanja zavarovanja ipd.

Poročilo o nastanku velike izpostavljenosti posamezne zavarovalne vrste in

datum nastanka in datum najvišje izpostavljenosti v obdobju

Statistike z izkazi uspeha, stanja komitentov, realizacija/plan in za preverjanje

portfelja zavarovalnice glede na kriterije Zakona o zavarovalništvu.

Ugotavljanje uspešnosti posameznega tipa zavarovanih storitev



Ugotavljanje uspešnosti posameznih delov poslovne mreţe

Prihodki zavarovalnice od posameznega komitenta po posameznih postavkah

(moţnost primerjave med obdobji, podjetji, panogami, moţnost spreminjanja

predpostavk (pogojev) in izvajanja simulacij

5.2 Pogoji za nadaljevanje projekta

Enako kot pri vseh projektih tega obsega, odločitev za proces uvajanja podatkovnega

skladišča v podjetju mora biti strateška odločitev najvišjega vodstva v podjetju. Če

ţelimo zagotoviti uspešnost projekta, se izgradnje podatkovnega skladišča moramo

lotiti kot najpomembnejše strateške naloge, ki ga podpira vrhnji menedţment. Hkrati

se moramo zavedati da gre za dolgotrajni proces.

Ključnega pomena pri izgradnji podatkovnega skladišča je da ţe na začetku natančno

določimo cilje in obseg dela. Potem je treba ustrezno prilagoditi plan dela sektorja

informatike tem ciljem. Podatkovno skladišče bo sluţilo svojemu namenu le, če bodo

izpolnjena pričakovanja uporabnikov in doseţeni cilji, ki smo si jih zastavili.

5.3 Možnosti nadaljnjega razvoja

Z realizacijo prototipa podatkovnega skladišča je opravljeno veliko dela, vendar je to

v primerjavi s pravim skladiščem podatkov, ki bo podpiralo vse poslovne procese na

področju odločanja in celovit sistem poročanja, šele začetek. Priprava in vzdrţevanje

nekaterih poročil sta res poenostavljena, vendar je to šele prvi korak na dolgi poti

uvajanja centralnega sistema poročanja za celotno druţbo.

Prototipna izdelava področnega podatkovnega skladišča je pokazala, da je v relativno

kratkem času mogoče ustvariti konkreten, uporaben in delujoč sistem. Izkušnje in

znanja ki smo jih pridobili v tem procesu nam bodo pomagali pri razvoju nadaljnjih

področnih podatkovnih skladišč.



Literatura in viri

Knjige:

Feuerstein Steven, Oracle PL/SQL Programming, 2005

Hobbs Lilian, Hillson Susan, Lawande Shilpa , Oracle9iR2 Data Warehousing, 2003

Inmon Wiliam, Building the data warehouse Third edition, 2002

Kimball Ralph: The Data Warehouse Lifecycle Toolkit Second Edition, 2002

Loney Kevin, Oracle Database 10g The Complete Reference, 2004

Scalzo Bert, Oracle DBA Guide to Data Warehousing and Star Schemas, 2003

Wang John, Montclair State University, USA, Encyclopedia of Data Warehousing

and Mining, 2006

Spletne strani:

Kimball Ralph, A Dimensional Modeling Manifesto,

http://www.kimballgroup.com/html/articles_search/articles1997/9708d15.html,

marec 2011

Oracle Metalink,

https://support.oracle.com/CSP/ui/flash.html, 2011

Slovar informatike,

http://www.islovar.org/iskanje_enostavno.asp, 2011

Oraccle Database Documentation Library

http://www.oracle.com/pls/db102/homepage, marec 2011

Oracle Database PL/SQL User's Guide and Reference 10g Release 2 (10.2)

http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/toc.htm, marec

2011

Oracle Database SQL Reference 10g Release 2 (10.2)

http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/toc.htm, marec

2011

Oracle Database Data Warehousing Guide 10g Release 2 (10.2)

http://download.oracle.com/docs/cd/B19306_01/server.102/b14223.pdf, marec 2011

Oracle Database Performance Tuning Guide 10g Release 2 (10.2)



http://download.oracle.com/docs/cd/B19306_01/server.102/b14211.pdf, marec 2011

OLAP DML Reference

http://download.oracle.com/docs/cd/B19306_01/olap.102/b14346.pdf, marec 2011

OLAP Application Developer's Guide

http://download.oracle.com/docs/cd/B19306_01/olap.102/b14349.pdf, marec 2011

V. R. Grupta, An Introduction to Data Warehousing,

http://system-services.com/dwintro.asp, marec 2011

Wikipedia, Business_intelligence,

http://en.wikipedia.org/wiki/Business_intelligence, marec 2011



Priloge

Priloga 1: Programski paket za polnjenje nekaterih dimenzijskih tabel…..………52

Kazalo slik

Slika 1: Proces skladiščenja podatkov .................................................................... 7

Slika 2: Osnovne komponente podatkovnega skladišča ....................................... 11

Slika 3: Shema aplikacijskih in podatkovnih okolij NLB Vita ............................ 18

Slika 4: Ciljna shema uporabniških aplikacij NLB Vita ....................................... 20

Slika 5: Kimballova shema podatkovnih skladišč ................................................ 22

Slika 6: Logična shema Windows gruče streţnikov ............................................. 25

Slika 7: Fizične povezave streţnikov .................................................................... 26

Slika 8: Prikaz atributov na primeru dimenzije VITA_DIM_DAN ..................... 27

Slika 9: Prikaz uporabe primarnega ključa ........................................................... 28

Slika 10: Primer uporabe binarnih indeksov ........................................................... 29

Slika 11: Primer uporabe materializiranega vpogleda ............................................ 31

Slika 12: Podatkovni model: realizacija letnega plana prodaje zavarovanj ............ 41

Slika 13: Podatkovni model: letni plan prodaje zavarovanj ................................... 42

Kazalo tabel

Tabela 1: Seznam najpomembnejših aplikacij NLB Vita .................................... 16

Tabela 2: Dimenzija VITA_DIM_AGENT ......................................................... 32

Tabela 3: Dimenzija VITA_DIM_BANKA ........................................................ 33

Tabela 4: Dimenzija VITA_DIM_DAN .............................................................. 33

Tabela 5: Dimenzija VITA_DIM_FREKVENCA .............................................. 34

Tabela 6: Dimenzija VITA_DIM_PODRUZNICA ............................................. 34

Tabela 7: Dimenzija VITA_DIM_POLICA ........................................................ 35

Tabela 8: Dimenzija VITA_DIM_POSLOVALNICA ........................................ 35

Tabela 9: Dimenzija VITA_DIM_PRODUKT .................................................... 36

Tabela 10: Dimenzija VITA_DIM_STATUS_POLICE ....................................... 36

Tabela 11: Dimenzija VITA_DIM_TIP_POLICE ................................................ 37

Tabela 12: Dimenzija VITA_DIM_TIP_TRANSAKCIJE .................................... 37

Tabela 13: Dimenzija VITA_DIM_VALUTA ...................................................... 37

Tabela 14: Tabela dejstev VITA_FKT_REALIZACIJA ....................................... 39

Tabela 15: Tabela dejstev VITA_FKT_PLAN_PRODAJE .................................. 39

Tabela 16: Realizacija letnega plana podruţnice Ljubljana - Center .................... 43

Tabela 17: Realizacija letnega plana podruţnice Moste ........................................ 44



Pojmovnik

Legacy systems podedovani sistemi

On Line Analytical Processing tehnologija za sprotno analizo podatkov

Business intelligence (BI) Poslovna inteligenca

Feedback povratna informacija

Decision support systems (DSS) sistemi za podporo odločanju (SPO)

Online Transaction Procesing (OLTP) transakcijski sistem

Fully additive measure seštevljive mere

Drill-down vrtanje v globino

Dimensional model dimenzijski model

Fact table tabela dejstev

Slowly changing dimension počasi se spreminjajoča dimenzija

Unique key edinstveni ključ

Extract, Transformation, Load pridobi, pretvori, prenesi

On-Line Analytical Processing sprotna analiza podatkov),

Podatkovna arhitektura data arhitecture

Data Mining podatkovno rudarjenje

Request & Change Management upravljanje zahtev in sprememb

Incident & Problem Management upravljanje incidentov in problemov

Release Management upravljanje verzij programske opreme

Configuration Management upravljanje konfiguracije

Service Level Managemet upravljanje ravni storitev

Kratice in akronimi

CIF: Corporate Information Factory: Inmon-ova arhitektura podatkovnega

skladišča

ER: Entity – Relationship: entitetno – relacijski model

ETL: Extract, Transform, Load: zajemanje, transformacija in polnjenja

podatkov v podatkovno skladišče

OLAP: Online Analytic Processing: sprotna analitična obdelava podatkov

OLTP: Online Transaction Processing: sistem za sprotno obdelavo transakcij

DW: Data Warehouse: podatkovno skladišče

DM: Data Mart: področno podatkovno skladišče

GUI: graphical user interface

SQL: Structured Query Language: strukturiran povpraševalni jezik za delo s

podatkovnimi bazami



Priloga 1: Programski paket za polnjenje nekaterih dimenzijskih tabel

CREATE OR REPLACE PACKAGE nlb_dw_pkg IS

PROCEDURE vrni_oracle_napako(p_status IN OUT VARCHAR2,

p_sporocilo IN OUT VARCHAR2);

FUNCTION vrni_id_napake(p_opis_napake IN vita_dw_napake.opis_napake%TYPE)

RETURN NUMBER;

FUNCTION zapisi_napako(p_tabela VARCHAR2,

p_polnjenje_id NUMBER,

p_program VARCHAR2,

p_opis_napake VARCHAR2,

p_atribut VARCHAR2) RETURN NUMBER;

PROCEDURE polni_vita_dim_dan(p_id_obdelave IN NUMBER,

p_status IN OUT VARCHAR2);

PROCEDURE polni_vita_dim_produkt(p_id_obdelave IN NUMBER,

p_status IN OUT VARCHAR2,


PROCEDURE polni_vita_dim_agent(p_id_obdelave IN NUMBER,



END nlb_dw_pkg;

/

CREATE OR REPLACE PACKAGE BODY nlb_dw_pkg IS

--------------------------------------------------------------------------

--------------------------

-- 01-FEBRUAR-2011 V1.0-1 Vajo Lukic

--------------------------------------------------------------------------

--------------------------

c_pkg CONSTANT VARCHAR2(50) := 'nlb_dw_pkg.';

c_status_izpad CONSTANT VARCHAR2(10) := 'IZPAD';

c_status_uspeh CONSTANT VARCHAR2(10) := 'USPEH';

c_status_napaka CONSTANT VARCHAR2(10) := 'NAPAKA';

c_start_date CONSTANT DATE := '01.01.2003'; -- začetni datum

polnjenja

--------------------------------------------------------------------------

--------------------------

-- Namen procedure : vrača opis šteila obdelanih vrstic obdelave

--------------------------------------------------------------------------

--------------------------

FUNCTION st_obd_vrstic_opis(p_st_obd_vrstic IN NUMBER)

RETURN VARCHAR2 IS

BEGIN

RETURN to_char(p_st_obd_vrstic) || ' obdelanih vrstic.';

END;

--------------------------------------------------------------------------

--------------------------

-- Namen procedure : vrača status in opis Oracle napake

--------------------------------------------------------------------------

--------------------------

PROCEDURE vrni_oracle_napako(p_status IN OUT VARCHAR2,

p_sporocilo IN OUT VARCHAR2) IS

c_proc VARCHAR2(30) := 'vrni_oracle_napako';

BEGIN

p_status := c_status_izpad;

p_sporocilo := p_sporocilo || SQLERRM;

END;

--------------------------------------------------------------------------



--------------------------

-- Namen procedure : Funkcija vrača vita_dw_napake.id za podani opis

napake. Če opis napake

-- ne obstaja, funkcija doda zapis v tabelo opisov napak vita_dw_napake in

vrne id novega zapisa.

--------------------------------------------------------------------------

--------------------------

FUNCTION vrni_id_napake(p_opis_napake IN vita_dw_napake.opis_napake%TYPE)

RETURN NUMBER IS

c_proc VARCHAR2(30) := 'vrni_id_napake';

v_id_napake NUMBER;

BEGIN

BEGIN

SELECT id

INTO v_id_napake

FROM vita_dw_napake

WHERE opis_napake = upper(p_opis_napake);

EXCEPTION

WHEN no_data_found THEN

SELECT vita_dw_napake_sq.nextval INTO v_id_napake FROM dual;

INSERT INTO vita_dw_napake

(id,

opis_napake)

VALUES

(v_id_napake,

upper(p_opis_napake));

END;

RETURN v_id_napake;

END;

--------------------------------------------------------------------------

--------------------------

-- Namen procedure : Funkcija zapise napako v tabelo napak polnjenja in

vrne ID napake.

--------------------------------------------------------------------------

--------------------------

FUNCTION zapisi_napako(p_tabela VARCHAR2,

p_polnjenje_id NUMBER,

p_program VARCHAR2,

p_opis_napake VARCHAR2,

p_atribut VARCHAR2) RETURN NUMBER IS

c_proc VARCHAR2(30) := 'zapisi_napako';

v_id_napake NUMBER;

v_id_opisa NUMBER;

BEGIN

SELECT vita_dw_napake_polnjenja_sq.nextval INTO v_id_napake FROM dual;

v_id_opisa := vrni_id_napake(p_opis_napake);

INSERT INTO vita_dw_napake_polnjenja

(id,

id_opisa_napake,

id_obdelave,

ime_tabele,

ime_polja,

ime_obdelave)

VALUES

(v_id_napake,

v_id_opisa,

p_polnjenje_id,

p_tabela,

upper(p_atribut),

p_program);

RETURN(v_id_napake);

END;

--------------------------------------------------------------------------



--------------------------

--

--------------------------------------------------------------------------

--------------------------

PROCEDURE polni_vita_dim_dan(p_id_obdelave IN NUMBER,

p_status IN OUT VARCHAR2) IS

v_start_date DATE;

v_end_date DATE; -- končni datum polnjenja

v_st_vrstic NUMBER := 0;

c_proc VARCHAR2(30) := 'polni_vita_dim_dan';

BEGIN

v_start_date := c_start_date;

v_end_date := add_months(v_start_date,

240) - 1; -- (+ 20 let)

WHILE v_start_date <= v_end_date

LOOP

INSERT INTO vita_dim_dan

SELECT vita_dim_dan_sq.nextval id,

v_start_date datum,

to_char(v_start_date,

'dd. ') || TRIM(to_char(v_start_date,

'Month')) ||


', YYYY') datum_opis,

to_number(to_char(v_start_date,

'DD')) dan,

TRIM(to_char(v_start_date,

'Day')) dan_opis,


'D')) dan_v_tednu,


'DD')) dan_v_mesecu,


'DDD')) dan_v_letu,

CASE

WHEN to_number(to_char(v_start_date,

'D')) IN (7) THEN

'DA'

ELSE

'NE'

END zadnji_dan_tedna,

CASE

WHEN trunc(v_start_date) = last_day(trunc(v_start_date))

THEN

'DA'

ELSE

'NE'

END zadnji_dan_meseca,


'W')) teden_v_mesecu,


'WW')) teden_v_letu,


'MM')) mesec,

TRIM(to_char(v_start_date,

'Month')) mesec_opis,


'mm')) mesec_v_letu,

last_day(v_start_date) mesec_zad_datum,

NULL mesec_st_del_dni,

to_number(to_char(last_day(v_start_date),

'dd')) mesec_st_kol_dni,

to_number(TRIM(to_char(v_start_date,



'Q'))) kvartal,

CASE

WHEN TRIM(to_char(v_start_date,

'Q')) = '1' THEN

'Januar - Marec'


'Q')) = '2' THEN

'April - Junij'


'Q')) = '3' THEN

'Julij - September'


'Q')) = '4' THEN

'Oktober - December'

END kvartal_opis,


'Q')) kvartal_v_letu,

CASE


'Q')) = '1' THEN

to_date('1.1.' || to_char(v_start_date,

'yyyy'),

'dd.mm.yyyy')


'Q')) = '2' THEN


'yyyy'),

'dd.mm.yyyy')


'Q')) = '3' THEN


'yyyy'),

'dd.mm.yyyy')


'Q')) = '4' THEN


'yyyy'),

'dd.mm.yyyy')

END kvartal_zac_datum,

CASE


'Q')) = '1' THEN


'yyyy'),

'dd.mm.yyyy')


'Q')) = '2' THEN


'yyyy'),

'dd.mm.yyyy')


'Q')) = '3' THEN


'yyyy'),

'dd.mm.yyyy')


'Q')) = '4' THEN


'yyyy'),

'dd.mm.yyyy')

END kvartal_kon_datum,


'YYYY')) leto,




'YYYY') leto_opis,

CASE


'D')) IN (6,

7) THEN

'NE'

ELSE

'DA'

END delovni_dan,

CASE

WHEN to_char(v_start_date,

'dd.mm') IN ('01.01',

'02.01',

'08.02',

'27.04',

'01.05',

'02.05',

'25.06',

'15.08',

'31.10',

'01.11',

'25.12',

'26.12') THEN

'DA'

ELSE

'NE'

END praznik,

CASE


'D')) IN (6,

7) THEN

'DA'

ELSE

'NE'

END vikend,

USER kreiral,

SYSDATE kreirano,

NULL spremenil,

NULL spremenjeno

FROM dual;

v_start_date := v_start_date + 1;

v_st_vrstic := v_st_vrstic + 1;

END LOOP;

UPDATE vita_dim_dan a

SET mesec_st_del_dni =

(SELECT COUNT(*)

FROM vita_dim_dan

WHERE vikend = 'NE'

AND praznik = 'NE'

AND to_char(datum,

'mm.yyyy') =

to_char(a.datum,

'mm.yyyy')

GROUP BY to_char(a.datum,

'mm.yyyy'));

p_status := c_status_uspeh;

EXCEPTION

WHEN OTHERS THEN

raise_application_error(-20999,

c_pkg || c_proc || ' - ' ||

dbms_utility.format_error_stack);



/*WHEN OTHERS THEN

pkg_error_util.get_oracle_napaka(p_status,

p_message);*/

END polni_vita_dim_dan;

--------------------------------------------------------------------------

--------------------------

--

--------------------------------------------------------------------------

--------------------------

PROCEDURE polni_vita_dim_produkt(p_id_obdelave IN NUMBER,




c_proc VARCHAR2(30) := 'polni_vita_dim_produkt';

BEGIN

INSERT INTO vita_dim_produkt

SELECT vita_dim_produkt_sq.nextval id,

n.planno id_vira,

CASE

WHEN p.plan_cats = 'U' THEN

'NALOZBA'

ELSE

'RIZIKO'

END tip_riz_produkta,

CASE

WHEN upper(p.plan_descn) LIKE '%KOLEK%' THEN

'KOLEKTIVNO'

ELSE

'INDIVIDUALNO'

END tip_zav_produkta,

CASE

WHEN n.planno = 310 THEN

'REDNO'


'ENKRATNO'


'KOMBINIRANO'

WHEN r.max_freq = 99 THEN

'ENKRATNO'

ELSE

'REDNO'

END tip_plac_produkta,

p.plan_descn naziv_produkta,

p.plan_name opis_produkta,

g.nlb_code koda_produkta,

p.date_created dat_velj_od,

NULL dat_velj_do,

a.acc_short_name sifra_racuna,

a.acc_no racun,

substr(a.acc_no,

-3) racun_okra,

c.currency_code oznaka_valute,

c.description opis_valute,

c.nmemonic ime_valute,

1 enota_valute,

USER kreiral,

SYSDATE kreirano,

NULL spremenil,

NULL spremenjeno

FROM plan p,

nlb_kj_gk k,

nlb_plan n,

nlb_plan_group g,



nlb_vita_accounts a,

(SELECT p.planno,

c.nmemonic,

c.description,

c.currency_code

FROM plan_curr p,

currency_tbl c

WHERE p.curr_no = c.curr_no) c,

(SELECT planno,

MAX(max_freq) max_freq

FROM plan_alloc_rules

GROUP BY planno) r

WHERE g.id = n.group_id

AND n.planno = p.planno(+)

AND n.acc_id = a.id

AND p.planno = c.planno

AND n.gk_code = k.gk_code

AND p.planno = r.planno(+);



p_sporocilo := st_obd_vrstic_opis(p_st_obd_vrstic => v_st_vrstic);

EXCEPTION

WHEN OTHERS THEN

p_status := c_status_napaka;

vrni_oracle_napako(p_status,

p_sporocilo);

END polni_vita_dim_produkt;

--------------------------------------------------------------------------

--------------------------

--

--------------------------------------------------------------------------

--------------------------

PROCEDURE polni_vita_dim_agent(p_id_obdelave IN NUMBER,




c_proc VARCHAR2(30) := 'polni_vita_dim_agent';

BEGIN

INSERT INTO vita_dim_agent

SELECT vita_dim_agent_sq.nextval id,

v.agentno id_vira,

pp.first_name ime,

pp.surname priimek,

(pp.first_name || ' ' || pp.surname) ime_in_priimek,

CASE

WHEN pp.sex = 'F' THEN

'ŢENSKI'

WHEN pp.sex = 'M' THEN

'MOŠKI'

END spol,

CASE

WHEN substr(v.site_agentno,

1,

4) = '1000' THEN

'NLB'


1,

1) = '6' THEN

'BC'


1,

1) = '9' THEN



'VITA'

END sifra_banke,

v.lvl1_name banka,

v.lvl2_name podruznica,

v.branch_name poslovalnica,

v.regija,

'KOMERCIALIST' delovno_mesto,

v.agent_dc licenca_od,

v.term_date licenca_do,

v.site_agentno mst_delavca,

NULL telefon,

NULL fax,

NULL gsm1,

NULL gsm2,

NULL email1,

NULL email2,

USER kreiral,

SYSDATE kreirano,

NULL spremenil,

NULL spremenjeno

FROM (SELECT b.lvl1_no,

b.lvl1_name,

b.lvl2_no,

b.lvl2_name,

b.branch_no,

b.branch_name,

CASE

WHEN lvl2_no IN (1,

2,

3,

5,

8,

21,

22) THEN

'OSREDNJA SLOVENIJA'

WHEN lvl2_no IN (4,

6,

7,

9,

11,

12,

13,

14,

23) THEN

'OSTALE'

ELSE

'OSTALE'

END regija,

a.agentno,

a.perno,

a.site_agentno,

s.term_date,

a.date_created agent_dc

FROM agents a,

agent_structure s,

nlb_agency_branch_vw b

WHERE a.agentno = s.agentno

AND s.branchno = b.branch_no

AND b.lvl1_no = 1) v,

person pp

WHERE v.perno = pp.perno

AND v.term_date IS NULL

AND substr(v.site_agentno,



1,

1) NOT IN ('A',

'B',

'C',

'D',

'E')

AND lower(pp.surname) NOT IN

('nlb agent',

'poslovalnica',

'direktna pošta');



p_sporocilo := st_obd_vrstic_opis(p_st_obd_vrstic => v_st_vrstic);

EXCEPTION

WHEN OTHERS THEN

p_status := c_status_napaka;

vrni_oracle_napako(p_status,

p_sporocilo);

END polni_vita_dim_agent;

END nlb_dw_pkg;

/

Documents

PODATKOVNO SKLADIŠČE ZA ZAVAROVALNICO - … · V diplomski nalogi sem v prvem delu ... Diplomsko delo predstavlja opis rešitve ki temelji na podatkovni zbirki Oracle. ... orodja