SVEUILITE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAUNARSTVA

Draen Oreanin

OSIGURANJE KVALITETE PODATAKA U

SKLADITIMA PODATAKA

MAGISTARSKI RAD

Zagreb, 2011.

1 / 95
Magistarski rad je izraen u Zavodu za primjenjeno raunarstvo Fakulteta
elektrotehnike i raunarstva

Mentor: Prof.dr.sc. Mirta Baranovi

Magistarski rad ima: 88 stranica

Magistarski rad br.: ___________

2 / 95
Zahvale:

Aniti i Andreji, za bezgraninu ljubav i podrku

Mentorici Prof.dr.sc. Mirti Baranovi, za vjeru i upornost bez kojih ovaj rad
nikada ne bio dovren

3 / 95
Sadraj:

1. Uvod ............................................................................................ 6
2. Integracija podataka i aplikacija ................................................ 12
2.1. Tipovi integracija podataka i aplikacija ...................................... 13
2.2. Nejednakost podataka i upravljanje matinim podacima ........... 17
2.3. Integracijski centri kompetencije ............................................... 18
3. Definicije i pojanjenja bitnih pojmova ....................................... 23
3.1. Skladita podataka .................................................................... 23
3.2. Izvori podataka .......................................................................... 29
3.3. Transformacija podataka i privremeni spremnik ........................ 30
3.4. Metapodaci................................................................................ 31
3.5. Data mart .................................................................................. 31
3.6. Izvjetajni i analitiki sustavi ...................................................... 32
3.7. OLAP ........................................................................................ 33
3.8. Dubinska analiza podataka ....................................................... 34
3.9. Upravljanje matinim podacima ................................................ 35
4. Kvaliteta podataka i informacija................................................. 37
4.1. Kvaliteta metapodataka ili definicije podataka ........................... 37
4.2. Kvaliteta sadraja podataka ...................................................... 38
4.3. Kvaliteta prikaza podataka ........................................................ 38
5. Upravljanje kvalitetom podataka ............................................... 39
5.1. Tri okruenja za osiguranje kvalitete podataka ......................... 40
5.2. ienje podataka na aplikacijskoj razini .................................. 40
5.3. ienje podataka u integracijskom sloju ................................. 42
5.4. Odravanje povijesnih podataka u skladitu podataka .............. 43
6. Pojmovi i algoritmi vezani za platforme za kvalitetu podataka .. 45
6.1. Oznaavanje ............................................................................. 46
6.2. Soundex i NIISYS algoritmi ....................................................... 47
6.3. Edit Distance algoritam ............................................................. 49
6.4. Hamming Distance algoritam .................................................... 50
6.5. Jaro-Winkler Distance algoritam ............................................... 51
6.6. Bigram Distance algoritam ........................................................ 52
6.7. Neizrazita logika ........................................................................ 53

4 / 95
7. Proces poboljanja kvalitete podataka ...................................... 55
7.1. Analiza i profiliranje ................................................................... 55
7.2. Standardizacija i korekcija ......................................................... 57
7.3. Dopunjavanje ............................................................................ 58
7.4. Uparivanje ................................................................................. 58
7.5. Preivljavanje ............................................................................ 60
8. Dobavljai i platforme za poboljanje kvalitete podataka .......... 61
8.1. IBM QualityStage ...................................................................... 62
8.2. Informatica Data Quality ............................................................ 63
8.3. Oracle Warehouse Builder i Oracle Data Integrator .................. 64
8.4. Microsoft SQL Server Integration Services ............................... 65
9. Proces lokalizacije i izrade pravila za Hrvatsku ......................... 67
9.1. IBM QualityStage ...................................................................... 67
9.2. Informatica Data Quality ............................................................ 73
10. Studija sluaja T-Mobile Hrvatska ............................................. 76
10.1. Okruenje projekta .................................................................... 76
10.2. Poslovne potrebe ...................................................................... 76
10.3. Arhitektura rjeenja ................................................................... 77
10.4. Kljuni indikatori poslovanja i dimenzije .................................... 79
10.5. Hardverska infrastruktura .......................................................... 79
10.6. Softverska infrastruktura ........................................................... 80
10.7. Implementacijski tim .................................................................. 81
10.8. Proces implementacije .............................................................. 82
10.9. Implementacija rjeenja za poboljanje kvalitete podataka ....... 83
10.10. Sljedei koraci ....................................................................... 84
10.11. Rezultati uvoenja sustava .................................................... 84
11. Zakljuak ................................................................................... 86
Reference ............................................................................................. 88

5 / 95
1. Uvod

Procjene kau da e se u svake sljedee tri godine u svijetu prikupiti i

pohraniti na raunalnim medijima koliina podataka i informacija jednaka
koliini prikupljenoj od postanka ovjeanstva do danas. Razlozi nastanka
tolike koliine podataka su dvojaki.

Prvi razlog je injenica da je, zbog tehnolokog napretka i pojeftinjenja

tehnologije za procesiranje i pohranu podataka, sve lake podatke arhivirati,
a znanje publicirati putem Interneta. Posljedica toga je golema koliina
znanja javno dostupna, koja je ve sada praktino tolika da onemoguuje
ozbiljno bavljenje bilo kakvom strukom van vrlo uskih i specijaliziranih okvira.

Drugi razlog se krije u tome da se dolaskom informacijske revolucije1

poslovna filozofija velikih svjetskih kompanija bitno promijenila te da se u
svome poslovanju i u donoenju poslovnih odluka sve vie oslanjaju na
analizu podataka iz vlastitog poslovanja i poslovnog okruenja.

Drugim rijeima, podaci koji se nalaze na raunalima kompanija ne koriste se

samo za udovoljavanje zakonskim obvezama i izvjetavanje o onome to se
desilo, ve je pristup postao proaktivan te se tei tome da se na temelju
historijskih podataka to uspjenije usmjeri poslovanje u buduem razdoblju.
Osim to se historijski poslovni podaci zbog toga due uvaju, nastale su i
nove vrste podataka koje se koriste za analizu, poput podataka iz logova
Internet servera. Takoer, prilikom pripreme podataka za analizu i analize
same, podaci se transformiraju u oblik optimalan za prikaz i analizu, to
iznova kreira nove velike koliine podataka.

U zadnjih nekoliko godina vrlo je primjetan pomak u investicijama u

informacijsku tehnologiju. Prije deset godina se veina budeta velikih
poslovnih subjekata namijenjenog informacijskim tehnologijama ulagala se u
transakcijske sustave koji su omoguavali automatizaciju poslovanja, dok se
1
informacijska revolucija je pojam ekvivalentan tehnolokim revolucijama, a oznaava
injenicu da je informacija u dananjoj i buduoj ekonomiji kljuni poslovni faktor

6 / 95
manji dio ulagao u sustave koji kreiraju informacije i znanje. Danas je
situacija obrnuta veina novca ulae se u kreiranje znanja i informacija te u
nove modele poslovanja, komuniciranja i prikupljanja podataka.

Trei razlog vrlo je povezan s drugim razlogom. Naime, sve velike kompanije
ive od svojih klijenata i kupaca te im primarni poslovni fokus postaje
klijentocentrian. Posljedica toga je prikupljanje sve vee koliine podataka o
svim moguim interakcijama putem svih kanala kontakta izmeu kompanije i
klijenta, podataka demografske, transakcijske i behavioristike prirode, koji
takoer slue za analizu i kreiranje informacija za podrku donoenju
poslovnih odluka.

Put od podataka do informacija i znanja nije nimalo jednostavan. Bitne

komponente tog procesa bile su temom mnogih strunih radova u zadnjem
desetljeu, fokusirane uglavnom na dvije strane iste medalje poslovnu i
tehnoloku.

To je rezultiralo definiranjem novih, danas ve opeprihvaenih teorija i

metodologija poput skladitenja podataka (engl. Data Warehousing),
dubinske analize podataka (engl. Data Mining) i OLAP-a (engl. On-Line
Analytical Processing).

Sve te metodologije iskuane su u praksi te se sad najee mogu nai pod

krovnim pojmom poslovne inteligencije (engl. Business Intelligence) i ine
godinje trite veliine od 25 milijardi dolara u 2010. godini, s perspektivom
rasta od preko 10% godinje, s vie stotina razliitih dobavljaa opreme i
programskih rjeenja za pojedine faze u procesu te mnotvom uspjeno
implementiranih projekata u cijelom svijetu.

Sljedei korak u razvoju sustava poslovne inteligencije je skup metodologija

koje se nalaze iza imena upravljanje performansama (engl. PM -
Performance Management). U takvim sustavima poslovna inteligencija je
samo jedna od tri kljune komponente.

7 / 95
Druga komponenta je sustav za planiranje i budetiranje koji omoguava
brzo, jednostavno i pouzdano kreiranje stratekih i operativnih planova te
budeta i predvianja.

Na vrhu sustava za upravljanje performansama nalazi se uravnoteena

tablica rezultata (engl. BSC - Balanced Scorecard) platforma u kojoj su
definirani svi kljuni poslovni pokazatelji (engl. KPI - Key Performance
Indicators) koje tvrtka treba pratiti, s indikatorima trenda kretanja i statusa
ispunjenja planskih vrijednosti, koje ne moraju biti iskljuivo financijske
prirode.

Na tom putu jedan problem se praktino uvijek pojavljuje problem kvalitete

podataka. Istraivanje Gartner Grupe pokazuje da veina inicijativa za
reinenjering informacijskih sustava propada zbog zanemarivanja problema
kvalitete podataka. Praktino polovica projekata implementacije skladita
podataka u svijetu je osueno na propast, a glavni uzrok su nekvalitetni i
nepouzdani podaci u izvornim sustavima i samom skladitu podataka [14].

Podaci u transakcijskim sustavima uvijek su jednim dijelom nepotpuni,

nekonzistentni, netoni i kao posljedica toga - neistiniti. Poznato je pravilo
koje kae da ako ulazni podatak nije ispravan i istinit, niti na izlazu nee biti
ono to je potrebno informacija, odnosno znanje.

Naime, da bi neto bilo informacija, mora zadovoljavati tri uvjeta istinitost,

pravovremenost i donoenje nove vrijednosti. U ovom sluaju, ve prvi uvjet
nije zadovoljen. I u samoj inicijalnoj definiciji skladita podataka (o
skladitima podataka e biti vie rijei u zasebnom poglavlju) jedna od etiri
bitne karakteristike je integriranost, to podrazumijeva konzistentnost u
nazivlju, formatima i pohranjivanju podataka, to je praktino sinonim za
kvalitetu.

U projektima implementacije sustava poslovne inteligencije vrlo velika panja

posveuje se kvaliteti podataka te su razvijene politike osiguranja kvalitete

8 / 95
podataka, platforme i algoritmi za ienje, konsolidaciju i ispravljanje
netonih podataka, o kojima e takoer biti rijei u ovom radu.

U praksi u Hrvatskoj situacija je ipak malo drugaija kao i mnogoemu

drugome, tako se i kvaliteti podataka najee pristupa nesustavno te e
rijetko koja hrvatska kompanija rei da je zadovoljna kvalitetom svojih
poslovnih podataka.

Obino su hrvatske kompanije svjesne da su njihovi podaci upitne kvalitete.

Bez obzira na ovu injenicu, nita se ne ini kako bi se poboljala kvaliteta
podataka. Stavka za poboljanje kvaltete podataka se obino zasebno ne
budetira u projektima implementacije skladita podataka. Bez odgovarajuih
ulaganja, ovakav kompleksan problem ne moe se ni djelomino rijeiti.

Jedna od bitnih znaajki ovog rada je i analiza kvalitete podataka u realnom

poslovnom okruenju, implementacija sustava za osiguranje kvalitete
podataka kao dijela sustava za podrku poslovnom odluivanju te analiza
dobivenih rezultata i primijenjenih algoritama.

U zadnjih nekoliko godina obranjen je na hrvatskim sveuilitima prilian broj

diplomskih, magistarskih i doktorskih radnji koje su se koncentrirale na
pojedine segmente procesa kreiranja informacija i znanja.

Veina tih radnji odnosila se na koncepte skladitenja i dubinske analize

podataka, a ovo je, koliko je autoru poznato, jedan od prvih radova koji se
primarno fokusira na pitanje to je kvaliteta podataka i kako je postii u praksi
prilikom implementacije korporativnih analitikih sustava koji se temelje na
metodologiji skladitenja podataka.

Platforme za poboljanje kvalitete podataka vjerojatno ine najmanje

istraenu i koritenu grupu analitikog softvera u Hrvatskoj. Hrvatsko trite
nije dovoljno veliko da bude zanimljivo globalnim dobavljaima da ulau u
razvoj lokaliziranih pravila za svoje platforme. Za to postoje tri glavna
razloga.

9 / 95
Prvi razlog je cijena takvih platformi koja je previsoka ak i za najvee
potencijalne klijente na tritu.

Drugi je razlog da veina kompanija nije svjesna koristi koje mogu dobiti od
ove vrste softverskih platformi.

Trei i najvaniji razlog je injenica da nijedna od vodeih platformi za

poboljanje kvalitete podataka nije inicijalno, bez dodatnih aktivnosti i dorada,
spremna za rad s hrvatskim specifinim podacima o imenima, prezimenima i
adresama u procesu standardizacije i ienja, zbog razliitih kodnih stranica
i razliitih pravila za usporedbu s ostalim europskim jezicima.

Na sreu, stvari se mijenjaju na bolje, pa ovaj rad prikazuje lokalizacijski

proces i kreiranje skupa pravila za platformu za poboljanje kvalitete
podataka na projektu u jednoj velikoj hrvatskoj tvrtki.

U drugom poglavlju rada detaljno se razmatra integracija podataka i

aplikacija, tipovi integracije i razvoj metodologija i sustava za integraciju
podataka i aplikacija kroz povijest.

U treem poglavlju rada daju se definicije osnovnih pojmova vezanih za

skladita podataka, poslovnu inteligenciju i analitiku integraciju podataka, s
osvrtom na ulogu koju kvaliteta podataka ima u procesu skladitenja
podataka.

U etvrtom poglavlju rada definirane se tri komponente kvalitete kvaliteta

definicija i metapodataka, kvaliteta podataka i kvaliteta prikaza podataka.

U petom poglavlju opisani su nain i metodologija upravljanja kvalitetom

podataka i okruenja u kojima se moe utjecati na kvalitetu podataka.

U estom poglavlju detaljno su opisani najbitniji statistiki algoritmi koji se

koriste u platformama za poboljanje kvalitete podataka.

U sedmom poglavlju detaljno su opisani koraci u procesu poboljanja

kvalitete podataka, s primjerima upotrebe pojedinih algoritama.

10 / 95
U osmom poglavlju su ukratko opisane funkcionalnosti vodeih platformi za
poboljanje kvalitete podataka prisutnim na hrvatskom tritu.

U devetom poglavlju opisan je proces lokalizacije pravila za poboljanje

kvalitete podataka za dvije najprisutnije platforme za poboljanje kvalitete
podataka na hrvatskom tritu.

U desetom poglavlju je opisana studija sluaja implementacije sustava za

skladitenje podataka koji je ukljuivao i platformu za poboljanje kvalitete
podataka u jednoj od velikih tvrtki u Hrvatskoj.

Zakljuak rada je u posljednjem, jedanaestom poglavlju.

Implementacija platformi za poboljanje kvalitete podataka je podruje

analitike infrastrukture ija se vanost u Hrvatskoj jo uvijek nije dovoljno
spoznala, a moe se rei i da je ovo podruje najmanje istraivano i
upoznato. Doprinos ovoga rada trebao bi biti jedan od poetnih koraka u iroj
implementaciji sustava za upravljanje kvalitetom podataka.

11 / 95
2. Integracija podataka i aplikacija

Svaki informacijski sustav temelji se na podacima koje sadri, koji se u njega

unose i kroz njega odravaju. U poslovanju moderne tvrtke imaju sve vie
razliitih aplikacija za prikupljanje i diseminaciju podataka, a podatke iz njih je
nuno prikupljati, razmjenjivati i usklaivati kako bi se osigurala
pravovremena informacija za rukovoditelje.

Problem integracije podataka iz razliitih sustava te razmjene podataka meu

sustavima ve je dugo prisutan u poslovnom svijetu, a s vremenom dobiva
sve vie na vanosti.

U prosjeku se svake tri godine koliina ukupno kreiranih podataka i

informacija na svijetu udvostrui, to znai da e u sljedee tri godine biti
proizvedena jednaka koliina informacija kao to je cjelokupno ovjeanstvo
proizvelo u ukupnoj svojoj povijesti. Ne samo da raste koliina podataka,
nego raste i raznovrsnost, postoji sve vie razliitih platformi, baza podataka,
poslovnih aplikacija, podatkovnih formata i standarda.

Takoer, poznata je injenica da se sve vei dio poslovnih informacija nalazi

u e-mail porukama i datotekama kreiranim u tekstualnim procesorima i
tablinim kalkulatorima poput Microsoft Worda ili Excela, pohranjenim na
osobnim raunalima i esto nedostupnim za integraciju s ostalim potrebnim
podacima.

Dodatni nivo sloenosti i volumena podataka donose i novi izvori podataka

koji su posljedica novih naina komuniciranja. Tu se prvenstveno radi o
podacima s drutvenih mrea poput Facebooka, Twittera i LinkedIna te
servisa za dijeljenje video, audio i slikovnih sadraja poput Youtubea.

Inicijalno su sustavi poslovne inteligencije i skladita podataka, odnosno

sustavi za podrku poslovnom odluivanju, bili prvo mjesto na kojem je bila
potrebna integracija podataka iz vie razliitih informacijskih sustava
transakcijke prirode. Globalizacijom poslovanja, i razvojem business-to-

12 / 95
business poslovnih modela putem Interneta, sve je vie i rasla potreba za
integracijom podataka iz razliitih sustava.

Velike svjetske tvrtke, a i mnoge hrvatske tvrtke, imaju pogone ili

predstavnitva u raznim zemljama svijeta, na razliitim kontinentima, u
kojima, ne samo da se govori razliitim jezicima, nego su i pisma koja se
koriste razliita.

Za uvid u konsolidirano poslovanje mora se omoguiti da svi ti sustavi

