SVEUČILIŠTE U ZAGREBU
FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
Dražen Oreščanin
OSIGURANJE KVALITETE PODATAKA U
SKLADIŠTIMA PODATAKA
MAGISTARSKI RAD
Zagreb, 2011.
1 / 95
Magistarski rad je izrađen u Zavodu za primjenjeno računarstvo Fakulteta
elektrotehnike i računarstva
Mentor: Prof.dr.sc. Mirta Baranović
Magistarski rad ima: 88 stranica
Magistarski rad br.: ___________
2 / 95
Zahvale:
Aniti i Andreji, za bezgraničnu ljubav i podršku
Mentorici Prof.dr.sc. Mirti Baranović, za vjeru i upornost bez kojih ovaj rad
nikada ne bio dovršen
3 / 95
Sadržaj:
1.
Uvod ............................................................................................ 6
2.
Integracija podataka i aplikacija ................................................ 12
2.1. Tipovi integracija podataka i aplikacija ...................................... 13
2.2. Nejednakost podataka i upravljanje matičnim podacima ........... 17
2.3. Integracijski centri kompetencije ............................................... 18
Definicije i pojašnjenja bitnih pojmova ....................................... 23
3.
3.1. Skladišta 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. Izvještajni i analitički sustavi ...................................................... 32
3.7. OLAP ........................................................................................ 33
3.8. Dubinska analiza podataka ....................................................... 34
3.9. Upravljanje matičnim podacima ................................................ 35
4.
Kvaliteta podataka i informacija................................................. 37
4.1. Kvaliteta metapodataka ili definicije podataka ........................... 37
4.2. Kvaliteta sadržaja podataka ...................................................... 38
4.3. Kvaliteta prikaza podataka ........................................................ 38
5.
Upravljanje kvalitetom podataka ............................................... 39
5.1. Tri okruženja za osiguranje kvalitete podataka ......................... 40
5.2. Čišćenje podataka na aplikacijskoj razini .................................. 40
5.3. Čišćenje podataka u integracijskom sloju ................................. 42
5.4. Održavanje povijesnih podataka u skladištu podataka .............. 43
6.
Pojmovi i algoritmi vezani za platforme za kvalitetu podataka .. 45
6.1.
Označavanje ............................................................................. 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
Proces poboljšanja kvalitete podataka ...................................... 55
7.
7.1. Analiza i profiliranje ................................................................... 55
7.2. Standardizacija i korekcija ......................................................... 57
7.3. Dopunjavanje ............................................................................ 58
7.4. Uparivanje ................................................................................. 58
7.5. Preživljavanje ............................................................................ 60
Dobavljači i platforme za poboljšanje kvalitete podataka .......... 61
8.
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 slučaja T-Mobile Hrvatska ............................................. 76
10.1. Okruženje projekta .................................................................... 76
10.2. Poslovne potrebe ...................................................................... 76
10.3. Arhitektura rješenja ................................................................... 77
10.4. Ključni 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 rješenja za poboljšanje kvalitete podataka ....... 83
10.10. Sljedeći koraci ....................................................................... 84
10.11. Rezultati uvođenja sustava .................................................... 84
11.
Zaključak ................................................................................... 86
Reference ............................................................................................. 88
5 / 95
1. Uvod
Procjene kažu da će se u svake sljedeće tri godine u svijetu prikupiti i
pohraniti na računalnim medijima količina podataka i informacija jednaka
količini prikupljenoj od postanka čovječanstva do danas. Razlozi nastanka
tolike količine podataka su dvojaki.
Prvi razlog je činjenica da je, zbog tehnološkog napretka i pojeftinjenja
tehnologije za procesiranje i pohranu podataka, sve lakše podatke arhivirati,
a znanje publicirati putem Interneta. Posljedica toga je golema količina
znanja javno dostupna, koja je već sada praktično tolika da onemogućuje
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 donošenju poslovnih odluka sve više oslanjaju na
analizu podataka iz vlastitog poslovanja i poslovnog okruženja.
Drugim riječima, podaci koji se nalaze na računalima kompanija ne koriste se
samo za udovoljavanje zakonskim obvezama i izvještavanje o onome što se
desilo, već je pristup postao proaktivan te se teži tome da se na temelju
historijskih podataka što uspješnije usmjeri poslovanje u budućem razdoblju.
Osim što se historijski poslovni podaci zbog toga duže čuvaju, nastale su i
nove vrste podataka koje se koriste za analizu, poput podataka iz logova
Internet servera. Također, prilikom pripreme podataka za analizu i analize
same, podaci se transformiraju u oblik optimalan za prikaz i analizu, što
iznova kreira nove velike količine podataka.
U zadnjih nekoliko godina vrlo je primjetan pomak u investicijama u
informacijsku tehnologiju. Prije deset godina se većina budžeta velikih
poslovnih subjekata namijenjenog informacijskim tehnologijama ulagala se u
transakcijske sustave koji su omogućavali automatizaciju poslovanja, dok se
1
informacijska revolucija je pojam ekvivalentan tehnološkim revolucijama, a označava
činjenicu da je informacija u današnjoj i budućoj ekonomiji ključni poslovni faktor
6 / 95
manji dio ulagao u sustave koji kreiraju informacije i znanje. Danas je
situacija obrnuta – većina novca ulaže se u kreiranje znanja i informacija te u
nove modele poslovanja, komuniciranja i prikupljanja podataka.
Treći razlog vrlo je povezan s drugim razlogom. Naime, sve velike kompanije
žive od svojih klijenata i kupaca te im primarni poslovni fokus postaje
klijentocentričan. Posljedica toga je prikupljanje sve veće količine podataka o
svim mogućim interakcijama putem svih kanala kontakta između kompanije i
klijenta, podataka demografske, transakcijske i behaviorističke prirode, koji
također služe za analizu i kreiranje informacija za podršku donošenju
poslovnih odluka.
Put od podataka do informacija i znanja nije nimalo jednostavan. Bitne
komponente tog procesa bile su temom mnogih stručnih radova u zadnjem
desetljeću, fokusirane uglavnom na dvije strane iste medalje – poslovnu i
tehnološku.
To je rezultiralo definiranjem novih, danas već općeprihvaćenih teorija i
metodologija poput skladištenja podataka (engl. Data Warehousing),
dubinske analize podataka (engl. Data Mining) i OLAP-a (engl. On-Line
Analytical Processing).
Sve te metodologije iskušane su u praksi te se sad najčešće mogu naći pod
krovnim pojmom poslovne inteligencije (engl. Business Intelligence) i čine
godišnje tržište veličine od 25 milijardi dolara u 2010. godini, s perspektivom
rasta od preko 10% godišnje, s više stotina različitih dobavljača opreme i
programskih rješenja za pojedine faze u procesu te mnoštvom uspješno
implementiranih projekata u cijelom svijetu.
Sljedeći 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 ključne komponente.
7 / 95
Druga komponenta je sustav za planiranje i budžetiranje koji omogućava
brzo, jednostavno i pouzdano kreiranje strateških i operativnih planova te
budžeta i predviđanja.
Na vrhu sustava za upravljanje performansama nalazi se uravnotežena
tablica rezultata (engl. BSC - Balanced Scorecard) platforma u kojoj su
definirani svi ključni poslovni pokazatelji (engl. KPI - Key Performance
Indicators) koje tvrtka treba pratiti, s indikatorima trenda kretanja i statusa
ispunjenja planskih vrijednosti, koje ne moraju biti isključivo financijske
prirode.
Na tom putu jedan problem se praktično uvijek pojavljuje – problem kvalitete
podataka. Istraživanje Gartner Grupe pokazuje da većina inicijativa za
reinženjering informacijskih sustava propada zbog zanemarivanja problema
kvalitete podataka. Praktično polovica projekata implementacije skladišta
podataka u svijetu je osuđeno na propast, a glavni uzrok su nekvalitetni i
nepouzdani podaci u izvornim sustavima i samom skladištu podataka [14].
Podaci u transakcijskim sustavima uvijek su jednim dijelom nepotpuni,
nekonzistentni, netočni i kao posljedica toga - neistiniti. Poznato je pravilo
koje kaže da ako ulazni podatak nije ispravan i istinit, niti na izlazu neće biti
ono što je potrebno – informacija, odnosno znanje.
Naime, da bi nešto bilo informacija, mora zadovoljavati tri uvjeta – istinitost,
pravovremenost i donošenje nove vrijednosti. U ovom slučaju, već prvi uvjet
nije zadovoljen. I u samoj inicijalnoj definiciji skladišta podataka (o
skladištima podataka će biti više riječi u zasebnom poglavlju) jedna od četiri
bitne karakteristike je integriranost, što podrazumijeva konzistentnost u
nazivlju, formatima i pohranjivanju podataka, što je praktično sinonim za
kvalitetu.
U projektima implementacije sustava poslovne inteligencije vrlo velika pažnja
posvećuje se kvaliteti podataka te su razvijene politike osiguranja kvalitete
8 / 95
podataka, platforme i algoritmi za čišćenje, konsolidaciju i ispravljanje
netočnih podataka, o kojima će također biti riječi u ovom radu.
U praksi u Hrvatskoj situacija je ipak malo drugačija – kao i mnogočemu
drugome, tako se i kvaliteti podataka najčešće pristupa nesustavno te će
rijetko koja hrvatska kompanija reći da je zadovoljna kvalitetom svojih
poslovnih podataka.
Obično su hrvatske kompanije svjesne da su njihovi podaci upitne kvalitete.
Bez obzira na ovu činjenicu, ništa se ne čini kako bi se poboljšala kvaliteta
podataka. Stavka za poboljšanje kvaltete podataka se obično zasebno ne
budžetira u projektima implementacije skladišta podataka. Bez odgovarajućih
ulaganja, ovakav kompleksan problem ne može se ni djelomično riješiti.
Jedna od bitnih značajki ovog rada je i analiza kvalitete podataka u realnom
poslovnom okruženju, implementacija sustava za osiguranje kvalitete
podataka kao dijela sustava za podršku poslovnom odlučivanju te analiza
dobivenih rezultata i primijenjenih algoritama.
U zadnjih nekoliko godina obranjen je na hrvatskim sveučilištima priličan broj
diplomskih, magistarskih i doktorskih radnji koje su se koncentrirale na
pojedine segmente procesa kreiranja informacija i znanja.
Većina tih radnji odnosila se na koncepte skladištenja 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 postići u praksi
prilikom implementacije korporativnih analitičkih sustava koji se temelje na
metodologiji skladištenja podataka.
Platforme za poboljšanje kvalitete podataka vjerojatno čine najmanje
istraženu i korištenu grupu analitičkog softvera u Hrvatskoj. Hrvatsko tržište
nije dovoljno veliko da bude zanimljivo globalnim dobavljačima da ulažu 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 najveće
potencijalne klijente na tržištu.
Drugi je razlog da većina kompanija nije svjesna koristi koje mogu dobiti od
ove vrste softverskih platformi.
Treći i najvažniji razlog je činjenica da nijedna od vodećih platformi za
poboljšanje kvalitete podataka nije inicijalno, bez dodatnih aktivnosti i dorada,
spremna za rad s hrvatskim specifičnim podacima o imenima, prezimenima i
adresama u procesu standardizacije i čišćenja, zbog različitih kodnih stranica
i različitih pravila za usporedbu s ostalim europskim jezicima.
Na sreću, stvari se mijenjaju na bolje, pa ovaj rad prikazuje lokalizacijski
proces i kreiranje skupa pravila za platformu za poboljšanje 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 trećem poglavlju rada daju se definicije osnovnih pojmova vezanih za
skladišta podataka, poslovnu inteligenciju i analitičku integraciju podataka, s
osvrtom na ulogu koju kvaliteta podataka ima u procesu skladištenja
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 način i metodologija upravljanja kvalitetom
podataka i okruženja u kojima se može utjecati na kvalitetu podataka.
U šestom poglavlju detaljno su opisani najbitniji statistički algoritmi koji se
koriste u platformama za poboljšanje kvalitete podataka.
U sedmom poglavlju detaljno su opisani koraci u procesu poboljšanja
kvalitete podataka, s primjerima upotrebe pojedinih algoritama.
10 / 95
U osmom poglavlju su ukratko opisane funkcionalnosti vodećih platformi za
poboljšanje kvalitete podataka prisutnim na hrvatskom tržištu.
U devetom poglavlju opisan je proces lokalizacije pravila za poboljšanje
kvalitete podataka za dvije najprisutnije platforme za poboljšanje kvalitete
podataka na hrvatskom tržištu.
U desetom poglavlju je opisana studija slučaja implementacije sustava za
skladištenje podataka koji je uključivao i platformu za poboljšanje kvalitete
podataka u jednoj od velikih tvrtki u Hrvatskoj.
Zaključak rada je u posljednjem, jedanaestom poglavlju.
Implementacija platformi za poboljšanje kvalitete podataka je područje
analitičke infrastrukture čija se važnost u Hrvatskoj još uvijek nije dovoljno
spoznala, a može se reći i da je ovo područje najmanje istraživano i
upoznato. Doprinos ovoga rada trebao bi biti jedan od početnih koraka u široj
implementaciji sustava za upravljanje kvalitetom podataka.
11 / 95
2. Integracija podataka i aplikacija
Svaki informacijski sustav temelji se na podacima koje sadrži, koji se u njega
unose i kroz njega održavaju. U poslovanju moderne tvrtke imaju sve više
različitih aplikacija za prikupljanje i diseminaciju podataka, a podatke iz njih je
nužno
prikupljati,
razmjenjivati
i
usklađivati
kako
bi
se
osigurala
pravovremena informacija za rukovoditelje.
Problem integracije podataka iz različitih sustava te razmjene podataka među
sustavima već je dugo prisutan u poslovnom svijetu, a s vremenom dobiva
sve više na važnosti.
U prosjeku se svake tri godine količina ukupno kreiranih podataka i
informacija na svijetu udvostruči, što znači da će u sljedeće tri godine biti
proizvedena jednaka količina informacija kao što je cjelokupno čovječanstvo
proizvelo u ukupnoj svojoj povijesti. Ne samo da raste količina podataka,
nego raste i raznovrsnost, postoji sve više različitih platformi, baza podataka,
poslovnih aplikacija, podatkovnih formata i standarda.
Također, poznata je činjenica da se sve veći dio poslovnih informacija nalazi
u e-mail porukama i datotekama kreiranim u tekstualnim procesorima i
tabličnim kalkulatorima poput Microsoft Worda ili Excela, pohranjenim na
osobnim računalima i često nedostupnim za integraciju s ostalim potrebnim
podacima.
Dodatni nivo složenosti i volumena podataka donose i novi izvori podataka
koji su posljedica novih načina komuniciranja. Tu se prvenstveno radi o
podacima s društvenih mreža poput Facebooka, Twittera i LinkedIna te
servisa za dijeljenje video, audio i slikovnih sadržaja poput Youtubea.
Inicijalno su sustavi poslovne inteligencije i skladišta podataka, odnosno
sustavi za podršku poslovnom odlučivanju, bili prvo mjesto na kojem je bila
potrebna integracija podataka iz više različitih informacijskih sustava
transakcijke prirode. Globalizacijom poslovanja, i razvojem business-to-
12 / 95
business poslovnih modela putem Interneta, sve je više i rasla potreba za
integracijom podataka iz različitih sustava.
Velike svjetske tvrtke, a i mnoge hrvatske tvrtke, imaju pogone ili
predstavništva u raznim zemljama svijeta, na različitim kontinentima, u
kojima, ne samo da se govori različitim jezicima, nego su i pisma koja se
koriste različita.
Za uvid u konsolidirano poslovanje mora se omogućiti da svi ti sustavi
međusobno nesmetano komuniciraju i razmjenju podatke na pouzdan i
pravovremen način. Osnovna pretpostavka za komunikaciju među sustavima
su standardni industrijski formati za komunikaciju, poput SWIFT standarda za
međubankovne transakcije ili EDI standarda za elektroničke transakcije te u
novije vijeme sve više XML-a kao plaforme za komunikaciju među sustavima
na kojoj se mogu razvijati specifična rješenja.
2.1.
Tipovi integracija podataka i aplikacija
Zahtjev poslovanja je da se mora omogućiti da se podaci iz različitih sustava,
koji za komunikacju koriste različite standarde i protokole, iz različitih
aplikacija na različitim jezicima razmjenjuju među sustavima.
Tu je potrebno razlikovati tri osnovne vrste interakcija među sustavima.
U prvom slučaju je je riječ o razmjeni podataka u realnom vremenu ili u
relativno kratkim vremenskim razmacima. U ovu kategoriju mogu se ubrojiti
sinkronizacije podataka između sustava ili replikacije podataka na drugu
lokaciju radi osiguravanja nastavka nesmetanog funkcioniranja u slučaju
havarije. Tu se najčešće radi o malim do srednjim količinama podataka i
visokoj učestalosti razmjene te malim potrebama za transformacijama.
U drugu kategoriju spadaju punjenja skladišta podataka i analitičkih sustava
za podršku odlučivanju. Takvi integracijski zadaci najčešće se dešavaju
13 / 95
jednom dnevno u doba kada izvorni i ciljni sustavi nisu opterećeni korisničkim
zahtjevima, najčešće tijekom noći. Količine podataka koje se prebacuju su
srednje do velike, uz složene transformacije.
U treću kategoriju spadaju migracije s jednog sustava na drugi, poput slučaja
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 dešavaju se jednokratno, uz veliku količinu
podataka i najčešće vrlo složene transformacije i kontrole. U skupinu
migracija spadaju i migracije podataka iz testnog u produkcijski sustav kod
uvođenja novog sustava.
Kroz zadnjih desetak godina nastale je nekoliko specifičnih grupa proizvoda
koji su rješavali te probleme. Većina ih je grupirana u dvije osnovne grupe
koje se baziraju na tipu integracije.
Prvu i veću grupu činile su platforme koji omogućavaju komunikaciju i
integraciju transakcijskih sustava, koje se nazivaju EAI – Enterprise
Application Integration platforme. EAI je segment informatičkog tržišta koji
ima najveći rast od preko 30% godišnje, što je daleko iznad tržišnog
prosjeka, budući da je i potreba za integracijom sve veća i veća.
Drugu grupu čine platforme koje služe ekstrakciju, transformaciju i učitavanje
podataka i za punjenje skladišta podataka, odnosno analitičku integraciju
(engl. ETL – Extraction, Transformation and Load). U obje grupe, osim
proizvođača specijaliziranih za takva rješenja poput TIBCO-a ili Informatice,
nalaze se i uvijek prisutni Microsoft, Oracle, SAP i IBM [6].
U zadnje vrijeme ta dva tržišta pokazuju tendenciju konvergencije, pa je tako
uveden pojam platformi za integraciju podataka (engl. Data integration).
Gartner Grupa je godinama kroz svoj magični kvadrant pratila tržište
platformi za ekstrakciju, transformaciju i učitavanje podataka. Međutim,
zadnja tržišna 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 došli i neki drugi
dobavljači poput Tibca [6]. Gartner kategoriju platformi za podatkovnu
integraciju definira kao platforme koje podržavaju jednu ili više navedenih
funkcionalnosti opisanih u tablici 2.1 [6].
Gartner dobavljače na nekom tržištu ocjenjuje prema viziji razvoja koja se
nalazi na horizontalnoj osi te prema trenutačnoj snazi i tržišnoj poziciji tvrtke
koja je na vertikalnoj osi. Dobavljači koji su jaki u oba segmenta nalaze se u
gornjem desnom kvadrantu te se smatraju tržišnim liderima. U tom kvadrantu
nalaze se Informatica, IBM, SAP i Oracle. Sve te tvrtke su sa svojim
integracijskim
proizvodima
prisutne
u
našoj
regiji
te
su
proizvodi
implementirani kod nekoliko korisnika.
Većina ostalih dobavljača nalazi se među igračima orjentiranim na pojedine
niše, budući da nemaju cjelovitu integracijsku platformu, odnosno orjentirani
su samo na neke elemente integracije. Sve te tvrtke imaju ideju nametnuti se
kao dobavljači cjelovitih integracijskih platformi u budućnosti. Neke od tih
tvrtki također su i vrlo prisutne na našem tržištu sa svojim integracijskim
platformama, prvenstveno Microsoft, SAS i Talend.
15 / 95
Tip integracije
Prikupljanje podataka za
analitičke sustave
Opis funkcionalnosti
Ekstrakcija podataka iz operativnih sustava,
transformiranje i uparivanje te zapisivanje u analitičke
sustava.
Kreiranje integriranih
Omogućavanje konsolidacije, sinkronizacije i
repozitorija matičnih
racionalizacije podataka koji opisuju ključne poslovne
podataka
subjekte poput kupaca, proizvoda i zaposlenika.
Migracije i konverzije
podataka
Sinkronizacija podataka
među operativnim
aplikacijama
Mogućnosti transformacije i pripreme podataka kod
migracija s legacy sustava na ERP sustave te
konsolidacija višestrukih ERP sustava kod akvizicija.
Omogućavanje konzistentnosti na nivou baza podataka,
u jednom ili dva smjera, unutar tvrtke ili prema okruženju
Ova funkcionalnost se često naziva Enterprise
Kreiranje federiranih
Information Integration (EII) te omogućava integrirani
pogleda nad podacima
pogled na informacije u realnom vremenu, bez potrebe
iz različitih repozitorija
da se podaci fizički “spreme” u jedan zajednički
podataka
repozitorij. Ova funkcionalnost je sve bitnija za Data
Integration platforme.
Integracija podataka u
Ovdje je više riječ o arhtekturalnom svojstvu, nego o
servisno orijentiranoj
funkcionalnosti. Moderne platforme za integarciju
arhitekturi (SOA)
podataka moraju biti servisno orjentirane.
Unifikacija strukturiranih
i nestrukturianih
podataka
Ovdje je također riječ o mogućnosti relevantnoj za sve
navedene scenarije, budući da organizacije teže
sjedinjanju strukturiranih i nestrukturiranih podataka u
kreiranju informacijske infrastrukture.
Tablica 2.1: Funkcionalnosti platformi za integraciju podataka
16 / 95
2.2.
Nejednakost podataka i upravljanje matičnim
podacima
Kod integracije podataka je uvijek prisutan problem nejednakosti podataka.
Nejednakost proizlazi iz različitosti aplikacija samih po sebi. Nejednakost će
biti u daljem tekstu pojašnjena na jednostavnom primjeru. Aplikacija za
prodaju ima svoj šifarnik kupaca, dok aplikacija za financije ima svoj šifarnik
kupaca, u kojima isti kupac ima različite šifre, različit opseg podataka i
različite dokumente koji se vežu uz tog kupca. Razlog tome je različita
poslovna potreba koju pojedini sustav zadovoljava i različito vrijeme
nastajanja zapisa o pojedinom kupcu u svakom od ta dva sustava.
Jedan od načina rješavanja tog problema je implementacija integriranog
poslovnog sustava poput SAP-a ili Navisiona, ali to sa sobom nosi velike
troškove i angažman cijele tvrtke [15]. S druge strane, što je s velikim holding
tvrtkama koje u svom sastavu imaju desetak ili više manjih tvrtki u regiji ili
cijelom svijetu? Takav pristup kod njih graniči s neizvedivošću.
Drugi način, koji se najčešće koristi, je primjena referentnih tablica za
preslikavanja podataka iz jednog u drugi sustav. U tim tablicama nalazi se
informacija koja omogućava da se jednoznačno odredi kupac kojem
pripadaju dokumenti i podaci u jednom i u drugom sustavu.
U realnom svijetu, ne postoje samo matični podaci o kupcima koji se trebaju
uskladiti i integrirati – tu su i podaci o proizvodima, poluproizvodima,
materijalima, dobavljačima, zaposlenicima, organizacijskim jedinicama ili
kontnom planu. Također, velike tvrtke nemaju samo dvije, nego puno više
različitih aplikacija. Cijelu tu problematiku pokriva jedna grana integracije koja
se naziva upravljanje matičnim 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 više konvergiraju prema jednoj jedinoj riječi, a to je integracija,
neovisno o tipu aplikacije, količini podataka ili složenosti transformacija. Tako
je nastao i koncept integracijskog centra kompetencije (engl. Integration
Competency Center - ICC) koji je vrlo brzo zadobio vrlo snažnu podršku i
informatičke struke i poslovnih korisnika.
Osnovna ideja koja stoji iza ovog koncepta je da postoji središnje mjesto u
organizaciji koje se brine za integraciju aplikacija i podataka, organizacijska
jedinica sa skupinom ljudi i platformom ili platormama s kojima mogu
rješavati integracijske izazove svih triju tipova, umjesto da se svaki zadatak
integracije sustava gleda kao zaseban problem.
Na taj način se razvija kompetencija te se za svaki sljedeći 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, konačni rezultat su brže implementacije integracijskih
projekata te manji troškovi.
Kičma takve organizacije je repozitorij metapodataka, podataka o podacima,
koji sadrži informacije o svim preslikavanjima i tijeku podataka među
različitim sustavima. Na taj način su i najsloženiji poslovni sustavi detaljno i
precizno dokumentirani te je integracija novih podsustava u cjelinu brža i
jednostavnija.
U integracijskom centru kompetencije metapodaci nisu samo podaci o
podacima, nego također podaci o sustavima, procesima, sučeljima, ljudima i
uslugama. To je puno opsežnija definicija metapodataka nego uobičajena
definicija. Organizacija mora imati centralizirane i organizirane informacije o
svojoj vlastitoj informacijskoj infrastrukturi kao tehnološku osnovu za
integracijski centar kompetencije.
18 / 95
Jedna vrlo jednostavna analogija koja se može 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 omogućava da se s jednim presjedanjem može
doći iz Zagreba do bilo kojeg dijela svijeta.
Analogno tome, integracijski centar kompetencije ima ulogu takvog
prometnog čvora koji usmjerava podatke u njihovom prometu između
različitih sustava.
Slika 2.1: Interakcija među sustavima u organizaciji bez integracijskog centra
kompetencije
19 / 95
Slika 2.2: Interakcija među sustavima u organizaciji s integracijskim centrom
kompetencije
Mogući 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 vođenje projekata
omogućavaju kreiranje dodane vrijednosti u odnosu na organizacije bez
centraliziranih projektnih standarda.
Sljedeći model je model korištenja 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 postiže višestrukim korištenjem akumuliranog
znanja.
Model tehnoloških standarda najčešće je prisutan kod velikih svjetskih
korporacija, koje za svoje članice propisuju standarde kojih se trebaju držati.
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 tehnološka konzistentnost,
koja omogućuje jednostavnu integraciju podataka i među više tvrtki u više
država.
Sljedeći model je model dijeljenih servisa kojem su glavne značajke dijeljeni
resursi i hibridna organizacija. U tom modelu postoji centralizirana
integracijska tehnološka platforma, ali svaki sustav ima svoje sučelje prema
integracijskom centru. Boljitak koji ovaj model donosi je najveći, ali je i
organizacijski i implementacijski najsloženiji, budući 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 nešto manje poboljšanje od distribuiranog
modela, ali je lakši i brži za implementaciju, budući da se jedan centralni tim
brine o svim potrebnim sučeljima.
21 / 95
Odabir prikladnog modela za pojedinu organizaciju ovisi o više važnih
čimbenika, od kojih svakako valja naglasiti postojeću organizaciju i
korporativnu kulturu te informacijsku infrastrukturu.
Današnja integracijska tehnologija je prilično zrela i većina tehnologija
vodećih dobavljača je vrlo dobra te je u odabiru infrastrukture za integracijski
centar kompetencije teško pogriješiti.
Svakako je puno kritičniji faktor efikasna implementacija metodologije. Za to
je potrebno imati puno iskustva u integraciji, a također je nužno i poznavanje
procesa specifičnih 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 događaje i dokumente u podatke i informacije –
zato je poznavanje procesa toliko bitno.
22 / 95
3. Definicije i pojašnjenja bitnih pojmova
Uz pojam i sustave za poboljšanje kvalitete podataka vezani su i drugi
pojmovi koji se odnose na sustave za pohranu, obradu, integraciju,
upravljanje i
korištenje podataka i informacija. U ovom poglavlju biti će
definirani i pojašnjeni najbitniji pojmov te njihov odnos i povezanost sa
sustavima za kvalitetu podataka.
3.1.
Skladišta podataka
Pojam skladišta podataka nije uopće toliko dugo prisutan u informatičkim
rječnicima, iako je sam koncept bio upotrebljavan i prije, ali bez teoretske
formalizacije. Skladište podataka je prije svega skup podataka orijentiran
analitičkom korištenju, što znači da je optimiziran za puno upita koji
dohvaćaju veću količinu podataka.
Za razliku od skladišta podataka, transakcijski sustav je orijentiran na veliki
broj istovremenih korisnika te brzo zapisivanje, čitanje i izmjenu malih
količina podataka, najčešće samo jednog zapisa. Druga bitna značajka
transakcijskih sustava je normaliziranost (najčešće u trećoj normalnoj formi),
odnosno eliminiranje redundancije u podacima.
Zbog normaliziranosti strukture transakcijski sustavi ne odgovaraju potebno
dobro na analitičke upite; vrlo je često kod složenijeg analitičkog upita
dostupiti do podataka iz desetak i više tablica istovremeno. S jedne strane,
performanse dostupa do podataka nisu dobre, a s druge strane veliki utrošak
procesorskih i memorijskih resursa za takve upite onemogućava ostale
korisnike u obavljanju operativnih zadataka.
Prva definicija skladišta podataka potječe iz 1992. godine kad je “kum”
skladištenja podataka Bill Inmon definirao skladište podataka kao “skup
23 / 95
subjektno orijentiranih, integriranih, vremenski ovisnih i
nepromjenjivih
podataka za podršku poslovnom odlučivanju” [3]. Svaka od ove četiri
značajke zaslužuje malo detaljnije pojašnjenje, s osvrtom na utjecaj kvalitete
podataka.

