Kakovost podatkov v skladišču je pomemben predpogoj za pridobivanje dragocenih informacij. Slaba kakovost dolgoročno vodi v negativno verižno reakcijo.
Prvič, izgubljeno je zaupanje v posredovane informacije. Ljudje začenjajo manj uporabljati aplikacije poslovne inteligence; potencial aplikacij ostaja neizkoriščen.
Posledično je pod vprašajem nadaljnje vlaganje v analitični projekt.
Odgovornost za kakovost podatkov
Vidik, povezan z izboljšanjem kakovosti podatkov, je pri BI projektih mega pomemben. Ni pa privilegij samo tehničnih strokovnjakov.
Na kakovost podatkov vplivajo tudi vidiki, kot so
Kultura podjetja
- So delavci sami zainteresirani za kakovostno proizvodnjo?
- Če ne, zakaj ne? Lahko pride do konflikta interesov.
- Morda obstajajo pravila podjetja, ki določajo, kdo je odgovoren za kakovost?
Procesi
- Kateri podatki nastanejo na koncu teh verig?
- Morda so operacijski sistemi konfigurirani tako, da se morate "zasukati", da bi odražali to ali ono situacijo v resnici.
- Ali operacijski sistemi sami izvajajo preverjanje in usklajevanje podatkov?
Vsi v organizaciji so odgovorni za kakovost podatkov v sistemih poročanja.
Opredelitev in pomen
Kakovost je dokazano izpolnjevanje pričakovanj strank.
Toda kakovost podatkov ne vsebuje definicije. Vedno odraža kontekst uporabe. Skladišče podatkov in sistem BI služita drugačnim namenom kot operacijski sistem, iz katerega prihajajo podatki.
Na primer, v operacijskem sistemu je atribut stranke lahko izbirno polje. V repozitoriju se ta atribut lahko uporablja kot dimenzija in ga je treba izpolniti. Kar pa uvaja potrebo po izpolnjevanju privzetih vrednosti.
Zahteve glede shranjevanja podatkov se nenehno spreminjajo in so običajno višje kot pri operacijskih sistemih. Lahko pa je tudi obratno, ko v shrambo ni treba shranjevati podrobnih informacij iz operacijskega sistema.
Da bo kakovost podatkov merljiva, je treba opisati njene standarde. V proces opisa morajo biti vključeni ljudje, ki za svoje delo uporabljajo informacije in številke. Rezultat te vpletenosti je lahko pravilo, po katerem lahko na prvi pogled v tabelo ugotovimo, ali je napaka ali ne. To pravilo mora biti oblikovano kot skript/koda za naknadno preverjanje.
Izboljšanje kakovosti podatkov
Nemogoče je počistiti in popraviti vse hipotetične napake med postopkom nalaganja podatkov v skladišče. Dobro kakovost podatkov je mogoče doseči le s tesnim sodelovanjem med vsemi udeleženci. Ljudje, ki vnašajo podatke v operacijske sisteme, se morajo naučiti, katera dejanja vodijo do napak.
Kakovost podatkov je proces. Na žalost veliko organizacij nima strategije za nenehne izboljšave. Mnogi se omejijo le na shranjevanje podatkov in ne izkoristijo celotnega potenciala analitičnih sistemov. Običajno se pri razvoju podatkovnih skladišč 70-80 % proračuna porabi za implementacijo integracije podatkov. Postopek spremljanja in izboljšanja ostaja nedokončan, če sploh.
Orodja
Uporaba programskih orodij lahko pomaga pri procesu avtomatizacije izboljšanja in spremljanja kakovosti podatkov. Na primer, lahko popolnoma avtomatizirajo tehnično preverjanje struktur shranjevanja: format polja, prisotnost privzetih vrednosti, skladnost z imeni polj tabele.
Morda bo težje preveriti vsebino. Ker se zahteve glede shranjevanja spreminjajo, se lahko spreminja tudi interpretacija podatkov. Samo orodje lahko postane ogromen projekt, ki potrebuje podporo.
Nasvet
Relacijske baze podatkov, v katerih so trgovine običajno zasnovane, imajo izjemno sposobnost ustvarjanja pogledov. Z njimi lahko hitro preverite podatke, če poznate posebnosti vsebine. Vsak primer iskanja napake ali težave v podatkih je mogoče zabeležiti v obliki poizvedbe po bazi podatkov.
Na ta način se bo oblikovala baza znanja o vsebini. Seveda morajo biti takšne zahteve hitre. Pogledi običajno zahtevajo manj časa za vzdrževanje kot orodja, ki temeljijo na tabelah. Pogled je vedno pripravljen za prikaz rezultata testa.
V primeru pomembnih poročil lahko pogled vsebuje stolpec s prejemnikom. Za poročanje o stanju kakovosti podatkov v skladišču je smiselno uporabiti ista BI orodja.
Primer
Poizvedba je bila napisana za bazo podatkov Oracle. V tem primeru testi vrnejo številsko vrednost, ki jo je mogoče interpretirati po želji. Vrednosti T_MIN in T_MAX lahko uporabite za prilagoditev stopnje alarma. Polje REPORT je bilo nekoč uporabljeno kot sporočilo v komercialnem izdelku ETL, ki ni znal pravilno pošiljati e-pošte, zato je rpad "bergla".
V primeru velike tabele lahko dodate na primer AND ROWNUM <= 10, tj. če je napak 10, potem je to dovolj za alarm.
CREATE OR REPLACE VIEW V_QC_DIM_PRODUCT_01 AS
SELECT
CASE WHEN OUTPUT>=T_MIN AND OUTPUT<=T_MAX
THEN 'OK' ELSE 'ERROR' END AS RESULT,
DESCRIPTION,
TABLE_NAME,
OUTPUT,
T_MIN,
T_MAX,
rpad(DESCRIPTION,60,' ') || rpad(OUTPUT,8,' ') || rpad(T_MIN,8,' ') || rpad(T_MAX,8,' ') AS REPORT
FROM (-- Test itself
SELECT
'DIM_PRODUCT' AS TABLE_NAME,
'Count of blanks' AS DESCRIPTION,
COUNT(*) AS OUTPUT,
0 AS T_MIN,
10 AS T_MAX
FROM DIM_PRODUCT
WHERE DIM_PRODUCT_ID != -1 -- not default value
AND ATTRIBUTE IS NULL ); -- count blanks
V publikaciji so uporabljeni materiali iz knjige
Ronald Bachmann, dr. Guido Kemper
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird
Vir: www.habr.com