meusobno nesmetano komuniciraju i razmjenju podatke na pouzdan i
pravovremen nain. Osnovna pretpostavka za komunikaciju meu sustavima
su standardni industrijski formati za komunikaciju, poput SWIFT standarda za
meubankovne transakcije ili EDI standarda za elektronike transakcije te u
novije vijeme sve vie XML-a kao plaforme za komunikaciju meu sustavima
na kojoj se mogu razvijati specifina rjeenja.

2.1. Tipovi integracija podataka i aplikacija

Zahtjev poslovanja je da se mora omoguiti da se podaci iz razliitih sustava,

koji za komunikacju koriste razliite standarde i protokole, iz razliitih
aplikacija na razliitim jezicima razmjenjuju meu sustavima.

Tu je potrebno razlikovati tri osnovne vrste interakcija meu sustavima.

U prvom sluaju je je rije o razmjeni podataka u realnom vremenu ili u

relativno kratkim vremenskim razmacima. U ovu kategoriju mogu se ubrojiti
sinkronizacije podataka izmeu sustava ili replikacije podataka na drugu
lokaciju radi osiguravanja nastavka nesmetanog funkcioniranja u sluaju
havarije. Tu se najee radi o malim do srednjim koliinama podataka i
visokoj uestalosti razmjene te malim potrebama za transformacijama.

U drugu kategoriju spadaju punjenja skladita podataka i analitikih sustava

za podrku odluivanju. Takvi integracijski zadaci najee se deavaju

13 / 95
jednom dnevno u doba kada izvorni i ciljni sustavi nisu optereeni korisnikim
zahtjevima, najee tijekom noi. Koliine podataka koje se prebacuju su
srednje do velike, uz sloene transformacije.

U treu kategoriju spadaju migracije s jednog sustava na drugi, poput sluaja

kada se uvodi novi operativni ERP sustav (engl. Enterprise Resource
Planning) u tvrtku pa se podaci iz starog sustava trebaju prebaciti u novi.
Takvi integracijski zadaci deavaju se jednokratno, uz veliku koliinu
podataka i najee vrlo sloene transformacije i kontrole. U skupinu
migracija spadaju i migracije podataka iz testnog u produkcijski sustav kod
uvoenja novog sustava.

Kroz zadnjih desetak godina nastale je nekoliko specifinih grupa proizvoda

koji su rjeavali te probleme. Veina ih je grupirana u dvije osnovne grupe
koje se baziraju na tipu integracije.

Prvu i veu grupu inile su platforme koji omoguavaju komunikaciju i

integraciju transakcijskih sustava, koje se nazivaju EAI Enterprise
Application Integration platforme. EAI je segment informatikog trita koji
ima najvei rast od preko 30% godinje, to je daleko iznad trinog
prosjeka, budui da je i potreba za integracijom sve vea i vea.

Drugu grupu ine platforme koje slue ekstrakciju, transformaciju i uitavanje

podataka i za punjenje skladita podataka, odnosno analitiku integraciju
(engl. ETL Extraction, Transformation and Load). U obje grupe, osim
proizvoaa specijaliziranih za takva rjeenja poput TIBCO-a ili Informatice,
nalaze se i uvijek prisutni Microsoft, Oracle, SAP i IBM [6].

U zadnje vrijeme ta dva trita pokazuju tendenciju konvergencije, pa je tako

uveden pojam platformi za integraciju podataka (engl. Data integration).
Gartner Grupa je godinama kroz svoj magini kvadrant pratila trite
platformi za ekstrakciju, transformaciju i uitavanje podataka. Meutim,
zadnja trina analiza tih platformi bila je 2005. godine, a od zadnjeg kvartala
2006. tu analizu je zamijenila analiza platformi za podatkovnu integraciju.

14 / 95
Platforme za integraciju podataka su se kroz seriju akvizicija i spajanja ve
pomalo prorijedile (IBM je kupio Ascential, Business Objects je kupio Actu,
Oracle je kupio Sunopsis) [4], a i sam koncept se razvio prema potpunoj
integraciji podataka. Sa strane operativne integracije su doli i neki drugi
dobavljai poput Tibca [6]. Gartner kategoriju platformi za podatkovnu
integraciju definira kao platforme koje podravaju jednu ili vie navedenih
funkcionalnosti opisanih u tablici 2.1 [6].

Gartner dobavljae na nekom tritu ocjenjuje prema viziji razvoja koja se

nalazi na horizontalnoj osi te prema trenutanoj snazi i trinoj poziciji tvrtke
koja je na vertikalnoj osi. Dobavljai koji su jaki u oba segmenta nalaze se u
gornjem desnom kvadrantu te se smatraju trinim liderima. U tom kvadrantu
nalaze se Informatica, IBM, SAP i Oracle. Sve te tvrtke su sa svojim
integracijskim proizvodima prisutne u naoj regiji te su proizvodi
implementirani kod nekoliko korisnika.

Veina ostalih dobavljaa nalazi se meu igraima orjentiranim na pojedine

nie, budui da nemaju cjelovitu integracijsku platformu, odnosno orjentirani
su samo na neke elemente integracije. Sve te tvrtke imaju ideju nametnuti se
kao dobavljai cjelovitih integracijskih platformi u budunosti. Neke od tih
tvrtki takoer su i vrlo prisutne na naem tritu sa svojim integracijskim
platformama, prvenstveno Microsoft, SAS i Talend.

15 / 95
 Tip integracije Opis funkcionalnosti

Ekstrakcija podataka iz operativnih sustava,

Prikupljanje podataka za
transformiranje i uparivanje te zapisivanje u analitike
analitike sustave
sustava.

Kreiranje integriranih Omoguavanje konsolidacije, sinkronizacije i

repozitorija matinih racionalizacije podataka koji opisuju kljune poslovne
podataka subjekte poput kupaca, proizvoda i zaposlenika.

Mogunosti transformacije i pripreme podataka kod

Migracije i konverzije
migracija s legacy sustava na ERP sustave te
podataka
konsolidacija viestrukih ERP sustava kod akvizicija.

Sinkronizacija podataka
Omoguavanje konzistentnosti na nivou baza podataka,
meu operativnim
u jednom ili dva smjera, unutar tvrtke ili prema okruenju
aplikacijama

Ova funkcionalnost se esto naziva Enterprise

Kreiranje federiranih Information Integration (EII) te omoguava integrirani
pogleda nad podacima pogled na informacije u realnom vremenu, bez potrebe
iz razliitih repozitorija da se podaci fiziki spreme u jedan zajedniki
podataka repozitorij. Ova funkcionalnost je sve bitnija za Data
Integration platforme.

Integracija podataka u Ovdje je vie rije o arhtekturalnom svojstvu, nego o

servisno orijentiranoj funkcionalnosti. Moderne platforme za integarciju
arhitekturi (SOA) podataka moraju biti servisno orjentirane.

Ovdje je takoer rije o mogunosti relevantnoj za sve

Unifikacija strukturiranih
navedene scenarije, budui da organizacije tee
i nestrukturianih
sjedinjanju strukturiranih i nestrukturiranih podataka u
podataka
kreiranju informacijske infrastrukture.

Tablica 2.1: Funkcionalnosti platformi za integraciju podataka

16 / 95
 2.2. Nejednakost podataka i upravljanje matinim
podacima

Kod integracije podataka je uvijek prisutan problem nejednakosti podataka.

Nejednakost proizlazi iz razliitosti aplikacija samih po sebi. Nejednakost e
biti u daljem tekstu pojanjena na jednostavnom primjeru. Aplikacija za
prodaju ima svoj ifarnik kupaca, dok aplikacija za financije ima svoj ifarnik
kupaca, u kojima isti kupac ima razliite ifre, razliit opseg podataka i
razliite dokumente koji se veu uz tog kupca. Razlog tome je razliita
poslovna potreba koju pojedini sustav zadovoljava i razliito vrijeme
nastajanja zapisa o pojedinom kupcu u svakom od ta dva sustava.

Jedan od naina rjeavanja tog problema je implementacija integriranog

poslovnog sustava poput SAP-a ili Navisiona, ali to sa sobom nosi velike
trokove i angaman cijele tvrtke [15]. S druge strane, to je s velikim holding
tvrtkama koje u svom sastavu imaju desetak ili vie manjih tvrtki u regiji ili
cijelom svijetu? Takav pristup kod njih granii s neizvedivou.

Drugi nain, koji se najee koristi, je primjena referentnih tablica za

preslikavanja podataka iz jednog u drugi sustav. U tim tablicama nalazi se
informacija koja omoguava da se jednoznano odredi kupac kojem
pripadaju dokumenti i podaci u jednom i u drugom sustavu.

U realnom svijetu, ne postoje samo matini podaci o kupcima koji se trebaju

uskladiti i integrirati tu su i podaci o proizvodima, poluproizvodima,
materijalima, dobavljaima, zaposlenicima, organizacijskim jedinicama ili
kontnom planu. Takoer, velike tvrtke nemaju samo dvije, nego puno vie
razliitih aplikacija. Cijelu tu problematiku pokriva jedna grana integracije koja
se naziva upravljanje matinim podacima (engl. Master Data Management
MDM) [16], to je detaljnije razmotreno u poglavlju 3.9.

17 / 95
 2.3. Integracijski centri kompetencije

S vremenom zadaci koji se postavljaju i pred jednu i pred drugu skupinu

platformi sve vie konvergiraju prema jednoj jedinoj rijei, a to je integracija,
neovisno o tipu aplikacije, koliini podataka ili sloenosti transformacija. Tako
je nastao i koncept integracijskog centra kompetencije (engl. Integration
Competency Center - ICC) koji je vrlo brzo zadobio vrlo snanu podrku i
informatike struke i poslovnih korisnika.

Osnovna ideja koja stoji iza ovog koncepta je da postoji sredinje mjesto u
organizaciji koje se brine za integraciju aplikacija i podataka, organizacijska
jedinica sa skupinom ljudi i platformom ili platormama s kojima mogu
rjeavati integracijske izazove svih triju tipova, umjesto da se svaki zadatak
integracije sustava gleda kao zaseban problem.

Na taj nain se razvija kompetencija te se za svaki sljedei projekt integracije

tede resursi iz dva razloga prvi je da postoji interno poznavanje platforme
koja se koristi i sustava koji se integriraju, a drugi je da se pojedine
integracijske komponente i logika iz prethodnih projekata mogu ponovo
koristiti. Naravno, konani rezultat su bre implementacije integracijskih
projekata te manji trokovi.

Kima takve organizacije je repozitorij metapodataka, podataka o podacima,

koji sadri informacije o svim preslikavanjima i tijeku podataka meu
razliitim sustavima. Na taj nain su i najsloeniji poslovni sustavi detaljno i
precizno dokumentirani te je integracija novih podsustava u cjelinu bra i
jednostavnija.

U integracijskom centru kompetencije metapodaci nisu samo podaci o

podacima, nego takoer podaci o sustavima, procesima, sueljima, ljudima i
uslugama. To je puno opsenija definicija metapodataka nego uobiajena
definicija. Organizacija mora imati centralizirane i organizirane informacije o
svojoj vlastitoj informacijskoj infrastrukturi kao tehnoloku osnovu za
integracijski centar kompetencije.

18 / 95
Jedna vrlo jednostavna analogija koja se moe primijeniti je analogija prema
avio-prijevozu i takozvanom hub and spoke konceptu po kojem u svakoj
regiji postoji veliki, centralni tranzitni aerodrom (poput Frankfurta u Europi ili
Hong Konga na Dalekom istoku) koji je spojen sa svim lokalnim i velikim
globalnim aerodromima i koji omoguava da se s jednim presjedanjem moe
doi iz Zagreba do bilo kojeg dijela svijeta.

Analogno tome, integracijski centar kompetencije ima ulogu takvog

prometnog vora koji usmjerava podatke u njihovom prometu izmeu
razliitih sustava.

Slika 2.1: Interakcija meu sustavima u organizaciji bez integracijskog centra

kompetencije

19 / 95
Slika 2.2: Interakcija meu sustavima u organizaciji s integracijskim centrom
kompetencije

Mogui modeli funkcioniranja integracijskog centra kompetencije prikazani su

na slici 2.3 te detaljnije opisani u nastavku teksta [7].

Slika 2.3: Modeli organizacije integracijskog centra kompetencije

20 / 95
Najjednostavniji model je model projektne optimizacije. U tom modelu nema
dijeljenja resursa, ve se svi projekti vode zasebno. Tehnologija, procesi i
organizacija su nezavisni, ali satndardizirana organizacija i voenje projekata
omoguavaju kreiranje dodane vrijednosti u odnosu na organizacije bez
centraliziranih projektnih standarda.

Sljedei model je model koritenja najboljih praksi. U tom modelu se ide

korak dalje i centralizirano se definiraju integracijski procesi, dok je odabir
tehnologije na razini preporuke. Organizacija rada na projektima je
distribuirana, a boljitak se postie viestrukim koritenjem akumuliranog
znanja.

Model tehnolokih standarda najee je prisutan kod velikih svjetskih

korporacija, koje za svoje lanice propisuju standarde kojih se trebaju drati.
Tako e primjerice sve banke unutar neke bankove grupacije koristiti istu
platformu za integraciju podataka ili sustav za upravljanje rizicima. Dodatna
prednost ovog modela u odnosu na prethodne je tehnoloka konzistentnost,
koja omoguuje jednostavnu integraciju podataka i meu vie tvrtki u vie
drava.

Sljedei model je model dijeljenih servisa kojem su glavne znaajke dijeljeni

resursi i hibridna organizacija. U tom modelu postoji centralizirana
integracijska tehnoloka platforma, ali svaki sustav ima svoje suelje prema
integracijskom centru. Boljitak koji ovaj model donosi je najvei, ali je i
organizacijski i implementacijski najsloeniji, budui da zahtijeva poznavanje
integracijskih procesa, ne samo centralno, nego i na strani svake pojedine
aplikacije.

I na kraju, zadnji model centralnih servisa, za razliku od prethodnog, ima

centraliziranu organizaciju, donosi neto manje poboljanje od distribuiranog
modela, ali je laki i bri za implementaciju, budui da se jedan centralni tim
brine o svim potrebnim sueljima.

21 / 95
Odabir prikladnog modela za pojedinu organizaciju ovisi o vie vanih
imbenika, od kojih svakako valja naglasiti postojeu organizaciju i
korporativnu kulturu te informacijsku infrastrukturu.

Dananja integracijska tehnologija je prilino zrela i veina tehnologija

vodeih dobavljaa je vrlo dobra te je u odabiru infrastrukture za integracijski
centar kompetencije teko pogrijeiti.

Svakako je puno kritiniji faktor efikasna implementacija metodologije. Za to

je potrebno imati puno iskustva u integraciji, a takoer je nuno i poznavanje
procesa specifinih za pojedinu industriju. Nikako se ne smije izgubiti iz vida
da su informacijski sustavi u tvrtki potpora poslovnim procesima te da oni
doslovno prenose poslovne dogaaje i dokumente u podatke i informacije
zato je poznavanje procesa toliko bitno.

22 / 95
3. Definicije i pojanjenja bitnih pojmova

Uz pojam i sustave za poboljanje kvalitete podataka vezani su i drugi

pojmovi koji se odnose na sustave za pohranu, obradu, integraciju,
upravljanje i koritenje podataka i informacija. U ovom poglavlju biti e
definirani i pojanjeni najbitniji pojmov te njihov odnos i povezanost sa
sustavima za kvalitetu podataka.

3.1. Skladita podataka

Pojam skladita podataka nije uope toliko dugo prisutan u informatikim

rjenicima, iako je sam koncept bio upotrebljavan i prije, ali bez teoretske
formalizacije. Skladite podataka je prije svega skup podataka orijentiran
analitikom koritenju, to znai da je optimiziran za puno upita koji
dohvaaju veu koliinu podataka.

Za razliku od skladita podataka, transakcijski sustav je orijentiran na veliki

broj istovremenih korisnika te brzo zapisivanje, itanje i izmjenu malih
koliina podataka, najee samo jednog zapisa. Druga bitna znaajka
transakcijskih sustava je normaliziranost (najee u treoj normalnoj formi),
odnosno eliminiranje redundancije u podacima.

Zbog normaliziranosti strukture transakcijski sustavi ne odgovaraju potebno

dobro na analitike upite; vrlo je esto kod sloenijeg analitikog upita
dostupiti do podataka iz desetak i vie tablica istovremeno. S jedne strane,
performanse dostupa do podataka nisu dobre, a s druge strane veliki utroak
procesorskih i memorijskih resursa za takve upite onemoguava ostale
korisnike u obavljanju operativnih zadataka.

Prva definicija skladita podataka potjee iz 1992. godine kad je kum

skladitenja podataka Bill Inmon definirao skladite podataka kao skup

23 / 95
subjektno orijentiranih, integriranih, vremenski ovisnih i nepromjenjivih
podataka za podrku poslovnom odluivanju [3]. Svaka od ove etiri
znaajke zasluuje malo detaljnije pojanjenje, s osvrtom na utjecaj kvalitete
podataka.

Subjektna orijentiranost znai da podaci u skladitu podataka

organizirani tako da daju informacije o pojedinom poslovnom subjektu
(prodaji, naplati), za razliku od operativnih sustava koji su kreirani tako
da itaju ili zapisuju pojedinu transakciju koja reprezentira poslovni
dogaaj ili dokument. Sustavi za osiguranje kvalitete podataka
osiguravaju da je svaki subjekt jednoznano definiran, odnosno da se
pojedini kupac ili proizvod viestruko ne pojavljuje, bilo da podaci o
pojedinom subjektu dolaze iz jednog ili vie sustava.

Integriranost podrazumijeva dosljednost u sadraju, nazivima i

formatima podataka koji dolaze iz razliitih izvora. Primjerice, formati
zapisa datuma u razliitim transakcijskim sustavima na razliitim
platformama mogu biti razliiti, ali u skaditu podataka takvih razlika
ne smije biti. Ova znaajka skladita podataka ponajvie je ugroena
nekvalitetnim izvorinim podacima.

Vremenska ovisnost znai da podaci u skladitu imaju vremensku