Subjektna orijentiranost znači da podaci u skladištu 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
događaj ili dokument. Sustavi za osiguranje kvalitete podataka
osiguravaju da je svaki subjekt jednoznačno definiran, odnosno da se
pojedini kupac ili proizvod višestruko ne pojavljuje, bilo da podaci o
pojedinom subjektu dolaze iz jednog ili više sustava.

Integriranost podrazumijeva dosljednost u sadržaju, nazivima i
formatima podataka koji dolaze iz različitih izvora. Primjerice, formati
zapisa datuma u različitim transakcijskim sustavima na različitim
platformama mogu biti različiti, ali u skadištu podataka takvih razlika
ne smije biti. Ova značajka skladišta podataka ponajviše je ugrožena
nekvalitetnim izvorišnim podacima.

Vremenska ovisnost znači da podaci u skladištu imaju vremensku
dimenziju, odnosno da se skladište podataka sastoji od snimaka (engl.
snapshotova) transakcijskih podataka uzetih u redovnim vremenskim
periodima. Ova značajka omogućava analitičku funkcionalnost i
analizu trendova poslovanja kroz vrijeme, budući da transakcijski
sustavi uvijek čuvaju samo trenutnu vrijednost transakcije, a do stanja
u nekom trenutku se dolazi zbrajanjem svih transakcija u traženom
periodu

