Kvaliteten på dataene på lageret er en viktig forutsetning for å få verdifull informasjon. Dårlig kvalitet fører til en negativ kjedereaksjon på sikt.
For det første går tilliten til informasjonen som gis tapt. Folk begynner å bruke Business Intelligence-applikasjoner mindre; potensialet til applikasjoner forblir uavhentet.
Som et resultat blir ytterligere investering i analyseprosjektet satt i tvil.
Ansvar for datakvalitet
Aspektet knyttet til forbedring av datakvalitet er megaviktig i BI-prosjekter. Det er imidlertid ikke kun tekniske spesialisters privilegium.
Datakvalitet påvirkes også av slike aspekter som
Bedriftskultur
- Er arbeiderne selv interessert i å produsere god kvalitet?
- Hvis ikke, hvorfor ikke? Det kan være en interessekonflikt.
- Kanskje er det bedriftsregler som bestemmer hvem som har ansvaret for kvaliteten?
prosesser
- Hvilke data opprettes på slutten av disse kjedene?
- Kanskje operativsystemene er konfigurert på en slik måte at du må "vri" for å gjenspeile denne eller den situasjonen i virkeligheten.
- Utfører operativsystemer dataverifisering og avstemming selv?
Alle i organisasjonen er ansvarlige for kvaliteten på data i rapporteringssystemer.
Definisjon og mening
Kvalitet er bevist tilfredsstillelse av kundenes forventninger.
Men datakvalitet inneholder ingen definisjon. Det gjenspeiler alltid brukskonteksten. Datavarehuset og BI-systemet tjener andre formål enn operativsystemet som dataene kommer fra.
For eksempel, på et operativsystem, kan kundeattributtet være et valgfritt felt. I depotet kan dette attributtet brukes som en dimensjon, og fyllingen er nødvendig. Noe som igjen introduserer behovet for å fylle inn standardverdier.
Kravene til datalagring er i stadig endring, og de er vanligvis høyere enn for operativsystemer. Men det kan også være omvendt, når det ikke er behov for å lagre detaljert informasjon fra operativsystemet i lagringen.
For å gjøre datakvaliteten målbar, må standardene beskrives. Personer som bruker informasjon og figurer til sitt arbeid må involveres i beskrivelsesprosessen. Resultatet av dette engasjementet kan være en regel som følger med et blikk på bordet om det er en feil eller ikke. Denne regelen må formateres som et skript/kode for etterfølgende verifisering.
Forbedring av datakvalitet
Det er umulig å rydde opp og korrigere alle hypotetiske feil under prosessen med å laste data inn i lageret. God datakvalitet kan kun oppnås gjennom tett samarbeid mellom alle deltakere. Folk som legger inn data i operativsystemer, må lære hvilke handlinger som fører til feil.
Datakvalitet er en prosess. Mange organisasjoner har dessverre ikke en strategi for kontinuerlig forbedring. Mange begrenser seg til kun å lagre data og bruker ikke det fulle potensialet til analysesystemer. Vanligvis, når man utvikler datavarehus, brukes 70-80 % av budsjettet på å implementere dataintegrasjon. Overvåkings- og forbedringsprosessen er fortsatt ufullstendig, om i det hele tatt.
Verktøy
Bruk av programvareverktøy kan hjelpe i prosessen med å automatisere forbedring og overvåking av datakvalitet. For eksempel kan de fullt ut automatisere teknisk verifisering av lagringsstrukturer: feltformat, tilstedeværelse av standardverdier, samsvar med tabellfeltnavn.
Det kan være vanskeligere å kontrollere innholdet. Ettersom lagringskravene endres, kan også tolkningen av dataene endres. Selve verktøyet kan bli et stort prosjekt som krever støtte.
Rådet
Relasjonsdatabaser, der butikker vanligvis er utformet, har den bemerkelsesverdige evnen til å lage visninger. De kan brukes til raskt å sjekke data hvis du kjenner detaljene til innholdet. Hvert tilfelle av å finne en feil eller et problem i dataene kan registreres i form av en databasespørring.
På denne måten vil det dannes en kunnskapsbase om innholdet. Selvfølgelig må slike forespørsler være raske. Visninger krever vanligvis mindre menneskelig tid å vedlikeholde enn tabellbaserte verktøy. Visningen er alltid klar til å vise resultatet av testen.
Ved viktige rapporter kan visningen inneholde en kolonne med mottakeren. Det er fornuftig å bruke de samme BI-verktøyene for å rapportere om tilstanden til datakvalitet på lageret.
Eksempel
Spørringen ble skrevet for Oracle-databasen. I dette eksemplet returnerer testene en numerisk verdi som kan tolkes som ønsket. T_MIN- og T_MAX-verdiene kan brukes til å justere alarmnivået. RAPPORT-feltet ble en gang brukt som en melding i et kommersielt ETL-produkt som ikke visste hvordan de skulle sende e-poster på riktig måte, så rpad er en "krykke".
Ved en stor tabell kan du legge til for eksempel AND ROWNUM <= 10, dvs. hvis det er 10 feil, er dette nok til å forårsake 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
Publikasjonen bruker materiale fra boken
Ronald Bachmann, Dr. Guido Kemper
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird
Kilde: www.habr.com