Mellomvare Tjenester: Datakvalitetssikring - dummies

Du bør etablere to forskjellige kvalitetssikrings (QA) tjenester i strømmen av middleware-tjenester. Du må utføre de første QA-oppgaver mot utdraget fra datakilden før du utfører flere mellomvaretjenester.

Datakvalitetssikring: del I

Prøv å fange (og rette) feil og problemer så tidlig i prosessen som mulig. Flytte data ned i rørledningen mot datalageret er meningsløst hvis problemer er så signifikante at de enten krever betydelig innsats for å korrigere senere i prosessen eller rett og slett ikke kan korrigeres.

Så, hvilke typer problemer skal du se etter? Her er noen:

• Verdier i dataelementer som overskrider et rimelig utvalg: En kunde har levert 150 millioner innkjøpsordrer i den siste måneden, for eksempel, eller en ansatt har jobbet med selskapet i 4, 297 år, ifølge medarbeidsdatabasen og den lagrede ansettelsesdatoen.

• Verdier i dataelementer som ikke passer til den offisielle og komplette listen over tillatte verdier: En verdi kan ha en A-kode, for eksempel når de eneste tillatte verdiene for dette feltet er M og F. (Hvis feltet ble merket GENDER, A kan stå for androgynt!)

• Tverrbordets inkonsekvenser: For oppføringer i CUSTOMER_ORDER-tabellen finnes ingen tilsvarende oppføringer (som identifisert av CUSTOMER_ID) i CUSTOMER_MASTER_TABLE.

• Tverrfelt inkonsekvenser: Skrifter som har feil post eller postnummer angitt for byen.

• Manglende verdier: Skrifter som mangler verdier i bestemte felt hvor de skal ha innhold.

• Dataplays: For eksempel bør en kildetabell inneholde en rad data som inneholder totalt solgte enheter og salgspriser for hver måned de siste to årene. For et stort antall kunder finnes det imidlertid ingen rader i minst en av disse månedene.

• Ufullstendige data: Hvis informasjon om hvert produkt som selgeren selger skal være tilgjengelig, er alle produktene inkludert i utdraget?

• Brudd på forretningsregler: Hvis en forretningsregel sier at bare en grossist kan selge produkter til en av selskapets kunder, bør du sjekke om eventuelle kundeoppføringer viser salg gjennom mer enn en grossist, noe som kan indikere feil data i kilden.

• Datakorrupsjon siden siste utdrag: Hvis utvinning skjer månedlig, bør du for eksempel holde oversikt over dataværdier eller summer som skal være konstant, for eksempel SALG PER KUNDE PER MÅNED.Hvis verdien av SALG PER KUNDE PER MÅNED i en påfølgende måned endres for en gitt kunde for en forrige måned, kan de underliggende dataene være skadet.

• Staveforstyrrelser: En kundes navn staves på flere forskjellige måter, for eksempel.

Hva gjør du når du finner problemer? Du kan prøve en av følgende teknikker:

• Bruk en automatisk korrigeringsregel. Når du finner en inkonsekvent stavemåte, gjør du for eksempel et oppslag i en hovedtabell med tidligere stavekorrigeringer og gjør automatisk endringen i dataene.

• Sett opp rekorden for et lagmedlem for å analysere og korrigere senere. I dette tilfellet kan du gjøre den menneskelige delen av QA sammen med automatisk korreksjon.

  For eksempel blir det automatisk gjort korrigeringer, hvis det er mulig, og en rapport om andre problemer blir lagt inn i en egen fil og sendt til QA-personen. Når QA-personen gjør alle manuelle korrigeringer, slår du sammen korrigeringene tilbake til dataene som har gått gjennom den automatiske QA-prosessen.

• Kjøle jetsene dine. Hvis du oppdager nok problemer som er alvorlige eller krever en ubestemt mengde forskning, bør du vurdere å stoppe hele prosessen til etter at du har funnet og fikset problemet.

Du kan gjøre QA-prosessen mye mer effektiv, og mye mindre problematisk, hvis du utfører en grundig kildesystemanalyse. Hvis du har en ganske god ide om hvilke typer dataproblemer du kan finne i hver datakilde, kan du omprogrammere QA-prosessen for å oppdage og (forhåpentligvis) rette opp disse problemene før du fortsetter.

Historisk behandlet organisasjoner data warehouse QA prosessen som en en-retnings flyt. Problemene blir korrigert før dataene flyttes videre inn i strømmen av mellomvareprosesser, men blir aldri korrigert i datakildene. De fleste nye datalager har en innebygd tilbakemeldingsløype fra QA-prosessen som korrigerer datakvalitetsproblemer i kildedataene.

Datakvalitetssikring: del II

Etter ferdigstillelse av transformasjonsprosessene må dataene være QA'd - igjen. Du vet aldri hvilken type feil eller uoverensstemmelser transformasjonsprosessen kan ha innført i dataene. Etter endringer har noen tidligere QA-prosesser ikke lenger gyldighet.

Kjør de konsoliderte, transformerte dataene gjennom samme type QA-trinn som diskuteres her. Selv om du sannsynligvis ikke finner så mange rudimentære feil (som stavefeil eller verdier som er utenfor rekkevidde) hvis du gjorde en grundig jobb på QA på første nivå, vil du fortsatt sørge for det. Videre må du sørge for at koden eller skriptene som brukes til datatransformering ikke ved et uhell forårsaket nye feil å krype inn.

Målet med dette QA-nivået er å sørge for at din konsoliderte og transformerte data er klar til å lastes inn i datalagring - så snart et steg oppstår, om nødvendig.