Kvaliteta podataka – dio drugi

Skladištenje podataka

Kvaliteta podataka – dio drugi

U prvom dijelu ove kolumne pokušali smo prikazati osnove strukture relacijskih baza podataka, koje omogućavaju održavanje referencijalnog integriteta i garantiraju određeni nivo kvalitete podataka u transakcijskim sustavima. O uvom, drugom nastavku, pokušati ćemo se pozabaviti ptanjima poput:

  • Zašto podaci u transakcijskom sustavu nisu kvalitetni?
  • Što i kako možemo napraviti da podignemo kvalitetu podataka?
  • Koje postupke i alate možemo za to koristiti?

Na kraju prvog nastavka vidjeli smo da sama ograničenja strukture i ponašanja ne mogu osigurati kvalitetu podataka – ograničenja mogu samo pomoći u nekim aspektima:

  • mogu pomoći da podaci budu potpuni(ji) ako se ne dozvoli unošenje null-vrijednosti pojedinog atributa, primjerice imena, prezimena i adrese klijenta. Naravno, ako osoba koja u transakcijsku aplikaciju unosi podatke o novom klijentu nema podatke o adresi klijenta, a polje s adresom ne smije ostati prazno, nju ništa ne priječi da u polje adrese unese nešto besmisleno poput ‘XXXXX’, nešto beskorisno poput ‘Nepoznata’, nešto netočno poput ‘Trg Bana Kelačića 3’ ili nešto nepostojeće poput ‘Ilica 5280’. U svakom slučaju, vrlo je bitan ljudski faktor kod unosa
  • mogu pomoći da podaci koji moraju poprimiti diskretnu, predodređenu vrijednost (spol, stručna sprema, poštanski broj…) poprime jednu od vrijednosti koja je definirana u pripadajućem šifarniku. Naravno, ukoliko se šifarnici redovito ne održavaju, neće biti osigurana kvaliteta podataka ni u ovom slučaju. Najveći problem, kojim ćemo se zasebno pozabaviti, je postojanje više slogova u šifarniku koje opisuju jedan subjekt (klijenta u banci, artikl u maloprodaji…) ili jednostavno rečeno duplikata

Kako doskočiti ovim problemima?

Kod projektiranja transakcijske aplikacije mora se naći balans između brzine rada i osiguravanja kvalitete podataka. Naime, svaka provjera integriteta, bilo da se dešava direktno prilikom unosa podataka na ekranu ili kod zapisivanja podataka u bazu podataka, uzrokuje komunikaciju između klijenta i servera i povećanje korištenja resursa računala, te samim time usporava rad aplikacije. Drugim riječima, moglo bi se reći da je garantirana razina kvalitete transakcijskih podataka obrnuto razmjerna brzini rada OLTP sustava. Kako većina transakcijskih sustava mora raditi brzo, budući da im je to svrha postojanja, vrlo često pati kvaliteta podataka. Iskreno rečeno, vrlo često se dešava da transakcijske aplikacije ne zadovoljavju niti jedan od ta dva uvjeta. Da li vam se ikada desilo da u redu u nekoj banci čujete od blagajnice da ‘nemaju onlajna’ ili da blagajnica nervozno lupa po tastaturi i zvjera naokolo žaleći se da je ‘sustav danas jako spor’? Da li vam se desilo da negdje na autorizaciju kreditne kartice čekate nekoliko minuta, pa prodavač na kraju mora telefonom zvati i pitati centar za autorizaciju? Da li vam se desilo u tvrtki u kojoj radite da u računovodstvu postoje hrpe dokumenata koje čekaju na unos, a gospođe koje rade na unosu govore kako ‘pritisnu tab, pa treba trideset sekundi da kursor skoči u slijedeće polje…’ Ako vam se sve ovo nije nebrojeno puta desilo, možete slobodno prestati čitati – vi živite u nekom sretnijem svijetu…

Ljudski faktor

Već jednom spomenuti ljudski faktor izuzetno je važan. Veliki ERP sustavi poput SAP-a, Baana ili PeopleSofta ne postavljaju mnogo ograničenja kod unosa, budući da je u zapadnom svijetu normalno da osoba koja radi na unosu svoj posao radi maksimalno odgovorno. Na žalost, to u Hrvatskoj često nije slučaj, iako zvuči pomalo paradoksalno da u doba velike nezaposlenosti dobar dio ljudi koji imaju posao, taj posao rade s minimalnom koncentracijom i pažnjom, što je posljedica loše motiviranosti za rad.

Postoji priča o jednoj hrvatskoj banci u kojoj su odlučili u izvještajnom sustavu napraviti analizu žiro-računa pravnih osoba po sektorizaciji – banke, javna poduzeća, privatna poduzeća, obrtnici, udruge… Rezultati su pokazali da među klijentima ima neobično mnogo banaka, te da se sve banke nalaze u istoj podružnici. Razlog tome je bila činjenica da je kod provjeravanja ograničenja integriteta uvijek prvi izbor bila šifra ’01’, koja, pogađate, označava banke. Osoba koja je podatke unosila, kada je kod unosa kursor došao na polje sektora, prvim pritiskom na Enter je otvorila pomoćni ekran sa mogućim šiframa, a drugim pritiskom na Enter odabrala prvu po redu. I tako su se zubarske ordinacije i građevinski poduzetnici vodili kao banke… Na pitanje zašto nisu unijeli ispravnu vrijednost, odgovor je glasio otprilike ‘Pa mi u podružnici znamo sve svoje klijente, s njima kontaktiramo svakodnevno, pa naravno da mi znamo da oni nisu banke!’, a spoznaja da te podatke još netko osim njih koristi i gleda nije im bila ni u peti…