dimenziju, odnosno da se skladite podataka sastoji od snimaka (engl.
snapshotova) transakcijskih podataka uzetih u redovnim vremenskim
periodima. Ova znaajka omoguava analitiku funkcionalnost i
analizu trendova poslovanja kroz vrijeme, budui da transakcijski
sustavi uvijek uvaju samo trenutnu vrijednost transakcije, a do stanja
u nekom trenutku se dolazi zbrajanjem svih transakcija u traenom
periodu

Nepromjenjivost odreuje da se podaci jednom uitani u skladite

podataka vie ne mogu promijeniti, osim ponovnim uitavanjem s
transakcijskog sustava. Od ove znaajke se moe odstupiti kod
odravanja podataka u sluaju promjena poslovnih politika ili

24 / 95
 organizacije. U praksi se zna deavati da doe do reorganizacije
tvrtke te da je zahtjev korisnika informacija da se trokovi iz prijanjih
godina prikazuju korisnicima prema novoj organizaciji. U tom sluaju
potrebno je poslovna pravila za alokaciju na podatke u skladitu
podataka iz prijanjih godina.

Postoji i jo jedna vrlo jednostavna definicija skladita podataka kao kopije

transakcijskih podataka optimiziranih za analitike upite. Povijesno gledano,
skladita podataka nastala su poetkom devedesetih godina prolog stoljea
s razlogom da se operativni sustavi rasterete analitikih upita. U to doba broj
razliitih informacijskih sustava koji su postojali u tvrtkama bio je bitno manji
nego danas. S vremenom, razlog implementacije skladita podataka je sve
vie bila integracija podataka iz raziitih izvora.

Glavni graevni elementi skladita podataka su injenine tablice (engl. Fact

tables) koje sadre kvanitativne, numerike podatke koji se analiziraju te
dimenzijske tablice (engl. Dimension tables), koje sadre kvalitativne,
strukturne podatke koji slue za kreiranje hijerarhija za sumarizaciju i analizu.

injenine tablice imaju velik broj zapisa, ponekad i desetke ili stotine
milijuna. Primjer injenine tablice je tablica ostvarene prodaje kupcima po
proizvodima. U injeninim tablicama se ne nalaze samo podaci iz
operativnih sustava, nego i dodatni kalkulirani podaci koji donose novu
poslovnu vrijednost. Tako u spomenutoj tablici prodaje se za svaki proizvod
moe dodati i nabavna ili proizvodna cijena te se izraunati kontribucija po
svakoj stavci i profitabilnost proizvoda i klijenta.

U tom kontekstu, dimenzijske tablice koje su vezane za injeninu tablicu

prodaje mogu biti tablice kupaca, proizvoda, vremena i prodajnog mjesta.
Svaka od tih tablica sadri atribute koji omoguavaju grupiranje i analizu od
ukupnog prema detaljnom. Tako se primjerice proizvodi mogu grupirati
prema grupama i podgrupama, a kupci prema geografskoj pripadnosti,
veliini, znaaju ili nekom drugom atributu.

25 / 95
Kod uitavanja podataka u skladite vri se denormalizacija i optimizacija
podataka za analitike upite. Dva najzastupljenija naina modeliranja su
zvjezdasta (engl. Star) i pahuljiasta (engl. Snowflake) shema.

Zvjezdasta shema podrazumijeva da je svaka dimenzija za analizu u

potpunosti denormalizirana, dok pahuljiasta shema nije u potpunosti
denormalizirana. Denormalizacija se radi kako bi broj tablica koje se
dohvaaju u korisnikom upitu bio to manji te kako bi upiti radili bre.
Dimenzijske tablice obavezno trebaju imati primarne kljueve, kojima se veu
na tablicu injenica. Skladite podataka se uobiajeno sastoji od vie
subjektnih podruja, od kojih svako ima najee jednu, a ponekad i vie
injeninih tablica te nekoliko dimenzijskih tablica.

Dimenzijske tablice mogu imati kontekst u vie subjektnih podruja, a

najjednostavniji primjer je vremenska dimenzija koja je potrebna u svakoj
analizi. Takve dimenzije koje se definiraju jednoznano, a koriste u vie
razliitih subjektnih podruja, nazivaju se konformne dimenzije.

Zvjezdasta shema se najee koristi u implementaciji skladita podataka te

je i najjednostavnija za razumijevanje, budui da je svaka dimenzija
reprezentirana jednom tablicom. Veina dizajnerskih problema kod
implemantacije skladita podataka moe se rijeiti koritenjem zvjezdaste
sheme, ali ponekad je potrebno koristiti i pahuljiastu shemu. Ako se uzme
kao primjer distribucijska tvrtka koja radi s kupcima koji imaju vie dostavnih
mjesta za isporuku. Isporuka se vri po dostavom mjestu, dok se fakturiranje
vri na nivou kupca. Svako dostavno mjesto pripada jednom kupcu. Dakle, u
analizi isporuka postoji veza tablice injenica s podacima o isporukama
prema dimenziji dostavnog mjesta, a od nje prema dimenziji kupca. S druge
strane, u analizi naplate dimenzija dostavnog mjesta se gubi i injenina
tablica se vee direktno na dimenziju kupca.

26 / 95
Slika 3.1.: Primjer Zvjezdaste (engl. Star) sheme

Vrlo je esta pojava tzv. sporo promjenjivih dimenzija u kojima subjekti

mijenjaju neki od kljunih atributa (npr. klijent banke koji se preselio iz jednog
grada u drugi), koje se mogu u skladitu podataka tretirati na nekoliko
naina. Teorija poznaje tri osnovna tipa takvih dimenzija i nekoliko hibridnih
varijanti, a detaljnije razmatranje njihovog tretiranja je van opsega ovog rada.

27 / 95
Slika 3.2.: Primjer Pahuljiaste (engl. Snowflake) sheme

Jo jedna vrlo bitna znaajka skladita podataka je veliina. Naime, zbog

velikog povijesnog perioda koji podaci u skladitu podataka pokrivaju, zbog
broja aplikacija iz kojih dolaze te zbog injenice da u procesu punjenja
podataka dolazi do denormalizacije i kreiranja dodatnih stupaca u tablicama,
skladita podataka su naee vrlo velika. U tom kontekstu u naem
okruenju skladite od 100 GB smatra se relativno malim skladitem, dok se
u velika skladita mogu ubrojati ona veliine od preko 1 TB. Najvea svjetska
skladita podataka od preko 100 TB i preko 1PB mogu se nai u
telekomunikacijskim tvrtkama i dravnim obavjetajnim institucijama.
Naravno, porast koliine podataka ne rezultira samo poveanjem dimenzija
diskovnog prostora, nego i procesorske memorijske snage i komunikacijske
propusnosti sustava, kako bi svi podaci pravovremeno bili uitani. Takoer,
veliina skladita podataka utjee i na performanse prema krajnjim

28 / 95
korisnicima, koje u sluaju loeg dizajna i indeksiranja mogu znaajno
degradirati s poveanjem koliine podataka.

Jedan od trendova u dizajnu velikih skladita podataka je povratak treoj

normalnoj formi, kao nainu osiguravanja konzistentnosti podataka. U
ovakvoj arhitekturi nema jasne podjele na injenine i dimenzijske tablice.
Sve tablice su povezane ogranienjima stranih kljueva (engl. primary-
foreign key constraint). Kod takvog modeliranja se obavezno koriste Data
Martovi kao jo krajnji nivo pripreme podataka za krajnje korisnike. Data Mart
u tom sluaju ima zvjezdastu strukturu, kako bi se analitiki upiti izvravali to
bre.

Izuzetno je bitno kod implementacije skladita podataka postaviti i potivati

konvencije imenovanja tablica i atributa, kako bi se sustav mogao
jednostavno koristiti, odravati i dokumentirati.

3.2. Izvori podataka

Izvori podataka za skladite podataka mogu biti razliiti, a u osnovi se dijele

na interne i eksterne. U veini sluajeva prevladavaju interni podaci koji
dolaze iz transakcijskih sustava. Velike tvrtke imaju vie razliitih
transakcijskih sustava, pogotovo ako su nastajale kao posljedica integracija
vie tvrtki koje su imale razliite sustave. Podaci iz svih tih sustava najee
su potrebni za analizu i izvjetavanje te ih je potrebno napuniti u skladite
podataka.

Takoer se ponekad koriste i podaci iz Excel tablica, kojima se podaci koji ne

postoje na transakcijskoj razini nadopunjuju. Iz tih izvora esto dolaze i
eksterni podaci, poput podataka od Zavoda za statistiku ili marketinkih
istraivanja.

U zadnje vrijeme sve ee se pojavljuju jo dvije bitne grupe podataka koje

je potrebno uitati u skladite podataka. Prvu grupu ine nestrukturirani

29 / 95
podaci poput PDF ili Word dokumenata ili e-mail poruka. Istraivanja kau da
tvrtka ima preko 80% podataka u nestrukuriarnim izvorima.

Za razliku od sustava za upravljanje dokumentima, koji dokumente

pohranjuju u repozitorij preko kojeg im korisnici mogu pristupati kao
dokumentima, u skladita podataka uitava se sadraj pojedinih dokumenata
te se prema poziciji i kontekstu sadraj smjeta u relacijsku strukturu.
Primjerice, ako tvrtka ima standardne ugovore s kupcima pohranjene na
centralnom mjestu, iz Word ili PDF dokumenta mogue je dobiti potrebne
informacije u skladitu podataka.

Drugu grupu ine podaci ije je porijeklo vezano za web servise i messaging
platforme. Oni su najee u nekoj od formi XML-a te se prilino jednostavno
uitavaju u skladite podataka.

Iz razliitih izvora podaci se moraju uitati u skladite podataka te

nadupunjavati u redovnim vremenskim intervalima. Za to slue platforme za
integraciju podataka, ija je funkcionalnost ve opisana u prethodnim
poglavljima.

3.3. Transformacija podataka i privremeni spremnik

Prilikom transformacije podataka, najee se koristi i dodatni privremeni

spremnik (engl. staging area). Najjednostavniji opis ove komponente je da je
rije o spremniku u koji se dopremaju podaci iz izvora podataka, meusobno
kombiniraju i dorauju, kako bi u skladite podataka doli proieni,
konsolidirani i obogaeni dodatnim informacijama.

Privremeni spremnik ima vitalnu funkciju kod implementacije velikih sustava

skladita podataka, jer omoguava da se sloj konanog sadraja skladita
podataka fiziki i/ili logiki odvoji od podataka koji se koriste u tijeku obrade i
pripreme. Privremeni spremnik moe se nalaziti na istoj bazi podataka u istoj
ili drugoj shemi ili na drugoj instanci baze podataka.

30 / 95
 3.4. Metapodaci

Metapodaci su podaci o podacima oni govore od kuda koji podatak dolazi,

na koji nain se transformira, gdje, kako i tko ga koristi na koji nain.
Metapodaci su doslovno vezivno tkivo skladita podataka i sustava poslovne
inteligencije. Object Management Group je razvio Common Warehouse
Metamodel, zajedniki standard metapodataka koji ve podravaju mnogi
proizvodi na tritu [9], to korisnicima ivot poinje initi puno lakim.

Vrlo esto velike tvrtke koriste vie razliitih softverskih proizvoda razliitih
tvrtki u procesu kreiranja i koritenja analitikih sustava te mogunost
razmjene metapodataka izmeu razliitih platformi moe utedjeti i vrijeme i
resurse pri implementaciji.

3.5. Data Mart

Jedan od takoer esto koristenih izraza u teoriji skladita podataka je i Data

Mart, to podrazumijeva podskup podataka iz skladita podataka
namjenjenih za koritenje od strane pojedine poslovne funkcije ili djelatnika
na jednoj lokaciji. Data Mart najee pokriva jedan subjekt, odnosno sadri
jednu zvjezdastu shemu s potrebnom injeninom i dimenzijskim tablicama.

Viedimenzionalne OLAP kocke o kojima e kasnije biti rijei u poglavlju 3.7,

najei su pojavni oblik multidimenzionalnog Data Marta. Prije je u velikim
tvrtkama est sluaj bio da su pojedine organizacijske jedinice (prodaja,
nabava, financije) kreirale vlastite Data Martove, koje je kasnije teko
integrirati u jedinstveni sustav zbog ve spomenutog problema integriranosti.

Danas je najei pristup kreiranje centralnog korporativnog skladita

podataka, iz kojeg se rade podskupovi, tj. data martovi za pojedinu poslovnu
funkciju, ime se osigurava integriranost i konzistentnost podataka.

31 / 95
 3.6. Izvjetajni i analitiki sustavi

Prvi i prilino standardan zahtjev za koritenje informacija iz skladita

podataka je kreiranje statinih izvjetaja i ad-hoc upita koji koriste podatke
pohranjene u skladitu. To nije jako sofisticiran i zahtjevan posao ako
kompleksnost skladita podataka ne prelazi nekoliko stotina tablica, ako
injenine tablice ne sadre stotine milijuna slogova, ako podatke iz skladita
ne koriste stotine ili tisue korisnika i ako se dnevno ne trebaju isporuiti
stotine izvjetaja. Dananje izvjetajne platforme uglavnom imaju iskljuivo
web suelja. Velike mogunosti za kreiranje izvjetaja i jednostavnost suelja
za krajnjeg korisnika se za sve ozbiljne platforme podrazumijevaju.

S razvojne strane, bitno je da takvi sustavi omoguavaju s jedne strane

kreiranje jednostavnih ad-hoc upita za korisnike koji nemaju veliko
informatiko iskustvo pomou jednostavnih funkcionalnosti i bez potrebe
poznavanja SQL-a. S druge strane, bitno je da omoguavaju i kreranje
sloenih sofisticiranih izvjetaja koji kombiniraju podatke iz vie razliitih upita
te sadravaju i dodatne objekte (logotipove, poveznice, tekstualne
komentare), kako bi se zadovoljile potrebe naprednih korisnika. Takoer je
bitno da takve platforme korisnicima omoguavaju dostup do relacijskih i
OLAP izvora kroz jedno suelje.

Sa sigurnosne strane, bitno je da se platforma moe integrirati u postojeu

autentikacijsku infrastrukturu te da se mogu definirati razine sigurnosti na
nivou pojedinog izvjetaja, odnosno podskupa podataka dostupnih pojedinoj
klasi korisnika unutar pojedinog izvjetaja.

Naravno, izvjetajne i analitike platforme moraju omoguavati i skalabilnost

koritenja od nekoliko do nekoliko tisua korisnika, a po mogunosti i
viejezinost suelja za mutinacionalne tvrtke.

32 / 95
 3.7. OLAP

Vjerojatno je najomiljeniji i najpoznatiji nain iskoritavanja podataka iz

skladita podataka OLAP (engl. On-Line Analytical Processing). Iako je kao
pojam nastao prilino davno, tek je u zadnjih desetak godina je postao vrlo
omiljen, a napredak tehnologije omoguio je nastajanje zaista monih OLAP
platformi. Ideja OLAP-a je da je poslovanje kompanije i funkcioniranje
ljudskog uma u biti viedimenzionalno ako je potrebno analizirati prodaju
proizvoda svoje tvrtke, onda je je takva analiza potrebna u vremenu, po
regijama, po prodajnim mjestima, po artiklima, po kupcima... Kada bi za
svaku tu dimenziju bila kreirana zasebna sumarizacijska tablica za potrebe
izvjetavanja, to bi bio dugaak i mukotrpan posao.

Ideja OLAP-a se zasniva na tehnologiji koji takve viedimenzionalne

sumarizacije kreira automatski i daje ih korisniku na raspolaganje, ime se
stvara mogunost kombiniranja najrazliitijih uvjeta koji, neovisno o svojoj
smislenosti, korisniku daju odgovor na postavljeni upit u realnom vremenu.

OLAP tehnologije dijele se na tri osnovne vrste. Prva je MOLAP

(Multidimensional OLAP), koji od izvorne relacije napravi viedimenzionalnu
kocku njegova prednost bila je brzina, a mana veliko zauzee prostora u
sluaju postojanja veeg broja dimenzija. Drugi je ROLAP (Relational OLAP)
koji je na postojeu relaciju dodao samo sumarizacije njegova prednost je
malo zauzee diskovnog prostora, to je plaeno smanjenom brzinom, ali je
ostala primjenjivost na veliku koliinu podataka. Na kraju je prevladao hibridni
HOLAP koncept (Hybrid OLAP), koji samo sumarizacije pohranjuje u
viedimenzionalnoj kocki, dok elementarni nivo podataka ostaje u izvornoj
relaciji i njima pristupa pomou drill-trough procedura koje iz agregiranih
podataka u OLAP kocki za potrebe detaljnih upita prelaze na koritenje
podataka iz relacija. Na taj nain objedinjene su i velika brzina pristupa i
relativno malo zauzee prostora.

33 / 95
Prednost relacijskog izvjetavanja pred OLAP-om je u injenici da ne postoji
faza izgradnje viedimenzionalne kocke, koja kod kreiranja kocaka od stotina
milijuna zapisa moe biti jako dugotrajna. S druge strane, mogunosti analize
koje prua OLAP su daleko vee.

Danas se OLAP posluitelji mogu smatrati dijelom infrastukture, budui da tri

glavna dobavljaa baza podataka (Microsoft, Oracle i IBM) imaju svoje
vlastite OLAP servere. Vodee izvjetajne i analitike platforme mogu se
spojiti i koristiti podatke iz OLAP struktura iz bilo kojeg od tih posluitelja.

3.8. Dubinska analiza podataka

Najzahtjevniji nain koritenja informacija za analizu je dubinska analiza

podataka (engl. Data Mining), a osnovni joj je smisao izrada prediktivnih
modela koji e predvidjeti ponaanje nekog subjeka ili pojave u budunosti.

Dubinska analiza podataka se moe opisati kao netrivijalan proces

identifikacije neospornih, novih, potencijalno korisnih i razumljivih uzoraka
(engl. patterns) i odnosa (engl. relationships) meu podacima u skladitu
podataka. Ima vie modela i algoritama koji se koriste te se ovisno o primjeni
odabire najpogodniji. Najpoznatije metode dubinske analize podataka su:
klasifikacija i regresija (algoritmi neuralnih mrea i stabla odluivanja),
klasteriranje (identificiranje i grupiranje slinih podataka), saimanje i
vizualizacija, modeliranje zavisnosti, asocijacije i sekvencijalna analiza
(analiza potroake koarice) te analiza vremenskih serija.

