1 / 95

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.

2 / 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.: ___________

3 / 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

4 / 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

3. Definicije i pojašnjenja bitnih pojmova ....................................... 23

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

5 / 95

7. Proces poboljšanja kvalitete podataka ...................................... 55

7.1. Analiza i profiliranje ................................................................... 55

7.2. Standardizacija i korekcija ......................................................... 57

7.3. Dopunjavanje ............................................................................ 58

7.4. Uparivanje ................................................................................. 58

7.5. Preživljavanje ............................................................................ 60

8. Dobavljači i platforme za poboljšanje kvalitete podataka .......... 61

8.1. IBM QualityStage ...................................................................... 62

8.2. Informatica Data Quality ............................................................ 63

8.3. Oracle Warehouse Builder i Oracle Data Integrator .................. 64

8.4. Microsoft SQL Server Integration Services ............................... 65

9. Proces lokalizacije i izrade pravila za Hrvatsku ......................... 67

9.1. IBM QualityStage ...................................................................... 67

9.2. Informatica Data Quality ............................................................ 73

10. Studija 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

6 / 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

7 / 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.

8 / 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

9 / 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.

10 / 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.

11 / 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.

12 / 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-

13 / 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

14 / 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.

15 / 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.

16 / 95

Tip integracije Opis funkcionalnosti

Prikupljanje podataka za

analitičke sustave

Ekstrakcija podataka iz operativnih sustava,

transformiranje i uparivanje te zapisivanje u analitičke

sustava.

Kreiranje integriranih

repozitorija matičnih

podataka

Omogućavanje konsolidacije, sinkronizacije i

racionalizacije podataka koji opisuju ključne poslovne

subjekte poput kupaca, proizvoda i zaposlenika.

Migracije i konverzije

podataka

Mogućnosti transformacije i pripreme podataka kod

migracija s legacy sustava na ERP sustave te

konsolidacija višestrukih ERP sustava kod akvizicija.

Sinkronizacija podataka

među operativnim

aplikacijama

Omogućavanje konzistentnosti na nivou baza podataka,

u jednom ili dva smjera, unutar tvrtke ili prema okruženju

Kreiranje federiranih

pogleda nad podacima

iz različitih repozitorija

podataka

Ova funkcionalnost se često naziva Enterprise

Information Integration (EII) te omogućava integrirani

pogled na informacije u realnom vremenu, bez potrebe

da se podaci fizički “spreme” u jedan zajednički

repozitorij. Ova funkcionalnost je sve bitnija za Data

Integration platforme.

Integracija podataka u

servisno orijentiranoj

arhitekturi (SOA)

Ovdje je više riječ o arhtekturalnom svojstvu, nego o

funkcionalnosti. Moderne platforme za integarciju

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

17 / 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.

18 / 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.

19 / 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

20 / 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

21 / 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.

22 / 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.

23 / 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

24 / 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

25 / 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.

26 / 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.

27 / 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.

28 / 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

29 / 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. primary-

foreign key constraint). Kod takvog modeliranja se obavezno koriste Data

Martovi kao još krajnji nivo pripreme podataka za krajnje korisnike. Data Mart

u tom 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

30 / 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.

31 / 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.

32 / 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.

33 / 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.

34 / 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.

35 / 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.

3.9. Upravljanje matičnim podacima

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.

36 / 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.

37 / 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.

38 / 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.

39 / 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

40 / 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.

41 / 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.

42 / 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

43 / 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

44 / 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.

45 / 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

46 / 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

47 / 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

48 / 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.

49 / 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

50 / 95

for i from 1 to m

for j from 1 to n

if s[i] = t[j] then cost := 0

else cost := 1

d[i, j] := minimum(

d[i-1, j] + 1, //

deletion

d[i, j-1] + 1, //

insertion

d[i-1, j-1] + cost //

substitution

)

return d[m, n]

6.4. Hamming Distance algoritam

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

godine u radu koji se bavio 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.

51 / 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

52 / 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.

53 / 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]

54 / 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.

55 / 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

56 / 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.

Broj pojavljivanja Riječ

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

57 / 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:

58 / 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

59 / 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

60 / 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

61 / 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 SAD-

u, 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.

62 / 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.

63 / 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.

64 / 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.

65 / 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 SQL Server Integration Services

Microsoft 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.

66 / 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.

67 / 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.

68 / 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.

69 / 95

Da bi se dovršila lokalizacija pravila za hrvatski jezik, potrebno je kreirati tri

od pet opisanih komponenti: Klasifikacijsku tabelu, Lookup tablice i Pattern-

Action file. Dictionary File koji definira strukturu je uglavnom isti kao i za

skupove pravila za druge jezike. Override tablice se kreiraju u 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

70 / 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.

71 / 95

;--------------------------------------------------------

-----

; Floors_and_Units SUBROUTINE Starts Here

;--------------------------------------------------------

-----

\SUB Floors_and_Units

; Floor and Unit Patterns

;

*F | ^ | $ | [ {FT} = "" & {FV} = "" ]

COPY_A [1] {FT}

COPY [2] {FV}

RETYPE [2] 0

RETURN

*U | ^ | $ | [ {UT} = "" & {UV} = "" ]

COPY_A [1] {UT}

COPY [2] {UV}

RETYPE [1] 0

RETYPE [2] 0

RETURN

\END_SUB

Slika 9.1.: Primjer procedure za obradu katova kao dijela adrese u Pattern-

Action Fileu u IBM QualityStage

Kad se kreiraju sve potrebne tablice i pravila, 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.

72 / 95

Slika 9.2.: Funkcionalnost testiranja pravila u IBM QualityStage platformi

73 / 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.

74 / 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.

75 / 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.

76 / 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

77 / 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

78 / 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 podataka te metapodacima potrebnim za kreiranje

korisničkih izvještaja i analiza. Ova komponenta 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

79 / 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

80 / 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.

81 / 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.

82 / 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.

83 / 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 T-

Mobilea 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

84 / 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.

85 / 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.

86 / 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

87 / 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.

88 / 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

89 / 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

90 / 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

91 / 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

92 / 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

93 / 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.

94 / 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

95 / 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.