Middleware Services: Data Quality Assurance - dummies

Du bør etablere to forskellige kvalitetssikringssystemers (QA) tjenester i flow af middleware-tjenester. Du skal udføre de første QA-opgaver mod uddraget fra datakilden, før du udfører flere middleware-tjenester.

Datakvalitetssikring: del I

Prøv at fange (og rette) fejl og problemer så tidligt som muligt. Flytning af data ned over rørledningen mod datalageret er meningsløst, hvis problemer er så signifikante, at de enten kræver betydeligt mere indsats for at rette senere i processen eller simpelthen ikke kan rettes.

Så hvilke typer problemer skal du se efter? Her er et par:

• Værdier i dataelementer, der overstiger en rimelig rækkevidde: En kunde har f.eks. Indsendt 150 millioner indkøbsordrer i den seneste måned, eller en medarbejder har arbejdet med virksomheden i 4, 297 år, ifølge medarbejderdatabasen og den lagrede ansættelsestidspunkt.

• Værdier i dataelementer, der ikke passer til den officielle og komplette liste over tilladte værdier: En værdi kan have en A-kode, f.eks. Når de eneste tilladelige værdier for dette felt er M og F. (Hvis dette felt blev mærket GENDER, et kan stå for androgynt!)

• Indbyrdes uoverensstemmelser: For poster i CUSTOMER_ORDER-tabellen findes der ingen tilsvarende poster (som identificeret af CUSTOMER_ID) i CUSTOMER_MASTER_TABLE.

• Uoverensstemmelser på tværs af felter: Records, der har en forkert stat eller postnummer til den angivne by.

• Manglende værdier: Records, der mangler værdier i bestemte felter, hvor de skal have indhold.

• Datagab: Eksempelvis skal en kildetabel indeholde en række data, der indeholder de samlede solgte enheder og salgspriser for hver måned i løbet af de sidste to år. For et stort antal kunder findes der dog ingen rækker i mindst en af ​​disse måneder.

• Ufuldstændige data: Hvis oplysninger om hvert produkt, som virksomheden sælger, skulle være tilgængeligt, er alle produkter medtaget i uddraget?

• Overtrædelse af forretningsregler: Hvis en forretningsregel fastsætter, at kun en grossist kan sælge produkter til en af ​​virksomhedens kunder, skal du undersøge om nogen kundejournaler angiver salg foretaget gennem mere end en grossist, hvilket kan indikere forkerte data i kilden.

• Datakorruption siden sidste uddrag: Hvis udvindingen sker månedligt, skal du f.eks. Holde styr på dataværdier eller beløb, der skal være konstante, såsom SALG PER KUNDE PER MÅNED.Hvis værdien af ​​SALG PER KUNDE PER MÅNED i en efterfølgende måned ændres for en given kunde for en tidligere måned, kan de underliggende data være blevet beskadiget.

• Staveforstyrrelser: En kundes navn staves f.eks. På flere forskellige måder.

Hvad gør du, når du finder problemer? Du kan prøve en af ​​følgende teknikker:

• Anvend en automatisk korrigeringsregel. Når du finder en inkonsekvent stavning, skal du f.eks. Foretage et opslag i en master-tabel med tidligere stavekorrigeringer og foretage automatisk ændringen i dataene.

• Sæt rekorden for et holdmedlem til at analysere og rette senere. I dette tilfælde kan du gøre den menneskelige del af QA sammen med automatisk korrektion.

  For eksempel foretages der automatisk korrigeringer, og en rapport om andre problemer sættes i en separat fil og sendes til QA-personen. Når QA-personen foretager alle de manuelle korrektioner, fusionerer du korrektionerne igen i de data, der er gennemgået den automatiske QA-proces.

• Cool dine jetfly. Hvis du opdager nok problemer, der er alvorlige eller kræver en ubestemt mængde forskning, skal du overveje at stoppe hele processen, indtil du har fundet og repareret problemet.

Du kan gøre QA-processen meget mere effektiv og meget mindre problematisk, hvis du udfører en grundig analysesystem. Hvis du har en ret god ide om, hvilke typer af dataproblemer du måtte finde i hver datakilde, kan du omprogrammer din QA-proces for at opdage og (forhåbentlig) rette disse problemer, før du fortsætter.

Historisk behandlede organisationer data warehouse QA-processen som en-retningsstrøm. Problemerne rettes, før dataene flyttes videre ind i flowet af middleware-processer, men korrigeres aldrig i datakilderne. De fleste nye datalagre har en indbygget feedback-loop fra QA-processen, der korrigerer datakvalitetsproblemer i kildedataene.

Datakvalitetssikring: del II

Efter færdiggørelsen af ​​transformationsprocesserne skal dataene QA'd - igen. Du ved aldrig, hvilken type fejl eller uoverensstemmelser transformationsprocessen kan have indført i dataene. Når der er sket ændringer, er eventuelle tidligere QA-processer ikke længere gyldige.

Kør de konsoliderede, transformerede data gennem den samme type QA-trin, der diskuteres her. Selv om du sandsynligvis ikke finder så mange rudimentære fejl (som stavefejl eller værdier uden for rækkevidde), hvis du har gjort et grundigt job på dit første niveau QA, vil du stadig sørge for. Desuden skal du sikre dig, at koden eller scriptene, der blev brugt til datatransformation, ikke ved et uheld forårsagede nye fejl.

Målet med dette QA på anden niveau er at sikre, at dine konsoliderede og transformerede data er klar til at indlæses i datalagring - så snart et yderligere trin opstår, om nødvendigt.