Dubinska analiza i prediktivni modeli koriste se u raznim industrijama, a

najea podruja primjene su spreavanje prevare u osiguranju, kartiarstvu
i telekomunikacijama, spreavanje odljeva korisnika u telekomunikacijama i
financijskoj industriji te analiza potroake koarice i stimuliranje poveanja
prodaje u maloprodaji.

34 / 95
Za dubinsku analizu podataka izuzetno je bitno imati kvalitetne podatke,
budui da predikitvni modeli bazirani na nekvalitetnim i nekonsolidiranim
podacima nee davati kvalitetne rezultate.

3.9. Upravljanje matinim podacima

Pojam upravljanja matinim podacima (engl. Master Data Management -

MDM) obuhvaa skup procesa i alata koji dosljedno definiraju i upravljaju
netransakcijskim podacima organizacije, koje prvenstveno ukljuuje matine
podatke. Sustavima za upravljanje matinim podacima je cilj implementacija
procesa za prikupljanje, agregiranje, uparivanje, konsolidaciju, osiguranje
kvalitete, praenje ivotnog vijeka i distribuiranje matinih podataka u cijeloj
organizaciji, kako bi se osigurala dosljednost i nadzor u tijeku odravanja i
primjene matinih podataka.

Sustav za upravljanje matinim podacima moe biti jednodomenski ili

viedomenski, to podrazumijeva upravljanje matinim podacima vezanim za
jednu ili vie poslovnih domena kupce, proizvode, materijale,
organizacijske jedinice, konta. Inicijalno su sustavi za upravljanje matinim
podacima bili jednodomenski, a u zadnjih nekoliko godina sve vie
prevladava viedomenski pristup.

Postoji nekoliko tipova sustava za upravljanje matinim podacima, od kojih je

nabitnije razdvojiti referencijske i transakcijske sustave. Referencijski sustavi
za upravljanje matinim podacima sadre samo pokazivae prema
referentnim podacima u transakcijskim i opertivnim sustavima. Transakcijski
sustavi za upravljanje matinim podacima u potpunosti preuzimaju
funkcionalnost upravljanja matinim podacima od transakcijskih sustav. U
njima se matini podaci kreiraju i odravaju te distriburaju transkacijskim
sustavima u stvarnom vremenu.

35 / 95
Implementacija sustava za upravljanje matinim podacima je vrlo esto
potrebna u velikim meunarodnim korporacijama kako bi se omoguio uvid u
odnos s klijentom na razini korporacije kroz sve sustave ili kako bi se mogla
pratiti prodaja istog proizvoda na razliitim tritima. U Hrvatskoj sustav za
upravljanje matinim podacima koristi Agrokor, a u drugim velikim tvtkama
poput Hrvatskog Telekoma, Hrvatske Pote ili Zagrebakog Holdinga planira
se uvoenje sustava za upravljanje matinim podacima.

Sustavi za upravljanje matinim podacima se snano oslanjaju na

funcionalnost platformi za poboljanje kvalitete podataka, koje se uvijek
nalaze implementirane kao dijelovi takvih sustava, prvenstveno u funkciji
standardizacije, uparivanja i deduplikacije.

Kod sustava za upravljanje matinim podacima se komponente platformi za

poboljanje kvalitete podataka koriste i u 'batch' procesima i prilikom obrade
u realnom vremenu, posebice kod transakcijskih sustava za upravljanje
matinim podacima.

36 / 95
4. Kvaliteta podataka i informacija

Kvaliteta podataka ima tri osnovne komponente:

definiciju podataka (metapodataka),

sadraj podataka i
kvalitetu prikaza informacija

Kvaliteta konanih informacija zahtijeva odgovore na pitanja vezana uz

kvalitetu svih navedenih komponenti, iako se vrlo esto pod kvalitetom
podataka smatra samo kvaliteta sadraja, to se uglavnom smatra
funkcionalnostima platforme za poboljanje kvalitete podataka. Za potpuno
razumijevanje problematike potrebno je okvirno opisati sve tri komponente
vane za kvalitetu podataka i informacija

4.1. Kvaliteta metapodataka ili definicije podataka

Kvaliteta metapodataka ili definicije podataka je kvaliteta specifikacije

podataka, koja ukljuuje jasne, precizne i potpune definicije i poslovna
pravila. Definicija podataka predstavlja kriterije integriteta sadraja podataka.

Bez kvalitetne definicije podataka nema jasne komunikacije za dobavljaa

(izvor) podataka, s ciljem da zna koje podatke bi trebao proizvesti i dostaviti.
Takoer nema jasnog kriterija za mjerenje kvalitete sadraja podataka.
Pitanje kvalitete metapodataka nije unutar konteksta ovog rada, iako se
moe smatrati kritinim pitanjem za implementaciju, ne samo analitikih
sustava, nego informacijskih sustava u velikim organizacijama openito.
Kvaliteti metapodataka najee nije posveena potrebna panja.

37 / 95
 4.2. Kvaliteta sadraja podataka

Kvaliteta sadraja podataka je tonost vrijednosti podataka. Ukljuuje

potpunost, standardiziranost, nepostojanje duplih vrijednosti, usklaenost s
definiranim i priznatim pravilima, kao i tonost podataka. Podaci mogu biti u
skladu s poslovnim pravilima, a da su jo uvijek nekvalitetni. To su uglavnom
podaci u poljima koja se odnose na kupce, kao to su ime i adresa. Kvaliteta
sadraja podataka obino se smatra kvalitetom podataka u uem smislu i
softverski proizvodi poznati kao platforme za poboljanje kvalitete podataka
uglavnom se usredotouju na probleme tonosti podataka.

4.3. Kvaliteta prikaza podataka

Kvaliteta prikaza podataka je kvaliteta informacija dostavljenih radnicima

znanja, gdje se podaci pretvaraju u korisne i upotrebljive informacije. To
ukljuuje pravovremenost podataka i kanala za distribuciju informacija, kao i
prezentacijski format koji lako istie vanost podataka na nain koji najbolje
odgovara potrebama radnika znanja. Platforme za poslovnu inteligenciju,
odnosnu za izvjetavanje i analizu, obino su odgovorne za kvalitetu prikaza
informacija.

38 / 95
5. Upravljanje kvalitetom podataka

Pitanje odgovornosti za kvalitetu podataka i upravljanje kvalitetom podataka

uvijek je bilo jedno od kljunih kod implementacije sustava za poboljanje
kvalitete podataka, ne samo za potrebe skladita podataka, nego za
podizanje i osiguranje traenog nivoa kvalitete podataka u svim sustavima u
organizaciji.

Shankaranarayanan i Cai u [11] definiraju pojam Total Data Quality

Management (TDQM) za sustave za podrku odluivanju kao analogiju Total
Quality Management (TQM) pristupu koji se koristio u proizvodnji. Ideja
njihovog pristupa je da postoji povezanost traene kvalitete informacije i vrste
odluke za koju se traena informacija koristi. Za neke odluke nije potrebna
apsolutna kvaliteta i preciznost podataka, dok za druge jest.

U svom radu Shankaranarayanan i Cai definiraju i potrebu da donositelji

odluka imaju i alat koji e im kroz vizualno suelje i koritenje KPI-eva
omoguavati uvid u kvalitetu podataka u vremenskoj perspektivi, s podacima
o primjerice postotku nepopunjenih matinih brojeva ili neverificiranih imena.
Takoer uvode i zanimljivu tezu po kojoj podaci nisu dodatni izlazni proizvod
informacijskog sustava koji je sam po sebi proizvod, nego su proizvod sam
po sebi.

U radu je predstavljen jednostavan softverski paket koji omoguava praenje

i nadzor kvalitete podataka. Nekoliko godina nakon objave rada veina
vodeih dobavljaa platformi za poboljanje kvalitete podataka ve je imala
ugraenu slinu funkcionalnost koja je omoguavala poslovnim korisnicima
monitoriranje kvalitete podataka putem jednostavnog web suelja.

U prolosti je problematika kvalitete podataka vrlo esto bila smatrana

odgovornou IT funkcije u organizaciji, ali je s uvoenjem koncepata
upravljanja podacima (engl. Data Governance) dolo i do promjene
shvaanja odgovornosti za kvalitetu podataka. Wende u [12] uvodi model

39 / 95
upravljanja za kvalitetu podataka, koji se bazira na tri osnovne komponente
ulogama, podrujima i odgovornostima koje su definirane za pojedinu
dimenziju kvalitete.

Upravljanje kvalitetom podataka mora imati izvrno sponzorstvo u

organizaciji te tijelo koje Wende [12] naziva Data Quality Board, koje je
zadueno za upravljanje kvalitetom podataka u organizaciji, a sastoji se
primarno od poslovnih korisnika, uz uee informatiara. Podruja kojima se
navedeno tijelo bavi su razvoj strategije upravljanja kvalitetom podataka,
uspostavljanje potrebne organizacije i implementacija informacijskih sustava
za tu namjenu. Unutar tako definiranog okruenja, svaki lan tima ima svoju
ulogu i odgovornosti. U velikim tvrtkama u svijetu ovakva organizacijska
struktura je ve uobiajena, dok se u Hrvatskoj jo ne moe susresti u praksi.

5.1. Tri okruenja za osiguranje kvalitete podataka

Postoje tri osnovna okruenja za osiguranje kvalitete podataka, gdje se moe

osigurati da e podaci u skladitu podataka imati najvii stupanj kvalitete.
Prva je instanca, naravno, ienje podataka u operativnom okruenju.
Druga prilika je ienje podataka u integracijskom i transformacijskom sloju
(procesu). Trea je prilika odravanje uitanih povijesnih podataka u samom
skladitu podataka.

5.2. ienje podataka na aplikacijskoj razini

ienje podataka na aplikacijskoj razini ini se najprirodnije mjesto za

osiguranje kvalitete podataka. to su podaci ii na toki ulaza, bolja je
kvaliteta podataka u skladitu podataka. Teoretski, ako su na aplikacijskoj
razini podaci savreno isti, vie ih nigdje nee biti potrebno istiti.

40 / 95
Naalost, u stvarnom ERP-u i transakcijskim sustavima to nije mogue.
Nekoliko faktora onemoguava da aplikacija bude jedino rjeenje za
probleme vezane za kvalitetu podataka.

Prvi problem je pitanje optimizacije aplikacije. Najbolja praksa je omoguiti

brzi unos, promjenu i brisanje podataka u aplikaciji. Implementacija dodatnih
kontrola i ogranienja moe usporiti aplikaciju; rad s aplikacijom moe uiniti
manje ugodnim te moe znaajno oslabiti produktivnost, to e dovesti do
loeg konanog rezultata. S druge strane, runi unos podataka daleko je od
savrenog, stoga je niska kvaliteta podataka u ovom sluaju neizbjena.

Druga potekoa je stanje same aplikacije. U mnogim sluajevima, aplikacija

je stara i nije dobro dokumentirana. Vrlo esto nije poznato gdje se nalazi
zadnja verzija izvornog koda aplikacije. est je sluaj i da su aplikacije
kreirane koritenjem zastarjelih alata i programskih jezika. Programeri koji su
prvotno kreirali neke aplikacijske module moda su davno otili iz kompanije.
Programeri aplikacija esto se boje ui u aplikacijski kod i znaajnije ga
mijenjati. Popravljanje jednog problema moglo bi uzrokovati pokretanje
itavog niza drugih problema. Krajnji rezultat je da je aplikacija loija nego to
je bila prije popravljanja.

Razlog zato osobe koje rade na razvoju aplikacije dvaput razmisle prije no
to se vrate u stari kod je da oni ne vide koristi od toga jer su fokusirani na
postojee zahtjeve i ne vide hitnost, ili bilo kakvu motivaciju da se vraaju u
stari kod i da ga mijenjaju kako bi rijeili tue probleme.

Naalost, ak i kada bi bilo mogue oistiti podatke na aplikacijskoj razini, jo

uvijek je potrebno podatke istiti i kasnije, prilikom prebacivanja u skladite
podataka. Razlog zato je integracijsko i transformacijsko ienje jo uvijek
potrebno, ak i kada su aplikacijski podaci savreni, lei u tome to
aplikacijski podaci nisu integrirani s podacima iz drugih aplikacija i sustava.

41 / 95
Kompanije koje implementiraju skladite podataka obino imaju nekoliko
aplikacijskih sustava koji imaju suelja na aplikacijskoj razini samo za
podatke koji se razmjenjuju, no glavni podaci nisu sinkronizirani.

5.3. ienje podataka u integracijskom sloju

ienje podataka u integracijskom i transformacijskom sloju mogue je

samo kada su podaci izvueni iz aplikacija u privremeni spremnik.

Svaka aplikacija ima vlastitu interpretaciju podataka, kako je to originalno

odredio dizajner aplikacije. Definicije polja podataka, kljuevi, atributi,
strukture, kodne stranice i pravila dekodiranja razlikuju se izmeu aplikacija.
Isto tako, veze meu podacima unutar i izmeu sustava moda e ostati
neotkrivene.

Kako bi skladite podataka sadravalo integrirane podatke, mnoge

aplikacijske strukture i konvencije moraju se integrirati u jedinstveni skup
struktura i konvencija. Anomalije podataka o imenima, adresama, opisima i
iframa rauna drugo su podruje za popravljanje.

Nekonzistentnosti izmeu definicija metapodataka i sadraja podataka s

vremenom dolaze do izraaja, npr. imena pravnih osoba pomijeana su s
imenima fizikih osoba, u adresama nedostaju neki podaci ili su postojei
podaci zastarjeli, neke informacije su nepotpune zato to su definicije polja
za unos podataka nezadovoljavajue, specijalni znakovi se koriste kao
separatori, nedostaju neke vrijednosti u poljima s podacima, koriste se
razliite kratice, i sl.

Ovi se problemi kvalitete podataka mogu nai u svakom skupu aplikacijskih

podataka te mogu dovesti u pitanje ostvarivanje korporativne inteligencije.
Integracijski i transformacijski sloj je kljuna prilika za implementaciju
procedura za poboljanje kvalitete podataka, gdje e promjena na bolje imati

42 / 95
najznaajniji pozitivan poslovni rezultat, stoga e u ovom radu biti dan
naglasak upravo na ovu priliku.

Procesi koji e biti detaljnije opisani su ienje, ispravljanje, profiliranje,

uparivanje, obogaivanje, analiza i standardizacija podataka.

5.4. Odravanje povijesnih podataka u skladitu podataka

Odravanje povijesnih podataka u skladitu podataka od vitalne je vanosti

zbog toga to skladite podataka sadri podatke prikupljene kroz neki
vremenski period. Problem je u tome to se podaci s vremenom mijenjaju. U
nekim sluajevima, promjene su spore i zanemarive. No, u nekim
sluajevima promjene su brze i radikalne.

S opisanim promjenama javlja se i potreba za odravanjem kvalitete

podataka u skladitu podataka nakon to su podaci ve uitani u skladite
podataka. Najei nain za praenje promjena u podacima je koritenje
dimenzija koje se sporo mijenjaju.

Postoje tri osnovne vrste takvih dimenzija, koje su vrlo detaljno obraene u
teoriji skladitenja podataka te nekoliko hibridnih pristupa koji koriste neke od
znaajki pojedinih osnovnih tipova. Nekad su potrebna i radikalnija rjeenja,
koja se mogu prikazati kroz nekoliko jednostavnih primjera.

Prvi je primjer uvoenje Eura kao nove valute u Europskoj uniji 2000. godine,
to je sve prole transakcije obavljene u bivim valutama uinilo
neupotrebljivim i neusporedivim s novim transakcijama. Prema tome, svi stari
rauni i fakture morali su se u skladitu podataka pretvoriti u iznose izraene
u Eurima.

Drugi je primjer zamjena postojeeg zastarjelog (eng. legacy) sustava s

modernim transakcijskim sustavom, to se obino ini tako da se u novi
transakcijski sustav uitaju samo otvorene stavke iz zastarjelog sustava. Svi

43 / 95
povijesni podaci koji su ve uitani u skladite podataka moraju se pretvoriti i
transformirati tako da budu usporedivi s novim podacima u skladitu
podataka.

44 / 95
6. Pojmovi i algoritmi vezani za platforme za kvalitetu podataka

U ovom poglavlju e biti opisani pojmovi i najee koriteni algiritmi za

procjenu slinosti, standardizaciju i uparivanje koji se pojavljuju unutar
platformi za poboljanje kvalitete podataka, kako bi se mogle detaljno opisati
i ocijeniti pojedine platforme koje e biti usporeene u sljedeim poglavljima.
Rije je uglavnom o matematikim algortimima koji daju ocjenu slinosti te o
fonetskim algoritmima koji kodiraju imena temeljem naina na koji se
izgovaraju.

Kod implementacije algoritma unutar platformi za poboljanje kvalitete

podataka uvijek se postavlja prag slinosti (engl. treshold) te svi parovi koji
postignu rezultat iznad praga e biti proglaeni istovjetnim. Neke platforme
imaju mogunost definiranja i praga mogue slinosti (engl. clerical), koji je
nii od praga slinosti te se parovi koji postignu rezultat (engl. score) izmeu
ta dva praga proglaavaju potencijalno istovjetnim. Parovi koji postignu
rezultat ispod pragova proglaavaju se razliitim.

Kod nekih platformi mogue je za usporedbu dva niza paralelno koristiti

nekoliko algoritama te konaan rezultat dobiti izraunom teinskog prosjeka
na taj nain dobivenog rezultata, to osigurava najpouzdanije rezultate.
Pojmovi i algoritmi na koje e biti stavljen naglasak su sljedei:

Oznaavanje (engl. tokenization)

Soundex i Nysiis
Edit Distance algoritam
Hamming Distance algoritam
Jaro-Winkler algoritam
Bigram algoritam
Neizrazita (engl. fuzzy) logika

45 / 95
 6.1. Oznaavanje

Oznaavanje (engl. tokenization) je pojam koji se u raunarstvu koristi za