Nepromjenjivost određuje da se podaci jednom učitani u skladište
podataka više ne mogu promijeniti, osim ponovnim učitavanjem s
transakcijskog sustava. Od ove značajke se može odstupiti kod
održavanja podataka u slučaju promjena poslovnih politika ili
24 / 95
organizacije. U praksi se zna dešavati da dođe do reorganizacije
tvrtke te da je zahtjev korisnika informacija da se troškovi iz prijašnjih
godina prikazuju korisnicima prema novoj organizaciji. U tom slučaju
potrebno je poslovna pravila za alokaciju na podatke u skladištu
podataka iz prijašnjih godina.
Postoji i još jedna vrlo jednostavna definicija skladišta podataka kao kopije
transakcijskih podataka optimiziranih za analitičke upite. Povijesno gledano,
skladišta podataka nastala su početkom devedesetih godina prošlog stoljeća
s razlogom da se operativni sustavi rasterete analitičkih upita. U to doba broj
različitih informacijskih sustava koji su postojali u tvrtkama bio je bitno manji
nego danas. S vremenom, razlog implementacije skladišta podataka je sve
više bila integracija podataka iz razičitih izvora.
Glavni građevni elementi skladišta podataka su činjenične tablice (engl. Fact
tables) koje sadrže kvanitativne, numeričke podatke koji se analiziraju te
dimenzijske tablice (engl. Dimension tables), koje sadrže kvalitativne,
strukturne podatke koji služe za kreiranje hijerarhija za sumarizaciju i analizu.
Činjenične tablice imaju velik broj zapisa, ponekad i desetke ili stotine
milijuna. Primjer činjenične tablice je tablica ostvarene prodaje kupcima po
proizvodima. U činjeničnim 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
može dodati i nabavna ili proizvodna cijena te se izračunati kontribucija po
svakoj stavci i profitabilnost proizvoda i klijenta.
U tom kontekstu, dimenzijske tablice koje su vezane za činjeničnu tablicu
prodaje mogu biti tablice kupaca, proizvoda, vremena i prodajnog mjesta.
Svaka od tih tablica sadrži atribute koji omogućavaju grupiranje i analizu od
ukupnog prema detaljnom. Tako se primjerice proizvodi mogu grupirati
prema grupama i podgrupama, a kupci prema geografskoj pripadnosti,
veličini, značaju ili nekom drugom atributu.
25 / 95
Kod učitavanja podataka u skladište vrši se denormalizacija i optimizacija
podataka za analitičke upite. Dva najzastupljenija načina modeliranja su
zvjezdasta (engl. Star) i pahuljičasta (engl. Snowflake) shema.
Zvjezdasta shema podrazumijeva da je svaka dimenzija za analizu u
potpunosti denormalizirana, dok pahuljičasta shema nije u potpunosti
denormalizirana. Denormalizacija se radi kako bi broj tablica koje se
dohvaćaju u korisničkom upitu bio što manji te kako bi upiti radili brže.
Dimenzijske tablice obavezno trebaju imati primarne ključeve, kojima se vežu
na tablicu činjenica. Skladište podataka se uobičajeno sastoji od više
subjektnih područja, od kojih svako ima najčešće jednu, a ponekad i više
činjeničnih tablica te nekoliko dimenzijskih tablica.
Dimenzijske tablice mogu imati kontekst u više subjektnih područja, a
najjednostavniji primjer je vremenska dimenzija koja je potrebna u svakoj
analizi. Takve dimenzije koje se definiraju jednoznačno, a koriste u više
različitih subjektnih područja, nazivaju se konformne dimenzije.
Zvjezdasta shema se najčešće koristi u implementaciji skladišta podataka te
je i najjednostavnija za razumijevanje, budući da je svaka dimenzija
reprezentirana
jednom
tablicom.
Većina
dizajnerskih
problema
kod
implemantacije skladišta podataka može se riješiti korištenjem zvjezdaste
sheme, ali ponekad je potrebno koristiti i pahuljičastu shemu. Ako se uzme
kao primjer distribucijska tvrtka koja radi s kupcima koji imaju više dostavnih
mjesta za isporuku. Isporuka se vrši po dostavom mjestu, dok se fakturiranje
vrši 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 činjenična
tablica se veže 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 ključnih atributa (npr. klijent banke koji se preselio iz jednog
grada u drugi), koje se mogu u skladištu podataka tretirati na nekoliko
načina. 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 Pahuljičaste (engl. Snowflake) sheme
Još jedna vrlo bitna značajka skladišta podataka je veličina. Naime, zbog
velikog povijesnog perioda koji podaci u skladištu 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,
skladišta podataka su načešće vrlo velika. U tom kontekstu u našem
okruženju skladište od 100 GB smatra se relativno malim skladištem, dok se
u velika skladišta mogu ubrojati ona veličine od preko 1 TB. Najveća svjetska
skladišta podataka od preko 100 TB i preko 1PB mogu se naći u
telekomunikacijskim
tvrtkama
i
državnim
obavještajnim
institucijama.
Naravno, porast količine podataka ne rezultira samo povećanjem dimenzija
diskovnog prostora, nego i procesorske memorijske snage i komunikacijske
propusnosti sustava, kako bi svi podaci pravovremeno bili učitani. Također,
veličina skladišta podataka utječe i na performanse prema krajnjim
28 / 95
korisnicima, koje u slučaju lošeg dizajna i indeksiranja mogu značajno
degradirati s povećanjem količine podataka.
Jedan od trendova u dizajnu velikih skladišta podataka je povratak trećoj
normalnoj formi, kao načinu osiguravanja konzistentnosti podataka. U
ovakvoj arhitekturi nema jasne podjele na činjenične i dimenzijske tablice.
Sve tablice su povezane ograničenjima stranih ključeva (engl. primaryforeign key constraint). Kod takvog modeliranja se obavezno koriste Data
Martovi kao još krajnji nivo pripreme podataka za krajnje korisnike. Data Mart
u tom slučaju ima zvjezdastu strukturu, kako bi se analitički upiti izvršavali što
brže.
Izuzetno je bitno kod implementacije skladišta podataka postaviti i poštivati
konvencije imenovanja tablica i atributa, kako bi se sustav mogao
jednostavno koristiti, održavati i dokumentirati.
3.2.
Izvori podataka
Izvori podataka za skladište podataka mogu biti različiti, a u osnovi se dijele
na interne i eksterne. U većini slučajeva prevladavaju interni podaci koji
dolaze iz transakcijskih sustava. Velike tvrtke imaju više različitih
transakcijskih sustava, pogotovo ako su nastajale kao posljedica integracija
više tvrtki koje su imale različite sustave. Podaci iz svih tih sustava najčešće
su potrebni za analizu i izvještavanje te ih je potrebno napuniti u skladište
podataka.
Također 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 marketinških
istraživanja.
U zadnje vrijeme sve češće se pojavljuju još dvije bitne grupe podataka koje
je potrebno učitati u skladište podataka. Prvu grupu čine nestrukturirani
29 / 95
podaci poput PDF ili Word dokumenata ili e-mail poruka. Istraživanja kažu 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 skladišta podataka učitava se sadržaj pojedinih dokumenata
te se prema poziciji i kontekstu sadržaj smješta u relacijsku strukturu.
Primjerice, ako tvrtka ima standardne ugovore s kupcima pohranjene na
centralnom mjestu, iz Word ili PDF dokumenta moguće je dobiti potrebne
informacije u skladištu podataka.
Drugu grupu čine podaci čije je porijeklo vezano za web servise i messaging
platforme. Oni su najčešće u nekoj od formi XML-a te se prilično jednostavno
učitavaju u skladište podataka.
Iz različitih izvora podaci se moraju učitati u skladište podataka te
nadupunjavati u redovnim vremenskim intervalima. Za to služe platforme za
integraciju podataka, čija je funkcionalnost već opisana u prethodnim
poglavljima.
3.3.
Transformacija podataka i privremeni spremnik
Prilikom transformacije podataka, najčešće 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, međusobno
kombiniraju i dorađuju, kako bi u skladište podataka došli pročišćeni,
konsolidirani i obogaćeni dodatnim informacijama.
Privremeni spremnik ima vitalnu funkciju kod implementacije velikih sustava
skladišta podataka, jer omogućava da se sloj konačnog sadržaja skladišta
podataka fizički i/ili logički odvoji od podataka koji se koriste u tijeku obrade i
pripreme. Privremeni spremnik može 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 način se transformira, gdje, kako i tko ga koristi na koji način.
Metapodaci su doslovno vezivno tkivo skladišta podataka i sustava poslovne
inteligencije. Object Management Group je razvio Common Warehouse
Metamodel, zajednički standard metapodataka koji već podržavaju mnogi
proizvodi na tržištu [9], što korisnicima život počinje činiti puno lakšim.
Vrlo često velike tvrtke koriste više različitih softverskih proizvoda različitih
tvrtki u procesu kreiranja i korištenja analitičkih sustava te mogućnost
razmjene metapodataka između različitih platformi može uštedjeti i vrijeme i
resurse pri implementaciji.
3.5.
Data Mart
Jedan od također često koristenih izraza u teoriji skladišta podataka je i Data
Mart,
što
podrazumijeva
podskup
podataka
iz
skladišta
podataka
namjenjenih za korištenje od strane pojedine poslovne funkcije ili djelatnika
na jednoj lokaciji. Data Mart najčešće pokriva jedan subjekt, odnosno sadrži
jednu zvjezdastu shemu s potrebnom činjeničnom i dimenzijskim tablicama.
Višedimenzionalne OLAP kocke o kojima će kasnije biti riječi u poglavlju 3.7,
najčešći su pojavni oblik multidimenzionalnog Data Marta. Prije je u velikim
tvrtkama čest slučaj bio da su pojedine organizacijske jedinice (prodaja,
nabava, financije) kreirale vlastite Data Martove, koje je kasnije teško
integrirati u jedinstveni sustav zbog već spomenutog problema integriranosti.
Danas je najčešći pristup kreiranje centralnog korporativnog skladišta
podataka, iz kojeg se rade podskupovi, tj. data martovi za pojedinu poslovnu
funkciju, čime se osigurava integriranost i konzistentnost podataka.
31 / 95
3.6.
Izvještajni i analitički sustavi
Prvi i prilično standardan zahtjev za korištenje informacija iz skladišta
podataka je kreiranje statičnih izvještaja i ad-hoc upita koji koriste podatke
pohranjene u skladištu. To nije jako sofisticiran i zahtjevan posao ako
kompleksnost skladišta podataka ne prelazi nekoliko stotina tablica, ako
činjenične tablice ne sadrže stotine milijuna slogova, ako podatke iz skladišta
ne koriste stotine ili tisuće korisnika i ako se dnevno ne trebaju isporučiti
stotine izvještaja. Današnje izvještajne platforme uglavnom imaju isključivo
web sučelja. Velike mogućnosti za kreiranje izvještaja i jednostavnost sučelja
za krajnjeg korisnika se za sve ozbiljne platforme podrazumijevaju.
S razvojne strane, bitno je da takvi sustavi omogućavaju s jedne strane
kreiranje jednostavnih ad-hoc upita za korisnike koji nemaju veliko
informatičko iskustvo pomoću jednostavnih funkcionalnosti i bez potrebe
poznavanja SQL-a. S druge strane, bitno je da omogućavaju i kreranje
složenih sofisticiranih izvještaja koji kombiniraju podatke iz više različitih upita
te
sadržavaju
i dodatne
objekte
(logotipove,
poveznice,
tekstualne
komentare), kako bi se zadovoljile potrebe naprednih korisnika. Također je
bitno da takve platforme korisnicima omogućavaju dostup do relacijskih i
OLAP izvora kroz jedno sučelje.
Sa sigurnosne strane, bitno je da se platforma može integrirati u postojeću
autentikacijsku infrastrukturu te da se mogu definirati razine sigurnosti na
nivou pojedinog izvještaja, odnosno podskupa podataka dostupnih pojedinoj
klasi korisnika unutar pojedinog izvještaja.
Naravno, izvještajne i analitičke platforme moraju omogućavati i skalabilnost
korištenja od nekoliko do nekoliko tisuća korisnika, a po mogućnosti i
višejezičnost sučelja za mutinacionalne tvrtke.
32 / 95
3.7.
OLAP
Vjerojatno je najomiljeniji i najpoznatiji način iskorištavanja podataka iz
skladišta podataka OLAP (engl. On-Line Analytical Processing). Iako je kao
pojam nastao prilično davno, tek je u zadnjih desetak godina je postao vrlo
omiljen, a napredak tehnologije omogućio je nastajanje zaista moćnih OLAP
platformi. Ideja OLAP-a je da je poslovanje kompanije i funkcioniranje
ljudskog uma u biti višedimenzionalno – 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
izvještavanja, to bi bio dugačak i mukotrpan posao.
Ideja OLAP-a se zasniva na tehnologiji koji takve višedimenzionalne
sumarizacije kreira automatski i daje ih korisniku na raspolaganje, čime se
stvara mogućnost kombiniranja najrazličitijih 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 višedimenzionalnu
kocku – njegova prednost bila je brzina, a mana veliko zauzeće prostora u
slučaju postojanja većeg broja dimenzija. Drugi je ROLAP (Relational OLAP)
koji je na postojeću relaciju dodao samo sumarizacije – njegova prednost je
malo zauzeće diskovnog prostora, što je plaćeno smanjenom brzinom, ali je
ostala primjenjivost na veliku količinu podataka. Na kraju je prevladao hibridni
HOLAP koncept (Hybrid OLAP), koji samo sumarizacije pohranjuje u
višedimenzionalnoj kocki, dok elementarni nivo podataka ostaje u izvornoj
relaciji i njima pristupa pomoću drill-trough procedura koje iz agregiranih
podataka u OLAP kocki za potrebe detaljnih upita „prelaze“ na korištenje
podataka iz relacija. Na taj način objedinjene su i velika brzina pristupa i
relativno malo zauzeće prostora.
33 / 95
Prednost relacijskog izvještavanja pred OLAP-om je u činjenici da ne postoji
faza izgradnje višedimenzionalne kocke, koja kod kreiranja kocaka od stotina
milijuna zapisa može biti jako dugotrajna. S druge strane, mogućnosti analize
koje pruža OLAP su daleko veće.
Danas se OLAP poslužitelji mogu smatrati dijelom infrastukture, budući da tri
glavna dobavljača baza podataka (Microsoft, Oracle i IBM) imaju svoje
vlastite OLAP servere. Vodeće izvještajne i analitičke platforme mogu se
spojiti i koristiti podatke iz OLAP struktura iz bilo kojeg od tih poslužitelja.
3.8.
Dubinska analiza podataka
Najzahtjevniji način korištenja informacija za analizu je dubinska analiza
podataka (engl. Data Mining), a osnovni joj je smisao izrada prediktivnih
modela koji će predvidjeti ponašanje nekog subjeka ili pojave u budućnosti.
Dubinska analiza podataka se može opisati kao netrivijalan proces
identifikacije neospornih, novih, potencijalno korisnih i razumljivih uzoraka
(engl. patterns) i odnosa (engl. relationships) među podacima u skladištu
podataka. Ima više modela i algoritama koji se koriste te se ovisno o primjeni
odabire najpogodniji. Najpoznatije metode dubinske analize podataka su:
klasifikacija i regresija (algoritmi neuralnih mreža i stabla odlučivanja),
klasteriranje (identificiranje i grupiranje sličnih podataka), sažimanje i
vizualizacija, modeliranje zavisnosti, asocijacije i sekvencijalna analiza
(analiza potrošačke košarice) te analiza vremenskih serija.
Dubinska analiza i prediktivni modeli koriste se u raznim industrijama, a
najčešća područja primjene su sprečavanje prevare u osiguranju, kartičarstvu
i telekomunikacijama, sprečavanje odljeva korisnika u telekomunikacijama i
financijskoj industriji te analiza potrošačke košarice i stimuliranje povećanja
prodaje u maloprodaji.
34 / 95
Za dubinsku analizu podataka izuzetno je bitno imati kvalitetne podatke,
budući da predikitvni modeli bazirani na nekvalitetnim i nekonsolidiranim
podacima neće davati kvalitetne rezultate.
Upravljanje matičnim podacima
3.9.
Pojam upravljanja matičnim podacima (engl. Master Data Management MDM) obuhvaća skup procesa i alata koji dosljedno definiraju i upravljaju
netransakcijskim podacima organizacije, koje prvenstveno uključuje matične
podatke. Sustavima za upravljanje matičnim podacima je cilj implementacija
procesa za prikupljanje, agregiranje, uparivanje, konsolidaciju, osiguranje
kvalitete, praćenje životnog vijeka i distribuiranje matičnih podataka u cijeloj
organizaciji, kako bi se osigurala dosljednost i nadzor u tijeku održavanja i
primjene matičnih podataka.
Sustav za upravljanje matičnim podacima može biti jednodomenski ili
višedomenski, što podrazumijeva upravljanje matičnim podacima vezanim za
jednu
ili
više
poslovnih
domena
–
kupce,
proizvode,
materijale,
organizacijske jedinice, konta. Inicijalno su sustavi za upravljanje matičnim
podacima bili jednodomenski, a u zadnjih nekoliko godina sve više
prevladava višedomenski pristup.
Postoji nekoliko tipova sustava za upravljanje matičnim podacima, od kojih je
nabitnije razdvojiti referencijske i transakcijske sustave. Referencijski sustavi
za upravljanje matičnim podacima sadrže samo pokazivače prema
referentnim podacima u transakcijskim i opertivnim sustavima. Transakcijski
sustavi za upravljanje matičnim podacima u potpunosti preuzimaju
funkcionalnost upravljanja matičnim podacima od transakcijskih sustav. U
njima se matični podaci kreiraju i održavaju te distriburaju transkacijskim
sustavima u stvarnom vremenu.
35 / 95
Implementacija sustava za upravljanje matičnim podacima je vrlo često
potrebna u velikim međunarodnim korporacijama kako bi se omogućio uvid u
odnos s klijentom na razini korporacije kroz sve sustave ili kako bi se mogla
pratiti prodaja istog proizvoda na različitim tržištima. U Hrvatskoj sustav za
upravljanje matičnim podacima koristi Agrokor, a u drugim velikim tvtkama
poput Hrvatskog Telekoma, Hrvatske Pošte ili Zagrebačkog Holdinga planira
se uvođenje sustava za upravljanje matičnim podacima.
Sustavi za upravljanje matičnim podacima se snažno oslanjaju na
funcionalnost platformi za poboljšanje kvalitete podataka, koje se uvijek
nalaze implementirane kao dijelovi takvih sustava, prvenstveno u funkciji
standardizacije, uparivanja i deduplikacije.
Kod sustava za upravljanje matičnim podacima se komponente platformi za
poboljšanje kvalitete podataka koriste i u 'batch' procesima i prilikom obrade
u realnom vremenu, posebice kod transakcijskih sustava za upravljanje
matičnim podacima.
36 / 95
4. Kvaliteta podataka i informacija
Kvaliteta podataka ima tri osnovne komponente:

definiciju podataka (metapodataka),

sadržaj podataka i

kvalitetu prikaza informacija
Kvaliteta konačnih informacija zahtijeva odgovore na pitanja vezana uz
kvalitetu svih navedenih komponenti, iako se vrlo često pod kvalitetom
podataka smatra samo kvaliteta sadržaja, što se uglavnom smatra
funkcionalnostima platforme za poboljšanje kvalitete podataka. Za potpuno
razumijevanje problematike potrebno je okvirno opisati sve tri komponente
važne za kvalitetu podataka i informacija
4.1.
Kvaliteta metapodataka ili definicije podataka
Kvaliteta metapodataka ili definicije podataka je kvaliteta specifikacije
podataka, koja uključuje jasne, precizne i potpune definicije i poslovna
pravila. Definicija podataka predstavlja kriterije integriteta sadržaja podataka.
Bez kvalitetne definicije podataka nema jasne komunikacije za dobavljača
(izvor) podataka, s ciljem da zna koje podatke bi trebao proizvesti i dostaviti.
Također nema jasnog kriterija za mjerenje kvalitete sadržaja podataka.
Pitanje kvalitete metapodataka nije unutar konteksta ovog rada, iako se
može smatrati kritičnim pitanjem za implementaciju, ne samo analitičkih
sustava, nego informacijskih sustava u velikim organizacijama općenito.
Kvaliteti metapodataka najčešće nije posvećena potrebna pažnja.
37 / 95
4.2.
Kvaliteta sadržaja podataka
Kvaliteta sadržaja podataka je točnost vrijednosti podataka. Uključuje
potpunost, standardiziranost, nepostojanje duplih vrijednosti, usklađenost s
definiranim i priznatim pravilima, kao i točnost 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
sadržaja podataka obično se smatra kvalitetom podataka u užem smislu i
softverski proizvodi poznati kao platforme za poboljšanje kvalitete podataka
uglavnom se usredotočuju na probleme točnosti 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
uključuje pravovremenost podataka i kanala za distribuciju informacija, kao i
prezentacijski format koji lako ističe važnost podataka na način koji najbolje
odgovara potrebama radnika znanja. Platforme za poslovnu inteligenciju,
odnosnu za izvještavanje i analizu, obično 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 ključnih kod implementacije sustava za poboljšanje
kvalitete podataka, ne samo za potrebe skladišta podataka, nego za
podizanje i osiguranje traženog nivoa kvalitete podataka u svim sustavima u
organizaciji.
Shankaranarayanan i Cai u [11] definiraju pojam Total Data Quality
Management (TDQM) za sustave za podršku odlučivanju kao analogiju Total
Quality Management (TQM) pristupu koji se koristio u proizvodnji. Ideja
njihovog pristupa je da postoji povezanost tražene kvalitete informacije i vrste
odluke za koju se tražena 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 sučelje i korištenje KPI-eva
omogućavati uvid u kvalitetu podataka u vremenskoj perspektivi, s podacima
o primjerice postotku nepopunjenih matičnih brojeva ili neverificiranih imena.
Također 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 omogućava praćenje
i nadzor kvalitete podataka. Nekoliko godina nakon objave rada većina
vodećih dobavljača platformi za poboljšanje kvalitete podataka već je imala
ugrađenu sličnu funkcionalnost koja je omogućavala poslovnim korisnicima
monitoriranje kvalitete podataka putem jednostavnog web sučelja.
U prošlosti je problematika kvalitete podataka vrlo često bila smatrana
odgovornošću IT funkcije u organizaciji, ali je s uvođenjem koncepata
upravljanja podacima (engl.
Data Governance) došlo i do promjene
shvaćanja odgovornosti za kvalitetu podataka. Wende u [12] uvodi model
39 / 95
upravljanja za kvalitetu podataka, koji se bazira na tri osnovne komponente –
ulogama, područjima i odgovornostima koje su definirane za pojedinu
dimenziju kvalitete.
Upravljanje
kvalitetom
podataka
mora
imati
izvršno
sponzorstvo
u
organizaciji te tijelo koje Wende [12] naziva Data Quality Board, koje je
zaduženo za upravljanje kvalitetom podataka u organizaciji, a sastoji se
primarno od poslovnih korisnika, uz učešće informatičara. Područja kojima se
navedeno tijelo bavi su razvoj strategije upravljanja kvalitetom podataka,
uspostavljanje potrebne organizacije i implementacija informacijskih sustava
za tu namjenu. Unutar tako definiranog okruženja, svaki član tima ima svoju
ulogu i odgovornosti. U velikim tvrtkama u svijetu ovakva organizacijska
struktura je već uobičajena, dok se u Hrvatskoj još ne može susresti u praksi.
5.1.
Tri okruženja za osiguranje kvalitete podataka
Postoje tri osnovna okruženja za osiguranje kvalitete podataka, gdje se može
osigurati da će podaci u skladištu podataka imati najviši stupanj kvalitete.
Prva je instanca, naravno, čišćenje podataka u operativnom okruženju.
Druga prilika je čišćenje podataka u integracijskom i transformacijskom sloju
(procesu). Treća je prilika održavanje učitanih povijesnih podataka u samom
skladištu podataka.
5.2.
Čišćenje podataka na aplikacijskoj razini
Čišćenje podataka na aplikacijskoj razini čini se najprirodnije mjesto za
osiguranje kvalitete podataka. Što su podaci čišći na točki ulaza, bolja je
kvaliteta podataka u skladištu podataka. Teoretski, ako su na aplikacijskoj
razini podaci savršeno čisti, više ih nigdje neće biti potrebno čistiti.
40 / 95
Nažalost, u stvarnom ERP-u i transakcijskim sustavima to nije moguće.
Nekoliko faktora onemogućava da aplikacija bude jedino rješenje za
probleme vezane za kvalitetu podataka.
Prvi problem je pitanje optimizacije aplikacije. Najbolja praksa je omogućiti
brzi unos, promjenu i brisanje podataka u aplikaciji. Implementacija dodatnih
kontrola i ograničenja može usporiti aplikaciju; rad s aplikacijom može učiniti
manje ugodnim te može značajno oslabiti produktivnost, što će dovesti do
lošeg konačnog rezultata. S druge strane, ručni unos podataka daleko je od
savršenog, stoga je niska kvaliteta podataka u ovom slučaju neizbježna.
Druga poteškoća je stanje same aplikacije. U mnogim slučajevima, aplikacija
je stara i nije dobro dokumentirana. Vrlo često nije poznato gdje se nalazi
zadnja verzija izvornog koda aplikacije. Čest je slučaj i da su aplikacije
kreirane korištenjem zastarjelih alata i programskih jezika. Programeri koji su
prvotno kreirali neke aplikacijske module možda su davno otišli iz kompanije.
Programeri aplikacija često se boje ući u aplikacijski kod i značajnije ga
mijenjati. Popravljanje jednog problema moglo bi uzrokovati pokretanje
čitavog niza drugih problema. Krajnji rezultat je da je aplikacija lošija nego što
je bila prije popravljanja.
Razlog zašto 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
postojeće zahtjeve i ne vide hitnost, ili bilo kakvu motivaciju da se vraćaju u
stari kod i da ga mijenjaju kako bi riješili tuđe probleme.
Nažalost, čak i kada bi bilo moguće očistiti podatke na aplikacijskoj razini, još
uvijek je potrebno podatke čistiti i kasnije, prilikom prebacivanja u skladište
podataka. Razlog zašto je integracijsko i transformacijsko čišćenje još uvijek
potrebno, čak i kada su aplikacijski podaci savršeni, leži u tome što
aplikacijski podaci nisu integrirani s podacima iz drugih aplikacija i sustava.
41 / 95
Kompanije koje implementiraju skladište podataka obično imaju nekoliko
aplikacijskih sustava koji imaju sučelja na aplikacijskoj razini samo za
podatke koji se razmjenjuju, no glavni podaci nisu sinkronizirani.
5.3.
Čišćenje podataka u integracijskom sloju
Čišćenje podataka u integracijskom i transformacijskom sloju moguće je
samo kada su podaci izvučeni iz aplikacija u privremeni spremnik.
Svaka aplikacija ima vlastitu interpretaciju podataka, kako je to originalno
odredio dizajner aplikacije. Definicije polja podataka, ključevi, atributi,
strukture, kodne stranice i pravila dekodiranja razlikuju se između aplikacija.
Isto tako, veze među podacima unutar i između sustava možda će ostati
neotkrivene.
Kako bi skladište podataka sadržavalo integrirane podatke, mnoge
aplikacijske strukture i konvencije moraju se integrirati u jedinstveni skup
struktura i konvencija. Anomalije podataka o imenima, adresama, opisima i
šiframa računa drugo su područje za popravljanje.
Nekonzistentnosti između definicija metapodataka i sadržaja podataka s
vremenom dolaze do izražaja, npr. imena pravnih osoba pomiješana su s
imenima fizičkih osoba, u adresama nedostaju neki podaci ili su postojeći
podaci zastarjeli, neke informacije su nepotpune zato što su definicije polja
za unos podataka nezadovoljavajuće, specijalni znakovi se koriste kao
separatori, nedostaju neke vrijednosti u poljima s podacima, koriste se
različite kratice, i sl.
Ovi se problemi kvalitete podataka mogu naći u svakom skupu aplikacijskih
podataka te mogu dovesti u pitanje ostvarivanje korporativne inteligencije.
Integracijski i transformacijski sloj je ključna prilika za implementaciju
procedura za poboljšanje kvalitete podataka, gdje će promjena na bolje imati
42 / 95
najznačajniji pozitivan poslovni rezultat, stoga će u ovom radu biti dan
naglasak upravo na ovu priliku.
Procesi koji će biti detaljnije opisani su čišćenje, ispravljanje, profiliranje,
uparivanje, obogaćivanje, analiza i standardizacija podataka.
5.4.
Održavanje povijesnih podataka u skladištu podataka
Održavanje povijesnih podataka u skladištu podataka od vitalne je važnosti
zbog toga što skladište podataka sadrži podatke prikupljene kroz neki
vremenski period. Problem je u tome što se podaci s vremenom mijenjaju. U
nekim slučajevima, promjene su spore i zanemarive. No, u nekim
slučajevima promjene su brze i radikalne.
S opisanim promjenama javlja se i potreba za
održavanjem kvalitete
podataka u skladištu podataka nakon što su podaci već učitani u skladište
podataka. Najčešći način za praćenje promjena u podacima je korištenje
dimenzija koje se sporo mijenjaju.
Postoje tri osnovne vrste takvih dimenzija, koje su vrlo detaljno obrađene u
teoriji skladištenja podataka te nekoliko hibridnih pristupa koji koriste neke od
značajki pojedinih osnovnih tipova. Nekad su potrebna i radikalnija rješenja,
koja se mogu prikazati kroz nekoliko jednostavnih primjera.
Prvi je primjer uvođenje Eura kao nove valute u Europskoj uniji 2000. godine,
što je sve prošle transakcije obavljene u bivšim valutama učinilo
neupotrebljivim i neusporedivim s novim transakcijama. Prema tome, svi stari
računi i fakture morali su se u skladištu podataka pretvoriti u iznose izražene
u Eurima.
Drugi je primjer zamjena postojećeg zastarjelog (eng. legacy) sustava s
modernim transakcijskim sustavom, što se obično čini tako da se u novi
transakcijski sustav učitaju samo otvorene stavke iz zastarjelog sustava. Svi
43 / 95
povijesni podaci koji su već učitani u skladište podataka moraju se pretvoriti i
transformirati tako da budu usporedivi s novim podacima u skladištu
podataka.
44 / 95
6. Pojmovi i algoritmi vezani za platforme za kvalitetu podataka
U ovom poglavlju će biti opisani pojmovi i najčešće korišteni algiritmi za
procjenu sličnosti, standardizaciju i uparivanje koji se pojavljuju unutar
platformi za poboljšanje kvalitete podataka, kako bi se mogle detaljno opisati
i ocijeniti pojedine platforme koje će biti uspoređene u sljedećim poglavljima.
Riječ je uglavnom o matematičkim algortimima koji daju ocjenu sličnosti te o
fonetskim algoritmima koji kodiraju imena temeljem načina na koji se
izgovaraju.
Kod implementacije algoritma unutar platformi za poboljšanje kvalitete
podataka uvijek se postavlja prag sličnosti (engl. treshold) te svi parovi koji
postignu rezultat iznad praga će biti proglašeni istovjetnim. Neke platforme
imaju mogućnost definiranja i praga moguće sličnosti (engl. clerical), koji je
niži od praga sličnosti te se parovi koji postignu rezultat (engl. score) između
ta dva praga proglašavaju potencijalno istovjetnim. Parovi koji postignu
rezultat ispod pragova proglašavaju se različitim.
Kod nekih platformi moguće je za usporedbu dva niza paralelno koristiti
nekoliko algoritama te konačan rezultat dobiti izračunom težinskog prosjeka
na taj način dobivenog rezultata, što osigurava najpouzdanije rezultate.
Pojmovi i algoritmi na koje će biti stavljen naglasak su sljedeći:

