podatkovno skladiŠČe za zavarovalnico - … · v diplomski nalogi sem v prvem delu ... diplomsko...
TRANSCRIPT
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).
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 2
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:
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 3
Ţ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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 4
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šč.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 5
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 6
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.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 7
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 8
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).
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 9
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 10
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.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 11
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.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 12
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 :
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 13
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.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 14
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 15
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.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 16
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.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 17
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 18
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)
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 19
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:
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 20
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.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 21
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).
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 22
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šč
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 23
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 24
• 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.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 25
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 :
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 26
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:
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 27
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.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 28
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).
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 29
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 30
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,
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 31
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 32
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 33
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
NAZIV POLJA TIP PODATKA OPIS
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
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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
NAZIV POLJA TIP PODATKA OPIS
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 34
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 ?
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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
NAZIV POLJA TIP PODATKA OPIS
ID NUMBER Šifra frekvence plačevanja v PS
ID_VIRA NUMBER Izvorna šifra frekvence plačevanja
OPIS_FREKVENCE VARCHAR2 Opis frekvence plačevanja
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
Dimenzijska tabela VITA_DIM_PODRUZNICA
Vsebuje osnovne podatke o podruţnicah v prodajni mreţi skupine NLB.
Tabela 6: Dimenzija VITA_DIM_PODRUZNICA
NAZIV POLJA TIP PODATKA OPIS
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 35
TELEFON VARCHAR2 Telefonska št. podružnice
FAX VARCHAR2 Št. faksa podružnice
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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
NAZIV POLJA TIP PODATKA OPIS
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
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
Dimenzijska tabela VITA_DIM_POSLOVALNICA
Vsebuje osnovne podatke o poslovalnicah v prodajni mreţi skupine NLB.
Tabela 8: Dimenzija VITA_DIM_POSLOVALNICA
NAZIV POLJA TIP PODATKA OPIS
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 36
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
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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
NAZIV POLJA TIP PODATKA OPIS
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
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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
NAZIV POLJA TIP PODATKA OPIS
ID NUMBER Šifra statusa police v PS
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 37
ID_VIRA VARCHAR2 Izvorna šifra statusa police
OPIS_STATUSA VARCHAR2 Opis statusa police
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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
NAZIV POLJA TIP PODATKA OPIS
ID NUMBER Šifra tipa police police v PS
OPIS_TIPA VARCHAR2 Izvorna šifra tipa police
OPIS_SKUPINE VARCHAR2 Opis skupine tipa police
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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
NAZIV POLJA TIP PODATKA OPIS
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
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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
NAZIV POLJA TIP PODATKA OPIS
ID NUMBER Šifra valute v PS
ID_VIRA NUMBER Izvorna šifra valute
SIFRA_VALUTE VARCHAR2 Naziv valute
OPIS_VALUTE VARCHAR2 Opis valute
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 38
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
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 39
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
NAZIV POLJA TIP PODATKA OPIS
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
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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
NAZIV POLJA TIP PODATKA OPIS
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
KREIRAL VARCHAR2 Uporabnik kreiranja zapisa
KREIRANO DATE Datum kreiranja zapisa
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 40
SPREMENIL VARCHAR2 Uporabnik spremembe zapisa
SPREMENJENO DATE Datum spreminjanja zapisa
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.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 41
Slika 12: Podatkovni model: realizacija letnega plana prodaje zavarovanj
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 42
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 :
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 43
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 44
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 45
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 46
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 47
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šč.
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 48
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)
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 49
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 50
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 51
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
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 52
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,
p_sporocilo IN OUT VARCHAR2);
PROCEDURE polni_vita_dim_agent(p_id_obdelave IN NUMBER,
p_status IN OUT VARCHAR2,
p_sporocilo IN OUT VARCHAR2);
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;
--------------------------------------------------------------------------
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 53
--------------------------
-- 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;
--------------------------------------------------------------------------
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 54
--------------------------
--
--------------------------------------------------------------------------
--------------------------
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')) ||
to_char(v_start_date,
', YYYY') datum_opis,
to_number(to_char(v_start_date,
'DD')) dan,
TRIM(to_char(v_start_date,
'Day')) dan_opis,
to_number(to_char(v_start_date,
'D')) dan_v_tednu,
to_number(to_char(v_start_date,
'DD')) dan_v_mesecu,
to_number(to_char(v_start_date,
'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,
to_number(to_char(v_start_date,
'W')) teden_v_mesecu,
to_number(to_char(v_start_date,
'WW')) teden_v_letu,
to_number(to_char(v_start_date,
'MM')) mesec,
TRIM(to_char(v_start_date,
'Month')) mesec_opis,
to_number(to_char(v_start_date,
'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,
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 55
'Q'))) kvartal,
CASE
WHEN TRIM(to_char(v_start_date,
'Q')) = '1' THEN
'Januar - Marec'
WHEN TRIM(to_char(v_start_date,
'Q')) = '2' THEN
'April - Junij'
WHEN TRIM(to_char(v_start_date,
'Q')) = '3' THEN
'Julij - September'
WHEN TRIM(to_char(v_start_date,
'Q')) = '4' THEN
'Oktober - December'
END kvartal_opis,
to_number(to_char(v_start_date,
'Q')) kvartal_v_letu,
CASE
WHEN TRIM(to_char(v_start_date,
'Q')) = '1' THEN
to_date('1.1.' || to_char(v_start_date,
'yyyy'),
'dd.mm.yyyy')
WHEN TRIM(to_char(v_start_date,
'Q')) = '2' THEN
to_date('1.4.' || to_char(v_start_date,
'yyyy'),
'dd.mm.yyyy')
WHEN TRIM(to_char(v_start_date,
'Q')) = '3' THEN
to_date('1.7.' || to_char(v_start_date,
'yyyy'),
'dd.mm.yyyy')
WHEN TRIM(to_char(v_start_date,
'Q')) = '4' THEN
to_date('1.10.' || to_char(v_start_date,
'yyyy'),
'dd.mm.yyyy')
END kvartal_zac_datum,
CASE
WHEN TRIM(to_char(v_start_date,
'Q')) = '1' THEN
to_date('31.3.' || to_char(v_start_date,
'yyyy'),
'dd.mm.yyyy')
WHEN TRIM(to_char(v_start_date,
'Q')) = '2' THEN
to_date('30.6.' || to_char(v_start_date,
'yyyy'),
'dd.mm.yyyy')
WHEN TRIM(to_char(v_start_date,
'Q')) = '3' THEN
to_date('30.9.' || to_char(v_start_date,
'yyyy'),
'dd.mm.yyyy')
WHEN TRIM(to_char(v_start_date,
'Q')) = '4' THEN
to_date('31.12.' || to_char(v_start_date,
'yyyy'),
'dd.mm.yyyy')
END kvartal_kon_datum,
to_number(to_char(v_start_date,
'YYYY')) leto,
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 56
to_char(v_start_date,
'YYYY') leto_opis,
CASE
WHEN to_number(to_char(v_start_date,
'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
WHEN to_number(to_char(v_start_date,
'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);
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 57
/*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,
p_status IN OUT VARCHAR2,
p_sporocilo IN OUT VARCHAR2) IS
v_st_vrstic NUMBER := 0;
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'
WHEN n.planno = 777 THEN
'ENKRATNO'
WHEN n.planno = 150 THEN
'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,
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 58
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(+);
v_st_vrstic := v_st_vrstic + 1;
p_status := c_status_uspeh;
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,
p_status IN OUT VARCHAR2,
p_sporocilo IN OUT VARCHAR2) IS
v_st_vrstic NUMBER := 0;
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'
WHEN substr(v.site_agentno,
1,
1) = '6' THEN
'BC'
WHEN substr(v.site_agentno,
1,
1) = '9' THEN
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 59
'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,
Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija
Vajo Lukić: Podatkovno skladišče za zavarovalnico stran 60
1,
1) NOT IN ('A',
'B',
'C',
'D',
'E')
AND lower(pp.surname) NOT IN
('nlb agent',
'poslovalnica',
'direktna pošta');
v_st_vrstic := v_st_vrstic + 1;
p_status := c_status_uspeh;
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;
/