Duomenų kokybė sandėlyje yra svarbi prielaida norint gauti vertingos informacijos. Prasta kokybė ilgainiui sukelia neigiamą grandininę reakciją.
Pirma, prarandamas pasitikėjimas pateikta informacija. Žmonės pradeda mažiau naudotis verslo žvalgybos programomis; programų potencialas lieka neišnaudotas.
Dėl to kyla abejonių dėl tolesnių investicijų į analitinį projektą.
Atsakomybė už duomenų kokybę
Duomenų kokybės gerinimo aspektas yra labai svarbus BI projektuose. Tačiau tai nėra tik technikos specialistų privilegija.
Duomenų kokybei įtakos turi ir tokie aspektai kaip
Firmos kultūra
- Ar patys darbuotojai suinteresuoti kokybiškai gaminti?
- Jei ne, kodėl gi ne? Gali kilti interesų konfliktas.
- Galbūt yra įmonių taisyklės, kurios nustato, kas atsakingas už kokybę?
Procesai
- Kokie duomenys sukuriami šių grandinių pabaigoje?
- Galbūt operacinės sistemos sukonfigūruotos taip, kad reikia „pasukti“, kad atspindėtų tą ar kitą situaciją realybėje.
- Ar operacinės sistemos pačios atlieka duomenų patikrinimą ir derinimą?
Kiekvienas organizacijos narys yra atsakingas už duomenų kokybę ataskaitų teikimo sistemose.
Apibrėžimas ir prasmė
Kokybė yra įrodytas klientų lūkesčių patenkinimas.
Tačiau duomenų kokybė neapibrėžiama. Jis visada atspindi naudojimo kontekstą. Duomenų saugyklos ir BI sistemos tikslai skiriasi nuo operacinės sistemos, iš kurios gaunami duomenys.
Pavyzdžiui, operacinėje sistemoje kliento atributas gali būti pasirenkamas laukas. Saugykloje šis atributas gali būti naudojamas kaip matmuo ir jį reikia užpildyti. O tai savo ruožtu įveda poreikį užpildyti numatytąsias reikšmes.
Duomenų saugojimo reikalavimai nuolat kinta ir dažniausiai yra aukštesni nei operacinėms sistemoms. Tačiau gali būti ir atvirkščiai, kai nereikia saugoti išsamios operacinės sistemos informacijos saugykloje.
Kad duomenų kokybę būtų galima išmatuoti, turi būti aprašyti jo standartai. Žmonės, kurie savo darbui naudoja informaciją ir skaičius, turi būti įtraukti į aprašymo procesą. Šio įsitraukimo rezultatas gali būti taisyklė, pagal kurią iš pirmo žvilgsnio į lentelę galima pasakyti, ar yra klaida, ar ne. Ši taisyklė turi būti suformatuota kaip scenarijus / kodas, kad būtų galima vėliau patikrinti.
Duomenų kokybės gerinimas
Duomenų įkėlimo į sandėlį metu neįmanoma išvalyti ir ištaisyti visų hipotetinių klaidų. Gerą duomenų kokybę galima pasiekti tik glaudžiai bendradarbiaujant visiems dalyviams. Žmonės, kurie įveda duomenis į operacines sistemas, turi sužinoti, kokie veiksmai sukelia klaidų.
Duomenų kokybė yra procesas. Deja, daugelis organizacijų neturi nuolatinio tobulėjimo strategijos. Daugelis apsiriboja tik duomenų saugojimu ir neišnaudoja viso analitinių sistemų potencialo. Įprastai kuriant duomenų saugyklas duomenų integravimui įgyvendinti išleidžiama 70-80% biudžeto. Stebėsenos ir tobulinimo procesas lieka neužbaigtas, jei iš viso yra.
Įrankiai
Programinės įrangos įrankių naudojimas gali padėti automatizuoti duomenų kokybės gerinimo ir stebėjimo procesą. Pavyzdžiui, jie gali visiškai automatizuoti techninį saugojimo struktūrų patikrinimą: lauko formatą, numatytųjų reikšmių buvimą, atitiktį lentelių laukų pavadinimams.
Gali būti sunkiau patikrinti turinį. Keičiantis saugojimo reikalavimams, gali keistis ir duomenų interpretacija. Pats įrankis gali tapti didžiuliu projektu, kuriam reikia paramos.
Patarimas
Reliacinės duomenų bazės, kuriose paprastai kuriamos parduotuvės, turi puikią galimybę kurti rodinius. Jie gali būti naudojami norint greitai patikrinti duomenis, jei žinote turinio specifiką. Kiekvienas atvejis, kai duomenyse aptinkama klaida ar problema, gali būti užfiksuotas duomenų bazės užklausos forma.
Tokiu būdu bus suformuota žinių bazė apie turinį. Žinoma, tokie prašymai turi būti greiti. Paprastai rodiniams prižiūrėti reikia mažiau žmogaus laiko nei lentelėse pagrįstiems įrankiams. Rodinys visada paruoštas rodyti testo rezultatą.
Svarbių ataskaitų atveju rodinyje gali būti stulpelis su gavėju. Prasminga naudoti tuos pačius BI įrankius norint pranešti apie duomenų kokybės būklę sandėlyje.
Pavyzdys
Užklausa buvo parašyta „Oracle“ duomenų bazei. Šiame pavyzdyje testai grąžina skaitinę reikšmę, kurią galima interpretuoti kaip pageidaujama. T_MIN ir T_MAX reikšmės gali būti naudojamos aliarmo lygiui reguliuoti. Laukas REPORT kažkada buvo naudojamas kaip pranešimas komerciniame ETL gaminyje, kuris nežinojo, kaip tinkamai siųsti el. laiškus, todėl rpad yra „ramentas“.
Didelės lentelės atveju galite pridėti, pavyzdžiui, AND ROWNUM <= 10, t.y. jei yra 10 klaidų, to pakanka, kad sukeltų aliarmą.
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
Leidinyje panaudota knygos medžiaga
Ronaldas Bachmannas, dr. Gvidas Kemperis
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird
Šaltinis: www.habr.com