oznaavanje i po mogunosti klasifikaciju dijelova niza znakova koji je
potrebno obraditi. Oznake koji se dobiju kao rezultat procesa se zatim
prosljeuju sljedeim koracima u procesu obrade. Oznaavanje se esto
smatra dijelom procesa analize sintakse (engl. parsing).

U platformama za poboljanje kvalitete podataka, oznaavanje je naziv za

proces koji se koristi za oznaavanje pojedinih elemenata niza, kako bi se u
daljoj obradi niz mogao razdvojiti na sastavne dijelove i standardizirati.
Postoji pet osnovnih tipova oznaka:

Slovana oznaka koja se sastoji od alfabetskih znakova (Word)

Numerika oznaka koja se sastoji od brojanih znakova (Number)
Kod se sastoji od mijeanih alfanumerikih znakova (Code)
Inicijal je jedan alfabetski znak (Initial)
Simbol je punktuacija ili neki drugi simbol (Symbol)

U samom procesu oznaavanja, bitne su i dvije komponente koje se moraju

definirati. Prva komponenta je lista graninika koji razdvajaju pojedine
oznake to su najee razmak, kosa crta ili toka u hrvatskom jeziku.
Druga komponenta je lista znakova koje se kod oznaavanja treba ignorirati,
koja se ponekad ne treba koristiti.

Kod implementacije u pojedinim platformama za poboljanje kvalitete

podataka postoje i drugi tipovi oznaka osim pet osnovnih, koji ovise o
platformi. Na njih u ovom radu nee biti stavljen dodatni naglasak, budui da
se radi o izvedenicama osnovnih oznaka.

U samom procesu oznaavanja, neke platforme omoguavaju da se niz od

nekoliko rijei usporedi sa sadrajem postojeih rijenika te se za oznake koji
su naene u rijeniku koristi oznaka koja se definira prema sadraju rjenika.
Tako bi niz Marko Markovi Smith oznaen imao oblik word word word, a

46 / 95
oznaen s koritenjem rjenika hrvatskih imena i prezimena imao oblik ime
prezime word, budui da se Smith ne nalazi u rjeniku hrvatskih imena i
prezimena.

Poseban sluaj oznaavanja je oznaavanje na nivou pojedinog znaka u

nizu, gdje se radi analiza strukture pojedinog niza te se svakom znaku daje
oznaka radi li se o slovu, numerikom znaku ili simbolu. Ovakvo oznaavanje
je korisno kod analize oblika zapisa i standardizacije telefonskih ili matinih
brojeva.

6.2. Soundex i NIISYS algoritmi

Soundex je fonetski algoritam za indeksiranje imena po tome kako se

izgovaraju na engleskom. Svrha algoritma je prepoznati imena koja se isto
izgovaraju, na nain da se kodiraju na isti nain, kako bi se eliminirale manje
pogreke u zapisivanju poput dvostrukih slova. Soundex je najpoznatiji
fonetski algoritam [9], a razvili su ga Robert Russell i Margaret Odell te
patentirali jo 1918. godine.

Soundex algoritam uvijek sauva prvo slovo alfanumerikog niza, a ostala

slova zamijeni s brojkama. Vano je napomenuti da se sva pojavljivanja
suglasnika i znakova h,w i y eliminiraju, osim ako nisu na prvom mjestu.
Ostali suglasnici se kodiraju na sljedei nain:

1 b, f, p, v

2 c, g, j, k, q, s, x, z

3 d, t

4l

5 m, n

6-r

47 / 95
Ukoliko se znak s istom kodom pojavi dvaput za redom, koristi se samo
jedan kod. Takoer, maksimalna duina kodiranog niza je 4. Ukoliko je niz
krai od 4, do kraja se nadopunjava s nulama.

NIISYS algoritam je poboljana varijanta Soundex algoritma, koju je uveo

New York State Identification and Intelligence System 1970. godine, po emu
je algoritam i dobio naziv [9]. NIISYS algoritam daje poboljanje u
raspoznavanju 2,7% u odnosu na Soundex. Pravila kodiranja su znatno
sloenija.

Oba ova algoritma su implementirana u veini platformi za poboljanje

kvalitete podataka. Najvei problem oba algortima za nae prilike je to to su
napravljeni za engleski jezik te su za naa imena, koja su slavenskog
porijekla, praktino neupotrebljivi.

Postoji i algoritam koji se moe koristiti za indeksiranje slavenskih imena. Taj

algoritam poznat je kao Double Metaphone algoritam, a postavio ga je
Lawrence Phillips 2000. godine [9], koji osim engleskih moe indeksirati
slavenska, germanska, francuska i druga imena. Ovaj algoritam je vrlo
sloen primjerice samo slovo C se moe smjestiti u vie od sto razliitih
konteksta.

Ovaj algoritam ima javno objavljen kod za implementiraciju u programskim

jezicima Java, Perl i PHP, ali ga se ne moe nai u vodeim platformama za
poboljanje kvalitete podataka. Razlog tome je vjerojatno relativna novost
algoritma, a takoer i preteita usmjerenost platformi na englesko govorno
podruje.

48 / 95
 6.3. Edit Distance algoritam

Edit Distance algoritam [9] kreira rezultat slinosti za dva niza podataka
izraunom minimalnog broja transformacija odnosno troka za
transformaciju jednog niza u drugi ubacivanjem, brisanjem ili zamjenom
pojedinih znakova. to je rezultat vei, vea je i slinost izmeu dva niza.

Algoritam je postavio Vladimir Levensthein 1965. godine te se po njemu

esto naziva i Levensthein Distance.

Ovaj algoritam daje najbolje rezultate kada se usporeuju nizovi koji sadre
jednu rije ili kratki tekstualni nizovi, poput imena ili kratkih adresa.

Za primjer se mogu uzeti dva niza:

Kraljavieva Ul

Kraljevieva Ul.

Algoritam e izraunati troak zamjene a iz prvog niza s e u drugom nizu

te troak dodavanja toke na kraju prvog niza. U implementaciji algoritma u
pojedinoj platformi za poboljanje kvalitete podataka, ostvareni rezultat
slinosti bi trebao biti preko 0,9, to bi znailo da su ova dva niza slina
preko 90%.

Implementacija ovog algoritma u pseudo kodnoj funkciji, koja uzima dva niza
duljine m i n te izraunava rezultat slinosti, izgleda ovako [9]:

LevenshteinDistance(char s[1..m], char t[1..n])

// d is a table with m+1 rows and n+1 columns
declare int d[0..m, 0..n]

for i from 0 to m
d[i, 0] := i
for j from 1 to n
d[0, j] := j

49 / 95
 for i from 1 to m
for j from 1 to n
if s[i] = t[j] then cost := 0
else cost := 1
d[i, j] := minimum(
d[i-1, j] + 1, //
deletion
d[i, j-1] + 1, //
insertion
d[i-1, j-1] + cost //
substitution
)
return d[m, n]

6.4. Hamming Distance algoritam

Hamming Distance algoritam [9] postavio je Richard W. Hamming 1950.

godine u radu koji se bavio pronalaenjem pogreaka u prijenosu podataka.
Algoritam slui za usporedbu nizova iste duljine te daje rezultat koji kae
koliko zamjena treba napraviti da bi dva niza koja se usporeuju bila
istovjetna.

Dakle, ako su dva niza duljine sedam znakova potpuno jednaka, rezultat e
biti nula, ako se razlikuju u jednom znaku, rezultat e biti jedan, a ako se
razlikuju u svim znakovima, rezultat e biti sedam.

Algoritam je vrlo jednostavan za implementaciju, a najee se koristi za

usporedbu nizova kod kojih je bitna duljina i pozicija pojedinih znakova u
nizu, poput telefonskih brojeva, potanskih brojeva, matinih brojeva ili bilo
kojih drugih kodova.

50 / 95
 6.5. Jaro-Winkler Distance algoritam

Jaro-Winkler distance algoritam [9] postavio je W.E.Winkler 1999. godine,

kao varijantu Jaro distance algoritma koji je postavio M.A. Jaro deset godina
ranije.

Jaro distance algoritam daje izraun razliitosti, tj. distance dj dva niza s1 i s2,
kao:

dj = (m/a + m/b + (m-t)/ m) / 3

gdje je:

m broj znakova koji su "uparivi;

a i b su duljine nizova s1 and s2;
t je broj "premjetanja".

Dva znaka iz s1 i s2 se smatraju "uparivim" ako razmak njihovih pozicija nije

vei od polovice duljine duljeg niza, umanjene za jedan. Svaki znak iz niza s1
se usporeuje sa svim uparivim znakovima iz niza s2. Broj uparivih, a
razliitih znakova podjeljen s dva daje broj "premjetanja".

Jaro-Winkler distance algoritam razrauje Jaro distance algoritam na nain

da favorizira nizove koji su istovjetni u prvih nekoliko znakova. Ako ponovo
uzmemo nizove s1 i s2, njihova Jaro-Winkler distanca dw e biti:

dw = dj + (l * p * (1 dj))

gdje je:

dj is Jaro distanca za nizove s1 i s2

l je broj znakova koji su istovjetni na poetku oba niza
p je konstanta, odnosno faktor kojim se rezultat slinosti uveava
nizovima koji imaju takve zajednike prefikse

51 / 95
Jaro-Winkler Distance algoritam jedan je od algoritama koji daje najbolje
rezultate. Kod implementacija na pojedinim platformama za poboljanje
kvalitete podataka vrlo se esto koristi reverzna logika, tako da se umjesto
konstante za uveavanje rezultata koristi konstanta za penalizaciju odnosno
umanjenje rezultata ukoliko prvih l znakova na poetku niza nisu istovjetni.

Sustav za normalizaciju i uparivanje podataka baziran na implementaciji

Jaro-Winkler algoritma u Java programskom jeziku izveden je 2007. godine
za Croatia osiguranje te opisan u [13].

6.6. Bigram Distance algoritam

Bigram Distance algoritam [9] baziran je na analizi pojavljivanja parova

uzastopnih znakova u dva niza znakova. U prvom koraku se svaki niz podijeli
na podnizove od dva znaka, tako da se svaki znak u nizu osim zadnjeg
koristi kao poetni znak u podnizu. to je vei broj parova koji se pojavljuju u
oba niza, vei je rezultat koji algoritam daje.

Ovaj algoritam daje najbolje rezultate kod usporeivanja dugih nizova

znakova, poput dugih adresnih linija ili komentara i napomena. Ako se uzmu
kao primjer dva uobiajena imena Draen i Dragan moe se vidjeti kako
Bigram Distance algoritam funkcionira. Kada se oba ova imena razloe na
parove znakova dobija se sljedee:

Draen dr, ra, a, e, en

Dragan dr, ra, ag, ga, an

Dobiveno je ukupno 10 parova znakova, od kojih se po dva iz svakog niza

mogu upariti (oznaeni su italic fontom), tako da je ukupan rezultat 0,4,
odnosno 40%.

Vano je napomenuti da je Bigram Distance algoritam samo jedan od

algoritama koji pripada grupi n-gram algoritama, gdje n moe biti jedan, dva,
tri ili vie. N-gram algoritmi su vrlo dobro poznati u teoriji informacije.

52 / 95
Ti algoritmi se vrlo esto koriste u obradi i analizi teksta, ne samo u
platformama za poboljanje kvalitete podataka, nego i kod prepoznavanja
govora i u prediktivnim modelima. Ovisno o aplikaciji, n-gram algoritam moe
raditi sa znakovima ili rijeima kao jedininim elementima. Google neke od
svojih algoritama za raspoznavanje i pretraivanje temelji na n-gram
algoritmima.

Bigram Distance je algoritam koji je vrlo jednostavan za shvaanje, koritenje

i implementaciju te ga se moe nai implementiranog u veini vodeih
platformi za poboljanje kvalitete podataka.

6.7. Neizrazita logika

Koncept neizrazite (engl. fuzzy) logike bazira se na pretpostavci da kod

procesiranja podataka postoji mogunost djelomine pripadnosti nasuprot
uobiajene egzaktne logike pripadnosti odnosno nepripadnosti, odnosno na
ocjeni relativnih pretpostavki u donoenju zakljuaka.

Pojednostavljeno, neizrazita logika koristi IF [A] AND [B] THEN [C] pristup da
bi dola do rjeenja, umjesto uobiajenog matematikog modeliranja te je u
tome vrlo slina ljudskom nainu zakljuivanja. Vano je primijetiti da nema
ELSE opcije te da su u neizrazitnoj logici sve alternative definirane.

Kao primjer se moe koristiti ovjek koji se tuira i situacija da je voda koju
koristi prehladna i postaje sve hladnija, gdje bi neizrazitna logika dala
sljedee rezultate:

1) IF [voda je prehladna] AND [voda postaje hladnija] THEN [pojaaj toplu

vodu]

2) IF [voda je jako hladna] AND [voda postaje hladnija] THEN [brzo pojaaj
toplu vodu]

53 / 95
U ovom logikom procesu nigdje egzaktno nije definirana temperatura vode i
brzina hlaenja vode, ali zakljuci koji su izvedeni su potpuno logini. Ovakva
logika koristi se kod neegzaktnih premisa, ali ipak u implementaciji zahtijeva
numerike varijable koje ocjenjuju iznos nepreciznosti.

Prema toj logici, iznos nepreciznosti (pogreke) od traenog ishoda u drugoj

izjavi je vei nego u prvoj. Ovakva nedirektna logika omoguava
raspoznavanje slinih uzoraka te se koristi za eliminiranje pogreaka i
umova u nizovima.

U platformama za poboljanje kvalitete podataka neizrazitna logika koristi se

kod usporedbe i grupiranja atributa po slinosti, kako bi se omoguila
standardizacija i uparivanje podataka.

54 / 95
7. Proces poboljanja kvalitete podataka

Kao to je ranije navedeno, kvaliteta podataka u uem smislu se odnosi na

kvalitetu sadraja podataka u skladitu podataka te se uglavnom odnosi na
ienje i korekciju podataka koji iz operativnih sustava dolaze u skladite
podataka.

Procesi poboljanja kvalitete podataka za vrijeme integracije i transformacije

podataka ponajvie su usmjereni na ienje podataka o klijentima, kao to
su imena i adrese, budui da se u tim podacima nalazi najvie pogreaka i
nekonzistentnosti. Postoji nekoliko osnovnih tipova koraka u procesu
poboljanja kvalitete podataka koje bi trebalo uzeti u obzir ili implementirati
unutar procesa, kako bi se u skladitu podataka osigurala visoka kvaliteta
podataka, a to su:

Analiza i profiliranje,

Standardiziranje i ispravljanje,

Obogaivanje,

Uparivanje i

Preivljavanje.

Svi navedeni koraci se ne moraju koristiti u procesu, a problem i potreba

odreuju koji od njih e biti upotrijebljen.

U nastavku ovog poglavlja svaki od tih koraka biti e detaljnije opisan, kako
bi kasnije u radu bio napravljen prikaz kako su konkretno implementirani.

7.1. Analiza i profiliranje

Analiza i profiliranje je prva faza procesa poboljanja kvalitete podataka. U

ovoj fazi se analiziraju sadraj i uzorci podataka kako bi se opisali uzorci
izvora podataka koji se najee pojavljuju. Informacije koje se skupljaju na

55 / 95
ovaj nain pomau pri utvrivanju razine trenutne kvalitete podataka i pri
odluivanju koje bi aktivnosti za poboljanje kvalitete podataka trebalo uzeti u
obzir kod sljedeih koraka. Profiliranje je vrlo mono sredstvo za
razumijevanje sadraja podataka. Osim vrijednosti i frekvencija pojavljivanja
pojedinih vrijednosti, alati za profiliranje omoguavaju mnoge druge
funkcionalnosti, poput profiliranja upita koji povezuju vie tablica, grafikog
prikaza vrijednosti te kreiranje pravila za standardizaciju i validaciju koja
poboljavaju vrijednost i razumljivost izraenog profila.

Kao primjer takve analize, uzorak broja pojavljivanja nekih uobiajenih rijei u
sluajnom uzorku od 8.000 adresa prikazan je u Tablici 7.1.

Broj pojavljivanja Rije

00000085 B

00000050 BANA

00000157 BRAE

00000116 BRDO

00000112 BREG

00000088 BRIJEG

00000306 CESTA

00000089 D

00000059 DOL

00000085 DON

00000114 DONJA

00000076 DONJE

00000243 DONJI

Tablica 7.1: Uzorak pojavljivanja nekih rijei u uzorku od 8.000 hrvatskih

adresa

56 / 95
 7.2. Standardizacija i korekcija

Standardizacija i korekcija je sljedea faza procesa poboljanja kvalitete

pdoataka. U ovoj se fazi imena i adrese standardiziraju kako bi se uskladili s
listom vaeih imena, adresa, potanskih brojeva i gradova. Softverske
platforme za poboljanje kvalitete podataka moraju imati prethodno
definirana pravila da bi se omoguila standardizacija podataka.

Ova pravila ukljuuju tablice s vaeim podacima, kao i procedure koje

objanjavaju kako se odnositi prema svakom uzorku koji se moe pronai
unutar podataka te kako ga standardizirati. Na primjer, ako u izvornim
podacima postoji vrijednost Kraljavieva Ul. 2B/3, ta bi pravila trebala
prepoznati dijelove adrese prikazane u Tablici 7.2.

Dio adrese Kontekst

Kraljavieva Ime ulice

Ul. Kratica vrste ulice

2 Kuni broj

B Dodatak kunom broju

/ Separator

3 Kat

Tablica 7.2: Dijelovi adrese

Kada se ispravno prepoznaju dijelovi adrese, tada se oni mogu ispraviti. U

naem bi sluaju trebalo prepoznati i ispraviti dvije stvari:

57 / 95
 1) Kraljavieva nije vaee ime ulice pa e se zamijeniti s
Kraljevieva, temeljeno na slinosti uzorka netono napisane i
ispravne vrijednosti.

2) Ul. je kratica za Ulica.

Standardizacija se temelji na pragu tolerancije. Prag tolerancije odreuje

stupanj nesigurnosti koja se moe tolerirati u zapisivanju neke oznake.
Algortimi opisani u 6 koriste se kako bi se uzele u obzir fonetske greke,
sluajna umetanja, brisanja te zamjena i transpozicija znakova.

