Kvaliteta podataka – dio prvi

Skladištenje podataka

Kvaliteta podataka – dio prvi

U zadnjih godinu i pol dana napisali smo zaista gomilu kolumni koje se bave raznim aspektima DW, BI, DM i CRM sustava i metodologija, a jedan izuzetno važan aspekt koji do sada nismo obrađivali je kvaliteta podataka i informacija. Kvaliteta, potpunost, ispravnost i istinitost ulaznih podataka je ključna u svim sustavima koji se temelje na skladištima podataka, budući da se sam smisao sustava gubi ukoliko nije u mogućnosti davati ispravne i istinite informacije korisnicima, ili kako se to lijepo kaže ‘garbage in – garbage out…’

Ova tema nije nimalo trivijalna i namijenjena je ponajviše tehničkom osoblju (ili kako mi to lijepo kažemo inormatičarima), tako da je za potpuno razumijevanje daljnjeg teksta potrebno određeno tehničko predznanje i poznavanje strukture informacijskih sustava.

Pokušati ćemo ovo razmatranje o kvaliteti podataka podijeliti u tri dijela, koji će svaki predstavljati zasebnu kolumnu u razmaku od nekoliko tjedana. U prvom dijelu, koji će biti obrađen u ovoj kolumni, pokušati ćemo odgovoriti na pitanja poput:

  • Što kvaliteta podataka ustvari jest?
  • Koje su teoretske osnove cijelog procesa i što je integritet podataka?
  • Koje vrste anomalija u podacima postoje?

a u preostala dva ćemo pokušati odgovoriti na pitanja:

  • Zašto podaci u transakcijskom sustavu nisu kvalitetni?
  • Što i kako možemo napraviti da podignemo kvalitetu podataka?
  • Koje alate možemo za to koristiti?
  • Kako osigurati da podaci u skladištu podataka ostanu kvalitetni?
  • Što je kvaliteta informacija?

Malo više teorije…

Većina podataka u skladište podataka dolazi automatiziranim procedurama za učitavanje iz neke vrste transakcijskog (OLTP) sustava, koji se u većini slučajeva bazira na nekom relacijskom sustavu za upravljanje bazama podataka. Prilikom učitavanja podataka iz raznih sustava vrši se integracija – proces koji osigurava da podaci koji dolaze iz različitih sustava u različitim formatima u skladištu budu jednoznačni – najbolji primjer za to je vrijeme odnosno format datuma, koji je u raznim OLTP sustavima različit, te se prilikom učitavanja u skladište vrše tranformacije. Pogreške u podacima u skladištu podataka mogu se podijeliti u tri osnovne grupe – pogreške u izvornim podacima, pogreške integracije prilikom učitavanja u skladište podataka i pogreške koje nastaju kao posljedica inkonzistentnosti podataka tijekom vremena. U prvom dijelu ćemo se pozabaviti izvornim podacima, relacijskim DBMS sustavima, transakcijskim aplikacijama i pogreškama koje se u njima mogu dogoditi.

Sam RDBMS sustav se brine za transakcijski integritet baze podataka, što bi trebalo osigurati, zajedno s kvalitetno napisanom transakcijskom aplikacijom, da podaci budu potpuni i ispravni. To se osigurava primjenom pravila integriteta, koja možemo podijeliti u dvije osnovne grupe – strukturna ograničenja integriteta i ograničenja ponašanja.

Ograničenja strukture

Ograničenja strukture podrazumijevaju nekoliko različitih vrsta integriteta od kojih su nabitniji entitetski, referencijalni i domenski. Smisao svakog od njih objasniti ćemo na kratkom primjeru iz bankovnog poslovanja.

Entitetski integritet znači da primarni ključ neke tablice (relacije) mora biti jednoznačan i ne smije biti null-vrijednost, te se još naziva i pravilo jedinstvenosti primarnog ključa. U primjeru banke mogli bismo uzeti registar klijenata. Svaki klijent mora imati jednoznačan identifikacijski ključ na koji se onda vežu svi podaci o njegovim računima i transakcijama po tim računima. Da taj uvjet kojim slučajem nije ispunjen i da postoje tri različita klijenta s istim ključem, ne postoji način na koji bi aplikacija sa sigurnošću mogla utvrditi koji račun, a kao posljedicu toga i prometi po tim računima, pripada kojem klijenu. Drugi problem koji se može pojaviti je da se jedan klijent vodi ne pod jednim, nego pod dva ili više identifikacijskih ključeva, ali to je pogreška koja nema nikakve veze s teorijom, već je posljedica isključivo pograšaka pri unosu (ili konsolidaciji prilikom spajanja) i kao takva biti će razmatrana kasnije.