Označavanje (engl. tokenization)

Soundex i Nysiis

Edit Distance algoritam

Hamming Distance algoritam

Jaro-Winkler algoritam

Bigram algoritam

Neizrazita (engl. fuzzy) logika
45 / 95
6.1.
Označavanje
Označavanje (engl. tokenization) je pojam koji se u računarstvu koristi za
označavanje i po mogućnosti klasifikaciju dijelova niza znakova koji je
potrebno obraditi. Oznake koji se dobiju kao rezultat procesa se zatim
prosljeđuju sljedećim koracima u procesu obrade. Označavanje se često
smatra dijelom procesa analize sintakse (engl. parsing).
U platformama za poboljšanje kvalitete podataka, označavanje je naziv za
proces koji se koristi za označavanje pojedinih elemenata niza, kako bi se u
daljoj obradi niz mogao razdvojiti na sastavne dijelove i standardizirati.
Postoji pet osnovnih tipova oznaka:

Slovčana oznaka koja se sastoji od alfabetskih znakova (Word)

Numerička oznaka koja se sastoji od brojčanih znakova (Number)

Kod se sastoji od miješanih alfanumeričkih znakova (Code)

Inicijal je jedan alfabetski znak (Initial)

Simbol je punktuacija ili neki drugi simbol (Symbol)
U samom procesu označavanja, bitne su i dvije komponente koje se moraju
definirati. Prva komponenta je lista graničnika koji razdvajaju pojedine
oznake – to su najčešće razmak, kosa crta ili točka u hrvatskom jeziku.
Druga komponenta je lista znakova koje se kod označavanja treba ignorirati,
koja se ponekad ne treba koristiti.
Kod implementacije u pojedinim platformama za poboljšanje kvalitete
podataka postoje i drugi tipovi oznaka osim pet osnovnih, koji ovise o
platformi. Na njih u ovom radu neće biti stavljen dodatni naglasak, budući da
se radi o izvedenicama osnovnih oznaka.
U samom procesu označavanja, neke platforme omogućavaju da se niz od
nekoliko riječi usporedi sa sadržajem postojećih riječnika te se za oznake koji
su nađene u riječniku koristi oznaka koja se definira prema sadržaju rječnika.
Tako bi niz „Marko Marković Smith“ označen imao oblik „word word word“, a
46 / 95
označen s korištenjem rječnika hrvatskih imena i prezimena imao oblik „ime
prezime word“, budući da se Smith ne nalazi u rječniku hrvatskih imena i
prezimena.
Poseban slučaj označavanja je označavanje na nivou pojedinog znaka u
nizu, gdje se radi analiza strukture pojedinog niza te se svakom znaku daje
oznaka radi li se o slovu, numeričkom znaku ili simbolu. Ovakvo označavanje
je korisno kod analize oblika zapisa i standardizacije telefonskih ili matičnih
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 način da se kodiraju na isti način, kako bi se eliminirale manje
pogreške 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 sačuva prvo slovo alfanumeričkog niza, a ostala
slova zamijeni s brojkama. Važno 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 sljedeći način:

1 – b, f, p, v

2 – c, g, j, k, q, s, x, z

3 – d, t

4–l

5 – m, n

6-r
47 / 95
Ukoliko se znak s istom kodom pojavi dvaput za redom, koristi se samo
jedan kod. Također, maksimalna dužina kodiranog niza je 4. Ukoliko je niz
kraći od 4, do kraja se nadopunjava s nulama.
NIISYS algoritam je poboljšana 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 poboljšanje u
raspoznavanju 2,7% u odnosu na Soundex. Pravila kodiranja su znatno
složenija.
Oba ova algoritma su implementirana u većini platformi za poboljšanje
kvalitete podataka. Najveći problem oba algortima za naše prilike je to što su
napravljeni za engleski jezik te su za naša imena, koja su slavenskog
porijekla, praktično neupotrebljivi.
Postoji i algoritam koji se može 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 može indeksirati
slavenska, germanska, francuska i druga imena. Ovaj algoritam je vrlo
složen – primjerice samo slovo C se može „smjestiti“ u više od sto različitih
konteksta.
Ovaj algoritam ima javno objavljen kod za implementiraciju u programskim
jezicima Java, Perl i PHP, ali ga se ne može naći u vodećim platformama za
poboljšanje kvalitete podataka. Razlog tome je vjerojatno relativna novost
algoritma, a također i pretežita usmjerenost platformi na englesko govorno
područje.
48 / 95
6.3.
Edit Distance algoritam
Edit Distance algoritam [9] kreira rezultat sličnosti za dva niza podataka
izračunom
minimalnog
broja
transformacija
odnosno
„troška“
za
transformaciju jednog niza u drugi ubacivanjem, brisanjem ili zamjenom
pojedinih znakova. Što je rezultat veći, veća je i sličnost između 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 uspoređuju nizovi koji sadrže
jednu riječ ili kratki tekstualni nizovi, poput imena ili kratkih adresa.
Za primjer se mogu uzeti dva niza:

Kraljavićeva Ul

Kraljevićeva Ul.
Algoritam će izračunati trošak zamjene „a“ iz prvog niza s „e“ u drugom nizu
te trošak dodavanja točke na kraju prvog niza. U implementaciji algoritma u
pojedinoj platformi za poboljšanje kvalitete podataka, ostvareni rezultat
sličnosti bi trebao biti preko 0,9, što bi značilo da su ova dva niza slična
preko 90%.
Implementacija ovog algoritma u pseudo kodnoj funkciji, koja uzima dva niza
duljine m i n te izračunava rezultat sličnosti, 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,
//
d[i, j-1] + 1,
//
deletion
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 pronalaženjem pogrešaka u prijenosu podataka.
Algoritam služi za usporedbu nizova iste duljine te daje rezultat koji kaže
koliko zamjena treba napraviti da bi dva niza koja se uspoređuju 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 najčešće se koristi za
usporedbu nizova kod kojih je bitna duljina i pozicija pojedinih znakova u
nizu, poput telefonskih brojeva, poštanskih brojeva, matičnih 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 izračun različitosti, 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 "premještanja".
Dva znaka iz s1 i s2 se smatraju "uparivim" ako razmak njihovih pozicija nije
veći od polovice duljine duljeg niza, umanjene za jedan. Svaki znak iz niza s1
se uspoređuje sa svim “uparivim” znakovima iz niza s2. Broj uparivih, a
različitih znakova podjeljen s dva daje broj "premještanja".
Jaro-Winkler distance algoritam razrađuje Jaro distance algoritam na način
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 početku oba niza

p je konstanta, odnosno faktor kojim se rezultat sličnosti uvećava
nizovima koji imaju takve zajedničke prefikse
51 / 95
Jaro-Winkler Distance algoritam jedan je od algoritama koji daje najbolje
rezultate. Kod implementacija na pojedinim platformama za poboljšanje
kvalitete podataka vrlo se često koristi reverzna logika, tako da se umjesto
konstante za uvećavanje rezultata koristi konstanta za penalizaciju odnosno
umanjenje rezultata ukoliko prvih l znakova na početku 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 početni znak u podnizu. Što je veći broj parova koji se pojavljuju u
oba niza, veći je rezultat koji algoritam daje.
Ovaj algoritam daje najbolje rezultate kod uspoređivanja dugih nizova
znakova, poput dugih adresnih linija ili komentara i napomena. Ako se uzmu
kao primjer dva uobičajena imena – Dražen i Dragan – može se vidjeti kako
Bigram Distance algoritam funkcionira. Kada se oba ova imena razlože na
parove znakova dobija se sljedeće:
Dražen – 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 (označeni su italic fontom), tako da je ukupan rezultat 0,4,
odnosno 40%.
Važno je napomenuti da je Bigram Distance algoritam samo jedan od
algoritama koji pripada grupi n-gram algoritama, gdje n može biti jedan, dva,
tri ili više. 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 poboljšanje kvalitete podataka, nego i kod prepoznavanja
govora i u prediktivnim modelima. Ovisno o aplikaciji, n-gram algoritam može
raditi sa znakovima ili riječima kao jediničnim elementima. Google neke od
svojih algoritama za raspoznavanje i pretraživanje temelji na n-gram
algoritmima.
Bigram Distance je algoritam koji je vrlo jednostavan za shvaćanje, korištenje
i implementaciju te ga se može naći implementiranog u većini vodećih
platformi za poboljšanje kvalitete podataka.
6.7.
Neizrazita logika
Koncept neizrazite (engl. fuzzy) logike bazira se na pretpostavci da kod
procesiranja podataka postoji mogućnost djelomične pripadnosti nasuprot
uobičajene egzaktne logike pripadnosti odnosno nepripadnosti, odnosno na
ocjeni relativnih pretpostavki u donošenju zaključaka.
Pojednostavljeno, neizrazita logika koristi IF [A] AND [B] THEN [C] pristup da
bi došla do rješenja, umjesto uobičajenog matematičkog modeliranja te je u
tome vrlo slična ljudskom načinu zaključivanja. Važno je primijetiti da nema
ELSE opcije te da su u neizrazitnoj logici sve alternative definirane.
Kao primjer se može koristiti čovjek koji se tušira i situacija da je voda koju
koristi prehladna i postaje sve hladnija, gdje bi neizrazitna logika dala
sljedeće rezultate:
1) IF [voda je prehladna] AND [voda postaje hladnija] THEN [pojačaj toplu
vodu]
2) IF [voda je jako hladna] AND [voda postaje hladnija] THEN [brzo pojačaj
toplu vodu]
53 / 95
U ovom logičkom procesu nigdje egzaktno nije definirana temperatura vode i
brzina hlađenja vode, ali zaključci koji su izvedeni su potpuno logični. Ovakva
logika koristi se kod neegzaktnih premisa, ali ipak u implementaciji zahtijeva
numeričke varijable koje ocjenjuju iznos nepreciznosti.
Prema toj logici, iznos nepreciznosti (pogreške) od traženog ishoda u drugoj
izjavi je veći nego u prvoj. Ovakva nedirektna logika omogućava
raspoznavanje sličnih uzoraka te se koristi za eliminiranje pogrešaka i
šumova u nizovima.
U platformama za poboljšanje kvalitete podataka neizrazitna logika koristi se
kod usporedbe i grupiranja atributa po sličnosti, kako bi se omogućila
standardizacija i uparivanje podataka.
54 / 95
7. Proces poboljšanja kvalitete podataka
Kao što je ranije navedeno, kvaliteta podataka u užem smislu se odnosi na
kvalitetu sadržaja podataka u skladištu podataka te se uglavnom odnosi na
čišćenje i korekciju podataka koji iz operativnih sustava dolaze u skladište
podataka.
Procesi poboljšanja kvalitete podataka za vrijeme integracije i transformacije
podataka ponajviše su usmjereni na čišćenje podataka o klijentima, kao što
su imena i adrese, budući da se u tim podacima nalazi najviše pogrešaka i
nekonzistentnosti. Postoji nekoliko osnovnih tipova koraka u procesu
poboljšanja kvalitete podataka koje bi trebalo uzeti u obzir ili implementirati
unutar procesa, kako bi se u skladištu podataka osigurala visoka kvaliteta
podataka, a to su:

Analiza i profiliranje,

Standardiziranje i ispravljanje,

Obogaćivanje,

Uparivanje i

Preživljavanje.
Svi navedeni koraci se ne moraju koristiti u procesu, a problem i potreba
određuju 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 poboljšanja kvalitete podataka. U
ovoj fazi se analiziraju sadržaj i uzorci podataka kako bi se opisali uzorci
izvora podataka koji se najčešće pojavljuju. Informacije koje se skupljaju na
55 / 95
ovaj način pomažu pri utvrđivanju razine trenutne kvalitete podataka i pri
odlučivanju koje bi aktivnosti za poboljšanje kvalitete podataka trebalo uzeti u
obzir kod sljedećih koraka. Profiliranje je vrlo moćno sredstvo za
razumijevanje sadržaja podataka. Osim vrijednosti i frekvencija pojavljivanja
pojedinih vrijednosti, alati za profiliranje omogućavaju mnoge druge
funkcionalnosti, poput profiliranja upita koji povezuju više tablica, grafičkog
prikaza vrijednosti te kreiranje pravila za standardizaciju i validaciju koja
poboljšavaju vrijednost i razumljivost izrađenog profila.
Kao primjer takve analize, uzorak broja pojavljivanja nekih uobičajenih riječi u
slučajnom uzorku od 8.000 adresa prikazan je u Tablici 7.1.
Riječ
Broj pojavljivanja
00000085
B
00000050
BANA
00000157
BRAĆE
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 riječi u uzorku od 8.000 hrvatskih
adresa
56 / 95
7.2.
Standardizacija i korekcija
Standardizacija i korekcija je sljedeća faza procesa poboljšanja kvalitete
pdoataka. U ovoj se fazi imena i adrese standardiziraju kako bi se uskladili s
listom važećih imena, adresa, poštanskih brojeva i gradova. Softverske
platforme za poboljšanje kvalitete podataka moraju imati prethodno
definirana pravila da bi se omogućila standardizacija podataka.
Ova pravila uključuju tablice s važećim podacima, kao i procedure koje
objašnjavaju kako se odnositi prema svakom uzorku koji se može pronaći
unutar podataka te kako ga standardizirati. Na primjer, ako u izvornim
podacima postoji vrijednost „Kraljavićeva Ul. 2B/3“, ta bi pravila trebala
prepoznati dijelove adrese prikazane u Tablici 7.2.
Dio adrese
Kontekst
Kraljavićeva
Ime ulice
Ul.
Kratica vrste ulice
2
Kućni broj
B
Dodatak kućnom broju
/
Separator
3
Kat
Tablica 7.2: Dijelovi adrese
Kada se ispravno prepoznaju dijelovi adrese, tada se oni mogu ispraviti. U
našem bi slučaju trebalo prepoznati i ispraviti dvije stvari:
57 / 95
1) „Kraljavićeva“ nije važeće ime ulice pa će se zamijeniti s
„Kraljevićeva“, temeljeno na sličnosti uzorka netočno napisane i
ispravne vrijednosti.
2) „Ul.“ je kratica za „Ulica“.
Standardizacija se temelji na pragu tolerancije. Prag tolerancije određuje
stupanj nesigurnosti koja se može tolerirati u zapisivanju neke oznake.
Algortimi opisani u 6 koriste se kako bi se uzele u obzir fonetske greške,
slučajna umetanja, brisanja te zamjena i transpozicija znakova.
Posljednji korak ovog dijela procesa je preoblikovanje podataka u važeću
formu koja će se koristiti u kasnijim koracima procesa.
7.3.
Dopunjavanje
Dopunjavanje je faza procesa u kojem se nedovršeni i nepotpuni podaci
upotpunjavaju nedvojbeno ispravnim podatkovnim elementima.
Primjerice, ako adresa kupca ima važeće ime grada, može se dopuniti s
važećim poštanskim brojem, županijom ili regijom. Također, imena se mogu
nadopuniti odgovarajućim prefiksima za oslovljavanje.
Ovaj se korak ne koristi često zbog toga što se većina dopuna može obaviti u
fazi standardizacije i korekcije.
7.4.
Uparivanje
Uparivanje je faza procesa poboljšanja kvalitete podataka u kojoj se zapisi
uparuju s podacima iz različitih izvora, ovisno o relativnoj sličnosti.
Obično se proces uparivanja obavlja kroz nekoliko faza. U svakoj fazi koristi
se jedan ili više atributa za „blokiranje“ dijelova skupova zapisa koji će se
58 / 95
upariti te se analizira jedan ili više atributa kako bi se otkrilo da li su oni
dovoljno slični da bi se radilo o podacima vezanim za istu osobu ili
kućanstvo.
Ako sličnost nadmašuje definirani prag sličnosti, upareni zapis će dobiti
jedinstveni dodatni identifikator koji će ih definirati kao podatke o istom kupcu
te će ih isključiti iz sljedećih faza.
Primjerice, u jednom prolazu jedinstveni identifikator osobe može 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 postojećima, nastalim u prvom prolazu. U sljedećim
prolazima mogu se definirati dodatna pravila koja će označiti neke od
preostalih podataka. Važno je napomenuti da se tu radi u grupama koje
imaju dva ili više zapisa, a ne isključivo o parovima od dva zapisa.
Osim zapisa koji sigurno predstavljaju iste subjekte, postoje i parovi koji
možda predstavljaju iste subjekte, odnosno relativna sličnosti ima vrijednost
manju od praga sličnosti, a veću od praga sigurne različitosti. 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 najčešće koriste web sučelja koja su standardni dio
funkcionalnosti vodećih platformi za poboljšanje kvalitete podataka.
Slika 7.1. Informatica Data Quality Assistant – primjer web aplikacije u kojoj
poslovni korisnik potvrđuje predloženo uparivanje
59 / 95
7.5.
Preživljavanje
Preživljavanje je zadnja faza procesa poboljšanja kvalitete podataka gdje se
između svih uparenih zapisa biraju oni najbolji, koji se često naziva zlatni ili
referentni zapis (engl. golden record). Svi preživjeli podaci ne moraju nužno
potjecati iz samo jednog zapisa te najčešće sadrže dijelove nekoliko zapisa
iz različitih 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 sigurnošću većom od definiranog praga
sličnosti, odabir atributa koji će preživjeti je najčešće automatiziran prema
pravilima definiranim u standardizaciji, odnosno prema nivou pouzdanosti
izvornog sustava iz kojeg dolaze.
Za zapise koji su clerical, osoba (data steward) koja potvrđuje uparivanje,
kroz korisničko sučelje odabire atribute koji će ići u zlatni zapis, a postoji i
mogućnost direktnog unosa ako atribut ni iz jednog izvornog zapisa nije
ispravan.
Uparivanje i preživljavanje vrlo često su procesi koji se dešavaju istovremeno
kroz jedno korisničko sučelje koje je opisano u 7.4
60 / 95
8. Dobavljači i platforme za poboljšanje kvalitete podataka
Softverske platforme koji služe za profiliranje, čišćenje, standardiziranje,
uparivanje i preživljavanje podataka poznati su kao platforme za poboljšanje
kvalitete podataka. Analitičari tržišta kao što su Gartner Group [8] i Forrester
[4] u svojim tržišnim analizama koje redovno publiciraju obuhvaćaju većinu
značajnijih dobavljača.
Ti su dobavljači povijesno bili manji od dobavljača platformi za poslovnu
inteligenciju i integraciju podataka, pa je tržišni trend prije nekoliko godina
bila jaka konsolidacija, gdje su velike kompanije na podatkovnom tržištu
kupile manje dobavljače platformi za poboljšanje kvalitete podataka te
integrirale njihovu tehnologiju u svoje platforme za integraciju podataka [4].
U posljednjih nekoliko godina su IBM, Informatica, SAP i SAS, zahvaljujući
svojim cjelovitim rješenjima, preuzele značajan tržišni udio na tržištu platformi
za poboljšanje kvalitete podataka, nadograđujući se s ovim dijelom ponude
na integracijska rješenja.
Također, ove tvrtke na tržištu platformi za poboljšanje kvalitete podataka
imaju i vodeće položaje prema analitičarima [8]. Jedini značajan samostalan
dobavljač na tom tržištu ostao je Trillium Software. Ostali važniji dobavljači
poput Oraclea i Microsofta donose određene funkcionalnosti za upravljanje i
poboljšanje kvalitete podataka u trenutnim verzijama svojih proizvoda, no
zasad bez značajnijeg tržišnog utjecaja.
Iako su platforme za poboljšanje kvalitete podataka dobro prihvaćene u SADu, postoje dva glavna problema zašto je njihova prihvaćenost na globalnoj
razini još uvijek ograničena.
Prvi razlog je što ovi alati još uvijek nisu u potpunosti integrirani s
platformama za integraciju podataka i, iznenađujuće, vrlo često je potrebno
uložiti mnogo truda kako bi se integrirala dva proizvoda, čak i od istog
dobavljača, č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 specifična za pojedine jezike i države,
a većina je dobavljača kreirala i prilagodila ova pravila za SAD i nekoliko
najvažnijih svjetskih jezika – engleski, njemački, francuski i španjolski te u
zadnje vrijeme sve češće i za jezike Dalekog Istoka.
U Hrvatskoj se, u donekle značajnijoj mjeri, može osjetiti prisustvo nekoliko
dobavljača, čije proizvode je autor koristio na stvarnim projektima te će u
nastavku rada biti detaljnije opisani i uspoređeni. U ovom slučaju riječ je o
dvije prave platforme za poboljšanje kvalitete podataka – IBM QualityStage i
Informatica Data Quality te o dvije, u nas vrlo česte, platforme za integraciju
podataka odnosno primarno za punjenje skladišta podataka, s limitiranom
funkcionalnosti za čišćenje 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 rješenja za poboljšanje 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 tadašnji
Ascential kupio 2002. godine. Arhitektura tog proizvoda je bila prilično
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 korisničko sučelje bilo je vrlo rudimentarno, dok se za razvoj pravila
koristio vrlo složen i specifičan programski jezik. Unatoč svim tim manama,
platforma je imala odlične ugrađene 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 većina ovih problema osim
specifičnog programskog jezika u aktualnim verzijama više nije prisutna
Možda jedina ozbiljnija zamjerka aktualnoj inačici QualityStage platforme je
nepostojanje web sučelja za poslovne korisnike i analitičare, pomoću kojeg bi
oni direktno mogli raditi na poboljšanju kvalitete podataka. Također,
platforma za profiliranje Information Analyzer je potpuno odvojen proizvod te
funkcionalnosti nisu integrirane, iako je profiliranje prvi korak u procesu
poboljšanja kvalitete podataka.
U našoj 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 poboljšanje kvalitete podataka.
U današnjoj verziji, platforma za kvaltietu podataka Informatica Data Quality
ima i sve potrebne funkcionalnosti za profiliranje. Uz profiliranje, postoje i
dodatne komponenete za utvrđivanje identiteta osoba te za validaciju i
standardizaciju adresa za većinu država u svijetu. Informatica Data Quality je
u potpunosti integrirana s Informatica PowerCentrom, platformom za
integraciju podataka.
Bitna strateška odrednica općenitog 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 ključne indikatore za praćenje kvalitete podataka, pratiti
povijest izvršavanja procesa i rezultata, verificirati uparene zapisa, odnosno
pregledavati, popravljati i verificirati odbačene zapise.
63 / 95
Slika 8.1. Informatica Data Quality Analyst – sučelje u web pretraživaču
namjenjeno primarno poslovnim korisnicima
Uspoređujući s funkcionalnostima drugih vodećih platformi, autor je mišljenja
da je Informatica Data Quality trenutačno najpotpunije i najfleksibilnije
rješenje na tržištu.
U našoj 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 specifične
platforme za poboljšanje kvalitete podataka. Oba njihova proizvoda za
integraciju podataka imaju neke osnovne funkcionalnosti za poboljšanje
kvalitete podataka, ali u obimu i kvaliteti koja nije usporediva s platformama
Informatice i IBM-a.
64 / 95
Pristup Oraclea se najčešće temeljio na rješenjima u kojima se kao ugrađena
funkcionalnost (engl. OEM – original equipment manufacturer) koristi neka od
postojećih platformi na tržištu. Ovisno o tome da li je neko rješenje plod
internog razvoja ili je došlo kroz akviziciju kojih je Oracle napravio vrlo mnogo
u proteklih desetak godina u različitim područjima, najčešće su u Oracleovim
rješenjima ugrađene platforme Informatice i Trilliuma.
Autoru nije poznato da netko od većih korporativnih korisnika u našoj regiji
koristi Oracle proizvode za poboljšanje kvalitete podataka sustavno i u
ozbiljnijem obimu.
8.4.
Microsoft
Microsoft SQL Server Integration Services
unutar
svoje
integracijske
platforme
nudi
vrlo
bazičnu
funkcionalnost za poboljšanje kvalitete podataka, koja od prethodno opisanih
funkcionalnosti pokriva samo uparivanje i grupiranje temeljem usporedbe
nejednakih vrijednosti po sličnosti korištenjem Fuzzy logike.
Za to se koriste dvije ugrađene transformacije – Fuzzy Lookup i Fuzzy
Grouping.
Fuzzy Lookup set ulaznih podataka uparuje s već postojećim setom
referentnih podataka prema odabranom ključu ili ključevima 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ć postojeći 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 može se podesiti koji će se znakovi smatrati
graničnicima te podesiti prag minimalne sličnosti.
65 / 95
Iako je riječ o elementarnoj funkcionalnosti uparivanja i deduplikacije, u
određenim slučajevima na projektima ove transformacije su se već pokazale
izuzetno korisnima, pogotovo kod konsolidacije matičnih podataka o
klijentima koji dolaze iz više različitih operativnih aplikacija.
Dakle, od pet osnovnih funkcionalnosti za poboljšanje kvalitete podataka
Microsoft SQL Server Integration Services ima implementiranu samo jednu.
Microsoft je za sljedeću 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 počne koristiti platforma za poboljšanje kvalitete podataka s
ciljem čišćenja podataka koji se koriste u hrvatskim kompanijama, potrebno
je kreirati potrebna pravila obrade podataka za Hrvatsku.
Prvi korak je osiguranje odgovarajuće potpore hrvatskim kodnim stranicama
koje trebaju izraditi osobe zadužene za razvijanje platformi i koje trebaju biti
kodirane unutar samog proizvoda. Na sreću, u Hrvatskoj se koriste Latin II
kodne stranice koje se koriste i u mnogim drugim srednjoeuropskim
zemljama, pa je većina dobavljača već izradila potporu za Windows-1250 i
ASCII8859-2 kodne stranice. Nažalost, to je samo jedan olakšavajući faktor
koji će omogućiti kreiranje lokalnih pravila.
Drugi i mnogo zahtjevniji korak je kreiranje nekoliko pravila koja će osigurati
funkcionalnosti platforme za čišćenje i standardiziranje hrvatskih podataka.
Ova su pravila načinjena od nekoliko komponenti koje su za svaku platformu
različita te se trebaju dodatno razviti i pripremiti za korištenje.
U nastavku će biti prikazano kako se za standardizaciju hrvatskih imena i
adresa prilagođavaju dvije najprisutnije platforme na tržištu – IBM Quality
Stage i Informatica Data Quality.
9.1.
IBM QualityStage
Najmanje jedan skup pravila potreban je za čišćenje 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 sadrži listu domena i polja za uparivanje i izvještavanje.
Svako polje je identificirano pomoću kratice, na primjer IG za Ime Grada.
Ovdje se također mogu pronaći informacije o tipu podataka (npr.
character) i njihovoj duljini.
2) Klasifikacijska tablica omogućuje procesu standardizacije da identificira i
klasificira ključne riječi, 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 pridružuju pojedinim elementima podataka. Stadij
standardizacije koristi Klasifikacijsku tabelu za identifikaciju i klasifikaciju
ključnih riječi, kao što su tip ulice i vrsta oslovljavanja. Klasifikacijska
tablica omogućuje standardizaciju i ovakvih riječi.
3) Pattern-Action File sadrži pravila standardizacije; to su akcije izvršenja na
temelju danih uzoraka oznaka. Standardizacija započinje s rastavljanjem
svih elemenata adresa na oznake. Svaka oznaka je riječ, broj ili
kombinacija odvojena pomoću jednog ili više 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, pridružen je
određenoj klasi. Ako se ne nalazi u tabeli, oznaka se dodjeljuje jednoj od
standardnih klasa: brojevima, slovima, nepoznatim ili nekim posebnim
znakovima.
4) Lookup tablice sadrže informacije specifične za određeni skup pravila; na
primjer, Lookup tablica sadrži imena uključena u skup pravila vezana za
imena. Sadržaj ovih tablica može se po potrebi i ručno uređivati.
Uključene 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 pružaju dodatne upute. Informacije u Override
tablicama imaju prednost pred sadržajem datoteka iz prve četiri točke.
Ove tablice omogućuju prilagodbu ponašanja tijekom označavanja i
standardizacije ako su rezultati koji su dobiveni netočni ili nepotpuni.
68 / 95
Da bi se dovršila lokalizacija pravila za hrvatski jezik, potrebno je kreirati tri
od pet opisanih komponenti: Klasifikacijsku tabelu, Lookup tablice i PatternAction file. Dictionary File koji definira strukturu je uglavnom isti kao i za
skupove pravila za druge jezike. Override tablice se kreiraju u izvršnom
okruženju, s ciljem finog podešavanja pravila. Nažalost, javni izvori koji mogu
pomoći pri kreiranju Lookup i Klasifikacijskih tablica nisu dostupni, osim liste
hrvatskih poštanskih ureda.
Klasifikacijska tablica za svako pravilo kreirana je na temelju analize
podataka pronađenih u nekoliko različitih velikih izvora podataka. Sve
moguće različite verzije iste ključne riječi 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
ŠETALIŠTE
ŠETAL
ŠETALIŠTE
ŠETALIŠTE
ŠETALIŠTE
Tablica 9.1. Dio klasifikacijske tablice za HRADDR pravilo
69 / 95
Lookup tablica za svako se pravilo kreira na sličan način kao i Klasifikacijska
tablica. Primjerice, za kreiranje Lookup tablice za osobna imena biti će
korištena različita imena iz nekoliko velikih izvora. Ovu bi listu trebalo
detaljno provjeriti i utvrditi ima li nepravilno napisanih imena, mogućih
prezimena ili pak nehrvatskih imena.
Ovo iziskuje mnogo više vremena nego kreiranje Lookup tablica. Isto tako,
Klasifikacijske tablice zahtijevaju s vremenom mnogo više održavanja.
Kreiranje Pattern-Action datoteke je najzahtjevniji dio procesa lokalizacije.
Prvo treba analizirati sve uzorke podataka. Nakon toga, za sve moguće
uzorke, akcije će se definirati tako da se svaka oznaka stavi u odgovarajuću
kategoriju. Kada se oznake kategoriziraju, mogu se upariti s Lookup
tablicama, pa se standardizirani podaci mogu preoblikovati.
Hrvatske adrese sadrže mnoge specifičnosti koje se ne mogu pronaći u
drugim zemljama. Rimski brojevi koriste se za određivanje dijelova ulica, kao
na primjer „X. Kašinski odvojak 12 B“, a platforme za poboljšanje kvalitete
podataka ih prepoznaju kao kratice, a ne kao brojeve.
Drugi veliki problem bile su nejednoznačne veze između poštanskih ureda i
poštanskih brojeva. Na primjer, i „Samoborska 15, Odranski Obrež, 10010
Novi Zagreb“ i „Samoborska 15, 10010 Odranski Obrež“ važeće su adrese.
Kako bi se to riješilo, uveden je još jedan atribut adrese, tzv. naselje, pa je
uzorak prepoznavanja postao još složeniji.
Dodatna otežavajuća okolnost je što programski jezik koji se koristi za
kreiranje pravila nije neki od uobičajenih programskih jezika, nego vlastito
interno razvijeno rješenje koje najviše podjeća na assembler te je razvoj
pravila spor i mukotrpan.
Na slici 9.1. prikazan je izvadak koda koji obrađuje samo jednu proceduru
kod obrade hrvatskih adresa. Cijela Pattern-Action datoteka ima više od dvije
tisuće 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 PatternAction Fileu u IBM QualityStage
Kad se kreiraju sve potrebne tablice i pravila, može započeti faza testiranja i
podešavanja pravila. Ova faza oduzima mnogo vremena. Izlazne vrijednosti
procesa standardizacije uspoređuju se s ulazima kako bi se pronašli oni koji
nisu definirani ili nisu na odgovarajući način obrađeni u Pattern-Action Fileu.
IBM QualityStage ima kao dio korisničkog sučelja ugrađenu i funkcionalnost
za testiranje pravila, koja unešeni slijed znakova obrađuje 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 stručnjaka 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,
poštanskim brojevima i svemu ostalom što je potrebno. Ako se usporedi
Informatica Data Quality s IBM QualityStageom, sadržaj referentne tablice u
Informatici pokriva sadržaj Dictionary File i Klasifikacijske tablice.
Referentne tablice korisnik sam kreira, sadržaj unosi direktno kroz web
sučelje ili uvozi iz datoteka korištenjem jednostavnog čarobnjaka. U
referentne tablice se osim navedenog sadržaja koji je vezan za korisnike i
adrese može unositi i drugi sadržaj koji omogućava poboljšanje kvalitete
podatak iz drugih domena, poput kodova i naziva proizvoda i slično.
Jednom kada su referentne tablice kreirane i popunjene, ostatak posla se
radi kroz Designer konzolu u kojoj se kreiraju preslikavanja koja ustvari
obrađuju podatke. Svako preslikavanje se sastoji od jednog ili više izvora
podataka, jedne ili više izlaznih tablica i datoteka te od transformacija koje
obrađuju podatke. Različite transformacije rade različite obrade podataka, od
označavanja, preko standardizacije i pretraživanja do uparivanja, uz
korištenje algoritama detaljno opisanih u poglavlju 6.
Unutar jednog preslikavanja može se napraviti kompletna obrada jednog ili
više setova podataka. Unutar preslikavanja na svakoj transformaciji je
moguće 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 može koristiti i za Hrvatsku.
Address Doctor je u stvari dodatna komponenta u kojoj se nalazi adresni
model većine svjetskih država, pa tako i Hrvatske. Za izradu tog modela
koriste se podaci o gradovima, naseljima i ulicama koje u Hrvatskoj održava i
ustupa za komercijalno korištenje Državna Geodetska Uprava. U Designeru
postoji zasebna AddressDoctor transformacija koja ulaznu adresu, bilo
prikazanu u standardnim redovima, bilo u slobodnoj formi, validira i
standardizira prema ugrađenom predlošcima adresnog modela. Na izlazu se
osim standardizirane adrese dobiva i kôd koliko Address Doctor neku adresu
smatra verificiranom i pouzdanom.
74 / 95
Slika 9.4.: Funkcionalnost predložaka 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
država,
koja
omogućava
brzo
pretraživanje,
standardizaciju i uparivanje podataka u stvarnom vremenu. Na žalost, za ovu
komponentu Hrvatska još nije podržana.
75 / 95
10.
Studija slučaja T-Mobile Hrvatska
10.1.
Okruženje projekta
T-Mobile Hrvatska jedan je od vodećih pružatelja usluga mobilne
komunikacije u Hrvatskoj. Orjentiranost na potrebe korisnika i kreiranje
usluga u skladu s njihovim željama rezultiralo je izvrsnim rezultatima te je
više od 2 milijuna korisnika prepoznalo kvalitetu i pouzdanost T-Mobilea.
Društvena odgovornost jedna je od najvažnijih stavki poslovanja T-Mobilea, a
kvalitetan odnos sa zajednicom u kojoj posluje tvrtka smatra osnovnim
preduvjetom za uspješno poslovanje. T-Mobile pažljivo njeguje i svoj imidž
ekološki osvještene kompanije, što potvrđuje i sustav upravljanja okolišem
prema međunarodnoj normi ISO 14002. T-Mobile svaki dio svog poslovanja
prilagođava najsuvremenijim europskim i svjetskim ekološkim normama.
Glavno mjerilo prema kojem T-Mobile vrednuje svoje rezultate jest
zadovoljstvo korisnika te najveći naglasak stavlja na kvalitetu svojih usluga te
daljnju izgradnju i modernizaciju mreže.
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 značajno povećati svoju sposobnost
prikupljanja i analize poslovnih podataka kako bi podržao ostvarenje dva
poslovna cilja:

Povećanje i zaštita prihoda

Povećanje operativne efikasnosti
76 / 95
Slijedom navedenog, započet je projekt implementacije skladišta podataka
čiji je sadržaj bio namjenjen prvenstveno rukovoditeljima i poslovnim
korisnicima za donošenje pravovremenih i kvalitetnih poslovnih odluka,
putem korištenja pravovremenih i pouzdanih informacija. Na podacima iz
skladišta podataka nadograđuje se snažna podrška za sustav poslovne
inteligencije.
Rezultat projekta bilo bi potpuno funkcionalno skladište podataka sa svim
potrebnim podacima definiranim na razini tvrtke, implementirano u fazama.
Projekt implementacije skladišta podataka nije uključivao uvođenje platforme
za analizu i izvještavanje. Uvođenje sučelja za analizu i izvještavanje
izvršeno je kroz drugi, paralelni projekt.
10.3.
Arhitektura rješenja
Arhitektura rješenja.prikazana je na slici 10.1:
Slika 10.1: Arhitektura T-Mobile DWH sustava
77 / 95
Pojedine komponente sustava su sljedeće:

Data Sources (Izvori podataka) ― izvori podataka su operacijski
sustavi T-Mobile-a Hrvatska iz kojih se podaci ekstrahiraju za potrebe
punjenja skladišta podataka.

Staging Area (privremeni spremnik) ― ovaj privemeni spremnik koristi
se tijekom transformacije i učitavanja podataka kako bi se poboljšale
performanse učitavanja te omogućilo kombiniranje podataka koji
potječu iz različitih sustava. Spremnik je instanca Oracle 10g baze
podataka.

Data Warehouse Data Store (skladište podataka) ― ovo je ključna
komponenta sustava koja služi kao spremnik u kojem su pohranjene
sve ključne poslovne informacije, obrađene i pripremljene za potrebe
izvještavanja i analize. Spremnik je instanca Oracle 10g Enterprise
Edition baze podataka s opcijom particioniranja.

Application Architecture ― ovaj dio arhitekture uključuje sustav za
razvoj procedura za ekstrakciju, transformaciju i učitavanje podataka u
skladište podataka i upravljanje tijekom procesa ažuriranja podataka u
skladištu
podataka,
arhiviranja
podataka
te
migracije
između
razvojnog, testnog i produkcijskog okruženja.

Metadata Management Architecture – arhitektura za upravljanje
metapodacima
(podacima
o
podacima)
omogućuje
upravljanje
poslovnim i tehničkim metapodacima, metapodacima vezanim za
dizajn procedura za ekstrakciju, transformaciju i učitavanje podataka u
skladište
korisničkih
podataka
izvještaja
te
metapodacima
i
analiza.
Ova
potrebnim
za
komponenta
kreiranje
osigurava
konzistentnost nazivlja i korištenosti pojedinih elemenata informacija
poput struktura, definicija ili kalkulacija kroz cijeli analitički sustav.