Posljednji korak ovog dijela procesa je preoblikovanje podataka u vaeu

formu koja e se koristiti u kasnijim koracima procesa.

7.3. Dopunjavanje

Dopunjavanje je faza procesa u kojem se nedovreni i nepotpuni podaci

upotpunjavaju nedvojbeno ispravnim podatkovnim elementima.

Primjerice, ako adresa kupca ima vaee ime grada, moe se dopuniti s
vaeim potanskim brojem, upanijom ili regijom. Takoer, imena se mogu
nadopuniti odgovarajuim prefiksima za oslovljavanje.

Ovaj se korak ne koristi esto zbog toga to se veina dopuna moe obaviti u
fazi standardizacije i korekcije.

7.4. Uparivanje

Uparivanje je faza procesa poboljanja kvalitete podataka u kojoj se zapisi

uparuju s podacima iz razliitih izvora, ovisno o relativnoj slinosti.

Obino se proces uparivanja obavlja kroz nekoliko faza. U svakoj fazi koristi
se jedan ili vie atributa za blokiranje dijelova skupova zapisa koji e se

58 / 95
upariti te se analizira jedan ili vie atributa kako bi se otkrilo da li su oni
dovoljno slini da bi se radilo o podacima vezanim za istu osobu ili
kuanstvo.

Ako slinost nadmauje definirani prag slinosti, upareni zapis e dobiti

jedinstveni dodatni identifikator koji e ih definirati kao podatke o istom kupcu
te e ih iskljuiti iz sljedeih faza.

Primjerice, u jednom prolazu jedinstveni identifikator osobe moe biti blokiran

te e se usporediti atributi imena i prezimena. U drugom prolazu skupovi
zapisa mogu blokirati ime i prezime, a usporedit e se atributi ulice i grada.
Ove se grupe dodaju postojeima, nastalim u prvom prolazu. U sljedeim
prolazima mogu se definirati dodatna pravila koja e oznaiti neke od
preostalih podataka. Vano je napomenuti da se tu radi u grupama koje
imaju dva ili vie zapisa, a ne iskljuivo o parovima od dva zapisa.

Osim zapisa koji sigurno predstavljaju iste subjekte, postoje i parovi koji
moda predstavljaju iste subjekte, odnosno relativna slinosti ima vrijednost
manju od praga slinosti, a veu od praga sigurne razliitosti. Za takvo
uparivanje koristi se engleski izraz clerical. Kod takvih uparivanja potrebna je
ljudska intervencija kako bi se potvrdilo ili opovrgnulo da je rije o pravom
uparivanju te se za to najee koriste web suelja koja su standardni dio
funkcionalnosti vodeih platformi za poboljanje kvalitete podataka.

Slika 7.1. Informatica Data Quality Assistant primjer web aplikacije u kojoj
poslovni korisnik potvruje predloeno uparivanje

59 / 95
 7.5. Preivljavanje

Preivljavanje je zadnja faza procesa poboljanja kvalitete podataka gdje se

izmeu svih uparenih zapisa biraju oni najbolji, koji se esto naziva zlatni ili
referentni zapis (engl. golden record). Svi preivjeli podaci ne moraju nuno
potjecati iz samo jednog zapisa te najee sadre dijelove nekoliko zapisa
iz razliitih izvornih sustava koji mogu potpuno opisati kupca.

Primjerice, identifikator, ime, prezime i vrsta oslovljavanja mogu se preuzeti

iz zapisa iz transakcijskog sustava, a adresa i broj telefona mogu biti iz
zapisa iz kontakt centra.

Za zapise koji su upareni sa sigurnou veom od definiranog praga

slinosti, odabir atributa koji e preivjeti je najee automatiziran prema
pravilima definiranim u standardizaciji, odnosno prema nivou pouzdanosti
izvornog sustava iz kojeg dolaze.

Za zapise koji su clerical, osoba (data steward) koja potvruje uparivanje,

kroz korisniko suelje odabire atribute koji e ii u zlatni zapis, a postoji i
mogunost direktnog unosa ako atribut ni iz jednog izvornog zapisa nije
ispravan.

Uparivanje i preivljavanje vrlo esto su procesi koji se deavaju istovremeno

kroz jedno korisniko suelje koje je opisano u 7.4

60 / 95
8. Dobavljai i platforme za poboljanje kvalitete podataka

Softverske platforme koji slue za profiliranje, ienje, standardiziranje,

uparivanje i preivljavanje podataka poznati su kao platforme za poboljanje
kvalitete podataka. Analitiari trita kao to su Gartner Group [8] i Forrester
[4] u svojim trinim analizama koje redovno publiciraju obuhvaaju veinu
znaajnijih dobavljaa.

Ti su dobavljai povijesno bili manji od dobavljaa platformi za poslovnu

inteligenciju i integraciju podataka, pa je trini trend prije nekoliko godina
bila jaka konsolidacija, gdje su velike kompanije na podatkovnom tritu
kupile manje dobavljae platformi za poboljanje kvalitete podataka te
integrirale njihovu tehnologiju u svoje platforme za integraciju podataka [4].

U posljednjih nekoliko godina su IBM, Informatica, SAP i SAS, zahvaljujui

svojim cjelovitim rjeenjima, preuzele znaajan trini udio na tritu platformi
za poboljanje kvalitete podataka, nadograujui se s ovim dijelom ponude
na integracijska rjeenja.

Takoer, ove tvrtke na tritu platformi za poboljanje kvalitete podataka

imaju i vodee poloaje prema analitiarima [8]. Jedini znaajan samostalan
dobavlja na tom tritu ostao je Trillium Software. Ostali vaniji dobavljai
poput Oraclea i Microsofta donose odreene funkcionalnosti za upravljanje i
poboljanje kvalitete podataka u trenutnim verzijama svojih proizvoda, no
zasad bez znaajnijeg trinog utjecaja.

Iako su platforme za poboljanje kvalitete podataka dobro prihvaene u SAD-

u, postoje dva glavna problema zato je njihova prihvaenost na globalnoj
razini jo uvijek ograniena.

Prvi razlog je to ovi alati jo uvijek nisu u potpunosti integrirani s

platformama za integraciju podataka i, iznenaujue, vrlo esto je potrebno
uloiti mnogo truda kako bi se integrirala dva proizvoda, ak i od istog
dobavljaa, ime bi se trebala osigurati integracija korporativnih podataka.

61 / 95
Drugi razlog je problem s pravilima potrebnima za to da platforme pravilno
rade s imenima i adresama. Pravila su specifina za pojedine jezike i drave,
a veina je dobavljaa kreirala i prilagodila ova pravila za SAD i nekoliko
najvanijih svjetskih jezika engleski, njemaki, francuski i panjolski te u
zadnje vrijeme sve ee i za jezike Dalekog Istoka.

U Hrvatskoj se, u donekle znaajnijoj mjeri, moe osjetiti prisustvo nekoliko

dobavljaa, ije proizvode je autor koristio na stvarnim projektima te e u
nastavku rada biti detaljnije opisani i usporeeni. U ovom sluaju rije je o
dvije prave platforme za poboljanje kvalitete podataka IBM QualityStage i
Informatica Data Quality te o dvije, u nas vrlo este, platforme za integraciju
podataka odnosno primarno za punjenje skladita podataka, s limitiranom
funkcionalnosti za ienje podataka Oracle Warehouse Builder / Data
Integrator i Microsoft SQL Server Integration Services.

U Hrvatskoj su formalno prisutni SAS i SAP, ali nisu bitnije usmjereni prema
implementaciji rjeenja za poboljanje kvalitete podataka.

Autoru nije poznato da li netko u regiji koristi Trillium.

8.1. IBM QualityStage

IBM QualityStage je nastao evolucijom platforme Vality koje je tadanji

Ascential kupio 2002. godine. Arhitektura tog proizvoda je bila prilino
zastarjela. Primjerice, mogao ja kao izvor i izlaz koristiti samo datoteke s
fiksnom duljinom kolona, nazivi datoteka i kolona mogli su imati do osam
slova, a nije postojao nikakav relacijski repozitorij metapodataka.

Vizualno korisniko suelje bilo je vrlo rudimentarno, dok se za razvoj pravila

koristio vrlo sloen i specifian programski jezik. Unato svim tim manama,
platforma je imala odline ugraene algoritme te je funkcionirala vrlo stabilno
i s kvalitetnim rezultatima.

62 / 95
U novijim verzijama, unazad nekoliko godina, QualityStage je integriran s
DataStage platformom za integraciju podataka te veina ovih problema osim
specifinog programskog jezika u aktualnim verzijama vie nije prisutna

Moda jedina ozbiljnija zamjerka aktualnoj inaici QualityStage platforme je

nepostojanje web suelja za poslovne korisnike i analitiare, pomou kojeg bi
oni direktno mogli raditi na poboljanju kvalitete podataka. Takoer,
platforma za profiliranje Information Analyzer je potpuno odvojen proizvod te
funkcionalnosti nisu integrirane, iako je profiliranje prvi korak u procesu
poboljanja kvalitete podataka.

U naoj regiji IBM QualityStage koristi T-Mobile Hrvatska.

8.2. Informatica Data Quality

Osnova Informatica Data Quality platforme su dva proizvoda koje je

Informatica dobila kupovinom tvrtke Similarity Systems. Jedan proizvod je bio
namijenjen za profiliranje, a drugi za poboljanje kvalitete podataka.

U dananjoj verziji, platforma za kvaltietu podataka Informatica Data Quality

ima i sve potrebne funkcionalnosti za profiliranje. Uz profiliranje, postoje i
dodatne komponenete za utvrivanje identiteta osoba te za validaciju i
standardizaciju adresa za veinu drava u svijetu. Informatica Data Quality je
u potpunosti integrirana s Informatica PowerCentrom, platformom za
integraciju podataka.

Bitna strateka odrednica openitog razvoja Informatica platformi je

integracija aktivnosti poslovnih i IT funkcija. To je razlog zbog kojeg
Informatica Data Quality ima i web aplikaciju koja se naziva Analyst, u kojoj
poslovni korisnici mogu profilirati i pregledavati podatke, kreirati jednostavna
pravila, kreirati kljune indikatore za praenje kvalitete podataka, pratiti
povijest izvravanja procesa i rezultata, verificirati uparene zapisa, odnosno
pregledavati, popravljati i verificirati odbaene zapise.

63 / 95
Slika 8.1. Informatica Data Quality Analyst suelje u web pretraivau
namjenjeno primarno poslovnim korisnicima

Usporeujui s funkcionalnostima drugih vodeih platformi, autor je miljenja

da je Informatica Data Quality trenutano najpotpunije i najfleksibilnije
rjeenje na tritu.

U naoj regiji Informatica Data Quality koriste Hrvatski, Slovenski i

Crnogorski telekom.

8.3. Oracle Warehouse Builder i Oracle Data Integrator

Oracle nikada nije imao ozbiljniji fokus na razvoj ili akviziciju specifine
platforme za poboljanje kvalitete podataka. Oba njihova proizvoda za
integraciju podataka imaju neke osnovne funkcionalnosti za poboljanje
kvalitete podataka, ali u obimu i kvaliteti koja nije usporediva s platformama
Informatice i IBM-a.

64 / 95
Pristup Oraclea se najee temeljio na rjeenjima u kojima se kao ugraena
funkcionalnost (engl. OEM original equipment manufacturer) koristi neka od
postojeih platformi na tritu. Ovisno o tome da li je neko rjeenje plod
internog razvoja ili je dolo kroz akviziciju kojih je Oracle napravio vrlo mnogo
u proteklih desetak godina u razliitim podrujima, najee su u Oracleovim
rjeenjima ugraene platforme Informatice i Trilliuma.

Autoru nije poznato da netko od veih korporativnih korisnika u naoj regiji

koristi Oracle proizvode za poboljanje kvalitete podataka sustavno i u
ozbiljnijem obimu.

8.4. Microsoft SQL Server Integration Services

Microsoft unutar svoje integracijske platforme nudi vrlo bazinu

funkcionalnost za poboljanje kvalitete podataka, koja od prethodno opisanih
funkcionalnosti pokriva samo uparivanje i grupiranje temeljem usporedbe
nejednakih vrijednosti po slinosti koritenjem Fuzzy logike.

Za to se koriste dvije ugraene transformacije Fuzzy Lookup i Fuzzy

Grouping.

Fuzzy Lookup set ulaznih podataka uparuje s ve postojeim setom

referentnih podataka prema odabranom kljuu ili kljuevima te na temelju
procjene da li se radi o podatku koji se nalazi ili ne nalazi unutar referentnog
seta usmjerava ulazni podatak u jedan od dva izlazna seta novi podatak ili
ve postojei podatak.

Fuzzy Grouping uzima set ulaznih podataka, unutar njih pronalazi grupe
zapisa koje smatra jednakima te ih sukladno tome u izlaznom setu grupira.
Kod obje transformacije moe se podesiti koji e se znakovi smatrati
graninicima te podesiti prag minimalne slinosti.

65 / 95
Iako je rije o elementarnoj funkcionalnosti uparivanja i deduplikacije, u
odreenim sluajevima na projektima ove transformacije su se ve pokazale
izuzetno korisnima, pogotovo kod konsolidacije matinih podataka o
klijentima koji dolaze iz vie razliitih operativnih aplikacija.

Dakle, od pet osnovnih funkcionalnosti za poboljanje kvalitete podataka

Microsoft SQL Server Integration Services ima implementiranu samo jednu.

Microsoft je za sljedeu verziju platforme (kodno ime Denali, SQL Server

2012) najavio implementaciju i dodatnih transformacija koje e se baviti
problemima vezanim za profiliranje, standardizaciju i dopunjavanje.

66 / 95
9. Proces lokalizacije i izrade pravila za Hrvatsku

Prije no to se pone koristiti platforma za poboljanje kvalitete podataka s

ciljem ienja podataka koji se koriste u hrvatskim kompanijama, potrebno
je kreirati potrebna pravila obrade podataka za Hrvatsku.

Prvi korak je osiguranje odgovarajue potpore hrvatskim kodnim stranicama

koje trebaju izraditi osobe zaduene za razvijanje platformi i koje trebaju biti
kodirane unutar samog proizvoda. Na sreu, u Hrvatskoj se koriste Latin II
kodne stranice koje se koriste i u mnogim drugim srednjoeuropskim
zemljama, pa je veina dobavljaa ve izradila potporu za Windows-1250 i
ASCII8859-2 kodne stranice. Naalost, to je samo jedan olakavajui faktor
koji e omoguiti kreiranje lokalnih pravila.

Drugi i mnogo zahtjevniji korak je kreiranje nekoliko pravila koja e osigurati

funkcionalnosti platforme za ienje i standardiziranje hrvatskih podataka.
Ova su pravila nainjena od nekoliko komponenti koje su za svaku platformu
razliita te se trebaju dodatno razviti i pripremiti za koritenje.

U nastavku e biti prikazano kako se za standardizaciju hrvatskih imena i

adresa prilagoavaju dvije najprisutnije platforme na tritu IBM Quality
Stage i Informatica Data Quality.

9.1. IBM QualityStage

Najmanje jedan skup pravila potreban je za ienje podataka koji se odnose

na imena, jedan za adrese i jedan za gradove. Osnovne komponente skupa
pravila su Dictionary File, Klasifikacijska tablica, Pattern-Action File, Lookup
tablica i Override tablica.

67 / 95
1) Dictionary File definira polja za izlaznu datoteku ili tablicu skupa pravila.
Ova datoteka sadri listu domena i polja za uparivanje i izvjetavanje.
Svako polje je identificirano pomou kratice, na primjer IG za Ime Grada.
Ovdje se takoer mogu pronai informacije o tipu podataka (npr.
character) i njihovoj duljini.

2) Klasifikacijska tablica omoguuje procesu standardizacije da identificira i

klasificira kljune rijei, kao tu su ime ulice, tip ulice, smjerovi i sl., tako
da osigura standardne kratice za svaku rije i listu klasifikacijskih oznaka
koje se tijekom obrade pridruuju pojedinim elementima podataka. Stadij
standardizacije koristi Klasifikacijsku tabelu za identifikaciju i klasifikaciju
kljunih rijei, kao to su tip ulice i vrsta oslovljavanja. Klasifikacijska
tablica omoguuje standardizaciju i ovakvih rijei.

3) Pattern-Action File sadri pravila standardizacije; to su akcije izvrenja na

temelju danih uzoraka oznaka. Standardizacija zapoinje s rastavljanjem
svih elemenata adresa na oznake. Svaka oznaka je rije, broj ili
kombinacija odvojena pomou jednog ili vie razmaka. Kako se formiraju
oznake, u isto vrijeme svaka se oznaka klasificira tako da se provjeri da li
se ve nalazi u Klasifikacijskoj tabeli. Ako ve postoji, pridruen je
odreenoj klasi. Ako se ne nalazi u tabeli, oznaka se dodjeljuje jednoj od
standardnih klasa: brojevima, slovima, nepoznatim ili nekim posebnim
znakovima.

4) Lookup tablice sadre informacije specifine za odreeni skup pravila; na

primjer, Lookup tablica sadri imena ukljuena u skup pravila vezana za
imena. Sadraj ovih tablica moe se po potrebi i runo ureivati.
Ukljuene tablice ovisne su o skupu pravila koja se odnose na njih.

5) Override tablice nadopunjavaju Klasifikacijsku tabelu i Pattern-Action File

tako da tijekom obrade pruaju dodatne upute. Informacije u Override
tablicama imaju prednost pred sadrajem datoteka iz prve etiri toke.
Ove tablice omoguuju prilagodbu ponaanja tijekom oznaavanja i
standardizacije ako su rezultati koji su dobiveni netoni ili nepotpuni.

68 / 95
Da bi se dovrila lokalizacija pravila za hrvatski jezik, potrebno je kreirati tri
od pet opisanih komponenti: Klasifikacijsku tabelu, Lookup tablice i Pattern-
Action file. Dictionary File koji definira strukturu je uglavnom isti kao i za
skupove pravila za druge jezike. Override tablice se kreiraju u izvrnom
okruenju, s ciljem finog podeavanja pravila. Naalost, javni izvori koji mogu
pomoi pri kreiranju Lookup i Klasifikacijskih tablica nisu dostupni, osim liste
hrvatskih potanskih ureda.

