Middleware Tjänster: Data Quality Assurance - dummies

Du bör skapa två olika kvalitetssäkringstjänster i flödet av middleware-tjänster. Du måste utföra de första QA-uppgifterna mot extraktet från datakällan innan du utför mer middleware-tjänster.

Datakvalitetssäkring: del I

Försök att fånga (och korrigera) fel och problem så tidigt som möjligt. Att flytta data ner i rörledningen mot datalageret är meningslöst om problem är så signifikanta att de antingen kräver avsevärt större ansträngning för att korrigera senare i processen eller helt enkelt inte kan rättas.

Så, vilka typer av problem ska du leta efter? Här är några:

• Värden i dataelement som överstiger ett rimligt intervall: En kund har lämnat in 150 miljoner inköpsorder under den senaste månaden, till exempel, eller en anställd har arbetat med företaget i 4, 297 år, enligt anställddatabasen och det lagrade anställningsdatumet.

• Värden i dataelement som inte passar den officiella och kompletta listan över tillåtna värden: Ett värde kan ha en A-kod, till exempel när de enda tillåtna värdena för det fältet är M och F. (Om det fältet var märkt GENDER, A kan stå för androgynt!)

• Innebörden av interna tabeller: För poster i CUSTOMER_ORDER-tabellen finns inga motsvarande poster (som identifieras av CUSTOMER_ID) i CUSTOMER_MASTER_TABLE.

• Inkonsekventa inkonsekvenser: Rekord som har en felaktig stat eller postnummer för den angivna staden.

• Saknade värden: Poster som saknar värden i vissa fält där de ska ha innehåll.

• Data luckor: Till exempel bör en källtabell innehålla en rad data som innehåller totala enheter som såldes och försäljningsdollar för varje månad under de senaste två åren. För ett stort antal kunder finns dock inga rader för minst en av dessa månader.

• Ofullständiga data: Om information om varje produkt som företaget säljer ska vara tillgänglig, till exempel, ingår alla produkter i utdraget?

• Överträdelser av affärsregler: Om en affärsregel anger att endast en grossist kan sälja produkter till någon av företagets kunder, bör du kontrollera om eventuella kundrekord anger försäljning genom mer än en grossist, vilket kan ange felaktiga uppgifter i källan.

• Datakorruption sedan det senaste extraktet: Om utvinningen sker månadsvis, bör du till exempel hålla reda på datavärden eller summor som ska vara konstanta, t.ex. SÄLJNING PER KUND PER MÅNAD.Om värdet av försäljningen per kund per månad i en efterföljande månad ändras för en viss kund för en föregående månad, kan de underliggande uppgifterna ha skadats.

• Stavningsinsammanhang: En kunds namn stavas på flera olika sätt, till exempel.

Vad gör du när du hittar problem? Du kan prova en av följande metoder:

• Använd en automatisk korrigeringsregel. När du hittar en inkonsekvent stavning, gör du en sökning i en malltabell av tidigare stavningskorrigeringar och gör automatiskt ändringen i data.

• Lägg till rekordet för en lagmedlem för att analysera och korrigera senare. I det här fallet kan du göra den mänskliga delen av QA i samband med automatisk korrigering.

  Till exempel görs automatiskt korrigeringar, om möjligt, och en rapport om andra problem sätts i en separat fil och skickas till QA-personen. När QA-personen gör alla manuella korrigeringar sammanfogar du korrigeringarna tillbaka till de data som har gått igenom den automatiska QA-processen.

• Coola dina jetar. Om du upptäcker tillräckligt med problem som är allvarliga eller kräver en obestämd mängd forskning, överväg att stoppa hela processen tills du har hittat och åtgärdat problemet.

Du kan göra QA-processen mycket effektivare, och mycket mindre problematisk, om du utför en grundlig källsystemanalys. Om du har en ganska bra uppfattning om vilka typer av dataproblem du kan hitta i varje datakälla, kan du omprogrammera din QA-process för att upptäcka och (förhoppningsvis) korrigera dessa problem innan du fortsätter.

Historiskt behandlade organisationer QA-processen för datalagret som ett enriktat flöde. Problem korrigeras innan data flyttas vidare till flödet av middleware-processer men korrigeras aldrig i datakällorna. De flesta nya datalager har en inbyggd återkopplingsslinga från QA-processen som korrigerar datakvalitetsproblem i källdata.

Datakvalitetssäkring: del II

Efter slutförandet av omvandlingsprocesserna måste data vara QA'd - igen. Du vet aldrig vilken typ av fel eller avvik som omvandlingsprocessen kan ha infört i data. När förändringar har inträffat är inga tidigare QA-processer längre giltiga.

Kör den konsoliderade transformerade data genom samma typ av QA-steg som diskuteras här. Även om du förmodligen inte hittar så många rudimentära fel (som stavfel eller värden som inte är i intervallet) om du gjorde ett grundligt jobb på din QA-nivå på första nivå, vill du ändå vara säker. Dessutom ska du se till att koden eller skripten som används för datatransformation inte av misstag orsakade nya fel.

Målet med denna andra nivå QA är att se till att din konsoliderade och transformerade data är redo att ladda in i datalager - så snart ett steg uppstår, om det behövs.