Kvaliteten af data på lageret er en vigtig forudsætning for at opnå værdifuld information. Dårlig kvalitet fører til en negativ kædereaktion i det lange løb.
For det første går tilliden til de oplyste oplysninger tabt. Folk begynder at bruge Business Intelligence-applikationer mindre; applikationernes potentiale forbliver uanmeldt.
Som følge heraf sættes yderligere investering i analyseprojektet i tvivl.
Ansvar for datakvalitet
Aspektet relateret til at forbedre datakvaliteten er megavigtigt i BI-projekter. Det er dog ikke kun tekniske specialisters privilegium.
Datakvaliteten er også påvirket af aspekter som
Virksomhedskultur
- Er arbejderne selv interesserede i at producere god kvalitet?
- Hvis ikke, hvorfor ikke? Der kan være en interessekonflikt.
- Måske er der virksomhedsregler, der bestemmer, hvem der har ansvaret for kvaliteten?
processer
- Hvilke data skabes i slutningen af disse kæder?
- Måske er operativsystemerne konfigureret på en sådan måde, at du skal "dreje" for at afspejle denne eller hin situation i virkeligheden.
- Udfører operativsystemer selv dataverifikation og afstemning?
Alle i organisationen er ansvarlige for kvaliteten af data i rapporteringssystemer.
Definition og betydning
Kvalitet er den dokumenterede tilfredsstillelse af kundernes forventninger.
Men datakvalitet indeholder ikke en definition. Det afspejler altid brugskonteksten. Datavarehuset og BI-systemet tjener andre formål end det operativsystem, som dataene kommer fra.
For eksempel på et operativsystem kan kundeattributten være et valgfrit felt. I lageret kan denne attribut bruges som en dimension, og dens udfyldning er påkrævet. Hvilket igen introducerer behovet for at udfylde standardværdier.
Kravene til datalagring ændrer sig konstant, og de er normalt højere end for operativsystemer. Men det kan også være omvendt, når der ikke er behov for at gemme detaljerede oplysninger fra styresystemet i lageret.
For at gøre datakvaliteten målbar, skal dens standarder beskrives. Personer, der bruger oplysninger og tal til deres arbejde, skal inddrages i beskrivelsesprocessen. Resultatet af denne involvering kan være en regel, hvorefter man ved et blik på bordet kan se, om der er en fejl eller ej. Denne regel skal formateres som et script/kode til efterfølgende verifikation.
Forbedring af datakvalitet
Det er umuligt at rydde op og rette alle hypotetiske fejl under processen med at indlæse data på lageret. God datakvalitet kan kun opnås gennem tæt samarbejde mellem alle deltagere. Folk, der indtaster data i operativsystemer, skal lære, hvilke handlinger der fører til fejl.
Datakvalitet er en proces. Desværre har mange organisationer ikke en strategi for løbende forbedringer. Mange begrænser sig til kun at gemme data og udnytter ikke analytiske systemers fulde potentiale. Ved udvikling af datavarehuse bruges typisk 70-80 % af budgettet på implementering af dataintegration. Overvågnings- og forbedringsprocessen er stadig ufuldstændig, hvis overhovedet.
Værktøj
Brugen af softwareværktøjer kan hjælpe i processen med at automatisere forbedring og overvågning af datakvalitet. For eksempel kan de fuldt ud automatisere den tekniske verifikation af lagerstrukturer: feltformat, tilstedeværelse af standardværdier, overholdelse af tabelfeltnavne.
Det kan være sværere at kontrollere indholdet. Efterhånden som lagringskravene ændres, kan fortolkningen af dataene også ændre sig. Selve værktøjet kan blive et kæmpe projekt, der kræver støtte.
Rådet
Relationelle databaser, hvor butikker typisk er designet, har den bemærkelsesværdige evne til at skabe visninger. De kan bruges til hurtigt at tjekke data, hvis du kender indholdets detaljer. Hvert tilfælde af at finde en fejl eller et problem i dataene kan registreres i form af en databaseforespørgsel.
På den måde vil der blive dannet en videnbase om indholdet. Naturligvis skal sådanne anmodninger være hurtige. Visninger kræver typisk mindre menneskelig tid at vedligeholde end tabelbaserede værktøjer. Visningen er altid klar til at vise resultatet af testen.
I tilfælde af vigtige rapporter kan visningen indeholde en kolonne med modtageren. Det giver mening at bruge de samme BI-værktøjer til at rapportere om tilstanden af datakvalitet på lageret.
Eksempel
Forespørgslen blev skrevet til Oracle-databasen. I dette eksempel returnerer testene en numerisk værdi, der kan fortolkes som ønsket. T_MIN og T_MAX værdierne kan bruges til at justere alarmniveauet. RAPPORT-feltet blev engang brugt som en besked i et kommercielt ETL-produkt, der ikke vidste, hvordan man korrekt sender e-mails, så rpad er en "krykke".
Ved en stor tabel kan du f.eks. tilføje AND ROWNUM <= 10, dvs. hvis der er 10 fejl, så er dette nok til at forårsage 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
Udgivelsen bruger materialer fra bogen
Ronald Bachmann, Dr. Guido Kemper
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird
Kilde: www.habr.com