Klasifikacijska tablica za svako pravilo kreirana je na temelju analize

podataka pronaenih u nekoliko razliitih velikih izvora podataka. Sve
mogue razliite verzije iste kljune rijei moraju se nalaziti u Klasifikacijskoj
tablici.

Oznaka Standardna vrijednost

AV AVENIJA

AVENIJA AVENIJA

OD ODVOJAK

ODV ODVOJAK

ODVOJAK ODVOJAK

OGRAN OGRANAK

OGRANAK OGRANAK

UL ULICA

ULICA ULICA

ET ETALITE

ETAL ETALITE

ETALITE ETALITE

Tablica 9.1. Dio klasifikacijske tablice za HRADDR pravilo

69 / 95
Lookup tablica za svako se pravilo kreira na slian nain kao i Klasifikacijska
tablica. Primjerice, za kreiranje Lookup tablice za osobna imena biti e
koritena razliita imena iz nekoliko velikih izvora. Ovu bi listu trebalo
detaljno provjeriti i utvrditi ima li nepravilno napisanih imena, moguih
prezimena ili pak nehrvatskih imena.

Ovo iziskuje mnogo vie vremena nego kreiranje Lookup tablica. Isto tako,
Klasifikacijske tablice zahtijevaju s vremenom mnogo vie odravanja.

Kreiranje Pattern-Action datoteke je najzahtjevniji dio procesa lokalizacije.

Prvo treba analizirati sve uzorke podataka. Nakon toga, za sve mogue
uzorke, akcije e se definirati tako da se svaka oznaka stavi u odgovarajuu
kategoriju. Kada se oznake kategoriziraju, mogu se upariti s Lookup
tablicama, pa se standardizirani podaci mogu preoblikovati.

Hrvatske adrese sadre mnoge specifinosti koje se ne mogu pronai u

drugim zemljama. Rimski brojevi koriste se za odreivanje dijelova ulica, kao
na primjer X. Kainski odvojak 12 B, a platforme za poboljanje kvalitete
podataka ih prepoznaju kao kratice, a ne kao brojeve.

Drugi veliki problem bile su nejednoznane veze izmeu potanskih ureda i

potanskih brojeva. Na primjer, i Samoborska 15, Odranski Obre, 10010
Novi Zagreb i Samoborska 15, 10010 Odranski Obre vaee su adrese.
Kako bi se to rijeilo, uveden je jo jedan atribut adrese, tzv. naselje, pa je
uzorak prepoznavanja postao jo sloeniji.

Dodatna oteavajua okolnost je to programski jezik koji se koristi za

kreiranje pravila nije neki od uobiajenih programskih jezika, nego vlastito
interno razvijeno rjeenje koje najvie podjea na assembler te je razvoj
pravila spor i mukotrpan.

Na slici 9.1. prikazan je izvadak koda koji obrauje samo jednu proceduru
kod obrade hrvatskih adresa. Cijela Pattern-Action datoteka ima vie od dvije
tisue redova programskog koda.

70 / 95
;--------------------------------------------------------
-----
; Floors_and_Units SUBROUTINE Starts Here
;--------------------------------------------------------
-----
\SUB Floors_and_Units
; Floor and Unit Patterns
;
*F | ^ | $ | [ {FT} = "" & {FV} = "" ]
COPY_A [1] {FT}
COPY [2] {FV}
RETYPE [2] 0
RETURN
*U | ^ | $ | [ {UT} = "" & {UV} = "" ]
COPY_A [1] {UT}
COPY [2] {UV}
RETYPE [1] 0
RETYPE [2] 0
RETURN
\END_SUB

Slika 9.1.: Primjer procedure za obradu katova kao dijela adrese u Pattern-
Action Fileu u IBM QualityStage

Kad se kreiraju sve potrebne tablice i pravila, moe zapoeti faza testiranja i
podeavanja pravila. Ova faza oduzima mnogo vremena. Izlazne vrijednosti
procesa standardizacije usporeuju se s ulazima kako bi se pronali oni koji
nisu definirani ili nisu na odgovarajui nain obraeni u Pattern-Action Fileu.
IBM QualityStage ima kao dio korisnikog suelja ugraenu i funkcionalnost
za testiranje pravila, koja uneeni slijed znakova obrauje s odabranim
pravilom i prikazuje povratne rezultate.

71 / 95
Slika 9.2.: Funkcionalnost testiranja pravila u IBM QualityStage platformi

72 / 95
 9.2. Informatica Data Quality

Informatica Data Quality je, za razliku od IBM QualityStagea, puno

funkcionalnija platforma i za razvojnog strunjaka i za krajnjeg korisnika.

Prvi korak u procesu je kreiranje referentnih tablica. Referentne tablice se

kasnije koriste za proces standardizacije te se u njima nalaze podaci o
validnim imenima, prezimenima, prefiksima, sufiksima, adresama, naseljima,
potanskim brojevima i svemu ostalom to je potrebno. Ako se usporedi
Informatica Data Quality s IBM QualityStageom, sadraj referentne tablice u
Informatici pokriva sadraj Dictionary File i Klasifikacijske tablice.

Referentne tablice korisnik sam kreira, sadraj unosi direktno kroz web
suelje ili uvozi iz datoteka koritenjem jednostavnog arobnjaka. U
referentne tablice se osim navedenog sadraja koji je vezan za korisnike i
adrese moe unositi i drugi sadraj koji omoguava poboljanje kvalitete
podatak iz drugih domena, poput kodova i naziva proizvoda i slino.

Jednom kada su referentne tablice kreirane i popunjene, ostatak posla se

radi kroz Designer konzolu u kojoj se kreiraju preslikavanja koja ustvari
obrauju podatke. Svako preslikavanje se sastoji od jednog ili vie izvora
podataka, jedne ili vie izlaznih tablica i datoteka te od transformacija koje
obrauju podatke. Razliite transformacije rade razliite obrade podataka, od
oznaavanja, preko standardizacije i pretraivanja do uparivanja, uz
koritenje algoritama detaljno opisanih u poglavlju 6.

Unutar jednog preslikavanja moe se napraviti kompletna obrada jednog ili

vie setova podataka. Unutar preslikavanja na svakoj transformaciji je
mogue pregledati kako izgledaju izlazni podaci nakon te transformacije.
Kreirana preslikavanja mogu se koristiti u batch modu ili se mogu publicirati
kao web servis koji se poziva i koristi u realnom vremenu.

73 / 95
Slika 9.4.: Funkcionalnost izrade preslikavanja za kvalitetu podataka u
Informatica Data Quality Developer konzoli

Uz ovakav manualni pristup upravljanju kvalitetom podataka, Informatica ima

i dvije dodatne komponente Address Doctor i Identity Resolution, od kojih
se ova prva moe koristiti i za Hrvatsku.

Address Doctor je u stvari dodatna komponenta u kojoj se nalazi adresni

model veine svjetskih drava, pa tako i Hrvatske. Za izradu tog modela
koriste se podaci o gradovima, naseljima i ulicama koje u Hrvatskoj odrava i
ustupa za komercijalno koritenje Dravna Geodetska Uprava. U Designeru
postoji zasebna AddressDoctor transformacija koja ulaznu adresu, bilo
prikazanu u standardnim redovima, bilo u slobodnoj formi, validira i
standardizira prema ugraenom predlocima adresnog modela. Na izlazu se
osim standardizirane adrese dobiva i kd koliko Address Doctor neku adresu
smatra verificiranom i pouzdanom.

74 / 95
Slika 9.4.: Funkcionalnost predloaka adresnog modela u Informatica Data
Quality platformi

Identity Resolution komponenta je ustvari set referentnih tablica za imena,

prezimena, prefikse, formate identifikatora i brojeve putnih isprava za preko
ezdeset svjetskih drava, koja omoguava brzo pretraivanje,
standardizaciju i uparivanje podataka u stvarnom vremenu. Na alost, za ovu
komponentu Hrvatska jo nije podrana.

75 / 95
10. Studija sluaja T-Mobile Hrvatska

10.1. Okruenje projekta

T-Mobile Hrvatska jedan je od vodeih pruatelja usluga mobilne

komunikacije u Hrvatskoj. Orjentiranost na potrebe korisnika i kreiranje
usluga u skladu s njihovim eljama rezultiralo je izvrsnim rezultatima te je
vie od 2 milijuna korisnika prepoznalo kvalitetu i pouzdanost T-Mobilea.

Drutvena odgovornost jedna je od najvanijih stavki poslovanja T-Mobilea, a

kvalitetan odnos sa zajednicom u kojoj posluje tvrtka smatra osnovnim
preduvjetom za uspjeno poslovanje. T-Mobile paljivo njeguje i svoj imid
ekoloki osvjetene kompanije, to potvruje i sustav upravljanja okoliem
prema meunarodnoj normi ISO 14002. T-Mobile svaki dio svog poslovanja
prilagoava najsuvremenijim europskim i svjetskim ekolokim normama.

Glavno mjerilo prema kojem T-Mobile vrednuje svoje rezultate jest

zadovoljstvo korisnika te najvei naglasak stavlja na kvalitetu svojih usluga te
daljnju izgradnju i modernizaciju mree.

2010. godine je T-Mobile pripojen Hrvatskom Telekomu i u tijeku je

integracija informacijskih sustava dviju tvrtki.

10.2. Poslovne potrebe

T-Mobile Hrvatska je imao potrebu znaajno poveati svoju sposobnost

prikupljanja i analize poslovnih podataka kako bi podrao ostvarenje dva
poslovna cilja:

Poveanje i zatita prihoda

Poveanje operativne efikasnosti

76 / 95
Slijedom navedenog, zapoet je projekt implementacije skladita podataka
iji je sadraj bio namjenjen prvenstveno rukovoditeljima i poslovnim
korisnicima za donoenje pravovremenih i kvalitetnih poslovnih odluka,
putem koritenja pravovremenih i pouzdanih informacija. Na podacima iz
skladita podataka nadograuje se snana podrka za sustav poslovne
inteligencije.

Rezultat projekta bilo bi potpuno funkcionalno skladite podataka sa svim

potrebnim podacima definiranim na razini tvrtke, implementirano u fazama.
Projekt implementacije skladita podataka nije ukljuivao uvoenje platforme
za analizu i izvjetavanje. Uvoenje suelja za analizu i izvjetavanje
izvreno je kroz drugi, paralelni projekt.

10.3. Arhitektura rjeenja

Arhitektura rjeenja.prikazana je na slici 10.1:

Slika 10.1: Arhitektura T-Mobile DWH sustava

77 / 95
Pojedine komponente sustava su sljedee:

Data Sources (Izvori podataka) izvori podataka su operacijski

sustavi T-Mobile-a Hrvatska iz kojih se podaci ekstrahiraju za potrebe
punjenja skladita podataka.

Staging Area (privremeni spremnik) ovaj privemeni spremnik koristi

se tijekom transformacije i uitavanja podataka kako bi se poboljale
performanse uitavanja te omoguilo kombiniranje podataka koji
potjeu iz razliitih sustava. Spremnik je instanca Oracle 10g baze
podataka.

Data Warehouse Data Store (skladite podataka) ovo je kljuna

komponenta sustava koja slui kao spremnik u kojem su pohranjene
sve kljune poslovne informacije, obraene i pripremljene za potrebe
izvjetavanja i analize. Spremnik je instanca Oracle 10g Enterprise
Edition baze podataka s opcijom particioniranja.

Application Architecture ovaj dio arhitekture ukljuuje sustav za

razvoj procedura za ekstrakciju, transformaciju i uitavanje podataka u
skladite podataka i upravljanje tijekom procesa auriranja podataka u
skladitu podataka, arhiviranja podataka te migracije izmeu
razvojnog, testnog i produkcijskog okruenja.

Metadata Management Architecture arhitektura za upravljanje

metapodacima (podacima o podacima) omoguuje upravljanje
poslovnim i tehnikim metapodacima, metapodacima vezanim za
dizajn procedura za ekstrakciju, transformaciju i uitavanje podataka u
skladite podataka te metapodacima potrebnim za kreiranje
korisnikih izvjetaja i analiza. Ova komponenta osigurava
konzistentnost nazivlja i koritenosti pojedinih elemenata informacija
poput struktura, definicija ili kalkulacija kroz cijeli analitiki sustav.

Data Quality Architecture Moduli za osiguravanje kvalitete podataka

koriste se za profiliranje, standardizciju, uparivanje i ienje

78 / 95
 postojeih podataka o klijentima i adresama iz postojeih operativnih
sustava.

10.4. Kljuni indikatori poslovanja i dimenzije

Dvije su osnovne komponente na kojima se temelji definicija funkcionalnosti

sustava dimenzije i kljuni indikatori poslovanja (engl. KPI Key
Performance Indicators).

Indikatori su definirani kao pokazatelji vrijednosti mjera u kontekstu pojedinih

dimenzija, imaju numeriku vrijednost, usporedivi su s planskim vrijednostima
u vremenu te u kontekstu pojedinih dimenzija. Indikatori su bili grupirani u
grupe (obitelji) indikatora koji predstavljaju kljune grupe subjekata (logikih
entiteta) u mobilnoj komunikaciji.

Dimenzije opisuju zahtjeve za grupiranje i filtriranje numerikih podataka u

mjerema i vezanim kljunim pokazateljma poslovanja. Dimenzije su bile
grupirane u grupe (obitelji) dimenzija koje su pandan obiteljima indikatora.

Za potrebe projekta napravljena je matrica konteksta pojedinog kljunog

pokazatelja uspjenosti prema dimenzijama u kojem njegova analiza ima
smisla. Primjerice, analiza ostvarenog prometa ima kontekst u dimenziji
korisnika, dimenziji vremena i dimenziji koritenog proizvoda / usluge, ali
nema kontekst u obitelji dimenzija investicija jer nije direktno vezana ni uz
jednu investiciju.

10.5. Hardverska infrastruktura

Hardverska infrastruktura bazira se na Hewlet-Packard PA RISC rp7420

serverima s HP-UX operacijskim sustavom. U dva servera na raspolaganju
sustavu je 16 procesora, od kojih 6 koristi produkcijska instanca skladita

79 / 95
podataka, a 6 je na raspolaganju za procese integracije podataka i
produkcijski privremeni spremnik. Ova dva vora nalaze se u klasteru te u
sluaju da jedan vora nije dostupan drugi e preuzeti funkciju oba vora. Od
preostala etiri procesora, po dva procesora alocirana su za razvojnu i testnu
instancu skladita podataka.

Ukupna raspoloivost prostora za pohranu podataka je 5 TB, od kojih je

veina na raspolaganju za produkcijsku instancu skladita podataka. Druge
tri instance Oracle baze podataka koje zauzimaju znaajno manje diskovnog
prostora su razvojna i testna instanca skladita podataka te zajednika
instanca privremenog spremnika.

Dimenzioniranje sustava napravljeno je na nain da moe sadravati povijest

svih potrebnih poslovnih podataka to u detaljnom, to u agregiranom obliku.
Drugi bitan zahtjev kod dimenzioniranja sustava bio je da u previenom
nonom prozoru za uitavanje podataka bude mogue uitati sve potrebne
podatke iz operacijskih sustava.

10.6. Softverska infrastruktura

Kao baza podataka za sve instance skladita podataka i privremeni spremnik

koritena je Oracle 10g Enterprise Edition baza podataka. Kako je
implementacija projekta poela u rujnu 2004., ovo je bila prva implementacija
skladita podataka na Oracle 10g bazi podataka u naoj regiji koja je
premaila 1 TB podataka.

Za aplikacijsku, metapodatkovnu i arhitekturu za kvalitetu podataka koriteni

su su proizvodi tvrtke Ascential DataStage, MetaStage i QualityStage.
Tvrtku Ascential je u meuvremenu preuzeo IBM, koji je ove proizvode
nastavio podravati unutar InfoSphere obitelji proizvoda.

80 / 95
Kao osnova za modeliranje skladita podataka koriten je standardni
industrijski model skladita podataka za mobilne operatere tvrtke ADRM.
Kako je navedeni model bio razvijen temeljem poslovne prakse
sjevernoamerikih operatera, zahtijevao je znatnu doradu za potrebe projekta
u T-Mobile-u Hrvatska. Kao front-end platforma za izvjetavanje koriten je
Business Objects.

10.7. Implementacijski tim

Tijekom implementacije na projektu je radilo vie od dvadeset eksternih

strunjaka, uz veliki interni angaman djelatnika T-Mobile-a Hrvatska, kako
informatiara, tako i poslovnih korisnika.

Uloge unutar projekta su ukljuivale voditelja projekta i menadera osiguranja

kvalitete, koji su se brinuli za organizaciju projekta i kvalitetu isporuke tijekom
cijelog trajanja projekta.

Poslovni, podatkovni i sistemski analitiari su u suradnji s kljunim

korisnicima definirali funkcionalni dizajn sustava i kreirali funkcionalne
specifikacije.

Glavni arhitekt je na temelju funkcionalne specifikacije prilagoavao postojei

industrijski model i kreirao detaljnu tehniku specifikaciju, koja je ukljuivala i
definiranje strategije za auriranje podataka u skladitu podataka.

Eksperti za razvoj procedura za ekstrakciju, transformaciju, uitavanje i

kvalitetu podataka su kreirali i testirali procedure za punjenje podataka u
skladite.

UNIX i Oracle administratori brinuli su se za konfiguraciju, dostupnost,

performanse i sigurnost sustava.

81 / 95
Treneri su osigurali pravovremeni transfer znanja na djelatnike T-Mobilea,
kroz teajeve, kroz praktine radionice i zajedniki rad na razvoju procedura.

Testiranje je vreno prvo unutar tehnikog projektnog tima kako bi se

osiguralo da sve procedure za uitavanje rade prema specifikaciji te da su
podaci u skladitu podataka toni i konzistentni. Na kraju svakog modula je
raeno korisniko testiranje i prihvaanje modula, nakon ega je poelo
produkcijsko koritenje.

Nositelj projekta je bio Siemens Hrvatska, ija je nadlenost bila voenje