Data Quality Architecture – Moduli za osiguravanje kvalitete podataka
koriste se za profiliranje, standardizciju, uparivanje i čišćenje
78 / 95
postojećih podataka o klijentima i adresama iz postojećih operativnih
sustava.
10.4.
Ključni indikatori poslovanja i dimenzije
Dvije su osnovne komponente na kojima se temelji definicija funkcionalnosti
sustava – dimenzije i ključni indikatori poslovanja (engl. KPI – Key
Performance Indicators).
Indikatori su definirani kao pokazatelji vrijednosti mjera u kontekstu pojedinih
dimenzija, imaju numeričku vrijednost, usporedivi su s planskim vrijednostima
u vremenu te u kontekstu pojedinih dimenzija. Indikatori su bili grupirani u
grupe (obitelji) indikatora koji predstavljaju ključne grupe subjekata (logičkih
entiteta) u mobilnoj komunikaciji.
Dimenzije opisuju zahtjeve za grupiranje i filtriranje numeričkih podataka u
mjerema i vezanim ključnim pokazateljma poslovanja. Dimenzije su bile
grupirane u grupe (obitelji) dimenzija koje su pandan obiteljima indikatora.
Za potrebe projekta napravljena je matrica konteksta pojedinog ključnog
pokazatelja uspješnosti prema dimenzijama u kojem njegova analiza ima
smisla. Primjerice, analiza ostvarenog prometa ima kontekst u dimenziji
korisnika, dimenziji vremena i dimenziji korištenog 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 skladišta
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
slučaju 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 skladišta podataka.
Ukupna raspoloživost prostora za pohranu podataka je 5 TB, od kojih je
većina na raspolaganju za produkcijsku instancu skladišta podataka. Druge
tri instance Oracle baze podataka koje zauzimaju značajno manje diskovnog
prostora su razvojna i testna instanca skladišta podataka te zajednička
instanca privremenog spremnika.
Dimenzioniranje sustava napravljeno je na način da može sadržavati povijest
svih potrebnih poslovnih podataka što u detaljnom, što u agregiranom obliku.
Drugi bitan zahtjev kod dimenzioniranja sustava bio je da u previđenom
noćnom prozoru za učitavanje podataka bude moguće učitati sve potrebne
podatke iz operacijskih sustava.
10.6.
Softverska infrastruktura
Kao baza podataka za sve instance skladišta podataka i privremeni spremnik
korištena je Oracle 10g Enterprise Edition baza podataka. Kako je
implementacija projekta počela u rujnu 2004., ovo je bila prva implementacija
skladišta podataka na Oracle 10g bazi podataka u našoj regiji koja je
premašila 1 TB podataka.
Za aplikacijsku, metapodatkovnu i arhitekturu za kvalitetu podataka korišteni
su su proizvodi tvrtke Ascential – DataStage, MetaStage i QualityStage.
Tvrtku Ascential je u međuvremenu preuzeo IBM, koji je ove proizvode
nastavio podržavati unutar InfoSphere obitelji proizvoda.
80 / 95
Kao osnova za modeliranje skladišta podataka korišten je standardni
industrijski model skladišta podataka za mobilne operatere tvrtke ADRM.
Kako
je
navedeni
model
bio
razvijen
temeljem
poslovne
prakse
sjevernoameričkih operatera, zahtijevao je znatnu doradu za potrebe projekta
u T-Mobile-u Hrvatska. Kao front-end platforma za izvještavanje korišten je
Business Objects.
10.7.
Implementacijski tim
Tijekom implementacije na projektu je radilo više od dvadeset eksternih
stručnjaka, uz veliki interni angažman djelatnika T-Mobile-a Hrvatska, kako
informatičara, tako i poslovnih korisnika.
Uloge unutar projekta su uključivale voditelja projekta i menadžera osiguranja
kvalitete, koji su se brinuli za organizaciju projekta i kvalitetu isporuke tijekom
cijelog trajanja projekta.
Poslovni, podatkovni i sistemski analitičari su u suradnji s ključnim
korisnicima definirali funkcionalni dizajn sustava i kreirali funkcionalne
specifikacije.
Glavni arhitekt je na temelju funkcionalne specifikacije prilagođavao postojeći
industrijski model i kreirao detaljnu tehničku specifikaciju, koja je uključivala i
definiranje strategije za ažuriranje podataka u skladištu podataka.
Eksperti za razvoj procedura za ekstrakciju, transformaciju, učitavanje i
kvalitetu podataka su kreirali i testirali procedure za punjenje podataka u
skladište.
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 tečajeve, kroz praktične radionice i zajednički rad na razvoju procedura.
Testiranje je vršeno prvo unutar tehničkog projektnog tima kako bi se
osiguralo da sve procedure za učitavanje rade prema specifikaciji te da su
podaci u skladištu podataka točni i konzistentni. Na kraju svakog modula je
rađeno korisničko testiranje i prihvaćanje modula, nakon čega je počelo
produkcijsko korištenje.
Nositelj projekta je bio Siemens Hrvatska, čija je nadležnost bila vođenje
projekta, osiguranje kvalitete, integracija s izvornim sustavima i razvoj dijela
procedura za integraciju podataka. Implementirano je rješenje tvrtke
Poslovna inteligencija, koja je u projektu bila zadužena za analizu, dizajn
modela, razvoj procedura za poboljšanje kvalitete podataka i većeg 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 predviđenoj funkcionalnosti i
izvornim sustavima iz kojih je vršena ekstrakcija podataka.
Na Slici 10.2 prikazan je model T-Mobile DWH sustava koji je u svakoj
sljedećoj fazi projekta proširivan i nadograđivan novim funkcionalnostima.
Različitim bojama označena su različita subjektna područja koja su
međusobno više ili manje ovisna.
82 / 95
Slika 10.2.: Model T-Mobile DWH sustava
10.9.
Implementacija rješenja za poboljšanje kvalitete
podataka
Procedure za poboljšanje kvalitete podataka su u projektu implementacije
skladišta podataka korištene prvenstveno za poboljšanje kvalitete podataka o
korisnicima usluga T-Mobilea.
Kao prva i najzahtjevnija aktivnost odrađeno je kreiranje potrebnih pravila
detaljno opisanih u poglavlju 9.1, budući da je bila riječ o prvoj implementaciji
navedene platforme u Hrvatskoj [17].
U prvom koraku obrade su standardizirani adresni podaci za fizičke i
korporativne postpaid korisnike. Inicijalno je korišten adresni model nabavljen
od Državnog zavoda za statistiku (to je model koji se sada nabavlja od
Državne Geodetske Uprave). Prilikom integracije Hrvatskog Telekoma i TMobilea standardizacija je modificirana da koristi interni adresni model
Hrvatskog Telekoma.
U drugom koraku je napravljeno uparivanje novih korisnika s postojećim
korsnicima, kako bi se otkrili potencijalni duplikati. U tom koraku se kreira
83 / 95
tablica u kojoj se nalaze ID-evi potencijalnih duplikata te pripadajući
koeficijent sličnosti.
Nakon drugog koraka podatke preuzima platforma za integraciju podataka
pomoću koje se odvija dalje procesiranje.
10.10.
Sljedeći koraci
DWH sustav je u produkcijskom korištenju. U T-Mobileu se tim od pet
informatičara brine za održavanje i dalji razvoj sustava, a uz skladište
podataka isti tim održava i Business Objects reporting sustav.
S dobavljačem je potpisan Service Level Agreement (SLA) koji T-Mobileu
osigurava podršku za održavanje i razvoj sustava. Sljedeći koraci odnose se
uglavnom na poboljšanja i dorade postojećeg modela te kreiranje procedura
za učitavanje podataka iz novoimplementiranih operativnih sustava. Više
aktivnosti u sljedećem periodu može se očekivati u dijelu korištenja podataka
sukladno potrebama krajnjih korisnika.
Početkom 2011. godine sustav je migriran na aktualnu verziju 8.5, u kojoj su
funkcionalnosti DataStage i QualityStage platforme integrirane u jedno
funkcionalno okruženje.
10.11.
Rezultati uvođenja sustava
DWH sustav u T-Mobileu je integrirano, skalabilno, kompleksno i
centralizirano skladište podataka organizirano prema specifičnim zahtjevima
krajnjih korisnika. Sustav je namijenjen izvještavanju (samostalno, od strane
krajnjih korisnika), analizi podataka i podršci u donošenju odluka.
84 / 95
DWH sustav sadrži kompanijske podatke prikupljene iz cijelog niza
produkcijskih sustava. Podaci se, sukladno potrebama, čuvaju u detaljnom
i/ili u agregiranom obliku kroz duži vremenski period, kako bi se osiguralo
povijesno praćenje i izvještavanje. DWH sustav je optimiziran za operacije
nad velikom količinom podataka i zadovoljavajući odziv prema krajnjim
korisnicima, a bitno je naglasiti kako je kvaliteta podataka u DWH sustavu
unaprijeđena u odnosu na izvorišne sustave te da se kontinurano
poboljašava i unapređuje.
Krajnji rezultat je sustav korišten u cijeloj kompaniji, koji sadrži kvalitetne
podatke te koji služi kao podloga za donošenje poslovnih odluka.
85 / 95
11.
Zaključak
Kvaliteta podataka se u organizaciji mora razmatrati u najširem mogućem
kontekstu svih poslovnih sustava u okviru inicijativa za upravljanje podacima.
Skladište podataka je samo jedan od sustava u kojem se platforme za
kvalitetu podataka mogu koristiti.
Ako se gleda u širem kontekstu, kvaliteta podataka u skladištima podataka
se ne odnosi samo na kvalitetu samih podataka, nego i na kvalitetu definicije
podataka i kvalitetu prikaza podataka.
Niti jedna od vodećih platformi za poboljšanje kvalitete podataka nije u
procesu standardizacije i čišćenja spremna za rad s imenima, prezimenima i
adresama specifičnim za hrvatski jezik, odnosno nemaju ugrađenu
odgovarajuću aplikacijsku logiku i referentne podatke za Hrvatsku. Prije
korištenja tih platformi potrebno je kreirati pravila za hrvatska imena i adrese.
Za neke platforme, kreiranje pravila za platformu za poboljšanje kvalitete
podataka za hrvatski jezik nije lagan i tečan proces, zbog arhitekture
platformi koje nisu jednostavne za kreiranje ekstenzija.
Jedna od glavnih smetnji je nedostatak javno dostupnih izvora važećih
hrvatskih imena i adresa koji bi se mogli iskoristiti za kreiranje Klasifikacijskih
tablica. Drugi veliki problem je nejednoznačna veza između poštanskih ureda
i poštanskih brojeva, odnosno postojanje pojma naselja koji nije prisutan u
drugim europskim adresnim modelima, koja dodatno posložava kreiranje
pravila.
Faza podešavanja pravila nakon početnog kreiranja zahtjeva najviše
vremena. Kada se jednom kreiraju, pravila zahtijevaju neprestano održavanje
i nadograđivanje.
U zadnjih nekoliko godina pojavile su se tehnologije i nove verzije platformi s
kojima se radi potpuno u vizualnom okruženju. Proces razvoja i
implementacije rješenja je znatno brži, a moguće je koristiti funkcionalnosti
86 / 95
za poboljšanje kvalitete podataka u realnom vremenu za potrebe
implementacije rješenja za upravljanje matičnim podacima.
Stupanj prihvaćenosti rješenja za poboljšanje kvalitete podataka na tržištu je
još uvijek prilično 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 uopće
postoje. Treći razlog je visoka cijena postojećih platformi.
U budućnosti se može očekivati 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]
Dražen Oreščanin: „Implementacija skladišta 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]
Dražen Oreščanin, Krešimir Š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]
Dražen Oreščanin, Lidija Ivaštinović: „Localization of Data Quality
Rules for Croatian language“, 2006, Zbornik radova MIPRO
konferencije
89 / 95
Osiguranje kvalitete podataka u skladištima podataka
Sažetak:
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 netočni. U
projektima implementacije skladišta podataka i sustava poslovne inteligencije
vrlo velika pažnja posvećuje se kvaliteti podataka te su razvijene politike
osiguranja kvalitete podataka, platforme i algoritmi za čišćenje, konsolidaciju i
ispravljanje netočnih podataka. Platforme za poboljšanje kvalitete podataka
vjerojatno čine najmanje istraženu i korištenu grupu analitičkog softvera u
Hrvatskoj. Hrvatsko tržište nije dovoljno veliko da bude zanimljivo globalnim
dobavljačima da ulažu u razvoj lokaliziranih pravila za svoje platforme. Niti
jedna od vodećih platformi za poboljšanje kvalitete podataka nije u procesu
standardizacije i čišćenja spremna za rad s imenima, prezimenima i
adresama
specifičnim
za
hrvatski
jezik,
odnosno
nema
ugrađenu
odgovarajuću aplikacijsku logiku i referentne podatke za Hrvatsku. Prije
korištenja 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 poboljšanje
kvalitete
podataka
za
dvije
vodeće
platforme
te
praktični
primjer
implementacije na projektu u velikoj hrvatskoj tvrtki.
Ključne riječi:
Kvaliteta podataka, skladišta 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
Dražen Oreščanin - Životopis
Dražen Oreščanin je rođen u Zagrebu 1968. godine. Nakon osnovne škole,
završava Matematičko-Informatički Obrazovni centar V. Popović (MIOC,
današnja XV gimnazija) 1986. godine s odličnim uspjehom. Diplomirao je na
Sveučilištu u Zagrebu na Fakultetu elektrotehnike i računarstva na smjeru
Radiokomunikacije i profesionalna elektronika u veljači 1992. godine s
odličnim uspjehom, s temom „Zvučnik kao opterećenje pojačala“. Nakon
diplomiranja se 1992. zapošljava u Zagrebačkoj banci.
Svoja prva iskustva u području sustava za skladišta podataka i poslovne
inteligencije stječe u Zagrebačkoj banci gdje je sudjelovao na brojnim
projektima razvoja aplikacija za ocjenu kreditnog rizika i upravljanja rizikom te
na projektu razvoja sustava za izvještavanje od 1994. do 1998. godine na
poziciji stručnog suradnika i voditelja službe. 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 osnivača tvrtke Poslovna Inteligencija gdje radi od 2001. na
pozicijama Direktora strategije i razvoja i Predsjednika Uprave. Odgovoran je
za razvoj novih tržišta te uvođenje novih tehnologija i metodologija. Ekspert
je za područje telekomunikacija te sudjeluje na najsloženijim projektima
podatkovne integracije u ulozi voditelja projekta i dizajnera rješenja, poput
projekata
u T-Mobile Hrvatska, Dukatu, Tisku, a u regiji u Crnogorskom
Telekomu i Telenoru Srbija.
1993. godine upisuje jednosemestralni stručni studij Poslovnog upravljana za
inženjere (Diploma Study in Management) na Fakultetu elektrotehnike i
računarstva, koji završava 1994. godine.
Napisao je i objavio više znanstvenih radova. Objavljuje i tekstove u stručnim
časopisima, ponajviše u računalnom magazinu Mreža, gdje je i stalni vanjski
suradnik. Tekstove objavljuje i u drugim stručnim časopisima poput
92 / 95
InfoTrenda, Lidera i Banke. Kourednik je prvog hrvatskog nezavisnog web
centra
za
skladištenje
podataka
i
poslovnu
inteligenciju
www.skladistenje.com.
Redovni je sudionik i predavač na stručnim 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 stručne 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 održao više predavanja unutar kolegija
„Izgradnja informacijskih sustava“ za polaznike EUCIP programa u
organizaciji Algebre te kao predavač na stručnom seminaru „Sustavi za
podršku poslovnom odlučivanju“ u organizaciji Algebre.
U školskoj godine 2011/2012 izabran je u zvanje predavača te nositelj
kolegija „Skladišta podataka i poslovna inteligencija“ na Visokoj školi za
primjenjeno računarstvo u Zagrebu.
93 / 95
Dražen Oreščanin - Curriculum Vitae
Oreščanin 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 Zagrebačka banka.
His first experience in the field of systems for data warehousing and business
intelligence was in Zagrebačka 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 Mreža 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 Dražen 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

VODITELJ SKLADIŠTA (m/ž) - Kraš trgovina doo Široki Brijeg

DEJA M - Program za vođenje skladišta mob. 091/508 4220

605_Srzentić, Arbanas referat DW modeli.pdf

Moderna logistika – uvod u automatizaciju skladišta

File

TOP LISTA NAJČITANIJIH NASLOVA ZA LISTOPAD 2012

Preuzmite pdf - Gradska knjižnica Marka Marulića

Analitika Web mjesta

Diplomski rad Alena Stojanovića

Preuzmite pdf - Gradska knjižnica Marka Marulića