Domenski integritet zahtijeva da vrijednost pojedinog atributa mora biti jednaka nekoj od vrijednosti iz skupa definiranih vrijednosti (domene), a također određuje i vrijednosti i operacije nad tim vrijednostima koje su definirane samim tipom podataka. U našem primjeru možemo uzeti isti registar klijentata i vrijednost atributa Šifre djelatnosti, koju svaka pravna osoba dobija prilikom registracije. Vrijednosti šifre djelatnosti određene su prema Nacionalnoj klasifikaciji djelatnosti i ne mogu poprimiti druge vrijednosti osim definiranih. Također, ako je šifra djelatnosti definirana kao cjelobrojna varijabla, neće biti moguće unošenje alfanumeričkih ili decimalnih vrijednosti. Važno je primijetiti da ako šifra djelatnosti nije ključni atribut, onda može i poprimiti null-vrijednost, što je također i jedno od ograničenja strukture – može se definirati da atribut ne smije poprimiti null-vrijednost (npr. naziv klijenta ne smije biti null-vrijednost, što ne znači da će zapisana vrijednost biti smislena, ali znači da će nešto biti zapisano).

Prethodno spomenuti problem može se riješiti upotrebom pravila referencijalnog integriteta, odnosno upotrebom veze primarnog ključa i stranog ključa, koji kaže da strani ključ u nekoj tablici može poprimiti samo vrijednosti primarnog ključa u nekoj drugoj tablici. U našem primjeru to bi značilo da nećemo imati domenu vrijednosti za šifru djelatnosti, već ćemo imati zasebnu tablicu u bazi podataka u kojoj će biti sve dozvoljene vrijednosti za šifru djelatnosti (s pripadajućim opisima po mogućnosti) gdje će šifra djelatnosti biti primarni ključ, dok će u registru klijenata šifra djelatnosti biti definirana kao strani ključ.

Ograničenja ponašanja

Ograničenja ponašanja podrazumijevaju različite tipove ovisnosti između pojedinih atributa, a za ispravno kreiranje transakcijskog sustava najvažnije su funkcijske ovisnosti. Ulaženje u teoriju funkcijskih ovisnosti moglo bi nas poprilično udaljiti od teme, pa ćemo samo zaključiti da se na poštivanju uvjeta zadanih aksiomima funkcijskih ovisnosti baziraju definicije normalnih formi i postupci normalizacije relacijske sheme.

U praksi je uobičajeno svoditi relacijsku shemu na tzv. treću normalnu formu, koja osigurava da ne postoji neželjena redundancija podataka u bazi podataka, odnosno da jedan podatak nije istovremeno bespotrebno zapisan na više različitih mjesta. Na taj način se osigurava da se, uz korištenje pravila referencijalnog integriteta, eliminiraju anomalije održavanja, koje podrazumijevaju potencijalnu inkonzistenciju, te anomalije dodavanja i brisanja.

U našem primjeru registra klijenata možemo zamisliti da registar ima atribute za šifru djelatnosti i opis djelatnosti. Svaki put kad unesemo novog klijenta, unosimo i šifru i opis djelatnosti. Šifra djelatnosti je određena pravilom domenskog integriteta i može poprimiti određene vrijednosti, dok je opis djelatnosti alfanumerička varijabla koja ne može poprimiti null-vrijednost i korisnik u nju može upisati opis na različite načine koji su svi valjani:

Tablica REGISTAR

SIF_KLIJ
NAZ_KLIJ
SIF_DJEL
OPIS_DJEL
0001
IBM
72
Računalne i srodne djelatnosti
0002
Mikrosoft
72
Računalne djelatnosti
0003
HP
72
Rać. djel.
0004
Compaqt
72
XXX

Postojeće stanje predstavlja stanje u kojem imamo izraženu nepotrebnu redundanciju i anomaliju inkonzistencije, a kod svakog novog unosa pojavila bi se anomalija dodavanja i dodatna inkonzistencija. Umjesto postojeće tablice, ispravno projektirani sustav sadržavao bi dvije tablice koje bi zadovoljavale uvjete treće normalne forme, a bile bi povezane vezom primarnog i stranog ključa preko atributa SIF_DJEL. Na ovaj način izbjegava se nepotrebna redundancija, spriječava se pojava anomalija, olakšava se održavanje i osigurava viši nivo kvalitete transakcijskih podataka:

Tablica REGISTAR

SIF_KLIJ
NAZ_KLIJ
SIF_DJEL
0001
IBM
72
0002
Mikrosoft
72
0003
HP
72
0004
Compaqt
72

Tablica DJELATNOSTI

SIF_DJEL
OPIS_DJEL
72
Računalne i srodne djelatnosti

A što dalje?

Sim RDBMS i normalizirana baza podataka transakcijskog sustava osiguravaju određeni nivo kvalitete podataka, ali ne mogu garantirati niti približno sve (prisjetimo se primjera klijenta koji ima više različitih identifikacijskih ključeva). Drugim riječima, ispravno projektirana baza podataka na kojoj se temelji transakcijska aplikacija, koja osigurava integritet podataka i elimira pojavu anomalija, tek je prvi korak prema kvalitetnim podacima. Primjerice, ako alfanumerički atribut NAZ_KLIJ ima ograničenje da ne smije sadržavati null-vrijednosti, nema nikakve garancije da će podatak koji je upisan biti smislen – što znači da se pogreške u unosu koje su se desile u gornjem primjeru (ovaj put su to svjesno napravljene pogreške) dešavaju i u stvarnom životu. S tim problemom i mnogim drugima ćemo se pozabaviti u slijedećem nastavku… (D.O.)