projekta, osiguranje kvalitete, integracija s izvornim sustavima i razvoj dijela
procedura za integraciju podataka. Implementirano je rjeenje tvrtke
Poslovna inteligencija, koja je u projektu bila zaduena za analizu, dizajn
modela, razvoj procedura za poboljanje kvalitete podataka i veeg dijela
procedura za integraciju podataka. Za infrastrukturu su se na projektu brinuli
S&T i Hewlet-Packard.

10.8. Proces implementacije

Projekt je bio podjeljen u pet faza, sukladno predvienoj funkcionalnosti i

izvornim sustavima iz kojih je vrena ekstrakcija podataka.

Na Slici 10.2 prikazan je model T-Mobile DWH sustava koji je u svakoj

sljedeoj fazi projekta proirivan i nadograivan novim funkcionalnostima.
Razliitim bojama oznaena su razliita subjektna podruja koja su
meusobno vie ili manje ovisna.

82 / 95
Slika 10.2.: Model T-Mobile DWH sustava

10.9. Implementacija rjeenja za poboljanje kvalitete

podataka

Procedure za poboljanje kvalitete podataka su u projektu implementacije

skladita podataka koritene prvenstveno za poboljanje kvalitete podataka o
korisnicima usluga T-Mobilea.

Kao prva i najzahtjevnija aktivnost odraeno je kreiranje potrebnih pravila

detaljno opisanih u poglavlju 9.1, budui da je bila rije o prvoj implementaciji
navedene platforme u Hrvatskoj [17].

U prvom koraku obrade su standardizirani adresni podaci za fizike i

korporativne postpaid korisnike. Inicijalno je koriten adresni model nabavljen
od Dravnog zavoda za statistiku (to je model koji se sada nabavlja od
Dravne Geodetske Uprave). Prilikom integracije Hrvatskog Telekoma i T-
Mobilea standardizacija je modificirana da koristi interni adresni model
Hrvatskog Telekoma.

U drugom koraku je napravljeno uparivanje novih korisnika s postojeim

korsnicima, kako bi se otkrili potencijalni duplikati. U tom koraku se kreira

83 / 95
tablica u kojoj se nalaze ID-evi potencijalnih duplikata te pripadajui
koeficijent slinosti.

Nakon drugog koraka podatke preuzima platforma za integraciju podataka

pomou koje se odvija dalje procesiranje.

10.10. Sljedei koraci

DWH sustav je u produkcijskom koritenju. U T-Mobileu se tim od pet

informatiara brine za odravanje i dalji razvoj sustava, a uz skladite
podataka isti tim odrava i Business Objects reporting sustav.

S dobavljaem je potpisan Service Level Agreement (SLA) koji T-Mobileu

osigurava podrku za odravanje i razvoj sustava. Sljedei koraci odnose se
uglavnom na poboljanja i dorade postojeeg modela te kreiranje procedura
za uitavanje podataka iz novoimplementiranih operativnih sustava. Vie
aktivnosti u sljedeem periodu moe se oekivati u dijelu koritenja podataka
sukladno potrebama krajnjih korisnika.

Poetkom 2011. godine sustav je migriran na aktualnu verziju 8.5, u kojoj su

funkcionalnosti DataStage i QualityStage platforme integrirane u jedno
funkcionalno okruenje.

10.11. Rezultati uvoenja sustava

DWH sustav u T-Mobileu je integrirano, skalabilno, kompleksno i

centralizirano skladite podataka organizirano prema specifinim zahtjevima
krajnjih korisnika. Sustav je namijenjen izvjetavanju (samostalno, od strane
krajnjih korisnika), analizi podataka i podrci u donoenju odluka.

84 / 95
DWH sustav sadri kompanijske podatke prikupljene iz cijelog niza
produkcijskih sustava. Podaci se, sukladno potrebama, uvaju u detaljnom
i/ili u agregiranom obliku kroz dui vremenski period, kako bi se osiguralo
povijesno praenje i izvjetavanje. DWH sustav je optimiziran za operacije
nad velikom koliinom podataka i zadovoljavajui odziv prema krajnjim
korisnicima, a bitno je naglasiti kako je kvaliteta podataka u DWH sustavu
unaprijeena u odnosu na izvorine sustave te da se kontinurano
poboljaava i unapreuje.

Krajnji rezultat je sustav koriten u cijeloj kompaniji, koji sadri kvalitetne

podatke te koji slui kao podloga za donoenje poslovnih odluka.

85 / 95
11. Zakljuak

Kvaliteta podataka se u organizaciji mora razmatrati u najirem moguem

kontekstu svih poslovnih sustava u okviru inicijativa za upravljanje podacima.
Skladite podataka je samo jedan od sustava u kojem se platforme za
kvalitetu podataka mogu koristiti.

Ako se gleda u irem kontekstu, kvaliteta podataka u skladitima podataka

se ne odnosi samo na kvalitetu samih podataka, nego i na kvalitetu definicije
podataka i kvalitetu prikaza podataka.

Niti jedna od vodeih platformi za poboljanje kvalitete podataka nije u

procesu standardizacije i ienja spremna za rad s imenima, prezimenima i
adresama specifinim za hrvatski jezik, odnosno nemaju ugraenu
odgovarajuu aplikacijsku logiku i referentne podatke za Hrvatsku. Prije
koritenja tih platformi potrebno je kreirati pravila za hrvatska imena i adrese.
Za neke platforme, kreiranje pravila za platformu za poboljanje kvalitete
podataka za hrvatski jezik nije lagan i tean proces, zbog arhitekture
platformi koje nisu jednostavne za kreiranje ekstenzija.

Jedna od glavnih smetnji je nedostatak javno dostupnih izvora vaeih

hrvatskih imena i adresa koji bi se mogli iskoristiti za kreiranje Klasifikacijskih
tablica. Drugi veliki problem je nejednoznana veza izmeu potanskih ureda
i potanskih brojeva, odnosno postojanje pojma naselja koji nije prisutan u
drugim europskim adresnim modelima, koja dodatno posloava kreiranje
pravila.

Faza podeavanja pravila nakon poetnog kreiranja zahtjeva najvie

vremena. Kada se jednom kreiraju, pravila zahtijevaju neprestano odravanje
i nadograivanje.

U zadnjih nekoliko godina pojavile su se tehnologije i nove verzije platformi s

kojima se radi potpuno u vizualnom okruenju. Proces razvoja i
implementacije rjeenja je znatno bri, a mogue je koristiti funkcionalnosti

86 / 95
za poboljanje kvalitete podataka u realnom vremenu za potrebe
implementacije rjeenja za upravljanje matinim podacima.

Stupanj prihvaenosti rjeenja za poboljanje kvalitete podataka na tritu je

jo uvijek prilino nizak, prvenstveno zbog tri glavna razloga. Prvi razlog je
organizacijska nespremnost velikih tvrtki na organizaciju funkcije upravljanja
kvalitetom podataka. Drugi razlog je nesvjesnost da takve platforme uope
postoje. Trei razlog je visoka cijena postojeih platformi.

U budunosti se moe oekivati da e i druge velike tvrtke u Hrvatskoj,

prvenstveno financijske institucije i telekomunikacijski operateri,
implementirati sustave za upravljanje kvalitetom podataka.

87 / 95
Reference

[1] Larry P. English: Data Quality: Meeting Customer Needs, Data

Quality Management, 1998, Pitney Bowes Inc.

[2] William H. Inmon: Enterprise Intelligence Enabling High

Quality in the Data Warehouse / DSS Enviroment, 2002,
Ascential Software Corporation

[3] William H. Inmon, Building the Data Warehouse, Third Edition,

2002, John Wiley & Sons

[4] Rob Karell: The Forrester Wave: Enterprise Data Quality

Platforms, Q4 2010 , 2010, Forrester Research

[5] QualityStage Designer User Guide, 2003, Ascential Software

Corporation

[6] Ted Friedman, Mark A. Beyer, Eric Thoo: Magic Quadrant for
Data Integration Tools, 2010, Gartner Group

[7] John Schmidt, David Lyle: Integration Competency Center: An

Implementation Methodology, Informatica Corporation, 2005

[8] Ted Friedman, Andreas Bitterer: Magic Quadrant for Data Quality
Tools, 2011, Gartner Group

[9] www.wikipedia.org

[10] Draen Oreanin: Implementacija skladita podataka u T-Mobile

Hrvatska, 2006, Zbornik radova HrOUG konferencije

[11] G. Shankaranarayanan, Yu Cai: Supporting data quality

management in decision-making, 2005, Boston University School
of Management

[12] Kristin Wende: A Model for Data Governance Organising

Accountabilities for Data Quality Management, Institute of
Information Management, 2007, University of St. Gallen

88 / 95
[13] Draen Oreanin, Kreimir iki, Fran Pregernik: Sustav za
normalizaciju i uparivanje podataka u Croatia Osiguranju, 2008,
Zbornik radova MIPRO konferencije

[14] Larry P. English: mproving Data Warehouse and Business

Information Quality: Methods for Reducing Costs and Increasing
Profits, 1999, Wiley & Sons

[15] Richard West, Stephen L.Daige: Total Cost of Ownership:

Strategic tool for ERP Planning and Implementation, 2006,
California State University

[16] Philip Howard: Master Data Management and Data Integration:

Complementary but distinct*, 2006, Bloor Research

[17] Draen Oreanin, Lidija Ivatinovi: Localization of Data Quality

Rules for Croatian language, 2006, Zbornik radova MIPRO
konferencije

89 / 95
 Osiguranje kvalitete podataka u skladitima podataka

Saetak:

Put od podataka do informacija i znanja nije jednostavan. Na tom putu se

uvijek pojavljuje problem kvalitete podataka. Podaci u transakcijskim
sustavima uvijek su jednim dijelom nepotpuni, nekonzistentni i netoni. U
projektima implementacije skladita podataka i sustava poslovne inteligencije
vrlo velika panja posveuje se kvaliteti podataka te su razvijene politike
osiguranja kvalitete podataka, platforme i algoritmi za ienje, konsolidaciju i
ispravljanje netonih podataka. Platforme za poboljanje kvalitete podataka
vjerojatno ine najmanje istraenu i koritenu grupu analitikog softvera u
Hrvatskoj. Hrvatsko trite nije dovoljno veliko da bude zanimljivo globalnim
dobavljaima da ulau u razvoj lokaliziranih pravila za svoje platforme. Niti
jedna od vodeih platformi za poboljanje kvalitete podataka nije u procesu
standardizacije i ienja spremna za rad s imenima, prezimenima i
adresama specifinim za hrvatski jezik, odnosno nema ugraenu
odgovarajuu aplikacijsku logiku i referentne podatke za Hrvatsku. Prije
koritenja tih platformi potrebno je kreirati pravila za hrvatska imena i adrese.
Za neke platforme, kreiranje pravila za hrvatski jezik nije lagan proces, zbog
arhitekture platformi koje nisu jednostavne za kreiranje ekstenzija. Ovaj rad
prikazuje lokalizacijski proces i kreiranje skupa pravila za poboljanje
kvalitete podataka za dvije vodee platforme te praktini primjer
implementacije na projektu u velikoj hrvatskoj tvrtki.

Kljune rijei:

Kvaliteta podataka, skladita podataka, integracija podataka

90 / 95
 Data Quality Assurance in Data Warehouse

Summary:

The path from data to information and knowledge is not easy. On this path
there is always the problem of data quality. Data in operational systems are
always partly incomplete, inconsistent and inaccurate. During implementation
of data warehouse and business intelligence systems great attention must be
paid to the quality of data. Policies for data quality assurance, platforms and
algorithms for the cleaning, consolidation and correction of inaccurate data
were developed. Platforms for improving data quality are probably the least
explored and used group of analytical software in Croatia. Croatian market is
not big enough to be interesting to global suppliers to invest in the
development of localized rules for their platforms. None of the leading
platforms for improving data quality is ready to work with the names and
addresses specific to the Croatian language in the process of standardization
and cleansing. Before using these platforms need to create rules for Croatian
names and addresses. For some platforms, creating rules for the Croatian
language is not an easy process, because the architecture of the platforms is
not easy for creating extensions. This work shows the localization process
and creation of a set of rules for improving the quality of data for the two
leading platforms, and a practical example of implementation of the project in
a large Croatian company.

Keywords:

Data Quality, Data Warehouse, Data Integration

91 / 95
 Draen Oreanin - ivotopis

Draen Oreanin je roen u Zagrebu 1968. godine. Nakon osnovne kole,

zavrava Matematiko-Informatiki Obrazovni centar V. Popovi (MIOC,
dananja XV gimnazija) 1986. godine s odlinim uspjehom. Diplomirao je na
Sveuilitu u Zagrebu na Fakultetu elektrotehnike i raunarstva na smjeru
Radiokomunikacije i profesionalna elektronika u veljai 1992. godine s
odlinim uspjehom, s temom Zvunik kao optereenje pojaala. Nakon
diplomiranja se 1992. zapoljava u Zagrebakoj banci.

Svoja prva iskustva u podruju sustava za skladita podataka i poslovne

inteligencije stjee u Zagrebakoj banci gdje je sudjelovao na brojnim
projektima razvoja aplikacija za ocjenu kreditnog rizika i upravljanja rizikom te
na projektu razvoja sustava za izvjetavanje od 1994. do 1998. godine na
poziciji strunog suradnika i voditelja slube. Nakon toga odlazi u Grupaciju
Kaptol banke gdje je podpredsjednik za informacijsku tehnologiju. Od 2000.,
kao Zamjenik direktora Sektora informatike odgovoran je za operativno
upravljanje segmentima informacijskog sustava Agrokora.

Jedan je od osnivaa tvrtke Poslovna Inteligencija gdje radi od 2001. na

pozicijama Direktora strategije i razvoja i Predsjednika Uprave. Odgovoran je
za razvoj novih trita te uvoenje novih tehnologija i metodologija. Ekspert
je za podruje telekomunikacija te sudjeluje na najsloenijim projektima
podatkovne integracije u ulozi voditelja projekta i dizajnera rjeenja, poput
projekata u T-Mobile Hrvatska, Dukatu, Tisku, a u regiji u Crnogorskom
Telekomu i Telenoru Srbija.

1993. godine upisuje jednosemestralni struni studij Poslovnog upravljana za

inenjere (Diploma Study in Management) na Fakultetu elektrotehnike i
raunarstva, koji zavrava 1994. godine.

Napisao je i objavio vie znanstvenih radova. Objavljuje i tekstove u strunim

asopisima, ponajvie u raunalnom magazinu Mrea, gdje je i stalni vanjski
suradnik. Tekstove objavljuje i u drugim strunim asopisima poput

92 / 95
InfoTrenda, Lidera i Banke. Kourednik je prvog hrvatskog nezavisnog web
centra za skladitenje podataka i poslovnu inteligenciju
www.skladistenje.com.

Redovni je sudionik i predava na strunim konferencijama u Hrvatskoj i

regiji, od kojih je najbitnije spomenuti IBC BI Roadshow, Microsoft Windays,
konferenciju Hrvatske udruge Oracle korisnika (HrOUG), IBM Cognos
Performance Day, IBM Software Days i mnoge druge.

Posjeduje strune certifikate Cognos BI Solutions Consultant, Informatica

PowerCenter Consultant, IBM InfoSphere Information Server Technical
Professional i IBM Smart Analytics Technical Professional.

U posljednjih nekoliko godina je odrao vie predavanja unutar kolegija

Izgradnja informacijskih sustava za polaznike EUCIP programa u
organizaciji Algebre te kao predava na strunom seminaru Sustavi za
podrku poslovnom odluivanju u organizaciji Algebre.

U kolskoj godine 2011/2012 izabran je u zvanje predavaa te nositelj

kolegija Skladita podataka i poslovna inteligencija na Visokoj koli za
primjenjeno raunarstvo u Zagrebu.

93 / 95
 Draen Oreanin - Curriculum Vitae

Oreanin Drazen was born in Zagreb 1968. year. After primary school, he
graduated from Mathematics-Informatics High School V. Popovic (MIOC, the
present XV gimnasium) in 1986.. He graduated from the University of Zagreb
Faculty of Electrical Engineering and Computer Science in
Radiocommunications and Professional Electronics in February 1992. After
graduation he was employeed from 1992. in Zagrebaka banka.

His first experience in the field of systems for data warehousing and business
intelligence was in Zagrebaka banka where he participated in numerous
projects and developed applications for credit risk assessment and risk
management from 1994 until 1998 at the position of expert developer and
team leader. Afer that, he was employed in Kaptol Bank Group as Vice
president for information technology. Since 2000 he was working as Deputy
Director of IT department in Agrokor.

He is one of the founders of Poslovna inteligencija, where he worked since

2001 at positions of Director of Strategy and Development and Chairman of
the Board. His responsibilities include development of new markets and
introduction of new technologies and methodologies. He is expert in the fields
of telecommunications. He participated in the most complex data integration
projects in the role of project manager and solution designer, such as
projects in the T-Mobile Croatia, Dukat, Tisak, and in the region in the
Montenegrin Telekom and Telenor Serbia.

In 1993 he enrolled in Diploma Study in Management at the Faculty of

Electrical Engineering and Computer Science and graduated in 994..

He has written and published several scientific papers. He publishes articles

in professional journals, primarily in Mrea computer magazine, where he
was a permanent associate. His articles are published in other professional
journals such as InfoTrend, Lider and Banka. He is co-editor of the first

94 / 95
independent Croatian web center for data warehousing and business
intelligence www.skladistenje.com.

He is a regular participant and speaker at professional conferences in Croatia

and the region, of which the most important thing to mention IBC BI
Roadshow, Microsoft Windays, the conference of the Croatian Association of
Oracle users (HrOUG), IBM Cognos Performance Day, IBM Software Days,
and many others.

He has professional certifications Cognos BI Solutions Consultant,

Informatica PowerCenter Consultant, IBM InfoSphere Information Server and
IBM Professional Technical Smart Analytics Technical Professional.

In recent years Draen has lectured several lectures within the course
"information system" for students EUCIP program organized by Algebra, and
as a lecturer at seminars "Decision Support Academy", organized by
Algebra.

In the academic year 2011/2012 he was elected Lecturer and he lectures

"Data Warehouse and Business Intelligence" course at the High School of
Applied Computing in Zagreb.

95 / 95