To vodi do jednog često zanemarivanog aspekta Business Intelligence sustava – oni zaista mogu omogućiti povratnu vezu i pogled na sve besmislice i pogreške unešene u transakcijski sustav. Nakon toga, pogreške se mogu ispraviti na mjestu kojem su nastale, te podaci ponovo učitati u skladište podataka i ponovo kreirati OLAP strukture i izvještaje s ispravnim podacima. Prema mojem iskustvu, to se pokazuje jednom od najvećih prednosti i poslovnih dobitaka od OLAP sustava u našem okruženju – mogućnost približavanja istinitim podacima…

Dakako, idealno rješenje bi bilo da zaista ljudski faktor odradi svoje od prve kako treba, ali motivacija je uostalom i jedan od velikih problema Hrvatske u cjelini, a ne samo implementacije informacijskih sustava.

Duplići

Drugi veliki problem koji se često pojavljuje su dupli slogovi, primjerice kad se u maloprodaji može pronaći isti proizvod pod dvije ili više različitih šifri, ili kad se u banci jedan klijent vodi pod više različitih šifri.

Jedan mogući uzrok takve pogreške je neintegriranost poslovnih aplikacija koje nemaju zajedničke šifarnike. Primjerice, klijent u podružnici neke banke u Osijeku otvori devizni račun. Nakon nekog vremena u podružnici banke u Rijeci podigne kredit. Ukoliko se devizna i kreditna aplikacija ne vežu na centralni ili replicirani registar klijenata, taj klijent će biti unešen dvaput i biti će tretiran kao dva različita klijenta, što je vrlo pogrešno. Iako postoji jedinstveni matični broj građana, transakcijski sustavi najčešće taj broj ne koriste kao jedinstveni identifikator klijenata, već se koristi zasebni identifikator unutar aplikacije.

Drugi uzrok dupliciranja slogova su spajanja kompanija pri kojima se i baze podataka spajaju. Ako veliki trgovački lanac koji ima u asortimanu 50.000 artikala kupi manji trgovački lanac, preuzeti će sve trgovine i svu robu na skladištima, na kojima ima recimo 20.000 različitih artikala. Bilo bi suludo sve artikle ponovno unositi u bazu, te se baze jednostavno spoje. Neki artikli su za obe tvrtke isti, a neki su različiti. Oni koji su isti u obje tvrtke, pojavljuju se kao dvostruki, te ako postoje odvojeni sustavi naručivanja, artikli se mogu godinama voditi kao dvostruki.

U boj, u boj…

Naravno, postoje i načini borbe protiv takvih nekonzistentnosti, koje možemo grupirati u tri osnovne grupe. Prva grupa je korištenje povratne veze iz analitičkog sustava za ispravljanje nelogičnosti u transakcijskom sustavu, koji smo već spomenuli.

Drugi način je implementacija integriranog transakcijskog poslovnog sustva i proceduralno reguliranje centralizaranog održavanja svih šifarnika i registara klijenata. To može biti jako skupo, pogotovo u većim tvrtkama, ali sustavi poput SAP-a i pored visoke cijene implementacije vrlo brzo isplaćuju uloženo.

Treći način je korištenje sofisticiranih Data Quality alata koji automatski mogu čistiti i ribati transakcijske podatke, te eliminirati dulikate (engl. cleansing, scrubbing i deduplicating), među koje spadaju proizvodi tvrtki poput FirstLogic i DataFlux. Takve platforme koriste dva međusobno povezana algoritma na koima se baziraju. Prvi je definiran rječnikom sinonima koji se koristi za konverziju prilikom procesa učitavanja i transformacije. Dobar primjer je da se ‘Ulica’,’ulica’, ‘ul.’ i ‘Ul.’ mogu svesti pod ‘Ulica’, budući da je značenje jednoznačno. Loš primjer je ‘D.’, budući da u ‘D. Štefanki’ znači ‘Desni’, a u ‘D.Dragonožec’ znači ‘Donji’, budući da značenje nije jednoznačno. Uz rječnike su definirani i algoritmi sličnosti koji mogu ispravljati pogreške pri upisu. Ako postoji popis svih mogućih imena koja su ispravna, pojavljivanje klijenta koji ima ime koje se ne nalazi u popisu, primjerice ‘Stjelan’ će uzrokovati da algoritam nađe najsličnije ime i automatski ga ispravi u ‘Stjepan’. Kombinacijom ta dva postupka mogu se podaci konsolidirati i integrirati, te identificirati i eliminirati dupli slogovi. Mana ovakvih platformi je da do sada nisam čuo ni za jednu koja ima ugrađeni rječnik hrvatskog jezika, te algoritme sličnosti koji podržavaju hrvatske dijakritike. Budući da smo malo tržište za koje čak ni WIndowsi nisu lokalizirani, nije ni čudo da tako nešto ne postoji…

A što dalje?

U prve dvije kolumne pozabavili smo se uglavnom infrastrukturnim pitanjima i pogrešnim podacima koji potječu iz transakcijskih sustava. U zadnjem dijelu ćemo se orjentirati na preostala pitanja na koja još nismo odgovorili – pogreškama koje nastaju prilikom integracije, osiguravanjem da podaci u skladištu podataka ostanu kvalitetni, te problemom kvalitete informacija… (D.O.)